SOC Operations practice questions

Local Administrator on all domain controllers

Why it fails: Local Administrator access on all domain controllers exceeds the required operational scope.

Domain Administrator privileges

Why it fails: Granting Domain Administrator privileges violates least privilege and exposes the domain to critical risk.

Schema Administrator privileges

Why it fails: Schema Administrator is unnecessary and dangerously over-privileged for reading logs.

Objects > Custom Objects > URL Category

Why it fails: URL Category objects define custom URL filtering lists for security policy matching; they grant no administrative role scoping. It is tempting because Objects holds reusable configuration elements, and URL Category would be correct if the task were classifying web traffic for a URL Filtering profile.

Network > Interfaces > VLAN

Why it fails: VLAN objects under Network define Layer 2 interface tagging and zones; they do not assign administrator roles or permissions. It is tempting because Network is where firewall interface and zone configuration lives, and VLAN settings would be correct if the task were segmenting traffic rather than restricting admin rights.

Device > Setup > Management

Why it fails: Device > Setup > Management configures Panorama's own management interface, hostname, and services, not role-based admin permissions. It is tempting because the name suggests administrative control, and it would be correct for changing Panorama's management IP or certificates rather than scoping an engineer's access.

Via the Panorama Syslog export settings to the SIEM

Why it fails: Panorama syslog export only forwards logs to a SIEM for correlation and reporting; it cannot block a session. The enforcement occurs in the Prisma Access data plane. Syslog forwarding would be the right choice when the requirement is centralised visibility and retention of firewall or threat logs.

Within the Cortex XDR agent running on the endpoint

Why it fails: Cortex XDR enforces endpoint detection and response, not the ZTNA data-plane decision; Prisma Access itself evaluates posture and grants or denies the connection after SAML authentication. XDR would be the right tool for host-level threat detection and remediation, not for gating network sessions.

Inside the Active Directory Domain Controller Group Policy Objects

Why it fails: Group Policy Objects apply configuration at domain logon or refresh intervals, not per-session runtime posture checks; Prisma Access performs the enforcement when the connection is brokered. GPOs would be correct for centrally managing Windows settings and security templates across domain-joined machines.

Disabling User-ID and relying solely on source IP address subnets in security rules

Why it fails: Source IP subnets violate Zero Trust identity principles because IPs can be spoofed or shared.

Enabling SNMP v1 read-only polling of user session tables

Why it fails: SNMP v1 is insecure, does not map user-to-IP correctly for modern directories, and is deprecated.

Enforcing GlobalProtect captive portal without authentication cookies

Why it fails: Captive portal without cookies creates a poor user experience and does not replace DC polling for internal networks.

Traffic Log

Why it fails: Traffic logs record session initiation, termination, and data transfer metrics, not admin logins.

Threat Log

Why it fails: Threat logs record security events such as spyware, viruses, and vulnerability exploits.

GlobalProtect Log

Why it fails: GlobalProtect logs track client connection events and tunnel states for end-users, not firewall administrators.

TACACS+ single-connection mode with static PINs

Why it fails: TACACS+ single-connection mode carries static PINs, which are shared secrets rather than per-session hardware assertions, so FIDO2/WebAuthn cannot be enforced. It is tempting because TACACS+ is the classic protocol for granular administrative command authorisation, and would be correct when device administration needs per-command accounting.

Local database with plaintext password hashing

Why it fails: A local database with plaintext hashing stores reusable secrets and cannot perform FIDO2/WebAuthn challenge-response, so no hardware-backed token is validated. It is tempting as a fallback for small deployments without external identity infrastructure, and would be correct where administrators authenticate locally with no central directory.

RADIUS PAP protocol without secondary token prompts

Why it fails: RADIUS PAP transmits passwords without a hardware challenge, so no FIDO2/WebAuthn assertion is ever verified. It is tempting because RADIUS integrates widely with token servers and directory services, and would be correct where OTP or push-based second factors are acceptable rather than mandatory hardware keys.

Initial Access

Why it fails: Initial Access is the entry phase of an attack, not a post-compromise stage.

