IEH Defense Contractor Breach: M365 Inbox Compromise via Social Engineering — Detection and Hardening Guide

U.S. defense and aerospace manufacturer IEH Corporation has disclosed a breach stemming from a social engineering attack that gave threat actors access to a Microsoft 365 inbox — potentially including emails containing export-controlled military data. For any organization in the Defense Industrial Base (DIB) handling ITAR- or EAR-regulated technical data, this incident is a case study in why identity, not malware, remains the primary attack surface.

Introduction

IEH Corporation, based in Brooklyn, New York, manufactures high-reliability hyperboloid connectors used in demanding military and aerospace environments. That product line makes the company a textbook target: connectors, interconnects, and related design documentation frequently fall under export control regimes (ITAR/EAR), and adversaries — particularly state-sponsored collection operations — value exactly this category of technical data.

According to the disclosure, attackers used social engineering to compromise access to a company Microsoft 365 mailbox. The exposed contents include emails and potentially export-controlled military data. No CVE, no zero-day, no malware dropper — this was an identity attack against a cloud tenant, the single most common intrusion vector we see against DIB small and mid-size manufacturers in 2026.

The severity here is not measured in CVSS points. It is measured in regulatory exposure (ITAR violations carry civil and criminal penalties), contract risk (DFARS 252.204-7012 rapid reporting obligations to DoD), and the strategic value of the data itself. If your organization holds Controlled Unclassified Information (CUI) or export-controlled technical data in Exchange Online, assume you are being targeted with the same playbook.

Technical Analysis

What Was Hit

• Organization: IEH Corporation, U.S. defense/aerospace manufacturer (hyperboloid connectors for military platforms)
• Attack vector: Social engineering (phishing/credential compromise against a Microsoft 365 identity)
• Impact: Unauthorized access to a Microsoft 365 inbox; emails and attachments exposed, potentially including export-controlled military technical data
• CVEs: None — this is a technique-based intrusion, not a vulnerability exploitation

