{ "id": "b702e56b-af60-4188-a670-245be46172af", "created_at": "2026-04-06T02:11:23.010768Z", "updated_at": "2026-04-10T03:24:29.195082Z", "deleted_at": null, "sha1_hash": "2b0ef76af26b04058ee881fbc9326eacc1236b2a", "title": "Rovnix bootkit framework updated", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 302813, "plain_text": "Rovnix bootkit framework updated\r\nBy Aleksandr Matrosov\r\nArchived: 2026-04-06 01:34:07 UTC\r\nChanges in the threatscape as regards exploitation of 64-bit systems, exemplified by the latest modifications to the\r\nRovnix bootkit.\r\n13 Jul 2012  •  , 6 min. read\r\nWe have been tracking the activity of the Rovnix bootkit family since April 2011. Rovnix was the first bootkit\r\nfamily to use VBR (Volume Boot Record) infection (NTFS bootstrap code) for loading unsigned kernel-mode\r\ndrivers on x64 (64 bit) platforms. The reason for exploring further is the desire of the Rovnix developers to bypass\r\nantivirus detection. The payload of the first samples in the wild blocked internet connection for Russian users and\r\nforced them to send an SMS to a premium number in order to get their connection unblocked (Hasta La Vista,\r\nBootkit: Exploiting the VBR).\r\nThese variants with the internet blocking payload stopped using the bootkit component during the summer of\r\n2011. At that time the Rovnix framework was sold to Carberp developers responsible for the botnet\r\nHodprot/Origami (Evolution of Win32Carberp: going deeper). The Carberp developers used droppers\r\nincorporating bootkit framework only up to the end of 2011. We don't have information about other sales of the\r\nRovnix bootkit framework. But we only have information relating to a really small percentage of infections with\r\nRovnix based bootkit code. A few days ago we got some interesting samples and quick analysis revealed similar\r\nVBR modifications to the Rovnix.B family. After unpacking the dropper we found a typical component for\r\nproviding the next steps for   installation of the Rovnix bootkit's BkSetup.dll module. The compilation timestamp\r\nof BkSetup.dll module looks fresh and is dated 24/06/2012: certainly it's possible to fake a timestamp, but up to\r\nnow developers had not changed the date on BkSetup.dll).\r\nThere is also a version information structure to be found in the resource section of BkSetup.dll filled as follows:\r\nhttps://www.welivesecurity.com/2012/07/13/rovnix-bootkit-framework-updated/\r\nPage 1 of 7\n\nThe file version has been changed to 2.4: previously, Carberp used version 2.1 of BkSetup.dll and stored the\r\ninformation in the debug string sent to the C\u0026C as debugging information.\r\nThe base functionality of BkSetup.dll is centred on the process of infection and setting up the hidden storage\r\npartition. A call graph of the main BkSetup.dll routines looks like this:\r\nA new sample with a new version of the Rovnix bootkit framework is indirect evidence of renewed sales activity\r\nand in the near future we may possible be able to disclose details of the relationship between Rovnix and other\r\nmalware families. And now we will go deeper into the technical details of the Rovnix.D modification.\r\nPolymorphic bootstrap code\r\nSince Rovnix.B the modified bootstrap code has used polymorphic code in order to bypass static antivirus\r\nsignature detection. Originally, polymorphic decryption code was detected in Carberp samples incorporating\r\nbootkit code. The following figure shows the basic workings of the polymorphic decryption code.\r\nhttps://www.welivesecurity.com/2012/07/13/rovnix-bootkit-framework-updated/\r\nPage 2 of 7\n\nA simple trick of polymorphism based on permutations of the basic code blocks always results in the malware's\r\ngetting control of the decrypted malicious VBR code. The basic code blocks look like this:\r\n[polymorphic code from Rovnix.B]\r\nThe reason for using polymorphic code is to bypass static signature detections by antivirus engines: this code can\r\nonly be detected generically using emulation. Emulation is a technique closely related to sandboxing where the\r\ncode is executed in a safe virtual environment in order to analyse it dynamically.  The differences between the\r\nRovnix.D and Rovnix.B versions are presented in this flow graph:\r\n  \r\n[Rovnix.D variant (left) and Rovnix.B variant (right)]\r\nThe place where the encrypted malicious VBR is stored has been changed too, and after execution of the\r\npolymorphic code, control is transferred to the decrypted malicious VBR code. The different placement of the\r\nencrypted malicious VBR looks like this:\r\nhttps://www.welivesecurity.com/2012/07/13/rovnix-bootkit-framework-updated/\r\nPage 3 of 7\n\nWe also found changes to the function for decrypting and reading the malicious unsigned driver from raw sectors\r\nin the hard drive. These sectors are not used for general hidden storage, but only as a location for storing the\r\nmalicious driver, which injects the payload into specified user-mode processes on the infected machine.\r\nDifferences can be seen in the following figure:\r\n  \r\n[Rovnix.D variant (left) and Rovnix.B variant (right)]\r\nAll these changes are directed towards bypassing antivirus detections and do not represent fundamental changes in\r\nthe general Rovnix bootkit framework structure.\r\nChanges in hidden file storage\r\nThe structure of the hidden file system looks similar to the previous Rovnix modification and has already been\r\ndescribed in previous blog posts (Rovnix Reloaded: new step of evolution). However insignificant changes were\r\nfound in the file system initialization code. A strange function call was detected with the ability to read the file\r\nINJECTS.SYS from hidden storage.\r\nhttps://www.welivesecurity.com/2012/07/13/rovnix-bootkit-framework-updated/\r\nPage 4 of 7\n\nThis curious function extracts one or two paths from the file INJECTS.SYS to files on the standard file system.\r\nThe function code is presented in the figure below:\r\nControl flow never gets to execution of this code because the condition always receives NULL and control is\r\nnever transferred to this code. In my opinion this modification in Rovnix.D is used for tests, and we aren't seeing\r\nmany detections in the wild. Rovnix.D seems to be a transitional version in preparation for something else, but at\r\nthis moment we don't have a clear understanding of what that might be.\r\nPayload\r\nThe payload module includes functionality for downloading and executing additional modules from the C\u0026C\r\nserver. This module does not provide hooks and other malicious modifications to system memory, and is not\r\ngenerally detected by most common antivirus engines.\r\nThe C\u0026C domain is rtttt-windows.com\r\nThe payload module works in multithreading mode and can communicate with the malicious driver. For\r\nsynchronization reasons the payload generates the mutex:   Global\u003cGenerated_string\u003e. The call graph for the main\r\nthread looks like this:\r\nhttps://www.welivesecurity.com/2012/07/13/rovnix-bootkit-framework-updated/\r\nPage 5 of 7\n\nThe payload module can also send an encrypted buffer to the malicious driver to be written to hidden storage and\r\ninjection into processes. Before this Rovnix has not used any functionality for multiple injects, and provided only\r\none payload module. Rovnix.D can use multiple payloads and can be used to provide a botnet for rent, and at the\r\nend of the rental period the payload will be changed.\r\nConclusion\r\nAt this moment changes can be seen in the landscape of complex threats for the x64 platform. The Sirefef\r\n(ZeroAccess) family has been migrated to user-mode in its latest modifications (ZeroAccess: code injection\r\nchronicles). Olmarik/Olmasco (TDL4 and MaxSS modification) does not account for a large percentage of\r\ninfections in the wild and has stopped evolving (The Evolution of TDL: Conquering x64). Why are\r\nrootkits/bootkits for the 64 bit platform dying? In my opinion the ways in which x64 systems can be infected are\r\nseverely limited, and the search for something new requires ample time and considerable experience on the part of\r\nthe developer. Most bootkit infections have used MBR-modification, but this method is pretty old and by this time\r\nmost common antivirus engines provide checks for a modified MBR. The Rovnix family used other ways to infect\r\nwith modification of the VBR, but a constant stream of new modifications necessitates the provision of a great\r\ndeal of debugging information to the C\u0026C. The complexity of development and debugging on multiple platforms\r\nis one reason for the high price of the Rovnix bootkit framework. For example the fully-featured builder costs\r\n$60.000 including basic support for half a year. This price is only for the bootkit package and excludes the cost of\r\nexploits for escalating privilege in order to get access allowing modifications deep into the system.\r\nIn future, complex stealth technologies will mostly be used in targeted attacks, because the cost of buying and\r\nusing them is not commensurate with the anticipated profit for typical cybercriminals. We now have less than ten\r\nfamilies of x64 bootkits and their activity in the wild is also decreasing.\r\nSHA1 hashes for the Rovnix.D droppers mentioned are:\r\nC1C0CC056D31222D3735E6801ACBA763AC024C5B\r\n764B4F0202097F2B41A2821D30A7424490BF3A42\r\nSpecial thanks to my colleagues Pawel Smierciak and Maxim Grigoryev.\r\nAleksandr Matrosov, Security Intelligence Team Lead\r\nLet us keep you\r\nup to date\r\nSign up for our newsletters\r\nhttps://www.welivesecurity.com/2012/07/13/rovnix-bootkit-framework-updated/\r\nPage 6 of 7\n\nSource: https://www.welivesecurity.com/2012/07/13/rovnix-bootkit-framework-updated/\r\nhttps://www.welivesecurity.com/2012/07/13/rovnix-bootkit-framework-updated/\r\nPage 7 of 7", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://www.welivesecurity.com/2012/07/13/rovnix-bootkit-framework-updated/" ], "report_names": [ "rovnix-bootkit-framework-updated" ], "threat_actors": [ { "id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d", "created_at": "2022-10-25T16:07:24.139848Z", "updated_at": "2026-04-10T02:00:04.878798Z", "deleted_at": null, "main_name": "Safe", "aliases": [], "source_name": "ETDA:Safe", "tools": [ "DebugView", "LZ77", "OpenDoc", "SafeDisk", "TypeConfig", "UPXShell", "UsbDoc", "UsbExe" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775441483, "ts_updated_at": 1775791469, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/2b0ef76af26b04058ee881fbc9326eacc1236b2a.pdf", "text": "https://archive.orkl.eu/2b0ef76af26b04058ee881fbc9326eacc1236b2a.txt", "img": "https://archive.orkl.eu/2b0ef76af26b04058ee881fbc9326eacc1236b2a.jpg" } }