Security Operations practice questions

WMI persistence

Why it fails: WMI persistence stores event subscriptions in the WMI repository, leaving no process running from C:\Users\Public. It is tempting because WMI can execute code, but that suits fileless persistence via __EventFilter and CommandLineEventConsumer, not a masqueraded binary injecting into explorer.exe.

Process hollowing

Why it fails: Process hollowing replaces the image of a legitimately created suspended process, so the executable path would remain the original one. Here the binary runs from an abnormal path and injects into explorer.exe, which describes process injection or masquerading, not hollowing; hollowing would be the answer if the path stayed System32.

DLL side-loading

Why it fails: DLL side-loading plants a malicious DLL beside a legitimate executable that loads it, so the running binary keeps its trusted path. It is tempting because it also abuses trusted processes, but that suits hijacked DLL search order, not a relocated svchost.exe injecting into explorer.exe.

Normal behavior for an administrator

Why it fails: While administrators often perform remote management tasks across multiple systems, authenticating to geographically separated systems within a one-minute window is highly anomalous. This pattern indicates lateral movement rather than standard administrative workflows, as physical or logical transit times make such rapid, disparate logins impossible under normal operations.

A user with superhuman speed

Why it fails: Although 'superhuman speed' or 'impossible travel' is an informal term used by some identity protection systems to flag anomalous geographic logins, it is not a technically precise security diagnosis. In a professional analysis, this symptom must be attributed to the underlying attack mechanism, such as credential theft or session hijacking.

A false positive due to time synchronization issues

Why it fails: Although Network Time Protocol (NTP) synchronization failures can cause log timestamps to appear skewed or out of order, they do not account for the specific sequence of successful authentications originating from a single source IP to distinct targets. A true time sync issue would manifest as systemic, broad-spectrum logging discrepancies rather than isolated, targeted lateral authentication events.

Lateral movement using SMB

Why it fails: Server Message Block (SMB) is a network file-sharing protocol that operates over TCP port 445, or NetBIOS ports 137, 138, and 139, to facilitate lateral movement and resource sharing within a local network. Because SMB does not utilize UDP or TCP port 53, which is reserved exclusively for DNS traffic, this protocol is unrelated to the observed port 53 anomaly.

Port scan activity from an internal host

Why it fails: A port scan involves systematically sending reconnaissance packets to a wide range of target ports on one or more destination hosts to identify open services. This activity produces a highly distributed traffic pattern across multiple destination ports, which contrasts sharply with a high volume of persistent, structured traffic directed specifically and solely to port 53.

Beaconing to a command-and-control server

Why it fails: Command-and-control (C2) beaconing typically relies on standard web protocols like HTTP or HTTPS over ports 80 and 443 to blend in with legitimate outbound web browsing traffic. While some advanced C2 frameworks can use DNS for beaconing, standard beaconing behavior is characterized by highly regular, periodic check-in intervals rather than the continuous, high-throughput data streams typical of active data exfiltration.

Disable the rule entirely

Why it fails: Disabling the rule entirely eliminates the alert noise problem by also eliminating all detection capability, including for real brute-force attacks — the opposite of the stated goal, which is to reduce false positives while still catching genuine attacks. A rule that never fires isn't tuned, it's removed, taking away the SIEM's ability to flag credential-stuffing or password-spraying activity entirely.

Increase the alert severity to critical for all failed logins

Why it fails: Raising every failed-login alert to critical severity changes how alerts are prioritized in the queue but does nothing to reduce the actual number of alerts being generated — the SIEM still fires on every single failure, so the analyst team remains overwhelmed by volume. It may even worsen things by burying genuinely urgent alerts among a flood of newly-critical low-value ones.

Add a correlation rule to trigger on successful login after multiple failures

Why it fails: A correlation rule for a successful login after multiple failures is a genuinely useful detection for catching brute-force attempts that ultimately succeed, but it's an additional detection layer, not a noise-reduction technique — it doesn't touch the volume of individual failed-login alerts already overwhelming the team, so on its own it doesn't solve the stated tuning problem.

Scheduled task creation

