Incident ReportsIR
IR-2026-006
MED

Scareware — Azure-Hosted Tech Support Scam

FILED:Jan 2026
TAXONOMY:T1566.002
Complexity:Standard
1.5h containment
~5m read
TRUE POSITIVE — QUARANTINED AT DELIVERY, NO USER INTERACTION

Defender for Office 365 detected and quarantined an inbound email containing a URL flagged by URL Detonation Reputation at delivery. Analyst sandbox confirmed the URL resolved to an Azure Blob Storage-hosted tech support scam — browser-locking JavaScript, full-screen fake Windows security alert, and a fraudulent UK freephone number. Email quarantined before any user interaction. Zero open events and zero URL clicks confirmed.

MalwareEmailAzureScarewareSandbox
Outcome
Email quarantined — never delivered to user inbox
Zero user interactions confirmed — no open events, no URL clicks
No further remediation required — DFO365 fully contained at delivery
Background & Context

Tech support scams (TSS) are social engineering attacks that use fake security alerts to panic victims into calling fraudulent support numbers, at which point attackers install remote access tools or extract payment. The browser-lock technique — which uses JavaScript to intercept browser close events and prevent the user from dismissing the page — is specifically designed to simulate a genuine system lockout and amplify panic.

Azure Blob Storage hosting is an increasingly common evasion technique for TSS campaigns. By hosting the scam page on *.core.windows.net, attackers inherit Microsoft's domain reputation, causing traditional URL reputation filters that extend trust to Microsoft-owned infrastructure to bypass the content. URL detonation-based detection — which analyses runtime page behaviour rather than static domain reputation — is the only reliable detection mechanism for this pattern.

The targeting of a shared service team mailbox is deliberate: a shared inbox has multiple users with access, statistically increasing the probability that someone will open the email before it is reported. The fraudulent UK freephone number on the scam page confirms geographic targeting at UK-based recipients, indicating campaign localisation rather than generic global deployment.

Triage Thought Process
01DFO365 has already quarantined at delivery. This is a post-quarantine verification and documentation exercise. Primary question: did any user interact before quarantine?
02Verify delivery action and delivery location explicitly. Confirm 'Delivery action: Blocked' and 'Original delivery location: Quarantine' — not inbox delivery with post-delivery action.
03Confirm zero user interactions. Check both email open events and URL click events. Shared mailboxes carry higher interaction risk.
04Manual sandbox detonation is for documentation. DFO365 already detonated — analyst sandbox documents full page behaviour for client reporting and institutional knowledge.
05Azure Blob hosting means platform-level domain blocking is not effective. Document the specific subdomain URL only.
06Report to Microsoft abuse team. Azure-hosted scam pages can be removed within hours of a valid abuse report.
Decision
Fully contained at delivery by DFO365. Sandbox documentation completed. Zero user interactions confirmed. Client advisory issued. No further remediation required.
Incident Timeline
23 Jan, ~16:00
Malicious email delivered to shared service team mailbox — DFO365 URL Detonation Reputation triggers, delivery blocked
23 Jan, 16:12
Analyst logs internal note — email preview and analysis begins in Microsoft Defender portal
23 Jan, 16:15
Malicious URL identified in email body — Azure Blob Storage subdomain
23 Jan, 16:20
URL submitted to manual sandbox detonation in isolated browser environment
23 Jan, 16:25
Sandbox loads: hxxps://sarimiwas[.]z13[.]web[.]core[.]windows[.]net/
23 Jan, 16:28
Page behaviour documented: full-screen Windows security alert overlay, Admin Login popup, fraudulent UK freephone number
23 Jan, 16:30
Browser-lock confirmed: page executes JavaScript reload on close attempt
23 Jan, 16:32
DFO365 details confirmed: Delivery action: Blocked, Original delivery location: Quarantine
23 Jan, 16:35
Zero email open events and zero URL click events confirmed via admin console
23 Jan, ~17:30
Ticket closed — full containment at delivery confirmed, client advisory issued
Technical Analysis

The email was delivered to the shared service team mailbox where Defender for Office 365's URL Detonation Reputation engine triggered at delivery, classifying the email as malicious and routing it to quarantine before it reached the inbox. This is the correct containment point — pre-delivery quarantine is preferable to post-delivery remediation.

