Nobody Taught Me Malware Analysis. I Had to Figure It Out the Hard Way.

I remember the exact moment I got obsessed.

I had a suspicious .exe sitting in my VM. I ran it, not really expecting much. Then I opened Wireshark — and watched it silently phone home to some random IP in Eastern Europe, write itself into the registry, and try to kill my antivirus process.

All of this happened in about four seconds.

I just sat there staring at the screen. Something that looked like a normal file was doing all of this under the hood, and nobody around me had any idea. That feeling — of seeing what others can't — that's what pulled me into malware analysis. And honestly, it never really goes away.

If you're reading this, you're probably curious about this field but don't know where to begin. Maybe you've Googled it and landed on some dense academic paper or a YouTube video that assumed you already know assembly. Maybe you got discouraged.

This is not that. I'm going to tell you exactly how I'd start if I were beginning today — no fluff, no gatekeeping.

Let's clear something up first

Malware analysis sounds intimidating. People picture some genius reading raw hex dumps at 3am. The reality is way more accessible than that.

At its core, you're just answering a few questions about a suspicious file:

• What does it actually do?
• How does it try to hide?
• What does it touch — files, registry, network?
• How do we stop it?

That's it. You're a detective. The malware is your crime scene. And like any detective work, you don't need to know everything upfront — you just need to know how to ask the right questions.

Before anything else — build a safe place to work

Please don't skip this part. I've seen people run malware on their actual machines "just to see what happens." Don't be that person.

Get VirtualBox (it's free) and install Windows 10 inside it. Microsoft actually gives away evaluation ISOs — just search "Windows 10 evaluation ISO Microsoft." Once it's set up and clean, take a snapshot. That snapshot is your undo button. Every time you're done analyzing something, you revert to it and start fresh.

Also make sure the VM can't access your real files. Go into VirtualBox settings and disable shared folders and clipboard sharing. Your host machine should be completely invisible to anything running inside the VM.

If setting all that up feels like too much right now, just use Any.run. It's a browser-based sandbox — you upload a file, it runs it for you, and you watch everything that happens in real time. Free tier exists. It's honestly a great place to start before you even touch local tools.

The two ways you'll look at malware

Every analysis you ever do will involve some mix of these two approaches:

Static analysis — you look at the file without running it. You're reading its structure, pulling out strings, checking what Windows functions it imports. Think of it like reading someone's search history before you've even met them.

Dynamic analysis — you actually run it and watch what it does. What files does it create? What does it connect to? Does it try to inject itself into another process?

You usually start static to get a rough picture, then go dynamic to confirm. Neither one alone tells you the full story.

The tools I actually use

You don't need to spend money on any of this.

For static work, I use pestudio almost every time — it's one executable, no install needed, and it shows you strings, imports, file metadata, and a bunch of red flags all in one window. Pair it with Detect-It-Easy to figure out if the file is packed or obfuscated (more on that later), and FLOSS by Mandiant when the strings are hidden.

For dynamic work, the three tools I always have open are Process Monitor, Wireshark, and Process Hacker. ProcMon shows you every file and registry operation in real time. Wireshark captures all the network traffic. Process Hacker gives you a deep look at what's running and what's hiding.

One more — Regshot. It takes a snapshot of your registry before you run the malware, then after, and shows you exactly what changed. This is how you catch persistence — how the malware makes sure it survives a reboot.

What an actual analysis looks like

Say you've got a suspicious file. Here's roughly how I'd approach it.

First, before I even think about running it, I grab the SHA256 hash and throw it into VirusTotal. If 40 antivirus engines are already flagging it, great — I know what I'm dealing with. If it's clean, interesting — might be something new, or might be nothing.

Then I open it in pestudio. I'm looking at the strings section hard. Real malware tends to hide things, but you'd be surprised how often you find a hardcoded IP address, a domain name, a file path, or a registry key just sitting there in plain text. I've found full C2 server URLs this way.

I'm also checking the imports — the list of Windows API functions the file uses. Certain combinations are red flags. VirtualAllocEx and WriteProcessMemory together? That's process injection. CryptEncrypt and FindFirstFile? Possibly ransomware walking through your files to encrypt them.

Once I've got a mental model from static analysis, I fire up the VM, open ProcMon and Wireshark, take a Regshot baseline, and run the thing.

Then I just watch.

Does it spawn child processes? Does it try to reach out to the internet? Does it drop files somewhere weird like C:\Users\Public or %AppData%? Does it kill any processes? I let it run for a few minutes, then take the second Regshot and compare.

By the end, I usually have a pretty clear picture of what the malware was trying to do — even if I haven't read a single line of assembly code.

Where to get samples to practice on

MalwareBazaar (bazaar.abuse.ch) is where I'd send anyone who's starting out. It's a free repository of real malware samples, tagged by family. Download something labeled "AgentTesla" or "AsyncRAT" and start poking at it.

Any.run also has a public feed of submissions you can browse — you can look at what other people are analyzing and read through the behavioral reports. This alone taught me a ton when I was starting.

Start with well-documented malware families. WannaCry, Emotet, Raccoon Stealer — there's years of public research on these. Analyze one yourself, then compare your findings to what the pros wrote. That gap between what you found and what they found is your curriculum.

The honest learning curve

Month one is going to feel slow. You'll spend more time setting up tools than actually analyzing anything, and that's fine. Get comfortable with your environment. Run some samples through Any.run just to watch what malware actually does. Read other people's analysis write-ups on blogs like MalwareBytes Labs or Securelist.

Around month two, you'll start to recognize patterns. You'll see a suspicious import and immediately think "ah, this is probably doing X." That pattern recognition is the whole game — and it only comes from repetition.

By month three, if you've been consistent, you should be able to sit down with an unknown sample, spend an hour on it, and produce a reasonable report with IOCs — indicators of compromise like IPs, domains, file hashes, registry keys. That's genuinely useful output. People pay for that.

If you want to go deeper into the code itself — actually reading assembly and stepping through malware in a debugger — that's where x64dbg comes in. But I'd say don't rush there. Get the fundamentals solid first.

One last thing

The security community is one of the most open and generous communities I've been part of. People share their research, post their tools for free, write detailed blogs about their analysis. That culture exists because everyone who's good at this was once a confused beginner who got help from someone else.

So ask questions. Post your findings even when you're unsure. Write about what you learn. The worst thing that can happen is someone corrects you — and now you know more.

Your first analysis won't be perfect. Neither was mine. That's not the point.

The point is to start.

If you made it this far — thanks for reading. This is my first article on Medium, and I write about malware analysis, reverse engineering, and what I'm currently learning as a security researcher. Follow if that sounds interesting to you, and drop a comment if you have questions or want me to do a deep-dive on a specific malware family.