I was catching up on weekend news when ESET’s report landed covering another RAR file path traversal. Initial coverage was careful about not describing the mechanism — understandably — but there’s a fake PoC on GitHub that has nothing to do with the actual CVE (the author couldn’t resist the SEO, much like this author). I found one of the file hashes submitted to any.run and went from there.

At first nothing looked obviously wrong — no malicious network traffic on initial inspection. But any.run’s behavior view showed a lnk file launching:

starts new process

That sent me to the RAR file itself:

rar bytes

According to rarlab.com’s format spec, the STM section marker is NTFS alternate data stream. That matches ESET’s description. The path traversal pattern is in the bytes adjacent to the STM marker: /\x00\x00\x03STM.{2}\x3a[^\x00]*\x2e\x2e\x5c — a colon followed by a path containing ..\\.

Detection concept

The detection key is the STM marker combined with a path traversal sequence in the surrounding bytes. James Emery-Callcott of Emerging Threats tightened the path traversal PCRE considerably beyond my initial version — the more durable form handles URL-encoded variants and slash normalization.

For network detection, the pattern is visible in HTTP response bodies when RAR files are delivered over cleartext HTTP. For file-based detection, the same byte sequence is present in the RAR container regardless of delivery method.

The YARA condition: uint16(0) == 0x6152 (RAR magic bytes) plus the STM marker and ..\\ sequence in the same file.

Shoutout to WinRAR developers — considering the software has been around 30 years and is still routinely used to deliver malware, the attack surface it presents is remarkable.