UNC6508 Exfiltrated Through a Gmail Compliance Rule. The Audit Event Your Detection Uses Retires After August

By AutoCypher · 0 days ago 29 Jul 2026

Someone with administrative access to a Google Workspace tenant turned on a single mail-handling rule — the kind of setting a compliance team uses to route copies of mail to an archive — and pointed it at a Gmail address they controlled. From then on, every message matching a list of keywords was quietly copied out of the organization as it was sent or received. There was no malware on anyone’s laptop to find, no suspicious outbound connection from the network to notice, and nothing in any user’s own mail settings to look wrong, because the copying was done by Google’s servers on Google’s side of the line. That is the exfiltration channel Google Threat Intelligence Group documented in its June 2026 report on UNC6508, a PRC-nexus actor grinding through North American academic medical institutions since September 2023. If you run Workspace, two things follow: detections built on per-user forwarding settings, inbox rules, endpoint activity, or network egress are all watching the wrong layer to catch this one, and the admin-audit event family you would use instead is halfway through a migration that retires the legacy events after August 2026.

Concretely: the rule was a domain-level Gmail content compliance rule named “Patroit” (their spelling, and yes that matters), matching a hand-maintained regex list and taking a blind-carbon-copy action to an attacker-controlled Gmail address. It sits in the mail-flow policy engine, above the mailbox — which is the whole problem, because the widely available SaaS mail-exfiltration detection content targets the user layer below it. The authoritative record of its creation is the Workspace admin audit log event CREATE_GMAIL_SETTING carrying SETTING_NAME=CONTENT_COMPLIANCE, and that whole Gmail-specific event family is being renamed out from under whatever detection you have for it, with the legacy names going dark after August 2026.

TL;DR

UNC6508 exfiltrated mail from a Workspace tenant with a single domain-level Gmail content compliance rule (“Patroit”) that silently BCC’d matching messages to an attacker-controlled Gmail address — invisible to per-user forwarding reports, inbox-rule detections, and outbound network correlation, since the copy is generated by Google’s own infrastructure.

GTIG could not confirm how initial access happened; what it documented is UNC6508 probing vulnerable legacy REDCap versions kept installed alongside current ones, then a help.php web shell and later the INFINITERED implant. INFINITERED hooks the upgrade process and rewrites the incoming Upgrade.php, so an in-place upgrade can reinstall it — search the filesystem for the GUID delimiter and run Google’s G_Backdoor_INFINITERED_1 YARA rule against the application files, and query the REDCap sessions table for the xc32038474a session-ID prefix, which is a database artifact rather than a file one. Google’s own remediation is to fully update, completely remove older versions, and scan; treating a confirmed compromise as a rebuild-and-selective-restore is my recommendation on top of that, not Google’s instruction.

The authoritative configuration-change record is the Workspace admin audit log event CREATE_GMAIL_SETTING (plus CHANGE/DELETE), keyed on SETTING_NAME=CONTENT_COMPLIANCE — note the legacy event documents no NEW_VALUE payload field, so keep USER_DEFINED_SETTING_NAME and SETTING_DESCRIPTION, which is where a rule name like “Patroit” lives. Baseline the change rate in your own tenant before setting thresholds.

Google is collapsing those events into CREATE_APPLICATION_SETTING / CHANGE / DELETE with legacy names going dark after August 2026: Google says saved investigations built on legacy events “will stop working” then without describing what that looks like in the UI, so treat an unchanged one as unreliable rather than reading an empty result as “nothing matched” — and auto-migrated alert rules with two conditions may fire when only one is true. Write the detection against both families now, while both schemas still emit and you can diff them.

Tune out DLP, archiving, and MSP delegated-admin rules, but never tune away rule creation by admins outside the mail-flow owners, or a free-webmail BCC destination on a broadly scoped rule — treat that as high severity requiring documented approval, since it is the condition that most directly matches this campaign; the Exchange Online equivalent is New-TransportRule/Set-TransportRule in the UAL, where the parameter blob is directly matchable.

So the timing on this one is bad in a specific way. If you build the detection only against the legacy event family your tenant is still emitting today, it becomes ineffective after August 2026 — and Google does not say whether an affected investigation or downstream rule fails with a warning, an error, or just an empty result. That uncertainty is the reason to write it against both families now rather than to find out later which one it was.

