Threat knowledge matters in real help desk work because it shapes how you triage tickets, spot risk early, and give users advice they can follow. It also supports safer daily computing, since the same patterns show up in personal email, web browsing, and account logins. This section aligns with CompTIA A+ Core 2 (220-1202), Domain 2, Objective 2.5 and focuses on the second set of threats you're expected to recognize and explain.
In Threats and Attacks Part 2, you'll review brute-force and dictionary attacks, then contrast them with the human risks behind an insider threat. Next, you'll cover web and app abuse, including Structured Query Language (SQL) injection and cross-site scripting (XSS), with attention to how attackers move from a small input flaw to real impact.
You'll also look at email-driven fraud, especially business email compromise (BEC), and why it succeeds even when malware isn't involved. Finally, you'll study supply chain and pipeline attacks, where a trusted vendor, update, or build process becomes the entry point. Throughout, expect clear definitions, a simple explanation of how each attack works, common warning signs, and basic defenses you can apply at the endpoint and in daily workflows.
Password Guessing
Password attacks that break in by guessing are common because they are simple, cheap, and often automated. For CompTIA A+ Core 2 (220-1202), Domain 2, Objective 2.5, you should be able to explain how attackers guess credentials, what the attempts look like in real systems, and which controls reduce risk without blocking real users.
Brute-force attacks, what they are and what they look like
A brute-force attack means the attacker keeps trying passwords until one works. Think of it like trying every key on a keyring, one after another, until a door opens. Because computers can try guesses quickly, weak passwords fail fast.
There are two broad ways brute-force guessing happens:
- Online guessing: The attacker tries passwords against a live login page (email, VPN, router admin page). This is slower because the system can rate-limit, log, and lock accounts.
- Offline guessing: The attacker first steals password data (often password hashes) and then guesses on their own system. This can be much faster because there is no lockout or network delay. Defense depends heavily on strong hashing and long passwords.
A short example makes it clearer. Suppose an attacker targets a cloud email mailbox (for example, Microsoft 365) for a staff member. They try common passwords plus many variations across thousands of accounts. In another case, they hit a router admin page exposed to the internet. They try admin usernames and cycle through password guesses until they find one that matches.
You can often spot brute-force activity through patterns like these:
- Many failed logins for one account in a short period.
- Failures across many accounts from one source address (spraying behavior).
- Logins at odd hours that don't match the user's routine.
- Repeated attempts from new locations or unfamiliar devices.
- A sudden success after many failures, followed by mailbox rules, forwarding, or config changes.
Practical defenses should slow guessing and reduce the value of a guessed password:
- Long passwords or passphrases (length matters more than complexity rules).
- Multi-factor authentication (MFA) to stop most account takeovers after a password guess.
- Rate limiting and smart throttling to slow repeated failures.
- Disable or rename default accounts, especially on network devices.
- Restrict admin interfaces to internal networks or a VPN, not the public internet.
If a login page is reachable from the internet, attackers will test it. The question is whether your controls make guessing unproductive.
Dictionary attacks, why common words still fail
A dictionary attack is a more efficient form of guessing. Instead of trying every possible character combination, the attacker tries likely passwords first. They use wordlists built from real leaks, common phrases, and predictable patterns. As a result, accounts with "human-like" passwords often fall quickly.
Attackers also add rules that mimic how people "strengthen" a password. These rules turn one word into many guesses at high speed. Common patterns include SeasonYear!, names with a number at the end, or favorite teams with a symbol. For example, Summer2026! looks complex, but it is highly predictable. In the same way, Jackson!1 and Cowboys2024 match patterns attackers expect.
This is the key contrast with brute force: brute force tries everything eventually, while a dictionary attack tries the most probable guesses first. That makes it faster in practice against typical user passwords, even when the attacker has limited attempts online.
To reduce dictionary risk, focus on choices that break predictability:
- Prefer passphrases that are long and uncommon (for example, 4 to 6 unrelated words). Length increases the search space without relying on tricky symbols.
- Avoid personal details (names, pets, birthdays, sports teams, company name). Attackers test these early.
- Use unique passwords for each site so one leak does not spread to other accounts.
- Enforce banned password lists so users cannot pick known weak choices. This stops the most common words and patterns at creation time.
MFA changes the outcome because it adds a second check after the password. Even so, MFA does not "fix" weak passwords by itself. First, some services allow legacy logins that bypass MFA. Second, attackers can still use a guessed password for password reset abuse, social engineering, or session takeover if other controls fail. Strong passwords plus MFA is the safer pairing, not either one alone.
Lockouts, MFA, and monitoring, choosing the right control for the risk
Controls for password guessing work best when you combine them, because each one covers a different weakness. Still, every control has tradeoffs. A strict lockout policy can stop brute-force attempts, but it can also create a new problem: denial of service. An attacker may intentionally lock many accounts, which blocks real users and floods the help desk.
MFA reduces account takeover risk because a guessed password alone is not enough. However, you still need good password hygiene, since MFA prompts can be abused through fatigue tactics, and some login paths may not enforce MFA. Monitoring closes another gap because not every attack is loud. Some attackers guess slowly to avoid lockouts and rate limits.
The table below summarizes practical choices and the main tradeoffs:
| Control | What it stops best | Main downside | Good fit |
|---|---|---|---|
| Account lockout after repeated failures | Fast online brute force | Can be abused to lock out users | Small user groups, high-value accounts |
| Rate limiting and progressive delays | Repeated guessing without full lockout | Can still allow slow spraying | Public-facing logins, large orgs |
| MFA (app, token, or biometric factor) | Most takeovers after password guessing | Doesn't remove need for strong passwords | Email, VPN, admin roles |
| Monitoring and alerting | Slow attacks and unusual logins | Needs tuning to avoid alert fatigue | Any environment with centralized logs |
In practice, a balanced setup often works best: use rate limiting instead of harsh lockouts for broad user bases, require MFA for remote access and privileged accounts, and then monitor for behavior that does not match normal use. For example, alert on repeated failures across many accounts, logins from new countries, or sudden changes after a successful login.
Choose controls based on impact. If an account controls payments or admin access, treat it as high-risk and add stronger friction.
Insider Threats
An insider threat occurs when a person with legitimate access (employee, contractor, or vendor) harms security on purpose or by mistake. For CompTIA A+ Core 2 (220-1202), Domain 2, Objective 2.5, you should understand why this risk is different from outside attacks, because the "attacker" may already have passwords, badges, and access that look normal in logs. As a result, insider events often blend into everyday work traffic and routine system changes.
Unlike brute-force or phishing, insider issues often start with a normal login and approved tools. That makes the early stage look harmless. The goal is not to suspect everyone, but to reduce the chance that one account, one device, or one bad decision can cause broad damage.
Malicious insiders vs careless mistakes, know the difference
A malicious insider is someone who misuses authorized access on purpose. The motive may be money, anger, or pressure from a competitor. For example, a departing employee copies a customer list to a personal drive, or an admin quietly creates a hidden account for later use.
A careless insider (sometimes called a negligent insider) causes harm without intent. Mistakes happen during busy work. For example, a staff member emails a spreadsheet with sensitive data to the wrong address, stores files in a public cloud folder, or clicks "approve" on an unexpected MFA prompt.
Both types are hard to detect because they can look like real work. A malicious insider may move slowly, access only what they already use, and act during business hours. Meanwhile, careless actions are common and noisy, so teams can miss the one mistake that matters. In addition, insiders often use approved services (email, SharePoint, Teams, Google Drive), which reduces obvious malware signals.
Watch for behavior that doesn't fit the role or the routine. The signs below do not prove wrongdoing, but they justify a closer look and a calm check-in:
- Odd file access patterns: A user opens many records they don't normally touch, such as HR files by a non-HR role.
- Large downloads or bulk copying: Sudden exports, mass printing, or syncing whole folders to a new device.
- Policy bypass attempts: Repeated use of personal email, unapproved cloud storage, or "shadow IT" tools to move data.
- Repeated permission requests: A spike in requests for shared drives, admin tools, or finance apps without a clear need.
- Unusual access times or locations: Late-night access, weekend logins, or new geographies that don't match prior history.
- Disabling or avoiding controls: Turning off endpoint protection, clearing browser history, or insisting on "temporary" exceptions.
Insider threats rarely announce themselves. Look for patterns over time, not one isolated event.
Controls that limit damage without assuming everyone is bad
Good insider threat controls focus on reducing blast radius, not blaming staff. People need access to do their jobs, so the goal is to set safe boundaries and make risky actions harder. When controls are fair and consistent, they also protect employees from false accusations, because the system records what happened.
Start with access design. Least privilege means users get the minimum access they need, then nothing more. This reduces the harm from both intent and error.