PRC Hackers Exploit REDCap Research Servers

PRC-Nexus Hackers Exploit REDCap Servers to Spy on Research Networks

A PRC-nexus threat actor has been linked to a long-running cyber espionage campaign targeting research, healthcare, academic, and defense-related environments in the United States and Canada.

Tracked by Google Threat Intelligence Group as UNC6508, the attackers compromised externally facing REDCap servers and used them as a foothold into sensitive research networks.

REDCap, short for Research Electronic Data Capture, is widely used by hospitals, universities, clinical research teams, academic institutions, and public health organizations to collect and manage research data.

That made it an attractive target.

The campaign reportedly involved custom malware, credential theft, internal reconnaissance, persistence through software upgrades, and covert email exfiltration through Google Workspace content compliance rules.

For enterprises, universities, healthcare providers, and research organizations, this is a serious warning.

Specialized research platforms are not just business applications.

They can become entry points into high-value data, trusted networks, medical research, defense programs, and identity systems.

What Happened:

Google Threat Intelligence Group reported a campaign linked to UNC6508, a China-aligned threat actor focused on intelligence collection.

The attackers compromised externally facing REDCap servers used by research-focused organizations.

The earliest known compromise activity dates back to September 2023, with malicious activity continuing through November 2025.

After gaining access, the attackers deployed custom malware called INFINITERED.

INFINITERED was designed specifically to target REDCap environments.

It trojanized legitimate REDCap system files, harvested credentials, maintained persistence, and supported command execution through the compromised application.

The campaign targeted organizations connected to clinical research, academic medicine, healthcare, military health, public health policy, advocacy, and defense-related research.

The attackers later abused Google Workspace content compliance rules to silently copy emails matching selected keywords to attacker-controlled accounts.

Why This Issue Is Critical:

This issue is critical because REDCap systems often sit close to sensitive research and operational data.

Research environments may contain clinical trial information, medical studies, intellectual property, patient-linked research records, grant data, public health information, defense-related research, and institutional communications.

When attackers compromise a REDCap server, they may gain more than application access.

They may obtain credentials, database access, service account details, internal network visibility, and pathways into broader enterprise systems.

The Google Workspace abuse also raises the risk significantly.

Instead of using noisy malware-based exfiltration, the attackers used legitimate administrative email routing functionality to copy selected messages.

That means sensitive data could leave the environment through trusted cloud services without triggering traditional malware alerts.

Why REDCap Was Targeted:

REDCap is widely used in research-heavy environments.

That makes it valuable for espionage actors.

Organizations using REDCap may be involved in medical research, clinical trials, public health planning, biomedical innovation, military health programs, or sensitive academic research.

Those datasets can have strategic value.

They can reveal research priorities, health policy decisions, defense-related work, advanced technology development, institutional partnerships, funding patterns, and operational relationships.

The campaign shows that attackers are willing to reverse-engineer and weaponize specialized software when the target environment is valuable enough.

This is especially important for organizations that rely on niche platforms but do not monitor them with the same urgency as VPNs, firewalls, identity providers, or endpoint systems.

How INFINITERED Worked:

INFINITERED was custom malware designed for REDCap environments.

It reportedly performed several key functions.

• It trojanized legitimate REDCap system files
• It intercepted REDCap upgrade processes
• It reinjected malicious code during upgrades
• It harvested usernames and passwords from the login process
• It stored stolen credentials in local database tables
• It provided backdoor functionality
• It supported remote commands through HTTP cookie-based control
• It helped maintain access across REDCap page loads

This design is especially dangerous because it abused normal application behavior.

By targeting upgrade processes, the malware could survive remediation efforts that did not fully remove infected legacy components or validate clean system files.

How the Attack Chain Worked:

A realistic attack path may follow this pattern.

