Stop IEH-style fake M365 login credential theft

One password into a fake Microsoft login page. A defense manufacturer's mailbox open.

According to IEH Corporation’s Form 8-K, an employee followed a hyperlink dressed as a Microsoft document-sharing link from a spoofed prospective business contact, entered Microsoft 365 credentials on a fraudulent login page, and enabled a threat actor using an alias to read mail, attachments, customer communications, purchase orders, engineering documentation, and potentially export-controlled technical information. IEH discovered the access on 2026-08-04, secured the account, disabled malicious mailbox rules, reported no evidence of successful exfiltration, and filed the 8-K on 2026-08-06.

Portable secrets on the wrong origin are enough. MFA 2.0 does not put a factor on that page worth stealing.

What the IEH 8-K documents about the lure

IEH Corporation is a U.S. defense and aerospace connector manufacturer. The public record is an SEC Form 8-K, not a rumor thread. A threat actor using an alias impersonated a prospective business contact and delivered a hyperlink disguised as a Microsoft document-sharing link. The employee opened it and entered Microsoft 365 credentials into a fraudulent login page. That submission produced unauthorized access to one employee mailbox.

Scope in the filing: emails, attachments, customer communications, purchase orders, engineering documentation, and potentially export-controlled technical information. The attacker also created malicious mailbox rules. IEH disabled those rules during containment. The company stated that no evidence currently exists that unauthorized emails were transmitted from the account or that data was successfully exfiltrated, and that it believes the incident will not have a material adverse effect on business operations.

What the 8-K does not describe matters as much as what it does. No reverse proxy. No adversary-in-the-middle kit. No named MFA bypass. Credentials on a fraudulent page. One workforce identity. One mailbox. Stay inside those lines.

For the attack-side walkthrough, see the related post on legacymfa.sucks: IEH employee M365 mailbox phished via fake login page.

Why a typed Microsoft 365 secret still loses to a lookalike page

Initial access was a credential-phase problem. Authentication for the attacker had not completed until the employee submitted secrets the attacker could reuse. A password is portable. Anything else the fraudulent form asked the user to type (one-time codes, recovery strings, or similar) is portable the same way. An attacker-controlled page is the wrong origin. Portable factors do not care about origin.

That is the industrial failure mode for employee M365 credential phishing on a fake login page. Collaboration UX makes the lure boringly effective. "Open the shared document from a prospective contact" is ordinary work in manufacturing supply chains. The page only needs to look enough like Microsoft 365 sign-in for one busy person to complete the form. Once those secrets leave the real enterprise boundary, the attacker can authenticate as the employee on the real service.

There is no public statement that MFA was missing, fatigued, approved, or defeated by a named kit. Claiming a specific bypass mechanism would be fiction. What is documented: a transferable factor was collected on a page the company did not control. Common workforce patterns still rely on secrets users can type or approve under coaching. Those patterns fail the moment the user trusts the wrong tab.

After credential acceptance, the incident moved into post-authentication mailbox use. Reading mail and planting rules assume a live session already exists. No login control rewinds an opened mailbox. Malicious rules are persistence inside that session: divert threads, hide traffic, keep a quiet view into purchase orders and engineering mail without another click from the victim. Containment after discovery (secure the account, disable rules, preserve evidence, review authentication protections) is necessary operations work. It is not proof that authentication was healthy upstream.

The split is mechanical. Credential harvest decides whether the attacker ever holds a usable Microsoft 365 session. Data access and rule abuse are consequences of that session. Treating revoke-and-detect as the main lesson of a fake-page credential phishing attack confuses backup hygiene with root-cause removal.

How phishing-proof MFA 2.0 starves the fraudulent form

Prevention starts at the form, not at the rule inbox. With phishing-proof MFA 2.0, sign-in proof is a private key held in hardware on an enrolled device. The server stores public keys, not a password database worth stealing and not a symmetric OTP seed. The private key never crosses the network as something a user can paste into a stranger's page. Signatures are bound to the legitimate enterprise origin. A fraudulent Microsoft lookalike is the wrong place. It cannot complete a channel-bound ceremony the real IdP will accept.

That is why the IEH-style path dies early. The employee can still be coached to open a "document share" link. They can still land on a polished fake page. What they cannot usefully do is hand the attacker a reusable secret that finishes authentication elsewhere. No password to replay. No typed second factor to relay. No enrollment code on that page that turns the attacker into a newly trusted device. The fake form becomes theater without a harvest.

