CS0-004 Exam Questions and Answers

Threat intelligence finding

AWS GuardDuty actively leverages continuously updated threat intelligence feeds, including lists of known malicious IP addresses, domains, and attack signatures, to identify suspicious activity. When an EC2 instance communicates with an IP address or domain identified as a known command and control (C2) server by these feeds, GuardDuty generates a finding, indicating a high probability of compromise and C2 communication.

Exclude failed logins from known service accounts

Service accounts frequently generate legitimate failed-login noise from scheduled password rotations, expired credentials in automation scripts, or misconfigured connection strings, none of which represent an attacker probing for access. Suppressing these known, expected sources removes a large share of benign alert volume without weakening detection against genuine unauthorized login attempts from unexpected accounts or sources.

Require a minimum threshold of 5 failed attempts from the same source IP within 10 minutes before alerting

Setting a threshold of multiple failures from the same source within a short window filters out the high-volume background noise of isolated typos, expired passwords, and one-off misclicks, since those rarely repeat five times from one IP in ten minutes. Genuine brute-force or password-spraying activity is characterized by exactly this kind of repeated rapid-fire failure pattern, so the threshold preserves detection of real attacks while suppressing the vast majority of harmless noise.

Command and control beaconing

Command and control (C2) beaconing involves an infected host periodically initiating outbound connections to a C2 server, often on a non-standard port like 4444, to check for new commands or upload data. These connections are typically regular, repetitive, and consistent in their destination and port, fitting the description of repeated connections to a single IP on port 4444. This behavior establishes a persistent communication channel for remote control of the compromised system.

Disabling unnecessary plug-ins

Disabling unnecessary plug-ins prevents the scanner from running checks that are not relevant to the environment, such as Windows-specific tests against Linux hosts. Each plug-in produces findings, and if it probes for software or services that are absent, it can generate false positives based on erroneous banner matches. By tailoring the active plug-in set to the actual asset inventory and exposed services, the analyst reduces meaningless alerts and focuses the scan on likely vulnerabilities. This is a core tuning step that directly reduces false positives while preserving comprehensive coverage.

Enabling credentialed scanning

Enabling credentialed scanning authenticates the scanner to target systems, allowing it to read local configuration data, installed patch levels, and registry settings. This eliminates the guesswork inherent in uncredentialed scans, where the scanner infers vulnerabilities fro remote banners and may flag correctly patched systems or miss actual issues. With credentials, the scanner can perform deeper checks, such as validating hotfixes or inspecting local security settings, producing more accurate results and dramatically fewer false positives. It also uncovers vulnerabilities only visible through authenticated access, such as weak password policies or misconfigured services.

SMB traffic between workstations

SMB traffic between workstations is a strong lateral movement indicator because in a well-managed environment, peer-to-peer file sharing or remote administration between endpoints is uncommon; most SMB flows are client-to-server (e.g., accessing a domain controller or file server). Attackers commonly use tools like PsExec or WMIC that create SMB connections from one compromised workstation to another to copy malicious payloads, execute remote services, or access shared resources, making this traffic a precise behavioral signature for lateral spread.

SMB traffic to administrative shares (e.g., IPC$)

SMB traffic to administrative shares such as IPC$, ADMIN$, or C$ is a recognized lateral movement technique because these hidden shares are designed for remote administration. Tools like PsExec, WMI, and other post-exploitation frameworks connect to IPC$ and named pipes (e.g., \pipe\svcctl) to launch services or execute commands on a remote host, while C$ and ADMIN$ provide full filesystem access. Such connections from an unexpected workstation strongly indicate an attacker actively moving laterally, as standard users rarely need to access these shares directly.

DNS responses with unusually large payload sizes

Normal DNS responses are typically small, often under 512 bytes when using traditional UDP limits. During DNS tunneling, attackers encode exfiltrated data into TXT records or other response fields, causing responses to be several kilobytes or larger. Such unusually large payloads are a direct and strong indicator that DNS is being used to transfer unauthorized data, making this the correct sign of data exfiltration.

Unusually high volume of DNS queries to a single domain

DNS tunneling tools often embed data into subdomain labels of queries, which are limited to 63 characters per label. To transfer a meaningful amount of data, an attacker must send thousands of queries to a single malicious domain, creating a distinctive high-volume spike in DNS traffic. This query-frequency pattern is a classic behavioral signature of DNS tunneling and should raise immediate suspicion.

