Security+ 801 Countdown, T-29: Objective 2.4 Rebuilt Around Attack Surfaces, Secrets, and Public Buckets

An attack surface is the set of points on a system’s boundary where an attacker “can try to enter, cause an effect on, or extract data” (NIST, n.d.). The definition is deliberately wide. An open database port, a laptop that never enrolled in device management, and a storage bucket that answers anonymous requests all qualify, and none of them is a bug in the usual sense. They are conditions: an asset exists in a state the organization did not choose, or did not notice. A vulnerability, by contrast, is a specific weakness that an attack can exploit, and the classic ones (injection, buffer overflows, race conditions) live in code. Security work at the attack-surface level is therefore mostly inventory and configuration review rather than code review: find every asset, decide what state it is in, and close or justify everything it exposes.

SY0-801 objective 2.4, “Explain types of vulnerabilities and attack surfaces,” expands the vulnerability objective to cover exactly that view, with asset states (unsupported products and unpatched, obsolete, and unmanaged systems), unauthorized presence on the network (rogue devices and Shadow IT), and three leak paths (hardcoded secrets, public repositories, and public object storage) listed alongside code-level items such as race conditions (TOC, TOU), malicious updates, and unsafe exception handling (CompTIA 2025). Basically, the objective asks two questions of every asset: what condition is it in, and what does it expose.

Four asset states on one operating system

CompTIA defines none of the four asset states, so these working definitions are my reading of the terms:

• Unpatched: a fix exists but is not installed.
• Unsupported: the vendor no longer ships fixes, so none will exist.
• Obsolete: superseded or end-of-life technology that may still receive paid fixes.
• Unmanaged: the asset exists but sits outside patch management, MDM, EDR, or the inventory.

The four are separated by one question: does a fix exist, and if so, who is responsible for applying it. Zero-day is the contrast case at the far end: no fix exists because the flaw was “previously unknown” (NIST, n.d.), so no amount of patch discipline would have helped.

Windows 10 puts all four states on a single operating system. Support ended October 14, 2025, and only version 22H2 is eligible for Extended Security Updates (ESU): paid commercial ESU for at most three years, and consumer ESU through October 12, 2027 (Microsoft, n.d.a; Microsoft, n.d.b). A 22H2 PC enrolled in ESU and current with its updates is obsolete but supported. The same PC missing the latest ESU update is unpatched. A 21H2 PC, or any PC not enrolled in ESU, is unsupported: no fix will ever ship for it, however diligent its owner. Any of them without a reporting patch agent or EDR sensor is also unmanaged, whichever other state it is in, because the organization has no way to know.

Unmanaged is the state that hides the others, and fixing it starts with inventory: you cannot patch an asset you never discovered. CISA’s Binding Operational Directive 23-01 made that concrete for federal agencies, requiring automated asset discovery every 7 days and vulnerability enumeration of the discovered assets every 14 days (CISA 2022). The two cadences are the point. Discovery finds the asset; enumeration finds its state.

Rogue devices and Shadow IT

Two more bullets turn on authorization rather than maintenance (again, my interpretation, since CompTIA defines neither). A rogue device is unauthorized hardware on your network, such as a consumer Wi-Fi router plugged into a conference-room jack or a Raspberry Pi left as a drop box; it is found through network access control (covered at T-14), DHCP lease review, or the same discovery scans that find unmanaged systems. Shadow IT is unsanctioned software or services adopted by staff, such as a team’s personal file-sharing account; the asset is real and in daily use, but the organization never approved it and cannot secure what it does not know about. An unmanaged system may be fully authorized; it simply has no agent. The bare “Rogue” under 2.5 network attacks is a different item (T-26).

Ports and services

Ports and services is the most measurable surface in the objective: every listening service is an exposure to justify or close. One constructed nmap -sV line from a web server at 192.0.2.25 carries three 2.4 bullets at once:

PORT     STATE SERVICE VERSION
3306/tcp open  mysql   MySQL 8.0.42-0ubuntu0.20.04.1

The database listens beyond localhost, so it should be bound to 127.0.0.1 or firewalled (T-16); that is the ports-and-services exposure. The version string marks Ubuntu 20.04, whose standard security maintenance ended May 2025: the host is obsolete, and unsupported unless Ubuntu Pro ESM (to May 2030) covers it (Canonical, n.d.b). A banner is evidence, not proof. For many packages, OpenSSH among them, Ubuntu backports security fixes without changing the upstream version number, so confirm against the vendor’s security notices before calling the host unpatched (Canonical, n.d.a).

