## En Route with #### Part 3: A Mysterious Downloader ###### Version 1.0 • October 2016 ----- # En Route with Sednit #### Part 3: A Mysterious Downloader ###### Version 1.0 • October 2016 ----- ##### Table of Content **Executive Summary** **5** **Introduction** **6** The Sednit Group 6 The Third Part of the Trilogy 7 Attribution 8 Publication Strategy 8 **Downdelph** **9** Identikit 9 Timeline 10 Deployment 11 Core Behavior 12 Persistence Mechanisms 15 **Conclusion and Open Questions** **24** **Indicators of Compromise** **25** Downdelph 25 **References** **26** ----- ##### List of Tables Table 1. Downdelph main configuration file extended.ini 14 Table 2. Downdelph server configuration file pinlt.ini 15 ##### List of Figures Figure 1. Timeline of 0-day vulnerabilities exploited by the Sednit group in 2015. 6 Figure 2. Main attack methods and malware used by the Sednit group since 2014, and how they are related 7 Figure 3. Downdelph major events 10 Figure 4. Downdelph deployments, with the purpose and name of each file 11 Figure 5. Decoy document used in Case 7 (September 2015) 12 Figure 6. Downdelph communication workflow 13 Figure 7. Downdelph request to download main configuration file 14 Figure 8. Beginning of infected hard drive layout 16 Figure 9. MBR opening code, as seen in a decompiler 17 Figure 10. Startup process of a Windows 7 machine infected by the bootkit 18 Figure 11. Hook code in ACPI.sys resources section (.rsrc) 19 Figure 12. User mode bootkit component attempts to set an exported Boolean variable in Downdelph, after having loaded it 20 Figure 13. Hook code for ZwSetInformationFile to hide files 22 Figure 14. Preoperation callback for IRP_MJ_CREATE (the creation or opening of files and directories) 23 Figure 15. Kernel mode APC registration, FN_ApcNormalRoutine being the shellcode address in the target process 23 ----- ### En Route with Sednit ##### Executive Summary The Sednit group — also known as APT28, Fancy Bear and Sofacy — is a group of attackers operating since 2004 if not earlier and whose main objective is to steal confidential information from specific targets. This is the third part of our whitepaper “En Route with Sednit”, which covers the Sednit group activities since 2014. Here, we describe a special downloader named Downdelph. The key points described in this third installment are the following: - Downdelph was used only seven times over the past two years, according to our telemetry data: we believe this to be a deliberate strategy formulated in order to avoid attracting attention - Downdelph has been deployed on a few occasions with a never-previously-documented Windows bootkit, which shares some code with the infamous BlackEnergy malware - Downdelph has been deployed on a few occasions with a previously undocumented Windows rootkit [For any inquiries related to this whitepaper, contact us at: threatintel@eset.com](mailto:threatintel@eset.com) ----- ### En Route with Sednit ##### Introduction _Readers who have already read the first parts of our Sednit trilogy might want to skip the following section_ _and go directly to the specific introduction of this third part._ ###### The Sednit Group The Sednit group — variously also known as APT28, Fancy Bear, Sofacy, Pawn Storm, STRONTIUM and Tsar Team — is a group of attackers operating since 2004 if not earlier, whose main objective is to steal confidential information from specific targets. Over the past two years, this group’s activity has increased significantly, with numerous attacks against government departments and embassies all over the world. Among their most notable presumed targets are the American Democratic National Committee [1], the German parliament [2] and the French television network TV5Monde [3]. Moreover, the Sednit group has a special interest in Eastern Europe, where it regularly targets individuals and organizations involved in geopolitics. One of the striking characteristics of the Sednit group is its ability to come up with brand-new 0-day [4] vulnerabilities regularly. In 2015, the group exploited no fewer than six 0-day vulnerabilities, as shown in Figure 1. **CVE-2015-3043** Flash **CVE-2015-1701** Windows LPE **CVE-2015-2590** Java **CVE-2015-4902** Java click-to-play bypass **CVE-2015-7645** Flash **APR** **MAY** **JUN** **JUL** **AUG** **SEP** **OCT** **CVE-2015-2424** Office RCE Figure 1. Timeline of 0-day vulnerabilities exploited by the Sednit group in 2015. This high number of 0-day exploits suggests significant resources available to the Sednit group, either because the group members have the skills and time to find and weaponize these vulnerabilities, or because they have the budget to purchase the exploits. Also, over the years the Sednit group has developed a large software ecosystem to perform its espionage activities. The diversity of this ecosystem is quite remarkable; it includes dozens of custom programs, with many of them being technically advanced, like the Xagent and Sedreco modular backdoors (described in the second part of this whitepaper), or the Downdelph bootkit and rootkit (described in the third part of this whitepaper). We present the results of ESET’s two-year pursuit of the Sednit group, during which we uncovered and analyzed many of their operations. We split our publication into three independent parts: 1. _“Part 1: Approaching the Target” describes the kinds of targets the Sednit group is after, and the_ methods used to attack them. It also contains a detailed analysis of the group’s most-used reconnaissance malware. 2. _“Part 2: Observing the Comings and Goings” describes the espionage toolkit deployed on some_ target computers, plus a custom network tool used to pivot within the compromised organizations. ----- ### En Route with Sednit 3. _“Part 3: A Mysterious Downloader” describes a surprising operation run by the Sednit group,_ during which a lightweight Delphi downloader was deployed with advanced persistence methods, including both a bootkit and a rootkit. Each of these parts comes with the related indicators of compromise. ###### The Third Part of the Trilogy Figure 2 shows the main components that the Sednit group has used over the last two years, with their interrelationships. It should not be considered as a complete representation of their arsenal, which also includes numerous small, custom tools. **ATTACK** **FIRST-STAGE** **SECOND-STAGE** **PIVOT** **METHODS** **MALWARE** **MALWARE** **MALWARE** **Seduploader** **Seduploader** **Sedreco** **Sedreco** **Xtunnel** dropper payload dropper payload Sedkit **Usbstealer** Email attachments **Downdelph** **Xagent** Fake webmail login panels En Route En Route En Route with Sednit with Sednit with Sednit **Part 1** **Part 3** **Part 2** Figure 2. Main attack methods and malware used by the Sednit group since 2014, and how they are related We divide Sednit’s software into three categories: the first-stage software serves for reconnaissance of a newly compromised host, then comes the second-stage software intended to spy on machines deemed interesting, while the pivot software finally allows the operators to reach other computers. In this third part, we describe the first-stage software named Downdelph, outlined in Figure 2. This software was deployed only seven times by the Sednit operators, according to our telemetry data. Interestingly, some of these deployments were made with advanced persistence methods: a Windows bootkit and a Windows rootkit. All the components shown in Figure 2 are described in this whitepaper, with the exception of Usbstealer, a tool to exfiltrate data from air-gapped machines that we have already described at WeLiveSecurity [5]. Recent versions have been documented by Kaspersky Labs [6] as well. _Readers who have already read the first parts of our Sednit trilogy may skip the following sections_ _and go directly to Downdelph’s analysis._ |Col1|Col2|Col3|Col4|Col5| |---|---|---|---|---| |||||| |||||| |||||| |||||| |||||| |Seduploader Seduploader Sedreco Sedreco Xtunnel dropper payload dropper payload Sedkit Usbstealer Email attachments Downdelph Xagent Fake webmail login panels En Route En Route En Route with Sednit with Sednit with Sednit Part 1 Part 3 Part 2|Col2| |---|---| ||| ||| **SECOND-STAGE** **MALWARE** **Sedreco** **Sedreco** dropper payload **Xagent** En Route with Sednit **Part 2** **ATTACK** **METHODS** Sedkit Email attachments Fake webmail login panels ----- ### En Route with Sednit ###### Attribution One might expect this reference whitepaper to add new information about attribution. A lot has been said to link the Sednit group to some Russian entities [7], and we do not intend to add anything to this discussion. Performing attribution in a serious, scientific manner is a hard problem that is out of scope of ESET’s mission. As security researchers, what we call “the Sednit group” is merely a set of software and the related network infrastructure, which we can hardly correlate with any specific organization. Nevertheless, our intensive investigation of the Sednit group has allowed us to collect numerous indicators of the language spoken by its developers and operators, as well as their areas of interest, as we will explain in this whitepaper. ###### Publication Strategy Before entering the core content of this whitepaper, we would like to discuss our publication strategy. Indeed, as security researchers, two questions we always find difficult to answer when we write about an espionage group are “when to publish?”, and “how to make our publication useful _to those tasked with defending against such attacks?”._ There were several detailed reports on the Sednit group published in 2014, like the Operation Pawn Storm report from Trend Micro [8] and the APT28 report from FireEye [9]. But since then the public information regarding this group has mainly came in the form of blog posts describing specific components or attacks. In other words, no public attempts have been made to present the big picture on the Sednit group since 2014. Meanwhile, the Sednit group’s activity has significantly increased, and its arsenal differs from those described in previous whitepapers. Therefore, our intention here is to provide a detailed picture of the Sednit group’s activities over the past two years. Of course, we have only partial visibility into those activities, but we believe that we possess enough information to draw a representative picture, which should in particular help defenders to handle Sednit compromises. We tried to follow a few principles in order to make our whitepaper useful to the various types of readers: - Keep it readable: while we provide detailed technical descriptions, we have tried to make them readable, without sacrificing precision. For this reason we decided to split our whitepaper into three independent parts, in order to make such a large amount of information easily digestible. We also have refrained from mixing indicators of compromise with the text. - Help the defenders: we provide indicators of compromise (IOC) to help detect current Sednit infections, and we group them in the IOC section and on ESET’s GitHub account [10]. Hence, the reader interested only in these IOCs can go straight to them, and find more context in the whitepaper afterwards. - Reference previous work: a high profile group such as Sednit is tracked by numerous entities. As with any research work, our investigation stands on the shoulders of the previous publications. We have referenced them appropriately, to the best of our knowledge. - Document also what we do not understand: we still have numerous open questions regarding Sednit, and we highlight them in our text. We hope this will encourage fellow malware researchers to help complete the puzzle. We did our best to follow these principles, but there may be cases where we missed our aim. [We encourage readers to provide feedback at threatintel@eset.com, and we will update](mailto:threatintel@eset.com) the whitepaper accordingly. ----- ### En Route with Sednit ##### Downdelph ----- ### En Route with Sednit ###### Timeline The dates presented in this timeline refer to when we believe Downdelph was deployed with a specific persistence method, possibly against several different targets, and are based on ESET’s LiveGrid® [12] telemetry data. ##### 2013 **November** ##### 2014 **February** Three Downdelph deployments. Persistence is ensured by a kernel mode rootkitkernel mode rootkit installed as a Windows service (Cases 2, 3 and 4). ##### 2015 **September** Most recently observed Downdelph deployment. Persistence is ensured by registering an auto-start entry in the Windows Registry (Case 7). ##### 2014 **March** Downdelph deployment. Persistence is ensured by a bootkitbootkit infecting the MBR of the hard drive (Case 5). ##### 2014 **May** Downdelph deployment. Persistence is ensured by registering an auto-start entry in the Windows Registry (Case 6). Figure 3. **Downdelph major events** As shown in the timeline, Downdelph operators abandoned more complex persistence methods over time, probably due to new security features introduced in Windows. ----- ### En Route with Sednit ###### Deployment As mentioned in the timeline, we were able to find only seven deployments of Downdelph. Such deployments start with a dropper, which contains Downdelph and some additional binaries, as depicted in Figure 4. **Bootkit-based** **persistence** Helper Helper (kb0004542.exe) (inst32.exe) **Case 5** **Case 1** **Dropper** (unknown name) **Rootkit-based** **persistence** **Case 2** **Dropper** (WinXP1.exe) **Case 4** **Dropper** (serviceinstall.exe) UAC bypass **Registry-based** **persistence** **Case 6** **Dropper** (fs6na.exe) UAC bypass **Dropper** (syscfg.exe) UAC bypass **Case 3** **Dropper** (serviceinstallx32.exe) UAC bypass **Case 7** **Dropper** (EU_Eastern_ Europe_agenda_ BA_3_Nov_2015.pif) Files shown in the same color serve the same purpose Figure 4. **Downdelph deployments, with the purpose and name of each file** ----- ### En Route with Sednit In Cases 3 to 6, the deployed binaries used a User Account Control (UAC) bypass technique, as mentioned in Figure 4. Two different UAC bypass techniques were employed; the first one relying on a custom “RedirectEXE” shim database [13], while the second one is based on a DLL load order hijacking of the Windows executable sysprep.exe, which possesses the property to auto-elevate its privileges [14]. In Case 7, the dropper was deployed through a targeted phishing email. We do not have any evidence of this deployment method for the other cases. In this particular case, the dropper opens a decoy document when executed, to reinforce the illusion the email was legitimate. Figure 5 shows this decoy document, an invitation to a conference organized by the Slovak Foreign Policy Association in November 2015 regarding Russia-Ukraine relations [15]. Figure 5. Decoy document used in Case 7 (September 2015) ###### Core Behavior Downdelph’s core logic is implemented in one Delphi class, named TMyDownloader by its developers, and remained the same in all samples we analyzed. Roughly summarized, Downdelph first downloads a main configuration file, which allows extending the list of C&C servers, and then fetches a payload from each of these C&C servers. ----- ### En Route with Sednit The whole process is pictured in Figure 6, and is detailed thereafter for the most recent Downdelph sample known (Case 7 in Figure 4). Downdelph Initial C&C server Additional Additional infected computer C&C server 1 C&C server 2 Fetches main configuration file (extended.ini) Download payload from initial C&C server Sends machine ID Fetches server configuration file (pinlt.ini) Downloads payload Download payload from additional C&C server 1 Sends machine ID Fetches server configuration file (pinlt.ini) Downloads payload Download payload from additional C&C server 2 Sends machine ID Fetches server configuration file (pinlt.ini) Downloads payload **[...]** Figure 6. **Downdelph communication workflow** |Col1|Fetches main configuration file (extended.ini) Download payload from initial C&C server Sends machine ID Fetches server configuration file (pinlt.ini) Downloads payload Download payload from additional C&C server 1 Sends machine ID Fetches server configuration file (pinlt.ini) Downloads payload Download payload from additional C&C server 2 Sends machine ID Fetches server configuration file (pinlt.ini) Downloads payload [...]|Col3|Col4|Col5| |---|---|---|---|---| |||||| |||||| |||||| |||||| |||||| |||||| |||||| |||||| |||||| |||||| |||||| |||||| ----- ### En Route with Sednit ###### Extend C&C servers List First, Downdelph downloads a main configuration file named extended.ini from the initial C&C server, whose address is hardcoded in the binary. The network request is an HTTP POST with a URI containing the file name to fetch encoded with a custom algorithm, as pictured in Figure 7. Figure 7. **Downdelph request to download main configuration file** The encoding algorithm was designed to make writing signatures on Downdelph network requests difficult. To do so, pseudo-randomly generated characters are inserted between each original character during the encoding, such that the same input text will be encoded differently each time. The response from the server is an RC4-encrypted configuration file following the INI format [16], and composed of a single section named [options], which contains the key-value pairs described in Table 1. Table 1. **Downdelph main configuration file extended.ini** Key Value `Servers` Comma-separated list of additional C&C server addresses (can be NULL) Defines whether server configuration files — described below — will ``` Crypt ``` be RC4-encrypted or not `Sleep` Time to wait before contacting C&C servers again `Key` Cryptographic key to replace the default key (can be NULL) If the Servers key is not empty, Downdelph adds the C&C server addresses to its list of servers to contact to download payloads. The RC4 algorithm uses by default a 50-byte hardcoded value, to which the last two bytes of the input text are appended to form the key, before decrypting. This 50-byte value is present in other Sednit components, such as Seduploader and Xagent. ----- ### En Route with Sednit ###### Payload Download For each known C&C server — the initial one and the additional ones possibly provided in extended.ini — Downdelph performs three steps leading to the download of a payload. First, it sends a machine ID, which was previously generated from the hard drive serial number. Second, it downloads a configuration file named pinlt.ini describing the payload to fetch from this particular C&C server (if any). The network request follows a format similar to the one shown in Figure 7. The possible key-value pairs of the received file are described in Table 2. Table 2. **Downdelph server configuration file pinlt.ini** Key Value Time to wait before contacting C&C servers again (if present, overrides ``` Sleep ``` value provided in extended.ini) `Crypt` Defines whether or not the payload will be RC4-encrypted Cryptographic key to replace the default key (if present, overrides value provided ``` Key ``` in extended.ini) `FileName` Name of the payload to fetch Location in which to save the payload on the local machine, or alternatively ``` PathToSave shell to indicate the payload is a shellcode to execute in memory ``` `Execute` Defines whether the payload will be executed, or simply dropped on the machine `RunApp` Command line to run the payload (for example rundll32.exe for a DLL payload) `Parameters` Parameters to pass to the payload Defines whether or not the payload will be deleted from the local machine ``` Delete ``` after being executed `DelSec` Time to wait before trying to delete the file Finally, if the previous configuration file is non-empty, Downdelph downloads a payload from this C&C server, and processes it according to the configuration. Once all C&C servers have been contacted, Downdelph sleeps for a certain amount of time (defined by the Sleep key in its configuration), and then re-starts the whole workflow from the beginning, including downloading the main configuration file from the initial C&C server. We do not have in-the-wild examples of Downdelph configuration files. Nevertheless, we know that in a few cases this component eventually downloaded Sedreco and Xagent. ###### Persistence Mechanisms In most of the deployments we analyzed, Downdelph was dropped with a companion binary taking charge of its persistence, as pictured in Figure 4. This section describes the two most interesting persistence methods employed, respectively with a bootkit and a rootkit, leaving aside the classic and more common Windows Registry modification methods. ----- ### En Route with Sednit ###### Bootkit Interestingly, we observed Downdelph deployment with a bootkit on two occasions, Cases 1 and 5 in Figure 4. As defined in ESET’s VirusRadar® [17], a bootkit is “A type of rootkit that infects the Master _Boot Record or Volume Boot Record (VBR) on a hard disk drive in order to ensure that its code will be run_ _each time the computer boots. […​]”._ In recent years, bootkits have become popular as a way to load unsigned malicious Windows drivers, which is normally prevented by the OS in 64-bit versions of Windows. But in the present case the bootkit serves as a stealthy persistence method for the user-mode downloader Downdelph — although for this purpose an unsigned driver will indeed be loaded, as we will describe later. Persistence through a bootkit makes detection harder, as its code is executed before the operating system is fully loaded. The bootkit in question has the ability to infect Microsoft Windows versions from Windows XP to Windows 7, on both 32-bit and 64-bit architectures. To the best of our knowledge the bootkit used by Downdelph has never been documented, even though it belongs to the well-known category of bootkits infecting the Master Boot Record (MBR) — first sector of the hard drive — to take control of the startup process. We will now describe the various components installed on the machine during the infection by the bootkit, and then how those components cooperate during startup to eventually execute Downdelph. Installation Process The bootkit installation process varies depending on the Windows version, and whether the machine is 32-bit or 64-bit. In all cases the bootkit installer starts by overwriting the hard drive’s first sectors — a sector being the basic hard drive storage unit, resulting in a new hard drive layout as shown in Figure 8 and described in the following. **Sector 1** **Sector 2** **Sector 3** Bootkit MBR Original MBR (XOR-encrypted) Bootkit Code (XOR-encrypted) Bootkit Driver (XOR-encrypted, RC4-encrypted) Legitimate data Figure 8. Beginning of infected hard drive layout First things first: the MBR is overwritten with a custom version, while an encrypted copy of the original MBR code is stored in the second sector. Starting in the third sector comes the core bootkit code, encrypted with a simple XOR-based algorithm. This core code will be slightly different depending on the operating system versions, as the hooks — described later — put in place at startup will vary. Finally comes an RC4-encrypted Windows driver, which depending on the architecture will be a 32-bit or 64-bit binary. ----- ### En Route with Sednit In order to access the first sectors of the hard drive, the installer employs a technique previously seen in the infamous TDL4 bootkit [18], whose code is shown in Figure 9. Figure 9. MBR opening code, as seen in a decompiler Once this device access is established, the installer simply calls the Windows API function WriteFile to overwrite the hard drive’s first sectors. It should be noted that this method requires administrative rights on the system. Second, the installer stores a DLL in the newly created Windows Registry key HKLM\SYSTEM\ ``` CurrentControlSet\Control\Lsa\Core Packages. As we will explain later, this binary ``` is the user mode component of the bootkit. Additionally, Downdelph itself is stored in the same registry path, but in the key named Impersonation Packages. These two files are stored in Windows’ Registry following a custom-encrypted data format that is also used for the bootkit code initially contained in the installer. More precisely, the data are aPLib-compressed [19], then RC4-encrypted, and begin with the following header: ``` struct PackedChunkHeader { DWORD magic; // set to `0x203a3320` (` :3 ` in ASCII) DWORD packed_size; DWORD unpacked_size; DWORD key_size; BYTE rc4_key[16]; }; ``` The magic 4-byte value “ :3 “ is also written by the bootkit installer at offset ``` 0x19B of the MBR, as a marker to indicate that the hard drive has already ``` been infected in the event that the installer is re-executed. ----- ### En Route with Sednit ###### Startup Process Once installed, the bootkit takes control of the machine during the next system startup. The startup process is detailed in Figure 10 for Windows 7, where only the steps involving the bootkit are shown. **Bootkit MBR** **Original MBR** **CPU in real mode** **CPU in** **protected** **mode** Loads Downdelph in ``` explorer.exe process ``` Figure 10. Startup process of a Windows 7 machine infected by the bootkit Roughly summarized, a bootkit’s objective is to “survive” Windows’ startup and eventually to execute a payload once the operating system is fully running. Such survival is made difficult by the strong modifications of the machine state at each step of the startup process (for example by reorganizing memory or switching the CPU mode). Hence, starting from the initially infected MBR, the bootkit ensures at each step that it will regain control at the next step, mainly by setting hooks. While the bootkit workflow described in Figure 10 bears some similarities with other known MBRinfected bootkits (see “Bootkits: Past, Present & Future” [20] for some examples), there are certain particularities that we would like to point out: - The bootkit MBR decrypts the bootkit code and the bootkit driver initially stored from the third sector (see Figure 8) into a memory buffer. On the system we used for analysis, the buffer was located at physical memory address 0x97C00. This memory area therefore contains the bulk of the bootkit code, and the hooks in bootmgr, winload.exe and ACPI. ``` sys re-route the execution flow to this buffer. It is more common for bootkits to copy ``` their code at each step into a new memory area, in order to survive memory re-organization during startup. ----- ### En Route with Sednit - This is the first use of the genuine Windows driver ACPI.sys in a bootkit, to the best of our knowledge. More precisely, the entry-point of this driver is patched to redirect to a small snippet of code written in its resources section, as shown in Figure 11. Figure 11. Hook code in ACPI.sys resources section (.rsrc) This code receives as an input parameter the memory address of the Windows kernel ntoskrnl. ``` exe, where the bootkit stores some crucial data in unused PE header fields. Using these data, ``` it first restores the first five bytes of the original ACPI.sys entry-point, and then redirects to bootkit code stored at physical memory address 0x97C00, mapped in the virtual memory space using the Windows API MmMapIoSpace _[21]. This bootkit code will decrypt and execute the bootkit driver._ The modifications to the ACPI.sys driver bypass Windows’ bootloader integrity checks, because those checks are done on the hard-drive version of the file, not on the in-memory version. ----- ### En Route with Sednit - The bootkit driver injects the bootkit user-mode component into the explorer.exe process by patching its entry-point before it is executed. The user mode component then loads Downdelph and, interestingly, it tries to set an exported global Boolean variable named ``` m_bLoadedByBootkit in Downdelph to TRUE, as shown in Figure 12. ``` Figure 12. User mode bootkit component attempts to set an exported Boolean variable in Downdelph, after having loaded it As this global variable is absent in all Downdelph binaries, we speculate that the bootkit was originally intended to be used with a different payload, and was repurposed by Sednit’s operators. Moreover, the user-mode component of the bootkit exports two functions named Entry and ep_data. Those two export names are also present in early samples of the infamous BlackEnergy malware [11]. Also, we found several cases of code sharing between the bootkit components and the same BlackEnergy samples. These hints lead us to speculate that the developers may be related. ###### Kernel Mode Rootkit Another interesting Downdelph persistence method we analyzed relies on a Windows driver, used during deployments in February 2014. Once loaded at startup as a Windows service, this driver executes and hides Downdelph, effectively acting as a rootkit [22]. We were able to dig up only four samples of this rootkit: three 32-bit versions, corresponding to Cases 2, 3 and 4 in Figure 3, and an additional 64-bit version for which we do not have any context. Roughly summarized, the rootkit hides certain operating system artifacts (files, registry keys, folders) whose location matches a rule in a set of so-called Hide rules. Those rules are set by the dropper and stored in the Windows Registry, making the rootkit a flexible tool able to hide any given artifacts. Interestingly, numerous debug messages were left by the developers in the rootkit, which allow those Hide rules in particular to be clearly seen. For example, here are the rules used with one sample, as output in debug logs during execution: ``` HIDEDRV: >>>>>>>>Hide rules>>>>>>>> rules HIDEDRV: File rules: \Device\HarddiskVolume1\Windows\system32\mypathcom\dnscli1.dll HIDEDRV: File rules: \Device\HarddiskVolume1\Windows\system32\drivers\FsFlt.sys HIDEDRV: Registry rules: \REGISTRY\MACHINE\SYSTEM\ControlSet002\services\FsFlt HIDEDRV: Registry rules: \REGISTRY\MACHINE\SYSTEM\ControlSet001\services\FsFlt HIDEDRV: Registry rules: \REGISTRY\MACHINE\SYSTEM\CurrentControlSet\services\FsFlt HIDEDRV: Inject dll: C:\Windows\system32\mypathcom\dnscli1.dll HIDEDRV: Folder rules: \Device\HarddiskVolume1\Windows\system32\mypathcom HIDEDRV: <<<<<<<