Proactive Threat Detection practice questions

A misconfigured web application load balancer

Why it fails: Load balancers typically use load-balancing specific ports or 80/443.

Standard user traffic to a file share

Why it fails: User traffic is typically directed to a single known file server, not multiple IPs.

Normal background updates for the operating system

Why it fails: Windows updates generally use ports 80/443, not 445.

Process Monitor

Why it fails: Process Monitor captures real-time file system, registry, and process/thread activity. It can log network operations if configured with filters, but it does not provide a simple, dedicated view of active network connections per process. Its primary strength is deep system activity monitoring, not a live network endpoint mapping like TCPView.

Process Explorer

Why it fails: Process Explorer provides detailed process information such as handles, DLLs, and memory usage, but it does not natively map processes to network endpoints. It can show TCP/IP tab via integration with other tools, but it is not designed for real-time network connection correlation. For identifying processes with network connections, a dedicated network-to-process mapping tool is required.

Autoruns

Why it fails: Autoruns shows what programs are configured to start during system boot or user logon, including registry keys, scheduled tasks, and services. While useful for persistence detection, it does not provide information about active network connections or map them to running processes. Therefore, it cannot correlate processes with network endpoints in real time.

Event ID 4688 in the Security log

Why it fails: Event ID 4688 logs process creation, including the process name and command line. While it can show that a suspicious process like mimikatz.exe was executed, it does not directly indicate memory access to lsass.exe. Credential dumping often involves opening a handle to lsass with specific access rights, which is captured by a different event. Thus, 4688 alone is insufficient for detecting the memory access behavior.

Event ID 4656 in the Security log

Why it fails: Event ID 4656 is generated when a handle to an object is requested. It can include access to lsass.exe if object access auditing is enabled, but it is not specific to credential dumping and can be noisy. It requires additional configuration and filtering to be useful. The more direct event for detecting lsass memory access is 4663, which logs the actual access attempt.

Event ID 10 in the Sysmon log

Why it fails: Sysmon Event ID 10 logs process access events, including the source process and target process, and the granted access. It is indeed a valuable source for detecting lsass access, but the question specifies Windows event logs, and Sysmon is an optional additional logging tool. The native Windows Security log event for object access is 4663. If Sysmon is not deployed, 4663 is the correct answer.

Inspect the SNI field in the TLS handshake for known malicious domain names.

Why it fails: SNI inspection can identify malicious domains if they are known, but it relies on threat intelligence and does not detect unknown exfiltration destinations. Attackers often use compromised or newly registered domains not yet in blocklists. Also, SNI may be encrypted with ECH. This method is limited and not as effective as volume-based anomaly detection for unknown threats.

Analyze the size and timing of TLS records to infer the type of data being transferred.

Why it fails: TLS record size and timing analysis can sometimes infer application type, but it is complex, noisy, and not reliable for detecting exfiltration of arbitrary data. It requires deep expertise and may not work with all traffic patterns. Given the constraint of no TLS inspection, this method is impractical and less effective than volume-based anomaly detection.

Alert on any HTTPS connection to a cloud storage service, as these are common exfiltration channels.

Why it fails: Cloud storage services are used legitimately for business, so alerting on all connections would generate excessive false positives. While they can be exfiltration channels, the mere connection is not indicative of data theft. This method lacks specificity and would overwhelm analysts, making it ineffective for proactive detection without additional context.

Repeated connections to a known CDN IP address with high upload volume.

Why it fails: Connections to CDNs are normal and often high-volume for legitimate services. While C2 may use CDNs, high upload volume alone is not specific to domain fronting and would generate many false positives. Without the SNI/Host mismatch, this characteristic is insufficient to detect domain fronting and could mislead the analyst.

DNS queries for the front domain resolving to multiple IP addresses.

Why it fails: CDN domains commonly resolve to multiple IPs for load balancing and redundancy. This is normal behavior and not indicative of domain fronting. Attackers abuse the CDN's infrastructure, but the DNS response itself does not reveal the technique. Focusing on this would produce false positives and miss the actual fronting indicators.

Outbound connections to port 443 that use self-signed certificates.

Why it fails: Domain fronting uses legitimate CDN certificates, which are signed by trusted CAs. Self-signed certificates are more typical of direct C2 without fronting. Alerting on self-signed certificates would not detect domain fronting and could miss it entirely. This characteristic is not relevant to the technique.

Event ID 4648

Why it fails: Event ID 4648 is logged when a process attempts to log on using explicit credentials, such as when using 'runas' or scheduled tasks with stored credentials. While pass-the-hash involves using credentials, it does not typically generate 4648 because the attacker uses the hash directly without specifying explicit credentials. 4648 is more relevant for detecting credential use in interactive sessions or scripts, not pass-the-hash over the network.