Race conditions: the state checked is not the state used

A race condition is a flaw in which the correctness of an operation depends on the timing of events the program does not control. The time-of-check to time-of-use (TOCTOU) variant, which objective 2.4 names as “Race conditions (TOC, TOU),” is the one that matters for security: a program checks a condition, the condition changes, and the program then acts on the stale result. In the classic example from CWE-367, a setuid program checks whether the user may write a file with access(), then opens it by name with fopen(); a symbolic link swapped in between the two calls redirects the privileged write to a file the user could never have touched directly (MITRE, n.d.b). The defect is the gap between the check and the use, and the fix is to remove the gap: open once, and act on the handle you hold rather than on a name that can be repointed.

The same shape appears at the hypervisor boundary. CVE-2025-22224 is a TOCTOU flaw in VMware ESXi and Workstation that lets a virtual machine’s local administrator run code as the VMX process on the host, which is the classic VM escape scenario, and Broadcom’s advisory of March 4, 2025 said exploitation “has occurred in the wild” (Broadcom 2025). A race condition is an application bug, but when the application is the hypervisor, the exposed asset is every guest on the box.

Hardcoded secrets outlive the commit that deletes them

A hardcoded secret is a credential written into source code or configuration that ships with the software. CWE-798 covers products that contain “hard-coded credentials, such as a password or cryptographic key” (MITRE, n.d.c). Its practical danger in modern development is git history. In a throwaway repository, commit 920cd18 put a fake AWS key pair in settings.py; the next commit replaced it with boto3.client("s3"), which reads credentials at runtime, the way the code should have been written from the start. Real gitleaks 8.30.1 output, trimmed:

$ gitleaks dir . --redact
INF no leaks found

$ gitleaks git . --redact -v
Finding:     REDACTED
RuleID:      aws-access-token
File:        settings.py
Line:        4
Commit:      920cd18b0ac88d43b6ca4604969e2dc48683e13f
WRN leaks found: 2

The working tree is clean; the history is not, and every clone carries every commit. The directory scan finds nothing; the history scan finds two leaks in the commit that introduced them. Gitleaks exits 1 on findings, which fails a CI job, and the same scanner run against staged changes only works as a pre-commit hook, stopping the secret before it ever enters history.

Response order is where candidates slip. OWASP lists containment as revocation, rotation, deletion, and logging, and GitHub’s first step is to “revoke and/or rotate that secret” (OWASP Foundation, n.d.; GitHub, n.d.b). For an AWS key, abbreviated to its verbs, the sequence is:

# 1. deploy a replacement key to everything that used the old one
# 2. deactivate the old key
aws iam update-access-key --status Inactive
# 3. search CloudTrail for any use of the old key
aws cloudtrail lookup-events        # filter on AccessKeyId
# 4. delete the old key
# 5. only now purge the history and force-push
git filter-repo --sensitive-data-removal

The order is deliberate. Forks and existing clones keep the secret, so a purge never substitutes for revocation; it only shrinks the number of places a dead key can be found.

“Public repositories” has no CompTIA definition, and two readings fit. One is public code hosting, which adversaries search for “accidentally leaked credentials or API keys” (MITRE, n.d.d); GitHub detected over 1 million leaked secrets on public repositories in the first eight weeks of 2024 (Tooley and Claessens 2024). The other is public package registries, where typosquatted packages deliver malicious code, overlapping the Malicious update bullet. Under either reading the repository is the channel, and the hardcoded secret remains the weakness.

Secrets scanning as the paired control

SY0-801 pairs the exposure with a control: objective 4.1, “Repositories,” carries the single sub-bullet “Secrets scanning” (CompTIA 2025). In GitHub’s implementation, secret scanning runs free on public repositories across every branch’s history, plus issues, pull requests, discussions, and wikis. Push protection is the preventive half: it blocks a supported secret before the push lands, became the default for pushes to public repositories on February 29, 2024, and can be bypassed with a stated reason (GitHub, n.d.a). Secret scanning detects what is already there; push protection keeps the next one out.

Unsafe exception handling fails two ways

An exception handler decides what a program does when something goes wrong, and unsafe exception handling is the family of flaws in which that decision either tells the attacker too much or quietly grants what the failed check was meant to deny. The first failure is a leak: CWE-209 covers an error message “that includes sensitive information about its environment, users, or associated data” (MITRE, n.d.a). A browser-visible traceback from a search for O’Brien, ending in sqlite3.OperationalError: near "Brien": syntax error, reveals the database engine and proves that input reaches SQL unescaped: the apostrophe in the name closed a string literal early, and the parser choked on what followed. Parameterize the query, log the detail server-side, and return a generic message to the client.

