Scenario practice questions

File Quarantine

Why it fails: File Quarantine isolates individual malicious files on the host; it does not block the endpoint's network communications, so lateral movement remains possible. It is tempting because it neutralises identified malware artefacts, but Network Containment is the Falcon feature that severs network access while preserving the responder channel for memory dumps.

Credential revocation

Why it fails: Credential revocation invalidates stolen accounts but leaves the host itself communicating freely, so the adversary retains network access for lateral movement. It is tempting because it removes the attacker's authenticated access, yet Network Containment is the Falcon feature that isolates the endpoint while preserving the responder channel for memory acquisition.

Sensor uninstallation

Why it fails: Uninstalling the sensor removes Falcon's visibility and control entirely, so the host is neither contained nor available for remote memory collection. It is tempting when decommissioning an infected machine permanently, but Network Containment is the feature that blocks lateral movement while keeping the responder channel open.

Reviewing the Windows Security event log for Event ID 4688 to identify the full command line of the PowerShell process and its parent process ID.

Why it fails: Event ID 4688 records process creation and can include the command line if audit policy is configured, but it does not by itself confirm malicious intent. The Base64-encoded argument is suspicious, yet the log entry alone lacks network or payload context. It is a supporting artifact, not the most direct confirmation of a true positive in this scenario.

Inspecting the Windows Registry for persistence mechanisms added by the PowerShell process, such as a Run key entry.

Why it fails: Looking for persistence is valuable during eradication, but the absence of a Run key does not rule out malicious activity. The encoded command could be performing credential theft, reconnaissance, or lateral movement without establishing persistence. This check does not directly confirm whether the encoded script itself is malicious.

Checking the Microsoft Word document's file hash against VirusTotal to see if any antivirus engines flag it as malicious.

Why it fails: A VirusTotal lookup may show detections, but many malicious documents are custom or zero-day and yield no detections. Even if flagged, it does not prove that this specific execution chain was malicious; false positives occur. It is a useful enrichment step but insufficient to confirm the true positive on its own.

DNS query logs from the internal resolver

Why it fails: DNS query logs show domain name resolution requests and can reveal command-and-control domains or data exfiltration via DNS tunneling, but they do not provide byte counts, flow duration, or volume for large outbound transfers over encrypted channels. They are useful for identifying destinations, not for measuring transfer size and duration.

Full packet capture analyzed with a protocol analyzer

Why it fails: Full packet capture provides payload visibility but encrypted traffic remains unreadable, and the storage and processing overhead is significant. While it can show packet sizes and timing, it does not directly summarize flow volume and duration as efficiently as flow records, and it may not be retained long enough for retrospective correlation.

Proxy access logs with HTTP status codes

Why it fails: Proxy logs capture HTTP request metadata and response codes for traffic that traverses the proxy, but encrypted tunnels and non-proxy-aware traffic may bypass them. They also typically lack accurate byte counts for long-lived encrypted sessions and cannot reliably show the volume and duration of arbitrary outbound transfers.

Avoid the risk by disconnecting the electronic health record system from all external networks permanently.

Why it fails: Avoidance eliminates the activity that generates risk, but here it would eliminate clinical care itself, which is unacceptable. Fully isolating the record system prevents vendor updates, remote specialist access, and interoperability mandated for patient treatment. Avoidance is only viable when the underlying business function can genuinely be discontinued, which is not the case for a hospital's core clinical platform.

Accept the risk because the electronic health record vendor contractually guarantees system uptime.

Why it fails: Vendor uptime commitments address service availability, not the confidentiality and integrity damage ransomware causes to patient records. Acceptance is inappropriate when likelihood is high and impact is critical, since residual risk would remain far above the hospital's tolerance. Contractual guarantees also rarely cover regulatory penalties, breach notification, or clinical disruption, so this treatment misreads the risk's true scope.

Transfer the risk entirely by purchasing a cyber insurance policy covering ransomware incidents.

Why it fails: Insurance transfers financial consequences but does not reduce the probability or operational impact of an attack on clinical systems. Patient safety and care continuity cannot be insured away, and policies carry limits, exclusions, and retention that leave residual exposure. Pure transfer is therefore insufficient for a high-likelihood, critical-impact risk affecting availability of the electronic health record.

The asset's physical rack location and data center row