Reconnaissance

Why it fails: Reconnaissance occurs before an attack begins to gather intelligence.

SELECT * FROM process WHERE causality_actor_process_image_name = 'httpd'

Why it fails: This query filters processes where the immediate causal actor is httpd, but it only returns direct children, missing deeper process tree descendants such as bash spawned by a shell script. The web shell may launch intermediate processes, so a single-level causality filter is insufficient for full visibility.

SELECT * FROM process WHERE actor_process_image_name = 'httpd'

Why it fails: The actor_process_image_name field refers to the process that performed the action, not the parent. For process creation events, this would identify httpd as the actor only if httpd itself spawned the child. However, the web shell may be executed by a different actor within the httpd process tree, so this query misses the full lineage.

SELECT * FROM process WHERE causality_actor_process_image_name = 'httpd' OR actor_process_image_name = 'httpd'

Why it fails: Combining both fields broadens the scope but still only captures processes directly related to httpd as either actor or immediate causal actor. It does not recursively retrieve all descendants, so processes spawned by a child of httpd would be excluded, leaving gaps in the process tree.

T1059 - Command and Scripting Interpreter

Why it fails: Command and Scripting Interpreter covers the use of command-line interfaces and scripting languages to execute commands. While certutil is a command-line tool, the specific abuse for proxy execution is better mapped to T1218. T1059 is broader and does not specifically address signed binary abuse.

T1105 - Ingress Tool Transfer

Why it fails: Ingress Tool Transfer involves transferring tools or files from an external system into the victim network. While certutil is used for download, the specific technique for using a signed binary to proxy execution is different. T1105 focuses on the transfer itself, not the abuse of the binary for execution.

T1567 - Exfiltration Over Web Service

Why it fails: Exfiltration Over Web Service involves stealing data by sending it to a web service. The scenario describes downloading a payload, not exfiltrating data. The use of certutil for download is an ingress technique, not exfiltration. T1567 would apply if data were being uploaded to a cloud service.

Set up network connection logging for all endpoints.

Why it fails: Network connection logging records network traffic associated with processes, including IP addresses and ports. While useful for identifying command-and-control, it does not provide process command-line arguments or user context. It is complementary but not a source for the specific telemetry needed here.

Configure the Cortex XDR agent to log all file system modifications.

Why it fails: Logging file system modifications provides visibility into file changes but does not directly capture process creation details such as command-line arguments or user context. While file system monitoring is valuable for detecting malicious file activity, it is not the primary source for process-level telemetry. This configuration alone would not fulfill the requirement.

Enable registry monitoring for critical system hives.

Why it fails: Registry monitoring tracks changes to registry keys, which can indicate malicious persistence or configuration changes. However, it does not capture process creation events or their command-line arguments. It is a separate telemetry source and not relevant to the requirement of process-level detail.

Alert severity level

Why it fails: Excluding by alert severity is too broad and would suppress all alerts of that severity, including true threats. It does not target the specific legitimate tool or behavior, leading to potential blind spots and increased risk. Severity is not a scoping criterion for precise exclusions.

File hash of the administrative tool

Why it fails: While file hash is precise, it can change with updates, requiring frequent maintenance. It also does not account for command-line variations. For a frequently used tool, hash-based exclusions may be too brittle and not as targeted for behavioral alerts, which often rely on process behavior rather than file identity.

Time of day when the tool runs

Why it fails: Time-based exclusions are not a standard or reliable way to scope alert exclusions in Cortex XDR. Attackers can schedule activity to match legitimate windows, and the tool might run at various times. This approach is imprecise and could allow malicious activity during the excluded period.

Threat intelligence feeds to check the reputation of the external IP

Why it fails: Threat intelligence feeds can provide reputation data for the external IP, which is useful, but the question asks for two data sources to prioritize. DNS and firewall logs are more directly tied to the observed network connections and provide immediate context about the domain and data volume. Threat intelligence is supplementary and may not be as readily available or specific.

User login logs to check for anomalous authentication events