Event ID 4625

Why it fails: Event ID 4625 logs failed logon attempts. While pass-the-hash attacks can sometimes cause failed logons if the hash is incorrect or the account is locked, successful pass-the-hash attacks do not generate 4625. Attackers typically use valid hashes, so the authentication succeeds. Monitoring 4625 is useful for detecting brute-force or password guessing, but it is not a primary indicator of pass-the-hash. Therefore, it is less relevant for this specific hunt.

Event ID 4672

Why it fails: Event ID 4672 is logged when a user with administrative privileges logs on. It indicates that special privileges were assigned to a new logon session. While pass-the-hash often involves privileged accounts, 4672 is generated for any admin logon, including legitimate ones. It does not specifically indicate pass-the-hash. Therefore, it is not one of the most relevant event IDs for detecting this technique, though it can provide context when correlated with other events.

Failed login attempts to the local administrator account

Why it fails: Failed local administrator logons indicate password guessing against an account, not a process opening lsass.exe for memory reading. It is tempting because credential theft often follows successful logons, and it would be correct when detecting brute-force or password-spray activity against local accounts.

Increased CPU usage on the Domain Controller

Why it fails: CPU spikes on a domain controller reflect authentication load or replication work, not memory reads of lsass.exe on the targeted host. It is tempting because credential dumping can accompany heavy authentication traffic, and it would be correct when baselining domain controller performance during a suspected brute-force campaign.

Modification of registry keys in HKEY_LOCAL_MACHINE\SYSTEM

Why it fails: Registry modifications under that hive cover service, driver and boot configuration changes, not handle access to the LSASS process. It is tempting because attackers do persist via registry keys, and it would be correct when detecting persistence mechanisms such as malicious services or altered security settings.

The task is scheduled to run every 24 hours

Why it fails: A 24-hour interval is ordinary for legitimate updaters, so it does not distinguish malicious from benign. It is tempting because regular recurrence looks mechanical, but the critical indicator is the task's action and trigger context, such as a binary in a user-writable path launched at logon.

The task has a generic name like 'Updater'

Why it fails: A generic name like 'Updater' is weak evidence; attackers mimic such names, but legitimate software uses them too. It is tempting because the label looks deceptive, yet the critical indicator is the task's executable path and command line, which reveal unsigned binaries or encoded payloads.

The task is configured to run at system startup

Why it fails: Startup execution is common in legitimate updaters and services, so it alone does not indicate malice. It is tempting because persistence at boot feels suspicious, but the decisive indicator is what the task runs and from where, such as an unsigned binary in a temporary directory.

Capability

Why it fails: Capability describes the adversary's tools, techniques and malware, not the command-and-control servers or domains reaching internal hosts. It is tempting because capability analysis maps what an intrusion can do, and would be the priority when profiling an adversary's tradecraft or predicting future attack methods rather than locating its communication infrastructure.

Adversary

Why it fails: Adversary identifies the actor or group behind an intrusion, not the servers and domains used for command and control. It is tempting because attribution work is central to threat intelligence, and would be the priority when the analyst needs to profile the threat actor's identity, motivation or sponsorship rather than trace its communication channels.

Victim

Why it fails: Victim describes the targeted organisation, assets and people, not the adversary's command-and-control infrastructure. It is tempting because victim analysis supports impact assessment and targeting insight, and would be the priority when scoping which internal hosts or business units were affected rather than identifying the external infrastructure contacting them.

Check the destination IP against a reputation database

Why it fails: Reputation databases flag known-bad infrastructure, but a beacon to a clean or newly registered host passes unchecked, and the query returns no timing data. It is tempting because threat-intelligence lookups are a routine triage step, yet they cannot separate periodic beaconing from ordinary high-volume user traffic.

Compare the total volume of data sent to the IP against a global average

Why it fails: Aggregate volume hides periodicity: beaconing sends small, evenly spaced packets that can sit well below a global average. It is tempting because volume baselines are a standard anomaly-detection technique, but they suit exfiltration or flooding detection, not the regular inter-arrival timing that distinguishes beaconing from high-volume user traffic.

Perform a DNS lookup on the destination IP address

Why it fails: A DNS lookup resolves the destination to a hostname; it returns no timing or interval data, so periodic beaconing stays indistinguishable from bulk traffic. It is tempting because reverse lookups quickly attribute suspicious IPs during triage, but reputation and naming do not reveal the regular inter-arrival intervals that define beaconing.

