Google reports UNC6508 used Workspace rules to steal email
News

Updated on 18 Aug 2026: We updated this report with Google's full hardening guidance and clearer investigation steps.
Google reported on June 15, 2026 that UNC6508, a PRC-nexus threat actor, used Google Workspace content compliance rules to silently BCC matching emails to an attacker-controlled Gmail account after gaining administrator access. The most important email security lesson is simple: a legitimate routing or compliance rule becomes an exfiltration channel when an admin account is compromised.
The Google Cloud Blog says the campaign targeted North American academic, medical, and military research organizations. The attack path started with externally facing REDCap servers, moved through INFINITERED malware and harvested credentials, then reached an administrator account that had enough authority to change mail compliance behavior.
This is not an inbox placement story. DMARC, SPF, and DKIM still matter, but they do not prove that an administrator has not added a hidden BCC or forwarding rule inside a cloud mail environment. Google Workspace admins, enterprise mail admins, research organizations, medical organizations, defense-related organizations, and any team using routing rules should audit administrative mail controls immediately.
The operational risk
Email authentication protects domain identity. It does not inspect every administrative rule that can duplicate, redirect, quarantine, rewrite, or forward mail during Workspace processing.
- Admin compromise: An authenticated administrator can create a rule that looks like normal mail governance but copies sensitive mail externally.
- Authentication gap: A message can pass DMARC while a Workspace rule separately copies it to an unauthorized recipient.
What Google reported
Google Threat Intelligence Group attributed the activity to UNC6508 with high confidence. The reported campaign began with compromises of REDCap servers used by medical and research organizations. Google said the earliest known compromise occurred in September 2023, and in one medical research university case, activity continued through November 2025.
Google did not confirm the initial access method, identify a specific CVE, or name affected REDCap versions. It did observe UNC6508 probing vulnerable legacy versions, which is why removing old installations matters alongside patching the current version.
The server-side malware, named INFINITERED, captured REDCap usernames and passwords and persisted through REDCap upgrades. That persistence matters because a routine upgrade does not clean up an environment if old versions remain reachable or if the upgrade process has already been altered.

