CompTIA Network+ (N10-008): Compare and Contrast Common Types of Attacks

Here are the most formulaic or predictable sentences rewritten in a more varied, natural style while keeping the meaning intact: ---

If you’re studying for CompTIA Network+ and zeroing in on the N10-008 attack objective, the real trick isn’t just memorizing a pile of definitions. It’s spotting the symptoms, telling look-alike attacks apart, and choosing the control that actually fits what’s happening. That is exactly how these questions tend to work.

→ If you’re grinding through CompTIA Network+ with the N10-008 attack objective in your sights, memorizing definitions only gets you so far. The real game is catching the symptoms, separating the twins-from-the-cousins attacks, and picking the control that actually matches the mess in front of you. That’s the shape these questions usually take.

Attack classification also connects to the CIA triad, but not always in a neat one-to-one way. Sniffing primarily threatens confidentiality. On-path attacks threaten confidentiality and integrity, and sometimes availability. Replay attacks often affect session validity, authentication, or transaction integrity. DNS poisoning can mess with integrity, leak information, and, indirectly, hurt availability too. Ransomware is usually the first thing people think of when availability starts going sideways, but honestly, it’s gotten a lot uglier over the years. These days, it often isn’t just about locking files up. A lot of attackers will grab the data first and then pile extortion on top of the encryption, which makes cleanup a whole lot uglier.

→ Attack types do tie back to the CIA triad, though not in some tidy little spreadsheet way. Sniffing leans hard on confidentiality. On-path attacks are nastier — confidentiality and integrity both take a hit, and availability can get dragged in too. Replay attacks mess with session trust, authentication, or transaction integrity. DNS poisoning can bend integrity, spill information, and, by extension, bruise availability. And ransomware? Most people think “availability” and stop there, but that’s old news. These days it’s often grab-first, encrypt-second, extort-whatever’s-left. Messy stuff. Really messy.

When I’m studying for the exam, I like to keep things simple and use the same game plan every time, honestly. So anyway, I always tell people to slow down and ask a few basics: what’s the attack actually doing, where is it happening, what’s the first clue someone would notice, what evidence would prove it, and which control would actually slow it down or stop it? Also remember that Network+ expects recognition and defensive understanding, not exploit steps.

→ When I’m prepping for the exam, I stick to one boring little routine. Boring is good, by the way. I slow the question down and ask: what’s the attack doing, where’s it living, what clue would show up first, what would prove it, and what control actually bites back? Also—important—Network+ wants you to recognize and defend, not walk through the attack like you’re writing a how-to guide.

Use this checklist when a scenario question gives you murky or incomplete symptoms and you’ve gotta work through the clues instead of guessing. It keeps you from chasing the wrong answer just because one clue looks familiar.

→ Use this checklist when a scenario feels foggy and half-built. It keeps you from grabbing the first answer that smells familiar, which is a trap exam writers absolutely love.

One more exam tip: some terms are used loosely in practice. You may see MITM and on-path used interchangeably, or DNS poisoning and DNS spoofing treated as near-synonyms. Know the exact distinction, absolutely, but don’t let the loose wording people use in the real world throw you off.

→ Quick exam note: real-world language gets sloppy. MITM and on-path get swapped around all the time, and DNS poisoning and DNS spoofing are often treated like cousins instead of separate terms. Know the difference, yes — but don’t let loose wording trip you up.

A denial-of-service attack is basically a way to make a service unavailable by burning through bandwidth, connection state, CPU, memory, or app resources. A distributed denial-of-service attack does the same thing, but from a bunch of systems at once, and yeah, it’s often powered by a botnet. The botnet is the herd of compromised machines; DDoS is one of the things attackers use that herd for.

→ A DoS attack is the digital equivalent of clogging every pipe, chewing up bandwidth, connection state, CPU, memory, whatever hurts most. DDoS does the same thing, only with a crowd of machines piled on top. Botnet herd, attacker leash. Ugly combination.

At a high level, I usually break availability attacks into three buckets. Volumetric attacks saturate links, often through floods or reflection/amplification using services such as DNS, NTP, SSDP, or memcached. Protocol attacks abuse network or transport behavior, such as SYN floods exhausting half-open TCP state. Application-layer attacks use apparently valid requests, such as HTTP floods, to overwhelm web tiers or APIs.

