What Is Malware? Types, Infection Routes, and Recovery
Follow a malicious download from its first execution to the access and information it may expose.
Key takeaways
- Malware is software or code used to compromise systems, information, or authorized activity.
- Labels such as worm, Trojan, and ransomware describe different properties and can overlap.
- Malware can arrive through deception, exploited vulnerabilities, or compromised software distribution.
- Removing a file does not establish that stolen credentials, persistence, or wider access have been addressed.
Malware is malicious software or code designed to steal information, disrupt operations, damage data, spy on activity, or give an attacker unauthorized access.
A computer virus is one kind of malware. The broader category also includes ransomware, spyware, worms, and other malicious programs.
Imagine an employee installing what appears to be a required document viewer. The installer opens a plausible application while quietly collecting credentials. The visible program may work normally even though the device is compromised.
Malware Types Describe Different Things
Some labels describe how malicious code spreads; others describe what it does.
| Type | Main characteristic |
|---|---|
| Virus | Replicates by infecting host files or programs |
| Worm | Replicates between systems, often through reachable weaknesses |
| Trojan | Presents malicious behavior within something that appears legitimate |
| Ransomware | Restricts access or encrypts data as part of extortion |
| Spyware | Collects information about users or systems |
| Information stealer | Targets valuable data such as credentials or session material |
One program can fit several descriptions. A Trojan installer might deploy an information stealer and later deliver ransomware.
NIST’s malware prevention and handling guide treats malware as a threat to the confidentiality, integrity, and availability of systems and data.
How Malware Gets Onto a Device
A deceptive download is one route. Others include malicious attachments, compromised websites, untrusted extensions, and software distributed through a compromised supplier.
An attacker can also exploit a vulnerability in a reachable service. That path may require no user to click anything.
Phishing can persuade someone to install malware, but phishing and malware are different concepts. A fake login page can steal a password without installing a program.
For the document-viewer example, the crucial event is execution. Downloading a file, opening it, granting permissions, and running its code are different actions whose consequences need to be established.
What Can Happen After Execution?
The first program may be only a starting point. It can establish a way to run again, contact external infrastructure, collect information, or download additional components.
The attacker may then use exposed credentials to access accounts from another device. Deleting the installer does not revoke those credentials or terminate every session.
Likewise, malware running under an account with broad access may reach shared folders or administrative resources. The impact depends partly on the permissions available to the compromised process.
This is why least privilege and resource-level access controls matter even when endpoint protection is present.
Why Symptoms Are Not a Reliable Diagnosis
Unexpected pop-ups, disabled security tools, unusual account activity, and unexplained processes deserve investigation. Slow performance alone does not prove infection.
The reverse is also true: a responsive computer can still contain software designed to remain quiet.
Endpoint tools can combine known-file detection with behavior and other signals. A clean scan is useful evidence, but its meaning depends on the tool, coverage, and what happened before the scan.
Record the observed behavior and relevant times rather than assuming one symptom identifies a particular malware family.
Different Controls Interrupt Different Stages
Keeping software updated reduces exposure to known vulnerabilities. Restricting installation sources and unnecessary privileges reduces opportunities for malicious execution.
Endpoint monitoring can help detect suspicious behavior. Segmentation can limit movement to other systems. Account controls can restrict what stolen credentials allow.
Backups address another problem: recovering data after destructive activity. They do not remove malware or prevent publication of information already stolen.
For the document-viewer scenario, protected recovery copies might restore damaged files while account recovery is still required. No single control covers both outcomes.
What to Do After Suspected Execution
For an organizational device, stop normal use and contact the designated security or IT team through a known channel. Follow their containment process, which may include disconnecting the device from networks.
Explain what was opened, installed, or approved and when. Avoid experimenting with the suspicious program or attaching backup drives to the affected machine.
If credentials may have been exposed, perform account recovery from a known-clean device. Responders may need to revoke sessions, rotate credentials, and inspect account changes as well as address the endpoint.
Avoid immediately wiping an organizational device unless directed. That may remove evidence needed to identify other affected systems. NIST’s incident-response guidance places response and recovery within a broader risk-management process.
Recovery Should Address the Original Entry Point
Restoring files or rebuilding a device is incomplete if the vulnerable service, malicious extension, or compromised account remains.
Determine how the incident began, what access was available, and which recovery actions can be verified. Test that restored data is usable and that important accounts are no longer accessible through exposed credentials or sessions.
For the employee’s laptop, a successful outcome includes a trustworthy device, secured accounts, and an understood installation path. That is stronger evidence than the disappearance of the original installer.
Finding the malicious file is the beginning of understanding an incident, not proof that its consequences have ended.