Flowchart showing REDCap compromise leading to Workspace rule BCC forwarding.
The email-specific step came later. Google said UNC6508 used overlapping credentials harvested through REDCap to access an administrator account, then created a domain content compliance rule named Patroit. The rule used about 150 regular-expression search terms and email addresses to inspect sent or received messages, then silently BCC-forwarded matches to a Gmail account controlled by the threat actor. Content compliance rules apply by default to all users in a selected organizational unit, so admins should check both the matching logic and the rule's scope.
The matching terms pointed to collection priorities that included geo-strategic policy, military strategy, advanced technology, and medical research. Google described this compliance-rule exfiltration as novel for PRC-nexus actors it had observed. Google also said it disabled the Gmail account used for exfiltration, notified affected organizations, and disrupted infrastructure tied to the activity.
Why the rule abuse matters
The uncomfortable part is that the abused capability was legitimate. Content compliance, routing, forwarding, and BCC rules exist because organizations need to archive mail, route regulated messages, apply policy controls, and support investigations. The same control plane also gives a compromised administrator a clean path to copy email without deploying a mail server implant.
That changes the defender's question. The question is not only whether messages are authenticated. It is also whether the mail platform is configured to send copies where nobody expects them to go. A perfect DMARC result on a message does not make an administrator-configured route trustworthy.
Authentication controls
Authentication proves whether a message lines up with the sending domain's published policy and cryptographic identity.
- Scope: Checks domain identity and authorization at message evaluation time.
- Evidence: Produces DMARC aggregate data, pass and fail results, and source visibility.
- Limit: Does not prove that mail routing rules are approved or unchanged.
Administrative routing
Routing controls decide where mail is copied, redirected, quarantined, rejected, or modified inside the mail administration layer.
- Scope: Applies after an administrator configures policy for users, groups, or organizational units.
- Evidence: Leaves traces in admin audit logs, rule inventories, and message trace data.
- Limit: Becomes dangerous when an administrator session or credential is compromised.
This is a control-plane incident. The threat actor did not need to break SPF or DKIM to copy sensitive mail. It used administrative access to change how legitimate mail was handled.
Checks for Google Workspace admins
Workspace admins should start with rule inventory, then move to logs. The immediate goal is to find any rule that sends mail outside the organization, especially through BCC, forwarding, redirection, external recipients, regular expression matches, or broad organizational-unit scope.
|
|
|
|---|---|---|
Rules | External BCC | Copies mail without user action. |
Rules | Forwarding | Routes messages outside policy. |
Rules | Patroit | Matches Google's named rule. |
Logs | Admin changes | Shows who changed mail policy. |
Access | 2SV | Reduces credential replay risk. |
SIEM | Workspace logs | Keeps changes visible. |
Priority checks for Workspace rule abuse
Review every content compliance rule and routing rule, not only the newest ones. Look for descriptions that sound normal but include external copy actions. Review regular expressions and keyword lists, because the Google report says UNC6508 used matching logic to select messages tied to targeted research and defense topics.
Then review admin audit logs for rule creation, rule edits, administrator sign-ins, unusual source IP addresses, and changes made outside normal maintenance windows. A rule can be deleted after collection, so logs matter even when today's rule inventory looks clean.
A practical audit order
- Rules: Export or document all content compliance, routing, forwarding, and BCC rules.
- Recipients: Flag any external destination, personal mailbox, or address that lacks a current business owner.
- Logs: Review admin audit events for creation, edits, deletion, and scope changes.
- Admins: Require phishing-resistant 2SV and remove shared or reused administrator credentials.
- Monitoring: Send Workspace admin and mail logs into the SIEM with alerts for external routing changes.
Hardening and containment for admin compromise
Rule audits show what changed, but admins also need controls that reduce the chance of stolen credentials or sessions reaching the Workspace control plane. Apply these controls first to super administrators and accounts that handle sensitive research or defense data.
- Admin authentication: Enforce phishing-resistant 2SV for administrator accounts, including sign-ins through a third-party identity provider.
- Session protection: Use Device Bound Session Credentials with context-aware access on supported devices to reduce reuse of stolen session cookies.
- Data controls: Define data loss prevention rules that block or alert on unauthorized external sharing of sensitive data.
- Credential detection: Enable password leak alerts and investigate any credential reuse across REDCap, directory services, and Workspace administration.
If an unauthorized rule is found, preserve its configuration and related audit events before containment. Suspend the affected admin account, revoke active sessions, rotate exposed credentials, remove the rule, and identify which messages matched its conditions. The matched data determines the notification, legal, and regulatory response.
REDCap and INFINITERED checks
Organizations using REDCap should treat this as more than a mail administration issue. Google said UNC6508 consistently targeted externally facing REDCap servers, used INFINITERED to capture credentials, and persisted through upgrades by altering legitimate REDCap files.
Patch current REDCap installations, remove old REDCap versions instead of leaving them side by side, and scan for INFINITERED with Google's published YARA rule and indicators. Check for the help.php web shell, which Google identified as a persistence file and uploader. If the same credentials were used across REDCap, directory services, cloud admin accounts, or email administration, rotate them and treat related sessions as suspect.
Selected indicators from the Google reporttext
Email: BebitaBarefoot774[@]gmail[.]com IP: 23.169.65.49 Persistence file: help.php GUID: b49e334d-9c01-463e-9bc5-00a6920fb66e Session prefix: xc32038474a Rule name: Patroit
Run two investigations in parallel. One team should validate REDCap integrity, remove persistence, and check host indicators. Another team should review mail administration, admin identity, audit events, and all external mail copy paths. The two investigations connect through credential reuse.
Response priority
A simple way to sort what needs immediate review after this report.
Immediate
Today
External BCC, external forwarding, admin-rule edits, and REDCap indicators.
High
24-48 hours
Admin 2SV gaps, reused credentials, and missing Workspace log ingestion.
Ongoing
Weekly
Authentication baselines, domain monitoring, and scheduled rule review.
Where Suped fits
Suped does not replace a Workspace admin audit. The rule abuse described by Google sits inside the mail administration control plane, so the first step is to inspect content compliance, routing, forwarding, BCC rules, administrator activity, and REDCap exposure.
Suped covers the surrounding domain-authentication workflow: keeping DMARC policy visible, finding SPF and DKIM issues, detecting authentication failures, watching for domain health changes, and turning report data into remediation steps. After an incident, clean mail administration should be paired with verified domain identity.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
After reviewing Workspace rules, run a broad check with Suped's domain health checker to confirm the public authentication posture still matches what you expect. For ongoing visibility, Suped's DMARC monitoring gives teams a single place to track authentication sources, policy movement, and domain-level changes.
A controlled message test has a place, but it is not a substitute for an admin audit. Use Suped's email tester to inspect headers and authentication results for a real message, then verify separately that no Workspace rule is copying mail to an unauthorized destination.
For MSPs and larger organizations, Suped centralizes DMARC reporting, authentication alerts, domain health checks, and blocklist (blacklist) monitoring. This keeps the domain-authentication investigation in one workflow while security operators focus on identity, admin logs, and routing governance.
What to do now
The right response is a targeted review. Search for unauthorized external BCC and forwarding behavior, validate every content compliance rule, review administrator audit logs, and make sure Workspace logs reach the SIEM. If REDCap is in use, patch it, remove older versions, and scan for INFINITERED indicators.
Email security has to cover both identity and administration. DMARC, SPF, and DKIM protect the trust boundary around the sending domain. Admin audit, strong authentication, unique credentials, and rule review protect the mail system when an administrator account is compromised.

