Hard Difficulty Questions

Generating a hash value of the forensic image and storing it separately from the image

Why it fails: Hash values verify the integrity of the forensic image, proving it has not changed since acquisition. While important, a hash alone does not establish who had control of the evidence or whether it was properly handled. Without a documented chain of custody, the hash value may be challenged as insufficient to prove the evidence was not tampered with during storage or transfer.

Using a write blocker during imaging to prevent modification of the original disk

Why it fails: A write blocker is essential during the acquisition phase to prevent accidental writes to the original evidence. However, the scenario states that the forensic image has already been created. The question asks about maintaining admissibility after imaging, so the focus shifts to documenting custody and integrity, not the initial acquisition process.

Encrypting the forensic image with a strong algorithm and storing the key in a secure vault

Why it fails: Encryption protects the confidentiality of the forensic image but does not by itself establish admissibility. If the chain of custody is not documented, the court cannot verify that the image is the same one collected and that it has not been altered. Encryption is a good practice for storage, but it is secondary to proving integrity and custody through documentation.

Increasing password complexity

Why it fails: Password complexity only hardens the credential secret; a stolen or leaked service account credential still authenticates successfully, so impersonation persists. Complexity is tempting because it strengthens human logins, and would be correct for user accounts lacking rotation or length requirements.

VLAN isolation

Why it fails: VLAN isolation segments network paths, but an adversary holding valid service account credentials can still authenticate from any permitted segment. VLANs are tempting because they limit lateral movement, and would be correct when containing a compromised host rather than preventing credential impersonation.

Firewall rules

Why it fails: Firewall rules filter network traffic by IP and port; they cannot verify a service account's identity, so impersonation via stolen credentials still succeeds. Firewalls are tempting because they segment traffic, and would be correct when restricting which hosts may reach a service.

Exploiting an internal web server

Why it fails: T1133 requires an externally reachable remote service, such as a VPN concentrator or exposed RDP gateway, used with valid accounts. An internal web server is not externally facing, so exploiting it maps to T1190 (exploit public-facing application), not external remote services.

Phishing a user

Why it fails: T1133 covers adversary use of legitimate external remote services such as VPNs, RDP or Citrix to enter a network, typically with valid credentials. Phishing is T1566, a separate initial-access technique; it is tempting because both are initial access, but the mechanism differs.

Using a USB drive

Why it fails: T1133 covers interactive access through external services such as VPNs, RDP and SSH, so a USB drive describes physical media rather than a remotely exposed service. It tempts because USB delivery is a genuine initial-access vector, but that maps to T1091 Replication Through Removable Media, not external remote services.

AWS Config

Why it fails: AWS Config records resource configuration states and changes over time, not the API calls made by an IAM role. It is tempting because it offers historical timelines, but that history covers resource attributes; CloudTrail is the service logging the identity, time and parameters of each API request.

AWS Trusted Advisor

Why it fails: Trusted Advisor inspects account configuration against best-practise checks for cost, security and limits; it holds no per-call API history. It is tempting because it surfaces security findings, but CloudTrail is the service that records API activity, which is what the anomalous role investigation requires.

AWS X-Ray

Why it fails: X-Ray traces request paths through distributed applications for latency and error diagnosis, not IAM identity activity. It is tempting because it captures request-level detail, but those traces follow application transactions rather than recording which principal invoked which AWS API, which CloudTrail provides.

Wireshark to analyze the encrypted traffic.

Why it fails: Wireshark captures packets, but TLS handshake records are encrypted, so it cannot reveal chain validation errors such as an untrusted or expired intermediate. It is tempting because it inspects handshake alerts, and would be correct for diagnosing plaintext protocol negotiation issues.

'certutil -verify -urlfetch' on the Linux server.

Why it fails: certutil is a Windows-only utility; it does not exist on Linux, so the command cannot run there. It is tempting because certutil -verify -urlfetch genuinely validates certificate chains and revocation via AIA and CRL fetching, and would be correct on a Windows server.

