Malware Types and Analysis Reference

Malware — malicious software engineered to infiltrate, damage, or exploit computing systems without authorized consent — represents one of the most operationally consequential threat categories in enterprise and government cybersecurity. This reference covers the principal malware classifications, their technical mechanics, the analytical frameworks applied by security professionals, and the regulatory obligations triggered when malware causes a breach. Practitioners in security operations, digital forensics, and incident response rely on this taxonomy to communicate precisely about threats and apply proportionate controls.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps (non-advisory)
• Reference table or matrix

Definition and scope

The National Institute of Standards and Technology (NIST) defines malware in NIST SP 800-83 Rev. 1 as "software or firmware intended to perform an unauthorized process that will have adverse impact on the confidentiality, integrity, or availability of an information system." That definition encompasses a broad operational spectrum — from self-replicating worms that traverse network segments autonomously to dormant trojans that execute only upon specific environmental triggers.

The scope of malware as a security discipline extends beyond the code artifact itself. Malware analysis is a professional practice that integrates reverse engineering, behavioral observation, network traffic inspection, and threat intelligence correlation. CISA and the FBI Cyber Division jointly issue malware analysis reports (MARs) on high-priority threats, establishing a federal reference standard for classification and response.

From a regulatory standpoint, malware-enabled incidents trigger notification obligations under the Health Insurance Portability and Accountability Act (HIPAA) Security Rule (45 CFR §164.306) when protected health information is affected, and under the Gramm-Leach-Bliley Act (GLBA) Safeguards Rule for financial institutions. The Cybersecurity and Infrastructure Security Agency Act of 2018 (6 U.S.C. §651 et seq.) further establishes CISA's authority to coordinate federal response to significant malware campaigns affecting critical infrastructure sectors.

Core mechanics or structure

Malware operates through a lifecycle that security researchers typically divide into 5 functional phases: delivery, installation, persistence, execution, and exfiltration or payload detonation. Each phase presents distinct technical signatures that analysis tools and detection logic target.

Delivery mechanisms include email attachments, drive-by downloads exploiting browser vulnerabilities, malicious macros embedded in Office documents, and compromised software supply chains. The MITRE ATT&CK framework — maintained by The MITRE Corporation — catalogs delivery under Initial Access (Tactic TA0001), with 9 distinct techniques documented as of the framework's enterprise matrix.

Installation and persistence mechanisms commonly involve registry key modification on Windows systems (Run and RunOnce keys), scheduled task creation, DLL hijacking, and bootkit implantation in the Master Boot Record. Bootkits operating below the OS layer resist standard remediation because they execute before security software initializes.

Code obfuscation is a structural feature of most sophisticated malware. Packers compress or encrypt the executable payload; polymorphic engines mutate code signatures on each execution; metamorphic engines rewrite entire code blocks while preserving functional behavior. These techniques are specifically designed to evade signature-based detection, which is why behavioral analysis and sandbox execution have become primary analysis methods.

Command-and-control (C2) infrastructure enables the operator to issue instructions, receive stolen data, and update the malware remotely. C2 channels increasingly use legitimate services — encrypted HTTPS traffic to cloud providers, DNS tunneling, and social media APIs — to blend with normal traffic and evade network-layer detection. The NIST National Cybersecurity Center of Excellence (NCCoE) has published practice guides specifically addressing C2 detection in enterprise environments.

Causal relationships or drivers

Malware proliferation is driven by a convergence of economic incentives, technical accessibility, and organizational vulnerability patterns. The ransomware-as-a-service (RaaS) model, documented extensively in CISA advisories, has lowered the technical barrier to deploying ransomware by separating the developer role from the affiliate (operator) role — affiliates require no coding expertise to launch campaigns.

Unpatched software vulnerabilities constitute the primary technical enabler. The CISA Known Exploited Vulnerabilities (KEV) Catalog lists vulnerabilities that have been actively exploited in the wild; as of public reporting, the catalog has exceeded 1,000 entries, reflecting the scale of unmitigated attack surface across federal and private-sector systems.

