CS0-003: CompTIA CySA+

Option B is inconsistent with the stem because it requires high privileges and user interaction, which directly contradicts the description of no privilege requirement and no user interaction. It also uses malformed CVSS notation such as AV:K, PR:H in a context that does not fit, and UI:R instead of the valid UI:N or UI:R style expected in proper vectors. Although C:H and I:H would fit the impact portion, the exploitability metrics are fundamentally wrong. This makes B a poor match even before considering the notation issues.

Option C is incorrect because it indicates user interaction is required, which conflicts with the explicit statement that no user interaction is needed. Its impact metrics also do not fit the scenario: confidentiality is only low, integrity is none, and availability is high, while the stem says confidentiality and integrity are significantly affected but availability is not. Even though AV:N and AC:L are plausible, the rest of the vector misrepresents the vulnerability. Therefore, C does not accurately describe the threat.

Option D is wrong because it describes a local attack vector and requires privileges and user interaction, all of which contradict the scenario's highly exploitable no-interaction, no-privilege nature. It also assigns high availability impact, which the stem explicitly rules out. While confidentiality impact is high, the rest of the vector reflects a very different type of vulnerability. As a result, D is not an accurate CVSS representation of the described zero-day.

PAM (Privileged Access Management) focuses on securing privileged accounts (admins, service accounts) through vaulting, rotation, just-in-time access, session recording, and least privilege. It reduces the risk of privileged misuse and lateral movement, but it is not primarily a content-aware control. PAM won’t reliably stop a user from emailing or uploading PII externally unless combined with other data controls.

IDS (Intrusion Detection System) monitors traffic or host activity to detect malicious behavior and policy violations. While it can alert on suspicious outbound connections or known exfiltration patterns, it typically lacks deep, business-context content inspection for PII and is often not deployed inline to block. IDS is more aligned with detection than prevention of PII exposure.

PKI (Public Key Infrastructure) provides certificates, authentication, digital signatures, and encryption (e.g., TLS, S/MIME). It can protect data in transit and help ensure only intended recipients can read encrypted messages, but it does not prevent users from sending PII to unauthorized external recipients. PKI is about trust and confidentiality, not policy enforcement on sensitive content.

Lessons learned is typically part of an after-action report or post-incident review in incident response. It captures what went well, what failed, and process improvements. A vulnerability scan report focuses on discovered vulnerabilities and their context, not retrospective analysis of an event. While a vulnerability program may later produce lessons learned, it is not a standard scan report component.

A service-level agreement (SLA) defines expected service performance or response/remediation timelines (e.g., critical vulnerabilities remediated within X days). SLAs are governance artifacts and may be referenced by a vulnerability management policy, but they are not usually included as a required element inside the scan report output itself, which is primarily findings and prioritization data.

A playbook is an incident response or security operations guide that outlines step-by-step actions for specific scenarios (e.g., ransomware, phishing, web shell). Vulnerability scanning is a proactive assessment activity; its report documents vulnerabilities found. While playbooks may exist for remediation workflows, they are not a standard inclusion in the scan report.

An education plan is a training and awareness artifact used to improve staff skills or user behavior over time. It is not part of the standard output of a vulnerability scan. While scan trends might inform training needs (e.g., recurring misconfigurations), the scan report itself should focus on findings, affected assets, and prioritization/remediation details.

Ruby is incorrect. Ruby loops and variables look different (e.g., users.each do |user| ... end) and Ruby does not use Verb-Noun cmdlets or pipelines. While Ruby could interact with AD via libraries or system calls, the native syntax and the presence of Get-ADUser/Add-ADGroupMember strongly indicate PowerShell rather than Ruby.

Python is incorrect. Python would typically use “for user in ...:” with indentation and would rely on libraries (e.g., ldap3) or subprocess calls to manage AD. The script’s pipeline operator “|”, cmdlet naming, and hashtable replacement syntax are not Python constructs, making PowerShell the clear match.

Shell script is incorrect in the common sense of bash/sh. Bash uses constructs like “for user in $(cat file); do ...; done” and does not have PowerShell cmdlets or object pipelines. Although PowerShell is sometimes called a “shell,” the option “Shell script” here refers to Unix-like shell scripting, not PowerShell.

An SSL certificate or port 443 outage would typically make HTTPS consistently unavailable or generate clear browser errors (certificate expired, name mismatch, untrusted CA, TLS handshake failures). It does not inherently cause users to sometimes land on HTTP and sometimes on HTTPS unless there is a separate redirection misconfiguration. It also doesn’t strongly explain credential compromise compared to an on-path downgrade/stripping scenario.

