Cyber Knowledge · Domain 05 of 11 · Practitioner field guide

Malware Analysis & Reverse Engineering

A source-backed, lab-first guide to answering the questions that matter: what a suspicious artifact is, what it can do, what it actually did, how confidently it relates to a family or campaign, and which durable controls, detections, hunts, and intelligence records should follow.

Controlled-analysis boundary

Handle only artifacts you are authorized to possess and analyze. Treat every unknown sample as executable, preserve provenance and hashes, use disposable isolated systems, disable shared folders and credentials, control egress, snapshot before execution, and never upload restricted material to a public service. This guide teaches defensive analysis—not malware development or uncontrolled deployment.

Start the field guide → Open malware labs AdversaryGraph workflow All domains

Version 1.0 Published 27 Jun 2026 Source review: 27 Jul 2026 Status: maintained practitioner guide Maintained by Andrey Pautov Editorial policy and corrections

Start here

Use a question-driven workflow, not a tool parade

Malware analysis is disciplined reduction of uncertainty. Every action should answer a defined question and produce reviewable evidence. A long list of strings, sandbox events, or model-generated claims is not analysis until an analyst explains identity, behavior, confidence, limitations, and operational consequence.

The repeatable analysis loop

Authorize and identify→ Preserve and hash→ Form hypotheses→ Static triage→ Controlled observation→ Reverse key logic→ Correlate→ Detect and hand off→ Archive reproducibly

Stop rule: stop when the decision can be made with sufficient confidence. Do not execute merely because execution is possible. If static evidence establishes that a document is a benign test fixture, dynamic detonation adds risk without value. If behavior changes by environment, preserve the uncertainty and escalate deliberately.

What good looks like

Analyst outcomes

Identity

Cryptographic hashes, size, format, architecture, signature state, acquisition path, timestamps, container relationships, and sample handling history.

Behavior

Observed and inferred process, file, registry, persistence, credential, network, discovery, injection, and impact behaviors—with evidence and confidence.

Code understanding

Important functions, data flows, configuration handling, decoding/decryption, capability gates, anti-analysis logic, and execution conditions.

Defender content

High-quality YARA candidates, behavioral detections, hunt leads, ATT&CK mappings, network indicators, enrichment pivots, and collection requirements.

Intelligence

Family and campaign hypotheses separated from fact, relationships to parent/dropper/payload/configuration, source citations, and attribution limits.

Incident decisions

Scope, containment priority, eradication needs, recovery caveats, affected assets, retrospective search criteria, and the evidence required to close the case.

Foundations

Observation, inference, and claim discipline

Separate what the artifact contains, what a tool reports, what was observed at runtime, and what the analyst concludes. This prevents a string from becoming a false capability, a sandbox label from becoming a family identity, or a shared IP from becoming attribution.

Evidence states

Observed: directly captured from the exact artifact or runtime.

Derived: deterministically decoded or computed with a documented method.

Corroborated: supported by an independent source or method.

Inferred: analytically plausible but not directly demonstrated.

Unknown: unanswered, inaccessible, or outside scope.

Do not conflate

A hash match is not family proof. An import is not executed behavior. A URL in a resource is not contacted infrastructure. An ATT&CK technique is not attribution. A compiler timestamp is not a trusted build date. A high-entropy region is not automatically encrypted. A model summary is not evidence.

Safety engineering

Build the lab before opening the sample

Minimum architecture

Analysis guests

A Windows analysis VM such as a controlled FLARE-VM installation for PE/.NET behavior and debugging.
A REMnux or equivalent Linux analysis VM for triage, document/script inspection, network simulation, and cross-platform tooling.
Separate Android emulator/device profiles for APK work; never reuse personal accounts or tokens.
Known-clean baselines, immutable tool manifests, synchronized time, and revertible snapshots.

Containment controls

Host-only or isolated virtual network; no bridge to corporate, home, VPN, or cloud-management networks.
No host clipboard, drag-and-drop, shared folders, mounted personal storage, cached cloud credentials, or password managers.
Simulated DNS/HTTP/TLS where possible; explicit allowlisted egress only when authorized and necessary.
Out-of-band emergency stop, resource quotas, packet capture, snapshots, and tested restore.

Containers are packaging, not a universal malware boundary. Kernel-sharing containers may be useful for non-executing parsers and reproducible tools, but unknown native code belongs in an appropriately isolated VM or physical research device with defense-in-depth controls.

Core curriculum

Fourteen practitioner modules

The modules are ordered to favor cheap, safe, high-information work first. Experienced analysts can jump directly to a question, but the evidence record should remain continuous.

Intake, provenance, and analysis scope

Module 01

Create a defensible chain from acquisition to decision before any parser or sample execution changes the environment.

Record the case, requester, authority, source, acquisition channel, original filename, container/password handling, timestamps, and handling classification.
Work on a copy; retain the original read-only. Calculate at least SHA-256 before transformation and again for every extracted child.
Define questions: family identification, capability confirmation, incident scope, configuration recovery, detection development, or all of these.
Choose the least risky analysis tier that can answer each question: metadata → static parsing → manual code review → emulation → controlled execution.
Record prohibited actions, external-service restrictions, retention, sharing group, deadline, and stop conditions.

