China-Nexus Crew Burrowed Into REDCap, Turned Google Workspace Rules Into an Exfil Pipe

Key points

• A China-linked espionage group planted a credential-stealing backdoor on REDCap servers to gain initial access.
• Attackers rewrote victims' Google Workspace mail-routing rules to silently copy messages to attacker-controlled addresses.
• The operation ran undetected for more than 13 months across multiple North American research networks.
• No endpoint malware was required; exfiltration ran entirely through Google's own infrastructure.
• Targets were medical, academic, and defense-adjacent research organizations, consistent with Beijing-linked collection priorities.

What actually happened here?

A China-linked espionage group sat inside North American research networks for over a year, stealing sensitive correspondence without tripping the usual alarms. The way in was a credential-stealing backdoor planted on internet-facing REDCap servers, the open-source clinical data capture platform widely used at universities and federally funded labs. With researcher logins in hand, the attackers pivoted into victims' Google Workspace tenants and rewrote mail-handling rules so every inbound and outbound message was silently copied to attacker-controlled addresses.

No malware on the endpoint, no outbound beacon from a workstation. Google's own infrastructure did the forwarding.

We first covered REDCap as an attack surface on 15 June 2026, and this campaign fits a pattern we've been tracking: Chinese state-aligned actors quietly repositioning inside trusted research infrastructure rather than burning noisy C2 channels. The TA4922 crew, which we reported on 4 June, rotates payloads fast; this group went the other direction and moved almost invisibly.

Should you worry?

If your organization runs REDCap or Google Workspace and handles research data, yes. This is the part defenders should sit with: traditional EDR telemetry is blind to a tenant-side forwarding rule. Most SOCs audit Exchange transport rules carefully but treat Workspace routing configuration as an afterthought. The intrusion ran undetected across multiple victim organizations for more than 13 months, and not every affected organization has been named publicly.

The target set is telling. This is collection against research output and defense-adjacent email threads, not extortion. That's a patient, deliberate operation.

What should defenders do?

Audit your Workspace routing and content-compliance rules at the domain, OU, and user level. Attackers favor domain-wide routing paths because those rules survive individual password resets. Google documents the relevant surface in its admin help.

Pull Admin SDK reports for CREATE_GMAIL_SETTING and CHANGE_EMAIL_SETTING events. If you haven't looked before, don't assume the results will be clean.

Patch and harden REDCap. Confirm you're running a current build via the Vanderbilt consortium portal and that your instance sits behind SSO and MFA. Rotate any service account or API token that touched the REDCap host; credential theft is the documented initial payload.

Treat tenant configuration as code. Diff it. Alert on changes.

What's the attribution picture?

Attribution to a Chinese state-aligned cluster is consistent with the targeting profile. Biomedical research and defense email have been priority collection topics for Beijing-linked groups for years. No CVE has been assigned to the REDCap backdoor; the implant appears to be custom, though investigators haven't ruled out an unpatched vulnerability as the delivery mechanism.

The honest judgement: the exfiltration method here is more operationally mature than most of what we see from this threat cluster. Abusing a platform's own routing infrastructure leaves almost nothing for a host-based sensor to catch. Defenders who aren't treating cloud admin logs as first-class security telemetry are flying blind against exactly this kind of move.