Threats and Attacks

Slow apps that time out, a Wi‑Fi network that looks familiar but isn't, or a login alert from a place you've never been, these are common help desk tickets, and they often trace back to threats and attacks. In CompTIA A+ Core 2 (220-1202), Domain 2.0 Security, Objective 2.5, you're expected to recognize what's happening and respond with safe, basic steps. A threat is a potential cause of harm (a risk that could be used against you), while an attack is the action taken to cause that harm.

This Part 1 focuses on the attack types you'll see on the exam and in day-to-day support work: DoS, DDoS, evil twin, zero-day, spoofing, and on-path attacks. These issues can show up as sudden slowdowns, unstable connections, strange browser behavior, or repeated account lockouts.

Each section follows the same pattern so it's easy to study and apply on the job. You'll get what the attack is, how it works at a high level, common signs you can spot during troubleshooting, and basic prevention steps that fit a help desk role.

Exam Mindset

When you read a security scenario on CompTIA A+ 220-1202, Domain 2.0 (Security), Objective 2.5, the fastest way to score points is to classify the problem before you chase details. Treat each prompt like a triage note: what is failing, what is exposed, and what safe step should happen first? This habit keeps you from picking answers that sound technical but skip the basics.

A good rule is to translate the story into a few plain statements. Something is unavailable, something looks fake, or data might be altered. Once you name the category, the attack type (DoS, DDoS, evil twin, zero-day, spoofing, on-path) often becomes obvious.

A quick triad check: availability, confidentiality, and integrity

The exam often hides the answer inside the CIA triad. If you can tag the scenario as an availability, confidentiality, or integrity problem, you narrow choices quickly.

Availability means systems and data are reachable when needed. If users cannot access a service, availability is the primary concern. A classic example is DoS or DDoS, where traffic floods a target until it slows or fails. Nothing "steals" data in the story; the problem is that work stops.

Confidentiality means only authorized people can see data. If the scenario suggests someone is reading traffic or collecting credentials, confidentiality is at risk. An evil twin Wi-Fi can break confidentiality when it tricks users into connecting, then captures logins. Spoofing can also harm confidentiality when an attacker pretends to be a trusted site and collects usernames and passwords.

Integrity means data stays accurate and unaltered. If the prompt hints that information was changed in transit, integrity is the key issue. On-path attacks (person-in-the-middle) commonly affect integrity because the attacker can edit what both sides see. Spoofing can also harm integrity if a user receives altered instructions, forged emails, or fake updates that lead to wrong actions.

On the exam, you will see repeated clue words. Watch for these common "CIA flags":

Availability clues: "service down," "cannot reach website," "timeouts," "network flooded"
Confidentiality clues: "fake login page," "new SSID with same name," "credentials captured"
Integrity clues: "unexpected certificate warning," "redirected to a different site," "data doesn't match"

If the prompt mentions a certificate warning or a redirect you didn't request, assume the connection might not be trustworthy. That points you toward on-path or spoofing before anything else.

One more nuance helps with tricky questions: on-path attacks can hit all three. They can read data (confidentiality), change it (integrity), and disrupt it (availability). If the scenario includes multiple symptoms at once, on-path becomes more likely.

Attack surface, threat actor, and risk in plain language

After the triad check, the exam usually wants you to notice exposure. That is the attack surface, meaning the parts of a system that an attacker can touch. The easiest way to think about attack surface is "all the doors and windows," including the ones you forgot you left open.

Everyday attack surface examples show up in Objective 2.5 scenarios:

Public Wi-Fi: You share the network with strangers. That makes evil twin and on-path attacks more realistic because attackers can sit close and wait for connections.
Open ports and exposed services: A device with unnecessary services running gives attackers more chances. While A+ does not ask for deep port strategy, it expects you to see "open to the internet" as added risk.
Outdated software: Old versions raise the chance of a zero-day attack succeeding because defenses lag behind new techniques, and users may not have a fix ready.

Next, consider the threat actor, which is simply the person behind the attempt. You do not need a full profile on the exam. A few broad types explain most prompts:

A script kiddie often uses ready-made tools. Their attacks are noisy, so DoS attempts and simple spoofing fit this profile.
An insider has access already, so risk rises when the scenario mentions shared accounts, unmanaged admin rights, or unusual behavior from a known user.
An organized group tends to be patient and consistent. They may run realistic spoofing pages, long-running on-path setups, or target high-value systems.

Finally, tie these ideas to risk, which is the chance that a threat uses the attack surface and causes harm. The exam frames "reduce risk" as simple control choices, not hero work.

Two common risk reducers appear in help desk level answers:

Patching reduces risk because it removes known weaknesses and closes gaps that attackers rely on. It will not fix a true zero-day immediately, but staying current still cuts overall exposure and limits follow-on attacks.

Secure Wi-Fi settings reduce risk because they make it harder to trick users or intercept traffic. Using the right SSID, avoiding open networks, and preferring trusted connections all reduce the odds of evil twin and on-path scenarios.

First actions that are usually safe on the job