Nmap with the '--script ssl-enum-ciphers' flag.

Why it fails: ssl-enum-ciphers enumerates supported protocols and cipher suites; it does not retrieve or validate the certificate chain, issuer trust, or revocation status. It is tempting because it diagnoses TLS handshake failures, and would be correct if the failure stemmed from a cipher or protocol mismatch.

Successful MFA challenge

Why it fails: A successful MFA challenge indicates fresh interactive authentication, which token replay bypasses entirely. It is tempting because MFA success looks reassuring, but it is the correct indicator when verifying that a legitimate user completed authentication, not when detecting a replayed token.

Location change

Why it fails: A location change alone is weak evidence, since token replay often originates from the same geography as the victim. It is tempting because impossible-travel alerts flag stolen credentials, but Pass-the-Token is confirmed by a sign-in with no preceding authentication event.

Successful password-based sign-in

Why it fails: Pass-the-Token reuses a stolen token, so no password is submitted and no password-based sign-in appears. It is tempting because password sign-ins are logged routinely, but that detail is the right choice when investigating credential-stuffing or brute-force attacks rather than token replay.

Change all company Wi-Fi passwords

Why it fails: Rotating Wi-Fi passwords does not address the compromised PII, its storage, or the affected accounts, and disrupts the whole company. It is tempting because credential rotation is a standard containment step, and it would be correct if the incident involved a breached network or wireless credential.

Post a message on the company intranet

Why it fails: An intranet post broadcasts the incident to all staff, widening exposure of the PII rather than containing it. It is tempting because internal communications are routine during incidents, and an intranet notice would be appropriate for a general service outage carrying no personal data.

Delete all user databases

Why it fails: Deleting user databases destroys the evidence and business records an investigation needs, and does not contain the exposure. It tempts as an apparent way to purge sensitive data, but PII incident response requires preserving logs, scoping affected records and notifying according to policy.

The KQL query lacks a 'summarize' operator

Why it fails: 'summarize' aggregates rows for counting or thresholding but is not required for a rule to fire; a query returning any matching row still generates alerts. It is used when building threshold logic, such as counting failed sign-ins per account.

Log Analytics workspace ingestion limit reached

Why it fails: Ingestion limits halt data arrival, which would also stop analytics rules firing, but they are a workspace-level quota issue, not an 'Incident Settings' configuration. Incident Settings control whether a triggered alert creates an incident, so the correct cause lies in those creation or grouping rules.

The analytics rule is set to 'Disabled' instead of 'Enabled'

Why it fails: The stem states the rule is enabled, so disabling it contradicts the given scenario. The Enabled toggle is the correct fix when a rule has been intentionally paused and no alerts should fire at all.

Check the file metadata (MACE)

Why it fails: MACE timestamps give the file's modification, access, creation and entry times, narrowing when the web shell appeared but not who or which request uploaded it. Metadata is tempting because it is quick to read, yet identifying the source requires correlating web server access logs with that timestamp.

Scan the server for viruses

Why it fails: Antivirus scanning matches known malware signatures on disk; it cannot reconstruct which request or user wrote a web shell. It is tempting as routine host hygiene, yet identifying the upload source demands correlating web server access and POST request logs with the file's creation time.

Check system boot logs

Why it fails: Boot logs record operating system startup events, not HTTP requests, so they cannot reveal which upload wrote a web shell. They are tempting because logs are the natural investigative artefact, but the correct source is the web server's access and error logs capturing the POST that created the file.

Delete the registry key.

Why it fails: Deleting the registry key destroys the evidence needed to determine whether the entry is malicious and how it persists. It is tempting as immediate remediation to stop the program launching, but that is containment, not investigation; the examiner must first capture and analyse the value, its binary and associated timestamps.

Reboot the server.

Why it fails: Rebooting the server destroys volatile evidence such as running processes, network connections and memory-resident malware, and may trigger the persistence entry itself. It is tempting as a quick way to observe whether the entry executes, but forensic examination demands static analysis of the registry value and referenced binary before any restart.

