CCNA Perform Threat Hunting Questions

Windows Security Events, collected via Windows Event Forwarding (WEF), are the authoritative source for on-premises failed-logon hunting because domain controllers log Event ID 4625 for every failed NTLM/Kerberos logon attempt. WEF uses HTTP/HTTPS (WinRM) and a collector-initiated subscription, preserving the full payload: source IP address, workstation name, logon type, and authentication package. This enables centralized correlation across all DCs in the domain and direct ingestion into a SIEM such as Sentinel.

Joining SigninLogs and AuditLogs on user principal name, constrained to a short time window, correlates an anomalous sign-in with a subsequent password reset. This temporal correlation across both tables surfaces the credential-theft sequence, which neither log alone reveals.

The DNS (Preview) via AMA connector ingests DNS query events from devices, which is the only telemetry that records domain resolution. Enabling it satisfies the requirement to trigger when any device resolves the C2 domain, since network connectors alone would not capture resolution.

DeviceProcessEvents is the correct table because it captures process creation events on endpoints, and its ProcessCommandLine column stores the exact command line used to launch each process. This includes the PowerShell executable path, individual arguments, flags like -EncodedCommand or -ExecutionPolicy Bypass, and any obfuscated script text. The table also provides process ID, parent process, and initiating process command line, which are crucial for gaining full context on the suspicious PowerShell invocation during a threat hunt.

Advanced Hunting is the Microsoft 365 Defender tool purpose-built for proactively querying across deep time series and event tables via KQL, including DeviceProcessEvents, DeviceEvents, and associated network/file events. With schema-aware queries such as process parent-child joins, an analyst can pivot from a suspicious PowerShell process to its parent chain, command-line, file hashes, and related lateral-movement indicators. This makes it the correct surface for ad-hoc threat hunting and validating a specific suspicious process observed in the environment.

DeviceNetworkEvents, ingested via Microsoft Defender for Endpoint, records inbound and outbound connection attempts with initiating process and remote IP. This connection-level telemetry exposes the internal host-to-host traffic patterns that characterise lateral movement, satisfying the stem's threat-hunting requirement.

This query precisely identifies NTLM network logons by combining EventID 4624, LogonType 3, and LogonProcessName containing 'NTLM', which is the signature of pass-the-hash authentication. The `TargetUserName !endswith '$'` filter removes machine accounts, and the `Computer !in (list of domain controllers)` exclusion eliminates the large volume of legitimate DC-to-DC NTLM activity, leaving only suspicious user logons from non-DC hosts. By projecting TimeGenerated, Account, SourceWorkstation, and LogonProcessName, it retains the forensic context needed for incident investigation, making it the correct detection for PtH lateral movement.

The activity log records every user action and sign-in event with source IP, location and timestamp, letting analysts correlate the impossible-travel sign-ins and trace subsequent suspicious activity. It directly satisfies the requirement to investigate an account authenticating from multiple geographic regions within a short window.

DeviceNetworkEvents with RemotePort 3389 and ActionType 'ConnectionSuccess' captures successful RDP sessions, and summarising dcount(RemoteIP) by DeviceName surfaces devices connecting to many distinct internal addresses — exactly the fan-out pattern the stem's lateral movement hunt requires.

DeviceProcessEvents stores process creation telemetry, including the full command line and arguments for each executed process, so querying it reveals the exact PowerShell parameters used. Network connection tables record destination IPs but not the command-line arguments that launched the script.

DeviceEvents records endpoint telemetry from Defender for Endpoint, and its ActionType field captures ScheduledTaskCreated when a new scheduled task is registered. Filtering on that value surfaces persistence activity directly, which is exactly what the hunting scenario requires.

DNS logs, whether collected from internal DNS servers or via Azure DNS Analytics, are a top-tier C2 data source because malware frequently uses DNS to resolve the domain name of its command-and-control server. Every query name, client IP, and timestamp is captured, allowing defenders to correlate against threat intelligence feeds for known malicious domains or detect domain-generation-algorithm (DGA) patterns. This visibility into the resolution process is essential because C2 often leverages a legitimate-looking domain rather than a hard-coded IP address.

DeviceNetworkEvents records outbound connections with remote IP, port and initiating process, exposing transfers to unfamiliar destinations or large uploads. That network-layer visibility is what reveals exfiltration traffic leaving endpoints, complementing cloud-side logging rather than duplicating it.

Matching known IOCs — file hashes, domains, IP addresses — against telemetry quickly flags artefacts already tied to confirmed campaigns. It is a core hunting technique because it converts threat intelligence into concrete queries across Defender XDR tables, surfacing compromised hosts without waiting for alerts.

Process access events, recorded as Event 4656, capture when one process opens a handle to another with specific access rights. LSASS credential dumping appears here because tools request read access to lsass.exe memory, matching the hunting requirement.

