- We detected CapFix campaigns targeting Russian organizations in the industrial and aviation sectors.
- The threat actors used compromised legitimate infrastructure, which they likely accessed by exploiting a critical vulnerability.
- The criminals used a modified version of the CapDoor backdoor to download next-stage payloads, such as SectopRAT.
- We analyzed multiple versions of CapDoor, highlighting their evolution and differences from previously documented variants.
- We also tracked earlier attacks targeting several countries, which used cryptocurrency lures to deliver CapDoor. We discovered phishing sites mimicking hotel booking pages and employing the ClickFix technique.
Alexander Badaev
Cyberthreat Intelligence Specialist, Threat Intelligence Department, Positive Technologies
Maxim Shamanov
Junior Specialist, Advanced Threat Research Group, Threat Intelligence Department, Positive Technologies
Key findings
Introduction
In late 2025, the threat intelligence team at Positive Technologies Expert Security Center (PT ESC) detected a series of unusual attacks against Russian organizations. The attackers leveraged legitimate infrastructure, which we believe was compromised shortly before the active phase began in late autumn.
Our investigation revealed that CapFix was behind these attacks. Previously, the group had targeted users with the ClickFix technique and used phishing files themed around cryptocurrency and hotel bookings.
Most of the attacks followed the same scenario.

Since early 2026, we have been monitoring the attackers' infrastructure. We observed that they resumed their attacks in March, using modified tools.
Attacks in late December 2025
In late December, we intercepted PDF documents containing links to download RAR archives. The lures claimed the files were corrupted, prompting the user to download them again.

Clicking the link downloaded an archive from a compromised legitimate site.
Inside the archive was a script named 2025130002313.chm. When executed, it downloaded a file from a compromised legitimate domain (a.gif), renamed it to dmitry_medvedev.msi, and opened a legitimate PDF document:
- https://regulhub.***.ru/upload/iblock/2b6/rw2lul4zdfmj6w2f7w70fp5tcfhnrjdt.pdf

The .msi file was signed QILING Tech and masqueraded as the QILING Disk Master application. When run, it created the Disk Master folder in C:\Users\admin\AppData\Local\ and dropped numerous DLLs alongside a legitimate executable, MetadataConvert.exe, which is vulnerable to DLL sideloading. During execution, it connected to a compromised legitimate IP address and used it as its command-and-control (C2) server. To connect, it sent the following request:
- hxxp://*ip_adress*//bitrix24/?login= [a‑z]{30}
The a.gif/dmitry_medvedev.msi files were downloaded from a legitimate domain via a mail subdomain. The A-record for this subdomain pointed to a shared IP hosting several other mail subdomains.

In late December and earlier, when the attackers were actively running campaigns, this host was vulnerable to CVE-2025-49113—a critical vulnerability (CVSS 9.9) in the popular Roundcube Webmail client. We suspect this is how they gained access to the infrastructure.
Early campaigns and infrastructure
Further investigation revealed that the attackers used multiple mail subdomains hosted on this IP. We uncovered traces of earlier campaigns, such as a malicious PDF document (SHA-256: 23f693029d8e00999a1c0e68d72884fd55f874582780afb94dbb1d3f8fb07f38).

Clicking the "CHM оснастка" (CHM snap-in) button in the PDF triggered the download of sankcionnui-MO-RF.rar from a compromised legitimate site.
Based on shared metadata, we identified numerous PDFs that behaved similarly, with names like "Инструкция_минная_угроза_ВСУ_10.11.2025.pdf" (Mine_threat_instructions_AFU_10.11.2025.pdf) and "Перечень_документов_для_отчета_по_тренингу_ИБ_ФСБ (56).pdf" (List_of_documents_for_FSB_IS_training_report (56).pdf). Researchers at F6 previously wrote about these attacks, attributing them to the financially motivated CapFix group.
Our analysis of the samples confirmed that the malware used in these campaigns was CapDoor, a name coined by F6. A detailed breakdown of this malware and its infection chains is provided in the dedicated section below.
While investigating the dmitry_medvedev.msi attack, we noticed that alongside legitimate IPs, the attackers also used their own custom domain as a CapDoor C2 server:
- https://windowsextupdates.com/bitrix24/?login=[a z]{30}
The threat actors registered this domain using the email virrtasuin93@onionmail.org. We found three domains tied to this address, all masquerading as Windows updates:
- microsoftpathes.com,
- windowsextupdates.com,
- securityswindows.com.