The worse failure is failing open (CWE-636, a child of CWE-755):

def can_read(user, doc):
    try:
        return policy_check(user, doc)
    except Exception:
        return True   # a policy-service timeout grants access

When policy_check times out, the handler swallows the exception and returns True, and a guest reads payroll.xlsx. The fail-closed version catches the specific timeout exception, returns False, and alerts, so that an outage in the policy service degrades into denied requests rather than open ones. OWASP made A10:2025 “Mishandling of Exceptional Conditions” a new category covering CWE-209 and CWE-636 (OWASP Foundation 2025). This coding flaw is distinct from “Failure modes” in objective 3.2, which is an appliance design choice (T-20); SY0-801 pairs unsafe exception handling with static code analysis in 4.1 (T-16) and source code review in 4.3 (T-13).

Public object storage: one policy, four switches

Object storage holds files (objects) in named containers (buckets) and serves them over HTTP, which makes it the easiest service in a cloud account to expose to the entire internet with a single policy. AWS’s own static-website policy, which can be attached only after Block Public Access is turned off, is the canonical example:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "PublicReadGetObject",
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
  }]
}

S3 treats this policy as public because the principal is "*" and no fixed-value condition key, such as aws:SourceVpc or an aws:SourceIp range narrower than /8, restricts it (Amazon Web Services, n.d.a). The policy is legitimate for a website; the exposure is attaching it to a bucket that holds anything else. Detection is a single call: aws s3api get-bucket-policy-status returns "IsPublic": true, and AWS Security Hub CSPM fails controls S3.2, “S3 general purpose buckets should block public read access” (Critical), and S3.8 (High) (Amazon Web Services, n.d.b). Cloud security posture management as a 4.3 method is covered at T-13.

Prevention belongs at the account level, where a bucket owner cannot undo it:

aws s3control put-public-access-block --account-id 123456789012 \
  --public-access-block-configuration '{"BlockPublicAcls": true, "IgnorePublicAcls": true, "BlockPublicPolicy": true, "RestrictPublicBuckets": true}'

The four switches divide the work. BlockPublicAcls rejects new public ACLs, IgnorePublicAcls neutralizes existing ones, BlockPublicPolicy rejects a policy like the one above, and RestrictPublicBuckets blocks anonymous and cross-account access through an existing public policy. The settings override policies and ACLs without deleting them, so switching them off re-exposes whatever remains underneath. New buckets have had all four on since April 2023, but that default never touched existing buckets (Amazon Web Services 2023). Azure’s AllowBlobPublicAccess property and Google Cloud Storage’s public access prevention are the equivalents. Presigned URLs are the subtler exposure: each carries the signer’s permissions for up to 7 days from the AWS CLI, so a URL pasted into a ticket is bearer access for a week, with no bucket policy involved.

What you need to know for SY0-801

• Unpatched: a fix exists. Unsupported: none will ship. Obsolete: superseded, possibly still supported. Unmanaged: outside patch, MDM, or EDR tooling. No fix because the flaw was unknown: zero-day.
• Hardware on the wire: rogue device. Unapproved app or SaaS account: Shadow IT. Known asset with no agent: unmanaged system.
• Every listening service is a ports-and-services exposure; a version banner is evidence of patch state, not proof.
• A hardcoded secret (CWE-798) is the weakness, even in a private repository; a public repository is the channel that makes it world-readable.
• Leaked key: revoke and rotate first, then purge history. Push protection prevents; secret scanning detects. The 4.1 control is “Secrets scanning” under “Repositories.”
• Unsafe exception handling has two forms: verbose errors (CWE-209) and failing open (CWE-636).
• TOCTOU: the state checked is not the state used.
• For storage readable by anyone, “Public object storage” is likely the intended answer over “Misconfiguration”; that is test-taking judgment, not CompTIA guidance.
• Injection and buffer overflow are 2.5 application attacks, not 2.4 vulnerabilities; SQL injection, XSS, and VM escape are 701-era vocabulary, and the 2.4 list is not exhaustive.

Check yourself

1. A lab has six Windows 10 Pro version 21H2 PCs. Each reports to EDR and has every available update installed. Which SY0-801 term best describes these PCs?

• A. Unpatched systems.
• B. Unsupported products.
• C. Unmanaged systems.
• D. Zero-day.

