Malware that never touched the disk
Someone left a backdoor on a Windows machine without saving a single file. It hid inside a database Windows keeps for its own housekeeping — and ran itself once an hour, as the most privileged account on the system.
- T1546.003 Event Triggered Execution: WMI Event Subscription
- T1027 Obfuscated Files or Information
What I was given
Five files with no extensions. No program to run, no obvious clue — just raw data lifted off a Windows machine after something bad had already happened. That is what real forensic work usually looks like: you rarely get the live computer, you get a copy of part of it and have to work out what happened from the leftovers.
The files turned out to be Windows’ own internal database. Windows keeps a store of management information about itself — how much memory is free, what is running, what time it is. It is ordinary housekeeping, and it lives on disk in a handful of files.
The clever part
That housekeeping database can also schedule things. You can register a rule that says “when this happens, run that.” It exists so administrators can automate maintenance, and it runs with the highest privileges on the machine.
Whoever attacked this host registered a rule of their own:
Every hour, at half past, run this command.
The command launched PowerShell with its instructions scrambled into a block of gibberish text. Decoding it revealed something better than a virus: a set of instructions for fetching one.
The program itself was not on the hard drive at all. It had been stuffed into the
same housekeeping database, inside a made-up entry with a boring name —
Win32_HardwareTelemetry — sitting in a field called ConfigData. Every hour, the
scheduled command woke up, read the program back out of the database, unpacked it in
memory, and ran it. Nothing was ever written to disk as a program.
That is what “fileless” means, and it is why this technique is popular. Antivirus scans files. There was no file to scan. There was no suspicious item in the startup folder, no unfamiliar scheduled task, nothing in the usual places anyone would look.
What the payload actually did
Pulling the hidden program out and taking it apart showed how small the ambition was:
- Check the computer’s name. If it was not one specific machine, do nothing at all.
- On the right machine, create a new local user account called
patch.
The name is chosen the way all good hiding is chosen — patch looks like something
that belongs. The password was stored scrambled, and decoding it produced the answer
the exercise wanted.
Step one is worth pausing on. Malware that refuses to run anywhere except its intended target is malware that will not misbehave in a security researcher’s test environment. It is a small detail that makes the attack considerably harder to study.
Where I lost time
I spent a while assuming the hidden program would be compressed in the normal way, because almost everything is. It was not — it used a rawer form with none of the usual header bytes at the front. Every tool I pointed at it reported a corrupt file, which sent me looking for damage that was never there.
The lesson was not about compression. It was that “the tool says it’s broken” and “it’s broken” are different statements, and I had stopped distinguishing them.
How you would actually catch this
This is the part most writeups skip, and it is the only part that matters defensively.
Sysmon Event IDs 19, 20 and 21 exist for precisely this technique — one for the trigger being registered, one for the action, one for the two being linked. They were added because this attack is common. They are not enabled in most default configurations, which is why this works as often as it does.
Beyond that:
- Windows’ own WMI activity log records these registrations. It is off by default too.
- PowerShell script block logging (Event ID 4104) records what a scrambled command actually says, at the moment it runs. It would have printed this entire loader in plain text.
- Security Event 4720 fires whenever a local account is created. That is the final step of the attack, and the noisiest thing it does.
The honest summary: none of this needed a clever detection rule. It needed logging that ships turned off. The detection gap here is a configuration gap.
Why I wrote this one up
I wrote a rule for encoded PowerShell in my own monitoring setup, and it has since fired on real activity from a Windows machine in my lab. This room is where I understood what that rule is actually looking at — and, more usefully, what it would still miss.
Flags are redacted throughout. These are learning writeups, not answer keys.