CompTIA Security+ SY0-601: How to Analyze Indicators Associated with Network Attacks

Introduction

This objective is really about pattern recognition. In a real environment, nobody walks up and says, “Hey, this is a SYN flood,” or “Yep, that’s ARP spoofing.” You usually have to piece it together from the evidence in front of you. What you usually get are clues, not clean answers. Maybe failed logins suddenly spike, users start seeing certificate warnings, DNS starts pointing them at the wrong IP, the switch is grumbling about MAC flapping, or a web app gets sluggish under traffic that just feels... off. Your job on Security+ is to match those clues to the most likely attack and choose the best way to confirm it.

I’m writing this with the CompTIA Security+ SY0-601 objective in mind, but honestly, the same analysis skill carries over nicely to SY0-701 too. The exam may have changed, but the way you think through the problem really hasn’t. Honestly, the big thing to remember is pretty simple: don’t latch onto one symptom and sprint to a conclusion. Instead, line up the symptom with the right logs, the protocol behavior you’d expect, and what’s normal for that environment.

A few basics first: indicators, baselines, and symptoms

Start with three distinctions:

• Indicator of attack (IoA): behavior suggesting malicious activity, such as one source touching many ports, repeated SYNs without completed handshakes, or one password attempted across many accounts.
• Indicator of compromise (IoC): an artifact associated with confirmed or likely malicious activity, such as an endpoint contacting a known malicious domain, a rogue DHCP server confirmed on a switch port, or browser/endpoint evidence of redirection to a known phishing host.
• Symptom: what the user or system experiences, such as slowness, disconnects, certificate warnings, or failed logins. A symptom isn’t the same thing as an attack name, and that distinction matters a lot.

Also, some telemetry gives you indicators, not proof. Take NetFlow, sFlow, and IPFIX, for example. They usually give you metadata like source, destination, port, byte counts, and timing. That’s absolutely useful for spotting scanning, DDoS patterns, or beaconing, but it won’t give you payload-level confirmation on its own.

Baselines are a big deal because “unusual” only means anything if you actually know what normal looks like. Scheduled vulnerability scans, EDR check-ins, patching jobs, backups, cloud sync, and load balancer health checks can all look suspicious if you don’t have context. I’ve seen junior analysts chase their tails over perfectly legitimate maintenance traffic more than once. In practice, I’d build baselines around authentication volume, DNS request patterns, expected ports, normal external destinations, bandwidth by time of day, and known maintenance windows.

A good exam habit is this: This suggests X; I would confirm with Y.

Protocol quick primers for exam scenarios

TCP: normal TCP uses a three-way handshake: SYN, SYN-ACK, ACK. If you see lots of SYNs with very few completed handshakes, or a bunch of RST-heavy behavior during some scan types, that’s when your antenna should go up.

ARP: ARP maps an IPv4 address to a MAC address on the local LAN/VLAN. What usually looks wrong is unsolicited ARP replies, the gateway IP suddenly mapping to a different MAC, or ARP entries changing over and over when they really shouldn’t. On its own, ARP spoofing stays local to the broadcast domain unless the attacker uses it as part of something bigger.

DHCP: DHCP commonly follows DORA: Discover, Offer, Request, Acknowledge. If you see DHCP OFFER or ACK messages coming from an unauthorized device, clients getting the wrong default gateway or DNS server, or the address pool drying up because of DHCP starvation, that’s not normal.

DNS: recursive resolvers ask questions on behalf of clients; authoritative servers provide the official answers for a zone. If the answers are wrong, the resolver changes unexpectedly, subdomains look random or high-entropy, TXT records are being used in weird ways, or you’re seeing lots of NXDOMAIN responses, that’s worth a closer look.

802.11 Wi-Fi: clients associate to an AP identified by a BSSID under an SSID. What looks abnormal is repeated deauthentication frames, users joining a lookalike SSID, or a sudden BSSID or channel change that doesn’t fit the managed wireless environment.

Where to look for evidence

That’s just how the job works — you pivot from one clue to the next. If a user reports a fake website, for example, I’d check the DNS answers first, then look at proxy logs, and then dig into endpoint browser artifacts. If a switch starts reporting MAC flapping, I’d look at the MAC address table, port security logs, and whether a failover event happened. If a VPN alert shows a bunch of failures, I’d compare account distribution and source IP behavior in the SIEM before I called it anything specific.

High-yield network attacks and their indicators

Reconnaissance and scanning

Common indicators include one source touching many hosts, many ports on one host, sequential probes, many denied connections, or ICMP sweep behavior. For exam recognition, know these patterns:

• SYN scan: half-open behavior; SYN sent, response observed, connection not fully completed.
• TCP connect scan: full connection attempts; noisier in logs.
• UDP scan: no handshake; often inferred from ICMP unreachable responses or silent ports.
• FIN/NULL/Xmas scans: stealthier probes using unusual flag combinations; often generate odd RST patterns depending on the target OS.
• Ping/ICMP sweep: one source testing many hosts for reachability.

Confirm with: firewall logs, IDS, NetFlow, and packet capture. A simple SIEM rule might be something like one source contacting more than 50 hosts or more than 100 ports in five minutes.

Common distractor: authorized vulnerability scanners or asset discovery tools. Dual-use tools create a ton of false positives if you don’t know they’re running.

First response: verify authorization, then rate-limit or block if unauthorized and policy allows.

DoS and DDoS

DoS affects availability; DDoS does it from many distributed sources. But here’s the catch: lots of source IPs alone don’t automatically prove DDoS, because NAT, proxies, content delivery networks, and bot infrastructure can make traffic look more distributed than it really is.

Main categories:

• State exhaustion/protocol attacks: SYN floods create many half-open sessions.
• Volumetric floods: UDP or ICMP floods consume bandwidth.
• Amplification/reflection: DNS or NTP amplification sends small requests that trigger large responses toward the victim.
• Application-layer floods: HTTP GET/POST floods exhaust web or app resources even if bandwidth is not extreme.

Indicators: bandwidth spikes, queue buildup, high CPU, session table exhaustion, many repeated requests to one service, or a web tier slowing while network bandwidth looks normal in an HTTP flood.

Confirm with: firewall/load balancer/WAF logs, NetFlow, and packet capture. Example packet clue for a SYN flood: tcpdump -nn 'tcp[tcpflags] & tcp-syn != 0'.

Common distractor: a legitimate traffic surge, health checks, or a product launch. If the handshakes are completing and the application still behaves normally, don’t jump straight to SYN flood.

Controls: SYN cookies, rate limiting, upstream traffic scrubbing, WAF support, and autoscaling where applicable.

ARP spoofing / ARP poisoning

ARP spoofing poisons local IP-to-MAC mappings so traffic goes to the attacker. The classic clue is when the default gateway IP suddenly resolves to the wrong MAC address.

Indicators: changing ARP entries, unsolicited ARP replies, intermittent connectivity, or signs of on-path interception.

Confirm with: arp -a, ip neigh, show arp, and packet capture. What you’re really looking for is repeated ARP replies claiming the gateway IP from the wrong MAC.

Common distractor: legitimate failover such as HSRP/VRRP, clustering, or gateway replacement. Always verify that before you escalate it.

Controls: Dynamic ARP Inspection (DAI), which commonly depends on DHCP snooping, plus segmentation. Static ARP can help in a few tightly controlled cases, but it doesn’t scale well and I definitely wouldn’t treat it as a general fix.

DNS poisoning, hijacking, and tunneling

Keep these separate:

• DNS cache poisoning: false data inserted into a resolver cache.
• DNS hijacking: clients or traffic redirected to the wrong resolver or path.
• Domain hijacking: control of the domain registration or DNS zone is compromised.

Indicators: wrong DNS answers, redirects, browser certificate warnings, unauthorized resolver changes, or suspicious DNS queries such as long high-entropy subdomains, unusual TXT usage, repeated NXDOMAINs, or periodic DNS check-ins.

Unusual TTL values by themselves are only a weak clue. Split-horizon DNS can also legitimately return different answers, so you’ve got to be careful there.

Confirm with: compare recursive and authoritative answers using commands like nslookup example.com, querying a trusted public resolver for comparison, and dig +trace example.com. If tunneling is on the table, review query length distribution, entropy, TXT records, and whether one host keeps querying a rare domain over and over.

Common distractor: resolver outage, stale cache, split-horizon DNS, or a captive portal. If DNS just fails outright, that’s not the same thing as poisoning.