We also discovered additional domains linked to this threat actor. They were also registered via Onionmail, but under a different address: salasunion@onionmail.org. These domains included two of the domains mentioned earlier: documents-sed.com and sed-documents.com.

Furthermore, in their early November campaigns, the group used a PDF named "Приказ № ФСБ-1412025 и подробности о досудебной претензии (57).pdf" (Order No. FSB-1412025 and pre-trial claim details (57).pdf).

The document's name did not match its content. Clicking the link downloaded a RAR archive from support-archiver.com, which contained an MSI that ultimately installed CapDoor.
While investigating attacks tied to this domain, we uncovered PDFs and emails that the attacker had mass-mailed to various organizations. The targets included two aviation companies, four manufacturing companies, and one educational institution.

These emails were sent from ddmmitriypetrovv.ru. By analyzing related domains, we found two more tied to the same actor, both with a similar "first name + last name" name. However, we did not detect any attacks originating from these domains:
- leonidkalatov.ru,
- andreiushakov.ru.

In addition to PDF lures, we observed HTML files employing the same tactic: displaying a seemingly legitimate document that required the user to download additional files to "unlock" it. These HTML files spoofed government or non-profit organizations.

Opening the malicious HTML file loaded the corresponding logos and images from the spoofed organizations' official websites.
March 2026 attacks
In early March, we spotted a new batch of PDF documents from this group. As before, they mimicked official Russian government structures.

Clicking the "Download" button fetched a malicious archive, just like in the older attacks. The difference was that in March 2026, the attackers decided to use their own infrastructure they had previously reserved only for CapDoor C2 communications. The archive was downloaded from the following link:
- https://windowsextupdates.com/updates/latest/q/Document.rar
Interestingly, the attackers configured a redirect on the domain, so the user was always forwarded to ya.ru. They also deployed an updated version of the CapDoor backdoor with expanded functionality.

Next, we will take a deep dive into CapDoor, detailing its functionality, the changes we observed in the 2025–2026 campaigns, and the malware it was used alongside.
CapDoor: loader or backdoor?
The DLL sideloading chain
Upon execution, the MSI installer creates a directory in %LOCALAPPDATA% named after the supposed legitimate software. It populates this folder with numerous dynamic link libraries (DLLs) and other files required for subsequent work.
Figures 14.1, 14.2, 14.3. Content of created directories (examples)
Notably, the names of the created directories and the installed software do not match the names of the installer files.
A core feature of the analyzed samples is the multistage DLL sideloading chain used to launch the payload. Rather than injecting directly, the attackers use several interconnected libraries, each playing a specific role in the installation process:
- Orchestrator DLL, which manages the installation
- Watchdog DLL responsible for hiding the windows of the current process
- Inject DLL, whose exported functions are used to deploy and execute the payload
After the files are saved to the created directory, a legitimate digitally signed executable is launched. Its execution triggers the DLL sideloading chain described above, loading CapDoor into the address space of the legitimate process.

As shown in the diagram, the legitimate executable sideloads the first dynamic library. This library contains no malicious code; its sole task is to sideload the orchestrator DLL during initialization. The orchestrator acts as follows:
1. Sideloads the inject DLL upon initialization. This DLL contains the exported functions that will later be used to run the shellcode.
2. Sideloads the watchdog DLL from the created directory. This module is responsible for hiding the windows of the current process.
While analyzing numerous samples, we found one instance where the attackers used a highly descriptive variable name for this library: windowshider_dll_name. Equally telling was the exported function name used in that same sample: From_Detect.

