For more than a year, a China-linked espionage crew sat inside North American medical, academic, and military research networks and read other people’s email without dropping malware on a single endpoint. They didn’t need to. The victims’ own Google Workspace handed over the messages on a schedule the attackers wrote. This is the part of the cybersecurity story everyone keeps skipping: the most patient adversaries don’t break things. They configure them.

Google’s Threat Intelligence Group calls the actor UNC6508. The way in was a backdoor planted on vulnerable REDCap servers, the open-source data-collection platform that a depressing number of universities and hospitals run themselves on a server somebody set up in 2019. The way out was Workspace mail-forwarding rules. The way to stay undetected was to make sure nothing about the activity looked unusual to a SOC that watches endpoints instead of admin consoles.

The unowned middle of the cyber security stack

Think about what a mail-forwarding rule actually is. It’s a policy object, set in the same admin surface where you onboard employees and reset 2FA. It runs without anyone logging in. It survives password rotations. It doesn’t trip EDR. It doesn’t show up in any phishing report. And in most shops, nobody owns it.

That’s the gap UNC6508 lived in. They didn’t write clever malware to scrape inboxes. They opened the settings, said “copy every inbound message to this address,” and walked away. Nine days later, three months later, fourteen months later, the rule kept doing its job. The same week, a separate story made the rounds: Xavier at SANS ISC flagging another “Evil MSI Background” with malicious base64 content tucked inside the installer’s wallpaper image. Different attack, same instinct. Hide the bad thing inside a legitimate-looking artifact that nobody inspects.

Endpoint telemetry can’t see a Google forwarding rule. Your firewall can’t see it. Your IDS can’t see it. The traffic looks like ordinary outbound Gmail. This is the part of defense in depth that breaks down quietly: every layer was looking for the wrong shape.

Why the rules are a perfect hiding spot

Mail-handling rules combine three properties that adversaries love. They’re persistent without needing a session. They’re invisible to the user whose mailbox they live on, especially when the rule targets administrators or shared mailboxes. And they’re parsed by the platform itself, so the activity doesn’t generate the kind of detection signal SOCs are trained to chase.

Workspace and Microsoft 365 both ship powerful rule engines that were designed for legitimate productivity. Forward to a delegate. Auto-archive newsletters. Bounce sensitive messages. The same engine, in the hands of a patient attacker who got admin via a compromised REDCap credential, becomes a turnkey exfiltration pipeline that needs zero malware and no C2 infrastructure.

And here’s the kicker. If your incident response runbook assumes you’ll find malware artifacts, hashes, indicators of compromise that match a threat-protection feed, you will close the ticket on a clean investigation. The endpoints really are clean. The breach lives in the configuration plane, and the configuration plane is somebody else’s problem until it isn’t.

What to actually do about your mail rules this week

Tool-agnostic, vendor-neutral, and doable before Friday. Pick three.

• Inventory every forwarding and external-routing rule in your tenant. Both platforms expose this via admin APIs. Pull the list. Sort by destination domain. Anything pointing at an external address that isn’t on a known-good list is your first review queue.
• Alert on rule creation and modification, not just sign-ins. Most tenants log these events. Few wire them to detection. Send the events to your SIEM and treat new external-forwarding rules as an incident-response trigger, not a routine config change.
• Disable auto-forwarding to external domains by policy. If a business unit genuinely needs it, exception-list them. The default should be off. This single setting would have made the UNC6508 exfiltration channel useless.
• Audit admin role assignments and service accounts quarterly. The REDCap pivot got the attackers a credential. The damage came from where that credential could reach. Tighten the blast radius. Service accounts with mailbox-rule scope should not exist by default.
• Run brute-force controls on the auth endpoints that admin the rules engine. Edge tools like IPBan and IPBan Pro, fail2ban, or a managed identity provider’s adaptive policies all do the same job: kill credential stuffing against the surface that grants rule-writing power. The attacker who can’t get into the admin console can’t write the rule.
• Add a “configuration plane” tabletop to your IR rotation. Walk the team through a scenario where there’s no malware, no phishing email, no ransomware note. Just a forwarding rule and a quiet leak. See how long it takes them to find it.

None of this is expensive. None of it requires a product. It requires somebody to own the surface, which is the part that keeps not happening.

The pattern is getting louder

Look at the rest of this week’s news with the configuration-abuse lens and the picture sharpens. The Copilot SearchLeak attack abused legitimate microsoft.com URLs and Copilot Enterprise’s own search to exfiltrate data on a single click. The FCC’s proposed burner-phone rule would force telecoms into a new data-collection regime that creates an enormous new attack surface inside legitimate carrier systems. The DOJ’s first TAKE IT DOWN Act seizures, of CFAKE and SOCFAKE, are an enforcement story where the underlying capability, generative image models, remains entirely lawful and accessible. The exploitable thing is not the binary. The exploitable thing is the configuration.

Threat detection programs built around the last decade’s signals miss this category. You can run the best EDR money can buy and never see a rule that auto-forwards email to a Gmail address controlled by an attacker. The detection has to move closer to the policy plane, the identity plane, and the admin console where rules get created.

Security hardening for 2026 looks less like patching and more like configuration governance. Who can create a forwarding rule. What destinations are allowed. Which admin actions trigger an alert. Which service accounts can touch the mail engine. None of that is sexy. All of it is what would have caught UNC6508 in week one instead of month fourteen.

Sources

• Chinese Hackers Abused Google Workspace Rules to Steal Research and Defense Emails
• Chinese hackers breached North American research institutions via REDCap servers
• Evil MSI Background: BASE64 Statistical Analysis
• Copilot ‘SearchLeak’ Attack Allows 1-Click Data Theft
• The FCC Wants to Eliminate Burner Phones
• DOJ seizes CFAKE, SOCFAKE deepfake nude sites under TAKE IT DOWN Act