Threat Intelligence

The URL That Put adobe.com in the Wrong Place

apaxson@ironscales.com (Audian Paxson) — Mon, 20 Apr 2026 11:00:00 GMT

TL;DR A phishing campaign used URL path deception to embed 'adobe.com/' inside an attacker-controlled domain's directory structure, exploiting how both humans and automated scanners evaluate link safety. The email impersonated a construction bid request, displayed a fabricated RFI number as the link text, and was sent from a Yahoo account. The attacker domain was registered in November 2025 and routed through Cloudflare DNS. Microsoft assigned a Spam Confidence Level of 5. Themis flagged the message based on link structural analysis.

Severity: High Credential Harvesting Url Deception MITRE: T1566.002 MITRE: T1036.005 MITRE: T1608.005

Look at this URL and decide in two seconds whether it is safe: reviewdocpdfreader[.]com/docprivatepremiumfile/allfile/adobe.com/. Did your eye catch "adobe.com" and move on? That is exactly what the attacker counted on.

The domain is reviewdocpdfreader[.]com. The directory path contains adobe.com/. The actual destination has nothing to do with Adobe. But the human brain, scanning a link under time pressure, latches onto the familiar brand name and fills in the rest. This is URL path deception, and it is surprisingly effective against both people and automated scanners that weight path content in their reputation scoring.

A Construction Bid That Never Existed

In April 2026, IRONSCALES detected a credential harvesting campaign targeting an employee at a construction materials supplier. The phishing email used a construction bid pretext, referencing a fabricated RFI (Request for Information) number as the hyperlink display text.

This industry targeting is deliberate. Construction companies exchange bid documents, RFIs, and project specifications with unfamiliar external parties as part of normal business operations. A subcontractor the recipient has never emailed before sending a document link is not unusual. It is Tuesday. The Verizon 2024 Data Breach Investigations Report identified manufacturing and construction as increasingly targeted sectors, with phishing as the dominant initial access vector.

The email arrived from a Yahoo account. No corporate domain, no authentication infrastructure beyond Yahoo's default. Microsoft assigned a Spam Confidence Level (SCL) of 5, flagging it as likely spam but not blocking delivery outright. In many organizations, SCL 5 messages land in the junk folder. In organizations with custom transport rules (common in construction firms that receive legitimate external bid communications), they may reach the inbox.

How the URL Tricks Both Eyes and Algorithms

The full URL path tells the story: reviewdocpdfreader[.]com/docprivatepremiumfile/allfile/adobe.com/.

Three deception layers are stacked here. First, the domain name itself (reviewdocpdfreader) contains words associated with legitimate document review. Second, the directory path (docprivatepremiumfile/allfile/) reinforces the "private document" pretext. Third, adobe.com/ sits in the path, visually anchoring the URL to a trusted brand.

This technique exploits a well-documented cognitive bias. When humans scan URLs, they do not parse the domain hierarchy the way a browser does. They scan for recognizable patterns. "adobe.com" anywhere in a URL registers as "Adobe" to a reader who is not pausing to identify where the actual domain ends and the path begins. The Microsoft Digital Defense Report 2024 notes that URL obfuscation techniques, including path-based brand embedding, have increased as defenders have improved detection of lookalike domains and homoglyph attacks.

The display text compounded the deception. Rather than showing the full URL, the hyperlink text displayed what appeared to be an RFI reference number. The recipient would see a plausible document identifier, not the suspicious URL behind it. Hovering over the link would reveal the full path, but in practice, hover-to-inspect rates are low, particularly on mobile devices. According to Osterman Research, more than 60% of business email is now read on mobile, where URL preview behavior varies by client and is frequently truncated.

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

The Infrastructure Behind the Deception

The attacker registered reviewdocpdfreader[.]com in November 2025, five months before this campaign. That registration timeline is notable. Many phishing campaigns use domains registered hours or days before an attack, making domain age a useful (if imperfect) detection signal. A five-month-old domain bypasses age-based heuristics that flag newly registered infrastructure.

DNS resolution routed through Cloudflare, giving the domain valid SSL certificates, DDoS protection, and CDN-level performance. Cloudflare's infrastructure is used by millions of legitimate websites. The presence of Cloudflare in the resolution chain adds no reputational signal in either direction, which is precisely why attackers choose it. The FBI IC3 2024 Annual Report documented a continued rise in phishing infrastructure hosted behind legitimate CDN and cloud providers, complicating IP-based and domain-based blocklist approaches.

The Yahoo sender account provided minimal authentication. Yahoo's outbound infrastructure handles SPF and DKIM for its own domain, but the email carried no organizational authentication signals. Combined with the SCL 5 score, the message sat in a gray zone: suspicious enough to flag, not definitive enough to block. That gray zone is where the most effective phishing campaigns operate.

MITRE ATT&CK Mapping

This attack maps to several MITRE ATT&CK techniques:

T1566.002 (Phishing: Spearphishing Link): The email contained a malicious link to an external credential harvesting page.
T1036.005 (Masquerading: Match Legitimate Name or Location): The URL path embedded "adobe.com" to impersonate a trusted brand.
T1608.005 (Stage Capabilities: Link Target): The attacker pre-staged a credential harvesting page on a dedicated domain with Cloudflare infrastructure.

Indicators of Compromise

Type	Indicator	Context
Phishing Domain	`reviewdocpdfreader[.]com`	Attacker-controlled credential harvest host
URL Path	`/docprivatepremiumfile/allfile/adobe.com/`	Brand embedding in path for visual deception
DNS Provider	Cloudflare	Infrastructure routing
Domain Registration	November 2025	Five months pre-campaign
Sender Platform	Yahoo	Free email, minimal authentication
SCL Score	5	Microsoft spam confidence (flagged, not blocked)
Display Text	Fabricated RFI number	Hid malicious URL behind document reference

Where the Domain Ends and the Lie Begins

Themis flagged this message based on link structural analysis, identifying the mismatch between the display text, the actual destination domain, and the brand reference embedded in the path. The IRONSCALES Adaptive AI evaluates URL structure beyond simple reputation lookups, parsing the relationship between the displayed link text, the true hosting domain, and any trust signals embedded in the path or parameters.

Domain reputation and URL scanning remain necessary components of email security. But they are not sufficient when the attacker's entire strategy is designed to manipulate how those systems (and humans) evaluate links. The IBM Cost of a Data Breach 2024 report found that phishing-initiated breaches cost an average of $4.88 million, and the time to detect phishing-based intrusions continues to lengthen as evasion techniques improve.

The fix is not more blocklists. It is structural link analysis that understands the difference between where a URL appears to go and where it actually goes. If "adobe.com" appears in the path rather than the domain, that is not Adobe. That is the attacker betting you will not notice the difference.

Email Attack of the Day is a daily series from IRONSCALES spotlighting real phishing attacks caught by Adaptive AI and our community of 30,000+ security professionals. Each post breaks down one attack — what it looked like, why it worked, and what you can do about it.

The Zoho Invoice That Was Four Months Late (And Kept Its Receipts on Google Drive)

apaxson@ironscales.com (Audian Paxson) — Mon, 20 Apr 2026 11:00:00 GMT

TL;DR A phishing email impersonating a drone services vendor used Zoho Books transactional infrastructure to deliver a past-due invoice four months after its stated due date. The email passed SPF and DKIM at the originating hop but failed both at the recipient environment after traversing a Barracuda gateway. The real payload was not the PAY NOW button (which pointed to a legitimate Zoho payment domain) but a Google Drive folder link embedded below the invoice, an atypical addition to standard Zoho invoice flows. Themis flagged the message based on behavioral anomalies, authentication degradation, and the unusual external link pattern.

Severity: High Bec Credential Harvesting MITRE: T1566.001 MITRE: T1566.002

The invoice looked routine. An $802.50 bill from a drone inspection vendor, delivered through Zoho Books, complete with a PDF attachment and a green PAY NOW button. The kind of thing an accounts payable team processes dozens of times a week without a second thought.

Except this one was four months late. The invoice date read November 22, 2025. The due date was December 22, 2025. The email didn't arrive until late March 2026. And tucked below the payment button, almost as an afterthought, sat a Google Drive folder link labeled as "invoice materials."

That link was the real payload.

The Invoice That Aged Like Milk

The email targeted a forensic engineering firm, landing in the mailbox of an employee whose role involved processing vendor payments. The subject line followed Zoho Books conventions exactly: "Invoice - ART-INV-251691 for MAT-188157-D6X3 from Air Reel Technologies LLC." Nothing about it screamed phishing.

The sender address, message-service@sender[.]zohobooks[.]com, is the legitimate transactional domain Zoho uses for invoice delivery. The From header showed "Brian." The Reply-To pointed to brian@airreeltech[.]com, a real domain belonging to a legitimate drone services company in the Atlanta area. The PDF attachment matched the email content: line items for "Basic Travel" and "Drone Roof Inspection," an EIN, a phone number, a company address.

Every detail checked out, which is exactly why the four-month delay and the Drive link were so easy to overlook.

According to the FBI IC3 Internet Crime Report, business email compromise accounted for over $2.9 billion in reported losses in 2024 alone. Attacks like this one succeed precisely because they weaponize legitimate infrastructure. The attacker didn't need to spoof a domain or craft a convincing lookalike. They used the real thing.

When Authentication Tells Two Different Stories

The email's journey through the relay chain tells the real story. At the first hop (Zoho's own infrastructure), everything checked out. SPF passed. DKIM passed. DMARC showed no policy to enforce (dmarc=none). The Authenticated Received Chain (ARC) sealed cleanly.

Then the message hit a Barracuda Email Security Gateway (outbound-ip76b[.]ess[.]barracuda[.]com, IP 209[.]222[.]82[.]242). Barracuda is a legitimate email security provider, and its presence in the relay chain is normal for organizations that route outbound mail through scanning appliances. But the gateway's processing altered the message enough to break alignment downstream.

By the time the email reached the recipient's Microsoft 365 environment, the picture had changed completely:

SPF: Softfail (the Barracuda IP isn't in sender[.]zohobooks[.]com's SPF record)
DKIM: Fail (body hash did not verify, meaning the message body was modified in transit)
DMARC: Fail (both SPF and DKIM alignment broken)
ARC: Fail at the Microsoft seal (cv=fail)

This is a pattern security teams should recognize. According to the Microsoft Digital Defense Report 2024, legitimate email gateways in the relay path are one of the most common causes of authentication result degradation. The challenge is distinguishing between "authentication failed because a gateway modified the message" and "authentication failed because the message was forged." In this case, the recipient's mail system couldn't tell the difference.

The recipient's email client displayed two warnings: an external email banner and an "Unusual sender" flag for message-service@sender[.]zohobooks[.]com. Both are correct signals. Neither is specific enough to tell a busy AP clerk that this particular invoice is dangerous.

The Google Drive Folder Nobody Expected

The PAY NOW button linked to zohosecurepay[.]com, Zoho's legitimate payment processing domain. That link scanned clean because it is clean. If the only payload were the payment button, this would likely be a legitimate invoice.

But below the invoice block sat a plaintext Google Drive URL: hxxps://drive[.]google[.]com/drive/folders/1_2IAvK-LskteX6qDIB8JipJOoLTf9jkj. No anchor text, no explanation, just a raw link to a shared folder labeled as supplementary "media" for the invoice.

Standard Zoho Books invoice emails do not include Google Drive links. Zoho hosts invoice PDFs on its own platform. The presence of an external file-sharing link in an otherwise standard invoice flow is a significant anomaly, the kind that URL reputation scanners often miss because drive.google.com is universally trusted. According to the Verizon 2024 DBIR, abuse of legitimate cloud services for payload hosting has become one of the most effective evasion techniques precisely because domain reputation checks give these links a pass.

That Drive folder is where the real risk lives. Whether it contained credential harvesting documents, malware, or fraudulent wire instructions, its mere presence in a transactional invoice email is a red flag that most static filters cannot evaluate.

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

Stale Urgency Is Urgency That Works Harder

The four-month gap between the invoice date and the delivery date is not a bug. It is a feature of the social engineering. A fresh invoice gives the recipient time. A past-due invoice creates pressure.

An AP clerk who sees an $802.50 invoice that was due four months ago has two immediate reactions: (1) this vendor has been waiting, and (2) someone dropped the ball. Both reactions push toward fast payment and away from careful verification. The CISA phishing guidance specifically warns about urgency manipulation as a core social engineering lever, but most training scenarios focus on "act now" language. Stale urgency is subtler. It manufactures guilt instead of panic.

Across the IRONSCALES global deployment, Themis flagged this message within seconds of delivery. The Adaptive AI engine correlated three signals that individually might have passed muster: the authentication degradation across the relay chain, the behavioral anomaly of a first-time sender on a transactional Zoho address, and the atypical external link in an otherwise standard invoice template. No single signal was decisive. Together, they painted a clear picture.

What the Invoice Got Right (and What Gave It Away)

Type	Indicator	Context
Sender Domain	`sender[.]zohobooks[.]com`	Legitimate Zoho transactional domain
Reply-To	`brian@airreeltech[.]com`	Real vendor domain
Relay IP	`209[.]222[.]82[.]242`	Barracuda ESG outbound relay
Payment URL	`zohosecurepay[.]com`	Legitimate Zoho payment domain
Payload URL	`hxxps://drive[.]google[.]com/drive/folders/1_2IAvK-LskteX6qDIB8JipJOoLTf9jkj`	Atypical Google Drive folder link
Attachment	`ART-INV-251691.pdf` (MD5: `9d1d474ce826fc1e59fec0630619fa38`)	Invoice PDF, static scan clean

MITRE ATT&CK mapping: - T1566.001: Phishing, Spearphishing Attachment (invoice PDF) - T1566.002: Phishing, Spearphishing Link (Google Drive folder link)

The lesson here is not that Zoho Books invoices are inherently suspicious. It is that attackers are increasingly building their lures on legitimate platforms, using real vendor identities, real payment infrastructure, and real transactional mail systems. The differentiator is not the platform. It is the pattern: a stale invoice nobody requested, authentication that degraded across the relay chain, and a Google Drive link that has no business being in a Zoho invoice.

If your email security stack evaluates these signals independently, each one looks explainable. If your stack correlates them, the picture changes fast.

The PDF Scanner Couldn't Open the Attachment (But the Victim Could)

apaxson@ironscales.com (Audian Paxson) — Sun, 19 Apr 2026 11:00:00 GMT

TL;DR A phishing email carrying a password-protected PDF attachment passed SPF, DKIM, DMARC, and ARC authentication checks using a legitimate state government education domain. Automated scanners could not open the encrypted file, so they returned clean verdicts by default. The attacker included the PDF passcode directly in the email body, ensuring only the human target could access the malicious payload. IRONSCALES flagged the message based on first-time sender analysis, encrypted attachment detection, and behavioral anomalies, quarantining it within seconds of delivery across all affected mailboxes.

Severity: High Phishing Credential Harvesting MITRE: T1566.001 MITRE: T1027

The email looked like routine government correspondence. A state education department, a professional signature block, an attached PDF described as an "Approved New Statement." The subject line was bureaucratic enough to be boring. Every authentication check passed. SPF, DKIM, DMARC, ARC: all green.

There was just one small detail that changed everything. The PDF was password-protected, and the passcode was sitting right there in the body of the email.

The Attachment That Every Scanner Declared Safe

Automated security scanners are built to open files, inspect their contents, and render a verdict. They do this millions of times a day, and they do it well. But they have a blind spot that attackers increasingly exploit: encrypted files.

When a scanner encounters a password-protected PDF, it cannot decrypt the contents without the passcode. Most systems handle this by returning a default clean verdict or simply skipping the file entirely. According to MITRE ATT&CK's documentation on obfuscated files and information, this is a well-known evasion technique (T1027) that continues to be effective precisely because it exploits how automated tools process attachments in isolation from email body content.

In this case, the 112KB PDF named Georgia Department of Education_protected.pdf passed through multiple scanning layers. Every one returned the same result: clean. Not because the file was safe, but because none of them could open it.

The FBI's 2024 Internet Crime Report documented over $2.9 billion in losses from business email compromise alone. Password-protected attachments are a growing vector within that category because they turn the scanner's own security model against itself.

A Sender Who Checked Every Box

The email arrived from a legitimate state government domain, doe[.]k12[.]ga[.]us, which belongs to the Georgia Department of Education. The sending infrastructure was Microsoft 365, routed through outbound[.]protection[.]outlook[.]com. Authentication headers confirmed full alignment:

SPF: Pass (authorized sending IP)
DKIM: Pass (signature verified for doe[.]k12[.]ga[.]us)
DMARC: Pass (policy alignment confirmed)
ARC: Pass (chain of custody intact through relay)

The signature block was detailed and convincing, listing a named staff member, a title (Paraprofessional), a physical address at a real facility in Macon, Georgia, a local phone number, and links to legitimate government websites. The email even included branded banners for the Georgia Department of Education and a promotional graphic for the PEACH Education Tax Credit.

According to the Verizon 2024 Data Breach Investigations Report, the human element is involved in 68% of breaches. This attack was engineered to ensure the human element did the attacker's work: read the passcode, open the file, and trust the contents because everything around it looked right.

The Gap Between Machine Logic and Human Behavior

This is the core of the technique, classified under MITRE ATT&CK T1566.001 (Spearphishing Attachment). The attacker bet on a simple asymmetry. Machines process email components (headers, body text, attachments) through separate analysis pipelines. A scanner inspecting the PDF has no access to the body text containing PDF Passcode: 0937728736. It sees an encrypted file and moves on.

The human recipient experiences the email as a single unit. They read the greeting, see the passcode, open the attachment, and follow whatever instructions are inside, whether that means clicking a link, entering credentials, or enabling macros.

This separation is not a bug in any single product. It is a structural limitation in how most Secure Email Gateways process messages. SEGs miss an average of 67.5 phishing emails per 100 mailboxes per month (IRONSCALES, 2025 SEG analysis), and password-protected attachments represent one of the hardest categories for static scanning to address.

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

What the Authentication Couldn't Tell You

Full authentication passage is not a trust signal when the sending account itself may be compromised. The Microsoft Digital Defense Report 2024 highlights that compromised legitimate accounts are one of the most effective ways attackers establish trust with their targets.

In this case, the sender was a first-time correspondent to the recipient, a professional at a regional law firm. A state education paraprofessional sending an "Approved New Statement" to an attorney with no prior communication history is exactly the kind of contextual anomaly that behavioral AI detection is designed to catch.

That is what happened here. Within seconds of delivery, Themis flagged the message based on the convergence of first-time sender status, the presence of an encrypted attachment, and community threat intelligence from IRONSCALES global network of over 35,000 security professionals. The email was quarantined across both affected mailboxes before either recipient could act on it.

Indicators of Compromise

Type	Indicator	Context
Sender Domain	`doe[.]k12[.]ga[.]us`	Legitimate domain, likely compromised account
Sender Email	`Meredith[.]Minick@doe[.]k12[.]ga[.]us`	First-time sender to target organization
Attachment	`Georgia Department of Education_protected.pdf`	Password-protected PDF (112,382 bytes)
Attachment Hash (MD5)	`bc4b336fd7a461d05da3e00d68e9975d`	PDF file hash
Image	`image001.png` (MD5: `2d589e67f48e7b9b97dc8841cc2e43c4`)	Embedded branding image
PDF Passcode	`0937728736`	Provided in email body for recipient
Linked Domain	`gabmacon[.]org`	Legitimate site used for trust-building
Linked Domain	`gadoe[.]org`	Legitimate site used for trust-building

MITRE ATT&CK Mapping: - T1566.001: Phishing, Spearphishing Attachment (encrypted PDF delivery) - T1027: Obfuscated Files or Information (password protection as scanner evasion)

Why This Pattern Keeps Working

Password-protected attachment phishing works because it exploits a design constraint, not a vulnerability. Scanners are built to respect encryption. They cannot brute-force every protected file in a mail stream, and most organizations would not want them to.

The defensive answer is not better scanning. It is context-aware analysis that evaluates the combination of signals: first-time sender, encrypted attachment, passcode in body text, mismatch between sender role and recipient function. Each signal alone might be benign. Together, they form a pattern that human-trained, community-powered AI recognizes as high risk.

For security teams evaluating their email defenses, the question is straightforward. If an attacker sends a password-protected PDF to your users tomorrow, with the passcode in the body and perfect authentication on the envelope, what in your stack catches it?

If the answer depends on opening the file, you have a gap.

An Encrypted Attachment, an Empty Body, and a Scanner That Couldn't Look Inside

apaxson@ironscales.com (Audian Paxson) — Fri, 17 Apr 2026 11:00:00 GMT

TL;DR A compromised Microsoft 365 account delivered a 540KB encrypted RPMSG attachment to a forensic engineering firm. The email body was completely empty, the subject line referenced a regional law firm by name, and the message carried High Importance and X-Priority:1 flags. SPF, DKIM, DMARC, and ARC all passed. Every automated scanner returned a 'clean' verdict on the attachment because the RPMSG encryption prevented content inspection. Themis flagged the message at 61% confidence based on structural anomalies.

Severity: High Credential Harvesting Scanner Evasion MITRE: T1566.001 MITRE: T1027 MITRE: T1078.004

The email body was empty. Completely empty. No greeting, no context, no instructions. Just a subject line referencing a regional law firm, a 540KB encrypted attachment, and a red exclamation mark screaming "High Importance."

Every scanner that touched it returned the same verdict: clean.