Enable verbose logging on all domain controllers

Why it fails: Verbose logging on domain controllers captures authentication events, not the decoded contents or parent process of an encoded PowerShell command. It is tempting because domain controllers are central to detecting credential abuse, but decoding the script block and inspecting process lineage on the originating host is what distinguishes malicious obfuscation from legitimate administration.

Run a full antivirus scan on the affected workstation

Why it fails: Signature-based scanning inspects files on disk, whereas encoded PowerShell executes in memory and typically leaves no matching signature, so the scan returns clean without resolving intent. It is tempting because antivirus is the standard response to suspected endpoint compromise, and would be correct if the artefact were a known malware binary on disk.

Reimage the host immediately to prevent lateral movement

Why it fails: Reimaging destroys volatile evidence — memory-resident scripts, network connections and prefetch artefacts — before the encoded command can be decoded and scoped, so the malicious-versus-administrative question is never answered. It is tempting as containment for confirmed compromise, and would be correct once analysis establishes active lateral movement requiring eradication.

Update all signatures to the most restrictive settings available

Why it fails: Maximum restrictive signature settings increase sensitivity across every rule, raising false positives and analyst workload rather than reducing them. The scenario needs targeted tuning of noisy signatures; restrictive global settings suit high-security environments where over-alerting is acceptable.

Disable all low-severity alerts in the IDS management console

Why it fails: Disabling all low-severity alerts discards genuine indicators that correlate with higher-severity activity, so visibility drops and detection efficacy falls. Threshold tuning and suppression rules targeting known-benign patterns reduce false positives while retaining coverage; blanket disabling is not tuning.

Set the IDS to 'Alert Only' mode for all signatures

Why it fails: Alert Only mode leaves every signature firing without blocking, so false-positive volume and analyst workload remain unchanged. It suits passive monitoring or baselining phases before enforcement, not signature tuning that must cut noise while preserving detection.

Purchase every available threat intelligence feed on the market

Why it fails: Buying every feed floods analysts with unfiltered indicators and does not map detections to ATT&CK techniques, so coverage against common enterprise threats stays unmeasured. It is tempting because intelligence feeds enrich detection, and would be correct when prioritising specific adversary infrastructure already observed targeting the organisation.

Rewrite all existing SIEM correlation rules from scratch

Why it fails: Rewriting all correlation rules from scratch discards working detections and delays coverage, without first mapping existing rules to ATT&CK techniques to expose gaps. It is tempting because rule quality matters, and would be correct after a gap assessment identifies specific techniques lacking any detection logic.

Focus only on detecting the 'Command and Control' phase

Why it fails: Restricting detection to Command and Control leaves earlier techniques such as initial access, execution and persistence uncovered, so common enterprise threats proceed undetected. It is tempting because C2 is high-fidelity, and would be correct when hunting specific beaconing behaviour already indicated by threat intelligence.

Disabling SSL verification for the incoming feed

Why it fails: Disabling certificate validation exposes the feed to tampering and spoofed indicators, undermining trust in ingested data; it never affects workflow mapping. Validation is disabled only for lab testing with self-signed certificates. Mapping depends on correlation rules translating STIX objects into incident fields.

Configuration of the TAXII server's internal clock synchronization

Why it fails: Clock synchronisation aligns timestamps for correlation; it does not map STIX indicator objects to incident workflows. TAXII servers require accurate time for ordering and expiry, so it is tempting when ingestion timing looks wrong, but the mandatory setting is the indicator-to-field mapping configuration.

Setting the API polling interval to 24 hours

Why it fails: Polling frequency governs how often indicators are fetched, not how they map to response workflows; a 24-hour interval also delays detection. Mapping requires configuring indicator-to-incident correlation rules or severity fields. Polling intervals are tuned for feed freshness and API rate limits instead.

Increase the retention period for all raw log data

Why it fails: Longer raw log retention only extends how far back analysts can search; it neither filters false positives nor raises the proportion of genuine signals. It is tempting because retained logs support investigation and compliance, so it would be correct when the gap is historical visibility or forensic evidence rather than alert volume.

Lower the threshold for all IDS alerts to catch more threats

Why it fails: Lowering thresholds flags more benign activity, increasing false positives and worsening the signal-to-noise ratio rather than improving it. It is tempting because it appears to reduce missed detections, and it would be correct when the priority is maximising threat coverage and analysts can absorb the extra volume.

Outsource all monitoring to a managed security provider

Why it fails: Outsourcing transfers who triages alerts but leaves the underlying detection rules and thresholds unchanged, so the ratio of true to false positives stays the same. It is tempting because it offloads analyst workload, and it would be correct when the organisation lacks in-house monitoring capacity rather than suffering noisy detections.

