Hard Difficulty Questions

The parser is disabled.

Why it fails: A disabled parser stops events being normalised into fields, so the correlation rule's conditions never match the raw data. Parser configuration is the correct focus when events arrive but their fields are missing or malformed, not when filters are already verified.

The user interface is loading slowly.

Why it fails: Slow interface rendering affects only the console display and does not prevent the correlation engine from evaluating events server-side. Interface performance is the right concern when dashboards lag or time out, not when a rule fails to fire.

The license has expired.

Why it fails: An expired licence halts ingestion or rule evaluation entirely, producing silence across all rules rather than one rule failing while others run. Licence renewal is the correct action when the manager refuses to start or stops processing altogether.

Application log, Event ID 1000

Why it fails: Event ID 1000 in the Application log is typically generated by Windows Error Reporting when an application crashes. It contains faulting application information but not command-line arguments for normal process executions. PowerShell executions that do not crash will not generate this event, and even if they did, the command line is not included. Thus, it cannot provide the needed details.

System log, Event ID 7045

Why it fails: Event ID 7045 in the System log indicates a new service was installed. It does not record process command lines for general processes like PowerShell. While attackers may use services for persistence, the scenario specifically asks for the command line of a PowerShell execution, not service installation. Therefore, this event would not contain the required information and is irrelevant to the investigation.

Windows PowerShell log, Event ID 4104

Why it fails: Event ID 4104 in the Windows PowerShell log records script block logging, which captures the content of scripts executed. While it can show PowerShell code, it does not necessarily record the full command line as passed to powershell.exe, especially for one-liners or encoded commands. The command line is better captured by process creation events. Therefore, this event is not the primary source for the exact command line used to invoke PowerShell.

Wireshark

Why it fails: Wireshark captures and dissects packets passively; it cannot forge or transmit a DNS reply to the malware. It is tempting because it displays DNS queries, but answering them requires an active spoofer such as dnsspoof, which sends crafted responses redirecting resolution to the analysis host.

Netcat

Why it fails: Netcat relays TCP or UDP payloads but does not parse DNS queries or craft valid response packets, so the resolver rejects its output. It is tempting as a general network swiss-army knife, yet simulating a DNS server needs a tool that understands the DNS message format and answers queries.

Nmap

Why it fails: Nmap performs port scanning and host discovery, not DNS response forgery, so it cannot answer the malware's query. It is tempting because it resolves names and probes services, but redirecting traffic requires an active DNS spoofer that returns a crafted A record pointing at the local analysis machine.

Disk forensic analysis of the user's browser history

Why it fails: Browser history records URLs visited, holding no PowerShell command text or script-block content at all. It tempts because disk forensics preserves artefacts an attacker cannot easily erase remotely, and would be the right source if the hypothesis concerned web-based drive-by compromise or phishing-site visits preceding execution.

Windows Security Log - Process Creation (Event ID 4688)

Why it fails: Event ID 4688 records process creation, capturing only the executable name and parent, not the PowerShell script block content or command arguments. It tempts because process creation auditing is the standard starting point for endpoint hunting, and would be correct if the hypothesis concerned which binaries executed rather than the commands themselves.

Network firewall traffic logs for port 5985

Why it fails: Firewall logs on port 5985 capture connection metadata for PowerShell Remoting, not the commands transmitted within the session. It tempts because WinRM traffic is a genuine lateral-movement indicator, and would be correct if the hypothesis concerned remote PowerShell connections between hosts rather than the commands executed on one.

The analyst's mood

Why it fails: An analyst's mood is subjective and unrelated to incident impact, so it cannot inform severity, which derives from business impact, data or system criticality, and scope of compromise. It is tempting because analyst judgement matters in triage, and would be correct when assessing confidence in an alert rather than its severity.

The day of the week

Why it fails: Incident severity derives from technical impact, scope and data sensitivity, not calendar position; a Sunday breach is no less severe than a Tuesday one. It is tempting because staffing and on-call coverage genuinely vary by day, so rota planning may reference the weekday, but that affects response logistics rather than the severity rating itself.

In the user permission settings.