Web servers generally do not forward users from HTTPS to HTTP because of load; they scale out, shed load, or fail. Redirecting to HTTP would be a major security anti-pattern and would likely be consistent if configured. While high TLS load can cause timeouts or handshake failures, it doesn’t naturally produce intermittent protocol switching and doesn’t directly explain account compromise as well as an on-path attack does.

BGP governs inter-domain routing between autonomous systems and is not a typical mechanism for causing an internal portal to alternate between HTTP and HTTPS. Internal routers usually use IGPs (OSPF/EIGRP/IS-IS) or static routes, and even if routing changed, it would affect reachability/latency rather than selectively downgrading application-layer encryption. This option doesn’t match the symptoms.

THOR.HAMMER is highly exploitable (AV:N/AC:L/PR:N/UI:N) and has High availability impact (A:H) but no confidentiality or integrity impact (C:N/I:N). It is also on an internal system, which the policy deprioritizes relative to external systems. Additionally, the policy states confidentiality is prioritized over availability when a choice must be made, so this ranks below confidentiality-impacting issues like B/D.

LOKI.DAGGER is externally exposed and highly exploitable, which makes it important. However, its impact is only High availability (A:H) with no confidentiality/integrity impact (C:N/I:N). The policy explicitly prioritizes confidentiality over availability when choosing between them. Therefore, despite being external, it is lower priority than an external vulnerability with High confidentiality impact (B).

THANOS.GAUNTLET has the same strong exploitability and High confidentiality impact as option B, but it is on an internal system. The policy states publicly available (external) systems and services are prioritized over internal systems. Therefore, D would be a high priority, but it is second to B because external exposure is the tie-breaker when severity characteristics are otherwise equivalent.

Code analysis generally refers to reviewing source code (manual review or SAST) to find malicious logic, insecure functions, or vulnerabilities. For a received malicious binary, the analyst typically does not have the original source code, making traditional code analysis impractical. While decompiled output can resemble code, that activity is better categorized as reverse engineering rather than straightforward code review.

Static analysis examines an artifact without executing it (hashes, strings, headers, imports, entropy, signatures). It is useful for quick triage and IOC extraction, but by itself may not reveal full intent, especially if the binary is packed, obfuscated, or uses runtime-resolved APIs. Static analysis is often a component of reverse engineering, but it is not as complete a technique for understanding a malicious binary’s logic.

Fuzzing is a testing technique that sends malformed or unexpected inputs to a program to trigger crashes or anomalous behavior, commonly used to discover vulnerabilities. It is not primarily used to analyze what a malicious binary does; instead, it helps find weaknesses in software. While you could fuzz a malware sample’s parser to learn about it indirectly, that is not the best or most direct technique for malware binary analysis.

Hacktivists are threat actors motivated by political or social causes who intentionally conduct attacks (e.g., defacement, DDoS, data leaks) to promote an agenda. In this scenario, there is no indication of ideology or deliberate activism—only a user downloading infected software. Therefore, “hacktivist” does not fit the described behavior or motivation.

An advanced persistent threat (APT) refers to a highly capable adversary (often state-sponsored or well-funded) that performs targeted, stealthy, long-term intrusion with persistence and careful operational security. While malware spreading to many systems can happen during APT activity, the scenario focuses on a user accidentally introducing malware, not a sophisticated, persistent external campaign.

A script kiddie is typically an external attacker with limited skills who uses existing scripts, exploit kits, or tools to compromise systems. The scenario does not describe the user actively attacking others or using hacking tools; it describes accidental installation of malware. Thus, “script kiddie” is not the correct classification for the user’s role.

Logging into the affected server to review logs seems efficient, but it is not the best first action in a forensic-minded incident. Interactive access changes the system state (new authentication events, file access timestamps, potential log rotation) and can overwrite artifacts. Best practice is to acquire a forensic copy first, then analyze logs and artifacts from the clone/image.

Restoring from a last known-good backup is a recovery/continuity action, not an investigation-first action. It can overwrite or remove evidence needed to determine initial access, persistence, lateral movement, and data impact. Unless the question prioritizes immediate service restoration over investigation, restoration should occur after evidence preservation and scoping.

Shutting down immediately can destroy volatile evidence (RAM contents, running processes, active network connections) and may also trigger disk consistency operations on reboot that alter artifacts. While isolation/containment is often necessary, an abrupt shutdown is typically not the first step when the goal is to determine exactly what happened; preserve evidence via imaging/cloning first.

A vulnerability management plan focuses on identifying, prioritizing, remediating, and tracking vulnerabilities (scanning, patching, risk ranking, exception handling). While it reduces the likelihood of incidents and can limit impact, it does not directly ensure service availability during an incident. It is a preventative and risk-reduction program rather than an operational continuity plan.

