UNC6508 Spent a Year Inside US and Canadian Research Networks via Trojanized REDCap
A China-linked espionage group hijacked REDCap's own upgrade process to plant persistent malware across academic, medical, and defense-adjacent research environments.
Key points
- UNC6508, a China-nexus espionage actor, was embedded in US and Canadian research institutions for more than a year before disruption.
- The group abused REDCap's upgrade workflow to ensure malware survived software updates.
- Targets included academic institutions, medical research centers, and defense-focused research programs.
- GTIG could not confirm the initial access method and has notified affected organizations.
- A YARA rule for hunting the malware family INFINITERED is now publicly available.
Google's Threat Intelligence Group (GTIG) has published findings on UNC6508, a China-nexus actor embedded in research institutions across the United States and Canada for over a year. The vector was REDCap, a platform widely used for collecting and managing research data. Sensitive data of interest spanned national security, AI development, cyber operations, and medical research.
When we first reported this intrusion set on 15 June, the group was abusing victim-side mail forwarding to quietly exfiltrate data. This GTIG report details the persistence layer that kept them in place long enough to do it.
How the malware survives upgrades
INFINITERED, the malware family GTIG tracks here, embeds itself into REDCap's upgrade workflow so it survives software updates. Three components work together: a dropper that intercepts the upgrade process and reinjects malicious logic, a credential harvester injected into REDCap's authentication system file, and a backdoor written into the custom hooks configuration file.
The upgrade interception module is the linchpin. REDCap permits administrators to run legacy versions alongside current installations. UNC6508 exploited that design choice: older legacy instances were first compromised through an initial access method GTIG could not confirm, then used as a reservoir of malicious logic. When administrators ran upgrades, that logic transferred forward automatically. It's a supply-chain-style persistence trick without touching the supply chain.
What happened after initial compromise
Post-compromise activity included credential discovery and internal reconnaissance to obtain database and service account credentials. UNC6508 also deployed a web shell named help.php, which served as both a persistence mechanism and a file uploader inside the REDCap application, supporting remote file management, shell command execution, and system enumeration.
REDCap's maintainers have not issued a public advisory as of publication.
Should you worry?
If your organization runs REDCap, yes. GTIG released a YARA rule for hunting INFINITERED; treat it as the starting point, not the finish. Four steps matter:
- Audit REDCap application files for unauthorized modifications, paying particular attention to authentication system files and custom hooks configuration files.
- Identify and remove or isolate any legacy REDCap versions still accessible alongside current deployments.
- Validate file integrity before and after every upgrade cycle.
- Enforce phishing-resistant multi-factor authentication and device-bound session credentials for all REDCap administrative accounts.
The uncomfortable detail here is that GTIG still doesn't know how UNC6508 got in the first time. Fixing the persistence mechanism matters, but without knowing the front door, organizations can't be confident they've fully closed this off.
