Skip to content
FR

Vulnerabilities and Malicious Activity

Step 7 of 28

Security+ Vulnerabilities, Malware, and Attack Indicators

Introduction

This lesson continues Domain 2, Threats, Vulnerabilities, and Mitigations (22% of SY0-701). It covers objective 2.3 (explain various types of vulnerabilities) and objective 2.4 (given a scenario, analyze indicators of malicious activity). In the first lesson of the domain you learned who attacks and how they reach you. Here you learn what weaknesses they exploit and what the evidence looks like when they do.

Security+ attack indicators include unusual outbound traffic, authentication failures, and suspicious web requests. Correlate these signals with logs and context: a slow workstation or a quote mark accepted by a form does not establish an attack. For each category, distinguish the weakness, the attempted technique, and evidence that exploitation succeeded.

Learning objectives

After this lesson you will be able to:

  • Differentiate malware types: ransomware, trojans, worms, spyware, bloatware, viruses, keyloggers, logic bombs, rootkits.
  • Recognize password attacks: brute force, dictionary, spraying, credential stuffing, and rainbow tables.
  • Identify application attacks: injection, buffer overflow, race conditions, cross-site scripting, cross-site request forgery, privilege escalation, forgery, directory traversal, replay.
  • Identify network attacks: DDoS, DNS attacks, on-path (man-in-the-middle), wireless attacks, and credential replay.
  • Describe vulnerability classes in hardware, operating systems, cloud, virtualization, mobile devices, supply chain, and zero-days.
  • Read indicators of compromise (IoCs) in logs and symptoms.

1. Malware

Malware is software designed to harm or abuse a system. The exam classifies it by behavior, not by name.

Type Defining behavior Typical indicator
Virus Infects a host file or program and replicates when that host code executes Modified executables, unexpected file growth
Worm Self-replicates across the network without user action Sudden network congestion, many outbound connections
Trojan Appears legitimate but carries a hidden payload Software that does more than advertised
Ransomware Encrypts data and demands payment; often exfiltrates first Renamed files, ransom note, mass file modification
Spyware Collects information secretly Unknown processes sending data out
Keylogger Records keystrokes Credentials misused after typing on a given device
Rootkit Hides itself and other malware at a low level (kernel or firmware) Security tools disabled, mismatched process lists
Logic bomb Code that triggers on a condition such as a date or a user removed from payroll Destructive event at a specific time
Bloatware Unnecessary bundled or preinstalled software; not inherently malicious Slower devices, extra attack surface
Botnet agent Turns the host into a remote-controlled "bot" Beaconing to a command-and-control (C2) address
Fileless malware Runs in memory using legitimate tools like PowerShell Memory-resident execution, suspicious script or process activity; disk artifacts may still exist

Key distinctions:

  • Virus vs worm: viruses depend on execution of infected host code, which may be triggered automatically; worms self-propagate.
  • Trojan vs virus: trojans do not replicate; they rely on deception.
  • Rootkit: its purpose is concealment, so antivirus on the infected host may not see it. Isolate and preserve evidence, then rebuild from trusted media. Suspected firmware compromise requires firmware-specific recovery or hardware replacement; an OS reinstall alone may be insufficient.
  • Ransomware: modern gangs practice double extortion: they steal data and then encrypt, so restoring from backup does not remove the leak risk.

Example 1: reading ransomware indicators

Scenario. At 02:14 an analyst sees 40,000 file renames in ten minutes on a file server, each given the extension .locked, followed by a text file named README_RESTORE.txt in every folder. The server's endpoint agent was stopped one hour earlier by a service account.

Analysis. The mass rename and note are ransomware. The stopped agent suggests defense evasion; review its logs and account activity rather than assuming how access was gained. First isolate the server, preserve evidence, and scope the compromise. Remove persistence and close the entry path before restoring verified clean backups in a controlled recovery environment. Network isolation limits spread but does not stop local encryption already running. Paying is not a control.

For the containment and recovery sequence, see incident response planning and forensic evidence.

2. Password attacks

Attack How it works Best defenses
Brute force Tries every possible combination Long passwords, account lockout or throttling, MFA
Dictionary Tries common words and variations Password blocklists, length
Password spraying One or a few common passwords tried against many accounts to avoid lockout MFA, monitoring for failed logins across many accounts, blocking common passwords
Credential stuffing Replays username/password pairs leaked from another breach MFA, unique passwords, breached-password checks
Rainbow table Precomputed hash lookups Salting hashes
Offline cracking Cracking stolen hashes with GPUs Salted adaptive password hashing (for example Argon2id), suitable cost settings, long unique passwords

