{ "id": "aab9ee77-e684-44d2-9b03-10f74b9691c3", "created_at": "2026-04-06T00:06:46.644283Z", "updated_at": "2026-04-10T03:32:20.943475Z", "deleted_at": null, "sha1_hash": "940ae1c4489d0e00e8de1f4936ca96e48e03a355", "title": "I am HDRoot! Part 1", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 329700, "plain_text": "I am HDRoot! Part 1\r\nBy Dmitry Tarakanov\r\nPublished: 2015-10-06 · Archived: 2026-04-05 20:11:18 UTC\r\nSome time ago while tracking Winnti group activity we came across an intriguing sample.\r\nMD5 Size Linker Compiled on\r\n2C85404FE7D1891FD41FCEE4C92AD305 241’904 10.00 2012-08-06 16:12:29\r\nProperty Value\r\nCompanyName Microsoft Corporation\r\nFileDescription Net Command\r\nFileVersion 6.1.7600.16385 (win7_rtm.090713-1255)\r\nInternalName net.exe\r\nLegalCopyright © Microsoft Corporation. All rights reserved.\r\nOriginalFilename net.exe\r\nProductName Microsoft® Windows® Operating System\r\nIt was protected by a commercial VMProtect Win64 executable signed with a known compromised certificate\r\nfrom Chinese entity Guangzhou YuanLuo Technology. Moreover, the properties of the executable read as if it were\r\nMicrosoft’s Net Command net.exe, and even running the sample also resulted in output typical of the original\r\nnet.exe utility:\r\nMasquerading as net.exe\r\nAll this pointed to the sample being rather suspicious.\r\nBootkit\r\nSince the code of the program was protected, an analysis of its functionality would have been an arduous task. But\r\nluckily a dump revealed some unique and quite important strings and four more samples hidden inside the initial\r\none: Win32 and Win64 versions of one library and one driver:\r\nhttps://securelist.com/i-am-hdroot-part-1/72275/\r\nPage 1 of 10\n\nStrings in malware body\r\nThe strings led us to suspect that this sample was actually a bootkit installer. And thanks to some clear artifacts we\r\nfound a similar sample but with no code protection that confirmed our suspicions.\r\nFirst of all, let’s run this tool:\r\nhttps://securelist.com/i-am-hdroot-part-1/72275/\r\nPage 2 of 10\n\nOriginal HDD Rootkit output\r\nThe program parameters are quite self-explanatory – this tool installs a bootkit that infects the operating system\r\nduring the boot stage with an arbitrary backdoor specified as a parameter. The backdoor has to be a Win32\r\nexecutable or dynamic link library.\r\nThis utility is called “HDD Rootkit”; hence the base of our verdict names HDRoot. On 22 August 2006 the\r\nversion number was 1.2.\r\nSo, we can conclude that the protected version was the same utility modified for use on the victim side to avoid\r\nrevealing the intent of the tool in case someone outside the intruders’ circle discovered it.\r\nHDD Rootkit maintains a bunch of resources that also have quite telling names:\r\nHDD Rootkit resources\r\nAs it reads:\r\n“MBR” maintains the 1st piece of malicious code that is injected to the MBR of an infected computer;\r\n“BOOT” – 2nd piece of malicious booting code;\r\n“RKIMAGE” – 3rd piece of malicious booting code;\r\n“DLLLOAD” – Dynamic Link Library that is pushed by the malicious booting code into the file system and OS\r\nautorun.\r\nLet’s try running some executable with the help of a bootkit. In our experiment the role of the executable is played\r\nby a benign program that does nothing apart from create a file in the root of the C: drive. I will try to run it using\r\nthe HDD Rootkit utility with the following command line:\r\nhdroot.exe inst write_to_c.exe c:\r\ntelling it that I’d like to install a bootkit on drive C: that will make the program write_to_c.exe run on system\r\nstartup.\r\nhttps://securelist.com/i-am-hdroot-part-1/72275/\r\nPage 3 of 10\n\nLive installing of HDRoot bootkit\r\nThe utility checks the free space left on the specified drive and refuses to install the bootkit when the value is less\r\nthan 30% of overall volume.\r\nFree space check\r\nSo, now the bootkit has been installed. Let’s take a look at what has happened. First of all, part of the code in the\r\nMBR is replaced with a malicious one from the resource “MBR”:\r\nhttps://securelist.com/i-am-hdroot-part-1/72275/\r\nPage 4 of 10\n\n“MBR” resource\r\nThe first 2 bytes EB 70 mean a jump to the 72nd offset where the rest of the 1st booting code block is located. The\r\nzeros before 0x70 and after 0xB0 mean the code of the original MBR at these positions remains intact. The\r\nfollowing image represents a patched MBR after the bootkit is installed:\r\nhttps://securelist.com/i-am-hdroot-part-1/72275/\r\nPage 5 of 10\n\nInjected malicious code in MBR\r\nThis first piece loads the next booting code block that has been placed by the bootkit installer in the 11th sector\r\n(Offset: 0x1400 bytes). The 2nd block is taken from the resource “BOOT”.\r\n2nd booting block\r\nThe byte at 8th offset of the 2nd booting block is a drive number and the next DWORD is an offset in sectors\r\nwhere the next booting part is located. This example has the value 0x80, meaning drive 0 and the offset\r\nhttps://securelist.com/i-am-hdroot-part-1/72275/\r\nPage 6 of 10\n\n0x5FD9A0, which if multiplied by 0x200 bytes (size of sector) results in 0xBFB34000. This is the offset in bytes\r\nfrom the beginning of the drive where the bootkit installer has put the 3rd booting block taken from its resource\r\n“RKIMAGE”.\r\nThe “RKIMAGE” resource has a large piece of code that implements a DLL injection (the DLL is taken from the\r\n“DLLLOAD” resource) into the file system and makes changes in the system registry so that DLL is loaded and\r\nrun during system start-up. As that piece of code is executed at the early booting stage, there is no API for\r\naccessing the file system and the code parses the file systems (FAT32 and NTFS) on its own.\r\nSupported file systems\r\nIt searches for the hardcoded special file whose content is replaced with the DLL taken from a specified place on\r\nthe disk. Most versions of HDRoot that we have found and detected use the file %windir%\\WMSysPr9.prx for\r\nthese purposes. Sometimes the DLL overwrites some existing system library which is certainly not a safe way for\r\nmalware to work because it could cause OS failure in some cases and alert the user to the infection. Among other\r\nfiles that can be used for overwriting we have noticed:\r\n%windir%\\twain.dll\r\n%windir%\\msvidc32.dll\r\n%windir%\\help\\access.hlp\r\n%windir%\\help\\winssnap.hlp\r\n%windir%\\system\\olesvr.dll\r\n%windir%\\syswow64\\C_932.NLS\r\n%windir%\\syswow64\\C_20949.NLS\r\n%windir%\\syswow64\\dssec.dat\r\n%windir%\\syswow64\\irclass.dll\r\n%windir%\\syswow64\\msvidc32.dll\r\n%windir%\\syswow64\\kmddsp.tsp\r\nThe code then reads the content of the file %windir%\\system32\\config\\system that maintains the content of the\r\nHKEY_LOCAL_MACHINE\\SYSTEM registry hive. Among other things the registry hive contains information\r\nabout installed services. There are numerous system services that are started during OS logon as ServiceDll via\r\nsvchost.exe where the path to the functional library to be run is specified in the ServiceDll registry value for a\r\nparticular service. The malicious booting code searches in the file “system” for the hardcoded path to a system\r\nlibrary associated with a system service and replaces that value with the path to the injected DLL (for example,\r\n%windir%\\WMSysPr9.prx). In all the versions we encountered we found that HDRoot exploited the following\r\nservices:\r\nInternal service name Displayed service name Path to search for\r\nhttps://securelist.com/i-am-hdroot-part-1/72275/\r\nPage 7 of 10\n\nwuauserv Automatic Updates system32\\wuauserv.dll\r\nLanManServer Server system32\\srvsvc.dll\r\nschedule Task Scheduler system32\\schedsvc.dll\r\nwinmgmt Windows Management Instrumentation system32\\wbem\\wmisvc.dll\r\nSo, when the operating system starts running services, instead of loading the original service DLL svchost.exe\r\nloads a malicious one. This malicious library does nothing apart from load and run a backdoor taken from a\r\nspecified offset on the hard drive where the bootkit installer HDD Rootkit had placed it. We have found two\r\nversions of HDRoot with different methods of doing this. The first one just saves the backdoor as a file\r\n%windir%\\temp\\svchost.exe and executes it with the help of the WinExec API function. By all appearances the\r\nmalware author later decided that this approach is not the best way to run the backdoor because it is visible to AV\r\nproducts and the fact that the application has started may be noticed when inspecting events in the system logs.\r\nThe other version of the DLL does not drop the file but allocates a read backdoor in memory, prepares it for\r\nproper execution (loads libraries according to the import table and fixes relocations) and runs it there on its own.\r\nThis approach is much more clandestine as it substantially reduces the chances of discovering the backdoor even\r\nif the DLL or poisoned MBR are detected.\r\nReturning to our experiment, when the command\r\nhdroot.exe inst write_to_c.exe c:\r\nhas been run, we restart the operating system. After the OS has loaded we can see the result of running of our\r\nprogram write_to_c.exe, which behaves as though it were a backdoor:\r\nCreated test file zzz.bin\r\nThe file C:\\zzz.bin is seen immediately after Windows has loaded, which proves that the program write_to_c.exe\r\nhas been successfully executed.\r\nThe whole process of the HDRoot infection is as follows:\r\nhttps://securelist.com/i-am-hdroot-part-1/72275/\r\nPage 8 of 10\n\nHDRoot operation scheme\r\nInterestingly, the malware does not have functionality to start the original service that was substituted during the\r\nboot process. Because the affected services are part of the OS, neglecting to do this could cause Windows to\r\nmalfunction and reveal the infection. This is even stranger considering the malware does try to cover its tracks.\r\nNamely “tries”, because it fails to do so. The dropped DLL has a function to restore the original value of\r\nServiceDll in the registry, storing the path to the DLL associated with the service. But due to flawed code in the\r\n3rd booting block (from “RKIMAGE”), which slightly patches the content of “DLLLOAD” before injecting, DLL\r\nstarts holding the wrong data at hardcoded offsets and it prevents the DLL from finding the proper registry path to\r\nServiceDll to restore the original value. That’s why, for example, “C:\\WINDOWS\\WMSysPr9.prx” can still be\r\nviewed instead of “C:\\WINDOWS\\system32\\wuauserv.dll” after logging on to Windows:\r\nPath remains to injected malicious DLL in registry\r\nhttps://securelist.com/i-am-hdroot-part-1/72275/\r\nPage 9 of 10\n\nWrong registry path and value name\r\nMistakenly overwritten registry SubKey with original value of ServiceDll\r\nAs a result, we have to conclude that the malware was not created very carefully, which is not what you expect\r\nfrom such a serious APT actor as Winnti. However, we have noticed the malware author’s efforts to make this\r\nbootkit work properly at the booting stage to avoid completely blocking the OS from loading. But the mistakes\r\nmentioned above leave some quite conspicuous signs of infection on the compromised computer. For example,\r\noriginal services such as Windows Update or Task Scheduler do not work, but it appears nobody noticed them.\r\nDuring the investigation we found several backdoors that the HDRoot bootkit used for infecting operating\r\nsystems. These malicious programs will be described in the next part of our article.\r\nSource: https://securelist.com/i-am-hdroot-part-1/72275/\r\nhttps://securelist.com/i-am-hdroot-part-1/72275/\r\nPage 10 of 10", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia", "ETDA" ], "references": [ "https://securelist.com/i-am-hdroot-part-1/72275/" ], "report_names": [ "72275" ], "threat_actors": [ { "id": "5bbced13-72f7-40dc-8c41-dcce75bf885e", "created_at": "2022-10-25T15:50:23.695735Z", "updated_at": "2026-04-10T02:00:05.335976Z", "deleted_at": null, "main_name": "Winnti Group", "aliases": [ "Winnti Group" ], "source_name": "MITRE:Winnti Group", "tools": [ "PipeMon", "Winnti for Windows", "PlugX" ], "source_id": "MITRE", "reports": null }, { "id": "4d5f939b-aea9-4a0e-8bff-003079a261ea", "created_at": "2023-01-06T13:46:39.04841Z", "updated_at": "2026-04-10T02:00:03.196806Z", "deleted_at": null, "main_name": "APT41", "aliases": [ "WICKED PANDA", "BRONZE EXPORT", "Brass Typhoon", "TG-2633", "Leopard Typhoon", "G0096", "Grayfly", "BARIUM", "BRONZE ATLAS", "Red Kelpie", "G0044", "Earth Baku", "TA415", "WICKED SPIDER", "HOODOO", "Winnti", "Double Dragon" ], "source_name": "MISPGALAXY:APT41", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "945a572f-ebe3-4e2f-a288-512fe751cfa8", "created_at": "2022-10-25T16:07:24.413971Z", "updated_at": "2026-04-10T02:00:04.97924Z", "deleted_at": null, "main_name": "Winnti Group", "aliases": [ "G0044", "Leopard Typhoon", "Wicked Panda", "Winnti Group" ], "source_name": "ETDA:Winnti Group", "tools": [ "Agentemis", "BleDoor", "Cobalt Strike", "CobaltStrike", "FunnySwitch", "RbDoor", "RibDoor", "RouterGod", "Winnti", "cobeacon" ], "source_id": "ETDA", "reports": null }, { "id": "2a24d664-6a72-4b4c-9f54-1553b64c453c", "created_at": "2025-08-07T02:03:24.553048Z", "updated_at": "2026-04-10T02:00:03.787296Z", "deleted_at": null, "main_name": "BRONZE ATLAS", "aliases": [ "APT41 ", "BARIUM ", "Blackfly ", "Brass Typhoon", "CTG-2633", "Earth Baku ", "GREF", "Group 72 ", "Red Kelpie ", "TA415 ", "TG-2633 ", "Wicked Panda ", "Winnti" ], "source_name": "Secureworks:BRONZE ATLAS", "tools": [ "Acehash", "CCleaner v5.33 backdoor", "ChinaChopper", "Cobalt Strike", "DUSTPAN", "Dicey MSDN", "Dodgebox", "ForkPlayground", "HUC Proxy Malware (Htran)" ], "source_id": "Secureworks", "reports": null } ], "ts_created_at": 1775434006, "ts_updated_at": 1775791940, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/940ae1c4489d0e00e8de1f4936ca96e48e03a355.pdf", "text": "https://archive.orkl.eu/940ae1c4489d0e00e8de1f4936ca96e48e03a355.txt", "img": "https://archive.orkl.eu/940ae1c4489d0e00e8de1f4936ca96e48e03a355.jpg" } }