{
	"id": "196497bf-c352-4145-96df-91eeb468728d",
	"created_at": "2026-04-06T00:14:28.957603Z",
	"updated_at": "2026-04-10T13:12:53.797037Z",
	"deleted_at": null,
	"sha1_hash": "cfe350f137a4a79195fce4de1abccf12a6cdc89b",
	"title": "Injection as a way of life",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1469704,
	"plain_text": "Injection as a way of life\r\nBy Raul AlvarezFortinet, USAEditor: Helen Martin\r\nArchived: 2026-04-05 17:34:58 UTC\r\n2010-09-01\r\nAbstract\r\nInjecting code into a process is not a new technology, but it is still used by most prevalent malware today. Raul\r\nAlvarez dissects two examples of recent prevalent malware and shows how they inject their code into a running\r\nprocess.\r\nCopyright © 2010 Virus Bulletin\r\nMemory-residency is employed by malware to ensure that it is always active on the system. Techniques have been\r\ntried and tested; the good old DOS infector used Terminate and Stay Resident – TSR (using the infamous INT 21h\r\nfunction 31h) – and another well-known technique is code injection. Injecting code into a process is not a new\r\ntechnology, but it is still used by most prevalent malware today.\r\nThe main idea behind code injection is that the malware embeds itself into a running process to maintain\r\nresidency. Well, of course we already know that. Behavioural analysis can tell us that a certain application has\r\nbeen infected; we use different tools to determine if a thread has been injected into a certain process. And lots of\r\nmalware analysis online will tell us that a given piece of malware injects its code into a running process. But little\r\nhas been said about the actual code-by-code steps that malware uses to inject its code.\r\nThis article will dissect two examples of recent prevalent malware and show how they inject their code into a\r\nrunning process. We will start with a variant of Virut, detected by Fortinet as W32/Virut.CE, which uses Zw***\r\nAPIs to implement code injection. Then we will explain how a variant of OnlineGames embeds its code into the\r\nExplorer.exe process.\r\nPart I: Virut, Virut and Virut\r\nVirut’s code injection starts by modifying the access token’s privilege; the access token contains the security\r\ninformation for a logon session. Every time a user logs on, the system generates an access token which is also\r\nused by every process and application executed by the current user.\r\nVirut uses the ZwOpenProcessToken API in order to get the handle for the access token of the user. After\r\nacquiring the handle of the token, Virut resolves the address of the LookupPrivilegeValueA API by using the\r\nLoadLibrary and GetProcAddress APIs. Virut calls for the LookupPrivilegeValueA API to get the locally unique\r\nidentifier (LUID) for SeDebugPrivilege, also known as SE_DEBUG_NAME; this is a privilege required for\r\nmemory modification of a given process, which Virut needs to freely inject its code. This is immediately followed\r\nhttps://www.virusbulletin.com/virusbulletin/2010/09/injection-way-life/\r\nPage 1 of 10\n\nby a call to the ZwAdjustPrivilegesToken API, which adjusts the privilege of the access token based on the new\r\nLUID.\r\nSetting the privilege of the access token to SeDebugPrivilege enables Virut to perform code injection with ease;\r\nthe malware doesn’t need to concern itself with any issue regarding the opening of a process, writing to it,\r\nhooking code in its shared memory space, creating threads and executing instructions. Once the privilege is set to\r\nthe proper attributes, Virut proceeds to enumerate the running processes.\r\nBrowsing active processes\r\nVirut is a polymorphic virus, and after decryption and resolving the necessary APIs we can see that most variants\r\ndon’t go far from their intended purpose.\r\nA typical way to enumerate the active processes in a given system starts with a call to the\r\nCreateToolhelp32Snapshot API; Virut calls the CreateToolhelp32Snapshot API to get a snapshot of the system.\r\nUsing this API, a piece of malware can get a snapshot of every module, thread, heap and process, all depending on\r\nthe dwFlags parameter supplied to it; Virut uses TH32CS_SNAPPROCESS to include all processes in the system.\r\nThe malware enumerates the processes one by one using a single call to the Process32First API and concurrent\r\ncalls to the Process32Next API. These two APIs use the PROCESSENTRY32 structure generated by the\r\nCreateToolhelp32Snapshot API which was called earlier (see Figure 1).\r\nFigure 1. Code snippets on enumerating the active processes and the skipping of the first four processes.\r\nWhile enumerating the list of processes, Virut intentionally skips the first four processes without even checking\r\ntheir names. Interestingly, most often, the Winlogon.exe process is the fifth on the list. Winlogon is the first\r\nprocess into which Virut injects its code; Winlogon is infected not by choice but for the simple reason that it is one\r\nof the first processes available for Virut infection.\r\nThe next logical step, after acquiring the handle of the process to infect, is to open it. Virut opens the process by\r\ncalling the OpenProcess API with the CREATE_THREAD|VM_OPERATION|VM_WRITE access parameter; this\r\nhttps://www.virusbulletin.com/virusbulletin/2010/09/injection-way-life/\r\nPage 2 of 10\n\nenables the malware to create a thread in the given process and to write the codes to inject.\r\nMapping a section of memory\r\nBefore the code injection stage, Virut creates a section of memory named \\BaseNamedObjects\\houtVt; this\r\ncontains the complete code to be injected into the process. This is evident on any process that has already been\r\ninjected with Virut’s code. Process Explorer or any tool that can show the events, keys, sections and other objects\r\nof a process can be used to determine if the process is already infected.\r\nSince the section already exists, Virut calls the ZwMapViewOfSection API to map a copy of\r\n\\BaseNamedObjects\\houtVt to the current process that it is working on. The actual Virut code is copied to the\r\nprocess’s memory space by mapping the section of memory. Mapping a section of memory is like sharing a DLL\r\nin a process’s memory space, thereby giving Winlogon (or other process) access rights to the section. Any viable\r\ncode within the \\BaseNamedObjects\\houtVt section can now be executed by any process that maps it; calling a\r\nfunction from within the section is just a matter of pointing it to the right memory address.\r\nFigure 2. The mapped section named \\BaseNamedObjects\\houtVt in the Winlogon.exe process.\r\nHooking NTDLL.dll\r\nHooking is an old technique used by malware; old DOS viruses hooked INT functions to redirect calls to their\r\ncode and new malware hooks DLL functions in a similar way. When a call to the hook function is performed,\r\nexecution transfers to the malware code, which is executed, and then control is transferred back to the original\r\nfunction routine; this is basically what happened to the hooked function.\r\nVirut hooks some APIs from NTDLL, of a given process, simply by replacing the MOV EAX,yy instruction with\r\na CALL xxxxxxxx, an address pointed to by the mapped \\BaseNamedObjects\\houtVt section. It uses the\r\nZwProtectVirtualMemory to change the protection mode of NTDLL attached to the process to\r\nPAGE_READWRITE mode then proceeds to hook it by writing the CALL instruction using\r\nZwWriteVirtualMemory. The PAGE_READWRITE mode ensures that the shared NTDLL can be written to by a\r\ncall to ZwWriteVirtualMemory.\r\nVirut hooks the following APIs:\r\nhttps://www.virusbulletin.com/virusbulletin/2010/09/injection-way-life/\r\nPage 3 of 10\n\nZwCreateFile\r\nZwOpenFile\r\nZwCreateProcess\r\nZwCreateProcessEx\r\nZwQueryInformationProcess\r\nBy hooking the APIs above, Virut’s code becomes available whenever a file is read, opened or created, and\r\nwhenever a process is opened, created or queried.\r\nFigure 3. The hooked NTDLL.dll; the green boxes are the normal codes and the red box is the hooked\r\nZwCreateFile API; the MOV instruction was replaced by a call to the mapped section.\r\nRunning the thread\r\nOnce everything is set – privileges have been set up, a process has been selected to infect, a section of memory\r\nhas been mapped, and DLL hooked – the last thing for Virut to do is to execute a thread remotely.\r\nVirut creates a remote thread using a call to CreateRemoteThread, with dwCreationFlags equal to 0. It executes\r\nthe thread immediately. When a remote thread is created, it can be suspended or, in this case, executed\r\nimmediately. Virut executes the thread as soon as it is created to speed up the infection process. When all is well,\r\nVirut relinquishes its control to the process and proceeds to look for a new process to inject its code into. As we\r\nhttps://www.virusbulletin.com/virusbulletin/2010/09/injection-way-life/\r\nPage 4 of 10\n\nnow know, Virut doesn’t only infect the Winlogon.exe process; it keeps looking for more processes to inject code\r\ninto.\r\nFigure 4. Strings found in services.exe’s process indicative of Virut’s mapped section\r\nAs discussed earlier, we can easily check if a process is infected by looking for the presence of the\r\n\\BaseNamedObjects\\houtVt section. To be certain, we can browse the process’s memory and look for a sign that\r\nVirut is really there. Most often, Virut’s favourite location is 7FF90000h and the size is 0A000h; however, some\r\nprocesses use that location, so Virut uses the next location on the block, 7FFA0000h, with the same virus size.\r\nVirut’s code within the process’s memory is not encrypted, thereby giving us the strings to look for. We can see\r\nstrings like AV company names, the name of the section, resolved names of APIs, IRC-related strings, and registry\r\nkey strings.\r\nVirut’s method of code injection is fairly common amongst malware. That being said, we will now look at another\r\nmethod of injecting code.\r\nPart II: Online Gaming\r\nThe next piece of malware we will look at is a variant of OnlineGames. Most malware families have their own\r\nstyle of decryption routine, and the same is true when it comes to the process of code injection. We have already\r\nhttps://www.virusbulletin.com/virusbulletin/2010/09/injection-way-life/\r\nPage 5 of 10\n\nnoted that a variant of Virut skips the first four processes and injects its code into Winlogon.exe and succeeding\r\nprocesses after that. In this variant of OnlineGames, Explorer.exe is the sole target.\r\nWe will discuss some commonalities of Virut and OnlineGames when selecting the process for injection, how\r\ncodes are copied to the process’s memory space and what the remote code looks like before it is executed in the\r\nprocess.\r\nChoosing Explorer.exe\r\nLike Virut, OnlineGames uses the CreateToolhelp32Snapshot to enumerate the processes active in the system –\r\nusing TH32CS_SNAPPROCESS as the dwFlags parameter. Although the malware knows what process to infect,\r\nit still uses the same pair of Process32First and Process32Next APIs to locate the pID (process ID) of\r\nExplorer.exe.\r\nInterestingly enough, the malware has a longer code routine just to copy a string (process name) to a memory\r\nlocation; it also has a longer code routine comparing the process name to look for the ‘Explorer.exe’ string. Instead\r\nof copying the string using a single instruction, the malware copies it, character by character, to the memory. To\r\ncompare the string, the malware first counts the number of characters of the name of the given process and\r\ncompares it to the length of the ‘Explorer.exe’ string. If the size of the two strings matches, then it proceeds to\r\ncheck each character of both strings. After a successful attempt at getting the right process name, ‘Explorer.exe’,\r\nthe malware captures the pID of the process.\r\nThe pID of Explorer.exe is now used by OpenProcess, with an access parameter of PROCESS_ALL_ACCESS –\r\nall possible access rights.\r\nWriting codes to process\r\nVirut’s method of putting its codes into memory is by mapping the entire \\BaseNamedObjects\\houtVt section and\r\nhooking NTDLL.dll APIs linking to the mapped section. In comparison, OnlineGames uses the\r\nWriteProcessMemory API to write codes into the Explorer.exe process. But in this respect, the code written to the\r\nprocess’s memory space is not the whole virus code yet.\r\nhttps://www.virusbulletin.com/virusbulletin/2010/09/injection-way-life/\r\nPage 6 of 10\n\nFigure 5. Code snippet showing the call to the OpenProcess, VirtualAllocEx and WriteProcessMemory\r\nAPIs. It also shows a certain call to a memory location, 00401D20, where the pID searching can be found.\r\nLastly, it shows where the length of the codes, 457h(1111), is used.\r\nBefore OnlineGames writes some of its code to the process, it uses the VirtualAllocEx API to reserve some\r\nmemory space from the process; the resulting value is the base address where OnlineGames can write to. It then\r\nproceeds to write 457h(1111) bytes of code – which, of course, is not the whole virus code.\r\nIntercepting the Remote Thread\r\nThe WriteProcessMemory API is only called once within the malware body; it only writes 457h(1111) bytes of\r\ncode. We can only assume that there should be more to it than just writing that small piece of code. Does\r\nOnlineGames use the same technique of mapping a section of memory to the running process as Virut? The\r\nanswer is no, OnlineGames doesn’t use memory mapping and it doesn’t hook any functions in NTDLL, or any\r\nDLL for that matter. But how can OnlineGames copy the whole malware code to Explorer.exe? The answer lies in\r\nthe 457h bytes of memory the malware wrote earlier.\r\nThe only logical way to look for the answer is to intercept the execution of the 457h mystery bytes. A remote\r\nthread is created when OnlineGames uses the CreateRemoteThread API; it points to the base address, the starting\r\naddress of the 457h bytes of code taken from the call to VirtualAllocEx API earlier. Once the thread is created and\r\nExplorer.exe is within a debugger, such as OllyDbg, we will see a message box displaying ‘Module “cvasds0” has\r\nentry point outside the code (as specified in the PE header). Maybe this file is self-extracting or self-modifying.\r\nPlease keep it in mind when setting breakpoints!’ (see Figure 6). Note that the message will only show when\r\nExplorer.exe is within a debugger context.\r\nhttps://www.virusbulletin.com/virusbulletin/2010/09/injection-way-life/\r\nPage 7 of 10\n\nFigure 6. Message displayed when CreateRemoteThread API from OnlineGames was executed.\r\nKnowing that a file named ‘cvasds0’ is being accessed by Explorer.exe, it is safe to say that it is the same malware\r\nfile that we are looking for. We haven’t intercepted the code yet, so we need to go back and execute the\r\nCreateRemoteThread API; this time we are in intercept mode. Figure 8 shows a snippet of the intercepted code,\r\nthe 457h bytes of code copied earlier using the WriteProcessMemory API.\r\nFigure 7. Memory map of the ‘Explorer.exe’ process within OllyDbg. It shows the map view of\r\n‘Explorer.exe’ and the new file ‘cvasdds0’.\r\nhttps://www.virusbulletin.com/virusbulletin/2010/09/injection-way-life/\r\nPage 8 of 10\n\nFigure 8. Code snippet of 457h bytes of code copied to the memory space of Explorer.exe, showing the call\r\nto the LoadLibraryA API and the string ‘Game_start’.\r\nThe 457h bytes of code is responsible for loading ‘cvasds0’ into the Explorer.exe process; it calls the\r\nLoadLibraryA API to load the file, actually a DLL, that can be found at the ‘c:\\DOCUME~1\\\r\n[varies]\\LOCALS~1\\Temp\\’ folder. ‘cvasds0.dll’ is a DLL file dropped by OnlineGames at an earlier stage of the\r\nmalware’s execution. The 457h bytes of code also contains the string ‘Game_start’, which is encoded character by\r\ncharacter.\r\nConclusion\r\nWe have seen two different pieces of malware, each demonstrating different skills in performing code injection.\r\nThey both start off by using the basic techniques of enumerating, searching and opening a process. Then, they\r\neach go a different way when they start preparing the code to be injected. Virut has chosen to map its code to the\r\nhttps://www.virusbulletin.com/virusbulletin/2010/09/injection-way-life/\r\nPage 9 of 10\n\nprocess and hook NTDLL, while OnlineGames has chosen to inject a small amount of code into Explorer.exe and\r\nlet it load its complete code in a library form. There are several more tricks for code injection out there; we will\r\nencounter them in one way or another, yet they will always have one thing in common - the process.\r\nSource: https://www.virusbulletin.com/virusbulletin/2010/09/injection-way-life/\r\nhttps://www.virusbulletin.com/virusbulletin/2010/09/injection-way-life/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.virusbulletin.com/virusbulletin/2010/09/injection-way-life/"
	],
	"report_names": [
		"injection-way-life"
	],
	"threat_actors": [],
	"ts_created_at": 1775434468,
	"ts_updated_at": 1775826773,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/cfe350f137a4a79195fce4de1abccf12a6cdc89b.pdf",
		"text": "https://archive.orkl.eu/cfe350f137a4a79195fce4de1abccf12a6cdc89b.txt",
		"img": "https://archive.orkl.eu/cfe350f137a4a79195fce4de1abccf12a6cdc89b.jpg"
	}
}