Indicators: many guesses against one account suggest focused brute force; one or a few guesses distributed across many accounts suggest password spraying. Successful logins from unfamiliar locations merit investigation, but establish credential stuffing with evidence of reused, leaked credential pairs. Attacks can use multiple source addresses.

Review MFA, provisioning, and privileged access management to connect these attacks to identity controls.

Worked example: distinguishing spraying from brute force

Scenario. The authentication log shows 1,200 failed logins in an hour. Each of 400 distinct user accounts has three failed attempts. A controlled attack simulation confirms that the same candidate password, Summer2026!, was reused; ordinary authentication logs should not record plaintext passwords. The lockout threshold is five attempts.

Step by step.

  1. Count per account: only three attempts per account, below the lockout threshold. That is a deliberate choice to remain under the radar.
  2. Use the simulation evidence: one password across many accounts. Brute force would try many passwords against one account.
  3. Conclusion: password spraying.
  4. Why not credential stuffing? Stuffing uses different, previously leaked pairs for each account, not one common password.
  5. Response: enforce MFA, block the sprayed password, alert on failures across accounts per source, and check for successful logins from the same source.

3. Application attacks

Attack Description Defense
SQL injection Untrusted input is inserted into a database query Parameterized queries, input validation, least-privilege DB accounts
Command injection Untrusted input changes a shell command Prefer structured APIs, avoid shell interpretation, allowlist expected input
Cross-site scripting (XSS) Script injected in a page runs in other users' browsers (stored, reflected, DOM) Context-aware output encoding; sanitize permitted HTML; CSP as an additional layer
Cross-site request forgery (CSRF) A victim's browser is tricked into sending an authenticated request Server-validated anti-CSRF tokens and origin checks; SameSite as defense in depth
Buffer overflow Data exceeds a memory buffer and overwrites adjacent memory Bounds checking, memory-safe languages, ASLR
Race condition (TOCTOU) Outcome depends on timing between check and use Locks, atomic operations
Directory traversal ../ sequences reach files outside the web root Canonicalize paths, restrict file access
Privilege escalation Gaining higher rights (vertical) or another user's rights (horizontal) Patching, least privilege
Replay Valid authentication data captured and resent Enforce freshness with one-use challenges/nonces and checked validity windows; a reusable session token can itself be replayed
Server-side request forgery (SSRF) Server tricked into requesting internal resources Allowlists, network egress controls
Session hijacking Stealing a session ID Secure and HttpOnly cookies, TLS, short sessions

A short code example shows the difference between a vulnerable and a safer query:

Python
# Vulnerable: input is concatenated into SQL
query = "SELECT * FROM users WHERE name = '" + name + "'"
# name = "x' OR '1'='1"  ->  returns every user

# Safer: parameter binding with a Python driver using %s placeholders
cursor.execute("SELECT * FROM users WHERE name = %s", (name,))

The driver binds name as a value instead of SQL syntax. Placeholder syntax is driver-specific (%s here); never use Python string interpolation to fill it. Dynamic table or column names require a separate allowlist.

Indicators in logs: web requests containing ' OR 1=1, UNION SELECT, <script>, ../../etc/passwd, or very long strings of repeated characters.

Example 2: choosing between XSS and CSRF

Scenario. A forum lets users post comments. An attacker posts a comment containing a script that sends every visitor's session cookie to the attacker's server. Visitors do not click anything.

Analysis. The script is stored in the site and runs in visitors' browsers: stored XSS. CSRF would involve a forged request to the site using the victim's existing session, not script execution. Use output encoding appropriate to the rendering context, or a maintained sanitizer when users may author HTML. Add a restrictive CSP as defense in depth. HttpOnly prevents JavaScript from reading a cookie, but XSS can still act through the victim’s authenticated browser.

