CompTIA Security+ SY0-601: How to Analyze Indicators and Identify the Type of Attack

Introduction: How Security+ Tests Attack Recognition

This guide is written for CompTIA Security+ SY0-601. SY0-601 has been retired in CompTIA’s current track, but if that is the version you are studying, the skill is still the same: read the clues, identify the likely attack, rule out the closest distractor, and choose the safest first response.

That is exactly how real incidents look. You usually don’t get a neat label handed to you at the start. You start with a user report, an EDR alert, failed sign-ins, a suspicious DNS query, or a web log full of malformed input. From there, you classify what is happening.

For this objective, tighten two terms early. Indicators of Compromise (IoCs) are observable artifacts associated with known or suspected compromise: bad hashes, malicious domains, ransom notes, altered registry keys, or a suspicious scheduled task. Indicators of Attack (IoAs) are behavioral patterns that reveal attacker activity or tradecraft in progress: password spraying, encoded PowerShell, unusual service ticket requests, or repeated deauthentication frames on Wi-Fi. Either can appear before, during, or after detection depending on your tools.

Also keep the full incident response lifecycle straight: preparation, identification, containment, eradication, recovery, and lessons learned. On the exam, you usually enter at identification, but the best answer often depends on what preserves evidence while reducing risk.

A Simple 5-Step Attack Analysis Framework

Use this under pressure:

1. Identify the symptom. What changed: failed logins, browser redirects, file encryption, Wi-Fi drops, or suspicious email?

2. Find the best evidence source. Email headers, AD or cloud sign-in logs, DNS, proxy, firewall, EDR, web logs, wireless controller logs, and SIEM correlation all tell different parts of the story.

3. Match the pattern. Is this social engineering, malware, network abuse, web exploitation, credential abuse, or wireless/mobile?

4. Rule out the nearest lookalike. Password spraying is not brute force. Evil twin is not just rogue AP. CSRF is not XSS.

5. Choose the safest first response. That might be isolating a host, revoking sessions, resetting credentials, preserving volatile evidence, or escalating to the right team. On exam questions, “best first action” matters as much as attack identification.

The exam loves attacks that start with human trust. The clues are usually urgency, authority, curiosity, fear, or a request that bypasses normal process.

Phishing is broad and generic. Spear phishing is targeted and personalized. Whaling is spear phishing aimed at executives or other high-value roles. Vishing uses voice, and smishing uses SMS or messaging apps. Business email compromise (BEC) usually involves impersonating a trusted executive, vendor, or finance contact to redirect payments or request sensitive data without necessarily delivering malware.

High-yield indicators include lookalike domains, mismatched display name and sender address, urgent payment requests, unusual attachment types, QR-code lures, reply-to mismatches, and language that pressures the user to ignore process. Typosquatting and brand impersonation often show up as domains that differ by one character or a swapped top-level domain.

What to inspect: sender, return-path, reply-to, SPF/DKIM/DMARC results, embedded addresses, attachment type, and whether the message came from a newly registered or low-reputation domain. In cloud environments, also check whether the user created suspicious mailbox forwarding rules or granted malicious OAuth or app consent after clicking.

Physical and human variants include impersonation, pretexting, tailgating, shoulder surfing, dumpster diving, baiting, quid pro quo, and eliciting information. The distinction Security+ likes is simple: impersonation is the fake identity, pretexting is the story that makes it believable.

Best first response: preserve the email, do not just delete it, verify the request through an approved channel, check whether the user clicked or submitted credentials, review mailbox rules and sign-in logs, and reset credentials or revoke sessions if compromise is suspected.

Malware Indicators

Security+ usually tests malware by behavior, not by asking for a textbook definition.

Ransomware shows encryption, changed file extensions, ransom notes, and bursts of file modifications on local or shared drives. Scareware shows fake infection warnings and pressure to call or pay, but without actual encryption. Trojans masquerade as legitimate software. Viruses attach to a host file, macro-enabled document, or boot-related object and spread when that infected object is executed or accessed. Worms self-replicate without needing a host file, often exploiting network services.

Spyware collects activity or data. Keyloggers specifically capture keystrokes. Cryptominers drive sustained CPU or GPU usage, heat, fan noise, and poor performance. Logic bombs trigger on a condition such as a date, account change, or file event. Rootkits are stealth and persistence mechanisms that may operate in user mode, kernel mode, boot, or firmware layers; hidden-process symptoms are suggestive, not conclusive by themselves.

Fileless malware is especially testable. It usually keeps disk artifacts to a minimum and leans on trusted tools like PowerShell, mshta, rundll32, regsvr32, certutil, or WMI. That’s why it slips by folks who only hunt for obvious files and miss the bigger behavior pattern. It is not always literally file-free; defenders may still find script logs, registry changes, scheduled tasks, WMI subscriptions, startup entries, or command-line artifacts.