How These Attacks Typically Work (Defender's View)

While IEH has not published granular TTPs, M365 inbox compromises via social engineering follow a well-documented chain that maps to MITRE ATT&CK:

1. Initial Access (T1566 — Phishing / T1078 — Valid Accounts): The victim receives a targeted lure — fake MFA prompt, DocuSign/SharePoint-themed credential harvester, or an adversary-in-the-middle (AiTM) phishing page (e.g., Evilginx-style) that captures the session token, bypassing basic MFA.
2. Persistence (T1098.002 / T1550.004): The attacker registers an additional MFA method, adds an inbox rule, or grants consent to a malicious OAuth application to maintain access even after password reset.
3. Collection (T1114 — Email Collection): The mailbox is searched for technical drawings, contracts, export-controlled attachments. Attackers frequently create inbox rules to auto-forward or hide inbound mail and use eDiscovery-style keyword searches ("ITAR", "export", "drawing", "spec", part numbers).
4. Exfiltration (T1567 / T1114.003): Data is forwarded to external addresses, synced via a third-party mail client over IMAP/POP, or staged through the attacker's OAuth app using Graph API calls.

Exploitation Status

This is a confirmed, successful intrusion against a defense contractor — not theoretical. Social engineering against M365 tenants is among the most heavily used initial access techniques against the DIB in 2025–2026. No CISA KEV entry applies (no CVE); the relevant frameworks are MITRE ATT&CK and CISA's #StopRansomware / identity-focused guidance.

Why Basic MFA Wasn't Enough

If IEH (or any victim) was protected only by SMS/OTP or push-based MFA without number matching, AiTM phishing kits and MFA fatigue remain viable. The defensive baseline in 2026 is phishing-resistant MFA (FIDO2/passkeys or certificate-based auth) plus Conditional Access token protection — anything less is a compensating control, not a solution.

Detection & Response

This is a technical threat (confirmed breach with defined TTPs). The detections below target the observable behaviors in this attack class: anomalous sign-ins, malicious inbox rule creation, illicit OAuth consent, and mass mailbox access.

Sigma Rules

These rules focus on the highest-fidelity, lowest-noise behaviors: inbox forwarding rules (the single best BEC/intrusion indicator) and suspicious OAuth consent in the tenant.

---
title: Suspicious Exchange Inbox Rule with Forwarding or Hiding Behavior
id: 8c2f4a91-6e3d-4b7a-9f21-5d8c7e6a1b02
status: experimental
description: Detects creation of inbox rules that forward mail externally or hide messages, a hallmark of M365 compromises following phishing/social engineering as seen in the IEH breach.
references:
  - https://securityaffairs.com/196890/cyber-crime/u-s-defense-manufacturer-ieh-hit-by-phishing-attack-exposing-potentially-export-controlled-data.html
  - https://attack.mitre.org/techniques/T1114/003/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.collection
  - attack.t1114.003
  - attack.exfiltration
logsource:
  product: m365
  service: exchange
detection:
  selection_params:
    Parameters|contains:
      - 'ForwardTo'
      - 'ForwardAsAttachmentTo'
      - 'RedirectTo'
      - 'DeleteMessage'
      - 'MoveToFolder'
  selection_ops:
    Operation:
      - 'New-InboxRule'
      - 'Set-InboxRule'
  condition: selection_ops and selection_params
falsepositives:
  - Legitimate user-created forwarding rules (audit and whitelist known shared mailboxes/service accounts)
level: high
---
title: Suspicious OAuth Application Consent in Microsoft 365 Tenant
id: 3b7e9d24-1c5f-4a68-8d93-2f4a6c8e0b13
status: experimental
description: Detects user consent granted to OAuth applications requesting mail read or full mailbox access scopes, a common persistence and exfiltration technique after social engineering compromise.
references:
  - https://securityaffairs.com/196890/cyber-crime/u-s-defense-manufacturer-ieh-hit-by-phishing-attack-exposing-potentially-export-controlled-data.html
  - https://attack.mitre.org/techniques/T1528/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.credential_access
logsource:
  product: azure
  service: auditlogs
detection:
  selection_ops:
    OperationName:
      - 'Consent to application'
      - 'Add delegated permission grant'
      - 'Add app role assignment to service principal'
  selection_scope:
    TargetResources|contains:
      - 'Mail.Read'
      - 'Mail.ReadWrite'
      - 'Mail.Send'
      - 'full_access_as_app'
      - 'EWS.AccessAsUser.All'
      - 'offline_access'
  condition: selection_ops and selection_scope
falsepositives:
  - Legitimate enterprise app onboarding (correlate with approved app inventory; user-consent grants to unknown publishers are the priority)
level: high
---
title: Legacy Protocol Authentication to Exchange Online
id: 5a1c6f38-9b2e-4d47-a3c8-7e9f1b4d2a65
status: experimental
description: Detects authentication to Exchange Online over legacy protocols (IMAP, POP3, SMTP AUTH) frequently abused by attackers after credential phishing to sync and exfiltrate mailbox contents.
references:
  - https://attack.mitre.org/techniques/T1114/002/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.collection
  - attack.t1114.002
logsource:
  product: azure
  service: signinlogs
detection:
  selection:
    ClientAppUsed:
      - 'IMAP4'
      - 'POP3'
      - 'Authenticated SMTP'
      - 'Exchange ActiveSync'
    AppDisplayName|contains: 'Exchange Online'
  condition: selection
falsepositives:
  - Legacy mail clients and multifunction printers still using basic auth (these should be migrated — treat hits as remediation backlog)
level: medium

KQL Hunt (Microsoft Sentinel / Defender)

This query chains the intrusion lifecycle: suspicious sign-in followed by inbox rule creation or mass mail access — the exact pattern expected in a social-engineering-driven M365 compromise.

// Hunt: Suspicious sign-in followed by inbox rule creation or mailbox access anomalies
let lookback = 14d;
let riskySignins =
    SigninLogs
    | where TimeGenerated > ago(lookback)
    | where ResultType == 0
    | where RiskLevelDuringSignIn in ("high", "medium")
       or (LocationDetails.countryOrProvince !in ("US") and isempty(LocationDetails.countryOrProvince) == false)
    | summarize FirstRiskySignIn=min(TimeGenerated), Locations=make_set(Location), IPs=make_set(IPAddress) by UserPrincipalName;
CloudAppEvents
| where TimeGenerated > ago(lookback)
| where Application == "Microsoft Exchange Online"
| where ActionType in ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules")
| extend RuleParams = tostring(RawEventData.Parameters)
| where RuleParams has_any ("ForwardTo", "RedirectTo", "ForwardAsAttachmentTo", "DeleteMessage", "MoveToFolder")
| project TimeGenerated, AccountObjectId, ActionType, RuleParams, IPAddress, ISP
| join kind=inner (riskySignins) on $left.AccountObjectId == $right.UserPrincipalName
| project TimeGenerated, AccountObjectId, ActionType, RuleParams, IPAddress, ISP, FirstRiskySignIn, Locations
| order by TimeGenerated desc;

Supplementary hunt for mass mailbox read via Graph (exfiltration staging):

// Hunt: Abnormal volume of MailItemsAccessed per user/app — possible bulk exfiltration
CloudAppEvents
| where TimeGenerated > ago(7d)
| where ActionType == "MailItemsAccessed"
| extend ClientApp = tostring(RawEventData.AppDisplayName), SessionId = tostring(RawEventData.SessionId)
| summarize AccessCount=count(), DistinctFolders=dcount(tostring(RawEventData.Folders)), Apps=make_set(ClientApp) by AccountObjectId, bin(TimeGenerated, 1h)
| where AccessCount > 500
| order by AccessCount desc;

Tune the AccessCount threshold against your baseline; EDiscovery and backup tooling will appear here — whitelist known service principals.

Velociraptor VQL

If the social engineering lure involved a malicious attachment or credential-harvesting link opened on an endpoint, hunt for evidence of the initial access on the user's workstation — recently executed files from user-writable paths and suspicious browser-to-credential-page artifacts.

-- Hunt for recently executed files in user-writable locations (potential phishing-delivered payloads)
SELECT Pid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Exe =~ '(?i)(\\\\AppData\\\\Local\\\\Temp|\\\\Downloads|\\\\AppData\\\\Roaming)'
  AND Name !~ '(?i)(teams|onedrive|spotify|slack|zoom)'

-- Hunt for recently modified files in Downloads matching common phishing lure extensions
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs='C:/Users/*/Downloads/*')
WHERE Mtime > now() - 1209600
  AND FullPath =~ '(?i)\\.(iso|img|html|htm|lnk|one|pdf\\.exe|zip)$'
