NightEagle targets Russian companies

ESET said FamousSparrow has replaced SparrowDoor with SparroWocky

ESET Research’s ongoing monitoring of FamousSparrow has borne fruit once again. Our previous public report on FamousSparrow revealed that this China-aligned APT group had developed two new versions of its custom backdoor named SparrowDoor. This time, we discovered that FamousSparrow has switched to a new backdoor, SparroWocky, and has been deploying it to several countries in Latin America since at least August 2025. In what was probably China’s reaction to the US showing increased interest in Latin America, FamousSparrow increased its targeting of the region to almost exclusively targeting it in July 2025. A month later, we noticed that the group had started using the new SparroWocky backdoor, which then quickly replaced SparrowDoor as FamousSparrow’s main implant. SparroWocky is a modular, C++ backdoor. Its architecture and the techniques used by its authors indicate strong knowledge of anti-analysis tricks and Windows internals. We chose to name the backdoor SparroWocky because the first samples we collected all contain the first stanza of Jabberwocky, a nonsense poem by Lewis Carroll. Fortunately, while advanced, SparroWocky’s inner workings are much less arcane than a gyre and gimble in the wabe, so a through and through [of] the vorpal blade allowed us to bring you a detailed analysis of the backdoor. Key points of the blogpost: FamousSparrow is extensively targeting governmental organizations in Latin America. Since August 2025, the group appears to be abandoning SparrowDoor in favor of SparroWocky, a new custom C++ backdoor. With the switch to SparroWocky, FamousSparrow started to incorporate code from open-source projects directly into its malware. SparroWocky is a full-featured backdoor that manipulates low-level structures in memory, and patches code at runtime in order to avoid detection. SparroWocky has the capability to load and execute Beacon Object Files, a special type of executable file supported by many red-teaming and penetration-testing tools. FamousSparrow is a China-aligned cyberespionage group believed to have been active since at least 2019. We first publicly documented the group in a blogpost from September 2021 when we observed it exploiting the ProxyLogon vulnerability. The group was initially known for targeting hotels around the world but has also targeted governments, international organizations, trade groups, engineering companies, and law firms. FamousSparrow is the only known user of the SparrowDoor backdoor. We analyzed two versions of SparrowDoor in a 2025 blogpost, in which we also discussed the attribution claims around the group. As mentioned by Trend Micro, FamousSparrow is linked to Earth Estries; however, the exact nature of the link is not fully known. FamousSparrow has also been publicly linked to Salt Typhoon, but, due to the absence of any technical indicators, we track them as separate. Based on our investigation, we attribute the latest campaign and the SparroWocky backdoor to FamousSparrow with high confidence, since in some of the first attacks involving this backdoor, SparroWocky was deployed by the FamousSparrow-exclusive SparrowDoor. Moreover, not only does the victimology match FamousSparrow’s previous targeting, we have also recorded attempts to deploy SparroWocky at many of the same organizations that had previously been targeted with SparrowDoor. Latin America in the crosshairs As previously mentioned, FamousSparrow currently appears to be focused on high-profile targets in Latin America. This trend started at the latest in July 2025 and has continued with the introduction of SparroWocky. In fact, from mid-2025 and into 2026, 90% of the group’s targets registered in our telemetry have been located in the region. As depicted in Figure 1, we’ve seen the new backdoor deployed against governmental entities in Argentina, Ecuador, Guatemala, Honduras, Panama, Peru, Puerto Rico, and Venezuela. This represents a rare occurrence among the China-aligned APT groups that we currently track, which are generally observed throughout various world regions within such an extended time frame. We believe that this focus is not coincidental and likely reflects China’s reaction to various recent US initiatives in the region. Indeed, Donald Trump’s second presidential term has brought about an aggressive reaffirmation of US interests in Latin America, which threatens various long-term investments that China has cultivated throughout the continent in the last decade, in domains such as energy, mining, and telecommunications. We suspect that FamousSparrow’s activities are intended to help China better monitor and anticipate the reaction of local governments to current US pressures. In some cases, we have observed elements that clearly seem to confirm this hypothesis. For instance, one of the Panamanian entities we’ve seen being targeted is directly involved in the ongoing commercial dispute regarding two major ports located in the canal area, which were, until recently, operated by a China-based company. As the concession granted to this company was legally challenged by the Panamanian government in early 2025, it seems highly likely that FamousSparrow’s operation was intended to gain early, privileged knowledge of local authorities’ intentions on this issue. It is not clear whether the group’s apparent focus on Latin America may reflect a formal, geographical mandate, or whether this focus is only temporary and dictated by the current geopolitical circumstances. Examining SparroWocky SparroWocky is a full-featured, modular C++ backdoor built with modularity and stealthiness in mind. It appeared shortly after FamousSparrow started focusing on Latin America and quickly became the group’s new flagship implant, replacing SparrowDoor. It should be noted that SparroWocky is not a variant of SparrowDoor, but is rather a distinct malware family. The transition to this new backdoor also came with a greater level of integration of open-source tooling into FamousSparrow’s workflow: while previously, standalone versions of these tools were deployed side by side with SparrowDoor, with SparroWocky, some have been incorporated directly into the malware. Some of SparroWocky’s notable features include the ability to execute arbitrary files, to act as a TCP proxy, and to execute commands. The backdoor also collects general information about the compromised machine, such as the computer name, the username, domain name, Windows version, and the IP addresses of its network interfaces. SparroWocky is also capable of exfiltrating files and taking screenshots periodically. Exfiltrated information is encrypted using RC4 and sent over the TLS protocol. Depending on its configuration, SparroWocky can establish persistence either by creating a dedicated service or an entry in a registry Run key. SparroWocky is deployed using the common trident loader scheme, which consists of a legitimate executable, a malicious DLL standing in for one required by that executable, and a file containing an encrypted payload (see Figure 2). The loader resides in the aforementioned DLL and is executed via DLL side-loading. We have seen FamousSparrow use a wide range of side-loading targets; in most cases, a patched version of the legitimate DLL that the executable is supposed to load. While most of the file is left untouched, an arbitrary portion of the .text section is replaced with the malicious code, and the entry point header is changed to point inside this patched region. This has some defense-evasion properties: having the metadata and exported function list of the malicious DLL be the same as that of the legitimate version allows it to more easily blend in. Since the code in the patched region does not align with the exported functions and calls in the untouched portion, automated analysis tools may have trouble recognizing function boundaries. The loader’s main role is to extract and decrypt its payload from a file. These files, which typically have the same name as the executable but with a .dat extension, have a specific structure detailed in Figure 3. The file has a custom header that begins with a four-byte magic value of 0x11328712, followed by the size of the configuration data, the size of the payload, and a 16-byte RC4 key. This RC4 key is used to decrypt the remainder of the file, which contains the configuration for SparroWocky (detailed in the Configuration section) and the backdoor itself. We provide a script to decrypt SparroWocky payload files in our GitHub repository. The plaintext backdoor payload is formatted as a portable executable (PE) file with the MZ and PE magic values deleted. This executable payload is reflectively mapped directly into memory without being written to disk. Thus, we believe that stripping these magic values is possibly an attempt to evade in-memory defense mechanisms that use simple pattern recognition to identify or dump suspicious sections of memory. SparroWocky Our analysis of SparroWocky is mainly based on a sample compiled on November 17th, 2025 according to its PE timestamp (SHA-1: 44F0A22B143B79FA760BF31E14C8FFF714C8A2A1). The version of this backdoor appears to be 1.8, based on the information collected by its fingerprint command explained in Table 3. As we already mentioned, we chose the name SparroWocky because we found the first stanza of Lewis Caroll’s Jabberwocky in several samples we collected. We believe that this stanza comes from the test vectors in RFC 7539, which defines the ChaCha20-Poly1305 encryption algorithm. The samples of SparroWocky also contain other strings that are used as test vectors in that RFC. However, SparroWocky does not use ChaCha20-Poly1305. While we don’t know the exact version of Mbed TLS used in the backdoor, the test vectors were present in that library prior to version 4.0.0. Notably, SparroWocky relies at least on the following public projects: Mbed TLS, a C library it uses to establish a secure communication channel with its C&C server, MinHook, a Windows API hooking library it uses to hide the start address of newly created threads from security products, and COFF Loader (or a similar project) that it uses to enable dynamic loading and execution of in-memory plugins in the form of COFF objects. Additionally, our analysis revealed that the developers implemented various techniques to evade monitoring tools. This includes a variant of a technique called SilentMoonwalk (or StackMoonwalk), which allows SparroWocky to spoof the call stacks originating from MinHook routines. The backdoor also uses a custom API-hashing algorithm to dynamically resolve Windows API functions. These are explained in greater detail in the Anti-analysis techniques section. The SparroWocky loader extracts and decrypts its configuration from the payload .dat file located in the same directory, as explained in the Loader section. The RC4 key stored in the payload header is used to decrypt the configuration, which is provided in the form of a tab-separated string that is then parsed and stored in a structure. The fields and their values are described in Table 1 in order of appearance. Table 1. SparroWocky configuration Capabilities After parsing its configuration, the backdoor checks the command line of the process in which it is running and behaves differently based on the number and value of the arguments passed. If no arguments are present, SparroWocky simply sets up persistence and executes the core logic of the backdoor. Otherwise, the value of the first argument directs the malware to follow specific instructions, as described in Table 2. Table 2. SparroWocky command line arguments and their meaning Explained in the Backdoor commands section. When SparroWocky is executed with the c option, it reads an additional comma-separated list of parameters from standard input (stdin): a command string, a timeout delay (in seconds), and optionally, the body of a PE file. If this last parameter is absent, the backdoor reads the executable specified in the command string from C:\Windows\System32\ and loads the associated English MUI (Multilingual User Interface) file (from C:\Windows\System32\en-US\). This process is described in the Host process camouflage for dynamically loaded PEs section. Otherwise, the PE file is executed by SparroWocky’s reflective loader, and the command string is passed as a command line. This functionality is likely meant to allow the backdoor to easily execute system utilities. SparroWocky loads the specified executable into memory and executes it with the provided command. At the same time, the backdoor creates a new thread that calls ExitProcess to kill the process when the timeout delay expires. The loading process involves setting up hooks and forging structures in memory to camouflage the host process before running the target executable. These anti-analysis tricks are explained in greater detail in the dedicated Host process camouflage for dynamically loaded PEs section. Additionally, when the malware is executed without arguments or with the p option, an instance synchronization mechanism is started. This feature prevents multiple instances of the backdoor from running concurrently by leveraging a custom interprocess communication (IPC) mechanism. When a new instance is launched, the currently running instance stops and, if the new instance is launched from a different location than the current one, the files and persistence configurations set by the currently running instance are deleted. This is achieved by using three types of global objects: a mutex, an event, and a shared memory block named MyMutexName, MyEventName, and MySharedMemName, respectively. The backdoor first establishes communication with its C&C server, then executes its core logic in an infinite loop, within which it processes received commands. These are handled by a custom class named WinHandler (derived from a ServerHandler custom class), according to the runtime type information (RTTI) present in the malware. Handlers for a minimal set of commands are hardcoded in the command loop itself. ServerHandler has a dedicated virtual method to handle more commands. This method is implemented in WinHandler. While we have not observed other implementations of this method, this architecture would make it easy for its developers to change the set of commands that the backdoor can handle. The list of supported commands is shown in Table 3. Table 3. SparroWocky commands Hardcoded command. Command 0x14 uses a slightly modified version of RunCOFF from the open-source COFF Loader project to load and execute a Beacon Object File (BOF). A BOF is a position-independent Common Object File Format (COFF) executable that is meant to be run within the memory of an implant. BOFs were first introduced in Cobalt Strike and have since been adopted by other popular red-teaming frameworks such as Brute Ratel, Metasploit, and Sliver. The change to RunCOFF resides in the resolution of imported symbols. SparroWocky redirects calls to external libraries in the BOF to a stack-spoofing subroutine. This effectively hides and proxies calls made by the BOF object. Once the object is loaded, the BOF loader finds and executes function_name, passing the arguments provided in function_arguments. The ability to load BOFs allows FamousSparrow to use existing modules and tools designed to work with this file type. Self-deletion As described in the Argument-controlled behavior section, SparroWocky can delete itself entirely from the system. This can be done from the C&C server via command 0x13. First, the persistence mechanism previously set is removed and then the batch file shown in Figure 4 is created and executed. @echo off timeout /t 2 del " " /f /q del " " /f /q del " " /f /q del "%%0" /f /q\n Figure 4. Batch file for self-deletion This deletes the files used by the backdoor: the legitimate executable, the side-loading library, and the payload file. The batch file deletes itself at the end of the script. SparroWocky employs a few techniques to complicate its analysis and to evade security software that may be in place. A common technique that the backdoor uses is dynamic API resolution via API hashing, but the backdoor also uses more interesting ones, described below. SilentMoonwalk The first noteworthy technique is called SilentMoonwalk, which essentially provides a way to forge fake call stacks. Its purpose is to prevent analysis tools and products from inspecting the true caller of specific functions that are frequently monitored, such as Windows API functions. This method requires a few initialization steps: Finding the offset of RtlUserThreadStart and BaseThreadInitThunk, two functions that are usually found at the start (or bottom) of any call stack. Finding a JOP (jump-oriented programming) and a ROP (return-oriented programming) gadget in the legitimate kernel32.dll library to restore the original call stack. Once these requirements are met, when SparroWocky makes an obfuscated call to a Windows API function, it first saves the current context (registers); next, it forges a fake stack using the gadgets found previously, and then inserts the address of a stack and context restoration routine. This makes it appear as if the calls to Windows API functions are originating from RtlUserThreadStart and BaseThreadInitThunk. Figure 5 shows the call stack view from a debugging session using WinDbg. In the case of SparroWocky, this technique is used to obfuscate calls made by BOF-formatted plugins (command 0x14) or by the statically linked MinHook hooking library. Concealing the thread start address SparroWocky uses the MinHook library to hook the CreateThread function in order to conceal the original lpStartAddress parameter from security products. Essentially, any thread created by SparroWocky would have AnimateWindow as the starting address, which would likely be considered legitimate by a security product. The patch applied to AnimateWindow turns it into a trampoline that simply executes the original start address, as illustrated in Figure 6. The last notable piece of code from SparroWocky is its custom PE loader, used when executed with option c. While implementing PE loaders is pretty much routine for malware authors, SparroWocky authors took it a step further and integrated host process camouflage. As described in Table 2, when SparroWocky is executed with the c option, it loads a PE file in memory and executes it. If the file is not passed as an argument, the PE loader parses the specified command line to extract the file’s name. It searches for that filename in the C:\Windows\System32\ directory, but most importantly it retrieves the English localization MUI file associated with the target PE (stored as C:\Windows\System32\en-US\ .mui). In that case, the PE file is loaded in memory, and a few hooks are set to make sure any calls made by the loaded PE file to retrieve resource data, such as RtlLoadString or RtlFindMessage, are redirected to the .mui data. This process mirrors normal behavior of Windows when loading PEs, and reduces the risk of unexpected errors. The command line retrieved from Stdin is parsed and SparroWocky hooks the following functions, which are used to retrieve information about command line arguments, to make them point to this command line: GetCommandline[AW] __(w}getmainargs p_argc p_{w}argv The PE loader is also able to register the exception handlers of the newly loaded executable – an unusual, yet critical, addition – since it allows exceptions to be handled correctly. Finally, before calling the entry point of the loaded PE file, SparroWocky forges and inserts a fake LDR_DATA_TABLE_ENTRY structure in the doubly linked list of the PEB_LDR_DATA structure. This doubly linked list is used by Windows to keep track of loaded modules and is usually monitored by security products. Figure 7 shows a snippet of the code used to set some of its fields. This last technique shows that SparroWocky authors possess a deep understanding of the Windows PE loading mechanism and are willing to go the extra mile to camouflage the host process and confuse monitoring software. Network protocol To communicate with its C&C server, SparroWocky uses the TLS encryption protocol. Under the hood, the backdoor uses the Mbed TLS library and the only element worth mentioning is that it uses the personalization string acdbenus when initializing the deterministic random bit generator, as seen in Figure 8. Before the initial TLS handshake, a TCP connection is established with the C&C server using one of three connection modes: A connection mode of 0 means that SparroWocky uses the proxy currently configured on the machine or a direct TCP connection if no system proxy is configured. This configuration is retrieved by querying the ProxyServer registry value located under the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings. If the connection to the proxy server is not successful, SparroWocky tries to connect via mode 1, then mode 2. Connection mode 1 represents a connection via an HTTP proxy. This connection uses either the Negotiate (Kerberos or NTLM) or Basic authentication scheme with the username and password provided in the configuration. Both authentication methods use generic HTTP headers with the User-Agent string set to Mozilla/5.0. Connection mode 2 uses a SOCKS5 proxy without authentication (AUTH field set to 0x00) or with a username and password (AUTH field set to 0x02). The values used by the latter are provided in the configuration. Command messages Once the TLS handshake is complete, SparroWocky sends the bytes 0x11223344 (big-endian) to indicate that it is ready to receive commands in the main session. The backdoor uses a simple format to receive commands and send results, as illustrated in Figure 9. If the command_arg_size field does not equal 0, then additional data is to be received or sent after the header. In that case, the data (command arguments or results) is encrypted via RC4, and each command message uses a newly generated eight-byte key, which is sent in the header. Network infrastructure SparroWocky uses the IP address of its C&C servers, which is generally running on port 443, to connect directly. We have also seen it running on port 8080 in some cases. While we have observed some self-signed certificates being reused across multiple servers, we do not have a reliable generic fingerprint. Conclusion Over the latter half of 2025 and the first half of 2026, FamousSparrow had been focusing on targets in Latin America. This represents a shift from its previous global targeting. To go along with this change, the group has developed SparroWocky, which replaced SparrowDoor as its main implant. While it doesn’t appear to be based on the same codebase, we can see that SparroWocky still shares some of the functionality and concepts that were present in the group’s previous backdoor, which we analyzed in our previous blogpost. SparroWocky uses more complex defense evasion techniques to stay under the radar. FamousSparrow still uses open-source offensive tooling for its own malicious ends. Previously, these tools were mainly used side by side with the group’s backdoor. With SparroWocky, we can observe that it also has the development capabilities to integrate open-source code directly into its own custom backdoor. IoCs A comprehensive list of indicators of compromise (IoCs) and samples can be found in our GitHub repository. Files Network MITRE ATT&CK techniques This table was built using version 19 of the MITRE ATT&CK framework.

