Hard Difficulty Questions

Phishing

Why it fails: Phishing typically involves deceptive emails or fraudulent websites with malicious links or attachments designed to harvest credentials. This attack occurs entirely over a live phone call, with no email or web content involved, so the more precise classification is vishing—voice phishing—rather than generic phishing.

Baiting

Why it fails: Baiting relies on luring a victim with an attractive offer, such as a free download, contaminated USB drive, or fake prize, to trigger a specific action like inserting a device or clicking a link. The exhibit shows an attacker impersonating support staff on a call to directly coax an MFA code, not offering any digital or physical bait, so baiting does not apply.

Pretexting

Why it fails: Pretexting describes the broader tactic of fabricating a believable story to establish false legitimacy, but it is channel-agnostic—it could happen via email, chat, or in person. The exhibit specifically depicts a phone call with urgent requests and caller ID spoofing, which points to vishing as the precise attack type, even though a pretext is being used.

Run one server and keep nightly backups in cloud object storage.

Why it fails: Backups help recovery after loss, but they do not provide automatic service continuity during an outage.

Deploy active-active multi-region capacity with identical production load in both regions.

Why it fails: Active-active meets the availability goal, but it usually costs more than the scenario allows and duplicates production capacity.

Add RAID 1 and a spare power supply to the database server.

Why it fails: These hardware controls improve a single server’s reliability, but they do not address a site outage or application-level failover.

HTML-encode the report name before inserting it into the shell command.

Why it fails: HTML encoding protects web pages from script injection, not operating-system shell interpretation. It does not stop the shell from treating characters like semicolons or pipes as command separators. The control does not address the execution context shown in the scenario.

Switch the feature from POST to GET so the values are easier to inspect.

Why it fails: Changing HTTP method does not fix command injection. The vulnerability is in how the server uses the input, not in the request verb. GET may even make sensitive values more visible in logs and history without improving security.

Hide the server error messages so attackers cannot see the failure details.

Why it fails: Suppressing error output can reduce information leakage, but it does not stop command execution. The application would still process attacker-controlled shell content if the input is unsafe. This is a helpful hardening measure, not a root-cause fix.

The traffic is normal web browsing to a content delivery network.

Why it fails: Normal web browsing to a content delivery network would generate HTTP or HTTPS requests to standard ports (80/443) with visible GET/POST paths, and would show TCP handshakes and data transferred over those connections. The exhibit instead shows repeated DNS TXT queries, which are UDP-based DNS record lookups carrying no web session data. A CDN might legitimately serve content via HTTPS, but it would not explain the absence of any web requests and the exclusive use of DNS queries.

The issue is most likely ARP spoofing on the local switch port.

Why it fails: ARP spoofing operates at Layer 2, poisoning the IP-to-MAC mapping on a local switch port to redirect traffic to an attacker's machine, causing misrouted frames and MITM interception. It would produce duplicate IP/MAC bindings in the ARP cache and unusual ARP replies, but it would not cause the host to generate a continuous stream of DNS TXT queries at a predictable interval. The exhibit shows a stealthy DNS beacon pattern, which is unrelated to local Layer 2 address resolution issues.

The evidence most strongly indicates a password spraying campaign.

Why it fails: Password spraying involves an attacker trying a few common passwords against many user accounts across the network, which generates failed authentication events, account lockouts, and traffic to authentication services like LDAP, Kerberos, or web single sign-on portals. The exhibit contains no such authentication logs or login attempts; instead, it shows a single host emitting DNS TXT queries with unique subdomains on a regular schedule. This beaconing behavior indicates command-and-control or data exfiltration, not a brute-force credential attack.

Avoid insecure state: Defense in depth

Why it fails: Avoiding an insecure state is achieved by fail secure controls, not defense in depth. Defense in depth is a layered protection strategy that assumes multiple defenses; it does not define how a system behaves when a component fails. A fail secure control ensures that upon a failure, such as a power loss or error, the system transitions to a secure state (e.g., locked doors default to locked) rather than an insecure one. Confusing fail secure with defense in depth misattributes a specific failure-mode guarantee to a general layered-security concept.

Reduce misconfiguration: Least privilege