Why it fails: Scheduled task creation is a persistence and execution technique that involves registering a task with the Windows Task Scheduler, typically utilizing schtasks.exe or direct API calls. While a scheduled task can be configured to run rundll32.exe, the immediate parent-child relationship of winword.exe spawning rundll32.exe points directly to an active macro execution payload rather than the registration of a scheduled task.

Process hollowing

Why it fails: Process hollowing is an evasion technique where an adversary spawns a legitimate process in a suspended state, unmaps its memory, and replaces it with malicious code before resuming execution. While rundll32.exe can theoretically be targeted for hollowing, the scenario of Word spawning rundll32 to load an external library represents a direct DLL execution vector rather than the hollowed-out replacement of a suspended process's address space.

WMI persistence

Why it fails: Windows Management Instrumentation (WMI) persistence relies on registering WMI event filters, consumers, and bindings to execute payloads when specific system events occur. This persistence mechanism is managed by the WMI repository and executed via wmiprvse.exe, which differs fundamentally from a Microsoft Word process directly spawning rundll32.exe to load a dynamic link library.

Report the finding as a false positive

Why it fails: Reporting the finding as a false positive is incorrect because the vulnerability actually exists on the host server. A false positive indicates an incorrect detection of a non-existent flaw, whereas in this scenario, the vulnerability is real but mitigated externally by the WAF. Falsely classifying it undermines the accuracy of the vulnerability management database.

Re-run the scan with credentials

Why it fails: Re-running the scan with credentials will only confirm the presence of the vulnerability with higher confidence by checking local registry keys or package versions. It does not address the risk, nor does it acknowledge the active protection provided by the WAF. This action merely delays the necessary risk management decision.

Patch the server immediately

Why it fails: While patching is the ultimate remediation goal, doing so immediately without testing can cause unplanned downtime or system instability. Because the WAF acts as an active compensating control to block exploitation attempts, the organization can safely schedule the patch during a standard maintenance window rather than executing an emergency change.

AppInit_DLLs

Why it fails: AppInit_DLLs is a registry-based DLL injection technique where every user-mode process that loads User32.dll also loads the DLLs specified under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs. While this can achieve persistence, it requires a DLL to be present and modifies the AppInit_DLLs value, not the Run key or a scheduled task. Since the incident response findings point to service creation or task scheduling rather than DLL injection, AppInit_DLLs is not the indicated mechanism.

Service

Why it fails: A Windows service is a background process that can be registered with the Service Control Manager to start automatically at system boot or on-demand. Attackers frequently create malicious services using tools like `sc create` or PowerShell's New-Service, and these services appear under the HKLM\SYSTEM\CurrentControlSet\Services registry key. A suspicious service entry is a strong persistence indicator and directly aligns with the observed ability to run code automatically, making it the correct answer.

WMI event subscription

Why it fails: WMI event subscriptions consist of a filter, a consumer, and a binding that allow a script to run whenever a specified WMI event occurs, such as system startup. However, this persistence mechanism is stored in the WMI repository (CIMV2), not in the traditional Run keys or scheduled task folders, and it does not create a visible service. Without signs of a WMI filter and consumer pair, a Run key or scheduled task finding alone does not implicate WMI, so it is not the correct answer.

Repeated failed logins to multiple hosts

Why it fails: Repeated failed logins to multiple hosts may indicate brute-force attempts or password spraying, but they are pre-authentication failures, not evidence of an established lateral movement session. Once an attacker gains valid credentials, lateral movement often appears as successful logins or SMB connections rather than recurring failures, so this event is too noisy and ambiguous for a horizontal movement detection rule.

High volume of DNS queries

Why it fails: A high volume of DNS queries is typically associated with malware beaconing, domain generation algorithms, or reconnaissance, yet it does not involve the SMB protocol (ports 445/139) that Windows lateral movement relies on for file shares, named pipes, and remote administration. Lateral movement between workstations leverages direct authenticated SMB sessions, whereas DNS is a separate name-resolution service; correlating DNS volume alone would generate many false positives from legitimate internet activity.

Unusual outbound connections on port 443