→ I usually sort availability attacks into three buckets. Volumetric ones just stuff the pipes until they choke, often with floods or reflection/amplification tricks using DNS, NTP, SSDP, memcached — the usual suspects. Protocol attacks mess with network or transport mechanics, like a SYN flood stuffing half-open TCP state. Application-layer attacks are sneakier-looking, with requests that seem fine on the surface but still grind web apps or APIs into paste.

SYN flood questions are especially common. In a normal TCP handshake, the client sends SYN, the server replies with SYN-ACK, and then the client finishes things off with ACK. In a SYN flood, the attacker keeps firing off SYN packets and never bothers to finish the handshake. So the server winds up wasting resources on a pile of half-open connections that never become real sessions. Mitigations usually include rate limiting, ACLs, SYN cookies, load balancers, hardened TCP settings, and upstream filtering before the traffic even reaches the target. In the real world, you usually want a few of those working together, not just one shiny control and a prayer. For a big DDoS, content delivery and traffic-scrubbing matter a lot more than relying on one edge firewall and hoping for the best.

→ SYN flood questions show up constantly. Normal TCP goes SYN, SYN-ACK, ACK — neat little handshake. A SYN flood tosses out the first step over and over, then ghosts the rest, leaving the server babysitting a pile of half-open connections that go nowhere. Fixes? Rate limiting, ACLs, SYN cookies, load balancers, hardened TCP behavior, upstream filtering. Usually a stack of controls, not one magical setting and crossed fingers. For serious DDoS, scrubbing and content distribution do the heavy lifting; a lonely edge firewall is not your superhero here.

Sniffing is passive packet capture. It can capture encrypted or unencrypted traffic, but encryption really cuts down on what the attacker can actually understand. On-path attacks place the attacker in the traffic path so they can observe, alter, or relay traffic. Replay means capturing valid traffic and sending it again later. Session hijacking focuses on taking over an authenticated session, often through stolen cookies, tokens, or session identifiers.

→ Sniffing is just passive capture — sitting there, listening. Encryption doesn’t stop the capture, but it can turn the haul into unreadable static. On-path attacks are different; the attacker wedges themselves into the route so they can watch, tweak, or relay traffic. Replay is the “save it for later and throw it back” move. Session hijacking is more personal: steal the live session, take the chair, keep the browser seat warm.

This is exactly where compare-and-contrast pays off, because a lot of these attacks look related until you slow down and ask what’s actually happening. Sniffing is passive. On-path is active interception. Replay resends previously valid data. Session hijacking abuses existing session state. ARP spoofing can help an attacker get on-path inside a local segment, but it can also be used just to break connectivity instead of intercepting traffic.

→ This is where compare-and-contrast really earns its keep. A lot of these look like siblings until you stop and ask, “Okay, what’s the attacker actually doing?” Sniffing watches. On-path interferes. Replay reuses old valid data. Session hijacking steals the existing state and keeps going like it belongs there. And ARP spoofing? Sometimes it’s a launchpad into on-path access; sometimes it’s just sabotage with no finesse at all.

TLS, SSH, VPNs, and IPsec definitely reduce risk, but only if trust is being checked the right way. TLS helps a lot, but it won’t save you if users keep clicking through certificate warnings or if a bad certificate gets trusted by mistake. And that’s the part people tend to gloss over, which is a mistake. And replay protection doesn’t happen automatically just because something is encrypted. A lot of protocols and apps still need nonces, timestamps, sequence numbers, challenge-response, token expiration, or mutual authentication to really shut that door.

→ TLS, SSH, VPNs, and IPsec all help, sure — but only when trust is actually being verified, not just assumed. TLS is useful right up until somebody clicks through a scary certificate warning or trusts the wrong cert and shrugs it off. That’s the sloppy part people skip past. Replay protection is another one: encryption alone doesn’t magically solve it. You still need nonces, timestamps, sequence numbers, challenge-response, token expiration, mutual auth... the usual armor plating.

Brute force tries many combinations. Dictionary attacks try likely words and common patterns. Password spraying uses one or a few common passwords against many accounts. Credential stuffing uses known username/password pairs from another breach. The exam distinction is usually in the login pattern.

→ Brute force hammers away at lots of combinations. Dictionary attacks go for likely words and familiar patterns. Password spraying is the “one password, lots of victims” approach. Credential stuffing uses leaked username/password pairs from somewhere else and hopes they still fit. On the exam, the login pattern is usually the giveaway.

