online lostsh.github.io fake-folder-explained | 2026-09-10 rfc 3514: evil bit not set
post 09 2026-09-10 explainer | worm | cryptomining 0 XMR

The folder that wasn't: how one fake icon turns a PC into a crypto miner

Explainer | Worm | Cryptomining 7 min read

A sample that is more interesting for its ordering than its code. Every step buys something the next step needs, and the whole chain reads like a business plan. If you want the hex, offsets and detection rules, the full teardown is here. This is the version you can forward to a colleague.

TL;DR

The trick

A binary that ships a folder icon, named to look like a folder, with an extension Windows hides. That is the entire disguise. Here is the icon pulled out of the sample:

The malware's embedded application icon at 256 by 256 pixels: the standard Windows Vista and 7 era file folder. A yellow manila folder drawn in three-quarter perspective with its front flap swung open to the left, a soft grey drop shadow falling down and to the right, and a thin white sheet of paper peeking from the right edge of the front panel whose lower third is a pale blue band. The background is fully transparent.
Figure 1: the icon resource stored inside the binary. It ships at ten sizes so no Explorer view mode falls back to a generic program icon

.scr is the deliberate choice: it runs on double-click like any PE, it is on the hidden-extension list, and it reads as media rather than software. The result, in a file listing:

Two side-by-side mockups of the same Explorer window listing four items at the root of drive E, titled The disguise: the same four items, with and without the default that hides extensions. The left pane is headed Extensions hidden, Windows default, and lists Backup, Documents, images and Photos, every one of them drawn with the identical yellow folder icon and none of them showing an extension, so nothing on screen separates them. The caption below it reads: one of these four is a 4.5 MB executable. The right pane is headed Extensions shown and lists the same four items, except the third row is highlighted in dark red and now reads images.scr in red, still carrying the same folder icon. The caption below it reads: same directory, one checkbox flipped. A panel across the bottom, headed And the properties dialog agrees, notes that right-click, Properties, Details reads FileDescription = Folder, ProductName = Images folder (x86-x64) and Comments = FOLDER, and that the metadata was set to lie in the same direction as the icon, so the one place a cautious user checks agrees with it.
Figure 2: the icon bytes are the system's own, so under the default setting the fake row is indistinguishable. Turning extensions back on is the entire fix

The primitive being abused is a default setting, which is why a decade of security improvements had nothing to say about it.

What it wants

Your electricity and your cycles, converted to Monero and deposited elsewhere. Not your files, not your credentials. A single host trickles, so the model only works at volume. The spreading therefore matters more to the operator than any individual infection, and it shapes the payout side:

Diagram of the intended money flow, titled Where the money was meant to go, and why the operator used twenty accounts instead of one. On the left, twenty small numbered chips labelled 00 to 19 represent twenty payout accounts, with chip 17 highlighted in amber as the one this victim was assigned. A caption notes the account is chosen by a timestamp on the victim's own machine, so it is effectively random per host and stays the same on that host forever. An arrow leads right to a green box labelled A Public Mining Pool, described as a real legitimate service, not the attacker's, abused. From the pool two arrows lead right: a solid green one to a box labelled The Operator, whoever ran this campaign, and a dashed purple one to a box labelled The Tool's Author, which takes a hidden cut of every customer's mining, a skim. Below, a panel headed Why not just one account explains that scale is conspicuous: thousands of infected machines paying into a single account would show up on the pool's own public statistics as an implausibly large miner and get the account banned, whereas split twenty ways each account looks like an ordinary small mining rig, which is camouflage and also means losing one account does not cost the whole campaign. A final red-bordered panel headed What actually arrived reads: Nothing. Not less than expected, zero.
Figure 3: twenty payout accounts is not paranoia, it is arithmetic. The constraint is the mining pool's own public statistics

The dashed line is the detail worth keeping. The miner binary carries a second hardcoded payout address, a dev fee baked in by whoever wrote it. The operator was being skimmed by their own toolmaker.

That has an attribution consequence: artifacts inside a purchased tool belong to the vendor, not the deployer. An email address or build path recovered from the miner tells you about the toolmaker.

The chain, in order

