The scareware that walked through your allow-list

A user searching for a business listing clicked a search result and got hijacked by a full-screen "Windows locked due to unusual activity" page — loud beeping, a fake Microsoft Support phone number, the works. She did the right thing and called IT instead of the number. No compromise. Case closed in fifteen minutes.

Except one detail turned a routine scareware ticket into a real finding: the malicious page loaded from *.web.core.windows.net — Azure Blob Storage — and the corporate web proxy explicitly allowed it, bypassing inspection entirely. The attacker didn't defeat the filter. They hosted on a domain the filter had been told to trust.

01What actually happened on the endpoint

Convincing theatre, zero malware. That's the point of scareware.

The page was pure social engineering. It played system sounds, faked a "calculating hashes" cracking screen, and invoked real Windows processes to look authentic — slui.exe (the activation UI) and SppExtComObj.exe (the Software Protection Platform). Those aren't malware; they're legitimate binaries the page triggered to manufacture panic. Nothing was dropped, nothing was installed. When the URL was later detonated in a sandbox, the verdict came back "no threats detected" — because there genuinely was no malware. Only trusted processes ran.

Why the sandbox said "clean"

Sandboxes are built to catch malware behaviour — file drops, registry persistence, process injection. A browser-based scam that only opens system dialogs and shows scary text does none of that. "No threats detected" here doesn't mean safe; it means the threat was social, not technical. The malicious intent lives in what the page asks the human to do, which no sandbox scores.

02The real finding: a wildcard someone trusted

The proxy logs told the actual story.

The web-proxy logs showed the connection allowed, categorized under a custom bypass rule, across several requests in the space of a few minutes. Tracing why led to a single line in a custom "bypass inspection" URL category:

# custom bypass category — trusted, not inspected
.cloudapp.net
.secureworkspace.io
.windows.net          ← the problem
.in.applicationinsights.azure.com
.dc.applicationinsights.microsoft.com

That .windows.net wildcard was added, reasonably enough, so that legitimate Microsoft services (Autopilot, sign-in endpoints, telemetry) would skip inspection. But web.core.windows.net — the domain any Azure Blob Storage account gets — also matches .windows.net. So the attacker's throwaway storage account inherited the same trust as your identity provider. The filter did exactly what it was told; it was told the wrong thing.

Wildcard trust is inherited trust. A bypass rule keyed on a broad suffix can't distinguish first-party Microsoft endpoints from any tenant's — or any attacker's — storage account under the same suffix. Reputation and inspection are skipped for all of them equally.

03Response — treat "no compromise" as "prove it"

Even a scam that only shows a phone number gets the full check.

Scareware's whole goal is to get the user to call and hand over access, so the response assumes they might have — then proves they didn't. The checklist that closed this out:

# confirm the source and that nothing was installed
- reviewed browser history → confirmed pop-up origin, not a download
- ran full AV + adware scans → clean
- checked for unauthorized installed software → none

# identity + mailbox hygiene, in case the user called and granted access
- reset the Windows / account password
- revoked all active cloud sign-in sessions
- verified the registered MFA device is the user's own
- checked mailbox for forwarding / inbox / sweep rules → none

None of it turned up compromise — but you run it anyway, because "the user didn't call the number" is a claim you verify, not one you assume. The mailbox-rule and MFA-device checks in particular are cheap and catch the cases where a user did engage before reporting.

04The fix that actually matters

Fixing the endpoint fixes one user. Fixing the wildcard fixes the class.

The endpoint was never the problem. The recommendations that close the real gap are all about the allow-list:

# replace the broad wildcard with explicit, first-party endpoints
- REMOVE  .windows.net              # matches every Azure blob on earth
+ ALLOW   login.windows.net         # only what actually needs bypass
+ ALLOW   autopilot.windows.net
+ ALLOW   <specific service FQDNs you rely on>

# and verify nothing else is quietly trusting a broad suffix
- audit every bypass/allow category for wildcard suffixes
- put the bypass category into log-only / inspect mode first to see
  what's actually riding through before you tighten it

Shared cloud domains are shared trust

web.core.windows.net, blob.core.windows.net, *.cloudfront.net, *.web.app, storage and CDN suffixes generally — these are multi-tenant. Whitelisting the suffix hands the same trust to every tenant on the platform, including attackers who spin up an account for an afternoon. Trust specific hostnames, not the platform they sit on.

The lesson

The interesting artifact in a "harmless" scareware ticket wasn't on the endpoint — it was in the proxy config. A wildcard bypass on a shared cloud suffix is a hole attackers rent by the hour: they host on the exact domains you told your filter to trust. Whenever you allow-list to reduce friction, allow-list hostnames, never the multi-tenant suffix underneath them.