Security Operations practice questions

search xdr_data | stats count by command_line | where command_line = 'Hidden'

Why it fails: Using stats before filtering the specific process execution is inefficient and syntactically incorrect for raw process searches.

SELECT * FROM xdr_data WHERE event_type == 'PROCESS_START' AND command_line LIKE '%Hidden%'

Why it fails: XQL does not use standard SQL SELECT syntax; it uses dataset name and pipe notation.

collect xdr_data where event_type = 'PROCESS_START' | parse command_line as Hidden

Why it fails: 'collect' is not the correct command to initiate an XQL search stream.

Panorama > Managed Devices > Health Summary

Why it fails: Panorama health summaries track hardware and connection status, not SOC response times.

WildFire > Portal > Statistics

Why it fails: WildFire statistics track file analysis numbers, not SOC incident KPIs.

Prisma Access > Monitoring > Traffic Logs

Why it fails: Traffic logs show network flows, not SOC operational KPIs.

Enable User-ID redistribution via Panorama to invalidate the user session.

Why it fails: User-ID redistribution invalidates sessions based on user mapping; it does not parse an email sample, extract URLs, query reputation services or push firewall blocks. It is tempting because User-ID underpins policy enforcement, but that mechanism applies to identity-based rules, not to automated phishing indicator extraction and remediation.

Configure a WildFire Analysis Profile to inspect inbound SMTP traffic streams.

Why it fails: A WildFire Analysis Profile inspects files and links for malicious behaviour on the firewall, but it neither extracts URLs from an email sample nor performs reputation lookups and enforcement orchestration. It is tempting because WildFire does detonate URLs, yet the automated extract-check-block workflow belongs to Cortex XSOAR playbooks and integrations.

Deploy a Decryption Profile to re-sign TLS certificates on the mail server.

Why it fails: A Decryption Profile manages TLS inspection settings such as certificate re-signing and unsupported protocol handling; it does not extract URLs from email, check reputations or block them. It is tempting because inbound inspection touches mail traffic, yet decryption profiles govern cipher and certificate behaviour, not indicator extraction and response.

Disable all header encryption and export logs using raw ASCII carriage returns only.

Why it fails: Raw ASCII without structured formatting makes SIEM parsing extremely difficult and prone to errors.

Rewrite the PAN-OS kernel to natively output syslog in Microsoft Word DOCX format.

Why it fails: PAN-OS does not support DOCX log exports.

Convert all log files into uncompressed raw bitmap graphics prior to export.

Why it fails: Bitmaps cannot contain text logs or structured security events.

Bluetooth peer-to-peer relay

Why it fails: Bluetooth is not a supported enterprise log forwarding mechanism.

Local BIOS firmware flash memory

Why it fails: BIOS flash memory is hardware-level storage, not a log forwarding destination.

Endpoint Inventory

Why it fails: Endpoint Inventory in Cortex XDR provides a list of managed endpoints and their properties, but it does not contain network connection details or the ability to search for communication with a specific IP. The analyst would not find the required information here. It is used for asset management, not traffic analysis.

Incident Timeline

Why it fails: The Incident Timeline in Cortex XDR displays a chronological sequence of events related to a specific incident, but it does not support querying across all network connections for a specific IP. It is limited to the scope of the incident and may not include all relevant network traffic. The analyst needs a broader search capability.

Network Connections

Why it fails: Network Connections in Cortex XDR shows a list of network connections made by endpoints, but it does not directly allow filtering by a specific remote IP address over a time range. The analyst would need to manually scan through many entries. A more targeted query is needed to efficiently identify the internal host.

Event ID 5140 on the domain controller, which logs that a network share was accessed

Why it fails: Event ID 5140 indicates that a network share object was accessed and includes the account and source address. It does not record process creation or the binary responsible for the NTLM authentication. While it may corroborate lateral movement, it cannot identify the source process on the workstation, making it the wrong choice here.

Event ID 4776 on the domain controller, which validates the credentials for the account

Why it fails: Event ID 4776 is logged on the domain controller when NTLM credentials are validated, and it records the account name and the authenticating workstation. It does not identify the source process or its parent on the workstation, so it cannot answer which binary initiated the authentication. The analyst needs process-level context, which this event does not provide.

Event ID 4688 on the domain controller, which records process creation for services running on that server

Why it fails: Event ID 4688 is a process creation event, but it is generated on the host where the process runs. On the domain controller it would only show processes executing on the DC, not the remote workstation's initiating process. It cannot reveal what ran on the workstation, so it fails to answer the question in this scenario.

