{ "id": "8e248010-59e1-44a1-9fd9-38a4b3ec4879", "created_at": "2026-09-23T02:02:50.911635Z", "updated_at": "2026-09-24T02:01:31.399409Z", "deleted_at": null, "sha1_hash": "0bbe08391e07869882c39a9bbe8de8537363be06", "title": "Beware the SparroWock: The backdoor that bites, the commands that catch", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 847066, "plain_text": "https://www.welivesecurity.com/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nBeware the SparroWock: The backdoor that bites, the commands\n\nthat catch\n\nBy Alexandre Côté CyrRomain Dumont\n\nArchived: 2026-09-23 02:01:40 UTC\n\nESET Research’s ongoing monitoring of FamousSparrow has borne fruit once again. Our previous public report\n\non FamousSparrow revealed that this China-aligned APT group had developed two new versions of its custom\n\nbackdoor named SparrowDoor. This time, we discovered that FamousSparrow has switched to a new backdoor,\n\nSparroWocky, and has been deploying it to several countries in Latin America since at least August 2025.\n\nIn what was probably China’s reaction to the US showing increased interest in Latin America, FamousSparrow\n\nincreased its targeting of the region to almost exclusively targeting it in July 2025. A month later, we noticed that\n\nthe group had started using the new SparroWocky backdoor, which then quickly replaced SparrowDoor as\n\nFamousSparrow’s main implant.\n\nSparroWocky is a modular, C++ backdoor. Its architecture and the techniques used by its authors indicate strong\n\nknowledge of anti-analysis tricks and Windows internals. We chose to name the backdoor SparroWocky because\n\nthe first samples we collected all contain the first stanza of Jabberwocky, a nonsense poem by Lewis Carroll.\n\nFortunately, while advanced, SparroWocky’s inner workings are much less arcane than a gyre and gimble in the\n\nwabe, so a through and through [of] the vorpal blade allowed us to bring you a detailed analysis of the backdoor.\n\nKey points of the blogpost:\n\nFamousSparrow is extensively targeting governmental organizations in Latin America.\n\nSince August 2025, the group appears to be abandoning SparrowDoor in favor of SparroWocky,\n\na new custom C++ backdoor.\n\nWith the switch to SparroWocky, FamousSparrow started to incorporate code from open-source\n\nprojects directly into its malware.\n\nSparroWocky is a full-featured backdoor that manipulates low-level structures in memory, and\n\npatches code at runtime in order to avoid detection.\n\nSparroWocky has the capability to load and execute Beacon Object Files, a special type of\n\nexecutable file supported by many red-teaming and penetration-testing tools.\n\nFamousSparrow is a China-aligned cyberespionage group believed to have been active since at least 2019. We\n\nfirst publicly documented the group in a blogpost from September 2021 when we observed it exploiting the\n\nProxyLogon vulnerability. The group was initially known for targeting hotels around the world but has also\n\ntargeted governments, international organizations, trade groups, engineering companies, and law firms.\n\nFamousSparrow is the only known user of the SparrowDoor backdoor.\n\nWe analyzed two versions of SparrowDoor in a 2025 blogpost, in which we also discussed the attribution claims\n\naround the group. As mentioned by Trend Micro, FamousSparrow is linked to Earth Estries; however, the exact\n\nPage 1 of 21\n\nhttps://www.welivesecurity.com/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nnature of the link is not fully known. FamousSparrow has also been publicly linked to Salt Typhoon, but, due to\n\nthe absence of any technical indicators, we track them as separate.\n\nBased on our investigation, we attribute the latest campaign and the SparroWocky backdoor to FamousSparrow\n\nwith high confidence, since in some of the first attacks involving this backdoor, SparroWocky was deployed by\n\nthe FamousSparrow-exclusive SparrowDoor. Moreover, not only does the victimology match FamousSparrow’s\n\nprevious targeting, we have also recorded attempts to deploy SparroWocky at many of the same organizations that\n\nhad previously been targeted with SparrowDoor.\n\nLatin America in the crosshairs\n\nAs previously mentioned, FamousSparrow currently appears to be focused on high-profile targets in Latin\n\nAmerica. This trend started at the latest in July 2025 and has continued with the introduction of SparroWocky. In\n\nfact, from mid-2025 and into 2026, 90% of the group’s targets registered in our telemetry have been located in the\n\nregion. As depicted in Figure 1, we’ve seen the new backdoor deployed against governmental entities in\n\nArgentina, Ecuador, Guatemala, Honduras, Panama, Peru, Puerto Rico, and Venezuela. This represents a rare\n\noccurrence among the China-aligned APT groups that we currently track, which are generally observed\n\nthroughout various world regions within such an extended time frame.\n\nPage 2 of 21\n\nhttps://www.welivesecurity.com/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nFigure 1. Victimology of SparroWocky\n\nWe believe that this focus is not coincidental and likely reflects China’s reaction to various recent US initiatives in\n\nthe region. Indeed, Donald Trump’s second presidential term has brought about an aggressive reaffirmation of US\n\ninterests in Latin America, which threatens various long-term investments that China has cultivated throughout the\n\ncontinent in the last decade, in domains such as energy, mining, and telecommunications. We suspect that\n\nFamousSparrow’s activities are intended to help China better monitor and anticipate the reaction of local\n\ngovernments to current US pressures.\n\nIn some cases, we have observed elements that clearly seem to confirm this hypothesis. For instance, one of the\n\nPanamanian entities we’ve seen being targeted is directly involved in the ongoing commercial dispute regarding\n\ntwo major ports located in the canal area, which were, until recently, operated by a China-based company. As the\n\nconcession granted to this company was legally challenged by the Panamanian government in early 2025, it seems\n\nhighly likely that FamousSparrow’s operation was intended to gain early, privileged knowledge of local\n\nauthorities’ intentions on this issue.\n\nPage 3 of 21\n\nhttps://www.welivesecurity.com/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nIt is not clear whether the group’s apparent focus on Latin America may reflect a formal, geographical mandate, or\n\nwhether this focus is only temporary and dictated by the current geopolitical circumstances.\n\nExamining SparroWocky\n\nSparroWocky is a full-featured, modular C++ backdoor built with modularity and stealthiness in mind. It appeared\n\nshortly after FamousSparrow started focusing on Latin America and quickly became the group’s new flagship\n\nimplant, replacing SparrowDoor. It should be noted that SparroWocky is not a variant of SparrowDoor, but is\n\nrather a distinct malware family. The transition to this new backdoor also came with a greater level of integration\n\nof open-source tooling into FamousSparrow’s workflow: while previously, standalone versions of these tools were\n\ndeployed side by side with SparrowDoor, with SparroWocky, some have been incorporated directly into the\n\nmalware.\n\nSome of SparroWocky’s notable features include the ability to execute arbitrary files, to act as a TCP proxy, and to\n\nexecute commands. The backdoor also collects general information about the compromised machine, such as the\n\ncomputer name, the username, domain name, Windows version, and the IP addresses of its network interfaces.\n\nSparroWocky is also capable of exfiltrating files and taking screenshots periodically. Exfiltrated information is\n\nencrypted using RC4 and sent over the TLS protocol.\n\nDepending on its configuration, SparroWocky can establish persistence either by creating a dedicated service or an\n\nentry in a registry Run key.\n\nLoader\n\nSparroWocky is deployed using the common trident loader scheme, which consists of a legitimate executable, a\n\nmalicious DLL standing in for one required by that executable, and a file containing an encrypted payload (see\n\nFigure 2). The loader resides in the aforementioned DLL and is executed via DLL side-loading. We have seen\n\nFamousSparrow use a wide range of side-loading targets; in most cases, a patched version of the legitimate DLL\n\nthat the executable is supposed to load. While most of the file is left untouched, an arbitrary portion of the .text\n\nsection is replaced with the malicious code, and the entry point header is changed to point inside this patched\n\nregion.\n\nFigure 2. Trident loader scheme\n\nThis has some defense-evasion properties: having the metadata and exported function list of the malicious DLL be\n\nthe same as that of the legitimate version allows it to more easily blend in. Since the code in the patched region\n\ndoes not align with the exported functions and calls in the untouched portion, automated analysis tools may have\n\ntrouble recognizing function boundaries.\n\nPage 4 of 21\n\nhttps://www.welivesecurity.com/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nThe loader’s main role is to extract and decrypt its payload from a file. These files, which typically have the same\n\nname as the executable but with a .dat extension, have a specific structure detailed in Figure 3. The file has a\n\ncustom header that begins with a four-byte magic value of 0x11328712, followed by the size of the configuration\n\ndata, the size of the payload, and a 16-byte RC4 key. This RC4 key is used to decrypt the remainder of the file,\n\nwhich contains the configuration for SparroWocky (detailed in the Configuration section) and the backdoor itself.\n\nWe provide a script to decrypt SparroWocky payload files in our GitHub repository.\n\nFigure 3. Definition of the structure of SparroWocky’s payload file\n\nThe plaintext backdoor payload is formatted as a portable executable (PE) file with the MZ and PE magic values\n\ndeleted. This executable payload is reflectively mapped directly into memory without being written to disk. Thus,\n\nwe believe that stripping these magic values is possibly an attempt to evade in-memory defense mechanisms that\n\nuse simple pattern recognition to identify or dump suspicious sections of memory.\n\nSparroWocky\n\nOur analysis of SparroWocky is mainly based on a sample compiled on November 17th, 2025 according to its PE\n\ntimestamp (SHA-1: 44F0A22B143B79FA760BF31E14C8FFF714C8A2A1). The version of this backdoor appears\n\nto be 1.8, based on the information collected by its fingerprint command explained in Table 3.\n\nAs we already mentioned, we chose the name SparroWocky because we found the first stanza of Lewis Caroll’s\n\nJabberwocky in several samples we collected. We believe that this stanza comes from the test vectors in RFC\n\n7539, which defines the ChaCha20-Poly1305 encryption algorithm. The samples of SparroWocky also contain\n\nother strings that are used as test vectors in that RFC. However, SparroWocky does not use ChaCha20-Poly1305.\n\nWhile we don’t know the exact version of Mbed TLS used in the backdoor, the test vectors were present in that\n\nlibrary prior to version 4.0.0.\n\nNotably, SparroWocky relies at least on the following public projects:\n\nMbed TLS, a C library it uses to establish a secure communication channel with its C\u0026C server,\n\nMinHook, a Windows API hooking library it uses to hide the start address of newly created threads from\n\nsecurity products, and\n\nCOFF Loader (or a similar project) that it uses to enable dynamic loading and execution of in-memory\n\nplugins in the form of COFF objects.\n\nPage 5 of 21\n\nAdditionally, our analysis revealed that the developers implemented various techniques to evade monitoring tools.\n\nThis includes a variant of a technique called SilentMoonwalk (or StackMoonwalk), which allows SparroW\n\nspoof the call stacks originating from MinHook routines. The backdoor also uses a custom\n\nto dynamically resolve Windows\n\ntechniques section.\n\nConfiguration\n\nThe SparroWocky loader extracts and decrypts its configuration from the payload .dat file located in the same\n\ndirectory, as explained in the\n\nconfiguration, which is provided in the form of a tab-separated string that is then parsed and stored in a structure.\n\nThe fields and their values are described in T\n\nTable 1. SparroWocky configuration\n\nField\n\nC\u0026C IP address\n\nC\u0026C port\n\nnumber\n\nConnection retry\n\ndelay (in\n\nseconds)\n\nProxy connection\n\ntype\n\nProxy IP address\n\nProxy port\n\nnumber\n\nProxy username\n\nProxy password\n\nPersistence\n\nmethod\n\nService\n\npersistence:\n\nhttps://www.welivesecurity.com/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nAPI functions. These are explained in greater detail in the\n\nLoader section. The RC4 key stored in the payload header is used to decrypt the\n\nable 1 in order of appearance.\n\nValue\n\n216.238.110[.]120\n\n443\n\n10\n\n0\n\nN/A\n\nN/A\n\nN/A\n\nN/A\n\n1\n\nProcAuditManager\n\nocky to\n\nAPI-hashing algorithm\n\nAnti-analysis\n\nAdditional details\n\nAfter the first retry, the value is randomized.\n\n0: If enabled, use the proxy configured on\n\nthe system; otherwise, connect directly.\n\n1: HTTP proxy via Negotiate or Basic\n\nauthentication.\n\n2: SOCKS5 proxy via Basic authentication\n\nor without authentication.\n\n1: Service persistence.\n\n2: Registry persistence.\n\nIn the configurations we have extracted, the\n\ndisplay name is always the same as the\n\nPage 6 of 21\n\nhttps://www.welivesecurity.com/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nField Value\n\nservice name\n\nService\n\npersistence: ProcAuditManager\n\ndisplay name\n\nService\n\npersistence: Tracks process creation, termination,\n\nservice and related system audit events.\n\ndescription\n\nRegistry\n\npersistence: SnapCart\n\nregistry value\n\nRegistry\nSOFTWARE\\Microsoft\\Windo\npersistence:\nws\\CurrentVersion\\Run\nregistry key\n\nCapabilities\n\nArgument-controlled behavior\n\nAfter parsing its configuration, the backdoor checks the command line of the process in which it is running and\n\nbehaves differently based on the number and value of the arguments passed. If no arguments are present,\n\nSparroWocky simply sets up persistence and executes the core logic of the backdoor\n\nfirst argument directs the malware to follow specific instructions, as described in T\n\nTable 2. SparroWocky command line arguments and their meaning\n\nArgument Behavior\n\nLoad and execute a PE file\n\nin memory for a specified\nc\namount of time before\n\ntermination.\n\nSleep for five seconds, set\n\np up persistence, and run the\n\ncore logic of the backdoor.\n\ns Run the core logic of the\n\nbackdoor without\n\nDescription\n\nUsed in tandem with command 0x16*, SparroW\n\ncommand string, an execution timeout delay\n\nPE file from standard input (stdin). It then loads the specified\n\nexecutable into memory and executes it with the given\n\ncommand.\n\nUsed in tandem with command 0x2F*, this argument also\n\nmeans the backdoor was run as a specific user (via\n\nPage 7 of 21\n\nAdditional details\n\nservice name. These usually match the\n\nfilename of the payload file.\n\nUses HKLM or HKCU depending on\n\nprivileges.\n\n. Otherwise, the value of the\n\nable 2.\n\nocky reads a\n\n, and the body of a\n\nhttps://www.welivesecurity.com/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nArgument Behavior\n\nestablishing persistence.\n\nStart a new instance of the\n\ns2 backdoor with argument p\n\nand terminate.\n\nSet the process working\n\ndirectory to the backdoor\nt\nlocation and run the core\n\nlogic of the backdoor.\n\n* Explained in the Backdoor commands section.\n\nWhen SparroWocky is executed with the c option, it reads an additional comma-separated list of parameters from\n\nstandard input (stdin):\n\na command string,\n\na timeout delay (in seconds), and\n\noptionally, the body of a PE file.\n\nIf this last parameter is absent, the backdoor reads the executable specified in the command string from\n\nC:\\Windows\\System32\\ and loads the associated English MUI (Multilingual User Interface) file (from\n\nC:\\Windows\\System32\\en-US\\). This process is described in the\n\nPEs section. Otherwise, the PE file is executed by SparroW\n\npassed as a command line. This functionality is likely meant to allow the backdoor to easily execute system\n\nutilities.\n\nSparroWocky loads the specified executable into memory and executes it with the provided command.\n\nsame time, the backdoor creates a new thread that calls ExitProcess to kill the process when the timeout delay\n\nexpires. The loading process involves setting up hooks and forging structures in memory to camouflage the host\n\nprocess before running the target executable. These anti-analysis tricks are explained in greater detail in the\n\ndedicated Host process camouflage for dynamically loaded PEs\n\nAdditionally, when the malware is executed without arguments or with the p option, an instance synchronization\n\nmechanism is started. This feature prevents multiple instances of the backdoor from running concurrently by\n\nleveraging a custom interprocess communication (IPC) mechanism. When a new instance is launched, the\n\ncurrently running instance stops and, if the new instance is launched from a different location than the current one,\n\nthe files and persistence configurations set by the currently running instance are deleted. This is achieved by using\n\nthree types of global objects: a mutex, an event, and a shared memory block named MyMutexName,\n\nMyEventName, and MySharedMemName, respectively.\n\nBackdoor commands\n\nDescription\n\nCreateProcessAsUser), identified by a session ID that was\n\nretrieved by command 0x2E*.\n\nThis argument indicates that the backdoor was started via the\n\nservice persistence.\n\nHost process camouflage for dynamically loaded\n\nocky’s reflective loader, and the command string is\n\nAt the\n\nsection.\n\nPage 8 of 21\n\nhttps://www.welivesecurity.com/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nThe backdoor first establishes communication with its C\u0026C server, then executes its core logic in an infinite loop,\n\nwithin which it processes received commands. These are handled by a custom class named WinHandler (derived\n\nfrom a ServerHandler custom class), according to the runtime type information (R\n\nHandlers for a minimal set of commands are hardcoded in the command loop itself. ServerHandler has a dedicated\n\nvirtual method to handle more commands. This method is implemented in WinHandler\n\nobserved other implementations of this method, this architecture would make it easy for its developers to change\n\nthe set of commands that the backdoor can handle. The list of supported commands is shown in T\n\nTable 3. SparroWocky commands\n\nID Arguments\n\n0x10 N/A\n\n0x11* N/A\n\n0x12 N/A\n\n0x13 N/A\n\n\u003cfunction_name\u003e\n\n0x14 \u003cBOF_object\u003e\n\n\u003cfunction_arguments\u003e\n\n0x16 \u003ccommand_line\u003e\n\n\u003cexecution_timeout\u003e\n\n\u003cPE_file\u003e\n\nTTI) present in the malware.\n\n. While we have not\n\nable 3.\n\nDescription\n\nCollects and sends the following system information:\n\n· MD5 hash of the machine GUID,\n\n· SparroWocky PID,\n\n· hostname,\n\n· IP addresses of all network interfaces,\n\n· username,\n\n· Windows product name,\n\n· backdoor version (1.8),\n\n· x64 (likely backdoor architecture),\n\n· domain name,\n\n· SparroWocky’s host file path,\n\n· connection retry delay, and\n\n· self-deletion enable state (0 or 1).\n\nStarts a new interactive session.\n\nEstablishes a new connection to the C\u0026C server, sends an\n\ninitial packet containing the byte sequence 44 33 22 11 (hex),\n\nand then starts processing received commands in a separate\n\nthread.\n\nTerminates by calling ExitProcess.\n\nRemoves persistence then terminates by calling ExitProcess.\n\nLoads a Beacon Object File in memory and calls\n\n\u003cfunction_name\u003e with \u003cfunction_arguments\u003e as parameters,\n\nthen sends the completion status.\n\nSee below for additional details.\n\nExecutes the provided PE file by spawning a new\n\nSparroWocky process with the c parameter and standard I/O\n\nand error streams redirected to the pipe \\\\.\\pipe\\ccpipe. The\n\nPage 9 of 21\n\nhttps://www.welivesecurity.co\n\nID Arguments\n\n0x17 \u003ccommand\u003e\n\n\u003cIP_address\u003e\n0x1A*\n\u003cport\u003e\n\nString of semicolon-separated\n\nvalues starting with two\n\n0x1B unknown values followed by the\n\nIP address and port number on\n\nwhich to listen\n\n0x1C Same as 0x1B\n\n0x1D N/A\n\nPath to the new working\n0x1E\ndirectory\n\n0x1F N/A\n\n0x20 Path to the target directory\n\n0x21 N/A\n\n0x22 Path to the target directory\n\n0x23 Path of the file to delete\n\nm/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nDescription\n\narguments are written to the new process’s stdin, then the\n\noutput of the new process is read and sent to the C\u0026C server.\n\nExecutes \u003ccommand\u003e by spawning cmd.exe with standard I/O\n\nand error streams redirected to two dedicated anonymous\n\npipes.\n\nConnects to the provided IP address (via TCP/IP) and creates\n\na thread to forward the traffic between the remote machine\n\nand the C\u0026C server. The completion status is sent to the C\u0026C\n\nserver.\n\nInternally named PortmapReverseServer, it accepts TCP\n\nconnections and forwards traffic to the C\u0026C server.\n\nFor each accepted connection, a new connection to the C\u0026C\n\nserver is established and a first packet is sent containing the\n\nbyte sequence 13 12 11 09 (hex). The listener code then sends\n\nthe machine GUID followed by the received arguments and\n\nthe list of connections opened so far. The code proceeds to\n\nhandle the forwarding of the traffic between the distant\n\nmachine and the C\u0026C server.\n\nCloses the PortmapReverseServer connection specified by the\n\nprovided IP address and port.\n\nThe list of remaining open connections is sent to the C\u0026C\n\nserver.\n\nReturns a list of all PortmapReverseServer connections to the\n\nC\u0026C server.\n\nSets the specified current working directory and returns the\n\nCWD to the C\u0026C server.\n\nReturns the current working directory to the C\u0026C server.\n\nCreates the specified directory, sending the completion status\n\nto the C\u0026C server.\n\nReturns the list of logical drives and their type to the C\u0026C\n\nserver.\n\nReturns a list of the contents of the specified directory, their\n\nsizes and last-write times, collected via FindFirstFileW.\n\nDeletes the specified file and returns the completion status.\n\nPage 10 of 21\n\nhttps://www.welivesecurity.com\n\nID Arguments\n\n0x24 Source and destination paths\n\n0x25 Source and destination paths\n\nPath of the file to rename and the\n0x26\ndesired new name\n\n0x27* File offset and target file path\n\n0x28* Target file path to write to\n\n0x29 N/A\n\n0x2A Display device name\n\n0x2E N/A\n\nSession ID of the target user\n\n0x2F session (retrieved via command\n\n0x2E)\n\n0x30\nN/A\n0x31\n\n/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nDescription\n\nCopies the specified file to the specified location and returns\n\nthe completion status.\n\nMoves the specified file to the specified location and returns\n\nthe completion status.\n\nRenames the specified file to the specified new name and\n\nreturns the completion status.\n\nSends the file size, creation, last access, and last write\n\ntimestamps, and the contents of the specified file, read from\n\nthe specified offset in chunks of 4,096 bytes.\n\nSends the current size of the specified file then receives the\n\nadditional file contents in 4,096-byte chunks, appending them\n\nto the target file in a loop.\n\nEnumerates display devices and associated settings, returning\n\nfor each active display device:\n\n· device name,\n\n· whether it is the main display,\n\n· width (pixels), and\n\n· height (pixels).\n\nTakes a screenshot periodically by sending an initial JPG\n\nscreenshot with its dimensions (width and height) via\n\ncommand ID 0x2C.\n\nEvery 500 ms, if no new commands are received, a new\n\nscreenshot is taken, and the difference from the previous\n\nscreenshot is sent to the C\u0026C server. Changed blocks of pixels\n\nin these subsequent screenshots are sent along with\n\ncoordinates (x, y) and dimensions via command ID 0x2D.\n\nReturns session IDs and usernames of enumerated remote\n\nsessions on the system, collected via\n\nWTSEnumerateSessionsW.\n\nSpawns a new instance of SparroWocky (with option s) by\n\nduplicating the token associated with the specified session ID\n\nand calling CreateProcessAsUserW.\n\nEchoes the command ID back to the C\u0026C server.\n\nPage 11 of 21\n\nhttps://www.welivesecurity.com/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nID Arguments\n\n0x33 \u003ccommand\u003e\n\n* Hardcoded command.\n\nCommand 0x14 uses a slightly modified version of RunCOFF from the open-source COFF Loader project to load\n\nand execute a Beacon Object File (BOF). A BOF is a position-independent Common Object File Format (COFF)\n\nexecutable that is meant to be run within the memory of an implant. BOFs were first introduced in Cobalt Strike\n\nand have since been adopted by other popular red-teaming frameworks such as Brute Ratel, Metasploit, and\n\nSliver. The change to RunCOFF resides in the resolution of imported symbols. SparroW\n\nexternal libraries in the BOF to a stack-spoofing subroutine. This effectively hides and proxies calls made by the\n\nBOF object. Once the object is loaded, the BOF loader finds and executes function_name, passing the arguments\n\nprovided in function_arguments. The ability to load BOFs allows FamousSparrow to use existing modules and\n\ntools designed to work with this file type.\n\nSelf-deletion\n\nAs described in the Argument-controlled behavior\n\nThis can be done from the C\u0026C server via command 0x13. First, the persistence mechanism previously set is\n\nremoved and then the batch file shown in Figure 4 is created and executed.\n\n@echo off\ntimeout /t 2\ndel \"\u003clegitimate_executable\u003e\" /f /q\ndel \"\u003cloader_library\u003e\" /f /q\ndel \"\u003cpayload_filepath\u003e\" /f /q\ndel \"%%0\" /f /q\\n\n\nFigure 4. Batch file for self-deletion\n\nThis deletes the files used by the backdoor: the legitimate executable, the side-loading library\n\nfile. The batch file deletes itself at the end of the script.\n\nAnti-analysis techniques\n\nSparroWocky employs a few techniques to complicate its analysis and to evade security software that may be in\n\nplace. A common technique that the backdoor uses is dynamic\n\nalso uses more interesting ones, described below.\n\nSilentMoonwalk\n\nDescription\n\nExecutes \u003ccommand\u003e in the current directory by calling\n\nCreateProcess with lpCommandLine set to \u003ccommand\u003e and\n\nlpCurrentDirectory set to the CWD. The PID of the newly\n\ncreated process is returned to the C\u0026C server.\n\nocky redirects calls to\n\nsection, SparroWocky can delete itself entirely from the system.\n\n, and the payload\n\nAPI resolution via API hashing, but the backdoor\n\nPage 12 of 21\n\nhttps://www.welivesecurity.com/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nThe first noteworthy technique is called SilentMoonwalk, which essentially provides a way to forge fake call\n\nstacks. Its purpose is to prevent analysis tools and products from inspecting the true caller of specific functions\n\nthat are frequently monitored, such as Windows API functions. This method requires a few initialization steps:\n\nFinding the offset of RtlUserThreadStart and BaseThreadInitThunk, two functions that are usually found at\n\nthe start (or bottom) of any call stack.\n\nFinding a JOP (jump-oriented programming) and a ROP (return-oriented programming) gadget in the\n\nlegitimate kernel32.dll library to restore the original call stack.\n\nOnce these requirements are met, when SparroWocky makes an obfuscated call to a Windows API function, it first\n\nsaves the current context (registers); next, it forges a fake stack using the gadgets found previously, and then\n\ninserts the address of a stack and context restoration routine. This makes it appear as if the calls to Windows API\n\nfunctions are originating from RtlUserThreadStart and BaseThreadInitThunk. Figure 5 shows the call stack view\n\nfrom a debugging session using WinDbg.\n\nFigure 5. WinDbg call stack view of an obfuscated call to Sleep\n\nIn the case of SparroWocky, this technique is used to obfuscate calls made by BOF-formatted plugins (command\n\n0x14) or by the statically linked MinHook hooking library.\n\nConcealing the thread start address\n\nSparroWocky uses the MinHook library to hook the CreateThread function in order to conceal the original\n\nlpStartAddress parameter from security products. Essentially, any thread created by SparroWocky would have\n\nAnimateWindow as the starting address, which would likely be considered legitimate by a security product. The\n\npatch applied to AnimateWindow turns it into a trampoline that simply executes the original start address, as\n\nillustrated in Figure 6.\n\nFigure 6. AnimateWindow API is patched to execute the original start address\n\nHost process camouflage for dynamically loaded PEs\n\nThe last notable piece of code from SparroWocky is its custom PE loader, used when executed with option c.\n\nWhile implementing PE loaders is pretty much routine for malware authors, SparroWocky authors took it a step\n\nfurther and integrated host process camouflage.\n\nPage 13 of 21\n\nhttps://www.welivesecurity.com/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nAs described in Table 2, when SparroWocky is executed with the c option, it loads a PE file in memory and\n\nexecutes it. If the file is not passed as an argument, the PE loader parses the specified command line to extract the\n\nfile’s name. It searches for that filename in the C:\\Windows\\System32\\ directory, but most importantly it retrieves\n\nthe English localization MUI file associated with the target PE (stored as C:\\Windows\\System32\\en-US\\\n\n\u003cexe_name\u003e.mui). In that case, the PE file is loaded in memory, and a few hooks are set to make sure any calls\n\nmade by the loaded PE file to retrieve resource data, such as RtlLoadString or RtlFindMessage, are redirected to\n\nthe .mui data. This process mirrors normal behavior of Windows when loading PEs, and reduces the risk of\n\nunexpected errors.\n\nThe command line retrieved from Stdin is parsed and SparroWocky hooks the following functions, which are used\n\nto retrieve information about command line arguments, to make them point to this command line:\n\nGetCommandline[AW]\n\n__(w}getmainargs\n\n__p___argc\n\n__p___{w}argv\n\nThe PE loader is also able to register the exception handlers of the newly loaded executable – an unusual, yet\n\ncritical, addition – since it allows exceptions to be handled correctly.\n\nFinally, before calling the entry point of the loaded PE file, SparroWocky forges and inserts a fake\n\nLDR_DATA_TABLE_ENTRY structure in the doubly linked list of the PEB_LDR_DATA structure. This doubly\n\nlinked list is used by Windows to keep track of loaded modules and is usually monitored by security products.\n\nFigure 7 shows a snippet of the code used to set some of its fields.\n\nFigure 7. SparroWocky forges an LDR_DATA_TABLE_ENTRY structure\n\nThis last technique shows that SparroWocky authors possess a deep understanding of the Windows PE loading\n\nmechanism and are willing to go the extra mile to camouflage the host process and confuse monitoring software.\n\nNetwork protocol\n\nTo communicate with its C\u0026C server, SparroWocky uses the TLS encryption protocol. Under the hood, the\n\nbackdoor uses the Mbed TLS library and the only element worth mentioning is that it uses the personalization\n\nPage 14 of 21\n\nhttps://www.welivesecurity.com/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nstring acdbenus when initializing the deterministic random bit generator, as seen in Figure 8.\n\nFigure 8. Custom initialization of Mbed TLS random bit generator\n\nBefore the initial TLS handshake, a TCP connection is established with the C\u0026C server using one of three\n\nconnection modes:\n\nA connection mode of 0 means that SparroWocky uses the proxy currently configured on the machine or a direct\n\nTCP connection if no system proxy is configured. This configuration is retrieved by querying the ProxyServer\n\nregistry value located under the registry key HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet\n\nSettings. If the connection to the proxy server is not successful, SparroWocky tries to connect via mode 1, then\n\nmode 2.\n\nConnection mode 1 represents a connection via an HTTP proxy. This connection uses either the Negotiate\n\n(Kerberos or NTLM) or Basic authentication scheme with the username and password provided in the\n\nconfiguration. Both authentication methods use generic HTTP headers with the User-Agent string set to\n\nMozilla/5.0.\n\nConnection mode 2 uses a SOCKS5 proxy without authentication (AUTH field set to 0x00) or with a username\n\nand password (AUTH field set to 0x02). The values used by the latter are provided in the configuration.\n\nCommand messages\n\nOnce the TLS handshake is complete, SparroWocky sends the bytes 0x11223344 (big-endian) to indicate that it is\n\nready to receive commands in the main session. The backdoor uses a simple format to receive commands and send\n\nresults, as illustrated in Figure 9.\n\nPage 15 of 21\n\nhttps://www.welivesecurity.com/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nFigure 9. Command message format\n\nIf the command_arg_size field does not equal 0, then additional data is to be received or sent after the header. In\n\nthat case, the data (command arguments or results) is encrypted via RC4, and each command message uses a\n\nnewly generated eight-byte key, which is sent in the header.\n\nNetwork infrastructure\n\nSparroWocky uses the IP address of its C\u0026C servers, which is generally running on port 443, to connect directly.\n\nWe have also seen it running on port 8080 in some cases. While we have observed some self-signed certificates\n\nbeing reused across multiple servers, we do not have a reliable generic fingerprint.\n\nConclusion\n\nOver the latter half of 2025 and the first half of 2026, FamousSparrow had been focusing on targets in Latin\n\nAmerica. This represents a shift from its previous global targeting. To go along with this change, the group has\n\ndeveloped SparroWocky, which replaced SparrowDoor as its main implant. While it doesn’t appear to be based on\n\nthe same codebase, we can see that SparroWocky still shares some of the functionality and concepts that were\n\npresent in the group’s previous backdoor, which we analyzed in our previous blogpost. SparroWocky uses more\n\ncomplex defense evasion techniques to stay under the radar.\n\nFamousSparrow still uses open-source offensive tooling for its own malicious ends. Previously, these tools were\n\nmainly used side by side with the group’s backdoor. With SparroWocky, we can observe that it also has the\n\ndevelopment capabilities to integrate open-source code directly into its own custom backdoor.\n\nFor any inquiries about our research published on WeLiveSecurity, please contact us at\n\nthreatintel@eset.com.\n\nESET Research offers private APT intelligence reports and data feeds. For any inquiries about this\n\nservice, visit the ESET Threat Intelligence page.\n\nIoCs\n\nA comprehensive list of indicators of compromise (IoCs) and samples can be found in our GitHub repository.\n\nFiles\n\nPage 16 of 21\n\nhttps://www.welivesecurity.com/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nSHA-1 Filename Detection Description\n\n3209689E509205CCDB7E SparroWocky\nwinfsp-x64.dll Win64/Agent.HUP\n49062B7B407DDC23CAC1 loader.\n\n52C6646759CF6037BB17 SparroWocky\nwinfsp-x64.dll Win64/Agent.HUP\n466203631C4BD794532F loader.\n\n99E7070B5AF24A0FE1E6 SparroWocky\nDukeQt.dll Win64/Agent.ISF\nFEBE5954B03CB385E91F loader.\n\n44F0A22B143B79FA760B N/A (in- SparroWocky\nWin64/Agent.ASW\nF31E14C8FFF714C8A2A1 memory) backdoor.\n\n9AA9FF61BC63CCAB907 N/A (in- SparroWocky\nWin64/Agent.ASW\n4FE837F39C980CA9DDC8C memory) backdoor.\n\nNetwork\n\nIP Domain Hosting provider First seen Details\n\n38.54.57[.]17 N/A LightNode‑BR 2026‑02‑25 SparroWocky C\u0026C server.\n\n38.60.197[.]55 N/A Kaopu Cloud HK Limited 2026‑03‑16 SparroWocky C\u0026C server.\n\n38.60.209[.]106 N/A Kaopu Cloud HK Limited 2026‑02‑26 SparroWocky C\u0026C server.\n\n38.60.224[.]51 N/A Kaopu Cloud HK Limited 2026‑02‑25 SparroWocky C\u0026C server.\n\n38.60.224[.]235 N/A Kaopu Cloud HK Limited 2026‑02‑24 SparroWocky C\u0026C server.\n\n38.60.241[.]65 N/A Cogent Communications\n\n38.60.241[.]127 N/A Cogent Communications\n\n38.60.241[.]193 N/A KaopuCloud‑BR\n\n77.111.101[.]40 N/A Latitude.sh\n\n91.148.134[.]115 N/A Charles‑R Paquet\n\n130.94.101[.]82 N/A NTT America, Inc.\n\n140.99.164[.]199 N/A Private Customer\n\n149.104.87[.]228 N/A Lightnode‑MX\n\n149.104.90[.]203 N/A BEDGE CO LIMITED\n\n2026‑03‑10 SparroWocky C\u0026C server.\n\n2026‑03‑04 SparroWocky C\u0026C server.\n\n2026‑01‑22 SparroWocky C\u0026C server.\n\n2026‑05‑20 SparroWocky C\u0026C server.\n\n2026‑06‑17 SparroWocky C\u0026C server.\n\n2026‑02‑26 SparroWocky C\u0026C server.\n\n2026‑02‑26 SparroWocky C\u0026C server.\n\n2026‑02‑24 SparroWocky C\u0026C server.\n\n2026‑01‑22 SparroWocky C\u0026C server.\n\n216.238.92[.]2 N/A The Constant Company, LLC 2026‑02‑25 SparroWocky C\u0026C server.\n\nPage 17 of 21\n\nIP\n\n216.238.105[.]53\n\n216.238.110[.]120\n\n216.238.121[.]164\n\nMITRE ATT\u0026CK techniques\n\nThis table was built using\n\nTactic\n\nResource\n\nDevelopment\n\nInitial Access\n\nExecution\n\nhttps://www.welivesecurity.com/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nDomain\n\nN/A\n\nN/A\n\nN/A\n\nversion 19\n\nID\n\nT1583.003\n\nT1587.001\n\nT1608.001\n\nT1190\n\nT1059.003\n\nT1569.002\n\nT1106\n\nT1559\n\nT1574.001\n\nHosting provider\n\nThe Constant Company, LLC\n\nThe Constant Company, LLC\n\nThe Constant Company, LLC\n\nof the MITRE ATT\u0026CK framework.\n\nName\n\nAcquire Infrastructure:\n\nVirtual Private Server\n\nDevelop Capabilities:\n\nMalware\n\nStage Capabilities: Upload\n\nMalware\n\nExploit Public-Facing\n\nApplication\n\nCommand and Scripting\n\nInterpreter: Windows\n\nCommand Shell\n\nSystem Services: Service\n\nExecution\n\nNative API\n\nInter-Process Communication\n\nHijack Execution Flow: DLL\n\nPage 18 of 21\n\nFirst seen Details\n\n2026‑01‑22 SparroWocky C\u0026C server.\n\n2025‑12‑11 SparroWocky C\u0026C server.\n\n2026‑03‑16 SparroWocky C\u0026C server.\n\nDescription\n\nFamousSparrow has acquired servers to\n\nuse for C\u0026C and delivery servers for\n\nSparroWocky.\n\nFamousSparrow has developed\n\nSparroWocky and its loader.\n\nFamousSparrow has uploaded the\n\nSparroWocky trident loader to attacker-\n\ncontrolled delivery servers.\n\nFamousSparrow gained access to targets’\n\nnetworks by exploiting publicly reachable\n\nExchange servers.\n\nSparroWocky has functionality to run\n\ncommands via the Windows command\n\nshell.\n\nWhen establishing persistence via a\n\nservice, SparroWocky starts the service\n\ndirectly.\n\nSparroWocky uses the native Windows\n\nAPI.\n\nSparroWocky uses an interprocess\n\ncommunication mechanism to\n\nsynchronize instances when a new one is\n\nlaunched.\n\nThe SparroWocky loader is executed via\n\nDLL side-loading.\n\nhttps://www.welivesecurity.com/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nTactic ID Name Description\n\nBoot or Logon Autostart\nSparroWocky can persist via a registry\nT1547.001 Execution: Registry Run\nRun key.\nKeys / Startup Folder\nPersistence\n\nCreate or Modify System SparroWocky can persist via a Windows\nT1543.003\nProcess: Windows Service service.\n\nStealth SparroWocky can create processes using a\nAccess Token Manipulation:\nT1134.002 token obtained from any existing user\nCreate Process with Token\nsession.\n\nSparroWocky’s loader retrieves the\n\nDeobfuscate/Decode Files or configuration and payload via RC4\nT1140\nInformation decryption of the content of a file with a\n\ncustom format.\n\nSparroWocky uses a mutex to prevent\nExecution Guardrails: Mutual\nT1480.002\nExclusion\n\nHide Artifacts: Process\nT1564.010\nArgument Spoofing\n\nObfuscated Files or\n\nmultiple instances from running\n\nconcurrently.\n\nWhen loading an external PE file,\n\nSparroWocky hooks functions to retrieve\n\nits command line arguments from stdin.\n\nSparroWocky uses a custom API hashing\n\nT1027.007 Information: Dynamic API algorithm to dynamically resolve API\n\nResolution functions at runtime.\n\nThe SparroWocky reflectively loads its\n\npayload into memory. SparroWocky can\nT1620 Reflective Code Loading\nreflectively load and execute PE and BOF\n\nobjects.\n\nIndicator Removal: File SparroWocky can delete itself from the\nT1070.004\nDeletion compromised machine.\n\nSparroWocky can remove its persistence\nIndicator Removal: Clear\nT1070.009 mechanism from the compromised\nPersistence\nmachine.\n\nThe SparroWocky loader keeps the now\nMasquerading: Invalid Code\nT1036.001 invalid signature of the legitimate module\nSignature\nit is impersonating.\n\nPage 19 of 21\n\nhttps://www.welivesecurity.com/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nTactic ID Name Description\n\nSparroWocky uses legitimate or generic\nMasquerading: Masquerade\nT1036.004 names and descriptions for its persistence\nTask or Service\nservice.\n\nSparroWocky can list files and directories\nT1083 File and Directory Discovery\non mapped drives.\n\nSparroWocky can retrieve information\nT1680 Local Storage Discovery\n\nSystem Information\nT1082\nDiscovery Discovery\n\nSystem Owner/User\nT1033\nDiscovery\n\nabout mapped storage devices.\n\nSparroWocky can collect information\n\nabout the system it is running on, such as\n\nthe Windows version, hostname, and the\n\nIP addresses of network interfaces.\n\nSparroWocky can retrieve the username\n\nof the current user and of any user with an\n\nactive session.\n\nSparroWocky can retrieve information\nT1120 Peripheral Device Discovery\nabout connected display devices.\n\nSparroWocky can exfiltrate files from\nT1005 Data from Local System\nmapped storage.\nCollection\nSparroWocky can periodically capture\nT1113 Screen Capture\nscreenshots.\n\nSparroWocky uses TLS, which uses\nEncrypted Channel:\nT1573.002 asymmetric cryptography in its\nAsymmetric Cryptography\nhandshake.\n\nEncrypted Channel: SparroWocky uses RC4 to encrypt the\nT1573.001\nSymmetric Cryptography information it exfiltrates.\n\nSparroWocky can proxy connections\nCommand and\nT1090.001 Proxy: Internal Proxy between the C\u0026C server and another\nControl\nremote machine.\n\nSparroWocky can use an HTTP or\n\nT1090.002 Proxy: External Proxy SOCKS5 proxy to connect to its C\u0026C\n\nserver.\n\nNon-Application Layer SparroWocky uses TLS over TCP to\nT1095\nProtocol communicate with its C\u0026C server.\n\nPage 20 of 21\n\nhttps://www.welivesecurity.com/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nTactic ID Name Description\n\nSparroWocky exfiltrates data through the\n\nExfiltration T1041 Exfiltration Over C2 Channel same connection used to receive\n\ncommands from the C\u0026C server.\n\nSource: https://www.welivesecurity.com/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/\n\nPage 21 of 21", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://www.welivesecurity.com/en/eset-research/beware-sparrowock-backdoor-bites-commands-catch/" ], "report_names": [ "beware-sparrowock-backdoor-bites-commands-catch" ], "threat_actors": [ { "id": "f67fb5b3-b0d4-484c-943e-ebf12251eff6", "created_at": "2022-10-25T16:07:23.605611Z", "updated_at": "2026-09-24T02:00:07.064061Z", "deleted_at": null, "main_name": "FamousSparrow", "aliases": [ "Earth Estries" ], "source_name": "ETDA:FamousSparrow", "tools": [], "source_id": "ETDA", "reports": null }, { "id": "f0eca237-f191-448f-87d1-5d6b3651cbff", "created_at": "2024-02-06T02:00:04.140087Z", "updated_at": "2026-09-24T02:00:05.2629Z", "deleted_at": null, "main_name": "GhostEmperor", "aliases": [ "RedMike", "OPERATOR PANDA", "FamousSparrow", "UNC2286", "Salt Typhoon" ], "source_name": "MISPGALAXY:GhostEmperor", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "a09ade2a-6b87-4f9a-b4f8-23cf14f63633", "created_at": "2023-11-04T02:00:07.676869Z", "updated_at": "2026-09-24T02:00:04.945366Z", "deleted_at": null, "main_name": "Earth Estries", "aliases": [], "source_name": "MISPGALAXY:Earth Estries", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "d390d62a-6e11-46e5-a16f-a88898a8e6ff", "created_at": "2024-12-28T02:01:54.899899Z", "updated_at": "2026-09-24T02:00:07.664318Z", "deleted_at": null, "main_name": "Salt Typhoon", "aliases": [ "Earth Estries", "FamousSparrow", "GhostEmperor", "Operator Panda", "RedMike", "Salt Typhoon", "UNC2286" ], "source_name": "ETDA:Salt Typhoon", "tools": [ "Agentemis", "Backdr-NQ", "Cobalt Strike", "CobaltStrike", "Crowdoor", "Cryptmerlin", "Deed RAT", "Demodex", "FamousSparrow", "FuxosDoor", "GHOSTSPIDER", "HemiGate", "MASOL RAT", "Mimikatz", "NBTscan", "NinjaCopy", "ProcDump", "PsExec", "PsList", "SnappyBee", "SparrowDoor", "TrillClient", "WinRAR", "Zingdoor", "certutil", "certutil.exe", "cobeacon", "nbtscan" ], "source_id": "ETDA", "reports": null }, { "id": "024d447f-fdba-4545-a421-21fffc5f2edb", "created_at": "2026-09-17T02:00:03.694586Z", "updated_at": "2026-09-24T02:00:04.997972Z", "deleted_at": null, "main_name": "BRONZE TIGER", "aliases": [ "Earth Estries ", "Famous Sparrow ", "Ghost Emperor ", "RedMike ", "Salt Typhoon " ], "source_name": "Secureworks:BRONZE TIGER", "tools": [], "source_id": "Secureworks", "reports": null }, { "id": "fcff864b-9255-49cf-9d9b-2b9cb2ad7cff", "created_at": "2025-04-23T02:00:55.190165Z", "updated_at": "2026-09-24T02:00:05.542073Z", "deleted_at": null, "main_name": "Salt Typhoon", "aliases": [ "Salt Typhoon" ], "source_name": "MITRE:Salt Typhoon", "tools": [ "JumbledPath" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1790128970, "ts_updated_at": 1790215291, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/0bbe08391e07869882c39a9bbe8de8537363be06.pdf", "text": "https://archive.orkl.eu/0bbe08391e07869882c39a9bbe8de8537363be06.txt", "img": "https://archive.orkl.eu/0bbe08391e07869882c39a9bbe8de8537363be06.jpg" } }