Why it fails: User permission settings govern who may view or edit alerts, not when they fire; time-based triggering belongs in the correlation rule or alert schedule. Restricting access is tempting because permissions do control alert visibility, but they cannot restrict execution to business hours.

In the log ingestion configuration.

Why it fails: Alert scheduling belongs in the correlation rule or alert definition, where time-of-day conditions are evaluated against event timestamps. Log ingestion configuration governs parsing, normalisation and source onboarding, so a time filter there would silently discard events outside business hours, leaving no data for later forensic queries.

In the dashboard settings.

Why it fails: Dashboard settings control visualisation layout, refresh intervals and widget arrangement, not alert evaluation schedules. Alert triggering windows are defined in the correlation rule or alert condition itself, where time-based filters are applied. Dashboards would be the right place to restrict a view's displayed data to business hours, but that changes nothing about when the alert fires.

A user-mode process with a single thread that is currently in a wait state

Why it fails: A single waiting thread is entirely normal for many idle or background processes and carries no injection significance. Wait states occur constantly during normal scheduling. Without evidence of anomalous memory permissions or orphaned thread start addresses, this observation does not indicate that malicious code was injected.

A signed Microsoft DLL loaded at its expected base address

Why it fails: A legitimately signed system DLL loaded at its expected location is normal behavior and provides no evidence of injection. Attackers may target such modules for hollowing, but the mere presence of a correctly loaded signed DLL is expected on every Windows host and therefore is not an indicator by itself.

A process with a high handle count and many open Registry keys

Why it fails: High handle counts and numerous open Registry keys can reflect normal application behavior, such as services or browsers, and are not specific to code injection. While unusual handle patterns may warrant a look, they do not directly demonstrate that foreign code was written into a process, so they are weak and non-specific for this purpose.

Fast flux by rapidly changing the domain's A records across many IP addresses

Why it fails: Fast flux involves frequent changes to DNS records, often with short TTLs and multiple IPs, to keep malicious infrastructure alive. Here the domain resolves to a single CDN IP that also hosts legitimate services, which is more consistent with domain fronting than with fast flux.

DNS tunneling by encoding command-and-control data in DNS query names

Why it fails: DNS tunneling would show unusually long or high-entropy DNS queries and high query volume to a single domain, often with TXT records. The scenario describes periodic resolution of a new domain to a CDN IP, not data exfiltration via DNS payloads, so DNS tunneling is not the best fit.

Use of a domain generation algorithm (DGA) to create many pseudorandom domains

Why it fails: A DGA would generate numerous algorithmically created domains, often with high entropy, and the infected host would attempt to resolve many of them. The scenario describes one newly registered domain resolving to a CDN IP, which does not match the pattern of DGA-based communication.

A service account being added to the Domain Admins group.

Why it fails: Adding a service account to Domain Admins is a privilege escalation technique, but it is not part of Kerberoasting. Kerberoasting aims to crack service account passwords offline; it does not require group membership changes. Alerting on this would detect a different attack and fail to identify Kerberoasting activity, leading to missed detections.

Event ID 4771 for Kerberos pre-authentication failures from a single source.

Why it fails: Event ID 4771 indicates failed Kerberos pre-authentication, often associated with password spraying or brute-force attempts. Kerberoasting does not cause pre-authentication failures; it succeeds after valid authentication. Therefore, this event is not relevant to detecting Kerberoasting and would misdirect the analyst toward credential-guessing attacks instead.

Event ID 4624 logon type 3 (network) from a workstation to a domain controller.

Why it fails: Network logons to domain controllers are common in normal operations, such as file shares and authentication. While unusual sources might warrant investigation, this event alone is not specific to Kerberoasting. The attack occurs after authentication, during ticket requests, so focusing on logon events would generate excessive false positives and miss the core behavior.

Event ID 4656 (A handle to an object was requested)

Why it fails: Event ID 4656 is generated when a handle to an object is requested, such as a file or registry key. While credential dumping may involve accessing the LSASS process, 4656 is not the primary event for detecting such access. It requires additional auditing settings and is not as directly indicative as other events specifically tied to LSASS access.

Event ID 4663 (An attempt was made to access an object)