Enterprises in Russia have emerged as the target of three threat activity clusters tracked as NightEagle, Hacking Cat, and Toy Ghouls, according to multiple reports from Kaspersky. The cybersecurity vendor said it has identified attacks mounted by NightEagle (aka APT-Q-95), a threat actor known to be active since at least 2023, that involve new techniques for persistence and lateral movement.

Over the past year, our Global Emergency Response Team (GERT) has investigated several incidents involving the NightEagle group (APT-Q-95). This group has been active since at least 2023 and originally focused on organizations in Asia. We have now identified attacks by the group targeting businesses in Russia. This post examines both known and new tools NightEagle used in its latest campaign. Initial access In most incidents, the attackers used compromised valid credentials to gain access to corporate VPNs. VPN connections originated from IP addresses in the Russian segment linked to Cloudflare WARP tunnels, as well as from IP addresses associated with European virtual infrastructure providers. GhostContainer on Microsoft Exchange Both during the initial access stage and as the attack progressed, the attackers deployed the GhostContainer backdoor on Microsoft Exchange servers. It incorporates components from several open-source projects, including the Neo-reGeorg tunnel, an exploit for the CVE-2020-0688 vulnerability, and the GhostWebShell class from the ysoserial utility. All of these components are publicly available on GitHub. We were unable to determine the exact method the attackers used to deliver the backdoor to Microsoft Exchange servers. We believe with a high degree of confidence that they applied a technique already familiar to us : extracting the cryptographic keys used by Microsoft Exchange from the ASP.NET configuration, overwriting the VIEWSTATE framework parameter, and injecting a payload into it, which then launched the GhostContainer backdoor in memory. The backdoor is a .NET assembly containing three classes that implement its core functionality: Stub : processes C2 commands delivered to the infected system through the x-owa-urlpostdata headers and evades detection by the Antimalware Scan Interface (AMSI) and Windows Event Log mechanisms by overwriting addresses in amsi.dll and ntdll.dll . App_Web_843e75cf5b63 : accepts the fakePath and fakePageName parameters and creates virtual paths that redirect requests to the App_Web_8c9b251fb5b3 class. App_Web_8c9b251fb5b3 : implements network traffic redirection (proxying) and socket forwarding functionality. Kaspersky products detect the GhostContainer backdoor as Trojan.MSIL.GhostContainer.gen. GhostContainer samples identified by the Similarity technology from Kaspersky Threat Analysis Traffic redirection Once the attackers gain sufficient privileges during an attack, they leverage RDP to move laterally within the internal network segment. To do this, they download and run tools for tunneling and redirecting network traffic. The attackers used GitHub repositories to host their archived tools. The names of the repositories and archives were disguised to look legitimate: https://github[.]com/mirror-js/mirror-js/refs/heads/main/js/js-webpack.zip https://github[.]com/mirror-js/mirror-js/refs/heads/main/js/jsonp-pack.zip https://github[.]com/browserthemes/resourcepack/releases/download/main/resource-pack.zip One of the repositories used for storing network tools The files contained within the archives were also given names mimicking known legitimate software, though unrelated to the archive names: adobe_32.exe ; AdobeSync.exe ; trueconf.exe ; 1cbroker.exe ; 1c-office-plugin.exe ; trueconf-broker.exe . Across the incidents we investigated, we found two tools that the attackers combined for traffic tunneling. Microsoft dev tunnels This is a legitimate Microsoft mechanism that allows local web services to be published for internet access on *.*.devtunnels.ms domains. The attackers used this tunneling capability to expose port 3389 (RDP) on the compromised system. Execution graph of adobe_32.exe in Kaspersky Research Sandbox rdp2tcp This is a publicly available tool for tunneling TCP traffic over an established RDP connection. It includes a server component that runs on the target system and a client component that runs on the attacker’s side. When virtual channels are opened and closed, corresponding events with IDs 132 (channel opened) and 148 (channel closed) are logged in the Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational.evtx Windows log. These events contain the names of the channels (such as XPSRD, cliprdr, Microsoft::Windows::RDS::DisplayControl, and others) used by the RemoteFX module, which extends the capabilities of the RDP protocol. When the rdp2tcp tool is used, events with IDs 132 and 148 will contain the channel name rdp2tcp or other random alphanumeric combinations chosen by the attackers. Creation event for a channel named rdp2tcp (server component startup) The combination of Microsoft dev tunnels and rdp2tcp allows the attackers to maintain network access by using legitimate services without opening additional suspicious ports. The attackers also used the atexec utility from the Impacket toolkit to create scheduled tasks on target systems. These tasks enabled network port forwarding through standard Windows functionality: netsh interface portproxy add v4tov4 listenport=443 connectaddress=10.0.12.101 connectport=445 Lateral movement To obtain elevated privileges and move laterally through the network, NightEagle exploited various vulnerabilities in Active Directory. The attackers used previously established tunnels to connect to internal infrastructure systems. In one incident, they exploited a well-known RDP implementation vulnerability, CVE-2019-0708 (BlueKeep). They used the vulnerable mechanism to create a local account on the system and add it to the Administrators and Remote Desktop Users groups. Contents of a system memory dump showing artifacts of the CVE-2019-0708 exploit The attackers also requested Kerberos tickets with a non-standard combination of flags ( Forwardable , Proxiable , Renewable ) and attempted to replicate the Domain-Password object from the Active Directory database to impersonate the domain controller (a technique known as DCSync) after obtaining an account with sufficient privileges. Through these methods, the attackers establish persistence in the infrastructure, obtain password hashes for domain accounts, use long-lived Kerberos tickets to gain legitimate access to target resources, and ultimately compromise domain controllers and the victim’s entire Active Directory infrastructure. Takeaways To expand the geographic scope of its targets, NightEagle is updating its methods and adopting new techniques for persistence and lateral movement. Despite the group’s efforts to stay hidden, timely detection of anomalies combined with a comprehensive approach to infrastructure protection can significantly hinder the attackers from achieving their goals. Since the attackers rely on known legitimate tools and infrastructure vulnerabilities, well-configured monitoring can help detect NightEagle’s presence on the network. Detection by Kaspersky solutions Kaspersky solutions reliably identify the malicious activity described above at various stages of the attack. We showed examples above of how Kaspersky Threat Analysis detects samples of the GhostContainer backdoor and the tunneling utility. This toolkit also includes the analytical solution Kaspersky Threat Attribution Engine (KTAE), which helps SOC analysts and incident responders determine which APT groups malware can be attributed to. The solution uses a proprietary comparison method that measures the similarity between analyzed samples of suspicious files and known malicious samples in Kaspersky’s collection. The backdoor we discovered showed similarity to previously analyzed GhostContainer samples and a connection to the NightEagle APT group: Backdoor analysis with KTAE However, detection scenarios for this kind of attacks are not limited to file analysis. Deploying a backdoor on a target host produces numerous characteristic artifacts, which allow Kaspersky Endpoint Detection and Response Expert to alert users to anomalies in the infrastructure in a timely manner. This malicious activity is detected by the following rules, available in the repository: Initial detection of the malicious signature occurs through the generic_ransomware_related_detection rule, based on EPP module events Detection of a malicious DLL’s .NET assembly being loaded via PowerShell: suspicious_assembly_loading_into_powershell_via_reflection Activity of tunneling and traffic redirection tools: detection_of_access_to_tunnel_domains_dns Use of tools from the Impacket toolkit, such as atexec: impacket_possible_activity attempt_to_download_hacktool_or_risktool_by_non_browser credentials_dumping_tools_file_artifacts_creation Attempts to replicate an Active Directory database object to impersonate a domain controller: potential_dcsync_via_startupparameters Process tree in KEDR Expert Kaspersky Anti Targeted Attack (KATA) detects this malicious activity in network traffic. For example, the Exploit.CVE-2019-0708.TCP.C&C signature allows detecting attempts to exploit the CVE-2019-0708 (BlueKeep) vulnerability. Alert card for the BlueKeep vulnerability exploitation Beyond this activity, KATA also detects other NightEagle actions in network traffic, such as the following: Traffic redirection and tunneling variations Attacks on Active Directory (DCSync, attempts to compromise AD CS, and others) Lateral movement across the network Indicators of compromise 1dcafb7f8448683281106b06dd22409a AdobeSync.exe 1f3034b706c78b35d8e34044e68c693a adobe_32.exe 3ecd1cd627d0340c92901a478a7caad8 631fb131a56caf4ca0f287ed73e876ab App_Web_Container_1.dll 4aa9fb1bf9223dfcdac920759bc7a3c7 1c-office-plugin.exe, 1cbroker.exe, trueconf.exe https://github[.]com/mirror-js/mirror-js https://github[.]com/browserthemes/resourcepack