Rename the file to .txt.

Why it fails: Renaming a file to .txt changes nothing about its content or behaviour, so it cannot reveal whether the Run entry is malicious. It is tempting as a safe way to inspect suspicious code, but proper analysis requires examining the binary, hash or signature rather than altering the artefact and destroying evidential integrity.

All three vulnerabilities should be remediated simultaneously with equal priority, because any vulnerability could be exploited.

Why it fails: Treating all vulnerabilities equally ignores risk-based prioritization, which is essential for efficient use of resources. Some vulnerabilities pose greater immediate threats due to exposure and exploitability. The analyst should prioritize based on the actual risk to the organization, not on a blanket approach.

The critical RCE vulnerability, because it has a known exploit and critical severity rating, regardless of network accessibility.

Why it fails: While the RCE is critical, it is on an internal administrative interface not accessible from the internet. The lack of external exposure significantly reduces the immediate risk. Prioritizing solely based on severity ignores the context of exploitability and reachability, which are key factors in risk-based vulnerability management.

The low-severity information disclosure, because it could reveal sensitive information about the server that aids further attacks.

Why it fails: Information disclosure is typically low risk and often does not directly lead to compromise. While it could assist an attacker, it is not as urgent as a publicly exploitable XSS that can directly steal credentials. Risk prioritization should focus on vulnerabilities that can be readily exploited to cause significant harm.

/bin/sh

Why it fails: /bin/sh is the Bourne shell interpreter binary, not a login-time script; attackers may replace it, but that is binary tampering, not a per-login persistence hook. It is tempting because shells execute commands, yet the question asks for a file sourced on every user login, such as /etc/profile or ~/.bashrc.

/var/log/syslog

Why it fails: /var/log/syslog is a log file written by the system logging daemon; nothing sources or executes it at login. It is tempting because attackers tamper with logs to hide traces, but that is anti-forensics, not persistence. Login-time execution belongs in profile or shell rc files.

/etc/passwd

Why it fails: /etc/passwd stores user account records — usernames, UIDs, home directories and shell paths — and is not executed at login. It is tempting because attackers do modify it, but only to add rogue accounts or change shells, which is account creation rather than code execution on each login.

Red Team creates policy, Blue Team audits it

Why it fails: Red and Blue Teams both operate within an agreed scope; neither owns policy creation or audit. Policy authorship and compliance auditing belong to governance functions, so this split misdescribes the adversarial-versus-defensive axis that actually separates the teams during a simulation.

Red Team handles infrastructure, Blue Team handles software

Why it fails: Both teams span infrastructure and software; the split is adversarial offence versus defensive monitoring and response, not layer ownership. Infrastructure and software responsibilities are divided by role, not team colour, so this mapping fails to capture the offence-defence distinction the question asks about.

Red Team identifies vulnerabilities, Blue Team remediates them

Why it fails: Remediation is a shared outcome, not the defining axis: Blue Teams detect and respond, while Red Teams emulate adversaries, and vulnerability identification is one activity within offence. Framing the difference as identify-versus-remediate misstates both teams' remits and the adversarial premise of a simulation.

The server is offline.

Why it fails: An offline server produces a connectivity or name-resolution failure, not a calculated 'Effective Access' of Deny, which is derived from share and NTFS permission entries. Server availability is tempting because unreachable hosts do block access, yet the Effective Access tab requires the server to be reachable to compute permissions at all.

The drive is full.

Why it fails: A full drive causes write failures, not an access-control decision; 'Effective Access' reports the resultant permissions calculated from share and NTFS ACLs, so a Deny result means an explicit or inherited deny entry applies. Disk capacity is tempting because storage exhaustion does block writes, but it never yields a Deny in the access calculation.

They are not in the correct group.

Why it fails: Group membership determines which allow entries apply; absence from a required group yields no grant, which the calculation reports as implicit denial through lack of permission rather than an explicit Deny entry. Missing membership is tempting because groups commonly grant share access, but the stem's Deny points to an explicit deny ACE.