Asset criticality and business context

Asset criticality and business context are central to vulnerability prioritization because they determine the potential impact on operations, data confidentiality, and compliance. A critical internet-facing server, for example, represents a higher risk to the organization if compromised, even when the vulnerability's severity is moderate. Contextual factors such as exposure, sensitive data, and required availability turn a generic technical finding into a prioritized business risk.

CISA Known Exploited Vulnerabilities (KEV) catalog

The CISA Known Exploited Vulnerabilities catalog is a curated, authoritative list of vulnerabilities with confirmed evidence of active exploitation in the wild, removing the guesswork from vulnerability prioritization. This ground-truth intelligence, coupled with asset criticality, directly supports urgent remediation because the attack is ongoing and organizations must act immediately. It is a leading element in federal vulnerability management directives and modern risk-based decision-making.

Trivy

Trivy is an open-source, fast, and comprehensive vulnerability scanner designed specifically for container images. It scans both OS packages (e.g., Alpine, Debian) and application dependencies (e.g., Python, Node.js) by comparing against a continuously updated CVE database, and it can be easily embedded into CI/CD pipelines with a simple CLI without requiring a separate server. Its low false-positive rate and support for multiple input formats (e.g., Docker, Podman, OCI) make it the most straightforward and effective choice among these options for the security team's container scanning need.

Clair

Clair is an open-source project originally from CoreOS that performs static analysis of security vulnerabilities in container images. It ingests images from registries, breaks them into layers, and correlates installed OS packages with CVE data via a PostgreSQL-backed API, enabling tools like Quay or custom queries to retrieve results. As a registry-integrated scanner, it is a valid option for continuous vulnerability assessment, though it requires more operational overhead—namely a database and backend services—compared to more modern single-binary scanners.

Snyk

Snyk is a developer-first security platform that offers container scanning for known vulnerabilities, license compliance, and configuration drift, with robust integrations into IDE plugins, Git repositories, and CI/CD systems. Unlike purely image-layer scanners, Snyk also performs deep dependency analysis and provides actionable fix advice, patching recommendations, and continuous monitoring through both free and commercial tiers. It is a correct tool for container security scanning, particularly when the team wants developer-friendly policy enforcement in addition to CVE detection.

Network

AV:N (Attack Vector: Network) means the vulnerable component is bound to the network stack and the attacker's path to exploit lies through a routable network connection, potentially even across the internet, rather than requiring physical or local access. This is the highest-severity attack vector value because it maximizes the pool of potential attackers, contributing to this vulnerability's near-maximum CVSS base score of 9.8 alongside low complexity and no required privileges or user interaction.

It has high impact on availability

The A component of the CVSS v3.1 vector is H, which is the Availability Impact metric and indicates that the exploit can cause a total loss of availability, such as a denial of service. Unlike the C and I metrics, which are both N, the A metric is the only one rated high, so this option correctly identifies the finding's high impact on availability.

The gradual deviation of a system's configuration from the intended baseline

Configuration drift is the gradual and often unnoticed deviation of a system's current configuration from its intended, documented baseline. It results from incremental changes such as manual edits, emergency fixes, unpatchable workarounds, or inconsistent patch deployments that accumulate over time without change-control approval. This divergence can lead to security weaknesses, compliance violations, and unpredictable behavior, making it a central concern for configuration management.

Implement a compensating control and schedule patching during a maintenance window

This approach aligns with best-practice vulnerability management by balancing the need for security against operational availability. A compensating control, such as an internal network access control list (ACL) or an updated intrusion prevention system (IPS) signature, reduces the likelihood or impact of exploitation until the patch can be installed during a scheduled maintenance window. This ensures that the system remains functional and that the patch is tested and deployed in a controlled manner, minimizing downtime and the risk of unexpected failures. It is the correct decision because it addresses the vulnerability without disproportionate disruption to the business.

Capture a forensic image of the affected systems

Capturing a forensic image of affected systems is the correct first step because it creates a bit-for-bit copy of the storage media while preserving file slack, unallocated space, and metadata. Using a hardware write-blocker and cryptographic hashing ensures the evidence remains intact and tamper-proof for later analysis. This action is essential for identifying how the data exfiltration occurred, which files were accessed, and what remnants remain, all without altering the original source.

