I Detonated Real Ransomware in a VM. Here’s the Forensic Trail It Left.

| Ransomware | Blue Teaming | Forensic | Cybersecurity | Wireshark | Malware Bazaar |

There is a specific kind of nervousness that comes from double checking your network settings for the third time before deliberately running a real piece of malware on purpose. Not a simulation, not a sample written for a classroom. An actual ransomware family pulled from a live threat intelligence repository, downloaded, verified, and detonated inside a machine that existed for exactly this purpose and nothing else.

This is the story of that machine's last few minutes before I reverted it back to clean.

You do not just download malware casually

The sample came from MalwareBazaar, a public repository where security researchers share real world malicious files specifically so people can study them safely. Before touching anything, I pulled the listed metadata for the sample. A SHA256 hash a file size a first seen date and a signature clasification identifying it as AESCrypt a known ransemware family.

The file itsilf arrived as a password protected zip which is standard practice for these repositoris specifically so that antivirus engines and email filters do not detonate it accidentally during transfer. After extracting it with the default repository password the very first thing I did was hash it again and compare that hash against the one MalwareBazaar listed.

They matched exactly. That single check matters more than it sound. It confirms that file you are about to analyze is genuinely the sample you intended to study untampered unmodified and not something silently swaped during downloads. Skipping that step means you might end up analyzing the wrang file entirely and drawing conclusions about a threat that was never actually in front of you.

Building a cage before opening the door

Before the malware touched anything, the lab needed to be locked down properly. The analysis machine, a Windows 10 virtual machine, was set to an internal isolated network with no route to the actual internet. A clean snapshot labeled specifically as a pre execution baseline was taken, so that no matter what happened next, I could roll the entire system back to this exact second.

Monitoring tools went up before the malware did, not after. Process Monitor was configured and ready to capture every system call. Wireshark was capturing on the isolated interface. Windows Defender was left active and running normally, since watching how a fully patched, fully protected modern operating system actually responds to a real threat was part of the point.

Only once every one of those pieces was confirmed running did the sample actually get transferred onto the analysis machine.

What static analysis could and could not tell me

Before running anything, I tried pulling readable text directly out of the binary using the strings command, hoping to find plaintext clues like URLs or configuration data. What came back instead was page after page of unreadable, scrambled looking content. A few PE section names were visible, the structural skeleton any Windows executable needs to have, but almost nothing else was human readable.

That itself was the finding. The binary was packed meaning its real content had been comprassed or encrypted and would only reveal itself once the program actually started running and unpacked itself in memory. Static analysis just reading the file sitting still had hit a wall. The only way forward was to actually let it execute and watch what happened in real time.

Pressing play

The moment the sample launched Windows Defender did not hesitate. Within seconds it identified the file and classified it as a trojan flegging it as a severe threat. That alone was reassuring, since it confirmed the modern operating system's built in defenses were doing exactly what they are supposed to do.

But Defender flagging something tells you that it is bad. It does not tell you how it is bad, and that is where Process Monitor became the real story. Over the course of the malware's brief life on that machine, it generated well over two hundred thousand recorded system events. Buried inside that mountain of activity were a few patterns that mattered far more than the rest.

The process immediately began querying deep into the Windows registry, specifically areas related to system configuration, the kind of behavior consistent with a piece of malware checking what environment it had landed in before deciding what to do next. It also accessed several core Windows system libraries in a sequence that read less like normal software loading its dependencies and more like an attempt to inject itself somewhere it did not belong.

The network told its own story

While Process Monitor was capturing what the malware did on disk and in memory Wireshrk was capturing what it tried to do on the wire and this is where things got genuinely interesting.

Almost immediately after excution the network capture lit up with a burst of DNS queries. Some of them, like a lookup for a local proxy discovery service looked like generic reconnaissance, the malware quietly trying to understand the network environment around it. Others pointed toward legitimate looking domains tied to Microsoft services and telemetry providers, the kind of destinations that could just as easily be normal background noise from Windows itself as they could be an attempt to blend malicious traffic into ordinary looking patterns.

That ambiguity is actually the realistic part. Real malware analysis rarely hands you a glowing neon sign that says command and control server right here. It hands you a burst of DNS activity that looks suspicious in context and demands you cross reference timing, destination, and behavior before drawing any conclusion at all.

Writing it all down properly

None of this mattered until it became a structred incident report. I built mine around the NIST SP 800 61 framework the same structure real incident response teams use walking through preperation detection, containment eradication recovery and a final lessons learned review.

The containment phase was straightforward since the machine was already isoleted by design but I still walked through what contaiment would mean in a real production environment. Quarantine the affected segment. Reset any potentially exposed credentials. Push the indicators of compromise, the hashes, the process names, the suspicious domains, into the organization's detection systems immediately so the same threat cannot land twice.

Eradication meant removing the sample and its associated files, checking common persistence locations like scheduled tasks and registry run keys, and confirming nothing had managed to survive a Defender scan afterward. In this particular case, Defender's early interception meant the malware never achieved full persistence, which was itself a useful and slightly reassuring finding.

Recovery was the easiest part of the entire process precisely because of a decision made before any of this started. Reverting to that pre execution snapshot restored the machine to a verified clean state in minutes, no manual cleanup required, no lingering doubt about whether something had been missed.

What this actually teaches you

The biggest lesson from this entire exercise was not about ransomware specifically. It was about the limits of any single analysis technique. Static analysis alone would have told me almost nothing, since the binary was packed specifically to defeat that kind of inspection. Antivirus detection alone would have told me something was bad without explaining how or why. Network monitoring alone would have given me a list of suspicious domains with no context about what process generated them or what that process did on disk first.

It took all three layers together, static inspection, behavioral monitoring, and network capture, layered against a structured response framework, to actually turn a malicious file into a complete, defensible story about what it tried to do and how it was stopped.

That is the real difference between knowing malware exists and knowing how to investigate it. The first one you can learn from an article. The second one only comes from sitting in front of the actual chaos it leaves behind, and writing down everything you find, in order, properly, every single time.