{
	"id": "2e3555d6-c99c-4cb0-acb6-037f9a7c7218",
	"created_at": "2026-04-06T00:15:48.688585Z",
	"updated_at": "2026-04-10T03:19:56.23818Z",
	"deleted_at": null,
	"sha1_hash": "70553547d5a0e07bb92a09631a4e59247a5b0c07",
	"title": "Mebromi: The First BIOS Rootkit in the Wild",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 209502,
	"plain_text": "Mebromi: The First BIOS Rootkit in the Wild\r\nBy Blog Staff\r\nPublished: 2011-09-13 · Archived: 2026-04-05 13:20:43 UTC\r\nBy Marco Giuliani\r\nIn the past few weeks a Chinese security company called Qihoo 360 blogged about a new BIOS rootkit hitting\r\nChinese computers. This turned to be a very interesting discovery as it appears to be the first real malware\r\ntargeting system BIOS since a well-known proof of concept called IceLord in 2007. The malware is called\r\nMebromi and contains a bit of everything: a BIOS rootkit specifically targeting Award BIOS, a MBR rootkit, a\r\nkernel mode rootkit, a PE file infector and a Trojan downloader. At this time, Mebromi is not designed to infect\r\n64-bit operating system and it is not able to infect the system if run with limited privileges.\r\nThe infection starts with a small encrypted dropper that contains five crypted resource files: hook.rom, flash.dll,\r\ncbrom.exe, my.sys, bios.sys. The goal of these files will be presented later in this analysis.\r\nThe infection is clearly focused on Chinese users, because the dropper is carefully checking if the system it’s\r\ngoing to infect is protected by Chinese security software Rising Antivirus and Jiangmin KV Antivirus. To gain\r\naccess to the BIOS, the infection first needs to get loaded in kernel mode so that it can handle with physical\r\nmemory instead of virtual memory.\r\nMany of you may recall the old CIH/Chernobyl infection, the infamous virus discovered in 1998 that was able to\r\nflash the motherboard BIOS, erasing it. Even CIH needed to gain kernel mode access to reach the BIOS, though at\r\nthe time the virus was exploiting a privilege escalation bug in Windows 9x operating system which allowed it to\r\noverwrite the Interrupt Descriptor Table with its own payload from user mode, then triggering the overwritten\r\ninterrupt handler and its malicious code is executed in kernel mode. Mebromi does not use such kind of privilege\r\nescalation trick anymore, it just needs to load its own kernel mode driver which will handle the BIOS infection. To\r\ndo so, it uses two methods: it could either extract and load the flash.dll library which will load the bios.sys driver,\r\nor it stops the beep.sys service key, overwriting the beep.sys driver with its own bios.sys code, restart the service\r\nkey and restore the original beep.sys code.\r\nThe bios.sys driver is the code which handle the BIOS infection. To read the BIOS code, it needs to map the\r\nphysical memory located at physical memory address 0xF0000, this is where the BIOS ROM usually resides.\r\nOnce read, the driver verifies if the BIOS ROM is Award BIOS, by checking the presence of the string:\r\n$@AWDFLA. If found, the driver tries to locate the SMI port that will be used by the rootkit to flash the BIOS\r\nROM.\r\nhttps://www.webroot.com//blog/2011/09/13/mebromi-the-first-bios-rootkit-in-the-wild/\r\nPage 1 of 4\n\nIf the BIOS ROM matches the string, the rootkit saves a copy of the BIOS to the file C:bios.bin and pass the next\r\nstep to the user mode component of the infection. The dropper extracts two files: cbrom.exe and hook.rom.\r\nCbrom.exe is a legitimate tool developed by Phoenix Technologies, used to modify the Award/Phoenix BIOS\r\nROM binaries. Hook.rom is the rootkit ISA BIOS ROM that is added to the BIOS binary, containing the rootkit\r\ninfection. The dropper executes cbrom.exe with the /isa switch parameter, passing the hook.rom file. Before\r\nactually injecting the malicious ISA ROM, the dropper checks the BIOS ROM code looking for the “hook rom”\r\nstring, used as a marker of the infection. If found, it means that the BIOS is already infected and it doesn’t need to\r\nbe infected again.\r\nAfter that the bios.bin file has been modified, the bios.sys driver send to the BIOS SMI port the command 0x29,\r\nused to erase the BIOS flash, and then the command 0x2F used to write the new BIOS ROM code to the BIOS\r\nROM.\r\nThe BIOS is now infected, and the dropper goes to its next step: infecting the Master Boot Record. The infection\r\nis 14 sectors long and the original MBR is stored to the sector 7. To avoid potential startup issues, the infected\r\nMBR stores a copy of the original MBR’s partition table. Finally the dropper extracts the my.sys driver on the root\r\nof the C: drive. My.sys is a kernel mode rootkit that hijacks disk.sys’s IRP major functions, by redirecting the\r\nIRP_MJ_READ/WRITE and IRP_MJ_DEVICE_CONTROL native functions. It is used to hide the infection on the\r\ndisk. Even if the BIOS infection doesn’t succeed, the rootkit does infect the MBR.\r\nAt the next system startup, after the BIOS POST phase, the malicious code injected inside it prepares the full\r\nMBR infection (all the first 14 sectors are stored inside the malicious BIOS rom, 7168 bytes in total) and checks\r\nthe MBR code of the hard drive looking if the infection is already present. To do it, the BIOS malicious code\r\nchecks for the presence of the string “int1” at the offset 0x92. If the string is not found, the BIOS malicious rom\r\nwill overwrite all the first 14 sectors of the hard drive, thus restoring the MBR infection.\r\nhttps://www.webroot.com//blog/2011/09/13/mebromi-the-first-bios-rootkit-in-the-wild/\r\nPage 2 of 4\n\nThe system startup procedure continues and the control now passes to the malicious master boot record. Here the\r\nmalicious payload analyzes the original MBR partition table and looks for the active partition, checking if it’s\r\nusing a NTFS or FAT32 file system. The malicious MBR code contains indeed NTFS/FAT32 parser routines,\r\nused to get inside the file system to look for winlogon.exe or wininit.exe file. When found, the malicious code\r\ncontains a file infection payload, able to inject malicious code inside the specified file and hijack the entry point of\r\nit. Before infecting the file, the MBR malicious code checks if it is already infected, by looking for the string\r\n“cnns” at the offset 0x50 from the beginning of the PE file. This is the infection marker. If the string is not found,\r\nthe infection stores a crypted payload – about 600 bytes of code – inside winlogon.exe or wininit.exe and hijacks\r\nthe PE entry point to the beginning of it, saving the original entry point at the offset 0x60.\r\nThe job of the MBR infection ends here, waiting for the Windows startup which will load the  patched executable.\r\nWhen loaded, the payload self-decrypt its malicious code and loads in memory the my.sys driver. Then it tries to\r\ndownload an additional infection from the (now unavailable) URL address:\r\nhttp://dh.3515.info:806/test/91/calc[removed].\r\nThe concept behind Mebromi is not new. In fact we must recall the IceLord BIOS rootkit published in 2007, a\r\npublic proof of concept able to target Award BIOS rom, using an approach very similar to the Mebromi one – or\r\nshould we say that Mebromi is more than just inspired by the IceLord rootkit?\r\nStoring the malicious code inside the BIOS ROM could actually become more than just a problem for security\r\nsoftware, giving the fact that even if an antivirus detect and clean the MBR infection, it will be restored at the next\r\nsystem startup when the malicious BIOS payload would overwrite the MBR code again. Developing an antivirus\r\nutility able to clean the BIOS code is a challenge, because it needs to be totally error-proof, to avoid rendering the\r\nsystem unbootable at all. The job of handling with such specific system codes should be left to the developers of\r\nthe specific motherboard model, who release BIOS updates along with specific tool to update the BIOS code.\r\nOn the other hand, although this kind of infection is potentially one of the most persistent infections known out\r\nthere in the wild, it will hardly become a major threat because of the level of complexity needed to achieve the\r\ngoal. While a kernel mode infection or a MBR infection could still work in a generic way among all the PC out\r\nthere – and they still have a huge available free space to play with, a BIOS-based rootkit needs to be fully\r\ncompatible with all major BIOS rom out there, it should be able to infect all the different releases of Award,\r\nPhoenix, AMI BIOS’s out there; a level of complexity that is simply unasked for writing a good persistent\r\ninfection (e.g. TDL rootkit, various Rustock releases, ZeroAccess rootkit among all). In fact, why is Mebromi\r\nonly targetting Award BIOS rom? Perhaps because there was already a known proof of concept that is 5 years old\r\ntargeting Award BIOS ROM available online.\r\nhttps://www.webroot.com//blog/2011/09/13/mebromi-the-first-bios-rootkit-in-the-wild/\r\nPage 3 of 4\n\nAre BIOS rootkits a real threat? Yes, we can consider Mebromi the first real BIOS rootkit incident discovered in\r\nthe wild – let’s consider IceLord BIOS rootkit more a proof of concept. Should we be concerned about BIOS\r\nrootkits? Well, while we try to discover whether our PC is infected by an unknown and super-stealth BIOS rootkit,\r\nlet’s try and look if there is a more “humble” kernel mode rootkit which is already infecting our PC, allowing a\r\nremote attacker to silently own our system.\r\nBlog Staff\r\nAbout the Author\r\nBlog Staff\r\nThe Webroot blog offers expert insights and analysis into the latest cybersecurity trends. Whether you’re a home\r\nor business user, we’re dedicated to giving you the awareness and knowledge needed to stay ahead of today’s\r\ncyber threats.\r\nSource: https://www.webroot.com//blog/2011/09/13/mebromi-the-first-bios-rootkit-in-the-wild/\r\nhttps://www.webroot.com//blog/2011/09/13/mebromi-the-first-bios-rootkit-in-the-wild/\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.webroot.com//blog/2011/09/13/mebromi-the-first-bios-rootkit-in-the-wild/"
	],
	"report_names": [
		"mebromi-the-first-bios-rootkit-in-the-wild"
	],
	"threat_actors": [],
	"ts_created_at": 1775434548,
	"ts_updated_at": 1775791196,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/70553547d5a0e07bb92a09631a4e59247a5b0c07.pdf",
		"text": "https://archive.orkl.eu/70553547d5a0e07bb92a09631a4e59247a5b0c07.txt",
		"img": "https://archive.orkl.eu/70553547d5a0e07bb92a09631a4e59247a5b0c07.jpg"
	}
}