3. Decrypts the payload stored in an external file. In most cases, the encrypted payload was delivered inside WAV files, located at a specific offset. We also observed attacks where the shellcode was stored in .dat files. Examples of filenames containing the payload:
- systemstatdrawing.wav;
- thumbsactivation.wav;updatecommunity.wav;Common.wav;
- Library.wav;
- Apartment.dat.
Curiously, if you play these WAV files, you can actually hear a few seconds of a standard alarm clock melody.
4. Executes the decrypted shellcode using the functions exported by the inject DLL loaded earlier (in step 1):
- The first function uses VirtualAlloc () to allocate memory with read and write permissions within the legitimate process's address space. The allocated buffer is then filled with random data using BCryptGenRandom (), after which the function returns a pointer to a location within this block at a certain offset. The payload is subsequently placed at this exact address, complicating detection and analysis.

- The second function uses VirtualProtect () to change the memory protection of the previously allocated area to executable, and then passes control to the shellcode. The shellcode is executed by passing its address to the EnumSystemCodePagesW () function.

We found versions of these core components written in both C++ and C#. Regardless of the implementation language, they shared one common feature: heavy obfuscation through the insertion of junk code utilizing GDI functions.

Loader shellcode
The loaded shellcode uses the FNV-1 hash function for dynamic API resolution and the Linear Congruential Generator (LCG) algorithm to decrypt strings. It scans the contents of the directory for files with one of the following extensions: .bak, .db, .bin, .dat, .raw, or .pak. Upon finding such a file, the shellcode decrypts its contents and passes control to the resulting payload—the CapDoor backdoor, which is implemented as shellcode.
To establish persistence in the system, it modifies the registry's autorun parameters, adding the legitimate executable of the installed software to the startup key: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.
CapDoor backdoor
Upon launch, CapDoor uses the MurmurHash3 algorithm for dynamic API resolution. Across all the samples we analyzed, the attackers used a non-standard 0xE5BBB seed value for the algorithm.
Next, CapDoor attempts to create or open lockfile in the %PROGRAMDATA% directory and acquire a lock on it. This file is used for inter-process synchronization. If successful, CapDoor generates a unique GUID using CoCreateGuid () (in the format %08lx-%04x-%04x-%04x-%04x%08lx) and collects system information to form the following structure:
struct COLLECTED_DATA {
DWORD msgType; // = 1
DWORD guidLen;
BYTE guid[guidLen];
DWORD computerFqdnLen;
BYTE computerFqdn[computerFqdnLen];
DWORD envUserNameLen;
BYTE envUsername[envUserNameLen];
DWORD logonDomainLen;
BYTE logonDomain[logonDomainLen];
DWORD osMajor;
DWORD osMinor;
DWORD osBuild;
BYTE isServer;
BYTE is64Bit;
DWORD exeNameSize;
BYTE exeName[exeNameSize];
BYTE isElevated;
};
Figure 20. Structure of the message with system information
The message is encrypted using the ChaCha20 algorithm and sent to the C2 server. If the message is sent successfully, the generated GUID is saved to %PROGRAMDATA%\lockfile so it is not regenerated during subsequent executions. CapDoor then sends another message containing only the GUID, waiting to receive a command in response.
In response to the transmitted GUID, the server sends a message in the following format:
struct C2_REPLY
{
BYTE key[32];
BYTE nonce[12];
BYTE ciphertext[];
};
Figure 21. Structure of the C2 response
After decrypting the message, CapDoor begins processing it. The C2 beacon interval is two minutes. The message can contain a single specific task (run a command, download and execute a payload, or take a screenshot) or any arbitrary combination of these tasks. Each task contains a pointer to the next task, if one exists.
struct С2_REPLY {
int64 unknown;
struct POWERSHELL_TASK *PowerShellTaskList;
struct DOWNLOAD_TASK *DownloadTaskList;
struct SCREENSHOT_TASK *ScreenshotTaskList;
};
struct POWERSHELL_TASK {
struct POWERSHELL_TASK *Next;
uint16_t *TaskId;
uint16_t *PowershellCommand;
};
struct DOWNLOAD_TASK {
struct DOWNLOAD_TASK *Next;
uint16_t *TaskId;
uint16_t *DownloadUrl;
int64 InstallType;
uint16_t *OptionalParam; // e.g. dllExportName
};
struct SCREENSHOT_TASK {
struct SCREENSHOT_TASK *Next;
uint16_t *TaskId;
};
Figure 22. C2 task structure
Below is the complete list of tasks supported by CapDoor:
| Task type | Subtype | Action | Execution mechanism | Description |
|---|---|---|---|---|
| POWERSHELL_TASK | — | Execute arbitrary PowerShell command | %WINDIR%\System32\WindowsPowerShell\v1.0\powershell.exe -NoLogo -NoProfile -Command - | Executes a PowerShell script configured to read commands from stdin. The command is passed via standard input; after execution, \r\nexit\r\n» is written to stdin, terminating the process |
| DOWNLOAD_TASK | 1 | Run an executable | ShellExecuteW(NULL, L"open", L"%TEMP%\\[a-z]{20}.exe", NULL, NULL, 0) | The executable file is downloaded from the C2 server, saved to a temporary directory, and executed using ShellExecuteW () |
| DOWNLOAD_TASK | 2 | Run DLL via rundll32 | ShellExecuteW(NULL, L"open", L"%WINDIR%\\System32\\rundll32.exe", L"\"%TEMP%\\[a-z]{20}.dll\", <ExportName>", NULL, 0) | The DLL file is downloaded from the C2 server, saved to a temporary directory, and then executed via rundll32 by specifying the exported function <ExportName> |
| DOWNLOAD_TASK | 3 | Register DLL via regsvr32 | ShellExecuteW(NULL, L"open", L"%WINDIR%\\System32\\regsvr32.exe", L"/s \"%TEMP%\\[a-z]{20}.dll\"", NULL, 0) | The DLL file is downloaded from the C2 server, saved to a temporary directory, and silently registered (/s) using regsvr32 |
| DOWNLOAD_TASK | 5 | Install MSI file | MsiInstallProductW(L"%TEMP%\\[a-z]{20}.msi", NULL) | The MSI file downloaded from the C2 server is saved to a temporary directory and installed via the Windows Installer API |
| SCREENSHOT_TASK | — | Take a screenshot | — | Captures a screenshot of the main display, encodes it in PNG format, splits the resulting buffer into 200 KB chunks, and transmits them to the C2 server |
CapDoor checks the tasks in the list and performs them one by one.

