Case 02 Host Forensics TDX Arena — IR Expert 08 / 11 / 2025

One of Us

A routine IR investigation on a Sea-Snail Security client workstation reached a point where local antivirus returned clean on a file that was producing anomalous behavior. The operational question became: is the file actually safe, or is local AV missing it? Cross-validation through VirusTotal's multi-engine analysis caught what local AV did not. A durable YARA rule derived from the resulting IOCs means the next detection does not depend on a local signature update ever arriving.

Executive Summary

Initial containment on the client workstation removed several known threats, but abnormal behavior persisted. Further review surfaced additional dropped files — 272 binaries named File0.exe through File271.exe — in ~/Desktop/suspicious-files/. Local antivirus flagged none of them. Given the observed persistence behavior, a local-AV-clean result was not convincing enough to treat the files as safe.

The analyst session was constrained: the logged-in user (bruce) had no sudo, which ruled out local tool installation and forced reliance on browser-accessible scanners. The ClamAV Web UI refused the bulk upload (25 MB limit, single-file constraint). VirusTotal accepted the zipped set and returned detections across multiple engines on file176.exe — nine engines flagged it, including Avast/AVG labelling it Win32:ShikataGaNai-A [Trj], Microsoft labelling it Trojan:Script/Wacatac.B!ml, and Fortinet labelling it W32/Swrort.Cltr. Cryptographic hashes (MD5: f48a8687e91fd9ef98cd1b7aaeeb2a4c, SHA-256: 1b7252aa6d8e4f717655de9d3e65edcf25836c5839c4946c521f934be0fdceb0) were extracted for blocklist and hunt use, and a YARA rule derived from those IOCs was authored to make future detection independent of local AV signature freshness.

Findings & Analysis

Local AV non-detection

Clean result on
live malicious payload

Local antivirus flagged none of the dropped files. Without cross-validation this finding would have been accepted and the compromise extended. The clean result was the signal to escalate, not to stand down.

Malicious file identified

file176.exe
(223.19 KB)

Nine of sixty-three VirusTotal engines classified it malicious. Labels cluster around Shikata Ga Nai obfuscation (a polymorphic XOR additive-feedback encoder commonly used to evade signature-based AV) and trojan/Meterpreter families. The label clustering across independent engines is what makes the classification defensible.

Cryptographic IOCs

MD5: f48a8687e9…2a4c
SHA-256: 1b7252aa…fdceb0

Hashes uniquely identify the sample for blocklist deployment, cross-environment hunting, and SIEM correlation. Local md5sum / sha256sum confirmed the file on disk matched the VirusTotal-reported hashes — the sample analyzed and the sample on the endpoint are the same bytes.

Dropper behavior

272 files
(File0.exe → File271.exe)

The directory count alone is a behavioral tell. Legitimate applications do not drop 272 sequentially-named executables. This is the pattern of a dropper that has already run — consistent with the Shikata Ga Nai family's usual delivery mechanism (initial stager unpacks payloads in memory, can write persistence or additional stages to disk).

Restricted environment

whoami → bruce
sudo -l → no sudo

Session constraint that shaped every subsequent tool choice. No local install, no privileged scans, no sudo-required services. The path through the investigation is a direct function of this constraint — it is not a limitation, it is the environment.

IOC quick reference

File: /home/bruce/Desktop/suspicious-files/file176.exe
Size: 228550 bytes (223.19 KB)
MD5: f48a8687e91fd9ef98cd1b7aaeeb2a4c
SHA-256: 1b7252aa6d8e4f717655de9d3e65edcf25836c5839c4946c521f934be0fdceb0
Family cluster: Shikata Ga Nai encoded payload (Meterpreter / Swrort / Wacatac labels across independent engines)
Secondary artifacts: 272 dropped binaries in ~/Desktop/suspicious-files/

Tools & Technologies

Local AV (client-installed)

Initial detection path. Returned clean on the dropped-file set. Not failure — an input signal that one detection layer is not sufficient and cross-validation is required.

ClamAV Web UI

First pivot attempt from a no-sudo session. Refused the bulk upload on a 25 MB single-file limit. A blocked path that still taught something — it narrowed the viable tool set and documented why the next pivot was necessary.

zip (maximum compression)

zip -r9 packaged the entire suspicious-files/ directory into a single archive for upload. -r9 is recursive with max compression — not speed-critical, but size-critical when every upload target has its own file-size ceiling.

VirusTotal

