CompTIA Security+ SY0-601: How to Identify Attack Types from Scenario Indicators
1. Introduction: How Security+ Tests Attack Identification
On CompTIA Security+ exam questions, the goal is usually not to name every attack that could fit. It is to choose the most likely attack based on the evidence given. That means reading the scenario like an analyst: identify the source of evidence, the attacker’s likely objective, and the clue that best separates one attack from its closest distractor.
For this article, the scope is Security+ SY0-601. If you’re studying for a newer version of the exam, I’d definitely double-check the current CompTIA objectives. The wording and emphasis do shift a bit over time, and that can trip people up.
A quick terminology fix that matters: Indicators of Compromise (IoCs) are artifacts associated with compromise, such as a malicious hash, domain, ransom note, suspicious process, or known bad IP address. Indicators of Attack (IoAs) are behavioral signs of attacker activity or intent, such as password spraying patterns, unusual PowerShell execution, or repeated MFA prompts. IoAs are not limited to real-time events; they can also be identified retrospectively in logs. In practice, both often appear in the same incident.
Security+ also expects you to think in terms of impact. If traffic is being intercepted, confidentiality is at risk. If records are being altered, integrity is impacted. If a service is overwhelmed or files are encrypted, availability is the issue. Authenticity may also be questioned in some scenarios, but the CIA triad remains confidentiality, integrity, and availability.
2. A Fast Analysis Framework That Works on the Exam
Use this five-step process:
- What changed? New alert, user complaint, traffic pattern, login behavior, or application error.
- Where is the evidence? In practice, I’m always asking, ‘Where’s the evidence coming from?’ It might be email, an endpoint, authentication logs, web logs, DNS, firewall data, wireless telemetry, or the SIEM.
- So, what’s the attacker really trying to pull off here? Usually it boils down to one of a few goals: steal credentials, run code, encrypt files, redirect traffic, or just flat-out disrupt service.
- What attack best fits? Pick the most specific supported answer.
- What is the first response? Contain carefully, preserve evidence, and escalate.
Worked example: Cloud identity logs show one password tried against 200 users over three hours, with a few successes and minimal lockouts. Step 1: the change is unusual login failures. Step 2: the evidence source is identity logs. Step 3: the likely goal is account access. Step 4: one password across many users points to password spraying, not brute force. Step 5: first actions include reviewing affected accounts, forcing password resets where needed, checking MFA and token activity, and preserving logs for source IP addresses, user agents, and timestamps.
3. Attack Indicators by Evidence Source
This is the fastest way to narrow answers:
| Evidence Source | Most Likely Attack Families | High-Value Clues |
|---|---|---|
| Email headers, user reports, secure email gateway | Phishing, spear phishing, whaling, BEC, smishing, vishing | Reply-To mismatch, spoofed domain, urgent payment request, fake login page |
| EDR, antivirus, host logs | Ransomware, trojan, worm, spyware, rootkit, fileless malware | Mass encryption, suspicious process tree, persistence, beaconing |
| Auth logs, VPN, IdP, cloud sign-in logs | Brute force, password spraying, credential stuffing, MFA fatigue | One user/many guesses, many users/one password, breached credentials, repeated push prompts |
| Web logs, WAF, app errors | SQL injection, XSS, CSRF, command injection, traversal, file inclusion | DB errors, script execution, unauthorized in-session actions, path manipulation |
| Firewall, IDS/IPS, packet capture, DNS | DoS/DDoS, on-path, ARP poisoning, DNS poisoning, replay | Traffic floods, certificate anomalies, wrong MAC/IP mapping, bad name resolution |
| Wireless controller, NAC, site survey | Evil twin, rogue AP, deauthentication, jamming | Duplicate SSID, unauthorized AP, repeated disconnects, RF interference |
4. Social Engineering Indicators
Phishing is broad email deception. Spear phishing is targeted. Whaling targets executives. Business email compromise (BEC) usually focuses on fraud rather than malware, such as invoice diversion, payroll changes, or urgent wire requests. Vishing uses phone calls, and smishing uses texts.
The technical clues I usually watch for are display-name tricks, lookalike domains, mismatched Reply-To addresses, SPF/DKIM/DMARC failures, shortened links, and fake login pages that are clearly built to steal credentials. A BEC scenario often lacks attachments and instead pressures finance or HR to act quickly. If the CEO “emails” accounting to change vendor payment details, BEC or whaling is a better fit than generic phishing.
Other social engineering types worth recognizing: pretexting uses a made-up role or story, baiting offers something tempting such as a free software package or dropped USB drive, quid pro quo offers a service in exchange for credentials or access, watering hole compromises a site a target group often visits, typosquatting uses a lookalike domain, and pharming redirects users to a fake site through DNS or host-resolution manipulation.
Exam tip: if the clue is “text message,” think smishing. If the clue is “phone call asking for MFA code,” think vishing. If the clue is “executive payment fraud,” think whaling or BEC.
5. Malware and host-based indicators are where the endpoint really starts telling you what happened.
Ransomware is the easy one to spot: mass file modification, strange extensions, ransom notes, deleted shadow copies, inaccessible shares, and spikes in disk activity. My first move is to isolate the host from the network. After that, I’m careful not to destroy volatile evidence unless procedure requires it, I check for affected shares and signs of lateral movement, and I preserve the logs right away.
Trojan describes disguise or delivery, not payload. A trojan may deliver a remote access tool, banker, loader, or dropper. Typical clues are a user opening a “legitimate” file followed by suspicious child processes, outbound connections, or persistence changes.
Worm means self-propagation. If multiple hosts show similar alerts quickly and network scanning or exploitation attempts spike, worm is the better answer than trojan or virus.
Spyware covertly collects information. A keylogger is often a specific spyware capability. I’d go with keylogger when the strongest clue is keystroke capture or credential theft after someone types on a shared system.
Rootkits focus on stealth and can exist in user mode, kernel mode, bootloader, firmware, or even hypervisor layers. The clues are usually hidden processes, inconsistent system views, tampered security tools, or persistence that normal tools seem to miss for no obvious reason.
Logic bombs trigger on a time, event, or condition. A scheduled deletion that occurs on a date or after an employee termination clue is a classic pattern.
High-yield host artifacts include suspicious parent-child process chains, PowerShell abuse, WMI persistence, Run keys, scheduled tasks, new services, startup folder changes, and beaconing traffic. These are often visible in EDR, Windows Event Logs, scheduled task listings, autorun locations, or command output showing active network connections.
| Malware Type | Best Clue | Common Evidence |
|---|---|---|
| Ransomware | Encryption plus extortion note | EDR, file server alerts, user reports |
| Trojan | Looks legitimate, acts malicious | Process tree, outbound traffic, persistence |
| Worm | Self-spreads rapidly | Multiple hosts, scanning, IDS/IPS |
| Spyware/Keylogger | Covert monitoring or keystroke theft | Credential theft, hooks, outbound exfiltration |
| Rootkit | Stealth and concealment | Hidden artifacts, tamper symptoms |
6. Identity and Password Attack Indicators
This is one of the most tested areas because the log patterns are distinctive.
| Attack | Pattern | Best Clue |
|---|---|---|
| Brute force | Many guesses against one account | Repeated failures for one user, sometimes followed by success |
| Dictionary attack | Common-word guesses | Only choose this if the scenario mentions wordlists or obvious common-password patterns |
| Password spraying | One/few passwords across many accounts | Many users, few attempts each, low lockout count |
| Credential stuffing | Reused breached credentials | Known leaked pairs, successful logins without much guessing |
| MFA fatigue | Repeated push notifications | User reports endless prompts until one is approved |
Cloud and SaaS scenarios may also mention impossible travel, suspicious OAuth consent grants, unusual mailbox forwarding rules, unfamiliar device registration, or token reuse. Those clues suggest account takeover or session/token abuse rather than simple password guessing.
Offline cracking is different from online login attacks. If attackers steal password hashes from a database, they may attempt rainbow table cracking against weak, unsalted hashes. Properly salted modern storage that uses PBKDF2, bcrypt, scrypt, or Argon2 makes rainbow tables a lot less practical, which is exactly what you want. Exam clue: if the prompt says “stolen unsalted hashes,” rainbow tables become a likely answer.
Exam memory anchor: one user, many passwords = brute force. Many users, one password = spraying.
7. Application Attack Indicators
SQL injection targets database queries. Clues include database errors, unexpected records returned, time-delay anomalies, suspicious input patterns, and WAF alerts. The classic string examples are recognition-only; real attacks may be obfuscated.
Cross-site scripting (XSS) runs attacker-controlled script in the victim’s browser. Stored XSS lives inside the application, reflected XSS bounces back off a request, and DOM-based XSS happens in client-side code. If the scenario points to browser-side execution, pop-ups, redirects, or a session being hijacked after someone views content, XSS is probably the best fit.
CSRF causes a logged-in user’s browser to perform an unwanted action. The user is already authenticated, the action looks legitimate to the application, and a lot of the time the app isn’t using anti-CSRF tokens or secure SameSite cookie settings. If the clue is “the transfer happened while the user was already logged in,” think CSRF.
Command injection causes the app to execute operating system commands. Clues appear in host logs, EDR, or web logs and may include shell execution, spawned command interpreters, or unusual OS-level activity.
Directory traversal tries to escape intended paths, often with path manipulation. File inclusion abuses unsafe file loading; LFI involves local files, while RFI involves remote files where the platform allows it.
| Attack | Primary Target | Best Distinguishing Clue |
|---|---|---|
| SQL injection | Database query | DB errors or unauthorized data access |
| XSS | Victim browser | Script executes when content is viewed |
| CSRF | Authenticated session | User did not intend the action |
| Command injection | Operating system | OS commands run through the app |
| Traversal/LFI/RFI | File system or file-loading logic | Path escape or unsafe include behavior |
First logs to check: WAF alerts, web server access logs, application error logs, database logs, and EDR on the application host.
8. Network, Wireless, and Session Attack Indicators
DoS usually comes from one source or a small set of sources. DDoS comes from many. SYN floods, reflection, and amplification are common examples. Look for traffic spikes, top talkers, connection exhaustion, and service degradation. Baselining matters because not every spike is malicious.
On-path attacks intercept or alter traffic. Certificate warnings can be a clue, but they are not proof by themselves; a duplicate SSID, ARP changes, rogue proxy behavior, or DNS anomalies make the case stronger.
ARP poisoning redirects local traffic by corrupting ARP mappings. On the host side, I’d check the ARP cache with a command-line tool that shows address-resolution entries, then compare the gateway’s MAC address against known-good switch data. In an enterprise, DHCP snooping and Dynamic ARP Inspection are two of the big defensive controls that help here.
DNS poisoning redirects users through bad name resolution. Compare answers from local cache, the configured resolver, and a trusted resolver using standard DNS query tools. Also consider split-brain DNS, stale cache, hosts file tampering, or misconfiguration before assuming poisoning.
Replay attacks reuse captured valid exchanges or transactions without necessarily decrypting them. The strongest defenses are nonces, timestamps, sequence numbers, and mutual authentication. Session hijacking instead uses a live session token or cookie. If the clue is “captured traffic reused later,” think replay; if the clue is “stolen active session,” think session hijacking.
MAC flooding targets a switch’s CAM table, causing increased unknown-unicast flooding and making traffic observation easier. VLAN hopping abuses switch spoofing or double-tagging to cross segmentation boundaries.
For wireless, separate these carefully: evil twin impersonates a legitimate SSID, rogue AP is unauthorized wireless hardware, deauthentication causes repeated disconnects by abusing management frames, and jamming is RF interference and may require spectrum analysis. Protected Management Frames such as 802.11w help against some deauthentication abuse.
9. Tools, Diagnostics, and False Positives
Security+ expects you to know what tool is most useful, not just what attack exists. SIEM correlates events across sources. IDS/IPS provides network attack indicators. EDR reveals host behavior and persistence. WAF highlights web attack patterns. NAC helps spot unauthorized devices. DLP shows suspicious sensitive-data movement but usually needs context to identify the exact attack.
Some of the most useful defensive checks are pretty straightforward: review raw email headers for Reply-To and authentication failures, inspect auth logs for user/IP/timestamp patterns, check scheduled tasks and services on endpoints, compare DNS resolution results, validate ARP entries, and review wireless controller logs for duplicate SSIDs or deauthentication events.
And yeah, don’t forget the false positives. Certificate warnings might just be expired certs, high CPU could be backup jobs or antivirus scans, account lockouts might come from stale service credentials, and bad DNS answers could be cache or configuration problems instead of poisoning.
10. First Response and Prevention Mapping
Preparation comes before identification in formal incident response, but once suspicious activity appears, analysis leads into containment. First response should be careful and evidence-aware.
| Attack Family | Best First Action | Key Evidence to Preserve | Important Preventive Controls |
|---|---|---|---|
| Phishing/BEC | Preserve email and block sender/domain | Raw message, headers, suspicious web addresses, affected users | SEG, SPF/DKIM/DMARC, user training, phishing-resistant MFA |
| Ransomware | Isolate host from network | Process tree, hashes, ransom note, network connections | EDR, segmentation, backups, least privilege |
| Password attacks | Review and contain affected accounts | Auth logs, source IP addresses, MFA events, tokens | MFA, smart lockout, conditional access, strong passwords |
| Web attacks | Block malicious requests and preserve logs | WAF, app, DB, and session logs | Parameterized queries, output encoding, anti-CSRF tokens, least privilege |
| ARP/DNS/on-path | Validate mappings/resolution and isolate bad infrastructure | ARP tables, DNS logs, packet captures | DAI, DHCP snooping, DNSSEC, secure Wi-Fi, certificate validation |
| Wireless attacks | Identify and contain the AP/interference source | Controller logs, site survey data, client reports | WIDS/WIPS, NAC, PMF, AP hardening |
11. Security+ Exam Traps and Practice
Common distractors: evil twin vs rogue AP, brute force vs spraying, XSS vs CSRF, worm vs trojan, DoS vs DDoS, replay vs session hijacking, phishing vs BEC.
30-second exam method: identify evidence source, identify attacker objective, eliminate the closest wrong answer, choose the best fit.
Scenario 1: Finance receives an urgent email from the “CEO” requesting a wire transfer to a new vendor account. No attachment is included, but the Reply-To domain is external and fails DMARC. Best answer: BEC/whaling. Why not generic phishing? The fraud objective and executive impersonation are more specific.
Scenario 2: EDR shows a user opened an invoice PDF, then powershell.exe spawned, a scheduled task was created, and the host began beaconing to an external IP address. Best answer: Trojan malware infection. Why not worm? The evidence supports disguised delivery, not self-propagation.
Scenario 3: Users on guest Wi-Fi see certificate warnings for the company portal. A site survey shows two APs advertising the same SSID, with the stronger one near the lobby entrance. Best answer: Evil twin. Why not rogue AP? The impersonation clue is more specific than mere unauthorized hardware.
12. Conclusion
The best way to answer Security+ attack-identification questions is to think like a triage analyst: match the evidence source to the attacker objective, then choose the most specific supported attack. Email clues point toward phishing and BEC. Endpoint telemetry points toward malware and persistence. Authentication logs reveal password attacks and account takeover. Web logs expose injection and session abuse. Network and wireless evidence reveal interception, disruption, and redirection.
If you remember only a few things, remember these: many users and one password means spraying; one user and many passwords means brute force. Duplicate SSID means evil twin; unauthorized AP without impersonation means rogue AP. Browser runs script means XSS; browser sends an unwanted valid request means CSRF. And if files are encrypted and a ransom note appears, do not overthink it: that is ransomware.