There is a pattern in this week’s threat intelligence that deserves attention beyond the individual stories.
AccountDumpling routes phishing delivery through Google AppSheet, exploiting the trusted email sending infrastructure of one of the world’s largest technology companies. EtherRAT encodes C2 commands in Ethereum blockchain transactions, retrieving them via public nodes like Cloudflare’s Ethereum gateway. DEEP#DOOR uses Cloudflare Tunnel to proxy command-and-control traffic, making all attacker communication appear as legitimate Cloudflare infrastructure traffic. TeamPCP’s CanisterSprawl exfiltrated stolen credentials to an Internet Computer Protocol blockchain canister. Tropic Trooper used GitHub’s REST API as a C2 relay.
Each of these is a different attack in a different campaign. Each arrives at the same strategic insight: the fastest route past enterprise security controls is through infrastructure that defenders cannot block.
Why This Approach Works
Enterprise network security is built on a model of infrastructure reputation. Good IP ranges, good domains, clean sender reputation — these are the signals that mail gateways, web proxies, DNS filters, and intrusion prevention systems use to distinguish legitimate traffic from malicious traffic. The model works reasonably well against attackers who operate their own infrastructure: C2 servers, phishing domains, malware distribution hosts. These can be taken down, blocked, and sinkholed.
Cloudflare serves roughly a third of the web’s HTTP traffic. Google’s email infrastructure sends several billion emails per day. Ethereum’s public node providers are used by a significant fraction of the world’s DeFi applications, developer tools, and blockchain projects. None of these can be blocked without substantial operational disruption — and the attacker knows this before they choose the relay.
The defensive implication is uncomfortable: the same properties that make these platforms trustworthy as infrastructure (ubiquity, reliability, legitimate use at massive scale) are precisely what makes them useful for attack delivery. Trust is the attack surface.
The Controls That Work and the Controls That Don’t
The standard enterprise response to a new phishing technique is to update spam filter rules to catch that specific pattern. The standard response to a new C2 technique is to add a signature to the network IDS. Neither works when the technique routes through platforms that are whitelisted at the infrastructure level.
What does work is a different class of control entirely — one that doesn’t try to distinguish good traffic from bad at the infrastructure layer but instead asks behavioural questions:
For phishing: Does the email contain a link to a domain that is not the organisation the email purports to be from? The AccountDumpling emails originated from legitimate AppSheet infrastructure, but the phishing link went to a non-Facebook domain. A control that checks destination link domain against claimed sender identity — regardless of sender infrastructure reputation — would catch this.
For C2: Is an endpoint process querying Ethereum JSON-RPC endpoints? There is a legitimate answer to this question for some organisations (DeFi teams, blockchain developers), but for an enterprise finance department or a legal firm, a workstation querying Infura’s Ethereum API is anomalous regardless of whether Infura is a reputable service. Endpoint-level monitoring of which applications connect to which external services can detect this without any knowledge of the specific malware.
For tunnelling: Is cloudflared.exe running as a child process of a PowerShell script on a managed endpoint? Cloudflare Tunnel is legitimate software with legitimate uses — deployed as a managed service. When it appears as a process spawned by a user-space script, that’s anomalous regardless of Cloudflare’s reputation.
The pattern is consistent: detection moves from “is this infrastructure legitimate?” to “is this behaviour expected for this endpoint in this context?”
What Needs to Change in the Security Architecture Conversation
Most enterprise security architecture conversations about trusted platforms focus on access control — who can use Google Workspace, who can access GitHub, which Cloudflare-hosted sites are permitted. The emerging threat model requires a different conversation about abuse patterns within trusted platforms, which is a harder problem.
It requires telling IT leadership that “we blocked Google AppSheet” is no longer a coherent response to an AppSheet-based phishing campaign — because blocking AppSheet would also break every organisation that uses it legitimately. It requires explaining that the question “is this a trusted service?” and “is this behaviour anomalous?” are different questions that require different controls.
It also requires honest acknowledgement of the detection gap. Most organisations cannot currently answer “which endpoints are querying Ethereum node providers?” or “which processes are spawning cloudflared?” or “which incoming emails from Google infrastructure contain links to non-Google destinations?”. Building those detection capabilities is not complex work, but it requires someone to decide that the question is worth asking.
The attackers have already made their strategic choice: route through what defenders can’t block, and the perimeter collapses. The defensive response needs to catch up to that conclusion.
Share this article