The execution result is sent to the C2 server and has the following structure:
struct TASK_REPORT_PACKET {
DWORD msgType; // = 3
DWORD GuidLen;
BYTE Guid[GuidLen]
DWORD TaskIdLen;
BYTE TaskId[TaskIdLen];
DWORD DataLen;
BYTE Data[DataLen];
};
Figure 24. Structure of the message containing the execution result
After analyzing numerous CapDoor versions and delivery chains, we conclude that the tool is being actively developed and regularly updated. For example, previous versions had the following differences:
- Instead of the DLL sideloading chain, attackers used the GHOSTPULSE loader (IDATLOADER or HIJACKLOADER) to load CapDoor.
- CapDoor was distributed as an executable file, whereas in recent attacks it is deployed as shellcode.
- Process Hollowing was used to execute CapDoor.
- Early versions of CapDoor did not support taking screenshots; this functionality was added in later versions.
- To execute MSI files downloaded upon a command from the C2 server, the malware called the ShellExecuteW (NULL, L"open”, L"msiexec.exe”, L"/i \"%TEMP%\\[a-z]{20}.msi\””, NULL, 0). Current versions use MsiInstallProductW () for this.
- Early versions of CapDoor supported downloading and executing shellcode as part of the DOWNLOAD_TASK routine, but this feature is no longer present in the latest versions.
Additional information
Researchers generally classify CapFix as a financially motivated group, although the selection of targets and the recent use of phishing tools align more with APT or hacktivist operations. CapFix has previously targeted Russian companies using fake CAPTCHA pages (ClickFix). In those incidents, CapDoor was named an "unclassified Remote Access Trojan (RAT).
During our investigation into CapDoor, we uncovered early samples used by the attackers. We found several samples that used an icon of an egg with the Bitcoin logo, which was also displayed upon execution. For instance, the sample SHA-256: d67d1628ff5ea924c25c8056446a8143e1171fab7e30dddb24aca3255dad8displayed the following image when launched:

We found more than 10 similar samples uploaded to public sandboxes from various countries (including the Netherlands, Mexico, the U.S., and France). All of them were uploaded in November 2025. The icons and the image shown upon execution resemble the branding of BitcoinIRA, a niche crypto service.
We found samples that used CapDoor sending the following requests to C2 servers:
- http://85.192.49.81/search/?text=[a z]{30}
- http://94.156.232.113/search/?text=[a z]{30}
In these samples, SectopRAT or ArechClient2 was used as the final payload.
Interestingly, a month prior—in September and October 2025—the CapDoor C2 server at 85.192.49.81 was used for AsyncRAT in ClickFix campaigns. For example, in October, the attackers used the domain booking.l-extranet.com employing the ClickFix technique.

In these attacks, the group used GitHub pages to redirect victims to malicious domains. For example, the page bedrewiews.github.io/reservasboolikng.com/ redirected users to booking.fleps-extranet.com.


Because in these specific attacks the threat actors used AsyncRAT rather than CapDoor, they cannot be definitively linked to CapFix. However, considering all the data (not just the tools), we believe the group is responsible for these campaigns as well.
As we mentioned earlier, during their autumn campaigns, the attackers used PDF files that prompted victims to download an additional payload. We took a closer look at the phrasing used in one of these phishing documents:

The attackers made several errors, both linguistic and factual:
- The mention of "ЦИБ МО РФ" (which supposedly stands for "Center for Information Security of the Ministry of Defense of the Russian Federation") is a clear sign of phishing. No such organization actually exists.
- The Russian phrase "Нажмите кнопку ниже, для установки" (Click the button below, to install) contained a punctuation error (an unnecessary comma).
- The use of the term "CHM snap-in" (CHM оснастка). In Microsoft's official Russian documentation, "snap-in" is translated as "оснастка." However, in this context, the combination "CHM snap-in" looks awkward and is used erroneously.
- As we noted previously, in some cases, the names of the files did not match their contents.
Conclusion
CapFix continues to refine CapDoor and its malicious to make their attacks more successful. While the group previously relied on financially themed phishing emails (cryptocurrency and anything money-related), they are now increasingly masking their emails as official communications from government agencies.
The attackers use compromised legitimate infrastructure, which significantly complicates the analysis and detection of their attacks. In March 2026, CapFix began using domains that we had been tracking since late 2025 and early 2026. We believe the attackers planned to use at least two additional domains that are currently attributed to them but remain inactive.
Indicators of compromise
File-based IoCs
Network indicators of compromise
MITRE ATT&CK matrix
Positive Technologies product verdicts
PT Sandbox
PT ESC
| Verdicts |
|---|
| PTESC_apt_win_ZZ_CapFix__Backdoor__CapDoor__mainModule__PeVersion |
| PTESC_apt_win_ZZ_CapFix__Dropper__CapDoor__decryptStage |
| PTESC_apt_win_ZZ_CapFix__Dropper__CapDoor__decryptStage__NetVersion |
| PTESC_apt_win_ZZ_CapFix__Trojan__CapDoor__PrepareAndInject__NetVersion |
| PTESC_apt_win_ZZ_CapFix__Trojan__CapDoor__hideWindow |
Behavioral rules
| Verdicts |
|---|
| Trojan.Win32.Generic.a |
| Exploit.Win32.DirectIo32.a |
| Trojan.Win32.Inject.a |
| Trojan-Dropper.Win32.Generic.i |
PT AV
| Verdicts |
|---|
| Trojan.Win64.CapFix |
Network verdicts
| Verdicts |
|---|
| LOADER [PTsecurity] CapDoor Checkin (APT CapFIX) sid: 10015625, 10016787 |
| REMOTE [PTsecurity] SectopRAT sid: 10012587 |
PT EDR
Behavioral rules
| Verdicts |
|---|
| Suspicious_Create_Process_DLLSideLoading_Evasion |
| Suspicious_Create_File_Extension_LibraryMS |
| Windows_Autorun_Modification |
PT AV
| Verdicts |
|---|
| Trojan.Win64.CapFix |


