Summary
We discovered a FamousSparrow campaign that used two tools: the new SquawkDoor backdoor and an updated version of the SparrowDoor backdoor.
The primary targets in the observed campaigns were Nepal, the Philippines, Indonesia, Taiwan, Egypt, Germany, and the Czech Republic.
FamousSparrow gained access to an information system belonging to an international research organization focused on food security.
FamousSparrow compromised websites and injected malicious JavaScript that displayed a fake error message and prompted users to download a certificate. In reality, the certificate was a malicious MSI file that infected systems with the SquawkDoor and SparrowDoor backdoors.
The threat actor made several OPSEC mistakes, allowing us to identify one of the group members involved in preparing the attack.
We identified several overlaps between FamousSparrow attacks and activity associated with other East Asian threat groups.
Introduction
In the first half of 2026, we discovered activity by the East Asian threat group FamousSparrow. Its attacks targeted several countries in South Asia and Europe. In these attacks, the threat actor used its own malware: a heavily reworked variant of the modular SparrowDoor backdoor and a new backdoor that we named SquawkDoor.
FamousSparrow, also known as Salt Typhoon and Earth Estries, is an East Asian threat group that has been active since 2019. The group is known for using its proprietary SparrowDoor backdoor and initially focused on attacks against hotels worldwide, as well as government and international organizations. Later, FamousSparrow began actively targeting telecommunications companies and internet service providers, apparently seeking long-term access to lawful communications intercept systems.
In these attacks, the threat actor used both malicious LNK files and a website compromise vector involving malicious JavaScript. The injected script displayed a fake error message when a user visited the page and prompted them to download a new certificate. In reality, the download was a malicious executable that led to backdoor infection. The attacks were tailored to specific countries:
the JavaScript samples and payloads contained text customized for the target country.
Victims
In the campaign we discovered, users in South Asia submitted malicious files to public sandboxes from various locations including Indonesia, the Philippines, Nepal, and Taiwan.
Based on the samples we identified, we determined that the threat actor used an infection chain involving compromised websites and fake certificates in at least four locations: Taiwan, Germany, Indonesia, and the Czech Republic.
While investigating the compromised websites, we confirmed that FamousSparrow had gained access to an information system belonging to an international research organization focused on food security. On this organization's platform, the threat actor injected malicious JavaScript that delivered fake certificates. In this case, the likely targets were researchers who use the platform as a library and a place to publish articles.
The JavaScript on the compromised websites contained text in specific languages, and the SquawkDoor samples had messages in specific languages embedded in them. This suggests that the attacks were prepared for specific countries. The JavaScript also included functions for collecting infection statistics: /report-url and /track-download. We did not observe mass infection in this case, although the functionality clearly supports scaling the campaign if needed.
Attacks involving SquawkDoor
Attacks using LNK files
While monitoring the group's activity, we discovered attacks involving Indonesian-language files. One example is the archive Strategi_AS_Referensi_April2026.rar (SHA-256: 1def54444cab1fd17fe5acb42dd0d2293bcb9ce72a8e955bf6796d10d662c4ff).
The archive contained four files:
Strategi_AS_Referensi_April2026.docx.lnk (SHA-256: 4c7ae604ad1af90ea155865cb28fd7ccd6371f5ac172de6014b328514d4618e7)
info.dll (SHA-256: 39bdf92a70a1bb4f07e58cd1081f80fced85df01c1f14a56ed5783104c902439)
.rels.log (SHA-256: 1a442a8e12c1571a0663e64e0ac9c930035bb267259b684cd9607f76be6d017b)
557.pdf (SHA-256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855)
When the LNK file is launched, it executes the following command: "C:\Windows\System32\ftp.exe" -""s: _rels\info.dll
In this case, the Windows parser consumes the quotation marks, allowing the attacker to bypass simple detections for the -s option. info.dll is a BAT script that contains the following command:
Figure 2. Contents of the info.dll script
The script copies .rels.log from the _rels folder to the temporary directory, removes its attributes, extracts its contents, runs the extracted hhc.exe, opens 557.pdf as a decoy document, and removes traces of execution.
.rels.log (SHA-256: 1a442a8e12c1571a0663e64e0ac9c930035bb267259b684cd9607f76be6d017b) is a CAB archive that extracts the following files to %TEMP%:
hhc.exe (SHA-256: fafb6ffd3ffcf414b702354f62a5216351af4566ed61ece7784846a6938bb8d9): a legitimate executable vulnerable to DLL sideloading.
MSVCR110.dll (SHA-256: c69534bb3e6d4e1c9b21f9e4745f6fb002cbcd3ab83f9ad208eb7bb135401062): a DLL used for DLL sideloading.
hcc (SHA-256: 60292dee0e07a2b889d657e2fbd2f1cd517eaea58f1cfb1ed4a721a173520499): the payload containing the SquawkDoor backdoor.
The payload was a new backdoor, which we describe later in this article. We named it SquawkDoor because of its unique mutex and distinctive magic value.
Attacks using fake certificates
While searching for related files, we found compromised websites that had a malicious JavaScript file embedded in their HTML:
<script src="https://malicious.com/js/jquery.min.js?s=*number*"></script>
The threat actor deliberately named the file jquery.min.js to make it appear legitimate and avoid raising suspicion.
The JavaScript is obfuscated with the popular JavaScript obfuscator JSV7/sjiami.com.v7.
Figure 3. Obfuscated JavaScript file
After partially deobfuscating the script, we identified the following functionality:
Code integrity check
The script runs an immediately invoked function expression (IIFE) that performs a code integrity check. If the code has been modified, the check triggers an error.Anti-analysis protection
The code implements anti-debugging mechanisms, including hooks for console methods, hidden debugger statements, and recursive dynamic analysis techniques designed to complicate analysis and decompilation.Platform check
The script checks whether the user's platform is Windows using the following logic:const isWindows = navigator.userAgent.includes ("Windows NT");
if (isWindows) {
// malicious code
}Heartbeat
The script contains serverUrl, which stores an encoded C2 address, and checkInterval, which is set to 1,000 ms by default. The script checks C2 availability using the following code:const img = new Image ();
img.src = serverUrl + "/image-check? t=" + Date.now ();
Figure 4. Heartbeat request Page content replacement
The script completely clears the <body>, creates a large full-screen iframe, and displays a fake SSL error page. In this example, the page is in Czech.
Figure 5. Script with hardcoded Czech text
The script also sends a POST request to serverUrl/report-url to log which pages the user visited from and which other sites are compromised.
As a result, when the user visits the site, they see the following message:
Figure 6. Output of the script shown to the user
When the user clicks "Nainstalovat certifikát" ("Install certificate"), the script sends a request to serverUrl/track-download, apparently to log the download event, and also sends a request to downloadUrl to download the payload from an Amazon S3 bucket.
In this case, the encoded C2 and download URLs were as follows:
serverUrl: pplpp.microsfot.vip
downloadUrl: uploads-temp.s3.amazonaws.com/scadwadwaew/certificate_repair_tool.msi
At the time of our investigation, the downloadUrl from this script was unavailable. However, we found another similar URL associated with these attacks:
The MSI files downloaded from the S3 bucket, including the file with SHA-256: b379d07ba81d4190490d9893b2d6d830ff594e042dce26053ef07794d0403787, contained the following command:cmd.exe /C ping 127.0.0.1 -n 3 > Nul & del /f /q "C:\Users\admin\AppData\Local\WinOx\hhc.exe" & del /f /q "C:\Users\admin\AppData\Local\WinOx\MSVCR110.dll" & del /f /q "C:\Users\admin\AppData\Local\WinOx\hhc"
As with the malicious LNK files described above, this infection chain also uses hhc.exe with the same hash. However, the MSVCR110.dll file is different: f23e5391656b178bc0ab510b0fca6ffbd963cf94870c82a5920f0f338f561f18.
When executed, these MSI files displayed messages in the victim's language. For example, in the attack targeting Taiwan, the following message appeared in Traditional Chinese:
証書安裝成功, 請返回瀏覽器操作! ("The certificate has been installed successfully. Please return to the browser to continue.")
In June, we also found a similar MSI file, CertFixer.msi (SHA-256: f51dc5e1848daee4e607d46faa25033e1151060cd3482ad4439754440d6c4c01), targeting Germany and using infrastructure in the same country. This file displayed messages in German, but the meaning was the same.
Figure 8. Message displayed when the malicious MSI is launched
When executed, the MSI creates the %LOCALAPPDATA%\Local\WinxA\ directory and drops a legitimate hhc.exe file, a malicious MSVCR110.dll library loaded via DLL sideloading, and an hhc file containing the encrypted payload. The payload was a previously undocumented backdoor, which we named SquawkDoor.
SquawkDoor
Loader
During initialization, the malicious MSVCR110.dll library dynamically resolves the addresses of the required API functions using the FNV-1a hashing algorithm with modified constants: the initial value 0×5D8CED15 and the multiplier 0×024151A3. The library also allocates memory for the payload.
As the legitimate application runs, it calls the first replaced exported function, __crtSetUnhandledExceptionFilter (). This function reads the contents of the hhc file, which contains the encrypted payload, and stores it in the allocated memory region.
Next, the legitimate executable calls the second replaced exported function, excepthandler4_common (). This function decrypts the payload using the RC4 algorithm and the key Hg5th5324Ve. After changing the memory permissions, it transfers execution to the decrypted payload.
Once it receives control, the shellcode loader reflectively loads the final payload, which is the group's new backdoor, SquawkDoor.
SquawkDoor backdoor
During initialization, the backdoor dynamically resolves the addresses of imported functions by hashing API names. It uses a custom algorithm with the initial value 0×753AB21D and a table of 12 constants. On each iteration, the next character of the API name is mixed into the current hash value using table lookups, XOR, subtraction, and multiplication by the constant 0xA3AB09. After all characters have been processed, the final value is compared against a predefined hash for the target function.
uint32_t hash_func(char *name) { uint32_t table[12] = { 0x753AB21D, 0x026CA124, 0x04671A71, 0x016371B8, 0x028174BB, 0x0635134C, 0x01475612, 0x0562154A, 0x03225411, 0x04124411, 0x04214ABC, 0x03244ABC };
uint32_t hash = 0x753AB21D; while (*name) { uint8_t c = *name++; uint32_t value = 0xA3AB09 * ((hash ^ (c + table[c % 12])) - table[hash % 12]); value &= 0x07FFFFFF; hash = value + table[value % 12]; } return hash;
Figure 11. Implementation of API function name hashing
Before handing off execution to SquawkDoor's main logic, the backdoor hides the console window by calling ShowWindow (hwnd, SW_HIDE), It then checks whether it is running from the expected working directory, %TEMP%. If the current launch directory does not match the expected path, the backdoor copies the components required for further execution to %TEMP%: the legitimate executable, the DLL used for sideloading, and the file containing the encrypted payload.
After placing the files in the target directory, the backdoor silently launches its own copy from %TEMP% using CreateProcessA () with the CREATE_NO_WINDOW flag.
It then starts a cmd.exe process that, after a short delay, deletes the original files with the following command:cmd.exe /C ping 127.0.0.1 -n 3 > Nul & del /f /q "<legit.exe>" & del /f /q "<malicious.dll>" & del /f /q "<encrypted_payload>".
The backdoor then adds the new copy to the current user's startup under the name WindowsUpdateAssist and creates the named mutex squadc_single_instance to prevent multiple instances from running.
The backdoor's configuration is stored encrypted and decrypted using the RC4 algorithm with the key Hg5th5324Ve. The configuration contains the C2 server address, the magic value used for validation "XlocmwW", the URL for JSON ping requests, the server polling interval in minutes, and flags that control whether the backdoor waits for a browser process and performs anti-analysis checks.
After decryption, the configuration has the following structure.
struct EMBEDED_CONFIG { BYTE c2_address[0x40]; BYTE magic_tag[0x40]; BYTE c2_json_ping_url[0x100]; DWORD beacon_interval_minutes; DWORD need_browser_waiting; DWORD anti_analysis_enabled; };
Figure 14. SquawkDoor configuration structure
Notably, the command-and-control server address and the magic_tag value used during C2 connection setup are initialized by default as 127.0.0.1:8443 and changeme, respectively. The use of a localhost address as a template value likely indicates that the threat actor conducted local testing.
If the anti_analysis_enabled flag is set in the configuration, the backdoor runs a set of 12 anti-analysis checks. These checks are designed to determine whether the sample is running in a sandbox, a virtual machine, or another virtualized analysis environment. If seven or more indicators are detected, SquawkDoor treats the environment as suspicious. The checks are as follows.
Mechanism | Purpose | Criterion |
|---|---|---|
Memory Size | Checks the amount of RAM | Total physical RAM is less than 2 GB |
Disk Size | Checks the size of the system drive | The C:\ drive is smaller than 50 GB |
VMware Registry | Looks for VMware artifacts in the registry | At least one of the following registry keys is present: SOFTWARE\VMware, Inc.\VMware ToolsSOFTWARE\VMware, Inc.\VMware WorkstationSYSTEM\CurrentControlSet\Services\VmwareHARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0 |
VMware Process | Looks for VMware processes | At least one of the following processes is running: vmtoolsd.exevmwaretray.exevmwareuser.exevmwarew.exe |
VMware Files | Looks for VMware Tools files, libraries, and drivers | At least one characteristic file is present on the system: C:\Windows\System32\Drivers\vmmouse.sysC:\Windows\System32\Drivers\vmhgfs.sysC:\Windows\System32\Drivers\vmmemctl.sysC:\Windows\System32\vmtray.dllC:\Windows\System32\vmtools.dllC:\Windows\System32\vmusr2.dllC:\Program Files\VMware\VMware Tools\vmtoolsd.exeC:\Program Files (x86)\VMware\VMware Tools\vmtoolsd.exe |
MAC Address | Checks network adapter MAC addresses | At least one active network adapter has a MAC address whose first three bytes match a known virtualization-related prefix: 00-05-69 — VMware00-0C-29 — VMware00-50-56 — VMware08-00-27 — VirtualBox00-15-5D — Hyper-V00-1C-42 — Parallels00-16-3E — Xen52-54-00 — QEMU/KVM00-1A-4A — KVM/Qumranet00-0F-4B — Oracle/Virtual Iron |
VM Drivers | Looks for VMware/VirtualBox drivers and services | At least one of the following service registry keys is present: SYSTEM\CurrentControlSet\Services\vmmouseSYSTEM\CurrentControlSet\Services\vmhgfsSYSTEM\CurrentControlSet\Services\vmmemctlSYSTEM\CurrentControlSet\Services\VBoxGuestSYSTEM\CurrentControlSet\Services\VBoxMouseSYSTEM\CurrentControlSet\Services\VBoxSF |
VM Devices | Checks connected devices | The description of at least one device contains one of the following strings: VMwareVirtualBoxVBoxQEMU |
Screen Resolution | Checks the screen resolution | The current screen resolution matches one of the following values: 800×6001024×7681280×10241440×900 |
BIOS | Checks BIOS data in the registry | The BIOSVendor or BIOSVersion values under HKLM\HARDWARE\DESCRIPTION\System\BIOS contain strings associated with virtualized environments: VMwareVirtualBoxQEMUBochsXeninnotek |
Motherboard | Checks the system manufacturer | The SystemManufacturer value under HKLM\HARDWARE\DESCRIPTION\System\BIOS contains one of the following strings: VMwareVirtualBoxQEMUBochsXeninnotek |
System Firmware | Checks the product name | The SystemProductName value under HKLM\HARDWARE\DESCRIPTION\System\BIOS contains one of the following strings: VMwareVirtualQEMUVirtualBox |
If the need_browser_waiting flag is set in the configuration, SquawkDoor postpones execution of the main payload until it detects one of the target browsers. To do this, it enumerates running processes every 30 seconds. Execution resumes only after one of the following processes is found:
chrome.exe;
firefox.exe;
msedge.exe;
edge.exe;
brave.exe
This mechanism acts as an additional anti-analysis technique: the program waits for a running browser, since in the attacks described above the payload was delivered through fake web pages.
In addition, if the c2_json_ping_url parameter is present in the configuration, the backdoor sends a one-time HTTP/HTTPS POST request to the specified URL. The request body contains an empty JSON object. Although the server response is read, its contents are not processed and do not affect the subsequent execution flow. The outgoing HTTP request has the following structure.
POST /register-ip HTTP/1.1 Host: <domain> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Content-Type: application/json Content-Length: 2 Connection: close {}
Figure 17. Structure of the outgoing HTTP request
Because all the investigated attacks used /register-ip as the endpoint, we assess that this mechanism was used by the attackers as a marker confirming successful malware execution on the victim's system. Receiving this request may also have served as a trigger for certain operator-side logic.
After completing all preparatory steps, the backdoor attempts to establish a connection to the command-and-control server. It does this in an infinite loop, making a series of sequential attempts to establish a secure TLS-over-TCP connection.
If the first connection attempt fails, two additional attempts are made after one and two minutes, respectively. After three consecutive failures, the next round of connection attempts starts after beacon_interval_minutes minutes, or after 30 minutes if this field is not defined.
Once the connection is successfully established, the backdoor sends the magic_tag value extracted from the configuration to the command-and-control server. Subsequent data exchange uses a custom protocol. Each inbound and outbound message begins with the SQD1 magic value and follows the structure shown below.
struct MESSAGE { uint32_t magic; // "SQD1" uint16_t control_code; // номер управляющей команды uint16_t error_flag; // статус ответа uint32_t body_len; // длина тела в байтах uint8_t body[]; // тело сообщения };
Figure 18. Inbound and outbound message format
Notably, during the initial transmission of the magic value, the control_code field is set to 1.
If the error_flag is not set in the server response, SquawkDoor collects basic information about the compromised system, including:
OS version
Computer name
The first active IPv4 address assigned to a network interface, excluding localhost
The collected data is sent to the C2 server with control_code set to 9.
In response to the system information, the command-and-control server returns a command for execution. During our analysis, we identified the following commands supported by the backdoor.
Command type | Command code | Description | Argument data |
|---|---|---|---|
Incoming | 2 | Lists files in the specified directory. Executed via cmd /C dir "<path>" | Directory path |
Incoming | 3 | Deletes the specified file or directory | Full path to the file or directory |
Incoming | 4 | Creates a file at the specified path and writes the supplied data to it | Contains the path of the file to be created and the data to write:[2-byte path_len][N-byte file_path][M-byte file_data] |
Incoming | 5 | Executes an arbitrary command through the command interpreter and returns the output | Command for the interpreter |
Incoming | 6 | Collects system information by executing systeminfo | — |
Incoming | 7 | Captures a screenshot | — |
Incoming | 8 | HEARTBEAT | — |
Incoming | 10 | Runs an arbitrary command as a detached background process, without a window, without waiting for completion, and without capturing output | Command for the interpreter |
Outgoing | 1 | Sends magic_tag for initial SquawkDoor identification | The magic_tag value is passed in the message body |
Outgoing | 9 | Sends collected information about the victim system | The collected system information is passed in the message body:os=<win_version>\nhost=<computer_name>\nip=<ipv4> |
Commands are executed in a child process with its output streams redirected through pipes.
Attacks using SparrowDoor
Using unique strings found inside the installer files, we identified an MSI with a similar name, CertFixer.msi (SHA-256: e5f7bbfc187264336dea5dfebfb5a7dd1e7fcdcc9692db55fbe6eb4d28f027bc). When executed, it displays a similar certificate-installation success message, this time in English.
During our investigation of the attack, we found that the threat actor used a heavily reworked variant of the modular SparrowDoor backdoor. In this version, the set of supported communication protocols was expanded, the configuration format was changed, stealth capabilities were improved, and the tool's architecture was revised.
SparrowDoor previously existed in two variants. The monolithic version included a set of built-in commands for controlling a compromised system, but did not support extending its functionality through plugins. The modular version, in contrast, provided only the basic capabilities required to load and manage plugins, with additional functionality delivered through modules downloaded from the command-and-control server.
The variant we identified combines capabilities from both versions: it supports an expanded command set, can load additional modules, and includes several preinstalled plugins.
In addition, this backdoor version incorporates certain technical and architectural approaches from other tools in the same shared-codebase family, including earlier versions of SparrowDoor, CrowDoor, TernDoor, and Hemigate. The toolkit's evolution and a comparative table are provided in the "Family development" section.
SparrowDoor Loader
When launched, the delivered MSI creates the %LOCALAPPDATA%\Local\WinxA\ directory, similar to the directory used by SquawkDoor, and drops three files there: the legitimate Avast Antivirus Installer (NisaSrv.exe), the malicious WTSAPI32.dll library, and a file named NisaSrv containing the encrypted payload.
During initialization, the malicious library loaded via DLL sideloading reads the first 16 bytes of the .text section of the process into which it has been loaded. This value is then used as the RC4 key to decrypt the names of WinAPI functions.
Next, the library dynamically resolves the required APIs and uses HeapAlloc to allocate about 5 MB of heap memory for the payload.
At the next stage, the malicious DLL modifies the execution flow of the legitimate process. Using VirtualProtect (), it temporarily makes writable a code region of the legitimate NisaSrv.exe that contains the 4-byte operand of a CALL instruction (0xE8). This operand stores the relative offset to the target function. The malicious library overwrites it with a new offset pointing to the payload decryption function inside the DLL. As a result, the next execution of the CALL instruction transfers control to malicious code.
The decryption function reads the payload file and determines the next processing scenario based on its first two bytes. If the file starts with 0×91 0×91 or 0xD1 0×92, the malware treats this as the first execution, meaning that its components have not yet been moved to the working directory. In this case, the payload is decrypted in a single RC4 pass using the key oWbgvv5234$43gh.
If these markers are not present, the malware assumes that the files have already been moved to the target directory and re-encrypted. In that case, the contents are first decrypted with RC4 using a key derived from the full path to the payload file, followed by the main decryption stage.
Once decryption is complete, execution is transferred to shellcode that reflectively loads the PE file into the process memory.
Reflective loading shellcode
The decrypted file contents include a custom header containing the parameters required for reflective loading, the shellcode loader to which the library transfers execution, and the raw sections of the SparrowDoor backdoor.
The reflective-loading parameter header contains the entry point of the module to be loaded, the number of sections, the relative virtual addresses of the relocation and import tables, the image base address, and the location and size of each section. This header can be represented by the following structure:
struct ShellcodeLoaderHeader { _DWORD entry_rva; _DWORD sections_count; _DWORD reloc_rva; _DWORD import_rva; _DWORD image_base; _DWORD unused; _DWORD sections_rva[7]; _DWORD sections_size[7]; };
Figure 24. Reflective-loading parameter header structure
Updated modular SparrowDoor
Initialization
During initialization, the shellcode-loaded SparrowDoor hides the process console window, dynamically resolves the addresses of target functions using a hash function of the form hash = ROR32(hash, 2) + name[i], and checks whether the current date is later than the cutoff date of April 2027.
If the date check passes, the agent decrypts its configuration. The configuration is stored at the end of the encrypted payload file and is decrypted with the same RC4 algorithm and the same key, oWbgvv5234$43gh.
The decrypted configuration contains the C2 server addresses, connection parameters, network protocol used to communicate with the C2 server (see below), the working directory, the name of the service created for persistence, and the second part of the key used to encrypt messages between the agent and the C2 server. The agent configuration has the following structure.
struct C2Entry { _BYTE host[0x80]; _WORD port; _DWORD transport; }; struct Config { C2Entry c2[3]; _BYTE target_path[0x100]; _BYTE service_name[0x40]; _BYTE rc4_key_part[0x40]; _DWORD reconnect_delay_min; _DWORD sleep_ms; };
Figure 26. Decrypted SparrowDoor configuration structure
Notably, this version of SparrowDoor creates an environment variable named datx, which stores the full path to the encrypted payload file. The malware uses this variable to extract the configuration from the end of the file.
The agent then parses the startup arguments passed to it.
SparrowDoor launch sequence
During execution, SparrowDoor relaunches itself multiple times with different arguments, each corresponding to a separate stage of the malware's workflow.
Launch without arguments: sets up persistence. It creates the working directory specified in the configuration and copies into it the three files extracted by the MSI installer: the legitimate executable, the malicious DLL used for DLL sideloading, and the payload file.
The payload file is additionally encrypted with RC4, using the file's full path as the key. The final 0×31A bytes, which contain the configuration, are left unchanged.
The agent then attempts to disguise the created files and working directory by setting their timestamps to match those of the system library ntdll.dll, and by applying the hidden and system attributes.
To establish persistence, the agent creates a Windows service with the name specified in the configuration (NisaSrv). This service is configured to automatically launch the copied legitimate executable when the user logs on.
If the service cannot be created or started, the agent adds the executable to the current user's autorun key and launches it.
When launched from the target directory, the agent starts its new copy via ShellExecuteA ("open"), passing the /a argument, and then terminates the current process.
Launch with the /a argument: decrypts the payload file contents twice: first using the file's full path as the key, and then using oWbgvv5234$43gh. It then starts msiexec.exe with the /c argument. In the context of this process, it allocates executable memory and writes the decrypted payload into it. Execution is then transferred to the loaded shellcode.
Launch with the /c argument: creates a named mutex in the format xnv_<internal_version>_<service_name> (in this case, xnv_1.1.0_NisaSrv) to prevent multiple instances from running. The agent then identifies the user session in which explorer.exe is running and uses that session ID to find a winlogon.exe instance running in the same session.
If such a process is found, the agent opens and duplicates its access token, then uses that token to start msiexec.exe via CreateProcessAsUserA, passing /b as the argument. If the token cannot be obtained, msiexec.exe is started via CreateProcessA with the same argument.
After creating the process, the agent allocates memory in the address space of msiexec.exe, decrypts the payload twice, writes it to the allocated memory region, and transfers execution to the decrypted shellcode.
It is also worth noting that, unlike previous instances, the current process does not terminate after completing its primary tasks, but continues to operate as a watchdog, ensuring SparrowDoor remains running and restarting it when necessary.
Launch with the /b argument: activates the agent's main logic.
Launch with the /u argument: starts the agent uninstallation routine. During this process, the malware removes its persistence mechanisms and the working directory it created, then builds and runs the command cmd /c taskkill /F /IM msiexec.exe. This command forcibly terminates all msiexec.exe processes, including the instance used to run the injected payload.
Preinstalled plugins
After the previous stages are completed successfully, execution proceeds to agent setup and preparation. At this stage, the malware creates a circular doubly linked list of built-in plugins and their handlers.
Each plugin is associated with a separate command group identified as 0×10000, 0×20000, … 0xF0000. The group identifier is extracted from the full command code using the command & 0xF0000 mask, while the lower 16 bits specify the action to be performed by the selected plugin. For example, for a keylogger plugin with the identifier 0×40000, command 0×40003 could activate the keylogger, while 0×40004 could deactivate it.
In the analyzed sample, the agent includes the following built-in plugins:
0×10000: a module loader and fallback command handler for commands whose target module has not yet been registered. If the plugin for the command group has not yet been registered, the command is routed to the loader. The loader identifies the missing module by its group identifier, requests it from the C2 server, decrypts it, loads it into memory, and calls the exported fmain function. It then registers the received module in the list of installed modules and transfers execution to the loaded module's handler.
0×40000: a keylogging module. When started, it installs a low-level keyboard hook with SetWindowsHookExW (WH_KEYBOARD_LL, …) and creates a separate thread that runs a message loop. This thread monitors keystrokes, identifies the currently active window, records its title, and accumulates the typed characters in an internal buffer. Special keys are handled separately and stored in readable form: [back], [tab], [enter], [ctrl], [alt], [esc]. When the active window changes, the buffer reaches 1008 bytes, or a timer triggers every 2 seconds, the accumulated data is saved to a file in the kl subdirectory of the working directory, where kl stands for keylog. The file name uses the format <YYYY>-<MM>-<DD>-<HH>-<mm>.x. Before the data is written, the string is encrypted with RC4 using a static key (see below), and then Base64-encoded.
Communication with the C2 server
After setting up the built-in plugins, the agent enters an infinite loop. In this loop, it iterates through all entries defined in the configuration and attempts to connect to the command-and-control server. The communication method for each entry is determined by the transport parameter.
transport | Communication method |
|---|---|
0×01 | Plain TCP connection |
0×02 | TLS-protected TCP connection |
0×03 | HTTP communication |
0×04 | HTTP communication |
When HTTP (S) is used, the agent sends data to the command-and-control server in POST requests to /325asd/fd.php using the following format.
After establishing a connection to the C2 server, the agent remains in the same infinite loop and collects information about the victim system. The collected data includes the current date, the IPv4 address of the first local interface, the OS version, the user name, the computer name, the list of antivirus products installed on the system, the agent version, and a generated victim system identifier.
After collecting this information, the agent packs it into the following structure for transmission.
struct SYSTEM_PROFILE { _WORD local_year; _WORD local_month; _WORD local_day; _DWORD local_ipv4; _DWORD os_build; _DWORD os_major; _DWORD os_minor; _BYTE host_id_hex[0x20]; _BYTE user_name_utf8[0x40]; _BYTE computer_name_utf8[0x40]; _BYTE antivirus_names[0x40]; _BYTE client_version[0x20]; };
Figure 34. Collected system information structure
The collected system information is encrypted using the RC4 algorithm. The key for it ("fdibnvvgbVUGV_hh3(2") is formed from two parts: the first part is extracted from the configuration ("fdibnvvgbVUGV"), and the second is hardcoded in the agent ("_hh3(2"). The generated static key is used to encrypt and decrypt messages.
Before sending the main message, the agent first sends a 4-byte magic value, 0×21A43B. If this value is delivered successfully, it sends a message header containing the message type, represented by the magic value 0×6A26B, and the payload size. The encrypted system information is then sent after the header.
The outgoing message header has the following format.
struct MsgHeader { _DWORD magic; _DWORD len; };
Figure 35. The header format of the sent messages
In response, the command-and-control server sends a 12-byte message. At this stage, the agent checks only the magic marker in the response: the marker field must always be 0xA1.
struct C2_COMMAND_HEADER { _DWORD command_id; _DWORD payload_len; _DWORD marker; };
Figure 36. Format of incoming C2 messages
After sending the system information, the agent starts receiving control messages. Each incoming message begins with a similar 12-byte header that contains the command identifier, payload size, and marker. The message is treated as valid only if the marker is 0xA1. If payload_len is nonzero, the header is followed by a separate message containing a payload of the specified size.
Processing received commands
The command_id value in the received header determines which command is executed. The supported commands are listed in the table below.
Purpose | command_id | Description |
|---|---|---|
Plugin management | 0×22BB,0×22BC,0×22BE,0×22C0 | SparrowDoor creates a separate thread that establishes a connection to the command-and-control server and sends the parameters of the new session, including the infected system identifier and service values specific to the command. This channel is then used to deliver commands to the plugin dispatcher. The agent receives a message, decrypts the payload with RC4 using the static key, and passes the command to the appropriate plugin handler based on its identifier. If the required handler is not present, the agent uses the loader plugin to download the corresponding PE plugin from the C2 server, then passes the original command to the newly loaded plugin. to the newly loaded plugin. |
0×22BD | ||
0×22BA | ||
Sending the current configuration to the C2 server | 0×22B8 | SparrowDoor extracts and decrypts the configuration using RC4 and the embedded key, then encrypts the result with the previously generated static key. It then creates a response with the header magic = 0x6A26D and sends it to the C2 server. |
Updating the configuration | 0×22B9 | SparrowDoor decrypts the supplied configuration using RC4 and the static key, then encrypts the updated configuration with the embedded key and overwrites the configuration block at the end of the payload file. |
Self-deletion and shutdown | 0×22BF | SparrowDoor removes its persistence mechanisms and working directory, terminates the process into which it was injected, and then calls ExitProcess. |
Downloading a file to the temporary directory | 0×22C1 | SparrowDoor decrypts the payload using RC4 and the generated static key, then extracts the data size, file name, and file contents. It then creates the file in %TEMP% and writes the received data to it. |
Launching a file from the temporary directory | 0×22C2 | SparrowDoor receives an encrypted file name, decrypts it, and constructs the full path to the file in %TEMP%. The file is then launched via ShellExecuteA ("open"). |
Attribution
Attacks linked to FTPlnk_phishing
In these attacks, FamousSparrow used an LNK file to abuse a living-off-the-land binary.
When the victim clicks the LNK file, Windows reads the Relative Path field, which is set to ..\..\..\..\Windows\System32\ftp.exe. It then resolves this path to the legitimate ftp.exe binary and executes it without an absolute path being specified.
ftp.exe is passed the argument ftp.exe -s:"_rels\info.dll". In our case, this file was a .bat script.
The technique comes from FTPlnk_phishing, which we previously covered in our article on the Asia-focused group UnsolicitedBooker. In that article, we showed metadata from the original LNK file in the official repository. The original argument referenced python.dll, but the underlying technique remains the same.
In that article, we noted that we had previously observed FTPlnk_phishing being used by two groups: UnsolicitedBooker and MustangPanda in an attack on the Royal Police. After further research, we found that at least two vendors have publicly described similar attacks.
The first report is on Operation GriefLure. In that report, the researchers described an APT campaign targeting Vietnamese military telecommunications and the Philippine healthcare sector. In this campaign, the attackers also used the ftp.exe -s: command, which launched a script, as in our case. Here, however, the script assembled an EXE file and a polymorphic DLL from document fragments. File assembly using copy /b commands and time-based polymorphism differs significantly from our case, but we can say with confidence that the group behind the operation used the same FTPlnk_phishing technique. The researchers did not attribute the attack to a specific group, but based on the TTPs and targeting, Mustang Panda is a plausible actor behind it.
The second attack we focused on involved a fake Claude website and the Beagles backdoor. The group used fake domains to download MSI files, each containing three components: a legitimate EXE, a DLL used for sideloading, and a DAT file. Notably, the referenced research described only MSI-based attacks. When we reanalyzed this activity, we found that, similar to the FamousSparrow activity covered in our research, the group described in the article also used LNK files and scripts in addition to MSI files.
The script embedded in the .lnk file launched a .dat file, which displayed the legitimate PDF Claude-Pro-Relay-Technical-Overview.pdf to the victim and also executed pdf.vbs.
As in the FamousSparrow activity, the attackers behind Donuts and Beagles used two delivery vectors: a website that downloaded an MSI file, and RAR archives containing an LNK file associated with FTPlnk_phishing.
We also analyzed all FTPlnk_phishing files that used this technique and the same IconLocation references, .\1.pdf or .\1.docx, and confirmed again that this is not a widely used tool. All analyzed files belong to one of three campaigns:
Operation Grieflure, likely associated with Mustang Panda
Donuts and Beagles, which is very similar to the FamousSparrow attacks we analyzed but uses a different backdoor
UnsolicitedBooker, which continues to target China, as described in our report and a report by the Chinese vendor ThreatBook.
Link to the Space Pirates group
While analyzing the modified SparrowDoor sample, we noticed that it sends the following POST requests to the /325asd/fd.php endpoint:
POST HTTP/1.1 Host: %s User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;) Accept: */* Content-Length: %d Connection: Keep-Alive Cache-Control: no-cache
Using this endpoint pattern, we identified the domain viscarae.com, which had previously resolved to the IP address 103.27.108[.]55.
This IP address was previously mentioned in a report on the East Asian group UAT-8302, also known as Space Pirates. In this case, the overlap is limited to infrastructure. However, in that report, the researchers included a diagram showing overlaps between different groups, including an overlap between Space Pirates, or UAT-8302, and FamousSparrow, also known as Earth Estries.
Other related attacks
In its attacks, FamousSparrow used hhc.exe (SHA-256: fafb6ffd3ffcf414b702354f62a5216351af4566ed61ece7784846a6938bb8d9), a component of ESET Security Suite that is vulnerable to DLL sideloading. In 2018, the same file was used in an attack by SectorM04, also known as Whitefly or Mofang. That attack used the same .exe file and a similarly named sideloaded DLL, MSVCR110.dll, but the final payload was PlugX. In our case, the final payload is a new tool that we named SquawkDoor. Malicious libraries named MSVCR110.dll have been used by several East Asian groups, including APT31 and Mustang Panda, but this specific combination of the .exe file and MSVCR110.dll had previously been observed only in SectorM04 activity.
During our investigation, we also discovered a related, previously undocumented attack from late August 2024. The attack used two delivery vectors: ClickFix and a malicious archive. The first vector relied on ClickFix: when the victim clicked the “I’m not a robot” button, a Base64 string was copied to the clipboard. Once decoded, the string downloaded the next stage from https://www.cloudf-update.com/down[.]txt.
Figure 42. ClickFix attack
down.txt (SHA-256: 56f7237236374acb77c4e158e6026bac9b05b16942a2c89d41bcce6230d42f8c) is a PowerShell script that downloads the next stage from https://www.cloudf-update[.]com/wp-statics/test.doc, renames it to test.cab, executes the .exe, and deletes the downloaded file.
The CAB file (SHA-256: 595a43169bcc5154712311e37c192a8f4bf93fa2a2b5afff465c816b01a187f2) contains three files:
svctop.exe (SHA-256: fafb6ffd3ffcf414b702354f62a5216351af4566ed61ece7784846a6938bb8d9): a legitimate file that was later used in SquawkDoor attacks
MSVCR110.dll (SHA-256: f8204ba0763622a5f7ed3ca9d8c970eb52d10505690b17c920039dead408fbc5): the DLL used for sideloading
svctop.exl (SHA-256: c2570d398b4cae11ae87269e8b9c3a4f53d3860974be04471fa092a96ecebc1d): the payload, implemented as a loader
When the legitimate EXE was launched, it loaded MSVCR110.dll. This DLL overrode the same functions as SquawkDoor (__crtSetUnhandledExceptionFilter () and excepthandler4_common) and did so in a similar way: it allocated memory, loaded the payload file, decrypted it with RC4, and then transferred execution to the payload.
The launched loader sends a POST request to /wp-statics/test.php? p1=2026, receives the payload, decrypts it with RC4, and executes it. The key used to retrieve the payload is gfj#56^%vfdli. By the time of our investigation, the payload was no longer available. The p1=2026 value in the request is hardcoded, even though the attack took place in 2024.
In addition to the HTML-based vector, we found another vector that used an archive containing LNK files. The archive was named Tender.rar (SHA-256: d5135980017905588e72f7030410c5903071f803cd4d4060eb51fc28b38b5ba1).
The archive contains three legitimate PDF files, an LNK file, a VBS script, and a CAB file named test.doc. At first, the victim sees only two PDFs and the LNK file, which also masquerades as a PDF document. As in the other cases, its IconLocation is .\1.pdf. When opened, the LNK runs .\$RECYCLE.BIN\aa.vbs, which starts the next script.
The script moves the CAB file, extracts it, and runs the .exe; replaces the LNK with a legitimate PDF and opens it; and then removes all malicious files. The PDFs appear to target Egypt. The archive also contained what was likely the initial lure document, Purchase_Form_for_Tender_Dossier.pdf, which included a link to the same archive: https://www.cloudf-update[.]com/files/Tender.rar.
The CAB file and its contents were similar to those used in the ClickFix attack described above.
Group member
The LNK file Strategi_AS_Referensi_April2026.docx.lnk (SHA-256: 4c7ae604ad1af90ea155865cb28fd7ccd6371f5ac172de6014b328514d4618e7) contains the computer name desktop-k196dpf. This is typically the name of the computer on which the file was created.
This name had not appeared anywhere before, except in a Chinese blog where the pentester imawuya describes a walkthrough of the Chemistry machine on Hack The Box, a pentesting training platform.
Figure 48 Hostname used by the pentester
In this case, the hostname desktop-k196dpf, which the pentester used for the walkthrough, appeared in several places in the terminal.
We were able to discover additional accounts, including accounts on X, bilibili, and Instagram.* Based on these accounts, it is possible to infer that this is a young woman from China who identifies herself as 东北人 ("Northeasterner," that is, a person from Northeast China). The X account itself is shown as being from Hong Kong, but this is normal practice, as Hong Kong is practically the only place in China where X is accessible without restrictions, and it is used as a VPN location for access.
The X account is highly niche and appears to be more of a personal blog, where she writes about personal challenges and shares her thoughts.
* Instagram is a product of Meta, has been designated an extremist organization and banned in Russia under Russian law.
Figure 50. imawuya's posts on X
For example, imawuya once wrote about gaining unauthorized access to a local dating app. Judging by the conversation, she may have had access to the application's database.
Figure 51. Admission of obtaining administrator access to the application
The Chemistry walkthrough was published in December 2024. It is highly unlikely that, within a year and a half, the same hostname would appear on the machine of an unrelated person in East Asia who is also involved in cybersecurity. Given imawuya's pentesting experience and her previous unauthorized activity, we assess with high confidence that the malicious LNK targeting Indonesia was tested and created on imawuya's computer. However, given the complexity of the other infection chains and the use of a unique backdoor, imawuya is likely a member of the group but not a key operator.
In addition to artifacts in the delivered LNK files, we also found that some SquawkDoor versions (this fragment was missing from some samples) contained an interesting artifact after decrypting the payload file contents. Between the shellcode, which reflectively loads the backdoor, and the backdoor itself, whose MZ and PE signatures had been wiped, we found values of environment variables.
The purpose of this placement is unclear: the values are used neither during the loading process nor by the backdoor itself. However, this data shows that HY-17388 was used as the domain associated with the user profile.
Malware family evolution
Tool | Architecture | Payload delivery | Configuration | Transport |
|---|---|---|---|---|
SparrowDoor | All core functionality is built into the backdoor. It does not support loading additional modules. During installation and transitions between operating modes, SparrowDoor relaunches itself several times with different arguments. When launched without arguments, it establishes persistence. With -i, it performs an intermediate launch. With -k and -d, it proceeds to the main logic, respectively with and without the ability to restart the backdoor. It does not distribute its logic across multiple instances, and C2 commands are handled in the main thread. | The malicious library is loaded via DLL sideloading. During initialization, it modifies the operand of an existing CALL instruction in the legitimate executable, replacing it with a new relative offset and redirecting execution to its own decryption function. When this function is called, it decrypts the payload, which is stored in a separate XOR-encrypted file. The first 4 bytes of the file are used as the decryption key, and the next 76 bytes contain parameters for reflective loading. The loader shellcode and the backdoor section data follow. After decryption, the malware allocates memory in the legitimate process, copies the decrypted data into it, and transfers execution to the shellcode, which reflectively loads SparrowDoor. | Embedded in the backdoor and stored in XOR-encrypted form. Contains one C2 server address; proxy parameters, including address, port, username, and password; and the service name, display name, and description used for persistence. | HTTPS |
HemiGate | Backdoor functionality is divided across built-in modules: Cmd executes individual commands, CFile handles file system operations, CKeylogPlug records keystrokes, CSocket5 provides a TCP proxy, CShell starts an interactive shell, CTransf transfers files, CRdp captures screenshots, CPro manages processes, and CFileMoniter monitors directory changes. The backdoor does not support loading additional modules from the C2 server. During installation, HemiGate launches three instances with different roles: one without arguments for installation and persistence, one with /a for C2 communication and processing incoming commands, and one with /u <PID> for executing received commands and interacting with the keylogger. The main and user instances exchange commands and collected data through a named pipe. | The malicious library is loaded via DLL sideloading and redirects an existing CALL instruction in the legitimate executable to its own decryption function. Decryption uses RC4, with the first 0×10 bytes of the encrypted file serving as the key. The decrypted file contains Dracu Loader shellcode for conventional reflective loading, followed by the full HemiGate backdoor PE file. | Stored in a separate file located alongside the other components, with its contents encrypted using RC4. The decrypted configuration contains up to three C2 server entries with their corresponding ports, proxy settings, including address, port, username, and password, and the delay interval between reconnection attempts. | HTTP, HTTPS |
CrowDoor | All core capabilities are built into the backdoor. It does not support loading additional modules. When executed, CrowDoor relaunches itself with different arguments: with no argument or with 0 to establish persistence, with 1 to inject into a legitimate process, such as colorcpl.exe, and with 2 to start the main backdoor logic. CrowDoor does not split its logic across multiple instances. However, long-running operations, such as starting a reverse shell or proxying traffic, run in separate threads that establish their own connections to the C2 server. | Two malicious libraries are loaded via DLL sideloading. The first decrypts the data, while the second loads and executes the payload in the current process without modifying the code of the legitimate EXE file. The payload is encrypted with RC4, and the decryption key is hardcoded in the first library. The first 76 decrypted bytes contain parameters for reflective loading, followed by the loader shellcode and the backdoor section data. | Embedded in the backdoor and stored in plaintext. Contains the C2 server address and port, the connection method, and the number of connection retry attempts. | TCP |
SparrowDoor | All core capabilities are built into the backdoor. It does not support loading additional modules. During installation, SparrowDoor runs with different arguments: with no argument to establish persistence, with 11 to inject the loader into a legitimate process, such as colorcpl.exe, and with 22 to start the main backdoor logic. It does not divide its logic across multiple instances. As in CrowDoor, C2 commands are processed in separate threads, each establishing its own connection to the C2 server. | The malicious library is loaded via DLL sideloading and decrypts the payload stored in a separate file. The file contents are encrypted with RC4, and the decryption key is hardcoded in the library. The decrypted file contains parameters for reflective loading, followed by the loader shellcode and the backdoor section data. | Stored at the end of the payload file in RC4-encrypted form. Contains three C2 server address and port pairs, as well as the reconnection delay specified in days, hours, minutes, and seconds. | TCP |
Modular SparrowDoor | The backdoor provides only basic capabilities: C2 communication, system information collection, configuration management, self-removal, and plugin loading. Its functionality is extended by downloading plugins from the C2 server. The modules are similar to those used by HemiGate. The tool also includes a preinstalled plugin for downloading additional modules. Downloaded modules are not written to disk. SparrowDoor maps them into memory, calls the exported fmain function, and registers their handlers. Commands for each plugin are processed in a separate thread over a dedicated C2 connection. | The malicious library is loaded via DLL sideloading. It then reads the payload from a separate file and decrypts it with RC4 using a hardcoded key. The decrypted file is a full PE file containing the backdoor, which the library loads reflectively. | Stored in plaintext. Contains an array of C2 server entries, including the C2 server address and corresponding port, as well as the delay interval in minutes. | TCP |
TernDoor | The backdoor provides only basic capabilities: C2 communication, system information collection, configuration management, and loading additional modules. Its functionality is extended by loading in-memory plugins: file for file operations, cmd for command execution, rootkit, shell for an interactive shell, screenshots for screen capture, sock5 for traffic proxying, and keylog for keylogging. When a plugin is loaded, the exported OnRecv function is called. A separate AES-encrypted Windows driver is delivered with the backdoor. Once installed, it allows the malware to terminate, suspend, and resume selected processes. When launched without arguments, TernDoor establishes persistence and injects into a legitimate process, such as msiexec.exe. The backdoor then starts its main logic in the context of the target process. When launched with the -u argument, it terminates active instances and removes its components. | The malicious library is loaded via DLL sideloading and modifies the code of the legitimate EXE file by writing an absolute jump instruction at the target address. This redirects execution to the function that loads and decrypts the payload from a separate file. The data is encrypted with RC4 using a key hardcoded in the DLL. The decrypted file contains shellcode that removes XOR encryption and decompresses the LZNT1-compressed payload, then reflectively loads the resulting PE file into memory. The file itself has its MZ and PE signatures removed. | Stored at the end of the payload file in RC4-encrypted form. Contains up to four C2 server entries, including address, transport type, and port, as well as proxy settings, including address, port, username, and password, and HTTP header values. | TCP, HTTP, HTTPS, TLS |
Modular SparrowDoor | The backdoor supports an expanded set of built-in control commands. Its functionality can be extended with downloadable modules: SparrowDoor maps them into memory, calls the exported fmain function, and registers the corresponding handlers. The tool also includes two preinstalled plugins: one for keystroke logging and one for downloading additional plugins.During installation, SparrowDoor relaunches itself with different arguments: with no arguments, it establishes persistence and disguises its components; with /a, it injects into a legitimate process, such as msiexec.exe; with /c, it creates a mutex, starts msiexec.exe under the current user's token, and injects into it; and with /b, it activates the main logic. When launched with /u, it uninstalls itself. Commands for each plugin are processed in a separate thread over a dedicated C2 connection. | The malicious library is loaded via DLL sideloading and redirects an existing CALL instruction in the legitimate executable to its own decryption function. Decryption uses RC4 with a key hardcoded in the DLL. The decrypted file contains parameters for reflective loading, followed by the loader shellcode and the backdoor section data. | The configuration is stored at the end of the payload file in RC4-encrypted form. It contains up to three C2 server entries, including address, transport, and port, as well as the working directory path, the second part of the RC4 key used for message encryption, and delay parameters. | TCP, HTTP, HTTPS, TLS |
The figure shows the toolkit's development timeline and the order in which its versions appeared.
Figure 53. Evolution of the malware family's toolset
Conclusions
FamousSparrow has significantly enhanced the SparrowDoor backdoor by reworking its architecture and combining the most effective mechanisms from earlier versions. Together with additional activity-hiding mechanisms, these changes have made the malware more functional, flexible, and dangerous, giving the attackers extensive control over compromised systems.
The use of hardcoded language parameters in the JS payload and SquawkDoor, as well as the compromise of only individual websites, suggests that these attacks were not conducted at scale. However, both the backdoor and the overall infection chain are designed to support scaling and convenient logging, which could enable broader campaigns if needed.
The threat group also repeated the same OPSEC mistake twice, exposing the hostname both in the LNK file metadata and in the decrypted payload.
Positive Technologies product verdicts
PT ESC
Verdicts |
|---|
PTESC_apt_win_CN_FamousSparrow__Backdoor__SparrowDoor__Modular__v2 |
PTESC_apt_win_CN_FamousSparrow__Dropper__SparrowDoorLoader |
PTESC_apt_win_CN_FamousSparrow__Backdoor__SquawkDoor |
PTESC_apt_win_CN_FamousSparrow__Dropper__SquawkDoor |
Behavioral rules
Rules |
|---|
Trojan.Win32.Generic.a |
Trojan.Win32.Recon.c |
Backdoor.Win32. SquawkDoor.n |
PT AV
Verdicts |
|---|
TrojanLoader.SparrowDoor |
Backdoor.Win32.SquawkDoor |
Network detections
Verdicts |
|---|
BACKDOOR [PTsecurity] SparrowDoor TLS JA3 fingerprint (APT FamousSparrow) sid: 10017920 |
BACKDOOR [PTsecurity] SparrowDoor Checkin (APT FamousSparrow) sid: 10017921 |
Indicators of compromise
Network indicators
Indicators |
|---|
135.136.135.54 |
103.141.235.123 |
37.122.150.133 |
165.154.227[.]16 |
bloontechn[.]com |
pplpp.microsfot[.]vip |
microsfot[.]vip |
astorialaza[.]com |
aistei[.]com |
File indicators
MD5 | SHA-1 | SHA-256 | Description |
|---|---|---|---|
e21e44bb8ef5c019acfb226df78303ba | 2339d0d76172ee4c62aabda60423e289203b0b2e | 1def54444cab1fd17fe5acb42dd0d2293bcb9ce72a8e955bf6796d10d662c4ff | Rar |
33cc27c7b4e2b2503d55c1ff5b1991a3 | 5672a9fcce3216834b5625bba4abafacc30e4e80 | 4c7ae604ad1af90ea155865cb28fd7ccd6371f5ac172de6014b328514d4618e7 | Lnk |
365d80130ec10f3d854eda5fbb592ef4 | b8fadbdcc79837e31e924fcd8c9277b89d979e20 | 39bdf92a70a1bb4f07e58cd1081f80fced85df01c1f14a56ed5783104c902439 | Batch |
1b18a85568b049567b74a532e91ce312 | 58a3e2da23607042cc3bbd7c0c831031d4d1a44a | 1a442a8e12c1571a0663e64e0ac9c930035bb267259b684cd9607f76be6d017b | Cab SquawkDoor |
ddac305e657f357a9d5e825e0f043d02 | 0498f03f97959c8561f363de69ac75f83b5033b9 | db1e361bb2e4674f1a5330bc25f772b90e6eb471a67b45b93dd782aaf1c1b8e9 | Cab SquawkDoor |
9c38c72cad8dbc831ecc66ba1e000330 | 7b386be4ec92e4ca9b7e908d716de66cccdfdcb6 | a21b2f9f302c33b4348ca762374864fb31220ff170b519ff09766b9a78a0c402 | Cab SquawkDoor |
995c1504e4ca5231cfd1dd5326ba4563 | 0df517b2f5a2fee5ca5387e1131a2015d52faa25 | 02836ec576c1e6dda13c1aa171af1dde06e19096f45edbfd9ecb753e11598f87 | Cab SquawkDoor |
3c136f72cfc2006f5e9c0f652347e520 | 9588afe462fa011f2c428e4af83da5d8c1fdec3f | e9f2f42ea3611096879f4152a7d78bb3a78a4dbead1c3b7e366dce485207551f | MSI SquawkDoor |
1532b7c0e95e4ba76ee2d464894b1327 | 716375a43cd5c1607c9693f6dab28aca28524b98 | f51dc5e1848daee4e607d46faa25033e1151060cd3482ad4439754440d6c4c01 | MSI SquawkDoor |
5ddc4dfcdc82f6378239541c0517cbff | d9455955be12e055a1cbd587c99e742af8d55513 | b379d07ba81d4190490d9893b2d6d830ff594e042dce26053ef07794d0403787 | MSI файл SquawkDoor |
48f9bbb696f3b20c755b14216ab2d00e | 0a372b2f38c921f97f91369b03e1565cc0e61292 | f23e5391656b178bc0ab510b0fca6ffbd963cf94870c82a5920f0f338f561f18 | SquawkDoor Loader |
cf40dff69e108487781dde696e28a847 | e9f6fdafe545b8ac43fc3c2c47fcf308c53d1711 | c69534bb3e6d4e1c9b21f9e4745f6fb002cbcd3ab83f9ad208eb7bb135401062 | SquawkDoor Loader |
d91ec21127c2f5253197d03a6b1ad8e6 | 9ab4472d3b2ab955bfb78b166abf05da1b1f1b41 | 8bbc395a7a0faff074c6e31c7da37bf1540a4e7ec3d80870f8d6bd1f5d4cecbb | SquawkDoor Loader |
1962628c042e7bfc1b241d9403af0bd3 | a60a8fd18f36926b3b077138583e4c9368b9c82c | 74f95f5d36172fda16eef5bede65023f5e0486fc87f81ebfdcd150187e63d004 | SquawkDoor Loader |
c7a69cad4a2d0f6c9c39579084f96b47 | 1a70e1fb6275f8a59ac3211f0b45f45ba72ee100 | 1c28aaa57223794ad34b0ebc063dc450187425e5c9b38a2c32276d8ea34c9f27 | Encrypted SquawkDoor |
b116e05f092d89ebee774d114f82c7cf | d74076ec8a2174d1f24e7f86ce54187309a09977 | 60292dee0e07a2b889d657e2fbd2f1cd517eaea58f1cfb1ed4a721a173520499 | Encrypted SquawkDoor |
623dc8d5112deae32b1b522040f5b78a | 27371e70ea1fef5cf31bb826b1458b99ae2516d2 | 83bc97e0a7da7030cac699a239b7071e84a388bc235a0cd9d3d01a5639915f08 | Encrypted SquawkDoor |
ba23ef057afdd4e4a6237582cc5bfb2b | 4860f6b3639402b20a19863c0ec9f01a2bd04cfd | 37feb5541c9ec47e16f98d847c19e00eb881705dc137e40ab21f8064e8fa2dde | SquawkDoor |
40a27ca8c7ee3477f789e5aa0b14405f | d078284c5ab9a2d59b5ad8b9b50d296a71b58b79 | 05f39d4fbabc4215b81ae143c75d828268f085d297a76585dd3788bc7d3326cb | SquawkDoor |
0fece08bb0a1ddb082bf4fef5046c385 | 13c92b98529b143abb956a844a3b4ad620f86b81 | 98c919734910cc7a825f9b5b4f7390831ba32cf054a01b5b7bf5e37a352f9155 | SquawkDoor |
5e9c5ee0045690d603fd85e313a566fd | 259e574cad7b6fee7cf7d33313f7bf0cf707d4d0 | e5f7bbfc187264336dea5dfebfb5a7dd1e7fcdcc9692db55fbe6eb4d28f027bc | MSI SparrowDoor |
81e333eb2b7ffc5e09b04c88a08ce245 | 2d2e9550f6c85d96b6cbd5396db9f96c0a91a233 | 284b7e3222d108b0224c47028fae2c0e6b96e130af7b792f2c2518f18ceedcb3 | CAB SparrowDoor |
606b52b523b53079b4a5948f758b277d | 84cc3a43b1e74fe50aba6905f75652caf45db375 | b60404c1299e69df029d9817dcf69f9fe325ecc990e16bc7758f56ce5714184b | SparrowDoor loader |
ef0ebcda5e7b79488b860c8050cd8a21 | b34cfe22b908032f110c275afeac9b97e2181e07 | 3cb6f80cf7753c16d23f493307c54b302f849daa5211415aa55781f3fdf153e6 | Encrypted SparrowDoor |
941836760e338a8120711166f8b3e62 | 0a408e4c4c670a1de9cfa9bcafa7e1a6944df1e3 | 5a1f4fad42ba66d48fef7834d1831667ae88a5615a65fcdd2ff6a9cd575b52b0 | Modular SparrowDoor, v2 |
MITRE ATT&CK Matrix
Resource Development | ||
|---|---|---|
T1587.001 | Develop Capabilities: Malware | FamousSparrow developed an updated version of the modular SparrowDoor backdoor, as well as a new backdoor called SquawkDoor, which is designed for attacks that involve installing a fake SSL certificate. |
T1583.006 | Acquire Infrastructure: Web Services | FamousSparrow used Amazon S3 buckets to host MSI files. |
T1608.001 | Stage Capabilities: Upload Malware | FamousSparrow uploaded MSI files to Amazon S3 buckets. |
T1608.004 | Stage Capabilities: Drive-by Target | FamousSparrow injected malicious JavaScript into compromised websites to replace legitimate pages and infect victims. |
Initial Access | ||
T1204.001 | User Execution: Malicious Link | FamousSparrow added malicious download links to compromised web pages, leading victims to MSI installers containing malware. |
Execution | ||
T1204.002 | User Execution: Malicious File | FamousSparrow distributes MSI files disguised as SSL certificate installers. When executed, these installers deploy the SparrowDoor and SquawkDoor backdoors on the victim's system. |
T1106 | Native API | FamousSparrow uses the SparrowDoor and SquawkDoor backdoors, both of which rely on native Windows APIs. During execution, SparrowDoor calls functions such as RtlAllocateAndInitializeSid(), RtlLengthSid(), RtlGetNtVersionNumbers(), CreateRemoteThread(), VirtualAllocEx(), ShellExecuteA(), among many others. SquawkDoor uses APIs such as CreateProcessA(), RtlGetVersion(), GetComputerNameA(), and others. |
T1059.007 | Command and Scripting Interpreter: JavaScript | FamousSparrow embedded malicious scripts into compromised websites using tags such as <script src=''https://malicious.com/js/jquery.min.js?s=*number*''></script>. These scripts checked the user's device and displayed fake certificate error pages. |
T1059.003 | Command and Scripting Interpreter: Windows Command Shell | FamousSparrow uses the SquawkDoor backdoor to enumerate the contents of an operator-specified directory by running cmd /C dir ''<path>'' |
FamousSparrow uses the SquawkDoor backdoor to execute arbitrary operator-supplied commands via the cmd.exe interpreter. | ||
Persistence | ||
T1547.001 | Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder | FamousSparrow uses the SparrowDoor and SquawkDoor backdoors to establish persistence on victim systems. The backdoors create the NisaSrv and WindowsUpdateAssist autostart values, respectively, under HKCU\Software\Microsoft\Windows\CurrentVersion\Run. |
T1543.003 | Create or Modify System Process: Windows Service | FamousSparrow uses SparrowDoor to establish persistence on victim systems by creating a Windows service with a configuration-defined name, such as NisaSrv, that launches the malware when the user logs on. |
Privilege Escalation | ||
T1134.001 | Access Token Manipulation: Token Impersonation/Theft | FamousSparrow uses the SparrowDoor backdoor to open the access token of the winlogon.exe process and duplicate it, allowing the malware to perform actions in that process's security context. |
T1134.002 | Access Token Manipulation: Create Process with Token | FamousSparrow uses SparrowDoor to launch msiexec.exe with a duplicated winlogon.exe process token via CreateProcessAsUserA(). |
Stealth | ||
T1218.007 | System Binary Proxy Execution: Msiexec | FamousSparrow uses msiexec.exe to run malicious MSI files, extract the components they contain, and continue the attack. |
T1027.012 | Obfuscated Files or Information: LNK Icon Smuggling | FamousSparrow used LNK files with the additional argument -s:"_rels\info.dll" to launch a batch script. |
T1574.001 | Hijack Execution Flow: DLL Side-Loading | FamousSparrow uses DLL sideloading to launch the SparrowDoor and SquawkDoor backdoors. |
T1027.007 | Obfuscated Files or Information: Dynamic API Resolution | FamousSparrow uses dynamic API resolution in its tools. |
T1027.013 | Obfuscated Files or Information: Encrypted/Encoded File | FamousSparrow delivers the payload as a separate RC4-encrypted file, which the malicious DLL loads into memory, decrypts, and executes. |
FamousSparrow stores backdoor configurations in RC4-encrypted form. The SquawkDoor configuration is embedded directly in the backdoor and encrypted with the key Hg5th5324Ve, while the SparrowDoor configuration is located at the end of the encrypted payload file and protected with the key oWbgvv5234$43gh. | ||
FamousSparrow uses SparrowDoor to encrypt data captured by the keylogger with RC4 using a static key, then Base64-encodes the result before saving it. | ||
FamousSparrow uses SparrowDoor to apply an additional layer of RC4 encryption to the payload file without affecting the configuration located at the end of the file. | ||
T1620 | Reflective Code Loading | FamousSparrow uses shellcode for reflective loading to launch the SparrowDoor and SquawkDoor backdoors. |
FamousSparrow uses SparrowDoor to reflectively load functional modules received from the C2 server and then call their exported fmain function. | ||
T1140 | Deobfuscate/Decode Files or Information | FamousSparrow uses loaders to decrypt and subsequently load the SparrowDoor and SquawkDoor backdoors. |
FamousSparrow uses the SparrowDoor and SquawkDoor backdoors, which decrypt their configurations with RC4. | ||
T1564.003 | Hide Artifacts: Hidden Window | FamousSparrow uses the SparrowDoor and SquawkDoor backdoors to hide the console window by calling ShowWindow(hwnd, SW_HIDE). |
FamousSparrow uses SquawkDoor to execute operator-supplied commands stealthily by creating processes via CreateProcessA() with the CREATE_NO_WINDOW | DETACHED_PROCESS flags. | ||
T1070.004 | Indicator Removal: File Deletion | FamousSparrow uses SquawkDoor to remove file artifacts left by the MSI installer after moving the payload to the target directory by executing the following command: cmd.exe /C ping 127.0.0.1 -n 3 > Nul & del /f /q <legit.exe> & del /f /q <malicious.dll> & del /f /q <encrypted_payload> |
FamousSparrow uses SquawkDoor to delete either an operator-specified file via DeleteFileA() or a directory via RemoveDirectoryA(). | ||
FamousSparrow uses SparrowDoor, which, when launched with the /u parameter, executes cmd /c taskkill /F /IM msiexec.exe, forcibly terminating all msiexec.exe processes, including instances used to run the injected payload. | ||
FamousSparrow uses SparrowDoor to remove persistence mechanisms and the working directory on operator command, then terminate the process by calling ExitProcess. | ||
T1480.002 | Execution Guardrails: Mutual Exclusion | FamousSparrow uses the SparrowDoor and SquawkDoor backdoors to create the named mutexes xnv_1.1.0_NisaSrv and squadc_single_instance, respectively, preventing multiple instances from running at the same time. |
T1480 | Execution Guardrails | FamousSparrow uses SquawkDoor, which, if the corresponding configuration flag is set, delays activation of its main malicious logic until one of the target browser processes is detected: chrome.exe, firefox.exe, msedge.exe, edge.exe, or brave.exe |
T1070.006 | Indicator Removal: Timestomp | FamousSparrow uses SparrowDoor to modify the timestamps of created files and the working directory, assigning them the timestamps of the ntdll.dll system library to conceal traces of its activity. |
T1574 | Hijack Execution Flow | FamousSparrow uses the SparrowDoor Loader to launch the backdoor. Using VirtualProtect(), it temporarily enables writes to the code area of the legitimate NisaSrv.exe process, modifies the relative offset of a CALL instruction, and redirects execution flow to its own payload-decryption function. |
T1564.001 | Hidden Files and Directories | FamousSparrow uses SparrowDoor to assign the hidden and system attributes to created files and the working directory, thereby hiding them during standard directory browsing. |
T1055 | Process Injection | FamousSparrow uses SparrowDoor to repeatedly inject the payload into newly launched msiexec.exe processes: it allocates an executable memory region with VirtualAllocEx(), writes code to it via WriteProcessMemory(), and starts it using CreateRemoteThread(). |
T1036.005 | Masquerading: Match Legitimate Resource Name or Location | FamousSparrow uses legitimate DLL names, such as WTSAPI32.dll and MSVCR110.dll, to make malicious libraries appear benign. |
Discovery | ||
T1083 | File and Directory Discovery | FamousSparrow uses the SparrowDoor and SquawkDoor backdoors to determine the current execution directory and check whether it matches the target working directory. |
FamousSparrow uses SquawkDoor to check the file system for characteristic VMware Tools components: vmmouse.sys, vmhgfs.sys, vmmemctl.sys, vmtray.dll, vmtools.dll, vmusr2.dll, and vmtoolsd.exe. | ||
FamousSparrow uses SquawkDoor, which, on operator command, enumerates files and subdirectories in a specified directory. | ||
T1497.001 | Virtualization/Sandbox Evasion: System Checks | FamousSparrow uses SquawkDoor to detect execution in a virtualized, sandboxed, or analysis environment. To do this, the backdoor performs 12 anti-analysis checks, including analysis of RAM size, system disk size, registry keys, processes, virtual machine files and devices, network adapter MAC addresses, screen resolution, and BIOS, motherboard, and system manufacturer parameters. |
T1082 | System Information Discovery | FamousSparrow uses SquawkDoor to collect information about the victim system configuration, including the OS version, computer name, amount of physical memory, system disk size, screen resolution, system manufacturer, device model, and BIOS data. |
FamousSparrow uses SquawkDoor, which, on operator command, runs systeminfo to collect information about the victim's operating system. | ||
FamousSparrow uses SparrowDoor to obtain the operating system version and computer name. | ||
T1012 | Query Registry | FamousSparrow uses SquawkDoor to read Windows registry information about connected devices, installed drivers, the system manufacturer, and the product name, as well as to search for other artifacts indicating execution in a virtualized environment. |
T1057 | Process Discovery | FamousSparrow uses SquawkDoor to obtain the list of running processes and check for VMware Tools components, including vmtoolsd.exe, vmwaretray.exe, vmwareuser.exe, and vmwarew.exe |
FamousSparrow uses SquawkDoor to obtain the list of running processes and search for target browsers. | ||
FamousSparrow uses SparrowDoor to search for explorer.exe and winlogon.exe processes running in the same user session for subsequent access-token manipulation. | ||
T1016 | System Network Configuration Discovery | FamousSparrow uses SquawkDoor to extract the MAC addresses of active network adapters and compare their first three bytes against prefixes associated with virtualization products and platforms, including VMware, VirtualBox, Hyper-V, Parallels, Xen, QEMU/KVM, Qumranet, and Virtual Iron by Oracle. |
FamousSparrow uses SquawkDoor to enumerate system network interfaces and obtain the first active IPv4 address, excluding localhost interface addresses. | ||
FamousSparrow uses SparrowDoor to enumerate local network interfaces and obtain the IPv4 address of the first interface. | ||
T1120 | Peripheral Device Discovery | FamousSparrow uses SquawkDoor to enumerate connected devices and search their names and descriptions for strings indicating the use of VMware, VirtualBox, or QEMU. |
T1010 | Application Window Discovery | FamousSparrow uses SparrowDoor to identify the active window and save its title together with keystrokes captured by the keylogger plugin. |
T1124 | System Time Discovery | FamousSparrow uses SparrowDoor to determine the current date on the compromised system. |
T1033 | System Owner/User Discovery | FamousSparrow uses SparrowDoor to determine the username under which the process is running. |
T1518.001 | Software Discovery: Security Software Discovery | FamousSparrow uses SparrowDoor to obtain a list of antivirus products installed on the victim system. |
Collection | ||
T1113 | Screen Capture | FamousSparrow uses SquawkDoor to take screenshots of the victim system on operator command. |
T1056.001 | Input Capture: Keylogging | FamousSparrow uses SparrowDoor to capture keystrokes by installing a hook via SetWindowsHookExW() with the WH_KEYBOARD_LL parameter. |
T1074.001 | Data Staged: Local Data Staging | FamousSparrow uses SparrowDoor to locally accumulate data captured by the keylogger and save it to files in the kl subdirectory when the active window changes, when the buffer reaches 1008 bytes, or when a two-second timer is triggered. |
Command and Control | ||
T1095 | Non-Application Layer Protocol | FamousSparrow uses the SparrowDoor and SquawkDoor backdoors to communicate with the command-and-control server over TCP and exchange data in a custom message format. |
T1573.002 | Encrypted Channel: Asymmetric Cryptography | FamousSparrow uses the SparrowDoor and SquawkDoor backdoors, which establish TLS-protected network connections. |
T1573.001 | Encrypted Channel: Symmetric Cryptography | FamousSparrow uses SparrowDoor to additionally protect communications with the command-and-control server by encrypting messages with RC4 using a static key. |
T1071.001 | Application Layer Protocol: Web Protocols | FamousSparrow uses SquawkDoor to send a single HTTP/HTTPS POST request to the /register-ip endpoint on the C2 server. This request registers the victim system and reports that the backdoor has started successfully. |
FamousSparrow uses SparrowDoor to communicate with the command-and-control server via HTTP/HTTPS POST requests to the /325asd/fd.php endpoint. | ||
T1105 | Ingress Tool Transfer | FamousSparrow uses SquawkDoor to receive data from the C2 server and save it to a file at an operator-specified path. |
FamousSparrow uses SparrowDoor to download additional modules from the C2 server, load them into memory, and extend its functionality. | ||
FamousSparrow uses SparrowDoor to receive a file name and file contents from the command-and-control server and then write the file to the victim's file system. | ||
T1008 | Fallback Channels | FamousSparrow uses SparrowDoor, which supports up to three C2 server addresses specified in its configuration. |
Exfiltration | ||
T1041 | Exfiltration Over C2 Channel | FamousSparrow uses the SquawkDoor and SparrowDoor backdoors to transmit collected system information and command execution results to the command-and-control server over the established C2 channel. |
T1030 | Data Transfer Size Limits | FamousSparrow uses SquawkDoor to split transmitted data into 16 KB chunks. |
