{
	"id": "29469c6a-7b12-4a11-beb5-e75ff410d641",
	"created_at": "2026-04-06T00:11:09.612704Z",
	"updated_at": "2026-04-10T03:21:56.40078Z",
	"deleted_at": null,
	"sha1_hash": "bd612da9e3dfe4b98a0f21fc50c2cf967dca2641",
	"title": "Gootkit Banking Trojan | Part 2: Persistence \u0026 Other Capabilities - SentinelLabs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2727797,
	"plain_text": "Gootkit Banking Trojan | Part 2: Persistence \u0026 Other Capabilities\r\n- SentinelLabs\r\nBy Daniel Bunce\r\nPublished: 2019-08-29 · Archived: 2026-04-05 15:38:00 UTC\r\nFollowing on from the previous post, Daniel continues exploring the Gootkit banking trojan, revealing its\r\npersistence techniques and other capabilities.\r\nThe Gootkit Banking Trojan was discovered back in 2014, and utilizes the Node.js library to perform a range of\r\nmalicious tasks, from website injections and password grabbing, all the way up to video recording and remote\r\nVNC capabilities. Since its discovery in 2014, the actors behind Gootkit have continued to update the codebase to\r\nslow down analysis and thwart automated sandboxes.\r\nIn the previous post, I explored Gootkit’s Anti-Analysis features. In this post, we’ll take a look into the first stage\r\nof Gootkit and figure out how it achieves persistence on an infected system, as well as reveal some other tricks it\r\nhas available.\r\nMD5 of Packed Sample: 0b50ae28e1c6945d23f59dd2e17b5632\r\nOnboard Configuration\r\nBefore we get into the persistence and C2 communication routines, let’s first take a look at the onboard\r\nconfiguration, and how it is stored.\r\nhttps://www.sentinelone.com/blog/gootkit-banking-trojan-persistence-other-capabilities/\r\nPage 1 of 16\n\nThe first time that the configuration is “mentioned” in the sample is immediately after the anti-analysis\r\nmechanisms that were covered in the previous post. A quick glance at the code may leave you thinking that\r\nGootkit is decrypting some shellcode to be used by the sample – but running this in a debugger shows otherwise.\r\nThe decryption routine is fairly simple; a basic XOR loop with a differentiating key based on imul  and\r\nidiv  calculations. The base key value is 0x22 , and the idiv  and imul  values are constant throughout each\r\niteration; 0x85  and 0x03  respectively. A Python script of this decryption routine can be seen in the image\r\nbelow.\r\nhttps://www.sentinelone.com/blog/gootkit-banking-trojan-persistence-other-capabilities/\r\nPage 2 of 16\n\nAfter decrypting the data manually, we can easily distinguish that this is in fact the configuration used by Gootkit\r\nto retrieve the next stage:\r\nme.sunballast.fr koohy.top 2700 svchost.exe\r\nEach value is split by multiple null bytes, meaning pretty much all of this configuration is null bytes. The first two\r\nvalues are obviously URLs, and the final value is the name of the process that the downloader could inject into.\r\nThe last two values are also set as environment variables – specifically vendor_id\u0026 nbsp;and\r\nmainprocessoverride . The vendor_id variable is given the value exe_scheduler_2700 , and\r\nmainprocessoverride is given the value svchost.exe . These variables are not used in the downloader aside\r\nfrom setup, and so it can be assumed that it is used in the final stage. Once the environment variables have been\r\ncreated and assigned values, four important threads are kicked off; a C2 Retrieve thread, a Browser Injection\r\nthread, a Persistence thread, and a Kill Switch thread. Let’s start off with the Persistence thread.\r\nPersistence Capabilities\r\nhttps://www.sentinelone.com/blog/gootkit-banking-trojan-persistence-other-capabilities/\r\nPage 3 of 16\n\nIn this sample of Gootkit, there are two persistence options available. First, there is the usual method of achieving\r\npersistence through a created service. In this case, Gootkit will generate a random filename, using the Mersenne\r\nTwister, based off of filenames in System32 , and then proceed to create a file under the same name in the\r\n%SystemRoot% . Upon testing this function, a file called msfearch.exe was created. A service is then created\r\nunder the same name, and then executed. Finally, the original executable cleans up by deleting itself from disk and\r\nexiting, leaving the created service running.\r\nThe second persistence routine is a lot more interesting, and has been covered quite often before. This routine is\r\nmost commonly used in Gootkit infections, as creating a service requires administrator privileges – this does not.\r\nIt starts by creating a simple .inf  file, which is given the same name as the running executable, and placed in\r\nthe same directory. The contents of the file can be seen below:\r\nThen, the sample will create a registry key located at:\r\nhttps://www.sentinelone.com/blog/gootkit-banking-trojan-persistence-other-capabilities/\r\nPage 4 of 16\n\nSoftwareMicrosoftIEAKGroupPolicyPendingGPOs\r\nAnd then create three values inside this key: Count , Path1 , and Section1 . Count  is assigned the value\r\n0x1 , Path1 is assigned the path to the INF file, and Section1  is assigned the string [DefaultInstall] , which\r\nis also present inside the INF file. And that is the setup complete.\r\nThe way this functions is explorer.exe  will load Group Policy Objects (GPO) whenever it is loaded –\r\nspecifically at runtime. What Gootkit does is it creates a Pending GPO for the Internet Explorer Administration\r\nKit (IEAK), which points directly at the INF file. When explorer.exe  is loaded at runtime, it will execute the\r\n[DefaultInstall]  inside the created file, which will execute the Gootkit executable.\r\nLoader Update Thread\r\nWith the persistence thread covered, let’s move onto analyzing the C2 Receive thread. This was particularly\r\ndifficult to analyze due to the fact that the command and control server went offline very quickly, and so at first\r\nglance it looked like the thread was responsible for downloading the final stage and constantly updating it, but as I\r\ndug deeper, this was proven incorrect.\r\nhttps://www.sentinelone.com/blog/gootkit-banking-trojan-persistence-other-capabilities/\r\nPage 5 of 16\n\nThe function is not extremely complex – to put simply, Gootkit will check if a variable is set to 0 or 1, and if it is\r\nset to 1, it will exit the thread. This variable is only activated inside the Kill Switch  function, which we will\r\nlook at soon.\r\nContinuing on, the sample appends   /rpersist4/-1531849038  to the URL, where the -1531849038  is the\r\nCRC32 hash of the binary – converted to decimal. Then, depending on the architecture, rbody32  or\r\nrbody64  will be appended to the URL.\r\nThen the actual connection takes place. Interestingly, there are two means of communication as well – it can either\r\noccur through WinInet functions such as InternetOpenW , or it can occur through WinHTTP functions such as\r\nWinHttpOpen , although I have yet to see it call the WinHTTP functions – regardless of privileges.\r\nhttps://www.sentinelone.com/blog/gootkit-banking-trojan-persistence-other-capabilities/\r\nPage 6 of 16\n\nBefore reaching out to the C2, Gootkit will first add to the headers of the GET request. These additions can be\r\nseen below:\r\nX-File-Name: Filename\r\nX-User-Name: Username\r\nX-ComputerName: Computername\r\nX-OSVersion: 6.1.7601|Service Pack 1 1.0|1|0x00000100\r\nX-VendorId: 2700\r\nX-IsTrustedComputer: 1\r\nX-HTTP-Agent: WININET\r\nX-Proxy-Present: False\r\nX-Proxy-Used: False\r\nX-Proxy-AutoDetect: False\r\nThe X-IsTrustedComputer is only set to 1 if the crackmeololo  environment variable is set, otherwise it is set to\r\n0. This could be seen as another anti-analysis/anti-sandbox/anti-VM mechanism, although it’s difficult to say\r\nwithout seeing the backend.\r\nhttps://www.sentinelone.com/blog/gootkit-banking-trojan-persistence-other-capabilities/\r\nPage 7 of 16\n\nIf the connection between the sample and the C2 fails, it will attempt to connect to the other C2s found in the\r\nconfiguration. If the connection is successful and the server returns an executable, Gootkit will create a randomly\r\nnamed file in the Temporary directory, and execute it with the --reinstall argument, using CreateProcessW .\r\nAs a result of this, we can fully understand that this thread is in fact an “updater” thread, which will continuously\r\ncheck in with the C2 server, waiting for any updates to the loader.\r\nNow that this function has been covered, let’s move over to the Kill Switch function briefly, before going onto the\r\nBrowser Injection function.\r\nhttps://www.sentinelone.com/blog/gootkit-banking-trojan-persistence-other-capabilities/\r\nPage 8 of 16\n\nKill Switch\r\nThe Kill Switch thread is only triggered if uqjckeguhl.tmp is located in  ..AppDataLocalTemp  or ..Local\r\nSettingsTemp . If the file exists, then Gootkit begins to clean up after itself – it will kill all running threads, and\r\nrestart the computer. It’s quite unclear as to why this is a feature, as persistence is established before the Kill\r\nSwitch thread is executed, and so simply restarting the computer will end up executing the loader again –\r\nhowever, if a loader update is issued and installed on the infected system, causing a reboot could be helpful in\r\npreventing several instances from running at once.\r\nAnd finally, on to the Browser Injection function.\r\nBrowser Injection\r\nThe Browser Injection function is quite interesting, as it is responsible for two tasks; executing itself with the --\r\nvwxyz  argument, and injecting two DLLs into running browsers. We’re going to focus on the second task.\r\nIn order to inject a DLL into a browser, there must already be a DLL residing somewhere – which there is. In fact,\r\nthere are 2 encrypted DLLs stored in the binary; an x86 DLL and an x64 DLL, which are decrypted with a simple\r\nXOR . What is also interesting is that there seems to be possible placeholders in other variants, as this sample\r\nchecks for 0x11223344  and 0x55667788  in both DLLs, in order to replace the values with 0x12  and\r\n0x13  respectively.\r\nhttps://www.sentinelone.com/blog/gootkit-banking-trojan-persistence-other-capabilities/\r\nPage 9 of 16\n\nWith both executables decrypted, Gootkit alters the values to 0x3  for the following registry keys:\r\nSoftwareMicrosoftWindowsCurrentVersionInternet SettingsZones02500\r\nSoftwareMicrosoftWindowsCurrentVersionInternet SettingsZones12500\r\nSoftwareMicrosoftWindowsCurrentVersionInternet SettingsZones22500\r\nSoftwareMicrosoftWindowsCurrentVersionInternet SettingsZones32500\r\nSoftwareMicrosoftWindowsCurrentVersionInternet SettingsZones42500\r\nSoftwareMicrosoftWindowsCurrentVersionInternet SettingsZones52500\r\nhttps://www.sentinelone.com/blog/gootkit-banking-trojan-persistence-other-capabilities/\r\nPage 10 of 16\n\nThis results in disabling Internet Explorer Protected Mode for each security zone in use. From there, Gootkit will\r\nmove onto scanning all running processes until it locates an active browser. In order to do this, it will import and\r\ncall NtQuerySystemInformation() , requesting System Process Information. This returns a list of running\r\nprocesses. Using this list, Gootkit will open each process, check the process architecture using\r\nIsWow64Process() , and then CRC-32 hash the (uppercase) process name. This hash is then passed onto a\r\nfunction responsible for detection and injection. A list of targeted browsers and their corresponding hashes can be\r\nseen below.\r\nMicrosoft EdgeCP: 0x2993125A\r\nInternet Explorer: 0x922DF04\r\nFirefox: 0x662D9D39\r\nhttps://www.sentinelone.com/blog/gootkit-banking-trojan-persistence-other-capabilities/\r\nPage 11 of 16\n\nChrome: 0xC84F40F0\r\nOpera: 0x3D75A3FF\r\nSafari:  0xDCFC6E80\r\nUnknown:  0xEB71057E\r\nhttps://www.sentinelone.com/blog/gootkit-banking-trojan-persistence-other-capabilities/\r\nPage 12 of 16\n\nhttps://www.sentinelone.com/blog/gootkit-banking-trojan-persistence-other-capabilities/\r\nPage 13 of 16\n\nThe injection technique used by Gootkit is nothing special, and is quite common. The sample calls\r\nNtCreateSection , and will then map that section into the Browser using NtMapViewOfSection . Both DLLs\r\nseem to be mapped into memory as well, regardless of architecture. Once the files have been injected, the function\r\nwill return back to the Process Searching function, until another browser is detected. And that brings an end to the\r\nbrowser injection!\r\nhttps://www.sentinelone.com/blog/gootkit-banking-trojan-persistence-other-capabilities/\r\nPage 14 of 16\n\nMD5 of x86 DLL: 57e2f2b611d400c7e26a15d52e63fd7f\r\nMD5 of x64 DLL: 7e9f9b2d12e55177fa790792c824739a\r\nFrom a quick glance at the injected DLLs, they seem to contain a few hooking functions that seem to hook\r\nCertVerifyCertificateChainPolicy  and CertGetCertificateChain , as well as potentially acting as some form\r\nof proxy to intercept requests and redirect them based on information from the C2 server or the Node.js payload –\r\nmy main reasoning behind this is that infecting a VM with Gootkit and trying to browse the internet using Internet\r\nExplorer is unsuccessful, as if connections were being prevented by a proxy, although this does require further\r\nanalysis.\r\nhttps://www.sentinelone.com/blog/gootkit-banking-trojan-persistence-other-capabilities/\r\nPage 15 of 16\n\nIn the next post, we will take a look at what happens when Gootkit is called with the --vwxyz argument, and\r\nthen take a quick peek into the final Node.js payload that is retrieved from the Command and Control server!\r\nSource: https://www.sentinelone.com/blog/gootkit-banking-trojan-persistence-other-capabilities/\r\nhttps://www.sentinelone.com/blog/gootkit-banking-trojan-persistence-other-capabilities/\r\nPage 16 of 16\n\n  https://www.sentinelone.com/blog/gootkit-banking-trojan-persistence-other-capabilities/    \nIn the next post, we will take a look at what happens when Gootkit is called with the--vwxyz argument, and\nthen take a quick peek into the final Node.js payload that is retrieved from the Command and Control server!\nSource: https://www.sentinelone.com/blog/gootkit-banking-trojan-persistence-other-capabilities/      \n   Page 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.sentinelone.com/blog/gootkit-banking-trojan-persistence-other-capabilities/"
	],
	"report_names": [
		"gootkit-banking-trojan-persistence-other-capabilities"
	],
	"threat_actors": [],
	"ts_created_at": 1775434269,
	"ts_updated_at": 1775791316,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/bd612da9e3dfe4b98a0f21fc50c2cf967dca2641.pdf",
		"text": "https://archive.orkl.eu/bd612da9e3dfe4b98a0f21fc50c2cf967dca2641.txt",
		"img": "https://archive.orkl.eu/bd612da9e3dfe4b98a0f21fc50c2cf967dca2641.jpg"
	}
}