4. Network attacks

  • Distributed denial of service (DDoS): many sources overwhelm a service. Types include volumetric, protocol (SYN flood) and application-layer. Mitigation: upstream scrubbing, rate limiting, and appropriately configured CDN/DDoS protection. Autoscaling can absorb some load but cannot prevent link saturation and can increase costs.
  • DNS attacks: cache poisoning, DNS hijacking, and DNS tunneling (hiding data in DNS queries). Mitigation: validate DNSSEC signatures for signed DNS data to resist forged answers, protect registrar and DNS-administration accounts, and inspect resolver traffic for tunneling. DNSSEC does not encrypt DNS or prevent exfiltration through otherwise valid queries.
  • On-path attack (formerly man-in-the-middle): attacker sits between two parties. Includes ARP poisoning and rogue access points. Mitigation: TLS, certificate validation, dynamic ARP inspection.
  • Wireless attacks: evil twin (rogue access point with a legitimate SSID), deauthentication, WPS attacks. Mitigation: use supported secure Wi-Fi configurations, validate enterprise authentication-server certificates, and monitor for unauthorized access points. An SSID or WPA3 support alone does not establish an access point’s legitimacy.
  • Credential replay: capturing authentication material (such as pass-the-hash) and reusing it.
  • Malicious code via network: worms and scanning traffic.

Indicators: a sudden flood of SYN packets from thousands of addresses (DDoS), repeated certificate warnings (on-path), duplicate IP-to-MAC mappings (ARP poisoning), an unknown access point with your SSID (evil twin), DNS queries with very long random-looking subdomains (tunneling).

5. Vulnerability categories

Objective 2.3 expects you to know that weaknesses exist in many layers:

Area Examples
Application Memory injection, buffer overflow, race condition, malicious update
Operating system Unpatched flaws, weak default configuration
Web SQL injection, XSS
Hardware Firmware flaws, end-of-life devices, legacy hardware
Virtualization VM escape, resource reuse
Cloud Misconfigured storage, overly broad identity permissions, exposed APIs
Supply chain Service providers, vendors, suppliers
Cryptographic Outdated algorithms, weak keys
Misconfiguration Open ports, default settings, permissive policies
Mobile Side loading, jailbreaking or rooting
Zero-day A previously unknown vulnerability is exploited before defenders have an effective fix

A zero-day attack exploits a previously unknown vulnerability. A flaw with no patch is not necessarily unknown, and a zero-day’s vendor may learn of it before a fix is released. While waiting for a fix, restrict the affected function and exposure and use behavioral detection. Known exploitation behaviors may still be detectable without a signature for the specific exploit.

Cloud vulnerabilities can affect provider infrastructure, customer workloads, or configuration. Responsibilities vary by service model: providers operate the underlying infrastructure while customers must correctly configure the identities, data access, and controls they manage. A storage bucket set to public read, an access key committed to a repository, or an administrator role granted to every developer are typical findings.

Virtualization: a VM escape lets an attacker break from a guest to the hypervisor. VM sprawl (unmanaged forgotten VMs) leaves unpatched systems running.

Mobile: jailbreaking (iOS) and rooting (Android) remove vendor protections; sideloading installs apps outside official stores. MDM can evaluate device compliance and restrict access where supported; detection depends on platform capabilities and can be evaded.

Example 3: cloud misconfiguration

Scenario. A start-up stores 2 million customer invoices in an object storage bucket. A security researcher finds that anyone can list and download the files without authentication.

Analysis. The vulnerability is a misconfiguration of access control. The fix: remove public access, apply least-privilege roles, enable access logging, and add automated configuration scanning (cloud security posture management) so that future drift is detected. Notifying affected parties may also be a legal duty.

Turn findings into a remediation plan with vulnerability scanning, logging, and detection.

6. Security+ indicators of malicious activity

Objective 2.4 asks you to analyze indicators, so build the habit of mapping a symptom to a category before you read the answer options.

Symptom observed Likely cause First action
Account lockouts for many users at once Brute force or spraying against the directory Identify the source, block it, require MFA
Impossible travel: login from two continents within an hour Possible credential misuse; check VPN/proxy and location accuracy Revoke sessions, reset the password, review activity
Out-of-hours access to unusual data Insider misuse or stolen account Review the account's permissions and logs
Resource consumption spike (CPU, bandwidth) with no business reason Cryptomining malware, DDoS participation or a worm Isolate the host and inspect processes
Missing or altered logs Attacker covering tracks Preserve remaining logs and forward logs to a central, write-protected store
Concurrent sessions from different places for one user Possible hijacking, sharing, or legitimate multi-device use Terminate sessions and investigate
Blocked content or outdated content on a web page Defacement or hijacked DNS Compare DNS records and restore from known-good content
Out-of-cycle or out-of-band beaconing at fixed intervals Command-and-control traffic Block the destination and hunt for the process
Published or leaked credentials Earlier breach Force resets and check for reuse

Resource consumption, impossible travel, concurrent sessions, and missing logs are named indicators in the exam objectives, so make sure you recognize each by its description.

Example 4: impossible travel