Passkeys and FIDO2-style WebAuthn factors put a key pair on the user device and keep the private half in hardware. The IdP challenges the device. The device returns an origin-bound signature. On a real enterprise identity provider that enforces that ceremony, a lookalike host is not a valid origin, so the signature the attacker needs does not materialize for their page. Industry language correctly calls this phishing-resistant at the login act: it hardens authentication when deployment forbids fallback to typed secrets. It is not automatically full-lifecycle coverage. For the IEH lure, origin-bound login is exactly the property that makes a fraudulent document-share sign-in form useless if no password or OTP remains as a backup path.

IEH's 8-K never discusses device onboarding, helpdesk recovery, or re-enrollment. The documented failure is login-form credential entry. Architects should still not stop at login-only hardening. Passkeys are phishing-resistant when the authentication ceremony is origin-bound, yet many deployments still bootstrap or recover with email codes, SMS, or helpdesk-issued secrets. An attacker who wins that recovery channel can enroll a device that later produces signatures that look legitimate. MFA 2.0 is phishing-proof because no phishable factor appears at registration, device onboarding, authorisation, authentication, or decommissioning. Closing enrollment and recovery is how you keep a second door from replacing the front door you just hardened.

Once a legitimate session already exists, reading the mailbox and creating rules are post-authentication actions. Device-bound login does not reach into Exchange and delete rules the attacker already wrote. It does not magically expire a session issued after a successful phishable login. MFA 2.0 helps this incident class by blocking the upstream credential harvest so that mailbox session is never issued to the attacker in the first place. Residual paths after phishing-proof login is in place are much harder: endpoint malware or other local compromise on a machine that already holds a good session. Getting someone to type on a fake page is cheap for an attacker. Malware on a signed-in device is a different and costlier attack.

Revoke, short lifetimes, and mailbox monitoring still matter as containment when something else goes wrong. They are not equivalent controls to removing phishable login secrets. Shortening a cloud session only forces the attacker to re-steal sooner if the login path still yields transferable factors. If the attacker can register their own factor during a window of access, lifetime knobs stop mattering. Treat revoke as cleanup, not as the fix for fake-page credential phishing.

Architecturally, the point is prevention, not detection: eliminate the transferable factor across the identity path so coached fake origins fail closed. Same-device, hardware-bound proof also removes the need for a second phone prompt the user can be talked into approving under pressure. The ceremony is a fresh signature from keys that never leave the TPM-class boundary, not a code someone reads aloud.

Defense manufacturers live on supplier threads, purchase orders, and engineering attachments. One employee mailbox is already a high-value hub. The durable fix is not a sterner reminder to inspect links. It is an identity architecture where the wrong origin cannot collect a factor worth having.

If you want the control-side walkthrough of phishing-proof, device-bound authentication, start at prevention, not detection.

FAQ

Would phishing-proof MFA 2.0 have stopped the IEH credential harvest?

Yes, at the fraudulent login page. There is no password or typed second factor for the employee to submit off-origin. According to IEH’s Form 8-K, unauthorized mailbox access followed credentials entered on a fake Microsoft 365 login page. Origin-bound hardware signatures do not complete on attacker-controlled hosts, so the attacker never receives the session used to read mail or create rules.

Can any MFA undo the malicious mailbox rules IEH found?

No. According to the 8-K, the attacker created those rules after unauthorized access. IEH disabled them during containment after discovery on 2026-08-04. Rules are post-authentication persistence. Prevention is upstream: block the credential phishing so the session is never issued to the attacker.

Are passkeys alone enough against IEH-style fake M365 pages?

Passkeys are phishing-resistant at login when origin binding holds and typed fallbacks are removed. That targets the fake-page harvest in IEH’s 8-K. They are not automatically phishing-proof across enrollment and recovery if email OTP, SMS, or helpdesk secrets still bootstrap new devices. MFA 2.0 is phishing-proof across the full identity lifecycle so a second phishable door does not replace the login you hardened.

Did IEH report that MFA was bypassed?

No. The Form 8-K documents credential entry on a fraudulent login page and the unauthorized single-mailbox access that followed. MFA type and prompt behavior are not in the public filing. Prevention guidance sticks to the transferable-credential mechanism that is actually described.