Before
- Pick one malware label
- Assume the label explains intent
- Search for one product to block it
Module 2 of 17
Malware Concepts and Multi-Axis Taxonomy
Describe observed behavior precisely instead of forcing every incident into one malware label.
Start here
Learning objectives
- Explain the difference between delivery, execution mechanism, behavior, operator objective, and impact.
- Classify a synthetic scenario across several axes without treating a family label as proof.
- Use ATT&CK to describe observed adversary behavior and D3FEND to discuss defensive countermeasures.
- Apply a consistent defensive playbook to viruses, worms, trojans, ransomware, spyware, backdoors, fileless threats, and supply-chain threats.
After
- Separate six classification axes
- Cite evidence and uncertainty
- Layer testable controls around behavior and impact
Labels Are Shortcuts, Not Conclusions
Terms such as trojan, worm, ransomware, spyware, backdoor, rootkit, and cryptominer are useful, but they describe different dimensions. A trojan describes deceptive delivery. A worm describes self-propagation. Ransomware describes an impact or business objective. A backdoor describes retained unauthorised access. One incident can fit several labels at once.
Good analysis starts with observable facts: which process existed, which parent started it, what file or configuration changed, what account was involved, what destination was contacted, and what impact followed. The label comes later and should never be more confident than the evidence. “The supplied log shows repeated creation of encrypted test copies” is stronger than “this is ransomware” when the fixture contains no proof about operator intent.
Use a Multi-Axis Taxonomy
Classify each scenario across separate axes. This prevents one memorable behavior from hiding the rest of the attack surface.
| Axis | Question | Examples of defensive observations |
|---|---|---|
| Delivery | How did it reach the environment? | Package dependency, document, removable media, exposed service, compromised update |
| Execution | What caused code or instructions to run? | User action, service launch, script host, application plugin, scheduled workload |
| Behavior | What did the system observe? | File change, process creation, configuration change, discovery query, unusual network request |
| Objective | What outcome does the evidence support? | Access, collection, disruption, extortion, resource theft, espionage |
| Impact | What changed for the organisation? | Availability loss, data exposure, integrity loss, cost, recovery work |
| Environment | Where did the behavior occur? | Endpoint, server, browser, package registry, CI runner, container, cloud control plane |
Mark each statement as observed, inferred, reported by another source, or unknown. That distinction makes a taxonomy useful during an incident rather than decorative after it.
Map Behavior Without Overclaiming
MITRE ATT&CK provides a shared language for adversary tactics and techniques. Use it to organise evidence, coverage, and gaps. A mapping is not proof of a particular actor or malware family. It is a hypothesis that should cite the event, timestamp, source, and reasoning that support it.
MITRE D3FEND complements behavior mapping with defensive techniques. The useful question is not “Which product stops this malware?” but “Which observable behavior can we prevent, detect, contain, or make less valuable?” Multiple controls should cover identity, execution, data, network, and recovery because one label rarely maps to one control.
Version the frameworks in the report. Technique names, identifiers, data sources, and guidance evolve. A production detection or course lesson should record when its mapping was reviewed.
Apply the Defensive Playbook
Every type deep dive in this course follows the same playbook: definition and overlaps, common delivery paths, observable behaviors, static evidence, endpoint and network evidence, ATT&CK mapping, detection opportunities, developer prevention, containment and recovery, then a sanitized case study. Reusing the structure makes comparison easier and keeps the lesson focused on defense.
The playbooks cover file infectors, worms, trojans and loaders, ransomware and wipers, spyware and stealers, backdoors and botnets, fileless and living-off-the-land activity, rootkits and boot threats, web shells, package and CI/CD compromises, resource hijacking, browser threats, and cloud or container incidents. They explain behavior at a conceptual level; they do not teach implementation, stealth, persistence, propagation, credential access, command and control, or destructive payloads.
Turn Taxonomy Into Developer Action
Developers can reduce whole classes of opportunity without identifying a family. Verify dependencies and updates, minimize plugin authority, run converters and build jobs with least privilege, separate secrets from build inputs, restrict outbound traffic, sign release artifacts, and emit useful process and configuration telemetry.
Describe the control at the same precision as the observation. “Block malware” is not testable. “The document conversion worker cannot reach the internet, cannot read deployment secrets, and is replaced after each job” can be tested in CI and reviewed during an incident.
Suggested Study Plan (6 hours)
The published duration includes active practice, not video playback alone. Complete each block with the course-owned evidence and retain the stated deliverable so another reviewer can reproduce your reasoning.
| Study block | Time | Required evidence |
|---|---|---|
| Guided lesson and primary-source review | 1h 21m | Annotated notes that separate observations, hypotheses, limits, and version-sensitive facts. |
| Worked evidence walkthroughs | 1h 8m | Reproduce the lesson's tables or decision flow and challenge at least two assumptions. |
| Independent practice rounds | 1h 8m | Apply the method to two alternate records in the sanitized evidence pack and compare the conclusions. |
| Required lab | 1h 30m | A six-axis classification table, evidence-linked ATT&CK mapping, D3FEND-informed control plan, confidence labels, and two plausible alternative explanations. |
| Knowledge check and review | 53 minutes | Answer the evidence check, review the rubric, and record one production follow-up. |
Evidence Check
Question: A synthetic case describes a dependency that entered through a package update, created an unexpected child process, and caused service downtime. Which single malware type is the correct answer?
Reveal the defensive reasoning
There is not enough evidence for one exclusive type. Record separate facts: package update as delivery, unexpected child-process creation as observed behavior, and availability loss as impact. State any family label as a bounded hypothesis and map only the ATT&CK behaviors the evidence supports.
Primary References
Use these primary sources for the current standard or tool behavior. The course records framework versions so mappings can be reviewed when upstream guidance changes.
Real world
Where this shows up
- Triaging an unexpected dependency update without prematurely naming a campaign.
- Explaining an incident consistently to engineering, security operations, and leadership.
- Building detection coverage around behavior shared by many malware families.
Production notes
Keep these close
- Store framework version, technique ID, evidence reference, confidence, owner, and review date with every mapping.
- Keep business impact distinct from technical behavior so recovery priorities are clear.
- Use playbooks as review prompts, not as automated proof of attribution.
- Measure control coverage across behavior and asset classes rather than counting family names.
Common mistakes
What usually breaks
- Treating trojan, worm, ransomware, and backdoor as mutually exclusive categories.
- Mapping every suspicious event to ATT&CK without citing the evidence.
- Assuming a technique identifies a specific actor or tool.
- Choosing a product control before stating the observable behavior and desired outcome.
Security risks
Threats to watch
- Premature attribution can misdirect containment and communication.
- A family-focused rule can miss behavior shared by new or renamed tools.
- Unversioned mappings silently become stale as frameworks evolve.
- Overbroad classifications can produce noisy controls and alert fatigue.
Tradeoffs
Design choices you should be able to defend
Family-first classification
Pros
- Fast shorthand when identity is well established
- Can connect to existing intelligence reports
Cons
- Encourages tunnel vision
- Can outpace the evidence
- A family may change behavior across incidents
Behavior-first multi-axis classification
Pros
- Maps directly to evidence and controls
- Works when attribution is unknown
- Makes uncertainty explicit
Cons
- Takes more disciplined documentation
- Does not provide a single memorable label
Think like an engineer
Questions to answer before shipping
- Which statement in the incident record is observed, and which is inferred?
- Would the proposed control still help if the family label were wrong?
- Which missing evidence would most change containment priority?
- How could the application make this behavior easier to observe safely?
Key terms
Vocabulary used in this module
Delivery
The path by which an unwanted artifact or instruction reaches an environment.
Behavior
An observable system action such as a process, file, identity, configuration, or network event.
Impact
The effect on confidentiality, integrity, availability, cost, safety, or recovery work.
ATT&CK technique
A documented pattern of adversary behavior used to organise evidence and defensive coverage.
D3FEND countermeasure
A defensive technique described in MITRE D3FEND and connected to relevant offensive behavior.
Exercises
Practice inside the lesson
Classify a Synthetic Incident Across Six Axes
Produce an evidence-backed classification and defensive plan without attributing a family or actor beyond the supplied facts.
- Read the instructor-authored scenario cards and list only directly observed facts.
- Classify delivery, execution, behavior, objective, impact, and environment independently; mark unknown values as unknown.
- Select up to three ATT&CK techniques supported by specific supplied events and record the framework version.
- Choose prevention, detection, containment, and recovery controls; connect each control to one observation or plausible risk.
- Write two alternative explanations and identify the additional authorised evidence needed to distinguish them.
- Peer-review the result for unsupported family names, actor attribution, or claims of intent.
Expected evidence
A six-axis classification table, evidence-linked ATT&CK mapping, D3FEND-informed control plan, confidence labels, and two plausible alternative explanations.
Assessment criteria
- Observed facts are separated from inference and unknowns.
- Every behavior mapping cites a specific event from the scenario.
- No malware family, actor, or intent is asserted without evidence.
- Controls are concrete, testable, and connected to the described behavior or impact.
Course-owned resources
Teardown
- Delete temporary working copies.
- Retain only the written defensive analysis.
Recap
Key takeaways
- Malware labels describe overlapping dimensions and are not mutually exclusive.
- Classify delivery, execution, behavior, objective, impact, and environment separately.
- ATT&CK organises behavior; it does not prove family or actor attribution.
- A repeatable defensive playbook is more useful than a long list of names.
- Testable controls should follow evidence, even when attribution remains unknown.
Related resources