Vulnerabilities, Malicious Activity, and Mitigations That Stick
Application, cloud, and supply-chain vulnerabilities; IoCs for malware and network attacks; and mitigation patterns Security+ expects you to apply.
CompTIA Security+ SY0-701 Domain 2 rewards candidates who can connect three ideas in one breath: what broke, what the attacker did afterward, and what control actually closes the gap. Memorizing CVE headlines will not carry you through scenario questions. You need a repeatable mental model that works whether the stem describes a misconfigured S3 bucket, a poisoned npm package, or a finance clerk clicking a credential-harvesting link.
This post walks through vulnerability classes, malicious activity patterns, indicators of compromise (IoCs), and mitigations—with worked examples and exam traps woven in throughout.
How SY0-701 frames "vulnerability"
A vulnerability is a weakness that can be exploited to violate a security policy. That definition sounds academic until you sit down with a practice exam. The weakness might be a buffer overflow in C code, an IAM role with s3:* on *, or a reception desk that tailgates visitors without challenge. Security+ groups these into recognizable families. Your job is to name the family, spot downstream activity, and pick the mitigation that matches the failure mode—not the mitigation that merely sounds impressive.
Application and web vulnerabilities
Application-layer flaws often involve trust boundaries the developer forgot to enforce. Memory corruption (buffer overflows, injection into running processes), race conditions (time-of-check/time-of-use), and unsigned or unverified update channels all appear in objectives and in real incident reports.
Web application issues remain core literacy:
- SQL injection (SQLi) — untrusted input becomes part of a database query.
- Cross-site scripting (XSS) — untrusted input executes in another user's browser context.
- Cross-site request forgery (CSRF) — a victim's browser performs an unwanted action while authenticated.
- Server-side request forgery (SSRF) — the server is tricked into requesting internal resources.
- Directory traversal — path manipulation reaches files outside the intended directory.
Why/when/how for exam scenarios: When a stem mentions "unsanitized input" and "database records exposed," think SQLi first. Mitigation is parameterized queries (prepared statements), least-privilege database accounts, input validation, and optionally a web application firewall (WAF) as a compensating control—not "encrypt the database" alone, because encryption at rest does not stop a query that already runs with SELECT privileges.
Exam trap: Choosing "disable error messages" as the primary fix. Error suppression reduces information leakage but does not remove the injection flaw.
Operating system, hardware, and firmware
End-of-life (EOL) software, legacy protocols, and unpatched firmware create a long tail of exploitable surface. Firmware implants and weak update verification are supply-chain-adjacent problems: the device looks fine until someone controls what it boots.
Worked example: A hospital keeps Windows Server 2012 R2 on imaging workstations because the vendor has not recertified newer OS versions. The vulnerability class is legacy/EOL OS. Malicious activity might include remote exploitation of a public RCE. Mitigations in exam answers often combine segmentation (imaging VLAN isolated from corporate AD), virtual patching/IPS, strict remote access, and a vendor risk plan—not "patch tonight" when the stem explicitly forbids it.
Virtualization, cloud, and container weaknesses
VM escape and resource reuse issues (leftover data in reallocated cloud storage) show up as architecture-aware vulnerability questions. Cloud misconfiguration—public buckets, open security groups, overly broad IAM—is so common that CompTIA treats it as its own recurring theme.
| Cloud misconfiguration | Typical exploit path | Mitigation direction |
|---|---|---|
| Public object storage | Anonymous read/list of sensitive files | Block public access, bucket policies, CSPM scanning |
| Open management port (e.g., 22/3389 to 0.0.0.0/0) | Brute force or known exploit | Security groups, bastion/jump host, IP allow lists |
| Overprivileged IAM role | Lateral movement after initial compromise | Least privilege, role boundaries, permission boundaries |
| Default credentials on SaaS admin | Full tenant takeover | Change defaults, MFA on admin, audit logging |
The table is not a checklist to recite—it maps shape to response. If the question says "backup files were world-readable in object storage," the vulnerability is misconfiguration, not a novel zero-day.
Supply chain and third-party risk
Supply chain attacks compromise software, hardware, or service providers before the victim ever touches a phish. SolarWinds-style narratives and poisoned open-source dependencies both fit this bucket.
Scenario: A CI pipeline pulls a compromised library version that exfiltrates environment secrets. IoCs might include unexpected outbound connections from build agents and new DNS queries to rare domains. Mitigations: dependency pinning, software composition analysis, code signing verification, staged rollouts, and rapid rollback—not merely "train developers."
Exam trap: Labeling every third-party incident "phishing." Phishing is a delivery mechanism; supply chain is a trust failure in the provisioning path.
Other high-yield classes
- Cryptographic weaknesses — weak algorithms, poor key management, certificate validation skipped.
- Misconfiguration — the quiet giant; the "vulnerability" is how it was deployed.
- Mobile — sideloading, jailbreaking, absent MDM posture.
- Zero-day — no patch yet; compensate with detection, isolation, least privilege, and network segmentation.
Malicious activity: function over family tree
Malware taxonomy on the exam is functional. Know what each type does, not every variant name in the wild.
| Type | Behavior | Often paired with |
|---|---|---|
| Ransomware | Encrypts or exfiltrates for extortion | Initial access via phish/RDP, lateral movement |
| Trojan | Disguised legitimate software | Social engineering delivery |
| Worm | Self-propagates without user action | Unpatched services, weak credentials |
| Spyware / keylogger | Surveillance, credential capture | Fraud, espionage |
| Rootkit | Hides presence on host | Persistence after escalation |
| Logic bomb | Triggers on condition (date, event) | Insider threat narratives |
| Virus | Requires host file/program to spread | User execution |
Network and application attacks to recognize in stems: DDoS (volume, protocol, application layer; amplified/reflected variants), DNS poisoning or hijacking, wireless deauth/evil twin, on-path (MitM), credential replay, injection (SQLi/XSS/command), privilege escalation, forgery (IP, ARP, email), and typosquatting for delivery.
Password attacks: Spraying tries one common password across many accounts (avoids per-account lockout). Brute force hammers one account. Credential stuffing reuses breached pairs. Downgrade attacks force weaker crypto or auth protocols.
Physical angles: RFID cloning, environmental tampering (HVAC/sensors in ICS narratives), dumpster diving, shoulder surfing—usually supporting a larger cyber chain.
Indicators of compromise and operational weirdness
An indicator of compromise (IoC) is evidence that an intrusion may have occurred. SY0-701 loves operational signals analysts actually see—not just file hashes.
Identity and access signals:
- Spike in account lockouts (spraying) or failed logins from one IP across many users
- Concurrent sessions or impossible travel (same user, distant geos, minutes apart)
- New service accounts created overnight with admin rights
Network and endpoint signals:
- Unexpected DNS queries to young domains or DGA-like patterns
- Beaconing—regular small outbound connections at fixed intervals
- Blocked content spikes in proxy logs (users hitting known-bad categories repeatedly)
- Resource exhaustion—CPU, bandwidth, storage—especially in DDoS or cryptomining stems
Logging anomalies:
- Out-of-cycle log generation or admin "cleanup" that removes logs
- Systems that are too quiet after an update (logging service disabled)
- Missing expected audit entries when peers still log normally
Exam trap: Treating a single IoC as proof of breach. Exams may ask what to investigate first or what best indicates compromise—prioritize correlated signals.
Worked example: Finance users report slow file shares. Monitoring shows high SMB traffic at night, new .encrypted extensions, and a service account running vssadmin delete shadows. IoCs point to ransomware activity, not "need a faster SAN." Containment and restoration beat tuning performance counters.
Mitigations that map to failure modes
Effective mitigations answer: What property of the system failed? Layered controls are good; misaligned controls are exam distractors.
| Failure mode | Primary mitigation direction | Common distractor |
|---|---|---|
| Excess privilege | Least privilege, JIT, PAM | "Buy a new firewall" |
| Known unpatched vuln | Patch mgmt, prioritization (CVSS + asset context) | Full disk encryption |
| Flat network | Segmentation, isolation, microsegmentation | Stronger password policy only |
| Soft endpoints | Hardening baselines, EDR | Annual pen test only |
| Risky execution | Application allow listing, sandboxing | Block all USB (may help, rarely primary) |
| Credential theft | MFA, monitoring replay, secure vaulting | Complex passwords without MFA |
| Ransomware | Offline/immutable backups + tested restore | Antivirus alone |
| SQLi | Parameterized queries, input validation | Hide error pages only |
Patch management nuance: CVSS score alone is insufficient when the stem says "this server is internet-facing and runs the vulnerable service." Context drives priority.
Encryption caveat: Encrypting data at rest does not stop ransomware operating as the authenticated user, nor SQLi running with DB read rights. Encryption protects confidentiality at rest/in transit—it is not a substitute for access control and input handling.
Scenario drill 1: Web app data leak
Stem: A customer portal returns other users' order history when the order_id parameter is changed.
Classification: Insecure direct object reference (IDOR) / authorization failure—often grouped with application vulnerabilities.
IoCs: Unusual access patterns, many order IDs enumerated, support tickets about wrong orders.
Mitigations: Server-side authorization checks on every request, session binding to identity, logging and alerting on enumeration, WAF rate limiting as supplement.
Scenario drill 2: Vendor update compromise
Stem: Several firms install the same vendor patch Tuesday; Wednesday, C2 traffic appears from those hosts.
Classification: Supply chain / malicious update.
IoCs: New processes signed but unexpected, identical beaconing across unrelated orgs, hash mismatch vs vendor-published manifest.
Mitigations: Verify signatures and hashes, staged deployment rings, network detection for new outbound behavior, vendor coordination, rollback images prepared.
Scenario drill 3: Cloud bucket exposure
Stem: Researchers find employee PII in a public bucket named like your company.
Classification: Cloud misconfiguration (not zero-day).
IoCs: Public ACL/policy, sensitive object prefixes, scanner traffic in access logs.
Mitigations: Remove public access, CSPM continuous checks, data classification preventing PII in unapproved stores, IR notification per regulation.
Ransomware as a cross-domain case study
Ransomware questions tie Domain 2 to architecture and operations. Initial access might be phish (social engineering), stolen RDP (weak credentials/no MFA), or unpatched VPN (known vulnerability). After entry: privilege escalation, lateral movement, credential dumping, shadow copy deletion, encryption.
Mitigations that exams accept as primary:
- Segmentation to limit spread
- EDR for behavioral detection
- Immutable/offline backups with tested restore
- MFA and least privilege to reduce initial access
- Incident response plan with communication tree
Exam trap: "Pay the ransom" or "decrypt with free tools" as first steps—never primary governance answers.
Building exam muscle memory
For every practice question, force this sentence:
> "This is a ___ vulnerability, indicated by ___, mitigated primarily by ___."
If you cannot fill the blanks, you are guessing between buzzwords. Domain 2 becomes manageable when you classify first and only then reach for tools.
Quick self-test:
- Public S3 bucket with PHI — vulnerability class? IoC? Top mitigation?
- Same password tried against 5,000 accounts — attack type? IoC? Mitigation?
- EOL Linux box on DMZ — compensating controls when patch is impossible?
- Logs deleted after hours — IoC or mitigation? What next?
Answers should flow: misconfiguration / public access logs / block public access and CSPM; password spraying / lockout patterns / MFA and lockout policies; segmentation and virtual patching; IoC of cover-up / preserve evidence and investigate.
Domain 2 is not a catalog of horrors—it is a decision tree. Learn the tree, and the scenarios stop feeling random.