A six-stage flow diagram titled One double-click, and the six things that follow, in order. Stage one, It Arrives: something that looks like a folder appears at the top level of a USB stick, an external disk or a shared drive. Stage two, You Open It: Windows runs it, because it is a program wearing a folder icon, and the real extension is hidden by default. Stage three, You Are Reassured: an empty folder opens on screen, you clicked a folder and a folder opened, so nothing looks wrong. Stage four, It Moves In: it copies itself somewhere quiet and adds two auto-start entries, so it comes back on every login. Stage five, It Gets To Work: it starts two mining programs that use your processor and graphics card to earn cryptocurrency. Stage six, It Spreads: it copies itself onto every drive it can reach, including network shares, with no exploit involved. Arrows connect each stage to the next. Beneath all six, a dashed band connected to every stage by a dotted line is headed Meanwhile, at every single step, and explains that it quietly pings a website to say a victim reached stage N, seven check-ins in all, which is not stealing data but the operator counting how many infections survive each step, exactly like a company measuring a signup funnel. A closing note reads: the order matters, it reassures you before it installs anything, and it spreads last, once it is already established.
Figure 4: the sequence. The dashed band underneath is the part most write-ups leave out, and it says the most about who built this

Why that order

Reassurance before installation. The empty folder opens almost immediately. Install first and you leave a window where the victim is staring at a screen that did nothing, which is when people go looking.

Copy before launch. It relocates first and runs the copy from there. Otherwise pulling the stick kills the infection.

Persistence before spreading. Auto-start is instant; walking every drive letter is slow and noisy. Securing the return path first means an interruption halfway through still leaves it installed.

Spreading last. Most likely to be noticed, least useful to this victim. It is an investment in the next one, so it goes where its failure costs least.

There is also a 30 second sleep between dropping the miners and running them, aimed at sandboxes with a fixed observation window. Half a minute of the attacker's time for a shot at being classified as boring.

The seven check-ins

Seven HTTP requests to a fixed address, one per stage reached. It downloads the response, deletes it unread, and moves on. No config, no exfiltration: the operator is measuring where infections drop out. How many saw the file, how many opened it, how many reached mining, how many spread it onward.

That is a conversion funnel. Someone is looking at those numbers and asking why stage four converts worse than stage three, which is a more useful model of their behaviour than any amount of detail about the binary.

How it travels

Diagram titled How it travels, subtitled no exploit, no vulnerability, it just copies a file. At the centre-left, a red-bordered box labelled Infected PC notes that it writes a copy of itself to every drive letter it can find. Three curved arrows lead right to three destination boxes. The first, amber, is USB Stick: carried to another machine, another office, another company. The second, amber, is External Disk: plugged into whatever needs a backup next. The third, red, is Mapped Network Share, described as the dangerous one, where one laptop infects a file server that a whole team opens. A panel at the bottom headed Why this is the part that matters explains that patching does not help because nothing is being exploited, a fully updated machine will run it just as happily since someone only has to open the folder, and once it reaches a shared drive every colleague who opens that share is a new candidate.
Figure 5: the mechanism is "write a file to a drive letter". None of the usual defences engage with that

Patching is irrelevant. Nothing is being exploited, so the only gate is a double-click.

One laptop contaminates a department. Once it lands on a mapped share, it sits somewhere many people open in the normal course of work. So the cleanup instruction that matters is not "reimage the laptop", it is "enumerate the shares that laptop could write to". Skip that and you reinfect from your own file server.

And then it earned nothing

The chain above completed successfully. It also achieved none of its goal.

Diagram titled Two phone calls, nobody home, subtitled both of its outbound channels failed and it carried on regardless. The first lane, in blue, is Call one, report a victim: it pinged the website it uses to count infections; that site was still online and healthy, but the operator's files had been removed from it, so the page it wanted was gone. Result: not found, seven times. The second lane, in red, is Call two, connect me to the mining pool: it tried to reach the pool that would hand it work to do, but the pool now sits behind a big web front-end that only carries ordinary web traffic, not mining traffic, so the call never connected. Result: it dialled 54 times and was never answered once. A bottom panel headed The uncomfortable part notes that it never checks whether either call worked, so it finished installing itself, set up both auto-starts and copied itself across the drives anyway, and total failure to reach the internet did not slow it down at all.
Figure 6: both channels dead, and the local half of the infection completed at full speed regardless