If one user gets thousands of guesses, think brute force. If many users each get one attempt with the same password, think spraying. If valid leaked credentials are being tested across another service, think stuffing. Authentication attacks may be followed by privilege escalation, which is different: getting in is not the same as gaining more rights after entry.

→ One user getting hammered with thousands of guesses? Brute force. Lots of users, same password, one shot each? Spraying. Leaked working credentials being tried somewhere else? Stuffing. And don’t blur that with privilege escalation — logging in is not the same thing as walking out with more power than you should have.

Phishing is broad deception, usually by email. Spear phishing is targeted. Whaling targets executives or other high-value roles. Vishing uses voice, smishing uses text messaging, and pretexting uses a fabricated story to gain trust. Business email compromise often involves impersonating executives, finance staff, or vendors to redirect payments or change banking details. Watering hole attacks compromise a site the target group is likely to visit. Typosquatting uses look-alike domains. Hoaxes are false alerts or fake security claims that manipulate users into harmful action.

→ Phishing is the broad umbrella — usually email, sometimes messy, always annoying. Spear phishing narrows the aim. Whaling goes after the big fish. Vishing talks, smishing texts, and pretexting builds a story and pushes it hard. Business email compromise is the slick con — fake the boss, fake finance, fake a vendor, and move the money. Watering holes infect a place the target already trusts. Typosquatting is the sneaky near-miss domain game. Hoaxes? Just fake alarms with a costume on.

And the physical side still matters, too. Tailgating is how somebody gets inside without permission, while shoulder surfing is just watching over someone’s shoulder to steal information the old-fashioned way. Dumpster diving looks for useful discarded data.

→ Physical attacks still count, inconveniently enough. Tailgating is the “follow somebody in and act like you belong there” move. Shoulder surfing is exactly what it sounds like — a little too interested in someone else’s screen or keypad. Dumpster diving is the unglamorous version: rifling through trash for anything that shouldn’t have been tossed.

Viruses typically attach to a host file and spread when that file or program executes. Worms self-propagate. Trojans look legitimate but are malicious. Ransomware encrypts data or disrupts access for extortion. Spyware collects data covertly, and keyloggers focus on keystrokes. Logic bombs trigger on a condition. Cryptojacking steals compute resources. Fileless malware often abuses scripts or trusted tools, sometimes described as living-off-the-land behavior.

Viruses hitch a ride on a host file and spread when that file runs. Worms do the self-spreading thing all by themselves. Trojans show up dressed like something useful. Ransomware locks or blocks access and then demands money, because of course it does. Spyware quietly sneaks data out, while keyloggers focus on every keystroke. Logic bombs wait for a trigger. Cryptojacking steals your compute like it’s paying rent. Fileless malware? It’s often script-heavy, tool-abusing, and annoyingly hard to pin down.

Rootkits are stealth and persistence tools that may operate in user mode, kernel mode, or even boot and firmware layers. They can hide files, processes, hooks, and registry changes, which is exactly why they’re such a pain to track down. A botnet is attacker-controlled infrastructure made of compromised systems; malware often creates bots, but the botnet itself is the controlled fleet.

Rootkits are all about hiding in plain sight — user mode, kernel mode, boot, firmware, wherever they can burrow. They’ll mask files, processes, hooks, registry changes, the whole unpleasant toolkit. Botnets are the managed mob: compromised systems under attacker control, marching to someone else’s tune.

Persistence often shows up through scheduled tasks, services, startup folders, registry run keys, browser extensions, or abuse of remote management tools. Privilege escalation may be vertical such as user to admin, or horizontal such as one user accessing another user’s data.

→ Persistence likes to leave fingerprints in boring places: scheduled tasks, services, startup folders, registry run keys, browser extensions, remote management tools being abused like they’re harmless. Privilege escalation comes in two flavors — vertical, where a user climbs to admin, or horizontal, where they slide sideways into someone else’s data.

A rogue AP is an unauthorized access point. An evil twin is a rogue AP impersonating a trusted SSID. Deauthentication or disassociation attacks force clients off Wi-Fi so they reconnect, sometimes to the attacker’s AP. Older wireless environments were more exposed here; 802.11w Protected Management Frames helps reduce this risk.

→ A rogue AP is just unauthorized. An evil twin is the impostor version — same costume, trusted SSID, bad intent. Deauth and disassociation attacks boot clients off Wi-Fi and make them reconnect, sometimes straight into the attacker’s lap. Older wireless gear had a rough time here; 802.11w helps take some of the sting out of it.