Why it fails: Reducing misconfiguration is the goal of secure defaults, not least privilege. Secure defaults ensure that when a system is initially deployed or configured, its out-of-the-box settings are already hardened, meaning insecure options are disabled by default and secure options are enabled. Least privilege, in contrast, is about restricting the rights and permissions of an authenticated user or process after deployment, not about the initial configuration state. Misconfiguration often stems from overly permissive defaults, which least privilege does not directly address.

Enforce consistently: Separation of duties

Why it fails: Enforcing access decisions consistently is achieved by complete mediation, not separation of duties. Complete mediation requires that every access request to every object be verified against the authorization policy each and every time, without caching or relying on prior checks. Separation of duties, on the other hand, is a fraud-prevention control that divides responsibilities among different people. These are fundamentally different mechanisms: complete mediation is a property of access control systems, whereas separation of duties is an organizational and procedural control.

Email phishing is used because the attacker is requesting a login action.

Why it fails: Phishing is a broad term, but this scenario is specifically about SMS and voice, not email. Since the channel is not email, calling it email phishing would be inaccurate. The attacker may still be phishing generally, but the more precise attack channels are different and more useful for response.

Baiting is used because the attacker offers a free reward or device.

Why it fails: Baiting usually involves enticing the victim with something attractive, such as free media, hardware, or a promised benefit. This scenario instead uses a fake service request and a follow-up call. There is no lure of a reward, so baiting is not the best fit.

Tailgating is used because the attacker follows someone into a restricted area.

Why it fails: Tailgating is a physical social engineering tactic involving unauthorized entry into a secured space. This scenario takes place over SMS and phone, so it does not involve a person following another through a door or into a controlled area. That makes tailgating irrelevant here.

The pattern is most consistent with password spraying across many accounts.

Why it fails: Password spraying is characterized by a small number of common passwords being tried against a large set of usernames, specifically to avoid triggering account lockout policies. In this SIEM data, all 17 failures are concentrated on a single account, not distributed across many accounts. That concentration is the opposite of spraying's low-and-slow approach, so while both are credential attacks, the pattern does not match spraying.

The events primarily indicate a volumetric denial-of-service attack.

Why it fails: A volumetric denial-of-service attack is designed to exhaust network bandwidth, server connections, or other resources by flooding them with high-volume traffic. The events here consist of 17 authentication failures and a token creation — neither of which generates the massive traffic required for a DoS. There is no indication of resource saturation or service unavailability, so the sequence is clearly about credential access and session abuse, not availability disruption.

Token creation proves the account password was never exposed.

Why it fails: Creating a token after a successful login is often the direct result of the attacker authenticating with the correct password, which could have been obtained through the brute-force attack. Tokens are issued by identity providers after authentication succeeds, so their existence is evidence that the password was used, not that it was never exposed. A compromised password frequently leads to token creation as part of persistence, so this option misreads the forensic artifact.

Allow administrators to enable any service they need without approval during maintenance windows.

Why it fails: Unrestricted changes during maintenance windows encourage configuration drift and make it difficult to prove the host still matches the approved baseline. Temporary convenience can become permanent exposure if changes are not tracked and reversed. Controlled change management is safer than informal administrator discretion.

Keep the default installation profile so vendor updates are easier to apply.

Why it fails: Keeping the default installation profile fails this scenario because it directly contradicts the objective of establishing a secure baseline by removing unnecessary services. Default profiles frequently include components like graphical desktops or Telnet that are not essential for a database host, thus perpetuating the very drift the operations team wants to prevent. This option is tempting as maintaining a default profile can simplify vendor updates and support, making it a valid consideration when ease of maintenance for a general-purpose server outweighs the immediate need for aggressive security hardening and minimal attack surface reduction.

Open the firewall broadly and rely only on strong passwords.

Why it fails: Broad firewall rules weaken the boundary around the host and do not correct the unnecessary services already running. Strong passwords are important, but they do not compensate for exposed and unused management or legacy services. Hardening requires reducing both exposure and drift.

User files are renamed with a new extension and a ransom note appears.

Why it fails: Renamed files and ransom notes are classic signs of ransomware, not spyware. Ransomware focuses on extortion through encryption or disruption, while spyware focuses on covert collection of data. This behavior points to a different malware family and does not match the scenario described.

CPU usage spikes only during a scheduled operating system update.