Controls: secure resolver settings, DNS logging, protective DNS, egress filtering, DNSSEC awareness, and change monitoring.

On-path attacks and certificate-related clues

An on-path attack places the attacker between parties to observe or alter traffic. ARP spoofing, evil twin wireless setups, and DNS hijacking can all be used to get an attacker into that position. For Security+, classic SSL stripping is still worth knowing, but it’s a lot less effective against properly hardened sites that use HTTPS everywhere and HSTS.

Indicators: certificate warnings, hostname mismatch, unexpected redirects, HTTP where HTTPS is expected, or suspicious session behavior.

Confirm with: DNS checks, ARP validation, proxy logs, certificate chain review, and wireless association details.

Common distractor: enterprise TLS inspection appliances, expired certificates, untrusted private PKI roots, or captive portals. On managed corporate devices, legitimate inspection proxies can also cause certificate substitution, so that trust path has to be configured correctly.

Credential attacks on the network

This is one of the highest-yield distinctions on the exam:

• Brute force: many passwords against one account.
• Password spraying: one or a few passwords against many accounts.
• Credential stuffing: reused username/password pairs from prior breaches; often produces at least some successful logins if passwords were reused.

Indicators: repeated failures, account distribution patterns, source IP reuse, MFA prompts, and occasional successes in stuffing scenarios. Impossible travel can support the story, but it’s more of an identity analytic than a pure network indicator, and VPNs or mobile networks can muddy it.

Confirm with: AD/Windows authentication logs, Kerberos/NTLM events, VPN, RADIUS, TACACS+, SSO, and SIEM correlation. A useful rule of thumb is: same source, same failure pattern, lots of usernames, and only a few attempts per account usually points to password spraying.

Modern note: MFA fatigue or push bombing may appear as repeated MFA prompts after valid credentials are obtained.

Beaconing and command-and-control

Beaconing is low-and-slow outbound communication from an infected host to a command-and-control server. Real beaconing often shows near-regular timing with a little jitter, not perfectly fixed intervals.

Indicators: repeated outbound connections to a rare destination, periodic DNS lookups, low-volume encrypted sessions, suspicious process context, or uncommon TLS fingerprints where tools support JA3/JA4-style analysis.

Confirm with: NetFlow/IPFIX, firewall logs, endpoint telemetry, and DNS logs. TLS encryption by itself is not suspicious. What matters is the combination of rarity, timing, destination reputation, and process context.

Common distractor: EDR, MDM, backup, monitoring, or software update check-ins. Always match the traffic to inventory before you start calling it malware.

Rogue DHCP and rogue devices

A rogue DHCP server can hand out the wrong gateway or DNS server and break or redirect traffic. Sometimes DHCP starvation shows up first, which exhausts the legitimate pool and makes the attacker’s DHCP service look like the only option to clients.

Indicators: clients suddenly receiving bad gateway/DNS settings, unexpected lease sources, duplicate or conflicting addressing, or new unauthorized devices on switch ports.

Confirm with: ipconfig /all, ip addr, nmcli dev show, DHCP logs, and switch data to identify the unauthorized MAC/interface. On managed switches, check show ip dhcp snooping where supported.

Controls: DHCP snooping, NAC, port security, 802.1X, and physical port control.

Wireless attacks: rogue AP, evil twin, deauthentication

Know the distinction:

• Rogue AP: unauthorized AP connected to the network.
• Evil twin: attacker-controlled AP impersonating a trusted SSID.

Indicators: repeated disconnects, users associating to a similar SSID, different BSSID/channel than expected, certificate prompts, or deauthentication frames.

Confirm with: wireless controller logs, client association history, BSSID, channel, RSSI, and packet capture if available.

Accuracy note: deauthentication attacks are especially relevant in legacy, open, or WPA2 environments; 802.11w/Protected Management Frames and WPA3 reduce some management-frame abuse.

Controls: WPA2/WPA3-Enterprise, EAP-TLS where appropriate, certificate validation, rogue AP detection, and PMF/802.11w.

Other attacks to recognize quickly

