From Packet to Pivot: A Practical Deep Dive into Modern NDR Systems

In the high-stakes environment of a Dallas Security Operations Center (SOC), visibility is everything. For years, security teams have relied on perimeter defenses and endpoint detection. However, as attackers become more adept at living off the land and using encrypted channels to bypass traditional controls, the network layer has emerged as the final source of truth.

Recently, the concept of "Network Detection and Response" (NDR) has moved from a buzzword to a operational necessity. But how does an NDR system actually fit into the daily grind of an analyst? To understand this, we took a hands-on look at the workflow of modern network threat hunting, simulating the experience of utilizing an Open NDR platform to bridge the gap between raw packets and actionable intelligence.

The Evolution of Network Visibility

Traditionally, network monitoring was limited to NetFlow data or simple IDS alerts that told you something happened, but rarely what or why. The modern NDR approach—exemplified by platforms leveraging deep packet inspection and frameworks like Zeek—changes the game.

Instead of just blocking IPs, these systems transform network traffic into structured logs. This allows analysts to treat network data like a database, querying for specific behaviors, tactics, techniques, and procedures (TTPs) rather than just known signatures.

For a SOC analyst, this shift is profound. It moves the workflow from reactive alert triage to proactive hypothesis testing. The objective is no longer just to "find the bad IP," but to answer the question: "Has an adversary established a foothold in this environment, and what are they doing?"

Analysis: Beyond the Headlines

The core value proposition of NDR lies in its ability to provide "Evidence of Attack." When an endpoint detection (EDR) tool flags a suspicious process, the network data provides the corroboration.

Key Capabilities in NDR Workflow

1. Retrospective Analysis: Unlike firewalls that may drop packets and forget them, NDR systems retain session metadata. This allows hunters to go back in time—days or weeks—to reconstruct the kill chain of a compromise that just became visible today.

2. Encrypted Traffic Analysis: With the vast majority of web traffic now encrypted (HTTPS/TLS), traditional packet inspection is often blind. Modern NDR platforms analyze TLS handshakes to extract metadata such as JA3 hashes (fingerprinting the client) and certificate details, allowing analysts to identify malicious C2 channels even without decrypting the payload.

3. Lateral Movement Detection: Attackers rarely jump straight to the crown jewels; they move laterally. NDR systems excel at identifying internal network scans, SMB/Windows Management Instrumentation (WMI) connections, and unusual data transfers between workstations.

Detection and Threat Hunting

To illustrate the power of NDR in a SOC environment, let's look at some practical queries and scripts. In a real-world scenario utilizing Zeek logs or an Open NDR platform, an analyst might hunt for long-lived connections indicative of Command and Control (C2) beacons.

Hunting with KQL (Sentinel/Defender)

If your NDR data is ingested into Microsoft Sentinel, you can use KQL to hunt for connections that have lasted longer than a typical user session, which is often a strong indicator of backdoors or persistent tunnels.

DeviceNetworkEvents
| where ActionType == "ConnectionAccepted"
| extend Duration = TimeGenerated - bin(TimeGenerated, 1h) // Simplified duration logic for demonstration
| summarize TotalBytes = sum(SentBytes + ReceivedBytes), ConnectionCount = count(), StartTime = min(TimeGenerated), EndTime = max(TimeGenerated) by SrcIpAddr, DstIpAddress, DstPort
| extend SessionLength = EndTime - StartTime
| where SessionLength > 1h // Sessions longer than 1 hour
| project SrcIpAddr, DstIpAddress, DstPort, TotalBytes, ConnectionCount, SessionLength
| order by SessionLength desc

Analyzing Zeek Logs with Python

Many Open NDR platforms output Zeek-style logs. SOC analysts often use Python to parse these logs to find anomalies that automated rules might miss. Below is a script that scans a connection log (conn.log) for potential data exfiltration based on byte ratios.

import pandas as pd

# Load Zeek conn.log (TSV format with a header)
# Assuming standard Zeek columns: ts, uid, id.orig_h, id.orig_p, id.resp_h, id.resp_p, proto, service, duration, orig_bytes, resp_bytes, conn_state, local_orig, local_resp, missed_bytes, history, orig_pkts, orig_ip_bytes, resp_pkts, resp_ip_bytes, tunnel_parents

def analyze_data_exfiltration(file_path):
    try:
        cols = ['ts', 'uid', 'id.orig_h', 'id.orig_p', 'id.resp_h', 'id.resp_p', 
                'proto', 'service', 'duration', 'orig_bytes', 'resp_bytes', 'conn_state']
        df = pd.read_csv(file_path, sep='\t', comment='#', header=None, names=cols)
        
        # Clean data: replace '-' with 0 for numeric columns
        df['orig_bytes'] = pd.to_numeric(df['orig_bytes'], errors='coerce').fillna(0)
        df['resp_bytes'] = pd.to_numeric(df['resp_bytes'], errors='coerce').fillna(0)
        
        # Filter for internal to external connections (Potential Exfil)
        # Logic: High outbound bytes, low inbound bytes (ratio check)
        df['ratio'] = df.apply(lambda row: row['orig_bytes'] / (row['resp_bytes'] + 1), axis=1)
        
        # Flag potential exfil: More than 10MB sent and ratio > 10 (sending much more than receiving)
        potential_exfil = df[(df['orig_bytes'] > 10000000) & (df['ratio'] > 10)]
        
        return potential_exfil[['id.orig_h', 'id.resp_h', 'id.resp_p', 'orig_bytes', 'resp_bytes', 'proto']]

    except Exception as e:
        print(f"Error processing log file: {e}")
        return pd.DataFrame()

# Example usage:
# results = analyze_data_exfiltration('conn.log')
# print(results)

Capturing Traffic with Bash

While NDR provides the dashboard, the underlying engine relies on packet captures. Analysts often need to run a manual capture to feed into the analysis engine.

# Capture traffic on eth0, filtering for a specific suspect subnet, writing to pcap
# We exclude SSH to reduce noise from the analyst's own connection
tcpdump -i eth0 -netw 192.168.1.0/24 -w investigation.pcap not port 22

Mitigation and Strategic Takeaways

Implementing an NDR solution is not just a technical upgrade; it is an operational shift. To maximize the effectiveness of NDR in your organization:

1. Baseline Normal Behavior: NDR is most effective when it knows what "normal" looks like. Spend the first 30 days of deployment establishing baselines for protocol usage, volume, and regular connection destinations.

2. Integrate with EDR: NDR should not be a silo. Ensure your NDR platform integrates via API with your Endpoint Detection and Response tools. When NDR sees a suspicious network connection, EDR should be checking the originating process immediately.

3. Train for Hypothesis-Based Hunting: Move your SOC team beyond simply "clearing alerts." Train them to formulate hypotheses (e.g., "Is there a DNS tunnel in our environment?") and use the NDR query interface to prove or disprove them.

The experience of getting hands-on with an NDR system reveals that the future of the SOC is not just about collecting more data, but about making that data queryable, understandable, and actionable. It transforms the network from a chaotic stream of packets into a structured narrative of security events.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub