{
	"id": "76513f15-08e4-4769-aeda-baa7e90d87bb",
	"created_at": "2026-04-06T01:28:53.394619Z",
	"updated_at": "2026-04-10T03:20:01.439314Z",
	"deleted_at": null,
	"sha1_hash": "8f0a39ac76b6201ff24553f732bb730fdfc08033",
	"title": "Virus Bulletin :: Spam from the kernel",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 150942,
	"plain_text": "Virus Bulletin :: Spam from the kernel\r\nBy Kimmo KasslinF-Secure, MalaysiaElia FlorioSymantec, IrelandEditor: Helen Martin\r\nArchived: 2026-04-06 00:17:26 UTC\r\n2007-11-01\r\nAbstract\r\nTrojan.Srizbi is the first example seen in the wild of a complex piece of malware that operates fully from kernel\r\nmode. Kimmo Kasslin and Elia Florio provide a detailed analysis.\r\nCopyright © 2007 Virus Bulletin\r\nTable of contents\r\nIntroduction\r\nIn December 2006 one of the authors of this article concluded his research paper on kernel malware with the\r\nfollowing paragraph [1]:\r\n‘This paper has shown the basic techniques that kernel malware is using to do their job. Their main role has been\r\nto perform some specific tasks for the main user-mode component. However, the scene is changing. There has\r\nbeen lots of interest in various research groups to investigate for the possibilities to do more complex tasks\r\ndirectly from kernel. The next big thing is going to be the network side. This year we have already seen\r\npresentations talking about how backdoors can be implemented directly from kernel mode using only the NDIS\r\nlayer and custom TCP/IP stack. We have also seen a presentation about bypassing personal firewalls from kernel-mode.’\r\nRegrettably, the prediction became true in June 2007 when the authors started to analyse a malicious kernel-mode\r\ndriver consisting of large amounts of code. After deeper analysis it became evident that there were no signs of\r\nuser-mode injection, meaning that all of the code was being executed at ring 0. Since then the malware family has\r\nbeen known as Trojan.Srizbi (or as Rootkit:W32/Agent.EA).\r\nOrigin of Trojan.Srizbi\r\nIn June 2007 several AV companies raised an alert due to a large-scale web-based attack being carried out with\r\ndrive-by exploits. A malicious tag was injected into the homepages of many legitimate Italian and Russian\r\nwebsites. Attackers had injected an IFRAME to redirect visitors to a website running a multi-staged exploit kit,\r\nnowadays best known as ‘MPack’ [2]. The specific MPack installation used for this attack was designed to\r\ndownload several trojans from the remote server 81.95.146.150, hosted by the ambiguous ‘Russian Business\r\nNetwork’.\r\nhttps://www.virusbulletin.com/virusbulletin/2007/11/spam-kernel\r\nPage 1 of 9\n\nOne of the nasty creatures to spread from this server was Trojan.Srizbi, a sophisticated piece of malware contained\r\nwithin 150Kb of kernel mode code. This was the first public revelation of Srizbi, but further research tracked older\r\nsamples back to April 2007. The first observed filename was ‘windbg48.sys’, followed by ‘symavc32.sys’ more\r\nrecently. Other pseudo random names of this threat always take the format [CHARS][2DIGITS] (e.g. Cmjg57.sys,\r\nWdml36.sys, Fln51.sys, etc.).\r\nThe Srizbi driver is installed by a dropper component that is packed with UPX and protected with a layer of\r\nscrambled code. This layer uses custom spaghetti code obfuscation with CALL/JMP mixed with junk opcodes. It\r\nresembles the Rustock.B polymorphic packer, but it is more advanced. The dropper code makes API calls by using\r\nPUSH/RET sequences, and parameters are pushed into the stack with MOV [ESP] and other complex indirect\r\nloading instructions, making standard static analysis almost impossible (see Figure 1).\r\nFigure 1. Examples of scrambled API calls used by the Srizbi packer.\r\nReverse engineering of this piece of code is not straightforward and may require the assistance of custom tracing\r\ntools. However, it is possible to spot two principal decryption routines in the code:\r\nhttps://www.virusbulletin.com/virusbulletin/2007/11/spam-kernel\r\nPage 2 of 9\n\n1. decryption with NOT BYTE\r\n2. decryption with BYTE XOR 0xB0\r\nDecryption routine (1) is identical to the one inside the driver and is used to decrypt all text strings; the XOR\r\ndecryption (2) is used to decrypt the embedded driver. The Srizbi installer drops a copy of the driver into the\r\n‘%SystemRoot%\\System32\\drivers’ folder and installs it as a service via OpenSCManager and CreateService.\r\nNext, the service is started and the installer self-deletes.\r\nAnother of Srizbi’s challenges is the use of CRC values instead of basic string compares when it searches for\r\nnames or resolves imported API functions dynamically. In some cases the only viable solution to find which string\r\nis being searched by Srizbi is to brute force CRCs over a set of possible strings.\r\nFull-kernel malware\r\nWe can say with some certainty that Trojan.Srizbi represents an important milestone in the evolution of malware\r\nutilizing kernel-mode techniques. It is the first complex full-kernel malware [3] to have features such as file and\r\nregistry hiding, bypassing of memory hooks, and low-level NDIS hooks with a private TCP/IP stack. The latter is\r\nutilized to implement a fully blown spam client with an HTTP-based command and control (C\u0026C) infrastructure\r\n– all directly from ring 0.\r\nThe fact that Trojan.Srizbi is fully implemented in kernel mode makes it very powerful. It can activate very early\r\nduring the boot process, allowing it to make its system modifications before most security products even have a\r\nchance to load. Also, many security products do not consider activities initiated by kernel-mode code to be\r\nsuspicious or malicious since the kernel should be trusted.\r\nA feature that makes Srizbi unique is the fact that it disables and removes other competitor rootkits from the\r\ninfected system very effectively. The trend of malware gangs fighting each other is becoming more intense\r\nnowadays since every unprotected machine is likely to be targeted by multiple pieces of malware – but in the end,\r\nthere can be only one! Only the strongest and most sophisticated malware will survive.\r\nSrizbi tries to accomplish this goal in a unique way: it rebuilds a clean copy of KiServiceTable by reading\r\nNTOSKRNL.EXE directly from disk and then it retrieves all the original (hook-free) function pointers of the\r\nrequired file and registry API functions. With this technique Srizbi is able to bypass most rootkits (and security\r\nproducts) present on the machine and can safely enumerate any files and registry keys.\r\nSrizbi rebuilds its own Service Table from disk.\r\nFigure 2. Srizbi rebuilds its own Service Table from disk.\r\nWe also found that Srizbi contains a generic driver removal routine based on CRC values. The routine enumerates\r\nservices sub keys from following key:\r\n\\REGISTRY\\MACHINE\\SYSTEM\\CurrentControlSet\\Services\\[SRV_NAME]\r\nhttps://www.virusbulletin.com/virusbulletin/2007/11/spam-kernel\r\nPage 3 of 9\n\nIf the CRC of [SRV_NAME] matches one of the following hardcoded CRC values, then the trojan unloads the\r\ndriver with ZwUnloadDriver then deletes the launch point of the service by removing the related registry key and\r\nits sub keys.\r\nCRC value Service name\r\n0xe0e5a117 runtime\r\n0x4c4f27cc runtime2\r\n0xbf36b345 xpdx\r\n0x949b30b3 lzx32\r\nTable 1. CRC values and service names targeted by Srizbi’s driver removal routine.\r\nThe services in Table 1 are quite (in)famous within the AV industry, since they are used by two of today’s most\r\ncommon rootkit malware families: Backdoor.Rustock.B (lzx32, xpdx) and Trojan.Pandex (runtime, runtime2).\r\nSrizbi also contains the text strings of some other malware, ‘wincom32.sys’ and ‘ntio256.sys’, however they are\r\nnot referenced and never used in the actual code. More evidence of the ongoing war between the Srizbi gang and\r\nother malware authors was reported by researchers at Arbor Networks [4], who noticed StormWorm bots running\r\nDDoS attacks against Srizbi domains.\r\nNDIS hijacking\r\nFrom a technical point of view the most interesting part of Trojan.Srizbi is its network layer implementation. Its\r\nsole purpose is to bypass personal firewalls and other security products that monitor incoming and outgoing\r\nnetwork packets. The implication is that the infected machine will be able to communicate with the command and\r\ncontrol server and send thousands of spam emails even if the firewall is set to the ‘block-all-traffic’ mode.\r\nWindows networking architecture is divided into different layers where the ones most commonly used by today’s\r\nfirewalls are TDI and NDIS. The NDIS layer abstracts the network hardware from network drivers and is the\r\nlowest layer available for third-party network drivers. This makes it the obvious choice for modern firewalls since\r\nthe lower they operate the harder it is to bypass them.\r\nUsually NDIS hooking firewalls install their triggers to the following locations:\r\nNDIS library functions\r\nNDIS_PROTOCOL_BLOCK structure handler function pointers\r\nNDIS_OPEN_BLOCK structure handler function pointers\r\nThe actual triggers controlling inbound and outbound traffic are implemented by replacing several function\r\npointers from inside the two internal NDIS structures that the NDIS layer uses for sending packets to and\r\nreceiving packets from the driver controlling the hardware. The following are some commonly hooked handler\r\nfunctions:\r\nhttps://www.virusbulletin.com/virusbulletin/2007/11/spam-kernel\r\nPage 4 of 9\n\nNDIS_OPEN_BLOCK-\u003eSendHandler\r\nNDIS_OPEN_BLOCK-\u003eSendPacketsHandler\r\nNDIS_OPEN_BLOCK-\u003eReceiveHandler\r\nNDIS_OPEN_BLOCK-\u003eReceivePacketHandler\r\nThe firewall driver normally installs inline hooks into four functions exported by ndis.sys that allow it to hook the\r\nrequired NDIS handler functions for any newly registered protocol driver. Otherwise the new protocol driver\r\nwould be able to send and receive traffic without the firewall seeing it. The hooked functions are:\r\nNdisRegisterProtocol\r\nNdisDeregisterProtocol\r\nNdisOpenAdapter\r\nNdisCloseAdapter\r\nNow that we have had a brief introduction to how modern firewalls are able to filter the traffic, let’s continue by\r\nlooking at what makes it possible for Trojan.Srizbi to bypass them completely.\r\nFirst, Trojan.Srizbi finds a network adapter that it can use to communicate with the Internet. It does this by finding\r\na suitable interface from the TCP/IP driver’s registry settings. It calls an undocumented LookupRoute function\r\nexported by tcpip.sys which will give it the IP address of the default gateway. Then it enumerates all sub keys\r\nunder the key:\r\n\\REGISTRY\\MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\\Interfaces\r\nIt uses the default gateway address to find the matching interface, or if there are no matches it will take the one\r\nthat has proper IP settings defined. Next, it enumerates all sub keys under the key:\r\n\\REGISTRY\\MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\\Adapters\r\nFinally, it selects the adapter whose IpConfig value matches the previously found interface.\r\nTrojan.Srizbi gets access to the NDIS structures by installing a dummy protocol temporarily. It first registers a\r\nnew protocol with a random name by calling NdisRegisterProtocol. Then it binds the protocol to the previously\r\nselected adapter by calling NdisOpenAdapter. As a result, the temporary protocol’s NDIS_OPEN_BLOCK\r\nhandler functions will be set up by the underlying system.\r\nAs we have already mentioned these two functions are commonly hooked by the firewall. Trojan.Srizbi solves this\r\nproblem by using its private and hook-free version of ndis.sys. During initialization it loads the ndis.sys file into\r\nmemory, resolves its imports and finally relocates the new module into the base address of the original ndis.sys\r\nhttps://www.virusbulletin.com/virusbulletin/2007/11/spam-kernel\r\nPage 5 of 9\n\nmodule. This means that the private module will still be using e.g. the same global variables as the original\r\nndis.sys module.\r\nThe following is the disassembly of the private and original NdisRegisterProtocol functions:\r\nkd\u003e u poi(Yol33!NdisRegisterProtocol)\r\n816b917d 8bff mov edi,edi\r\n816b917f 55 push ebp\r\n816b9180 8bec mov ebp,esp\r\n816b9182 51 push ecx\r\n816b9183 53 push ebx\r\n816b9184 56 push esi\r\n816b9185 57 push edi\r\n816b9186 b938d16ff9 mov ecx,offset NDIS!ndisPkgs+0x20 (f96fd138)\r\nkd\u003e u ndis!NdisRegisterProtocol\r\nNDIS!NdisRegisterProtocol:\r\nf96ff17d e9b2d75200 jmp fwdrv+0x934 (f9c2c934)\r\nf96ff182 51 push ecx\r\nf96ff183 53 push ebx\r\nf96ff184 56 push esi\r\nf96ff185 57 push edi\r\nf96ff186 b938d16ff9 mov ecx,offset NDIS!ndisPkgs+0x20 (f96fd138)\r\nWith the help of the dummy protocol the driver now has a handle to the registered protocol that is bound to the\r\nunderlying adapter. The handle is returned by NdisRegisterProtocol’s second argument called\r\nNdisProtocolHandle, which is defined as PNDIS_HANDLE. This is actually a pointer to the dummy protocol’s\r\nNDIS_PROTOCOL_BLOCK. By using the information stored in this structure the malware is able to find the\r\nadapter’s NDIS_MINIPORT_BLOCK structure that is part of the lowest layers of NDIS. It then searches for other\r\nprotocols that are bound to the same adapter, and takes the first one to match any of the following protocols:\r\n1. TCPIP\r\n2. PSCHED\r\n3. TCPIP_WANARP\r\nThe way this whole process works is illustrated in Figure 3.\r\nhttps://www.virusbulletin.com/virusbulletin/2007/11/spam-kernel\r\nPage 6 of 9\n\nFigure 3. Trojan.Srizbi uses the ‘dummy protocol’ approach to find the NDIS structures that it hooks.\r\nNow that the driver has access to the NDIS structures of an existing protocol it will replace a bunch of handler\r\nfunctions with its own. In addition, it fetches the addresses of certain handler functions that it will use itself. After\r\nit has finished it will just uninstall the dummy protocol.\r\nTrojan.Srizbi uses its NDIS hooks and the original handler functions together with its own TCP/IP stack to send\r\nand receive packets.\r\nTo send packets it uses the following handler function:\r\nNDIS_MINIPORT_BLOCK-\u003eSendPacketsHandler\r\nTo get a notification after the send operation has completed it uses the following hook:\r\nNDIS_OPEN_BLOCK-\u003eSendCompleteHandler\r\nTo receive packets it uses the following hooks:\r\nNDIS_OPEN_BLOCK-\u003eReceiveHandler\r\nNDIS_OPEN_BLOCK-\u003eReceivePacketHandler\r\nSince the malware is using its own TCP/IP stack it has somehow to identify which of the received packets should\r\nbe passed to its private stack instead of the stack used by the system. One solution to this problem would be to use\r\nits own IP and MAC addresses since their combination should be unique on most physical machines [5].\r\nHowever, Trojan.Srizbi uses a different approach. When it sends packets it always uses a source port that is higher\r\nthan 32,000. For every packet received it checks whether it is a TCP packet, whether its destination IP equals the\r\nclient's address, and whether the destination port is larger than 32,000. If all of these are true then it forwards the\r\npacket to its private stack. To make sure that no other application (using ephemeral ports) sends packets using its\r\nhttps://www.virusbulletin.com/virusbulletin/2007/11/spam-kernel\r\nPage 7 of 9\n\nreserved source port range it sets the MaxUserPort registry value to 31,999, which is defined under the following\r\nkey:\r\n\\REGISTRY\\MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\r\nStealth spam\r\nSrizbi (like Rustock) is a spam bot. A sophisticated, stealthy and powerful spam machine. Once the trojan takes\r\nover NDIS networking, it contacts C\u0026C servers on TCP port 4099 and retrieves spam instructions and\r\nconfigurations. The spam backdoor has a large set of commands that allow the botmaster to define a lot of\r\nparameters. A deep analysis of the C\u0026C protocol is beyond the scope of this document, but we can briefly\r\nsummarize how it works. Each spam session starts with the download of a ZIP package containing the files shown\r\nin Table 2.\r\nFile Content\r\nconfig\r\nConfiguration file with all spam parameters (e.g. task_owner, max_mails, max_sim conn,\r\npipeline, subj, etc.)\r\nmessage Text/HTML body of the spam message\r\nmlist List of recipients\r\n000_data22 List of mail domains\r\n001_ncommall List of names/surnames\r\n002_senderna List of names/surnames\r\n003_sendersu List of names/surnames\r\nmxdata MX records of the domains\r\nTable 2. Configuration files included in the package provided by the Srizbi C\u0026C server.\r\nSrizbi also has an advanced feature that allows the trojan eventually to bypass some badly configured honeypot\r\nmachines. The trojan does not trust the locally configured DNS server of the infected machine and instead\r\nreceives all the necessary DNS information as part of the ZIP package. For example, if Srizbi needs to resolve the\r\n‘smtp.acme.org’ server to send spam, it will receive in the package the necessary MX record info for the\r\n‘acme.org’ domain. Any honeypot that simply blocks/redirects DNS resolutions to prevent threats from spamming\r\nwill be bypassed by Srizbi because it has a kind of private DNS server over the C\u0026C channel. Srizbi can send\r\nimage spam in HTML format using English and also Cyrillic Unicode character sets.\r\nConclusion\r\nhttps://www.virusbulletin.com/virusbulletin/2007/11/spam-kernel\r\nPage 8 of 9\n\nDespite all the advanced features implemented for spam and networking, the major weakness of Srizbi is its\r\nhiding technique. The rootkit attempts to hide itself by placing the following kernel hooks:\r\nInline hook: NtOpenKey, NtEnumerateKey\r\n\\FileSystem\\Ntfs driver: IRP_MJ_CREATE, IRP_MJ_DIRECTORY_CONTROL;\r\nThese hooks effectively hide the malware’s driver file and registry keys, but currently they can easily be detected\r\nby common rootkit detectors and can effectively be bypassed to remove the threat from the infected system.\r\nBibliography\r\n[3] Malicious code that executes all its code in ring 0. After it is installed into the system by a dropper component\r\n(user-mode code or kernel-mode exploit) it will be able to operate by itself.\r\n[5] Hoglund, G.; Butler, J. Rootkits: subverting the Windows kernel. 2005. Upper Saddle River, NJ. Addison-Wesley Professional. 324 pages. ISBN 0-321-29431-9.\r\nSource: https://www.virusbulletin.com/virusbulletin/2007/11/spam-kernel\r\nhttps://www.virusbulletin.com/virusbulletin/2007/11/spam-kernel\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.virusbulletin.com/virusbulletin/2007/11/spam-kernel"
	],
	"report_names": [
		"spam-kernel"
	],
	"threat_actors": [],
	"ts_created_at": 1775438933,
	"ts_updated_at": 1775791201,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8f0a39ac76b6201ff24553f732bb730fdfc08033.pdf",
		"text": "https://archive.orkl.eu/8f0a39ac76b6201ff24553f732bb730fdfc08033.txt",
		"img": "https://archive.orkl.eu/8f0a39ac76b6201ff24553f732bb730fdfc08033.jpg"
	}
}