Identity Threat Detection And Response practice questions

dataset = endpoint_security_identity

Why it fails: This dataset name is not a standard Cortex XQL schema.

dataset = pan_wmi_raw

Why it fails: pan_wmi_raw is not the standard dataset for parsed domain controller logs.

dataset = xdr_data | filter event_simple_name = "Win-Security-Kerberos-Service-Ticket"

Why it fails: Event simple names vary, but the correct dataset for normalized AD logs is typically agent_log or specific parsed identity datasets.

Use the 'extract_identity()' parser modifier

Why it fails: Parsing modifiers extract fields; they do not perform baseline anomaly calculations.

Use the 'wildfire_scan()' function on the authentication stream

Why it fails: wildfire_scan is used for static and dynamic analysis of files, not log strings.

Use the 'isolate_endpoint()' action command inside the search bar

Why it fails: isolate_endpoint is a remediation action, not an XQL analytical function.

Browser pop-up blocker activation logs

Why it fails: Browser pop-up logs are client-side browsing events.

Local printer driver installation alerts

Why it fails: Printer driver installations are unrelated to DCSync.

DHCP Scope Exhaustion Warning logs

Why it fails: DHCP scope warnings indicate IP address depletion, not AD replication abuse.

Printing logs to paper and scanning them via OCR

Why it fails: Paper scanning is not a supported log collection method.

Connecting a USB flash drive directly to the Cortex XDR cloud tenant

Why it fails: Cloud tenants do not accept physical USB flash drives for log ingestion.

Sending logs via consumer email attachments to support@paloaltonetworks.com

Why it fails: Email is not a supported automated log ingestion mechanism.

SELECT * FROM active_directory WHERE password = plaintext

Why it fails: Cortex XDR uses XQL, not standard SQL syntax.

RUN playbook name = "isolate"

Why it fails: This is not an XQL query search command structure.

SEARCH logs WHERE identity == true AND action == format

Why it fails: This is an invalid query syntax for Cortex XDR XQL.

The Device Management inventory tab

Why it fails: Device Management tracks agent installations and device statuses, not identity behavior.

The Correlation Rules editor

Why it fails: Correlation Rules are used to create detection logic, not to review user-specific activity timelines.

The Host Details page under Endpoint Protection

Why it fails: Host Details focus on endpoint-specific telemetry, not user identity timelines.

Local endpoint Anti-Malware scanning engines

Why it fails: Anti-malware engines scan files for signatures and malicious code, not cloud sign-in behavior.

WildFire Static Analysis engine

Why it fails: WildFire is strictly for file analysis.

Cortex XDR Port Scan detector BIOCs

Why it fails: BIOCs target network reconnaissance and port scanning behavior on endpoints.

BIOC rule creation for impossible travel

Why it fails: Creating a BIOC rule is a detection-engineering task, not an investigation step for an existing alert. Writing a new rule does not help the analyst determine whether this specific pair of logins represents credential compromise, so it is the wrong first action here.

Threat Intelligence lookup on the source IP addresses

Why it fails: Threat intelligence can show whether an IP is known-bad, but it does not correlate the two authentication events to the same user session or reveal endpoint process context. For this scenario it is a supporting enrichment step, not the primary correlation capability the analyst should use first.

Endpoint Isolation for the source host

Why it fails: Isolation is a response action that cuts network connectivity for an endpoint; it does not help determine whether the two logins are related or malicious. Applying it before confirming compromise could disrupt a legitimate user and would not provide the correlation context the analyst needs in this identity investigation.

The workstation's endpoint risk score, because a high-risk endpoint in Cortex XDR automatically proves the service account credentials were dumped from LSASS memory.

Why it fails: An endpoint risk score aggregates many behaviors and does not prove credential dumping. Cortex XDR identity analytics correlates identity signals, not endpoint risk alone. Even a high-risk endpoint score could stem from malware unrelated to this service account, so it cannot confirm LSASS credential theft or the specific lateral-movement path observed.

The password age of 14 months, because Cortex XDR assigns a higher identity risk score to accounts that exceed the organization's 90-day rotation policy.

Why it fails: Password age is a hygiene finding, not an active attack indicator. Cortex XDR identity analytics does not elevate risk solely because a password is old; the platform scores behavioral anomalies such as impossible travel or new-source authentication. Prioritizing password age here would misdirect the investigation away from the active NTLM authentication from an anomalous workstation.

The volume of Windows Security event 4624 logons on the domain controller, since any successful logon from a workstation indicates the service account was compromised.

Why it fails: Event 4624 logons occur constantly and are not inherently suspicious. The analyst needs context: logon type, source host, and whether that source is first-seen for this account. A raw count of 4624 events on a domain controller is noise; the Cortex XDR identity signal is the anomalous source host paired with Kerberos service ticket activity, not the logon volume itself.

The service account password age exceeding 12 months

Why it fails: Password age is a hygiene concern and may violate policy, but it does not by itself indicate that the account was compromised. Many environments run service accounts with long-lived passwords without any malicious activity, so this factor alone is insufficient to conclude credential compromise in this scenario.

