{
	"id": "cb8857b3-3db9-4731-a9e0-b737ad6f3c64",
	"created_at": "2026-04-06T00:10:16.278154Z",
	"updated_at": "2026-04-10T03:21:44.480948Z",
	"deleted_at": null,
	"sha1_hash": "247f22f49b4dbee26246f02082bfd2b4ca37186b",
	"title": "Malware Tales: Gootkit",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1456752,
	"plain_text": "Malware Tales: Gootkit\r\nArchived: 2026-04-05 17:55:35 UTC\r\nSummary\r\n1. The Threat\r\n2. Payload Delivery\r\n3. Gootkit executable\r\n4. Stage 1: Packed Gootkit\r\n5. Stage 2: Gaining a foothold\r\n6. Stage 3: Check-in phase\r\n7. Last stage\r\n8. Additional findings\r\n9. Conclusions\r\n1.The Threat\r\nGootkit belongs to the category of Infostealers and Bankers therefore it aims to steal information available on\r\ninfected machines and to hijack bank accounts to perform unwanted transactions.\r\nIt has been around at least since 2014 and it seems being actively distributed in many countries, including Italy.\r\nPrevious reports about this threat can be found following this link: Malpedia\r\nToday we are going to dive into the analysis of a particular variant that came up the last week.\r\n2.Payload Delivery\r\nThe infection vector is an email written in Italian. In this case adversaries used one of the most common social\r\nengineering techniques to trigger the user to open the attachment\r\nhttps://www.certego.net/en/news/malware-tales-gootkit/\r\nPage 1 of 16\n\nThe downloaded file is a heavily obfuscated Javascript file called \"GLS_Notifica.js\". If the user opens it, the\r\nnative Javascript interpreter wscript.exe would be executed by default and it would perform the following HTTP\r\nrequest:\r\nThe result is the download of a cabinet file that is an archive file which can be extracted natively by Windows.\r\nInside there is a Portable Executable file that is saved into the %TEMP% folder\r\n(“C:\\Users\u003cusername\u003e\\AppData\\Local\\Temp”) and launched.\r\nJavascripts downloaders are a common payload delivery because a little obfuscation can be enough to make them\r\nvery difficult to be detected by antivirus engines.\r\nhttps://www.certego.net/en/news/malware-tales-gootkit/\r\nPage 2 of 16\n\n3.Gootkit executable\r\nFirst run of the sample in an automated environment revealed that something new was added in this version. As\r\nwe can see in the following images, malware authors added a new layer of protection to the malicious agent. The\r\ncomparison has been made with a variant spread during December of 2018 in Italy. images are from AnyRun\r\nThis means that the original program was “packed” with the aim to slow down reverse engineers and to make\r\nineffective static analysis tools like Yara rules.\r\n4.Stage 1: Packed Gootkit\r\nIn such cases, a malware analyst knows that he has to extract the original payload as fast as possible without\r\nlosing time to try to understand the inner workings of this stage.\r\nhttps://www.certego.net/en/news/malware-tales-gootkit/\r\nPage 3 of 16\n\nA great open-source tool exists which can resolve the problem in a matter of seconds. It’s called PE-Sieve GitHub.\r\nEven though it does not always work, in this case it can dump the unmapped version of the original executable\r\nbecause the malicious software uses a technique called Process Hollowing a.k.a. RunPE. This method consists in\r\nstarting a new process in a suspended state, “hollowing” out the content of the process, replacing it with malicious\r\ncode and, finally, resuming the thread.\r\nIn the image we can see that the 6th parameter of \"CreateProcessW\" was set to \"4\", indicating that the process will\r\nstart in a suspended state.\r\nWe are talking about a well known technique that is easily detectable with the monitoring of the Windows API\r\ncalls that are needed to perform the injection. But here comes the trick.\r\nFollowing the flow of execution we couldn’t find all the needed API calls: we got NtCreateProcess,\r\nNtGetContextThread, NtReadVirtualMemory and NtSetContextThread.\r\nThe most important ones that are used by monitoring applications to detect the technique were missing:\r\nNtUnmapViewOfSection to “hollow” the target process\r\nNtWriteVirtualMemory to write into the target process\r\nNtResumeThread to resume the suspended thread\r\nLet’s find out what’s happening!\r\nAfter some shellcode injections inside its memory space, the process executes a call to IsWow64Process API that\r\nis used by the application to understand if the process is running under the WOW64 environment (Wiki) : this is a\r\nsubsystem of the Windows OS that is able to run 32-bit applications, like this one, on 64-bit operating systems.\r\nThe result of this check is used to run two different paths of code but with the same scope: run one of the\r\naforementioned missing API calls in the Kernel mode. This means that, in this way, classic user-level monitoring\r\ntools would not catch these calls and the RunPE technique would remain unnoticed.\r\nhttps://www.certego.net/en/news/malware-tales-gootkit/\r\nPage 4 of 16\n\nSpecifically, in case the process is running in a 32-bit environment, it would use the SYSENTER command to\r\nswitch into the Kernel mode, while, on the contrary, it would use the SYSCALL command to perform the same\r\noperation.\r\nTo complicate even further, the SYSCALL command can’t be called in the context of a 32-bit application. This\r\nmeans that the executable needs to perform a “trick-into-the-trick” to execute this operation. We are talking about\r\na technique known as The Heaven’s Gate.\r\nPractically, thanks to the RETF instruction, it’s possible to change the code segment (CS) from 0x23 to 0x33, de\r\nfacto enabling 64-bit mode on the running process.\r\nIn the following image we highlight the entrance and the exit of the “Gate” which contains the 64-bit code that\r\nperforms the SYSCALL operation.\r\nhttps://www.certego.net/en/news/malware-tales-gootkit/\r\nPage 5 of 16\n\nInstead, in this other image, we can see the process status before opening the gate (grey=suspended process) and\r\nafter having closed it (orange=running process).\r\nAlso, Gootkit takes advantage of The Heaven’s Gate as an anti-debugging technique because the majority of\r\ncommonly used debuggers can’t properly handle this situation, not allowing the analyst to follow the code of the\r\nGate step-by-step.\r\nFor further details, this method was deeply explained in this blog MalwareBytes\r\nGoing back to the point, the first stage resulted more complicated than expected because it pushed over the limits\r\nof obfuscation and stealthiness with the combination of various techniques.\r\n5.Stage 2: Gaining a foothold\r\nAt this point we can proceed with the analysis of the unpacked Gootkit.\r\nThe very first considerable finding was the check for the existence of a mutex object named\r\n“ServiceEntryPointThread”. If it exists, the process would terminate itself.\r\nhttps://www.certego.net/en/news/malware-tales-gootkit/\r\nPage 6 of 16\n\nBut how mutexes works? Mutexes are used as a locking mechanism to serialize access to a resource on the\r\nsystem. Malware sometimes uses it as an “infection marker” to avoid to infect the same machine twice. The\r\nfascinating thing about mutexes is that they are a double-edged weapon: security analysts could install the mutex\r\nin advance to vaccinate endpoint. (ref: Zeltser blog).\r\nThis means that this is a great indicator of compromise that we can use not only to detect the infection but also to\r\nprevent it.\r\nMoving on, we found that malware authors implemented a lot of checks to understand if the malware is running\r\ninside a virtual environment. Some of them are:\r\nIt checks if the registry key\r\n“HKLM\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\0\\ProcessorNameString” contains the\r\nword “Xeon”\r\nit checks if the computer name is “7SILVIA” or “SANDBOX”, if the username is “CurrentUser” or\r\n“Sandbox” or if “sbiedll.dll” has been loaded.\r\nit checks if “HKLM\\HARDWARE\\Description\\System\\VideoBiosVersion” contains the word “VirtualBox”\r\nhttps://www.certego.net/en/news/malware-tales-gootkit/\r\nPage 7 of 16\n\nit checks “HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\SystemBiosVersion” for the string\r\n“VBOX”\r\nIn the case one of this check fails, the program would execute a Sleep operation in a infinite cycle in the attempt to\r\nthwart automated sandbox execution.\r\nAfter that, we encountered the implementation of a particular persistence mechanism that it seems Gootkit has\r\nbeen using for many months: it’s already documented in various blog posts, for ex. ReaQta blog.\r\nBriefly, the infostealer generates a INF file with the same filename of itself.\r\nContent of the INF file:\r\nThen it creates 3 different registry keys (“Count”, “Path1” and “Section1”) inside\r\n“HKCU\\Software\\Microsoft\\IEAK\\GroupPolicy\\PendingGPOs” with the purpose to allow the threat to execute on\r\nreboot.\r\nIt seems that this technique was reported to be used only by Gootkit.\r\nFamous security tools still can’t detect this mechanism even if it has been used for months.\r\nFor example, the famous SysInternal Autoruns tool, that should be able to show all the programs that are\r\nconfigured to run on system bootup or login, fails the detection of this persistence method.\r\nhttps://www.certego.net/en/news/malware-tales-gootkit/\r\nPage 8 of 16\n\nStepping through the code, we noticed that, at runtime, Gootkit decrypts the strings it uses with a custom\r\nalgorithm to evade static analysis detection of anomalous behaviour.\r\nIt’s a combination of “stack strings”, XOR commands and the modulo operation.\r\nAn exhaustive explanation of the decryption routine can be found here:link\r\nSkipping further, eventually there’s a call to “CreateProcessW” to start a new instance of Gootkit with the\r\nfollowing parameter: --vwxyz\r\n6.Stage 3: Check-in phase\r\nQuickly we found out that executing the malware with the cited parameter allows us to skip all the previous anti-analysis controls to get into the part of the code that starts to contact the Command \u0026 Control Server.\r\nThe first check-in to home is done to the following URL via HTTPS:\r\nhttps://www.certego.net/en/news/malware-tales-gootkit/\r\nPage 9 of 16\n\nAs we can see from the image, many headers were added to the request to send different informations of the\r\ninfected machine to the C\u0026C Server.\r\nIn particular one of the headers caught my attention: “ X-IsTrustedComp”. Digging into the code we found that\r\nthe value would be set to “1” if an environment variable called “crackmeololo” was found in the host, “0”\r\notherwise.\r\nThat seems another “escaping” mechanism implementing by the author, probably to stop the infection chain for\r\nhis own debugging purposes.\r\n7.Last stage\r\nhttps://www.certego.net/en/news/malware-tales-gootkit/\r\nPage 10 of 16\n\nThe response that arrives from the previous connection contains the final stage of Gootkit, configured to work\r\nproperly on the infected machine.\r\nThe malware dynamically loaded “RtlDecompressBuffer” call to use it to decompress the payload; then, it\r\ninjected into an area of the current process memory.\r\nAfterwards the flow of execution is transferred to the start of the injected code.\r\nThe final payload is a DLL file that is bigger than 5MB because it contains the Node.js engine which is probably\r\nneeded to run some embedded javascript files. At this time we decided to stop our analysis and leave the rest to\r\nfuture work.\r\nhttps://www.certego.net/en/news/malware-tales-gootkit/\r\nPage 11 of 16\n\n8.Additional findings\r\nWhile debugging, we noticed that Gootkit does not check only if a parameter called “ --vwxyz” was passed to the\r\ncommand line. Also it checks if other 3 parameters:\r\nhttps://www.certego.net/en/news/malware-tales-gootkit/\r\nPage 12 of 16\n\nhttps://www.certego.net/en/news/malware-tales-gootkit/\r\nPage 13 of 16\n\nPretty strange thing. We haven’t found the malware to actively use these arguments yet. However, stepping\r\nthrough code we discovered that:\r\n1 - the “--reinstall” command leaded the execution to some curious code. First, the malware used\r\n“CreateToolHelp32Snapshot” to retrieve a list of the current running processes.\r\nThen, it iterated through the retrieved list via “ Process32FirstW” and “Process32NextW” with the aim to get a\r\nhandle to the active “explorer.exe” instance.\r\nAt this point it killed “explorer.exe”. The following image shows the process list before the “TerminateProcess”\r\ncommand.\r\nAfter having executed that command, we found that a new instance of the malware spawned as a child of\r\n“explorer.exe”.\r\nhttps://www.certego.net/en/news/malware-tales-gootkit/\r\nPage 14 of 16\n\nWhat happened? We performed some tests and it seems that “ explorer.exe” was killed and then automatically\r\nrestarted by “winlogon.exe”. Therefore “explorer.exe” accessed the keys involved in the persistence mechanism\r\npreviously explained:\r\n2 - the “ --service” command did not change the flow of execution with the exception of creating a new\r\nenvironment variable called “USERNAME_REQUIRED” and set it to “TRUE”.\r\nEventually we found that the final stage checks if the aforementioned variable exists.\r\n3 - the “ -test” command just terminate the process. Indeed it’s a test.\r\n9.Conclusions\r\nWe explored some of the functionalities of one of the most widespread Infostealers of these days, revealing new\r\nand old tricks that is using to remain undetected as much time as possible.\r\nCertego is actively monitoring every day threats to improve our detection and response methods, continuously\r\nincreasing the effectiveness of the incident response workflow.\r\nPS: Let us know if you liked this story and feel free to tell us how we can improve it!\r\nHash\r\nGLS_Notifica.js\r\n5ed739855d05d9601ee65e51bf4fec20d9f600e49ed29b7a13d018de7c5d23bc\r\ngootkit 1st stage\r\ne32d72c4ad2b023bf27ee8a79bf82c891c188c9bd7a200bfc987f41397bd61df\r\nhttps://www.certego.net/en/news/malware-tales-gootkit/\r\nPage 15 of 16\n\ngootkit 2nd stage\r\n0ad2e03b734b6675759526b357788f56594ac900eeb5bd37c67b52241305a10a\r\ngootkit DLL module\r\nAthor:\r\nMatteo Lodi, Threat Intelligence Lead Engineer\r\nSource: https://www.certego.net/en/news/malware-tales-gootkit/\r\nhttps://www.certego.net/en/news/malware-tales-gootkit/\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.certego.net/en/news/malware-tales-gootkit/"
	],
	"report_names": [
		"malware-tales-gootkit"
	],
	"threat_actors": [],
	"ts_created_at": 1775434216,
	"ts_updated_at": 1775791304,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/247f22f49b4dbee26246f02082bfd2b4ca37186b.pdf",
		"text": "https://archive.orkl.eu/247f22f49b4dbee26246f02082bfd2b4ca37186b.txt",
		"img": "https://archive.orkl.eu/247f22f49b4dbee26246f02082bfd2b4ca37186b.jpg"
	}
}