Phished Employee Gives an Attacker the Keys to a Defense Contractor’s Inbox: How Kiteworks Email Protection Gateway Closes the Gap

A single click on a fake Microsoft sharing link is now enough to hand an attacker years of a company’s engineering correspondence, purchase orders, and export-controlled technical data, and there is nothing unusual about how it happened. That is the uncomfortable lesson from IEH Corporation’s disclosure this week, first reported by The Register, that a phished employee’s credentials gave an intruder standing access to the company’s Microsoft 365 mailbox.

IEH makes hyperboloid connectors used in the PATRIOT air-defense system, AMRAAM, THAAD, the APKWS precision-guided rocket, and the MARK-48 torpedo. Its Form 8-K filing with the SEC describes an attacker who impersonated a prospective business contact, sent a convincing fake sharing link, and harvested one employee’s Microsoft 365 credentials through the resulting login page. From there, the attacker had access to “mailbox contents, including email messages, attachments, customer communications, purchase orders, engineering-related documentation, and potentially export-controlled technical information.” IEH says it found no evidence the data was copied or exfiltrated, but by its own account, the intruder had that content available to browse for an unspecified “compromise period” before the company caught it on August 4.

This is not a story about a defense contractor doing something wrong. Credential phishing beats identity controls at almost every organization that relies on a login prompt as its last line of defense, and Microsoft 365 tenants are a constant target precisely because a single set of harvested credentials opens the door to everything a mailbox holds. What makes this incident worth studying is the second half of the attack chain: once the attacker was inside, the mailbox itself became the vault. Every purchase order, engineering drawing, and technical exchange that had ever passed through that inbox was sitting there in plain, readable form, with no additional barrier between “logged in” and “read everything.”

That second half is where Kiteworks Email Protection Gateway (EPG) changes the outcome. EPG does not stop a convincing phishing email from landing in an inbox. What it does is make sure that a compromised set of credentials does not automatically translate into a compromised archive of sensitive correspondence, because the sensitive content was never sitting in the native mailbox as plaintext to begin with.

Key Takeaways

1. Credential phishing routinely defeats identity-layer defenses.

The IEH attacker impersonated a prospective business contact and harvested Microsoft 365 credentials through a fake sharing-link login page, a technique that bypasses passwords and, in many configurations, weak or absent multi-factor authentication prompts.

2. The real damage happens after login, not at the login screen.

Once inside IEH’s mailbox, the attacker could browse email messages, attachments, customer communications, purchase orders, engineering documentation, and potentially export-controlled technical data, because all of it lived as plaintext inside the mailbox itself.

3. Kiteworks Email Protection Gateway removes sensitive content from the mailbox attack surface.

EPG applies automated policies to every inbound and outbound message, encrypting, quarantining, or routing sensitive and export-controlled content so it does not sit in the native inbox as an unprotected archive.

4. Centralized audit logging closes the detection gap IEH describes.

IEH could not determine when the intruder first gained access or how long the “compromise period” lasted. EPG’s unified, immutable audit log captures every policy decision on every message, giving security teams the forensic trail needed to scope an incident quickly.

5. Defense Industrial Base contractors face compliance exposure beyond the breach itself.

Export-controlled technical data implicates ITAR, and controlled unclassified information implicates CMMC 2.0 and NIST 800-171, frameworks that expect documented, automated controls over how sensitive data is handled in transit, not manual judgment calls by individual employees.

What Actually Happened at IEH Corporation

The mechanics of the IEH intrusion are almost mundane, which is exactly why they matter. An attacker posed as a prospective business contact and sent a phishing email built around a fake Microsoft sharing link. The employee clicked, landed on a convincing spoof of a Microsoft login page, and entered their credentials. Those credentials were valid for the company’s Microsoft 365 environment, and from that point forward the attacker had the same access to the mailbox that the legitimate user had.

IEH’s SEC filing states plainly what that access exposed: email messages, attachments, customer communications, purchase orders, engineering-related documentation, and potentially export-controlled technical information. For a company whose connectors sit inside PATRIOT, AMRAAM, THAAD, APKWS, and MARK-48 systems, “engineering-related documentation” and “export-controlled technical information” are not abstract categories. They are the kind of content that ITAR and the broader defense-industrial-base compliance regime exist specifically to protect.

IEH says it discovered the intrusion on August 4, secured the account, disabled malicious mailbox rules the attacker had set up, and preserved evidence. It also says it found no evidence the accessed information was copied or exfiltrated. That is a reasonable and honest disclosure, but it also points to a structural problem with mailbox-based security: absence of evidence of exfiltration is not the same as evidence of absence, and native email logging was not built to answer “what exactly did this account view, and when” with forensic precision after the fact.