Why it fails: User login logs can indicate compromised credentials, but they do not directly enrich the analysis of the specific network connections to the external IP. The scenario is about data exfiltration via network traffic, so authentication logs are less relevant than DNS and firewall logs for this particular investigation.

Endpoint process execution logs to identify the process initiating the connection

Why it fails: While process execution logs are valuable, they are not the highest priority for determining if the network traffic is malicious exfiltration. The question focuses on enriching the network connection analysis; DNS and firewall logs directly provide context about the destination and data volume, which are more immediately relevant to assessing exfiltration.

action = 'file create' AND actor_process_image_name = 'powershell.exe' AND file_name CONTAINS '.ps1'

Why it fails: This detects PowerShell creating a .ps1 file, which could be a script download. However, attackers may download scripts with other extensions or use in-memory execution, making this rule less comprehensive. It also may trigger on legitimate script creation. It is not as directly indicative of download-and-execute behavior as command-line inspection.

action = 'network connect' AND actor_process_image_name = 'powershell.exe' AND remote_ip IS NOT NULL

Why it fails: While PowerShell making network connections can indicate download activity, this rule is too broad. It would trigger on any network connection from PowerShell, including benign administrative tasks. It lacks the specificity of command-line parameters that indicate malicious intent, leading to high false positives.

action = 'process create' AND actor_process_image_name = 'powershell.exe' AND action_parameters CONTAINS 'Start-BitsTransfer'

Why it fails: Start-BitsTransfer is a legitimate cmdlet for downloading files, but it is less commonly used in malicious PowerShell attacks compared to Invoke-WebRequest or DownloadString. While it could be used by attackers, it is not a primary indicator, and this rule might miss more prevalent techniques. It is not one of the top two choices for detecting suspicious download and execution.

PowerShell process spawned by 'explorer.exe'.

Why it fails: While PowerShell can be spawned by explorer.exe in legitimate scenarios (e.g., user launching a script), it is not inherently suspicious. Attackers often use other parent processes like Office applications or scripting engines. Therefore, this condition alone is not a strong indicator of malicious activity.

PowerShell process running with a signed Microsoft certificate.

Why it fails: PowerShell itself is signed by Microsoft, so this condition would be true for all legitimate PowerShell processes. It does not distinguish malicious from benign activity. Attackers may use signed binaries, but the signature alone is not suspicious.

PowerShell process with a parent process of 'winword.exe'.

Why it fails: While a PowerShell process spawned by Word can indicate a malicious macro, it is not always malicious. Many legitimate documents use macros for automation. However, it is a suspicious indicator, but the question asks for two conditions that are indicative of malicious PowerShell usage. The '-EncodedCommand' and network connection are more directly indicative of malicious intent.

Block the domain at the firewall and continue monitoring the endpoint.

Why it fails: Blocking the domain at the firewall is a good preventive measure, but it does not address the potentially compromised endpoint. The malware might use other C2 channels or already have established persistence. Immediate isolation is necessary to contain the threat on the endpoint itself, not just block one domain.

Run a full antivirus scan on the endpoint and wait for results.

Why it fails: A full antivirus scan can detect known malware, but it may take time and might miss sophisticated threats. The immediate priority is to contain the endpoint to prevent further malicious activity. Scanning without isolation leaves the endpoint connected, allowing an attacker to continue operations or move laterally.

Collect a forensic image of the endpoint for further analysis.

Why it fails: Collecting a forensic image is valuable for investigation, but it is not an immediate containment action. The endpoint remains active and connected, risking further compromise. Containment should precede in-depth forensics to prevent the attacker from causing additional damage or exfiltrating data.

Process hollowing

Why it fails: Process hollowing involves creating a new process in a suspended state, replacing its memory with malicious code, and then resuming it. In this scenario, the malicious DLL was loaded into a legitimate process, which is more indicative of DLL injection or side-loading, not hollowing. Hollowing typically replaces the entire process image.

Reflective DLL injection

Why it fails: Reflective DLL injection is a specific form of DLL injection where the DLL maps itself into memory without using the Windows loader. While possible, the scenario does not specify that the DLL is reflectively loaded. The general term 'DLL injection' is more accurate, as it encompasses various methods including reflective injection.

