Types of Malware: Common Categories and Their Risks

Malware is software or firmware intended to perform an unauthorized action that harms confidentiality, integrity, or availability. Common types include viruses, worms, trojans, ransomware, spyware, rootkits, backdoors, botnets, wipers, and cryptojackers. These labels describe different dimensions, so one incident may fit several types and its real risk depends on context.

For developers, the useful question is not only “Which malware family is this?” It is “How did it arrive, what authority did it obtain, what behavior was observed, what outcome followed, and which control should change?” This guide compares the major malware types using that defensive model.

Malware Is a Multi-Axis Classification

Malware labels are useful shortcuts, but they are not mutually exclusive species. Each label usually describes one of these axes:

• Delivery and propagation: how software reached another system or moved between systems. Virus, worm, trojan, downloader, dropper, and supply-chain compromise belong mainly here.
• Execution, stealth, and persistence: how activity runs or remains difficult to observe. Fileless malware, rootkits, and bootkits describe this axis.
• Capability or objective: what the operator attempts to achieve. Ransomware, spyware, infostealers, keyloggers, backdoors, bots, wipers, and cryptojackers describe capabilities or outcomes.
• Environment: where the threat operates. Mobile, IoT, endpoint, server, cloud, container, browser, and operational technology are environments, not single behaviors.

A compromised dependency may arrive through a trusted update, behave like a trojan, install a downloader, establish a backdoor, collect credentials, and later enable ransomware. Calling it only a “trojan” hides the later impact. Calling it only “ransomware” hides the delivery and access paths that must be fixed.

This overlap is visible in real incidents. MITRE ATT&CK describes NotPetya as malware that appeared to be ransomware but functioned as a destructive wiper and spread through several paths. The lesson is not the historical label; it is that response should follow observed behavior and affected trust boundaries.

The diagram is a classification aid, not an implementation sequence. During a real investigation, mark each statement as observed, inferred, reported, or unknown. A label should never be more confident than the evidence behind it.

How to Compare Malware Risk

A malware type does not have a universal severity. Risk changes with the affected asset, privileges, data sensitivity, exposure, segmentation, propagation speed, persistence, monitoring, and recovery readiness. An infostealer on a disposable test machine and the same capability on an administrator workstation have very different consequences.

The table uses C for confidentiality, I for integrity, and A for availability. “High” means the malware type commonly creates strong pressure on that property, not that every alert is a confirmed high-severity incident.

Delivery and Propagation Types

Virus

A virus attaches to or modifies a host file, document, or program and reproduces when that host is executed or shared. The label mainly describes propagation, not the final objective. The primary risk is integrity loss, followed by downtime when many files require restoration. Unexpected file-hash changes, repeated detections around shared artifacts, and applications behaving differently are investigation signals. Isolate affected assets through the approved process, preserve representative evidence, and use trusted baselines to determine scope.

Worm

A worm spreads between reachable systems without requiring a person to open each infected host file. Its defining risk is speed: a modest payload can become a major availability incident when propagation consumes network or system capacity. Similar events across many hosts, unusual connection growth, and services failing together justify urgent investigation. Prioritize segmentation, scoped isolation, identity containment, and fleet-wide exposure analysis. “Self-propagating” does not reveal the worm's objective, so assess later capabilities separately.

Trojan

A trojan presents itself as legitimate or arrives inside something the recipient trusts. It is a delivery description, not one fixed payload. The risk may range from unauthorized access to data theft or destructive follow-on activity. Publisher changes, provenance mismatches, unexpected privileges, or behavior outside the product contract can raise suspicion. Pause distribution, preserve the exact artifact and metadata, and verify source, signer authorization, builder identity, and expected behavior before restoring trust.

Downloader and Dropper

Downloaders retrieve additional software; droppers place or unpack another component already carried with them. Both are staging capabilities, so the visible first component may not explain the eventual impact. Unexpected process relationships, new artifacts, or network activity inconsistent with the application contract should be correlated across endpoint and network evidence. Response must hunt for follow-on components and affected identities rather than deleting only the first file. Do not execute an unknown sample to discover what comes next.

Supply-Chain Malware

Supply-chain malware reaches users through a trusted dependency, maintainer account, source repository, builder, artifact registry, signing process, update channel, or service provider. It is an entry path rather than one behavioral family. Trust can create a large downstream blast radius before defenders see endpoint signals. Suspend the affected release path, identify immutable versions and digests, verify provenance, notify owners, and rebuild through a known-good path. The software supply-chain security guide explains the preventive controls.

Extortion, Destruction, and Surveillance