The source IP addresses used for the login attempts.

Why it fails: Source IP addresses can be spoofed or rotated in both brute-force and password-spraying attacks. While geographic diversity may suggest a distributed attack, it does not reliably distinguish the two methods. Both can originate from multiple IPs, so focusing solely on source IPs would not provide a definitive answer. The pattern of account targeting is more indicative.

The number of failed login attempts per user account.

Why it fails: Counting failed attempts per account does not distinguish brute-force from password spraying. Brute-force typically targets one account with many passwords, while password spraying uses a few common passwords across many accounts. The attempt count alone is ambiguous because both can generate many failures, and the pattern across accounts is what matters, not the raw count for a single user.

The time interval between consecutive failed login attempts.

Why it fails: The time interval can vary based on attack tooling and network latency, but it is not a reliable indicator of brute-force versus password spraying. Both attacks can be automated with similar timing patterns. The critical difference lies in whether the attacker is guessing many passwords for one account or one password for many accounts, not the timing between attempts.

Windows PowerShell operational log, Event ID 4104, which records script block logging

Why it fails: Event ID 4104 captures PowerShell script blocks when script block logging is enabled, which helps investigate PowerShell-based activity. It does not record general process creation or the command line of a non-PowerShell executable. A suspicious binary outside PowerShell would leave no 4104 event, so this source cannot confirm execution in this case.

Windows Defender Antivirus operational log, Event ID 1116, which records malware detection

Why it fails: Event ID 1116 in the Defender operational log reports that malware was detected, including the threat name and affected file. Detection does not guarantee the file was executed; it may have been quarantined on write or during a scan. It also does not provide the command line, so it cannot confirm execution or reveal how the binary was invoked.

Sysmon Event ID 1, which records process creation with hashes and command line

Why it fails: Sysmon Event ID 1 is excellent for process creation with hashes, parent image, and command line, but it is only available if Sysmon is deployed. The scenario states the endpoint agent is the EDR, not Sysmon. Without Sysmon installed, this event source does not exist on the workstation, so it cannot be the first data source to consult.

Isolate the critical server from the network.

Why it fails: Isolating the critical server could disrupt business operations and is a drastic step. While it may prevent further lateral movement, it is not the first action to take. The analyst should first contain the compromised account to stop the attacker's access, then assess whether server isolation is necessary based on evidence of malware or ongoing malicious activity.

Reset the user's password and force a change at next logon.

Why it fails: Resetting the password can be part of remediation, but it is not the immediate containment action. If the attacker has an active session, changing the password may not terminate it, and the attacker could still operate. Disabling the account is more effective for immediate containment. Password reset is typically done after containment to restore secure access.

Block the suspicious external IP address at the firewall.

Why it fails: Blocking the external IP address might prevent communication with that specific source, but attackers often use multiple IPs or compromised infrastructure. It does not address the compromised credentials, which could be used from other locations. This action is a partial mitigation but not a primary containment step for a credential compromise.

Spear phishing

Why it fails: Spear phishing targets specific individuals or groups, but it typically involves a more elaborate pretext and may not always involve executive impersonation. This scenario is a classic business email compromise (BEC) where the attacker impersonates a high-level executive to trick an employee into transferring funds or purchasing gift cards. Spear phishing is a related but broader category.

Whaling

Why it fails: Whaling is a type of phishing specifically targeting high-level executives, such as CEOs or CFOs, rather than impersonating them to attack lower-level employees. In this scenario, the CEO is being impersonated to target another employee, which is characteristic of BEC, not whaling. Whaling would involve targeting the executive directly.

Phishing

Why it fails: Phishing is a broad term for fraudulent emails, but this scenario specifically involves impersonating an executive to request gift cards, which is a targeted attack known as business email compromise (BEC). While BEC is a form of phishing, the specific characteristics of CEO impersonation and gift card request point to BEC. Phishing is too generic and does not capture the targeted nature.

Submit the suspicious file to VirusTotal directly from the Cortex XDR console using the 'Submit to VirusTotal' option.

Why it fails: While Cortex XDR may integrate with threat intelligence, submitting to VirusTotal is not a native action within the console and may not be available. Moreover, the alert already includes reputation data; the analyst should focus on internal context rather than external submission, which could also leak sensitive data.

Use the Cortex XDR 'Action Center' to isolate the endpoint immediately.