Evidence: intake record, original and working-copy hashes, parent/child extraction graph, analyst/tool identity, environment snapshot, and question list.

Decision gate: if a public reputation lookup is permitted, submit the hash first—not the sample. Absence of a match means “unknown to that source,” not benign.

provenancechain of custodyTLPscope

File identity, containers, and executable formats

Module 02

Determine what the bytes actually represent instead of trusting extensions, MIME labels, or filenames.

Confirm magic, format, size, entropy distribution, architecture, endianness, compiler/runtime clues, overlays, nested archives, alternate streams, and malformed structures.
For PE, review headers, sections, entry point, import/export tables, resources, relocations, TLS callbacks, debug directory, authenticode state, Rich header caveats, and overlay.
For ELF/Mach-O, inspect segments, sections, interpreter, dependencies, symbols, entry points, signing/notarization data, and architecture slices.
For managed code, identify .NET/Java metadata and runtime; for scripts/documents, identify encoding, macros, embedded objects, templates, and launch relationships.
Build an artifact graph: archive → document/dropper → decoded payload → configuration → supporting files.

Quality rule: timestamps, signatures, section names, and compiler markers are hints. Report whether each is structurally valid, cryptographically verified, internally consistent, or attacker-controlled.

1200km practice: use the FileInfo project as a first-pass concept, then confirm important results with format-aware tools and manual inspection.

Static triage: strings, imports, resources, and capabilities

Module 03

Extract maximum useful context without executing the artifact.

Extract ASCII, UTF-16, stack, obfuscated, and decoded strings with offsets and provenance. Separate analyst-decoded values from literal file content.
Review imports by behavior cluster: process/thread, filesystem, registry, services, network, crypto, token/credential, injection, persistence, discovery, and anti-analysis.
Inspect resources for configuration, embedded executables, icons, manifests, certificates, decoys, and localization clues.
Run capability classifiers such as capa and format-aware rules; retain rule versions and raw output.
Form ranked hypotheses and identify the smallest next action that can confirm or reject each one.

Evidence: offset-addressed strings, import-to-capability table, resource hashes, classifier rule version, hypothesis list, and false-positive notes.

1200km guides: Strings analysis, PE Import Analyzer, and static triage to unpacking.

Architecture, calling conventions, and assembly literacy

Module 04

Understand machine state well enough to validate decompiler output and reason through behavior the compiler did not preserve for you.

Learn registers, flags, stack frames, memory addressing, instruction effects, control flow, and ABI conventions for the target architecture.
Recognize prologue/epilogue variation, tail calls, indirect calls, position-independent code, exception handling, switch tables, and compiler intrinsics.
Track data, not just instructions: source, transformation, destination, lifetime, ownership, and security significance.
Use cross-references and call graphs to move from a known indicator—string, import, resource, constant, protocol field—to the logic that consumes it.
Annotate uncertainty when types, boundaries, aliases, or compiler optimizations are ambiguous.

Practice pattern: compile small benign programs with different optimization levels, inspect their disassembly, and compare source intent to generated control/data flow before interpreting unknown code.

Disassembly, decompilation, and code-led analysis

Module 05

Turn binary structure into reviewed functions, meaningful names, recovered types, and testable behavioral explanations.

Import with the correct format, language, base, symbols, and analyzer settings. Record tool and processor specification versions.
Validate entry points, function boundaries, cross-references, thunk handling, imports, and memory maps before trusting the call graph.
Rename functions and variables based on evidence; distinguish names assigned by symbols, libraries, tools, and the analyst.
Recover structures and enums only when field access, size, lifetime, and call usage support them.
Follow high-value paths: configuration parsing, command dispatch, persistence, credential access, injection, crypto, communications, update/removal, and error branches.
Write a plain-language function summary with address, inputs, outputs, side effects, callers, callees, confidence, and open questions.

Evidence: annotated analysis database, function map, recovered type notes, cited addresses, pseudocode screenshots/exports where permitted, and a reversible audit trail.

Tools: Ghidra, IDA, Binary Ninja, radare2/Cutter, Rizin, objdump, and platform debuggers. Tool agreement increases confidence; it does not replace analyst review.

Controlled dynamic behavior and differential observation

Module 06

Observe state change in a disposable environment while controlling noise, trigger conditions, and containment.

Capture a clean baseline: processes, services, autoruns, filesystem, registry, scheduled tasks, network listeners, users, and relevant telemetry.
Start host and network collection before launch. Record sample hash, command line, user/integrity, environment, time, locale, network mode, and snapshot ID.
Exercise one controlled condition at a time: online/offline, privilege, locale, argument, file presence, time, or simulated server response.
Diff the final state against the clean baseline; correlate events by process tree, timestamp, path, handle, socket, and causality.
Repeat from snapshot to test reproducibility and negative controls. Preserve PCAP, process traces, logs, screenshots, dropped artifacts, and hashes.