ORDER BY Mtime DESC

Remediation / Audit Script

Run this against any tenant where you suspect (or want to rule out) the IEH pattern: forwarding rules, unexpected OAuth grants, legacy auth, and MFA registration gaps.

# Requires: ExchangeOnlineManagement, Microsoft.Graph modules; run as Global Admin or Security Admin
# 1) Audit all mailboxes for forwarding / redirect / hiding rules
Connect-ExchangeOnline
$mailboxes = Get-EXOMailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox,SharedMailbox
foreach ($mbx in $mailboxes) {
    $rules = Get-InboxRule -Mailbox $mbx.UserPrincipalName -ErrorAction SilentlyContinue |
        Where-Object { $_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo -or $_.DeleteMessage -eq $true }
    if ($rules) {
        $rules | Select-Object @{n='Mailbox';e={$mbx.UserPrincipalName}}, Name, ForwardTo, RedirectTo, DeleteMessage, Description |
            Export-Csv -Path .\SuspiciousInboxRules.csv -NoTypeInformation -Append
    }
    # 2) Check SMTP forwarding set at mailbox level
    if ($mbx.ForwardingSmtpAddress -or $mbx.ForwardingAddress) {
        $mbx | Select-Object UserPrincipalName, ForwardingAddress, ForwardingSmtpAddress |
            Export-Csv -Path .\MailboxForwarding.csv -NoTypeInformation -Append
    }
}