MAC flooding / MAC spoofing: MAC spoofing changes identity; MAC flooding attempts to exhaust the switch CAM table. If the table gets exhausted, some switches may increase unknown unicast flooding depending on the platform and its protections, but the exact behavior isn’t identical across every switch. Check show mac address-table and show port-security. Controls include port security, sticky MAC, and 802.1X.

VLAN hopping: usually tied to misconfiguration. Two classic methods are switch spoofing by abusing DTP/trunk negotiation and double-tagging, which exploits native VLAN handling. Hardened environments reduce this risk by disabling DTP, forcing access ports, and avoiding careless native VLAN design.

Replay attacks: captured valid traffic is resent later. Just don’t confuse that with normal TCP retransmissions. Replay detection is often protocol-specific and relies on nonces, timestamps, sequence numbers, Kerberos authenticators, or IPsec anti-replay windows.

Practical validation commands

Useful commands for scenario validation:

• DNS: nslookup example.com, querying a trusted resolver for comparison, dig +trace example.com
• ARP: arp -a, ip neigh, show arp
• DHCP/client config: ipconfig /all, ip addr, nmcli dev show
• Packet capture: tcpdump -nn host <ip> and port 80, tcpdump -nn 'tcp[tcpflags] & tcp-syn != 0'
• Switch: show mac address-table, show interfaces status, show port-security, show ip dhcp snooping

Quick differential diagnosis for exam questions

Four exam-style scenarios

1. Web app is slow; many half-open sessions are visible.
Most likely: SYN flood. Best confirmation: packet capture or load balancer/firewall session data. Wrong answer trap: “high traffic” alone is not enough if handshakes complete normally.

2. Users reach a fake login page; DNS answers changed and certificates look wrong.
Most likely: DNS poisoning or DNS hijacking. Best confirmation: compare recursive and authoritative answers with dig or nslookup. Wrong answer trap: if only managed devices warn, consider TLS inspection before assuming an on-path attack.

3. One failed login per user appears across hundreds of accounts from one source.
Most likely: password spraying. Best confirmation: auth logs showing one or a few passwords across many usernames. Wrong answer trap: generic “brute force” is less precise.

4. Several clients suddenly receive the wrong default gateway and DNS server.
Most likely: rogue DHCP. Best confirmation: client IP configuration, DHCP logs, and switchport identification of the unauthorized server. Wrong answer trap: duplicate IPs alone are weaker evidence than wrong handed-out settings.

Controls that prevent or expose attacks

Analyst workflow and evidence preservation

Use a tight workflow:

1. Verify baseline: check maintenance windows, scans, patching, failover, and known tools.
2. Scope impact: one host, one user, one subnet, or a public service?
3. Correlate: don’t trust one alert; pull the matching DNS, auth, switch, endpoint, or flow data.
4. Confirm with protocol clues: handshake failure, wrong MAC, bad DNS answer, auth distribution pattern, or periodic outbound traffic.
5. Contain carefully: isolate a host, disable a port, block a source, or escalate upstream based on severity and authority.
6. Preserve evidence: export relevant logs, capture timestamps with time zone, note affected hosts/users, save short packet captures if allowed, and document what changed.

If evidence conflicts, slow down. Example: certificate warnings plus redirects may suggest MITM, but if only corporate devices are affected and the proxy root CA is missing, the real issue may be broken TLS inspection trust rather than an attack.

Security+ exam strategy

For this objective, the exam usually wants three things: the most likely attack, the best confirming evidence source, and the best first action.

High-yield memory anchors:

• One host, many ports = scan
• Half-open sessions = think SYN flood
• One password, many users = password spraying
• Wrong MAC for gateway = ARP spoofing or failover; verify
• Wrong DNS answer + redirect = poisoning/hijacking
• Wrong gateway/DNS handed to clients = rogue DHCP
• Steady rare check-ins = beaconing

Best test-taking habit: choose the most specific answer supported by the strongest indicator. If the pattern is one password across many accounts, pick password spraying, not the broader term brute force.

Conclusion

Network attack analysis is less about memorizing definitions and more about reading clues correctly. Match the symptom to the protocol behavior, confirm it with the right log source, and watch for common lookalikes like failover events, TLS inspection, vulnerability scans, and management traffic. If you can look at a scenario and say, “This most likely indicates X, and I’d confirm it with Y,” you’re thinking exactly the way Security+ wants.