A Disaster Recovery Plan (DRP) details how to restore IT systems, applications, and data after a disruptive event (backups, rebuild procedures, failover/failback). DRP supports availability, but it is typically narrower than BCP and is oriented toward recovery after the incident rather than maintaining business operations throughout. It’s often a component of the broader BCP.

An asset management plan inventories and tracks hardware, software, data, and ownership to support lifecycle management, compliance, and risk decisions. It helps with incident response (knowing what exists and who owns it) and vulnerability management (knowing what to patch), but by itself it does not provide continuity mechanisms like redundancy, alternate processing, or recovery procedures.

CDN logs are primarily useful when the organization is defending its own public-facing applications through a content delivery or DDoS protection provider. In this scenario, the problem is that internal users cannot access external SaaS resources, which are third-party services and generally not fronted by the organization's CDN. Reviewing CDN logs would not be the best first step unless the outage specifically involved the organization's hosted content or edge protection platform. Therefore, CDN logs are less directly relevant than DNS logs for this type of widespread outbound access issue.

Vulnerability scanner logs are used to track scanning activity, discovered weaknesses, and assessment results. They do not provide meaningful visibility into a live DDoS event affecting user access to external SaaS platforms. Even if a scanner generated excess traffic, it would not typically explain a distributed outage across multiple locations in the same way as a DNS-related disruption. As a result, these logs are not the correct first source to review.

Web server logs are useful for investigating attacks against a specific web application or server, especially for application-layer events such as HTTP floods. However, the scenario describes users across multiple locations being unable to access external SaaS resources, not an issue with the organization's own web server. Web server logs would not explain why many different third-party services became unreachable at once. That makes them a lower-priority and less appropriate first review point than DNS logs.

Regular red team exercises can uncover real-world attack paths and validate detection/response, but they are typically periodic and occur late (often against production). This does not address the root cause of recurring vulnerabilities being reintroduced during development. Red teaming is more about adversary emulation and assurance than continuous prevention across the SDLC.

Regularly checking implemented coding libraries is essentially software composition analysis and patch management for dependencies. This can reduce repeated findings related to known vulnerable components, but it won’t prevent recurring vulnerabilities in custom code (logic flaws, insecure input handling, auth issues). It’s a partial control, not the best broad SDLC-phase mitigation for repeated issues.

Proper input validation is an important secure coding practice and can mitigate specific vulnerabilities like injection and some XSS scenarios. However, it is a single technical control and may not address the full range of recurring findings (e.g., vulnerable dependencies, insecure configurations, auth flaws). The question asks for an SDLC-phase recommendation that best mitigates recurrence, which is better solved by pipeline scanning and gating.

Legacy systems are older technologies that remain in use due to business dependency, compatibility constraints, or replacement cost. They may be difficult to patch because updates could break integrations or because hardware/software is outdated. However, the stem’s primary blocker is not age or compatibility—it is lack of access because the system is controlled by a vendor appliance, which aligns more directly with proprietary constraints.

Unsupported operating systems are end-of-life platforms where the vendor no longer provides security patches. This is a major remediation inhibitor because vulnerabilities cannot be fixed through normal patching. The question does not indicate the OS is out of support; instead, it indicates the organization cannot upgrade due to a vendor appliance they cannot access. That is a different constraint than EOL/unsupported status.

Lack of maintenance windows means the organization cannot schedule downtime to apply patches or upgrades, often due to 24/7 availability requirements. In the scenario, most systems can be upgraded with a reboot and a single downtime window, so maintenance windows are available. The issue is not scheduling downtime; it is the inability to perform the upgrade because the vendor appliance is not accessible to the company.

A service-level agreement (SLA) defines measurable service expectations such as uptime, response times, and support commitments between parties. It is primarily focused on performance and availability targets rather than operational security response procedures. Although an SLA may state how quickly a provider must respond to an issue, it does not normally assign internal incident response roles or define who performs containment, investigation, or recovery tasks. Therefore, it would not solve the team's problem of clarifying who should take the next steps during a security event.

A change management plan is used to control how system changes are requested, reviewed, approved, implemented, and documented. Its purpose is to reduce risk when modifying production systems, not to coordinate security incident handling. While change management may become relevant when applying patches or remediation after an incident, it does not define incident ownership, escalation paths, or responder responsibilities. For that reason, it does not address the confusion described in the scenario.

