Hard Difficulty Questions

Hard drive image, network connections, running processes, RAM

Why it fails: RAM should be first, not last.

Running processes, RAM, hard drive image, network connections

Why it fails: RAM should be first.

Network connections, hard drive image, RAM, running processes

Why it fails: RAM is more volatile than network or disk.

Resetting all user passwords

Why it fails: Resetting passwords is important but does not remove the backdoor from the system.

Reimaging all affected systems from a known-good backup

Why it fails: Reimaging is effective but the question asks for the MOST critical step; if the backdoor is still present, reimaging might be necessary. However, the scenario implies the backdoor is already identified and removal can be attempted.

Conducting security awareness training for all employees

Why it fails: Training reduces future risk but does not address the current infection.

A warm site is typically ready to operate within hours.

Why it fails: Warm sites may take hours to days; hot sites are ready within minutes.

A warm site has live data replication from the primary site.

Why it fails: Live replication is characteristic of hot sites.

Apply the patch immediately without change management

Why it fails: Applying the patch immediately bypasses change management, which still applies to emergency patches; an emergency change process exists for exactly this situation. Skipping it tempts because active exploitation demands speed, yet unrecorded changes risk outages and audit failures, so the patch should follow the emergency change procedure.

Ignore the patch because the server is low criticality

Why it fails: Active exploitation plus a CVSS score of 9.8 outweighs the server's low criticality classification, so the patch must be applied. Ignoring it tempts because criticality ratings normally guide prioritisation, but exploited vulnerabilities demand emergency remediation regardless of the asset's business classification.

Wait for the next scheduled patch cycle

Why it fails: Active exploitation with CVSS 9.8 demands emergency remediation regardless of server criticality, since compromise can pivot to higher-value assets. Waiting for the scheduled cycle leaves the vulnerability exploitable for weeks. Scheduled cycles suit low-severity issues with no known exploitation and no compensating controls in place.

Disable the affected user accounts.

Why it fails: Account disabling is containment, not eradication.

Reimage all affected systems.

Why it fails: Reimaging is effective but may be too drastic if cleaning is possible.

Run an antivirus scan on the systems.

Why it fails: Antivirus may not detect fileless malware.

Exception requests for unpatched systems are documented

Why it fails: Documenting exception requests satisfies the audit trail requirement, so it evidences control rather than a gap. The critical gap is the absence of a defined remediation timeline or risk acceptance for unpatched systems. Formal exception handling is correct when compensating controls exist and management has approved the residual risk.

Critical systems are patched monthly

Why it fails: Monthly patching leaves critical systems exposed to exploits for up to thirty days, exceeding typical remediation windows for high-severity vulnerabilities. It is tempting because monthly cycles suit low-risk internal assets where rapid exploitation is unlikely, but critical internet-facing systems demand emergency patching on vendor release.

Patches are deployed within 30 days of release

Why it fails: A 30-day deployment window is a defined, measurable remediation timeframe, not a gap. A critical gap would be the absence of any deadline, or patches never applied; meeting a stated SLA indicates the process is functioning.

Report the non-compliance to management for remediation

Why it fails: Exceeding Level 1 complexity is not non-compliance, so there is nothing to report for remediation; the benchmark specifies a minimum baseline, and stricter settings remain conformant. Reporting is tempting because auditors routinely flag deviations, but a deviation that strengthens controls is not a finding.

Implement Level 2 benchmarks to be consistent

Why it fails: CIS Level 2 is a separate, stricter profile intended for high-security environments, not a consistency fix; the server already satisfies Level 1, so adopting Level 2 changes scope without a policy mandate. It tempts when teams equate stricter with compliant, yet the policy names Level 1 only.

Immediately revert to Level 1 settings to ensure compliance

Why it fails: Exceeding CIS Level 1 password complexity does not violate the benchmark, since Level 1 sets a minimum baseline rather than a ceiling; reverting weakens security for no compliance gain. Reverting is tempting when an auditor treats any deviation as a finding, but hardening above the baseline is permitted.

Number of systems affected and patch size

Why it fails: Patch size is irrelevant to risk, and system count alone ignores severity; a critical remote-code-execution flaw on one internet-facing server outranks a cosmetic fix on a thousand workstations. Severity plus exposure and asset criticality determine the order patches should be applied.

Age of the patch and vendor reputation

Why it fails: Patch age and vendor reputation say nothing about exploitability or exposure; an old patch for unused software outranks a fresh critical remote-code-execution fix under this logic. Reputation is also subjective. Severity combined with internet exposure and asset criticality drives prioritisation instead.

