マルウェア分析の理解：種類、方法論、ラボセットアップの基本

I've been digging into malware analysis lately, and one thing became clear pretty fast: before you ever touch a debugger or run a suspicious binary, you need to understand the landscape — what malware actually is, how it's classified, and what a safe, repeatable analysis workflow looks like. This post is my attempt to organize that foundation. No flashy exploit walkthrough here — just the core concepts I think anyone starting out in malware analysis needs to internalize first, because skipping this step is how people either get sloppy or get burned (sometimes literally infecting their own host machine). Problem Statement If you search "malware analysis tutorial," you mostly get tool-specific guides — "how to use Ghidra," "how to use Process Monitor" — without context on why you'd choose static vs. dynamic analysis, or how to build a lab that won't accidentally compromise your real network. I wanted to write down the methodology layer first: the classification of malware, the four analysis approaches, and the non-negotiables of lab isolation. This is the stuff that makes the tool-specific tutorials actually make sense later. What Malware Analysis Actually Is Malware analysis is the study of a malicious program's behavior — the goal is to understand what it does, how it got in, and how to detect/eliminate it across an environment, not just on one infected machine. A few concrete objectives that stuck with me: Determine the nature of the malware — is it an infostealer, a keylogger, a spam bot, ransomware? Understand the compromise — how did it get in, and what's the blast radius? Infer attacker motive — banking credential theft usually points to financial motive; persistence + C2 beaconing might point to espionage. Extract network indicators — domains, IPs, User-Agent strings — for network-level detection. Extract host-based indicators — registry keys, dropped filenames, mutexes — for endpoint-level detection. This connects directly to something called the Pyramid of Pain — a model showing that not all indicators are equally valuable to defenders: Hash Values → Trivial for attacker to change IP Addresses → Easy Domain Names → Simple Network/Host Artifacts → Annoying Tools → Challenging TTPs (Techniques/Tactics/Procedures) → Tough for attacker to change The higher you climb the pyramid, the more it costs the attacker when you detect/block it. A hash is trivial to regenerate by recompiling; a TTP (like "this group always uses macro-based phishing + a specific persistence registry path") is much harder for them to abandon. Malware Classification: Knowing What You're Dealing With Before analyzing a sample, it helps to know which bucket it likely falls into, since that shapes your expectations about propagation and payload. Viruses Viruses require human interaction to spread — opening an infected file, running infected media. They don't self-propagate. Propagation techniques I noted: Technique Description Master Boot Record viruses Infect the boot sector, execute before the OS loads File infector viruses Attach to executables, trigger on execution Macro viruses Abuse scripting in Office documents (e.g., Melissa virus) Service injection viruses Inject into trusted processes like svchost.exe , explorer.exe The Melissa virus is the classic example — it used Word macros to email itself to the first 50 contacts in the victim's Outlook address book the moment the infected document was opened. Worms Worms are standalone and self-replicating — no host file, no human interaction needed. They spread by exploiting vulnerabilities directly. Two examples that came up: Code Red — exploited a buffer overflow in Microsoft IIS, self-replicated by scanning for vulnerable servers, then defaced hosted websites. Stuxnet — targeted SCADA systems specifically, spreading via Windows vulnerabilities and USB drives, with a payload built to sabotage Siemens PLCs controlling centrifuges. A genuinely different class of malware — built for physical-world sabotage, not just data theft. Trojans Trojans look benign but carry a hidden malicious payload . They don't self-replicate — they rely on the user downloading or copying them. Sub-categories worth knowing: Remote Access Trojans (RATs) Rogue antivirus software (fake security tools that are the malware) Cryptomalware (mining cryptocurrency on the victim's hardware) Botnet clients The Four Types of Malware Analysis This is the part I found most useful — a clear framework for how to approach any sample. 1. Static Analysis → Examine without executing 2. Dynamic Analysis → Execute in isolation, observe behavior 3. Code Analysis → Disassemble/debug to understand internals 4. Memory Analysis → Inspect RAM for forensic artifacts 1. Static Analysis Look at the binary without running it . You're extracting metadata: file hashes, packer signatures, embedded strings, imports/exports, digital certificate info. It won't tell you everything, but it's low-risk and often tells you where to focus next. A good rule of thumb from the methodology: start by asking "Is it malware? How bad is it? How do I detect it? How do I analyze it?" — static analysis is usually how you answer the first two. Typical static analysis checklist: File and section hashes Packer identification Embedded resources Imports and exports Crypto API references Digital certificates "Interesting" strings (URLs, registry paths, mutex names) 2. Dynamic (Behavioral) Analysis Run the sample in an isolated sandbox and observe what it does — processes spawned, files written, registry keys created, network connections attempted. This reveals real-time behavior but won't expose every code path (malware often has logic that only triggers under specific conditions). 3. Code Analysis This is where you go from "what does it do" to "how exactly does it do it." Static code analysis — disassemble the binary, read the assembly without running it. Dynamic code analysis — step through execution with a debugger, watching registers and memory live. This requires understanding both the programming/assembly layer and OS internals — definitely the steepest part of the learning curve. 4. Memory Analysis Inspect RAM, usually via a memory dump, to catch artifacts that static and dynamic analysis miss — especially useful against malware designed to evade detection or that only materializes fully in memory (fileless malware, process-injected code). Building a Safe Analysis Lab — The Non-Negotiables This is the part I want to emphasize because it's easy to skip and genuinely risky if you do. Isolation is mandatory, not optional The lab network must be isolated from your production network and from the internet by default. Virtual machines (VirtualBox, VMware, Hyper-V) are the standard approach — multiple guest OSes running on one physical host, each set up like a normal machine but disposable. A typical lab layout: a Windows analysis VM + a Linux VM (often REMnux, a Linux distro purpose-built for reverse engineering) communicating over a host-only virtual network. Laboratory Network — 172.16.198.0/24 (isolated, host-only) ├── Windows 10/11 VM (REM Workstation) └── Linux VM (REMnux) Snapshots are your safety net Virtualization software lets you snapshot a clean VM state and roll back instantly after infecting it. This is the single biggest workflow advantage over physical hardware — you can re-infect, observe, revert, repeat, without ever rebuilding from scratch. For physical machines (when virtualization isn't an option, e.g., malware that detects VMs), you'd instead clone a clean disk image with tools like Clonezilla or dd and manually restore it post-analysis — far less convenient, but sometimes necessary. Anticipate anti-analysis tricks Some malware actively tries to detect that it's being watched — checking for virtualization artifacts, debugger presence, or sandbox indicators. If it detects analysis, it might terminate itself, sleep, or behave differently to throw off the investigator. Knowing this exists going in stops you from concluding "this sample is harmless" prematurely when it might just be hiding from your tools. Be careful with external connections If your investigation needs to reach the internet — following a C2 domain, checking OSINT sources — never do it from your normal connection or from inside the isolated lab network directly. Options range from Tor (weaker, exit nodes can be tracked) to a self-hosted VPN you spin up and destroy per-investigation. And critically: uploading a sample to a public service like VirusTotal makes your interest in that sample visible to anyone else watching it — including, in a targeted attack scenario, the attacker. How to Verify Since this article is methodology/notes-based rather than a completed hands-on lab, here's what verification looks like for this stage of learning: [ ] I can explain the difference between a virus, worm, and Trojan without notes [ ] I can name all four types of malware analysis and what each one reveals [ ] I understand why host-only networking matters for a malware lab [ ] I understand why VM snapshots are critical to a repeatable workflow [ ] I know why uploading a sample to a public sandbox has tradeoffs What I Learned The biggest shift for me was realizing malware analysis isn't really about memorizing tool commands — it's about having a decision framework . Static analysis first because it's cheap and safe. Dynamic analysis to see real behavior. Code analysis when you need to know exactly how something works at the instruction level. Memory analysis when the malware is actively trying to stay invisible. The lab isolation piece also reframed something for me: the "lab" isn't just a VM you click into — it's a deliberately engineered environment with isolation, repeatability, and anti-detection considerations baked in from the start. Skipping any of those isn't a shortcut, it's a liability. Common Mistakes Mistake Why It's a Problem Better Approach Running unknown samples on your main machine Real r