Why it fails: Event ID 4663 records attempts to access objects and can be useful if object access auditing is enabled for the LSASS process. However, it is not the most direct indicator of credential dumping. It may generate a high volume of events and requires careful configuration to be effective, making it less prioritized than events specifically designed to detect suspicious LSASS access.

Event ID 4624 (An account was successfully logged on)

Why it fails: Event ID 4624 logs successful logon events and is useful for tracking access, but it does not directly indicate credential dumping. Mimikatz and similar tools may generate logon events, but these are common and not specific to credential theft. Focusing solely on 4624 would produce many false positives and miss the actual dumping activity.

System memory dumps

Why it fails: Memory dumps capture volatile running state for malware and credential analysis, not the durable configuration that survives reboot, so they do not evidence persistence mechanisms. They are tempting because injected code can reside in memory, and would be correct when hunting fileless malware active in a live session.

Event log files

Why it fails: Event logs record activity such as logons and service installs, but persistence is established by durable artefacts like Run keys, scheduled tasks and services, which logs merely reference. They are tempting because they reveal attacker behaviour, and would be correct for building a timeline of actions rather than identifying persistence.

Masquerading via renamed binary, confirmed by comparing the file's hash against a known-good baseline

Why it fails: Masquerading involves a malicious file using a trusted name, but here the binary is genuinely signed and in its expected location. The signature being valid argues against masquerading. Hashing would not reveal the persistence mechanism, which is the child process writing to a startup location, so this focus is misplaced.

Scheduled task creation, confirmed by inspecting the Task Scheduler operational log for task registration events

Why it fails: Scheduled task persistence would register a task and show Event ID 106 in the Task Scheduler log. The scenario describes a file written to the Startup folder, which is a different persistence mechanism. Reviewing task registration would not explain the observed Startup folder artifact and would miss the actual technique.

Process injection, confirmed by examining the parent process's memory for unbacked executable regions

Why it fails: Process injection typically manifests as threads created in remote processes or anomalous memory regions within an existing process. Here the evidence is a child process writing a file, not injected code in a live process. Looking for unbacked memory would not confirm a file-drop persistence action and misdirects the investigation.

Exploitation

Why it fails: Exploitation is the moment a vulnerability is triggered to gain code execution, typically visible as exploit artifacts, crash behavior, or unusual child processes on the victim. The steady beaconing described happens after code execution is already established, so it does not represent the exploitation step itself.

Weaponization

Why it fails: Weaponization occurs on the attacker's side when an exploit and payload are paired into a deliverable, such as a malicious document or installer. It produces no network traffic from the victim host, so the observed beaconing cannot belong to this phase even though the payload being controlled may have been weaponized earlier.

Actions on Objectives

Why it fails: Actions on Objectives covers the attacker achieving intended goals such as data theft, encryption, or destruction, which would show distinct artifacts like large outbound transfers or mass file modification. Periodic small beacons indicate the channel is being maintained, not that objectives are being executed, so this phase is premature.

Parse the PE section table and compare the raw size against the virtual size of each section

Why it fails: Raw-size versus virtual-size discrepancies are an indicator of packing or an uninitialized region, and they might suggest the import table was rebuilt at runtime. However, this structural comparison only flags that something is unusual; it does not recover the resolved API names, so it leaves the analyst's actual question unanswered.

Extract printable ASCII and Unicode strings from the binary and filter for known Windows API names

Why it fails: If the malware resolves APIs by hash rather than by name, the strings will not contain the API names at all, so string extraction yields nothing useful. Even when plaintext names exist, strings do not show which functions are resolved, in what order, or with which arguments, making this approach unreliable for confirming dynamic resolution behavior.

Compute the file's MD5 and SHA-256 hashes and submit them to a public multi-engine scanning service

Why it fails: Hash submission identifies family labels and existing detections, but it reveals nothing about the internal resolution logic that produced the sparse import table. It is a useful triage step for reputation and clustering, yet it cannot enumerate the API names the sample resolves at runtime, so it fails to answer the analyst's specific question about dynamically loaded functions.

Run a full antivirus scan on the server to detect other malware files.

