Malware Analysis and Response Procedures: A Practical Playbook for Security Teams

February 9, 2023•Incident Response•3 min read

It was 2:47 AM when the SIEM alert fired—an endpoint in accounting was beaconing to a known C2 domain every 90 seconds. By 3:15 AM, three more hosts had joined the chorus. The difference between this becoming a reportable breach and a contained incident came down to one thing: a well-rehearsed malware analysis and response procedure. Here's the playbook your team needs before that alert fires.

Phase 1: Initial Triage and Isolation

The moment you suspect malware, your priority is containment without evidence destruction. Pulling the network cable is tempting, but it kills volatile memory artifacts. Instead, use network-level isolation.

If your EDR supports it, isolate the host from the network while maintaining management connectivity:

# Example: CrowdStrike Falcon - contain host via API
curl -X POST "https://api.crowdstrike.com/devices/entities/devices-actions/v2?action_name=contain" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"ids":["<device_id>"]}'

If you lack EDR isolation capability, use firewall rules to quarantine the VLAN segment:

# Isolate a specific host at the switch/firewall level
iptables -I FORWARD -s 10.10.5.23 -j DROP
iptables -I FORWARD -d 10.10.5.23 -j DROP
# Allow only your forensic workstation
iptables -I FORWARD -s 10.10.5.23 -d 10.10.1.100 -j ACCEPT

Document the exact time of isolation. Every action from this point forward should be logged in your incident tracking system.

Phase 2: Volatile Data Collection

Before imaging the disk, capture what disappears at reboot. Memory, network connections, and running processes are gold during analysis.

# Capture memory dump using WinPMEM (Windows)
winpmem_mini_x64.exe memdump.raw

# On Linux, grab volatile artifacts
ps auxf > /evidence/running_processes.txt
netstat -tulpn > /evidence/network_connections.txt
ss -tp > /evidence/socket_states.txt
cat /proc/*/maps > /evidence/process_memory_maps.txt
lsof -i > /evidence/open_network_files.txt

Hash everything you collect immediately:

sha256sum /evidence/* > /evidence/hash_manifest.txt

This hash manifest preserves your chain of custody and proves evidence integrity if the incident escalates to legal proceedings.

Phase 3: Static and Dynamic Analysis

With evidence secured, move to analysis. Start static—examine without executing.

# Extract strings from suspicious binary
strings -n 8 suspicious.exe | grep -iE "(http|cmd|powershell|reg add|socket)" > strings_output.txt

# Check file type and PE headers
file suspicious.exe
peframe suspicious.exe

# Query hash against VirusTotal API
curl -s "https://www.virustotal.com/api/v3/files/$(sha256sum suspicious.exe | cut -d' ' -f1)" \
  -H "x-apikey: $VT_API_KEY" | jq '.data.attributes.last_analysis_stats'

For dynamic analysis, always use an isolated sandbox. Tools like ANY.RUN, Joe Sandbox, or a local Cuckoo Sandbox instance let you observe runtime behavior—registry modifications, dropped files, network callbacks—without risking production infrastructure.

Phase 4: Indicator Extraction and Threat Hunting

Every malware sample yields indicators of compromise (IOCs). Extract them systematically and hunt across your environment:

# Example YARA rule generated from analysis
rule Accounting_Trojan_Jan2025 {
    strings:
        $c2_domain = "update-service-cdn.xyz"
        $mutex = "Global\\XR84_MTX"
        $registry_key = "HKCU\\Software\\WindowsUpdate\\Run"
    condition:
        2 of them
}

Deploy these IOCs immediately to your SIEM, EDR, and DNS filtering platforms. Hunt retroactively through at least 30 days of logs to determine initial access time and lateral movement scope.

Phase 5: Eradication and Recovery

Reimage compromised hosts entirely—never trust a "cleaned" system. Reset credentials for any accounts that touched infected machines. Patch the vulnerability that enabled initial access. Then monitor the recovered systems with heightened scrutiny for 30 days.

Building Muscle Memory

The best response procedures are the ones your team has practiced before the real event. Run tabletop exercises quarterly. Detonate safe malware samples in your sandbox monthly. Review and update your runbooks after every incident. The goal isn't perfection—it's reducing your mean time to containment from hours to minutes.

Have questions about malware analysis and response procedures? I'm always happy to talk shop — reach out or connect with me on LinkedIn.

← Back to Articles