Multi-engine reputation and static analysis at the bulk-upload tier. Surfaced the malicious file, produced the cryptographic IOCs, and gave the family-cluster signal (multiple independent engines converging on Shikata Ga Nai labels) that makes the classification defensible.

md5sum / sha256sum

Local hash generation to verify the file on the endpoint matched the hashes VirusTotal reported. Without this verification step, the IOCs describe a sample that was uploaded — not necessarily the sample still sitting on the host.

YARA (rule authoring)

Outcome tool, not investigation tool. The YARA rule derived from the captured IOCs is what makes this detection durable — no dependency on local AV vendor signature updates arriving, no dependency on a second VirusTotal submission. The rule runs wherever YARA runs.

Investigation Process

Six steps. The defining move is step 4 — treating the local-AV-clean result as a signal to escalate rather than a signal to stop. Cross-validation is the skill the case rewards.

Step 01 Confirm session and privilege constraints No sudo

whoami sudo -l

Why: Before touching evidence, establish what the session can actually do. User is bruce, no sudo. Every tool decision downstream is a direct function of this — no local install, no privileged scans, no root-required services. Documenting the constraint up front is what lets the report defend every tool choice that follows.

Step 02 Attempt web-based AV (ClamAV Web UI) 25 MB single-file limit

# Navigated to ClamAV Web UI in Chromium # Attempted multi-file upload → no multi-select support # Fell back to zip archive — blocked by 25 MB limit

Why: Native no-install scanning was the cheapest viable path given the privilege constraint. The block documents why the next pivot was necessary — without this step in the record, the VirusTotal choice looks arbitrary. With it, the choice is the first tool that actually accepts the workload.

Step 03 Compress for bulk submission Archive ready

cd ~/Desktop zip -r9 suspicious-files.zip suspicious-files

Why: -r recurses the directory, -9 applies maximum compression. A single file upload rather than 272 individual submissions — cheaper on the network, faster through any upload-quota gate, and keeps the entire dropped-file set analyzed together rather than piecemeal.

Step 04 Cross-validate through VirusTotal 9 / 63 flagged — file176.exe

# VirusTotal File upload → suspicious-files.zip # VT identified multiple files with positive detections # Selected file176.exe — highest detection count, aligned with incident timeline

Why: Local AV returned clean. A second independent detection surface was required to confirm or contradict that result. VT's multi-engine panel provides exactly that — sixty-three engines evaluating the same bytes. Nine positive detections on file176.exe, where the labels cluster around ShikataGaNai, Meterpreter, Swrort, and Wacatac — independent labeling converging on the same malware family is the signal that makes the classification defensible.

The real skill — treating a clean result as a signal

Local AV returning clean is not a failure of the investigation. It is an input the investigator has to interpret. A junior analyst reads clean and stops. A senior analyst reads clean against behavioral evidence — a workstation dropping 272 sequentially-named executables is not the behavior of a clean system — and treats the mismatch as the next lead. The pivot into VirusTotal is not creative; it is procedural. The creative move is refusing to accept a clean-AV result when observed behavior says otherwise, and designing the next step around that mismatch.

Step 05 Extract cryptographic IOCs and verify locally Hashes match

md5sum /home/bruce/Desktop/suspicious-files/file176.exe sha256sum /home/bruce/Desktop/suspicious-files/file176.exe # Local output: # MD5 f48a8687e91fd9ef98cd1b7aaeeb2a4c # SHA-256 1b7252aa6d8e4f717655de9d3e65edcf25836c5839c4946c521f934be0fdceb0 # Match VirusTotal — same bytes

Why: The IOCs VT reports describe the uploaded sample. Local hashing confirms the sample on the endpoint is the same sample VT analyzed. Without that verification, the IOCs are about a copy; with it, they identify the live threat on the host. That distinction matters for every downstream action — blocklist entries, SIEM hunts, incident report references all depend on the hashes being bound to the on-host file, not just the uploaded copy.

Step 06 Author YARA rule from IOCs Durable detection shipped

rule file176_shikata_ga_nai { meta: author = "Leishka Pagan" description = "Detection for file176.exe — Shikata Ga Nai encoded payload" reference = "VirusTotal multi-engine analysis" md5 = "f48a8687e91fd9ef98cd1b7aaeeb2a4c" sha256 = "1b7252aa6d8e4f717655de9d3e65edcf25836c5839c4946c521f934be0fdceb0" condition: filesize == 228550 and hash.md5(0, filesize) == "f48a8687e91fd9ef98cd1b7aaeeb2a4c" and hash.sha256(0, filesize) == "1b7252aa6d8e4f717655de9d3e65edcf25836c5839c4946c521f934be0fdceb0" }