Neither failure is a defence working. The check-in host was up and healthy; only the operator's files were gone, which suggests a compromised legitimate site used as a drop point and since cleaned. The mining pool now sits behind a large web front-end that carries HTTP, not Stratum on a non-web port, so 54 connection attempts got nowhere.

And it never noticed. Not once does it check whether a network call succeeded, so the local half of the infection ran at full speed while completely cut off.

Which is the finding worth carrying: "the network side failed" and "we're fine" are different statements. A report saying "no successful connections observed" describes the attacker's luck, not your controls. The host was still compromised and still spreading.

The file is eleven years old

The miners were compiled in 2014 and early 2015. Monero changed its PoW several times, ending with a wholesale switch in late 2019, so a miner built for the old algorithm produces nothing the network accepts. This one was found in quarantine in January 2026. Fossil and harmless are different claims:

Diagram titled An eleven-year-old threat, subtitled why the mining is finished but the file is not harmless. A horizontal timeline carries four markers: 2014 to 2015, Built and packaged for sale; 2019, Monero changes its maths, the miner is now useless; January 2026, Found and analysed, quarantined on a machine; and September 2026, its web address lapses, anyone can claim it. Below, two columns. The left, headed What is dead, lists: the mining itself, because the maths it knows is no longer the maths Monero uses; every mining pool it was built to use, all offline; and its check-in website, gone, then the address itself lapsed. The right, headed What still works, lists: spreading, copying itself to every drive and share it can reach, offline; coming back, via two separate auto-start entries where either one is enough; and fetching something new, a built-in download-and-run step left switched off, where one line in a text file turns it on. A footer reads: so an old miner that cannot mine and a self-spreading program that reinstalls itself and can be told to fetch anything are the same file, and only one of those gets cleaned up properly.
Figure 7: the left column is why it gets triaged as low priority. The right column is why that is a mistake

The right column is the argument of this post, and the third item is the one that matters. The installer reads a URL from a config entry, downloads whatever is there, and runs it hidden. In this build the entry is empty, so the step is skipped.

The machinery is intact. One line in a text file turns a dead cryptominer into a live loader for anything. That path never executed, so no dynamic analysis reports it. It only shows up if you read what the installer can do rather than what it did.

Generalised: a detonation report tells you one path through the program, not its capability set. Six capabilities in this sample never executed, and the most serious one is among them.

What to do about it

  1. Turn file extensions back on. Explorer, View, File name extensions. Deployable by policy, and the disguise collapses the moment images.scr stops rendering as images.
  2. Treat an executable at a drive root as an anomaly. Nothing legitimate installs itself to D:\. Worth an alert on its own.
  3. Alert on mining command lines, not mining binaries. Miners are commodity and repacked constantly, so hashes rot in days. A process launched with a pool address on its command line has to say so. That signal caught an eleven-year-old sample and will catch next year's.
  4. When you find one, enumerate the shares. The endpoint is the least interesting artifact. The file server it could write to is what reinfects everyone.
  5. Read the installer. If the sample is a dropper script, the script is the capability list.

One thing not to do: do not block the front-end provider's IP because it showed up in a report. It is shared with a large slice of the legitimate internet, the real server is behind it anyway, and a fleet-wide block will hurt more than the malware did.

Takeaways

  1. The exploit was a default setting. Hidden extensions plus a custom icon. No vulnerability, so no patch helps.
  2. Every step buys the next one. Reassure before installing, copy before launching, persist before spreading. The order tells you what the author was worried about.
  3. It measures itself. Someone is reading a conversion funnel and tuning the lure against it. Model the operator as a product team.
  4. Failed network activity is not protection. Both channels were dead and the infection still completed, persisted and spread.
  5. Obsolete payload, current risk. Triage each capability on its own.

The deep version, including how the installer was pulled apart, how the payload's identity and a hidden wallet were recovered from memory, and the detection rules that came out of it, is in the full teardown.