CCNA Perform threat hunting Questions

Summarising CloudAppEvents by AccountDisplayName within one-hour bins and filtering where dcount(CountryCode) exceeds one directly surfaces impossible-travel patterns, satisfying the requirement to detect users accessing cloud apps from multiple geographies in a short window. The CloudAppEvents table supplies the CountryCode and TimeGenerated fields this aggregation depends on.

CloudAppEvents holds Microsoft Defender for Cloud Apps activity records, including SharePoint access and the IP category field. Filtering on the site URL and AnonymousProxy identifies every user who reached that site from anonymous IPs, which Sentinel's sign-in tables cannot surface.

dcount(Account) counts distinct account values per grouping, so summarising by IP with a threshold above 10 flags the same source failing against many accounts within the five-minute window. It satisfies the distinct-account counting requirement precisely.

DeviceProcessEvents captures process creation events, which directly indicate malware execution.

In Microsoft Defender for Cloud Apps, the activity log is the authoritative source for operational events, and filtering for the activity type 'Install app' directly surfaces when an OAuth app was introduced to the tenant. After identifying these installation events, the App governance dashboard provides a unified inventory of all app instances, including permissions, publisher, and usage, enabling the hunter to scope the outbreak. This sequence—find the installation event, then pivot to the governance inventory—matches the intended workflow for OAuth app threat hunting.

Reviewing PowerShell script block logging could provide additional context, but it is not the most direct way to investigate an encoded command. Decoding the '-enc' argument first yields the actual command.

The query correlates DeviceProcessEvents with DeviceNetworkEvents, joining on DeviceId and a time window to link cmd.exe spawning PowerShell with subsequent outbound HTTPS traffic. This satisfies the hunting objective of surfacing suspicious process-to-network chains, where a command shell launching PowerShell and beaconing externally indicates potential malicious activity.

Using known IOCs such as malicious file hashes, suspicious domains, attacker IPs, and email sender addresses from threat intelligence feeds is effective because it gives the hunt concrete, evidence-backed starting points from both external intelligence and internal incident knowledge. In Microsoft Defender XDR, a hunter can run KQL queries over Advanced Hunting tables (DeviceFileEvents, DeviceNetworkEvents, EmailEvents, etc.) to cross-reference these IOCs and pivot to related processes, users, and machines. This method works best when the hunter expands beyond simple hash matches to hunt for subtle variations that preserve the attacker's underlying tradecraft.

SecurityEvent captures Windows security auditing events, including modifications to security settings and attempts to disable controls such as Defender or audit policies. It is the appropriate table for hunting activity that weakens protective mechanisms across monitored machines.

CommonSecurityLog is the Sentinel table that ingests normalized network traffic logs from firewalls and other security appliances using the Common Event Format (CEF). It records fields like source and destination IP addresses, ports, protocols, and the action taken (allow/deny), making it the go-to table for analyzing inter-host IP communication. For a hunt focused on direct network connections between two systems, this is the appropriate data source.

Starting from a detection rule is a valid method because the rule's underlying KQL query exposes the same log data used for detection and can be run interactively in the Logs or Hunting blade to explore broader patterns. For example, you can right-click a rule, select 'Run query' to see its results, then refine the query to look for related activity. This pivot from a deterministic detection to a broader investigation is a recognized hunting entry point in Microsoft Sentinel.

A thorough understanding of the advanced hunting schema—including table names, column structure, and relationships—is essential for writing accurate and efficient KQL queries. Hunters must know, for example, that DeviceProcessEvents contains process creation data while IdentityLogonEvents holds authentication logs, and how to join these tables to trace lateral movement. Without this schema knowledge, analysts risk querying irrelevant tables, misinterpreting data, or missing critical evidence hidden in less obvious tables.

Placing a `where` clause before `bag_unpack` reduces the number of rows entering the expansion, which is the most direct way to cut the CPU and memory cost of unpacking. Filtering on a non-computed column (or an indexed field) lets the engine prune data early, so `bag_unpack` operates on a minimal logical set and the query's overall runtime drops substantially.