The exposure was a research-managed server with retained legacy REDCap versions

REDCap is the PHP-based electronic data capture platform that runs a large fraction of clinical research in North America. Ownership varies — research computing, a clinical or academic department, or central IT, depending on the institution — and which of those owns it is worth establishing rather than assuming, because it determines whose patch calendar the thing is on. What is a property of the platform itself is the design decision that should make your teeth itch: administrators can keep legacy versions running side by side with the current one, which is an inventory and remediation problem before it is a vulnerability.

Be precise about what is known here, because the tidy version of this story is not what Google published. GTIG states plainly that it “was not able to confirm how UNC6508 initially gained access to the REDCap server.” What it did observe was the actor “probing for these vulnerable legacy versions on several target organizations’ REDCap systems,” and then, post-foothold, a web shell named help.php used for persistence and upload, credential discovery, and about three months later a modular PHP implant Google calls INFINITERED. So the side-by-side legacy installs are a documented exposure and the likely attack surface — they are not a confirmed initial-access vector, and a finding that asserts otherwise is asserting more than the report does.

The scale of the exposed population is the part that should reframe your risk register. Censys scanned for it and, as of June 16, 2026, found just over 8,500 internet-facing REDCap instances: 30.1% identified as 16.0.17, while only 1.18% ran 17.1.3, which Censys described as what “appears to be the latest version available.” That hedge is theirs and worth keeping — Censys noted it is “unclear from REDCap’s website when each of these versions were released,” so treat the version spread as an indicator of drift rather than proof that any given instance is unsupported. About 40% are in the US. If your institution has a research arm, the useful question is not whether the platform is exposed somewhere in the sector but whether your own inventory accounts for the instances you have — including any legacy versions retained beside them, which is the part a CMDB entry for “the REDCap server” tends not to capture.

Downstream of that: the University of Nebraska Medical Center disclosed in April 2026 that unauthorized REDCap access spanned September 20, 2023 through February 3, 2026, and that its investigation “was unable to determine whether any personal information housed in REDCap was actually accessed.” That start month falls in the same month as GTIG’s earliest known UNC6508 compromise. UNMC made no attribution, and the date overlap on its own does not establish a connection.

Upgrade interception is why “we patched it” is not an answer

INFINITERED’s dropper hooks the REDCap upgrade process. When the platform pulls a new version’s zip, the implant reads its own file contents, extracts the block between a fixed GUID delimiter (b49e334d-9c01-463e-9bc5-00a6920fb66e), and rewrites the incoming Upgrade.php so the payload comes back on the other side. There’s even special-cased handling for AWS Elastic Beanstalk deployments, which tells you the operators had done this on cloud-hosted instances enough times to bother.

The credential harvester lands in the auth path, grabs plaintext username/password from the POST, encrypts them with the application’s own encryption routine, and writes them into REDCap’s legitimate sessions table with a xc32038474a session-ID prefix. Backdoor commands arrive in an HTTP cookie named REDCAP-TOKEN. Every artifact is inside a file REDCap already owns, in a table REDCap already writes to, over a cookie the application already sets.

Which means an in-place upgrade cannot be treated as eradication on its own. The implant trojanizes files the application legitimately owns and reinjects itself into the incoming upgrade, so the maintenance window is a reinstall opportunity for the backdoor as much as for you.

Separate what Google published from what I’d do about it, because the post-compromise call is mine and not theirs. Google’s remediation guidance is to fully update REDCap to the latest version, ensure older versions are “completely removed,” and scan REDCap servers for INFINITERED using its published YARA rule and IOCs. Match the hunt to where each artifact actually lives, because these are two different searches: the GUID delimiter is a file artifact, so search the filesystem for it and run G_Backdoor_INFINITERED_1 against the application files; the xc32038474a prefix is a database artifact, so query the REDCap sessions table for session IDs beginning with it rather than grepping the webroot, where it will not be sitting unless you happen to have DB dumps or logs on disk as text. My addition, for a confirmed compromise rather than a precautionary sweep, is that rebuilding from trusted source and restoring data selectively is the safer path than trusting an in-place upgrade of a host whose implant is specifically built to survive upgrades. Google does not prescribe that rebuild; treat it as incident-response judgment.

The rule that beat every forwarding detection you have