Many exam questions test judgment, not tools. They want the first actions that reduce harm while avoiding mistakes. In a real help desk role, the safest early steps focus on containment, communication, and recordkeeping.

Start with actions that do not destroy evidence or spread the problem. In most situations, these are low-risk and appropriate:

Document what you see: Write down error messages, timestamps, affected users, and any odd prompts (like a certificate warning). Good notes help the next team act faster.
Isolate the device or segment when practical: If a single workstation looks compromised, disconnect it from the network or move it to a safe VLAN if your process allows. Isolation limits spread and reduces damage.
Switch to known-good connectivity: If the story involves public Wi-Fi, an evil twin, or strange redirects, move to a trusted network or use a wired connection. This also supports cleaner testing.
Notify the right team early: Escalate to security, networking, or your incident contact based on policy. Speed matters because DoS, on-path, and spoofing can affect more users over time.
Preserve evidence: Avoid wiping systems or "cleaning up" logs unless your procedure says so. Evidence matters for both diagnosis and reporting.

Password actions often appear in answer choices, so handle them in the right order. Change passwords after containment, not before. If an attacker is still on-path or the device is still connected to an evil twin, a password change can be captured again. A safer approach is to isolate first, then reset credentials using a trusted path (for example, from a known-good network).

In short, pick responses that are boring but correct. The exam rewards the candidate who contains the issue, reports it, and avoids making it worse.

Denial of Service

In CompTIA A+ Core 2 (220-1202), Domain 2.0 (Security), Objective 2.5, denial of service attacks appear as plain availability failures. The core idea is simple: a system can't serve real users because it is too busy handling junk. Sometimes the target is a website, sometimes it is a VPN, DNS, or a login service. Either way, the result feels the same to the business, work slows down, then stops.

It helps to picture a small shop with one cashier. If a crowd blocks the counter with pointless questions, paying customers can't check out. In DoS and DDoS, the attacker creates that crowd on purpose. Your job in an entry-level role is to spot the symptoms early, document them well, and escalate using the right channels.

DoS basics: one source, one goal, make it unusable

A denial of service (DoS) attack tries to make a service unavailable by overwhelming it from a single main source. The attacker may use one computer or one network path. The goal is not subtle. The attacker wants your server, firewall, or application to run out of something important, such as bandwidth, CPU time, memory, or available connection slots.

Two common DoS patterns show up in basic troubleshooting:

Traffic flooding: The attacker sends a large volume of packets toward a target. Even if the packets are meaningless, they still consume bandwidth and device effort.
Request spamming: The attacker sends many valid-looking requests, for example repeated web page hits or login attempts. The server spends real resources answering, until it can't keep up.

Because a DoS is about overload, the first signs often look like "normal" performance problems, except they arrive fast and affect many users at once. Watch for clues that point to resource exhaustion rather than a single broken workstation.

Common signs include:

Sudden slowdowns across a service, not just one user.
Timeout errors in browsers and apps, even though settings did not change.
High CPU usage or unusually high memory use on the server or a key appliance.
Many failed connections, for example a spike in refused sessions or half-open connections in logs.
Services flapping, where the service recovers briefly, then fails again.

A helpful exam distinction is what DoS is not. A DoS attack focuses on availability, not secrecy.

DoS doesn't require data theft. A service can go down without any data being accessed or copied.

That said, a DoS can distract staff while other attacks happen. Still, treat the symptoms you see. When the story describes timeouts and overload with no mention of stolen records, the simplest answer is usually DoS.

DDoS basics: many sources that are hard to block

A distributed denial of service (DDoS) attack uses many sources at the same time. Instead of one attacker sending traffic, a whole crowd does it. In practice, the crowd often comes from a botnet, which is a group of infected devices controlled remotely. Those devices might be home PCs, servers, or even smart devices. Each one sends a small amount of traffic, yet the total becomes overwhelming.

This "many sources" design matters because it changes the defense options. If one IP address floods a service, blocking that IP may help. With DDoS, blocking one address barely changes the volume. Also, the traffic can appear to come from real users spread across many networks, which makes basic filtering risky.

In some cases, attackers also use amplification, where they trigger third-party systems to send larger responses toward the victim.

For exam and job scenarios, focus on the typical clues that separate DDoS from a local server problem:

Large traffic from many IP addresses and many locations, often visible in firewall logs or web server logs.
ISP alerts about unusual inbound traffic, or warnings that a circuit is nearing capacity.
Normal server health but saturated bandwidth, meaning CPU and memory look fine, yet users still time out because the network link is full.
Multiple services failing at once, especially if they share the same internet connection (for example, website, VPN, and VoIP).

A practical way to reason about DDoS is to compare it to a traffic jam on the only bridge into town. Your servers may be ready to work, but legitimate users cannot reach them. As a result, DDoS mitigation often involves network-level help, such as upstream filtering, scrubbing services, or content delivery networks, rather than only changing settings on the server.

What you can do during a suspected DoS or DDoS incident

During a suspected DoS or DDoS event, entry-level staff add the most value through calm triage and strong documentation. Quick, unplanned changes can hide the real pattern or remove evidence that a network team needs.