Achilles Rogan

Project

Malware Analysis Lab

In progress
This page describes planned and underway work. It has no results or findings yet, and it will be updated as the lab is built.

Overview

I am building a personal malware analysis lab as a portfolio piece for SOC and detection engineering roles. The plan covers static and dynamic analysis, pulling indicators of compromise (IOCs) out of each sample, and writing YARA and Sigma rules from what the analysis actually shows.

The work is staged so that skill-building comes first and risk stays low. Live malware comes last, and only if the lab's isolation has been proven and approved.

Goals

  • Analyze samples without putting my own systems, my network, or anyone else at risk
  • Practice a repeatable workflow: triage, static analysis, controlled detonation, and documentation
  • Extract IOCs and behaviors in a form that detection tooling can use
  • Turn analysis into YARA rules (for files) and ATT&CK-mapped detections (for logs), each with test notes and known limitations

Planned approach

Staged, lowest risk first

  1. Traffic analysis exercises: working from published packet captures, with no live execution
  2. Public sandbox and vendor reports: studying documented samples from published analysis, with no binaries handled
  3. Training and CTF-style samples: material built for practice
  4. A live sample (optional, last): one carefully handled sample from a public malware-sharing service, only after isolation is proven and approved

If the live-sample stage is never used, the earlier stages still produce a complete portfolio piece.

Safety and isolation by design

  • Suspect files are never stored or opened on my daily-use computer or on shared workspaces
  • Samples are handled only inside an isolated, snapshotted analysis virtual machine on a private virtual network with no route to my home network or the internet
  • No live internet during detonation. Network behavior is observed against a simulated internet service inside the lab
  • Sharing features that could move files or clipboard data out of the VM are disabled
  • The VM is reverted to a clean snapshot after every session
  • Password-protected sample archives stay encrypted until they are inside the isolated VM. Only hashes, written findings, and detection rules leave it
  • Published IOCs are defanged, and no live samples are shared

Toolset (all free and open)

  • A Linux malware analysis distribution as the main analysis environment
  • A Windows analysis VM, built with an open-source tooling installer on a time-limited official evaluation copy of Windows, only when Windows behavior needs to be observed. It is never built on a daily-use computer
  • Ghidra for reverse engineering, capa for identifying capabilities, FLOSS for extracting strings, YARA for file rules, and Wireshark for traffic
  • A fake-internet service, so a sample can be observed without a live network path

Workflow

  • Static analysis: hashes, file metadata, strings, imports, capabilities, and packing checks before anything runs
  • Dynamic analysis: controlled detonation with process, file, registry, and network activity recorded
  • IOC extraction: file hashes, network indicators, persistence locations, and behavioral notes
  • Detection: YARA rules for the sample family and Sigma (or SIEM) rules for the behavior, both tested against lab data

What it will demonstrate

  • Safe handling of malicious files, an everyday concern for SOC and incident response teams
  • Moving from a suspicious file or capture to indicators a SOC can act on
  • Detection engineering based on real observed behavior, not guesswork
  • Clear write-ups that state what is known, what is assumed, and what a rule will miss

Planned deliverables

  • Three to four analysis write-ups
  • A small YARA rule set written from those analyses
  • One ATT&CK-mapped detection (Sigma and/or SIEM rule) per sample family, going through the same review-and-approval process as the rest of my detection engineering work

Status and roadmap

  • Now: the plan, safety rules, and staged sample strategy are drafted. The isolated lab design is under review
  • Next: build the isolated analysis environment and verify the isolation before any sample is handled
  • Then: work through the traffic analysis, report study, and training-sample stages, writing up each one
  • Later: publish sanitized write-ups and rules here, with test notes and limitations

Related: Home SOC lab and Detection rules.