# 3) Audit OAuth consent grants with mail scopes
Connect-MgGraph -Scopes "Application.Read.All","AuditLog.Read.All"
Get-MgOauth2PermissionGrant -All | Where-Object {
    $_.Scope -match 'Mail\.Read|Mail\.Send|full_access|EWS'
} | Select-Object ClientId, ConsentType, Scope, ExpiryTime | Export-Csv .\MailScopeGrants.csv -NoTypeInformation

# 4) Disable legacy auth protocols tenant-wide (Exchange Online)
Set-OrganizationConfig -OAuth2ClientProfileEnabled $true
# Per-mailbox: block IMAP/POP for users not explicitly exempted
Get-CASMailbox -ResultSize Unlimited | Where-Object { $_.ImapEnabled -eq $true -or $_.PopEnabled -eq $true } |
    Set-CASMailbox -ImapEnabled $false -PopEnabled $false

# 5) If compromise is suspected for a specific user: kill sessions, revoke refresh tokens, reset creds
# Revoke-MgUserSignInSession -UserId user@domain.com
# Update-MgUser -UserId user@domain.com -PasswordProfile @{ ForceChangePasswordNextSignIn = $true; Password = (New-Guid).Guid }

Remediation

Immediate (0–72 hours) — If You Suspect Similar Compromise

1. Revoke sessions and credentials: For the affected identity, revoke all refresh tokens (Revoke-MgUserSignInSession), force password reset, and re-register MFA methods. Attackers routinely add their own MFA device within minutes of compromise — audit authenticationMethods before assuming the reset stuck.
2. Purge persistence: Enumerate and remove unknown inbox rules (see script), OAuth grants, and mailbox forwarding. Check Set-Mailbox forwarding attributes, not just user-visible rules.
3. Scope the data exposure: Use Purview Audit (Premium) MailItemsAccessed records to determine exactly which emails and attachments were read — this drives your notification obligations.
4. Regulatory clock: If export-controlled technical data was accessed, engage counsel immediately — ITAR/EAR unauthorized access is a reportable event. For DoD contractors, DFARS 252.204-7012 requires reporting cyber incidents within 72 hours via dibnet.dod.mil.

Strategic (30–90 days) — Prevent the Next One

1. Deploy phishing-resistant MFA: FIDO2 security keys or passkeys for all users, mandatory for anyone with access to CUI/export-controlled data. Disable SMS and voice OTP as fallback factors.
2. Conditional Access: Block legacy authentication entirely (Microsoft has been retiring basic auth — verify with the sign-in logs rule above), enforce token protection, require compliant devices for Exchange Online, and block sign-ins from non-approved geographies.
3. Disable external forwarding tenant-wide: Set an outbound spam filter policy with AutoForwardingMode = Disabled. Legitimate forwarding exceptions should go through approval and a monitored allowlist.
4. Segment CUI: Export-controlled technical data should not live in general-purpose mailboxes. Move to a CMMC-aligned enclave with dedicated Conditional Access policies, DLP rules blocking external transmission of ITAR-tagged content, and sensitivity labels.
5. Social engineering resilience: The initial vector was human. Run targeted simulations against staff with access to controlled technical data, and establish out-of-band verification for any MFA reset or password change request.

References

• IEH breach coverage: https://securityaffairs.com/196890/cyber-crime/u-s-defense-manufacturer-ieh-hit-by-phishing-attack-exposing-potentially-export-controlled-data.html
• CISA: Phishing-Resistant MFA guidance — https://www.cisa.gov/mfa
• Microsoft: Protect against AiTM phishing — https://learn.microsoft.com/en-us/entra/identity/conditional-access/
• MITRE ATT&CK T1114 (Email Collection), T1566 (Phishing), T1078 (Valid Accounts)
• DoD DIBNet incident reporting: https://dibnet.dod.mil

The IEH breach is a reminder that in the DIB, the mailbox is the crown jewels. Identity controls, not perimeter appliances, are where this fight is won.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub