Case Library / Phishing / Azure Monitor callback phishing: a real Microsoft email with a fake $459.90 bill (2026)
PhishingVishing (Voice Phishing) Documented incident

Azure Monitor callback phishing: a real Microsoft email with a fake $459.90 bill (2026)

Attackers made Microsoft's own Azure Monitor send a fake $459.90 Windows Defender bill that passed SPF, DKIM and DMARC. A reviewer cleared it. How it worked.

Share:

Social Engineering Examples·4 sources

This callback phishing email really did come from Microsoft. Attackers opened a real Azure subscription and set up an Azure Monitor alert rule, then stuffed a fake "Windows Defender" bill for $459.90 into the alert text, with two phone numbers "to dispute" the charge. When the alert fired, Microsoft's own servers sent it from azure-noreply@microsoft.com. It passed SPF, DKIM and DMARC, and every link went to portal.azure.com. At one company, a security reviewer looked at it and marked it a false positive. Email security firm IRONSCALES published the case on 21 March 2026. Status: Vendor report; victims not named.

Key takeaways

  • Nothing was spoofed. The sender, the servers and the links were all genuinely Microsoft's.
  • No bad link, no attachment. The fraud happens on a phone call, which is what TOAD (telephone-oriented attack delivery) means.
  • The tell was context: a billing dispute sitting inside a cloud monitoring alert.
  • Whether anyone called the number or lost money isn't known.

How the attack worked

Step What the attacker did, per IRONSCALES
Set up Opened a real Azure subscription and made a resource group called "pay-cbb33c4ab1"
Rig the alert Created a metric alert rule called "Payment Completion Notice-cbb33c4ab1", severity 2
Write the bait Used the alert's free-text fields for a fake "MICROSOFT CORPORATION BILLING AND ACCOUNT SECURITY NOTICE" with reference MS-FRA-6673829-KP, a $459.90 Windows Defender charge and two callback numbers that appear on no Microsoft support page
Let Microsoft send it The alert fired and Azure Monitor emailed it through Microsoft's real outbound servers
Wait for the call Anyone who rang to dispute the charge would reach the attackers

The subject line looked exactly like a normal alert: "Azure: Activated Severity: 2 Payment Completion Notice-cbb33c4ab1". For most staff, that's routine cloud noise.

Tip: never call a number printed in an unexpected bill, even from a sender you trust. Look up the company's support number yourself.

Three samples, not one

Coverage often blurs these together. They're separate.

Sample Target Charge What happened
IRONSCALES main case A global IoT technology company (unnamed) $459.90 A human reviewer cleared it as a false positive
IRONSCALES companion case A mid-size US professional services firm (unnamed), "Your Payment Has Been Received", transaction ID PP456-887A-22B $459.90 Quarantined in 4 mailboxes before anyone engaged
BleepingComputer's find Not stated. Dated 5 March 2026, mixing the main case's reference with the companion's transaction ID and different phone numbers $389.90 Reported in the wild

The two IRONSCALES write-ups also list different sender IPs and link domains. Don't merge their indicators.

Why it fooled a reviewer

Think about what a security analyst checks first. Sender domain? Microsoft. Authentication? Pass on all three. Links? Microsoft's portal. Attachments? None. Every box says safe.

IRONSCALES argues that was the point. If the reviewer clears it, the last chance to catch it is gone. If someone calls the number, the attacker gets a live victim on the phone. Either way the campaign wins. No law enforcement action, loss figure or named group has been tied to any of the samples.

What stops it

  • Don't treat passing SPF, DKIM and DMARC as proof of safety. It proves who sent it, not what it says.
  • Look at content and context. A billing dispute inside an infrastructure alert is a mismatch worth flagging.
  • Train SOC reviewers not to clear tickets just because the headers pass.
  • Treat "urgent charge, call to dispute" as a red flag whatever the sender.
  • Share samples with peers and vendors. Indicators move fast.

See also callback phishing, vishing examples and tech support scams.

Common questions

What was the Azure Monitor callback phishing scam?

Attackers set up a real Azure Monitor alert so Microsoft's own servers emailed a fake $459.90 Windows Defender bill with phone numbers to call.

Why did it pass email security checks?

It genuinely came from Microsoft's mail servers, so SPF, DKIM and DMARC all passed, and the links pointed to portal.azure.com.

Did anyone lose money?

Not that's been reported. IRONSCALES doesn't say whether the employee in its main case called the number.

What is TOAD?

Telephone-oriented attack delivery: an email that pushes you to call a number, so the actual fraud happens on the phone.

Sources
  • Someone Filed a False Positive on This Azure TOAD Scam. Here's Why That's the Whole Point.. IRONSCALES (primary). Primary vendor writeup (published 2026-03-21) documenting the $459.90 lure, the pay-cbb33c4ab1 resource group / Payment Completion Notice alert rule, full SPF/DKIM/DMARC pass, sender IP 40.93.194.96 per its own IOC table, links resolving only to portal.azure.com, and the human reviewer's false-positive determination at a global IoT technology company. This article's own MITRE citation mislabels T1566.001 as 'Spearphishing Attachment via Service.' Verified live 2026-07-29.
  • The Azure Alert That Billed You $459: When Microsoft's Own Infrastructure Delivers the Phish. IRONSCALES (primary). Companion primary IRONSCALES writeup (published 2026-03-21) on the same Azure Monitor abuse technique, describing a related sample (professional services firm, transaction ID PP456-887A-22B) that also cited a $459.90 charge and was quarantined by IRONSCALES' Adaptive AI/behavioral detection (Themis), with four affected mailboxes, before recipient engagement. Documents sender IP 40.93.14.106, the outbound.protection.outlook.com relay chain, and links to azure.microsoft.com/go.microsoft.com/microsofticm.com, details specific to this companion case, not the primary one. Correctly cites MITRE T1566.003 (Spearphishing via Service). Verified live 2026-07-29.
  • Microsoft Azure Monitor alerts abused for callback phishing attacks. BleepingComputer (secondary). Independent secondary reporting (2026-03-21) corroborating the Azure Monitor alert-abuse callback-phishing pattern; describes a distinct in-the-wild example (dated 03/05/2026) combining the primary case's reference number (MS-FRA-6673829-KP) with the companion case's transaction ID (PP456-887A-22B) but citing a $389.90 charge and different callback numbers (+1 (864) 347-2494 and +1 (864) 347-4846): a third variant, not a figure IRONSCALES reported for either of its two documented samples. Verified live 2026-07-29.
  • In-Depth Analysis: Azure Monitor Alerts Phishing Campaign and BazarCall Techniques. IPSIP (secondary). Secondary technical analysis situating the campaign within the broader BazarCall/TOAD callback-phishing technique family. Verified live 2026-07-29.
Cite this case

Social Engineering Examples. “Azure Monitor callback phishing: a real Microsoft email with a fake $459.90 bill (2026)”. Accessed 3 November 2026. https://socialengineeringexamples.com/azure-monitor-alert-toad-billing-scam-2026

Attack Chain & Defense
1Reconnaissance and targeting
What happened

Not directly documented by any source, but consistent with this attack class, the operation likely began with selecting target organizations or mailing lists (per BleepingComputer, delivery ran through a mailing list believed to be attacker-controlled) and studying the genuine formatting conventions of Azure Monitor action-group alert emails (subject-line pattern, sender address, template structure) closely enough to inject convincing fraudulent text into them.

The control that would have stopped it

There is little a defender can do to stop an attacker from studying publicly visible Azure Monitor alert formatting, since that structure is intentionally public and documented by Microsoft; the realistic control sits at Stage 2, where the fraudulent resource construction itself becomes detectable.

2Attacker infrastructure setup
What happened

The attacker created a real Azure subscription and, within it, a resource group ("pay-cbb33c4ab1" in the primary case) and an Azure Monitor metric alert rule with a billing-themed name, then used the free-text description field that Azure Monitor exposes for alert rules to inject a fabricated "Windows Defender" billing dispute notice, complete with a fake reference number, dollar amount, and attacker-controlled callback numbers.

The control that would have stopped it

IPSIP's writeup recommends Azure-configuration/cloud-governance monitoring, auditing changes to Action Groups and Alert Rules for keywords like "invoice," "payment," or "billing" appearing in rules created by unrecognized principals, and enforcing MFA-gated, least-privilege access to who can create or modify alert rules and their free-text fields, whether on an organization's own tenant or as a pattern Microsoft itself could monitor for at the platform level.

3Weaponized delivery
What happened

The attacker triggered the alert rule so that Microsoft's own Azure Monitor notification pipeline generated and sent the email itself, from the genuine azure-noreply@microsoft.com address through Microsoft's outbound mail servers, producing a message with a fully passing SPF/DKIM/DMARC result because it truly originated on Microsoft's infrastructure.

