INFINITERED Turns Research Apps Into Cloud Mail Risk

Google Threat Intelligence Group published a June 15 report on UNC6508, a PRC-nexus espionage cluster that Google says targeted North American academic, medical, and military research organizations. The confirmed chain is notable because it did not stop at an exposed research application. Google says the actor compromised REDCap servers, deployed custom INFINITERED malware, harvested credentials, pivoted into internal systems, and later abused Google Workspace content compliance rules to silently BCC selected email to an actor-controlled Gmail account.

The practical lesson is that research software and collaboration administration have to be defended as one system. Patching REDCap is necessary, but it is not enough if a harvested account can become a cloud administrator and create a mail rule that turns legitimate compliance tooling into a collection channel. Sensitive research groups should review exposed application versions, administrator authentication, mail routing rules, audit logs, DLP coverage, and session protection together.

GTIG says UNC6508 targeted institutions in the North American academic, medical, and military research community and remained undetected for more than a year in at least one observed case. The report says the actor compromised externally facing web applications, deployed bespoke malware, pivoted to sensitive internal systems, and abused enterprise administrative tools for covert data exfiltration. Google says it disrupted malicious infrastructure, notified affected organizations with Mandiant Consulting, and updated Google Security Operations with relevant indicators.

The scope described by Google is not a routine web-shell incident. The collection priorities included medical research, artificial intelligence, national defense, uncrewed vehicle systems, Indo-Pacific operations, and cyber offensive programs. GTIG says the earliest known compromise occurred in September 2023, with activity continuing through November 2025 at one medical research institution. That long dwell time is the reason the story should be read as an identity and collaboration-security case, not only as a vulnerable-server case.

REDCap is widely used by research institutions to build and manage online surveys and databases. The official REDCap site describes it as a secure web application for collecting research data across web and mobile workflows, with use across thousands of institutions. That makes it valuable infrastructure: it often sits near regulated research data, study operations, clinical workflows, and institutional credentials.

Google is careful about one important point: GTIG was not able to confirm how UNC6508 initially accessed the REDCap server. The report does say the actor was observed probing for vulnerable legacy versions on target organizations' REDCap systems, and it notes that REDCap can allow administrators to run legacy software side by side with the current version. That creates a practical audit question for defenders. A patched current deployment may not be the only reachable deployment if old copies, test paths, backup directories, or migration remnants still exist.

GTIG says UNC6508 deployed INFINITERED about three months after initial compromise in the medical research case. The malware was not described as a generic dropper. Google says it trojanized legitimate REDCap system files across three components: a dropper and upgrade-interception mechanism, a credential harvester, and a backdoor with command-and-control functionality. The credential harvester captured usernames and passwords submitted during login and hid them inside a legitimate REDCap sessions database table.

The upgrade-interception behavior is the part that should concern application owners. According to Google, INFINITERED injected its own code into new REDCap versions by intercepting the upgrade process. If defenders treat an upgrade as a complete cleanup without file integrity review, web-root inspection, and credential rotation, they can preserve the attacker's foothold while believing they have moved forward. Research platforms need patching, but they also need post-upgrade validation that old malicious hooks did not follow the deployment.

More than a year after the initial compromise, GTIG says UNC6508 used overlapping credentials harvested from REDCap to access an administrator account. From there, the actor created a Workspace content compliance rule named Patroit that matched emails using regular expressions and silently BCC-forwarded selected messages to an actor-controlled Gmail account. Google says it disabled that Gmail account after discovery.

This is the operational pivot that matters for collaboration security. Content compliance rules are legitimate administrative features. Google Workspace documentation describes advanced Gmail content filtering as a way for administrators to control delivery based on message content. Those features are needed for compliance, routing, DLP, and operational policy. They are also powerful enough to become an exfiltration path when an administrator account is compromised. Reviewing user inbox forwarding is not enough. The admin rule plane has to be in scope.

The first response lane is the exposed application. Inventory every internet-reachable REDCap deployment, including legacy paths, staging hosts, backup directories, container images, old virtual hosts, and side-by-side versions. Confirm the current version, remove old versions rather than only disabling links to them, inspect files for unexpected hooks or web shells, and use the indicators in Google's report where applicable. Rotate credentials that may have crossed the application boundary, especially database, service, administrator, and shared research accounts.

The second response lane is cloud administration. Enforce phishing-resistant 2-Step Verification or equivalent controls for administrators and sensitive accounts, review content compliance rules and routing settings, inspect admin audit logs for rule creation and modification, and ensure SIEM coverage includes Workspace administrative events. Google's own recommendations include device-bound session credentials for sensitive accounts on Windows, DLP rules to block or alert on external sharing, audit-log monitoring, and scanning REDCap servers for INFINITERED indicators.

The report does not name victim organizations, quantify the full number of affected entities, or confirm the initial vulnerability used for access. It also does not prove that every REDCap deployment is exposed to the same path. The facts that matter are narrower and more useful: Google says multiple organizations in the US and Canada were compromised with INFINITERED, the initial-access method was not confirmed, and legacy REDCap versions were probed across targets.

That uncertainty should shape the response. Do not wait for a single CVE, a single vendor patch, or a public victim list. Treat this as a pattern: a research-facing application can become a credential source, a harvested account can become an administrator path, and a legitimate mail rule can become a quiet collection channel. The strongest defenses are boring controls applied together: current software, removed legacy copies, least-privilege admin roles, phishing-resistant admin login, rule-change alerting, DLP, and credential rotation after compromise.