Scenario. A sales director's account signs in from Lisbon at 09:00 and from Singapore at 09:25. Both succeed with the correct password and a push-approval prompt that was accepted.

Analysis. This is an impossible-travel signal, not proof of compromise: compare device, VPN/proxy, session, and geolocation evidence and contact the user through a known channel. Repeated unexpected push prompts would support MFA fatigue; a single accepted prompt does not establish it. If activity is unauthorized, contain the account, revoke sessions, reset affected credentials, and inspect MFA registrations and token use. Number matching reduces push-approval abuse; FIDO/WebAuthn provides phishing resistance.

7. Comparison: telling similar attacks apart

Pair Key difference
Virus vs worm Infects host code that must execute vs self-propagates
Spraying vs brute force Few passwords across many accounts vs many passwords against one account
Spraying vs stuffing Common password guesses vs real leaked pairs
XSS vs CSRF Script runs in victim's browser vs victim's browser sends a forged request
SQL injection vs command injection Database query vs operating system shell
Evil twin vs on-path Rogue access point impersonating an SSID vs any interception between two parties
Zero-day vs unpatched Exploits a previously unknown flaw vs an update has not been applied; “unpatched” alone does not establish zero-day status
Rootkit vs trojan Hides at a low level vs pretends to be useful

8. Common pitfalls

  • Choosing "antivirus" for every malware scenario; for a rootkit or fileless malware, endpoint detection and response (EDR) or reimaging may be better.
  • Reaching for "patch it" when the vulnerability is a zero-day or the system is unsupported.
  • Confusing a DDoS with a legitimate traffic spike. Check whether sources and requests look normal.
  • Believing the cloud provider fixes customer misconfigurations.
  • Thinking account lockout alone defeats spraying; the attacker stays beneath the threshold.
  • Thinking HTTPS prevents injection; encryption protects transport, not the logic of the application.

9. Exam tips

  • "Same password, many accounts" means spraying; "leaked list from another site" means credential stuffing.
  • "Input is part of the query" means injection; "parameterized queries" is almost always the fix.
  • Concealment from normal OS tools suggests a rootkit; execution primarily in memory suggests fileless techniques. Neither symptom alone proves a specific malware family.
  • "Triggered on a date or event" means logic bomb.
  • "Unknown to the vendor" means zero-day, so choose compensating controls.
  • A rogue access point with a legitimate name is an evil twin.

10. Mini case study

Case. Northwind Retail reports four events in one week:

  1. The web team sees requests such as /download?file=../../../etc/passwd returning system files.
  2. The help desk sees dozens of customers whose accounts were accessed using correct passwords from new countries; the same email and password pairs appeared in a public breach of a gaming site.
  3. A storage bucket containing delivery photos is found readable by anyone.
  4. A finance workstation shows a hidden process and its antivirus is silently disabled; an analyst's process list differs from what a kernel-level tool reports.

Tasks. Name each issue and recommend the best response.

Solution.

  1. Directory traversal. Canonicalize and validate file paths, restrict the application's filesystem permissions, and deploy a web application firewall rule as a stopgap.
  2. Credential stuffing. Enforce MFA, force resets for affected accounts, add bot detection and rate limiting, and check passwords against breached lists.
  3. Cloud misconfiguration. Remove public access, apply least privilege, enable logging, and scan continuously for drift.
  4. Suspected rootkit. Isolate the machine, preserve evidence, and rebuild the OS from trusted media. Investigate firmware persistence separately before returning it to service.

Key terms

  • Malware families: virus, worm, trojan, ransomware, spyware, keylogger, rootkit, logic bomb, fileless.
  • Password spraying / credential stuffing: one password across many accounts / leaked pairs replayed.
  • SQL injection, XSS, CSRF, buffer overflow, directory traversal: classic application flaws.
  • DDoS, evil twin, on-path, DNS poisoning: network attacks.
  • Zero-day attack: exploitation of a previously unknown vulnerability.
  • VM escape, jailbreak, sideloading: virtualization and mobile weaknesses.
  • Indicator of compromise (IoC): observable evidence of an intrusion.

Summary checklist

  • I can classify malware by behavior and name its main indicator.
  • I can tell brute force, spraying, stuffing, and rainbow table attacks apart.
  • I can match injection, XSS, CSRF, overflow, and traversal to their defenses.
  • I can recognize DDoS, DNS, on-path, and wireless attacks from symptoms.
  • I can explain why cloud misconfiguration is the customer's responsibility.
  • I know what a zero-day is and why compensating controls are required.
  • I can read a short log excerpt and name the likely attack.

Sources