Process Doppelgänging

Why it fails: Process Doppelgänging uses Windows Transactional NTFS to replace a legitimate process's memory with malicious code, similar to process hollowing. It does not involve loading a DLL into an existing process. The scenario describes DLL loading, making Doppelgänging less likely.

Defense Evasion

Why it fails: LSASS memory dumping is catalogued under Credential Access (T1003), not Defense Evasion; the technique's objective is harvesting credentials. Defense Evasion is tempting because attackers often obfuscate or disable tooling alongside it, and would be correct for techniques such as process injection or indicator removal that avoid detection.

Collection

Why it fails: Collection covers techniques that gather data for exfiltration, such as from local systems or email. LSASS dumping instead steals credentials, placing it under Credential Access. Collection would fit an attacker staging files or capturing input before exfiltration, not harvesting authentication secrets.

Discovery

Why it fails: LSASS dumping is cataloged under Credential Access, which covers techniques that steal credentials such as OS credential dumping. Discovery covers techniques like account, network and file discovery used to map the environment, not credential theft, so it fails this scenario despite the attacker's reconnaissance activity.

Rapid, automated encryption of all endpoints for immediate financial ransom

Why it fails: Rapid automated encryption for immediate ransom describes ransomware, typically commodity, not the stealthy custom C2 and low-and-slow exfiltration in the stem. It is tempting because ransomware is high-impact and often state-linked, yet its noisy, monetisation-driven behaviour contrasts with the APT's persistence-focused tradecraft.

Mass distribution via untargeted spam campaigns with out-of-the-box exploit kits

Why it fails: Mass untargeted spam with off-the-shelf exploit kits describes commodity malware, the opposite of this actor's custom C2 and slow exfiltration. It is tempting because broad distribution does generate large infection volumes, but that volume-based model is precisely what the stem contrasts against targeted, low-and-slow APT tradecraft.

Immediate self-replication across all reachable network segments without persistence goals

Why it fails: Self-replicating spread without persistence goals describes a worm, whose propagation is loud and indiscriminate rather than the APT's custom C2 and living-off-the-land stealth. It is tempting because worms also target many hosts, but their lack of persistence and covert exfiltration is the opposite of this actor.

Locally on the GlobalProtect gateway via local user database groups

Why it fails: GlobalProtect local user database groups authenticate users, not devices; conditional access evaluating device compliance is enforced by Microsoft Entra ID before the gateway issues a SAML assertion. Local groups would be correct only for standalone authentication without a cloud identity provider.

Within the Panorama Log Forwarding profile settings

Why it fails: Log Forwarding profiles only select which logs Panorama sends to external destinations; they perform no authentication or device-compliance evaluation. It tempts because Panorama centralises policy and logging, but conditional access decisions occur in Microsoft Entra ID, not in log-forwarding configuration.

Inside the firewall security policy rule base post-authentication

Why it fails: Firewall security policy matches traffic after authentication completes, so an unmanaged device would already hold a valid session; the block must occur during SAML authentication in Microsoft Entra ID. Post-authentication rules suit enforcing segmentation between already-admitted users, not device compliance.

Assign the built-in superuser administrator role to the user account.

Why it fails: The superuser role grants full read-write control across Panorama, directly violating the requirement that the analyst make no changes. It is tempting because it guarantees the visibility they need, and it would be correct for a senior administrator who must manage every firewall and log.

Grant dynamic device group ownership without specifying an admin role profile.

Why it fails: Dynamic device group ownership grants administrative rights over group membership, not read-only visibility of configurations and logs, so it cannot enforce least privilege here. It is tempting because dynamic groups automate role assignment, and it would be correct when access must follow device attributes rather than a fixed admin role profile.

Configure password complexity requirements without modifying access profiles.

Why it fails: Password complexity governs credential strength, not authorisation, so it leaves the analyst's permissions unchanged and cannot restrict changes. It is tempting because hardening authentication is a security control, and it would be correct when the risk is weak or reused passwords rather than excessive privileges.