windows.info

Why it fails: windows.info reports dump metadata such as the operating system build and capture time; it enumerates no process memory, so injected code regions cannot be surfaced. It is tempting because it is the standard first plugin run to confirm profile and symbol compatibility, and would be correct when validating a dump before deeper analysis.

windows.netscan

Why it fails: windows.netscan enumerates network endpoints and owning processes, revealing connections but not the memory regions or protection flags that indicate injected code. It is tempting because injected malware often beacons outbound, and netscan would be correct when correlating suspicious external connections to a process.

windows.pstree

Why it fails: windows.pstree displays parent-child process relationships, exposing anomalies such as unexpected parents, but it does not inspect memory for injected code. It is tempting because process-tree oddities frequently accompany injection, and pstree would be correct when establishing how a suspicious process was spawned.

Changing the administrator's wallpaper to the company logo.

Why it fails: Endpoint hardening concerns the web service's configuration, patches, exposed ports and file permissions. Wallpaper branding is cosmetic desktop personalisation with no security effect on the service. It tempts candidates because corporate imaging standards are sometimes grouped under hardening checklists, yet visual customisation alters no attack surface.

Configuring the server to auto-restart every 10 minutes.

Why it fails: Endpoint hardening reduces attack surface through patching, disabling unused services, least-privilege permissions and secure configuration. Scheduled auto-restarts merely mask instability and interrupt service without closing any vulnerability. It tempts administrators because restarting clears memory-resident threats temporarily, but that is incident response, not hardening.

Replacing the server's RAM with larger capacity sticks.

Why it fails: Endpoint hardening addresses software configuration, patch levels, service exposure and access controls on the web service. Adding RAM changes hardware capacity, leaving vulnerabilities, default credentials and unnecessary modules untouched. It tempts candidates because performance tuning is often bundled with server maintenance, yet memory upgrades deliver no security control.

Identify top talkers by total bandwidth consumption

Why it fails: Top-talkers by bandwidth ranks hosts by total volume, which beaconing's small periodic connections never accumulate, so the pattern stays hidden. It is tempting for capacity and anomaly triage, but detecting beaconing requires time-based analysis such as connection interval frequency or periodicity scoring across flows.

Filter connections by source port entropy

Why it fails: Source port entropy measures randomness in port selection, which beaconing does not alter; a beacon reuses a fixed destination port and regular timing. Entropy analysis suits detecting port-scan or DGA patterns. The scenario needs periodicity detection, such as inter-arrival time variance or Fourier analysis of connection intervals.

Calculate the mean of bytes transferred per session

Why it fails: Mean bytes per session averages payload volume, which stays roughly constant during beaconing and therefore reveals nothing about timing. It would suit detecting data exfiltration or throughput anomalies. The scenario requires periodicity, so inter-arrival time analysis or autocorrelation of connection timestamps is needed instead.

Change the service account to a local 'Guest' account.

Why it fails: Changing to Guest will likely break the service functionality and is not a security hardening technique.

Enable 'Service Isolation' in the Registry using the 'ServiceSidType' key.

Why it fails: While this is a security feature, it does not address the DLL hijacking vulnerability directly.

Rename the service executable to a random string.

Why it fails: Security through obscurity does not prevent DLL hijacking.

Background checks

Why it fails: Background checks are an administrative control, screening personnel before employment rather than restricting access through system configuration. It is tempting because vetting reduces insider threat, and it would be correct when classifying administrative controls such as onboarding screening, training and separation-of-duties policies.

Security policy documentation

Why it fails: Policy documentation is an administrative control, governing behaviour through written rules rather than enforcing restrictions in code or configuration. It is tempting because policies underpin every security programme, and it would be correct when classifying administrative controls such as standards, procedures and guidelines.

Guard patrol

Why it fails: Guard patrol is a physical control, relying on human presence and deterrence rather than automated enforcement within systems. It is tempting because patrols directly prevent intrusion, and it would be correct when classifying physical controls such as fences, locks, lighting and security personnel.

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.