Cost of the patch and availability of workarounds

Why it fails: Patch priority hinges on exploitability and severity, not procurement cost or workaround availability. Cost and workarounds inform risk acceptance or deferral decisions once a vulnerability's CVSS rating and exposure are known, so they belong to remediation planning rather than the initial prioritisation ranking itself.

Event logs from other systems

Why it fails: Event logs from other systems are not stored on the compromised system.

Prefetch files

Why it fails: Prefetch files may also be cleared or overwritten.

Registry keys

Why it fails: Registry keys could be altered or deleted by the attacker.

Write denied

Why it fails: The question asks about a read attempt, and Bell-LaPadula's simple security property already denies reads above clearance. Write denial concerns the star property, which restricts writing downward; it does not answer what happens when a Secret subject reads a Top Secret object.

Write allowed

Why it fails: Bell-LaPadula's simple security property forbids reading above clearance, so a Secret subject reading a Top Secret object is denied, not permitted to write. Write permission is irrelevant to a read attempt; the no-write-down property governs writing, not reading.

Read allowed

Why it fails: Bell-LaPadula's simple security property states no read up: a Secret-cleared subject cannot read a Top Secret object, so the attempt is denied. Read-up is permitted only under models such as Biba, which prioritise integrity rather than confidentiality.

Reset the user's password.

Why it fails: Resetting the password might lock out the legitimate user, but if the account is compromised, the attacker may have other persistence mechanisms. It does not immediately stop access if the attacker has already established a session or backdoor. Disabling the account is a stronger containment measure.

Notify law enforcement.

Why it fails: Notifying law enforcement may be required eventually, but it is not the first step. Immediate containment is necessary to prevent further damage. Law enforcement involvement typically follows internal investigation and containment, and may be subject to legal and regulatory considerations.

Review the file's contents to determine sensitivity.

Why it fails: Reviewing the file's contents may be part of the investigation, but it does not stop the ongoing threat. The account could still be used for further malicious activity. The first priority is to contain the incident, not to assess data sensitivity, which can be done after the account is secured.

Implement a clean desk policy

Why it fails: Clean desk policy is unrelated to physical access controls.

Install a CCTV camera to monitor the mantrap

Why it fails: CCTV is detective, not preventive.

Use biometric readers on both doors

Why it fails: Biometrics don't prevent propping open doors.

Immediately disconnect the server from the network to stop beaconing

Why it fails: Disconnecting halts beaconing but violates the availability requirement for the critical application and severs the network telemetry the jump box needs. It is tempting as immediate containment, and would be correct for a confirmed, actively spreading compromise on a host that can tolerate downtime.

Block the suspicious IP at the firewall and continue monitoring

Why it fails: Firewall blocking stops outbound beaconing to that one address but leaves the implant resident and able to reach alternate command-and-control infrastructure, so the investigation stalls. It is tempting because it is quick and non-disruptive, and would be correct as a containment measure once the malicious process has been identified and scoped.

Reimage the server from a known good backup

Why it fails: Reimaging would cause significant downtime and may not be necessary if the threat can be contained.

Reduced cipher suite options including CBC mode

Why it fails: CBC mode is not among TLS 1.3's permitted ciphers; the standard removed CBC entirely because of padding-oracle attacks such as Lucky13. It is tempting because CBC was a common TLS 1.2 option, but the correct answer is TLS 1.3's AEAD-only suites, which eliminate those padding vulnerabilities.

Use of RC4 cipher

Why it fails: RC4 is a broken stream cipher with documented biases, and TLS 1.3 prohibits it along with all non-AEAD ciphers. It is tempting because RC4 was historically valued for speed on constrained hardware, but the correct answer is TLS 1.3's mandatory AEAD cipher suites, which provide authenticated encryption.

Support for static RSA key exchange

Why it fails: Static RSA key exchange lacks forward secrecy, so a compromised long-term key exposes all recorded sessions; TLS 1.3 removed it entirely. It is tempting because static RSA was ubiquitous in TLS 1.2 deployments and appears to simplify handshakes, but the correct answer is TLS 1.3's ephemeral (EC)DHE-only key establishment.

Quarantine the endpoint anyway.

Why it fails: Quarantining an endpoint for a confirmed false positive disrupts business operations without cause; the file is benign, so no containment is warranted. Isolation suits genuine compromise or active containment scenarios, where an endpoint is confirmed infected and must be severed from the network.

Escalate to management.