Manual sandbox detonation of the URL (hxxps://sarimiwas[.]z13[.]web[.]core[.]windows[.]net/) documented the following page behaviour: a full-screen overlay presenting a Windows security alert warning with Microsoft branding; an "Admin Login" modal positioned in the foreground; a prominently displayed UK freephone number claimed to be Microsoft Support; and JavaScript logic that intercepted the browser's beforeunload event and executed an immediate page reload on any close attempt — implementing the browser-lock.

The browser-lock implementation is competent: it does not simply prevent window closure (which modern browsers restrict) but instead reloads the page, maintaining the alarming state and preventing casual dismissal. Non-technical users experiencing this for the first time would find it genuinely alarming and difficult to dismiss without knowing the Task Manager escape route.

The Azure Blob Storage subdomain (sarimiwas[.]z13[.]web[.]core[.]windows[.]net) cannot be blocked at the domain level without disrupting legitimate Microsoft services. The correct indicator is the specific subdomain URL. Azure static web hosting accounts can be created and deployed rapidly, meaning the campaign URL is likely short-lived — reporting to Microsoft's abuse team (abuse@microsoft.com) is the most effective remediation action to remove the hosted content.

Zero email open events and zero URL click events were confirmed via the admin console — DFO365 quarantined the email before any user interaction occurred.

Environment
Microsoft Sentinel — Defender for Office 365 (URL Detonation Reputation)
Microsoft 365 / Defender for Office 365
Manual sandbox detonation
Signals
URL Detonation Reputation flag on inbound email — triggered at delivery
URL hosted on Azure Blob Storage (*.z13.web.core.windows.net)
Delivery action: Blocked — Original delivery location: Quarantine
Shared service team mailbox targeted
What I Checked
Delivery action confirmed: Blocked — Original delivery location: Quarantine (not delivered to inbox)
URL submitted to manual sandbox detonation for full behavioural documentation
Sandbox: full-screen Windows security alert overlay, Admin Login modal, Microsoft branding, fraudulent UK freephone number
Browser-lock confirmed: page executes JavaScript reload on close attempt — re-displays warning
Zero email open events confirmed via admin console
Zero URL click events confirmed via UrlClickEvents query
Actions Taken
Email quarantined at delivery by DFO365 — confirmed never delivered to any user inbox
Specific Azure Blob Storage URL documented as indicator (subdomain-scoped, not platform-wide)
Client advisory issued: browser-lock escape via Task Manager (Ctrl+Shift+Esc), not browser UI
Recommended: report Azure Blob Storage URL to Microsoft abuse team (abuse@microsoft.com) for static site takedown
Indicators of Compromise
TypeIndicatorNotes
URLhxxps://sarimiwas[.]z13[.]web[.]core[.]windows[.]net/Azure Blob Storage hosted tech support scam page with browser-lock JavaScript
Phone+44 808 XXX XXXX (redacted)Fraudulent UK freephone number — geographic targeting confirmed
HostingAzure Blob Storage (z13.web.core.windows.net)Microsoft cloud infrastructure abused to inherit reputation and bypass URL filters
Threat TypeMalware / Spam — Scareware / Tech Support ScamBrowser-lock JavaScript + fake Windows alert + fraudulent callback number
MailMessage GUIDd634a8df-[REDACTED]-08de5a979b49M365 admin audit trail reference
MITRE ATT&CK Mapping
TacticTechniqueIDObserved
Initial AccessPhishing: Spearphishing LinkT1566.002Link-based email delivery to shared service team mailbox
ExecutionUser Execution: Malicious LinkT1204.001Scam designed to elicit user action — call fraudulent support number
Defense EvasionTrusted Infrastructure Abuse / MasqueradingT1199 / T1036Azure Blob Storage used to inherit Microsoft domain reputation
ImpactFinancial Theft / Establish Remote AccessT1657 / T1219End goal: victim calls number, attacker installs RAT or extracts payment
Detection Logic (KQL)
// Confirm delivery action and quarantine location
EmailEvents
| where NetworkMessageId == "d634a8df-[REDACTED]-08de5a979b49"
| project Timestamp, RecipientEmailAddress, DeliveryAction, DeliveryLocation, ThreatTypes, DetectionMethods

// Confirm zero user clicks on the Azure Blob URL
UrlClickEvents
| where Url contains "sarimiwas.z13.web.core.windows.net"
| project Timestamp, AccountUpn, Url, ActionType, IsClickedThrough

// Hunt for other Azure Blob scam URLs in last 7 days
EmailUrlInfo
| where Url contains "z13.web.core.windows.net"
   or Url contains "z22.web.core.windows.net"
   or Url contains "z6.web.core.windows.net"
| join EmailEvents on NetworkMessageId
| project Timestamp, RecipientEmailAddress, Url, DeliveryAction
Analyst NotesMuhammad Fezzan

Sandbox was primarily used for documentation rather than detection — DFO365 had already quarantined the email before analyst involvement. The Azure Blob hosting technique is increasingly common and well-suited to bypassing reputation-based URL filters.

The browser-lock JavaScript implementation was competent — it intercepted the standard close event and executed an immediate page reload. Non-technical users would find this genuinely alarming and difficult to dismiss without knowing the Task Manager escape route.

The fraudulent UK freephone number confirms geographic targeting at UK-based recipients — indicating campaign localisation rather than a generic global deployment.

Lessons Learned
Azure infrastructure abuse bypasses traditional reputation-based URL filtering — URL detonation is the only reliable detection mechanism.
Browser-lock JavaScript is effective against even technically aware users — security awareness training should cover the Task Manager (Ctrl+Shift+Esc) escape route.
Shared team mailboxes require heightened monitoring — higher user count increases interaction probability.
Report abused Azure Blob content promptly — takedown via abuse@microsoft.com can occur within hours.
Sandbox documentation has institutional value even when automated detection has already acted.
Recommendations
R1Maintain DFO365 URL detonation at maximum sensitivity: the detonation engine was the sole detection mechanism here. Ensure Safe Links detonation is active for all inbound email and is not bypassed by safe sender overrides applied to bulk senders.
R2Report abused Azure Blob content to abuse@microsoft.com promptly: Azure-hosted scam pages can be removed within hours of a valid abuse report. Timely takedown reduces campaign effectiveness against other organisations.
R3Include tech support scam recognition and browser-lock escape in security awareness training: key user messages — Microsoft will never display a phone number in a browser security alert; browser locks can always be escaped via Task Manager (Ctrl+Shift+Esc); any unexpected security popup should be reported to IT before any action is taken.
R4Apply heightened monitoring to shared team mailboxes: consider implementing additional review rules or alert thresholds for shared inboxes, which carry higher interaction probability than single-user mailboxes.
SIG
Case Certification
Muhammad Fezzan
SOC ANALYST
DIGITAL TIMESTAMP
JAN 2026 // REG-006-FS
← All incidentsCase anonymised