DeviceProcessEvents captures process creation telemetry from Defender for Endpoint, so filtering FileName for certutil.exe and ProcessCommandLine for the -urlcache or -split switches isolates exactly the LOLBin download behaviour the hunter hypothesised, within the required seven-day window.

Filtering on InitiatingProcessIntegrityLevel "Low" and ProcessIntegrityLevel "High" isolates genuine low-to-high integrity transitions, the exact escalation pattern sought. Summarising count() by DeviceName then top 10 by count_ ranks the noisiest endpoints over the ago(7d) window, matching both the frequency and timeframe constraints.

Threat hunting is hypothesis-driven: analysts form a theory about adversary behaviour, then encode it as a custom query to surface matching activity. This satisfies the recommended practise of proactive, hypothesis-led hunting rather than relying solely on existing scheduled detections.

Excluding known administrative jump boxes suppresses alerts from trusted sources performing legitimate RDP, while the rule's pass-the-hash logic still fires on anomalous authentication patterns elsewhere. This targets the false-positive source named in the stem without weakening detection coverage.

Detecting DNS tunnelling is crucial for identifying C2 communication because attackers frequently encapsulate malicious traffic within legitimate DNS queries and responses. Microsoft Sentinel can analyse DNS logs, looking for anomalous patterns such as excessively long domain names, unusual query frequencies, or specific data encoding within DNS records. This technique effectively uncovers covert C2 channels, satisfying the requirement to identify command and control communication.

Event ID 4769 logs Kerberos service ticket (TGS) requests, and encryption type 0x17 (RC4-HMAC) reveals weak cipher use typical of Kerberoasting, where attackers request SPN tickets then crack them offline. Filtering both fields surfaces exactly the SPN queries the stem requires.

Filtering out known-benign sources — corporate VPN egress addresses and common applications like Outlook Web Access — removes expected single logons, leaving anomalous ones. This directly targets the false-positive constraint by narrowing results to genuinely suspicious single-use accounts.

Process injection writes malicious code into a trusted process's address space, so activity inherits that process's legitimacy and evades allow-listing and behavioural controls. Threat hunters detect it via anomalous memory allocation, thread creation or unexpected module loads.

NTLM authentication originating from a machine the user does not normally use is a strong lateral movement indicator because NTLM uses a password hash in a challenge-response protocol, and attackers often employ pass-the-hash techniques to authenticate from a compromised host. In a Windows environment, this would appear as Event ID 4624 with LogonType 3 and NTLM as the authentication package, combined with a source hostname or IP that violates the user's typical logon pattern. This aligns with stolen credentials or hash theft, as a legitimate user would almost always authenticate from their known workstations or VPN exit points, so an unexpected source machine is statistically suspicious.

The workspace() function is a KQL table-scoping function that accepts a workspace name or resource ID and returns a table reference for that workspace, allowing cross-workspace queries in a single KQL statement. In Microsoft Sentinel, analysts commonly use workspace() with the union operator to combine security tables from multiple workspaces, for example: union workspace("sentinel-ws1").SecurityEvent, workspace("sentinel-ws2").SecurityEvent. This is the correct feature because it is purpose-built to reference other Log Analytics workspaces from within your query.

This is the correct approach because the summarize operator groups all events by SourceIP and calculates TotalBytes as the sum of SentBytes for each group, converting row-level byte counts into a single aggregate metric per unique IP address. The subsequent top 10 by TotalBytes desc operator then sorts those aggregated results in descending order and returns only the first ten rows, which are the ten source IPs with the highest total outbound byte volume. Using 'top' after 'summarize' is also more efficient than 'sort' followed by 'take' because Kusto can discard non-top records during execution. This pipeline precisely satisfies the goal of identifying the top source IPs by total bytes sent and is the only option that combines both grouping and aggregation with a limiting operation.

