---
{
  "title": "Malware",
  "summary": "Software used to perform unwanted or harmful activity.",
  "topic": "foundations",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    3
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: An Introduction to Information Security",
      "url": "https://csrc.nist.gov/pubs/sp/800/12/r1/final"
    },
    {
      "title": "NIST SP 800-83 Rev. 1: Malware Incident Prevention and Handling",
      "url": "https://csrc.nist.gov/pubs/sp/800/83/r1/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

Malware is software designed or deployed for malicious purposes. Categories include viruses, worms, trojans, spyware, and ransomware, but behaviors often overlap. The useful investigative question is what a program did, how it arrived, and what access it obtained. A name assigned by one security tool is a lead rather than a complete explanation. Analysis should use controlled environments and preserve the original evidence.

## In practice

A document launches an unexpected process, which connects to an unfamiliar destination and creates a startup entry. The behaviors matter more than a single product label.

## A common misunderstanding

An absent antivirus alert does not prove a system is clean, and an alert alone does not establish the full incident scope.

## Check your understanding

What evidence helps assess a malware alert?

**Think it through:** Process activity, file origin, persistence, network connections, and relevant identity or endpoint logs.


## Behavior explains the consequence better than a label

Malware categories describe common functions, but a single program can combine several behaviors. It may steal information, establish remote access, disrupt services, or deliver another component. Different tools may assign different names to related material. Investigators should prioritize what the program did, where it ran, and what authority it obtained.

A suspicious file is not automatically executed malware, and a detection alert can require validation. Correlate file identity, source, process events, persistence, network activity, and application impact. Signature matches, reputation, and behavioral alerts are useful inputs rather than complete substitutes for context.

## A fictional unfamiliar executable

An academy's endpoint tool flags a file downloaded during a support session. Analysts preserve its identity and relevant events, check whether it executed, and compare it with the approved support package. If it ran, they assess child processes, account context, changes, and communication. If it was blocked before execution, the impact statement should reflect that narrower outcome.

Do not run the file on a personal computer or upload sensitive samples to an uncontrolled public service. Use approved analysis and evidence-handling procedures. A clean result from one short test does not establish safety in every environment, while one ambiguous label should not create an unsupported claim about an entire campaign.

## Build a behavior summary

Using a prepared training event set, write a short account of arrival, execution, changes, and communication. Mark which stages are observed and which remain unknown. Then identify the containment and recovery questions the evidence raises. No live malicious sample is needed.

Recovery may require rebuilding an affected environment, revoking access, or correcting the original weakness, depending on the facts. Deleting one detected file can leave other components or compromised credentials behind. Verify the intended state and normal business function before declaring the incident resolved.

## Keep exploring

- [[ransomware]]
- [[endpoint-detection-response]]
- [[persistence]]
- [[memory-forensics]]