If you have spent any time in a Security Operations Center, you know the feeling. Your console shows 47 alerts from the last shift. Twelve are benign positives. Twenty are low-fidelity noise from misconfigured correlation rules. But buried in that pile — maybe as a single medium-severity event — is the first thread of an intrusion that has already been unfolding for six days.
The uncomfortable truth that a recent analysis from The Hacker News drives home is this: the most critical phases of an attack rarely generate alerts at all. Initial access might trigger something. A payload drop might fire an EDR signature. But the hours and days between those moments — the reconnaissance, the lateral movement, the privilege escalation, the data staging, the command-and-control beaconing — happen in the spaces that most detection stacks simply do not cover.
This is not a theoretical problem. In my experience leading incident response engagements over the past 15 years, the single most common failure mode I see is not a missing tool. It is a missing connection between tools. The EDR saw something. The firewall logged something. The identity platform flagged something. But nobody — and no system — tied those observations together into a coherent timeline until we were already in crisis mode.
This post breaks down why network data is the connective tissue that modern SOCs are missing, how attackers exploit the gaps between siloed detection tools, and what your team can do right now to close those gaps.
Why Alert-Centric Detection Is Failing
The Fundamental Problem
Traditional SOC detection is built on a per-alert triage model. An alert fires. An analyst investigates it in isolation. They either escalate it or close it. This model has three structural weaknesses that attackers exploit systematically:
- Context blindness: A single SMB connection to a file server looks benign. A single Kerberos ticket request looks benign. A single DNS query to an unfamiliar domain looks benign. Only when you see them in sequence, from the same host, within a 20-minute window, does the attack pattern emerge.
- Coverage gaps: EDR agents are not deployed everywhere. Network segmentation creates blind spots. Cloud workloads, IoT devices, legacy systems, and contractor laptops often lack endpoint instrumentation entirely.
- Alert fatigue as a weapon: Sophisticated threat actors deliberately operate below detection thresholds. They use living-off-the-land techniques, low-and-slow exfiltration, and legitimate administrative tools specifically because these generate low-severity or no alerts.
What Network Data Sees That Endpoints Cannot
Network Detection and Response (NDR) platforms operate on a fundamentally different principle than EDR or SIEM-centric detection. Rather than waiting for a signature to match or a behavioral rule to fire, NDR passively observes all network traffic — east-west and north-south — and builds a continuous model of what normal looks like.
Here is what that means practically:
| Observable | EDR Visibility | NDR Visibility |
|---|---|---|
| Process execution on managed endpoint | Full | None (network side effects only) |
| Lateral SMB/RDP/WinRM between internal hosts | Limited (only if both endpoints have agents) | Full (all network flows) |
| DNS tunneling / C2 over DNS | Partial (depends on DNS logging config) | Full (queries, response sizes, entropy, frequency) |
| Data staging and exfiltration volume | Partial (file system access only) | Full (byte counts, destination, protocol anomalies) |
| Beaconing periodicity and jitter | None | Full (connection timing analysis) |
| Unmanaged device communication (IoT, OT, rogue) | None | Full (any device that touches the network) |
| Encrypted C2 traffic patterns | None (payload is encrypted) | Partial (TLS fingerprinting, JA3/JA3S, flow metadata) |
The critical insight is that every attacker action that crosses a network boundary leaves a network artifact. You cannot move laterally without generating network traffic. You cannot exfiltrate data without generating network traffic. You cannot maintain C2 without generating network traffic. The network is the one substrate that an attacker cannot avoid touching.
Technical Analysis: The Attack Lifecycle Through a Network Lens
Let me walk through a realistic intrusion scenario and show where network data fills the gaps that alert-centric detection leaves open.
Phase 1: Initial Access (Often Detected — But Not Understood)
An attacker gains initial access via a phishing email with a malicious attachment, or by exploiting an internet-facing vulnerability. Your EDR might fire an alert. Your email gateway might log the delivery. But this alert arrives without context. The analyst sees "suspicious PowerShell execution on WORKSTATION-47" and has no way to know whether this is the beginning of a targeted intrusion or a drive-by malware infection that was already contained.
What NDR adds: Within seconds of initial execution, the compromised host makes its first outbound connection. The NDR platform captures this connection — destination IP, domain, TLS certificate details, payload size, timing. If the destination is a known-bad IP, a recently registered domain, or exhibits JA3 fingerprints associated with Cobalt Strike, Sliver, or Mythic C2 frameworks, the NDR immediately escalates the severity and links it to the endpoint alert.
Phase 2: Discovery and Internal Reconnaissance (Almost Never Detected by EDR)
Once established, the attacker begins internal reconnaissance. In 2025 and 2026, we are seeing threat actors overwhelmingly favor techniques that blend into legitimate administrative traffic:
- LDAP queries against Active Directory to enumerate users, groups, computers, and trust relationships
- SMB share enumeration using native Windows APIs
- NetBIOS / mDNS / LLMNR broadcast queries to map the local subnet
- WMI queries to remote systems for hardware, software, and logged-on user inventory
- DNS zone transfers or aggressive internal DNS enumeration
From an EDR perspective, each of these looks like normal system behavior — nltest.exe, net.exe, netstat.exe, arp.exe, and ipconfig.exe are all legitimate Windows binaries. The EDR sees the process execution but cannot determine whether the purpose is malicious.
What NDR adds: The NDR platform sees the network side effects of this reconnaissance. A workstation that has never made LDAP queries to the domain controller suddenly sending 200+ queries in 60 seconds is anomalous. A workstation sweeping port 445 across 50 internal hosts in rapid succession is anomalous. These patterns are visible in network flow data regardless of whether the endpoints have agents installed.
Phase 3: Lateral Movement (The Critical Gap)
This is where most detection stacks fail hardest. Lateral movement techniques in active use right now include:
- Pass-the-Hash / Pass-the-Ticket over SMB (port 445) and Kerberos (port 88)
- PsExec-style service creation on remote hosts (SMB + ADMIN$ share + named pipes)
- WinRM / PSRemoting (ports 5985/5986)
- RDP (port 3389) with stolen credentials
- SSH (port 22) for Linux pivot points
- DCOM/WMI remote execution (port 135 + dynamic RPC ports)
The critical detection challenge is that all of these protocols are also used by legitimate administrators. The EDR on the target system sees a successful logon and a process execution — but if the attacker is using valid credentials (stolen via Mimikatz, Kerberoasting, or a previous phishing campaign), there is no failed logon, no brute-force pattern, and no signature to match.
What NDR adds: The NDR platform sees the network session from anomalous source hosts. If WORKSTATION-47 (a marketing laptop) initiates an SMB session to SERVER-DC01 (a domain controller) at 3:17 AM, and that laptop has never communicated with the domain controller over SMB before, the NDR flags it. If the session involves named pipe operations consistent with PsExec (\PIPE\svcctl, \PIPE\atsvc), the NDR can identify the specific lateral movement technique.
This is the detection layer that catches lateral movement between unmanaged devices — the contractor laptop without an EDR agent, the legacy Windows 2012 server that cannot run a modern agent, the IoT device that was compromised as a pivot point.
Phase 4: Command and Control (Persistent and Low-Profile)
Modern C2 frameworks are specifically designed to evade detection. Current techniques include:
- Domain fronting through CDN providers (Cloudflare, Azure CDN, Google Cloud CDN)
- C2 over legitimate cloud services (Microsoft Graph API, Slack webhooks, GitHub gists)
- DNS tunneling with low-and-slow query rates
- TLS-encrypted C2 with valid certificates (often Let's Encrypt) and JA3 fingerprints that mimic common browsers
- Long-haul beaconing with sleep intervals of hours or days between check-ins
What NDR adds: Network metadata analysis can identify beaconing patterns even when the payload is encrypted. Connection periodicity, consistent byte counts, JA3/JA3S fingerprint anomalies, and connections to destinations with no business justification are all detectable in network flow data. NDR platforms with TLS fingerprinting capabilities can differentiate between a Chrome browser making HTTPS connections and a Cobalt Strike beacon using a custom TLS stack.
Phase 5: Exfiltration (The Final Mile)
Data exfiltration is where the financial damage occurs. Techniques we are actively seeing in 2026 include:
- Cloud storage uploads (Mega, Google Drive, OneDrive, Dropbox) using attacker-controlled accounts
- DNS exfiltration with encoded data in subdomain queries
- ICMP tunneling for small, sensitive data (credentials, keys)
- HTTPS POST to attacker-controlled infrastructure disguised as web traffic
- Rclone or WinSCP to cloud or SFTP destinations
What NDR adds: The NDR platform sees the volume anomaly. A workstation that normally sends 50 MB per day outbound suddenly transferring 4.7 GB to an external destination over 90 minutes is detectable. The destination's threat intelligence profile, the protocol used, the time of day, and the data volume all contribute to a high-fidelity detection.
Detection & Response
This is a technique-focused threat — the detection gap itself is the vulnerability. The following detection content targets the lateral movement, C2, and reconnaissance behaviors that thrive in the spaces between alerts.
Sigma Rules
The following Sigma rules target specific behaviors that indicate an attacker operating in the detection gaps. These are designed to be high-fidelity with minimal false positives when properly tuned to your environment's baseline.
---
title: Anomalous Internal SMB Lateral Movement via PsExec Named Pipes
id: 3f8a2b41-7c1e-4d9a-b5f2-8e6a0c4d1f7b
status: experimental
description: Detects network connections to named pipes commonly used by PsExec and similar lateral movement tools over SMB. Focuses on workstation-to-server SMB connections that include remote service control pipe access, a hallmark of PsExec-style remote execution.
references:
- https://attack.mitre.org/techniques/T1021/002/
- https://attack.mitre.org/techniques/T1569/002/
author: Security Arsenal
date: 2026/02/14
tags:
- attack.lateral_movement
- attack.t1021.002
- attack.t1569.002
logsource:
category: network_connection
product: windows
detection:
selection:
DestinationPort: 445
Image|endswith:
- '\PSEXESVC.exe'
- '\PAExec.exe'
- '\RemComSvc.exe'
- '\csexecsvc.exe'
filter_known_admin:
SourceIp:
- '10.0.0.0/8' # Adjust to known admin jump hosts
condition: selection and not filter_known_admin
falsepositives:
- Legitimate systems administration using PsExec from designated jump boxes
- SCCM/MECM remote operations
level: high
---
title: DNS Beaconing with Periodic Low-Frequency Queries
id: 9c4d7e12-3a5b-4f8c-a1d6-2b7e9f0c3a5d
status: experimental
description: Detects potential DNS-based C2 beaconing by identifying hosts making repeated DNS queries to uncommon external domains at regular intervals. DNS tunneling and DNS-based C2 are increasingly used to bypass perimeter controls.
references:
- https://attack.mitre.org/techniques/T1071/004/
- https://attack.mitre.org/techniques/T1572/
author: Security Arsenal
date: 2026/02/14
tags:
- attack.command_and_control
- attack.t1071.004
- attack.t1572
logsource:
category: dns
detection:
selection:
query|contains:
- '.tk'
- '.ml'
- '.ga'
- '.cf'
- '.gq'
answer_count: 0
filter_internal:
query|endswith:
- '.local'
- '.internal'
- '.corp'
- '.lan'
condition: selection and not filter_internal
falsepositives:
- Misconfigured applications querying non-existent domains
- Security tools performing DNS-based threat intelligence lookups
level: medium
---
title: Internal Network Sweep from Non-Server Host
id: 5e1f8a63-2d4b-4c7e-9a3f-6b0d8e2c5a1f
status: experimental
description: Detects internal network reconnaissance by identifying hosts initiating connections to SMB or RDP ports across multiple internal destinations in a short time window. This pattern is characteristic of automated discovery tools or manual attacker enumeration.
references:
- https://attack.mitre.org/techniques/T1046/
- https://attack.mitre.org/techniques/T1135/
author: Security Arsenal
date: 2026/02/14
tags:
- attack.discovery
- attack.t1046
- attack.t1135
logsource:
category: network_connection
product: windows
detection:
selection:
DestinationPort:
- 445
- 3389
- 5985
- 5986
- 135
DestinationIp|cidr:
- '10.0.0.0/8'
- '172.16.0.0/12'
- '192.168.0.0/16'
condition: selection
falsepositives:
- Vulnerability scanners and asset management tools
- SCCM/Intune discovery operations
- Legitimate administrative tools
level: medium
KQL Hunt Queries
The following queries are designed for Microsoft Sentinel or Defender for Endpoint hunting. They assume network data is being ingested via an NDR platform, firewall logs (CommonSecurityLog/CEF), or Defender for Endpoint network events.
// Hunt 1: Identify hosts with anomalous outbound data transfer volumes
// Looks for workstations sending significantly more data than their 30-day baseline
// Useful for catching exfiltration that evades content-based detection
let baseline = DeviceNetworkEvents
| where TimeGenerated > ago(30d) and TimeGenerated < ago(1d)
| where RemoteIPType == "Public"
| summarize AvgDailyBytes = avg(BytesSent) by DeviceName;
DeviceNetworkEvents
| where TimeGenerated > ago(1d)
| where RemoteIPType == "Public"
| summarize TotalBytesSent = sum(BytesSent), UniqueDestinations = dcount(RemoteIP), DestinationList = make_set(RemoteIP, 20) by DeviceName, TimeGenerated
| join kind=inner baseline on DeviceName
| where TotalBytesSent > (AvgDailyBytes * 5) and TotalBytesSent > 1073741824 // >1GB and >5x baseline
| project DeviceName, TotalBytesSent, AvgDailyBytes, UniqueDestinations, DestinationList
| sort by TotalBytesSent desc;
// Hunt 2: Detect potential lateral movement via SMB from unusual source hosts
// Identifies workstation-to-server SMB connections from hosts with no prior SMB history to that destination
let known_smb_pairs = DeviceNetworkEvents
| where TimeGenerated > ago(30d) and TimeGenerated < ago(1d)
| where RemotePort == 445
| where RemoteIPType == "Private"
| summarize by DeviceName, RemoteIP;
DeviceNetworkEvents
| where TimeGenerated > ago(24h)
| where RemotePort == 445
| where RemoteIPType == "Private"
| where DeviceName !startswith "SRV" // Exclude servers (adjust naming convention)
| where DeviceName !startswith "DC"
| join kind=leftanti known_smb_pairs on DeviceName, RemoteIP
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), ConnectionCount = count(), InitiatingProcesses = make_set(InitiatingProcessFileName, 10) by DeviceName, RemoteIP, RemotePort
| sort by ConnectionCount desc;
// Hunt 3: Detect DNS-based C2 via query length and frequency anomalies
// Long DNS query names with high frequency can indicate DNS tunneling
Syslog
| where TimeGenerated > ago(24h)
| where SyslogMessage has "query"
| extend QueryName = extract(@"query:\s(\S+)", 1, SyslogMessage)
| where isnotempty(QueryName)
| extend QueryLength = strlen(QueryName)
| where QueryLength > 100 // Abnormally long DNS query names
| summarize QueryCount = count(), UniqueQueries = dcount(QueryName), SampleQueries = make_set(QueryName, 5) by Computer, QueryName
| where QueryCount > 50
| sort by QueryCount desc;
Velociraptor VQL
The following VQL artifacts are designed for endpoint hunting with Velociraptor. They target the forensic artifacts left by lateral movement and C2 activity.
-- Hunt 1: Identify suspicious network connections from non-standard processes
-- Focuses on processes making outbound connections that are not browsers or known applications
SELECT Pid,
Name,
Exe,
CommandLine,
Username,
netstat().RemoteAddress AS RemoteAddress,
netstat().RemotePort AS RemotePort,
netstat().Status AS ConnectionStatus,
CreateTime
FROM pslist()
WHERE netstat().RemotePort IN (443, 8443, 8080, 4444, 5555, 1337)
AND netstat().Status =~ 'ESTABLISHED'
AND Name NOT IN ('chrome.exe', 'firefox.exe', 'msedge.exe', 'iexplore.exe',
'svchost.exe', 'System', 'MsMpEng.exe', 'Teams.exe',
'OneDrive.exe', 'outlook.exe', 'winword.exe', 'excel.exe')
AND Exe !~ 'Program Files\\\\(Google|Microsoft|Mozilla)'
ORDER BY CreateTime DESC
-- Hunt 2: Search for recently created services with suspicious binary paths
-- PsExec and similar tools create temporary services on target systems
SELECT Name,
DisplayName,
PathName,
ServiceType,
StartType,
Status,
Description
FROM wmi_query(namespace='root/cimv2',
query='SELECT Name, DisplayName, PathName, ServiceType, StartType, Status, Description FROM Win32_Service')
WHERE PathName =~ '(?i)(\\\\ADMIN\$|\\\\C\$|\\\\IPC\$|Temp|Tmp|AppData\\\\Local\\\\Temp|PSEXESVC|PAExec|RemCom)'
OR Name =~ '(?i)(PSEXESVC|PAExec|RemComSvc|csexecsvc)'
ORDER BY Name
-- Hunt 3: Enumerate active RDP sessions and recent RDP logons
-- Identifies lateral movement via RDP to hosts that should not have interactive sessions
SELECT Pid,
Name,
Exe,
Username,
CommandLine,
netstat().LocalPort AS LocalPort,
netstat().RemoteAddress AS RemoteAddress,
netstat().Status AS Status
FROM pslist()
WHERE netstat().LocalPort = 3389
AND netstat().Status =~ 'ESTABLISHED'
AND netstat().RemoteAddress !~ '^(10\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.|192\\.168\\.)'
ORDER BY netstat().RemoteAddress
Remediation and Hardening Script
The following PowerShell script audits and hardens a Windows environment against the lateral movement techniques described above. It checks for common misconfigurations, enables critical logging, and applies network-level restrictions.
#Requires -RunAsAdministrator
# Security Arsenal - Lateral Movement Detection & Hardening Script
# Targets the network-level gaps that attackers exploit between alert-based detections
# Run on Domain Controllers and critical servers. Test in a lab environment first.
$reportPath = "C:\SecurityAudit_$(Get-Date -Format 'yyyyMMdd_HHmmss').txt"
"=== Security Arsenal Lateral Movement Hardening Report ===" | Out-File $reportPath
"Generated: $(Get-Date)" | Out-File $reportPath -Append
"Hostname: $env:COMPUTERNAME" | Out-File $reportPath -Append
"" | Out-File $reportPath -Append
# --- 1. Enable Advanced Audit Policies for Network-Based Detection ---
"[*] Configuring advanced audit policies..." | Out-File $reportPath -Append
$auditPolicies = @(
@{Category="Account Logon"; Subcategory="Kerberos Authentication Service"; Setting="Success and Failure"},
@{Category="Account Logon"; Subcategory="Kerberos Service Ticket Operations"; Setting="Success and Failure"},
@{Category="Logon/Logoff"; Subcategory="Logon"; Setting="Success and Failure"},
@{Category="Logon/Logoff"; Subcategory="Special Logon"; Setting="Success"},
@{Category="Detailed Tracking"; Subcategory="Process Creation"; Setting="Success"},
@{Category="Object Access"; Subcategory="File Share"; Setting="Success and Failure"},
@{Category="Object Access"; Subcategory="Detailed File Share"; Setting="Success and Failure"},
@{Category="Policy Change"; Subcategory="Authentication Policy Change"; Setting="Success"},
@{Category="Account Management"; Subcategory="Security Group Management"; Setting="Success and Failure"}
)
foreach ($policy in $auditPolicies) {
$result = auditpol /set /subcategory:"$($policy.Subcategory)" /success:enable /failure:enable 2>&1
" $($policy.Subcategory): $result" | Out-File $reportPath -Append
}
# --- 2. Enable PowerShell Script Block and Module Logging ---
"`n[*] Enabling PowerShell logging..." | Out-File $reportPath -Append
$psLoggingPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"
if (-not (Test-Path $psLoggingPath)) { New-Item -Path $psLoggingPath -Force | Out-Null }
Set-ItemProperty -Path $psLoggingPath -Name "EnableScriptBlockLogging" -Value 1
" Script Block Logging: ENABLED" | Out-File $reportPath -Append
$psModulePath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging"
if (-not (Test-Path $psModulePath)) { New-Item -Path $psModulePath -Force | Out-Null }
Set-ItemProperty -Path $psModulePath -Name "EnableModuleLogging" -Value 1
" Module Logging: ENABLED" | Out-File $reportPath -Append
# --- 3. Check SMBv1 Status (Should Be Disabled) ---
"`n[*] Checking SMB protocol versions..." | Out-File $reportPath -Append
$smbv1 = Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol
if ($smbv1.EnableSMB1Protocol) {
" [WARNING] SMBv1 is ENABLED. Disabling now..." | Out-File $reportPath -Append
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force
" SMBv1: DISABLED" | Out-File $reportPath -Append
} else {
" SMBv1: Already disabled (GOOD)" | Out-File $reportPath -Append
}
# --- 4. Enable SMB Signing (Prevents SMB Relay Attacks) ---
"`n[*] Checking SMB signing..." | Out-File $reportPath -Append
$smbSigning = Get-SmbServerConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature
if (-not $smbSigning.RequireSecuritySignature) {
" [WARNING] SMB signing not required. Enabling..." | Out-File $reportPath -Append
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force
" SMB Signing: REQUIRED" | Out-File $reportPath -Append
} else {
" SMB Signing: Already required (GOOD)" | Out-File $reportPath -Append
}
# --- 5. Check for Restricted Admin Mode (RDP Pass-the-Hash Mitigation) ---
"`n[*] Checking Restricted Admin Mode for RDP..." | Out-File $reportPath -Append
$rdpPath = "HKLM:\System\CurrentControlSet\Control\Lsa"
$restrictedAdmin = Get-ItemProperty -Path $rdpPath -Name "DisableRestrictedAdmin" -ErrorAction SilentlyContinue
if ($restrictedAdmin.DisableRestrictedAdmin -eq 1) {
" [WARNING] Restricted Admin Mode is DISABLED. Enabling..." | Out-File $reportPath -Append
Set-ItemProperty -Path $rdpPath -Name "DisableRestrictedAdmin" -Value 0
" Restricted Admin Mode: ENABLED" | Out-File $reportPath -Append
} else {
" Restricted Admin Mode: Enabled or not explicitly disabled (GOOD)" | Out-File $reportPath -Append
}
# --- 6. Check Windows Firewall Status for Key Ports ---
"`n[*] Checking Windows Firewall status..." | Out-File $reportPath -Append
$firewallProfiles = Get-NetFirewallProfile
foreach ($profile in $firewallProfiles) {
$status = if ($profile.Enabled) { "ENABLED" } else { "DISABLED [WARNING]" }
" $($profile.Name): $status" | Out-File $reportPath -Append
}
# --- 7. Check WinRM Configuration ---
"`n[*] Checking WinRM configuration..." | Out-File $reportPath -Append
$winrmService = Get-Service -Name WinRM -ErrorAction SilentlyContinue
if ($winrmService.Status -eq 'Running') {
" WinRM is RUNNING. Checking listener configuration..." | Out-File $reportPath -Append
$listeners = winrm enumerate winrm/config/listener 2>&1
" $listeners" | Out-File $reportPath -Append
" [RECOMMENDATION] If WinRM is not required for remote management, disable it: Disable-PSRemoting -Force" | Out-File $reportPath -Append
} else {
" WinRM: Not running (GOOD if not needed)" | Out-File $reportPath -Append
}
# --- 8. Check Local Administrator Password Solution (LAPS) ---
"`n[*] Checking LAPS deployment status..." | Out-File $reportPath -Append
$lapsKey = Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\LAPS" -ErrorAction SilentlyContinue
if ($lapsKey) {
" LAPS: Configured (GOOD)" | Out-File $reportPath -Append
} else {
" [WARNING] LAPS not detected. Deploy Windows LAPS to prevent lateral movement via shared local admin passwords." | Out-File $reportPath -Append
" Reference: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview" | Out-File $reportPath -Append
}
# --- 9. List Recent SMB Sessions ---
"`n[*] Current active SMB sessions:" | Out-File $reportPath -Append
Get-SmbSession | Format-Table ClientComputerName, ClientUserName, NumOpens, SessionId -AutoSize | Out-String | Out-File $reportPath -Append
# --- 10. List Currently Listening Network Services ---
"`n[*] Listening network services:" | Out-File $reportPath -Append
Get-NetTCPConnection -State Listen | Where-Object { $_.LocalPort -notin @(0) } |
Select-Object LocalAddress, LocalPort, OwningProcess, @{Name="ProcessName";Expression={(Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName}} |
Sort-Object LocalPort | Format-Table -AutoSize | Out-String | Out-File $reportPath -Append
"`n=== Report Complete ===" | Out-File $reportPath -Append
"Report saved to: $reportPath"
Write-Host "Audit complete. Report saved to: $reportPath" -ForegroundColor Green
Remediation: Closing the Gaps
There is no single patch for this problem because the vulnerability is architectural, not a specific software bug. However, there are concrete steps every organization should take immediately:
1. Deploy or Optimize NDR Coverage
If you do not have an NDR platform, this should be a top priority for 2026. If you have one, audit its coverage:
- East-west traffic visibility: Ensure your NDR is monitoring internal network segments, not just north-south perimeter traffic. SPAN ports, TAPs, or virtual network sensors should cover server-to-server and workstation-to-server traffic.
- Encrypted traffic analysis: Enable TLS fingerprinting (JA3/JA3S) and flow metadata analysis. You do not need to decrypt traffic to detect C2 patterns.
- Integration with SIEM/SOAR: Ensure NDR alerts are flowing into your SIEM with proper severity mapping and that correlation rules exist to link NDR observations with EDR and identity alerts.
2. Build Cross-Tool Correlation Rules
Your SIEM should be correlating across data sources, not just aggregating alerts. Build correlation rules that link:
- EDR process execution alerts with NDR network connection alerts from the same host within the same time window
- Identity authentication events (Kerberos ticket requests, NTLM authentications) with NDR lateral movement detections
- DNS query anomalies with outbound connection alerts to the same destination
3. Implement Network Segmentation
Lateral movement succeeds because networks are flat. Implement segmentation that restricts workstation-to-workstation communication and enforces least-privilege network access:
- Workstations should not be able to initiate SMB connections to other workstations
- Only designated jump hosts should be able to RDP or WinRM to servers
- IoT and OT devices should be on isolated VLANs with strict egress filtering
4. Deploy Deception Technology
Honeypots and honey credentials are high-fidelity detection mechanisms that generate zero false positives. Deploy:
- Honey credentials: Fake credentials in memory, registry, or files that trigger alerts when used
- Honey shares: SMB shares that no legitimate user should access
- Honey hosts: Systems that appear on the network but have no legitimate purpose — any connection to them is suspicious by definition
5. Establish a Baseline and Hunt for Anomalies
Use the KQL and VQL queries in this post to establish baselines for your environment:
- What does normal SMB traffic look like between workstations and servers?
- What is the average daily outbound data volume per workstation?
- Which hosts normally communicate with the domain controller over LDAP, Kerberos, and SMB?
Once you have baselines, deviations become detectable.
6. Review Your Detection Coverage Against MITRE ATT&CK
Map your current detection capabilities against the MITRE ATT&CK framework. Specifically, identify techniques where you have zero detection coverage. These are your blind spots. The techniques most commonly missed by EDR-only organizations include:
- T1021 (Remote Services) — lateral movement via SMB, RDP, WinRM, SSH
- T1071.004 (DNS C2)
- T1046 (Network Service Discovery)
- T1135 (Network Share Discovery)
- T1041 (Exfiltration Over C2 Channel)
- T1048 (Exfiltration Over Alternative Protocol)
Final Thoughts
The attackers are not beating your EDR with zero-days. They are walking through the gaps between your tools — the spaces where no single alert tells the full story. Network data is the connective tissue that turns isolated observations into a coherent narrative of an intrusion.
If your SOC is still triaging alerts one at a time, you are fighting with one hand tied behind your back. Invest in the platforms, the correlation logic, and the analytical skills that let you see the whole attack, not just the pieces that happen to trigger a signature.
The spaces between alerts are where breaches happen. Close them.
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.