Do not use the public internet as a laboratory. A sinkholed or simulated service is usually safer. If controlled egress is explicitly required, allowlist destinations and methods, apply rate limits, monitor continuously, and prevent scanning, propagation, messaging, or destructive effects.

Primary tools: Process Monitor, Process Explorer, Autoruns, Sysmon, Wireshark/tcpdump, FakeNet-NG/INetSim, API monitors, and reproducible sandboxes.

Debugging, tracing, and runtime instrumentation

Module 07

Pause at decision points, inspect machine state, verify hypotheses, and recover material that exists only at runtime.

Choose breakpoints from a question: decrypted configuration, resolved API, decoded payload, process creation, memory protection change, network send, or persistence write.
Prefer narrow breakpoints and conditional logging over indiscriminate single-stepping. Record module base and address-space changes.
Inspect arguments, return values, buffers, call stack, registers, and ownership before and after the operation.
Use trace, time-travel, or API instrumentation where timing-sensitive code becomes unstable under interactive debugging.
Dump runtime material only after validating its boundaries, permissions, and relationship to the original artifact; hash every dump.

Anti-debugging caution: a debugger changes timing and environment. Confirm important claims with a second observation method such as event tracing, API monitoring, instrumentation, or memory acquisition.

1200km practice: use the AIDebug 3.1 full release review as the platform map for binary intake, PE/ELF triage, functions, strings, Ghidra, optional AI review, controlled debugging, and reports. Continue with PE File Structure for Malware Analysis, Strings Analysis for Malware Analysis, and Assembly for Malware Analysis to validate each evidence layer.

Packing, obfuscation, and anti-analysis

Module 08

Identify transformations that conceal code or behavior, recover a stable representation, and retain the relationship to the original sample.

Treat entropy, tiny import tables, unusual sections, runtime-resolved APIs, self-modification, and entry-point stubs as indicators—not proof—of packing.
Identify common packers carefully; compare structural signatures and stub behavior rather than trusting a single label.
Prefer supported unpacking or deterministic decoding. For custom protection, locate allocation, copy/decode, permission change, transfer of control, and import resolution.
Dump at the correct stage, rebuild imports/metadata as needed, and validate that recovered code maps to the executed memory region.
Document anti-VM, anti-debug, timing, locale, hardware, user-interaction, and environment checks separately from malicious capabilities.

Evidence: original/payload hashes, parent-child relation, unpack point, memory range, import-rebuild method, validation results, and limitations.

1200km guides: Unpacker and static obfuscation analysis.

Memory forensics, injection, and resident behavior

Module 09

Recover evidence that is absent, encrypted, deleted, injected, or transformed on disk.

Acquire memory with an approved method and record platform/build, acquisition tool/version, time, state, and hash. Volatility analyzes images; it does not acquire them.
Establish the process tree, command lines, users, sessions, modules, handles, network state, and suspicious parent/child relationships.
Investigate executable private memory, permission transitions, unbacked regions, hollowed images, thread starts, cross-process handles, and anomalous modules.
Correlate suspected injected regions with source process activity, APIs, allocation/protection history, bytes, strings, and network behavior.
Extract bounded artifacts, hash them, and preserve address/process context. Validate detections against legitimate JIT, security, browser, and runtime behavior.

Claim discipline: “RWX memory” is an observation. “Injected malware” requires process, region, content, provenance, and behavior evidence sufficient to exclude common legitimate explanations.

Scripts, documents, shortcuts, and fileless chains

Module 10

Analyze multi-stage delivery and execution where the most important logic is encoded in scripts, macros, templates, archives, or living-off-the-land commands.

Inspect container relationships, file metadata, OLE/OOXML structures, macros, relationships, embedded objects, external templates, links, and shortcut fields without opening in a normal desktop workflow.
Normalize and decode scripts incrementally. Preserve each stage, encoding, command line, interpreter, and parent-child relationship.
Identify download, decode, execution, persistence, discovery, credential, and cleanup stages; separate present code from reachable/executed code.
Use language-aware parsers and constrained emulation before live execution. Treat remote content as a new artifact with its own provenance.
Translate stable behavior into script-block, command-line, process-chain, file, DNS, proxy, and endpoint detections.

Do not paste suspicious scripts into web decoders or general-purpose AI services. They may contain confidential data, live infrastructure, embedded instructions, or payloads. Use local tooling appropriate to the handling policy.

Android malware and mobile application behavior

Module 11

Analyze APK identity, manifest exposure, code, resources, native libraries, permissions, certificates, network behavior, and runtime abuse on a disposable mobile environment.

