Most BEC detection relies on inspecting the email body for social-engineering cues: urgency language, financial requests, impersonation signals, reply-to mismatches. This attack had none of that. The email arrived with a text/calendar content type, base64-encoded, that rendered as an empty body in the recipient's mail client. No visible text. No links. No attachments. The entire social-engineering payload was compressed into the subject line.
The message passed SPF, DKIM, and DMARC. Composite authentication returned a perfect score. Microsoft delivered it at SCL 1. The only signal that anything was wrong was behavioral: the display name impersonated the target company's own accounts payable department, but the email came from an external domain registered three years prior with privacy-protected WHOIS and a sending IP with no reverse DNS.
The subject line read: "[Company Name] has shared a wire transfer confirmation with [Recipient Name], please review the payment details for confirmation."
That single sentence contains everything the attacker needed to convey: a wire transfer exists, it requires review, and the recipient is personally responsible for confirming it. The urgency is implicit rather than explicit. There is no "ACT NOW" or "URGENT" flag. The tone reads as routine, which is precisely what makes it effective.
The email body was empty. The Content-Type header was set to text/calendar with base64 Content-Transfer-Encoding. When decoded, the calendar payload contained no actionable external links or URI entries in the available rendering. The attacker did not need the body to deliver the social-engineering message because the subject line did the work. The empty calendar body served a different purpose: it evaded content-based inspection.
Many email security engines parse HTML and plain-text bodies for phishing indicators. A text/calendar body is processed differently, often by calendar-specific parsers that look for event metadata (VEVENT, VTODO) rather than social-engineering language. By choosing a content type that most inspection engines handle as structured data rather than prose, the attacker avoided triggering natural language analysis and body-based detection rules.
The sending domain, agasoftwaresolutions[.]com, was registered in April 2023 through Hostinger with privacy-protected WHOIS. The domain has proper email authentication configured:
This is the inverse of a spoofing attack. Instead of forging a legitimate domain's identity, the attacker registered their own domain, configured it correctly, and relied on the fact that authentication only proves a message came from the domain it claims to come from, not that the domain itself is trustworthy. The Verizon 2024 DBIR notes that pretexting attacks now account for a growing share of social-engineering breaches, and purpose-built attacker domains with clean authentication are a key enabler.
The sending IP (178.93.216.150) had no PTR record and routed through mail.150.knowareai[.]com, a mail host with no association to recognized enterprise email infrastructure. The Forefront antispam report showed CTRY:CA (Canada) as the origin country. Microsoft's SCL evaluation returned 1, and the message was delivered to the inbox.
See Your Risk: Calculate how many threats your SEG is missing
The From header used a display name that included the target company's own name followed by "Accounts Payable." The actual sending address was info@agasoftwaresolutions[.]com, a domain with no connection to the target organization. IRONSCALES Adaptive AI detected the impersonation pattern: the company's name appeared in the display name of an external email, a technique designed to make the message appear as an internal or trusted communication in the recipient's inbox preview.
The impersonation was tagged as "Company's Name Appears in Display Name," and the message was flagged with VIP Recipient status. Themis assigned a 60% confidence score. The affected mailbox was quarantined.
The subject line also included the recipient's full name, adding a personalization layer that reinforces the impression of a legitimate, targeted communication. Recipients who see their own name in a subject line from what appears to be their own company's AP department are significantly less likely to question the message's authenticity.
BEC protection that relies on link or attachment scanning would have found nothing to scan in this message. The detection had to come from identity analysis: who is sending, who are they claiming to be, and does the relationship make sense?
| Technique | ID | Application |
|---|---|---|
| Phishing: Spearphishing Attachment | T1566.001 | Calendar invite as delivery mechanism for BEC pretext |
| Impersonation | T1656 | Company name and accounts payable role in display name |
| Match Legitimate Name or Location | T1036.005 | Display name mimicked internal department naming convention |
| Type | Indicator | Context |
|---|---|---|
| Sending Domain | agasoftwaresolutions[.]com | Attacker-registered domain (April 2023, Hostinger, privacy-protected) |
| Sending Email | info@agasoftwaresolutions[.]com | Envelope sender |
| Sending IP | 178[.]93[.]216[.]150 | No PTR record, geolocated to Canada |
| Mail Host | mail[.]150[.]knowareai[.]com | Unrecognized mail host in HELO |
| Content-Type | text/calendar (base64) | Calendar content type used to evade body scanning |
| SPF Result | Pass | Sending IP authorized by agasoftwaresolutions[.]com |
| DKIM Result | Pass (d=agasoftwaresolutions.com, s=selector3) | Valid signature on attacker domain |
| DMARC Result | Pass (p=none) | Aligned authentication, no enforcement |
| CompAuth Result | Pass (reason=100) | Full cryptographic verification |
| SCL | 1 | Low spam confidence, delivered to inbox |
| PTR | Missing | Sending IP has no reverse DNS record |
| CTRY | CA (Canada) | Origin country per Forefront antispam |
When authentication passes perfectly and the email body is empty, the detection surface collapses to identity and metadata. Traditional content inspection has nothing to inspect.
Flag text/calendar emails with financial subject lines. Calendar invites are a normal part of business email, but a calendar content type paired with wire-transfer language in the subject line is an unusual combination that should trigger elevated scrutiny. Build detection rules that cross-reference content type against subject-line keywords.
Penalize missing PTR records on sending IPs. A missing PTR record is a low-cost signal that the sending infrastructure was not configured to standard mail server conventions. While not conclusive alone, combining PTR absence with other signals (new domain, privacy WHOIS, financial subject line) produces a reliable risk score.
Detect company-name impersonation in display names. Any external email where the display name contains the recipient organization's own name should be flagged. This is a simple string-match rule that catches a common BEC technique with minimal false positive risk, since legitimate external senders rarely include the recipient company's name in their own display name.