The ACH Payment Alert Delivered as a Calendar Invite From a Spoofed Address

The subject line was a complete invoice narrative: an invoice number, a claim that an ACH payment had been processed, and a named employee asked to verify the payment details. The email body was empty. Not minimal. Empty. The Content-Type was text/calendar with base64 encoding, meaning the message was delivered as a calendar invite rather than a standard email. Every content-based scanner that evaluated this message evaluated nothing, because there was no content to evaluate.

The sender address was spoofed to appear as if it came from the recipient's own domain, a facilities services franchise. SPF returned softfail. DKIM was absent. DMARC failed. Yet the message arrived in the inbox with an SCL of -1, the highest trust level, because the sending IP was processed through a Cisco IronPort gateway that the receiving tenant had configured as a trusted connector.

One mailbox was quarantined after automated detection flagged the incident.

An Invoice Subject With No Invoice Inside

The subject read: "Invoice 7513810 has been paid through an automated clearing house transaction, Barbara Roth please verify the payment details." This is a complete social-engineering narrative compressed into a single line. It establishes a financial context (ACH payment), references a specific invoice number to create legitimacy, names the target employee to personalize the request, and demands a verification action.

The email body contained no HTML, no plain text, and no visible content. The MIME type was text/calendar with base64 Content-Transfer-Encoding and inline disposition, indicating a calendar invite payload. Calendar invites are processed differently from standard email bodies by most clients. Outlook, for example, may render a calendar invite directly in the calendar view or as a scheduling notification, bypassing the normal email reading pane where recipients might notice the absence of body content.

The message was marked X-Priority: 1 (High importance), adding visual urgency indicators in email clients that honor priority headers. A fabricated List-Unsubscribe header pointed to unsubscribe@enviro-master[.]com and hxxps://unsubscribe[.]enviro-master[.]com/unsubscribe?user=[recipient], using the legitimate domain to make the message appear to be a transactional communication with opt-out compliance.

See Your Risk: Calculate how many threats your SEG is missing

Unauthorized Infrastructure Wearing a Legitimate Domain

The From and Return-Path addresses both used broth@enviro-master[.]com, the same address as the intended recipient. This self-send pattern is a common spoofing technique that exploits recipients' trust in messages that appear to come from their own organization.

The actual sending infrastructure was entirely disconnected from the spoofed domain. The message originated from IP 162.141.126.18, which resolved to mail.18.send.gasucol[.]com in the SMTP hostname. PTR records for that IP resolved to mail.18.knowareai[.]com, a different hostname than the SMTP banner. Neither gasucol.com nor knowareai.com is an enterprise email gateway or a recognized email security vendor. The infrastructure appears associated with general-purpose hosting, not sanctioned email relay.

Enviro-master[.]com is an established domain registered since 2010 with MX records pointing to Microsoft's protection infrastructure. Its SPF record includes several legitimate third-party senders (Amazon SES, Mailjet, Mailgun, CreateSend) with a softfail (~all) qualifier. The sending IP 162.141.126.18 is not covered by any of these includes. The softfail result means the domain owner has flagged unauthorized IPs as suspicious but has not configured a hard rejection, leaving the final disposition to the receiving gateway.

DKIM was entirely absent. No DKIM-Signature header was present in the message. DMARC evaluated against the header.from domain and returned fail with action=none (the domain's published DMARC policy is p=none). Composite authentication returned compauth=fail with reason=601, indicating that neither SPF nor DKIM produced an aligned pass.

How a Triple Authentication Failure Reached the Inbox

Despite SPF softfail, absent DKIM, and DMARC fail, the message was delivered with SCL=-1. The Forefront antispam report shows SFV:SKN, which means "Skip Network," an override applied when a message is processed through a trusted network connector. The X-IronPort headers confirm the message was processed by a Cisco IronPort appliance (IronPort-AV and IronPort-Anti-Spam-Filtered headers are present). The Cisco X-ThreatScanner-Verdict returned "Negative" (clean).

The delivery chain worked as follows: the message arrived at the IronPort gateway from the unauthorized sending IP. IronPort processed it, applied its own scanning (which returned clean), and forwarded it to Microsoft's mail protection. Microsoft's Exchange Online Protection evaluated the message and saw that it arrived from the IronPort connector IP, which the tenant had configured as trusted. The trusted connector configuration overrode the SPF/DKIM/DMARC evaluation and assigned SCL=-1, delivering the message directly to the inbox.

IRONSCALES Adaptive AI flagged the message at 80% confidence based on behavioral signals. Community intelligence corroborated the classification based on pattern matching with similar self-send spoofing incidents. The mailbox was quarantined by automated detection.

MITRE ATT&CK Alignment

IOC Summary Table

When Your Gateway Overrides the Authentication Your Domain Published

This attack exploits a trust architecture problem. The domain owner configured SPF, DKIM, and DMARC to signal that unauthorized senders should be treated with suspicion. The receiving organization configured a gateway connector that overrides those signals when messages pass through a trusted appliance. The attacker only needed to route through an IP that would be processed by that appliance.

Audit your trusted connector configurations. A connector that assigns SCL=-1 to all traffic from a gateway IP neutralizes SPF, DKIM, and DMARC for every message that transits that gateway, regardless of origin. Consider applying conditional trust that preserves authentication evaluation for messages where SPF or DMARC fails.

Treat calendar-invite payloads from external senders as a content-evasion signal. A legitimate invoice notification does not arrive as a text/calendar payload. When the MIME type is text/calendar and the subject contains financial language, the format choice is almost certainly an attempt to bypass body-content scanning.

Flag self-send patterns where the From address matches the recipient. Messages where the sender and recipient share the same domain and address, particularly from external IPs not authorized by that domain's SPF, are a high-confidence spoofing indicator that should bypass gateway trust overrides.