Why it fails: Physical location is useful for on-premises hardware, but it provides no information about who is responsible for the asset or whom to contact during an incident. Cloud workloads and mobile devices have no rack or row, so relying on this element would leave significant portions of the hybrid inventory without actionable ownership data for escalation.

The asset's operating system build number and patch level

Why it fails: Patch level and OS build are critical for vulnerability management prioritization and exposure analysis, but they do not identify the business owner or the escalation contact. During an incident, responders need to know who can authorize containment and who understands the workload, so patch metadata alone does not satisfy the ownership and escalation requirement.

The asset's primary MAC address and hostname

Why it fails: MAC addresses and hostnames are identifiers that help correlate an asset across tools, but they are frequently spoofed, changed, or duplicated in virtual and cloud environments. They do not convey accountability, so an inventory built primarily around them will not tell a responder whom to escalate to when the asset is compromised.

Role-based access control restricting database queries to authorized analysts

Why it fails: Role-based access control limits who can query the database through normal application paths, but it does not protect the raw files on disk. An attacker with physical possession of the storage media can bypass database access controls entirely and read the underlying data unless it is encrypted.

Database activity monitoring generating alerts on anomalous queries

Why it fails: Database activity monitoring detects suspicious query patterns and supports incident response, but it is a detective control. It cannot prevent an attacker who has stolen the physical media from reading the data offline, so it fails to meet the stated confidentiality requirement.

TLS 1.3 for all client connections to the database

Why it fails: TLS 1.3 protects data in transit between clients and the database, but it does not encrypt data at rest on the storage media. If the disk is physically stolen, TLS provides no protection because the encrypted session ends at the network boundary and the stored records remain in plaintext.

Change the www-data password and remove it from the sudoers group to contain the incident, then review auth.log for further unauthorized commands.

Why it fails: Modifying credentials and group membership alters system state and may overwrite or invalidate evidence such as password hashes and sudoers timestamps. Containment actions taken before evidence preservation can destroy volatile and persistent artifacts alike. The analyst should first capture live state and logs, then contain, so that the investigation retains a defensible record of the attacker's actions.

Reboot the server into a trusted rescue environment to ensure no attacker processes interfere, then image the disk and parse auth.log from the image.

Why it fails: A reboot erases all volatile memory, active network connections, and running process context, which are critical for understanding how www-data obtained sudo rights. Although disk imaging from a rescue environment can preserve persistent files, the irreversible loss of live state violates order of volatility and severely limits root cause analysis. Reboot is a last resort, not an initial containment step.

Immediately run systemctl stop apache2 to halt the compromised service, then copy /var/log/auth.log to external media.

Why it fails: Stopping the service destroys in-memory process state, open file descriptors, and network connections that are more volatile than disk logs. Although copying the log preserves one artifact, the premature shutdown forfeits live evidence such as running processes and loaded modules. Order of volatility prioritizes memory and active state before persistent disk files, so this sequence is backwards.

Risk mitigation

Why it fails: Risk mitigation involves implementing controls to reduce likelihood or impact, such as patching the vulnerability, adding a web application firewall, or restricting access. In this scenario, no new controls are being applied; the organization is choosing to tolerate the risk until the system is retired. Therefore, mitigation is not the strategy being used.

Risk transference

Why it fails: Risk transference shifts the financial or operational impact to a third party, typically through insurance or outsourcing. Here, no third party is assuming the risk; the business owner is explicitly deciding to retain it. Because there is no contract or insurance shifting liability, transference does not apply to this situation.

Risk avoidance

Why it fails: Risk avoidance means eliminating the activity or system that introduces the risk, such as shutting down the application immediately. In this scenario, the application remains operational for two months, so the risk is not being avoided. The organization is choosing to live with the risk temporarily rather than remove the source, which distinguishes acceptance from avoidance.

Confidentiality

Why it fails: Confidentiality ensures data is accessible only to authorized parties. Immutable offline backups do not prevent unauthorized disclosure; they are a recovery mechanism. While backups themselves should be protected, the primary purpose described in the scenario is ensuring data remains accessible after an incident, which is an availability concern, not confidentiality.

Non-repudiation

Why it fails: Non-repudiation ensures a party cannot deny having performed an action, typically through digital signatures or audit logs. It is not part of the core CIA triad and does not describe the ability to keep records accessible after ransomware. Backups address recoverability and uptime, which fall under availability rather than non-repudiation.

Integrity