Hash the APK and its extracted components; record package name, version, SDK levels, signing certificate, split/APK set, installer context, and acquisition source.
Review manifest permissions, exported components, intent filters, services, receivers, providers, accessibility/device-admin use, deep links, and network-security configuration.
Trace from high-risk components and permissions into Java/Kotlin/native code; identify dynamic loading, reflection, WebView bridges, embedded DEX/SO, and obfuscated namespaces.
Use an emulator or owned research device with synthetic accounts. Instrument only within authorization; collect logs, files, traffic, IPC, and user-interaction triggers.
Separate application vulnerability findings from malicious intent. Map observed mobile behavior to the ATT&CK Mobile domain with citations and confidence.

Evidence: package/certificate identity, component map, permission-to-code paths, runtime trace, extracted configuration, network observations, and platform/version limitations.

1200km lab: build an Android analysis lab, use the terminal APK analysis toolkit, and follow the Android malware-analysis guide.

Network behavior, protocols, and configuration recovery

Module 12

Explain how the sample locates infrastructure, formats messages, authenticates, receives tasks, moves data, and changes behavior by configuration.

Extract candidate domains, IPs, URLs, paths, user agents, certificates, keys, mutexes, campaign IDs, and protocol constants with offsets and source context.
Identify name resolution, proxy discovery, fallback lists, domain-generation logic, TLS handling, request construction, serialization, encryption, retry/backoff, and task dispatch.
Simulate the minimum service behavior needed to observe the client safely; never impersonate a real operator or send commands to third-party systems.
Recover configuration deterministically where possible. Record algorithm, key/seed source, structure, checksums, sample scope, and validation.
Classify indicators by role and lifespan: payload delivery, command-and-control, redirector, staging, credential collection, exfiltration, sinkhole, research, or shared service.

Indicator quality: publish normalized value, type, role, first/last observed, source sample, confidence, handling restrictions, expiration/review date, and false-positive context. Never promote a shared cloud/CDN endpoint without tenant-specific evidence.

Family classification, behavior models, YARA, and ATT&CK

Module 13

Turn sample-specific evidence into reusable knowledge without overstating family identity, campaign, actor, or technique.

Cluster on multiple independent features: code lineage, configuration schema, protocol, infrastructure role, certificates, compiler/runtime, libraries, resources, and distinctive behavior.
Distinguish family, variant, builder, packer, loader, payload, tool, and campaign. Preserve vendor naming and explain any alias decision.
Map behavior to Malware Behavior Catalog concepts and ATT&CK techniques only when source/behavior evidence meets the technique definition.
Build YARA from stable, distinctive features; avoid volatile campaign IOCs, common libraries, packer-only bytes, and unconstrained strings.
Test rules against family positives, close variants, benign corpora, packer/compiler controls, and performance limits. Version rules and record corpus hashes.
Create behavior detections separately: telemetry source, event relationship, query, expected evidence, suppressions, validation case, owner, and review date.

Evidence: similarity feature table, naming rationale, technique citations, rule provenance, positive/negative corpus results, runtime/performance, and known blind spots.

Platform path: use AdversaryGraph Malware Analysis for sample findings, then pivot reviewed techniques and indicators into the public ATT&CK workspace or full platform workflows.

AI-assisted analysis, RAG/MCP controls, and defensive handoff

Module 14

Use AI to accelerate mechanical work while keeping samples, evidence, tool execution, and security decisions under deterministic control.

Classify data before sending it to any model. Prefer local/private processing for samples, disassembly, memory, configurations, incident data, unpublished indicators, and embargoed research.
Retrieve only case-relevant, source-attributed context. Treat strings, comments, resources, documents, and sample output as untrusted data—not instructions.
Use typed tasks: explain a bounded function, propose names, summarize cited behavior, compare two traces, suggest YARA candidates, map a demonstrated behavior, or draft a report section.
Require response schemas with evidence references, confidence, assumptions, alternatives, unsupported fields, and validation steps. Reject uncited family/actor/CVE claims.
Keep MCP/tool permissions least-privileged: immutable sample paths, no unrestricted shell, explicit network policy, per-tool time/size limits, audit logs, and approval before dynamic execution or export.
Human-review every accepted field and preserve model/provider/version, prompt template, retrieved sources, tool calls, output, edits, and final disposition.
Hand off separate artifacts to IR, CTI, detection, threat hunting, vulnerability management, legal/privacy, and leadership—each with only the facts and handling level required.

Prompt injection is part of the threat model. Malware authors can place instructions in strings, resources, documents, debug symbols, C2 responses, or web content. Model text must never expand tool authority, network scope, evidence access, or execution permissions.

1200km ecosystem: AIDebug, AdversaryGraph RAG/MCP, and malware-family behavior mapping.

Applied practice

Six evidence-led case studies

Case 1 — PE import triage without capability inflation

Question

Does an unknown PE provide sufficient evidence for persistence, injection, and networking claims?

Method

Verify PE structure and imports.
Group imports by plausible capability.
Trace high-value imports to callers and argument construction.
Check delayed/runtime resolution and dead code.
Confirm with a controlled trace where required.

Result

The report distinguishes imported capability, reachable code, and observed behavior. It avoids claiming injection merely because memory and thread APIs appear in the import table.

Read the PE Import Analyzer guide →

Case 2 — AIDebug function-review pipeline

