# Reputation Radar #6: The Network Was the Hiding Place > Three attacks this week didn't beat the network trust signals a SOC relies on. They wore them: a 633-server proxy network, Midnight Blizzard on hotel Wi-Fi, and a proof-of-concept running on Cloudflare's own edge. - Published: 2026-08-12 - Author: Reput.io Team - Tags: Threat Intelligence, Infrastructure Reputation, SOC, Weekly Report - Canonical: https://www.reput.io/blog/reputation-radar-06 --- Every SOC runs on a few quick network-level gut checks. This IP is a residential proxy, treat it with suspicion. This is a hotel captive portal, probably nothing. This came off Cloudflare's edge, so it's some real site hiding behind a proxy. Those calls aren't lazy, they're how you get through the alert queue before lunch. The uncomfortable thing about this week is that three separate groups didn't try to fool any of those checks. **They just set up shop inside the exact infrastructure the checks trust.** ## The proxy that launders where you came from SecurityScorecard spent 180 days pulling apart a proxy network they're calling **CanOworms**, and the number that stuck with us is 633. That's how many servers it runs, scattered on purpose across **more than six unrelated hosting providers in at least a dozen countries** ([SecurityScorecard](https://securityscorecard.com/blog/inside-canoworms-the-633-server-proxy-network-hiding-criminal-and-state-linked-activity/)). Rent access and your traffic pops out the far end wearing someone else's IP. When an address starts collecting abuse complaints, they drop it and move on. Parts of this have been running since 2017, so it's a business, not a stunt. Here's what makes it our kind of story. The renters aren't one crew. SecurityScorecard ties both **China-nexus and North-Korea-nexus activity** to the network, carefully, at low confidence, and each as one customer among many rather than the owner. So a state operator and someone running card fraud can be leaving through the same node on the same afternoon. Whatever you thought that exit IP was telling you, it isn't. And that's not your blocklist failing, it's the whole thing these people sell. Their advice is the useful bit: stop trusting the address, fingerprint the box behind it. They published **TLS certificate details plus JARM and JA4X fingerprints**, the stuff that stays put even after the IP rotates out from under you. ## The sign-in page was sitting on the hotel Wi-Fi This one's clever in a way we didn't enjoy. Zscaler's ThreatLabz caught a Midnight Blizzard sub-cluster (**Storm-2945** in their notes) going after the hotel instead of the guests ([Zscaler](https://www.zscaler.com/blogs/security-research/captivecrunch-midnight-blizzard-weaponizes-hotel-wi-fi-captive-portals)). Compromise the captive portal, that "click here to get online" gateway, and suddenly you get to mess with everyone's DNS and HTTP on the way through. From there it's pick-your-poison: a fake Microsoft 365 login, a **device-code prompt that quietly rides Entra ID's real auth flow** (that's the one that strolls past normal MFA), or a ClickFix "you need to update" nag. They dressed the set nicely, too. Domains like `ms365-device.com` and `owa-ms365.com`, a C2 callback disguised as an image tracking pixel, a payload that shows up looking like a JS polyfill file. Hooked gateways turned up in a handful of U.S. cities, plus India and Saudi Arabia. The part that gets me is the double layer of trust: you trust the hotel to put you online, and you trust the Microsoft page to be Microsoft, and both of those small acts of faith were quietly working for the attacker. ## The payload ran on Cloudflare's own edge The last one is a proof of concept, nobody's caught it live, but it makes the point too cleanly to skip. Check Point went digging in **workerd**, the runtime under Cloudflare Workers, and found five memory-corruption bugs in the C++ "glue" that stitches JavaScript to the native layer ([Check Point](https://research.checkpoint.com/2026/when-agentic-glue-melts/)). One path reads another tenant's API tokens straight out of shared memory. Another starts with a **prompt injection**, talks an LLM into writing booby-trapped TypeScript, then rides a use-after-free all the way to running code on the host. To their credit they were upfront that they tested this on their own workerd and never fired it at Cloudflare production. Why it belongs here: Workers pushes more than **10% of all traffic on Cloudflare's network**, and anything running there leaves through Cloudflare's IPs with Cloudflare's good name attached. We can show what that does to a defender. Drop the Workers apex into our own API: ```json { "indicator": "workers.dev", "status": "whitelisted", "verdict": "investigate" } ``` It's real Cloudflare, it's genuinely one of the most popular domains on earth, and the API still won't just wave it through. The note it leaves on the record is the honest one: attackers **"routinely proxy phishing kits and C2 panels through Cloudflare to hide origin IPs."** So even here, the label says Cloudflare and the advice is to go look at what's actually behind it. ## The thread for a SOC Line the three up and it's one trick wearing three outfits. The proxy makes the exit IP say nothing. The hijacked portal makes "I'm on a trusted network" say nothing. The edge platform makes "it came from Cloudflare" say nothing. Every one of them leaned on a signal that only ever told you where the traffic was standing, not who was behind it. None of this means junking network reputation, you'd never clear the queue without it. It means keeping honest about what those signals can and can't answer. When the position is something an attacker can rent or borrow, that's your cue to go look at the parts they can't easily fake: the certificate, the handshake, where that login form actually ships the password. ## Also on the radar - **Patch Tuesday was a big one, 398 CVEs.** Do CVE-2026-68820 first, a WinSock driver privilege-escalation bug that's already being exploited; there's also a perfect-10 authorization flaw in SAP Commerce Cloud, CVE-2026-58231 ([CSO Online](https://www.csoonline.com/article/4208185/patch-tuesday-august-2026-a-zero-day-winsock-driver-hole-under-exploit-and-a-maximum-severity-sap-vulnerability.html)). - **Sandworm (tagged UAC-0145 here) is phishing IT folks with a trojanized WireGuard build** called "SopraVPN," dangled through fake job interviews and a SourceForge page tied to `soprasteria-bg[.]com`; a tweaked config option decrypts and runs embedded PowerShell ([BleepingComputer](https://www.bleepingcomputer.com/news/security/sandworm-hackers-target-it-pros-with-trojanized-wireguard-vpn-client/)). Same idea as above, really: a VPN client you install because you trust the name on it. - **That SharePoint deserialization bug, CVE-2026-45659, is now turning up in ransomware.** CISA has had it in KEV since July 1 and updated the entry this week; it lets a low-privilege user run code reliably ([BleepingComputer](https://www.bleepingcomputer.com/news/security/cisa-microsoft-sharepoint-flaw-now-exploited-in-ransomware-attacks/)). - **The Snowflake saga finally closed with a guilty plea.** Connor Moucka, 26, admitted to intrusions at at least 165 organizations, exposing data on more than 100 million people, tracked as UNC5537. Almost every account came down to infostealer-grabbed passwords that were never rotated, MFA switched off ([The Hacker News](https://thehackernews.com/2026/08/snowflake-hacker-pleads-guilty-over.html)). No zero-day anywhere in it. - **Cloudflare's H1 2026 DDoS report** notes 1 Tbps attacks are now the boring normal rather than the headline ([Cloudflare](https://blog.cloudflare.com/ddos-threat-report-2026-h1/)). If you want the longer version of why a legitimate cloud IP is context rather than a verdict, we walked through it in [when the phishing page lives on Google's servers](/blog/borrowed-reputation-cloud-phishing). See you next week. *Sources are linked inline; credit to the original researchers and reporters. If we got a detail wrong, tell us and we'll fix it.* > **About Reputation Radar:** This is written by the small team building Reput.io, not a marketing department. It's our weekly read on the infosec landscape, with a bias toward the thing we care most about: how attackers borrow the reputation of legitimate infrastructure so their traffic looks normal. Every item links the original reporting, and any claim about our own API is run against it live and labelled.