UNC6508 harvested credentials from REDCap and used credential reuse to reach additional enterprise accounts (people reuse across security domains, this is not news), eventually landing on an administrator account with enough authority to create the rule. Worth keeping the terminology exact, because “replay” means something narrower in authentication: what GTIG describes is stolen username-password pairs working somewhere else, not the reuse of an intercepted authentication exchange or token. Worth being exact on that, since the privilege level drives your scoping assumptions: GTIG’s report describes an “administrator account,” an “enterprise administrator account,” and a pivot to a “domain admin account” — it does not establish in the public write-up that the account held Workspace’s specific Super Admin role, so don’t build a finding on that assumption. Google’s timeline puts the admin access more than a year after initial compromise. Then they created one content compliance rule.

Content compliance is a legitimate Gmail feature — the thing you configure under Apps → Google Workspace → Gmail → Compliance to enforce DLP or route mail to an archive. It matches on regex against message content and headers and takes an action. One of those actions is a blind carbon copy to an arbitrary address. By default the rule applies to every user in the organizational unit it’s attached to, and child OUs inherit it unless someone has explicitly overridden them — so a rule planted high enough in the tree covers the whole org.

The “Patroit” rule matched keyword and email-address patterns spanning geo-strategic policy, military strategy, advanced technology, and medical research, plus professional email addresses and phone numbers of people working in those areas. Google notes several terms were misspelled — as was the rule name itself — which reads as a list maintained by hand over a long period. Matches went out as a silent BCC to a Gmail account obtained through a bulk account-creation service.

Now think about where your existing SaaS email-exfil detections live. The common ones watch the user layer: Email Forwarding settings, New-InboxRule, external auto-forward policy, mail client rule creation. None of those identify the creation of a domain-level compliance rule, because the rule is administered outside the user’s mailbox, in the mail-flow policy engine. GTIG describes the resulting forwarding as silent, so don’t plan on the ordinary user-visible forwarding artifacts exposing it — lean on tenant configuration review and admin-audit telemetry instead. And because the copy is generated by Google’s own infrastructure rather than by a client on your network, there is no anomalous outbound session from your estate to correlate on. I’d stop short of claiming no message-level or delivery-side evidence could ever exist anywhere in Workspace; the defensible claim is that the artifacts most teams have wired up are the wrong ones, and the configuration layer is where this is actually visible.

The admin login that created it came from 23.169.65.49, a compromised ASUS router inside a US residential range — UNC6508 routed exclusively through US-based obfuscation infrastructure. Your impossible-travel and foreign-geo admin rules were never going to be the thing that caught this.

What the detection is, and what breaks in August

The event you want in the Workspace admin audit log is CREATE_GMAIL_SETTING (and CHANGE_GMAIL_SETTING / DELETE_GMAIL_SETTING), keyed on SETTING_NAME=CONTENT_COMPLIANCE. Be careful what you expect that event to hand you, because this is where a lot of draft detections quietly assume a field that isn’t there. Google documents exactly four parameters on CREATE_GMAIL_SETTING: SETTING_NAME, SETTING_DESCRIPTION, USER_DEFINED_SETTING_NAME, and ORG_UNIT_NAME. There is no NEW_VALUE on it — that pair of old/new value fields belongs to CHANGE_EMAIL_SETTING, a different event. So you do not get the rule’s regex list or its BCC destination out of the legacy creation event. What you get is that a content compliance rule was created, in which OU, and under what name — and USER_DEFINED_SETTING_NAME is the field that would have carried the string “Patroit.” To see the match expressions and the BCC destination you have to go to the configuration itself, not the audit trail. The Admin console shows it directly. Programmatically, Google lists gmail.content_compliance among the Policy API’s supported settings, exposing content_compliance_rules with their conditions and consequences — read-only, since that setting is documented as not supporting mutation, which is fine for the inventory sweep this calls for. Confirm your edition, method availability, and returned fields before you build tooling on it, and don’t reach for the Gmail API here: its user-level filters are a different object than a domain content-compliance rule. If you’re pulling via the Reports API it’s applicationName=admin. In Splunk with the Splunk Add-on for Google Workspace that’s the gws:reports:admin sourcetype; in Google SecOps it comes through as Workspace activity.