Credential compromise represents a second major driver. Malware frequently arrives as a secondary payload after an initial credential theft or phishing event. Phishing and social engineering campaigns harvest credentials that grant malware delivery mechanisms authenticated access to internal systems, bypassing perimeter controls.

The vulnerability management lifecycle directly influences malware exposure: organizations with mean-time-to-patch (MTTP) exceeding 30 days for critical vulnerabilities remain exposed during windows that threat actors actively exploit. NIST SP 800-40 Rev. 4 ("Guide to Enterprise Patch Management Planning") establishes patch management as a foundational control precisely because delayed patching correlates directly with successful malware installation.

Classification boundaries

Malware classification is not uniformly standardized across the industry. The following boundaries reflect the taxonomy used by NIST, CISA, and the MITRE ATT&CK framework:

Virus — requires a host file to attach to and propagate; activates when the infected host is executed. Distinguished from worms by the dependency on host file execution.

Worm — self-replicating, propagates autonomously across networks without requiring a host file. Exploits network services, open shares, or vulnerabilities directly.

Trojan — disguises malicious functionality within apparently legitimate software. Does not self-replicate; relies on user execution.

Ransomware — a subclass of malware that encrypts victim data or locks system access, then demands payment for restoration. Covered in depth in the ransomware reference. CISA and FBI classify ransomware under both extortion and destructive malware categories depending on whether data recovery is operationally feasible.

Spyware and adware — monitor user activity, collect credentials or financial data, or redirect browser traffic. The FTC has pursued enforcement actions under Section 5 of the FTC Act against spyware distributors.

Rootkit — modifies OS components to conceal the presence of malware. Kernel-mode rootkits operate with ring-0 privilege, making detection and removal technically demanding.

Botnet agent (bot) — enrolls the infected host in a distributed network controlled via C2. Bots are used for DDoS campaigns, spam relay, credential stuffing, and cryptocurrency mining.

Fileless malware — executes entirely in memory using legitimate OS utilities (e.g., PowerShell, WMI) without writing a persistent file to disk. This classification boundary is frequently contested because some fileless malware does write minimal registry-based components.

Keylogger — captures keystrokes to harvest credentials, financial data, or communications. May be implemented in hardware or software.

Tradeoffs and tensions

The tension between detection capability and operational performance defines the central engineering challenge in malware defense. Behavioral analysis engines that observe process behavior in real time impose CPU and memory overhead; in latency-sensitive operational technology (OT) environments, this overhead is operationally unacceptable. The OT/ICS security discipline addresses this tradeoff explicitly, often defaulting to application whitelisting rather than behavioral monitoring because OT process sets are stable and bounded.

A second tension exists between malware analysis fidelity and analyst safety. Dynamic analysis in a sandbox environment — executing malware to observe behavior — risks sandbox evasion. Sophisticated malware detects virtualized environments by checking for artifacts such as VMware registry keys, specific MAC address prefixes, or abnormal timing responses, and then enters a dormant state. Static analysis (examining code without execution) avoids this risk but cannot observe runtime-only behaviors such as packed payload extraction.

Attribution is a persistent tension in malware analysis. Code similarity, C2 infrastructure overlap, and TTP (tactics, techniques, and procedures) alignment can suggest threat actor attribution, but malware authors deliberately reuse code from public repositories and employ false flag techniques to mislead analysts. CISA and NSA joint advisories note attribution as probabilistic rather than definitive absent corroborating intelligence.

Automated malware analysis platforms increase throughput — commercial sandboxes can process thousands of samples per day — but introduce false-negative risk when novel evasion techniques outpace sandbox detection logic. The tradeoff between analyst-driven deep analysis (low throughput, high fidelity) and automated triage (high throughput, variable fidelity) structures how security operations centers prioritize sample queues.

Common misconceptions

Misconception: Antivirus software provides comprehensive malware protection.
Signature-based antivirus detects known malware variants by matching file hashes or byte sequences against a database. Polymorphic and metamorphic malware modify their signatures on each execution, rendering signature matching ineffective for novel samples. NIST SP 800-83 Rev. 1 explicitly classifies antivirus as one layer within a defense-in-depth architecture, not a standalone control.

