Trick 1: "Ransomware is particularly dangerous because it destroys the operating system, leaving the victim unable to use their computer at all." True or False?
FALSE — ransomware deliberately leaves the operating system fully functional.
This is the most common ransomware misconception and a reliable exam trap. Ransomware targets data files — documents, spreadsheets, images, databases — not the operating system. The OS remains running, intact, and usable. This is an intentional design decision by ransomware authors, not an oversight or limitation.
Why the OS must stay running:
The entire ransomware business model depends on the victim being able to act. If the OS were destroyed: (1) the victim could not read the ransom demand on the screen; (2) the victim could not navigate to the payment portal; (3) the victim could not transfer cryptocurrency. A non-functional computer cannot pay a ransom. So ransomware keeps the OS running while making work impossible — the victim is "running but not working."
What ransomware actually does:
Ransomware scans the file system for documents, images, spreadsheets, PDFs, databases, and other valuable file types. It encrypts each one using the attacker's public key. The encrypted files retain their location but cannot be opened. The OS, system files, and executables are left alone. A message appears (often as a desktop wallpaper change or a text file in every directory) explaining the situation and demanding payment.
Exam tip: Any answer option claiming ransomware destroys or disables the OS is wrong. Any answer that says the OS remains functional while data files are encrypted is correct. "They want you running, but not working" is the exam-relevant principle.
This is the most common ransomware misconception and a reliable exam trap. Ransomware targets data files — documents, spreadsheets, images, databases — not the operating system. The OS remains running, intact, and usable. This is an intentional design decision by ransomware authors, not an oversight or limitation.
Why the OS must stay running:
The entire ransomware business model depends on the victim being able to act. If the OS were destroyed: (1) the victim could not read the ransom demand on the screen; (2) the victim could not navigate to the payment portal; (3) the victim could not transfer cryptocurrency. A non-functional computer cannot pay a ransom. So ransomware keeps the OS running while making work impossible — the victim is "running but not working."
What ransomware actually does:
Ransomware scans the file system for documents, images, spreadsheets, PDFs, databases, and other valuable file types. It encrypts each one using the attacker's public key. The encrypted files retain their location but cannot be opened. The OS, system files, and executables are left alone. A message appears (often as a desktop wallpaper change or a text file in every directory) explaining the situation and demanding payment.
Exam tip: Any answer option claiming ransomware destroys or disables the OS is wrong. Any answer that says the OS remains functional while data files are encrypted is correct. "They want you running, but not working" is the exam-relevant principle.
Trick 2: "A drive-by download requires the user to click 'Download' or accept a file transfer prompt on the malicious web page." True or False?
FALSE — a drive-by download requires no user interaction beyond loading the page in the browser.
The defining characteristic of a drive-by download is that infection occurs automatically when a vulnerable browser loads a compromised page — no click, no download confirmation, no file to open. This distinguishes drive-by downloads from other social engineering attacks that require the victim to take an action.
How it works:
The compromised web page (or a malicious advertisement loaded by the page) contains exploit code — typically JavaScript or embedded content that targets a known vulnerability in: (1) the browser itself; (2) a browser plugin or extension (PDF reader, media player, Flash, Java); or (3) the JavaScript engine. When the browser loads the page, the exploit code runs automatically in the browser context. If the browser has the targeted vulnerability (i.e., the browser or plugin is unpatched), the exploit succeeds — it downloads and executes the malware payload in the background without any visible indication to the user.
The user might see:
Nothing at all. The page may look completely normal. The infection completes in milliseconds. The user continues reading the article they visited the page for. By the time they close the browser, malware may already be installed and communicating with an attacker's server.
What stops drive-by downloads:
Keeping the browser and all plugins fully patched eliminates the vulnerabilities the exploit code targets. If the browser has no matching unpatched vulnerability, the exploit fails and the page loads normally. This is why browser patching is specifically important — not just the OS.
Exam tip: Drive-by downloads = no user action required = stopped by browser/plugin patching. If a question describes infection that happened "just from visiting a website," the answer is drive-by download.
The defining characteristic of a drive-by download is that infection occurs automatically when a vulnerable browser loads a compromised page — no click, no download confirmation, no file to open. This distinguishes drive-by downloads from other social engineering attacks that require the victim to take an action.
How it works:
The compromised web page (or a malicious advertisement loaded by the page) contains exploit code — typically JavaScript or embedded content that targets a known vulnerability in: (1) the browser itself; (2) a browser plugin or extension (PDF reader, media player, Flash, Java); or (3) the JavaScript engine. When the browser loads the page, the exploit code runs automatically in the browser context. If the browser has the targeted vulnerability (i.e., the browser or plugin is unpatched), the exploit succeeds — it downloads and executes the malware payload in the background without any visible indication to the user.
The user might see:
Nothing at all. The page may look completely normal. The infection completes in milliseconds. The user continues reading the article they visited the page for. By the time they close the browser, malware may already be installed and communicating with an attacker's server.
What stops drive-by downloads:
Keeping the browser and all plugins fully patched eliminates the vulnerabilities the exploit code targets. If the browser has no matching unpatched vulnerability, the exploit fails and the page loads normally. This is why browser patching is specifically important — not just the OS.
Exam tip: Drive-by downloads = no user action required = stopped by browser/plugin patching. If a question describes infection that happened "just from visiting a website," the answer is drive-by download.
Trick 3: "An online cloud backup service automatically protects against ransomware, because the backup is stored separately from the infected system." True or False?
FALSE — an online or cloud backup that is connected and accessible from the infected system can itself be encrypted by ransomware.
This trick is particularly dangerous because it sounds logical: "the backup is in the cloud, not on my hard drive, so ransomware can't touch it." The problem is whether the backup location is accessible from the infected system, not whether it is local to the infected system.
How ransomware finds cloud and network backups:
Modern ransomware actively searches for backup locations. If a cloud sync folder (like OneDrive, Google Drive, or Dropbox) is mounted as a drive letter or accessible via a synced folder on the infected machine, ransomware will encrypt the files in that folder. The sync service will then faithfully upload the encrypted versions to the cloud, overwriting the clean originals. The cloud backup now contains only encrypted files. Similarly, a network backup share mapped as a drive letter is accessible to ransomware — it will encrypt files on the network share just as it encrypts local files.
What "offline" or "immutable" actually means:
An offline backup is physically disconnected from any network at the time of the attack — tape removed from the drive, external hard drive unplugged, air-gapped system. Ransomware running on the infected machine cannot reach a drive that is not connected. An immutable backup is one where the storage system itself prevents modification or deletion of written data (common in enterprise backup solutions with immutability features). Even if the backup system is network-connected, immutability prevents ransomware from overwriting the existing backup data.
Exam tip: "Cloud backup" is not the same as "offline backup." The question is whether the backup is accessible from the infected system at the time of attack. Online backups that are mounted, synced, or accessible via credentials stored on the infected machine are all reachable by ransomware. The exam answer for ransomware recovery is always offline backup or immutable backup.
This trick is particularly dangerous because it sounds logical: "the backup is in the cloud, not on my hard drive, so ransomware can't touch it." The problem is whether the backup location is accessible from the infected system, not whether it is local to the infected system.
How ransomware finds cloud and network backups:
Modern ransomware actively searches for backup locations. If a cloud sync folder (like OneDrive, Google Drive, or Dropbox) is mounted as a drive letter or accessible via a synced folder on the infected machine, ransomware will encrypt the files in that folder. The sync service will then faithfully upload the encrypted versions to the cloud, overwriting the clean originals. The cloud backup now contains only encrypted files. Similarly, a network backup share mapped as a drive letter is accessible to ransomware — it will encrypt files on the network share just as it encrypts local files.
What "offline" or "immutable" actually means:
An offline backup is physically disconnected from any network at the time of the attack — tape removed from the drive, external hard drive unplugged, air-gapped system. Ransomware running on the infected machine cannot reach a drive that is not connected. An immutable backup is one where the storage system itself prevents modification or deletion of written data (common in enterprise backup solutions with immutability features). Even if the backup system is network-connected, immutability prevents ransomware from overwriting the existing backup data.
Exam tip: "Cloud backup" is not the same as "offline backup." The question is whether the backup is accessible from the infected system at the time of attack. Online backups that are mounted, synced, or accessible via credentials stored on the infected machine are all reachable by ransomware. The exam answer for ransomware recovery is always offline backup or immutable backup.
Trick 4: "When an antivirus scan comes back clean, it confirms the system has no malware infection." True or False?
FALSE — a clean antivirus result means only that no known malware signatures were matched. It does not confirm the absence of infection.
This is an important nuance with significant exam implications. Antivirus (AV) uses signature-based detection: it compares files and processes against a database of known malware patterns. A clean result means nothing in that database matched — it does not mean no malware is present.
Three scenarios where AV shows clean despite infection:
(1) Zero-day malware — a never-before-seen exploit or malware variant has no signature. AV has nothing to match against. Clean result, active infection. (2) Out-of-date signatures — a malware variant released after the last signature update will not match any known pattern. Signatures that are days old may miss variants released in the interim. (3) Rootkit concealment — a rootkit actively hides malware from the OS and security tools. The AV engine may be unable to see the malware files or processes at all, because the rootkit intercepts the OS calls the AV uses to scan. Clean result — because the rootkit removed the files from the AV's view.
What clean AV actually tells you:
No currently known, unobfuscated malware was detected. This is useful information but not a security clearance. When behavioral indicators suggest infection (unusual outbound connections, unexpected processes, unexplained file changes), a clean AV result should increase suspicion that something is deliberately evading detection — not reduce it.
Exam tip: "Antivirus returned clean" combined with behavioral anomalies in a question scenario is a strong indicator of zero-day malware or rootkit concealment. Do not treat a clean AV result as the end of an investigation.
This is an important nuance with significant exam implications. Antivirus (AV) uses signature-based detection: it compares files and processes against a database of known malware patterns. A clean result means nothing in that database matched — it does not mean no malware is present.
Three scenarios where AV shows clean despite infection:
(1) Zero-day malware — a never-before-seen exploit or malware variant has no signature. AV has nothing to match against. Clean result, active infection. (2) Out-of-date signatures — a malware variant released after the last signature update will not match any known pattern. Signatures that are days old may miss variants released in the interim. (3) Rootkit concealment — a rootkit actively hides malware from the OS and security tools. The AV engine may be unable to see the malware files or processes at all, because the rootkit intercepts the OS calls the AV uses to scan. Clean result — because the rootkit removed the files from the AV's view.
What clean AV actually tells you:
No currently known, unobfuscated malware was detected. This is useful information but not a security clearance. When behavioral indicators suggest infection (unusual outbound connections, unexpected processes, unexplained file changes), a clean AV result should increase suspicion that something is deliberately evading detection — not reduce it.
Exam tip: "Antivirus returned clean" combined with behavioral anomalies in a question scenario is a strong indicator of zero-day malware or rootkit concealment. Do not treat a clean AV result as the end of an investigation.
Performance Task: You are a security analyst at a mid-sized financial services firm. On Monday morning, the help desk receives multiple calls: employees in the accounting department cannot open their Excel spreadsheets or Word documents. The files are present but have a ".enc" extension appended and will not open. A text file on each desktop reads: "Your files have been encrypted. Send 2 Bitcoin to [wallet address] within 48 hours to receive the decryption key." Investigation reveals the infection started Friday evening after an accounting staff member visited a website while working late. The workstation was running an unpatched browser version. Describe your complete incident response: immediate containment, scope determination, recovery path, and what longer-term controls you implement to prevent recurrence.
Model Answer:
Phase 1 — Immediate Containment:
(1) Isolate all affected systems immediately — disconnect accounting workstations from the network at the switch level. Do not simply disable network adapters via the OS (malware with OS-level access may be able to re-enable them). Physical disconnection or VLAN isolation ensures the ransomware cannot spread to additional shares or systems. (2) Identify and block the infection source — pull the DNS/proxy logs for the accounting staff member's workstation for Friday evening. Identify the website visited immediately before the anomalous behavior began. Block that domain and IP at the perimeter firewall to prevent other users from visiting the same compromised site. (3) Preserve the infected systems as-is — do not immediately wipe or remediate. The systems contain forensic evidence: the ransomware binary, execution logs, network connection logs, the encrypted files. Take memory images and disk images before any remediation for forensic preservation and potential law enforcement involvement.
Phase 2 — Scope Determination:
(1) Identify the delivery vector — confirm this was a drive-by download via the unpatched browser. Review browser version against known CVEs to identify which specific vulnerability was exploited. (2) Scan for lateral spread — query EDR or SIEM for the same ransomware indicators (the ".enc" extension change, the ransom note filename, the ransomware process name) across all other endpoints. Determine whether the ransomware spread beyond the initial accounting workstations. (3) Check all network shares — accounting workstations likely had mapped drives to file servers. Review whether any server-side files were also encrypted. (4) Determine whether data was exfiltrated before encryption — sophisticated ransomware groups exfiltrate data before encrypting it (double extortion). Review outbound network logs for the Friday evening window for unusual data transfers to external IPs. If exfiltration occurred, breach notification obligations may apply.
Phase 3 — Recovery Path:
(1) Identify the most recent clean backup — determine when the last backup of the accounting file share was taken and confirm it pre-dates Friday evening. Verify the backup is on offline or immutable storage and has not itself been encrypted. (2) Wipe and rebuild the affected workstations — do not attempt to decrypt in place. Format and reinstall the OS from a known clean image. Restore user data from the backup. (3) If no offline backup exists — assess whether to pay the ransom. Paying does not guarantee receipt of a working decryption key, may violate sanctions if the attackers are on a designated entity list, and marks the organization as a paying target. Engage law enforcement (FBI) and a forensic firm before paying. Check whether a free decryptor exists for this ransomware strain. (4) Verify restored data integrity — after restoration, confirm the restored files match expectations and are not themselves compromised.
Phase 4 — Longer-Term Controls:
(1) Emergency browser patching — immediately push the latest browser update to all endpoints. The unpatched browser version that enabled the drive-by download must be closed organization-wide. (2) Establish offline backup policy — implement a backup regime that includes regular offline or immutable backups. The backup frequency determines the maximum data loss window (RPO). Accounting data should be backed up at least daily; hourly incremental backups should be considered for high-value data. (3) Deploy EDR with behavioral monitoring — signature-based antivirus alone is insufficient. EDR monitors process behavior (mass file modifications consistent with encryption, unusual outbound connections) and can detect ransomware activity even for new variants without signatures. (4) Implement application whitelisting or browser hardening — restrict browsers from executing downloaded files without explicit user confirmation; consider blocking JavaScript from untrusted sites. (5) Review patch management cadence — the browser was unpatched on Friday. Establish a policy requiring browsers and browser plugins to be patched within a defined window (e.g., 72 hours of a critical patch release). (6) Conduct security awareness training — while this incident did not require a user to click (drive-by download), awareness training reinforces the value of reporting anomalous behavior immediately, which shortens the detection-to-containment window.
Phase 1 — Immediate Containment:
(1) Isolate all affected systems immediately — disconnect accounting workstations from the network at the switch level. Do not simply disable network adapters via the OS (malware with OS-level access may be able to re-enable them). Physical disconnection or VLAN isolation ensures the ransomware cannot spread to additional shares or systems. (2) Identify and block the infection source — pull the DNS/proxy logs for the accounting staff member's workstation for Friday evening. Identify the website visited immediately before the anomalous behavior began. Block that domain and IP at the perimeter firewall to prevent other users from visiting the same compromised site. (3) Preserve the infected systems as-is — do not immediately wipe or remediate. The systems contain forensic evidence: the ransomware binary, execution logs, network connection logs, the encrypted files. Take memory images and disk images before any remediation for forensic preservation and potential law enforcement involvement.
Phase 2 — Scope Determination:
(1) Identify the delivery vector — confirm this was a drive-by download via the unpatched browser. Review browser version against known CVEs to identify which specific vulnerability was exploited. (2) Scan for lateral spread — query EDR or SIEM for the same ransomware indicators (the ".enc" extension change, the ransom note filename, the ransomware process name) across all other endpoints. Determine whether the ransomware spread beyond the initial accounting workstations. (3) Check all network shares — accounting workstations likely had mapped drives to file servers. Review whether any server-side files were also encrypted. (4) Determine whether data was exfiltrated before encryption — sophisticated ransomware groups exfiltrate data before encrypting it (double extortion). Review outbound network logs for the Friday evening window for unusual data transfers to external IPs. If exfiltration occurred, breach notification obligations may apply.
Phase 3 — Recovery Path:
(1) Identify the most recent clean backup — determine when the last backup of the accounting file share was taken and confirm it pre-dates Friday evening. Verify the backup is on offline or immutable storage and has not itself been encrypted. (2) Wipe and rebuild the affected workstations — do not attempt to decrypt in place. Format and reinstall the OS from a known clean image. Restore user data from the backup. (3) If no offline backup exists — assess whether to pay the ransom. Paying does not guarantee receipt of a working decryption key, may violate sanctions if the attackers are on a designated entity list, and marks the organization as a paying target. Engage law enforcement (FBI) and a forensic firm before paying. Check whether a free decryptor exists for this ransomware strain. (4) Verify restored data integrity — after restoration, confirm the restored files match expectations and are not themselves compromised.
Phase 4 — Longer-Term Controls:
(1) Emergency browser patching — immediately push the latest browser update to all endpoints. The unpatched browser version that enabled the drive-by download must be closed organization-wide. (2) Establish offline backup policy — implement a backup regime that includes regular offline or immutable backups. The backup frequency determines the maximum data loss window (RPO). Accounting data should be backed up at least daily; hourly incremental backups should be considered for high-value data. (3) Deploy EDR with behavioral monitoring — signature-based antivirus alone is insufficient. EDR monitors process behavior (mass file modifications consistent with encryption, unusual outbound connections) and can detect ransomware activity even for new variants without signatures. (4) Implement application whitelisting or browser hardening — restrict browsers from executing downloaded files without explicit user confirmation; consider blocking JavaScript from untrusted sites. (5) Review patch management cadence — the browser was unpatched on Friday. Establish a policy requiring browsers and browser plugins to be patched within a defined window (e.g., 72 hours of a critical patch release). (6) Conduct security awareness training — while this incident did not require a user to click (drive-by download), awareness training reinforces the value of reporting anomalous behavior immediately, which shortens the detection-to-containment window.