Chinese state-sponsored actors spent over a year inside a North American medical research institution, stealing sensitive research data from compromised REDCap servers. The attack, attributed to a group tracked as UNC6508, demonstrates exactly why file-level security controls matter — and why organizations running research infrastructure on Windows need more than network perimeter defenses.
What Happened: Trojanized System Files and Year-Long Persistence
The attackers compromised the REDCap server in September 2023 and remained undetected through November 2025. Three months after initial access, they deployed custom malware called InfiniteRed, which consisted of three components: a persistence/update module, a credential harvester, and a backdoor.
The malware worked by trojanizing the server’s system files — replacing or modifying legitimate Windows files to hide its components. The credential harvester captured usernames and passwords from REDCap login pages, encrypted them, and wrote them to local database tables for later retrieval. The backdoor accepted commands via HTTP cookies and could execute shell commands, upload/download files, run SQL queries, and retrieve stolen credentials.
For exfiltration, the attackers created a content compliance rule in the organization’s email system that automatically forwarded emails matching specific keywords — medical research terms, advanced technology, military topics, geo-strategic policy — to an external Gmail address. The research data walked out via email, automatically, for over a year.
Why Traditional Security Failed
This attack succeeded because it operated at layers most security tools don’t effectively control. The malware modified system files on the server — a file write operation that required elevated privileges but wasn’t blocked. The credential harvester wrote to database file locations — another file operation that went unchallenged. The exfiltration mechanism read research data files and attached them to emails — file read operations that no one prevented.
Network security saw legitimate HTTPS traffic. Antivirus didn’t recognize the custom malware. The attackers used residential proxies and compromised routers, so the traffic looked normal. And because the malware trojanized existing system files rather than dropping obviously malicious executables, it avoided detection for over a year.
How FileSure Stops This at the Installation Stage
FileSure Defend operates at the Windows kernel level via a filter driver that intercepts every file operation before it completes. It enforces behavioral policies that define which users and programs can perform which file operations — regardless of whether the program is “known malware” or not.
Here’s the specific rule configuration that would have stopped InfiniteRed during installation:
File Name Filter: C:\Windows\System32\* (protect all system files)
Allowed Programs: C:\Windows\System32\msiexec.exe, C:\Windows\System32\dism.exe, [authorized patch management tools]
Allowed Operations: Read (allow), Write (block), Delete (block), Rename (block)
Drive Type: Fixed Drive
Action: Block and Log
When the attackers attempted to trojanize system files, FileSure would have blocked the write operation because the process attempting it wasn’t on the authorized list. The malware installation fails. The credential harvester never gets written to disk. The backdoor never executes. The persistence mechanism never establishes itself.
The attack stops at the earliest possible point — before the malware lands on the file system.
For the credential harvesting component, a second rule protects database file locations:
File Name Filter: C:\Program Files\REDCap\Database\*
Allowed Programs: C:\Program Files\REDCap\mysql.exe, C:\Program Files\REDCap\backup.exe
Allowed Operations: Read (allow), Write (restrict to authorized programs), Delete (block)
Action: Block and Log
Only the legitimate database engine and authorized backup tools can write to database directories. The credential harvester — even if it somehow executed — couldn’t write stolen passwords to the database tables.
For data exfiltration prevention, a third rule controls which programs can read sensitive research files:
File Name Filter: D:\ResearchData\*
Allowed Programs: C:\Program Files\REDCap\redcap.exe, C:\Program Files\Microsoft Office\WINWORD.EXE
Blocked Programs: C:\Program Files\Microsoft\Exchange\*, C:\Program Files\Outlook\* (prevent email clients from directly accessing research files)
Allowed Operations: Read (restrict to authorized programs)
Action: Block and Log
Research data can be opened by the REDCap application and by Word for legitimate document editing. But email clients can’t directly read research files — preventing the automatic email exfiltration the attackers used.
The Advantage of File System Security
The attackers in this case used sophisticated operational security: residential proxies, compromised routers, VPS infrastructure, credential replay, and dedicated exfiltration infrastructure. They stayed hidden for over a year. But all of that sophistication doesn’t help if their malware can’t write itself to the file system in the first place.
FileSure doesn’t need to recognize InfiniteRed. It doesn’t need a signature update. It doesn’t need to detect the attack after it happens. It simply enforces the rule: unauthorized programs cannot modify system files. The malware tries to trojanize a system file during installation — blocked. Done.
That’s the advantage of controlling file operations at the kernel level rather than trying to recognize threats after they’ve already landed.
If you’re running REDCap servers, medical research infrastructure, or any Windows-based system that handles sensitive data, you need file-level controls that work regardless of what new malware variant appears tomorrow.
Start a free 21-day trial of FileSure Defend at bystorm.com and test it on your REDCap environment. Install it, configure a rule protecting your system files, then try to modify one. Watch it get blocked. That’s the whole demo — and it works exactly like that against real attacks.
Source: Chinese hackers breach REDCap servers, steal medical research
Category: Threat Intelligence
Tags: infinitered, unc6508, redcap, medical research, credential harvesting, data exfiltration, kernel filter driver, file system security
Chinese state-sponsored actors spent over a year inside a North American medical research institution, stealing sensitive research data from compromised REDCap servers. The attack, attributed to a group tracked as UNC6508, demonstrates exactly why file-level security controls matter — and why organizations running research infrastructure on Windows need more than network perimeter defenses.
What Happened: Trojanized System Files and Year-Long Persistence
The attackers compromised the REDCap server in September 2023 and remained undetected through November 2025. Three months after initial access, they deployed custom malware called InfiniteRed, which consisted of three components: a persistence/update module, a credential harvester, and a backdoor.
The malware worked by trojanizing the server’s system files — replacing or modifying legitimate Windows files to hide its components. The credential harvester captured usernames and passwords from REDCap login pages, encrypted them, and wrote them to local database tables for later retrieval. The backdoor accepted commands via HTTP cookies and could execute shell commands, upload/download files, run SQL queries, and retrieve stolen credentials.
For exfiltration, the attackers created a content compliance rule in the organization’s email system that automatically forwarded emails matching specific keywords — medical research terms, advanced technology, military topics, geo-strategic policy — to an external Gmail address. The research data walked out via email, automatically, for over a year.
Why Traditional Security Failed
This attack succeeded because it operated at layers most security tools don’t effectively control. The malware modified system files on the server — a file write operation that required elevated privileges but wasn’t blocked. The credential harvester wrote to database file locations — another file operation that went unchallenged. The exfiltration mechanism read research data files and attached them to emails — file read operations that no one prevented.
Network security saw legitimate HTTPS traffic. Antivirus didn’t recognize the custom malware. The attackers used residential proxies and compromised routers, so the traffic looked normal. And because the malware trojanized existing system files rather than dropping obviously malicious executables, it avoided detection for over a year.
How FileSure Stops This at the Installation Stage
FileSure Defend operates at the Windows kernel level via a filter driver that intercepts every file operation before it completes. It enforces behavioral policies that define which users and programs can perform which file operations — regardless of whether the program is “known malware” or not.
Here’s the specific rule configuration that would have stopped InfiniteRed during installation:
File Name Filter: C:\Windows\System32\* (protect all system files)
Allowed Programs: C:\Windows\System32\msiexec.exe, C:\Windows\System32\dism.exe, [authorized patch management tools]
Allowed Operations: Read (allow), Write (block), Delete (block), Rename (block)
Drive Type: Fixed Drive
Action: Block and Log
When the attackers attempted to trojanize system files, FileSure would have blocked the write operation because the process attempting it wasn’t on the authorized list. The malware installation fails. The credential harvester never gets written to disk. The backdoor never executes. The persistence mechanism never establishes itself.
The attack stops at the earliest possible point — before the malware lands on the file system.
For the credential harvesting component, a second rule protects database file locations:
File Name Filter: C:\Program Files\REDCap\Database\*
Allowed Programs: C:\Program Files\REDCap\mysql.exe, C:\Program Files\REDCap\backup.exe
Allowed Operations: Read (allow), Write (restrict to authorized programs), Delete (block)
Action: Block and Log
Only the legitimate database engine and authorized backup tools can write to database directories. The credential harvester — even if it somehow executed — couldn’t write stolen passwords to the database tables.
For data exfiltration prevention, a third rule controls which programs can read sensitive research files:
File Name Filter: D:\ResearchData\*
Allowed Programs: C:\Program Files\REDCap\redcap.exe, C:\Program Files\Microsoft Office\WINWORD.EXE
Blocked Programs: C:\Program Files\Microsoft\Exchange\*, C:\Program Files\Outlook\* (prevent email clients from directly accessing research files)
Allowed Operations: Read (restrict to authorized programs)
Action: Block and Log
Research data can be opened by the REDCap application and by Word for legitimate document editing. But email clients can’t directly read research files — preventing the automatic email exfiltration the attackers used.
The Advantage of File System Security
The attackers in this case used sophisticated operational security: residential proxies, compromised routers, VPS infrastructure, credential replay, and dedicated exfiltration infrastructure. They stayed hidden for over a year. But all of that sophistication doesn’t help if their malware can’t write itself to the file system in the first place.
FileSure doesn’t need to recognize InfiniteRed. It doesn’t need a signature update. It doesn’t need to detect the attack after it happens. It simply enforces the rule: unauthorized programs cannot modify system files. The malware tries to trojanize a system file during installation — blocked. Done.
That’s the advantage of controlling file operations at the kernel level rather than trying to recognize threats after they’ve already landed.
If you’re running REDCap servers, medical research infrastructure, or any Windows-based system that handles sensitive data, you need file-level controls that work regardless of what new malware variant appears tomorrow.
Start a free 21-day trial of FileSure Defend at bystorm.com and test it on your REDCap environment. Install it, configure a rule protecting your system files, then try to modify one. Watch it get blocked. That’s the whole demo — and it works exactly like that against real attacks.
Source: Chinese hackers breach REDCap servers, steal medical research
Category: Threat Intelligence
Tags: infinitered, unc6508, redcap, medical research, credential harvesting, data exfiltration, kernel filter driver, file system security
Chinese state-sponsored actors spent over a year inside a North American medical research institution, stealing sensitive research data from compromised REDCap servers. The attack, attributed to a group tracked as UNC6508, demonstrates exactly why file-level security controls matter — and why organizations running research infrastructure on Windows need more than network perimeter defenses.
What Happened: Trojanized System Files and Year-Long Persistence
The attackers compromised the REDCap server in September 2023 and remained undetected through November 2025. Three months after initial access, they deployed custom malware called InfiniteRed, which consisted of three components: a persistence/update module, a credential harvester, and a backdoor.
The malware worked by trojanizing the server’s system files — replacing or modifying legitimate Windows files to hide its components. The credential harvester captured usernames and passwords from REDCap login pages, encrypted them, and wrote them to local database tables for later retrieval. The backdoor accepted commands via HTTP cookies and could execute shell commands, upload/download files, run SQL queries, and retrieve stolen credentials.
For exfiltration, the attackers created a content compliance rule in the organization’s email system that automatically forwarded emails matching specific keywords — medical research terms, advanced technology, military topics, geo-strategic policy — to an external Gmail address. The research data walked out via email, automatically, for over a year.
Why Traditional Security Failed
This attack succeeded because it operated at layers most security tools don’t effectively control. The malware modified system files on the server — a file write operation that required elevated privileges but wasn’t blocked. The credential harvester wrote to database file locations — another file operation that went unchallenged. The exfiltration mechanism read research data files and attached them to emails — file read operations that no one prevented.
Network security saw legitimate HTTPS traffic. Antivirus didn’t recognize the custom malware. The attackers used residential proxies and compromised routers, so the traffic looked normal. And because the malware trojanized existing system files rather than dropping obviously malicious executables, it avoided detection for over a year.
How FileSure Stops This at the Installation Stage
FileSure Defend operates at the Windows kernel level via a filter driver that intercepts every file operation before it completes. It enforces behavioral policies that define which users and programs can perform which file operations — regardless of whether the program is “known malware” or not.
Here’s the specific rule configuration that would have stopped InfiniteRed during installation:
File Name Filter: C:\Windows\System32\* (protect all system files)
Allowed Programs: C:\Windows\System32\msiexec.exe, C:\Windows\System32\dism.exe, [authorized patch management tools]
Allowed Operations: Read (allow), Write (block), Delete (block), Rename (block)
Drive Type: Fixed Drive
Action: Block and Log
When the attackers attempted to trojanize system files, FileSure would have blocked the write operation because the process attempting it wasn’t on the authorized list. The malware installation fails. The credential harvester never gets written to disk. The backdoor never executes. The persistence mechanism never establishes itself.
The attack stops at the earliest possible point — before the malware lands on the file system.
For the credential harvesting component, a second rule protects database file locations:
File Name Filter: C:\Program Files\REDCap\Database\*
Allowed Programs: C:\Program Files\REDCap\mysql.exe, C:\Program Files\REDCap\backup.exe
Allowed Operations: Read (allow), Write (restrict to authorized programs), Delete (block)
Action: Block and Log
Only the legitimate database engine and authorized backup tools can write to database directories. The credential harvester — even if it somehow executed — couldn’t write stolen passwords to the database tables.
For data exfiltration prevention, a third rule controls which programs can read sensitive research files:
File Name Filter: D:\ResearchData\*
Allowed Programs: C:\Program Files\REDCap\redcap.exe, C:\Program Files\Microsoft Office\WINWORD.EXE
Blocked Programs: C:\Program Files\Microsoft\Exchange\*, C:\Program Files\Outlook\* (prevent email clients from directly accessing research files)
Allowed Operations: Read (restrict to authorized programs)
Action: Block and Log
Research data can be opened by the REDCap application and by Word for legitimate document editing. But email clients can’t directly read research files — preventing the automatic email exfiltration the attackers used.
The Advantage of File System Security
The attackers in this case used sophisticated operational security: residential proxies, compromised routers, VPS infrastructure, credential replay, and dedicated exfiltration infrastructure. They stayed hidden for over a year. But all of that sophistication doesn’t help if their malware can’t write itself to the file system in the first place.
FileSure doesn’t need to recognize InfiniteRed. It doesn’t need a signature update. It doesn’t need to detect the attack after it happens. It simply enforces the rule: unauthorized programs cannot modify system files. The malware tries to trojanize a system file during installation — blocked. Done.
That’s the advantage of controlling file operations at the kernel level rather than trying to recognize threats after they’ve already landed.
If you’re running REDCap servers, medical research infrastructure, or any Windows-based system that handles sensitive data, you need file-level controls that work regardless of what new malware variant appears tomorrow.
Start a free 21-day trial of FileSure Defend at bystorm.com and test it on your REDCap environment. Install it, configure a rule protecting your system files, then try to modify one. Watch it get blocked. That’s the whole demo — and it works exactly like that against real attacks.
Source: Chinese hackers breach REDCap servers, steal medical research
Category: Threat Intelligence
Tags: infinitered, unc6508, redcap, medical research, credential harvesting, data exfiltration, kernel filter driver, file system security