Misconception: Macs and Linux systems are immune to malware.
Both macOS and Linux platforms have documented malware families. XLoader, a cross-platform information stealer, targets both Windows and macOS. The CISA KEV catalog includes vulnerabilities in macOS and Linux that have been actively exploited. Platform diversity reduces risk profile in some contexts but does not eliminate it.

Misconception: Ransomware is the only financially motivated malware.
Banking trojans (e.g., the Dridex family, documented in FBI and CISA joint advisories), info-stealers, and credential-harvesting malware generate direct financial returns through account takeover and fraud. Ransomware receives disproportionate attention because of its visible operational disruption, but the broader category of financially motivated malware operates at significant scale with less visibility.

Misconception: Malware always originates from external attackers.
Insider threat programs document cases where authorized users deploy malware as sabotage or to facilitate data exfiltration. The CERT Insider Threat Center at Carnegie Mellon University has published case studies where disgruntled employees introduced malicious code or tools into production environments.

Misconception: Wiping and reimaging a system always eliminates malware.
Firmware-level implants — such as those targeting UEFI/BIOS — survive OS reinstallation because they reside in non-volatile firmware storage outside the operating system's file system. The NSA's Cybersecurity Directorate has published guidance on firmware integrity verification as a remediation step for advanced persistent threat (APT) intrusions.

Checklist or steps (non-advisory)

The following sequence reflects the standard phases of malware incident analysis as documented in NIST SP 800-61 Rev. 2 ("Computer Security Incident Handling Guide") and CISA's incident response guidance:

Phase 1 — Detection and initial triage
- [ ] Confirm malware indicator (alert, behavioral anomaly, hash match against threat intelligence feed)
- [ ] Identify affected hosts, user accounts, and network segments
- [ ] Preserve volatile evidence: running processes, network connections, memory state (per NIST SP 800-86)
- [ ] Assign incident severity classification using organizational risk criteria

Phase 2 — Static analysis
- [ ] Compute cryptographic hash (MD5, SHA-256) of malware sample; query against VirusTotal or CISA-maintained threat feeds
- [ ] Examine PE header, import table, and strings in an isolated analysis environment
- [ ] Identify packers or obfuscation using entropy analysis tools
- [ ] Extract embedded URLs, IP addresses, registry keys, and file paths from strings

Phase 3 — Dynamic analysis
- [ ] Execute sample in an isolated, instrumented sandbox environment
- [ ] Capture process creation events, file system modifications, registry changes, and network connections
- [ ] Document C2 callback domains and IP addresses
- [ ] Assess sandbox evasion techniques present in the sample

Phase 4 — Containment
- [ ] Isolate affected endpoints from the network at the switch or firewall level
- [ ] Block identified C2 domains and IP addresses at DNS resolver and perimeter firewall
- [ ] Disable compromised credentials (reference identity and access management controls)
- [ ] Preserve forensic images before remediation proceeds

Phase 5 — Eradication and recovery
- [ ] Determine malware persistence mechanisms and remove all artifacts
- [ ] Validate firmware integrity if UEFI/BIOS-level compromise is suspected
- [ ] Restore from verified clean backups or rebuild affected systems
- [ ] Verify removal through re-scan and behavioral monitoring post-recovery

Phase 6 — Post-incident analysis
- [ ] Document indicators of compromise (IOCs) and share with CISA via the automated indicator sharing (AIS) program if applicable
- [ ] Identify the initial access vector and apply corresponding vulnerability management controls
- [ ] Update detection logic (SIEM rules, EDR signatures) based on observed TTPs
- [ ] Complete required breach notification within statutory deadlines if covered data was affected

Reference table or matrix

MITRE ATT&CK tactic coverage by malware type

Tactic codes reference the MITRE ATT&CK Enterprise Matrix maintained by The MITRE Corporation.

References

• NIST SP 800-83 Rev. 1 — Guide to Malware Incident Prevention and Handling
• [NIST SP 800-61 Rev. 2 — Computer Security Incident Handling Guide](https://csrc.nist.gov/publications/detail/sp/