What are the types of malware, and do the categories still matter?

The classic malware types are viruses, worms, Trojan horses, malicious mobile code and blended attacks. NIST notes that most real malware now combines these traits, so the label matters less than what the code does. Handle every incident with one consistent process: contain, identify scope, remove, recover.

What are the classic categories?

NIST's guide to malware incident handling lists the categories most people learn first.

• Viruses self-replicate by inserting copies of themselves into host programs or data files, and usually need user interaction such as opening a file. Subtypes include file infectors, boot sector viruses, macro viruses that abuse a document's macro language, and scripting viruses.
• Worms are self-replicating, self-contained programs that usually run without user action. Network service worms exploit a flaw in a network service to spread. Mass mailing worms spread by email.
• Trojan horses are self-contained, nonreplicating programs that appear benign but have a hidden malicious purpose. They often deliver other attacker tools.
• Malicious mobile code is software transmitted from a remote host and executed locally, typically without the user's explicit instruction, written in languages such as JavaScript or VBScript.
• Blended attacks use several infection or transmission methods, for example combining virus and worm propagation.

What are attacker tools, and are they malware?

Malware often installs tools whose job is to give an attacker access or capability. NIST lists backdoors (including bots and remote administration tools), keystroke loggers, rootkits, malicious browser plug-ins, email generators and attacker toolkits.

NIST makes a careful distinction: these tools have no infection capability on their own and rely on malware or other attack mechanisms to install them, so strictly speaking they are not malware. They are covered together because the same security products detect and remove both.

Why does NIST say the categories matter less now?

The guide is direct about this. Because so many instances have a variety of characteristics, and because current malware relies heavily on social engineering, the classic categories are considerably less useful for incident handling than they used to be. There was once different procedure for each category; now there is largely one set of procedures for handling all malware incidents. It even advises organizations to avoid spending substantial effort categorizing each incident.

It also points out that newer forms do not fit neatly. In drive-by-download, a user's browsing is redirected to an infected site, and the site's content works as an attacker tool that installs other tools. Phishing is outside the classic list entirely, though it often overlaps with malware delivery.

Other labels you will hear, such as ransomware, spyware or infostealer, describe what the malware does for the attacker, not how it spreads. They are useful because they point to impact and to the likely response, such as recovery from backup in the ransomware case.

A constructed example

An accountant opens an emailed spreadsheet. A macro downloads a program that installs a keystroke logger and then scans the local network for a vulnerable file service. By category, that is a macro virus delivering a Trojan, a keylogger and a network service worm. Arguing over the label wastes the first hour. The questions that help are: which machines ran the macro, what accounts were typed on them, which hosts were reachable, and what was taken. The response is the same either way: isolate affected machines, reset exposed credentials, scan and rebuild, and watch for reinfection. The scenario is invented for illustration.

How to check or apply this

1. Describe malware by observable behavior: how it arrived, what it ran, what it connected to, what it changed.
2. Keep one incident process for all malware, and record the category only as a note.
3. Layer defenses. NIST warns that customized malware defeats largely signature-based controls, and recommends defense in depth using several detection techniques.
4. Patch fast, since network service worms and drive-by attacks depend on known flaws.
5. Limit macros and script execution where users do not need them.
6. Keep offline, tested backups for the cases where cleanup is not enough.
7. After an incident, check for attacker tools such as backdoors and rootkits, not just the original file.

Quick check

Sources

• NIST SP 800-83 Revision 1, Guide to Malware Incident Prevention and Handling for Desktops and Laptops

Last reviewed: 18 October 2026.