# Reputation Radar #7: No Attacker Domain Required > Two campaigns this week ran their command-and-control entirely inside services a SOC can't block: a Python implant living inside Microsoft 365, and an espionage kit relaying through Google Apps Script. Plus a 14,000-camera botnet and a vCenter bug under active exploitation. - Published: 2026-08-19 - Author: Reput.io Team - Tags: Threat Intelligence, Infrastructure Reputation, SOC, Weekly Report - Canonical: https://www.reput.io/blog/reputation-radar-07 --- Ask a SOC where the callback went and you usually get a domain and an IP, and from there you can decide how worried to be. Two write-ups this week take that away from you on purpose. In both, the command-and-control channel never touches an address you could reasonably blocklist, because it terminates inside Microsoft and Google. There's **no attacker-owned domain to flag**, which is not an accident of the design. It is the design. ## The implant that lives inside Microsoft 365 Ontinue's Cyber Defense Center pulled apart a Python implant they're calling **TWINLOOT** after finding it mid-incident in July, and the summary they landed on is the honest one: it hides its entire C2 inside trusted Microsoft services ([Ontinue](https://www.ontinue.com/resource/python-implant-hiding-its-entire-c2-inside-microsoft-365-azure/)). Tasking runs through a **SharePoint Online folder used as a dead drop**, polled every 15 seconds or so through the Microsoft Graph API. Interactive access rides Microsoft Teams TURN relays over WebRTC. And the Graph traffic itself is fired from a headless copy of the victim's own Edge browser, so on the wire it looks like `msedge.exe` talking to Microsoft rather than a Python process talking to anywhere. The detail that makes it a reputation story rather than just clever tradecraft: the implant authenticates to an **attacker-controlled Azure tenant**, not the victim's, so it generates no sign-in or audit events in the victim's own Entra ID logs. The primary channels all terminate in Microsoft IP space. There is, by default, nothing attacker-shaped in the traffic for a network filter to catch. So we did the obvious thing and asked our own API what it thinks of the destinations. `graph.microsoft.com` and `login.microsoftonline.com` both come back **likely_benign, action allow**, tagged as Microsoft's own identity and API surface. That is the correct answer. Those really are first-party Microsoft endpoints, and a feed that flagged them would be crying wolf on half the traffic in every enterprise. The uncomfortable part is that the correct answer is also the whole opening: **when the destination is genuinely Microsoft, a reputation check on the destination is asking the wrong question.** Ontinue's own advice points at the right one, which is behavioral: unusual Graph calls, odd OAuth consents, SharePoint and Teams patterns that don't match a human. Where reputation does bite is off to the side. Ontinue notes the operator staged fallback infrastructure over about seven weeks, using **aged, drop-caught domains and a hosting ASN already flagged for credential-attack campaigns**. The clean primary path gets all the attention, but the backup path still stands on rented ground with a history, and that history is exactly what an ASN and domain-age signal are for. ## The espionage kit that rides Google's script host The second one is Kaspersky's GReAT on **Project CAV3RN**, a modular espionage framework hitting targets in Israel ([Securelist](https://securelist.com/project-cav3rn-continues/120991/)). The new piece is a C2 module that, in Kaspersky's words, "uses DNS A-record responses to choose between direct HTTPS and a Google Apps Script relay for each transaction." Per beacon, the malware decides whether to talk straight to its server or to launder the exchange through `script.google.com`. The crew did the same trick with **Outlook calendar events** before this, so the pattern is deliberate and repeated: pick a Google or Microsoft service everyone's firewall already waves through, and let the C2 ride it. Here the API answer is different, and the difference is worth a second. `script.google.com` comes back **investigate**, not benign. It resolves to google.com and ranks as a top-50k domain, which is precisely the kind of "known good" that tempts you to move on, so the note we return is that a popularity ranking says nothing about what code is actually running behind an Apps Script URL. That is a fairer call than the Microsoft case got, and not because our feeds like Google less. It's that Apps Script is a general-purpose place to run someone else's code on a Google domain, closer to rentable hosting than to a fixed first-party API, so the honest verdict lands on "go look" rather than "allow." ## The thread for a SOC Put the two next to each other and the shared move is clear: don't defeat the network reputation signal, stand behind it. TWINLOOT terminates in real Microsoft space; CAV3RN relays through a real Google endpoint. In both, the domain on the destination is telling you the truth, and the truth is useless for this particular question because the badness is in the behavior wrapped around a legitimate service, not in the address. That is not an argument against reputation, and it's worth being precise about why. A domain or IP verdict answers "is this destination itself hostile," and for first-party cloud the answer is honestly no. The gap it can't close is "is a legitimate destination being abused right now," which is a behavioral question about volume, timing, identity, and consent. The useful reading of both reports is knowing which of your layers owns which question, so the clean `allow` on `graph.microsoft.com` doesn't get mistaken for "nothing to see here." And the reputation layer still earns its place on the edges these operators can't dress up: the aged fallback domains, the flagged ASN, the Apps Script URL that popularity alone can't vouch for. ## Also on the radar - **One operator quietly took over more than 14,000 Dahua cameras** across Ukraine and Russia between mid-June and late July, through a mix of credential brute-forcing and old auth-bypass CVEs (CVE-2021-33044/33045). Hunt.io is tracking it as CameraSwarm ([Hunt.io](https://hunt.io/blog/operation-cameraswarm-dahua-cameras-compromised)). Every one of those is now a trusted-looking device that can be pointed somewhere else. - **A critical VMware vCenter flaw, CVE-2026-59310, is under active exploitation** for reverse SSH persistence; it's a directory traversal in the Syslog Server that an unauthenticated attacker on the network can reach ([BleepingComputer](https://www.bleepingcomputer.com/news/security/critical-vmware-vcenter-rce-flaw-exploited-for-reverse-ssh-access/)). If your vCenter is reachable from anywhere it shouldn't be, this is the week to fix that. - **Gunra ransomware is chaining two Fortinet bugs** (CVE-2024-55591 and CVE-2025-24472) to get into government and critical-infrastructure orgs. It's a RaaS operation built on leaked Conti code ([Infosecurity Magazine](https://www.infosecurity-magazine.com/news/gunra-ransomware-fortinet-flaws/)). Both Fortinet CVEs are the kind that belong at the top of a patch list, not the bottom. - **A backdoored GitHub Action poisoned CI/CD pipelines.** Resecurity attributes a campaign it calls SANDCLOCK to a group tracked as TeamPCP, which tampered with the widely used `aquasecurity/trivy-action` to harvest credentials from build runners ([Resecurity](https://www.resecurity.com/blog/article/the-litellm-supply-chain-attack-teampcp-sandclock-cicd-credential-harvesting-campaign-via-a-backdoored-trivy-github-action)). A pinned, popular Action is another thing teams reasonably trust by default. If you want the longer version of why a legitimate cloud endpoint 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.