Threat Hunting And Detection practice questions

System Event ID 7045

Why it fails: 7045 is for service installation.

Security Event ID 1102

Why it fails: 1102 tracks audit log clearance.

Security Event ID 4624

Why it fails: 4624 shows logins but does not distinguish RDP session details specifically enough for lateral movement hunting.

Event ID 1

Why it fails: Event ID 1 tracks process creation, which is too broad for hollowing.

Event ID 11

Why it fails: Event ID 11 tracks file creation.

Event ID 3

Why it fails: Event ID 3 tracks network connection activity.

File extension

Why it fails: The extension must match for the loading to occur.

Creation timestamp

Why it fails: Timestamps are easily modified via timestomping.

File size

Why it fails: File size can be spoofed.

HTTP User-Agent strings

Why it fails: User-agents can be easily spoofed to look like browsers.

DNS lookup failure counts

Why it fails: This indicates service issues, not beaconing.

Source IP addresses

Why it fails: Source IPs are too numerous to be a primary filter.

Domain controller name

Why it fails: This is a standard field.

Client IP address

Why it fails: IPs are not embedded in standard tickets.

Ticket encryption algorithm

Why it fails: Algorithms are standard.

ARP Spoofing

Why it fails: Used for interception/man-in-the-middle.

DNS Tunneling

Why it fails: Usually associated with C2/Exfiltration.

Traffic volume spikes

Why it fails: Spikes are usually associated with exfiltration, not heartbeat C2.

TCP Window size changes

Why it fails: TCP parameters fluctuate based on congestion, not C2 intent.

Event ID 4625 (An account failed to log on)

Why it fails: Event ID 4625 logs failed logon attempts. Pass-the-hash attacks usually succeed because the hash is valid, so they do not generate failed logon events. A high number of 4625 events might indicate brute force or password spraying, not pass-the-hash. While failed logons could occur if the hash is invalid, they are not a primary indicator of a successful pass-the-hash attack.

Event ID 4768 (A Kerberos authentication ticket was requested)

Why it fails: Event ID 4768 indicates a Kerberos TGT request. Pass-the-hash attacks abuse NTLM authentication, not Kerberos. While attackers might use pass-the-ticket with Kerberos, pass-the-hash specifically involves NTLM hashes. Therefore, Kerberos ticket events are not directly indicative of pass-the-hash. They would be relevant for detecting pass-the-ticket or Kerberoasting, but not for this scenario.

Event ID 4624 with Logon Type 10 (RemoteInteractive)

Why it fails: Logon Type 10 indicates a Remote Desktop session. While pass-the-hash can be used to authenticate via RDP, it is less common because RDP typically requires interactive logon and may trigger other defenses. Pass-the-hash is more often used for lateral movement via SMB or WMI, which use network logons. Therefore, Logon Type 10 is not as indicative of pass-the-hash as Logon Type 3.

Sysmon Event ID 7, ImageLoad, filtered for modules loaded by the Task Scheduler service.

Why it fails: Image load events record dynamic library loads into processes and are used for detecting DLL injection or side-loading. They do not record writes to task definition files, so they cannot show when a scheduled task was created or modified. This event is valuable for other hunts but does not address the persistence installation question here.

Sysmon Event ID 1, ProcessCreate, filtered for schtasks.exe with the /create argument.

Why it fails: Process creation telemetry only captures tasks created through the schtasks.exe command-line utility. Malware frequently creates scheduled tasks via the Task Scheduler COM interfaces or .NET APIs, which do not spawn schtasks.exe, so relying on this event alone would miss the persistence mechanism the hunter is trying to detect.

Sysmon Event ID 3, NetworkConnect, filtered for outbound connections from the Task Scheduler service.

Why it fails: Network connection events describe outbound communication, not task creation or modification. They might reveal an implant's C2 channel after execution, but they do not answer when the persistence mechanism was installed. Using this event to find task creation would conflate execution and installation, missing the moment the hunter needs.

Access to csrss.exe

Why it fails: Mimikatz targets lsass.exe, which holds credential material; csrss.exe access does not indicate credential dumping. Csrss.exe is tempting because it is a frequent target for process injection and token manipulation, and would be the correct focus when investigating session or injection-based attacks.

Access to svchost.exe

Why it fails: svchost.exe hosts many legitimate services, so access to it is routine and not specific to Mimikatz credential theft. It is tempting because Mimikatz often targets LSASS, and svchost is a familiar system process, but the correct indicator is lsass.exe memory access.