Why it fails: Isolating the endpoint is a containment action, not evidence gathering. The scenario asks to collect additional context before escalation; isolation would disrupt the user and may not be warranted yet. The analyst should first gather evidence to determine the severity and scope of the incident.

Run the 'tasklist' command on the endpoint via the Cortex XDR Live Terminal to list all running processes.

Why it fails: While Live Terminal can execute commands, using 'tasklist' provides only a static snapshot of current processes and lacks the historical and causal relationships already captured by Cortex XDR. The alert already includes process information; this action is redundant and does not leverage the platform's built-in investigation capabilities.

A Log Forwarding Profile configured on the Prisma Access cloud service.

Why it fails: Log Forwarding Profiles belong to Prisma Access and push traffic logs to external destinations; they cannot ingest Prisma Cloud alerts into Cortex XSOAR or trigger playbooks. It tempts because forwarding profiles genuinely centralise Prisma Access logging. In XSOAR, ingestion and playbook triggering come from an integration instance (the Prisma Cloud app) and its fetch configuration.

A Syslog Collector script running on a Panorama Log Collector.

Why it fails: A Syslog Collector script on a Panorama Log Collector relays firewall and Panorama logs; it neither receives Prisma Cloud alerts nor invokes XSOAR playbooks. It tempts because syslog collection is a real mechanism for onboarding network telemetry. Prisma Cloud alert ingestion instead requires an XSOAR integration instance configured to fetch incidents.

An External Dynamic List hosted on an internal web server.

Why it fails: An External Dynamic List is a read-only feed of IPs, URLs, or domains consumed by enforcement points such as firewalls; it cannot ingest Prisma Cloud alerts or start XSOAR playbooks. It tempts because EDLs genuinely distribute indicators for blocking. Alert ingestion and automation instead depend on an XSOAR integration instance.

Create an Incident Response Playbook in XSOAR to regex-parse the raw text file.

Why it fails: XSOAR playbooks orchestrate response actions after an incident is created; they run too late to map raw fields into the Common Schema, and regex on a text file does not populate the data model. Playbooks would be correct for automating enrichment or containment. Ingestion-time parsing in Cortex XSIAM handles schema mapping.

Modify the firewall Zone Protection profile to drop unparsed packets.

Why it fails: Zone Protection profiles are firewall settings applied to network zones to defend against floods and scans; they cannot map raw log fields into the Common Schema. Dropping unparsed packets would actually discard the telemetry the analyst needs. Custom parsing in Cortex XSIAM is performed with the Broker VM log parsing rules or the data model schema editor.

Configure Data Collection Rules in Expedition to automatically rewrite the syslog header.

Why it fails: Expedition rewrites syslog headers and normalises firewall log formats during migration; it does not create custom parsing rules mapping arbitrary non-RFC application fields into the Common Schema. It would be correct for converting legacy PAN-OS configurations. Cortex XSIAM's parsing rules and schema mapping handle non-standard log formats.

Change the Authentication Profile to drop Kerberos ticket grants.

Why it fails: Dropping Kerberos ticket grants affects domain authentication behaviour but leaves the endpoint's network connectivity intact, so the host could still communicate with attackers. It is used to disrupt credential-based lateral movement. Automatic host isolation requires a Cortex XDR response action, not an Authentication Profile change.

Enable strict Zone Protection profiles on the local switch interface.

Why it fails: Zone Protection profiles defend against network-layer floods and scans on a firewall interface; they cannot isolate an endpoint. They are chosen for volumetric attack mitigation at the perimeter. Automatic host isolation on impossible-travel detection requires a Cortex XDR response action, not switch or firewall zone hardening.

Apply a Global Protect Portal lockout via Panorama Device Groups.

Why it fails: A GlobalProtect portal lockout blocks VPN authentication for a user; it does not quarantine the compromised host's network access. Portal lockouts suit disabling remote access after credential abuse. The stem asks for automatic endpoint isolation, which is a Cortex XDR response action triggered by the analytics detection.

Change the GlobalProtect Gateway IP pool configuration.

Why it fails: The GlobalProtect gateway IP pool assigns addresses to VPN clients; it does not filter traffic to an external C2 address. It is tempting because GlobalProtect is a Panorama-managed security component, but blocking requires a security policy rule, not altering the client address pool.

Modify the local hosts file on every endpoint via Cortex XDR Action Center.