Why it fails: A full antivirus scan may detect other known malware, but it can miss modified or zero-day threats. The specific file in question may be a legitimate tool with added malicious code that antivirus might not catch. Antivirus relies on signatures and heuristics, which can be evaded. Memory analysis is more reliable for active infections because it examines runtime behavior.

Check the file's digital signature to verify if it is valid and trusted.

Why it fails: Checking the digital signature can reveal if the file was tampered with, but if the malware author re-signed it or removed the signature, it may not be conclusive. A valid signature might still be present if the attacker stole a certificate. Additionally, the absence of a signature does not confirm maliciousness. Memory analysis is a more direct method to confirm infection.

Submit the file to a multi-engine antivirus scanner like VirusTotal to see if other engines detect it as malicious.

Why it fails: Submitting the file to VirusTotal can provide additional detection, but it is not definitive. Some engines may flag it as a false positive, and the malware author may have modified the file to evade detection. VirusTotal results can be inconclusive. The analyst needs to examine the file's behavior or code to confirm malicious modifications, not rely solely on external scanners.

Event ID 4688 in the Security log

Why it fails: Event ID 4688 logs process creation, including the process name and command line. While it can show that a suspicious process like mimikatz.exe was executed, it does not directly indicate memory access to lsass.exe. Credential dumping often involves opening a handle to lsass with specific access rights, which is captured by a different event. Thus, 4688 alone is insufficient for detecting the memory access behavior.

Event ID 4656 in the Security log

Why it fails: Event ID 4656 is generated when a handle to an object is requested. It can include access to lsass.exe if object access auditing is enabled, but it is not specific to credential dumping and can be noisy. It requires additional configuration and filtering to be useful. The more direct event for detecting lsass memory access is 4663, which logs the actual access attempt.

Event ID 10 in the Sysmon log

Why it fails: Sysmon Event ID 10 logs process access events, including the source process and target process, and the granted access. It is indeed a valuable source for detecting lsass access, but the question specifies Windows event logs, and Sysmon is an optional additional logging tool. The native Windows Security log event for object access is 4663. If Sysmon is not deployed, 4663 is the correct answer.

Windows Security event logs showing successful logons from the user account

Why it fails: Security event logs record authentication events but do not show data transfer activities. While they can confirm that the account was used, they do not reveal the exfiltration channel or destination. In an exfiltration investigation, authentication logs are supporting evidence but not the primary source for identifying how data left the network.

NetFlow data showing large outbound transfers to a known cloud storage IP

Why it fails: NetFlow provides metadata about connections, such as IPs, ports, and byte counts, but it does not reveal application-layer content or the specific domain. Large outbound transfers to a known cloud storage IP could be legitimate business activity. While NetFlow can indicate volume, it lacks the context to definitively identify the exfiltration channel or the destination domain, making it less useful than proxy or DNS logs.

Antivirus logs showing a quarantined file on the user's workstation

Why it fails: Antivirus logs indicate malware detection but do not provide details about exfiltration channels or destinations. A quarantined file might be unrelated to the exfiltration or could be a secondary payload. These logs are useful for understanding the infection but do not directly help identify where data was sent or how it was exfiltrated.

Registry key creation in RunOnce

Why it fails: This indicates persistence, not lateral movement.

Prefetch file modification

Why it fails: Prefetch tracks application execution, not authentication methods.

DNS query logs

Why it fails: These track network resolution, not authentication tokens.

Set the log.level to error

Why it fails: This only affects logging output, not processing capacity.

Disable the Elasticsearch output plugin

Why it fails: Disabling output prevents log archival.

Change the time_zone parameter

Why it fails: Timezone affects metadata, not throughput.

Change the alert severity level in the 'Incident Review' dashboard settings.

Why it fails: Severity changes do not affect the underlying data fields of the event.

Edit the correlation search definition to pipe the results into the 'inputlookup' command for user data.

Why it fails: inputlookup reads data, it does not enrich the event stream dynamically.

Modify the 'Notable Event Aggregation Policy' to force a refresh of the user metadata.

Why it fails: Aggregation policies group events; they do not perform data enrichment.