Why it fails: Temporary CPU usage during a scheduled update is normal and does not imply malware. Without further evidence such as suspicious processes, odd network destinations, or unauthorized persistence, this is not a useful spyware indicator. It is more likely to be ordinary maintenance activity.

The browser certificate store was refreshed after applying a patch.

Why it fails: Refreshing the certificate store after a patch is a normal administrative event. It does not indicate keylogging, exfiltration, or covert monitoring. While certificate manipulation can be malicious in some attacks, this specific detail is routine and not aligned with the spyware behaviors in the scenario.

Least privilege, because each employee should only have the fewest permissions needed for the shared account.

Why it fails: Least privilege is important, but the real issue is broader than simply reducing permissions. The problem is that one identity can complete the full payment workflow, which allows a single person to create, approve, and alter payment data. That concentration of power is what creates the fraud risk, so the better principle is separation of duties.

Need-to-know, because only employees with confidential financial data should see the workflow details.

Why it fails: Need-to-know limits access to information, not necessarily to the ability to complete an entire business transaction. The exhibit is about who can perform which finance actions, not who can read a report. Restricting data visibility may help privacy, but it does not address the fraud risk created by one account being able to execute every step.

Defense in depth, because the organization should add more security layers around the finance process.

Why it fails: Defense in depth means multiple layers of protection, such as logging, approvals, and monitoring. Those layers can help, but they do not specifically solve the core issue shown in the workflow. The exhibit reveals a role-concentration problem, where one identity can complete the entire process. That is precisely what separation of duties is designed to prevent.

Store the private key on the same backup server so recovery is faster.

Why it fails: Putting the private key on the same server creates a single point of failure and weakens key protection. If the server is lost, compromised, or destroyed, the organization may also lose the ability to decrypt the backup key material.

Replace AES with hashing so the archive no longer needs a key.

Why it fails: AES is a reversible symmetric encryption algorithm used to protect backup data, whereas hashing (e.g., SHA-256) is a one-way deterministic function. Replacing AES with hashing would make the archive irreversible; you could compute a digest but never recover the original data, so the backup becomes unrecoverable. Additionally, hashing provides integrity, not confidentiality, and it still requires secret inputs (like a pepper) or exposes data to offline attacks, so the premise that it eliminates key management is false.

Send the private key to backup operators by email so they can restore data quickly.

Why it fails: Email is an inherently insecure transport mechanism that involves multiple relays, server-side storage, and potential eavesdropping. Sending the private key to backup operators via email exposes the key to interception, forwarding, and unauthorized access, and it violates the principle of least privilege by distributing key material to individuals who only need access during specific recovery events. Because the private key controls the decryption of all AES-encrypted backup keys, a single email compromise could result in the loss of confidentiality of the entire backup archive, making this an unacceptable recovery method.

The invoice is confidential because the signature encrypts the document contents.

Why it fails: Digital signatures do not provide confidentiality by themselves. The document may still be readable to anyone who has access to it. The exhibit only shows the signature validated successfully, which speaks to trust and integrity, not secrecy.

The invoice can be edited if the timestamp is still within business hours.

Why it fails: A timestamp does not grant permission to modify a signed document. If the file were edited, the digest would no longer match the signature. The exhibit explicitly says the digest matches, which supports integrity, not a temporary editing window.

The sender’s private key is now public because the certificate verified successfully.

Why it fails: Verifying a certificate does not expose the sender’s private key. The private key remains protected and should never be made public. Successful verification only means the public certificate chain and signature were accepted as valid by the trust store.

SQL injection is present because the customerId value changes in the URL.

Why it fails: A parameter changing from one integer to another does not by itself indicate SQL injection. SQL injection would require evidence that the application is interpreting malicious SQL syntax, such as quotes, comments, or database error behavior. Here, the clue is unauthorized object access, not database query manipulation.

Cross-site scripting is present because the invoice data is returned in the browser.

Why it fails: Receiving another user's invoice in the browser is not evidence of script injection. Cross-site scripting requires malicious script execution in a victim's browser context. The scenario describes unauthorized data disclosure through an identifier change, which is an access-control problem rather than a content-injection issue.

Insecure deserialization is present because the request uses JSON-like parameters.