Access to explorer.exe

Why it fails: Mimikatz reads LSASS memory, not explorer.exe, so this pattern does not indicate credential dumping. Explorer.exe access is tempting because it is a common user-mode target for injection, and would be relevant when hunting for shellcode injection or process hollowing rather than credential theft.

Low volume of DNS failures

Why it fails: Few DNS failures is normal baseline behaviour and indicates nothing about tunnelling. Tunnelling tooling often resolves successfully, so failure counts stay low; this data point would matter when hunting misconfigured resolvers or NXDOMAIN floods instead.

High volume of A record queries

Why it fails: High A record query volume is normal web browsing traffic, so it lacks specificity. Tunnelling is indicated by anomalous query length, entropy, or TXT record abuse; A record volume would be relevant when detecting DDoS amplification or malware domain generation algorithms.

Frequent SRV record updates

Why it fails: SRV records locate services such as SIP or LDAP, so frequent updates indicate service re-registration, not tunnelling. Tunnelling exfiltrates data through repeated queries for the same record type, typically TXT or A, with unusually long or encoded subdomains.

The connection is encrypted with an expired certificate

Why it fails: JA3S hashes the server's TLS ServerHello fields — version, cipher suite and extensions — and carries no certificate validity data, so an expired certificate cannot produce a distinctive JA3S. Certificate expiry is detected by inspecting the presented certificate chain, not the handshake fingerprint.

The client has been compromised

Why it fails: JA3S fingerprints the server's ServerHello, so it identifies the C2 listener, not which clients are compromised; a unique JA3S seen across many hosts indicates shared malicious infrastructure. Client compromise is established through host-based evidence such as process trees, injected memory or beacon configuration.

It is a standard browser connection

Why it fails: A standard browser's JA3S would match the common server fingerprints already present across the environment, not appear unique. JA3S fingerprints the server side of the handshake; browser identification relies on the client-side JA3 hash, which is why JA3 is used for user-agent profiling.

root\default

Why it fails: root\default hosts miscellaneous provider classes and default namespace definitions, not WMI event subscription artefacts. It is tempting as a generic starting point for enumeration, but no permanent event filter, consumer or binding objects are registered there. Persistence subscriptions reside in root\subscription, which the hunter must inspect.

root\security

Why it fails: root\security holds security-related audit and policy classes, not the event filter, consumer and binding objects used for persistence. It is tempting because the name suggests threat hunting, but subscription artefacts live in root\subscription. Analysts should enumerate __EventFilter, __EventConsumer and __FilterToConsumerBinding there.

root\cimv2

Why it fails: root\cimv2 holds the standard Windows management classes used for querying system state, not the permanent event subscription objects that survive reboot. It is tempting because most WMI queries target it, but persistence artefacts are registered in root\subscription. Hunters should enumerate filters, consumers and bindings there.

System Event ID 7040

Why it fails: Event ID 7040 records service start-type changes in the System log, holding no PowerShell content. It is tempting because System logs do capture service and driver activity, and it would be the right source when investigating a Windows service whose startup configuration was altered rather than script execution.

Application Event ID 1000

Why it fails: Application Event ID 1000 records application crashes and faulting module details, not PowerShell script content. It is tempting because Application logs do capture PowerShell host errors, and it would be the right source when diagnosing why a script or host process terminated unexpectedly rather than what the script contained.

Security Event ID 4688

Why it fails: Event ID 4688 logs process creation with the command line, which for -EncodedCommand shows only the encoded blob, not the decoded script block. It is tempting because 4688 is the standard process-creation audit event, and it would be correct if you needed to confirm that powershell.exe ran with that flag.

Sum aggregation on connection counts

Why it fails: Summing connection counts yields total volume per bucket, which cannot expose regular inter-arrival timing; a steady beacon and a burst can produce identical totals. Sum aggregation suits traffic-volume baselining. Detecting periodicity requires date histogram aggregations over timestamps, or statistics on inter-connection intervals.

Min/Max aggregation on bytes

Why it fails: Min and Max on bytes return the smallest and largest transfer sizes per bucket, describing payload volume rather than when connections occurred. Such aggregations suit spotting exfiltration size anomalies. Revealing beacon periodicity requires date histogram aggregation over timestamps, or statistics on inter-connection intervals.

Cardinality count on source IPs