What to inspect: process trees, command-line arguments, parent-child relationships, new scheduled tasks, Run and RunOnce keys, services, startup folders, WMI persistence, browser extensions, and tamper alerts showing AV or EDR was stopped or modified. A classic suspicious tree is WINWORD.EXE -> powershell.exe -> rundll32.exe.

Best first response: isolate the host if business impact allows, preserve evidence before rebooting or wiping, capture memory if fileless activity is suspected, collect hashes and logs, and check adjacent systems for spread. For ransomware, also isolate network shares and validate backups before recovery decisions.

Network and Wireless Attack Indicators

Network attacks usually reveal themselves through traffic patterns, service disruption, or trust abuse.

DoS denies service; DDoS does it from distributed sources. You’ll usually see traffic spikes, latency, dropped sessions, and plain old service exhaustion. Blocking a single source IP may help in small cases, but large DDoS events often require upstream filtering, content delivery or application filtering protections, rate limiting, or provider assistance.

On-path is the modern term for man-in-the-middle. Look for certificate warnings, rogue gateways, SSL stripping behavior, unexpected proxies, or traffic that seems to be bouncing through a device you don’t trust. Distinguish it from replay attacks, which reuse captured authentication data, and session hijacking, which abuses a stolen session token or cookie after authentication has already occurred.

ARP poisoning is local to an IPv4 broadcast domain and manipulates IP-to-MAC mappings. If I suspect ARP poisoning, I check ARP tables, gateway MAC changes, packet captures, and switch data. MAC spoofing clones or changes a MAC address to bypass filtering or obscure identity. VLAN hopping classically uses double-tagging or switch spoofing to reach another VLAN. DHCP starvation exhausts the legitimate pool, often followed by a rogue DHCP server handing out attacker-controlled gateway or DNS settings.

DNS poisoning should be separated from lookalikes. Cache or resolver poisoning corrupts name resolution responses. Pharming can also involve hosts-file tampering or malicious local resolver changes. Domain hijacking affects the registrar or DNS hosting account itself. If the issue is resolver output, think poisoning; if ownership or DNS management changed, think hijacking.

Rogue AP means unauthorized wireless infrastructure. Evil twin means a fake lookalike SSID intended to lure users, often with captive portal credential harvesting or downgrade or open-network tricks. When I’m sorting that out, I compare the SSID and BSSID, check controller inventory, look at signal strength, verify the security mode, and pay attention to any 802.1X certificate prompts. Deauthentication/disassociation attacks abuse 802.11 management frames to kick clients off Wi-Fi repeatedly.

Wireless protections worth remembering: WPA2/WPA3-Enterprise, 802.1X, certificate validation, rogue AP detection, NAC, and protected management frames where supported.

Web, Application, and Identity Attack Indicators

SQL injection targets the database layer. Look for suspicious parameters, stray quotes, comments, tautologies, UNION-based probes, database errors, or weird query behavior in the logs. Command injection causes the server to execute OS commands; think web service spawning cmd.exe, sh, or PowerShell. Remote code execution (RCE) is broader: command injection is one path to RCE, but not the only one.

XSS injects script into browser-rendered content. Stored XSS lives in the application itself, reflected XSS bounces right back off a request, and DOM XSS is driven by client-side script behavior. CSRF abuses an already authenticated browser session to submit unauthorized actions. If the clue says a valid session performed an action the user didn’t intend, CSRF should jump to the front of your mind. Mitigations include anti-CSRF tokens and SameSite cookies, which are absolutely worth remembering for exam day. Directory traversal often shows ../ path patterns. File upload abuse may lead to web shells.

Credential attacks are all about distribution patterns. Brute force is many guesses against one account. Password spraying is one or a few common passwords across many accounts, often spaced out to avoid lockouts. Credential stuffing uses stolen username/password pairs from prior breaches across multiple services. Geolocation anomalies can support the case, but the stronger clue is usually reused breached credentials and distributed sign-in attempts. Impossible travel alerts are useful, but can be false positives because of VPNs, mobile carrier routing, or cloud egress points.

Kerberoasting is more specific: attackers request Kerberos service tickets for SPN-associated accounts and crack the TGS material offline to recover weak service account passwords. NTLM abuse should be split mentally into NTLM relay and pass-the-hash. Relay abuses challenge-response authentication without necessarily learning the plaintext password. Pass-the-hash reuses the hash itself for authentication. The Kerberos parallel is pass-the-ticket. These are different from simple password guessing.