Why it fails: The presence of request parameters or JSON formatting does not imply insecure deserialization. That weakness involves tampering with serialized objects or object state during parsing. The scenario provides no evidence of object deserialization, integrity bypass, or gadget-chain exploitation.

Reflected cross-site scripting, because the tester's input is being echoed back into the response.

Why it fails: Reflected XSS would cause the injected payload to execute as client-side JavaScript in the victim's browser, producing behaviors like DOM manipulation or cookie theft. However, the described symptom is a server-side, query-dependent response-time delay that persists even when the page appears to render normally. A single quote followed by a conditional sleep indicates the input is being evaluated by a database engine, not echoed for browser interpretation. Thus, while the input may be reflected, the observable timing channel is characteristic of SQL injection, not XSS.

Command injection, because the application is pausing while executing system-level sleep commands.

Why it fails: Command injection typically exploits a weakness in shell or system-level command execution, where commands like `sleep` are executed by the operating system, often causing a fixed delay. Here, the delay is tied to crafted SQL conditions (e.g., conditional `SLEEP()` inside a query) and varies based on the logical evaluation of injected fragments. The application appears to return normal results, suggesting the payload is being processed within a database query, not passed to a system shell. Also, standard command injection would likely produce OS-specific error messages or side effects, not subtle, repeatable timing differences consistent with a database's response time.

Session fixation, because the tester is manipulating how the application handles user input over time.

Why it fails: Session fixation is an attack where an attacker forces a victim to use a known session identifier before authentication, then hijacks the session after the user logs in. It has nothing to do with how a search field processes or times its queries, and it would not produce a consistent, input-dependent delay pattern. Manipulating user input over time is a general description of many web attacks, but the specific mechanism here—database-driven conditional sleep triggered by SQL keywords—points to a backend injection flaw, not session management. Therefore, the observed behavior is a database timing side channel, not a session-related vulnerability.

Move the servers into a single larger subnet so internal routing is simplified

Why it fails: Consolidating servers into a single larger subnet does not segment east-west traffic; it actually eliminates any existing Layer 3 boundary, thereby increasing the attack surface for lateral movement rather than reducing it. This approach is tempting because a larger subnet can simplify routing tables and reduce broadcast domain fragmentation, which would be correct if the goal were to improve network performance or reduce administrative overhead, not to contain a breach.

Place the servers behind a network address translation device to hide their IP addresses

Why it fails: NAT can hide addressing details, but it does not provide meaningful internal segmentation or limit east-west access between the workloads. An attacker who compromises one host may still reach the other if no filtering exists.

Rely on password rotation and MFA for administrative logins only

Why it fails: Password rotation and MFA strengthen identity authentication, but they do not restrict network traffic between workloads. Even if an attacker cannot use stolen credentials directly, they could exploit a vulnerability in one server and then move laterally to another through unsegmented east-west paths. Microsegmentation enforces traffic rules independent of authentication state, making it the only option here that actually limits post-compromise movement.

Let all corporate laptops connect directly to SSH on the servers if MFA is enabled.

Why it fails: Enabling MFA on direct SSH connections does not prevent lateral movement if an admin laptop is compromised, because an attacker with access to an authenticated session can still pivot to other servers without re-authenticating. This design also fails to log every administrative session centrally, as SSH logs remain on individual servers rather than being captured in a session recorder or jump host. It is tempting because MFA is a strong authentication control that reduces credential theft risk, and in a scenario where only authentication security matters—without requirements for session logging or lateral movement containment—it would be a valid choice.

Expose SSH to the internet because key-based authentication is already strong.

Why it fails: Publicly exposing SSH is unnecessary and increases brute-force, scanning, and exploitation risk. Key-based authentication helps, but it does not justify direct internet access to management services. The requirement is to remove direct access from employee laptops, not extend management services to untrusted networks.

Use split tunneling for admin traffic so management packets can bypass the VPN.

Why it fails: Split tunneling is generally used to route some traffic outside the secure tunnel, which is the opposite of what this scenario needs. Management traffic should be tightly controlled and inspected, not routed around security controls. Bypassing the VPN would weaken the protected management path.

Use a cold site that is powered off until a disaster is declared.

Why it fails: A cold site may eventually support disaster recovery, but it usually has a long startup delay and does not meet a 30-minute downtime target. It is too slow for an environment that must recover quickly from a site outage and keep transactions flowing with minimal interruption.