Why Credential Phishing Beats the Identity Layer

It is tempting to read an incident like this and conclude that IEH needed better MFA or more employee training. Both help. Neither is sufficient on its own, and neither was the point of failure that turned a phishing email into a mailbox compromise with potential export-control implications.

Phishing kits built around fake Microsoft sharing links and device-code flows are specifically engineered to intercept session tokens and credentials in ways that pass right through single-factor logins and, increasingly, through poorly configured MFA as well. The Register has covered this exact pattern before: hundreds of Microsoft 365 tenants compromised daily through device-code phishing, and separate reporting on Russian state-linked actors adapting the same “half-click” email attack technique that IEH describes. Security awareness training reduces how often an employee clicks; it does not change what happens the one time in a hundred that they do.

That is the core design flaw in relying on the identity layer alone: access controls decide who gets in, but they say nothing about what happens to the data once someone, legitimate user or attacker wearing their credentials, is inside. A phished login and a legitimate login look identical to a mailbox that has no independent policy layer governing its content. The fix has to operate on the data itself, not just on the door in front of it.

The Real Exposure Is What a Compromised Mailbox Hands Over

This is the part of the IEH incident that deserves more attention than it has gotten. The attacker did not need to break encryption, defeat a firewall, or move laterally through a network. They needed one set of credentials and a native inbox that stored years of sensitive correspondence as plaintext, fully readable the moment anyone, authorized or not, opened the mailbox.

Purchase orders reveal supplier relationships, pricing, and program details. Engineering documentation can include drawings, specifications, and test data tied directly to weapons systems. Export-controlled technical information is, by definition, data the U.S. government has decided should not reach foreign persons or entities without a license, and once it is sitting in a compromised mailbox, that determination is entirely out of the organization’s hands. IEH’s own language, “gained access to mailbox contents,” describes a business’s entire correspondence history functioning as an unlocked filing cabinet the moment one employee’s credentials were stolen.

This is not unique to IEH. It is how Microsoft 365, Google Workspace, and every other native email platform is architected by default: the inbox is the storage location, the storage location is plaintext, and access control lives entirely at the authentication layer. That architecture works fine until the authentication layer fails, and phishing ensures that it periodically will.

How Kiteworks Email Protection Gateway Changes the Outcome

Kiteworks Email Protection Gateway addresses this exact failure mode by moving policy enforcement into the mail stream itself, rather than leaving it to individual judgment or to whatever the identity layer happens to let through. EPG inspects every inbound and outbound message against organization-defined policies and automatically encrypts, quarantines, rejects, or routes each one based on the data involved and the attributes of the sender, recipient, and message, with no decision required from the employee sending or receiving it.

Applied to a scenario like IEH’s, this matters in a specific and concrete way. Purchase orders, engineering documentation, and anything carrying export-controlled or CUI markings would be identified and handled under policy the moment they entered or left the organization, rather than sitting indefinitely as plaintext inside a Microsoft 365 mailbox. EPG can read Microsoft Purview sensitivity labels directly and apply the correct handling automatically, so a message already classified as CUI or export-controlled does not depend on an employee remembering to encrypt it, or an attacker who compromises that employee’s account gaining unrestricted access to it.

EPG also applies digital rights management controls to protected content on delivery: view-only access, expiration windows, download and forwarding restrictions, and automatic re-encryption of replies to keep the chain of protection intact. That means even legitimate recipients cannot casually forward export-controlled attachments outside their organization, and it means a compromised account cannot simply harvest that content from a mailbox the way IEH’s attacker apparently could, because the protected content lives behind Kiteworks-governed access rather than as a static file sitting in an inbox.

On the inbound side, EPG scans every message with DLP, antivirus, and advanced threat protection before it reaches an employee, catching known malicious payloads and suspicious link patterns that a fake sharing-link phish depends on. None of this eliminates the human risk of a convincing social-engineering attempt. It does mean the attack has to succeed against more than one layer to reach the content that actually matters.

Beyond Encryption: Zero Trust Access and Forensic Visibility

Encryption alone would not have fully addressed IEH’s exposure, because encrypted content that anyone with mailbox access can decrypt and read is not meaningfully protected against a phished account. What closes that gap is combining EPG’s automated encryption with attribute-based access control governed under zero trust architecture, access decisions based on who is asking, what they are asking for, and the context of the request, evaluated every time, rather than a single login event that grants standing access to everything in the mailbox indefinitely.