Ransomware

Ransomware supports extortion, commonly by making data or systems unavailable and sometimes by pairing disruption with data theft. Its risk spans availability, confidentiality, legal exposure, customer trust, and recovery cost. Sudden high-volume file changes, inaccessible services, unexpected backup failures, or an extortion message require the incident process, but no one signal proves ransomware. Contain affected systems and identities, preserve evidence, determine whether data left the environment, and recover only from verified, tested sources.

Wiper

A wiper destroys or irreversibly alters data, software, or system state. It may imitate ransomware even when recovery was never intended, so a ransom-shaped message should not determine the classification. The dominant risks are integrity and availability, with recovery potentially requiring full rebuilds. Treat destructive changes as time-sensitive, isolate through approved controls, protect clean backups and management planes, and retain enough evidence to understand distribution. Restoration without closing the compromised path can repeat the damage.

Spyware

Spyware is an umbrella category for covert monitoring and collection. It may gather communications, browsing, location, documents, audio, screen content, or other sensitive information depending on its privileges and platform. The main risk is confidentiality loss that can continue unnoticed. Unexpected access to sensitive resources, permission changes, or unexplained outbound activity are reasons to investigate. Response should identify affected people and data, revoke exposed access, consider privacy and legal duties, and avoid collecting more personal data than the investigation needs.

Infostealer

An infostealer targets valuable information such as credentials, session material, browser data, documents, configuration, or developer secrets. A single compromised engineering workstation can expose source repositories, cloud environments, package registries, and customer systems. Treat affected tokens and active sessions as potentially exposed, not only saved passwords. Preserve endpoint and identity evidence, revoke sessions through approved systems, rotate confirmed-at-risk secrets, and inspect downstream activity. The term describes collection intent; another component may provide delivery or persistence.

Keylogger

A keylogger records keyboard input or equivalent user interaction. It is a capability that may appear inside spyware, an infostealer, or another tool, not necessarily a separate family. Risk is highest where users enter privileged credentials, financial data, source code, or private communications. Unexpected input-monitoring permissions and behavior can justify review, but legitimate accessibility and management software can create similar observations. Validate context, protect the affected identity, and follow privacy-aware evidence handling rather than assuming intent from one signal.

Unauthorized Control and Fleet Abuse

Backdoor and Remote Access Trojan

A backdoor provides unauthorized access that bypasses the expected trust path. A remote access trojan, often called a RAT, exposes remote-control capabilities through deceptive or unauthorized deployment. Similar functions can exist in legitimate administration products, so authority, provenance, configuration, and user intent matter. Unexpected remote sessions, services, accounts, or network relationships warrant investigation. Isolate the host, protect related identities, determine what the access could reach, and rebuild trust instead of assuming removal of one component ended access.

Bot and Botnet Malware

A bot is a compromised system controlled as part of an operator-managed fleet; a botnet is the collection. Bots may support distributed denial of service, proxying, spam, credential abuse, resource theft, or delivery of other malware. Repeated outbound coordination, unexplained network traffic, and similar behavior across devices are useful signals. Block confirmed abusive communication through managed controls, isolate affected nodes, find the enrollment path, and remediate the whole population. The fleet behavior matters more than any single process name.

Web Shell

A web shell is unauthorized server-side code that gives an operator control through a web-facing application or server. It often indicates an earlier application, identity, or deployment compromise. The risk includes data access, application modification, credential exposure, and movement to connected services. Unexpected server files, requests, child processes, or deployment drift require correlation with change and access records. Preserve evidence, remove public exposure through approved controls, rotate affected authority, fix the original entry path, and rebuild from a verified artifact.

Stealth, Persistence, and Execution Style

Rootkit

A rootkit conceals unauthorized activity or maintains privileged access by altering or subverting trusted system layers. Its greatest risk is epistemic: normal tools and telemetry may no longer describe the host reliably. Conflicting system views, integrity failures, or security controls behaving unexpectedly should trigger specialist review, not improvised cleanup. Preserve external evidence, reduce the host's authority, and recover from a trusted baseline. The presence of stealth does not identify the original delivery method or operator objective.

Bootkit

A bootkit persists in or compromises the startup chain before the operating system is fully trusted. That can survive ordinary operating-system repair and undermine later security observations. Boot-integrity or firmware-integrity alerts, unexplained startup changes, and persistent anomalies after normal remediation require hardware and platform expertise. Containment should protect credentials and management systems used by the device. Recovery may require verified firmware, boot configuration, and full re-provisioning under vendor guidance, not repeated in-place cleaning.