• Attackers identify externally facing REDCap servers
• The attackers probe for vulnerable or legacy REDCap versions
• Initial access is gained through an exposed REDCap environment
• INFINITERED malware is deployed into REDCap system files
• The malware persists through upgrade-related mechanisms
• Usernames and passwords are harvested from REDCap authentication flows
• Database and service account credentials are discovered
• Internal reconnaissance is performed from the compromised server
• Stolen credentials are used to move deeper into the environment
• Administrative access is obtained
• Google Workspace content compliance rules are modified
• Emails matching attacker-selected keywords are silently copied to attacker-controlled accounts

This attack chain shows how an application compromise can become an identity, email, and data exfiltration event.

Why Google Workspace Rule Abuse Matters:

The abuse of Google Workspace content compliance rules is one of the most important parts of this campaign.

Content compliance rules are legitimate administrative controls.

They can scan email content for selected terms, patterns, or criteria and then take actions such as rejecting, quarantining, modifying, forwarding, or copying messages.

In this campaign, attackers used that legitimate capability for espionage.

Once they gained sufficient administrative control, they created rules that silently copied emails matching strategic keywords to attacker-controlled inboxes.

This technique is difficult to detect because it does not require malware on the mail server.

It does not necessarily create unusual outbound traffic from an endpoint.

It does not look like a typical file exfiltration tool.

It uses a trusted cloud feature in a malicious way.

That makes cloud configuration auditing just as important as endpoint detection.

Why This Incident Matters for Cybersecurity:

This incident reinforces a major cybersecurity reality.

Attackers increasingly target the systems that hold, process, or route high-value data.

That includes research platforms, cloud email rules, identity systems, SaaS applications, administrative consoles, and specialized business systems.

The campaign also shows how espionage actors combine custom malware with living-off-the-platform techniques.

INFINITERED provided persistence and credential theft inside REDCap.

Google Workspace rules provided quiet email exfiltration.

Together, those techniques created a stealthy and durable collection path.

For defenders, the lesson is clear.

Security teams must monitor not only malware and exploitation attempts, but also administrative configuration changes in cloud and research platforms.

Common Risks Highlighted:

This REDCap campaign highlights several common enterprise weaknesses.

• Externally facing research applications
• Legacy REDCap versions left accessible
• Incomplete removal of older application components
• Weak monitoring of research platforms
• Credential harvesting through compromised application login flows
• Service account credential exposure
• Poor segmentation between research systems and internal networks
• Administrative access abuse
• Google Workspace content compliance rule misuse
• Lack of auditing for cloud email routing changes
• Limited detection of application-specific malware

These weaknesses can allow attackers to maintain access and extract sensitive information for long periods.

Potential Impact:

The potential impact of REDCap compromise can be severe.

• Research data theft
• Clinical research exposure
• Credential theft
• Database compromise
• Service account abuse
• Internal reconnaissance
• Domain privilege escalation
• Email exfiltration
• Sensitive communications exposure
• Defense-related research exposure
• Public health and medical research intelligence collection
• Long-term espionage access
• Reputational and regulatory impact

The impact depends on what the REDCap environment can access and what email data attackers collected through cloud rules.

In research and healthcare environments, the sensitivity can be extremely high.

What Organisations Should Do Now:

Organizations using REDCap should take immediate action.

• Identify all externally facing REDCap deployments
• Remove or isolate legacy REDCap versions
• Confirm REDCap is updated to a current supported release
• Review REDCap system files for unauthorized changes
• Hunt for INFINITERED indicators where available
• Review REDCap login and authentication flows for credential harvesting modifications
• Search for unusual files such as unexpected PHP scripts or uploaders
• Review database tables for suspicious credential storage
• Rotate REDCap user credentials after suspected compromise
• Rotate database and service account credentials linked to REDCap
• Segment REDCap servers from sensitive internal systems
• Review administrative access paths from REDCap infrastructure
• Preserve logs before remediation if compromise is suspected

Patching alone may not be enough.

If malware modified application files or survived through upgrade mechanisms, teams must verify system integrity and remove malicious components.

Google Workspace Actions to Take:

Organizations using Google Workspace should review email routing and compliance configurations immediately.