Question

Can automated function explanation accelerate prioritization without treating generated text as fact?

Method

Preserve binary identity and function address.
Generate bounded disassembly features.
Request typed explanation, ATT&CK candidates, IOC/YARA seeds, and uncertainty.
Review cross-references and behavior manually.
Accept, edit, or reject every field.

Result

The assistant produces leads and structured notes; the analyst retains the evidence link and final claim authority.

Open the AIDebug 3.1 full release review →

Case 3 — Packed sample to validated payload

Question

Can a high-entropy PE be safely unpacked and tied to the runtime payload?

Method

Confirm packing indicators and entry stub.
Observe allocation, transformation, protection, and transfer.
Dump the bounded payload region.
Reconstruct imports where needed.
Compare memory, dump, and execution evidence.

Result

Original and recovered artifacts remain linked by hashes, address ranges, process context, and analyst method. The packer is not reported as the malware family.

Open the Unpacker guide →

Case 4 — Android APK behavior map

Question

Which declared mobile capabilities are reachable and which are actually exercised?

Method

Verify package/signing identity.
Map exported components and permissions.
Trace sensitive APIs to entry components.
Instrument a synthetic-account emulator.
Correlate logs, traffic, files, and code.

Result

The final map separates permission presence, reachable implementation, observed behavior, and untested conditions.

Read the Android malware guide →

Case 5 — Memory-injection investigation

Question

Is an executable private-memory region malicious injection, a legitimate runtime, or an incomplete observation?

Method

Preserve image identity and acquisition context.
Inspect process lineage, handles, threads, and maps.
Correlate allocation/protection transitions.
Extract and classify the region.
Compare known-good behavior for the same application/runtime.

Result

The conclusion is based on provenance, content, execution, and causality rather than an RWX heuristic alone.

Case 6 — MalwareGraph to detection handoff

Question

How should a reviewed sample become a connected investigation record rather than a flat report?

Method

Ingest the sample/report under correct handling.
Review static/dynamic observations.
Link artifact, family hypothesis, indicators, behavior, techniques, sources, and confidence.
Generate candidate YARA/detections.
Validate and hand off by owner.

Result

AdversaryGraph keeps source evidence and analyst decisions connected while clearly separating its workbench role from a dedicated detonation sandbox.

AdversaryGraph vs malware sandboxes →

Hands-on curriculum

Twelve progressive labs

Use benign fixtures, purpose-built training artifacts, or samples distributed for an authorized course. Do not download random live malware to complete these exercises.

Lab 1 — Evidence-safe intake

Receive a password-protected training archive. Build an intake record, hash original/container/children, define handling, record questions, and prove the original remained unchanged.

Lab 2 — Format and metadata truth

Analyze mislabeled benign PE, ELF, script, and document fixtures. Identify actual types, architectures, nesting, signature state, timestamps, resources, and misleading metadata. Use the PE File Structure practical guide to document header chains, RVA mappings, directories, and loader evidence.

Lab 3 — Static triage notebook

Produce strings-with-offsets, import capability clusters, resources, entropy map, classifier output, hypotheses, next actions, and explicit non-claims. Follow Strings Analysis for Malware Analysis to separate observations, working hypotheses, and validation requirements.

Lab 4 — Assembly to behavior

Compile small benign programs and explain the generated control flow, arguments, stack/register state, loops, switch logic, indirect calls, and optimized differences. Follow the Assembly for Malware Analysis practical guide and reproduce its AIDebug exercises.

Lab 5 — Ghidra function map

Import a training binary, validate analysis settings, identify key functions, rename with evidence, recover a configuration structure, and produce an address-cited behavior map.

Lab 6 — Differential dynamic trace

Run a safe simulator from clean snapshots under two environment conditions. Correlate process, file, registry, and network differences and explain trigger behavior.

Lab 7 — Debugger question plan

Design and execute five targeted breakpoints against a training binary to recover runtime configuration and validate API arguments without aimless stepping.

Lab 8 — Unpacking provenance

Use a benign packed fixture. Identify the packer stage, capture the payload at transfer, hash it, validate imports/code, and document the original-to-payload relationship.

Lab 9 — Memory triage and controls

Analyze a provided memory image containing both JIT/private executable memory and a simulated injection. Build evidence that distinguishes them and document acquisition limitations.

Lab 10 — Android behavior validation

Use the 1200km Android analysis lab or a purpose-built fixture. Map manifest components to code and validate selected behaviors on a synthetic emulator profile.

Lab 11 — YARA and behavior detections

Write one family-oriented YARA rule and one telemetry detection. Test positives, close variants, benign controls, common libraries, performance, suppressions, and version metadata.

Lab 12 — Analysis-to-operations capstone

Take one authorized training case from intake through static/dynamic analysis, code review, configuration, classification, ATT&CK/MBC mapping, YARA, hunt query, IR/CTI handoff, executive summary, peer review, and archive.

Tooling

Choose tools by question and evidence type