Bluejacking is mostly nuisance messaging and is less important on modern hardened devices. Bluesnarfing is unauthorized Bluetooth data access, often due to insecure pairing or vulnerabilities. NFC and RFID abuse usually involves unauthorized reading, cloning, or misuse of those proximity-based identifiers that people tend to trust a little too much.

→ Bluejacking is mostly annoying fluff. Bluesnarfing is the real problem — unauthorized Bluetooth access, often because pairing was weak or the device had a hole in it. NFC and RFID abuse is usually the same sort of thing in a different jacket: reading, cloning, or misusing something people assume is safe just because it’s close by.

ARP poisoning corrupts IP-to-MAC resolution on a local segment. Symptoms may include intermittent connectivity, duplicate mappings that don’t make sense, ARP entries that keep flipping back and forth, or local traffic that looks like it’s being intercepted. DHCP starvation exhausts leases. DHCP spoofing or a rogue DHCP server hands out false IP settings, gateway values, or DNS servers. DNS poisoning can mean forged responses or resolver cache poisoning; exam questions may also blur this with rogue DNS assignment or malicious local host file changes. MAC flooding attempts to exhaust CAM tables so the switch floods more unknown unicast traffic; modern behavior varies by vendor and model. VLAN hopping typically refers to switch spoofing or double-tagging to cross VLAN boundaries.

→ ARP poisoning messes with IP-to-MAC mapping on the local segment. You might see flapping entries, weird duplicate mappings, intermittent connectivity, or traffic that looks like it’s being quietly rerouted. DHCP starvation drains the pool dry. DHCP spoofing — rogue server, false gateway, bogus DNS, the whole nasty package. DNS poisoning is forged answers or cache poisoning, though exam writers love to blur it with other name-resolution weirdness. MAC flooding tries to overwhelm CAM tables so the switch starts flooding unknown traffic. VLAN hopping usually means switch spoofing or double-tagging to jump the fence.

DNS defenses usually include trusted resolvers, DNSSEC where it’s used, DNS filtering, sinkholing, and logging suspicious queries so you can spot trouble earlier. DNSSEC helps verify the authenticity and integrity of DNS data, but it doesn’t magically fix every DNS redirection problem on its own.

→ DNS defense is a mix of trusted resolvers, DNSSEC where appropriate, filtering, sinkholing, and logs that actually get reviewed. DNSSEC helps prove the data is legit, but no, it doesn’t magically cure every redirection problem under the sun.

SQL injection targets backend query handling. The main mitigation is parameterized queries or prepared statements, backed up by input validation and least privilege on the database side. It’s not flashy, but it’s the right answer. Cross-site scripting targets the browser and appears as stored, reflected, or DOM-based XSS. Defenses include output encoding, a content security policy, and careful session handling. CSRF tricks an authenticated browser into sending unwanted requests; defenses include anti-CSRF tokens, SameSite cookies, and reauthentication for sensitive actions. Path traversal or directory traversal abuses file path handling, so sanitization, canonicalization, and proper file permissions matter.

→ SQL injection goes after backend queries. Parameterized queries or prepared statements are the real fix, with input validation and least privilege backing them up. Not glamorous, but correct. Cross-site scripting hits the browser and shows up as stored, reflected, or DOM-based XSS. Defend with output encoding, a solid content security policy, and sane session handling. CSRF abuses a logged-in browser into doing something it shouldn’t; anti-CSRF tokens, SameSite cookies, and reauth help. Path traversal is the file-path trick — sanitize, canonicalize, lock permissions down.

Network teams still need to recognize these because they show up in WAF logs, reverse proxy logs, and packet captures all the time.. A suspicious query string manipulating database input suggests SQL injection. Script execution affecting users’ browsers suggests XSS. A forged funds-transfer action from an already logged-in browser suggests CSRF, not replay.

→ Network teams still have to know these because they pop up in WAF logs, reverse proxy logs, and packet captures all the time. A weird query string poking at database input smells like SQL injection. Script behavior aimed at users’ browsers points to XSS. A fake funds-transfer request coming from an already authenticated browser? That’s CSRF, not replay.

Reconnaissance always comes before exploitation, even if it’s quiet enough that nobody notices it at first. Active recon includes port scans, service probes, and banner grabbing. Passive recon includes public information gathering, publicly available records, and other observation. Banner grabbing is recon, not an attack family like MITM.

