Why “the sender looked legitimate” is no longer enough
Some phishing emails are easy to spot.
The sender address looks wrong.
The spelling is poor.
The message feels rushed.
The link clearly goes somewhere strange.
The email fails basic checks.
But not all phishing emails look like that.
We recently reviewed a phishing email that is a useful reminder of how these attacks have changed.
On the surface, it looked fairly ordinary.
It appeared to come from a genuine school email address. The wording was polite. The message was short. There was no dramatic warning, no obvious panic, and no clumsy spelling that made it stand out.
The message simply asked the recipient to review an attached document.
At first glance, that sounds routine.
But it was not.
The usual red flags were not all there
One of the most important points about this example is that some of the classic warning signs were missing.
This was not a random Gmail address pretending to be a school.
It was not an obvious display-name spoof.
It was not full of spelling mistakes.
It did not rely on a crude “act now or else” message.
The email authentication checks also passed.
SPF passed.
DKIM passed.
DMARC passed.
In plain English, that means the email passed the checks that say:
This email is allowed to come from this domain.
That matters.
SPF, DKIM and DMARC are important controls. Every organisation should have them configured properly. They help reduce spoofing and make it harder for attackers to impersonate your domain from unauthorised systems.
But they are not a guarantee that an email is safe.
They do not prove the sender meant to send it.
They do not prove the sender’s mailbox has not been compromised.
They do not prove the attachment is safe.
They do not prove the website behind a link is safe.
They are a trust signal, not a safety certificate.
The attachment was the doorway
The email contained an Excel attachment presented as a document review request.
That attachment did not appear to be the final payload itself. Instead, it acted as a doorway.
Inside the workbook was a fake document access message. It encouraged the user to copy and paste a link into their browser to view the document.
Attackers often use copy-and-paste links because it can help move the user away from the protection built into email platforms. It can also make the action feel more deliberate and less suspicious than clicking a big button in an email.
The user is no longer simply clicking a link.
They are being coached into taking the next step.
That is a common pattern in modern phishing.
The destination was blocked as malicious JavaScript
When the destination was checked, Harmony SASE blocked it with the detection:
GT:JS.Acsogenixx.4222.A92F5851
This is best understood as a malicious JavaScript detection.
The important part is JS.
That tells us the risk was likely linked to JavaScript running on the destination website, rather than the spreadsheet being the whole attack.
In practical terms, this does not automatically mean malware was installed on the device.
It means the web security layer detected malicious or suspicious JavaScript content when the user attempted to access the destination. The request was blocked before the user could continue.
That is exactly what secure web protection is designed to do.
The email got through.
The sender looked credible.
The authentication checks passed.
But the malicious web destination was stopped.
That is why layered security matters.
The fake verification page
The destination also presented what looked like a security verification page.
These fake verification pages are increasingly common.
They may look like a CAPTCHA, a Cloudflare check, a browser challenge, or a “verify you are human” prompt. To a busy user, this can feel normal. We have all seen genuine verification checks online.
Attackers use that familiarity.
A fake verification page can be used to:
- make the site look legitimate
- delay automated scanning
- separate real users from security tools
- redirect users to a credential theft page
- prepare the user for a second-stage attack
- introduce a ClickFix-style instruction where the user is told to run something manually
That does not mean every fake verification page does all of those things.
But it does mean the page should not be trusted.
In this case, the safest outcome was for the site to be blocked before the user could interact with it.
The XML files were probably not the main issue
During analysis, XML files were also visible.
That can look alarming if you are not used to seeing how Office files are built.
Modern Office documents such as .xlsx files are not just single flat files. They are packages made up of XML files, relationships, media, settings and metadata.
Some of the XML seen in this case related to Dublin Core metadata. By itself, that is not unusual.
The XML was probably not the main threat.
The bigger issue was the behaviour of the workbook.
It was being used as a lure to send the user to a malicious web destination.
That distinction matters, because it helps avoid chasing the wrong thing.
The danger was not simply “there was XML”.
The danger was the journey the user was being pushed to follow.
What this attack chain looked like
The likely chain was:
- A credible-looking email arrived from a legitimate-looking school domain.
- The message asked the recipient to review an attached document.
- SPF, DKIM and DMARC passed.
- The Excel attachment opened as a fake document review page.
- The user was instructed to copy and paste a link into their browser.
- The destination showed a fake verification page.
- Harmony SASE blocked the destination as malicious JavaScript.
That is a very different pattern from the old advice of “look for spelling mistakes and strange sender addresses”.
Modern phishing is often cleaner than that.
Why SPF, DKIM and DMARC still matter
This example should not be used as an argument against SPF, DKIM or DMARC.
They help stop unauthorised systems sending email as your domain. They improve trust in your outbound email. They reduce basic spoofing. They support better email filtering decisions.
But they answer a specific question:
Is this email allowed to come from this domain?
They do not answer:
Is this email safe?
That is the key lesson.
A message can pass authentication and still be dangerous.
That can happen if a real mailbox has been compromised. It can also happen if a legitimate service is abused, or if the phishing content is introduced after the email has passed the usual checks.
Security controls need to work together.
The role of layered protection
This incident is a good example of layered protection doing its job.
Email authentication helped validate the sending domain.
Email filtering assessed the message.
The user or recipient had reason to question the attachment.
Web protection blocked the malicious destination.
Endpoint protection would provide another layer if something was downloaded or executed.
Multi-factor authentication would reduce the risk if credentials were later targeted.
No single control is perfect.
But each layer reduces the chance of a successful compromise.
That is especially important for schools, nurseries, charities and small businesses, where staff are busy, budgets are tight, and people often wear several hats.
The answer is not to blame users for missing a subtle attack.
The answer is to make sure they are supported by good controls and a culture where reporting is encouraged.
What staff should be taught to notice
“Check the sender address” is still useful advice, but it is not enough on its own.
Better questions include:
Was I expecting this document?
Does the message explain clearly why I am receiving it?
Is the attachment just a route to a website?
Is it asking me to copy and paste a link?
Is the link going to a genuine Microsoft, Google, school or supplier domain?
Does the site ask me to verify myself before I have even seen the document?
Could I check with the sender using another route?
That last point is important. If something feels unusual, staff should feel able to check.
What organisations should take from this
This example shows why email security cannot rely on one control.
SPF, DKIM and DMARC are essential, but they are not enough by themselves.
Organisations should also consider:
- secure email filtering
- attachment scanning
- safe link protection
- DNS filtering
- secure web gateway protection
- endpoint detection and response
- multi-factor authentication
- conditional access
- staff awareness training
- simple reporting routes
- clear incident response steps
For schools and nurseries, this also connects directly to safeguarding and operational resilience.
If email accounts are compromised, attackers can impersonate trusted people. They can send convincing messages to staff, parents, suppliers or partner organisations. They can also use the trust built up around education domains to reach other organisations.
Cyber security is not just an IT issue.
It is part of keeping the organisation running safely.
The most useful lesson from this email is not that phishing is getting cleverer.
It is that phishing is getting more ordinary.
It did not look dramatic.
It did not scream “scam”.
It passed the usual authentication checks.
It used a familiar document review lure.
It hid the real danger behind a website.
That is why organisations need layered protection.
And it is why staff should be encouraged to pause, question and report.
Because in this case, the red flag was not the sender address.
The red flag was the journey the email wanted the user to take.
