Case Study: Detecting Gootloader's Concatenated ZIP Evasion

The Threat

Gootloader is a JavaScript-based malware loader distributed through SEO poisoning campaigns and used as an initial access vector for ransomware deployment. In late 2025, Gootloader operators adopted a novel evasion technique: concatenating hundreds of ZIP archives into a single file. The Hacker News, reporting research by Expel, puts the count at 500 to 1,000; the nine samples we tested carry 319 to 1,007 end-of-central-directory records each (table below).

This exploits how ZIP parsers read from the end of the file, the last archive is valid and extractable, while the hundreds of prepended copies create a massive, unique file that defeats:

• Hash-based detection: Every download is unique because the randomized archive count changes the file hash every time.
• Content-based scanning: Many unarchiving tools cannot consistently extract the malformed archive (Expel, via The Hacker News).
• Automated sandboxes: Tools like WinRAR and 7-Zip cannot process the archive, which prevents many automated workflows from analyzing its contents (Expel, via The Hacker News).
• Size-based filtering: Files range from 30 to 95 MB, unusual for a JavaScript payload but not high enough to trigger routine size filters.

The technique is documented publicly by Expel and The Hacker News. We have not independently measured detection rates across other vendors and make no claim about them here. MalwareBazaar vendor intelligence on these specific samples lists reporting from several providers including Kaspersky and ReversingLabs, so these files are not unknown to the industry. What follows is a measurement of HADES only.

The Test

We tested HADES against 9 real Gootloader samples obtained from MalwareBazaar, ranging from 30 MB to 95 MB. Each sample was scanned via the standard batch pipeline with default settings, no tuning, no custom rules, no sample-specific tweaks. The table below is the 2026-09-12 revalidation on HADES v1.7.1; the original measurement was taken in April 2026 on v1.1.0.

Two columns, because the verdict must hold with and without internet access. "Online" is a normal deployment with threat-intel lookups enabled. "Air-gapped" is the same scan with the host network physically disconnected, which is how an isolated analysis workstation runs.

Sample provenance, stated plainly: all 9 were first seen on MalwareBazaar between 2025-12-29 and 2026-01-01, a four-day window, and all carry the tags Gootloader and zip. This is one campaign burst, not a longitudinal sample. It is a fair test of whether the detection works on that campaign and a weak basis for claiming it generalizes across the life of the family. See Limitations below.

Result: 9 of 9 detected at CRITICAL, online and air-gapped. Zero timeouts. Zero errors.

The 1-point difference is threat-intel corroboration. Online, MalwareBazaar confirms the family and HADES reports confidence confirmed; air-gapped, the structural rule stands on its own and HADES reports confidence high. Both are CRITICAL, and the verdict an analyst acts on does not change.

Sizes are MiB. EOCD counts are the zip_forensics tally of end-of-central-directory signature occurrences; for 8 of the 9 samples these run slightly higher than the counts published in the April 2026 version of this table, which used a different counting method. No sample sits near the detection boundary under either counting method.

How HADES Detects It

HADES uses a purpose-built YARA rule (HADES_GOOTLOADER_ZIP_BOMB) that identifies the structural anomaly rather than any specific content signature:

1. ZIP local file header count: counts local file header signatures across the whole file.
2. End-of-central-directory count: counts end-of-central-directory records, one per concatenated archive.
3. Combined condition: Both thresholds must be exceeded simultaneously to trigger.

This approach is resilient to Gootloader's hashbusting because it detects the structural technique, not any specific hash or content signature. Randomizing the archive count changes the hash on every download but leaves the structural signal intact, and detection does not depend on the inner payload, so a new payload in the same wrapper is still caught.

On the CRITICAL rating, precisely. The structural match itself yields HIGH. A loader-family severity boost then promotes HIGH to CRITICAL for initial-access loader families, because an active ransomware precursor warrants a different response than a merely suspicious file. That promotion is a deliberate policy decision about response priority, not a second independent detection. Readers evaluating detection strength should weigh the HIGH; readers evaluating triage behavior should weigh the CRITICAL.

Why This Class of Evasion Is Hard

HADES succeeds because it analyzes ZIP structural integrity rather than content signatures. The rows above describe properties of the technique as reported by The Hacker News from Expel's research, not measurements of named products by us.

Performance and Reliability

The number that matters operationally is not seconds per file, it is whether the verdict arrives at all, and whether it still arrives when the host has no internet. On the 2026-09-12 revalidation (HADES v1.7.1):

• 9 of 9 CRITICAL online, 9 of 9 CRITICAL air-gapped. No sample changed severity when the network was pulled.
• Zero timeouts, zero errors across both runs, on files of 30 to 95 MB.
• HADES_GOOTLOADER_ZIP_BOMB matched on 9 of 9 files in both runs. Every sample finished its YARA pass inside the adaptive budget, which scales with input size precisely so that a 95 MB input is not silently skipped. The CRITICAL verdict therefore rests on the structural rule, not on a threat-intel lookup that an isolated analysis workstation cannot make.

Throughput is the weaker axis here and we would rather state it plainly than round it. These files are 30 to 95 MB and HADES reads all of them. On the measurement hardware, a 6-core VirtualBox VM running the batch scanner with 4 workers, the 10-file targeted directory completed in 224 seconds online and 160 seconds air-gapped (the 9 Gootloader samples plus one unrelated gzip-bomb test artifact that shares the directory and scored 32 LOW in both runs); the largest single-file wallclock was 110 seconds on a 93 MB sample. The gap between the two totals is threat-intel network latency, not detection work. Those figures are specific to that VM and to v1.7.1. They are a data point, not a product throughput specification, and different hardware will move them.

Limitations

A case study that only lists strengths is marketing. These are the boundaries of what the measurement above supports.

This test set contains no clean files, so it is not false-positive evidence. Nine known-malicious samples plus one gzip-bomb artifact cannot tell you anything about false positives. HADES false-positive performance is measured separately against a dedicated clean corpus and reported with that measurement, never inferred from this one.

Structural detection has a false-positive surface, and we test for it rather than assume it away. Any rule keyed on repeated archive structure has to be evaluated against legitimate files that also contain many archives, such as backup bundles and build-artifact collections, where byte-level structure can resemble concatenation. We maintain a dedicated false-positive regression suite for this class, including a positive control so the suite cannot pass while testing nothing, and we treat any case it identifies as a tracked engineering item rather than an acceptable cost.

One campaign window. The nine samples span four days at the end of December 2025. This demonstrates detection of that campaign. It does not by itself establish durability against future Gootloader iterations, and we do not claim that it does.

Adversary adaptation is expected. Any threshold-based structural detection can in principle be approached from below. That is why the structural rule is one layer rather than the whole answer, and why the sample set and thresholds are reviewed as the campaign evolves.

Why This Matters

Gootloader's concatenated ZIP technique is not a one-off. It represents a broader class of evasion that targets the assumptions built into traditional scanning engines, specifically, the assumption that a file's hash, content, or behavioral trace is the right detection surface. HADES is designed around a different assumption: that structure itself is signal. A file that is structurally anomalous, a PDF with 500 incremental updates, a ZIP with 1,000 duplicate headers, a JPEG that's also a valid PE binary, is saying something about its intent, independent of what it carries inside.

This structural-first approach is why HADES catches hashbusting loaders, polyglot files, VBA stomping, PDF shadow attacks, and many other techniques that defeat content-focused scanners.

Originally tested April 2026 on HADES v1.1.0 • Revalidated 2026-09-12 on HADES v1.7.1, online and air-gapped • Samples sourced from MalwareBazaar (abuse.ch)