• Audit Gmail content compliance rules
• Review mail routing and forwarding rules
• Search for rules that BCC, copy, redirect, or forward email externally
• Review admin audit logs for changes to Gmail compliance settings
• Investigate rules created by unexpected administrator accounts
• Look for misspelled or suspicious rule names
• Review keyword-based rules that match sensitive research or defense topics
• Disable unauthorized external forwarding
• Enforce phishing-resistant MFA for administrators
• Limit who can modify domain-wide mail rules
• Alert on new or modified content compliance rules
• Review attacker-controlled external recipient addresses where possible

Cloud email configuration should be monitored continuously.

A malicious rule can quietly exfiltrate information even when endpoints appear clean.

Detection and Monitoring Strategies:

Security teams should monitor both REDCap and cloud email environments.

• Monitor REDCap system file changes
• Detect unexpected PHP files or web shells
• Review REDCap upgrade-related file modifications
• Monitor authentication file changes
• Watch for unusual database writes involving credential-like data
• Review outbound connections from REDCap servers
• Monitor command execution from web server processes
• Review service account credential access
• Detect suspicious Google Workspace admin changes
• Alert on new Gmail compliance or routing rules
• Monitor external BCC or forwarding behavior
• Correlate REDCap compromise signals with cloud email rule changes

The best detection strategy combines application telemetry, file integrity monitoring, identity logs, database logs, and cloud admin audit logs.

This campaign cannot be fully understood by looking at only one layer.

The Role of Incident Response Planning:

Incident response teams should prepare for research platform compromise scenarios.

If REDCap compromise is suspected, responders should preserve application files, web logs, database logs, authentication records, system process data, cloud admin audit logs, and email routing configuration history.

They should determine whether credentials were harvested, whether internal movement occurred, and whether mail rules were modified.

If Google Workspace rules were abused, responders should identify which messages matched the rules, what recipients received copied mail, and what data categories may have been exposed.

Credential rotation should include REDCap users, database accounts, service accounts, administrative accounts, and any credentials that may have passed through affected systems.

Because the campaign involved long-term espionage, responders should assume attackers may have had time to study the environment carefully.

Penetration Testing Insight:

From a penetration testing perspective, REDCap and similar research platforms should be treated as high-value applications.

A realistic assessment should evaluate not only the web application, but also the surrounding identity, database, email, and cloud administration paths.

• Inventory REDCap deployments
• Review internet exposure
• Test whether legacy versions remain accessible
• Validate file integrity around application and upgrade paths
• Assess service account privileges
• Review database access controls
• Test segmentation between REDCap and internal networks
• Review administrative access from application servers
• Assess cloud email routing rule governance
• Validate alerts for Google Workspace compliance rule changes
• Simulate post-compromise data exfiltration paths in a controlled environment

Modern penetration testing should show how a research application compromise could become an enterprise-wide espionage path.

Expert Insight:

James Knight, Senior Principal at Digital Warfare, said:

“REDCap environments often sit near some of the most valuable research data an organization owns. This campaign shows why specialized applications need the same level of monitoring, segmentation, and configuration auditing as perimeter systems and identity platforms.”

What Security Leaders Should Prioritize:

Security leaders should treat this incident as a research infrastructure and cloud governance warning.

The immediate priority is reviewing externally exposed REDCap systems and removing legacy versions.

The broader priority is validating that compromised applications cannot lead to cloud email exfiltration or administrative control.

Leaders should ask direct questions.

Which REDCap servers are internet-facing?

Are legacy versions still accessible?

Can we detect file tampering in REDCap directories?

Which service accounts does REDCap use?

Can REDCap reach sensitive internal systems?

Who can modify Google Workspace content compliance rules?

Can we detect external BCC or forwarding rule creation?

Can we prove sensitive research emails were not copied externally?

If teams cannot answer those questions quickly, the organization has a research platform visibility gap.

Call to Action:

Organizations using REDCap should not treat research platforms as isolated academic tools.

Validate exposure, remove legacy versions, hunt for application tampering, review cloud email rules, rotate credentials, and confirm that compromised research systems cannot become a long-term espionage path.