The control that would have stopped it

Because the message is genuinely SPF/DKIM/DMARC-authenticated and delivered through Microsoft's real mail infrastructure, standard sender-authentication controls cannot block delivery at this stage; IRONSCALES' own reporting frames this as the central lesson, that authentication verifies who sent a message, not whether its content is safe.

4Automated-defense evasion
What happened

Because the email carried no malicious link or attachment, only genuine Microsoft domains (portal.azure.com and related) and a fraudulent paragraph of text plus a phone number, URL-reputation scanners and attachment/sandbox detonation had nothing to flag, and sender-authentication checks affirmatively vouched for the message.

The control that would have stopped it

Deploy behavioral or content-anomaly detection, such as IRONSCALES' own Adaptive AI (Themis) engine, that flags the mismatch between an infrastructure-monitoring template and injected billing/payment language, first-time-sender-to-recipient anomalies, and community threat-intelligence patterns, rather than relying solely on URL- or attachment-scanning verdicts.

5Human/SOC triage decision point
What happened

A security reviewer (in the primary case) or an automated behavioral system (in the companion case) evaluated the alert. In the primary case, seeing a genuine Microsoft sender with fully passing authentication and no flagged links, the human reviewer classified the message as a false positive rather than a phishing attempt.

The control that would have stopped it

Train SOC reviewers and end users not to auto-clear a ticket as a false positive solely because authentication headers pass; give reviewers an explicit rule that a billing dispute demand with a call-to-action phone number, embedded inside an unrelated infrastructure-monitoring alert, is itself the indicator, regardless of sender legitimacy.

6Voice-channel monetization (TOAD callback)
What happened

The intended final step, for any recipient who called one of the attacker-controlled numbers, was a live phone conversation in which the attacker would attempt to extract payment-card details, account credentials, or induce installation of remote-access software under the pretext of "verifying" or "disputing" the fake charge; neither IRONSCALES case discloses whether a recipient actually completed this step.

The control that would have stopped it

Treat any callback number embedded in an unsolicited billing or security alert as an unverified indicator and look up the vendor's real support number independently rather than dialing the number in the message; this end-user step is the last available control once delivery and triage have both failed to stop the message.

Quick Facts
Victim
An unnamed security reviewer/employee at a global IoT technology company (per IRONSCALES' primary case); a related same-technique sample separately targeted a mid-size U.S. professional services firm.
Both organizations are vendor-anonymized in IRONSCALES' reporting and have not been independently identified or confirmed.
Location
Not publicly disclosed for the primary case (described only as "a global IoT technology company"); a related same-technique sample hit a mid-size U.S. professional services firm.
Both organizational descriptions are vendor-anonymized in IRONSCALES' reporting and have not been independently identified or confirmed. Callback phone numbers used a U.S. (Indiana, area code 812) area code.
Date
2026-03-21 (IRONSCALES publication date; underlying campaign observed shortly before)
Impact
No confirmed financial loss has been publicly disclosed for either IRONSCALES case.
Basisnot-a-lossThe $459.90 is the lure amount; no completed fraud is documented
The primary lure demanded a disputed charge of $459.90 (framed as a "Windows Defender" billing item). IRONSCALES' companion sample (professional services firm, transaction ID PP456-887A-22B) cited the identical $459.90 figure, not a different "$389.90 variant" as earlier summarized. The $389.90 figure instead belongs to a third, distinct in-the-wild example that BleepingComputer independently observed and reported: a lure combining the primary case's reference number (MS-FRA-6673829-KP) with the companion case's transaction ID (PP456-887A-22B) and a transaction date of 03/05/2026, but with different callback numbers and a $389.90 charge. That figure is BleepingComputer's own finding, not a value IRONSCALES reported for either of its two documented samples. Because the primary email was marked a false positive by a human reviewer and IRONSCALES does not report a completed callback or fraud outcome for that case, whether the targeted employee called the number or lost money is not documented in the public record. The companion sample was quarantined by IRONSCALES' AI/behavioral detection before any recipient engagement (4 mailboxes affected, no reported loss).
Status
Documented incident
Case Type
Real-World Incident
Sector
Professional & Business Services, Technology & Software
Threat Actor
unknown
Explore more

Related Cases

Browse by what this case has in common with others in the library.