Malware identification questions on the Security+ exam give you a scenario describing malicious software behaviour and ask you to identify the malware type. Each type has a defining characteristic — knowing that one detail lets you eliminate all wrong answers quickly.
Virus
A virus attaches itself to a legitimate file or program and requires user action to spread — running an infected executable, opening a malicious document. The key characteristic: a virus cannot spread by itself; it needs a host file and a user to execute it.
Worm
A worm spreads autonomously across networks without requiring user action or a host file. It exploits vulnerabilities in network services to copy itself to other systems. WannaCry is a famous example — it spread via a Windows SMB vulnerability with no user interaction required.
Exam trap: both viruses and worms can cause damage and spread, but the distinguishing factor is whether user action is required. "Spreads across the network without user interaction" = worm.
Trojan
A Trojan (Trojan horse) disguises itself as legitimate software. The user installs it thinking it is a useful application, but it performs malicious actions in the background. Trojans do not self-replicate.
A Remote Access Trojan (RAT) specifically provides the attacker with remote control of the infected system — often used for persistent access and lateral movement.
Ransomware
Ransomware encrypts the victim's files and demands payment in exchange for the decryption key. The defining characteristics:
- Files become inaccessible (encrypted)
- A ransom demand appears
- Payment is requested in cryptocurrency
Any scenario describing encrypted files and a ransom demand is ransomware.
Rootkit
A rootkit hides itself and other malware by modifying the operating system at a deep level (often kernel-level). The defining characteristic is concealment — a rootkit makes other malicious processes invisible to standard security tools.
Detecting a rootkit requires booting from a trusted external medium and scanning the disk without letting the compromised OS run first.
Exam scenario: "A security tool consistently reports no malware even though symptoms suggest infection. Which type of malware is most likely responsible?" — Rootkit, because it hides itself from security tools.
Spyware and Keylogger
Spyware — Collects information about the user (browsing habits, credentials, personal data) without their knowledge and sends it to the attacker.
Keylogger — Records keystrokes. A specific type of spyware that captures everything typed, including usernames and passwords.
"An attacker is capturing the victim's login credentials by recording what they type" — Keylogger.
Adware
Adware displays unwanted advertisements. It is the least malicious malware type — usually not destructive, but invasive. It may also track browsing behaviour.
Fileless Malware
Fileless malware operates entirely in memory, using legitimate system tools (like PowerShell or WMI) to execute malicious code without writing files to disk. Because it leaves no files, traditional signature-based antivirus often misses it.
"Antivirus found no suspicious files, but the system is exhibiting malicious behaviour; memory forensics revealed the attack" — Fileless malware.
Command and Control (C2) Callbacks
Many malware types establish a C2 (command and control) channel — a connection back to the attacker's server. This allows the attacker to issue commands, exfiltrate data, or update the malware.
An exam scenario describing outbound network connections from a system to an unknown external IP, especially over unusual ports, typically indicates malware making C2 callbacks. The tool to detect this is a SIEM correlating firewall and DNS logs.
How to Identify the Type on the Exam
- Does it encrypt files and demand payment? → Ransomware
- Does it spread autonomously across networks? → Worm
- Does it disguise itself as legitimate software? → Trojan
- Does it hide other malware from detection? → Rootkit
- Does it record keystrokes? → Keylogger
- Does it give remote control to the attacker? → RAT
- Does it need a host file and user action to spread? → Virus
Practice Security+ malware identification questions to build quick recognition of these scenarios.
Rootkit Deep Dive — Why It's the Hardest to Detect
A rootkit's defining characteristic is not what damage it does — it is what it hides. A rootkit modifies the operating system to conceal itself and other malware from standard detection tools.
Why standard tools fail: Antivirus software that runs on the infected OS uses the OS's own APIs to list processes and files. A kernel-level rootkit intercepts those API calls and removes its own entries from the results. The antivirus asks "show me running processes," the rootkit intercepts the answer and removes itself from the list. The antivirus sees a clean list and reports no infection.
Detection methods:
- Integrity checking: Tools like Tripwire compare current file hashes against a known-good baseline. A rootkit that modifies system files will show altered hashes — unless the rootkit also intercepts the hash function.
- Out-of-band scanning: Boot from trusted external media (a live USB with known-clean OS). The rootkit on the infected drive cannot intercept API calls when the infected OS is not running. Scan the disk from outside the infected OS.
- Behaviour analysis: Even if a rootkit hides from file and process listings, it produces network traffic (C2 callbacks), causes performance changes, and may exhibit other detectable behaviours. Network monitoring and memory forensics can reveal activity that file-based tools miss.
- Memory forensics: Tools like Volatility analyse raw memory dumps. A rootkit hiding from the OS process list still occupies physical memory — direct memory analysis can find what the OS is hiding.
Exam scenario: "A security tool reports no malware on a system, but users report performance problems and unusual network activity." This is the rootkit scenario. The correct follow-up action involves out-of-band scanning or memory forensics — not running another antivirus scan on the live OS.
Fileless Malware — The Exam's Favourite Modern Threat
Fileless malware is one of the most heavily tested modern threat topics on SY0-701 because it represents the failure of traditional file-based detection.
The core concept: Fileless malware executes entirely in memory using legitimate system tools. It writes nothing to disk. Traditional antivirus scans for malicious files — if there are no files, it finds nothing.
LOLBins (Living Off the Land Binaries): Legitimate Windows binaries used maliciously. PowerShell, WMI (Windows Management Instrumentation), regsvr32, mshta, certutil — all are legitimate tools that can execute arbitrary code. Attackers use them because they are trusted, signed Microsoft executables.
Specific fileless techniques:
- PowerShell abuse: A malicious PowerShell command is base64-encoded and executed from a macro, phishing link, or existing access. The command downloads and executes shellcode directly in memory. PowerShell logs (Get-Content of the PowerShell event log) show the activity even if no file was written to disk.
- Registry-resident malware: Malicious code stored in a registry key, executed by a scheduled task or autorun entry. The "file" is in the registry, not the filesystem, so traditional file scans miss it.
- Process injection: Malicious code injected into the memory space of a legitimate running process (svchost.exe, explorer.exe). The malicious code runs under the legitimate process's identity and inherits its privileges.
Detection: EDR tools with memory scanning and behaviour monitoring, PowerShell script block logging, Sysmon event logging (process creation, network connections, registry modifications), and SIEM correlation.
Exam pattern: "Antivirus reports no threats, but memory forensics revealed malicious code running under a legitimate Windows process." = fileless malware. "An attacker gained code execution using PowerShell without dropping any files." = fileless/LOLBin attack.
Ransomware Response Checklist
The exam may describe a ransomware scenario and ask what to do. Order matters.
Step 1 — Isolate immediately. Disconnect the infected system from the network. Pull the cable or disable the wireless adapter. Ransomware spreads. Every second it has network access, it can encrypt more shares and infect more systems.
Step 2 — Assess scope. Identify which systems are encrypted. Check network shares. Look for the ransom note — it often identifies the ransomware family, which tells you if decryptors exist.
Step 3 — Do not pay the ransom. Law enforcement universally recommends against paying. Payment does not guarantee you get a working decryption key. It funds the attacker's next campaign. It may also violate OFAC regulations if the ransomware group is on a sanctions list.
Step 4 — Check for free decryptors. NoMoreRansom.org maintains a database of decryptors for known ransomware families. Some ransomware variants have had their encryption broken — check before paying or reimaging.
Step 5 — Restore from known-good backup. The actual answer to ransomware is backups. Verify the backup is not also encrypted (ransomware sometimes sleeps for days before triggering, to infect backup files). The backup predating the infection is the recovery point.
Step 6 — Investigate the initial access vector. Before reconnecting any system, determine how the attacker got in. Phishing email? Unpatched vulnerability? RDP exposed to the internet? Close the initial access vector before restoring — otherwise you restore clean systems into a compromised environment and get infected again.
What NOT to do: Do not run antivirus hoping to clean an actively encrypted system. Do not attempt to decrypt while the ransomware process is still running. Do not reboot into Safe Mode hoping to stop it — modern ransomware is designed to handle Safe Mode.
Malware Analysis — Static vs Dynamic
Static analysis: Examining the malware without executing it. Running strings to find readable text (URLs, registry keys, error messages), checking imports (which Windows APIs does it call?), disassembling or decompiling the binary. Safe — the malware is never executed. Limited — obfuscated malware may reveal little without execution.
Dynamic analysis: Executing the malware in a controlled environment (a sandbox) and observing its behaviour. What processes does it create? What files does it write? What network connections does it make? What registry keys does it modify? Risky if the sandbox is not properly isolated — some malware detects sandboxes and behaves differently.
Sandboxing: Automated dynamic analysis platforms (Cuckoo Sandbox, Any.run, Hybrid Analysis) run submitted malware samples and report on their behaviour. The exam tests sandboxing as a malware analysis technique, not just as a security control.
Exam scenario: "A security analyst receives a suspicious executable. Before executing it, the analyst examines the strings and imported functions." = static analysis. "A malware sample is submitted to an isolated virtual environment that records its behaviour." = dynamic analysis / sandboxing.
Botnet and C2 Infrastructure
Botnet: A network of compromised devices (bots or zombies) controlled by an attacker. Individual bots phone home to the Command and Control (C2) server to receive instructions and report data.
C2 communication patterns: Regular beaconing — the bot makes outbound connections at regular intervals to check for commands. Beaconing is detectable via SIEM correlation (regular outbound connections to a single external IP at consistent intervals). Attackers use domain generation algorithms (DGA) to constantly change C2 domains, making blocklists less effective.
Botnet uses: DDoS attacks (traffic floods), spam campaigns, cryptocurrency mining, credential stuffing attacks, ransomware distribution.
Exam question pattern: "A SIEM alert fires on traffic from 500 internal endpoints making connections to the same external IP address at 30-second intervals." This describes botnet C2 beaconing. The correct response: isolate the affected systems, block the C2 IP/domain at the firewall, investigate how the bots were installed.
Logic Bomb vs Time Bomb
Logic bomb: Malicious code that executes when a specific condition is met. "If the database no longer contains my employee record (i.e., I've been fired), delete the production database." Logic bombs are planted by insiders with system access and are a classic disgruntled employee threat.
Time bomb: A specific type of logic bomb where the trigger is a date and time condition. "Execute on January 1st." The infamous Michelangelo virus was a time bomb set to trigger on March 6.
Exam distinction: Logic bomb = condition-based trigger (can be anything). Time bomb = time-based trigger. All time bombs are logic bombs; not all logic bombs are time bombs. When the exam describes "malicious code that executes after a specific date," the most precise answer is time bomb. When the trigger is anything other than time, it's a logic bomb.