Event ID 4662 with the DS-Replication-Get-Changes access mask directly satisfies the stem's replication-permission indicator: DCSync abuses directory replication rights to harvest credential hashes. Monitoring this in Microsoft Sentinel detects non-domain-controller accounts requesting replication, the defining anomaly of DCSync activity.

Activity anomaly detection policies in Microsoft Defender for Cloud Apps baseline each user's typical file download volume and alert when behaviour deviates sharply. A mass SharePoint Online download to a personal device exceeds that learned baseline, matching the exfiltration scenario precisely.

A scheduled task that invokes PowerShell to establish an outbound connection to an external IP on port 4444 is a textbook reverse shell persistence mechanism. The attacker creates the scheduled task to execute at logon or on a recurring interval, ensuring reliable command-and-control access even after system reboots. PowerShell is frequently abused for this purpose because it enables 'living off the land' fileless attacks, often using System.Net.Sockets.TcpClient to send shell output without writing scripts to disk. Port 4444 is also a common default listener for Metasploit, and the non-admin context suggests the attacker is operating with limited privileges, possibly after phishing or lateral movement, maintaining access while working to elevate privileges.

When a KQL query uses `externaldata` to load a CSV file and then performs a `join` against that data, the join depends entirely on the availability and format of the external file. If the URL is malformed (e.g., missing scheme, incorrect path, invalid SAS token) or the endpoint is inaccessible (e.g., network restrictions, expired token, or file deleted), `externaldata` returns an empty table. The subsequent `join` then finds no matching rows, silently producing an empty result set, which matches the symptom described in the question.

A leftanti join returns rows from the left table that have no match in the right table. By joining failed sign-in records against the historical successful sign-in IP set, you get exactly the source IPs with failures but no prior success, which is the novel-IP condition the hunt requires.

DeviceNetworkEvents in Microsoft Defender XDR (ingested into Microsoft Sentinel via the Defender XDR connector) provides detailed network connection events from endpoints, including remote IP addresses. Querying this table for the malicious IP will identify all devices that connected to it, directly fulfilling the hunting requirement.

DeviceEvents records scheduled task creation and related process activity, including the task's action and initiating command line. Querying it surfaces matching PowerShell-from-temp-directory tasks across enrolled devices, letting you determine whether the suspicious task exists elsewhere in the estate.

Analytics rules in Microsoft Sentinel include a MITRE ATT&CK mapping section where each rule's tactics and techniques are configured. When the rule fires, generated incidents and alerts inherit those technique tags automatically, satisfying the requirement to categorise detected behaviours without manual enrichment.

DeviceNetworkEvents is the Advanced Hunting table that stores network connection activity initiated by processes, including source and destination IP addresses, remote ports, protocols, and connection metadata. A threat hunter can query this table with a known-bad IP or domain to list every device that established such communication. This makes it the direct and authoritative source for identifying compromised or suspicious endpoints.

Unexpected remote desktop connections from non-administrative workstations are a strong lateral movement indicator because attackers frequently use RDP to hop to other systems once they compromise an endpoint. By searching for RDP sessions initiated from a standard user's workstation, a defender can spot activity that does not match the user's baseline behavior, especially when the destination is a server or privileged host. This technique corresponds to MITRE ATT&CK T1021.001, since legitimate users rarely initiate such connections from non-admin workstations.

Grouping connections into a sliding window and counting distinct connection times per IP and device surfaces periodic low-and-slow beaconing that single-event thresholds miss, while the distinct-count aggregation suppresses noisy repeated hits from the same host, cutting false positives.

A Watchlist stores the external IP indicators as a reference table, letting a KQL query join them against DeviceNetworkEvents to surface devices contacting those addresses. This satisfies the requirement to hunt proactively across Defender for Endpoint telemetry without waiting for an alert.

Event 4624 with LogonType 3 and authentication package NTLM indicates a network logon using NTLM, which is exactly what a pass-the-hash attack performs. The logon process NtLmSsp and the authentication package NTLM in the event are key indicators; LogonType 3 signifies remote access to a resource. While normal network shares also create such events, filtering for unusual source workstations or privileged accounts can reveal pass-the-hash activity. This is the most direct Windows Security log source for detecting NTLM-based lateral movement.