Why it fails: Cardinality counts distinct source IPs per bucket, measuring source diversity rather than the timing of repeated connections from one host. It suits mapping which hosts contact a service. Periodicity detection needs date histogram aggregation on timestamps, or interval statistics, to expose regular beacon spacing.

Get-Service

Why it fails: Get-Service queries Windows service control manager entries, which are separate from Task Scheduler's task store, so it cannot enumerate registered tasks or their actions. It would be correct for auditing persistently running services, not for the scheduled task hunting described in the scenario.

Get-Process

Why it fails: Get-Process enumerates running processes and their resource usage, exposing nothing about registered task definitions or their triggers. It would be the right cmdlet for identifying suspicious running binaries, but scheduled task auditing requires Get-ScheduledTask with CIM sessions targeting remote hosts.

Get-WmiObject Win32_StartupCommand

Why it fails: Win32_StartupCommand returns programs configured to launch at logon via Run keys and startup folders, not Task Scheduler registrations. It would be correct for auditing autostart persistence, but the stem asks specifically about scheduled tasks, which require Get-ScheduledTask.

Incident response forensics

Why it fails: Incident response forensics reconstructs events after a detected compromise, working from artefacts to determine what happened. Threat hunting instead begins with a known adversary tactic and searches logs for its evidence. Forensics would be the right choice when investigating an alert that has already fired.

Machine learning-based hunting

Why it fails: Machine learning-based hunting detects anomalies statistically without starting from a predefined adversary tactic, so it cannot work backward from a known technique. It is tempting because ML surfaces unknown threats, but it would be correct when the goal is baselining normal behaviour and flagging deviations rather than hypothesis-driven tactic tracing.

Alert-driven hunting

Why it fails: Alert-driven hunting begins with a triggered detection or alert, not with a known adversary tactic, so the investigative direction is reversed. It is tempting because alerts often reference attacker behaviour, but alert-driven hunting would be correct when triaging or escalating existing detections rather than proactively hypothesising about a specific technique.

Extracting browser passwords

Why it fails: certutil is a certificate management tool; its -urlcache and -decode switches fetch or decode remote payloads, so it is abused for downloading and staging malware, not reading credential stores. It is tempting because it is a signed Microsoft binary, and it would be correct if the artefact were a browser credential database being parsed.

Clearing event logs

Why it fails: certutil cannot clear the Windows event log; that is done with wevtutil cl or PowerShell Clear-EventLog, so its abuse centres on downloading and decoding files. It is tempting because clearing logs is a common anti-forensics step, and it would be correct if the observed binary were wevtutil rather than certutil.

Modifying system registry keys

Why it fails: certutil.exe manages certificate services and can download or decode files, not edit registry hives; reg.exe, regedit or PowerShell handle registry modification. It tempts because LotL abuse of certutil for payload retrieval and Base64 decoding is well documented, making any certutil activity look suspicious.

Resource Monitor

Why it fails: Resource Monitor shows per-process CPU, memory, disk and network counters, not parent-child lineage, so it cannot reveal which process spawned another. It suits live performance troubleshooting on a single host, whereas threat hunting needs Sysmon or EDR process-tree data.

PowerShell ISE

Why it fails: PowerShell ISE is a scripting editor and console; it executes commands but does not record or display process ancestry. It is the correct choice for authoring and testing PowerShell scripts, not for visualising which parent process launched a suspicious child.

Wireshark

Why it fails: Wireshark decodes network packets, not process ancestry, so it cannot show which executable spawned another. It is the right tool for inspecting traffic, such as C2 beaconing or exfiltration, but process-tree visualisation requires Sysmon or similar endpoint telemetry.

Event ID 4771

Why it fails: Event ID 4771 records failed Kerberos pre-authentication, which indicates brute-force or password-guessing, not AS-REP Roasting. It is tempting because it is Kerberos-related; it would be correct when investigating failed logon attempts against accounts with pre-authentication enabled.

Event ID 4624

Why it fails: 4624 records a successful logon, not the pre-authentication failure that AS-REP Roasting depends on; the relevant indicator is 4768 with encryption type 0x17. It is tempting because 4624 is the standard logon-audit event, and it would be the right choice when investigating interactive or network logon activity.

Event ID 4769

Why it fails: Event ID 4769 records Kerberos service ticket requests, which occur after authentication, whereas AS-REP Roasting abuses accounts without pre-authentication during the initial AS exchange. It is tempting because it is Kerberos-related; it would be correct when investigating service ticket activity such as Kerberoasting.