Why: The VirusTotal finding is a moment in time. The YARA rule is a deployable artifact. It runs anywhere YARA runs — endpoint scanners, file-server sweeps, mail-gateway inspection — without depending on a local AV vendor shipping a matching signature. For future instances of the same sample, detection no longer has a vendor dependency. The rule is deliberately written against both MD5 and SHA-256 plus file size, giving redundant matching conditions so a single collision-style manipulation does not evade it.

Recommendations

Treat AV-clean results as inputs, not conclusions

A local-AV-clean result against observed anomalous behavior is not a closed case. It is a mismatch that demands a second detection surface. For workstations with suspected compromise, cross-validation through an independent multi-engine scanner should be a standard step in the IR playbook — not an exception reserved for confirmed detections.

Deploy the YARA rule to the endpoint fleet

The rule authored from this investigation identifies the specific sample regardless of whether AV signatures catch up. Push it to endpoint scanners, file-server sweeps, and mail-gateway inspection. A per-sample YARA rule is a small durable asset; a shelf of them over time is a detection library that does not depend on any vendor.

Quarantine the full dropped-file set, not just the identified sample

VirusTotal confirmed file176.exe. The 271 other files in the same directory share origin and were not individually exonerated. Quarantine the full set and scan each through YARA rules derived from known-bad samples before returning any of them to the host.

Harden egress and application control

Shikata Ga Nai-family payloads typically need network egress (C2 beaconing) and local execution permission to progress past initial delivery. Egress filtering against known C2 infrastructure and application allowlisting on the endpoint cut the attack chain at points where signature-based AV is structurally blind — because neither requires the payload to be correctly classified to be stopped.

Build the dropped-file heuristic into endpoint telemetry

A directory accumulating 272 sequentially-named executables is a behavioral indicator that does not depend on classifying any individual file. Endpoint telemetry that flags this pattern — sudden file-count growth in user-writable paths, sequentially-named executables, high file churn — catches dropper behavior before the individual payloads are identified.

Technical Note

Shikata Ga Nai and why signature-based AV struggles with it

Shikata Ga Nai is a polymorphic XOR additive-feedback encoder originally shipped with Metasploit. Every execution of an encoded payload produces a slightly different byte-level artifact — the decoder stub mutates, the key material rotates, the XOR chain advances — even though the decoded payload is identical. Signature-based antivirus detects bytes; an encoder that changes the bytes per generation reliably defeats naïve signatures. Independent research (AT&T Alien Labs, Bitdefender) documents the encoder's continued use for concealing Meterpreter shells, RATs, and ransomware droppers, including the real-world Shikitega family's multi-stage Linux-targeted delivery through a ~370-byte ELF dropper that unpacks successive stages in memory.

Two implications shape this case. First, the nine-of-sixty-three detection count on VirusTotal is exactly the pattern Shikata Ga Nai produces: the engines with heuristic or behavioral detection catch the sample; engines relying on static byte signatures miss it. That's not a VT quality issue — it's the encoder working as designed. Second, and more operationally important: if signature-based AV is structurally vulnerable to per-generation byte mutation, the detection strategy that stays durable is one grounded in the invariants. Cryptographic hash of the specific observed sample does not mutate across a generation you already have. A YARA rule against the exact bytes you captured will find that exact sample reliably, forever. It will not find the next generation — but the next generation gets a new rule, and the library grows.

The broader takeaway is that per-sample YARA rule authoring is cheaper than it looks and more durable than vendor signature waiting. Every confirmed malicious sample in an IR investigation should graduate to a YARA rule as a closing step — not as extra work, but as the investigation's deployable artifact.

References

AT&T Alien Labs — Shikitega: New stealthy malware targeting Linux. Documents real-world Shikata Ga Nai–encoded dropper behavior, multi-stage in-memory unpacking, and Meterpreter shell delivery. levelblue.com
Bitdefender — New Shikitega Malware Targets Linux and IoT Devices. Independent analysis of the Shikitega family including the ~370-byte ELF dropper, cryptominer delivery path, and persistence mechanisms. bitdefender.com
YARA documentation — Writing rules. Reference for YARA rule syntax including the hash module used in the authored rule and the condition patterns that combine hashes with filesize for redundant matching. yara.readthedocs.io
VirusTotal. Multi-engine reputation and static analysis service used to identify file176.exe and produce the IOCs the YARA rule was derived from. virustotal.com