MFA bypass is also narrower than “suspicious sign-in.” For MFA bypass, look for push fatigue, adversary-in-the-middle phishing kits, token theft, session cookie theft, SIM-swap-style abuse, or repeated approvals the user says they never initiated. Strong mitigations include number matching, conditional access, session revocation, and phishing-resistant MFA.

Privilege escalation can be vertical (user to admin) or horizontal (one peer account to another at the same privilege level). Treat it as a post-compromise technique, not just a web attack.

Where the Clues Appear: Logs, Correlation, and Validation

No single source tells the whole story. Good triage means checking the right fields and correlating timestamps.

Email: sender, reply-to, authentication results, attachment verdict, address analysis or detonation results. Identity logs: username, source IP, user agent, geography, success/failure pattern, MFA events, session revocation. Windows and AD: logon events, privilege changes, service ticket requests, group membership changes. EDR/Sysmon: parent-child process chains, command lines, registry changes, scheduled tasks, network connections. DNS/proxy: newly seen domains, low reputation, DGA-like lookups, beacon intervals, unusual user agents. Web/WAF: URI, parameters, status codes, blocked rules, backend errors. Wireless: duplicate SSIDs, BSSID mismatch, deauth events, rogue AP alerts.

Mini evidence examples:

Password spraying: many usernames, one password pattern, low-and-slow failures, few or no lockouts.

SQLi: GET /login?user=admin' OR '1'='1 followed by app or DB errors.

Suspicious scripting: Office spawning PowerShell with encoded commands.

Evil twin: same SSID, different BSSID, unexpected captive portal or certificate warning.

Beaconing: outbound connections at regular intervals to a low-reputation domain after suspicious process execution.

Many indicators are non-exclusive. One incident can involve spear phishing, malware execution, credential theft, persistence, lateral movement, and exfiltration all at once.

Lookalike Attacks Quick Matrix

Phishing vs spear phishing vs whaling: generic vs targeted vs executive target.

Brute force vs password spraying vs credential stuffing: one account/many passwords vs many accounts/one password vs stolen valid pairs reused across services.

Rogue AP vs evil twin: unauthorized AP vs fake clone of a legitimate SSID.

On-path vs replay vs session hijacking: intercepting live traffic vs reusing captured authentication data vs stealing an active session token.

SQLi vs command injection vs RCE: database manipulation vs OS command execution vs broader arbitrary code execution.

XSS vs CSRF: injected script in the browser vs unauthorized action through an already authenticated browser.

DNS poisoning vs pharming vs domain hijacking: bad resolver/cache answers vs redirection through local or DNS manipulation vs takeover of registrar/DNS management.

Troubleshooting and Safest First Response

Use this compact workflow:

1. Confirm the symptom. In other words, make sure you actually know what changed before you start guessing. What actually changed, and what’s the user or system telling you? Could this be load, misconfiguration, a legitimate admin script, or a software bug?

2. Validate with a second source. Do not trust one alert in isolation.

3. Scope the blast radius. One host, one account, one VLAN, or many?

4. Preserve evidence. Email headers, hashes, memory, logs, lease data, ARP tables, web logs, and sign-in records matter. Avoid rebooting if volatile evidence is important.

5. Contain appropriately. Isolate hosts, revoke sessions, disable accounts only according to procedure, and remember that source-IP blocking may be weak against cloud or distributed attacks.

6. Escalate to the right team. Identity, network, email, app, and endpoint teams often each hold one piece of the answer.

How to Answer Security+ Scenario Questions

Watch for CompTIA wording: user reports, logs show, administrators observe, most likely, best first action, and least disruptive. Those qualifiers are exam clues.

Keywords that often reveal the answer:

Distributed = DDoS. Many accounts, one password = password spraying. Executive target = whaling. Same SSID, fake prompt = evil twin. Valid session abused = CSRF. SPN/service ticket requests = Kerberoasting. Fake alert, call this number = scareware.

One compact case: a finance user receives a vendor invoice email from a lookalike domain. They open the attachment. EDR shows WINWORD.EXE -> powershell.exe, then a scheduled task is created. Identity logs later show successful access to a file share from an unusual host, and the firewall shows outbound connections every 60 seconds to a newly seen domain. The likely chain is spear phishing -> malware execution -> persistence -> account misuse -> C2 beaconing. Best first actions: isolate the endpoint, preserve evidence, review the account, revoke sessions or reset credentials as procedure requires, and check for spread.

Final exam reminder: Security+ usually does not require deep packet decoding, exploit development, or malware reverse engineering. It wants recognition and triage. Read the clues, pick the best fit, rule out the lookalike, and choose the safest response.