Common Threats and Safe User Practices

Recognizing Everyday Security Risks

Foundational security means knowing the threats that show up in normal support work. The exam favors realistic scenarios over jargon.

Threat catalog

Phishing is the most common entry point. Treat reports of suspicious messages seriously, do not click the link from the user's session to "investigate," and follow the reporting process. Social engineering bypasses technical controls entirely; the defense is to verify unusual requests — passwords, MFA codes, payment changes, remote access, urgent exceptions — through a separate trusted channel, never by replying to the suspicious message.

Malware response

Symptoms (pop-ups, disabled security tools, unknown extensions, renamed/encrypted files, strange network traffic) justify careful triage but are not proof alone. Do not download a random "cleaner" from a web search — that is often how more malware arrives. Preserve the device state if policy requires it, disconnect from the network only if instructed, and escalate to security/IT. Ransomware specifically encrypts files for extortion, which is why reliable offline or versioned backups are a genuine security control.

Wireless-specific threats

A rogue access point is an unauthorized AP connected to or near the network; an evil twin imitates a legitimate SSID to lure users onto an attacker's AP, where traffic can be intercepted. Defenses: define approved SSIDs, train users not to join look-alike names, and treat open public Wi-Fi as untrusted. A VPN, HTTPS, and avoiding sensitive admin work on public Wi-Fi reduce exposure, but the strongest control is connecting only to known, approved networks.

Unpatched devices and exposed services

A router, camera, NAS, printer, or server running old firmware may carry known vulnerabilities. Port forwarding to remote desktop (RDP) or a camera web page exposes weak services straight to the Internet, and default credentials make it far worse. Basic but powerful controls: apply vendor updates, disable unused services, restrict management access, and replace unsupported (end-of-life) hardware.

Incident posture (what NOT to do)

Collect who, what, when, where, how: affected user, device name, IP, network, safe screenshot or error text, suspicious sender, the URL shown, time of event, and actions already taken. Then:

• Do not delete emails, wipe devices, or reset accounts unless the procedure says so — you may destroy evidence.
• Do not declare a system "clean" after a quick look.
• Do not put the user's password in the ticket.
• Escalate when credentials may be exposed, sensitive data is involved, malware is suspected, unauthorized access is possible, or a device's management interface may be compromised.

Spotting phishing in a real message

The exam likes concrete tells. A phishing email often shows a display name that does not match the actual sender domain ("IT Help Desk" from a random free-mail address), a look-alike or shortened URL that does not point to the real company domain when you hover, urgency or fear ("your account will be closed in 24 hours"), unexpected attachments, and requests for credentials, codes, or payment changes. Hovering over a link to read its true destination — without clicking — is a safe inspection step you can teach users. The reply address is also revealing: legitimate password resets never ask you to send the password back.

The difference between a threat, a vulnerability, and an exploit

These three terms appear in security objectives and are easy to confuse. A vulnerability is a weakness, such as an unpatched router with a known flaw or a default password still in place. A threat is something that could act against that weakness, such as a botnet scanning the Internet for that exact router model. An exploit is the actual technique or code that takes advantage of the vulnerability.

Risk rises when a real threat can reach an unpatched vulnerability with a working exploit — which is exactly why patching, disabling unused services, and changing defaults matter: they remove the vulnerability so the threat has nothing to act on.

Common traps

• "Helpfully" approving an MFA prompt to stop the noise — that hands an attacker the login.
• Investigating a phishing link from the victim's own session.
• Running an unknown cleanup tool on a suspected-malware machine.
• Confusing a vulnerability (the weakness) with the threat (the actor) or the exploit (the technique).
• Declaring a device "clean" after a surface check rather than escalating to the people and tools that can confirm it.