Why it fails: Integrity ensures data is not altered improperly. Backups can support integrity by providing a clean restore point, but the scenario specifically emphasizes keeping records available during a ransomware attack. The dominant requirement is uptime and recoverability, making availability the principle most directly satisfied by immutable offline backups.

Packet sniffing on the wire

Why it fails: Packet sniffing threatens confidentiality by passively reading traffic; it does not deny access to the database. It tempts because it is a network attack, and would be correct if the scenario concerned exposure of data in transit rather than service disruption.

Replay attack

Why it fails: A replay attack threatens integrity or authentication by retransmitting captured valid messages, not availability. It tempts because it is an active attack, and would be correct if the scenario concerned forged or duplicated transactions rather than denial of access to the database.

Unauthorized data modification

Why it fails: Unauthorised data modification threatens integrity, altering stored values without permission, not availability. It tempts because it is a serious database attack, and would be correct if the scenario concerned tampered records rather than the database being made unreachable or unusable.

Risk

Why it fails: Risk is the combination of the probability of an event and its consequences. The question asks specifically about the potential loss or harm, which is the impact, not the overall risk. Risk includes likelihood, whereas impact is only one component of risk.

Vulnerability

Why it fails: A vulnerability is a weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source. The question asks about the potential loss or harm, which is the impact, not the weakness itself.

Threat

Why it fails: A threat is any circumstance or event with the potential to adversely impact organizational operations, assets, or individuals. The question asks about the potential loss or harm itself, not the source of the harm. Threat is the actor or event, while impact is the resulting damage.

Defense Evasion

Why it fails: Defense Evasion includes techniques like obfuscation or disabling security tools. While encoded PowerShell can be used for evasion, the primary tactic here is Execution because the adversary is running code. The encoded command is a method of execution, not the overarching tactic; the scenario's core is the initial execution from a trusted application.

Persistence

Why it fails: Persistence involves maintaining foothold, such as creating scheduled tasks or registry run keys. Here, the spawning of PowerShell is an immediate execution step, not a mechanism to survive reboots or maintain access. The scenario does not describe any persistence mechanism being installed; it focuses on the initial code execution from the email attachment.

Privilege Escalation

Why it fails: Privilege Escalation aims to gain higher-level permissions, like SYSTEM or root. The scenario does not indicate any attempt to elevate privileges; it merely describes PowerShell being spawned from Outlook. The encoded command downloads a payload, but there is no mention of exploiting vulnerabilities or bypassing user account controls to escalate privileges.

Non-repudiation

Why it fails: Non-repudiation provides proof of the origin or delivery of data so a party cannot deny having performed an action. Encryption at rest protects data from unauthorized disclosure but does not create evidence binding an action to an identity. Digital signatures and audit trails are the mechanisms that support non-repudiation, not symmetric encryption of stored data.

Integrity

Why it fails: Integrity concerns protecting data from unauthorized modification, not disclosure. While some encryption modes provide authenticated encryption that can detect tampering, the primary purpose of AES-256 encryption at rest with an HSM is to prevent unauthorized reading of ePHI, not to detect or prevent alteration. Hashing or digital signatures are more directly associated with integrity assurance.

Availability

Why it fails: Availability ensures that systems and data are accessible when needed by authorized users. Encryption at rest does not improve availability; in fact, if keys are lost, availability can be reduced because data becomes unrecoverable. Redundancy, backups, and failover mechanisms are the controls that primarily support availability, not encryption.

TLS 1.3 for all database connections between the application and the database server

Why it fails: TLS 1.3 protects data in transit between the application and database, not data at rest on the storage array. If the physical array is stolen, the data on disk remains unencrypted and readable. TLS does not address the physical theft scenario described, so it fails to meet the stated requirement.

Role-based access control (RBAC) restricting database access to authorized DBAs only

Why it fails: RBAC limits logical access through database accounts, but it offers no protection when the physical storage device is removed. An attacker with the stolen array can bypass all access controls by mounting the disks directly. Access control is necessary but insufficient for the physical theft scenario described.

Database activity monitoring (DAM) with real-time alerting on anomalous queries

Why it fails: DAM detects and alerts on suspicious query patterns while the database is running and connected. It cannot prevent data disclosure from a stolen physical disk, and it generates no telemetry once the array is offline. Monitoring is detective, not preventive, and does not satisfy the confidentiality requirement.

Firewall logs

Why it fails: Firewall logs show allowed and denied connections based on IP addresses and ports, but they do not resolve domain names. They can indicate IP-based communication but not the domain names used by malware. Therefore, they are not the best source for domain names.