Why it fails: Unusual outbound connections on port 443 are typically HTTPS web traffic and do not represent the native SMB protocol used in lateral movement. While an attacker could tunnel SMB over port 443 (e.g., via SOCKS proxies or port forwarding), standard SMB lateral movement occurs on ports 445/139, and monitoring for admin share access or SMB peer traffic is much more direct. Outbound 443 anomalies are more often associated with command-and-control communication or data exfiltration rather than a moving between hosts via Windows file services.

Lateral Movement (TA0008)

Why it fails: The Word-to-wscript-to-PowerShell chain is execution and command-and-control behaviour, not movement between hosts; lateral movement requires activity such as remote service creation or SMB/WinRM connections to other systems. Analysts are tempted because the downloaded script could later enable pivoting, but the observed parent-child process relationship itself maps to T1059 and T1204.

Credential dumping (T1003)

Why it fails: Credential dumping involves extracting stored passwords or hashes from memory or the SAM database using tools like Mimikatz; nothing in this Word-to-wscript-to-PowerShell chain indicates any attempt to harvest authentication material.

Persistence (TA0003)

Why it fails: Persistence techniques establish a foothold that survives reboot, such as a scheduled task or registry run key; the observed activity is a one-time download and execution chain with no indication a persistence mechanism was created.

Network-based scan without credentials

Why it fails: A network-based scan without credentials relies solely on active probing of open ports and banner grabbing to identify services. Because it lacks administrative access to the host's registry and file system, it cannot accurately determine local patch levels or registry-based vulnerabilities, leading to a high rate of false positives and missed internal flaws.

Non-credentialed external scan

Why it fails: This scanning method evaluates the target network from the perspective of an outside attacker, focusing on perimeter defenses and publicly exposed services. It is incapable of inspecting internal operating system configurations, local software versions, or system patch levels, making it ineffective for a comprehensive internal vulnerability assessment.

Agent-based scan

Why it fails: While agent-based scans provide deep local visibility similar to credentialed scans, they require installing software on every target host, which may not be feasible across all network assets. A credentialed internal scan represents the broader, more versatile category of assessment that can be conducted agentlessly across the entire internal subnet using standard administrative protocols.

Fast flux

Why it fails: Fast flux is a DNS technique used by botnets to hide malicious servers behind an ever-changing array of compromised host IP addresses. While it involves frequent DNS updates with short Time-To-Live (TTL) values, it does not generate random, high-entropy subdomains. Instead, a single domain name resolves to many different IP addresses in rapid succession.

DNS cache poisoning

Why it fails: DNS cache poisoning, or DNS spoofing, involves injecting fraudulent address records into a caching resolver's database to redirect traffic to malicious sites. This attack targets the integrity of the DNS resolution process rather than generating a high volume of randomized subdomain queries from an infected client. It is a redirection mechanism, not a command-and-control communication method.

DNS tunneling

Why it fails: DNS tunneling abuses the DNS protocol to encapsulate non-DNS traffic, such as SSH or HTTP, within standard queries to bypass firewalls. While it may use subdomains to exfiltrate data, these subdomains are structured payloads rather than the pseudo-randomly generated domain names typical of algorithmically derived rendezvous points. Its primary purpose is data transit rather than dynamic domain discovery.

Compare the process's command line with baseline

Why it fails: While baseline comparisons can identify anomalous startup arguments, they are insufficient for detecting process hollowing. Attackers frequently launch legitimate binaries with completely normal, expected command-line arguments before hollowing out the process memory. Furthermore, command-line arguments can be easily spoofed in memory, making this an unreliable indicator of injection.

Analyze network connections from the process

Why it fails: Analyzing network connections can reveal command-and-control traffic, but it does not definitively confirm process hollowing or memory injection. A hollowed process may remain dormant, perform local actions, or use legitimate system APIs to blend in with normal traffic. Memory-level analysis is required to confirm that the running code differs from the legitimate binary.

Check the process's digital signature

Why it fails: Checking the digital signature only verifies the integrity of the binary file residing on the disk. Because process hollowing occurs in-memory after the legitimate, signed executable has been launched, the on-disk file remains unaltered and its signature will still appear valid. Consequently, signature verification will fail to detect this memory-only evasion technique.

Frequent NXDOMAIN responses

