The Melissa virus of 1999 is one of the most instructive macro virus examples because it demonstrated, for the first time at scale, how a document-based virus could achieve epidemic spread through email.
How it spread: Melissa was embedded as a macro in a Microsoft Word document. The document was posted to an internet newsgroup with a message suggesting it contained passwords to adult websites — social engineering to encourage opening the file. When an infected document was opened and macros executed, the virus accessed the victim's Microsoft Outlook address book and automatically emailed copies of the infected document to the first 50 contacts. Each of those recipients, if they opened the document, would send it to 50 more contacts. The geometric growth quickly overwhelmed email servers.
The damage: Melissa did not destroy data — its payload was limited to spreading itself. But the sheer volume of email it generated caused email servers at organizations across the United States to become overloaded and unavailable. Companies including Microsoft, Intel, and government agencies had to shut down their email gateways to stop the flood. The FBI estimated over $80 million in damages from disrupted services.
Why it matters for the exam: (1) Macro viruses live inside documents, not executables. (2) The spread mechanism was the shared document — every recipient who opened the document became a new vector. (3) The virus exploited both technical capabilities (Office macros) and human behavior (social engineering to open the document). (4) Melissa spread through user action (opening a document) — this is the defining virus characteristic, not worm propagation.
The ILOVEYOU virus of May 2000 is among the most damaging script viruses in history, infecting an estimated 10% of internet-connected computers worldwide and causing damage estimated at $5.5 to $8.75 billion.
The delivery: ILOVEYOU arrived as an email with the subject line "ILOVEYOU" and an attachment named "LOVE-LETTER-FOR-YOU.TXT.vbs". The .txt in the filename was a visual trick — the actual extension was .vbs (Visual Basic Script). Windows at the time hid known file extensions by default, so the file appeared to users as a harmless text file rather than a script. When the user double-clicked the attachment, Windows executed the VBScript.
What the script did: The VBScript performed several actions: (1) It copied itself to multiple locations on the system and overwrote files with certain extensions (.jpg, .jpeg, .mp3, .mp2) with copies of itself, effectively destroying those files. (2) It sent copies of itself to every address in the victim's Outlook address book — similar to Melissa but without any limit on recipients. (3) It added registry entries to run itself on startup and attempted to download additional malicious code from the web.
Why the file extension mattered: ILOVEYOU is the historical basis for the security recommendation to always show file extensions in Windows. A user who could see the full filename "LOVE-LETTER-FOR-YOU.TXT.vbs" would understand it is a script, not a text document. With extensions hidden, the social engineering was trivially effective.
Exam takeaways: (1) Script viruses use scripting languages (VBScript, JavaScript, PowerShell) to execute malicious code. (2) Script viruses can arrive via email as attachments — user must open/run them (virus, not worm). (3) File extension spoofing is a delivery technique. (4) Showing file extensions is a defensive measure against this attack vector.
WannaCry is covered in Chapter 40 as a ransomware example. It is equally important here as the defining modern worm example — and specifically as a demonstration of what happens when worm propagation is combined with a ransomware payload.
The worm component: WannaCry's propagation mechanism was EternalBlue, an exploit for the Windows SMB (Server Message Block) protocol. SMB is the service that allows Windows computers to share files and printers across a network. The EternalBlue exploit allowed arbitrary code execution on any Windows system with SMB exposed on port 445 and not patched against MS17-010. No user on the target system needed to do anything — the system only needed to be reachable on the network.
The speed: Because no human action was required on any target, WannaCry's spread was limited only by network bandwidth and the number of reachable unpatched systems. Security researchers observed WannaCry scanning at approximately 50 million IP addresses per second globally. NHS hospitals in the UK, Spanish telecommunications company Telefónica, and FedEx's TNT division were among the high-profile victims. The infection took down hospital IT systems, forcing cancellation of appointments and diversion of ambulances.
The kill switch: A security researcher discovered that WannaCry contained a hardcoded domain name that it checked before executing. If the domain resolved, the worm halted. The domain was unregistered. The researcher registered it for $10.69, and new WannaCry infections stopped almost immediately — demonstrating that the domain check was a test for sandbox detection (sandboxes often make all domain lookups return responses). This accidental kill switch limited but did not stop the outbreak for already-infected systems.
Exam takeaways: (1) WannaCry = worm (EternalBlue propagation) + ransomware (encrypted data files). The worm is the delivery mechanism; the ransomware is the payload. (2) No user action was required on any target — distinguishes this from a virus. (3) MS17-010 patch (available 58 days before WannaCry) would have blocked the worm on patched systems. (4) Network segmentation would have contained the spread to the initially infected segment.
Fileless malware attacks have become increasingly common because they evade the signature-based antivirus tools that most organizations rely on. The following illustrates a representative fileless attack chain.
Initial access — the spearphishing email: The target receives an email appearing to be from a trusted vendor, containing a link to a "shared document." The link leads to a website that serves a malicious page. The page includes JavaScript that detects the browser version and delivers an exploit targeting a known vulnerability in an unpatched browser. The exploit runs in the browser's memory space — no file is written to disk.
In-memory execution: The exploit code calls Windows PowerShell with a Base64-encoded command as an argument. The command is not a file — it is text passed directly to PowerShell on the command line. PowerShell decodes and executes it entirely in RAM. The first-stage script makes an HTTPS connection to the attacker's command-and-control server and downloads a second-stage script, also executed in memory.
What the attacker achieves: The in-memory scripts establish a persistent shell that gives the attacker interactive access to the system. A keylogger runs in memory, recording credentials as the user logs into internal systems. After several days, the attacker has collected VPN credentials, email credentials, and domain admin credentials — all captured without any malicious file ever existing on disk.
The persistence mechanism: To survive reboots, the malware adds a single registry key in HKCU\Software\Microsoft\Windows\CurrentVersion\Run. The value is a PowerShell command that looks like a legitimate system health check. On every startup, PowerShell runs this "health check," which re-executes the entire in-memory chain. The antivirus scans the disk and registry for known patterns — the registry value contains no recognizable malware signature. The antivirus reports clean on every scheduled scan.
Detection: The infection is ultimately discovered by an EDR tool flagging anomalous PowerShell behavior — specifically, PowerShell spawning network connections to an external IP on startup. The behavioral alert triggers investigation; registry analysis finds the autostart entry; memory forensics captures the in-memory scripts. There was nothing on disk to find until the registry key was identified.
Scenario: A user in an accounting department opens a spreadsheet sent by a colleague. Shortly after, their Excel application begins behaving unusually — creating unexpected copies of spreadsheets in network shared folders and modifying other Excel files the user opens. Antivirus does not detect any executable malware. Which type of virus BEST explains this behavior?
Answer: This is a macro virus. The indicators are: (1) The infection vector was a spreadsheet file sent via email — macro viruses spread through document files, not executables. (2) The virus replicates by copying itself into other documents (Excel files) as they are opened — the classic macro virus behavior of infecting the application's document template so every new document is infected. (3) The antivirus does not detect an executable because the virus is embedded as a macro (VBA code) within documents, not as a standalone executable program. Macro viruses typically evade basic antivirus that focuses on executable scanning. Remediation: disable macros organization-wide by policy, scan all shared documents for embedded macros, use Office Protected View settings to block macro execution from external files.
Scenario: A security team detects that a server in the data center has been compromised by a worm that is actively scanning the internal network for other vulnerable systems. The worm exploits a known vulnerability in a network service for which a patch is available. The server cannot be immediately taken offline due to critical operations. Which immediate actions should the team take to limit the spread of the worm?
Answer: Two immediate actions are highest priority: (1) Network segmentation / isolation — if the server cannot be taken offline, isolate it at the network layer by blocking its traffic through VLAN segmentation or ACLs (access control lists) at the switch level. Prevent it from initiating new connections to the rest of the network. The worm spreads by scanning for and connecting to vulnerable systems — cutting network access stops propagation without taking the server offline. (2) Emergency patching of unaffected systems — immediately push the patch for the exploited vulnerability to all other systems on the network. Systems that are patched are no longer viable targets for the worm. Prioritize systems most accessible from the compromised server's network segment. Additionally: (3) Activate IPS signatures for the worm's known scan pattern to detect and block any propagation attempts that bypass the segmentation. (4) Monitor for additional compromised systems using SIEM alerts for the worm's characteristic scanning behavior. (5) Plan for an emergency maintenance window to patch the affected server as soon as operationally feasible.
Scenario: An analyst investigates a workstation after an EDR alert about unusual PowerShell network activity. A full antivirus scan returns clean — no malware files detected. The analyst observes that PowerShell runs briefly at every system startup, making an outbound connection to an external IP address, before terminating. No PowerShell scripts exist on the local disk. What is the MOST likely explanation, and what should the analyst do?
Answer: This is most consistent with fileless malware using PowerShell as its execution environment. The indicators are: (1) clean antivirus result despite active malicious behavior — signature-based AV found no files to match against; (2) PowerShell running at startup with no corresponding script on disk — the script is passed as a command-line argument or pulled from a registry value; (3) outbound network connections at startup — consistent with C2 check-in or script download from attacker infrastructure.
The analyst should: (1) Examine the Windows registry autostart locations — specifically HKCU and HKLM Run keys, scheduled tasks, and WMI event subscriptions — for PowerShell commands that execute at startup. The malicious autostart entry will be found here. (2) Capture a memory image before rebooting or remediating — the in-memory scripts are the primary forensic evidence and will be lost after reboot. Memory forensics tools can extract the PowerShell scripts from RAM. (3) Block the destination IP at the firewall to cut the C2 channel while investigation continues. (4) Remove the autostart registry entry and reboot to confirm the PowerShell execution stops. (5) Investigate the initial access vector — review browser history and email logs for the period before the behavior first appeared to identify the exploit that delivered the initial in-memory payload.