A memorandum of understanding (MOU) is a high-level agreement that outlines cooperation or shared expectations between organizations or departments. It can help clarify external support relationships, such as coordination with law enforcement, vendors, or partner agencies. However, an MOU usually does not provide the detailed internal workflow, role assignments, and decision-making structure needed during incident response. The team needs an operational plan for handling incidents, which is why an IRP is the better choice.

Blocking an IP range can be effective if the scanning is tied to a stable, well-defined netblock (e.g., a specific hosting provider). However, scanners often rotate across many providers and ranges, and large range blocks can cause collateral damage. It’s typically a tactical, short-term control rather than the best strategic mitigation when geography is the key clue.

Historical trend analysis helps determine whether the activity is new, recurring, or correlated with other events, and it can improve detection and threat hunting. However, it does not stop the scanning. The question asks for the best mitigation technique, so an investigative/analytical action is not the correct choice even though it is a good follow-up activity.

Blocking a single IP address is the least robust option because scanning commonly comes from botnets, VPNs, or cloud infrastructure with rapidly changing IPs. It may provide brief relief but is easily bypassed and creates ongoing operational overhead. It’s appropriate only as an immediate, temporary containment step when the source is singular and stable.

Incorrect. “Layout creation” is not the attacker’s goal; it is likely just the vulnerable route being abused (sc_layout) to reach a sensitive function. Restricting layout creation might reduce some functionality, but it does not directly prevent wp_insert_user from being invoked or stop user creation/role assignment if the vulnerability allows it. It’s an indirect control and less reliable as a mitigation.

Incorrect. Making the trx_addons directory read-only is a filesystem hardening step that can help prevent plugin file tampering or web shell drops, but it does not stop an exploit that triggers server-side code already present to create a user in the database. The attack shown is about abusing application logic/API parameters, not writing to plugin files.

Incorrect. Setting the V2 directory to read-only is similarly a filesystem permission change and does not address the core vulnerability: an API endpoint allowing unauthorized invocation of wp_insert_user with an administrator role. The REST API route can still be executed even if the directory is read-only, because the web server only needs read/execute access to run the existing code.

Implementing MFA on the server OS is an authentication hardening measure for administrative or interactive logons to the operating system. It does not remediate a web application vulnerability where crafted form input is used to extract credentials from the application/database. MFA may reduce the impact of stolen admin credentials, but it does not prevent the injection-style data retrieval described in the scenario.

Hashing user passwords is a critical best practice (with a strong adaptive algorithm like bcrypt/Argon2 and unique salts) to reduce the impact of credential theft. However, it does not address the root cause: the attacker can still exploit the form submission flaw to retrieve stored credential data (hashes or other sensitive fields). The vulnerability remains exploitable even if passwords are hashed.

Network segmentation between users and the web server is a compensating control that can reduce exposure and limit blast radius, but it does not fix the application logic flaw. Users must still reach the web server to use the application, and an attacker can still submit malicious form input through allowed paths. Segmentation is defense-in-depth, not primary remediation for injection.

Mean time between failures (MTBF) is a reliability/availability metric used to estimate the average time between inherent failures of a system or component. It is common in operations and engineering contexts (hardware, infrastructure, service uptime) rather than incident response. It does not measure how quickly a security team stops malware propagation, so it is not appropriate for the executive question asked.

Mean time to detect (MTTD) measures how long it takes to discover an incident after it begins (or after initial compromise). While detection speed is important, it does not answer the executive’s specific concern: “how long it takes to stop the spread.” You could detect quickly but still take too long to isolate affected systems, so MTTD alone is insufficient for this question.

Mean time to remediate (often aligned with MTTR in security contexts) measures how long it takes to fully fix the issue—eradicate malware, remove persistence, patch vulnerabilities, and restore systems to a secure state. Remediation typically occurs after containment and can take significantly longer. Because the question focuses on stopping spread (limiting propagation), remediation is not the best match.

Help desk is primarily responsible for operational support: triage, ticketing, endpoint remediation, and user support. While they may assist by isolating a workstation, removing unauthorized software, or reimaging systems, they are not the appropriate first escalation group for updating reporting policy or ensuring the organization’s response aligns with legal/privacy and disciplinary requirements.

Law enforcement involvement is typically reserved for situations with clear criminal activity requiring external investigation, mandatory reporting, or significant impact. Escalating to law enforcement first is usually not best practice for internal misuse because it can disrupt internal fact-finding, create unnecessary exposure, and complicate evidence handling unless legal has determined it is warranted.

A board member is part of executive governance and oversight, not day-to-day policy drafting or incident escalation. Boards typically receive high-level risk and incident reporting after internal stakeholders (security, legal, HR, compliance) have assessed impact and response. Escalating to a board member first is inefficient and bypasses necessary legal/compliance review.