Mimikatz reads credential material directly from LSASS memory, so a process requesting PROCESS_VM_READ against lsass.exe is the strongest signal. Legitimate tools rarely open LSASS with memory-read rights, making this access mask the specific indicator Microsoft Defender for Endpoint surfaces for credential-dumping detection.

Microsoft Threat Intelligence feed is natively integrated with Microsoft Sentinel, providing curated indicators of compromise from Microsoft's global telemetry. It satisfies the stem's ingestion requirement without custom connectors, unlike external feeds needing API configuration. This built-in source enriches threat hunting queries directly.

Device isolation severs network connectivity while preserving the endpoint for investigation, immediately halting the malicious PowerShell script's payload execution and preventing lateral movement across the affected workstations. This directly contains the active threat identified during the hunt.

DeviceNetworkEvents lacks a RemoteIPType column, so referencing it makes the query fail silently or return nothing. The schema exposes RemoteIP, RemoteUrl and RemotePort instead; filtering public addresses requires an ipv4_is_private() or similar check on RemoteIP. This schema mismatch, not the SMB filter, explains the empty result set.

Analytics Rules (also called scheduled or incident creation rules) are the correct mechanism in Microsoft Sentinel for correlating alerts from multiple security products into a unified incident. These rules are built on Kusto Query Language (KQL) and can use entity mapping and alert grouping to combine multiple separate alerts—whether from Microsoft Defender, Azure, or third-party connectors—into one incident based on common entities and a defined time window. When a query returns results and incident creation is enabled, Sentinel creates an incident enriched with the matching alerts, which is exactly what a threat hunter needs for correlation.

Correlating successful logon events from the same IP against those accounts reveals whether the failed attempts culminated in compromise, distinguishing brute-force success from mere noise. This directly satisfies the stem's goal of determining whether the activity constitutes an actual brute-force attack rather than isolated failures.

A hypothesis grounded in threat intelligence or recent incidents directs hunting toward plausible adversary behaviour rather than unfocused querying. This satisfies the stem's best-practise criterion by making hunting purposeful and evidence-driven within Microsoft Defender XDR.

Signature-based matching only catches known tools, so behavioural analysis is needed. Correlating process lineage and call stacks exposes anomalous LSASS access by novel variants, satisfying the requirement to detect previously unknown credential dumping tools rather than relying on known indicators.

DeviceNetworkEvents records inbound and outbound network connections with remote IP addresses, ports and initiating processes, so querying it reveals a compromised workstation connecting to other internal devices — exactly the lateral movement indicator the hunt requires.

The correct initial action in a threat hunt is to pivot from the observed indicator—the anonymizer IP—to the associated entities, specifically the impacted user accounts and endpoints, and examine authentication logs, behavioral anomalies, and device telemetry for evidence of unauthorized access or lateral movement. Microsoft Defender XDR provides integrated signals such as IdentityLogonEvents, DeviceNetworkEvents, and alerts that enable this scoping, aligning with the MITRE ATT&CK technique of discovering the full attack surface. Only after determining whether accounts are compromised and what systems are affected can you make informed decisions on containment and remediation.

Phishing with malicious macro is correct because the suspicious chain—Microsoft Word spawning PowerShell with an encoded command line—is a classic indicator of a macro-enabled Office document used as an initial access vector. Attackers embed VBA macros that invoke PowerShell via a WMI CreateProcess or direct CreateProcess call, often using -EncodedCommand or -EncodedArguments to hide the payload from command-line logging and initial inspection. This aligns with MITRE ATT&CK techniques T1566.001 (Spearphishing Attachment) and T1204.002 (User Execution: Malicious File), where the macro acts as the execution trigger and PowerShell serves as the download cradle or in-memory loader.