Question	Representative tools	Evidence to retain	Common failure
What is this artifact?	file/libmagic, hash tools, ExifTool, Detect It Easy, PEStudio/pefile/LIEF, readelf, otool, 7-Zip	Tool/version, command, hashes, parsed structure, raw offsets	Trusting extension, timestamp, or one parser
What capabilities are suggested?	FLOSS, strings, capa, YARA, PE Import Analyzer, String Analyzer	Offsets/addresses, rule versions, confidence, supporting code	Turning presence into execution
How does the code work?	Ghidra, IDA, Binary Ninja, radare2/Cutter, Rizin	Database, addresses, types, annotations, reasoning	Trusting decompiler pseudocode literally
What changed at runtime?	Procmon, Process Explorer, Autoruns, Sysmon, ETW, strace, auditd	Baseline/diff, trace, process tree, timestamps, conditions	Noise without causal correlation
What did it communicate?	Wireshark, tcpdump, FakeNet-NG, INetSim, mitmproxy where authorized	PCAP, simulated-service config, DNS/TLS/HTTP context	Attributing shared infrastructure
What appears only in memory?	Volatility 3, WinDbg, GDB, x64dbg, ProcDump, platform acquisition tools	Image/dump hash, OS/build, process/address context	Calling any executable private memory injection
How is it packed?	DIE, debuggers, Scylla/loader tooling, custom scripts, 1200km Unpacker	Unpack point, ranges, dumps, rebuilt metadata, relationship	Confusing packer and family
What does the APK do?	apktool, jadx, Androguard, MobSF, Frida, objection, adb	Package/cert, manifest paths, code references, runtime logs	Equating permissions with malicious action
How can defenders reuse it?	YARA, capa/MBC, Sigma/backend queries, ATT&CK, AdversaryGraph	Rule provenance, corpus test, technique citation, owner	Brittle IOC-only content
Can AI accelerate review?	AIDebug, local/private LLM, RAG, bounded MCP tools	Model/prompt/sources/tool calls/output/reviewer edits	Leaking samples or accepting hallucinated claims

Reproducibility

Minimum malware-analysis evidence record

Record group	Required fields
Case	Case ID, objective, authority, requester, analyst/reviewer, handling, dates, scope, restrictions, stop condition
Artifact	Artifact ID, parent ID, original name, normalized type, size, hashes, acquisition source/time, storage path, signature/certificate, extraction method
Environment	Snapshot ID, OS/build, architecture, installed tools and versions, clock/locale, privilege, network mode, simulated services, egress policy
Observation	Timestamp, subject, action, object, value, process/address/offset, method/tool, raw evidence reference, condition, reproducibility
Claim	Statement, state (observed/derived/corroborated/inferred/unknown), confidence, supporting evidence IDs, alternatives, limits, reviewer disposition
Indicator	Value/type, normalization, role, source artifact, first/last observed, confidence, handling, expiration/review date, false-positive context
Behavior	MBC/ATT&CK mapping, exact behavior, code/runtime evidence, platform, technique definition citation, confidence, detection opportunity
Output	Rule/query/report version, owner, validation corpus/case, results, limitations, review/expiry, distribution, downstream ticket

{
  "artifact_id": "sample-001:payload-002",
  "sha256": "<64 lowercase hex characters>",
  "relationship": {"parent": "sample-001", "type": "drops"},
  "observation": {
    "state": "observed",
    "subject": "process:training-loader.exe",
    "action": "writes",
    "object": "file:%TEMP%\\training-payload.dll",
    "evidence": ["procmon:event:481", "artifact:payload-002"],
    "condition": "lab_profile=online-simulated"
  },
  "claim": {
    "text": "The training loader writes the payload before launching it.",
    "confidence": "high",
    "limitations": ["Observed only on the recorded Windows lab build."]
  }
}

Detection engineering

A maintainable YARA engineering pattern

This intentionally non-operational example shows rule structure. Replace training markers only with features supported by your authorized analysis and test corpus.

import "pe"

rule Training_Family_Component_Review_Only
{
  meta:
    description = "Illustrative structure; not a production family signature"
    author = "1200km field-guide example"
    date = "2026-07-27"
    status = "review"
    source_artifacts = "documented in private evidence record"

  strings:
    $marker_a = "TRAINING_CONFIG_V1" ascii
    $marker_b = { 54 52 41 49 4E 49 4E 47 } // "TRAINING"

  condition:
    uint16(0) == 0x5A4D and
    pe.is_pe and
    filesize < 5MB and
    all of ($marker_*)
}

Promotion gate

Each feature is tied to an address/offset and analyst explanation.
Features represent the family/component, not a common compiler, library, packer, or campaign IOC.
All known authorized family positives and close variants were tested.
A diverse benign corpus and relevant near-neighbor controls were tested.
Runtime, memory, maximum strings, regex complexity, and scan limits are acceptable.
Rule metadata includes provenance, status, owner, version, review date, and handling.
The rule was peer reviewed and its false-negative boundaries are documented.

Deliverable

Malware-analysis report template

