Sage Brand Impersonation: How a Broken DKIM Signature and a French Payroll Lure Slipped Past the Gateway

When an email passes SPF, passes DMARC, and carries a DKIM signature, most secure email gateways treat it as authenticated. That trust is exactly what this campaign exploited. Attackers dressed up as Sage -- the accounting and HR software vendor used widely across European mid-market businesses -- and sent a French-language payroll whitepaper lure to procurement and finance staff at a multinational engineering services firm. The sending domain was registered weeks before the campaign launched. The DKIM signature used the deprecated rsa-sha1 algorithm and failed body-hash verification at final delivery. Every link in the email resolved not to sage.com but to an unrelated attacker-controlled domain. The gateway waved it through anyway.

This is the authentication-trust trap: a configuration just compliant enough to pass automated checks, built entirely to deceive.

The Lure: Borrowed Brand, Borrowed Trust

The email arrived with the subject line "Téléchargez le Livre blanc de la Paie digitale" ("Download the Digital Payroll White Paper") and a display name of "Sage SBCP PE (ascpm)." The body was a polished, French-language HTML newsletter carrying Sage's green color palette, Trustpilot badge, and corporate footer -- including a Paris-area address and a French VAT/RCS line formatted to match legitimate Sage communications.

The content offered a payroll-focused whitepaper titled "La paie digitale, pilier de l'experience collaborateur" ("Digital payroll, the cornerstone of the employee experience") with multiple calls to action: "Téléchargez le Livre Blanc," "cliquez-ici," plus privacy policy and data charter links. The message was generic, addressed to no one by name, and designed for mass distribution.

There was no credential-harvesting form visible in the email itself. The trap was the destination: every call-to-action, every image, every link resolved to sabo-um[.]info under paths structured as /sage-puzzle/[slug]/. The "sage-puzzle" path naming was deliberate -- close enough to suggest Sage, unconnected enough to give the operator plausible deniability.

Infrastructure Built for Impersonation

The sending domain, simparano[.]com, was registered roughly nine weeks before delivery. Privacy-protected WHOIS, generic Netherlands-based hosting infrastructure, and an MTA (smtp.simparano[.]com at 136[.]144[.]238[.]41) with no affiliation to any recognized email security provider -- these are the hallmarks of a domain stood up specifically to run a campaign.

DKIM was present but compromised in two ways. First, the signature used rsa-sha1, a hashing algorithm NIST deprecated for digital signatures over a decade ago. The DMARC standard recommends rsa-sha256 as the minimum acceptable algorithm; many modern validators treat rsa-sha1 as a reduced-trust signal. Second, and more critically, the body hash embedded in the signature (bh=PUzCwZz6o+t4vsNiJHt6k7+IKOM=) did not match the hash computed at final delivery. Microsoft Exchange Online Protection recorded dkim=fail (body hash did not verify) in the final authentication results. An intermediate relay had logged a DKIM pass, but by the time the message reached the recipient's mailbox, the integrity check had collapsed.

SPF passed. simparano[.]com's SPF record authorized 136[.]144[.]238[.]41, so the sending IP was technically permitted. DMARC passed as well -- header.from=simparano.com aligned with the authenticated sending domain. A gateway that stops at "SPF pass, DMARC pass" sees a green light. A gateway that goes further asks: does the domain presenting as Sage have any relationship to Sage at all?

The answer here is no. simparano[.]com has no publicly verifiable connection to Sage Group plc. The domain is nine weeks old. The display name was crafted to suggest an internal Sage product code ("SBCP PE") without actually being one.

The landing domain sabo-um[.]info compounded the problem. It carried an SPF record referencing a third-party mail provider, but published no DMARC record and no DKIM selectors. The .info TLD triggered Microsoft's custom spam filter (X-CustomSpam: URL to .biz or .info websites). Despite link scanners returning clean results for specific paths at scan time, the domain's authentication posture and non-brand ownership make it unsuitable as a legitimate Sage asset host.

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

What a Signature That Fails Should Signal

The DKIM body-hash failure deserves close attention because it reveals a gap in how some gateways weight authentication results. A body-hash mismatch means the signed hash of the message body at send time does not match the hash of the body that arrived. This can happen through legitimate transit modifications (some mailing list processors rewrite bodies), but in combination with a newly registered sender domain, a deprecated signature algorithm, and brand-domain misalignment, it is a compounding integrity failure.

The operational implication: the attacker either modified the message body after signing, used a signing environment inconsistent with the delivery path, or configured the DKIM signature carelessly -- any of which reduces the assurance the signature was intended to provide. A gateway that credits a DKIM signature pass at an intermediate hop without verifying the final-hop result will miss this failure entirely.

Microsoft's anti-spam scoring reached SCL=5 (probable spam) and flagged both .info domain links and remote image hosting. The message was auto-routed to junk. That is spam-filtering catching what DKIM failed to surface cleanly.

How IRONSCALES Caught It

IRONSCALES Adaptive AI did not rely on authentication headers to render a verdict. The Phishing SOC Agent analysis identified the brand-domain mismatch -- Sage branding presented from simparano[.]com infrastructure -- the nine-week domain age, the inconsistent DKIM results and deprecated algorithm, and the absence of any verifiable brand relationship between either sending or landing domain and Sage Group. The incident was automatically resolved as phishing before any recipient clicked a link. Four mailboxes at the engineering services firm received the campaign; all were mitigated.

This is the pattern Adaptive AI is built for: a multi-signal correlation that no single authentication header can capture. Brand identity, domain provenance, infrastructure reputation, and DKIM integrity all feed the analysis simultaneously.

Defensive Takeaways

Authentication pass is not a trust grant. DMARC passing for simparano[.]com confirms only that the message came from simparano.com's authorized infrastructure -- it says nothing about whether simparano.com is trustworthy or affiliated with the brand it displays. Organizations treating authentication pass as a trust signal should augment their DMARC Management posture with brand-alignment checks.

Flag newly registered sending domains. A sending domain under 90 days old carrying a well-known brand's visual identity is a high-priority signal for review, regardless of authentication status.

Weight DKIM algorithm and body-hash results separately. A final-hop dkim=fail (body hash did not verify) on an rsa-sha1 signature from a new domain should elevate risk scoring even when SPF and DMARC pass.

Treat landing-domain authentication posture as a risk factor. If a message claims to be from a major software vendor but every link resolves to a domain with no DMARC record and no DKIM selectors, the landing infrastructure is under-authenticated for the brand it represents.

Train procurement and finance staff on language-localized lures. This campaign targeted French-speaking recipients at an international firm's procurement function with professionally crafted French-language content. Localized campaigns are harder for recipients to dismiss as obvious phishing -- which makes the technical layer more important, not less.

---

Indicators of Compromise

---

MITRE ATT&CK Mapping