Malware Types and Analysis Reference

Malware — malicious software designed to infiltrate, damage, or extract value from computing systems — represents one of the most operationally consequential threat categories in cybersecurity practice. This page maps the major malware classifications, their technical mechanics, the analytical frameworks applied by security professionals, and the regulatory context that governs organizational response obligations. The coverage is structured for incident responders, threat intelligence analysts, compliance officers, and researchers navigating the malware analysis service sector rather than introductory audiences.


Definition and scope

The Cybersecurity and Infrastructure Security Agency (CISA) defines malware as software intentionally designed to cause disruption, damage, or unauthorized access to computer systems, networks, or data. NIST's Computer Security Resource Center (CSRC) formalizes this under NIST SP 800-83, Rev. 1 as "a program that is inserted into a system, usually covertly, with the intent of compromising the confidentiality, integrity, or availability of the victim's data, applications, or operating system."

The operational scope of malware analysis encompasses three distinct professional disciplines: static analysis (examining code without execution), dynamic analysis (observing behavior in controlled environments), and hybrid analysis (combining both methods). These disciplines are supported by specialized toolsets, sandbox environments, and reverse engineering platforms. The infosec-providers section of this provider network catalogs firms and practitioners operating across these disciplines.

Regulatory scope is broad. Organizations subject to the Health Insurance Portability and Accountability Act (HIPAA Security Rule, 45 CFR § 164.306) must implement technical safeguards against malicious software. The Federal Financial Institutions Examination Council (FFIEC) IT Examination Handbook mandates malware controls for regulated financial institutions. The NIST Cybersecurity Framework (CSF) 2.0, published in February 2024, addresses malware within its "Detect" and "Respond" function categories. Across these frameworks, malware detection and analysis are treated as core operational obligations rather than optional hardening measures.


Core mechanics or structure

Malware operates through a predictable lifecycle regardless of specific type. MITRE ATT&CK — the publicly maintained adversarial tactics, techniques, and procedures (TTP) knowledge base — structures malware behavior across 14 tactic categories, from Initial Access through Impact. This framework is the dominant reference standard used by SOC analysts, threat hunters, and incident responders to classify observed malware behavior.

Delivery mechanisms include phishing email attachments, drive-by downloads exploiting unpatched browser vulnerabilities, supply chain compromise (as documented in the 2020 SolarWinds incident analyzed by CISA Alert AA20-352A), and malvertising through compromised ad networks. Once delivered, malware typically executes through one of three pathways: direct execution by the user, exploitation of a software vulnerability (using a CVE-classified flaw catalogued in the NIST National Vulnerability Database), or fileless execution that resides entirely in system memory.

Persistence mechanisms documented in MITRE ATT&CK Sub-technique T1547 include modification of system registry run keys, scheduled task creation, and bootkit installation at the firmware level. Command-and-control (C2) infrastructure enables operators to issue commands to compromised hosts through protocols including HTTP/S, DNS tunneling, and encrypted peer-to-peer channels — a behavior set classified under MITRE ATT&CK Tactic TA0011.

The internal structure of a malware binary typically includes a dropper or loader component, the primary payload, and obfuscation layers designed to defeat signature-based detection. Packers and crypters modify the binary's on-disk representation while preserving runtime functionality, which is why static analysis alone is insufficient for most modern samples.


Causal relationships or drivers

Malware proliferation is driven by four intersecting factors: financial incentive structures, commoditization of development infrastructure, the persistent attack surface created by unpatched systems, and geopolitical motivations.

The financial ecosystem sustaining ransomware — the most economically significant malware category as of reporting through 2023 — involves affiliate programs where ransomware-as-a-service (RaaS) operators license toolkits to affiliates who conduct intrusions and split ransom proceeds, typically on an 80/20 split documented in FBI Private Industry Notification PIN-20211102-001. The FBI's Internet Crime Complaint Center (IC3) reported ransomware losses exceeding $59.6 million in adjusted losses for 2023, though this figure reflects only IC3-reported incidents and substantially understates true sector losses.

