online lostsh.github.io fake-folder-explained | 2026-09-10 rfc 3514: evil bit not set
post 08 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 13 min read

An overview of a piece of malware that is interesting less for its code than for its reasoning. Every step it takes is there for a reason, the order is deliberate, and the whole thing hangs together as a small business plan. This post walks through that logic. If you want the hex, offsets and detection rules, the full teardown is here — this is the version you can send to a colleague.

TL;DR

If you take one thing from this: the mining is the boring part. The interesting part is that every single step exists to make the next one possible.

The one idea the whole thing rests on

Strip away the cryptocurrency and this is a very old trick. Windows, by default, hides file extensions for known file types. So a file called images.scr shows up in Explorer as simply images. And Windows lets a program supply its own icon.

Put those two facts together and you can make a program that is, to the eye, indistinguishable from a folder. Here is the actual icon lifted 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: not a screenshot of a folder — this is the icon stored inside the malware, which Windows then dutifully displays. It ships at ten different sizes so that no Explorer view mode falls back to a generic program icon

The choice of .scr is the neat part. A screensaver is a normal Windows executable with a different extension. It runs on double-click like any program, but it reads to a person as media rather than software — and its extension is one of the ones Windows hides.

So there is no exploit here, and no clever code. The vulnerability being used is a default setting plus a human expectation. That is worth sitting with for a second, because it explains why this technique has survived a decade of security improvements that had nothing to say about it.

What it actually wants

Cryptocurrency mining is a lottery where tickets cost electricity. You do enormous numbers of pointless calculations, and occasionally you win a payout. Doing this profitably requires more hardware and more power than it returns for most people — unless someone else is paying for the hardware and the power.

That is the entire business model. The malware is not interested in your files, your passwords or your photos. It wants your electricity bill and your CPU cycles, converted into Monero and deposited somewhere else. Your machine gets hot, slow and loud; someone you will never meet gets a small trickle of currency.

And because a single machine trickles very slowly, the model only works at volume. Which is why the spreading matters more to the operator than any individual infection, and why the payout arrangement looks the way it does:

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 2: twenty payout accounts is not paranoia, it is arithmetic. The constraint is the mining pool's own public statistics

The detail I find most telling is the dashed line. The mining program itself contains a second, hidden payout address that takes a cut — a "dev fee" baked in by whoever wrote the miner. The operator running this campaign was themselves being skimmed by their own toolmaker. It is commodity crime with a supply chain, and everybody in that chain takes a margin.

It also has a practical consequence for attribution, which is worth flagging because it is a trap: artifacts inside a purchased tool belong to the tool's author, not to the person who deployed it. Finding an email address or a build path inside the miner tells you about the vendor, not the attacker.

The chain, in order

Here is the whole sequence. Six visible steps, plus one thing happening continuously underneath all of them:

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 3: 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, and not some other order

This is the bit worth dwelling on, because the ordering is not arbitrary — each step buys something the next step needs.

Reassurance comes before installation. The empty folder opens almost immediately. If the malware installed first and reassured second, there would be a window where the victim is staring at a screen that did nothing, which is exactly when people say "that's odd" and go looking. Removing that window is worth more than the fraction of a second it costs.

The copy comes before the launch. It relocates itself into a quiet directory and runs that copy, rather than running from the USB stick. Otherwise pulling out the stick kills the infection. The copy is what makes everything after it durable.

Persistence comes before spreading. Auto-start is cheap and instant; copying itself to every drive letter takes a while and touches a lot of disks. Securing its return on this machine first means an interruption halfway through the noisy part still leaves it installed.

Spreading comes last, for the same reason. It is the most likely step to be noticed and the least likely to be needed for this victim. It is an investment in the next victim, so it goes at the end where its failure costs least.

There is also a pause. Between dropping the mining programs and actually running them, it waits thirty seconds doing nothing at all. That is aimed squarely at automated analysis: a lot of sandboxes watch a sample for a short fixed window and file a report on whatever they saw. Wait long enough and the interesting part happens after the observer has stopped watching. It costs the attacker half a minute and can buy months of being classified as boring.

The seven check-ins

The band under the diagram is my favourite detail. At seven points in the sequence, it makes a web request to a fixed address — one per stage reached.

It never reads the reply. It downloads whatever comes back, deletes it unread, and moves on. So this is not configuration, and not exfiltration. It is telemetry: the operator instrumenting their own malware to see where infections drop out. How many people saw the file, how many opened it, how many got as far as mining, how many spread it onward.

That is a conversion funnel. Somebody is looking at those numbers and asking why stage four converts worse than stage three. Whatever else you think about the people who write this stuff, they are running it like a product — and that framing is more useful for predicting their behaviour than any amount of technical detail about the binary.

How it travels

The spreading deserves its own picture, because it is the part with organisational consequences rather than personal ones:

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 4: the mechanism is "write a file to a drive letter". That is all. Which is precisely why none of the usual defences engage with it