That verdict was not wrong, exactly. It was incomplete. The attachment was an RPMSG file, Microsoft's encrypted message format, and no automated tool in the delivery chain could decrypt it to inspect what was inside. The scanner did not find anything malicious because the scanner could not find anything at all.

The Anatomy of Nothing

In April 2026, IRONSCALES flagged a suspicious message targeting an employee at a forensic engineering consultancy. The email arrived from a compromised Microsoft 365 account. The subject line contained only the name of a regional law firm. No additional context. No "please review" or "action required." Just the firm name, implying enough familiarity that the recipient would know what it was about.

The body was blank. No text, no images, no embedded links. The only content was a single attachment: a 540KB RPMSG (Rights-Protected Message) file. RPMSG is the container format used by Microsoft's Azure Information Protection and Office 365 Message Encryption. When a legitimate sender encrypts an email through M365, the recipient receives an RPMSG attachment that can only be decrypted by authenticating with Microsoft.

The attacker understood that this encryption creates a functional blind spot. According to the Microsoft Digital Defense Report 2024, threat actors are increasingly leveraging platform-native features (encryption, rights management, and cloud storage sharing) as evasion tools. The platform's own security feature becomes the attack's shield.

Authentication That Proves the Wrong Thing

The message passed every authentication check in the stack. SPF passed because the email was sent through Microsoft's own outbound infrastructure. DKIM passed because Microsoft signed it. DMARC aligned because both mechanisms used the compromised account's legitimate domain. ARC (Authenticated Received Chain) passed cleanly through each relay hop.

Composite Authentication (compauth) returned a passing result. From the perspective of every protocol designed to verify sender legitimacy, this email was authentic. It was authentic because the account was compromised, not spoofed. The attacker was sending from inside the house.

The Verizon 2024 Data Breach Investigations Report found that stolen credentials remain the most common initial access vector, involved in over 40% of breaches. When attackers control a legitimate account, authentication becomes a liability rather than a defense. Every check confirms the message is "real," which is precisely the conclusion the attacker needs the recipient to reach.

Why Urgency Flags Are a Weapon

The attacker set two urgency markers: the Importance: High header and X-Priority: 1. In most email clients, this combination triggers a red exclamation icon next to the message and bold formatting in the inbox list.

These flags do not affect delivery or filtering. They affect human behavior. A message marked "High Importance" from what appears to be a law firm, with no body text and an encrypted attachment, creates a specific psychological pressure: this must be confidential, it must be time-sensitive, and I should open it before asking questions.

The FBI IC3 2024 Annual Report documented that social engineering attacks exploiting urgency and authority cues resulted in $2.9 billion in losses. The urgency flag is not a technical exploit. It is a social engineering primitive, and it costs nothing to deploy.

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

The Scanner's Dilemma

Here is the core problem. Email security scanners analyze content. When the body is empty, there is no text for natural language processing to evaluate. When the attachment is encrypted with Microsoft's own rights management, there is no payload for sandbox detonation to examine. The scanner's only option is to return "clean," which in this case means "unable to determine."

This is not a hypothetical gap. The attachment verdict on this message was explicitly "clean." Not "encrypted" or "unable to scan." Clean. That verdict label gives downstream systems and human reviewers a false sense of confidence. CISA advisories have repeatedly highlighted the risks of encrypted content evasion, recommending that organizations treat unscanned attachments as high-risk rather than clean.

Themis flagged this message at 61% confidence. That score reflects the structural anomalies rather than content analysis: empty body combined with encrypted attachment, urgency flags on an unsolicited message, a subject line pattern inconsistent with normal law firm correspondence to this recipient, and sender behavioral deviation. The score was not high enough for automatic quarantine at the default threshold, but it triggered enhanced review that led to manual quarantine across all affected mailboxes.

MITRE ATT&CK Mapping

This attack maps to several MITRE ATT&CK techniques:

T1566.001 (Phishing: Spearphishing Attachment): Malicious content delivered as an email attachment (encrypted RPMSG file).
T1027 (Obfuscated Files or Information): Microsoft's native encryption used to prevent security tool inspection of the payload.
T1078.004 (Valid Accounts: Cloud Accounts): The attack originated from a compromised M365 account, providing full authentication legitimacy.

Indicators of Compromise

Type	Indicator	Context
Attachment	RPMSG file, 540KB	Encrypted payload, scanner-opaque
Email Header	`Importance: High`, `X-Priority: 1`	Urgency social engineering
Attachment Verdict	"clean" (unable to inspect)	False negative from encryption evasion
Authentication	SPF pass, DKIM pass, DMARC pass, ARC pass	Compromised account, not spoofed
Subject Pattern	Law firm name only (no context)	Authority impersonation pretext

The Verdict That Should Not Exist

The word "clean" should never appear on an attachment that no scanner could read. That semantic gap, between "inspected and found safe" and "unable to inspect," is the structural weakness this attack exploits.

Organizations should reconfigure their email security policies to treat encrypted attachments from external senders as elevated risk, not clean. The IBM Cost of a Data Breach 2024 report found that breaches involving compromised credentials take an average of 292 days to identify and contain. When the initial delivery mechanism is an encrypted file that passes every check, that timeline only gets longer. Detection must move beyond content analysis and into behavioral territory: who sent this, is this communication pattern normal, and does the structural profile of this message match legitimate encrypted correspondence? Those are the questions that authentication cannot answer and that scanners were never designed to ask.

Past Due Invoice, Future Wire Fraud: How a BEC Campaign Passed Every Authentication Check

apaxson@ironscales.com (Audian Paxson) — Thu, 16 Apr 2026 11:00:00 GMT

TL;DR A Business Email Compromise campaign impersonated a known vendor contact using display name spoofing delivered through SendGrid infrastructure. The email passed SPF, DKIM, and DMARC authentication, carried VERP bounce tracking for delivery confirmation, and attempted to redirect an overdue invoice payment to an attacker-controlled domain registered in February 2026. Themis flagged the behavioral anomaly and quarantined the message across three affected mailboxes before any payment action occurred.

Severity: Critical Bec Invoice Fraud MITRE: T1566.001 MITRE: T1534 MITRE: T1036.005

The subject line was three words: "Past due invoice." The sender name matched a known vendor contact. SPF passed. DKIM passed. DMARC passed. And the entire purpose of the email was to reroute a real payment to an attacker-controlled bank account.

In April 2026, IRONSCALES detected a Business Email Compromise (BEC) campaign targeting a mid-size technology services firm. The attack did not rely on malware, credential harvesting links, or even a convincing email body. It relied on one thing: the recipient already expected the invoice.

BEC invoice diversion remains the most expensive category of cybercrime in the United States. The FBI IC3 2024 Annual Report documented $2.9 billion in BEC losses, and payment diversion schemes accounted for the majority. This attack illustrates exactly why.

Three Words, Zero Red Flags

The email arrived from stan@berteloot[.]org with the display name of a vendor contact the recipient had corresponded with before. The subject line ("Past due invoice.") was unremarkable. There were no urgent threats, no countdown timers, no "your account will be suspended" language. Just a routine nudge about an overdue bill.

The body reinforced the pretext with minimal text and a professional tone. The attacker tagged the message with a "BEC Payment Details" classification, a label that suggests familiarity with how internal email systems categorize financial communications.

What the recipient would not have noticed: the Reply-To address pointed to mail@ilyff[.]com, a domain registered in February 2026. If the recipient hit reply, the response would never reach the legitimate vendor. It would land in the attacker's inbox, where the next step would be a politely worded request to update the payment destination to invoice@billingsdepts[.]info.

That is the entire attack. No links to click. No attachments to open. Just a conversation designed to end with a wire transfer to the wrong account.

Why the Gateway Gave It a Green Light

The message was delivered through SendGrid (IP 159[.]183[.]224[.]102), one of the largest transactional email platforms in the world. SendGrid handles authentication on behalf of its customers, which means the SPF record for berteloot[.]org included SendGrid's infrastructure, and the DKIM signature validated correctly against SendGrid's signing keys.

DMARC? Pass. Microsoft's Composite Authentication (compauth)? Pass. The email was, from a protocol standpoint, indistinguishable from a legitimate business communication.

This is the fundamental limitation of authentication-based detection. SPF, DKIM, and DMARC verify that the sending infrastructure is authorized. They do not verify that the person controlling the sending infrastructure has honest intentions. According to the Verizon 2024 Data Breach Investigations Report, pretexting (the social engineering technique behind BEC) has doubled in frequency since 2022, and the median wire transfer loss per incident exceeds $50,000.

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

The Attacker's Delivery Infrastructure

The relay headers reveal a deliberate operational setup. The message originated from SendGrid's outbound pool at 159[.]183[.]224[.]102, passed through standard MX routing, and arrived with clean header chains. The attacker also configured VERP (Variable Envelope Return Path) bounce tracking, encoding recipient-specific data in the return path so that delivery success could be confirmed on a per-mailbox basis.

VERP is a legitimate email operations feature used by marketing platforms and transactional senders. In this context, it served as reconnaissance: the attacker could confirm which of the three targeted mailboxes accepted delivery and which bounced. That intelligence feeds the next campaign.

The Reply-To domain ilyff[.]com and the payment destination domain billingsdepts[.]info share a common pattern. Both were registered recently. Both use generic naming that could plausibly represent a billing department or financial services entity. Neither had any web presence, email history, or DNS records beyond the minimum required for email delivery. The Microsoft Digital Defense Report 2024 highlights that BEC actors increasingly register purpose-built domains that mimic financial terminology, making them harder to flag without behavioral context.

MITRE ATT&CK Mapping

This campaign maps to several MITRE ATT&CK techniques:

T1566.001 (Phishing: Spearphishing Attachment/Link): The email itself is the payload, using social engineering rather than technical exploitation.
T1534 (Internal Spearphishing): The attack leveraged familiarity with the target's vendor relationships to craft a convincing pretext.
T1036.005 (Masquerading: Match Legitimate Name or Location): Display name impersonation matched a known vendor contact.

Indicators of Compromise

Type	Indicator	Context
Sender Email	`stan@berteloot[.]org`	Impersonated vendor contact
Reply-To Email	`mail@ilyff[.]com`	Attacker-controlled reply capture
Payment Redirect	`invoice@billingsdepts[.]info`	Attacker payment destination
Sending IP	`159[.]183[.]224[.]102`	SendGrid delivery infrastructure
Subject Line	"Past due invoice."	BEC pretext
Classification Tag	"BEC Payment Details"	Attacker-applied message tag

The Signal That Authentication Cannot Provide

Three mailboxes received this message. All three were quarantined by Themis, the IRONSCALES Adaptive AI, before any user replied. The detection was not based on authentication results (which all passed) or URL reputation (there were no URLs). It was based on behavioral pattern analysis: the mismatch between the display name and the envelope sender, the recently registered Reply-To domain, and the communication pattern deviation from the legitimate vendor's baseline.

This is the gap that BEC exploits. Authentication tells you whether an email is technically authorized. It tells you nothing about whether the person behind it is who they claim to be. The IBM Cost of a Data Breach 2024 report found that BEC-initiated breaches cost an average of $4.88 million, with the longest mean time to identify of any attack vector at 261 days.

CISA's email authentication guidance recommends DMARC at p=reject for all organizations, but even perfect authentication cannot stop an attacker who controls a legitimately authenticated sending platform. Security teams need behavioral detection that evaluates who is sending, why, and whether the communication pattern matches historical norms. Without that layer, the next "past due invoice" might cost more than the original bill.

