{
	"id": "d075da7a-3635-417f-be08-5ab179ecd23c",
	"created_at": "2026-04-06T00:15:05.908279Z",
	"updated_at": "2026-04-10T03:21:07.873032Z",
	"deleted_at": null,
	"sha1_hash": "d97ce2059accb3ad84943994bfe7d551a1849f43",
	"title": "A Case Study of the Rustock Rootkit and Spam Bot",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 947568,
	"plain_text": "A Case Study of the Rustock Rootkit and Spam Bot\r\nArchived: 2026-04-05 15:05:28 UTC\r\nAbstract:\r\nIn this paper we present a case study of the steps leading up to the extraction of the spam bot payload found within a\r\nbackdoor rootkit known as Backdoor.Rustock.B or Spam-Mailbot.c. Following the extraction of the spam module we focus\r\nour analysis on the steps necessary to decrypt the communications between the command and control server and infected\r\nhosts. Part of the discussion involves a method to extract the encryption key from within the malware binary and use that to\r\ndecrypt the communications. The result is a better understanding of an advanced botnet communications scheme.\r\nIntroduction\r\nThe threat produced by botnets has escalated in recent years. Not only has the number of infected machines grown to\r\ncatastrophic levels, but the sophistication level of the tools used to infect and control vulnerable systems has also increased.\r\nTraditionally, botnets have used the Internet Relay Chat (IRC) protocol for command and control [1,2,3]. This method is\r\nlosing popularity among bot creators and herders since it is generally easy to detect, monitor, and block IRC traffic. New\r\nmethods for hiding the command and control communications include HTTP based communications, encryption, and peer-to-peer network models [3,4,5,6].\r\nIn this analysis we examine a backdoor rootkit known as Backdoor.Rustock.B [7] or Spam-Mailbot.c [8] but hereafter\r\nreferred to simply as rustock. While work has been done to deobfuscate the malware and study the rootkit [7,9], little\r\ninformation is available about the functionality of the spam bot that is contained within rustock. We are particularly\r\ninterested in the communications between the command and control (C\u0026C) server and infected hosts since they provide a\r\nglimpse into an advanced botnet communications scheme. The remainder of this paper presents a case study of the steps\r\nnecessary to extract and reverse engineer the spam bot component.\r\nFirst, we provide some information gleaned from observing the network traffic produced by the bot. Then, we walk through\r\nthe three phases of deobfuscation leading to the extraction of the spam bot component. Next, we describe the reverse\r\nengineering of the spam bot leading up to the extraction of the session encryption key from memory that makes it possible to\r\ndecrypt the C\u0026C communications between client and server. Finally we summarize a sample decrypted C\u0026C\r\ncommunication session between client and server.\r\nNetwork Traffic Analysis\r\nBefore we begin the static analysis of the rustock malware we are able to learn a lot about the functionality of the spam bot\r\nthrough direct observation of the network traffic between the client and server. By looking through a network traffic dump\r\nhttps://www.usenix.org/legacy/event/hotbots07/tech/full_papers/chiang/chiang_html/index.html\r\nPage 1 of 11\n\nwe determine that all C\u0026C communications are encrypted. The communications can be divided into two phases: key\r\nexchange and instructions. Both phases are initiated by the client in the form of HTTP POSTs. Figure 1 gives a general\r\noverview of the encrypted communications.\r\nFigure 1: Spam bot command and control\r\nThe key exchange phase is similar in all C\u0026C sessions we observed. The HTTP POST from the client contains a 96-byte\r\nencrypted payload and is sent to the login.php page on the server. This is followed by a response from the server\r\ncontaining a 16-byte payload.\r\nThe instruction phase of the C\u0026C communications consists of a variable number of HTTP POSTs from the client and\r\ncorresponding responses from the server. The size of the payloads contained within these packets is also variable and\r\ntherefore assumed to be dependent upon the variable nature of the underlying C\u0026C instructions.\r\nIn addition to the information we gained through observation of the network traffic the people at Symantec helped us\r\nrecognize that the encryption algorithm used to encrypt the data was RC4.\r\nStatic Analysis of the Malware\r\nBy combining the information we gather from static and dynamic analyses, we are able to ultimately decipher the\r\ncommunications between the client and server. This section describes the static analysis portion of the investigation into\r\nrustock. We perform the static analysis on this malware by studying the obfuscated disassembly code of the binary file\r\nlzx32.sys. The MD5 sum of this particular variant is: FDAFB3A14338B2B612C4E5C4F94B3677.\r\nAs shown in Figure 2 , the malware contains four main components: the initial deobfuscation routine, the rootkit loader,\r\nthe rootkit, and the spam module.\r\nFigure 2: Overview of the lzx32.sys malware. In our analysis we break it down into four parts: A. The first deobfuscation\r\nroutine, B. The rootkit loader which contains the second deobfuscation routine, C. The rootkit containing the third\r\ndeobfuscation routine, and D. The spam module.\r\nhttps://www.usenix.org/legacy/event/hotbots07/tech/full_papers/chiang/chiang_html/index.html\r\nPage 2 of 11\n\nIDA Pro 5.0 Standard Edition [10], an interactive disassembly tool is used to study the code. A useful plug-in to the\r\ndisassembly tool called idax86emu [11] is also employed to deobfuscate the malware. The plug-in tool emulates the x86\r\nCPU instruction set and can modify the disassembly as it walks through the obfuscated code.\r\nInitial Deobfuscation Routine\r\nThe Portable Executable (PE) header found within the lzx32.sys executable points to an entry point located at address\r\n0x00011000. This is the starting point of the first deobfuscation routine. The code at the entry point consists of a series of\r\nnested loops that contain instructions to self-modify the code starting at 0x000114AF (note: this address and all future\r\nreferences to addresses in this section are virtual addresses as seen by the disassembler and may be different with other\r\nversions of the malware).\r\nUsing the emulator, we follow the deobfuscation routine to address 0x000114AF. At this address, the deobfuscated code\r\nlooks different and makes more sense than the code prior to running through deobfuscation, see Figure 3 . This is the\r\nbeginning of the rootkit loader.\r\nFigure 3: View of the disassembled code at the rootkit loader's entrypoint before and after deobfuscation.\r\nhttps://www.usenix.org/legacy/event/hotbots07/tech/full_papers/chiang/chiang_html/index.html\r\nPage 3 of 11\n\nThe Rootkit Loader\r\nAfter a careful study of the code contained within the rootkit loader, we learn it takes the following steps:\r\n1. Searches for the ntoskernl.exe image in memory and imports the functions: ExAllocatePool,\r\nZwQuerySystemInformation, ExFreePool, and stricmp.\r\n2. Using these imported functions, the malware allocates a chunk of memory of about 34k (0x8800 bytes) and\r\ndeobfuscates the memory chunk starting at address 0x00011926 into the allocated memory. The deobfuscation\r\nroutine used at this stage (DOBF Routine 2 in Figure 2 ) can be recognized by the parameters passed to the\r\nfunction; they are the address of the encrypted 0x8800 bytes embedded in the binary and the address of the 0x8800\r\nbytes of newly allocated memory. The deobfuscation routine is called at 0x00011593. The deobfuscated memory\r\nturns out to be another PE executable, which is then mapped back to location 0x00011926. This executable is the\r\nembedded rootkit component that we will discuss in section  .\r\n3. Using the PE header of the embedded rootkit component starting at 0x00011926, the rootkit loader sets up the import\r\ntables by using the strings table located within the deobfuscated rootkit component. Some example function names\r\nare ZwEnumerateKey, ZwCreateKey, and ZwQueryKey. These functions will be used by the rootkit component later to\r\nhide itself. The rootkit loader then does any necessary relocation using the relocation section of the embedded binary.\r\n4. Since the rookit component is now decoded and mapped into the malware, its PE header is no longer needed.\r\nTherefore, in an attempt to defeat RAM forensics, the rootkit loader deletes the MZ and PE signatures bytes from the\r\ndecoded rootkit executable from memory before passing control to the embedded rootkit binary.\r\n5. The rootkit loader now jumps to 0x00011D92, the entry point of the rootkit component, which will be discussed next.\r\nThe Rootkit Component\r\nThe rootkit component's primary purpose is to hide traces of itself from the user. For example, in our dynamic test\r\nenvironment, the registry key HKLM\\system\\CurrentControlSet\\services\\pe386 used to start the malware disappears\r\nfrom the registry as soon as the malware is loaded. A detailed discussion of the rootkit's functionality is outside of the scope\r\nof this paper, however, a general discussion of the steps it takes that lead up to the extraction and execution of the spam\r\ncomponent is discussed here.\r\nThe rootkit component entry function at 0x00011D92 takes two arguments:\r\nhttps://www.usenix.org/legacy/event/hotbots07/tech/full_papers/chiang/chiang_html/index.html\r\nPage 4 of 11\n\nA pointer to an object representing the original malware driver file, i.e. lzx32.sys. It appears that this object is\r\ncreated by the Windows operating system when driver files are loaded into memory as a service.\r\nThe registry path pointing to the registry key that loaded the malware driver file into the operating system. This path\r\nis Unicode encoded.\r\nKnowing that the first argument is a pointer to the file object representing the original malware driver file is key in\r\nunderstanding how a modular component can be loaded and executed by the rootkit component.\r\nAfter storing the two arguments in global variables, a system thread is created. This thread has the following functionality:\r\n1. Creates a handle to the rootkit kernel driver named: \\BaseNamedObjects\\{DC5E72A0-6D41-47E4-C56D-024587F4523B} (Since this handle name is hard-coded into the binary, it may serve as a way to detect the presence of\r\nthe rootkit module).\r\n2. Checks whether the loaded malware driver file is stored in an Alternate Data Stream (ADS).\r\n3. Deletes all sub-keys in the hive: HKLM\\system\\CurrentControlSet\\Enum\\Root\\Legacy_lzx32.sys\r\n4. Replaces the registry functions to hide the registry key created to load the malware at boot.\r\n5. Creates a notify routine using PsSetCreateProcessNotifyRoutine which gets called for all process activity. This\r\nnotify routine creates at most two threads to inject the spam component into the services.exe process. By doing this,\r\nthe malware ensures its survivability.\r\n6. The rootkit then replaces the ZwQuerySystemInformation, and ZwTerminateProcess functions.\r\n7. The same routine that injects the spam component discussed in step 5 is called at this point to start the spam\r\ncomponent. This routine will be discussed in detail next.\r\nThe spam component is encrypted and appended to the original driver file lzx32.sys. The rootkit uses the first argument to\r\nextract this encrypted executable. One way to detect the presence of the appended component is to parse the PE header of\r\nthe original malware driver file. By so doing, one will notice that there is additional data past the end of the PE executable.\r\nTo extract and decrypt the appended data, the rootkit takes the following steps:\r\n1. Reads the last four bytes of the original file, this is the size of the encrypted and compressed executable, we will call\r\nit bot_compressed_size.\r\n2. Moves the file pointer back by bot_compressed_size + 4, and reads in four bytes that represent the xor key.\r\n3. Reads in the next four bytes after the xor key, this is the uncompressed size of the appended file, we will call it\r\nbot_uncompressed_size.\r\n4. The xor key is then used to xor-decrypt the data four bytes at a time, starting from the byte after\r\nbot_uncompressed_size.\r\n5. Allocates and uses a memory chunk of size bot_uncompressed_size, the xor-decrypted data is then deobfuscated\r\nusing deobfuscation routine 3 (DOBF Routine 3 is the same as DOBF Routine 2).\r\nThe resulting file is another PE executable that is the modular spam bot component. To properly extract this module, it is\r\nimportant to use the size variables detailed above. Using the wrong sizes results in an incomplete spam module.\r\nIt was previously mentioned that the spam module is injected into the services.exe process, this is another step taken by\r\nthe malware to thwart detection. The rootkit component follows these steps to inject the module into the services.exe\r\nprocess:\r\n1. Finds the process ID of services.exe by using the ZwQuerySystemInformation API function to return all system\r\nthread and process information and searching the returned results. Once found the process ID is stored in a global\r\nvariable.\r\n2. Creates another copy of the services.exe process.\r\n3. Sets up networking capabilities by hooking the tcpip.sys, wanarp.sys, and ndis.sys driver functions.\r\n4. Extracts, decrypts, and deobfuscates the spam module as described above.\r\n5. Maps the spam module into non-paged allocated memory.\r\nhttps://www.usenix.org/legacy/event/hotbots07/tech/full_papers/chiang/chiang_html/index.html\r\nPage 5 of 11\n\n6. Calls KeAttachProcess to switch the memory context to the services.exe process.\r\n7. The rootkit then sets up an asynchronous procedural call that provides a method to run the spam module code.\r\nThe Spam Module\r\nNow that we have extracted and decrypted the spam module, we use our observations of the network traffic generated by the\r\nbot and our dynamic analysis to determine where to focus our static analysis. We target the function calls that post to the\r\nlogin.php and data.php server files. By analyzing these functions with the knowledge that the symmetric encryption\r\nalgorithm is RC4, we are able to locate the code that randomly generates the session key and a location where the prepared\r\nform of the RC4 session key is stored in memory.\r\nThe RC4 encryption algorithm consists of two main parts, the key-scheduling algorithm, and the pseudo-random generation\r\nalgorithm [12]. To generate the keystream the two algorithms make use of an internal state consisting of two parts, a\r\npermutation of all 256 possible bytes, and two 8-bit index pointers. By comparing the two functions found within the\r\nassembly code with a C code implementation of RC4 [13], we are able to determine that the assembly functions are direct\r\nimplementations of the two algorithms that make up RC4. Additionally, the struct stored in global memory is the secret\r\ninternal state consisting of a 256 byte char array and two index pointers into the array. The function containing the key-scheduling algorithm is called once during login.php. This function initializes the internal state variable and stores it in the\r\nglobal struct. The session key itself is not stored in global memory and is therefore difficult to extract. Fortunately, having\r\nthe internal state variables is as good as having the original key generated by the infected host.\r\nThe code snippet in Figure 4 is from the IDA pro disassembly and shows the instructions leading up to the storage of the\r\nglobal struct containing the state variables. We have named the global struct g_prepped_session_key.\r\nFigure 4: Disassbled code for the routine that stores the prepared session key in a global struct. The hex equivalent of the\r\nfirst 4-bytes of the highlighted code is used to generate a signature that will be used later to extract the prepared key.\r\nThe instruction jz short loc_405CE4 is the instruction that precedes the code that prepares the session key and stores it in\r\nglobal memory. Converting this instruction and subsequent instructions to hexadecimal results in a unique signature 0x74\r\n0x11 0xA1 0x64 that we will use later to search and extract from memory the internal state variables used to decrypt the\r\nencrypted network communications.\r\nhttps://www.usenix.org/legacy/event/hotbots07/tech/full_papers/chiang/chiang_html/index.html\r\nPage 6 of 11\n\nKey Extraction\r\nNow that we know what we are looking for we need to search through memory to find the RC4 internal state variable. Based\r\non information gathered through the analysis of the rustock rootkit we know that the spam module is injected into the\r\nservices.exe process. A thorough overview of live memory forensics is beyond the scope of this paper but we will discuss\r\none method we used to extract the RC4 state variable from the memory of a running machine infected with the spam bot.\r\nWe used Microsoft's User Mode Process Dumper [14] to dump the memory space of the services.exe process to a file.\r\nTiming of the memory dump is critical since it must occur after the key exchange and instruction phases of the C\u0026C session\r\nbut before the next key exchange. Because the client typically initiates another C\u0026C session with the server every few\r\nminutes it is important to keep track of the various sessions and the corresponding memory dumps. In order to prevent the\r\npossibility of the state variable being overwritten one could use a remote kernel debugger to break execution after the C\u0026C\r\nsession has completed rather than dumping the memory. The disadvantage of this method is that it affects the timing of\r\nsubsequent C\u0026C sessions and could be noticed by the server.\r\nOnce we have a memory dump and a corresponding network capture of the C\u0026C session, we load the memory dump into\r\nMicrosoft's windbg [15]. The log file shown in Figure 5 enumerates the steps we took to extract the key. First, we locate\r\nthe signature isolated in the previous section (0x74 0x11 0xA1 0x64). Next, we disassemble several instructions starting at\r\nthe memory address we just found. The mov instruction at address 0x00d35cd3 loads a pointer to the struct containing the\r\nRC4 state variables, so to find the key we simply dereference the pointer. Finally we dump the state variables to a file.\r\nFigure 5: windbg log file with comments. This shows how to extract the RC4 state variables from memory.\r\nDecryption\r\nNow that we have the RC4 state variables we decrypt the C\u0026C communications. For each call to the data.php routine,\r\nthere are two parts. First, the client copies the global struct containing the RC4 state variables to a local instance located on\r\nhttps://www.usenix.org/legacy/event/hotbots07/tech/full_papers/chiang/chiang_html/index.html\r\nPage 7 of 11\n\nthe stack and calls the RC4 encryption/decryption function on the string it wishes to encrypt. The C\u0026C server receives the\r\nencrypted payload and decrypts it. Both the encryption on the client end and the decryption on the server end modify the\r\nstate variables in precisely the same fashion, so the state is synchronized on both ends before and after\r\nencryption/decryption. From this point the server encrypts the response using the modified state variables and sends it to the\r\nclient where it is decrypted. Again, the state variables are modified in the same way on both the server and client ends. Each\r\ncall to the data.php function starts with a fresh copy of the global state variable struct.\r\nTo decrypt the captured C\u0026C session we use the global struct we have extracted from the memory dump containing the state\r\nvariables. We modify the C code implementation of RC4 [13] to read the key-scheduling state variables from disk rather\r\nthen generating a new instance. For us to decrypt the communication we need to apply the RC4 encryption/decryption\r\nfunction (pseudo random generation algorithm) to the POST message from the client followed by the response from the\r\nserver. This keeps the state variables synchronized and allows us to decrypt both sides of the communication. Each exchange\r\nconsisting of a POST to data.php and reply from the server can be decrypted separately since the state variable is copied\r\nfrom the global struct to the stack each time.\r\nOne thing to note is that the first fourteen bytes of the client message are ignored when encrypting the message. This was\r\nnoticed during the static analysis of the spam module. In order to keep the state variables synchronized, we also must ignore\r\nthe first fourteen bytes of the message.\r\nTable 1 is a summary of a sample C\u0026C session we decrypted and consists of seven data exchanges. The client initiates the\r\nconversation by sending the \"kill.txt\" string for which the server responds with a list of processes to terminate and files to\r\ndelete from the client. Some examples of processes are CAPP.exe, syswire.exe, Ravmond.exe. Some examples of files are\r\nm_hook.sys, comdlj32.dll, and secure32.html. Web searches for the processes and file names indicate that these are\r\nother malicious programs that the client may be infected with. This provides a way to eliminate other infections that may\r\nconflict with this bot.\r\nTable 1: Summary of decrypted C\u0026C communications between the infected client and the server.\r\nMessage Message Contents or Summary\r\nClient 1 \"kill.txt\"\r\nServer 1 Server response specifies processes to terminate and files to delete from the client\r\nClient 2 Information about the client\r\nServer 2\r\nInformation for the client about the client and file names to create or request for subsequent\r\ncommunications with the server\r\nClient 3 \"neutral.txt\"\r\nServer 3 List of domain names to query for mail servers to use\r\nClient 4 \"unlucky.txt\"\r\nServer 4 List of SMTP server responses that indicate failure\r\nClient 5 \"tmpcode.bin\"\r\nServer 5 Binary data that specifies the formatting of spam message to be sent by the client\r\nClient 6 \"tmpcode.bin\"\r\nServer 6 Binary data including spam content\r\nClient 7 \"-\"\r\nhttps://www.usenix.org/legacy/event/hotbots07/tech/full_papers/chiang/chiang_html/index.html\r\nPage 8 of 11\n\nServer 7 List of target email addresses\r\nNext, the client sends information about itself to the server including bandwidth, OS version, SMTP availability (if\r\noutbound TCP/25 is allowed), if it is a virtual machine, and if it is blacklisted on a DNS blacklist. The server responds with\r\nadditional information including the client's external IP address, machine name, task id that the server assigns to the client\r\nfor a given spamming job, whether an update of the client is available, and names of additional command strings that the\r\nclient can use for subsequent communications. An example of the command strings are \"filesnames=neutral.txt\" and\r\n\"unluckystrings=unlucky.txt\".\r\nThe next packet sent by the client is \"neutral.txt\", this request results in a list of domain names from the server. The client\r\nputs these domain names in a double-linked list and queries them for the presence of mail servers.\r\nThe fourth client request in this session is \"unlucky.txt\". This request results in a list of error messages that an SMTP server\r\ncould return. Some examples are \"Please use your provider SMTP\" and \"your mail rejected\"\r\nIn the fifth and sixth exchange, the client sends the request string \"tmpcode.bin\" and the server responds with binary code\r\nand spam content that is used by the client to generate spam messages that are dynamic in nature to bypass spam filters.\r\nFinally, in the last session, the client send a single dash (\"-\") to which the server responds with a list of email addresses\r\nwhere spam messages will be sent.\r\nConclusions\r\nRustock is an advanced piece of malware used to effectively hide criminal activity. The rootkit technology employed makes\r\nit difficult to detect the infection at the host level. The use of encrypted HTTP for C\u0026C makes it difficult to detect at the\r\nnetwork level. Even after detection of the malware, the multiple levels of obfuscation makes it difficult for analysts to find\r\ninformation about the C\u0026C servers to generate signatures.\r\nBased on our observation that the starting address of the deobfuscated code changed between versions of lzx32.sys as well\r\nas different obfuscation techniques we conclude that the outer most binary packer/obfuscator was changed. It is likely that\r\nthe reason for this is that the authors of the code were attempting to avoid antivirus detection as well as to increase the\r\namount of time that it takes to deobfuscate the code. Our technique for deobfuscation was not affected much by the different\r\ntechniques since we step through the code using an emulator.\r\nOur analysis of the C\u0026C communications indicates ordinary spam bot functionality. Aside from this functionality the spam\r\nmodule also has the ability to download and execute arbitrary code. This could be used for other nefarious purposes. In\r\naddition, the modular design of the rootkit and embedded spam module makes it easy to update the spam module. During\r\nour experiments, we observed multiple updates to the spam module. These updates were confined to changes of C\u0026C server\r\ndomain names and search terms used to build the spam, but it indicates that it would be simple for those controlling the\r\nbotnet to update the module with other features.\r\nFuture Work\r\nMore work is needed to see if automated unpacking tools such as PolyUnpack [16] could be used to quickly deobfuscate the\r\nvarious binaries contained within lzx32.sys. This would greatly reduce the amount of time needed to analyze future\r\nversions of rustock.\r\nFuture work is also needed to better understand the details of the rustock rootkit. Since our focus was on getting to the spam\r\nmodule, we did not do a detailed analysis on the rootkit itself. Further details can be found in [9]. One element of the rootkit\r\nthat needs more analysis is the alternative behavior exhibited when the malware driver detects that it is not stored in an ADS.\r\nAdditional work should be done to automate the key extraction and C\u0026C decryption. One way to do this would be to\r\ncontinually monitor the network traffic from an infected client. Anytime a post to login.php is seen, a remote procedure\r\nhttps://www.usenix.org/legacy/event/hotbots07/tech/full_papers/chiang/chiang_html/index.html\r\nPage 9 of 11\n\ncall could be initiated to the infected host to dump the memory space of the services.exe process. Given the network\r\ncaptures and memory dumps it would be easy to write a script to extract the key from the dumps and decrypt the C\u0026C\r\ncommunications in a way similar to our method.\r\nAcknowledgments\r\nWe wish to express our appreciation to the people at Symantec who gave us several pointers about the deobfuscation of the\r\nrustock rootkit and helped us identify the encryption algorithm. We would also like to thank Chris Eagle from the Naval\r\nPostgraduate School for his tips on deobfuscation techniques and in using the idax86emu plugin for IDA Pro.\r\nBibliography\r\n1\r\nPaul Bacher, Thorsten Holz, Markus Kotter, and Georg Wicherski, Know Your Enemy: Tracking Botnets,\r\nhttps://www.honeynet.org/papers/bots/, (2005).\r\n2\r\nPaul Barford and Vinod Yegneswaran, An Inside Look at Botnets,\r\nhttps://www.cs.wisc.edu/~pb/botnets_final.pdf\r\n3\r\nNicholas Ianelli and Aaron Hackworth, Botnets as a Vehicle for Online Crime,\r\nhttps://www.cert.org/archive/pdf/Botnets.pdf, (2005).\r\n4\r\nPhatbot Trojan Analysis, LURHQ Threat Intelligence Group, https://www.lurhq.com/phatbot.html, (2004).\r\n5\r\nSinit P2P Trojan Analysis, LURHQ Threat Intelligence Group, https://www.lurhq.com/sinit.html, (2004).\r\n6\r\nRobert Lemos, Bot software looks to improve peerage, SecurityFocus,\r\nhttps://www.securityfocus.com/news/11390, (2006).\r\n7\r\nBackdoor.Rustock.B, Symantec, https://www.sarc.com/avcenter/venc/data/backdoor.rustock.b.html,\r\n(2006).\r\n8\r\nSpam-Mailbot.c, McAfee, https://vil.nai.com/vil/content/v_140181.htm, (2006).\r\n9\r\nFrank Boldewin, A Journey to the Center of the Rustock.B Rootkit,\r\nhttps://www.reconstructer.org/papers/A%20Journey%20to%20the%20Center%20of%20the%20Rustock.B%20Rootkit\r\n(2007).\r\n10\r\nIDA Pro, https://www.datarescue.com/idabase\r\n11\r\nThe x86 Emulator plugin for IDAPro, Chris Eagle, https://ida-x86emu.sourceforge.net\r\n12\r\nBruce Schneier, Applied Cryptography: Protocols, Algorithms, and Source Code in C, Second Edition, John Wiley\r\nand Sons, New York, NY, (1996).\r\n13\r\nRC4 C source code, https://www.cypherspace.org/adam/rsa/rc4.c\r\n14\r\nMicrosoft User Mode Process Dumper, https://www.microsoft.com/downloads/details.aspx?\r\nFamilyID=E089CA41-6A87-40C8-BF69-28AC08570B7E\u0026displaylang=en\r\n15\r\nhttps://www.usenix.org/legacy/event/hotbots07/tech/full_papers/chiang/chiang_html/index.html\r\nPage 10 of 11\n\nMicrosoft windbg, https://www.microsoft.com/whdc/devtools/debugging/default.mspx\r\n16\r\nPaul Royal, Mitch Halpin, David Dagon, Robert Edmonds, and Wenke Lee, PolyUnpack: Automating the Hidden-Code Extraction of Unpack-Executing Malware. In Proceedings of the 22nd Annual Computer Security Applications\r\nConference (ACSAC 2006) (December 2006).\r\nSandia National Laboratories\r\nSandia is a multiprogram laboratory operated by Sandia Corporation, a Lockheed Martin Company, for the United\r\nStates Department of Energy's National Nuclear Security Administration under Contract DE-AC04-94AL85000.\r\nLevi Lloyd 2007-04-03\r\nSource: https://www.usenix.org/legacy/event/hotbots07/tech/full_papers/chiang/chiang_html/index.html\r\nhttps://www.usenix.org/legacy/event/hotbots07/tech/full_papers/chiang/chiang_html/index.html\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.usenix.org/legacy/event/hotbots07/tech/full_papers/chiang/chiang_html/index.html"
	],
	"report_names": [
		"index.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434505,
	"ts_updated_at": 1775791267,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d97ce2059accb3ad84943994bfe7d551a1849f43.pdf",
		"text": "https://archive.orkl.eu/d97ce2059accb3ad84943994bfe7d551a1849f43.txt",
		"img": "https://archive.orkl.eu/d97ce2059accb3ad84943994bfe7d551a1849f43.jpg"
	}
}