Fileless Malware

“Fileless” describes execution that relies heavily on memory, interpreters, or existing system capabilities instead of a conventional standalone payload on disk. It is not an objective, and it does not mean no file appears anywhere in the incident. The main risk is reduced coverage from file-only scanning. Use behavior, process lineage, memory-aware endpoint telemetry, identity events, and network context. Microsoft's fileless-threat taxonomy explains why several distinct patterns sit under this label.

Resource Abuse and Target Environments

Cryptojacker

A cryptojacker consumes computing resources without authorization, usually to produce financial value for an operator. The immediate signs may be unexpected CPU or GPU use, cloud-cost growth, throttling, or degraded workloads. The deeper risk is the access that made resource theft possible. Contain the affected workload and identity, review cloud and deployment activity, rotate exposed authority where evidence supports it, and close the entry path. Do not treat reduced utilization alone as proof that the compromise is gone.

Adware and Scareware

Adware forces or injects advertising; scareware uses alarming claims to pressure a person into paying, granting permission, or installing software. These categories often create lower direct infrastructure impact than a wiper, but they are not automatically harmless. Browser changes, unwanted redirects, persistent notifications, and unfamiliar applications can signal privacy loss or a secondary installation path. Remove unauthorized software through managed endpoint processes, review permissions and affected accounts, and address the distribution source across the fleet.

Mobile Malware

Mobile malware is a platform category that can include trojans, spyware, infostealers, ransomware, and financial fraud capabilities. Risk depends on device permissions, enterprise identity, personal data, accessibility access, and whether the device participates in multifactor authentication. Unexplained permission changes, battery or network anomalies, unfamiliar profiles, or security alerts merit investigation. Use the organization's mobile-management and incident procedures, revoke affected sessions, protect personal privacy, and restore only through trusted platform channels.

IoT Malware

IoT malware targets connected devices such as cameras, gateways, appliances, sensors, and embedded systems. Large, similar fleets, exposed management interfaces, long patch cycles, and weak inventories can turn one compromise into a botnet or operational outage. Unexpected device traffic, configuration drift, or loss of management control should be investigated centrally. Segment devices, restrict their identities and destinations, apply vendor-supported updates, replace unsupported equipment when necessary, and preserve safety before attempting containment in operational environments.

Which Malware Type Is Most Dangerous?

There is no defensible universal ranking. A worm can create the fastest blast radius, ransomware can stop a business, a wiper can destroy recovery options, an infostealer can expose privileged cloud sessions, a rootkit can invalidate host evidence, and supply-chain delivery can distribute several of those capabilities through trusted infrastructure.

Rank the incident instead. Ask which assets are affected, what authority is exposed, whether propagation is continuing, whether sensitive data may have left, whether production integrity can be proven, and how safely service can recover. A supposedly “medium” category becomes critical when it compromises the identity or delivery system that controls thousands of other assets.

Warning Signs That Require Investigation

These signals are reasons to investigate, not proof of malware. Deployment changes, administrator tools, accessibility features, performance bugs, and monitoring failures can produce similar observations.

• An application creates processes, files, accounts, permissions, or network connections outside its documented contract.
• Artifact digests, publisher identity, provenance, dependencies, or deployed versions differ from approved records.
• Many hosts show the same unusual activity or services degrade together.
• Files become inaccessible, change rapidly, or fail integrity checks without an authorized operation.
• Authentication systems show unexpected sessions, token use, privilege changes, or access from affected identities.
• Compute, bandwidth, storage, or cloud cost rises without a matching workload change.
• Endpoint, boot, logging, backup, or security controls become unavailable or report conflicting state.

A good triage record names the event source, timestamp, asset, identity, expected behavior, observed difference, confidence, and plausible benign alternatives. It avoids converting “unusual” into “malicious” without supporting evidence.

Safe First Response When Malware Is Suspected

1. Stop informal exploration. Do not open, install, execute, upload, or forward an unknown artifact. Move from learning or debugging into the authorized incident process.
2. Activate ownership. Notify the incident lead, system owner, security team, and any privacy, legal, safety, or customer-response roles required by policy.
3. Contain deliberately. Use approved isolation and identity controls. Consider business and safety impact before disconnecting critical, medical, industrial, or operational systems.
4. Preserve evidence. Record asset identity, time, source, artifact digest, alerts, deployment version, relevant logs, actions taken, and evidence handlers. Avoid changing the original evidence unnecessarily.
5. Determine scope. Search inventories, deployments, identities, artifact digests, and telemetry for related exposure. Include downstream systems reached by the affected trust path.
6. Remove compromised authority. Revoke sessions, rotate confirmed-at-risk credentials, suspend a bad release, or block affected distribution through the systems that own those controls.
7. Recover from known-good sources. Rebuild or re-provision where trust cannot be proven, validate backups before restoration, patch the entry path, restore in stages, and monitor for recurrence.