The DocuSign That Lived on an S3 Bucket (and Couldn't Decide Who Sent It)

apaxson@ironscales.com (Audian Paxson) — Thu, 16 Apr 2026 11:00:00 GMT

TL;DR A credential harvesting campaign impersonated DocuSign using a compromised K-12 school district Google Workspace account. The email passed SPF, DKIM, and DMARC with a p=REJECT policy, making it indistinguishable from legitimate mail by authentication alone. Three conflicting sender names across the header, body, and footer revealed a template assembly error. The primary call-to-action linked to an HTML page hosted on an AWS S3 bucket in eu-north-1, not a DocuSign signing endpoint. IRONSCALES Themis flagged the behavioral anomalies within seconds of delivery.

Severity: High Credential Harvesting Brand Impersonation Account Compromise MITRE: {'id': 'T1566.002', 'name': 'Phishing: Spearphishing Link'} MITRE: {'id': 'T1078', 'name': 'Valid Accounts'} MITRE: {'id': 'T1585.001', 'name': 'Establish Accounts: Social Media Accounts'} MITRE: {'id': 'T1036.005', 'name': 'Masquerading: Match Legitimate Name or Location'}

The email passed every authentication check. SPF, DKIM, DMARC (with a p=REJECT policy, no less). It arrived from a real Google Workspace account belonging to a real K-12 school district in the southeastern United States. The DocuSign branding was pixel-perfect, the "Review Document" button looked exactly right, and the footer included a legitimate abuse-reporting link hosted on protect.docusign.net.

There was just one problem. The email couldn't decide who sent it.

The From header said Kristen Bowers. The body block said Luis Novella. And the footer credited the whole thing to Hasan Kurt. Three names, one envelope, zero legitimate explanation.

Three Names, One Template, Zero Excuses

Phishing kits are reusable. Attackers build templates with variable placeholders for sender names, document titles, and branding elements, then swap values for each campaign. When the template engine misfires (or when the operator gets careless), remnants from previous campaigns leak through.

That is exactly what happened here. The From header pulled one name from the compromised account. The body block rendered a second name from a previous campaign variable. And the DocuSign footer, which uses a "This message was sent to you by" attribution line, displayed a third name entirely.

For a recipient scanning the email quickly, the banner and CTA looked perfectly normal. The name mismatch only becomes visible if you read the full message, including the fine print. According to the Verizon 2024 Data Breach Investigations Report, the median time to click a phishing link is under 60 seconds. Most recipients never reach the footer.

A School District Domain as the Sending Platform

The attacker did not spoof the sender domain. They controlled it. The sending address, kristen.bowers@brantley[.]k12[.]ga[.]us, belongs to a Georgia K-12 school district running Google Workspace. The email was transmitted through mail-sor-f41[.]google[.]com (IP 209[.]85[.]220[.]41), a legitimate Google mail relay.

Because the message originated from an authorized Google Workspace account:

SPF passed: Google's IP is an authorized sender for the district's domain.
DKIM passed: The message was signed with the district's google DKIM selector.
DMARC passed: The domain's DMARC policy is set to p=REJECT sp=REJECT, the strictest possible configuration. The email aligned perfectly.

This is the paradox of DMARC in account compromise scenarios. A p=REJECT policy is designed to prevent unauthorized senders from using your domain. But when the attacker IS an authorized sender (because they compromised a legitimate account), DMARC does exactly what it is supposed to do: it passes. The Microsoft Digital Defense Report 2024 documented a significant increase in attacks leveraging compromised educational institution accounts for exactly this reason. These domains carry inherent trust with email filters.

K-12 school districts are especially vulnerable to account takeover. Limited security staffing, shared devices, and inconsistent MFA enforcement create conditions where a single compromised credential provides access to a fully authenticated sending platform. According to the FBI IC3 2024 Internet Crime Report, educational institutions reported a sharp rise in business email compromise incidents involving compromised accounts being weaponized against external targets.

The S3 Bucket That Wasn't DocuSign

The "Review Document" button, the primary call-to-action in every legitimate DocuSign notification, linked to:

hxxps://proposal-submission-1[.]s3[.]eu-north-1[.]amazonaws[.]com/invite/request[.]html

Not docusign.com. Not docusign.net. An Amazon S3 bucket in the eu-north-1 region (Stockholm), serving a static HTML page designed to harvest credentials.

Attackers favor S3 for phishing infrastructure because the amazonaws.com domain carries implicit trust. Many URL reputation engines and Secure Email Gateways treat Amazon Web Services hostnames as categorically safe. The bucket name, proposal-submission-1, was chosen to look plausible in logs. The path, /invite/request.html, mimicked a document-sharing workflow.

The rest of the email was dressed in legitimate DocuSign assets hotlinked from docucdn-a[.]akamaihd[.]net, the real DocuSign CDN. Footer links pointed to actual DocuSign pages (Terms of Use, Privacy, Support), and a valid protect.docusign.net abuse-reporting URL was included. This mix of legitimate brand links surrounding a single malicious CTA is a textbook evasion technique. It makes automated link scanning produce a mostly-clean verdict. When seven out of eight links are legitimate, the eighth gets less scrutiny.

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

The Subject Line Told on Itself

The email subject read: "Complete with Docusign: Kristen Bowers shared a file with you.pdf"

That trailing .pdf is a social engineering artifact. Legitimate DocuSign notifications never append file extensions to subject lines. The trick works because recipients mentally process it as "there is a PDF waiting for me," which increases urgency and the likelihood of clicking. The referenced document title, "Request_For_Proposal_Partnership_2026-0331," reinforced the pretext with a business-plausible filename and a date stamp.

The email was also BCC'd to undisclosed-recipients, a mass-distribution indicator. Legitimate DocuSign signing requests are addressed to specific signers, not blind-copied to hidden distribution lists.

Where the Behavioral Signals Broke Through

Email authentication told one story: everything is fine. Behavioral analysis told a different one. Themis, the IRONSCALES Adaptive AI engine, flagged the message at 90% phishing confidence within seconds of delivery. The detection signals included a first-time sender from a high-risk external domain, a primary CTA linking to infrastructure inconsistent with the impersonated brand, and community intelligence from the IRONSCALES global network where similar DocuSign-themed S3 campaigns had already been reported and classified by other organizations.

Across four affected mailboxes, the message was quarantined before any recipient clicked the harvesting page. Authentication passed. Behavior did not.

Indicators of Compromise

Type	Indicator	Context
URL	`hxxps://proposal-submission-1[.]s3[.]eu-north-1[.]amazonaws[.]com/invite/request[.]html`	Credential harvesting page (primary CTA)
S3 Bucket	`proposal-submission-1[.]s3[.]eu-north-1[.]amazonaws[.]com`	Attacker-controlled S3 bucket (Stockholm region)
Sender Domain	`brantley[.]k12[.]ga[.]us`	Compromised K-12 school district domain
Sender Email	`kristen[.]bowers@brantley[.]k12[.]ga[.]us`	Compromised account used as sending platform
Sending IP	`209[.]85[.]220[.]41`	Google mail relay (mail-sor-f41[.]google[.]com)
Security Code	`F1144A5FA36D4C6F8A29E09AB05CCD4A4`	Fake DocuSign alternate signing code

MITRE ATT&CK Mapping

Technique	ID	Context
Phishing: Spearphishing Link	T1566.002	DocuSign-themed email with malicious link to S3-hosted credential page
Valid Accounts	T1078	Compromised K-12 school district Google Workspace account used as sending platform
Masquerading: Match Legitimate Name or Location	T1036.005	S3 bucket name and path designed to mimic document-sharing infrastructure

What This Case Reinforces

Authentication is a necessary baseline, not a detection strategy. When the attacker controls a legitimate account, SPF, DKIM, and DMARC become accomplices rather than defenses. Security teams should pressure-test a specific scenario: what happens when a fully authenticated email from a first-time sender carries a CTA pointing to cloud infrastructure that is not the impersonated brand?

The three-name mismatch in this email was a gift. Most template assembly errors are subtler. The detection that mattered here was behavioral: sender reputation, link destination analysis, and cross-organization threat intelligence that had already seen this exact S3 pattern in the wild.

The school district domain, meanwhile, likely remains compromised until someone investigates. Per CISA guidance, organizations that discover their domains being used in phishing campaigns should immediately audit account access, rotate credentials, and review OAuth application grants. For the recipients targeted here, the lesson is simpler: if the "Review Document" button does not point to docusign.com, it is not DocuSign.

The Childcare App That Passed Every Security Check (The Reply-To Header Didn't)

apaxson@ironscales.com (Audian Paxson) — Tue, 14 Apr 2026 11:00:00 GMT

TL;DR Attackers used Brightwheel's legitimate childcare SaaS platform to send a billing notification to a K-12 school employee. The sending infrastructure was 100% real: SPF, DKIM, and DMARC all passed. The child's name in the subject line added credibility. The only anomaly was a Reply-To header pointing to an attacker-controlled domain at seniorlifestyle[.]com. When Themis cross-referenced the display name against known Brightwheel sender addresses, the mismatch triggered a flag. Four mailboxes were quarantined the same day.

Severity: High Brand Impersonation Bec Phishing MITRE: {'id': 'T1566.002', 'name': 'Phishing: Spearphishing Link'} MITRE: {'id': 'T1598.003', 'name': 'Phishing for Information: Spearphishing via Service'} MITRE: {'id': 'T1656', 'name': 'Impersonation'}

Every security check passed. SPF: pass. DKIM: pass. DMARC: pass with a p=REJECT policy. The sending IP was on Brightwheel's authorized list. The email looked exactly like a legitimate childcare billing notification, down to the logo, the branded button, and a real child's name in the subject line.

The only thing wrong was a single header nobody looks at: Reply-To.

How the Attack Was Constructed

The email arrived at a K-12 school employee's inbox on December 1, 2025. Subject: "Your most recent billing statement for Wesley Grier is now available." The display name read "Kimberly St.Pierre." The sending address was no-reply@notify[.]mybrightwheel[.]com.

Brightwheel is a widely used childcare management platform. Schools and daycare centers use it for attendance, messaging, and billing. Transactional emails go out through Postmark (pm.mtasv[.]net). This message came through that exact infrastructure, with full authentication credentials in place.

The body was a standard Brightwheel HTML template: logo, "View statement" button, footer with social links. All links pointed (via Postmark's track.pstmrk[.]it tracking proxy) to legitimate mybrightwheel[.]com destinations.

One line betrayed everything.

"If you have questions, please contact kstpierre@seniorlifestyle[.]com."

That email address, which also appeared in the Reply-To header, belongs to a domain with no relationship to Brightwheel, childcare, or the school. seniorlifestyle[.]com is an attacker-controlled address used to intercept any replies from the victim.

What the Attacker Actually Needed

The goal here was not a credential-harvesting link. The links in the email went to real Brightwheel pages. The play was social engineering through reply.

The attacker's model: a school employee receives a billing notification for a child named in the subject line. The name creates assumed legitimacy. The employee either clicks "View statement" (a real page, no harvest there) or, more likely, replies with a question. "I don't recognize this charge." "Can you explain this?" "I think there's a mistake."

That reply goes to kstpierre@seniorlifestyle[.]com. The attacker now has an open conversation thread with someone who believes they're talking to Brightwheel support. From there, the social engineering writes itself: incorrect charges, verification requests, payment redirects, or credential collection through a follow-up "support" link.

This is Business Email Compromise (BEC) without a spoofed domain, without a credential harvest page, and without any malicious links. The entire attack surface is one misconfigured header.

Why Authentication Checks Are Not Enough Here

The email authentication system worked exactly as designed. Brightwheel's DMARC policy is p=REJECT, meaning unauthenticated mail claiming to be from their domain should be blocked outright. This email was authenticated, because it was sent through Brightwheel's own platform or through a Postmark account that has been given Brightwheel's signing credentials.

This is the core tension in email authentication as a defense layer. SPF, DKIM, and DMARC verify that a message was sent from authorized infrastructure for a given domain. They say nothing about whether the person who authorized that send intended to phish someone.

When an attacker gains access to a SaaS platform's email-sending capability, or simply creates an account on a platform that sends on their behalf under the platform's own domain, authentication becomes irrelevant. According to the Verizon 2024 Data Breach Investigations Report, social engineering was involved in 73% of all breaches, and the effectiveness of these attacks depends far less on technical sophistication than on contextual credibility. A billing email with a child's name in the subject line has contextual credibility in abundance.

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

The Tell Themis Caught

The IRONSCALES platform had prior knowledge of Brightwheel-associated addresses. The display name "Kimberly St.Pierre" was known in the IRONSCALES community as a sender associated with support@mybrightwheel[.]com, not no-reply@notify[.]mybrightwheel[.]com.

That mismatch, display name tied to a known address now appearing from a different address, is an exact display name impersonation signal. Themis flagged it. Combined with community intelligence showing similar patterns flagged as phishing across other organizations, the confidence threshold crossed.

Four mailboxes were quarantined on April 2, 2026. The emails never got a reply.

There is also a secondary tell any analyst can spot: the greeting reads "Hello ," with no name. The mail merge token failed to populate. Legitimate transactional platforms always fill in the recipient name from account data. A blank greeting in a billing notification means the sender lacks access to actual account data, or is running a bulk send with a broken template. Neither is reassuring.

Why Filtering Tools Miss This

Microsoft's 2024 Digital Defense Report notes that attackers increasingly exploit trusted cloud infrastructure to deliver malicious content, because reputation-based filtering cannot penalize legitimate services without unacceptable false positive rates.

The pattern works because of how tooling is scoped. URL scanners check destinations. IP reputation scores sending infrastructure. DMARC enforcement blocks unauthorized domain use, not authorized misuse. None of these gates inspect the Reply-To header against behavioral expectations.

What this attack required was behavioral analysis: display name history against sending address, Reply-To domain against From domain, and a failed personalization token. None of those signals are in the authentication layer. The FBI's 2024 Internet Crime Report documented $2.9 billion in BEC losses, with a significant portion in this exact category: legitimate infrastructure, intercepted reply, social engineering close.

Phishing through trusted third-party services maps to MITRE ATT&CK T1598.003 (Spearphishing via Service). The technique is documented. The defenses have not kept pace.

What to Do About It

The standard advice does not fully apply here. You cannot block Brightwheel or Postmark without creating significant collateral damage for schools and childcare organizations that legitimately use both.

What works:

1. Flag Reply-To mismatches. If the Reply-To domain does not match the From domain, that is an anomaly worth investigating, particularly for billing, HR, and financial communications. Most email security platforms can surface this. Most organizations have not turned it on.

2. Check display name history. A display name that has appeared previously associated with a different address is a red flag. This requires a behavioral baseline, something static reputation scoring cannot provide.

3. Train on reply-chain attacks. Most phishing awareness training focuses on malicious links and attachments. Reply-To hijacks leave no malicious links. The payload is the reply. Train users to verify contact addresses before responding to billing or financial communications, even when the email looks perfect.

4. Look for broken personalization. "Hello ," is not subtle. A missing name in a billing notification is worth a second look. This is a teachable pattern.

The IRONSCALES platform detected this attack not by scanning links or checking sender reputation, but by comparing what it knew about the display name against the sending address, then cross-referencing with community intelligence from across its global deployment. That combination caught what authentication headers could not.

Indicators of Compromise

Indicator	Type	Context
`kstpierre@seniorlifestyle[.]com`	Email	Attacker-controlled Reply-To and contact address
`seniorlifestyle[.]com`	Domain	Attacker-controlled domain used for reply interception
`no-reply@notify[.]mybrightwheel[.]com`	Email	Legitimate Brightwheel sending address (abused)
`track[.]pstmrk[.]it`	Domain	Postmark tracking proxy (legitimate, used to wrap all links)
`104[.]245[.]209[.]210`	IP	Postmark MTA (mta210a-ord.mtasv[.]net), legitimate Brightwheel-authorized sender
Subject: "Your most recent billing statement for Wesley Grier is now available"	Subject line	Lure subject, child name used for credibility

For business email compromise incidents that exploit trusted SaaS infrastructure, IOCs have limited defensive value. The sending infrastructure is legitimate and will keep being used that way. The response priority is behavioral detection, not IP or domain blocking. See CISA phishing guidance for organizational reporting frameworks.

The same technique works against any SaaS platform that allows transactional email customization. Review your threat intelligence posture accordingly.

The Subdomain That Fused Two Trusted Brands Into One Convincing Lie

apaxson@ironscales.com (Audian Paxson) — Mon, 13 Apr 2026 11:00:00 GMT

TL;DR Attackers registered a subdomain under Zix's legitimate secureemailportal.com platform and named it 'fidelityusa' to impersonate Fidelity National Title. The resulting sender address fused two trusted brand names into one convincing-looking domain with valid DKIM, SPF, and DMARC at origin. Routed through the Zix enterprise relay chain, the message inherited enterprise-grade authentication reputation before landing in a bank business portal inbox. A mismatched Reply-To domain and a secondary lookalike domain (fidelity-usa.com, quietly updated just weeks before the attack) pointed to attacker infrastructure, but no automated filter caught either signal. Detection required behavioral analysis of sender identity divergence against authentication header context.

Severity: High Credential Harvesting Brand Impersonation MITRE: {'id': 'T1566.002', 'name': 'Phishing: Spearphishing Link'} MITRE: {'id': 'T1598.003', 'name': 'Phishing for Information: Spearphishing Link'} MITRE: {'id': 'T1036.005', 'name': 'Masquerading: Match Legitimate Name or Location'}

The sender address looked like a Zix secure portal notification from Fidelity National Title. That part was real. What wasn't real was that the subdomain fidelityusa.secureemailportal.com had anything to do with Fidelity National Title at all.

Attackers provisioned a subdomain under Zix's legitimate secure email portal infrastructure, named it after a major financial brand, and used the resulting address to target a community bank's business banking portal. The message passed DKIM, SPF, and DMARC at origin. Every automated filter in the chain called it clean.

This is what brand-fusion phishing looks like when it's done by someone who understands how email authentication actually works.

How You Build a Convincing Lie Out of Two Real Names

The attacker's first move was strategic. Rather than registering a throwaway lookalike domain that would age-check as days old and fail reputation filters, they used an established platform's subdomain provisioning to operate under secureemailportal.com.

That domain was registered in 2017 and runs on Zix nameservers (NS01.ZIXCORP.COM through NS03.ZIXCORP.COM). It carries enterprise-grade reputation. DKIM signing, SPF authorization, and DMARC enforcement are all handled by Zix infrastructure. When an attacker provisions a subdomain under that platform, they inherit all of it.

The subdomain label they chose was fidelityusa. Combined with the parent domain, the full sender address became:

fidelityusa-notification@fidelityusa.secureemailportal.com

To anyone reading that address, it signals: a Fidelity entity, using a Zix secure portal, sending a legitimate notification. Two trusted brands, fused into one address. Neither name alone is a red flag. The combination implies an institutional relationship that does not exist.

The target was a business banking portal inbox at a community bank. Not a random employee, not a generic info@ address. A BusinessOnline inbox handles wire transfer notifications, ACH confirmations, and account management messages. Attackers picked this target because the credential value is high.

The Attack Chain, Step by Step

The relay chain is where the technical sophistication becomes clear.

The message originated from mail3239.smtp25.com, routing into Zix's outbound infrastructure at out.zixmt1.zixworks.com, through mx1.zp.prod.zixcorp.com, and out via smtpout.zixmail.net. That exit point is secureemailportal.com at IP 199.30.236.16.

At that hop, the authentication record is clean. SPF passes. DKIM passes with a verified body signature. DMARC passes with action none. Microsoft's composite authentication score (compauth) marks it as pass reason=100.

The message then hit a Votiro content sanitization relay at 44.206.213.130 (an Amazon EC2 host, ec2-44-206-213-130.compute-1.amazonaws.com). Votiro performs content inspection and reconstruction, which modifies the message body. That modification invalidated the DKIM body hash. By the time the message reached Microsoft's inbound protection layer, the authentication picture had changed: SPF softfail, DKIM body-hash failure, DMARC fail.

But Microsoft had already seen the earlier passing authentication headers. The message was marked as previously validated and delivered.

The full delivery path:

Attacker sends via mail3239.smtp25.com
Routes through Zix enterprise relay chain
Exits secureemailportal.com (199.30.236.16) with full auth pass
Passes through Votiro sanitization relay (44.206.213.130), which breaks DKIM body hash
Arrives at Microsoft inbound protection nodes
Delivered to target inbox

MITRE ATT&CK mappings: T1566.002 (Spearphishing Link) for the primary delivery mechanism, T1036.005 (Masquerading: Match Legitimate Name or Location) for the subdomain brand fusion technique.

What the Email Said, and What It Was Trying to Do

The email body was minimal by design. A Zix secure-message template, gray header bar, a single "Open Message" button in a styled table cell.

The header read: "New Zix secure email message from The Baker Firm - Fidelity National Title."

The CTA linked to hxxps://fidelityusa[.]secureemailportal[.]com/s/e?m=ABAqJQldBKKwN6vp16AKCIBp.

An expiration notice added pressure: "The secure message expires on Apr 17, 2026 @ 04:09 PM (GMT)." Two weeks, not two hours. That pacing is deliberate. It reduces urgency that might prompt a call to verify, while still creating a deadline that pushes toward action.

There was no personalization. No recipient name, no account number, no transaction detail. That absence is a signal, because legitimate Zix secure-message notifications from financial institutions typically include some identifying context. This was a generic lure, sent at scale.

Four mailboxes at the target organization received the message.

See how many phishing emails are getting through your filters.

The Signal That Gave It Away

The Reply-To header pointed somewhere else entirely.

While the sender was fidelityusa-notification@fidelityusa.secureemailportal.com, the Reply-To was ecook@fidelity-usa.com. Different domain. Different registrar. Different nameservers.

fidelity-usa.com was registered in 2011 via Bluehost on iPowerWeb nameservers. Not Zix infrastructure. Not Fidelity National Title infrastructure. And it was quietly updated on February 24, 2026, roughly five weeks before this campaign ran.

That update is the tell. Someone refreshed a dormant domain to prepare it for operational use. The result is a two-domain attacker setup: the Zix subdomain handles inbound trust and authentication, and fidelity-usa[.]com handles reply-to collection, the actual phishing destination control.

Any reply from the recipient, any credential submission that routes through a reply, goes to attacker-controlled infrastructure. The two-domain structure is intentional: one domain for appearing legitimate, one for collecting the harvest.

Themis flagged the mismatch between sender domain and Reply-To domain as a behavioral anomaly. The sender's identity, cross-referenced against IRONSCALES community threat intelligence and authentication header analysis, did not support the claimed institutional relationship. The message was quarantined before any of the four affected mailboxes interacted with the "Open Message" link.

What Security Teams Should Do Differently Here

Static email authentication checks (SPF, DKIM, DMARC) are necessary but insufficient for this attack class. The message passed all three at origin. The threat was not in the authentication. It was in the identity claim.

A few specific controls matter here:

Reply-To domain inspection. If the Reply-To domain does not match the From domain or share the same organizational parent, that's a divergence signal worth flagging. It is not proof of phishing, but it warrants additional scrutiny before delivery.

Subdomain authority verification. The existence of a subdomain under a legitimate platform does not confirm that the subdomain operator has any relationship with the brand names in the subdomain label. fidelityusa.secureemailportal.com says nothing about Fidelity National Title authorizing that subdomain. This requires behavioral or community-intelligence signals, not just DNS or authentication checks.

Business banking inbox hardening. High-value inboxes like business email compromise targets, treasury addresses, and banking portals warrant stricter filtering thresholds than standard employee mailboxes. The expected email profile for a BusinessOnline address is narrow. An unexpected secure-portal notification from a real estate title firm falls outside that profile.

Age-of-relationship signals. The sending domain and the organization had no prior communication history. First-contact messages from unknown senders should carry elevated scrutiny regardless of authentication status, especially when they include a credential-requesting CTA.

The 2024 Verizon DBIR found phishing involved in 68% of financially motivated breaches, and the FBI's 2024 IC3 Report logged over $2.9 billion in BEC losses, with credential harvesting as the primary enabler. The Microsoft Digital Defense Report 2024 specifically flags trusted third-party platform abuse as an accelerating attacker technique, exactly what this case illustrates.

The defensive answer is not better authentication. It is behavioral detection that evaluates identity coherence across sender domain, Reply-To, brand claims, and relationship history, the kind of signal that flagged this message before any recipient clicked.

Indicators of Compromise

Type	Indicator	Context
Domain	`fidelityusa[.]secureemailportal[.]com`	Attacker-provisioned subdomain on Zix infrastructure. Sender and link destination.
URL	`hxxps://fidelityusa[.]secureemailportal[.]com/s/e?m=ABAqJQldBKKwN6vp16AKCIBp`	"Open Message" CTA. Credential harvesting portal entry point.
Domain	`fidelity-usa[.]com`	Reply-To domain. Attacker-controlled. Updated Feb 24, 2026. Bluehost/iPowerWeb nameservers.
Email	`ecook@fidelity-usa[.]com`	Reply-To address. Attacker collection infrastructure.
Email	`fidelityusa-notification@fidelityusa[.]secureemailportal[.]com`	Sender address. Zix subdomain, authenticated at origin.
IP	`199[.]30[.]236[.]16`	Zix outbound relay. Origin authentication passed at this hop.
IP	`44[.]206[.]213[.]130`	Votiro sanitization relay (EC2). Post-processing DKIM break occurred here.
Domain	`mail3239[.]smtp25[.]com`	Initial sending infrastructure origin.

---

For deeper context on how spear phishing campaigns exploit trusted third-party infrastructure, see the IRONSCALES threat intelligence blog.

The Password Expiry Email That Hid Its Destination in a Base64 Fragment

apaxson@ironscales.com (Audian Paxson) — Sun, 12 Apr 2026 11:00:00 GMT

TL;DR Attackers sent a Microsoft 365 password-expiry lure through a law firm domain on Amazon SES, routing victims through a multi-hop redirector chain that buried the real destination in a Base64-encoded URL fragment. Scanners that don't execute fragment-based redirects never saw the actual landing page: a Shopify-hosted credential harvesting kit with the recipient's email pre-loaded into the path. A third evasion layer salted the CTA button text with zero-width Unicode characters to defeat string-based content filters. IRONSCALES Adaptive AI flagged and quarantined the message automatically, correlating the obfuscated link behavior with credential theft patterns before any user interaction.

Severity: High Credential Harvesting Phishing MITRE: {'id': 'T1566.002', 'name': 'Phishing: Spearphishing Link'} MITRE: {'id': 'T1027', 'name': 'Obfuscated Files or Information'} MITRE: {'id': 'T1036', 'name': 'Masquerading'} MITRE: {'id': 'T1078', 'name': 'Valid Accounts'}

The email looked like a routine Microsoft 365 password expiry notice. Sender name: "Front Desk-Service." Subject line stamped with yesterday's date. A blue button urging the recipient to stay on their current password before the deadline.

What it actually was: a three-layer evasion stack delivering a Shopify-hosted credential harvesting kit, where every part of the delivery chain was specifically designed to look clean to automated scanners.

The Redirect That Wasn't in the URL

The CTA button linked to a legitimate-looking shortener service. That URL contained a redirect_url parameter pointing to a subdomain of a real conservation organization in Argentina. Standard redirect-chain behavior, nothing unusual there.

The destination URL for that redirect, however, was malformed. The scheme and host were present but the path was empty. What followed the # fragment delimiter was a long Base64 string:

`` hxxp://6c.vkfws.parquepatagoniaargentina[.]org://#aHR0cHM6Ly9zZXJlbml0eWphZGVi... ``

Decoded, that Base64 resolves to:

`` hxxps://serenityjadebundles[.]com/wahalawahalawahala/nibojapaomoiyami/Ironscales/[recipient-email] ``

The subdomain (6c.vkfws) is NXDOMAIN and effectively disposable. Its only purpose is to carry the Base64 payload in the fragment. The parent domain belongs to a legitimate conservation organization with DMARC enforcement in place. It was never a participant in this attack.

Here is why this matters for scanners: URL fragment identifiers (#...) are processed by the browser, client-side. They are not sent to the server in HTTP requests. Many link-scanning tools evaluate the stated redirect target at the network level and stop there. If the scanner doesn't spin up a browser context and execute the fragment-based redirect, it never reaches serenityjadebundles[.]com. It sees a malformed URL pointing at an NXDOMAIN subdomain of a reputable conservation org. It moves on.

The real landing page stays invisible.

Shopify as Phishing Infrastructure

serenityjadebundles[.]com resolves to Shopify hosting. Registered in 2019, most recently updated in February 2025, the domain nameservers are Google Domains. On the surface: an ordinary small business site on a mainstream commerce platform.

That is exactly the point.

Shopify domains inherit the platform's aggregate reputation. Security tools that evaluate URLs against blocklists and reputation scores tend to treat Shopify-hosted pages as low-risk by default. Registering a dedicated phishing domain leaves fingerprints: fresh registration dates, obscure TLDs, privacy-proxy WHOIS, hosting on known bulletproof infrastructure. Abusing an established domain on a trusted platform leaves far fewer.

The path structure embedded the recipient's email address: .../Ironscales/[recipient-email]. This is standard practice for commodity phishing kits. The harvesting page auto-fills the email field on load so the victim sees their own address pre-populated, reinforcing the illusion that this is a legitimate Microsoft 365 portal session. It also enables the attacker to track which specific addresses clicked through.

By the time this campaign was active, Shopify had already become a known vector for credential harvesting. According to the Microsoft Digital Defense Report 2024, legitimate cloud services are increasingly the preferred hosting environment for phishing infrastructure precisely because they benefit from established trust relationships with security tooling.

See Your Risk: Calculate how many credential theft attempts your current gateway is missing

Three Evasion Layers in One Email

The Base64 fragment trick was the headline, but the message was constructed with additional filter-bypass logic throughout.

Layer 1: Base64 fragment redirect. Covered above. Link scanners that evaluate redirect chains at the network layer, without executing fragment-based client-side navigation, never see the Shopify destination.

Layer 2: Personalized Shopify path. The recipient email address embedded in the URL path is not just a tracking mechanism. It also means every harvesting URL is unique per target. Blocklist-based detection that compares against known-bad URLs fails when every URL is slightly different.

Layer 3: Zero-width Unicode in button text. The CTA button label included invisible Unicode characters interspersed throughout the visible text. Rendered in a browser, the button reads normally. At the string level, the text is broken into fragments that don't match known-bad signatures. This technique has appeared in other campaigns using Unicode obfuscation (including a DocuSign impersonation with right-to-left override characters we covered recently). It is becoming table stakes in commodity kits.

The sending infrastructure rounded out the picture. The email came from a law firm domain via Amazon SES with valid SPF and DKIM. The problem: both authentication records aligned to amazonses.com, not to the law firm's own domain. The law firm domain published no DMARC record. So composite authentication failed, but there was nothing to enforce on. The message delivered cleanly.

Verizon's 2024 Data Breach Investigations Report found that phishing remains the most common initial access technique in confirmed breaches, present in 68% of social engineering incidents. The FBI's 2024 IC3 Internet Crime Report put credential theft-related losses at multi-billion dollar scale annually. Attacks like this one illustrate why those numbers don't move: the evasion investment is low, the tooling is commoditized, and each individual layer looks harmless in isolation.

What the Detection Chain Actually Had to Solve

Each evasion layer on its own is manageable. Together, they create a compound problem for tools that evaluate signals in isolation.

The redirect URL scores clean because the destination is NXDOMAIN. The Shopify domain scores clean because of platform reputation. The button text passes string matching because the tokens are fragmented by invisible characters. The sender authentication passes SPF and DKIM checks because SES signed it legitimately, even though DMARC alignment failed.

IRONSCALES Themis flagged this within seconds of delivery, with 90% confidence on Credential Theft, before any user interaction. The detection wasn't built on any single signal. It correlated the authentication failure pattern (compauth=fail on a DMARC-none domain), the first-time sender with no business relationship to the recipient, the obfuscated link structure, and the urgency header stack (Priority: urgent, X-Priority: 1, Importance: high) as a compound fingerprint of credential-theft behavior. The message was quarantined automatically.

The IRONSCALES Adaptive AI approach to this class of attack is behavioral, not signature-based. Fragment-based redirect chains don't have known-bad signatures at the point of delivery. What they do have is a pattern: obfuscation, authentication misalignment, urgency signals, first-time sender, and a harvesting kit on a platform with high ambient reputation. That pattern is detectable even when every individual component looks clean.

For teams using credential harvesting protection, this case is a useful calibration point on what to expect from the current generation of commodity kits.

What Security Teams Should Pressure-Test

Three direct takeaways from this campaign:

Verify that your URL scanning executes redirects. Static analysis of redirect URLs is increasingly insufficient. If your scanning infrastructure doesn't spin up a browser context and follow fragment-based redirects, an entire class of evasion techniques is invisible to it. Ask your vendor explicitly: does link scanning execute JavaScript and follow client-side navigation?

Don't treat platform reputation as a safety signal. Shopify, Google Sites, OneDrive, Dropbox: attackers use all of them. A URL pointing at a reputable platform hostname is not inherently safer than one pointing at a fresh attacker domain. Content analysis and behavioral signals matter more than hostname reputation alone.

Enforce DMARC on your own domain. The sending domain in this campaign published no DMARC record, which meant composite authentication failure had no consequence. If your organization's domain is in the same position, it's available as spoofing infrastructure. IRONSCALES DMARC management gives security teams visibility into domain posture and enforcement gaps. Per CISA's phishing guidance, DMARC enforcement at reject or quarantine is a baseline control recommendation.

The Verizon DBIR consistently shows that credential theft attacks succeed not because defenders lack awareness, but because the detection chain has gaps that attackers have already mapped. The fragment redirect trick isn't new. Neither is Shopify abuse. What's notable here is seeing all three evasion layers deployed together in a commodity campaign, suggesting these techniques have moved from targeted to routine.

Indicators of Compromise

Type	Indicator	Context
URL	`hxxp://qtd[.]io/r?a=click&c=lk5j-bf-email05&l=social-share-linkedin&redirect_url=...`	Initial redirector with encoded destination
Domain	`6c.vkfws.parquepatagoniaargentina[.]org`	Decoy/carrier host; NXDOMAIN subdomain carrying Base64 fragment
Domain	`serenityjadebundles[.]com`	Shopify-hosted credential harvesting kit
URL	`hxxps://serenityjadebundles[.]com/wahalawahalawahala/nibojapaomoiyami/`	Harvesting path (recipient email appended as final path segment)
Email	`mbalaban@balaban-law[.]com`	Sender address; law firm domain with no DMARC record
IP	`69[.]169[.]224[.]17`	Amazon SES EU-Central relay (b224-17.smtp-out.eu-central-1.amazonses[.]com)
Header pattern	`Priority: urgent` + `X-Priority: 1` + `Importance: high`	Triple urgency stack; common credential-theft delivery fingerprint

Purpose-Built Look-Alike Sending Domain Passes Full Authentication to Impersonate Training Brand

apaxson@ironscales.com (Audian Paxson) — Sat, 11 Apr 2026 05:00:00 GMT

TL;DR A webinar invitation impersonating a professional training brand passed full email authentication (SPF, DKIM, DMARC, compauth=100) using a purpose-built look-alike sending domain registered 2.5 years prior. The attacker exploited the common enterprise pattern where legitimate brands use separate sending subdomains. The display name matched a known contact exactly, but the sending domain swapped one keyword. Microsoft flagged SCL=5 and quarantined, but the authentication signals alone would have cleared most gateways.

Severity: High Brand-Impersonation Reconnaissance MITRE: T1583.001 MITRE: T1566.002 MITRE: T1036.005

A webinar invitation for "Electronic Records Retention" landed in an enterprise mailbox. The sender name matched a known vendor contact. The branding matched a legitimate professional training company. SPF passed. DKIM passed. DMARC passed with a compauth score of 100. The email carried CE credit details (ATAHR, HRCI, SHRM), a professional footer with a real physical address, and a functioning unsubscribe mechanism.

The sending domain was wrong. Not wrong in a way that screamed fraud. Wrong in a way that exploited how legitimate companies actually send email.

The IRONSCALES platform flagged the domain mismatch and quarantined the email across multiple mailboxes within seconds.

Exploiting the Separate Sending Domain Pattern

Most enterprise email programs use dedicated sending domains for marketing and transactional messages. A company operating as brand[.]com might send campaigns from brand-sending[.]com or brand-mail[.]com. Recipients are trained to accept this pattern. Email administrators whitelist these domains. Security tools learn to associate them with the primary brand.

This attack weaponized that expectation. The impersonated brand operates its primary domain at auroratrainingadvantage[.]com, registered in 2013 and hosted on Cloudflare. The attacker built a parallel infrastructure using two purpose-built domains:

Sending domain: trainingadvantagesending[.]com (From address, DKIM signing)
Mail relay domain: trainingadvantage-mail[.]com (MX/SMTP relay, HELO identity)

Both attacker domains were registered on the same day, July 31, 2023, through Dynadot with full WHOIS privacy. Both use the same nameservers. Both carry proper SPF, DKIM, and MX records. This is not a hastily assembled phishing kit. The infrastructure was purpose-built over two years before this attack landed.

The naming pattern is precise. The legitimate brand uses "aurora training advantage" while the attacker domains use "training advantage" plus a mail-function suffix ("sending" and "mail"). To a recipient scanning the From field, cindyfreeman@trainingadvantagesending[.]com looks like the marketing send variant of a familiar vendor.

Full Authentication on Attacker-Controlled Infrastructure

The email arrived from mx4.trainingadvantage-mail[.]com at IP 185[.]227[.]50[.]117 (geolocated to Canada). The complete authentication chain:

SPF: Pass (trainingadvantagesending[.]com designates 185[.]227[.]50[.]117 as permitted sender)
DKIM: Pass (d=trainingadvantagesending[.]com, selector smtpdkim, RSA-SHA256)
DMARC: Pass, action=none
compauth: 100 (Microsoft Composite Authentication, perfect score)

Every authentication check returned the best possible result. The domain aligned across envelope, headers, and DKIM signature. The DMARC protocol confirmed that the From domain matched the authenticating domain. The problem is that the authenticating domain was not the brand it pretended to be.

This is the structural limitation of SPF and DKIM. They verify that a domain owner authorized the sending server. They do not verify that the domain belongs to the brand the recipient thinks it represents. An attacker who registers their own domain and configures authentication correctly will pass every check, every time.

The Microsoft Digital Defense Report 2024 documented the growing sophistication of brand impersonation infrastructure, noting that attackers increasingly invest in long-lived domains with proper authentication to evade detection at scale.

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

Display Name Impersonation With Known Contact Match

The From header read: " Cindy Freeman " . The IRONSCALES platform had previously seen legitimate email from a contact named "Cindy Freeman" at cindyfreeman@trainingadvantagecampaign[.]com. The display name was an exact match. The local part (cindyfreeman) was identical. Only the domain differed.

This triggers a specific detection class: exact display name impersonation with domain mismatch. The attacker did not just copy a brand. They copied a specific person associated with that brand, using a domain close enough that the swap would not register on a quick visual scan.

The Verizon DBIR 2024 found that pretexting (which includes brand and identity impersonation) accounted for over 40% of social engineering incidents. The FBI IC3 2024 report documented $2.9 billion in BEC/fraud losses, with impersonation of trusted vendors as a primary attack vector.

Links Redirect Through Attacker Domain to Legitimate Event Platform

All embedded links pointed to trainingadvantagesending[.]com with click-tracking parameters, including /external_pages/clickTracker.aspx paths. These click-tracker URLs redirected to a legitimate Eventbrite registration page for a real Aurora Training Advantage webinar ($219-$599 tickets, CE credits, real event date).

This is the subtlety. The final destination is a real event on a real platform. The attacker is not harvesting credentials at the landing page. Instead, they are routing all clicks through their own tracking infrastructure first. Every click confirms an active mailbox, records the recipient's IP and user agent, and timestamps engagement. This maps to MITRE ATT&CK T1598.003 (Phishing for Information: Spearphishing Link), where the objective is intelligence gathering rather than immediate payload delivery.

The click-tracking URLs carried unique identifiers (cid=42072067, lid=4977080, sid=1592455) tied to specific campaigns and recipients. Combined with the X-Campaign and Feedback-ID headers, the attacker maintained full visibility into which mailboxes were active and which recipients engaged.

This case also maps to MITRE ATT&CK T1583.001 (Acquire Infrastructure: Domains) for the purpose-built look-alike domain registration, and T1036.005 (Masquerading: Match Legitimate Name or Location) for the brand naming pattern mimicry.

Why This Pattern Defeats Gateway Controls

Microsoft's own antispam engine assigned SCL=5 and a Bulk Complaint Level (BCL) of 8, routing the email to quarantine. But the detection was based on bulk mail heuristics, not the impersonation itself. The BCL=8 score reflects sender reputation patterns typical of mass marketing, not threat intelligence. An attacker sending lower volumes from the same authenticated infrastructure would likely achieve SCL=1, bypassing the quarantine entirely.

Legacy secure email gateways that rely on domain age, authentication results, and URL reputation would pass this email clean. The domain is 2.5 years old. Authentication is perfect. The link destinations are Eventbrite.

Detection required behavioral context: recognizing that a known contact name appeared on an unfamiliar domain, that the sending domain mimicked but did not match a known vendor, and that community threat intelligence had flagged similar patterns across organizations. The IRONSCALES Themis engine assigned 80% confidence and triggered automatic quarantine across affected mailboxes.

Indicators of Compromise

Type	Indicator	Context
Sender Email	cindyfreeman@trainingadvantagesending[.]com	Display name impersonation of known vendor contact
Sending Domain	trainingadvantagesending[.]com	Look-alike domain, registered 2023-07-31 via Dynadot, WHOIS privacy
Mail Relay Domain	trainingadvantage-mail[.]com	Registered same day as sending domain, same registrar
Relay Hostname	mx4.trainingadvantage-mail[.]com	SMTP HELO identity
Sending IP	185[.]227[.]50[.]117	Geolocated to Canada
Impersonated Brand Domain	auroratrainingadvantage[.]com	Legitimate domain, registered 2013, Cloudflare-hosted
Known Contact Domain	trainingadvantagecampaign[.]com	Legitimate campaign domain for same brand
Click Tracker URL	hxxps://www[.]trainingadvantagesending[.]com/external_pages/clickTracker[.]aspx	Attacker-controlled redirect with per-recipient tracking
DKIM Selector	smtpdkim (d=trainingadvantagesending[.]com)	Valid DKIM key on attacker domain
SCL Score	5	Microsoft spam confidence level (bulk mail heuristic)
BCL Score	8	Bulk complaint level (high, triggered quarantine)
compauth	100	Perfect composite authentication score

The Timestamp That Gave It Away: Oracle Identity Cloud Phishing Targets K-12 with a Stale Timezone

apaxson@ironscales.com (Audian Paxson) — Fri, 10 Apr 2026 11:00:00 GMT

Attackers sent a fake Oracle Identity Cloud password reset email to a K-12 employee in Florida. The kit used 'CDT' in the timestamp even though Daylight Saving Time had ended on November 2, 2025, meaning the correct abbreviation was 'CST.' The reset link pointed to richard-woof.com, a UK-hosted domain with no connection to Oracle, and its Base64-decoded token revealed explicit per-recipient targeting. A Google 404 redirect cloaked the destination from automated scanners. The case illustrates a low-tech detection method available to any recipient: check whether the timezone in a security notification matches the current time of year.

The GitLab Alert That Passed Every Filter (Except One Detail Nobody Checked)

apaxson@ironscales.com (Audian Paxson) — Thu, 09 Apr 2026 11:00:00 GMT

Attackers sent a near-perfect GitLab sign-in notification to employees at a UK-based specialty insurance firm. The email passed SPF, DMARC, and Proofpoint URL Defense rewriting — all signals that gave it an air of legitimacy. But the IP address listed in the notification body as the sign-in source was 10.115.13.36, an RFC1918 private address that cannot be reached from the public internet. Real GitLab cloud sign-in alerts always show a routable public IP. The Proofpoint URL Defense wrappers on the links actually worked against detection here: they created a false sense that the links had been vetted, drawing attention away from the real tell sitting in the body text itself. Themis flagged the message as credential theft before any user clicked.

When Your Security Vendor's OAuth Endpoint Is the Phishing Link

apaxson@ironscales.com (Audian Paxson) — Wed, 08 Apr 2026 13:45:00 GMT

A Pandora billing impersonation campaign embedded a CTA resolving to Mimecast's real OAuth2 API endpoint, with a redirect_uri pointing to an attacker-controlled destination under the mimecastcybergraph.com domain. Because the link resolved to api.services.mimecast.com, URL scanners rated it clean. SPF and DMARC passed via Amazon SES. DKIM body-hash failed at final delivery after Mimecast relayed and rewrote the message, eroding the last remaining cryptographic signal. The case demonstrates that trust in a security vendor's domain is not a safety proxy when OAuth redirect_uri parameters control where consent flows actually land.

The DocuSign Lure That Used Google as a Trust Shield (And Encoded Your Email in the Link)

apaxson@ironscales.com (Audian Paxson) — Wed, 08 Apr 2026 11:00:00 GMT

A credential harvesting campaign impersonated DocuSign using a google.com/url redirect wrapper to disguise a malicious .ink domain. The CTA URL contained a base64-encoded token that decoded to the recipient's exact email address, enabling precise click tracking. The email also exposed raw template placeholders in the body, a common attacker OPSEC failure. The originating IP produced an SPF failure against the spoofed law firm sender domain. IRONSCALES Themis flagged and quarantined the message at 90% confidence before any user interaction.

The USPS Link That Looked Right Until It Wasn't

apaxson@ironscales.com (Audian Paxson) — Tue, 07 Apr 2026 20:47:50 GMT

TL;DR Attackers combined two evasion layers in a USPS impersonation campaign: zero-width Unicode characters (U+FEFF) injected into the displayed URL made it render as a legitimate usps.com link on screen, while the actual href routed victims through Google Translate (translate.goog) to a threat-actor-controlled domain at dpdns.org, registered just weeks earlier. The email itself transited Microsoft 365 Groups infrastructure, preserving ARC-seal integrity and passing SPF for the envelope sender. DMARC failed on the header From address, but that signal was buried. The attack defeated both the hover-to-check reflex and most automated URL reputation checks simultaneously.

Severity: High Credential Harvesting Phishing Brand Impersonation MITRE: {'id': 'T1566.002', 'name': 'Phishing: Spearphishing Link'} MITRE: {'id': 'T1036', 'name': 'Masquerading'} MITRE: {'id': 'T1027', 'name': 'Obfuscated Files or Information'}

You can hover over a link. Every security awareness training program in existence tells you to do exactly that. Hover before you click, check the domain, move on.

This attack breaks that reflex completely.

A phishing email impersonating USPS arrived with a link that displayed as https://www.usps.com/Update_Address. Hovering it would have shown translate.goog, which is Google. Still looks safe to most people. Neither check would have exposed the actual destination: a threat-actor-controlled domain at dpdns[.]org, proxied through Google Translate, reached through a Microsoft 365 relay that kept the authentication chain intact. Two evasion layers working together, each one designed to defeat a different detection instinct.

What the Link Actually Said vs. What It Showed

The displayed URL in the email body was visually indistinguishable from a legitimate USPS link. Rendered on screen, it read https://www.usps.com/Update_Address. Look at the raw HTML and the picture changes immediately.

The attacker peppered every word and URL segment with Unicode U+FEFF, the zero-width no-break space character. These characters are invisible to the human eye but present in the underlying markup. Security filters that evaluate the display text of a link rather than its raw href value see what appears to be a usps.com URL. The href itself pointed somewhere entirely different.

The actual destination: hxxps://breakfast881-saccessful-dpdns-org.translate[.]goog/?_x_tr_hl=zh-CN&_x_tr_sl=auto&_x_tr_tl=mr

Unpacked, that is a Google Translate proxy URL. The origin domain is encoded in the subdomain as saccessful-dpdns.org, a subdomain of the attacker-registered dpdns[.]org. Google Translate fetches and renders the origin page at that domain, wrapped in the translate.goog hostname. To any tool checking the immediate URL, this is a Google domain.

This is a two-stage misdirection. The first stage fools anyone relying on display text. The second stage fools anyone who gets past the first stage and checks the actual href.

The Infrastructure Behind the Lure

dpdns[.]org was registered on 2025-03-13 through Gandi SAS with fully redacted WHOIS registrant data. Nameservers resolve to ns1.digitalplat[.]org, ns2.digitalplat[.]org, and ns3.digitalplat[.]org. The specific subdomain used in this campaign (saccessful-dpdns.org) returned NXDOMAIN during SOC analysis, a pattern consistent with phishing kits that rely on the Google Translate proxy to serve content without ever needing the phishing subdomain to resolve directly.

The domain was less than eight months old at the time of this incident. IRONSCALES platform data shows this kind of newly-registered, WHOIS-redacted infrastructure appearing regularly in campaigns that pair fresh domains with trusted proxy services precisely because reputation scores have no history to work from.

The email itself came from ptwmihaf462@hotmail.com, sent through a Microsoft 365 Groups relay (groups.outlook.com). That routing choice was deliberate. Because the relay is legitimate Microsoft infrastructure, ARC-Seal and ARC-Message-Signature were present and passed. SPF passed for the envelope sender domain (groups.outlook.com). DMARC failed for the visible header From address (hotmail.com) because there was no DKIM signature and no SPF alignment with hotmail.com, but that failure was buried in authentication headers that most end users never see and that some automated filters weight less heavily when the overall relay chain looks clean.

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

The USPS logo was pulled directly from www.usps.com. The body text followed a standard redelivery pretext: your package arrived, it will be returned if you don't update your address, click here. Generic enough to apply to anyone, urgent enough to prompt action. According to the FBI IC3 Internet Crime Report 2024, parcel and delivery-themed phishing continues to be one of the most volume-efficient social engineering pretexts in circulation, requiring minimal customization per target.

Why Standard Checks Did Not Catch This

URL reputation tools typically evaluate the domain in the href against known-bad lists. translate.goog is not on any reputation blocklist. It is an active Google service. Checking the redirect chain from translate.goog to the actual origin domain requires the scanner to follow the proxy and inspect what is on the other side, which most gateway-level scanners do not do in real time.

MITRE ATT&CK classifies the underlying techniques as T1566.002 (Spearphishing Link), T1036 (Masquerading), and T1027 (Obfuscated Files or Information). The combination is specifically engineered to defeat layered inspection that stops at any single checkpoint.

Verizon's 2024 Data Breach Investigations Report notes that the median time for a user to click a phishing link after delivery is under 60 seconds. This campaign did not need to beat sophisticated automated analysis. It needed to beat a person glancing at a URL on a phone or in a preview pane. It was built for that.

Themis flagged the mismatch between the displayed URL and the actual href value during behavioral analysis, catching what the surface-level authentication checks missed. The email was quarantined automatically before any recipient interaction. The sender was flagged as a first-time sender with high risk, and community intelligence from across the IRONSCALES platform had already associated similar relay chain patterns with active credential harvesting campaigns.

What Security Teams Need to Adjust

URL analysis needs to evaluate href values, not display text. If your email security platform only checks what the link appears to say, zero-width character injection bypasses it by design. The Microsoft Digital Defense Report 2024 specifically calls out URL obfuscation as an increasingly common technique used to evade gateway-level scanning (see: Microsoft Digital Defense Report 2024).

Trusted proxy abuse via Google Translate, AMP caches, and similar services is not new, but it has become more systematic. Filtering on the proxied hostname alone is insufficient. Detection needs to dereference redirect chains and inspect final destinations. The IRONSCALES Advanced Malware and URL Protection layer handles this at the platform level, but for teams relying on gateway inspection alone, the gap is real.

DMARC failure is a signal, but context matters. A DMARC fail on a message that transited legitimate Microsoft infrastructure is easier to dismiss than a DMARC fail from an entirely unknown source. Attackers know this. Routing through M365 Groups, Exchange Online Protection, or similar high-trust relays is a deliberate strategy to reduce the weight of authentication failures in automated scoring.

Train your users on more than just hovering. The hover-to-check habit is valuable but insufficient when the immediate destination is a legitimate Google domain masking the actual payload. For phishing simulation programs, testing against this class of redirect-wrapped lure reveals whether your user population recognizes the difference between an expected service URL and a proxied redirect chain.

Indicators of Compromise

Type	Indicator	Context
URL	`hxxps://breakfast881-saccessful-dpdns-org.translate[.]goog/?_x_tr_hl=zh-CN&_x_tr_sl=auto&_x_tr_tl=mr`	Malicious Google Translate proxy URL
Domain	`dpdns[.]org`	Attacker-registered infrastructure, created 2025-03-13
Domain	`saccessful-dpdns[.]org`	Phishing kit subdomain (NXDOMAIN, proxied via Google Translate)
Sender	`ptwmihaf462@hotmail[.]com`	Free webmail sender account used in campaign
Display URL	`h[ZWSP]tt[ZWSP]p[ZWSP]s[ZWSP]//[ZWSP]:www.[ZWSP]u[ZWSP]s[ZWSP]p[ZWSP]s[ZWSP].[ZWSP] c[ZWSP]o[ZWSP]m[ZWSP]/Update_Address`	Zero-width characters injected throughout
Nameservers	`ns1.digitalplat[.]org`, `ns2.digitalplat[.]org`, `ns3.digitalplat[.]org`	Infrastructure used by dpdns.org
---

The Mimecast Wrapper That Made a Phishing Link Look Safe

apaxson@ironscales.com (Audian Paxson) — Tue, 07 Apr 2026 20:46:23 GMT

TL;DR A credential phishing email impersonating a Dallas law firm used a one-day-old lookalike domain, crlaws.cam, to harvest credentials from a recipient at a major financial institution. The attack's defining feature was its trust chain: every malicious REVIEW button routed through Mimecast SafeLinks rewriting, leading the recipient to believe the URL had been scanned and cleared. A fake 'Powered by Microsoft Securely' badge added a second false legitimacy signal. Upstream SPF, DKIM, and DMARC all passed at the Mimecast relay stage. The lookalike domain went NXDOMAIN before full analysis could run, a hallmark of disposable phishing infrastructure.

Severity: High Credential Harvesting Impersonation Bec MITRE: {'id': 'T1566.002', 'name': 'Phishing: Spearphishing Link'} MITRE: {'id': 'T1036', 'name': 'Masquerading'} MITRE: {'id': 'T1078', 'name': 'Valid Accounts'}

The REVIEW button looked completely normal. It had the Mimecast wrapper on it, that long url.us.m.mimecastprotect.com prefix that security-conscious employees have been trained to associate with a scanned, vetted link. The email itself was marked High Importance, the subject line was "[EXTERNAL] Settlement Release," and the legal thread below the document panel referenced real case details and real organizations.

The destination behind that REVIEW button was crlaws.cam. Registered 22 hours before the email was sent. Pointing to nothing but air by the time analysis ran.

A Domain Built for One Job

WHOIS data tells a clean story. crlaws.cam was created on November 9, 2025 at 22:42 UTC via Namecheap, with nameservers at thcservers.com. The phishing email landed in the target's inbox on November 10. By the time forensic analysis attempted to resolve the domain, it had gone NXDOMAIN. The registry status shows clientHold, which is exactly what happens when a registrar flags and suspends a domain post-abuse.

The lookalike construction is straightforward but effective. The legitimate sender domain is cr.law. The phishing domain is crlaws.cam. The visual similarity is enough to pass a casual glance, and in the context of a Mimecast-rewritten URL, most recipients are not stopping to parse the destination domain character by character.

This is throwaway infrastructure, purpose-built for a 24-hour window.

What Mimecast Rewriting Actually Does (and Doesn't Do)

This attack's central technique is not the lookalike domain. It is the deliberate routing of the malicious link through Mimecast SafeLinks.

When Mimecast scans and rewrites a URL, it produces a link that looks like hxxps://url.us.m.mimecastprotect[.]com/s/...?domain=crlaws.cam. To a recipient, that prefix signals that Mimecast has touched the URL. Employees in organizations running Mimecast see these wrappers daily on legitimate email. The wrapper becomes a trust cue.

Attackers know this.

The Mimecast rewriting does not guarantee a clean destination. It means Mimecast evaluated the URL at the time of scanning. For a domain registered one day before the email was sent, the domain may have appeared benign at scan time, resolving to nothing harmful or nothing at all. The payload activates after delivery. By the time a recipient clicks, the domain is serving the credential harvesting page. By the time analysis runs, it is NXDOMAIN.

This is a timing attack on URL reputation systems. The gap between "scanned" and "clicked" is where the damage happens.

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

The Trust Stack: Two Layers of False Legitimacy

The email body used a two-layer trust construction.

The first layer was the Mimecast SafeLinks wrapper on every REVIEW button. Both buttons in the email carried Mimecast-rewritten URLs pointing to crlaws.cam. The recipient sees a familiar security gateway prefix and reasonably concludes the link has been evaluated.

The second layer was a fake "Powered by Microsoft Securely" badge inside the document panel. That is not a real Microsoft product name. There is no Microsoft service called "Microsoft Securely." It is a visual fabrication designed to invoke Microsoft brand trust for recipients using M365 environments. Combined with a generic Security PIN displayed in the panel, it mimics the visual pattern of legitimate SharePoint or OneDrive document-sharing notifications.

Both layers target the same cognitive shortcut: this email came through my security gateway and has Microsoft branding, so it must be legitimate. Neither signal actually validates safety. Together, they lower the recipient's guard precisely enough.

Authentication Passed. That Was Part of the Problem.

The relay chain for this email adds a layer of analytical complexity that works in the attacker's favor.

The message originated from the cr.law Microsoft 365 tenant, transited Mimecast, and arrived at the recipient's M365 environment. At the Mimecast relay stage, SPF, DKIM, and DMARC all passed cleanly. The sender domain cr.law has been registered since 2017, runs SPF with include:spf.protection.outlook.com -all, publishes a p=quarantine DMARC policy, and has an active DKIM selector.

At the recipient's M365 environment, SPF showed a fail for the Mimecast relay IP (170[.]10[.]128[.]131) because that IP is not in cr.law's SPF record. DKIM body hash verification also failed, which is expected when a security gateway rewrites links in transit. ARC (Authenticated Received Chain) passed, preserving the upstream authentication result.

This is the correct behavior for a Mimecast-relayed message. The SPF and DKIM failures at the recipient hop are expected artifacts of legitimate relay rewriting. The problem is that security systems treating ARC=pass as a trust signal will smooth over those downstream failures, which is exactly the outcome the attacker is counting on.

The pattern, combined with a first-time sender flag, is consistent with a compromised account on the cr.law side or a thread-hijack overlay. The legal thread content in the email body referenced real organizations and specific case context, giving the message an authenticity that is hard to fabricate from nothing. Themis flagged behavioral anomalies in the sender profile, including the first-time sender status and the newly registered destination domain behind the Mimecast wrapper, that the gateway passed without action.

What the Gateway Passed Over

The IRONSCALES detection model treats URL rewriting from a third-party gateway as a starting point for analysis, not an endpoint. For this email, the behavioral signals were clear:

First-time sender to the recipient mailbox, flagged high risk
Destination domain registered the previous day, visible through URL expansion of the Mimecast wrapper
NXDOMAIN resolution on crlaws.cam during analysis, indicating disposable infrastructure
Fake brand impersonation in the email body ("Powered by Microsoft Securely")
High-importance flag on an unexpected document request

No individual signal here is a slam dunk. A first-time sender from a law firm is plausible. A newly registered domain could be coincidence. But the combination, evaluated in real time against behavioral baselines across the IRONSCALES platform, produced a high-confidence phishing verdict. The email was automatically resolved as phishing without requiring manual SOC intervention.

Defending Against Trust Chain Manipulation

URL rewriting does not equal URL vetting. Every security team needs to internalize that distinction, and it needs to be a standing part of security awareness training for any organization running a gateway that rewrites links.

Specific recommendations from this case:

Treat gateway-wrapped URLs as unverified until analyzed. The wrapper tells you the gateway touched the URL. It does not tell you the destination is safe, especially for URLs wrapped at delivery and clicked hours later.
Configure post-delivery URL analysis. Static scan-at-delivery is not sufficient for fast-TTL attacker infrastructure. Time-of-click analysis, which evaluates the destination when the user actually clicks, catches domains that activate after delivery.
Flag first-time sender plus newly registered destination as a combined signal. Either alone is weak. Together they are a strong indicator, particularly when the destination domain is less than 48 hours old.
Train recipients to parse the destination domain in Mimecast URLs. The ?domain= parameter in Mimecast-wrapped links reveals the actual destination. A one-character lookalike domain (crlaws.cam vs. cr.law) is visible to anyone who looks. Most do not look.
Investigate authentication anomalies in relay chains. ARC=pass plus SPF fail plus DKIM body hash fail is a normal signature for legitimate gateway-relayed email. It is also a normal signature for attacker-leveraged gateway trust. Layered behavioral analysis is required to separate the two.

For financial services organizations handling inbound legal correspondence, the combination of high-importance flagging, settlement or invoice language, and embedded document review panels should trigger additional scrutiny. Attackers target exactly the workflows where speed and compliance create pressure to click first and verify later.

Indicators of Compromise

Type	Indicator	Context
Domain	`crlaws[.]cam`	Lookalike of `cr.law`, attacker-controlled credential harvesting infrastructure
URL	`hxxps://url.us.m.mimecastprotect[.]com/s/LCDxCmZkGps2ywyNCGfECRT--E?domain=crlaws.cam`	Mimecast-wrapped REVIEW button pointing to lookalike domain
IP	`170[.]10[.]128[.]131`	Mimecast relay IP (us-smtp-inbound-delivery-1.mimecast.com), appearing in SPF fail at recipient
Nameserver	`NS1.THCSERVERS[.]COM`	Attacker nameserver infrastructure for `crlaws.cam`
Email header	`X-Priority: 1`	High-importance flag used to create urgency
Subject	`[EXTERNAL] Settlement Release`	Social engineering lure, legal context

MITRE ATT&CK: T1566.002 Spearphishing Link, T1036 Masquerading, T1078 Valid Accounts

Sources: IRONSCALES platform analysis; Verizon 2024 DBIR (74% of breaches involve human element, phishing remains primary initial access vector); Microsoft Digital Defense Report 2024 (AiTM and trusted intermediary abuse increasing); FBI IC3 2024 Internet Crime Report (BEC losses exceeding $2.9 billion); CISA Phishing Guidance; MITRE ATT&CK

The Button Text Was the Weapon: Unicode RTL Obfuscation Inside a DocuSign Lure

apaxson@ironscales.com (Audian Paxson) — Sun, 05 Apr 2026 13:00:00 GMT

TL;DR A credential-harvesting campaign combined two underappreciated evasion techniques: Unicode right-to-left (RTL) marks (U+200F) embedded inside the clickable button text itself, and Constant Contact tracking infrastructure used as the first redirect hop to present a trusted domain to URL scanners. The email impersonated DocuSign using a DocuSign-style template, but linked to a Turkish-hosted harvest page at sync.bursatasdunyasi[.]com whose TLS certificate did not match its hostname. The sender domain passed DMARC via DKIM alignment, sent through Amazon SES, suggesting a compromised or abused marketing workflow. Themis flagged the campaign with 89% confidence on credential theft and VIP recipient risk signals.

Severity: High Credential Harvesting Phishing Brand Impersonation MITRE: {'id': 'T1566.002', 'name': 'Phishing: Spearphishing Link'} MITRE: {'id': 'T1027', 'name': 'Obfuscated Files or Information'} MITRE: {'id': 'T1036', 'name': 'Masquerading'}

The button said "REVIEW DOCUMENT." It looked exactly right. The color, the layout, the DocuSign branding, the fake security code in the footer. Nothing was visually off.

But embedded inside the button label text were dozens of Unicode right-to-left marks (U+200F), invisible to the human eye and devastating to the NLP pipelines that parse email content for threat signals. The string that rendered as clean English to every reader was a scrambled mess of zero-width control characters to every automated scanner trying to classify it.

That was only the first layer.

What the Scanner Saw at the Link

The CTA button resolved to cmopv9hbb.cc.rs6.net, a Constant Contact tracking domain. To most URL reputation engines, that URL is fine. Constant Contact is a legitimate email marketing platform used by thousands of companies. The domain has a long history. It's on nobody's blocklist.

That's exactly why attackers use it.

The Constant Contact redirect existed solely to absorb the first inspection. Behind it, the actual destination was sync.bursatasdunyasi[.]com, a subdomain hosted on IP 78[.]135[.]106[.]170 in Turkey. The PTR record for that IP resolves to west.ajansay.com, a web services provider. The TLS certificate presented by the server did not match the hostname. Standard browsers would flag this as an error. Most automated link scanners following the chain would already have marked the upstream hop as trusted and moved on.

A second redirect variant was also present in the same email body, routed through Mailjet tracking infrastructure (10o9o.mjt.lu/lnk/...) with the destination base64-encoded in the URL path. Same harvest endpoint. Two marketing platform redirect chains, two trusted first hops, one credential page waiting at the end.

See Your Risk: Calculate how many phishing emails your gateway is missing each month

The Unicode Obfuscation Technique (and Why It Works Here)

Unicode obfuscation is not a new concept. Security teams have known about homoglyph attacks (substituting visually similar characters from other scripts) for years. What this campaign did differently is worth a closer look.

The RTL marks were not in the domain name. Not in the URL path. Not in the sender address. They were inside the button label text rendered to the recipient.

Every character in "REVIEW DOCUMENT" had a U+200F right-to-left mark injected after it. From the HTML source: R‏E‏V‏I‏E‏W‏ ‏D‏O‏C‏U‏M‏E‏N‏T‏. The rendered output is visually identical. The string an NLP classifier receives is not.

This technique maps to MITRE ATT&CK T1027 (Obfuscated Files or Information). The target is not a human's eyes, it's the feature extraction layer of a machine learning model. By fragmenting the token boundary, the attacker reduces the probability that the classifier matches the string against known phishing phrases like "REVIEW DOCUMENT" with high confidence.

The same technique extended beyond the button. Nearly every text string in the email body, from the subject line to the footer disclaimer to the DocuSign boilerplate, was saturated with RTL marks. The body text that read "Confirm your disbursement details" was the same interleaved pattern. The attacker applied it uniformly, not just to the CTA.

The Authentication Paradox

The email passed DMARC. Not with a soft alignment or a policy override. A clean dmarc=pass on bigpineconsultants.com, backed by a valid DKIM signature. Amazon SES eu-west-1 sent it. SPF for the MAIL FROM subdomain was none, but DMARC authenticated on DKIM alignment, which is valid.

This is worth dwelling on. The organization whose domain was used had done everything right: M365 MX records, strict SPF with -all, active DKIM selectors, DMARC at p=reject. Their email infrastructure was properly configured. The evidence points to a compromised marketing automation workflow or an abused SES integration, not a spoofed domain. The attacker sent through authorized infrastructure.

This is the scenario your DMARC management tools are not built to catch, because the sending was authorized. DMARC tells you the domain is who it says it is. It cannot tell you the domain's marketing automation was hijacked.

The identity mismatch that did surface was in the content: the From address belonged to one US-based consulting firm while the email signature claimed a UK engineering company, including a real UK phone number and a forwarded internal email thread used as legitimacy padding. Two real organizations, neither of them the attacker, stitched together into one convincing wrapper.

The Attack Chain, Step by Step

This campaign used MITRE ATT&CK T1566.002 (Spearphishing Link) as the primary delivery technique, with T1036 (Masquerading) covering the DocuSign brand spoofing.

Delivery: Email sent via Amazon SES using a DMARC-passing domain, routed through Microsoft EOP into the target's M365 mailbox.
Social engineering: DocuSign-style HTML template with settlement/MOU subject line. Recipient's email address displayed inside the email body to personalize the lure.
Obfuscation: RTL marks (U+200F) injected into every text string in the email body, including the CTA button label.
First redirect hop: CTA resolves to Constant Contact tracking URL (cc.rs6.net). TLS mismatch at this hop already signals the final destination.
Second redirect hop (Mailjet variant): Base64-encoded destination embedded in Mailjet tracking URL provides a parallel delivery path with identical destination.
Harvest page: sync.bursatasdunyasi[.]com presents a bot-gate interstitial ("verify you are human"), consistent with credential harvest pages that filter automated sandbox traffic before presenting the actual form.
Infrastructure anchor: Domain registered 2018 via Turkish registrar Isimtescil Bilisim A.S., nameservers under ajansay.com. Aged domain reduces new-registration heuristic penalties.

Themis flagged the campaign at 89% confidence on credential theft, correlating the first-time sender status, malicious link behavior, and community signals from similar incidents across the IRONSCALES customer base. The email was automatically resolved as phishing and mitigated across affected mailboxes within 48 hours of delivery.

What to Do With This

According to the Verizon 2024 Data Breach Investigations Report, 74% of breaches involve the human element, with phishing and credential theft as primary vectors. The techniques in this campaign were designed to neutralize both automated defenses and human recognition simultaneously. That combination is the actual threat model.

Three things this case illustrates for security teams:

Follow the full redirect chain. URL reputation on the first hop is not sufficient. Constant Contact, Mailjet, and other legitimate ESP redirect domains are regularly abused as laundering infrastructure. Your link inspection needs to resolve the final destination, not stop at the first trusted domain.

Parse for control characters in display text. Unicode RTL marks in button labels and body text are inspectable. NLP models that do not account for zero-width character injection in their feature pipelines will assign lower confidence to well-known phishing phrases. This is a known, correctable gap.

DMARC pass is not a clean bill of health. A message can be authenticated and malicious at the same time. Credential harvesting protection that relies on authentication results as a positive signal will miss this class of attack. Layer behavioral analysis and link-chain inspection on top of authentication, not instead of it.

The IBM 2024 Cost of a Data Breach report puts the average breach cost at $4.88 million, with phishing-initiated incidents carrying some of the highest remediation costs due to dwell time and credential reuse (IBM, 2024). The cost of catching this email before any credentials were entered: zero.

---

Indicators of Compromise

Type	Indicator	Context
Domain	`bursatasdunyasi[.]com`	Harvest infrastructure, Turkish-hosted
Subdomain	`sync.bursatasdunyasi[.]com`	Credential harvest endpoint
IP	`78[.]135[.]106[.]170`	Hosting IP, Turkey (PTR: west.ajansay[.]com)
URL	`hxxps://cmopv9hbb.cc[.]rs6[.]net/tn.jsp?...`	Constant Contact first-hop redirect
URL	`hxxps://10o9o.mjt[.]lu/lnk/AcUAACKe6kA...`	Mailjet second-hop redirect (base64 destination)
Sending IP	`54[.]240[.]3[.]21`	Amazon SES eu-west-1
Domain	`bigpineconsultants[.]com`	Sending domain (DMARC-passing, likely compromised workflow)
Unicode	`U+200F` (RIGHT-TO-LEFT MARK)	Injected between every character in button label and body text

The Email That Shipped With Its Template Tokens Still In It (And Still Worked)

apaxson@ironscales.com (Audian Paxson) — Sat, 04 Apr 2026 11:00:00 GMT

TL;DR A phishing campaign targeting a finance team arrived with broken mail merge tokens literally visible in the subject line. Despite this, the email passed SPF, DKIM, and Microsoft EOP with a spam confidence level of 1. The attack used a cloned Oracle NetSuite voicemail template, a sender domain borrowed from a legitimate nonprofit via Amazon SES, and a 5-hop redirect chain running through Wix, MailerSend, Mailjet, and a 27-day-old domain before hitting a geo-gated 403. Themis flagged the malicious link and quarantined across four mailboxes. The lesson: authentication checks say nothing about intent, and redirect chains built from legitimate email infrastructure are specifically designed to outlast scanner timeout windows.

Severity: High Credential Harvesting Phishing MITRE: {'id': 'T1566.002', 'name': 'Phishing: Spearphishing Link'} MITRE: {'id': 'T1036', 'name': 'Masquerading'} MITRE: {'id': 'T1583.001', 'name': 'Acquire Infrastructure: Domains'}

The subject line read: Important VN ##NUMRANDOM5## - ##DATE##.

Not a substitution. Not a rendered value. The raw template tokens, exactly as they appear in the attacker's campaign builder, shipped to every recipient. The mail merge failed. The attacker either didn't notice or didn't care, hit send anyway, and the email landed in the finance team's inbox.

Microsoft Exchange Online Protection scored it a 1 on the spam confidence scale. Not spam. Not suspicious. Delivered.

What the Finance Team Actually Saw

The body looked like an Oracle NetSuite notification. Microsoft logo colors at the top (the colored tile grid), an Oracle NetSuite wordmark in the dark footer, a legitimate-looking address in Austin. The heading said: "Here Is The Important Voice Mail You Just Received."

The salutation: "Dear Finance."

Not a name. Not a role. The word "Finance," addressed to a team distribution alias. The message said a voicemail had been delivered by "Ironscales Voip service" on 6/11/2025, duration 1:44. There was a teal button labeled PLAY NOW.

A few things were off to a careful reader. The typos: "voicing mailbox" instead of "voice mailbox," "Durationn" with two n's. The fact that Oracle NetSuite does not deliver voicemails. The fact that the subject line was visibly broken. But finance teams process dozens of automated notifications daily, and this one had the right visual weight: corporate template, branded footer, a specific duration timestamp, an urgent action prompt. The "PLAY NOW" button is exactly the kind of thing that gets clicked in a busy queue.

The Infrastructure Behind the Button

The PLAY NOW button pointed to a free Wix subdomain (david42511[.]wixsite[.]com). From there, the redirect chain ran four more hops before resolving to anything definitive.

Hop 1: Wix subdomain. Free hosting, frequently abused for phishing staging, legitimate domain reputation. Hop 2: y7zpl9811m345vx6[.]click[.]mailersend[.]net — MailerSend click tracker. A legitimate transactional email platform's tracking infrastructure. Hop 3: 10vv6[.]mjt[.]lu — Mailjet tracking hop. Another legitimate email service provider's redirect. Hop 4: backup[.]dapteknik[.]com — the penultimate destination. Domain registered March 10, 2025. Twenty-seven days old at the time of delivery. Turkish registrar, unsigned DNSSEC, no registrant data, nameservers pointing to ajansay[.]com. Nothing about this domain belongs near an Oracle NetSuite notification. Hop 5: host[.]com — a 403. Geo-gated or user-agent filtered. Automated scanners see a dead end. Real victims in the right geography with the right browser get the payload.

This is the architecture of scanner evasion. Each of the first three hops is a platform with genuine domain reputation. URL reputation checks see MailerSend and Mailjet and pass. By the time the chain reaches the young, unregistered-looking domain at hop 4 and the gated 403 at hop 5, any scanner that followed the chain has already timed out or given up. The payload never had to reveal itself to any automated system.

See Your Risk: Calculate how many phishing emails your gateway is missing right now

Authentication Passed. That Was Never the Problem.

The sender was beth@newdayranch[.]org, a nonprofit organization's domain, routed through Amazon SES. SPF passed because SES is a permitted sender for the domain. DKIM passed with valid signatures for both newdayranch.org and amazonses.com. DMARC was not published at all (_dmarc.newdayranch.org returned NXDOMAIN), so EOP defaulted to a best-guess pass with no enforcement action.

The email was technically legitimate from a transport perspective. The delivery path was: Amazon SES in us-west-2, to Microsoft EOP, to internal Exchange Online transports, to the recipient mailboxes. TLS 1.3 the whole way. Clean relay chain.

This is the authentication gap that practitioners run into constantly. SPF tells you whether the sending server is authorized by the domain owner. DKIM tells you the message wasn't tampered with in transit. Neither tells you anything about whether the person controlling that domain intends to phish your employees. A compromised nonprofit account, or one set up specifically to abuse SES at low volume, passes every authentication check cleanly. According to the Verizon 2024 Data Breach Investigations Report, phishing remains a top initial access vector specifically because attackers have adapted to authentication controls, not because those controls don't work.

The Microsoft Digital Defense Report 2024 makes the same point: high-volume phishing campaigns increasingly route through legitimate cloud email infrastructure to inherit trusted reputation scores. The message in this case scored SCL:1. That is one step above absolute zero on EOP's confidence scale.

What Caught It

Themis flagged the PLAY NOW link at 90% confidence, labeled it Credential Theft, and noted the VIP Recipient signal (the finance distribution alias). IRONSCALES quarantined the email across four mailboxes. The first quarantine action happened roughly 30 minutes after delivery. All four were resolved the same day.

No one clicked the button. Or if they did, the quarantine happened before the credential page loaded.

The detection relied on behavioral signals and community intelligence, not on the redirect chain resolving to something identifiable. Across the IRONSCALES platform's global community of over 35,000 security professionals, the structural pattern of stacked click-tracker hops ending on a young, privacy-shielded domain had already been flagged in similar incidents. The community signal combined with link behavior analysis is what the IRONSCALES Adaptive AI engine uses to evaluate threats that authentication and static URL reputation checks can't reach.

The Broken Template Problem

The unreplaced tokens deserve a moment. ##NUMRANDOM5## and ##DATE## are placeholder syntax from whatever campaign tool the attacker was using. The template engine failed to substitute them before the batch fired. This is the kind of error that occasionally gets used as evidence that phishing campaigns are easy to spot.

It is not evidence of that.

The email still passed every authentication control. It still got a benign spam score. It still had polished visual design with real brand assets. The only thing the broken tokens reveal is that the attacker is running campaigns at scale, using templating infrastructure to randomize subjects and dates across thousands of sends. The failed substitution is a production error, not a competence indicator. According to the FBI IC3 2024 Internet Crime Report, BEC and phishing losses exceeded $2.9 billion last year. Those campaigns were not stopped by visible typos.

A defender who sees ##NUMRANDOM5## in a subject line and thinks "obvious, caught it" is correct exactly once. The same campaign template, working correctly, would have shipped a numeric string and a date. It would have looked like every other voicemail notification in the queue.

IOCs

Type	Indicator	Context
Domain	`dapteknik[.]com`	Penultimate redirect destination. Registered 2025-03-10, Turkish registrar, no registrant data
Subdomain	`backup[.]dapteknik[.]com`	Direct link target at hop 4 of redirect chain
URL	`hxxps://david42511[.]wixsite[.]com/so/96PfQFT_U/c`	Initial PLAY NOW button destination, Wix-hosted redirect
URL	`hxxps://y7zpl9811m345vx6[.]click[.]mailersend[.]net/tl/cws/[...]`	MailerSend click tracker, hop 2
URL	`hxxps://10vv6[.]mjt[.]lu/lnk/[...]`	Mailjet tracking hop, hop 3
Sender domain	`newdayranch[.]org`	Legitimate nonprofit domain used as sending envelope; SPF/DKIM pass
Sending IP	`54[.]240[.]27[.]209`	Amazon SES us-west-2 egress; PTR resolves to expected SES hostname

What to Do With This Pattern

The five-hop tracker chain is not exotic. It is a repeatable evasion template that attackers assemble from publicly available, free-tier services. Any combination of Wix, SendGrid, MailerSend, Mailjet, and a freshly registered parking domain can produce this structure in an afternoon.

Three things to evaluate in your environment:

Domain age as a signal. A 27-day-old domain in a redirect chain should trigger escalated scrutiny regardless of what the earlier hops look like. If your email security stack is not factoring domain registration recency into link scoring, you are missing a high-signal indicator. The IRONSCALES advanced URL protection layer evaluates this as part of multi-signal link analysis.

DMARC enforcement gaps. The sending domain had no DMARC record at all. NXDOMAIN on the _dmarc subdomain means there is no policy to enforce and no reporting to learn from. DMARC absence is not a blocker for mail delivery. It is a gap that reduces your visibility into abuse of domains that are routing through your trust perimeter. IRONSCALES DMARC management provides visibility and enforcement across sender domains in your ecosystem.

Voicemail lures going to group aliases. A phishing email addressed generically to "Finance" and delivered to a distribution alias is not spear phishing. It is spray phishing with brand impersonation. The fact that it hit a finance alias specifically, one that presumably receives legitimate Oracle NetSuite notifications, suggests some degree of targeting. Security awareness training that includes voicemail lure simulations helps finance and accounting teams build the skepticism reflex before the real version arrives.

The broken tokens were an accident. The landing was not.

SPF Passed. DMARC Passed. DKIM Didn't. What That Combination Actually Means.

apaxson@ironscales.com (Audian Paxson) — Fri, 03 Apr 2026 17:00:00 GMT

TL;DR A business email compromise attempt targeting a finance administrator at a regional public utility authority passed SPF and DMARC but failed DKIM body-hash verification, indicating the message body was modified after the original sender signed it. The attack impersonated a financial analyst at a legitimate hedge fund and requested ACH routing details and a signed W-9 under the guise of supplier onboarding. A branding mismatch in an embedded attachment added further suspicion. Most email security tools treat SPF and DMARC pass as sufficient; the DKIM body-hash failure, which signals in-transit tampering, went unrecognized by every gateway in the relay chain. IRONSCALES flagged the behavioral risk and quarantined the message across four mailboxes.

Severity: High Bec Impersonation MITRE: {'id': 'T1566.001', 'name': 'Spearphishing Attachment'} MITRE: {'id': 'T1534', 'name': 'Internal Spearphishing'} MITRE: {'id': 'T1586.002', 'name': 'Compromise Accounts: Email Accounts'}

The email looked like a routine supplier onboarding request. A financial analyst at a well-known investment firm had already exchanged several messages with a finance administrator at a regional public utility authority. The thread had a real subject line, real reply history, and a real Point72 signature block with a Stamford, CT address and direct phone numbers. The request: complete a W-9 form and provide ACH banking instructions for direct deposit setup.

SPF passed. DMARC passed. Every gateway in the relay chain gave it a green light.

The DKIM body-hash verification failed. That single data point told a different story.

When the Cryptographic Seal Breaks

DKIM works by signing a cryptographic hash of the message body at the moment of send. The signing server hashes the content, encrypts that hash with its private key, and embeds the signature in the message headers. When the receiving server evaluates the message, it recalculates the body hash from the content it received and compares it against the decrypted signature.

If they match, the body is intact. If they don't, something changed the content after it was signed.

In this incident, the ARC-Authentication-Results header at the final Microsoft Exchange hop showed dkim=fail (body hash did not verify) header.d=point72.com. Separately, the ARC chain reported cv=fail, meaning the chain of authenticated forwarding hops was broken. These two results together are not ambiguous: the message body that arrived at the recipient was not the message body that was originally signed by the Point72 mail infrastructure.

The relay chain ran through Proofpoint (mx0a-001f6201.pphosted.com at 148.163.157.251, permitted by Point72 SPF), then through Barracuda ESS (outbound-ip77a.ess.barracuda.com at 209.222.82.241), then through Microsoft Exchange Online frontend infrastructure before reaching the recipient's M365 mailbox. Multiple security gateways handled this message. At least one of them modified the body.

The BEC Payload Inside the Authentic Shell

The social engineering underneath the authentication anomaly was well constructed. The attacker (or a modified relay message acting on behalf of a compromised account) presented as a financial analyst in an estate management role at a legitimate hedge fund. The email thread had prior message references and realistic in-reply-to chains. The request followed an established vendor onboarding pattern: complete a W-9 in locked PDF format, provide ACH banking instructions on company letterhead or signed by an authorized officer, with the beneficiary name matching the invoice remit-to name.

This is textbook business email compromise. According to the FBI's 2024 Internet Crime Report, BEC losses exceeded $2.9 billion in the United States alone, with invoice and payment fraud representing the most consistent attack pattern across industries (FBI IC3, 2024 Internet Crime Report). The finance administrator targeted here was the Assistant to the CFO, a role with access to payment processes and vendor onboarding authority. Targeting was not accidental.

One additional anomaly surfaced in the attachment: an embedded PNG file carried branding from the recipient organization, not the sender. A SCWA (the target utility) logo appeared inside an email ostensibly from a Point72 financial analyst. That kind of branding mismatch can indicate a prior communication was harvested and repurposed, or that the attacker had access to prior correspondence and assembled this message from components of earlier legitimate exchanges.

The Verizon 2024 DBIR found that 68% of breaches involved a human element, and social engineering attacks on finance personnel consistently rank among the highest-impact entry points (Verizon DBIR, 2024). An Assistant to the CFO receiving a plausible onboarding request from a known counterparty with a reply thread is a scenario where human verification instincts are actively suppressed by apparent legitimacy.

See Your Risk: Calculate how many BEC attempts your current gateway is missing

What Every Gateway in the Chain Missed

Here is the authentication picture that each security gateway evaluated:

SPF: PASS. The sending IP (148.163.157.251) was authorized by point72.com's SPF record.
DMARC: PASS. The visible From header aligned with the SPF-passing domain.
DKIM: FAIL (body hash did not verify).

SPF checks that a sending server is permitted to send on behalf of a domain. It says nothing about message content. DMARC checks that the visible From address aligns with either a passing SPF or DKIM result. In this case, DMARC passed on the strength of SPF alone, since DKIM failed. Neither SPF nor DMARC provides any guarantee that the message body is what the original sender wrote.

Most security gateways are configured to accept messages that pass DMARC. That is a defensible default in the aggregate. But for high-risk request types (any email requesting banking details, ACH routing, wire instructions, or tax documents), DKIM body-hash failure should trigger an additional review layer, not a pass.

The MITRE ATT&CK framework categorizes this pattern under T1566.001 Spearphishing Attachment and, where relay compromise is the vector, intersects with T1534 Internal Spearphishing and T1586.002 Compromise Accounts. When the body-hash failure results from a compromised intermediate relay, the attacker never needs to spoof the sender domain at all.

Themis flagged the behavioral risk here based on the combination of signals: the payment request pattern, the DKIM/ARC failure, the branding mismatch in the attachment, and the recipient's financial role. The message was quarantined across four mailboxes before any user acted on the ACH request.

Indicators of Compromise

Type	Indicator	Context
Domain	`point72[.]com`	Legitimate sender domain; DKIM body-hash failed on transit
IP	`148[.]163[.]157[.]251`	Proofpoint relay; SPF-authorized for point72.com
IP	`209[.]222[.]82[.]241`	Barracuda ESS gateway in relay chain
File	`image001[.]png` (MD5: `8fa9fd9c37baedc913adb082c86473e2`)	Embedded PNG; branding mismatch (recipient org logo in sender email)
Auth result	`dkim=fail (body hash did not verify) header.d=point72[.]com`	Body altered after original signing
Auth result	`ARC cv=fail`	ARC chain integrity broken across forwarding hops

The Right Response to a Broken Seal

Authentication failures on payment requests deserve a different response than authentication failures on marketing emails.

When DKIM body-hash verification fails on an email requesting financial information, the correct posture is: treat the body content as unverified. Call the requester at a number obtained from official sources, not from the email. Do not use phone numbers embedded in the message or in the reply chain. Do not forward the banking instructions request to a colleague before completing that verification.

For security teams, a few changes to detection posture help:

Tag DKIM body-hash failures on payment-related emails for human review. DMARC pass is not sufficient for financial action items.
Monitor for ARC cv=fail in combination with high-risk request patterns. The two together are a strong indicator that body content cannot be trusted as original.
Treat attachment branding mismatches as a secondary signal. When the embedded graphics in an email belong to a different organization than the sender, something in the message construction is off.
Ensure DMARC management policies include alerting on body-hash failures, not just alignment failures. Most DMARC implementations are configured to alert on authentication failures that affect deliverability. DKIM body-hash failures may not trigger those alerts if DMARC still passes on SPF.

The Microsoft Digital Defense Report 2024 noted that business email compromise remains one of the most financially damaging threat categories, with attackers increasingly relying on legitimate infrastructure and authentication chain ambiguity to evade detection (Microsoft Digital Defense Report 2024). This case is a precise example of that pattern: a message that passed every policy-based check except the one that actually verifies content integrity.

The IBM 2024 Cost of a Data Breach Report puts the average BEC-related breach cost at levels that make out-of-band verification a very cheap countermeasure by comparison (IBM Cost of a Data Breach Report 2024). One phone call to a known contact number would have closed this attack entirely.

The Payload Was a Phone Number: How a Google Calendar Invite Weaponized Vishing

apaxson@ironscales.com (Audian Paxson) — Fri, 03 Apr 2026 15:00:00 GMT

TL;DR A threat actor registered scoolsd[.]com on the morning of March 17, 2026, spun up a Google Workspace account, and sent a Google Calendar invite to an employee at a mid-size technology company. The invite described a fake $399.77 'CoreDefense Plus' charge and instructed the recipient to call a toll-free number to dispute it. Every link in the email resolved to calendar.google.com and scanned clean. The .ics attachment had no executable payload. DKIM passed because Google signed the message from its own infrastructure. The only indicator of compromise was a phone number. Themis flagged it based on the newly-registered domain and behavioral anomalies in the invite content.

Severity: High Vishing Phishing Social Engineering MITRE: {'id': 'T1566.001', 'name': 'Spearphishing Attachment'} MITRE: {'id': 'T1598', 'name': 'Phishing for Information'} MITRE: {'id': 'T1204', 'name': 'User Execution'}

The email arrived on a Tuesday afternoon and looked, at a glance, like every other Google Calendar notification. A meeting invite. A subject line referencing a transaction. RSVP buttons. The Google logo at the top.

Below the invitation metadata was a billing notice: "CoreDefense Plus" renewed, $399.77 charged. "If you didn't make this purchase... call our customer care representative (808)-321-8085 (Toll Free)."

No link to a phishing page. No malicious attachment. No credential harvest form. The entire payload was a phone number.

When the Attack Surface Is Your Calendar

The security team's stack had no technical artifact to flag. The links in the email resolved to calendar.google.com and scanned clean. The .ics attachment contained no executable code, no embedded URLs, no alarm actions fetching external resources. Attachment sandboxes gave it a clean verdict. URL reputation engines had nothing to analyze.

DKIM passed. Google signed the outbound message from its own mail infrastructure, as it does for any Google Workspace account. That signature confirms Google sent the message. It says nothing about whether the sender's domain is legitimate.

The domain it came from, scoolsd[.]com, had been registered a few hours before the email was sent. Created March 17, 2026, same day as the attack. Registered through Hosting Concepts B.V. via Registrar.eu, privacy-protected, DNSSEC unsigned. No SPF record published, so the authentication result for the return-path was spf=none. No reputation. No history.

None of that registered in URL scan results, because there were no URLs to scan.

The Script Behind the Call

Callback phishing, also called Telephone-Oriented Attack Delivery (TOAD), has been a growing share of the vishing (voice phishing) threat landscape. According to the FBI's 2024 Internet Crime Report, BEC (Business Email Compromise) and related fraud cost U.S. businesses over $2.9 billion in reported losses, with phone-based social engineering a significant and undercounted contributor (FBI IC3 2024).

The model is straightforward. The attacker sends a notification that creates financial urgency, then waits for the victim to call. On the other end of the line is a live operator, or a convincing automated script, ready to socially engineer credentials, payment details, or remote access under the guise of "customer support."

In this case, the fake product name ("CoreDefense Plus") mimics legitimate antivirus software names well enough to be plausible. The charge amount ($399.77) is high enough to alarm but not so high as to seem implausible for a software renewal. The reference numbers and "Register Client UID" fields add just enough bureaucratic texture to look like a real receipt.

The organizer identity in the invite, "Twanette Cruz," has no verifiable presence tied to that domain. The email account (twanettecruz1003@scoolsd[.]com) was almost certainly created minutes before sending. The phone number is toll-free, making it cost-free to operate at scale.

See Your Risk: Find out how many threats like this your current security stack is missing

What Passed, What Flagged, and Why It Matters

This attack is specifically engineered to be invisible to the tools most email security stacks rely on.

URL reputation checks had nothing to evaluate. The only URLs in the email pointed to calendar.google.com. Sandbox detonation of the attachment found a clean .ics file. DKIM validation returned pass. SPF returned none, which many tools treat as inconclusive rather than suspicious.

Verizon's 2024 DBIR found that the human element is involved in 68% of breaches, and social engineering remains one of the top initial access techniques used by threat actors (Verizon DBIR 2024). Attacks like this one are designed to route around technical controls entirely and land directly in human psychology: you got charged $400 for something you didn't buy, here's the number to call.

The Microsoft Digital Defense Report 2024 also notes the growing use of legitimate cloud services as attack delivery infrastructure, precisely because those services have high reputation scores that defeat URL filtering (Microsoft Digital Defense Report 2024). Google Calendar is not a malicious service. That's the point.

Themis flagged this incident based on a combination of signals: the freshly-registered domain (scoolsd[.]com with a same-day creation date), the absence of any SPF policy, behavioral patterns in the invite content consistent with financial-urgency social engineering, and community-level confidence signals from similar incidents reported across the IRONSCALES platform. The confidence score came in at 66%, labeled as a vishing attack. The platform routed it for review rather than letting it sit in the inbox.

MITRE ATT&CK maps this to Spearphishing Attachment (T1566.001) for the .ics delivery vector, Phishing for Information (T1598) for the off-channel voice harvest, and User Execution (T1204) for the required victim action (calling the number). The attack chain is simple, which is part of why it works.

Indicators of Compromise

Type	Indicator	Context
Domain	`scoolsd[.]com`	Attacker-registered domain, created 2026-03-17
Email	`twanettecruz1003@scoolsd[.]com`	Attacker organizer account
Phone	`(808)-321-8085`	Vishing callback number in ICS DESCRIPTION
ICS Hash (MD5)	`849e769d4923a487f109e07aed005041`	invite.ics attachment

Closing the Gap That Wasn't on Your Map

The uncomfortable reality of zero-link vishing is that it doesn't fail against well-tuned URL filtering or a mature sandboxing solution. It doesn't need to. It bypasses them by design.

Defending against it requires a different set of controls. Domain age and reputation checks at the envelope level, not just for URLs. Behavioral analysis of calendar invite content, not just attachment sandboxing. Community intelligence that surfaces patterns across organizations, not just local telemetry. And user training that specifically addresses callback phishing scenarios, since this attack lives or dies on whether the recipient picks up the phone.

Security awareness training that covers TOAD and callback fraud scenarios is increasingly important as these attacks scale. The FBI's IC3 data shows the phone-based social engineering vector growing year over year, often targeting finance and accounting roles who are already primed to respond to billing and payment alerts. Vishing simulations that include the calendar-as-delivery-mechanism specifically would help build recognition before it matters.

Traditional email defenses are built around the assumption that attacks have a technical payload. A URL to block, a file to sandbox, a domain to blacklist. When the payload is a phone number buried in a calendar description, that assumption is wrong.

Across 1,921 organizations in the IRONSCALES customer base, the pattern of abusing legitimate cloud services for social engineering delivery, where the infrastructure is trusted even when the content is not, shows up consistently in callback phishing campaigns. The signal isn't always in the link. Sometimes it's in the domain registration date, the missing SPF record, and the phone number your employee is about to call.

When the Safety Wrapper Becomes the Disguise: Brazilian NF-e Phishing via Safe Links Rewrite

apaxson@ironscales.com (Audian Paxson) — Fri, 03 Apr 2026 13:00:00 GMT

TL;DR Attackers sent a convincing Portuguese-language NF-e (Brazilian electronic invoice) notification from a fully authenticated .com.br domain, embedding an is.gd shortener link that hid the real destination. Microsoft Safe Links rewrote the URL on delivery, replacing the suspicious shortener with a Microsoft-branded 'safelinks.protection.outlook.com' wrapper, making the attack look protected. The final landing page sat on emissao-br.org, registered just two days before delivery with privacy-shielded WHOIS and Cloudflare hosting. The email scored SCL 9 and was quarantined, but only after the URL rewrite chain was fully assembled and ready to deceive.

The email looked exactly like a routine accounts payable notification. Portuguese-language header, Brazilian invoice number, a total in Brazilian reais, a red "Acessar Documento Fiscal" button. For anyone who processes invoices from Brazilian suppliers, it was unremarkable. That was the point.

What the recipient at a U.S.-based steel and metals manufacturer actually saw when they hovered over that button was a nam12.safelinks.protection.outlook.com URL, Microsoft's own link-protection domain. The mental shortcut most people take is predictable: if Microsoft wrapped it, Microsoft checked it. This attack counted on exactly that assumption.

See Your Risk: Find out how many threats your current email setup is missing

The URL That Was Never in the Email

The original HTML embedded an is.gd shortener link as the CTA destination. is.gd is a free, public URL shortener with no vetting process and an effectively neutral reputation score with most email filters. The attacker's actual landing domain, emissao-br[.]org, appeared nowhere in the delivered email.

When Microsoft Safe Links processed the message in transit, it rewrote the is.gd URL following its standard behavior. The recipient received a fully Microsoft-branded safelinks URL. At click time, that URL would proxy through Microsoft's infrastructure, follow the is.gd redirect, and land on emissao-br[.]org.

The attack chain looked like this:

Attacker embeds hxxps://is[.]gd/PQjyJ3#0996615 in email HTML
Safe Links rewrites it to hxxps://nam12[.]safelinks[.]protection[.]outlook[.]com/?url=https%3A%2F%2Fis[.]gd%2FPQjyJ3...
Recipient sees a Microsoft-branded "protected" link
Click resolves is.gd shortener, which redirects to hxxps://emissao-br[.]org/nota-eletronica-emitida/?n=00730264.156604

Safe Links rewrites URLs to enable time-of-click scanning. But the shortener is the hinge point. Safe Links evaluated is.gd/PQjyJ3, not the final destination. The actual malicious domain stayed out of the scanner's view until click time, and the Safe Links wrapper gave the whole chain an air of legitimacy it had not earned.

This is MITRE ATT&CK T1027 (Obfuscated Files or Information) and T1566.002 (Spearphishing Link) working together. The obfuscation is not in a file or payload; it is in the URL architecture itself.

A Domain Born Two Days Before Delivery

emissao-br[.]org was registered on March 21, 2026. The email arrived on March 23, 2026. The domain was 48 hours old when it went live in this campaign.

WHOIS showed Dynadot as the registrar, Cloudflare nameservers (marty.ns.cloudflare.com, tricia.ns.cloudflare.com), and fully privacy-shielded registration with no registrant name, organization, or country. The domain had no email authentication records, no MX, no DMARC policy. It existed purely as a click destination.

The landing page served Brazilian-themed invoice content and prompted the visitor to download or open a PDF. The visual framing mimicked a document portal. No credential form at the surface layer, but the pattern is consistent with a multi-stage credential harvest: get the user to a download prompt, have the PDF contain a secondary redirect or a fake login form styled to match a document viewer.

Cloudflare hosting is standard attacker infrastructure practice. It proxies the real origin server's IP, absorbs DDoS mitigation, and provides HTTPS by default, making the domain look more legitimate to naive scanners. Combined with a two-day-old registration and privacy-shielded WHOIS, the domain had no observable threat history to flag.

Authentication Passed. The Account Was Still the Problem.

The sending domain, magazinepequim[.]com[.]br, is a registered Brazilian retail business, active since 2019. SPF passed, DKIM passed (signed via dkim.uni5.net), DMARC passed. compauth=pass with reason code 100. Microsoft's receiving infrastructure had no technical grounds to reject the message based on authentication alone.

The sender was a first-time contact for this recipient. The risk label on the sender record was high. That combination, authenticated but unknown and flagged, is a classic signal of a compromised account being used to phish targets with no prior relationship to the domain. The sending IP, 191[.]6[.]221[.]38, is part of Uni5's Brazilian SMTP infrastructure, consistent with a legitimate-but-abused Brazilian email hosting environment.

This is MITRE ATT&CK T1078 (Valid Accounts). The attacker did not spoof anything. They used a real account on a real domain that passes every authentication check. According to the Verizon 2024 Data Breach Investigations Report, 68% of breaches involve a human element, and credential theft from compromised accounts is the primary vector feeding into those statistics (Verizon DBIR 2024). When the account is already compromised, authentication gives you false confidence.

The SCL score hit 9, which is the maximum Microsoft spam confidence level. The message was quarantined. But the quarantine happened because of behavioral and heuristic signals, not because authentication flagged anything. A filtering posture that relies on authentication signals alone would have delivered this.

For reference, Secure Email Gateways (SEGs) as a category miss an average of 67.5 phishing emails per 100 mailboxes per month, according to IRONSCALES analysis of 1,921 organizations. Cases like this, where authentication passes cleanly and the malicious URL is hidden behind a shortener, are exactly the type that inflate that number. The IRONSCALES M365 augmentation layer operates post-delivery, analyzing behavioral signals that authentication-layer tools cannot see.

Indicators of Compromise

Type	Indicator	Context
Domain	`emissao-br[.]org`	Landing page, registered 2026-03-21, privacy-shielded WHOIS
URL	`hxxps://emissao-br[.]org/nota-eletronica-emitida/?n=00730264.156604`	Final landing page destination
URL	`hxxps://is[.]gd/PQjyJ3`	URL shortener link embedded in original email HTML
Sending Domain	`magazinepequim[.]com[.]br`	Compromised/abused Brazilian retail domain
Sending IP	`191[.]6[.]221[.]38`	Uni5 Brazilian SMTP infrastructure
Email Subject	`NF-e 0996615 gerada`	Portuguese-language invoice lure subject line

What This Attack Reveals About Trust Inheritance

The most interesting thing here is not the phishing itself. Invoice lures are common. Compromised sender accounts are common. Short-lived domains are common.

What is notable is how these three elements combine to exploit a specific trust model. The attacker built a chain where each hop borrows legitimacy from the previous one. A real authenticated domain loans credibility to the shortener. The shortener forces Safe Links to rewrite it. The Safe Links rewrite loans Microsoft's brand credibility to the final destination. Each link in the chain is unremarkable in isolation. Together, they manufacture trust.

The FBI IC3 2024 Internet Crime Report recorded over $2.9 billion in Business Email Compromise (BEC) losses, with phishing as the primary initial access vector (FBI IC3 2024). Cross-border lures, particularly those exploiting regional document standards like Brazil's NF-e system, add a layer of confusion for security teams not familiar with the format. An analyst who does not recognize NF-e as a Brazilian electronic invoice standard may not immediately flag Portuguese-language invoice content as suspicious.

The Microsoft Digital Defense Report 2024 notes that attackers are increasingly layering infrastructure specifically to defeat individual security controls, treating each layer of defense as a separate obstacle to route around (Microsoft Digital Defense Report 2024). This attack is a textbook example of that approach.

Themis flagged this via content and community intelligence signals, specifically the malicious link verdict and pattern match against similar community-reported incidents. The quarantine caught it. But the detection relied on post-delivery behavioral analysis, not the authentication chain, and not Safe Links' time-of-click scan returning a clean result for the shortener URL.

For organizations processing invoices from international suppliers, phishing simulation exercises that include multilingual lures and cross-border document formats are increasingly necessary. Security awareness training that only covers English-language phishing leaves a real gap when the threat is arriving in Portuguese, Spanish, or any other language your team may not default to scrutinizing.

The defensive takeaway is direct. For credential harvesting protection, the signal layers that matter are behavioral, not authenticative. A two-day-old domain behind a URL shortener, regardless of what authentication the sending account passes, should trigger additional scrutiny. Automated post-delivery scanning that follows redirect chains to their final destination, rather than stopping at the shortener, closes the specific gap this attack exploits. Safe Links rewriting a shortener URL is not the same as Safe Links checking the destination behind it.

Microsoft Bookings as a Weapon: When DMARC Says Trust Me and ARC Quietly Disagrees

apaxson@ironscales.com (Audian Paxson) — Fri, 03 Apr 2026 11:00:00 GMT

TL;DR Attackers weaponized Microsoft Bookings to deliver a convincing appointment confirmation to multiple employees at a U.S. government contractor. The email originated from legitimate Microsoft infrastructure, passing SPF, DKIM, and DMARC authentication. The ARC chain failed at hop 2, signaling non-standard routing that standard email gateways ignored. A divergent Reply-To address, an anomalous inline base64 image instead of a CDN-hosted asset, and first-time-sender behavioral signals together triggered automated mitigation across affected mailboxes. This case demonstrates that authentication pass is not the same as trust, and that behavioral anomaly detection is the last meaningful defense when legitimate infrastructure is turned against you.

Severity: High Phishing Impersonation Social Engineering MITRE: {'id': 'T1566.001', 'name': 'Spearphishing Attachment'} MITRE: {'id': 'T1566.002', 'name': 'Spearphishing Link'} MITRE: {'id': 'T1534', 'name': 'Internal Spearphishing'} MITRE: {'id': 'T1585.001', 'name': 'Establish Accounts: Social Media Accounts'}

The email looked exactly like a Microsoft Bookings appointment confirmation, because it was one. Sent from CSAMDCUnifiedOrientationBookings@bookings.microsoft.com. SPF passed. DKIM passed. DMARC passed. Every automated trust signal said: legitimate mail from Microsoft infrastructure.

Eight employees at a U.S. government IT contractor were CC'd on it. The booking was for a "Unified Operational Onboarding Session (1-Hour)" scheduled for a Tuesday afternoon. Teams join link, reschedule button, an INC reference number for added authenticity. Exactly the kind of vendor onboarding email that lands in a government contractor's inbox every week.

The attack didn't fail because of anything in the authentication chain. It got caught because of three quiet signals that most security tools never check.

The ARC Chain Break Nobody Was Looking For

Authenticated Received Chain (ARC) preserves authentication results across relay hops, especially when forwarding would otherwise break the original DKIM signature. Each intermediary adds its own ARC seal, building a chain the receiving server can validate end to end.

In this message, the ARC chain failed at hop 2.

ARC-Seal i=2 carried cv=fail. The second intermediary couldn't validate ARC records from hop 1. The receiving Exchange server logged it in the ARC-Authentication-Results header and delivered the message anyway, because SPF, DKIM, and DMARC had already passed.

ARC failure is not a hard block in most configurations. It hints that the message took an unusual path. In the context of a weaponized legitimate service, it is a meaningful signal. For most Secure Email Gateways (SEGs), it is invisible.

According to the Microsoft Digital Defense Report 2024, phishing attacks increasingly exploit trusted cloud infrastructure to bypass perimeter defenses. Microsoft Bookings, Calendly, DocuSign, and other scheduling and document platforms are all delivery vehicles now. The authentication chain validates the platform, not the intent behind its use.

Three Signals, None of Them in the Authentication Block

The ARC break was one signal. The other two were subtler.

The email's From field showed CSAMDCUnifiedOrientationBookings@bookings.microsoft.com. The Reply-To showed v-evereault@microsoft.com. Different address, different display context. Attackers use Reply-To divergence for one reason: when the target replies, the response goes somewhere the attacker controls, not back to the service that sent the notification. In a real Microsoft Bookings flow, the reply path would stay within the booked service's managed contact system. A divergent Reply-To is not technically invalid, but it is behaviorally anomalous.

The second signal was in the raw message body. Standard Microsoft Bookings emails reference assets from Microsoft's CDN. This one had an embedded inline base64 image in the raw HTML, which is not how Bookings generates confirmation emails. Inline base64 encoding avoids external URL calls that scanners would check. The image rendered fine in the email client. In the raw source, it was a fingerprint.

Neither of these signals would block the message on their own. Taken together with the ARC break and a first-time-sender flag across all eight targeted mailboxes, they formed a behavioral profile that didn't match legitimate Microsoft service mail.

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

Themis flagged the behavioral cluster. The affected mailboxes were automatically mitigated before any recipient could interact with the booking or the attached .ics calendar file.

The Calendar Attachment Is the Second Payload

The booking came with a booking.ics file. Calendar invites extend the attack surface beyond the inbox.

A malicious ICS can carry ATTACH parameters that pull remote resources when processed, ORGANIZER fields that differ from the displayed sender, or DESCRIPTION fields with obfuscated URLs. Auto-accept rules in enterprise calendars can silently add attacker-controlled events without user action. Once on the calendar, the event becomes a persistent pretext: a pre-confirmed meeting with a Teams link the attacker controls.

The Verizon 2024 Data Breach Investigations Report identifies pretexting as present in the majority of BEC (Business Email Compromise) incidents. A vendor onboarding invite is exactly that: it normalizes future contact with an attacker persona before the real ask arrives.

The ICS hash (3f557d26feafa32cd4d0237f791fb674) came back clean on static analysis. That does not clear it. ICS abuse risk lies in how the calendar application processes the file, not in static payload signatures. A clean verdict is not the same as a safe file.

Why Every Authentication Check Said Trusted

All three checks passed because all three things were true. Microsoft's mail servers are authorized to send for bookings.microsoft.com. Microsoft's keys signed the message. The From domain aligned with both. SPF, DKIM, and DMARC validate the infrastructure, not the account holder's intent.

This is the T1585 playbook at the infrastructure layer: establish accounts on legitimate services and use those services as delivery vehicles. The FBI's IC3 2024 Internet Crime Report documented over $2.9 billion in BEC losses, a category that increasingly involves exactly this pattern of legitimate-service weaponization. The CISA phishing guidance acknowledges that authentication alone is not sufficient for identifying malicious email, yet most organizations still treat DMARC pass as a meaningful trust signal.

IRONSCALES analysis across 1,921 organizations found that SEGs miss an average of 67.5 phishing emails per 100 mailboxes per month. In scenarios where every rule-based check passes, that miss rate isn't a calibration problem. It's structural. Behavioral detection that operates independently of authentication results is the mechanism that catches these attacks. If your stack stops reasoning about a message the moment DMARC passes, attackers know exactly how to get through. See how IRONSCALES M365 augmentation and Adaptive AI reason about the signals authentication can't surface.

Indicators of Compromise

Type	Indicator	Context
Domain	`bookings[.]microsoft[.]com`	Legitimate Microsoft service domain used as sender
Email	`CSAMDCUnifiedOrientationBookings@bookings[.]microsoft[.]com`	Attacker-created Bookings service address
Reply-To	`v-evereault@microsoft[.]com`	Divergent reply path, not controlled by Bookings service
File	`booking.ics` (MD5: `3f557d26feafa32cd4d0237f791fb674`)	Calendar attachment, static verdict clean, context suspicious
Header anomaly	ARC-Seal `i=2; cv=fail`	ARC chain break at hop 2, non-standard routing indicator
Body anomaly	Inline base64 image in HTML body	Atypical for Microsoft Bookings CDN-based template rendering

What Security Teams Need to Prioritize After Seeing This

Standard gateway tuning won't address this class of attack. Every rule-based check passed. The defensive requirements are behavioral:

Inspect ARC chain integrity as a supplemental signal. ARC failure alone isn't definitive, but combined with other anomalies it is meaningful.
Flag Reply-To divergence from first-time senders. Legitimate platforms rarely need Reply-To redirection outside their own service contact flow.
Treat inline base64 images as an anomaly signal from known SaaS senders. CDN asset delivery is standard; inline encoding is a phishing kit behavior.
Apply sender relationship analysis at organizational scale. Eight mailboxes, all first-time recipients from the same sender, is not a coincidence.
Do not auto-trust ICS attachments based on static scanning. Calendar abuse is under-monitored. Pair DMARC management with calendar security review.

The IBM Cost of a Data Breach 2024 report puts the average cost of a phishing-initiated breach at $4.88 million. The emails that generate those breaches are not the obvious ones. They are the ones that look exactly right.

A Phishing Ticket Nobody Opened: How Autotask Became the Attack Vector

apaxson@ironscales.com (Audian Paxson) — Wed, 01 Apr 2026 13:15:00 GMT

TL;DR A credential harvest campaign exploited Autotask, the Datto/Kaseya PSA platform used by thousands of MSPs, to deliver a mailbox expiry lure through legitimate ticketing infrastructure. The email passed SPF, DKIM, and DMARC with compauth=100 because the Autotask mail relay is an authorized sender for the target domain. Every link in the message pointed to real Autotask authentication pages, routing recipients to a genuine login form weaponized as the credential capture surface. The ticket body contained an unrelated Slovak-language email thread about festival logistics, a content mismatch that behavioral analysis flagged while authentication saw nothing wrong.

Severity: High Credential-Harvesting Platform-Trust-Exploitation MITRE: T1566.002 MITRE: T1078 MITRE: T1199

The email looked like every other Autotask ticket notification the IT team had ever received. Same formatting. Same "General Ticket Information" block. Same ticket link at the bottom. The difference: the subject line screamed "Mailbox Login Expire today" while the ticket body contained a Slovak-language conversation about festival accreditation that had nothing to do with mailbox credentials.

SPF passed. DKIM passed. DMARC passed. Microsoft assigned compauth=100 and SCL=-1. By every protocol-level measure, this was a legitimate email from a legitimate server.

It was not.

When Your MSP's Ticketing Platform Becomes the Phishing Vector

The attack exploited Autotask, the Professional Services Automation (PSA) platform owned by Datto/Kaseya and used by thousands of managed service providers worldwide. Autotask handles ticketing, client communications, and automated notifications for MSP operations. When a ticket is created or edited, Autotask's mail servers send formatted notification emails on behalf of the MSP's domain.

That is exactly what happened here. The attacker created (or manipulated) a ticket in an MSP's Autotask tenant. The ticket carried the title "ATTN : Mailbox Login Expire today, 4/16/2026" paired with a fabricated urgency hash (fa8c7b981610f3bda133aca4e3f75cf3a41f60e1) designed to look like a system-generated reference. Autotask's mail relay (phl-p-mail03[.]autotask[.]net, IP 8[.]34[.]161[.]203) then delivered the notification to multiple internal mailboxes as a routine ticket update.

Because the MSP's SPF record explicitly includes autotask.net as an authorized sender, and Autotask applies DKIM signatures using a selector registered on the MSP's domain (s=autotask), the message sailed through every authentication gate. Microsoft's composite authentication scored it 100 out of 100.

The FBI's 2024 Internet Crime Report documented $2.9 billion in BEC losses. Attacks that exploit trusted service provider infrastructure represent a growing subset of that figure, because they arrive pre-authenticated and pre-trusted.

The Three-Layer Deception

Layer 1: Trusted infrastructure. The Autotask notification template is instantly recognizable to anyone working in an MSP-managed environment. Ticket number (T20260416.0029), account name, queue assignment, priority level, due date. All rendered in the standard Autotask format. Recipients who process dozens of these notifications daily have been conditioned to treat them as routine.

Layer 2: Urgency injection. The subject line ("Mailbox Login Expire today, 4/16/2026") is the only English-language content that directly addresses the recipient. It creates a same-day deadline. The ticket's due date field reinforced this: 04/17/2026 17:00 ET, one day out.

Layer 3: Credential prompt as destination. Every link in the email pointed to ww14[.]autotask[.]net, a legitimate Autotask multi-tenant host. The primary link routed to Autotask's authentication controller (/Mvc/Framework/Authentication.Mvc/Authenticate), which presents a login form. For a recipient primed by the "mailbox expiry" subject to expect a credential prompt, the login page confirmed their expectation. The attack weaponized a real authentication page as the credential harvesting surface.

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

This maps to MITRE ATT&CK T1566.002 (Phishing: Spearphishing Link), T1078 (Valid Accounts, as the likely objective), and T1199 (Trusted Relationship, exploiting the MSP-client trust chain).

Content Mismatch: The Behavioral Signal That Authentication Missed

The ticket body exposed the attack's sloppiness. Instead of a coherent mailbox expiry notice, it contained a forwarded Slovak-language email thread between two individuals discussing festival accreditation logistics, partner passes, production staff counts, and wristband distribution procedures. The conversation referenced an Instagram reel, event scheduling hours, and parking allocations.

None of this had any connection to mailbox credentials.

This content-subject mismatch is a hallmark of ticket injection attacks: the attacker controlled the ticket title (which becomes the email subject) but populated the ticket body with whatever content was available, likely from a compromised or scraped email thread. The result is a message where the subject line says one thing and the body says something entirely unrelated.

IRONSCALES community intelligence, drawing on reports from over 35,000 security professionals, flagged similar incidents as phishing. The behavioral signals were clear: an internal-domain sender using a non-verifiable display name ("Pia Api"), a ticket body written in a language inconsistent with the organization's operational language, and an urgency-laden subject line disconnected from the ticket content. Microsoft's protocol-level evaluation saw compauth=100. Behavioral analysis saw a contradiction.

Four mailboxes received the message. All four were quarantined.

Why PSA Platform Abuse Is an Emerging Blind Spot

The Verizon 2024 DBIR found that credential theft remains the top action variety in breaches, appearing in 24% of all incidents. Attackers are increasingly creative about where they source those credentials. Platforms like Autotask, ConnectWise, and other PSA tools represent high-value relay points because:

They are pre-authorized in DNS. MSPs add PSA platforms to their SPF records and configure DKIM selectors for them. This is correct operational practice, but it means any email generated by the platform passes authentication by design.
They generate high-volume notification traffic. Security teams and end users are conditioned to see PSA ticket emails as routine. Volume creates habituation, and habituation reduces scrutiny.
They serve as trusted intermediaries. The MSP-client relationship is one of the most trust-heavy in enterprise IT. A ticket notification from your MSP's service desk triggers a different cognitive response than an email from an unknown sender.

IRONSCALES platform data shows that 67.5 phishing emails per 100 mailboxes per month bypass traditional secure email gateways. Attacks that leverage authenticated MSP infrastructure are disproportionately represented in that bypass rate because SEGs evaluate sender reputation and authentication status, both of which appear clean for PSA-relayed messages.

Hardening Against PSA-Relayed Phishing

For MSPs: Audit your Autotask/ConnectWise tenant access controls. Restrict ticket creation to authenticated internal users. Monitor for tickets with subject lines containing credential urgency keywords ("expire," "password," "verify," "suspend") that do not match the ticket body content. Review which external email addresses can create tickets via the Incoming Email Processor.

For MSP clients: Do not trust email authentication results as a proxy for content safety. Implement behavioral analysis that evaluates content-subject coherence, language consistency, and sender pattern anomalies. Flag ticket notifications that contain urgency language in the subject but unrelated content in the body.

For all organizations: Treat PSA platform notifications with the same scrutiny applied to any other email. The trust model that makes these platforms operationally useful is the same trust model that makes them attractive to attackers.

Type	Indicator	Context
Sending IP	`8[.]34[.]161[.]203`	Autotask mail relay (`phl-p-mail03[.]autotask[.]net`)
DKIM Selector	`autotask`	DKIM signing selector on sender domain
URL	`hxxps://ww14[.]autotask[.]net/Mvc/Framework/Authentication[.]Mvc/Authenticate`	Authentication controller used as credential prompt
URL	`hxxps://ww14[.]autotask[.]net/Autotask/AutotaskExtend/ExecuteCommand[.]aspx?Code=OpenTicketDetail&TicketId=32814`	Ticket detail link in notification footer
Display Name	Pia Api	Non-verifiable persona used as initiating resource
Ticket ID	T20260416.0029	Fabricated ticket number in subject line
Language	Slovak (sk)	Body language inconsistent with English-language subject and organization

Two Security Vendors Scanned This Link and Both Said Clean

apaxson@ironscales.com (Audian Paxson) — Wed, 01 Apr 2026 11:00:00 GMT

A phishing email impersonating a Microsoft Office 365 encrypted message notification, branded with JULY retirement services, was sent via Amazon SES with valid DKIM, SPF, and DMARC. The single call-to-action button chained two competing security vendor URL wrappers: TitanHQ linklock wrapping a Cisco secure-web URL, which in turn wrapped the malicious final domain shoppingtrends.in. Both vendor scanners returned Clean verdicts because each evaluated the other vendor's wrapper rather than the actual payload. The final domain was flagged malware by a third-party security gateway, had a TLS certificate hostname mismatch, and resolved to hosting infrastructure in Germany with inconsistent DNS. Three mailboxes were affected before Themis auto-resolved the incident as phishing at 90% confidence.

The Email That Passed Every Security Check (Because Adobe Sent It)

apaxson@ironscales.com (Audian Paxson) — Tue, 31 Mar 2026 11:00:00 GMT

A phishing campaign targeting a K-12 school district used Adobe's actual email infrastructure to deliver credential-theft lures. The emails passed SPF, DKIM, and DMARC checks for adobe.com, originated from Amazon SES servers Adobe authorizes, and routed every link through postoffice.adobe.com. There were no lookalike domains, no spoofed headers, no malicious URLs in any scanner. IRONSCALES detected the attack through semantic analysis of message intent and community pattern recognition, quarantining emails across four mailboxes. The case illustrates why organizations that rely exclusively on authentication signals and URL reputation are systematically blind to this class of threat.

The Tax PDF That Every Scanner Declared Clean (It Wasn't)

apaxson@ironscales.com (Audian Paxson) — Sun, 29 Mar 2026 11:00:00 GMT

A PDF titled 'Tax Document' landed in four mailboxes at a mid-market financial services firm during tax season. The file passed every static scanner, contained no JavaScript, no embedded URLs, no AcroForm fields, and was marked clean by antivirus. What it did contain: 12 occurrences of the PDF /AA (Additional Actions) token, a spec-level feature that can trigger automated behavior on document events like page open or close. Static tools cannot execute PDF behavior, so the /AA payload remained invisible to them. Themis flagged the email at 66% confidence despite the clean static verdict, citing sender anomalies and structural risk patterns. This is the gap between 'no malicious code found' and 'safe to open.'

Trusted Sender, Wrong Identity: How a Compromised Vendor Account Delivered a Microsoft Sway Credential Harvest

apaxson@ironscales.com (Audian Paxson) — Sat, 28 Mar 2026 18:00:00 GMT

Attackers compromised a legitimate engineering firm's email account and used it to send credential harvesting emails that passed DKIM, SPF, and DMARC authentication. The emails impersonated a Fortune 500 hospitality company using image-only content and delivered victims to a credential harvesting page hosted on Microsoft Sway, a trusted domain that most URL filters do not block. BCC delivery hid the actual recipients. Themis flagged the attack at a confidence of 59% based on behavioral signals including brand identity mismatch, first-time sender status, image-heavy content, and header recipient discrepancies. Security teams should treat vendor authentication as a necessary but not sufficient control and watch for identity inconsistencies that pass technical checks.

Triple-Brand Credential Harvest: How Attackers Fuse Microsoft, Oracle, and NetSuite to Phish Financial Services

apaxson@ironscales.com (Audian Paxson) — Sat, 28 Mar 2026 16:00:00 GMT

Attackers registered a .cz domain days before launching a credential-harvest campaign through Amazon SES. The phishing email stacks Microsoft header branding, an Oracle/NetSuite footer, and a fake IT team signature into a single message, then routes the CTA to a compromised third-party domain. IRONSCALES Themis flagged the attack at 85% confidence using multi-signal analysis: new-domain detection, brand-mismatch correlation, and community threat intelligence.

The Vendor Thread That Bit Back: How a Legitimate Tunneling Service Became a Phishing Vector

apaxson@ironscales.com (Audian Paxson) — Sat, 28 Mar 2026 14:00:00 GMT

A software engineering team lead at a mid-size tech company received a phishing email embedded in an ongoing, legitimate vendor pricing thread. The sender passed SPF, DKIM, and DMARC authentication. A malicious tunneling subdomain link, tied to known threat actor tooling, was delivered inside a real conversation. IRONSCALES Themis detected the malicious link and auto-quarantined the message across three mailboxes within seconds.

No SPF. No DKIM. No DMARC. No Problem (For the Attacker).

apaxson@ironscales.com (Audian Paxson) — Sat, 28 Mar 2026 12:00:00 GMT

Attackers spoofed a SharePoint drive notification using a display name crafted to look like an internal system alert, then routed the message from a FireVPS-RDP server through a Polish Exim relay with no SPF, DKIM, or DMARC in place. The body contained malformed financial figures and a QR code instructing the recipient to 'Scan to view document.' All links used Microsoft short URLs (aka[.]ms, krs[.]microsoft[.]com) but displayed the text 'Outlook for iOS,' a mismatch that has nothing to do with a financial document. Themis classified the email as Credential Theft targeting a VIP Recipient at 89% confidence. Auto-resolved as phishing, quarantined.

The Funding Email That Passed Every Filter By Being Invisible

apaxson@ironscales.com (Audian Paxson) — Sat, 28 Mar 2026 11:00:00 GMT

A financial fraud phishing email impersonating a capital funding firm used invisible Unicode tag characters from the U+E0000 block to break apart filter-detectable keywords like 'credit,' 'rates,' and 'Get Approved' mid-word. To human eyes the text read normally. To filter engines the keywords simply did not exist. The email was sent through legitimate ActiveCampaign infrastructure from a 7-month-old domain, and cleared SPF, DKIM, and DMARC without issue. The final landing domain was independently flagged malicious, and Themis caught it where content filters could not.

The Domain Registered This Morning: How a Compromised University Account Exploited Email Security's Zero-Day Blind Spot

apaxson@ironscales.com (Audian Paxson) — Fri, 27 Mar 2026 20:00:00 GMT

On March 30, 2026, a phishing email sent from a compromised student account at a Russian technical university targeted a K-12 school district in Virginia. The malicious link pointed to a domain registered the same morning, giving reputation-based URL scanners nothing to match against. SPF, DKIM, and ARC all passed. The email body was casual and personal, designed to look like a photo share between acquaintances. IRONSCALES flagged the attack through domain registration intelligence, display name impersonation history, and community behavioral signals, quarantining the message within approximately one minute of delivery.

When 'Release from Quarantine' Is the Attack

apaxson@ironscales.com (Audian Paxson) — Fri, 27 Mar 2026 16:00:00 GMT

Attackers sent a fake email quarantine digest from serverdata.net infrastructure, embedding JWT tokens in 'Allow' and 'Manage quarantined email' buttons that pointed to co.quarantine.serverdata.net. One link displayed membership@ihrm.or.ke but actually redirected to the attacker domain, a classic display-text mismatch. The subject targeted allstaff@nnedv.org but delivered to a completely different organization, revealing mass-targeting infrastructure. IRONSCALES community intelligence flagged the campaign across multiple tenants within minutes.

The PDF Was a Decoy. The QR Code Was the Weapon.

apaxson@ironscales.com (Audian Paxson) — Fri, 27 Mar 2026 14:00:00 GMT

In March 2026, a targeted credential harvesting attack against a cybersecurity firm used a two-layer evasion technique: a PDF attachment containing a QR code, with no URLs present in the email body itself. The QR code decoded to a personalized phishing URL with the recipient's email address base64-encoded in the fragment, confirming individual targeting rather than bulk delivery. The sending domain was four months old, had no DKIM or DMARC, and failed SPF, yet the social engineering mimicked e-signature workflows convincingly enough to draw attention away from authentication failures. URL scanners returned clean verdicts. Themis flagged it on delivery and quarantined it within six minutes using behavioral signals, attachment risk scoring, and community intelligence.

The Meeting Invite That Knew Your Email Address

apaxson@ironscales.com (Audian Paxson) — Fri, 27 Mar 2026 12:00:00 GMT

Attackers sent a flawless Microsoft Teams meeting invite to a staff accountant at a mid-size industrial controls company, impersonating her own organization. The 'Join Meeting' button routed through Microsoft SafeLinks to an AWS Lambda URL with the recipient's email address base64-encoded in the path, proving personalized targeting. Real Teams URLs were mixed in alongside the malicious link to create false trust signals. Themis flagged the mismatch between the envelope sender, the displayed organization, and the Lambda destination. The key lessons: SafeLinks wrapping does not equal safety, and base64-encoded personal data in redirect paths is a reliable indicator of targeted credential harvesting campaigns.

When the Sender Domain Is Also the Phishing Kit Host: Dual-Purpose Domain Compromise

apaxson@ironscales.com (Audian Paxson) — Fri, 27 Mar 2026 11:00:00 GMT

Attackers compromised a legitimate, decades-old manufacturing company domain and weaponized it twice over: once as the sending identity for an Amazon SES phishing campaign and again as the hosting environment for the credential harvest page itself. The lure impersonated Dropbox DocSend with an HR open enrollment deadline. Every authentication signal passed cleanly. Themis flagged the attack based on brand-domain mismatch and community reputation signals, quarantining the email before any credentials were captured.

The Contract You Didn't Request Has a QR Code You Shouldn't Scan

apaxson@ironscales.com (Audian Paxson) — Thu, 26 Mar 2026 20:00:00 GMT

Attackers sent a blank-body email with a PDF attachment disguised as a contract agreement. Inside the PDF, a QR code decoded to a credential harvesting URL hosted on userfocusedtech[.]de, with the victim's email address base64-encoded directly into the URL fragment. This per-recipient personalization means every QR code is unique, defeating signature-based detection. The sending domain concretejsl[.]com failed SPF, had no DKIM, and published no DMARC policy. Themis classified the attachment as malicious with an 89% confidence score and auto-quarantined within two seconds of delivery.

She Clicked the Bid Invitation and Handed Her Credentials to a Netlify Phishing Page

apaxson@ironscales.com (Audian Paxson) — Thu, 26 Mar 2026 16:00:00 GMT

Attackers used a likely compromised operations director account at a legitimate Canadian construction firm to mass-send a fake Request for Information bid invitation. The email passed SPF, DKIM, and DMARC because it genuinely originated from the company's Microsoft 365 tenant. The call-to-action linked to a Netlify-hosted page impersonating ConstructConnect's sign-in portal, a credential-harvesting trap. IRONSCALES' Adaptive AI flagged the href mismatch, anomalous sender behavior, and community intelligence signals, quarantining all four affected mailboxes within seconds.

The PDF That Let the Human In and Locked the Sandbox Out

apaxson@ironscales.com (Audian Paxson) — Thu, 26 Mar 2026 14:00:00 GMT

Attackers used a password-protected PDF sent from what appears to be a compromised state government email account to bypass automated sandboxes. Every authentication check passed: SPF, DKIM, DMARC. Every scanner returned clean. The trick: deliver the passcode in the email body so the human can open it, but the sandbox cannot detonate it. IRONSCALES flagged the pattern through behavioral AI and community threat intelligence, quarantining two mailboxes at a Florida law firm within 26 seconds of email receipt, before any user interaction occurred.

Password-Protected PDFs Are the New Sandbox Killer: How a Compromised .gov Account Delivered an Unopenable Payload

apaxson@ironscales.com (Audian Paxson) — Thu, 26 Mar 2026 12:00:00 GMT

Attackers compromised a paraprofessional's account at a state academy for the blind and used it to distribute a password-protected PDF labeled as a state education department document. The passcode was included in the email body, a classic scanner-evasion technique that prevents sandbox analysis while giving the human recipient everything needed to open the payload. Full SPF, DKIM, and DMARC authentication passed because the email originated from legitimate Microsoft 365 infrastructure. IRONSCALES community intelligence quarantined the message across two affected mailboxes before engagement.

Redirect Laundering: How Attackers Weaponize Trusted Infrastructure to Bypass Email Security

apaxson@ironscales.com (Audian Paxson) — Wed, 25 Mar 2026 20:00:00 GMT

Attackers are laundering malicious URLs through legitimate security and cloud infrastructure to bypass email defenses. Two recent campaigns demonstrate this trend: one chaining Cisco Secure Web and Microsoft SafeLinks to obscure a credential-harvesting domain, and another routing through an Australian academic federation portal to an S3-hosted phishing page. Static URL scanning alone cannot catch these multi-hop redirect chains.

Three Hops, Two Brands, One Fake WAV File: Inside a Multi-Layer Redirect Phishing Attack

apaxson@ironscales.com (Audian Paxson) — Wed, 25 Mar 2026 18:00:00 GMT

Attackers targeting a regional community bank sent a phishing email with a fake audio playback lure, routing victims through three sequential redirects: Microsoft SafeLinks, Cisco Secure Web, then the actual malicious destination at ithm[.]org. The email mixed authentic branding from two legitimate services to appear credible while using homoglyph characters and misspelled asset hosts to evade automated scanners. Despite passing DKIM and DMARC authentication for the sending ISP domain, the sender display name, brand mismatches, and redirect chain exposed the attack. Themis flagged the campaign as credential theft, and both affected mailboxes were quarantined before interaction.

The LinkedIn Invoice That Passed Every Email Check

apaxson@ironscales.com (Audian Paxson) — Wed, 25 Mar 2026 16:00:00 GMT

Attackers registered linkedinreceivables-mail.com just weeks before launching a BEC campaign targeting accounts payable teams. The domain passed SPF, DKIM, and DMARC checks because the attacker configured authentication for their own infrastructure. A single-line invoice query with no details was designed to start a conversation that could lead to payment diversion. This case demonstrates why email authentication verifies domain ownership, not sender intent, and why behavioral analysis is essential for catching authenticated threats.

The $15,247 Invoice That Came With Its Own W-9

apaxson@ironscales.com (Audian Paxson) — Wed, 25 Mar 2026 14:00:00 GMT

Attackers sent a $15,247.75 invoice to an energy company's accounts payable team from globaltradeaudit.org, a domain registered just two days before the attack. The email included three PDF attachments: an invoice, a memo, and a completed W-9 form with EIN. Payment instructions directed funds to 'Synza, Inc.' with full bank routing details. An embedded AWS tracking pixel monitored recipient engagement. The domain had no DMARC policy, was sent through Amazon SES, and passed through Mimecast without triggering impersonation protections.

Fake Google 'Open to Edit' Alert Hides a Kajabi Redirect and Targeted Credential Harvest

apaxson@ironscales.com (Audian Paxson) — Wed, 25 Mar 2026 12:00:00 GMT

A phishing email mimicking a Google Docs sharing notification used a compromised UK healthcare domain to pass SPF and DMARC (p=REJECT). The 'Open to Edit' CTA routed through Kajabi's email marketing platform with the recipient's email base64-encoded in the URL fragment, enabling per-target credential harvesting. Template artifacts like 'High Piority' and unrelated engineering text revealed an assembled phishing kit. IRONSCALES detected the attack through link analysis and community intelligence despite full authentication passing.

The Email Came From Google. The Law Firm Did Not.

apaxson@ironscales.com (Audian Paxson) — Tue, 24 Mar 2026 20:00:00 GMT

Attackers impersonated law firm Alston & Bird LLP using Cyrillic and Unicode homoglyph characters in the display name, abused Google Workspace to send a legitimate Google Drive share notification, and routed replies to an attacker domain registered one day before the attack. Every authentication check passed. IRONSCALES caught it via Unicode character analysis and Reply-To domain age signals, quarantining three mailboxes at a healthcare outcomes firm before any recipient clicked.

Funding Agreement, Forged Approval: How a Three-Layer Redirect Chain Targeted Finance Leadership

apaxson@ironscales.com (Audian Paxson) — Tue, 24 Mar 2026 18:00:00 GMT

Attackers sent a credential-theft email from a privacy-masked Italian domain through Amazon SES, impersonating a document-signing notification for a funding agreement. The campaign targeted a VP of Finance by name, chained a Cisco Secure Web redirect through an Argentinian domain, and displayed a spoofed IRONSCALES-branded URL while the actual href pointed to a different subdomain. DKIM failed for the claimed sender domain while DMARC enforcement was set to none, meaning the message was delivered despite authentication failure. IRONSCALES Adaptive AI quarantined the email within seconds based on link-mismatch detection, community intelligence, and sender behavioral anomalies.

The Health Supplement That Harvested Credit Cards: How a French-Language Phishing Campaign Weaponized ActiveCampaign

apaxson@ironscales.com (Audian Paxson) — Tue, 24 Mar 2026 16:00:00 GMT

Attackers used ActiveCampaign's legitimate mailing infrastructure to deliver a polished French-language health supplement email to a CFO at a U.S. financial institution. The email passed SPF, DKIM, and DMARC on original submission and used professional copywriting techniques to drive the recipient toward a fraudulent checkout page hosted at paiement-securise.optima-editions[.]com. The page collected credit card and bank transfer data directly. IRONSCALES' Adaptive AI flagged the campaign through malicious URL detection and behavioral analysis, quarantining the message before the recipient engaged.

The Fireflies Meeting Recap That Never Happened: Dual-Brand Impersonation via Amazon SES

apaxson@ironscales.com (Audian Paxson) — Tue, 24 Mar 2026 14:00:00 GMT

Attackers used Amazon SES to deliver a phishing email that simultaneously impersonated Fireflies.ai and Microsoft Teams, targeting a financial controller with a fake AP/AR settlement notification. The message passed SPF and DKIM because it originated from legitimate SES infrastructure, and it embedded real Fireflies.ai images, tracking pixels, and PDF links alongside a credential harvesting URL at authorzeyadkareem[.]com. IRONSCALES' Adaptive AI identified the campaign through malicious URL detection, sender anomaly analysis, and community intelligence, quarantining four affected mailboxes before any recipient clicked.

The Audit Request That Passed Every Authentication Check: How a Compromised Nonprofit Account Weaponized URL Shorteners

apaxson@ironscales.com (Audian Paxson) — Tue, 24 Mar 2026 12:00:00 GMT

Attackers compromised a legitimate nonprofit organization's email account and used it to inject a malicious URL shortener link into an ongoing audit correspondence thread. SPF, DKIM, and DMARC all passed because the email genuinely originated from the organization's authenticated Microsoft 365 infrastructure. The embedded qrco[.]de shortener link (a domain frequently abused in quishing campaigns) hid behind an interstitial page to obscure the final redirect. IRONSCALES' Adaptive AI flagged the message through behavioral anomalies and community-reported shortener abuse patterns, quarantining four affected mailboxes before engagement.