Commoditization of malware development infrastructure — including darknet markets for exploit kits, access-as-a-service brokers selling pre-established network footholds, and open-source offensive security tools repurposed for criminal use — has lowered the technical barrier for threat actors substantially. The MITRE ATT&CK Group catalog documents over 130 named threat actor groups using this commoditized infrastructure.

Unpatched software remains the dominant technical enabler. The CISA Known Exploited Vulnerabilities (KEV) Catalog, which lists CVEs actively exploited in the wild, contained over 1,100 entries as of 2024, with exploitation timelines shrinking from months to days between public disclosure and weaponized deployment.


Classification boundaries

Malware classification is not universally standardized. NIST SP 800-83 Rev. 1 and the SANS Institute both offer type taxonomies, but edge cases — such as dual-use tools or legitimate software modified for malicious purposes — create genuine boundary disputes in both academic and forensic contexts.

The following primary classifications represent consensus across NIST, CISA, and MITRE ATT&CK documentation:

Boundary tensions arise around dual-use tools: penetration testing frameworks such as Cobalt Strike, when deployed without authorization, meet the operational definition of malware under CISA guidance, but the binary itself is a commercial product. The page addresses how this provider network handles such classification edge cases.


Tradeoffs and tensions

Detection fidelity vs. performance overhead is the central operational tension in malware analysis. Behavioral detection engines that monitor process calls, memory writes, and network connections in real time impose measurable system overhead — endpoint detection and response (EDR) platforms can consume between 1% and 5% of CPU resources depending on configuration depth (vendor benchmarks vary; independent testing is conducted by organizations including AV-Comparatives, a third-party testing body).

Sandboxing vs. evasion presents an analytical arms race. Malware samples increasingly incorporate sandbox detection routines — checking for virtual machine artifacts, user interaction absence, or low processor core counts — that trigger dormancy when analysis environments are detected. This is documented in MITRE ATT&CK Sub-technique T1497.001 (Virtualization/Sandbox Evasion). Analysts counter with bare-metal analysis environments, which require substantially greater infrastructure investment.

Signature-based vs. behavioral detection reflects a fundamental architectural tradeoff: signature databases provide fast, low-false-positive detection for known malware families but fail entirely against zero-day samples and polymorphic variants. Behavioral detection catches novel samples but produces higher false-positive rates that require analyst triage. The how-to-use-this-infosec-resource page provides orientation for practitioners selecting between service providers specializing in each approach.

Attribution vs. operational security creates tension in incident response: pursuing technical attribution of a malware campaign to a specific threat actor group (using TTPs, C2 infrastructure, and code reuse analysis) consumes forensic resources that might otherwise accelerate containment. CISA's advisory framework recommends documenting indicators of compromise (IOCs) for threat sharing but does not mandate attribution as a response requirement.


Common misconceptions

Misconception: Antivirus software provides comprehensive malware protection.
Correction: Traditional antivirus relies primarily on signature matching. The 2022 Verizon Data Breach Investigations Report (DBIR) documented that fileless malware and living-off-the-land techniques — which use legitimate system tools for malicious activity — are not reliably detected by signature-based engines. EDR platforms and behavioral analysis are required for coverage against these vectors.

Misconception: Ransomware is the only financially motivated malware.
Correction: Credential-stealing trojans and banking malware (e.g., the Emotet botnet family) generate sustained revenue through account takeover and fraud, often exceeding single-event ransomware payouts. Emotet alone was assessed by Europol as having caused hundreds of millions of euros in damages before its 2021 takedown.

Misconception: Malware removal restores system integrity.
Correction: Post-infection system integrity cannot be assumed after malware removal alone. Rootkits operating at kernel or firmware level may survive standard remediation procedures. NIST SP 800-83 Rev. 1 explicitly recommends full system reimaging for high-severity infections rather than in-place remediation.