→ Reconnaissance comes first, even when it slips by quietly. Active recon is the noisy stuff: port scans, service probes, banner grabbing. Passive recon is the quieter look-around — public info, public records, plain observation. Banner grabbing is still recon, not some broad attack category like MITM.

A zero-day is a vulnerability for which no vendor patch or effective fix is available at the time of exploitation or disclosure. That is more specific than simply “unpatched.” Once attackers get in, the lifecycle often moves through execution, persistence, privilege escalation, lateral movement, exfiltration, and finally impact. That’s the pattern I’ve seen over and over again in enterprise environments.

→ A zero-day means no patch, no effective fix, at the moment it’s being exploited or even disclosed. That’s narrower than just “unpatched.” Once attackers are inside, the usual path starts unfolding: execution, persistence, privilege escalation, lateral movement, exfiltration, then impact. Same ugly rhythm, different breach.

When in doubt, ask yourself what evidence source would actually confirm the suspicion instead of just making the story sound plausible. Firewall and NetFlow data are really helpful for spotting DDoS activity, port scans, and unusual outbound traffic. Authentication logs reveal spraying, brute force, stuffing, and impossible-travel events. DHCP lease logs and ipconfig /all or equivalent help confirm rogue gateway or DNS assignments. ARP cache checks help with local redirection. DNS resolver logs can reveal suspicious domains, unusual query volume, or poisoned responses. Wireless controller and WIDS/WIPS alerts can expose rogue APs, deauth patterns, and SSID/BSSID mismatches. EDR telemetry is really useful for spotting ransomware, cryptojacking, spyware, and persistence behavior.

→ When you’re unsure, stop and ask what evidence would actually prove it, not just make the story sound neat. Firewall and NetFlow data catch DDoS, scans, and odd outbound traffic. Auth logs expose spraying, brute force, stuffing, and impossible travel. DHCP logs plus ipconfig /all help confirm bad gateway or DNS settings. ARP cache checks point toward local redirection. DNS logs can show weird domains, weird volume, or poisoned replies. Wireless controller and WIDS/WIPS alerts can light up rogue APs, deauth patterns, SSID/BSSID mismatches. EDR is where ransomware, cryptojacking, spyware, and persistence tend to leave their fingerprints.

Firewalls are primarily preventive, with detective value through logging. IDS is mainly detective; IPS is preventive. EDR may be preventive, detective, and corrective depending on the platform. VPNs reduce exposure on untrusted networks but do not make a compromised endpoint trustworthy. TLS provides confidentiality, integrity, and server authentication when certificate validation is correct, but replay resistance still depends on protocol and application design. WPA2/WPA3 improve wireless confidentiality and authentication, but they do not directly detect rogue APs; WIDS/WIPS and certificate validation are more direct there. RADIUS is an AAA backend service used by 802.1X, NAC, and VPN infrastructure rather than a standalone control category like MFA.

→ Firewalls mostly prevent, though their logs can still help you hunt. IDS is the watcher; IPS is the blocker. EDR can be all three depending on the product. VPNs help on hostile networks, but a compromised endpoint is still compromised. TLS gives you confidentiality, integrity, and server auth when cert validation is done right, but replay resistance lives deeper in the protocol and app design. WPA2/WPA3 help wireless confidentiality and auth, but they don’t directly sniff out rogue APs — that’s WIDS/WIPS territory. RADIUS is the AAA backend working behind 802.1X, NAC, and VPNs, not a standalone control like MFA.

The best way to study this Network+ objective is to move from symptom to attack to evidence to control. If a question mentions many distributed IPs, think DDoS. If it says one common password across many users, think spraying. If it emphasizes duplicate SSIDs and trust prompts, think evil twin before stopping at rogue AP. If users get bad gateway or DNS values, think DHCP spoofing before endpoint malware.

→ The cleanest way through this objective is symptom → attack → evidence → control. Distributed IPs? DDoS. One password, many users? Spraying. Duplicate SSIDs plus trust prompts? Evil twin, not just rogue AP. Bad gateway or DNS values? Start with DHCP spoofing before you go hunting for endpoint malware.

That compare-and-contrast mindset is what helps on the exam and in real troubleshooting. Memorize less, differentiate more, and always ask what the logs would show and which control best fits the attack.

→ That compare-and-contrast habit pays off on the exam and in the real world. Memorize less. Separate more. And always, always ask what the logs would say — and which control actually fits the fight.

--- If you want, I can also do a **full rewrite of the entire passage** in this same style while keeping it instructional.