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

A 13-plus-month intrusion across medical, academic, and defense research networks abused victim-side mail forwarding instead of dropping noisy C2.

ThreatVectr Newsdesk· 2 min read
China-Nexus Crew Burrowed Into REDCap, Turned Google Workspace Rules Into an Exfil Pipe
Share

A China-linked espionage operation sat inside North American research networks for over a year, siphoning sensitive medical, academic, and defense correspondence without tripping the usual alarms.

The initial access vector was prosaic. The exfiltration was not.

Operators planted a credential-stealing backdoor on internet-facing REDCap servers — the open-source clinical data capture platform widely deployed at universities, hospitals, and federally funded labs. Once researcher logins were in hand, the attackers pivoted into the victims' Google Workspace tenants and rewrote mail-handling rules so that every inbound and outbound message was silently copied to attacker-controlled addresses.

No malware on the endpoint. No outbound beacon from a workstation. Just Google's own infrastructure cheerfully forwarding the mail.

That is the part defenders should sit with. Traditional EDR telemetry is blind to a tenant-side forwarding rule, and most SOCs are not auditing Workspace routing config with the same rigor they apply to Exchange transport rules. The intrusion went undetected across multiple victim organizations for more than 13 months (the actual dwell time per environment varies, and not every victim has been named).

The target set tells you the intent: research output and defense-adjacent email threads. This is collection, not extortion.

A few operational notes for anyone running REDCap or Workspace at scale:

  • Audit your Workspace routing, compliance, and content compliance rules at the domain, OU, and user level. Attackers favor the domain-wide routing path because it survives individual password resets. Google documents the surface in its admin help.
  • Pull Admin SDK reports for CREATE_GMAIL_SETTING and CHANGE_EMAIL_SETTING events going back at least 18 months. If you have never looked, assume you will not like what you find.
  • Patch and harden REDCap. Confirm you are running a current build (the vendor publishes release notes via the Vanderbilt consortium portal) and that your instance is not exposed without SSO and MFA in front of it.
  • Rotate any service account or API token that touched the REDCap host. Credential theft is the documented payload.

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 going back years. No CVE has been assigned to the REDCap backdoor itself; the implant appears to be custom rather than the exploitation of a named flaw, though investigators have not ruled out an unpatched vulnerability as the planting mechanism.

If your threat model includes nation-state collection and you run either of these platforms, the homework is straightforward. Treat tenant configuration as code. Diff it. Alert on changes.

The quiet attacks are the ones that work.

© 2026 Threat Vectr