Misconception: Air-gapped systems cannot be infected.
Correction: The Stuxnet worm (analyzed by CISA and multiple national CERTs) demonstrated air-gap traversal via infected USB media in 2010. Subsequent research has documented acoustic, electromagnetic, and optical covert channels for air-gap exfiltration, published by academic researchers at Ben-Gurion University of the Negev.

Misconception: Open-source malware samples are safe to handle.
Correction: Malware samples obtained from repositories such as VirusTotal or MalwareBazaar (operated by abuse.ch) retain full execution capability. Mishandling outside isolated analysis environments constitutes a direct operational risk and may trigger legal liability under 18 U.S.C. § 1030 (Computer Fraud and Abuse Act) if unintended propagation occurs.


Checklist or steps (non-advisory)

The following sequence reflects the standard malware analysis workflow documented in NIST SP 800-83 Rev. 1 and operationalized in industry practice. This is a reference description of the process structure, not procedural guidance.

Phase 1 — Triage
- [ ] Confirm sample acquisition chain of custody is documented
- [ ] Compute and record cryptographic hash values (MD5, SHA-1, SHA-256)
- [ ] Query hash against NIST National Software Reference Library (NSRL) and VirusTotal
- [ ] Classify initial threat severity using CVSS or organizational risk matrix
- [ ] Determine whether live incident or post-incident analysis context applies

Phase 2 — Static Analysis
- [ ] Extract strings, imports, exports, and section headers using tools such as PEiD, CFF Explorer, or Detect-It-Easy
- [ ] Identify packer or obfuscation indicators
- [ ] Map imported API calls to MITRE ATT&CK technique identifiers
- [ ] Examine embedded resources, certificates, and compilation timestamps
- [ ] Cross-reference code signatures against YARA rule sets (including open-source rule sets maintained by Florian Roth)

Phase 3 — Dynamic Analysis
- [ ] Deploy sample in isolated sandbox environment (network-isolated VM or bare-metal system)
- [ ] Monitor process creation, file system changes, registry modifications, and network connections
- [ ] Document C2 callback attempts, DNS queries, and HTTP/S request patterns
- [ ] Capture memory dump for in-memory artifact analysis
- [ ] Record behavioral indicators for MITRE ATT&CK TTP mapping

Phase 4 — Documentation and Sharing
- [ ] Generate structured IOC report in STIX 2.1 format (OASIS standard)
- [ ] Submit IOCs to applicable threat sharing platforms (CISA AIS, ISACs)
- [ ] Document malware family classification with confidence level
- [ ] Retain evidence in compliance with organizational and regulatory retention requirements (e.g., HIPAA § 164.316(b)(2)(i) requires 6-year documentation retention)


Reference table or matrix

Malware Type Self-Replicating Requires User Action Primary Objective Primary Detection Method MITRE ATT&CK Tactic
Virus Yes Yes Damage / propagation Signature / heuristic TA0040 (Impact)
Worm Yes No Propagation / payload delivery Behavioral / network monitoring TA0008 (Lateral Movement)
Trojan No Yes Remote access / data theft Behavioral / sandbox TA0001 (Initial Access)
Ransomware No No (post-access) Financial extortion Behavioral / honeypot TA0040 (Impact)
Spyware No No Data collection Behavioral / EDR TA0009 (Collection)
Rootkit No No Persistence / concealment Memory forensics / integrity checking TA0005 (Defense Evasion)
Bootkit No No Pre-OS persistence Firmware integrity / UEFI scanning TA0005 (Defense Evasion)
Backdoor No No Persistent access Network traffic analysis / EDR TA0011 (Command and Control)
Keylogger No No Credential theft Behavioral / API hooking detection TA0009 (Collection)
Botnet Node No No Distributed attack / fraud Network traffic analysis TA0011 (Command and Control)
Cryptominer No No Resource hijacking CPU/GPU telemetry / behavioral TA0040 (Impact)
Adware No Yes (install) Revenue generation Signature / behavioral TA0009 (Collection)

Classification source: NIST SP 800-83 Rev. 1; tactic mappings per MITRE ATT&CK Enterprise Matrix.


 ·   · 

References