Three Identities, One QR Code: How a Print-Shop Domain Laundered a Rail-Executive Signature Into an HR Handbook Lure

A grid-operations staffer received what looked like a routine HR message from their own employer. The subject line named the organization directly: a new policy handbook effective December 2025, covering jury duty, bereavement, and vacation changes, requiring a signed acknowledgment. The sender display name read "OneDrive Sharing."

Nothing in the first read flagged it.

The sending address belonged to a graphics and printing services company in Angola. The signature claimed a senior director at a European rail-infrastructure agency. The only action item in the message was a QR code image. The QR destination was never resolved.

This is a three-identity impersonation delivered through a QR payload designed to bypass every scanner standing between the inbox and a click.

Three organizational names, zero consistent identity

The message assembled its deception from three unrelated organizations. The subject line invoked the recipient's own employer directly, giving the HR lure immediate organizational relevance. A real policy update from internal HR would do exactly that. But the From address resolved to a domain with no connection to the employer, and the signature block at the bottom of the message attributed the communication to a named senior executive at a European rail-infrastructure agency, complete with a Portuguese-language email address and phone number.

From address: unrelated foreign services domain. Subject: the recipient's employer. Signature: a European infrastructure executive. None of those identities overlap, and none of them is a real HR sender for a US grid-operations organization.

This kind of triple-identity mismatch is a common scaffold in image-based phishing attacks where the payload is an image rather than a link. Because the malicious URL lives inside the QR graphic, the attacker needs the surrounding text to carry enough plausibility to prompt a scan. Borrowing the recipient's own employer name in the subject line is the primary plausibility hook. The mismatched signature is either careless reuse of a template or deliberate noise.

How Amazon SES laundered the authentication stack

The message arrived through Amazon SES, specifically from outbound IP 54.240.27.56 on the us-west-2 endpoint. The relay chain runs SES to Microsoft's front-end servers to the recipient tenant, a standard commercial delivery path.

Authentication results: SPF passed (the SES IP was an authorized sender for the domain). DKIM passed with two valid signatures, one signed by the sending domain and one by amazonses.com. DMARC passed with an action of none. Composite authentication scored at 100.

That result looks identical to a legitimate message from the same infrastructure. It is supposed to. The attacker used a real domain's credentials through a real cloud sending service, and every check came back clean because every check was evaluating the infrastructure, not the intent.

The sending domain's DMARC policy was set to p=none: monitor only, no enforcement. Even if something had triggered a DMARC failure, the policy instructs receivers to take no action. Combined with an SPF soft-fail configuration, the domain was effectively sending with no authentication backstop. Permissive authentication posture is what makes a domain an attractive vehicle for abuse.

The MITRE ATT&CK framework documents this infrastructure pattern under Phishing: Spearphishing Attachment for the lure delivery and Phishing for Information: Spearphishing via Service for the exploitation of trusted cloud infrastructure to establish sender legitimacy.

The QR code is the gap that matters

The textual links in this message point entirely to Microsoft domains: Teams join URLs, support.office.com, aka.ms redirectors, a dial-in number. Every one of those was scanned and came back clean. That is not an accident. The Microsoft Teams block is a template element giving the message a veneer of internal meeting infrastructure, and all of those links scan cleanly because they are, in fact, real Microsoft addresses.

The actual payload is the embedded QR code, and it was not decoded from the evidence in this case. The incident record lists qrs: [] and the links analysis notes the QR could not be inspected without physically scanning the image. That is the design: quishing works precisely because the encoded URL never appears as text in the message, never touches a link-rewriting proxy, and never gets checked by a Safe Links-style scanner unless the security platform has dedicated QR image-decoding capability.

A recipient who scans the code with a personal mobile device on a corporate network becomes the URL evaluator. Whatever destination the QR encodes, the device resolves it before any organizational control can intervene.

Indicators of compromise

What caught it and what still stands as a gap

Four mailboxes received this message. All four were quarantined within roughly two hours. The detection surface was behavioral: the combination of a first-time sender, organizational identity mismatches across the From address, subject, and signature, and community reputation signals flagged the message before anyone scanned the QR code.

The gap that remains structural is the QR payload itself. Credential harvesting attacks delivered through QR codes exploit the boundary between email inspection and mobile device behavior. The email system sees an image. The mobile device sees a URL. What lives at that URL is invisible to the organization's security stack unless the platform specifically decodes and evaluates QR payloads before delivery.

The defense is not a signature check or a link scanner. It is QR-aware inspection at the mail layer combined with clear policy that employees do not scan codes from unexpected HR communications without out-of-band verification.

Verify through HR directly. The code can wait.

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