Why it fails: NXDOMAIN responses occur when a queried name does not exist. DNS tunneling relies on domains that are registered and resolve successfully so that encoded data can be transmitted via TXT records or query names. A high rate of NXDOMAIN responses is more indicative of domain-generation algorithm (DGA) malware or typo-squatting, not data exfiltration through DNS tunnels.

Queries for domains with unusual top-level domains (e.g., .tk)

Why it fails: While malicious DNS tunneling may sometimes use free or odd-looking top-level domains like .tk, many legitimate services and ad tracker domains also use unusual TLDs. The presence of such TLDs alone is not a specific or reliable indicator of tunneling, as normal enterprise traffic frequently includes queries to .tk, .xyz, or similar domains. Therefore, this observation is weak evidence without additional corroborating factors.

Multiple queries from different hosts to the same legitimate domain

Why it fails: In a typical enterprise, multiple hosts often query the same legitimate domain for content delivery, software updates, or cloud services. DNS tunneling is usually performed from a single compromised host communicating with one attacker-controlled domain, not spread uniformly across many hosts. Consequently, this pattern is more consistent with normal business traffic and is not strongly indicative of DNS exfiltration.

HKLM\Software\Microsoft\Windows\CurrentVersion\AppInit_DLLs

Why it fails: AppInit_DLLs is a machine-wide persistence mechanism that forces every user-mode process to load a specified DLL, but modern Windows versions disable it by default and require any loaded binary to be code-signed. The SecureDll flag and code-integrity policies further reduce its viability, so adversaries rarely use it today. Compared with services, Run keys, and scheduled tasks, AppInit_DLLs is not a top-three persistence vector for osquery-based triage, as those other mechanisms are far more prevalent and have dedicated, stable query tables.

User's Startup folder

Why it fails: The Startup folder is a valid persistence location, because executables placed there launch at every user logon, but it is user-scoped and only runs in the logged-on user's context. A threat hunter using osquery would typically prioritize system-wide persistence mechanisms such as services, scheduled tasks, and registry Run keys, which affect multiple sessions and can provide privilege escalation. Additionally, the Startup folder requires enumerating file-system paths that may be redirected or easily overlooked, whereas the selected mechanisms have direct osquery tables and are more commonly abused in real-world intrusions.

Change the rule to alert on inbound connections

Why it fails: Modifying the detection logic to monitor inbound connections fails to address the core issue of outbound scanning or beaconing behavior. Because the original alert is designed to detect suspicious outbound activity originating from internal hosts, shifting the focus to inbound traffic renders the rule useless for identifying compromised internal systems communicating outward.

Disable the alert rule

Why it fails: Deactivating the correlation rule entirely eliminates a critical security control and creates a massive blind spot across the entire enterprise network. While this action stops the immediate false positives, it prevents the SIEM from detecting genuine malicious outbound scanning, lateral movement, or command-and-control communications from any other host.

Create an exception for the web server's IP

Why it fails: Creating a blanket exclusion or whitelist for the web server's IP address completely exempts this high-value asset from outbound connection monitoring. If the web server is subsequently compromised by an attacker, the security team would have no visibility into any outbound scanning, pivoting, or data exfiltration originating from this specific host.

DNS query logs

Why it fails: DNS query logs are the wrong choice because they record only hostname-to-IP resolution, not the authentication or connection attempts that occur during pass-the-hash. Even when an attacker uses SMB or other network protocols to move laterally, they often already know the target's IP or use a tool that issues no unique DNS requests, so these logs provide no visibility into the hash-based authentication handshake itself.

Sysmon Event ID 1 (process creation)

Why it fails: Sysmon Event ID 1, process creation, is the wrong choice because it logs the creation of processes and their command lines, not the network authentication protocol that pass-the-hash actually abuses. An attacker can perform PtH with legitimate system tools (e.g., net use, PowerShell) that do not spawn a distinctive process, and the malicious tool may run purely in memory or be injected into an existing trusted process. While unusual process names can be a supplementary indicator, the absence or presence of such processes doesn't directly reflect the hash-based SMB/NTLM authentication, which is the core of the technique.

The connections are made to a known malicious IP