The workstation is not in the domain administrators group

Why it fails: A workstation not being a domain admin host is not a meaningful indicator of compromise; most workstations are not domain admin hosts. This fact does not help determine whether the service account was misused, and it is not a reliable signal in identity threat analysis.

The logon occurred outside standard business hours

Why it fails: Off-hours activity is suspicious but common for scheduled maintenance, backup jobs, and automated tasks that service accounts legitimately perform. Without the interactive logon type and privilege creation behavior, unusual timing alone would not reliably distinguish compromise from routine operations.

Cortex XDR Policy Rules

Why it fails: Policy Rules in Cortex XDR define security policies for endpoints, such as malware protection and exploit mitigation. They do not handle automated response actions for identity-based alerts. While policies can block certain behaviors, they are not the mechanism for orchestrating account disabling or other identity response actions.

Cortex XDR User View

Why it fails: Cortex XDR User View provides a centralized interface to investigate user activity and identity-related alerts. It is an investigative tool, not a configuration component for automated responses. It helps analysts understand the scope of an incident but does not itself execute remediation actions like disabling accounts.

Cortex XDR Analytics BIOC

Why it fails: Cortex XDR Analytics BIOC is used to create behavioral indicators of compromise based on specific event patterns. While it can trigger alerts, it is not designed for automated response actions like disabling user accounts. BIOC rules generate detections but do not directly execute remediation steps; that requires a different configuration component.

A user account performing a password spray against multiple accounts from a single source

Why it fails: Password spraying is an attack technique, not a user behavior indicating that a specific account has been compromised. Detecting it is valuable, but it describes the attacker's action against many accounts rather than an indicator that a particular user's credentials are already in use by an adversary.

A user account logging in during normal business hours from the usual office subnet

Why it fails: Logging in during normal hours from a familiar subnet matches expected baseline behavior and should not trigger an ITDR alert. Prioritizing this as a compromise indicator would generate excessive false positives and distract analysts from genuine identity threats.

A user account accessing a public website over HTTPS

Why it fails: Accessing a public website over HTTPS is routine user activity with no inherent identity risk, and it does not indicate credential compromise. Treating it as a detection priority would flood the SOC with noise and is not aligned with ITDR detection objectives.

The Security event log for Event ID 4624 logon events with logon type 3 (network) from the affected user account.

Why it fails: Event ID 4624 logon type 3 indicates a network logon, which is common for service access. While a Golden Ticket might lead to such logons, this event alone does not confirm forgery. It could be legitimate. The analyst needs more specific Kerberos artifacts, such as the TGS request details and the account's domain SID history, to differentiate a forged ticket from normal activity. Logon events are too generic.

The Cortex XDR agent's process execution logs for the affected user account to identify tools like Mimikatz or Rubeus.

Why it fails: Process execution logs can show the use of credential dumping tools, which might be used to obtain the KRBTGT hash for forging a Golden Ticket. However, the attack could be performed on a compromised host without leaving obvious process traces if the attacker uses fileless techniques or injects into legitimate processes. Moreover, the presence of such tools does not confirm that a forged TGT was actually used; it only indicates potential preparation. The question asks for artifacts to confirm the use of a forged TGT, not the tooling.

The Kerberos TGT request events (Event ID 4768) for the same user account to check for missing pre-authentication.

Why it fails: In a Golden Ticket attack, the attacker forges a TGT and injects it into memory, bypassing the normal TGT request process. Therefore, Event ID 4768 (TGT request) would not be generated for the forged ticket. Examining 4768 events might show no corresponding request, but that absence is not a direct artifact to confirm forgery; it is a negative indicator. The analyst should focus on TGS requests and other logs that reveal the anomalous use of the forged ticket.

Cloud storage audit logs

Why it fails: Cloud storage audit logs record object access, bucket policy changes and data operations in cloud storage services; they do not capture endpoint process execution such as 'whoami'. Detecting that command requires endpoint telemetry. Cloud storage audit logs would be correct for investigating unauthorised access to stored objects.

Firewall URL filtering logs

Why it fails: Firewall URL filtering logs record web requests and blocked destinations, revealing network browsing activity rather than local process execution. 'whoami' runs on the endpoint, so it never appears in URL filtering data. These logs would be correct for detecting connections to malicious or prohibited web domains.

DHCP lease tables

Why it fails: DHCP lease tables map IP addresses to devices over time; they contain no process-execution telemetry, so 'whoami' invocation by a domain user cannot be observed there. Such tables are the right source when resolving which host held an IP at a given moment during investigation.

Registry modifications affecting the Windows Firewall state

Why it fails: Firewall registry keys govern network filtering, not LSASS handle requests, so this telemetry never captures credential dumping. It is tempting because registry monitoring is genuinely the right choice for detecting defence-evasion persistence, such as disabling Windows Firewall, but that is a different attack technique from memory scraping.

DNS query logs for newly registered domains

