Malware Types — Quick Reference
| Type | Self-Replicates? | User Action Required? | Primary Purpose | Key Characteristic |
|---|---|---|---|---|
| Virus | Yes (via host file) | Yes — must execute infected host | Spread; damage; payload delivery | Attaches to legitimate files; requires host execution |
| Worm | Yes (autonomous) | No — exploits vulnerability directly | Rapid network propagation | Spreads without user interaction; no host file needed |
| Trojan Horse | No | Yes — user installs it | Deliver hidden payload | Disguised as legitimate software; no self-replication |
| Ransomware | Depends on delivery | Depends on delivery | Extortion via encryption | Encrypts files; demands payment; delivery varies |
| Spyware | No | Usually (Trojan delivery) | Covert data collection | Silent operation; exfiltrates data to attacker |
| Rootkit | No | Usually (elevated privileges needed) | Hide attacker presence | Modifies OS to conceal malware from detection tools |
| Keylogger | No | Usually | Credential/keystroke capture | Records all keystrokes; can be software or hardware |
| Logic Bomb | No | No — triggers automatically | Delayed payload execution | Dormant until trigger condition; often insider-planted |
| RAT / Backdoor | No | Usually (Trojan delivery) | Persistent remote control | Hidden access channel; full remote administration |
| Fileless Malware | No | Usually (exploit or phishing) | Evade filesystem detection | Runs in memory; no malicious files on disk |
Virus vs. Worm — Propagation Comparison
| Property | Virus | Worm |
|---|---|---|
| Host file needed | Yes — attaches to an executable, document, or script | No — standalone; installs itself directly |
| User action needed to spread | Yes — user must execute the infected file | No — exploits vulnerability; spreads automatically |
| Propagation speed | Limited by how often users share/execute infected files | Extremely fast — exponential; one host infects many simultaneously |
| Network spread | Indirect — through shared files, email, USB | Direct — scans and exploits network services autonomously |
| Example | Melissa virus (1999) — spread via infected Word document email attachments | WannaCry (2017) — spread via SMBv1 exploit with no user interaction |
| Primary defense | Anti-malware scanning of files; user training | Patching vulnerable services; firewall rules blocking exploit traffic |
WannaCry Attack — Step by Step
1. Vulnerability exists — Windows SMBv1 contains a critical remote code execution flaw (MS17-010 / EternalBlue); all unpatched Windows systems with SMB port 445 accessible are vulnerable
2. Exploit delivery — attacker (or infected machine acting as propagation node) sends a specially crafted SMBv1 packet to a target machine's port 445; no user interaction required; the packet exploits the vulnerability
3. Arbitrary code execution achieved — the malformed packet causes SMBv1 to execute attacker-controlled code on the target system with system-level privileges
4. Ransomware payload installed — WannaCry's ransomware component is installed and begins encrypting user files (documents, photos, databases) using AES encryption; a ransom note appears demanding Bitcoin payment
5. Worm propagation begins — the infected machine immediately begins scanning IP ranges for other systems with port 445 open; for each vulnerable system found, steps 2–5 repeat; one infected machine becomes many
6. Decryption key held ransom — without the decryption key (controlled by the attacker), encrypted files are inaccessible; systems without offline backups face full data loss if the ransom is not paid
Real-World Attack Comparison
| Attack | Malicious Code Type | Target | Mechanism | Scale |
|---|---|---|---|---|
| WannaCry (2017) | Worm + Ransomware executable | Unpatched Windows systems (SMBv1) | Arbitrary code execution via MS17-010 exploit; encrypted files; demanded Bitcoin ransom | 230,000+ machines, 150 countries |
| British Airways XSS (2018) | Malicious JavaScript (22 lines) | British Airways checkout web pages | Injected script silently exfiltrated payment card data as customers typed it | ~380,000 victims' payment data |
| Estonian Health DB (year undisclosed) | SQL injection | National healthcare database application | Unsanitized query input allowed arbitrary SQL execution; full database read access | Entire country's health records |
Cross-Site Scripting (XSS) — How It Works
1. Attacker gains write access to target website — through a separate vulnerability (broken authentication, file upload flaw, admin credential theft); attacker modifies pages served to users
2. Malicious script injected — attacker adds JavaScript to a page; in BA's case, 22 lines added to checkout pages that read form field values as users typed them
3. Victim visits the page — real user navigates to the checkout page; browser downloads the page including the injected script; the browser cannot distinguish legitimate code from injected code
4. Script executes in victim's browser — the malicious JavaScript runs with the same permissions as the legitimate site's scripts; it reads card number, expiration, CVV, name, billing address from the form fields in real time
5. Data exfiltrated — as the user types payment data and submits the form, the injected script also sends the captured data to the attacker's server; the legitimate transaction completes normally; the victim has no indication anything occurred
SQL Injection — How It Works
A SQL injection vulnerability exists when user input is incorporated into a database query without sanitization. Consider a login form where the application builds a query:
SELECT * FROM users WHERE username = '[input]' AND password = '[input]'
If the user types: ' OR '1'='1' -- as the username, the query becomes:
SELECT * FROM users WHERE username = '' OR '1'='1' --' AND password = '...'
The condition '1'='1' is always true; the password check is commented out (--). The query returns all users — authentication bypassed. More advanced injections can read any table, modify data, or in some configurations execute OS commands.
Defense: Parameterized queries (prepared statements) — the query structure is defined separately from user data, so the database never interprets user input as SQL commands. Input validation as a secondary layer.
Defense Stack — Matched to Attack Types
| Defense | Attacks Addressed | How |
|---|---|---|
| Anti-malware (endpoint) | Viruses, Trojans, ransomware, spyware, keyloggers, RATs | Signature-based detection of known malware; heuristic/behavioral detection of suspicious activity; sandboxing of unknown executables |
| Firewall | Worm propagation, RAT C2 traffic, exploit delivery | Blocks traffic to vulnerable ports (e.g., SMB port 445 from external sources); blocks known malicious IPs/domains; alerts on anomalous outbound connections |
| Patching and updates | Worms, exploit-delivered ransomware, drive-by downloads | Closes the specific vulnerabilities exploits use; MS17-010 patch prevented all WannaCry infections on patched systems; patches must be applied promptly |
| Input validation / parameterized queries | SQL injection, XSS | Prevents user input from being interpreted as code; separates data from executable instructions at the application layer |
| Content Security Policy (CSP) | Cross-site scripting | HTTP header that restricts which scripts can execute on a page; limits damage from injected scripts even if XSS injection succeeds |
| Secure computing habits | Trojans, macro viruses, phishing-delivered ransomware | Users who don't install untrusted software, don't enable macros in unsolicited documents, and don't click suspicious links remove the human-action delivery vector |
| Offline backups | Ransomware | If files can be restored from backup, ransomware loses its leverage; backups must be offline or air-gapped so ransomware can't encrypt them too |
| Behavioral monitoring / EDR | Fileless malware, rootkits, RATs | Watches process behavior rather than file signatures; detects unusual use of PowerShell, WMI, or system tools regardless of whether malicious files are present |
| Least privilege | All malware that requires elevated access | Malware running under a low-privilege user account has limited impact; rootkits require OS-level privileges; limiting user rights limits malware capabilities |
Malware Detection Methods
| Method | How It Works | Strength | Limitation |
|---|---|---|---|
| Signature-based | Compares file byte patterns against database of known malware signatures | Fast; low false-positive rate for known malware | Misses new (zero-day) and obfuscated malware; requires constant signature updates |
| Heuristic analysis | Analyzes code structure and behavior patterns for malware-like characteristics | Can detect variants of known malware not in signature database | Higher false-positive rate; sophisticated malware can evade heuristics |
| Behavioral monitoring | Watches running processes for suspicious actions (mass file encryption, network scanning, registry modification) | Detects malware by what it does, not what it looks like; catches fileless malware | May catch malware only after it begins executing; some legitimate tools behave similarly |
| Sandboxing | Executes suspicious files in isolated environment; observes behavior without risk to production systems | Can safely detonate unknown malware to observe payload | Advanced malware detects sandbox environments and behaves benignly until it detects a real system |