{
	"id": "416223cf-524c-45ce-9fd3-58ab7971eca2",
	"created_at": "2026-04-06T00:11:23.100154Z",
	"updated_at": "2026-04-10T03:34:18.773442Z",
	"deleted_at": null,
	"sha1_hash": "447aecb58a7e789b771bfe86c745a6da6fc9e211",
	"title": "Planned failure: Gootloader's malformed ZIP actually works perfectly",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2299216,
	"plain_text": "Planned failure: Gootloader's malformed ZIP actually works perfectly\r\nBy Aaron Walton\r\nPublished: 2026-01-15 · Archived: 2026-04-05 17:43:11 UTC\r\nTL;DR\r\nGootloader malware is delivered to victims in a ZIP archive and the ZIP itself is designed to bypass detection.\r\nThe ZIP archive is deliberately malformed causing many unarching tools to fail in analyzing it.\r\nHowever, defenders can take advantage of its unique format and behaviors to build detections.\r\nThe Gootloader developer has been involved in ransomware for a long time. Their role within ransomware has been initial\r\naccess: getting the foot in the door. Once the malware runs on a system, they hand their access to someone else. \r\nIn being responsible for this job, the Gootloader developer has incentive to ensure that their malware receives a low\r\ndetection score and can bypass most security tools. They’ve been very successful with this over the years. In years past,\r\nGootloader malware made up 11% of all malware we saw bypassing other security tools.\r\nAs documented by others (Huntress and an independent researcher), Gootloader returned in November 2025 after a hiatus.\r\nAccording to Huntress, the developer is working again with the threat actor tracked as Vanilla Tempest: an actor currently\r\nleveraging Rhysida ransomware. The aforementioned reports cover how the malware is being dropped and the second stage\r\nof the malware; we’re going to discuss the first stage of the malware. \r\nThe first stage of the malware consists of a malformed ZIP archive, which can thwart some automated processes and human\r\nanalysis. We’ll take a deep look at the ZIP archive itself and discuss how defenders can take advantage of its shape.\r\nZip it up\r\nWhen a user downloads Gootloader malware, they download a JScript file compressed in a ZIP archive. The JScript, when\r\nexecuted, is responsible for kicking off the infection and spawning a PowerShell process which establishes persistence on\r\nthe infected system—but the ZIP archive itself shouldn’t be ignored.\r\nFrom 2021–2023, we observed the Gootloader developer using a unique ZIP archive. The ZIP archive contained abnormal\r\ncharacteristics, allowing us to consistently identify it as having been created by the Gootloader developer’s infrastructure. So\r\nwhen the campaign resumed, we investigated the archive again. \r\nhttps://expel.com/blog/gootloaders-malformed-zip/\r\nPage 1 of 11\n\nThe characteristics of the latest version of the ZIP archive have changed, but it is again unique to the actor. The actor creates\r\na malformed archive as an anti-analysis technique. That is, many unarchiving tools are not able to consistently extract it, but\r\none critical unarchiving tool seems to work consistently and reliably: the default tool built into Windows systems. By being\r\ninaccessible to many specialized tools (such as 7zip and WinRAR) it prevents many automated workflows from analyzing\r\nthe contents of the file, but by being accessible to the default Windows unarchiver, it ensures that the actor’s target audience\r\n(potential victims) can open and run the JScript.\r\nBottom line up front (this is a ZIP archive file format joke)\r\nThe following summarizes the abnormal features of Gootloader’s ZIP archive. In the deep dive, we’ll discuss the file format\r\nand illustrate how to observe the malformed features. The deep dive provides an educational resource, shows our findings,\r\nand supports our detection recommendations.\r\nGootloader’s ZIP archives have the following features:\r\nThe file consists of 500–1,000 ZIP archives concatenated together. Because ZIP archives are read from the end of the\r\nfile, the ZIP archive can still function properly. The number of ZIP archives concatenated together is random, and the\r\nZIP archive itself is generated at the time of download.\r\nNOTE: We say the user downloads the malformed ZIP archive for convenience—what actually\r\nhappens is a bit more exotic and won’t be analyzed in depth in this post. Essentially, the user receives\r\nan XOR encoded blob of data, which contains one ZIP archive. The blob is decoded and appended to\r\nitself until it meets a set size. This happens on the victim’s hosts via their web browser. This prevents\r\ndefenders from detecting the ZIP when it’s passed over the network, but still delivers the hundreds of\r\nZIP archives appended together. Randy McEoin discovered this mechanism and discussed it with us\r\nprivately. \r\nThe ZIP archive’s “End of Central Directory” file structure is truncated: two critical bytes are missing from the\r\nexpected structure. This causes errors when some tools attempt to parse the End of Central Directory.\r\nFor each of Gootloader’s ZIP archives generated, values in non-critical fields are randomized: fields such as “Disk\r\nNumber” and “Number of Disks” are randomly assigned, causing some unarchiving tools to expect a sequence of ZIP\r\narchives which don’t exist.\r\nThe random number of files concatenated together and the randomized values in specific fields are a defense-evasion\r\ntechnique called “hashbusting.” In practice, every user who downloads a ZIP file from Gootloader’s infrastructure will\r\nreceive a unique ZIP file, so looking for that hash in other environments is futile. The Gootloader developer uses\r\nhashbusting for the ZIP archive and for the JScript file contained in the archive. \r\nAs a result of hashbusting, defenders must create more dynamic ways of identifying these abnormal files on disk and\r\nensuring dynamic detections can identify malicious activity if the file is run, as it’s highly unlikely to get flagged by\r\nantivirus or EDR based on static detection. See the final section of this report for detection methodologies and suggestions\r\nfor detection. \r\nDeep dive\r\nWhat good looks like\r\nIn this section, we’ll give an overview of what a normal ZIP archive is and look at a normal archive in analysis tools. We’ll\r\ngo into a fair amount of detail since file formats aren’t everyone’s specialty and some readers are most likely new to thinking\r\nabout file formats.\r\nThe normal ZIP archive\r\nThe following is a poster created by Ange Albertini breaking down a simple ZIP archive’s file structure. In his example, the\r\nZIP archive under review contains a simple text file that reads “Hello World!” The top left of the poster shows the\r\nhexadecimal content of the ZIP archive and the right side explains the color-coding showing the structures that make up the\r\nfile format.\r\nhttps://expel.com/blog/gootloaders-malformed-zip/\r\nPage 2 of 11\n\nA visual breakdown of a ZIP archive file’s structure.\r\nThe file format contains three main structures: a local file header containing metadata just before each compressed file, a\r\ncentral directory indicating where the files are located, and a section called “End of Central Directory”, which points to the\r\nwhere the directory itself can be found. When the archive is read by an unarchiving tool, it starts with the End of Central\r\nDirectory as illustrated in the poster in the bottom left corner.\r\nGootloader’s ZIP, if it were normal\r\nBelow, we’ve unzipped the Gootloader JScript file and re-zipped it into an archive. We’ll use two tools to visualize the ZIP\r\narchive’s structure: Malcat and ImHex. This ZIP archive only contains one file, so the structure is very simple and identical\r\nto the file format poster above.\r\nThe following is an image of the archive loaded into Malcat. On the left is the layout, where Malcat identifies the Central\r\nDirectory and End of Central Directory at the end of the file (simply labeled “directory”) and the singular file within the ZIP\r\narchive: Indiana_Animal_Protection_Laws_Guide.JS. In this image, Malcat also produces a report (highlighted in blue) that\r\nsummarizes the details of the ZIP archive’s central directory.\r\nhttps://expel.com/blog/gootloaders-malformed-zip/\r\nPage 3 of 11\n\nMalcat’s summary view of the normal ZIP archive.\r\nThe directory indicates that the archive contains one file, is not encrypted, has no comments, isn’t separated across floppy\r\ndisks, and isn’t using Zip64.\r\nWithin Malcat, we can view the Central Directory in the “structure view” which explains the values based on documented\r\nstandards for the file format.\r\nMalcat’s structural view of a well-formed ZIP file’s Central Directory and End of Central Directory.\r\nThese high level views and the structural view are valuable for readability. However, it’s important to know and understand\r\nthat these values are just a series of hexadecimal values. The image below is the hexadecimal values as they appear from\r\nMalcat. In this view, Malcat highlights the Central Directory and End of Central Directory structures as defined by the\r\nstandards.\r\nhttps://expel.com/blog/gootloaders-malformed-zip/\r\nPage 4 of 11\n\nMalcat’s hexadecimal view of a well-formed ZIP file’s Central Directory and End of Central Directory.\r\nWhen analyzing files at this level we also use dedicated hex editing tools. Tools like ImHex and 010 Editor allow the user to\r\nset a pattern to identify the major sections, as well as the individual components of those sections. In the image below, a\r\npattern based on the ZIP archive standard is used in ImHex. With the pattern, ImHex highlights each part of the structure.\r\nThe pattern also generates a table with the parts broken down. In the image, the Central Directory is selected and highlighted\r\nin the hexadecimal view.\r\nThe well-formed ZIP archive loaded and parsed by a pattern in ImHex.\r\nBased on these tools we can summarize some of the following key features of this ZIP archive:\r\nThe ZIP archive contains one file.\r\nThe file is 287 KB uncompressed. \r\nWhen compressed, the one file is 95.3 KB in size. \r\nIn these examples, the ZIP archive follows the standard. Next we’ll look at the ZIP a user downloads from websites infected\r\nby the Gootloader developer.\r\nWhat bad looks like\r\nThe following ZIP archive is the original ZIP that contained the JScript file “Indiana_Animal_Protection_Laws_Guide.js”.\r\nhttps://expel.com/blog/gootloaders-malformed-zip/\r\nPage 5 of 11\n\nZIP archive containing the “Indiana_Animal_Protection_Laws_Guide.js” JScript file.\r\nImmediately, we notice a lot of anomalies. First, the total size of the ZIP is 76.1MB in size: 819 times larger than the normal\r\nZIP archive we just reviewed. Yet, if the file is extracted from the archive, the file is only 287KB. \r\nSecond, we also see a very different structure in Malcat’s layout diagram, as pictured above. According to it, the file consists\r\nof 34.7MB of compressed data, followed by a gap, the Central Directory, and then an overlay—essentially data appended to\r\nthe end of a file outside of the file’s normal structure. This is all abnormal. This is indicative of Malcat struggling to make\r\nsense of the file. \r\nIn investigating the parsing failure, we find the End of Central Directory is malformed in this ZIP file. When we compare\r\njust the raw bytes between the ZIP files we see an immediate problem: they aren’t the same length, and not all parts of the\r\nstructure are accounted for.\r\nWell-formed 504B0506000000000100010079000000957D01000000\r\nMalformed 504B05060000000000000100F2050000F8810100\r\nThe End of Central Directory has fields that must exist and be the expected number of bytes, even if they’re empty. In this\r\ncase, the “Comment Length” field is missing. By adding these back in using a hex editor, the parser can now identify the\r\nEnd of Central Directory. However, this doesn’t solve all the problems.\r\nhttps://expel.com/blog/gootloaders-malformed-zip/\r\nPage 6 of 11\n\nImHex with the two bytes added to the end of the file. The Pattern Data also shows the color coding\r\nidentifying the End of Central Directory’s fields, but doesn’t highlight other structures of the file.\r\nMalcat’s anomaly engine highlighted one of the other issues with the ZIP archives: multiple elements of the local file’s\r\nmetadata differ from what’s in the central directory. That is, both the local file header and the central directory should\r\ncontain identical information about the file, but in this file, that’s not the case. \r\nMalcat analysis of file highlighting the mismatches between the Local File Header and Central Directories.\r\nIn this example, the following fields mismatch:\r\nVersion to extract\r\nModification time\r\nCRC32 (cyclic redundancy check; that is, a hashing method to help detect errors)\r\nCompressed size\r\nUncompressed size\r\nFile name length in bytes\r\nFile name\r\nThe following table shows the mismatches in this file. We observed these fields mismatch consistently across files we\r\nreviewed—and some values such as “version to extract” and “modification time” are seemingly randomized. \r\nStructure Version\r\nto\r\nModification\r\ntime\r\nCRC32 Compressed\r\nsize\r\nUncompressed\r\nsize\r\nFile\r\nname\r\nFile name\r\nhttps://expel.com/blog/gootloaders-malformed-zip/\r\nPage 7 of 11\n\nextract length\r\nLocal file\r\nheader\r\n0x34\r\n2010-02-13\r\n19:05:12\r\n0x34\r\n36 KB\r\n(0x22b1390)\r\n89 KB\r\n(0x555b776)\r\n0x1 /\r\nCentral\r\nDirectory\r\n0x14\r\n2024-05-06\r\n20:15:38\r\n0x1a20400c\r\n21 KB\r\n(0x1425f8c)\r\n97 KB\r\n(0x5ceb041)\r\n0x27 Indiana_Animal_Protection_Law\r\nFor most unarchivers, the mismatch of the CRC32 would be enough to indicate corruption of the file contents and cause\r\ndecompression to fail, so it’s unclear which specific elements cause specific unarchivers to fail. \r\nMore than one\r\nBy creating a YARA rule looking for static features of the Local File header and End of Central Directory, we find that the\r\ntwo structures aren’t each occurring one time in this file as expected. They both occurred 803 times. \r\nMalcat’s identification of 10 bytes of the Local File Header flagged by the YARA rule. The results on the left\r\nindicate that each pattern has matched 803 times.\r\nSince the actor appends identical ZIP archives together, the End of Central Directory always points to the same hard-coded\r\naddress for the Central Directory, allowing the directory to point to the expected file. This allows the ZIP to function despite\r\nthe random size.\r\nFrom anti-analysis to action\r\nThere is much more that could be said about the ZIP archive, but there’s an important question to answer first. What can we\r\ndo with what we know already? \r\nDetecting the ZIP archive\r\nWe can use what we know to detect Gootloader’s malformed ZIP archives. The following YARA rule can consistently\r\nidentify the current ZIP archives (November 11 to the time of this publication; however, the methodology for creating these\r\narchives  may change once this report is public). The YARA rule looks for specific ZIP characteristics in the local file header\r\nat the start of the file, more than 100 occurrences of the same local file header, and more than 100 occurrences of the End of\r\nCentral Directory with specific characteristics.  \r\nrule gootloader_zip_archive_2025_11_17 : malware {\r\nmeta:\r\nname = “gootloader_zip_archive”\r\ndescription = “Detects unique ZIP archive format used by Gootloader”\r\ncreated = “2025-11-17”\r\nreliability = 100\r\nhttps://expel.com/blog/gootloaders-malformed-zip/\r\nPage 8 of 11\n\ntlp = “TLP:CLEAR”\r\nsample = “b05eb7a367b5b86f8527af7b14e97b311580a8ff73f27eaa1fb793abb902dc6e”\r\nstrings:\r\n$zip_record_and_attacker_zip_parameters_hex = { 50 4B 03 04 ?? 00 00 00 08 00 } // check file header\r\n$end_of_central_directory = { 50 4B 05 06 0? 00 0? 00 00 00 01 00 ?? ?? 00 00 ?? ?? ?? 00 }\r\ncondition:\r\n$zip_record_and_attacker_zip_parameters_hex at 0\r\nand #zip_record_and_attacker_zip_parameters_hex \u003e 100\r\nand #end_of_central_directory \u003e 100\r\n}\r\nThis YARA rule is on our GitHub.\r\nWe chose to use a YARA rule for this because it helps you when investigating to know for certain this tactic was used. The\r\nmalicious JScript is more complex to detect: similar to the ZIP archive, it has a large deal of randomness, and it’s also\r\ndisguised to look benign. The Gootloader developer uses a benign JScript file, which is usually 10,000 lines long and hides\r\n100 lines of malicious code within it. Reviewing the script manually—or even in a sandbox environment—may not easily\r\nexpose its functionality. However, detecting the ZIP file provides analysts a pivot point to identify the malware in the\r\nenvironment and start investigating further.\r\nRunning from the ZIP \r\nAfter a user downloads the ZIP archive, they’re likely to double-click it. If the Windows unarchiver is their default\r\nunarchiver, it’ll open the ZIP folder in File Explorer. Most users will double-click the JScript file, which by default will run\r\nthe JScript using Windows Script Host (WScript). Since the file isn’t explicitly extracted from the ZIP and saved to disk,\r\nWScript will execute the JScript from a temporary folder. The process tree will look as follows:\r\nThe process tree for the JScript execution via WScript.\r\nThis happens because when a ZIP archive is opened, a temporary folder is created containing the ZIP archive contents.\r\nHowever, this provides a detection opportunity because the majority of users shouldn’t be running JScript files from a ZIP\r\narchive. The detection should look for Wscript executing a JScript file from the “AppData\\Local\\Temp” folder.\r\nThis also raises the question, should your users be running JScript files directly at all? Over the years, we’ve consistently\r\nseen malware bypass other security defenses by being delivered as a JScript file. They can do this because the JScript file\r\nitself is just a text file. However, by default, if a user double-clicks a JScript file, it’ll be executed with WScript. This is due\r\nto a Windows setting indicating that the default program to open JScript files is WScript. This default setting can be\r\nchanged with a Group Policy Object (GPO). We recommend changing the default program to Notepad, which\r\nprevents execution of the file when double-clicked. \r\nNote: If the default is changed, power users can still execute JScript files if they need to. \r\nBeyond the ZIP archive\r\nAs documented in the Gootloader is Back post, the current JScript does the following:\r\nCreates an .LNK file in the user’s Startup folder (C:\\Users\\\u003cusername\u003e\\AppData\\Roaming\\Microsoft\\Windows\\Start\r\nMenu\\Programs\\Startup). Files in this directory are run when the computer starts up.\r\nThe .LNK points to another .LNK in a random directory chosen by the JScript. \r\nA second JScript file is dropped in that same random directory and is pointed at by the .LNK file.\r\nAfter the user double-clicks the JScript—and after every computer restart—the .LNK will execute the second .LNK, which\r\nin turn executes the second JScript file. This is another detection opportunity.\r\nhttps://expel.com/blog/gootloaders-malformed-zip/\r\nPage 9 of 11\n\nWhen the .LNK file executes the JScript file, it does so with CScript and it runs from the same directory as the JScript file.\r\nAs a result, the JScript is run with no directory specified. The JScript is also executed using a NTFS shortname. NTFS was\r\ndeveloped in 1993 as part of Windows NT, and the short name is used for legacy systems that can’t handle longer file\r\nnames, shortening them to six characters, followed by ‘~1’ in most circumstances. Features like NTFS shortnames have\r\nbeen with Windows for a long time, but their appearance is fairly rare, which gives us a detection opportunity. We\r\nrecommend having a detection for CScript executing a JS file using a NTFS shortname. \r\nCommandline execution as surfaced by Workbench.\r\nWhen executed, the CScript will spawn PowerShell, which is also highly unusual and worth a detection. The PowerShell in\r\nturn spawns a second PowerShell instance containing a heavily obfuscated command. We recommend a detection focusing\r\non the process genealogy of Cscript spawning PowerShell.\r\nThe process genealogy resulting from execution of CScript executing the JScript file.\r\nGoot-bye and goot-riddance \r\nLooking at the first stage of a Gootloader infection allows us to detect and prevent Gootloader at its earliest point. Over the\r\nyears, we’ve seen the Gootloader developer change their malware time and time again, but by understanding the details of\r\ntheir campaign, we’re able to prevent them from getting a foothold within environments.\r\nCopies of the first stage ZIP file can be found on MalwareBazaar with the Gootloader tag.\r\nGootloader defense summary\r\n1. Prevention and hardening\r\n1. Reassociate JScript extensions: \r\n1. Use Group Policy Objects (GPO) to change the default “Open with” association for .js and .jse files\r\nfrom the Windows Script Host (WScript.exe) to Notepad. This ensures that if a user double-clicks a\r\nmalicious script, it opens as a text file rather than executing.\r\n2. Attack surface reduction: \r\n1. If JScript is not required for business operations, consider blocking wscript.exe and cscript.exe from\r\nexecuting downloaded content or restricting them entirely.\r\n2. Detection opportunities\r\n1. Detection should focus on the abnormal behavior of the ZIP archives and the subsequent process execution\r\nchain.\r\n1. Monitor for wscript.exe executing a .js file located within the AppData\\Local\\Temp directory.\r\n2. Monitor for the creation of .LNK files in the user’s Startup folder pointing to scripts in non-standard\r\ndirectories.\r\n3. Flag instances where cscript.exe executes a .js file using legacy NTFS shortnames (e.g.,\r\nFILENA~1.js).\r\n4. Alert on the specific process tree: cscript.exe → powershell.exe\r\nhttps://expel.com/blog/gootloaders-malformed-zip/\r\nPage 10 of 11\n\nSource: https://expel.com/blog/gootloaders-malformed-zip/\r\nhttps://expel.com/blog/gootloaders-malformed-zip/\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://expel.com/blog/gootloaders-malformed-zip/"
	],
	"report_names": [
		"gootloaders-malformed-zip"
	],
	"threat_actors": [
		{
			"id": "a6814184-2133-4520-b7b3-63e6b7be2f64",
			"created_at": "2025-08-07T02:03:25.019385Z",
			"updated_at": "2026-04-10T02:00:03.859468Z",
			"deleted_at": null,
			"main_name": "GOLD VICTOR",
			"aliases": [
				"DEV-0832 ",
				"STAC5279 ",
				"Vanilla Tempest ",
				"Vice Society",
				"Vice Spider "
			],
			"source_name": "Secureworks:GOLD VICTOR",
			"tools": [
				"Advanced IP Scanner",
				"Advanced Port Scanner",
				"HelloKitty ransomware",
				"INC ransomware",
				"MEGAsync",
				"Neshta",
				"PAExec",
				"PolyVice ransomware",
				"PortStarter",
				"PsExec",
				"QuantumLocker ransomware",
				"Rhysida ransomware",
				"Supper",
				"SystemBC",
				"Zeppelin ransomware"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "84aa9dbe-e992-4dce-9d80-af3b2de058c0",
			"created_at": "2024-02-02T02:00:04.041676Z",
			"updated_at": "2026-04-10T02:00:03.537352Z",
			"deleted_at": null,
			"main_name": "Vanilla Tempest",
			"aliases": [
				"DEV-0832",
				"Vice Society"
			],
			"source_name": "MISPGALAXY:Vanilla Tempest",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434283,
	"ts_updated_at": 1775792058,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/447aecb58a7e789b771bfe86c745a6da6fc9e211.pdf",
		"text": "https://archive.orkl.eu/447aecb58a7e789b771bfe86c745a6da6fc9e211.txt",
		"img": "https://archive.orkl.eu/447aecb58a7e789b771bfe86c745a6da6fc9e211.jpg"
	}
}