SPF Passed, DKIM Passed, DMARC Passed. The Replies Were Going Somewhere Else.

The email arrived at the HR department of a global IoT connectivity provider. The display name read "Irene Gao." The sending address was a real domain, operated by a legitimate Indonesian textile manufacturing group. SPF passed. DKIM passed. DMARC passed. The SCL landed at 5, high enough for quarantine, but on authentication results alone, the message looked clean.

There was no body text. The email contained only links to Microsoft support pages and a Microsoft short-link redirect. Every URL pointed to legitimate Microsoft infrastructure.

The attack was not in the links. It was not in an attachment. It was in a single header field that most email security tools never inspect for intent: the Reply-To address.

The Authentication Picture

The sending domain was a legitimate Indonesian manufacturing organization's mail infrastructure. The originating IP (183[.]81[.]154[.]220) submitted the message to the domain's own mail server (mail.yongjin[.]co[.]id), which relayed to the recipient's Microsoft 365 environment through standard MX routing.

SPF validated because the sending IP was authorized for the sending domain. DKIM validated because the message was signed by that domain's private key. DMARC passed because both identifiers aligned. From a technical authentication perspective, this was indistinguishable from a legitimate marketing or vendor communication.

The quarantine outcome (SCL=5) came from the sender risk score flagging a phishing pattern: a first-time sender to a sensitive mailbox combined with a disconnect between the displayed persona and the domain's actual identity. That behavioral signal, not any authentication failure, was what elevated the risk score.

Reply-To as the Attack Mechanism

The From address was agustiansyah@yongjin[.]co[.]id. The Reply-To address was Ireneasiacorp@outlook[.]com.

These two addresses share no domain, no organizational connection, and no logical relationship. The display name persona ("Irene Gao") was chosen to project plausibility for an HR-targeted message, likely referencing a real person's name visible on a professional network. The actual sending account had no relationship to that name.

If an HR staff member had replied to this message (to ask a question, follow up on a request, or send sensitive information), the reply would have traveled to Ireneasiacorp@outlook[.]com, an Outlook address with no connection to the authenticated sending domain. The attacker would receive the reply. The legitimate sending domain owner would receive nothing.

This maps directly to MITRE ATT&CK T1656 (Impersonation) and is a standard Business Email Compromise pattern: build just enough persona credibility to generate a reply, collect the reply in an attacker-controlled mailbox, then escalate the conversation.

Why HR Is the Target

HR departments are a preferred BEC target for several structural reasons. They handle payroll, direct deposit details, bank account change requests, and employee data. They also receive high volumes of email from first-time or unfamiliar senders (candidates, background screening vendors, benefits administrators, legal notices), which normalizes the experience of responding to unknown addresses.

A successful reply capture in this scenario opens a conversation. From there, the attacker can request a direct deposit change, probe for payroll data, or establish a persistent communication channel for follow-on fraud. The initial email requires no malicious payload: the payload is the reply itself.

The use of decoy links to Microsoft support pages (support.microsoft[.]com, aka[.]ms) reflects a deliberate social engineering approach. The message body looks like a corporate communication. An employee scanning the links quickly sees familiar Microsoft domains and concludes the message is safe. The actual attack mechanism, the Reply-To mismatch, is invisible to that visual check.

Detection Without a Payload to Scan

A standard Secure Email Gateway would evaluate this message against URL reputation (clean), attachment scanning (no attachment), sender domain reputation (legitimate manufacturing company), and authentication results (full pass). Every check would return green.

Themis, the IRONSCALES Adaptive AI engine, evaluates the behavioral layer: first-time sender to a sensitive departmental mailbox, display name persona with no relationship to the authenticated domain, Reply-To address on a public webmail provider with a different domain than the From, and decoy Microsoft links used as visual cover. None of those signals are individually conclusive; collectively they are diagnostic, producing a high-risk classification before any employee has a chance to reply.

The SCL=5 quarantine in this case reflected partial scoring from the sending infrastructure's risk profile. Adaptive AI detection adds the contextual layer: the intent model behind a message where everything authenticates but nothing about the recipient-facing information matches the authenticated entity.

Defensive Posture for Reply-To Diversion

Organizations defending against this pattern should examine a few structural controls. First, configure email security to flag any inbound message where the Reply-To domain differs from the From domain, particularly when the Reply-To uses a public webmail provider. Second, apply first-time sender warnings to sensitive departmental mailboxes (HR, Finance, Payroll) to prime employees for additional scrutiny. Third, implement a policy requiring that any request to change banking or payroll information be verified via a secondary out-of-band channel, regardless of how legitimate the email looks.

None of these controls require the attacker to have failed an authentication check. The attack is designed to pass every authentication test. The defense must operate at a different layer.

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

Indicators of Compromise

MITRE ATT&CK Mapping