Answer: B. Windows 10 Pro has had no updates since end of support on October 14, 2025, and only 22H2 can enroll in ESU, so these PCs will receive no further fixes. They are managed (EDR reports), nothing available is missing, and no unknown flaw is described.

2. A developer pushes an AWS access key to a public repository, then pushes a commit deleting it an hour later. What should the security team do first?

• A. Rewrite history with git filter-repo and force-push.
• B. Make the repository private.
• C. Deactivate the exposed key and issue a replacement.
• D. Enable push protection.

Answer: C. The key remains in history and may already sit in clones or forks, so revoke and rotate it first; the other options do nothing about copies that already exist.

3. A CSPM tool flags a bucket whose policy grants s3:GetObject to principal "*". The security lead wants no bucket in the account to be public, including through existing policies. Which control best meets the requirement?

• A. Delete the bucket’s policy.
• B. Enable all four Block Public Access settings at the account level.
• C. Enable default bucket encryption.
• D. Share objects through 7-day presigned URLs.

Answer: B. Account-level Block Public Access rejects new public policies and neutralizes existing ones for every bucket. Deleting one policy fixes one bucket, encryption does not stop anonymous reads, and presigned URLs remain bearer access.

This is T-29 of the Security+ 801 Countdown: one change from SY0-701 to SY0-801 every morning until the new exam launches on November 17, 2026. Tomorrow, T-28: Sessions, Identity Providers, and MFA Bypass Join the Attack Surface. New here? Start with T-38: The Blueprint Was Reweighted and Trimmed to 27 Objectives.

References

Amazon Web Services. 2023. “Amazon S3 Now Applies Two Security Best Practices to All New Buckets by Default.” AWS What’s New, April 28, 2023.

Amazon Web Services. n.d.a. “Blocking Public Access to Your Amazon S3 Storage.” Amazon S3 User Guide. Accessed October 12, 2026.

Amazon Web Services. n.d.b. “Security Hub CSPM Controls for Amazon S3.” AWS Security Hub User Guide. Accessed October 12, 2026.

Broadcom. 2025. “VMSA-2025-0004: VMware ESXi, Workstation, and Fusion Updates Address Multiple Vulnerabilities.” VMware Security Advisory, March 4, 2025.

Canonical. n.d.a. “Daemon Version Banners.” Ubuntu Security Documentation. Accessed October 12, 2026.

Canonical. n.d.b. “Ubuntu Release Cycle.” Ubuntu. Accessed October 12, 2026.

CISA (Cybersecurity and Infrastructure Security Agency). 2022. “BOD 23-01: Improving Asset Visibility and Vulnerability Detection on Federal Networks.” Binding Operational Directive 23-01, October 3, 2022.

CompTIA. 2023. CompTIA Security+ SY0-701 Certification Exam Objectives. Version 5.0.

CompTIA. 2025. CompTIA Security+ SY0-801 V8 Certification Exam Objectives. Document Version 2.0.

GitHub. n.d.a. “Push Protection.” GitHub Docs. Accessed October 12, 2026.

GitHub. n.d.b. “Removing Sensitive Data from a Repository.” GitHub Docs. Accessed October 12, 2026.

Microsoft. n.d.a. “Extended Security Updates (ESU) Program for Windows 10.” Microsoft Learn. Accessed October 12, 2026.

Microsoft. n.d.b. “Windows 10 Extended Security Updates.” Microsoft Windows. Accessed October 12, 2026.

MITRE. n.d.a. “CWE-209: Generation of Error Message Containing Sensitive Information.” Common Weakness Enumeration, version 4.20. Accessed October 12, 2026.

MITRE. n.d.b. “CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition.” Common Weakness Enumeration, version 4.20. Accessed October 12, 2026.

MITRE. n.d.c. “CWE-798: Use of Hard-coded Credentials.” Common Weakness Enumeration, version 4.20. Accessed October 12, 2026.

MITRE. n.d.d. “Search Open Websites/Domains: Code Repositories.” MITRE ATT&CK, T1593.003. Accessed October 12, 2026.

NIST (National Institute of Standards and Technology). n.d. “Attack Surface.” CSRC Glossary. Accessed October 12, 2026. See also the entry for zero-day attack.

OWASP Foundation. 2025. “A10:2025 Mishandling of Exceptional Conditions.” OWASP Top 10:2025.

OWASP Foundation. n.d. “Secrets Management Cheat Sheet.” OWASP Cheat Sheet Series. Accessed October 12, 2026.

Tooley, Eric, and Courtney Claessens. 2024. “Keeping Secrets Out of Public Repositories.” The GitHub Blog, February 29, 2024.