Two things follow from this, and they are the two I would actually put in an email to a team.

Patching is irrelevant here. There is no vulnerability in the chain. A fully updated, fully supported machine runs this exactly as well as an unpatched one. The only thing standing between the file and execution is whether a person double-clicks it.

One laptop can contaminate a department. The moment it reaches a mapped network share, the fake folder is sitting in a location that many people open in the normal course of their work — and every one of them is a fresh opportunity. This is why the cleanup instruction that matters is not "reimage the laptop" but "go and look at the shares that laptop could write to". Skip that and you reinfect from your own file server.

And then it earned nothing

Here is where the story turns, and where the interesting security lesson lives. The malware did everything above successfully. It also achieved precisely zero of its actual 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 5: both channels dead, and the local half of the infection completed at full speed regardless

Both failures are worth understanding because neither is a defence working.

The check-in website was still up and perfectly healthy. What had gone was the operator's files on it. That is a strong hint about the nature of that site: it was not the attacker's own server but somebody else's legitimate website, quietly used as a drop point and since cleaned up. Someone's blog was doing unpaid work for a malware campaign and has since had a tidy-up.

The mining pool failed for an even more mundane reason. It now sits behind a large web front-end service, the kind that fronts a huge share of the internet. Those services carry web traffic. Mining traffic uses a different port and a different protocol, so it simply is not carried. The malware dialled 54 times and never got an answer.

And it never noticed. Not once in the entire chain does it check whether a network call succeeded. So it completed the local half of the infection at full speed — copy, auto-start, auto-start, spread — while being completely cut off.

Which produces the finding I would want a defender to take away: "the network side failed" and "we're fine" are not the same statement. A report that says "no successful connections observed" describes the attacker's bad luck, not your protection. The machine was still fully compromised and still spreading.

The context: this file is eleven years old

The mining programs inside it were compiled in 2014 and early 2015, and that dates the whole package. It matters because Monero deliberately changed the mathematics of its mining several times, ending with a wholesale change in late 2019. A miner built for the old maths cannot produce anything the new network will accept.

So this is a fossil, found in quarantine on a machine in January 2026. But "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 6: the left column is why it gets triaged as low priority. The right column is why that is a mistake

The right-hand column is the whole argument of this post. Look at the third item in particular. Buried in the chain is a step that reads a URL from a small configuration file, downloads whatever is at that address, and runs it hidden. In this build that config entry is empty, so the step is skipped and nothing is fetched.

But the machinery is intact. One line in a text file turns an obsolete cryptominer into a live delivery mechanism for anything the operator likes — ransomware, an info-stealer, whatever is fashionable. That capability never ran, so no dynamic analysis would report it. It only shows up if you read what the installer can do rather than what it did.

Which is the general lesson, and it is not specific to this family: a detonation report tells you one path through the program. It does not tell you what the program is capable of. Six capabilities in this sample never executed. The most serious one is the one that never executed.

So what do you actually do about it

Nothing here needs a new product. In rough order of how much good it does:

  1. Turn file extensions back on. Explorer → View → File name extensions. The entire disguise collapses the moment images.scr stops rendering as images. It is a checkbox, it is deployable by policy, and it defeats a whole class of this.
  2. Treat an executable at the root of a drive as an anomaly. Legitimate software does not install itself to D:\. A file at a drive root with an executable extension is worth an alert on its own.
  3. Alert on mining command lines, not on mining files. Miners are commodity, endlessly repacked, and their file hashes are worthless within days. But something that launches a program pointing at a mining pool has to say so on the command line. That one signal caught an eleven-year-old sample and will catch next year's.
  4. When you find one, go and look at the shares. The infected endpoint is usually the least interesting artifact. The file server it could write to is the one that reinfects everybody.
  5. Read the installer, not just the report. If a sample is an installer script — and a great many droppers are — the script is the capability list. The sandbox only shows you the path it happened to take.

And one thing not to do: do not block the IP address of a big web front-end service because it appeared in a report. It is shared with an enormous portion of the legitimate internet, the attacker's real server is hidden behind it anyway, and blocking it fleet-wide will cause an outage considerably more disruptive than the malware.

Takeaways

  1. The exploit was a default setting. Hidden file extensions plus a custom icon plus a human expectation. No vulnerability, so no patch helps.
  2. Every step buys the next one. Reassure before installing, copy before launching, persist before spreading. Reading the order tells you what the author was worried about.
  3. It measures itself. Seven check-ins, replies discarded, purely to count conversion. Treat these people as running a product, because they are.
  4. Failed network activity is not protection. Both channels were dead and the infection still completed, persisted and spread. "No successful connections" describes their luck, not your defences.
  5. Obsolete payload, current risk. The mining is finished; the worm, the two auto-starts and a dormant download-and-run step are not. Triage capability by capability, never by headline verdict.

The deep version — 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.