A recent espionage campaign exposed a technique that sits at the intersection of operational security failure and architectural oversight: using email routing rules themselves as the persistence mechanism. Rather than deploying dedicated malware or jumping between systems, the attackers modified legitimate email forwarding configurations to siphon sensitive messages to external accounts. For infrastructure operators and security teams, this represents a structural weakness that transcends any single platform.
The Credential Theft Entry Point
The initial compromise relied on a familiar but effective pattern: a backdoored REDCap research data platform running on the victims' networks. REDCap is widely deployed in medical and academic environments, making it a natural target for persistent espionage. Once the attackers gained execution on that server, credential harvesting became straightforward.
What made this particular campaign notable wasn't the entry method itself, but what came after. Rather than pivoting laterally through the network via traditional methods—moving between machines, installing webshells, or deploying secondary payloads—the attackers took a different path. They obtained Google Workspace credentials (likely harvested from the REDCap server or through phishing) and used those to access the email environments directly.
Email Rules as Invisible Exfiltration Channels
The technique exploited a fundamental property of email systems: routing rules are legitimate, traffic and are typically less scrutinised than other forms of data movement. By creating or modifying email forwarding and filtering rules within Google Workspace, the attackers achieved several objectives simultaneously.
First, they gained durable access. Email rules persist independently of whether a user changes their password or security settings elsewhere. Second, they achieved stealth. A message copied to an external account via a rule looks like normal email flow to log analysis systems that aren't specifically configured to track rule changes. Third, they solved the exfiltration problem without deploying dedicated command-and-control infrastructure or relying on network-level data theft—they simply let the victim's own email platform do the work.
This approach is particularly insidious because it operates within expected system behaviour. An engineer reviewing logs might see email traffic as normal. A user might not notice their messages being copied if the rule uses the "archive and copy" pattern rather than simple forwarding. And from a network perspective, data is flowing through a first-party service that organisations explicitly trust and typically do not restrict.
Why Infrastructure Operators Should Care
Email security is often treated as a problem for end-user security teams rather than infrastructure operators. But when the email platform is cloud-hosted (Google Workspace, Microsoft 365) and the victim is a research or defence organisation, the distinction blurs. Infrastructure operators managing on-premises systems or hybrid environments need to understand that compromised credentials for SaaS platforms can become backdoors into the entire organisational data flow.
The risk compounds in organisations that treat email access as equivalent to a low-security application. If the same credential can access email and internal systems (via single sign-on), compromising one compromises both. If email is the canonical store of sensitive information, then email security is infrastructure security.
For those running hosting environments that support research, healthcare, or other sensitive workloads, the implication is clear: credential security on ancillary systems—databases, collaboration platforms, data repositories—matters as much as security on primary application servers. A backdoored research platform isn't just a local problem; it's a beachhead for access to everything that platform's users can reach.
Detection and Mitigation Requires Visibility
Detecting this technique requires monitoring at the email rule level, not just at the traffic level. Organisations need to log and alert on email rule creation and modification, particularly rules that forward or copy messages to external domains or unusual destinations. Most cloud email providers support this visibility, but it requires explicit configuration and interpretation.
On the credential side, organisations should assume that any service accessible from a compromised host—including cloud email—is effectively compromised. Enforcing strong credential separation, requiring multi-factor authentication on email access, and using conditional access policies (blocking email login from unusual locations or devices) all reduce the window of opportunity.
The deeper lesson here is about trust boundaries. Email systems sit outside traditional network perimeters, but they're not untrusted. They're first-party infrastructure that organisations explicitly want to be accessible. When that accessibility becomes a liability, it requires architectural thinking, not just patching.
For those operating infrastructure that handles sensitive research, communications, or operational data, this incident is a reminder that security design must account for cloud-based services not as external additions, but as part of the core security model itself.