Record current active network connections

Recording current active network connections is a critical evidence preservation technique because this volatile data disappears the moment the system is rebooted, disconnected, or the attacker cleans up. Documenting netstat output, established connections, remote IPs, ports, and associated process IDs provides a snapshot of potential command-and-control or exfiltration channels. This is a low-impact, non-destructive step that must occur before any containment action that would disrupt the network stack.

Email gateway logs for the week prior to the incident

Email gateway logs are the primary source for identifying phishing payloads because ransomware often arrives via malicious attachments or embedded URLs. These logs capture sender metadata, subject lines, message IDs, and any verdicts (e.g., quarantined, spam, clean), so reviewing the week prior to the incident lets investigators trace the exact message that delivered the initial dropper and recover the full email thread for IoC extraction.

Endpoint detection and response (EDR) logs from affected servers

EDR logs are crucial because they record the execution sequence on the affected servers, including process creation with command-line arguments, file creation/modification events, registry changes, and parent-child process relationships. Analysts can pinpoint the exact executable or script that initiated the encryption, determine whether it used a known LOLBin or PowerShell, and observe post-execution behavior such as privilege escalation or credential dumping before the ransomware ran.

Network traffic logs from the perimeter firewall

Perimeter firewall logs reveal the network-level indicators of compromise, such as initial outbound HTTP/HTTPS connections to attacker-controlled domains or IPs, DNS queries for malicious hostnames, and protocol anomalies that may correspond to command-and-control beaconing. Even if the initial payload was delivered by email, firewall egress logs help map the ransomware's callback infrastructure and may expose the original C2 channel used for key exchange or data staging.

WHOIS

WHOIS queries domain registration databases, returning registrar, registrant contact, creation and expiration dates, and nameserver records. For an IOC like a known malicious domain, WHOIS enables analysts to pivot on registration metadata, identify shared infrastructure, or detect typosquatting and recently registered domains. It is a read-only lookup service, not a traffic analysis tool, making it a first-line passive enrichment source.

VirusTotal

VirusTotal aggregates results from over 70 antivirus engines and other sandboxing services; an analyst can submit a file hash, URL, or domain to see detection ratios, threat classifications, and community comments. It also provides related samples, vendor-specific detection labels, and a visual relationship graph, which helps determine the breadth of an indicator's maliciousness. Using its API, security teams can automate bulk IOC reputation checks, making it a key triage tool.

Shodan

Shodan is a search engine for internet-facing devices, indexing banners, open ports, SSL certificates, and service fingerprints such as HTTP or FTP headers. When an IOC is an IP address, Shodan can reveal the organization, hosting provider, geographic location, and exposed services, letting analysts spot compromised infrastructure or vulnerable industrial controls. It does not analyze packet captures or run AV checks, but it is vital for understanding device-level exposure tied to an IP.

Block the phishing domain at the email gateway

Blocking the phishing domain at the email gateway is immediate containment because it prevents subsequent emails carrying the same malicious payload from reaching other recipients, thereby reducing the number of users exposed to the lure. This email gateway control is fast, reversible, and can also block outbound traffic if needed, but it does not remediate credentials that have already been stolen.

Disable the compromised user accounts

Disabling the specific compromised user accounts denies the attacker continued authentication with valid credentials and blocks any active sessions from being reused, cutting off lateral movement and data exfiltration while the investigation proceeds. This targeted control minimizes disruption to the rest of the organization and preserves the account's domain-joined state for forensic analysis. It is a correct and immediate containment step.

Verify the hash of the image against the original

Verifying the hash of the acquired image against the original evidence is a critical step because it provides cryptographic proof that the image is an exact bit-for-bit replica. Using algorithms like SHA-256, any change to even a single bit in the image produces a completely different hash, so the match confirms no data was altered during acquisition. This verification is recorded and matched against the hash of the original, establishing the integrity and authenticity of the evidence for the chain of custody and courtroom admissibility.

Use a write blocker when imaging the hard drive

