A fake internet, not a tighter cage: catching a trojan that waits for DNS

A connectivity check costs a malware author almost nothing: one DNS lookup, one HTTP request, then a branch. An air-gapped analysis VM answers it clearly and unhelpfully. So the graduate writeup on dev.to substitutes for the network instead of removing more of it: REMnux at 192.168.56.10 running INetSim 1.3.2 for HTTP, HTTPS and DNS, FakeDNS pointing every lookup from the Windows VM at 192.168.56.20 back at those services, all on a host-only segment with no route out ^[3][4]. The author's framing is that this is what answers the sample's question with a yes ^[4].

Worth being precise about what the lab proves. The writeup reports the execution with the simulated services running, and describes the dormancy behaviour as a known technique rather than something measured against a paired run with INetSim switched off ^[5][19]. The gate is plausible and the setup is the right one; the A/B that would pin it to this SHA-256 is not in the material.

The static picture explains why runtime work was necessary at all. Entropy of 7.916 sits above the 7.5 line where packed or encrypted content lives, and about 99 percent of the theoretical ceiling of 8 ^[6][17]. PEStudio identified UPX v0.89.6 with a Delphi stub, and the UPX0 section carries zero bytes on disk against 790KB of virtual size, which is the decompression target ^[7][8]. On VirusTotal, 33 of 76 engines flagged the file, meaning 43 of them, roughly 57 percent, did not ^[9][16]. Yet Windows Security raised a threat notification at execution with Defender mostly disabled ^[10]. The file was not the signal; the behaviour was.

That behaviour is short. The process created six threads inside the first second, did its work, and exited within a few seconds without staying resident ^[11][12]. Anything sampling on a coarser interval than that watches an executable exit cleanly. What it leaves behind is a fake GoogleUpdater tree at two version paths at once, 136.0.7079.0 and 137.0.7129.0, each with updater.exe, a Crashpad attachments directory and uninstall.cmd, followed by injection into five separate GoogleUpdater processes launched with --update ^[13][15].

The two directories are the operational detail. Legitimate Google Update keeps one version directory, and the analyst reads the pair as mutual reinstatement: delete one and the other restores it ^[18][14]. That makes the count, not the name, the indicator, and it makes remediation-by-path unreliable for anyone who finds the first folder and stops.

None of this needs a clever delivery chain. The file arrives inside pirated RAR and ZIP archives for Flexense disk tools, with VirusTotal tracking 151 parent archives, all of them pirated bundles ^[2]. A user who downloads an activator has already agreed to run an unsigned binary, often with local AV turned down to make the crack work. The interesting engineering is on the defender's side, and it is a service simulator on a second VM, not a stronger box around the first.