A KQL query targeting uncommon process chains, such as wscript.exe spawned from Microsoft Office, directly identifies suspicious child-process relationships that align with known script-based attack sequences (macro execution, DDE abuse). By focusing on the parent-child correlation rather than broad attributes, the query maintains a low false-positive rate because it only surfaces events matching a specific, behaviorally suspicious pattern, not every process creation.

SigninLogs in Microsoft Sentinel records Microsoft Entra ID sign-in events with IP-derived location and timestamp data. Querying it lets you correlate two authentications from geographically distant locations within an implausible interval, directly testing the impossible travel hypothesis.

This is correct. The query first aggregates failed logon events by account and IP, then performs an inner join with successful logon events on the same account/IP pair. The inner join ensures that any matched row has at least one successful logon from that IP, while the aggregate count shows a high number of failures. Together these filters reveal accounts that suffered many failed logon attempts and ultimately had a successful logon from the same source IP—a classic indicator of a successful brute-force attack.

The in operator tests whether a value exists in a dynamic list or watchlist, so source IPs can be matched directly against the malicious IP set. It satisfies the requirement to compare network connection sources with watchlist entries over the past seven days.

startofday(TimeGenerated) truncates each timestamp to the beginning of its calendar day, so grouping by this expression counts events per day. For a host that beacons once daily, the daily event count will remain consistently near one per day, making the periodic pattern easy to spot with a simple summarize query. This directly aligns with the hypothesis of a daily beacon and is the most appropriate choice among the options for detecting periodicity in typical C2 traffic.

Kerberoasting requests RC4-encrypted service tickets, so hunting for service account logon events showing RC4 (0x17) encryption type exposes the attack, since legitimate modern service authentication typically negotiates AES. This satisfies the stem's detection requirement by targeting the encryption downgrade inherent to extracting crackable ticket hashes.

Joining on DeviceId and constraining the network timestamp to fall shortly after the process timestamp links the suspicious execution to the outbound connection on the same host. This preserves the causal sequence the hunt hypothesis depends on and avoids correlating unrelated activity.

IdentityDirectoryEvents is the correct table because it contains audit records of directory service state changes, including user account creation, deletion, password resets, and group membership updates. When a user account appears in Active Directory or Azure AD, the corresponding ActionType and target object details are logged here. This makes it the definitive source for hunting accounts that have been newly added or modified by an attacker.

The Hunting blade in Microsoft Sentinel provides a KQL query environment tailored for proactive threat hunting. KQL includes built-in string functions, and base64_decode_tostring() specifically converts a Base64-encoded input to its plain-text string representation, which is ideal for decoding obfuscated PowerShell commands that attackers often encode using Base64. Running a KQL query against the relevant table (e.g., DeviceProcessEvents) with this function reveals the actual command executed, enabling further analysis. This is the correct approach because it directly transforms the encoded data into readable content.

Baselining normal network behaviour lets hunters spot anomalies such as beaconing, unusual lateral movement or data staging in Defender XDR telemetry. Without knowing what routine traffic looks like, distinguishing genuine malicious activity from benign administrative patterns is impossible, so this underpins every hypothesis.

SecurityEvent is a primary data source for lateral movement because it ingests Windows security audit events from event log channels such as Security and Sysmon. Events like 4624 (successful logon, especially type 3 network logons), 4688 (process creation), and 4648 (explicit logon credentials) let analysts spot pass-the-hash, remote logon, and service creation by attackers. These host-level audit trails provide the ground truth needed to reconstruct a kill chain as an adversary moves between machines.

Custom hunting queries operationalise a hypothesis by searching ingested log data for indicators that automated analytics have not flagged, satisfying the proactive, hypothesis-driven requirement of threat hunting in Microsoft Sentinel. Unlike scheduled analytics rules, which trigger alerts reactively, hunting queries are run on demand and their results can be promoted into detections.

Ransomware actors frequently register malicious binaries as Windows services to survive reboots and gain SYSTEM-level execution. Querying service installation events in advanced hunting exposes this persistence technique, satisfying the hunt's requirement to uncover stealthy ransomware footholds beyond initial encryption activity.