Why it fails: DNS query logging records name resolution, not the process-level memory reads that credential dumping produces, so it cannot detect LSASS access. It is tempting because DNS telemetry does surface command-and-control beaconing and newly registered domain callbacks, which is the correct choice for detecting malware egress rather than credential theft.

Outbound HTTPS connections to unknown external IP addresses on port 443

Why it fails: Outbound port 443 sessions describe network egress, not the local process access to LSASS memory that credential dumping requires. It is tempting because connection monitoring is the correct choice for detecting command-and-control or exfiltration traffic, but it cannot observe the API calls and handle grants occurring on the endpoint itself.

The Cortex XDR Network Traffic Analyzer

Why it fails: The Network Traffic Analyzer inspects network flows and protocol metadata; it never reads directory objects, so it cannot provide user or group attributes for ITDR correlation. It is tempting because it does enrich alerts with contextual telemetry, but that context is network-based rather than identity-based.

WildFire cloud analysis engine

Why it fails: WildFire performs cloud sandbox analysis of files to detect malicious behaviour; it holds no directory objects, so it cannot supply user or group metadata for ITDR correlation. It is tempting because it enriches alerts, but that enrichment is file-reputation data, not Active Directory identity context.

The Cortex XSOAR Content Pack for Active Directory

Why it fails: The XSOAR Content Pack supplies playbook integrations and commands that query Active Directory, but it does not itself continuously collect user and group metadata into Cortex XDR for ITDR correlation. It is tempting because it genuinely connects to AD, yet it is the automation layer, not the collector.

Real-time packet captures of the user's active browsing session

Why it fails: User View aggregates identity analytics, risk scores and authentication events for a user; it never captures live traffic. Packet capture belongs to network-level inspection, so it is tempting when an analyst wants session evidence, but that data comes from the traffic or endpoint modules, not the identity view.

The hardware warranty status of endpoints assigned to the user

Why it fails: User View aggregates identity context such as risk score, associated alerts and endpoint activity; warranty data sits in asset inventories, not identity investigation. It is tempting because endpoint details appear in the console, and would be correct when checking hardware support coverage rather than triaging an identity-based alert.

Group Policy Object (GPO) editing capabilities

Why it fails: User View is read-only investigative context; editing Group Policy Objects belongs to Active Directory administration tooling, not Cortex XDR alert triage. It is tempting because the console surfaces endpoint and user configuration, and would be correct for a systems administrator changing domain-wide policy settings.

Cloud > Posture > Identity

Why it fails: Identity analytics UBA alerts surface under the Identity Analytics dashboard, not Cloud Posture, which reports misconfigurations and compliance findings against cloud resources. Posture is the right destination when assessing cloud security posture, so it cannot display user behaviour detections.

XQL Search > Identity_Raw schema

Why it fails: Identity_Raw is a raw dataset queried through XQL for custom hunting, not the curated alert view where UBA-generated identity analytics alerts appear. XQL is correct when building bespoke queries against raw telemetry, but the scenario asks to inspect generated alerts.

Endpoints > Agent Configurations > Identity

Why it fails: Agent Configurations holds endpoint policy settings such as malware profiles and protection modules, not identity analytics alerts. It is tempting because agent settings govern what telemetry endpoints report, but UBA detections are viewed in the Identity Analytics dashboard, not configured here.

Antivirus scan reports

Why it fails: Kerberoasting appears in Kerberos service ticket requests (Event ID 4769) against SPNs, which antivirus scan reports do not record. Scan reports are tempting for detecting tooling such as Rubeus on disk, but file-based detection misses the directory-level ticket request itself.

DNS query logs showing external root hints

Why it fails: Kerberoasting is detected through Kerberos service ticket requests (Event ID 4769) against SPNs, which DNS query logs never record. External root hints only reveal recursive resolution paths, so they are tempting when investigating command-and-control domains, not ticket-granting abuse.

DHCP lease allocation tables

Why it fails: Kerberoasting leaves traces in Kerberos service ticket requests (Event ID 4769) against SPNs, which DHCP lease tables do not capture. Lease data is tempting for mapping an attacker's IP to a hostname during lateral movement, but it cannot show ticket requests.

To replace the Cortex XDR Agent on Linux servers

Why it fails: Entra ID logs supply identity, sign-in and conditional access telemetry; they cannot install, manage or replace an endpoint agent, which is a separate software component. Integration is tempting for consolidating identity visibility, and it is correct when correlating suspicious sign-ins with endpoint activity in Cortex XDR.

To enforce local BIOS password policies

Why it fails: BIOS password policies are configured locally on endpoint firmware and are unrelated to Entra ID, which reports cloud identity and authentication events. The integration is tempting as a single pane for hardening, but it is correct for correlating risky sign-ins and conditional access failures with endpoint alerts.

To automate the deployment of Windows security patches to endpoints

Why it fails: Entra ID sign-in and audit logs feed identity-based detections, such as risky sign-ins and impossible travel, into Cortex XDR; they carry no endpoint patch data. Patch deployment belongs to endpoint management tooling like Intune or Configuration Manager, which is the scenario where this capability would be relevant.