Developer Controls That Reduce Malware Risk

Developers rarely control every endpoint, but they control many of the paths malware abuses. Review each product with four verbs:

• Prevent: verify dependency and update origin, lock immutable inputs, require reviewed provenance, isolate parsers and plugins, validate untrusted content, protect signing paths, and use secure defaults.
• Limit: apply least privilege to users, services, CI jobs, installers, and extensions; separate production identities; restrict unnecessary egress; segment workloads; and make privileged helpers narrow and short-lived.
• Observe: record artifact digest, version, signer authorization, workload identity, process relationships, sensitive operations, configuration changes, and network metadata with privacy-aware retention. Monitor the health of the telemetry itself.
• Recover: keep deployment and dependency inventory, tested backups, immutable known-good artifacts, credential-revocation paths, kill switches, staged rollback, customer communication, and incident exercises.

Prefer testable requirements over slogans. “Block malware” is not an engineering contract. “The document-conversion worker has no deployment credentials, cannot reach the public internet, uses a read-only input, and is replaced after each job” is specific enough to test and review.

Continue with the malware-resistant software and delivery guide for architecture controls, the common CI/CD attack paths guide for pipeline trust, and the runtime security cheatsheet for observable signals.

Common Classification and Response Mistakes

• Calling all malware a virus: a virus is one propagation mechanism; many common threats do not infect host files.
• Choosing one exclusive label: record delivery, execution, behavior, objective, impact, and environment separately.
• Assigning severity from the name: asset value, authority, scope, exposure, and recovery determine incident risk.
• Assuming fileless means invisible: fileless activity can still produce process, memory, identity, network, and configuration evidence.
• Trusting a signature without authorization: a valid signature can identify a signer and protect integrity under its scheme; it does not prove the release was expected or safe.
• Treating one indicator as proof: filenames, hashes, domains, process names, and behavior patterns require context and can change or overlap with legitimate software.
• Equating a clean scan with safety: scanners have coverage limits. Provenance, behavior, identity, exposure, and product context still matter.
• Cleaning one host before scoping: the affected identity, delivery channel, other components, and downstream systems may remain exposed.
• Relying on backups alone: recovery also requires clean credentials, a fixed entry path, verified artifacts, tested restoration, and evidence that the threat is no longer active.

Common Questions

Is a virus the same as malware?

No. Malware is the broad category. A virus is malware that reproduces by attaching to or modifying a host file or program. Worms, trojans, ransomware, spyware, rootkits, and many other types are malware without necessarily being viruses.

Can one program be a trojan, infostealer, and ransomware?

Yes. “Trojan” can describe deceptive delivery, “infostealer” can describe collection capability, and “ransomware” can describe extortion impact. Separate labels make the incident easier to reason about when each is tied to evidence.

Does ransomware always encrypt files?

No. Encryption is common, but extortion can also rely on data theft, service disruption, or threats of disclosure. Responders should assess availability and possible confidentiality impact instead of assuming the visible ransom mechanism is the whole incident.

Is legitimate remote administration software malware?

Not by itself. Authority, deployment, configuration, and use matter. An approved support tool used within policy is different from the same capability installed deceptively or operated without authorization. Detect behavior and validate context before declaring intent.

Can antivirus detect every type?

No single control has complete coverage. Effective defense combines software-origin verification, least privilege, attack-surface reduction, endpoint and identity telemetry, network controls, tested detections, segmentation, backups, incident ownership, and verified recovery.

Continue Learning on CodersSecret

• Malware Analysis and Defense for Developers provides the complete defense-first learning path.
• Malware Concepts and Multi-Axis Taxonomy teaches evidence-backed classification.
• Malware Analysis for Developers explains safe triage without live-malware practice.
• Malware Detection Engineering with YARA and Sigma covers testable defensive detections.
• Incident Response Simulator lets you practice containment and recovery decisions.

Official Sources and Further Reading

• NIST Computer Security Resource Center: Malware definition
• NIST SP 800-83 Rev. 1: Guide to Malware Incident Prevention and Handling
• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations
• CISA StopRansomware Guide
• CISA and NSA: Detect and Prevent Web Shell Malware
• NIST SP 800-218: Secure Software Development Framework
• MITRE ATT&CK knowledge base