DeviceFileEvents records file creation, renaming and modification, exposing the mass rename and encryption patterns ransomware produces. DeviceProcessEvents supplies the spawning processes behind that activity, giving hunters early endpoint-level indicators rather than relying on network or email telemetry.

Bookmarking preserves specific result rows, together with their entities and timestamps, so they can be revisited, tagged and investigated later. This satisfies the valid hunting action of retaining evidence from query output rather than losing it when the results grid is refreshed.

DNS tunneling commonly encodes data in the subdomain portion of a query name, so attackers craft unusually long subdomains (often 50+ characters) and generate a high query volume to a single authoritative domain. By analyzing DNS query logs for these patterns—such as label length, entropy, and query frequency per domain—you can directly detect the covert channel. This technique is effective because DNS traffic is frequently allowed through firewalls without deep inspection, making the logs the primary evidence of the exfiltration.

Livestream streams events in real time as they are ingested, letting hunters watch activity unfold without waiting for scheduled analytics rules to fire. This satisfies the scenario's requirement for a hunting feature, since interactive, near-instant event visibility directly supports proactive investigation rather than automated detection alone.

The Hunting blade provides built-in, pre-built queries that run directly against your Log Analytics workspace, letting analysts pivot on entities and surface suspicious activity without authoring KQL from scratch. This satisfies the stem's requirement for a valid threat-hunting method in Microsoft Sentinel, complementing custom query development.

summarize groups rows by chosen keys and computes aggregates such as count or make_set, letting you collapse many similar PowerShell command lines into per-host or per-command patterns. That aggregation exposes commands recurring across workstations, which raw row-by-row output obscures.

AuditLogs records Microsoft Entra ID directory activity, including role membership and role definition changes, so it directly satisfies the requirement to hunt privileged account abuse through directory role modifications. SigninLogs covers authentication events instead, not administrative role changes.

Searching for known indicators of compromise lets hunters match observed artefacts — file hashes, IP addresses, domains — against threat intelligence. This reactive technique rapidly confirms whether known malicious infrastructure or payloads are present in the environment, satisfying one recognised threat hunting methodology.

Allowlisting known administrative tools removes legitimate remote-management activity from the result set, cutting false positives without narrowing the query's scope. Detection coverage for genuine lateral movement persists, since only trusted binaries are excluded rather than whole event categories.

The Investigation graph is Microsoft Sentinel's entity-centric exploration tool, modeling relationships between IPs, hosts, accounts, and alerts as a visual map. From a suspicious IP entity you can double-click or expand to immediately surface all connected alerts, related incidents, and adjacent entities, making it the correct pivot path for threat hunting. It leverages the entity schema and graph data to show both direct and indirect connections.

Event ID 4688 records process creation with command-line auditing enabled, capturing Mimikatz execution and its suspicious arguments. This contrasts with 4624 logons or 4672 privilege assignment, which show access but not the credential-dumping tool itself.

OAuth app granting permissions directly records consent events, capturing the scopes granted to each application. This satisfies the hunter's requirement to identify suspicious OAuth permissions, as the activity log exposes the specific delegated or application permissions assigned, enabling detection of illicit access or over-privileged third-party apps.

The IP address is the shared entity linking every suspicious sign-in, letting you pivot to enumerate all related authentication events, affected accounts and associated alerts. Pivoting on the IP exposes the full scope of the threat actor's activity.

Querying SecurityAlert for alert names containing 'Golden Ticket' or 'Suspicious Kerberos' is correct because Microsoft Defender for Identity, which is integrated into Microsoft 365 Defender and surfaces alerts in the SecurityAlert table, provides high-fidelity detections specifically for forged TGT activity. MDI signals such as anomalous ticket granting service requests, unusual TGT size, or encryption downgrade attacks are aggregated here, making it the direct, authoritative source for identifying golden ticket usage without needing to reconstruct indicators from raw logs.