Cybersecurity Article of the Week – He Verified the Email Before Clicking. It Still Almost Got Him.

The verification that verified nothing

A client received an email from a business contact he genuinely works with. A real person, a real firm, a relationship going back years. The message asked him to open something.

He was suspicious. Good. So he did what every security awareness course tells you to do: he verified it with the sender.

Here’s how he verified it. He opened a brand new email message, addressed it to that contact, and asked, “Did you send me this?”

He got a reply. Yes, I sent it.

So he proceeded. And in doing so, he handed an attacker access to his own Microsoft 365 mailbox.

Here is what had actually happened. The sender’s mailbox was already compromised. There was an intruder sitting inside that contact’s email account, reading mail as it arrived — which means the intruder read the verification email. And the intruder answered it.

What kept this from becoming a disaster was not the verification. It was the monitoring. Our proactive identity monitoring, run in partnership with Petra Security, flagged the unauthorized access almost immediately. The account was locked down on the spot. The attacker never got time to read email, pull attachments, set up forwarding rules, or reach any other data. Minutes, not days.

That gap matters more than anything else in this story. The industry average for catching a business email compromise is measured in weeks. In that window, attackers quietly read everything, learn who pays whom and when, and then send one perfectly timed invoice with new banking details. This one was over before it started.

Why this failed

Email verification only works if the channel you’re verifying through is independent of the channel you’re suspicious of. A new message to the same address is not a different channel. It is the same mailbox, controlled by the same intruder.

This is worth sitting with, because it is the single most common mistake we see from careful people.

In every one of the first four, you have asked the fox whether there is a fox in the henhouse. You will receive a very reassuring answer.

For anyone handling wire instructions, payoff figures, ACH changes, closing funds, or vendor banking details, this is not a best practice. It is the control. Put it in writing as a policy: no payment detail is ever accepted or changed based on email alone, no matter how legitimate the thread looks or how well you know the sender.

An email from yourself, sitting in your own junk folder

A different client, same week. He opened his junk mail folder and found a message that appeared to come from his own email address.

Naturally, his first thought was the worst one: somebody is in my mailbox sending mail as me.

The message was dressed up as a document notification — styled to look like a SharePoint file was waiting for him, with a button to go retrieve it. The button did not go to Microsoft. It pointed at an unrelated website that had nothing to do with SharePoint, his company, or anyone he does business with. The body copy was a mess: a request for quote mashed together with an ACH disbursement notice and a garbled reference number.

Good news first: nobody was in his mailbox. His account was fine.

How an email can claim to be from you

The “From” line on an email is not a credential. It is a text field. Anyone can type anything into it, in the same way anyone can write any return address on the outside of an envelope and drop it in a mailbox. Nothing about writing it makes it true.

Attackers spoof your own address at you because it does two useful things for them. It slips past the mental filter that treats internal mail as safe, and if you do get alarmed, the alarm itself is the hook — panic gets people clicking on “secure your account” links.

Three signals gave this one away, and they are the same three every time:

What actually stops this

Filtering caught this one, which is why it was in junk instead of the inbox. But the deeper fix is at the DNS level: SPF, DKIM, and DMARC are three records that tell the rest of the internet which servers are permitted to send mail as your domain — and what receiving servers should do with mail that fails the check. Configured properly, with DMARC set to reject, they make it substantially harder for anyone to impersonate your domain to your own staff, to your clients, and to your vendors.

If you don’t know whether your domain has these records in place and enforcing, that is a question worth asking this week. It’s a short conversation and a cheap fix, and it protects your reputation in other people’s inboxes as much as your own.

1.  Adopt the phone rule and say it out loud to your team.

Any request involving money, banking details, credentials, or an unexpected file gets verified by voice, using a number you already had.

2.  Check your own junk folder.

Not to click anything — just to see what is being aimed at you. It is a free look at what your staff will see next.

3.  Ask about your SPF, DKIM, and DMARC records.

If nobody at your organization can answer whether DMARC is enforcing, the answer is probably no.

4.  Know how fast you would find out.

Assume that eventually somebody on your team clicks the wrong thing — because eventually somebody does. The question that decides how bad it gets is whether anyone is watching your Microsoft 365 sign-ins in real time. If the honest answer is “we’d find out when something went wrong,” that’s the gap to close.