The second gap EPG closes is forensic. IEH’s filing is candid that it does not know when the intruder first gained access or how long the “compromise period” lasted, a common and honest limitation of native mailbox logging, which was not designed to answer granular questions about what a specific account viewed and when. Kiteworks EPG logs every inbound and outbound message in a unified, normalized, immutable audit log that captures the policy rule matched, the action taken, and the delivery outcome for every message, sensitive or not. That log feeds directly into a SIEM, which means that if an account is ever compromised, security teams can reconstruct exactly what that account touched, rather than working backward from an admission that the scope is unknown.

What This Means for Defense Industrial Base Contractors

IEH is a member of the Defense Industrial Base, and DIB membership brings compliance obligations that most commercial breaches do not trigger. Export-controlled technical information falls under ITAR, which restricts how that data can be accessed, stored, and transmitted regardless of whether an actual foreign transfer occurred. Controlled unclassified information falls under CMMC 2.0 compliance and its underlying NIST 800-171 controls, which explicitly expect organizations to demonstrate, not merely assert, that sensitive data is protected in transit and at rest, with documented, auditable controls rather than reliance on individual employee behavior.

A mailbox breach that exposes engineering documentation and potentially export-controlled data creates problems for a DIB contractor that go well past incident response: compliance exposure, contractual exposure with prime contractors and government customers, and potentially a licensing problem if any of that data qualifies as a controlled export. Automated policy enforcement of the kind EPG provides matters here beyond the raw security benefit, because it is close to what CMMC 2.0 and ITAR increasingly expect as evidence of a functioning compliance program. “We trained employees not to click phishing links” rarely survives an actual assessment.

That obligation is not going away, but the mechanism for verifying it just changed. CMMC 2.0’s Level 2 requirements were built around third-party assessment, a Certified Third-Party Assessment Organization checking a contractor’s controls instead of the contractor checking its own. On July 13, 2026, the Department of Defense suspended that requirement indefinitely and opened a 60-day review of the program, leaving NIST 800-171 self-assessment as the only check on DIB contractors for the foreseeable future. That makes an incident like IEH’s more relevant to the compliance conversation, not less: without an assessor scheduled to verify whether audit logging and access controls actually work, contractors are back to grading their own homework, and a self-reported score has never been able to answer “how long was this account compromised.”

IEH’s report does not attribute the attack, and there is no evidence tying it to any specific state actor. But the pattern is one that intelligence agencies have flagged repeatedly over the past year: Russian state-linked groups have adapted similar email-based intrusion techniques against Western targets, and the Five Eyes alliance has separately warned that China is expanding efforts to recruit contacts through LinkedIn connections tied to defense work. Whether this particular attacker was a criminal after resale value or something more targeted, the exposure to the organization is the same: engineering documentation and export-controlled data sitting in a mailbox is valuable to nearly any adversary who gets in, which is precisely why the content itself needs governance independent of who is currently logged into the account.

Building an Email Security Strategy That Survives the Next Phish

No control eliminates the risk that an employee clicks a convincing phishing link. The realistic goal is making sure that click does not cascade into the kind of exposure IEH disclosed. That means combining strong identity controls, phishing-resistant MFA where possible, with a policy layer that governs the content itself, so a compromised login does not equal a compromised archive of purchase orders and engineering data.

Organizations handling CUI, export-controlled data, or other regulated content should treat the mailbox itself as an asset that needs its own access governance, not just a destination protected by a password. That means automated classification and encryption of sensitive messages, DRM controls on what recipients, authorized or otherwise, can do with what they receive, inbound scanning that catches malicious payloads before an employee ever has the chance to click, and centralized, immutable logging that can answer “what did this account access and when” in hours rather than leaving that question open in an SEC filing.

Kiteworks secure email, extended with the Email Protection Gateway, brings that governance into the existing mail stream without changing how employees send and receive messages day to day, so the protection does not depend on anyone remembering to use it. For contractors operating inside PATRIOT, AMRAAM, THAAD, or any other program with export-control exposure, that is the difference between a phishing click being an inconvenient incident and it being an SEC disclosure with potential ITAR and CMMC consequences attached.

To learn more about closing the gap between a phished credential and a compromised archive of sensitive correspondence, schedule a custom demo today.

Additional Resources

• Blog Post Protect Your Sensitive Content With Email Security
• Brief How to Optimize Email Governance, Compliance, and Content Protection
• Brief Expand Visibility and Automate Protection of All Sensitive Email
• Brief Enhance Kiteworks Secure Email With the Email Protection Gateway (EPG)
• Blog Post Why TLS May Not Be Enough for Your Email Encryption Strategy