The volume is usually the good news. Content compliance and routing rule changes tend to be low-volume next to ordinary administrative churn, which is what makes this one of the cheapest high-signal detections available in Workspace. But the actual rate is tenant-dependent and I’m not going to invent a number for yours — measure creation, modification, and deletion frequency in your own environment across a few months before you set severity or suppression thresholds.

The bad news is that Google is renaming these events. The events[].type value EMAIL_SETTINGS becomes APPLICATION_SETTINGS, and the Gmail-specific event names collapse into the generic CREATE_APPLICATION_SETTING / CHANGE_APPLICATION_SETTING / DELETE_APPLICATION_SETTING family, where the Reports API documents APPLICATION_NAME as the parameter carrying the application’s name — that is what keeps your rule from matching a Drive or Calendar setting change. One caveat on field naming: the same discriminator surfaces under different labels depending on where you read it, and Google’s migration guidance writes the Security Investigation Tool condition as Setting Application IS Gmail. Confirm the normalized name in whichever representation you actually query — Reports API, SecOps, BigQuery export, or a third-party parser — before you ship the rule.

Setting identifiers change too, and this is the part to be careful about: there is no clean one-for-one replacement for SETTING_NAME=CONTENT_COMPLIANCE. Google’s migration table maps that single legacy setting onto more granular application-settings identifiers — a content-compliance setting exposing its rules through nested content-compliance metadata, and separately a rule-state identifier tracking whether a rule is enabled. So the legacy predicate your detection matches on decomposes into several, and the mapping is a schema transformation rather than a rename. Read the identifiers out of the table yourself, and confirm what your own ingestion path actually emits — Reports API, SecOps, BigQuery export, or a third-party parser will each present these differently, and a flattened rendering of that table is easy to mistake for a literal field value. There is one genuine improvement buried in the migration — unlike the legacy creation event, the application-setting events do document OLD_VALUE and NEW_VALUE, so the payload visibility the legacy schema never gave you arrives on the other side of the cutover. Legacy and new formats coexist right now, and after August 2026 only the new ones survive — across Reports API, SecOps, and the BigQuery export.

Google says saved investigations “will continue to work, but they will be based on legacy events and will stop working after August 2026.” Read that carefully, and note what it does not say: Google does not describe what “stop working” looks like from the analyst’s seat — whether you get an error, a warning, or simply an empty result set. I’m not going to assert the failure presentation I’d bet on. The operating conclusion holds either way, and it’s the conservative one: after the cutoff, an unchanged legacy investigation is unreliable evidence, so an empty result cannot be read as “nothing matched.” Verify before that distinction matters in an actual incident. Alerting rules are auto-migrated, but Google’s own guidance flags that migrated rules with two conditions may fire when only one is true, because breaking columns are getting removed from rule conditions. So the failure mode is bimodal, and the two halves fail in opposite directions: your saved investigations become untrustworthy in a way you have to go check for, and your migrated alerts can get louder and less accurate on their own. Go look at your rules now, while both schemas are still emitting and you can diff them against each other.

Write the detection against both event families, keep the OR in place through the fall, and set a reminder to strip the legacy branch rather than letting it rot in the rule for four years the way the last deprecated sourcetype did.

Where the false positives come from

Content compliance rules are load-bearing infrastructure in a lot of tenants, so a naive “any compliance rule created” alert is not free.

The first tuning round is almost entirely third-party integrations. Some DLP, email-security, archiving, and supervision products legitimately create or modify Gmail compliance and routing rules as part of their setup — Nightfall publicly documents a content-compliance-rule deployment as its Gmail monitoring configuration. I’d resist the urge to pre-allowlist the rest of the category by brand, though, and I’m not going to list vendors as equivalent here: integration models differ by product, edition, and architecture — API-based, journaling, routing, content compliance, or an upstream gateway — so a rule that is normal for one product is anomalous for another. Verify how each product in your tenant actually integrates, from its documentation and from the changes you can observe, before it goes on an allowlist. The archiving and supervision tier deserves particular attention because those can legitimately route copies to an external domain, which is the same shape as the malicious rule. If you alert on “BCC destination outside the primary domain” without allowlisting the archive tenant, you will page someone at 3am for the compliance team’s journaling config.