Why it fails: Management escalation adds no value once the alert is verified as a false positive; there is no business risk, decision or resource conflict requiring their authority. Escalation fits unresolved incidents, policy exceptions or suspected breaches needing executive sign-off, not a closed benign alert.

Delete the alert from the SIEM.

Why it fails: Deleting the alert destroys the audit record of the detection and its false-positive determination. It is tempting because the alert is noise and clearing it tidies the console, but the stem requires a documented disposition; the analyst should close or mark it as a false positive with justification, preserving evidence.

Set the container to run as non-root user

Why it fails: Running as non-root blocks root-owned file access inside the container, yet a process can still set allowPrivilegeEscalation or add capabilities and gain root. It is tempting because non-root users are a standard baseline hardening step, but it does not prevent escalation.

Mount the container root filesystem as read-only

Why it fails: A read-only root filesystem blocks writes to the image layer but does not stop privilege escalation through setuid binaries, capabilities, or privileged mode. It is tempting as a hardening measure, and it would be correct for preventing runtime tampering with container files, but not for least-privilege enforcement.

Enable SELinux enforcing mode on the host

Why it fails: SELinux confines host processes and files, but it does not stop a container running as root from exploiting privileged flags or kernel capabilities inside the cluster. It is tempting because it hardens the underlying node, which is a separate layer from pod-level privilege controls.

Change the user's password to a default

Why it fails: Resetting a password to a default leaves the credential known and guessable, and the account still exists, so access is not revoked. It is tempting because administrators sometimes reuse accounts for reassignment, but offboarding requires disabling or deleting the account and terminating its sessions, entitlements and tokens instead.

Notify the user that their account will be removed

Why it fails: Notifying the departing user is courteous but not mandatory; offboarding must proceed on the organisation's schedule regardless of acknowledgement. It is tempting because communication is good practise during workforce changes, yet the mandatory steps are revoking access, disabling credentials and recovering assets, not informing the user.

Delete the account and all associated data

Why it fails: Deleting the account and all associated data conflicts with retention, legal-hold and audit obligations, and destroys evidence needed for investigations. It is tempting because deletion appears to guarantee no residual access, but offboarding requires disabling or removing access while preserving records according to the organisation's retention policy.

Vulnerability scanning

Why it fails: Vulnerability scanning identifies weaknesses and feeds risk assessment; it is not a change management step, which covers requesting, approving, implementing and reviewing changes. It tempts because scan findings often trigger change requests, but scanning itself sits in vulnerability management.

Baseline configuration update

Why it fails: Updating the baseline configuration is a configuration management activity performed after a change is approved and implemented, not a change management process step itself. It tempts because baselines and changes are closely linked, but the process covers request, approval, implementation and review.

The firewall is blocking outbound TCP port 80 and 443.

Why it fails: Blocking outbound 80 and 443 would drop packets regardless of the DF flag, and internal browsing would typically also fail unless those servers use different ports. Port filtering is the right diagnosis when logs show consistent drops on specific destination ports. The DF flag points to MTU, not port policy.

The DNS server is not resolving external domain names.

Why it fails: DNS resolution failures produce name-resolution errors before any TCP connection, so packets would never reach the firewall with the DF flag set. DNS is the correct suspect when users cannot resolve hostnames at all. Here the DF flag indicates a path MTU discovery failure, not a naming problem.

The switch port connecting the firewall is set to the wrong VLAN.

Why it fails: A wrong VLAN would break connectivity entirely, including access to internal web servers, and would not selectively drop packets carrying the DF flag. VLAN misconfiguration is the correct answer when a host cannot reach anything on the expected subnet. The DF flag indicates fragmentation and MTU issues instead.

Use a write blocker when capturing the memory dump

Why it fails: Write blockers prevent writes to block storage devices during acquisition; they do not govern volatile memory capture, which is performed by tools reading RAM directly. It is tempting because write blockers are standard for disk imaging. Memory acquisition instead relies on hashing the dump and documenting the process.

Store the memory dump on the same server for easy access

Why it fails: Storing the dump on the compromised host lets an attacker or malware alter or delete it, and the host's own state is untrusted, so chain of custody and integrity cannot be demonstrated. It is tempting because it is convenient and requires no extra media. Isolated, write-once storage is required for forensic evidence.

Run antivirus on the memory dump file

Why it fails: Antivirus scans modify or quarantine files and can alter the dump's contents, destroying its evidentiary value and hash integrity. It is tempting because scanning captured artefacts feels like responsible handling. Antivirus belongs on live systems or analysis copies, never on the original evidence file.