TLDR: IEH Corporation filed a Form 8-K disclosing that an employee clicked a fake Microsoft document sharing link, entered their credentials on a fraudulent login page, and handed over a mailbox containing purchase orders, customer correspondence, engineering documentation and possibly export-controlled technical data. The attacker had time to set up mailbox rules before anyone noticed. Nothing about that attack required a large target, and nothing about stopping it requires a large budget.

On 4 August, IEH Corporation discovered that someone using an alias had been reading one of their employees’ Microsoft 365 mailboxes. Two days later they filed an 8-K with the SEC describing what happened, and it is worth reading, because the attack itself is entirely unremarkable.

Someone impersonated a prospective business contact and sent over a hyperlink dressed up as a Microsoft document sharing link. The employee clicked it, was presented with a login page, and typed in their Microsoft 365 credentials. That was the whole attack.

The lure is the interesting part

Most security awareness training teaches people to look for pressure and sloppiness: the urgent invoice, the password expiry warning, the transfer request from the managing director sent at 4:55pm on a Friday. This was none of those. It was a new prospect sharing a document, which for anyone in sales, purchasing or engineering is a normal Tuesday.

There is nothing to spot. The tell would have been the domain in the address bar, on a login page that looked correct because it either was correct, proxied through the attacker’s server, or was a good enough copy that nobody scrutinising it mid-task would catch the difference.

If your defence against this is a person noticing something, your defence is a person having a good day.

The mailbox rules tell you what this was for

Buried in the remediation section of the filing is the detail that matters: malicious mailbox rules were disabled. Rules are not the work of a smash and grab. They are set up so the attacker can keep reading, quietly, while the replies they do not want the victim to see get moved or deleted before anyone opens Outlook.

That is the opening move of business email compromise. The next move is a purchase order or an invoice going out with different bank details on it, from a real address, in a real thread, referencing a real order. The filing lists purchase orders among the accessible material, which fits.

“No evidence of exfiltration” is not the same as “nothing was taken”

The filing states there is no evidence that emails were sent from the account or that data was successfully removed, and then says something more honest than most disclosures manage: the company only knows the information was accessible during the compromise period.

That is the correct way to put it, and it is a limitation of the tooling as much as the investigation. Proving what an attacker did or did not read inside a mailbox depends on audit logging that is switched on, licensed appropriately, and retained long enough to still be there when you go looking. Most organisations find out where they stand on all three at the exact moment they need the answer.

Why a US defence supplier is relevant to a five person business

You could read this and conclude it does not apply to you: public company, SEC obligations, a CFO signing filings, export-controlled technical data. The company is clearly operating in a world with compliance overheads most of my clients will never touch.

That is the wrong read, because none of that had anything to do with how the attack worked. One person, one link, one login page. The attacker did not need to get through a firewall, did not need malware, and did not care how big the company was. They needed a mailbox and someone willing to type a password into a form.

Which means the exposure scales down perfectly. Think about what is in your own mailbox right now: quotes, contracts, client lists, bank details, invoices with your payment terms on them, and password reset links for every other system your business runs on. For a small business, the mailbox is not a communication tool sitting alongside the business, it is a fairly complete copy of it. Compromising the mailbox compromises the identity, and the identity opens everything else.

If anything, the lure used here works better on a small business than a large one. A large manufacturer treats an unsolicited approach from a new contact as routine. A five person business treats it as good news.

What to do about it, without buying anything

The uncomfortable part of this incident is that the fix is not exotic. Multi-factor authentication is the baseline, and it is necessary, but on its own it does not close this. Attackers running reverse proxy phishing capture the session token after the MFA prompt is satisfied, which I’ve written about before. The question your login process needs to answer is not only who is signing in, but what they are signing in from.

That means Conditional Access policies that require a known, compliant device before a mailbox opens, so a stolen token on an unknown machine is worth nothing. It means phishing resistant methods (passkeys, Windows Hello, FIDO2 keys) rather than approval prompts a distracted person taps through. It means legacy authentication blocked outright, because it bypasses the rest. And it means alerting on mailbox rule creation, since that is the earliest reliable sign that someone else is in there.

Here is the part that tends to surprise people: if you’re on Microsoft 365 Business Premium, you already own all of it. Entra ID P1 and Intune are in the licence, which is what Conditional Access and device compliance policies need. Nothing needs purchasing. It needs configuring, once, by someone who knows which policies matter and which ones just generate noise. Business Standard is a different conversation, because it gives you Security Defaults and MFA but no device based policy, and that gap is worth knowing about before you find out the hard way.

The other thing worth doing costs nothing at all: decide now what you would do in the first hour. Revoking sessions rather than only resetting the password, checking mailbox rules, checking which MFA methods are registered against the account, checking what app permissions have been consented to, checking mailbox delegation. Write it down somewhere that is not your email, because if your email is the thing that’s compromised, that’s not where you want your incident plan living.

IEH caught this one, contained it, and filed within two days. That is a competent response. The filing still exists, permanently, in a public archive, because one person clicked a link from someone who seemed like a customer.

Source: IEH Corporation, Form 8-K, filed 6 August 2026

← back to blog index