Two other sources worth carving out before go-live. MSP- and reseller-managed tenants generate delegated-admin changes that look attacker-shaped because the acting principal is a privileged admin you’ve never met. And the OU-scoped rule created against a single test OU during a vendor PoC will fire and get closed as benign three times before someone finally documents it.

What you should not tune away: rule creation by an admin account outside the small set of people who own mail flow, and any destination that is a free webmail domain. Gmail, Outlook.com, Proton, the usual set. An enterprise archive destination is a corporate domain. A free-webmail BCC target on a broadly scoped compliance rule should be high severity and should require explicit, documented approval to stand — legitimate exceptions can exist, but they ought to be rare, narrowly scoped, and traceable to a named business process. It is also the condition that most directly matches what UNC6508 actually did, since the destination account was a Gmail address obtained through a mass-creation service.

The same hole exists in Exchange Online, with better logs

If you’re on M365 the equivalent is a mail flow (transport) rule with a BlindCopyTo or RedirectMessageTo action. The Unified Audit Log records New-TransportRule and Set-TransportRule, and — this is where Microsoft is genuinely ahead — the parameter blob is inspectable, so you can match directly on Parameters.BlindCopyTo and regex the destination. Splunk’s M365 email-collection hunting writeup covers the query shape, and Elastic ships a prebuilt rule for transport rule creation. Neither is exotic. The reason this technique worked against a Workspace tenant and keeps working is that the Workspace-side detection content is thinner and the audit schema is a moving target.

One caveat on the M365 side that people miss: transport rule changes made through the Exchange admin center and through the PowerShell module both land in the UAL, but UAL delivery is not a safe basis for a strict real-time correlation window. Build the detection with enough lookback and with deduplication to absorb late arrival, and measure the actual latency in your own tenant rather than assuming a documented figure holds.

Control mapping

This is an AC-4 problem in the purest sense: an unauthorized information flow control policy, installed by an authorized-looking principal, operating exactly as designed. The audit story is AU-2 and AU-12 (are Workspace admin log events even in your index?) plus AU-6(3) for correlating admin config changes against the identity that made them — concretely, CREATE_GMAIL_SETTING today and CREATE_APPLICATION_SETTING after the cutover, joined to the acting admin and the source address. The schema migration is an AU-6 maintenance obligation you now own.

The rest maps cleanly enough. CM-3 and CM-5(1) cover change control over tenant-level mail flow policy, which in most shops has no change control at all because it lives in a SaaS console rather than in Terraform. For the side-by-side legacy REDCap finding, the safer primary mappings are CM-2 (Baseline Configuration), CM-6 (Configuration Settings), SI-2 (Flaw Remediation), and RA-5 (Vulnerability Monitoring and Scanning) — unauthorized or undocumented legacy installations, secure configuration, and the flaw-remediation and scanning obligations around them. Reach for SA-22 (Unsupported System Components) only where you have actually confirmed the retained version is unsupported by the supplier or no longer receiving security maintenance; “legacy,” “outdated,” and “unsupported” are three different assessment conditions, and Censys was explicit that REDCap’s release chronology is unclear from public sources. For the credential-reuse pivot that preceded the rule, be precise about which control does the work: IA-2(1) is Multi-factor Authentication to Privileged Accounts, and it does not itself require phishing resistance. Pair it with IA-2(8), Access to Accounts — Replay Resistant, and then with an authenticator implementation that is actually phishing-resistant, which is an implementation property rather than something either enhancement mandates on its own. SI-4(18) and SC-7(10) for outbound content monitoring, though be honest in the assessment about what those buy you when the exfil path is the mail provider’s own policy engine.

RA-5 gets a mention too, mostly to note that a scanner pointed at your research subnet is not going to tell you that a PHP file inside a legitimate application has been trojanized in a way that survives its own upgrades.

Go pull the domain-level compliance rule list for your tenant today — under Gmail → Compliance, in every OU including the ones the research group owns. The per-user forwarding report is a different artifact and it will not show you this. Then check who created each one and when. The whole check takes ten minutes and most teams will find nothing. Do it anyway. The ones that find something will find it in an OU nobody claimed.

Sources

This post was engineered and validated through a multi-agent AI workflow — drafted, adversarially reviewed by several independent models, checked against primary sources, and given a human review before publishing. See an inaccuracy, or found this useful? Leave a comment below — corrections and feedback are read and shape what comes next.