Executive assessment: decision, confidence, business/incident relevance, urgent actions, and major limitations.
Scope and handling: authority, questions, sample restrictions, environment, and methods not performed.
Artifact inventory: parent-child graph, hashes, formats, signatures, sizes, acquisition, and storage/evidence references.
Identity and classification: family/variant/component hypotheses, aliases, supporting features, rejected alternatives, attribution boundary.
Static findings: structure, strings, imports, resources, capabilities, code paths, packing, and confidence.
Dynamic findings: trigger conditions, process tree, filesystem, registry, persistence, network, memory, credentials, and impact.
Configuration and protocol: extraction method, schema, keys/IDs, infrastructure roles, validation, and handling.
Behavior mappings: exact behavior, ATT&CK/MBC ID, evidence, platform, confidence, and citation.
Indicators: normalized values, role, source, first/last observed, confidence, expiration, and false-positive context.
Detections and hunts: YARA, telemetry queries, assumptions, data requirements, validation result, owner, and review date.
IR actions: scoping queries, containment/eradication, persistence removal, credential impact, recovery, and closure evidence.
Appendices: commands, tool/version manifest, raw logs, screenshots, function/address notes, model/tool audit, and evidence index.

Troubleshooting

Failure atlas: symptom → likely cause → corrective action

Symptom	Likely cause	Corrective action
Hash reputation says clean	Unknown sample, new variant, source coverage, wrong child hash	Treat as unknown; verify artifact graph; continue question-driven analysis
Tools disagree on file type	Malformed header, polyglot, overlay, embedded object, parser limitation	Inspect magic/structure manually; compare parsers; cite offsets
Everything looks encrypted	Compression, resources, signed data, media, packer, small sample statistics	Use regional entropy plus format/context and runtime evidence
Huge string list, little value	No offsets/provenance, library noise, decoded/literal mixed	Group by region/function/encoding; trace consumers; label derivation
Decompiler output is impossible	Wrong architecture/base, data as code, packing, bad boundary, indirect flow	Repair analysis settings; validate disassembly and runtime state
Sample exits immediately	Missing argument/config, anti-analysis, locale/time/user check, dead C2	Form hypotheses from code; vary one controlled condition at a time
Sandbox and local run disagree	Different OS/build, trigger, network response, time, privilege, state	Compare complete environment manifests and traces; preserve both
Dumped payload will not parse	Wrong stage/range, relocations/imports absent, memory-only layout	Validate transfer point; capture mapping; reconstruct only as documented
RWX alert marks legitimate app	JIT, unpacking, security product, runtime, browser behavior	Use provenance, thread start, bytes, handles, and known-good control
YARA matches common software	Generic strings/library/packer/compiler feature	Use distinctive feature combinations and benign near-neighbor testing
ATT&CK map contains dozens of techniques	Capability inflation from strings/imports/model output	Require behavior-specific evidence and definition-aligned citations
Family names conflict	Vendor taxonomy, shared builder, packer, component/family confusion	Preserve aliases and feature basis; use neutral cluster until supported
AI invents function purpose	Insufficient bounded context or pattern completion	Require address/cross-reference evidence, alternatives, and human review
MCP tool attempts network access	Overbroad permission or untrusted sample instructions	Block by policy, log attempt, reduce tool authority, regression-test control
IOC causes excessive blocking	Shared service, expired infrastructure, role/context omitted	Add role, tenant/path context, confidence, TTL, review, and behavior correlation

Peer review

Practitioner review questions

Is the exact artifact identified by a strong hash, and is its acquisition/parent relationship preserved?
What question did each tool or execution answer?
What is directly observed, deterministically derived, corroborated, inferred, or still unknown?
Were unknown files ever opened outside the controlled lab or uploaded contrary to handling policy?
Can another analyst reconstruct the environment, commands, triggers, and result?
Are file format, architecture, runtime, signature, and packer claims validated?
Do strings/imports/resources have offsets and a code or runtime context?
Are decompiler types, function boundaries, and names distinguished from original symbols?
What negative control or alternative explanation was tested?
Did the sample contact only simulated or explicitly authorized destinations?
Are dropped, decoded, dumped, and downloaded children hashed and linked to their parent?
Does each malicious-behavior claim have causal process/code/runtime evidence?
Are family, component, packer, builder, variant, campaign, and actor kept distinct?
Do ATT&CK mappings meet the behavior definition rather than merely matching a keyword?
Are indicators assigned roles, confidence, handling, false-positive context, and expiry?
Were YARA rules tested against relevant benign and near-neighbor corpora?
Are behavior detections tied to available telemetry and validated events?
Did AI/RAG/MCP processing respect data handling and treat sample content as untrusted?
Are model-generated facts cited to exact evidence and independently reviewed?
Does the IR handoff state scope and eradication evidence, not just list IOCs?
Does the report make its limitations, untriggered branches, and environmental caveats visible?
Are samples, dumps, credentials, tokens, personal data, and embargoed outputs access-controlled?
Has the analyst recorded which external sources were queried and what was disclosed?
Is there an owner and review/expiry date for every operational output?