Why it fails: This is incorrect because attackers frequently exfiltrate data to legitimate cloud services, file-sharing platforms, or SaaS applications whose IP ranges are not flagged on threat intelligence lists. A connection to a known-malicious IP would be a strong indicator, but its absence does not rule out exfiltration—in fact, modern exfiltration often deliberately avoids such IPs to evade blacklist-based detection. Additionally, threat intelligence entries can become stale, so relying solely on this signal would miss many real data-theft scenarios.

The connections occur during business hours only

Why it fails: This is incorrect because exfiltration can absolutely occur during business hours, and many servers only operate during normal working hours, making business-hours connections the norm rather than an anomaly. Attackers may intentionally operate within legitimate workflows to blend in, or they may use the high volume of daytime traffic as cover to hide their activity. A static rule that treats business-hours traffic as benign would not only miss exfiltration but also generate false negatives when the exfiltration is embedded in a large volume of otherwise valid sessions.

Increase the alert threshold to 10 GB in 5 minutes.

Why it fails: Raising the volume threshold to 10 GB in 5 minutes is an arbitrary adjustment that fails to address the root cause of the false positive. This change severely degrades the SIEM's detection capability, allowing adversaries to exfiltrate significant amounts of sensitive data just below the new limit without triggering any alert.

Create a correlation rule that combines this alert with other indicators.

Why it fails: While correlation rules are valuable for complex threat hunting, creating one here does not resolve the immediate issue of the noisy, false-positive alert triggered by legitimate traffic. The analyst needs to tune the existing rule to ignore known-safe traffic rather than adding unnecessary complexity with additional event conditions.

Disable the alert rule permanently.

Why it fails: Permanently disabling the alert rule creates a critical blind spot in the organization's security monitoring posture. It completely eliminates the SOC's visibility into unauthorized data exfiltration events, leaving the network highly vulnerable to undetected data loss from malicious actors.

A SYN flood attack

Why it fails: A SYN flood attack is a Denial of Service (DoS) technique characterized by a massive, rapid volume of SYN packets originating from spoofed IP addresses designed to exhaust the target's connection queue. In contrast, a steady stream of repeated SYN packets at regular intervals targeting multiple ports indicates systematic probing rather than an attempt to overwhelm system resources.

A misconfigured firewall dropping SYN-ACK packets

Why it fails: If an intermediate firewall were misconfigured to drop outbound SYN-ACK packets, the analyst capturing traffic near the target server would still observe the server generating and transmitting those SYN-ACK responses. The complete absence of any outbound SYN-ACK packets suggests the target operating system is either ignoring the requests on closed ports or a packet-filtering mechanism is silently discarding the inbound SYN packets before they reach the socket layer.

A half-open connection due to network latency

Why it fails: While high network latency can delay TCP handshakes and trigger standard TCP retransmissions, these retransmissions follow an exponential backoff algorithm rather than occurring at rigid, regular intervals across multiple ports. Furthermore, latency issues would eventually result in delayed SYN-ACK or RST packets being captured, rather than a clean, uniform pattern of unanswered probes typical of reconnaissance.

Normal DNS caching behavior

Why it fails: Normal DNS caching behavior involves storing previously resolved domain names locally or on a recursive resolver to speed up subsequent requests. This process relies on standard, human-readable domain names and Time-to-Live (TTL) values. It would not generate a high volume of unique, randomized, or non-existent domain queries, which bypasses caching mechanisms entirely.

A misconfigured DNS resolver

Why it fails: A misconfigured DNS resolver typically results in resolution failures, routing loops, or timeouts for legitimate domains. While it might cause repetitive queries for the same domain due to retries, it cannot dynamically generate a sequence of random-looking domain strings. Such algorithmic randomness points to an intentional client-side behavior rather than a server-side configuration error.

Domain generation algorithm (DGA) usage

Why it fails: Malware families frequently employ Domain Generation Algorithms (DGAs) to dynamically generate a large number of pseudo-random domain names to use as rendezvous points for command-and-control (C2) servers. Because only a fraction of these domains are actually registered by the attacker daily, security logs will show a high volume of failed DNS queries (NXDOMAIN responses) mixed with successful connections to random-looking strings.