This is correct because PsExec creates a named pipe called 'psexesvc' on the target host when it executes. Event ID 5145 (A network share object was checked to see whether client can be granted desired access) with ShareName IPC$ and RelativeTargetName containing psexesvc is a reliable indicator of PsExec lateral movement. Hunting this named pipe artifact avoids dependence on the process name, which attackers can rename.

This query is correctly hunting for a known LOLBin technique where an attacker uses rundll32.exe to execute JavaScript code by placing 'javascript:' in the command line. When PowerShell (or another process) launches rundll32 with that argument, it triggers the JScript engine to evaluate the supplied script, allowing arbitrary code execution while masquerading as a legitimate Windows binary. This pattern is documented in MITRE ATT&CK as Signed Binary Proxy Execution (T1218.011), and the combination of the parent-child process relationship and the 'javascript:' string makes it a strong hunting indicator.

Unified analytics rules in Microsoft Sentinel correlate alerts from multiple sources, including Microsoft Defender for Cloud Apps and Microsoft Defender for Endpoint, and group them into a single incident. This satisfies the requirement to unify cross-product alerts for hunting rather than viewing them separately.

The Hunting blade in Microsoft Sentinel provides a centralized interface containing built-in hunting queries mapped to MITRE ATT&CK techniques, allowing analysts to run predefined KQL searches and pivot on suspicious results. Livestream is a complementary feature that creates an ongoing KQL query session over live ingested data, presenting real-time results that update as logs flow in, with optional alerts on each result. This combination is a valid hunting approach because it directly supports proactive, iterative, and continuous investigation of workspace data.

Isolate device — Immediately disconnects the device from the network via Microsoft Defender for Endpoint's containment action, severing all inbound and outbound traffic while keeping the device powered on for forensic preservation. This is the correct first response to a process making outbound connections because it stops active data exfiltration and lateral movement without rebooting or losing volatile evidence, and it can be applied selectively if needed.

`summarize count() by SourceIp, DestinationIp` aggregates events into per-source and per-destination groups, satisfying the stem's requirement to count outbound connections to a known bad IP. Grouping by DestinationIp lets you filter or threshold on that specific address, while the 5-minute window is applied by the scheduled query rule's frequency and lookback settings.

Filtering OfficeActivity for Operation=='FileDownloaded' and summarising with bin(TimeGenerated, 1h) aggregates download counts per user per hour, satisfying the short-window requirement. Joining against a historical baseline table then surfaces deviations from each user's normal behaviour, which is precisely the anomaly detection the stem demands for SharePoint exfiltration hunting.

The script likely used a query such as DeviceProcessEvents | where ProcessCommandLine contains 'javascript:' combined with a filter for rundll32.exe as the process name. In most environments, rundll32.exe executing a JavaScript URI (e.g., JScript or VBScript) is an uncommon attack pattern that rarely occurs, so the query returned an empty table even though the syntax and endpoint are correct. The absence of matching records, not an API error or schema mistake, explains why no data was returned.

Querying DeviceNetworkEvents for inbound connections on TCP port 3389 is effective because this is the default port for Remote Desktop Protocol (RDP). Inbound RDP connections from unusual sources or to high-value hosts can indicate an attacker establishing a foothold or performing lateral movement. To refine the hunt, you would look for new or unexpected source IPs, repeated connection attempts, and combine these network observations with authentication logs.

EmailAttachmentInfo is the correct table because it is specifically designed to store metadata about files attached to emails, including the file name, file size, and crucially the SHA256 hash. In a threat hunt for data exfiltration, this hash lets you pivot to threat intelligence sources or correlate with command-and-control activities. This table is the only one among the options that directly provides a hash value to verify if a file was malicious or sensitive.

To detect beaconing, you need to calculate the time difference between consecutive connections from the same host. The serialize operator orders the rows, and prev() accesses the previous row's timestamp. datetime_diff() then computes the interval. By analyzing these intervals for regularity (e.g., low standard deviation), you can identify beaconing. This approach is flexible and works with irregular intervals, making it the most appropriate for this scenario.

Azure Network Watcher flow logs are the correct source for this hunt because they record IP traffic through network security groups, capturing source/destination IPs, ports, protocols, and whether traffic was allowed or denied. These logs enable security analysts to identify anomalous outbound connections, such as a VM communicating with a known command-and-control (C2) IP on a non-standard port, by analyzing traffic patterns and byte/package counts. However, note that flow logs are aggregate and do not capture packet payloads, so they are best merged with other signals (e.g., threat intelligence) to confirm malicious intent.

If the externaldata URL cannot be reached from the workspace, the query returns no rows because the external source yields nothing to join or filter. Connectivity to that URL is the prerequisite the query depends on.