Why it fails: Editing endpoint hosts files blocks name resolution, not traffic to a known C2 IP address, and Cortex XDR cannot guarantee coverage of every host. It is tempting because XDR offers centralised endpoint action, but a firewall policy on the managed next-generation firewalls is what drops the connection enterprise-wide.

Reboot the Panorama management server to flush active state tables.

Why it fails: Rebooting Panorama restarts the management plane; it does not push a security policy to the firewalls enforcing traffic, and state tables are not flushed this way. Rebooting is tempting as a reset gesture, but policy enforcement requires a committed rule, not a management-server restart.

Objects > External Dynamic Lists > Syslog

Why it fails: External Dynamic Lists import external IP or URL lists for policy enforcement; they do not define Syslog server profiles. It is tempting because both are Objects entries referencing external resources, but Syslog server profiles are created under Objects > Server Profiles > Syslog, so this path cannot forward logs to a SIEM.

Policies > Forwarding > Syslog

Why it fails: Palo Alto Networks has no Policies > Forwarding > Syslog path; forwarding profiles are configured elsewhere, and server profiles live under Objects > Server Profiles > Syslog. It is tempting because log forwarding is policy-driven, but this menu does not exist for defining a Syslog server profile.

Network > Log Settings > Syslog

Why it fails: Network > Log Settings configures logging destinations and rates on the firewall itself, not external Syslog server profiles. It is tempting because both concern log handling, but defining a Syslog server profile requires Objects > Server Profiles > Syslog, so this path cannot create the external SIEM target.

Run a manual threat hunting query in the Action Center to install new agents.

Why it fails: The Action Center handles response actions such as isolating endpoints and installing agents, not investigative querying, so it cannot establish incident scope. Manual threat hunting belongs in the Query Center or Investigation view, where the analyst pivots on alerts, processes and IOCs.

Access the Policy Editor to disable the infected endpoints from the network.

Why it fails: Disabling endpoints via the Policy Editor is a containment action, not triage; it cannot reveal scope or root cause. The Policy Editor configures prevention profiles and agent settings, so it would be the right place to enforce a block once the investigation has already identified the affected endpoints and behaviour.

Open the Endpoint Protection profiles to manually delete the malware binaries.

Why it fails: Endpoint Protection profiles configure malware scanning and action settings; manually deleting binaries there is remediation, not triage, and cannot map the incident's scope or origin. Profiles would be the correct place to adjust scanning or blocking behaviour after the investigation establishes which files and endpoints require action.

Open Cortex XSOAR and run a manual ping command on the hash.

Why it fails: Cortex XSOAR is a SOAR orchestration platform, not a hash-reputation lookup service; a ping command tests network reachability and returns no verdict on file hashes. It is tempting because XSOAR playbooks can query threat intel, but the manual WildFire hash lookup lives in the WildFire portal or AutoFocus.

Check the User-ID agent status page for hash mapping tables.

Why it fails: The User-ID agent maps IP addresses to usernames; it holds no file-hash analysis records. It is tempting because User-ID pages expose mapping tables, but WildFire verdicts are queried through the WildFire portal or API, not the User-ID agent.

Navigate to Panorama > ACC and filter by SHA256 signatures.

Why it fails: The ACC displays aggregated traffic and threat dashboards, not per-hash WildFire verdicts, and SHA256 filtering there does not query the WildFire cloud. Manual hash lookup is performed in the WildFire portal or via the WildFire API, which return prior analysis results for a submitted hash.

Open the msiexec.log file generated during the initial software installation.

Why it fails: msiexec.log records the MSI installation transaction only, so it captures install-time errors and never ongoing server communication. The agent's operational logs, written under ProgramData, hold connection and heartbeat status. msiexec.log would be the correct file when an installation itself fails or rolls back.

Check the /var/log/pan/nsm.log file on the log collector.

Why it fails: nsm.log sits on a Linux log collector and records network security monitoring data, not Windows endpoint agent telemetry. Cortex XDR agent communication on Windows is logged in the agent's own log files under ProgramData. The nsm.log path is relevant only when troubleshooting the log collector appliance itself.

Inspect the pan_event_log.csv file in the PAN-OS system partition.

Why it fails: pan_event_log.csv resides in the PAN-OS system partition on a firewall, holding firewall event data, not Windows endpoint agent status. Cortex XDR agent communication is recorded in the agent log files on the endpoint. That CSV would be relevant when reviewing firewall events on a PAN-OS device.