{
	"id": "71542a75-2d85-4260-8d35-a54980ac12a9",
	"created_at": "2026-04-06T00:16:05.883046Z",
	"updated_at": "2026-04-10T13:12:02.431994Z",
	"deleted_at": null,
	"sha1_hash": "fa3519c1f123421af1f366f5e0183e0d4911bd61",
	"title": "Rovnix new “evolution”",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 279677,
	"plain_text": "Rovnix new “evolution”\r\nBy Marcus Hutchins\r\nPublished: 2014-05-06 · Archived: 2026-04-05 18:25:08 UTC\r\nRovnix is an advanced VBR (Volume Boot Record) rootkit best known for\r\nbeing the bootkit component of Carberp. The kit operates in kernel mode, uses\r\na custom TCP/IP stack to bypass firewalls, and stores components on a virtual\r\nfilesystem outside of the partition. Yesterday Microsoft posted an update\r\nexplaining a new “evolution” to rovnix that had been found.\r\n  “evolution”\r\nThe so-called Evolution\r\nI’m Melting The first thing i noticed was the file “melts” (delete’s itself once run (well, tries to)), this is done by a\r\nlot of malware to prevent future forensics, but how this sample does it is a little less than elegant. |\r\n | |—| | So\r\nadvanced |\r\nThe bot drops a non-hidden batch file to the location it’s run from (in my case the desktop), the batch file just uses\r\nthe “DEL” command on an infinite loop, which uses all of the CPU, until the file is deleted. On my test system,\r\nthe batch file actually fails because the executable locks the file, meaning it can only be deleted once the\r\nexecutable stops (the system reboots), when the system reboots windows stops the batch file before the\r\nexecutable, thus it’s never deleted.\r\nInitial Infection After executing the packed binary it unpacks itself and continues running, the above batch file is\r\ndeployed to delete the dropper after run. For stealth reasons, the kit sits idle for an undefined amount of time (I’m\r\nyet to find out how this is done), then the system is automatically rebooted. NtShutdownSystem is hooked to\r\nreceive notifications of shutdowns / reboots, so rebooting the computer will result in intimidate infection and save\r\nhttp://www.malwaretech.com/2014/05/rovnix-new-evolution.html\r\nPage 1 of 5\n\nyou a wait. Amusingly the packed dropper doesn’t exit until reboot and the delay is long enough to attach a\r\ndebugger, dump the unpacked code from memory, then move it to another computer.\r\nThe entire kit is packed inside the dropper, about 13 files total (32-bit and 64-bit) and during the reboot delay\r\neverything exists in one continuous block of memory and once dumped; the components can be split up by byte\r\nsignature “0x4D 0x5A 0x90” (DOS header).\r\nNo VBR The first thing i noticed after infection is that the first 16 sectors of the disk are blank (where the VBR\r\nshould be located). To anyone familiar with rovnix this is a common sign of infection, as it uses the kernel driver\r\nto hide infected sectors (which is probably just as suspicious as showing them). |\r\n | |\r\n—| | Ermahgerd |\r\nStability The kit appears to run ok on Windows XP 32-bit, but on Windows 7 64-bit it causes the PC to BSOD\r\nabout every 20 minutes (Sometimes the system can even get stuck in an infinite BSOD loop).\r\nAnti Reversing I can’t tell if I’m going crazy or the anti reversing protection is what I think it is. The driver\r\nappears to check for a wide variety of reversing tools (vbox, vmaware, wireshark, ollydbg, ida, lordpe, etc), then\r\ndisregards the results and exits the thread. My tests appear to confirm this as I’ve infected a VM with multiple\r\nhttp://www.malwaretech.com/2014/05/rovnix-new-evolution.html\r\nPage 2 of 5\n\nblacklisted tools running and the malware still continues the infection. | |\r\n|—| | The return value will be non-zero if any blacklisted tools are found |\r\nDisregard everything?\r\nI’ve checked through the ASM multiple time, but can’t seem to find anything that would result in the bot being\r\nany wiser about the environment after the execution of this thread.\r\nVirtual File SystemRemember the old rovnix filesystem? It used raw disk\r\naccess to store components outside of the filesystem in non-allocated disk\r\nspace, making it near impossible for the AV to find or remove? Well that has\r\nbeen “upgraded”. The virtual filesystem is now stored inside a file in\r\n“C:system32”, free for the AV to delete at any point (Coder couldn’t figure\r\nhow to access virtual filesystem from usermode?). The file-name ends in\r\n“.bin” and is a 64-bit hex value generated using the time stamp counter\r\n(“rdtsc” instruction), all files are encrypted with RC6.\r\n \r\nExample File-name\r\nGeneration\r\nBecause the file system is now vulnerable due to it being saved as a standard windows file, the coders have added\r\na high level (and fairly useless) kernel mode rootkit to the driver. The rootkit places SSDT hooks on the following\r\nfunctions:- NtQueryDirectoryFile – Hides the file.\r\nNtCreateFile – Prevents file from being opened by all except bot.\r\nNtOpenFile – Same as above.\r\nNtClose – No idea.\r\nhttp://www.malwaretech.com/2014/05/rovnix-new-evolution.html\r\nPage 3 of 5\n\nNtSetInformationFile – Prevents rename / delete.\r\nNtDeleteFile – Prevents delete.\r\nNtQueryInformationFile – Hides the file.\r\nAdditionally the rootkit also hooks some registry functions to hide keys, I can’t see any sane reason why. |\r\n| |—| | Each hook entry is an array of 16 bytes (4 double words) |\r\nAlthough this won’t protect against antiviruses, it may stop usermode malware and beginner security researchers\r\nfrom tampering with the filesystem.Usermode ComponentThis entire bootkit + kernel mode rootkit all serves to\r\nprotect a small trojan which appears to run as a service and do nothing other than log keys and ammyy id’s to a\r\ncommand and control server. The MD5 has is: 5e5f3ced234c6f7c91457a875cf4a570.\r\nConclusion\r\nThis isn’t the work of common scriptkiddies, it’s likely the coder has a moderate knowledge of kernel mode\r\nprogramming; however, the code is not experience with malware (using SSDT hooks and filters in a bootkit,\r\nhaving to move the virtual filesystem into a real file to access it from usermode, using batch file to delete melt\r\nexe). This clearly isn’t an “evolution” of rovnix as Microsoft claim, it’s just some random coders trying to make\r\nthe bootkit compatible with their bot.\r\nhttp://www.malwaretech.com/2014/05/rovnix-new-evolution.html\r\nPage 4 of 5\n\nThanks to Poopsmith for bringing the sample to my attention and Xylitol for retrieving it for me. |\r\n | |—| | Finally, something to reverse. |\r\nSource: http://www.malwaretech.com/2014/05/rovnix-new-evolution.html\r\nhttp://www.malwaretech.com/2014/05/rovnix-new-evolution.html\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"http://www.malwaretech.com/2014/05/rovnix-new-evolution.html"
	],
	"report_names": [
		"rovnix-new-evolution.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434565,
	"ts_updated_at": 1775826722,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/fa3519c1f123421af1f366f5e0183e0d4911bd61.pdf",
		"text": "https://archive.orkl.eu/fa3519c1f123421af1f366f5e0183e0d4911bd61.txt",
		"img": "https://archive.orkl.eu/fa3519c1f123421af1f366f5e0183e0d4911bd61.jpg"
	}
}