Take nightly backups to meet the 5-minute recovery point objective.

Why it fails: Nightly backups create a much larger potential data-loss window than 5 minutes. Backups are essential for recovery, but they are not a substitute for replication when the business needs very low RPO. This option does not match the stated transaction-loss tolerance.

Rely on weekly VM snapshots because they are faster than replication.

Why it fails: Weekly snapshots are far too infrequent for a 5-minute recovery point objective and do not provide continuous availability. Snapshots can help with point-in-time rollback, but they do not replace real-time replication or failover for a payment system with strict uptime requirements.

Preventive controls, because they stop every possible compromise completely.

Why it fails: The measures do reduce risk, but they do not eliminate all compromise paths and are not being used in the normal ideal way. The important clue is that the primary security requirements cannot be met on the device itself, so alternate controls are used instead.

Corrective controls, because they repair the controller after an incident occurs.

Why it fails: Corrective controls address damage after a security event or restore systems to a secure state. The exhibit describes measures already put in place before an incident to reduce exposure. That makes them compensating, not corrective, controls.

Deterrent controls, because they mainly scare attackers away from trying.

Why it fails: Deterrent controls discourage attacks, such as visible signage or warning banners. The exhibit contains concrete technical and procedural restrictions that limit access and increase visibility. Those measures do more than discourage; they compensate for missing native protections.

Document the deviations and rely on manual checks after each maintenance window

Why it fails: Documentation and manual checks after maintenance windows are inherently reactive and dependent on human follow-through. Configuration drift can occur at any time, not just during scheduled maintenance, and a manual review cannot continuously verify that all services, registry keys, and permissions remain at the hardened baseline. Even with a checklist, repeated inconsistencies across many servers will be missed, and documentation does not enforce or remediate insecure settings. This approach does not scale and leaves security controlled by memory and discipline rather than automation.

Run a vulnerability scan more often and close the findings in the ticketing system

Why it fails: A vulnerability scanner provides a point-in-time snapshot of known weaknesses but cannot correct the underlying drift that allows insecure services or settings to persist. Closing findings in a ticketing system creates a manual remediation loop that still depends on an administrator to reapply the baseline, and the same issue will likely reappear after the next change. Additionally, scanners may miss configuration issues that do not map to a specific CVE, and they do not address the enforcement gap. The goal should be automated remediation, not just more frequent detection of the same recurring problems.

Increase storage capacity so the image can be rebuilt faster next time

Why it fails: Increasing storage capacity does nothing to prevent or repair configuration drift because the problem is logical state, not disk space. Even if the image can be rebuilt faster, the new server will inherit the same insecure modifications unless the build process itself enforces the hardened baseline. A larger storage allocation only helps with backup or image placement, but it cannot reapply disabled security policies or re-enable blocked services. The root cause is the lack of continuous configuration enforcement, so improving storage architecture is orthogonal to the security failure.

ARP poisoning, because the attacker is changing IP-to-MAC mappings on the local network.

Why it fails: ARP poisoning specifically corrupts the Layer 2 IP-to-MAC resolution table on hosts or switches, allowing an attacker to intercept traffic after it has been addressed. In this scenario, the laptops are being assigned a wrong default gateway directly from a forged DHCP offer, so they never even attempt to resolve the legitimate gateway's IP because their IP stack is already misconfigured by the rogue server. The attack occurs during initial network configuration, before ARP lookups are made, so ARP poisoning is not the immediate mechanism causing the observed symptoms.

Replay attack, because the attacker is reusing old DHCP offers.

Why it fails: A replay attack involves capturing legitimate DHCP messages and retransmitting them later to trick clients into accepting stale or previously used offers. This scenario describes an active rogue DHCP server that responds to the laptops' DHCP DISCOVER requests in real time, handing out a malicious default gateway rather than reusing a previously seen offer. The switch reboot causes clients to renew their leases, which creates an opportunity for an unauthorized server to inject its own fresh DHCP responses, not for an attacker to replay old ones.

DNS poisoning, because the clients are being sent to the wrong network path.

Why it fails: DNS poisoning alters name resolution to misdirect clients to malicious hostnames or addresses. Here the wrong default gateway is being assigned directly by a fake DHCP server, so the issue is earlier in the network configuration process.