Someone Filed a False Positive on This Azure TOAD Scam. Here's Why That's the Whole Point.

The email had a perfect authentication record. SPF passed. DKIM passed. DMARC passed. Every link resolved to portal[.]azure[.]com. And when a security reviewer at a global IoT technology company looked it over, they marked it as a false positive and moved on.

That last part is the whole attack.

This wasn't a misconfigured filter or an oversight. The attacker built the campaign specifically to provoke that response. A recipient who calls the number loses money. A reviewer who clears the ticket kills the alert. Either outcome works.

Get a Demo: See how IRONSCALES catches intent-based attacks that pass authentication

A Real Subscription, a Fake Bill

The infrastructure behind this attack required actual work. The attacker created a legitimate Azure subscription and provisioned a resource group named pay-cbb33c4ab1. Inside that resource group, they configured an Azure Monitor metric alert rule named "Payment Completion Notice-cbb33c4ab1" and set it to trigger at severity level 2.

When the alert fired, Microsoft's own notification system did exactly what it was designed to do. It sent an email from azure-noreply@microsoft[.]com with full SPF, DKIM, and DMARC compliance, routed through Microsoft's outbound mail infrastructure. The subject line read: "Azure: Activated Severity: 2 Payment Completion Notice-cbb33c4ab1."

Inside the standard Azure Monitor alert template, the attacker injected a fraudulent billing paragraph. It read as an official-looking notice: "MICROSOFT CORPORATION BILLING AND ACCOUNT SECURITY NOTICE (REF: MS-FRA-6673829-KP)." The charge: $459.90 for "Windows Defender." Two callback numbers were provided to dispute it, +1 (812) 266-1510 and +1 (812) 266-1890, neither of which appears on any legitimate Microsoft support page.

Every link in the email pointed to portal[.]azure[.]com. There were no credential harvesting domains, no redirect chains, no weaponized attachments. From a technical scanning perspective, this email was clean.

According to MITRE ATT&CK T1566.001 (Spearphishing Attachment via Service), attackers frequently exploit trusted third-party infrastructure to deliver social engineering payloads. When the delivery mechanism is the trusted platform itself, reputation-based defenses have no surface to act on.

Why "No Malicious Links" Is the Feature, Not the Bug

TOAD, Telephone-Oriented Attack Delivery, is a technique built around the limits of automated security tools. If there's no URL to scan, URL scanners produce no verdict. If there's no attachment, sandbox detonation has nothing to run. The entire attack chain lives in a phone call.

The FBI's 2024 Internet Crime Report recorded $2.7 billion in losses tied to phishing and BEC (Business Email Compromise) schemes, with voice-channel escalation cited as an increasingly common component. The pattern is consistent: the email creates urgency and hands the victim a number to call. The attacker answers and handles the rest.

CISA's phishing guidance explicitly calls out callback-based attacks as a growing evasion method, in part because they shift the social engineering to a channel where no automated detection exists.

The recipient in this case was a technology company employee. The fake charge was $459.90, plausible enough to warrant a call but not so large as to trigger immediate escalation to finance. Urgency language about account suspension and additional fees rounded out the pressure.

MITRE ATT&CK T1204.001 (User Execution: Malicious Link) captures the execution dependency here: the attack only completes if the user takes action. In callback phishing, that action is picking up the phone.

See Your Risk: Calculate how many attacks like this your current email security is missing

The False Positive Problem Is the Security Gap

The case was ultimately marked as a false positive by a human reviewer. That outcome deserves unpacking, because it illustrates exactly where this category of attack is designed to succeed.

The reviewer saw a legitimate Microsoft sender. Valid authentication. Real Azure domains. An alert format consistent with genuine infrastructure notifications. Nothing in the technical metadata said "threat." So the verdict was: false positive. Not a phishing attempt.

This is a structural problem, not a human error. Secure Email Gateways (SEGs) evaluate indicators that can be measured: IP reputation, domain age, URL verdicts, attachment hashes. Across IRONSCALES analysis of 1,921 organizations, SEGs miss an average of 67.5 phishing emails per 100 mailboxes per month. TOAD attacks push that number higher because they eliminate the indicators SEGs depend on entirely.

IBM's 2024 Cost of a Data Breach Report put the average cost of a phishing-initiated breach at $4.88 million. That number assumes eventual detection. Attacks cleared as false positives have no detection event to start the clock.

What catches this is behavioral analysis of message content and intent. The Azure Monitor alert template does not normally contain billing notices. The phrase "MICROSOFT CORPORATION BILLING AND ACCOUNT SECURITY NOTICE" is not part of Azure's standard alert format. The phone numbers in the message don't resolve to any documented Microsoft support contact. These are content signals, not infrastructure signals, and they require a different detection model.

Themis, the IRONSCALES Adaptive AI virtual SOC analyst, evaluates this kind of content-authentication mismatch as a primary detection signal. An Azure alert email that reads like a billing dispute notice, with urgency language and unverified contact numbers, scores differently than a genuine infrastructure alert, regardless of what the SPF record says. Across the IRONSCALES community of over 35,000 security professionals, community-level threat intelligence had already flagged similar Azure notification abuse patterns before this specific campaign delivered.

The Verizon 2025 Data Breach Investigations Report found phishing involved in 36% of breaches. The share involving authenticated delivery mechanisms is rising because attackers have figured out that authentication is the easiest checkpoint to clear.

What Security Teams Should Do About This

Four actions, each specific to this attack category:

1. Train reviewers to flag callback numbers as IOCs. Any email instructing users to call an unverified number deserves the same scrutiny as a suspicious URL. Verify callback numbers against official vendor support pages before any engagement. Microsoft publishes its support contact numbers; a quick search proves whether +1 (812) 266-1510 is legitimate. It isn't.

1. Audit your Azure environment for unauthorized alert rules. Navigate to Azure Monitor > Alerts > Alert rules. Look for metric alert rules referencing resource groups you didn't create. Review Azure Activity Logs for resource creation events tied to unfamiliar accounts or principals. This attack required real infrastructure; it leaves a trail.

1. Treat content-authentication mismatch as a detection signal. A Microsoft alert email containing billing dispute language is a red flag regardless of DMARC pass status. Security awareness training should include examples of authenticated phishing, specifically the class of attacks where the sender is technically legitimate and the social engineering is entirely in the copy.

1. Deploy behavioral AI that evaluates intent, not just sender reputation. SPF tells you the email came from Microsoft's servers. It says nothing about whether the content is asking your employee to call a scammer. Organizations that rely on authentication-based filtering alone have no detection mechanism for this attack class. IRONSCALES platform behavioral AI evaluates both.

Try It Free: Start your free IRONSCALES trial and see behavioral detection in action

---