Disk forensic analysis of the user's browser history

Why it fails: Browser history records URLs visited, holding no PowerShell command text or script-block content at all. It tempts because disk forensics preserves artefacts an attacker cannot easily erase remotely, and would be the right source if the hypothesis concerned web-based drive-by compromise or phishing-site visits preceding execution.

Windows Security Log - Process Creation (Event ID 4688)

Why it fails: Event ID 4688 records process creation, capturing only the executable name and parent, not the PowerShell script block content or command arguments. It tempts because process creation auditing is the standard starting point for endpoint hunting, and would be correct if the hypothesis concerned which binaries executed rather than the commands themselves.

Network firewall traffic logs for port 5985

Why it fails: Firewall logs on port 5985 capture connection metadata for PowerShell Remoting, not the commands transmitted within the session. It tempts because WinRM traffic is a genuine lateral-movement indicator, and would be correct if the hypothesis concerned remote PowerShell connections between hosts rather than the commands executed on one.

mspaint.exe

Why it fails: mspaint.exe is a legitimate graphics editor with no command execution, credential access or network capability, so non-administrative use is unremarkable. Investigate utilities such as certutil, bitsadmin or rundll32, which perform download, encoding and proxy execution functions attackers abuse for living-off-the-land activity.

calc.exe

Why it fails: Calculator performs only local arithmetic and cannot execute scripts, spawn shells or contact remote hosts, so non-administrative use is not anomalous. It is tempting because it is a signed Microsoft binary that can occasionally host code-execution tricks, but that requires a crafted file, not mere launch by a standard user.

notepad.exe

Why it fails: Notepad is a plain text editor with no scripting, network or execution capability, so its use by a standard user reveals nothing about LotL tradecraft. It is tempting because attackers do abuse it for hiding payloads in text files, but that scenario concerns file content, not the utility itself warranting immediate investigation.

System clock synchronization logs

Why it fails: Clock synchronisation logs only show NTP offset and drift, revealing nothing about sessions, authentication or file shares. They matter when correlating event timestamps across hosts; RDP and SMB detection instead needs Security event logs and network flow or IDS telemetry.

Application logs for Microsoft Word

Why it fails: Microsoft Word application logs capture document events such as file opens and macro execution, not inbound RDP or SMB session establishment, so they cannot reveal lateral movement. They are tempting because macro and document telemetry does support phishing or malware investigation, which is where they would be the right source.

Browser cache logs

Why it fails: Browser cache logs record HTTP objects and cookies, containing no session, authentication or SMB/RDP connection metadata, so lateral movement over those protocols leaves no trace there. They are tempting because cached content can reveal user web activity, which suits web-usage auditing or forensic browsing-history review, not remote-access detection.

Store all raw intelligence feeds in an unindexed archive

Why it fails: Storing raw feeds unindexed prevents correlation, enrichment and alerting, so indicators never reach detection rules. It is tempting because immutable archives support forensic replay and compliance retention, where bulk storage without query performance is the goal. Actionable intelligence instead requires parsing, normalisation and indexing against log sources.

Increase the TTL for all IP-based indicators to 'infinite'

Why it fails: Extending TTL to infinite prevents automatic expiry of stale indicators, so compromised or reassigned IPs remain flagged indefinitely and generate false positives. It is tempting because longer retention suits stable, long-lived indicators such as malicious ASN ranges. For fast-changing IP-based threat data, finite TTLs with automated refresh are required instead.

Checking all outbound traffic against a whitelist of top 1000 websites

Why it fails: A top-1000 whitelist permits any destination on that list, so exfiltration to legitimate cloud or CDN services proceeds unchecked; low-and-slow volumes also stay under thresholds. It is tempting because allowlisting known-good destinations blocks malicious or unknown endpoints, making it correct when the risk is outbound connections to untrusted hosts.

Scanning all outgoing emails for keywords

Why it fails: Keyword scanning inspects email content only, so exfiltration over other channels (DNS, HTTPS uploads, cloud storage sync) passes unseen; low-and-slow transfers also avoid suspicious volumes. It is tempting because content inspection genuinely catches policy breaches and data leakage in email, making it the right control when email is the suspected exfiltration vector.

Blocking all encrypted traffic at the firewall

Why it fails: Blocking encrypted traffic removes visibility rather than detecting exfiltration, and low-and-slow transfers hide inside permitted cleartext or tunnelled channels anyway. It is tempting because denying encryption forces inspection of payloads, making it correct where policy forbids unapproved encryption and cleartext inspection is feasible.