Language

Glossary

Artifact: a file, memory region, configuration, packet capture, log, or derived object preserved for analysis.

Behavior: action performed or attempted by code in a stated context.

Capability: what code appears able to do; not necessarily reached or executed.

Configuration: data that controls endpoints, identifiers, features, timing, keys, or execution conditions.

Decompiler: tool that reconstructs higher-level pseudocode from machine code; output is an interpretation, not original source.

Dropper/loader/payload: distinct roles for placing, loading, and performing primary functionality; one artifact can combine roles.

Dynamic analysis: observation of runtime behavior in a controlled environment.

Family: analyst/vendor grouping of related malware based on defined shared features.

IOC: observable value used as an investigation lead; quality depends on role, context, confidence, and time.

Memory injection: cross-process or in-process placement/execution of code; requires more evidence than an executable memory permission.

Packer: transformation that wraps/compresses/encrypts an executable and restores code at runtime.

Provenance: documented origin and transformation history of an artifact or claim.

Static analysis: inspection without executing the artifact.

Unpacking: recovering and validating the representation used after a packing transformation.

YARA: pattern language and engine for identifying/classifying files or memory using strings, metadata, modules, and conditions.

MBC: Malware Behavior Catalog, a behavior vocabulary tailored to malware analysis and related to ATT&CK concepts.

Primary references

Authoritative source shelf

NIST SP 800-83 Rev. 1 — malware prevention and incident-handling guidance; published in 2013 and used here as foundational handling context.
MITRE ATT&CK Software — current software/malware records, associated software names, reported techniques, and source citations.
MITRE ATT&CK — technique definitions and current platform/domain knowledge. Note that ATT&CK data sources were deprecated in v18; use current detection-strategy guidance where applicable.
Malware Behavior Catalog — malware objectives, behaviors, and code characteristics, including anti-static and anti-behavioral-analysis objectives.
YARA 4.5 documentation — rule language, modules, Python/C APIs, undefined values, and scanning behavior.
Mandiant capa — capability identification for PE, ELF, .NET, shellcode, and supported sandbox reports with ATT&CK/MBC-oriented rules.
Mandiant FLARE-VM — reproducible Windows reverse-engineering tool environment; the project explicitly requires installation in a VM and recommends host-only networking and snapshots.
FLARE Learning Hub — official training material and controlled exercise artifacts for reverse engineering and malware analysis.
REMnux documentation — Linux malware-analysis toolkit, curated tools, containers, and current AI-assistant guidance.
Ghidra Debugger courseware — debugger UI, breakpoints, machine state, navigation, memory maps, emulation, and scripting.
Microsoft Process Monitor — real-time file, Registry, process/thread activity, filtering, stacks, and process-tree evidence.
Microsoft Sysmon — process, network, file, Registry, driver/module, and related telemetry; it records events but does not analyze them.
Volatility 3 documentation — current memory-analysis framework concepts, CLI, symbols, layers, and plugins.

Release gate

Final analysis and handoff checklist

Authority, purpose, handling restrictions, retention, sharing, and stop conditions are recorded.
The original artifact is retained read-only; working copies and all derived children are strongly hashed.
Lab snapshots, tool versions, OS/build, network policy, time/locale, user/privilege, and trigger conditions are documented.
No sample or restricted data was submitted to an external service without explicit policy authority.
Every material statement is labeled observed, derived, corroborated, inferred, or unknown.
Strings, imports, resources, code, and behavior are not conflated.
Parent/child, dropper/loader/payload, configuration, and memory-artifact relationships are preserved.
Static and dynamic claims cite offsets, addresses, events, packets, artifacts, or other reviewable evidence.
Family, variant, component, packer, campaign, infrastructure, and actor claims are separated and confidence-scored.
Indicators include role, context, source artifact, confidence, first/last observed, handling, expiry, and false-positive notes.
ATT&CK and MBC mappings meet their definitions and cite the exact demonstrated behavior.
YARA and behavior detections passed positive, near-neighbor, benign, performance, and peer-review checks.
AI/RAG/MCP output retains model, prompt, retrieval, tool-call, response, reviewer-edit, and disposition history.
Untrusted sample content could not expand tool authority or bypass network/filesystem policy.
IR receives scoping, containment, eradication, recovery, and closure evidence—not only a list of IOCs.
CTI receives sourced relationships and attribution limits; detection receives telemetry requirements and validation evidence.
The report states untriggered branches, unavailable data, environmental caveats, and remaining uncertainty.
Samples, dumps, packet captures, credentials, personal data, and embargoed material are access-controlled.
Operational outputs have owners, versions, review/expiry dates, and downstream records.
A second analyst can reproduce the material findings from the preserved evidence package.

Connected original research

AI in Cyberattacks: statistical CTI study

Compare reported AI-assisted malware development, tooling, evasion, and code-generation coverage across the indexed publications.

Read the study Explore the dashboard Search 108 indexed references