NetFlow records

Why it fails: NetFlow records provide metadata about network flows, such as source/destination IP, ports, and byte counts, but they do not include domain names. While they can show IP addresses contacted, they lack the domain resolution context. Thus, they are less effective for identifying C2 domains.

Proxy server logs

Why it fails: Proxy logs can capture HTTP requests and may include domain names if the proxy is configured to log them. However, many malware C2 channels use HTTPS or non-HTTP protocols, and proxy logs may not capture those. DNS logs are more comprehensive for domain resolution. Hence, proxy logs are not the most reliable.

Daily full backups of the web application and its database stored on the same host.

Why it fails: Backups support recovery but do not prevent compromise, and storing them on the same host means ransomware or host destruction can eliminate both copies. This is a resilience measure, not a preventive layer, so it does not satisfy the requirement for independent protection against application attacks.

A firewall rule permitting only port 443 inbound to the web servers.

Why it fails: Restricting inbound ports is good hygiene but only narrows the attack surface; it does not inspect application-layer payloads. An attacker can still deliver injection or authentication attacks over port 443, so this control alone leaves the application logic unprotected and cannot serve as a distinct defensive layer against web attacks.

A second WAF from the same vendor deployed in front of the first WAF.

Why it fails: Two identical WAFs share the same detection logic, signature set, and failure modes, so a bypass that defeats one will very likely defeat the other. This adds redundancy rather than diversity and does not create an independent layer, since a single flaw in the product family affects both devices.

T1134 Access Token Manipulation

Why it fails: Access Token Manipulation involves manipulating access tokens to operate under a different user or security context. While it can be used for privilege escalation, it does not involve injecting code into a remote process. The scenario specifically describes CreateRemoteThread, which is a process injection method, not token manipulation.

T1055.002 Portable Executable Injection

Why it fails: Portable Executable Injection is a sub-technique of Process Injection where a portable executable is injected into a process. While CreateRemoteThread can be used in PE injection, the scenario does not specify that a PE is being injected; it only mentions executing code via CreateRemoteThread. The broader technique T1055 Process Injection is more accurate, as it encompasses various injection methods. Additionally, the question asks for the technique, not the sub-technique, and T1055 is the parent technique.

T1055.012 Process Hollowing

Why it fails: Process Hollowing is a specific sub-technique of Process Injection where a legitimate process is created in a suspended state, its memory is replaced with malicious code, and then it is resumed. The scenario describes using CreateRemoteThread to inject into an existing remote process, which is a different sub-technique (e.g., T1055.002 Portable Executable Injection or T1055.003 Thread Execution Hijacking). Process Hollowing does not typically involve CreateRemoteThread in the same way.

T1136.001 Create Account: Local Account

Why it fails: Create Account: Local Account involves creating a new local account for persistence. The scenario describes creating a service, not an account. Account creation is a different technique that provides access but does not involve service execution.

T1053.005 Scheduled Task/Job: Scheduled Task

Why it fails: Scheduled Task/Job involves creating a scheduled task to run a program at a specific time or trigger. While also a Persistence technique, the scenario describes a Windows service, not a scheduled task. The mechanism and registry locations are different, so this technique does not apply.

T1547.001 Registry Run Keys / Startup Folder

Why it fails: Registry Run Keys or Startup Folder persistence involves adding entries to the registry or startup folder to execute programs at logon. The scenario involves a Windows service, which is a different persistence mechanism. Services run at system startup before user logon, whereas Run Keys execute at user logon.

Annualized loss expectancy (ALE) calculation

Why it fails: ALE calculation is a quantitative method that computes expected annual financial loss using asset value, exposure factor, and annualized rate of occurrence. It relies on numerical estimates and is not a qualitative technique. The scenario explicitly asks for qualitative risk analysis methods.

Monte Carlo simulation

Why it fails: Monte Carlo simulation is a quantitative technique that uses probability distributions to model potential outcomes. It requires numerical data and is not typically classified as a qualitative method. The scenario asks for qualitative techniques, so this option does not fit.

Fault tree analysis

Why it fails: Fault tree analysis is a deductive technique often used in reliability and safety engineering to identify combinations of failures that lead to an undesired event. While it can be qualitative or quantitative, it is not a standard qualitative risk analysis technique for general cybersecurity risk assessments and is less common in this context.