Reference Advisory: Malicious Code Taxonomy — Classification, Propagation, and Defining Characteristics
Executive Summary
Malicious code is the technical toolkit for gaining unauthorized access to, or exerting unauthorized control over, computing systems. Where social engineering and misconfiguration attacks exploit human error and configuration mistakes, malicious code exploits vulnerabilities in software — bugs, design flaws, and unpatched weaknesses — that allow code to execute with authorization the attacker does not legitimately possess. This reference document classifies the malware types commonly tested on the Security+ examination by their defining characteristics, propagation method, and primary purpose. Correct classification is required for recommending appropriate defenses, as different malware classes are addressed by different control layers.
Malware Classification Reference
| Malware Type | Defining Characteristic | Propagation | User Action Required? | Primary Defense |
|---|---|---|---|---|
| Virus | Attaches to a host file; runs when infected file is executed; replicates into other files | Shared files, USB drives, email attachments, infected downloads | Yes — user must execute the infected file | Anti-malware; user training; application allowlisting |
| Worm | Self-contained; no host file needed; exploits network vulnerabilities to spread autonomously | Network exploitation of vulnerable services; no user interaction | No — spreads without any user action | Patching the exploited vulnerability; firewall rules blocking attack vector; network segmentation |
| Trojan Horse | Disguised as legitimate/useful software; malicious payload hidden inside apparent functionality | User installation; does not self-replicate | Yes — user voluntarily installs it | User training; application allowlisting; software source verification |
| Ransomware | Encrypts victim files; demands payment for decryption key; extortion payload | Varies: Trojan delivery, worm propagation, phishing link, drive-by | Depends on delivery method | Offline backups; patching; endpoint protection |
| Spyware | Collects user information without knowledge; transmits to attacker; operates silently | Bundled with software; drive-by download; Trojan delivery | Often yes, deceptively | Anti-malware; user training; EDR behavioral monitoring |
| Rootkit | Modifies the OS to hide its own presence; intercepts system calls to conceal files, processes, and network connections | Requires initial compromise; not self-propagating | Depends on delivery method | Boot from trusted external media for detection; OS reinstall; firmware-level scanning |
| Keylogger | Records every keystroke; captures passwords, credentials, card numbers | Software: Trojan delivery; Hardware: physical installation between keyboard and system | For software variants, yes | Anti-malware; physical security (hardware keyloggers); EDR |
| Logic Bomb | Dormant until trigger condition; activates on date, event, or condition; often planted by insiders | Manual installation by insider; no self-propagation | No — activates automatically on trigger | Code review; change control monitoring; separation of duties |
| RAT / Backdoor | Creates persistent remote access channel; full remote control; operates silently for extended periods | Trojan delivery; phishing; vulnerability exploitation | Depends on delivery method | Network monitoring for C2 traffic; EDR; firewall egress filtering |
| Fileless Malware | Operates entirely in memory; no executable files written to disk; abuses legitimate system tools (PowerShell, WMI) | Document macros; malicious scripts; Living-off-the-Land techniques | Often yes (macro execution, script click) | Behavioral EDR; script execution policy; memory scanning |
Critical Distinction: Virus vs. Worm
The exam consistently tests this distinction. The critical difference is not the payload but the propagation method: a virus requires a host file and requires user execution to spread — it cannot move on its own. A worm requires neither: it exploits network vulnerabilities to install itself on reachable systems with no user involvement. A worm can infect a fully up-to-date, well-trained user's machine if that machine has a vulnerable network service exposed — because the user does nothing to trigger the infection. This is why WannaCry infected 230,000 machines without a single user clicking anything, and why patching — not user training — is the primary defense against worm propagation.
Incident Analysis: WannaCry — Ransomware Worm Exploiting MS17-010 (EternalBlue) SMBv1 Vulnerability
Incident Overview
On May 12, 2017, the WannaCry ransomware worm began propagating across the internet and corporate networks, infecting approximately 230,000 machines in 150 countries within 24 hours. WannaCry was notable for combining two distinct capabilities: a worm propagation engine based on a critical Windows SMBv1 vulnerability, and a ransomware payload that encrypted victim files and demanded Bitcoin payment. No user interaction was required at any stage. Vulnerable machines were infected solely by virtue of having port 445 (SMB) accessible to the propagating worm.
Technical Analysis — Vulnerability and Propagation
WannaCry's propagation engine exploited MS17-010, a critical vulnerability in Windows Server Message Block version 1 (SMBv1) — the legacy Windows file-sharing protocol enabled by default on all Windows versions. The vulnerability, internally code-named EternalBlue, allowed an attacker to send a specially crafted SMBv1 packet to a target machine and achieve arbitrary code execution — the ability to run any software on the target system — without any user interaction and without credentials.
Arbitrary code execution is the highest-impact single vulnerability class. It means the attacker's code runs on the target with whatever privileges the vulnerable service operates under. In WannaCry's case, this enabled installation of the ransomware payload and the worm's scanning engine in seconds, with no prompt, no notification, and no log entry the victim would recognize as hostile until the ransom note appeared.
Propagation sequence: each infected machine immediately began scanning IP address ranges for other machines with port 445 open. On contact with a vulnerable machine, EternalBlue was used to install WannaCry on the new target. The new target began scanning immediately. Exponential propagation: tens of thousands of new infections per hour at peak.
Key Facts and Timeline
| Item | Detail |
|---|---|
| Vulnerability exploited | MS17-010 / EternalBlue — SMBv1 arbitrary code execution |
| Microsoft patch release | March 14, 2017 — two months before the attack |
| Attack launch date | May 12, 2017 |
| Peak infection rate | Tens of thousands of machines per hour |
| Total confirmed infections | ~230,000 machines in 150 countries |
| User interaction required | None — worm propagated entirely autonomously via network exploitation |
| Notable victims | UK NHS (hospitals diverted ambulances, cancelled surgeries); Telefónica; FedEx; Deutsche Bahn; LATAM Airlines |
| Kill switch | Hardcoded domain check in the worm; registering the domain (cost: $10.69) caused infected instances to halt propagation; discovered by researcher Marcus Hutchins |
| Ransom demanded | $300–$600 USD in Bitcoin per machine; relatively few victims paid; payment did not guarantee decryption |
Preventability Assessment
Every WannaCry infection was preventable. Microsoft had released the MS17-010 patch on March 14, 2017 — 59 days before the attack. Systems that had applied the patch were completely immune to the EternalBlue exploit. Every infected system had failed to apply a publicly available patch during that 59-day window. This is the defining lesson of WannaCry for security practitioners: the "window of vulnerability" between patch release and patch application is the window in which exploitation succeeds. The WannaCry timeline makes the cost of delayed patching inescapably concrete.
Additionally, organizations that had disabled SMBv1 (deprecated and unnecessary in modern Windows environments) were immune regardless of patch status — removing the attack surface entirely eliminated the vulnerability.
Recommended Mitigations
- Continuous patching with defined SLAs: Critical patches must be applied within 48–72 hours of release. An 18-month or even 2-month patching lag is operationally indefensible for a Critical severity vulnerability with active exploitation. Automated patch deployment with emergency patch procedures for critical vulnerabilities is required.
- Disable SMBv1: SMBv1 is a legacy protocol deprecated by Microsoft. It has no legitimate use in modern Windows environments. Disable via Group Policy or PowerShell on all systems. This removes the EternalBlue attack surface entirely on otherwise unpatched systems.
- Firewall rules blocking SMB from untrusted networks: Block TCP port 445 (and 139) inbound from external networks and untrusted network segments. WannaCry's initial external infection vector required port 445 to be reachable from the internet. Perimeter firewalls that blocked SMB prevented external infection; internal segmentation would have limited intra-network spread.
- Offline backup strategy: Ransomware encrypts all accessible data including network shares. Offline (air-gapped) backups not reachable from infected systems enable recovery without paying ransom. 3-2-1 backup rule: 3 copies, 2 media types, 1 offsite/offline.
Advisory: Web-Based Malicious Code — XSS Formjacking and SQL Injection Against Web Applications
Executive Summary
Web applications present a distinct malicious code attack surface from the endpoint and OS-level threats covered in MALCODE-2024-001 and -002. Two web-specific malicious code techniques are covered in this advisory: cross-site scripting (XSS), which injects malicious JavaScript into legitimate web pages to execute in other users' browsers, and SQL injection, which injects malicious SQL commands into database queries through unsanitized input fields. Both techniques were used in significant real-world breaches: the 2018 British Airways payment data theft (XSS formjacking) and the Estonian Central Health Database breach (SQL injection). Each requires defenses at the application code layer that differ from the OS-level and network-level controls used for traditional malware.
Incident Analysis — British Airways XSS Formjacking, 2018
Between June and September 2018, attackers attributed to the Magecart threat group compromised the British Airways website and inserted 22 lines of malicious JavaScript into the payment processing pages used by customers booking flights. The injected script monitored the payment form in real time: as customers typed their payment card details (card number, expiration date, CVV, cardholder name, billing address), the script captured the input values and transmitted them to an attacker-controlled server at the moment of form submission.
The attack ran undetected for more than two weeks. Approximately 380,000 customers had payment card data compromised. British Airways was subsequently fined £20 million under the UK GDPR (reduced from an initial £183 million proposed fine).
The attack's efficiency is notable: a single website compromise automatically became an attack against 380,000 users. The attacker never accessed those users' devices. The attack succeeded because the injected script ran with the same browser trust level as the legitimate site's own JavaScript — the browser could not distinguish malicious injected code from authorized site code. Detection required monitoring the site's loaded scripts for unexpected additions, which was not in place during the initial breach window.
Incident Analysis — Estonian Health Database SQL Injection
In a separate incident, attackers exploited a SQL injection vulnerability in Estonia's national healthcare database application. The vulnerability existed in an input field that accepted user-supplied data and incorporated it directly into a database query without sanitization. By supplying SQL syntax rather than the expected data value, the attackers were able to manipulate the database query to return unauthorized records — ultimately gaining access to the patient record database for the entire country.
A parameterized query would have prevented the breach: by separating query structure from data values, the database engine would have treated the attacker's SQL input as a literal string to search for rather than executable query syntax. The absence of this basic control — standard practice for decades — allowed a single input field to become the entry point for a national health data breach.
Web Malicious Code Comparison
| Technique | Attack Layer | Mechanism | Primary Defense |
|---|---|---|---|
| XSS (stored/persistent) | Browser (client-side) | Malicious JavaScript stored on server; executes in victim browsers when page is loaded; can read cookies, form data, and perform actions as the victim | Output encoding; Content Security Policy (CSP) headers; input sanitization |
| XSS formjacking (Magecart style) | Browser (client-side) | JavaScript injected into checkout/payment page captures form field data as typed; transmits to attacker server | Subresource Integrity (SRI) for third-party scripts; CSP; website script integrity monitoring |
| SQL Injection | Server (database layer) | Malicious SQL syntax in input fields manipulates database queries; enables unauthorized read/write/delete of database contents | Parameterized queries (prepared statements); least-privilege database accounts; input validation |
Recommended Mitigations
- Content Security Policy (CSP) headers: A CSP header instructs the browser to execute only scripts loaded from explicitly approved sources. An injected inline script or a script loaded from an unexpected domain is blocked by the browser before execution. Had British Airways implemented a restrictive CSP, the injected Magecart script loading from an external attacker domain would have been blocked in all visiting browsers. CSP is configured at the web server or application layer and costs nothing beyond implementation effort.
- Parameterized queries for all database interactions: User-supplied values must be passed to the database as bound parameters, never concatenated into query strings. This is the architectural prevention for SQL injection. Input validation and WAF rules are secondary layers — parameterized queries are the required primary control.
- Website integrity monitoring: Automated comparison of loaded JavaScript against a known-good baseline enables detection of injected scripts. The British Airways breach ran for two weeks because no such monitoring was in place. Continuous integrity checks against deployed page content, with alerting on unexpected changes, would have enabled rapid detection and response.
- Third-party script governance: Any JavaScript loaded from a third party (analytics, advertising, payment processing, chat widgets) has the same execution authority in the browser as the site's own scripts. Each third-party script is a potential injection vector if that vendor is compromised. Audit all third-party script dependencies; use Subresource Integrity (SRI) to verify script hash before execution; minimize third-party script surface area.