Using a write blocker when imaging the hard drive is essential because it prevents the acquisition workstation from sending any write commands to the suspect drive, guaranteeing that the original evidence remains byte-for-byte unchanged. A hardware write blocker physically intercepts and blocks writes, while a software write blocker does the same at the driver level; both allow read-only access to the source. This safeguards the evidence from accidental modifications, OS artifacts, or malware, ensuring the image is a true and admissible copy of the original.

Document every action taken during the acquisition

Documenting every action taken during the acquisition is essential because it creates a complete, auditable chain of custody that allows another examiner to independently reproduce the process. Detailed notes on the tools used, timestamps, commands issued, and any anomalies observed establish the evidence's integrity and demonstrate that proper forensic protocols were followed. Without this documentation, the opposing counsel can successfully challenge the evidence's reliability, even if the technical acquisition was flawless.

Apply security patches to vulnerable systems

Apply security patches to vulnerable systems is the definitive root-cause remediation for a ransomware outbreak. If the initial infection exploited a known software flaw, patching closes the exact vulnerability the attacker used, preventing the same binary from reinfecting hosts after cleanup. This action breaks the kill chain at the exploitation stage and is mandatory before restored systems are placed back on the production network. Without patching, any unpatched host still exposed to the same entry vector will likely be re-encrypted within hours.

Rotate all privileged account credentials

Rotating all privileged account credentials is critical because ransomware operators frequently steal administrator, domain admin, or service account hashes to move laterally and disable backups. Once credentials are compromised, the attacker can maintain persistence even if files are quarantined, using Scheduled Tasks or remote management tools backed by those valid accounts. Immediate rotation of every privileged password, including local admin accounts and Kerberos service tickets, invalidates the attacker's existing access. This must be done before restoring systems, not after, or the attacker will simply re-encrypt the rebuilt servers.

Rebuild affected servers from clean backups

Rebuilding affected servers from clean backups is the most reliable way to recover encrypted data while ensuring the ransomware is completely eradicated. The backup must be verified malware-free and ideally restored from offline or immutable storage, because many ransomware strains delete or encrypt backup copies. Clean restoration eliminates malicious files, registry entries, and persistence mechanisms that might survive a simple antivirus scan. For fully successful recovery, this step must be combined with patching vulnerabilities and resetting compromised credentials to prevent a repeat infection.

72 hours

72 hours is the correct timeframe under GDPR Article 33(1), which states that a data breach notification must be made to the competent supervisory authority 'without undue delay' and, where feasible, no later than 72 hours after the controller becomes aware of the breach. This period is a fixed regulatory deadline, and failure to meet it without a documented justification (e.g., complexity of investigation) can result in significant administrative fines.

Timeline

The timeline is the chronological reconstruction of every observable event leading up to, during, and after the security incident. It consolidates artifacts like log entries, file system changes, network flows, and user actions into a coherent sequence. This component is foundational because it enables analysts to map the attack lifecycle and determine the exact order of compromise, which is essential for effective containment and eradication.

Patch SLA compliance %

Patch SLA compliance percentage directly measures whether systems are being patched within the timeframes the organization has committed to, for example critical patches within 14 days, which is precisely what a management-facing compliance dashboard needs to show for the patch management program. It ties directly to the process being audited rather than to an adjacent security function.

Executive leadership

Executive leadership is the primary audience for strategic intelligence because it informs high-level decisions about risk tolerance, resource allocation, and business continuity. This type of intelligence is written in non-technical language, summarizing geopolitical threats, industry-level trends, and potential impacts to the enterprise in a way that supports governance and investment choices. It helps the C-suite align cybersecurity with organizational objectives, not with day-to-day tactics.

Implement multi-factor authentication for remote access to reduce risk.

This is a concrete, actionable recommendation that directly addresses a common attack vector used in ransomware incidents, such as compromised VPN credentials. It specifies the control (MFA), the scope (remote access), and the goal (risk reduction), making it a proper lesson learned. Unlike observations or causes, it provides a clear implementation step that stakeholders can act on to harden their environment.

Explain the potential financial loss and reputational damage.

Quantifying the unpatched vulnerability in terms of potential financial loss—such as breach response costs, regulatory fines, or lost revenue from downtime—and reputational damage, like customer churn or erosion of brand trust, directly aligns the technical risk with the board's fiduciary responsibilities. This translation reassures executives that their decision allocates resources to protect shareholder value and market standing, not just IT infrastructure.