Network traffic analysis for military networks: baselining, anomaly detection, and lateral movement

An adversary who has gained initial access to a military network does not announce their presence with loud, signature-matched malware. They move slowly, using protocols that are already present, credentials that are already valid, and communication paths that already exist. Network traffic analysis (NTA) is the discipline of making that movement visible: by understanding what normal traffic looks like on a specific classified network and building detection logic around deviations from that norm, NTA tools surface the behavioral indicators that signature-based intrusion detection systems miss. This article covers the technical methods for establishing baselines, detecting protocol anomalies, identifying lateral movement patterns, and integrating NTA output into a SIEM in a way that produces actionable alerts rather than noise.

Why military network traffic presents unique analysis challenges

Military networks differ from enterprise environments in ways that directly affect how NTA tools must be configured and tuned. The most significant structural difference is classification-boundary segmentation: traffic between enclaves at different classification levels is tightly constrained by policy, and any flow crossing a boundary that was not explicitly permitted is an immediate high-confidence anomaly. This predictability is an analytical asset that enterprise NTA tools are not built to exploit. A tool designed for a commercial network where any user can reach any SaaS endpoint will generate far more baseline variation than one deployed in an enclave where 90% of legitimate traffic flows between a small set of application servers and client workstations on defined ports.

The protocol population on military networks adds another layer of complexity. Legacy command and control applications, STANAG messaging systems, secure voice gateways, and specialized sensor integration middleware coexist with standard Windows domain protocols. An NTA sensor that decodes only common enterprise protocols will classify a substantial fraction of military application traffic as unknown UDP or TCP flows, degrading its ability to detect anomalies within those protocol families. Effective NTA deployment on military networks requires either custom protocol decoders or close integration with application owners to map which ports and flow characteristics correspond to legitimate application behavior.

Operational tempo variation creates baselining challenges that static threshold systems cannot accommodate. A training exercise saturates the network with simulation traffic. A deployment rotation temporarily changes the user population and application mix. An NTA system that locks in a baseline during a quiet garrison period will generate excessive false positives during high-tempo operations if it cannot adapt its statistical model to the current operational context. Streaming baseline models that update continuously with configurable inertia parameters are more appropriate for military environments than fixed-reference-period approaches.

Establishing traffic baselines: what normal looks like in a classified network

A traffic baseline is not a single number. It is a multi-dimensional statistical model that captures the typical distribution of protocols, flow volumes, connection rates, byte counts per session, and communication pair relationships across the network at different times of day, days of week, and operational phases. Building a meaningful baseline requires collecting flow telemetry or full-packet data continuously for a period long enough to capture the full variation of legitimate network activity -- typically four to eight weeks on a military enclave. During this period, the NTA system builds per-host, per-enclave, and per-protocol profiles that form the reference distribution against which future observations are compared.

The most analytically useful dimension of a military network baseline is the communication graph: which hosts talk to which other hosts, using which protocols, at what average byte volumes and connection rates. On a well-segmented military enclave, the communication graph is sparse. Most workstations communicate with a small number of infrastructure services (domain controllers, DNS resolvers, application servers, file servers) and rarely with each other. A new edge in this graph -- a workstation that has never communicated with a particular server suddenly opening a connection to it -- is statistically significant in a way it would not be on a flat enterprise network where lateral communication is routine. NTA tools that model the communication graph explicitly, rather than just volumetric thresholds, provide substantially better lateral movement detection sensitivity on classified enclaves.

Baseline quality depends critically on the completeness of tap coverage during the collection period. A baseline built from perimeter traffic only will be blind to east-west flows that never cross the perimeter sensor. A baseline built from a SPAN port that drops packets under load will undercount high-volume protocols, causing the statistical model to treat those protocol rates as anomalously high during normal operations. Before committing to a baseline period, verify tap coverage against the network topology diagram and confirm that the sensor is receiving lossless traffic at the expected volumes. Gaps discovered after the baseline period require re-baselining from that tap point rather than patching the model with estimates.

Protocol analysis: detecting unauthorized or anomalous protocol usage

Protocol-level anomaly detection operates on a simpler logic than behavioral baselining: if a protocol is not supposed to be present on a given network segment, any instance of it is an alert. The challenge is defining the allowed-protocol matrix with sufficient granularity to be operationally meaningful. A rule that blocks all non-Windows-domain protocols on a workstation VLAN will catch SSH, Telnet, and IRC used as covert channels, but it will also alert on every legitimate application that uses non-standard ports unless those applications are enumerated and their flows whitelisted by port and destination IP. The allowed-protocol matrix is a living document that must be maintained as applications change, and NTA tools that can automatically detect when a new protocol appears in a segment and propose a whitelist update reduce the administrative burden of keeping the matrix current.

Protocol tunneling -- encapsulating one protocol inside another to bypass inspection -- is a persistent technique on military networks precisely because the outer protocol is often permitted. DNS tunneling encodes arbitrary data in DNS query and response records, exploiting the fact that DNS traffic is rarely blocked at military perimeters. HTTP/HTTPS tunneling carries non-HTTP control traffic inside HTTP sessions to egress through web proxies. ICMP tunneling encodes data in the payload field of ICMP echo packets. NTA detection of tunneling relies on protocol behavior signatures rather than port-based rules: a DNS flow with unusually long query names, high query rates from a single host, and responses carrying large TXT or AAAA records is characteristic of DNS tunneling regardless of whether it uses port 53. Tools that perform deep packet inspection on allowed protocols to verify that the traffic conforms to the expected protocol grammar are significantly more effective than tools that trust port numbers as protocol identifiers.

Covert channel detection extends beyond known tunneling techniques to statistical analysis of protocol field entropy and timing patterns. A covert channel that encodes data in the low-order bits of TCP sequence numbers or in the padding fields of IP headers will not produce unusual protocol grammar violations, but it will produce statistical anomalies: sequence number distributions that are not random, padding field values that correlate across connections, or inter-packet timing that matches a known encoding scheme. These detections require purpose-built statistical analysis modules rather than generic anomaly detection and are most practical when applied to high-value network segments rather than full network coverage.

Lateral movement detection: SMB, WMI, and Kerberos abuse indicators

Lateral movement on Windows-based military networks follows predictable protocol paths because the Windows ecosystem offers a limited set of built-in remote execution mechanisms. SMB (Server Message Block, port 445) is the most frequently abused because it supports not only file sharing but also named pipe communication used by DCOM, service creation through the Service Control Manager, and scheduled task manipulation -- all of which allow an adversary to execute code on a remote host using only valid credentials and network access. NTA-level SMB detection focuses on the communication graph: peer-to-peer SMB connections between workstations that have no baseline history of such communication, connections to administrative shares (C$, ADMIN$) from hosts that do not normally access those shares, and SMB relay patterns where a host receives an incoming SMB connection and immediately initiates outbound SMB to a third host, characteristic of NTLM relay attacks.

WMI (Windows Management Instrumentation) lateral movement is harder to detect from network traffic alone because the initial DCOM connection on port 135 is followed by a dynamically negotiated high port that carries the actual WMI payload. NTA tools must correlate the port 135 connection with the subsequent dynamic-port connection from the same source to recognize the complete WMI session and classify it as a remote WMI execution event. The key behavioral indicator is timing: legitimate WMI activity from management platforms occurs on predictable schedules with stable source-destination pairs. Spontaneous WMI connections from workstations to servers at irregular times, or WMI connections from hosts that have no baseline record of initiating WMI sessions, are high-confidence lateral movement indicators that NTA tools should surface without requiring full payload decryption.

Kerberos abuse indicators are visible in authentication traffic even when the actual lateral movement payload is encrypted. Kerberoasting -- the technique of requesting service tickets for all enumerable service principal names (SPNs) to crack offline -- produces a burst of TGS-REQ messages from a single workstation, requesting tickets for a large number of SPNs in a short window. This pattern is statistically distinguishable from legitimate Kerberos activity, where a workstation requests tickets for the specific services it actually needs. Pass-the-ticket and overpass-the-hash attacks produce Kerberos AS-REQ messages that use unusual encryption types or originate from hosts that have no baseline history of authenticating to the targeted service. Baselining per-host Kerberos request volumes and SPN request diversity provides the reference distribution against which these attack patterns become statistically visible.

Encrypted traffic analysis: extracting indicators without decryption

The proportion of military network traffic that is encrypted has grown substantially as TLS 1.3 becomes the standard for application-layer protocols and as legacy clear-text protocols are replaced with encrypted alternatives. This creates a detection gap for NTA tools that rely on payload inspection: the content of an encrypted session is inaccessible without a decryption capability. Encrypted traffic analysis (ETA) addresses this gap by extracting metadata features from the TLS handshake and the behavioral characteristics of the session that remain visible even when the payload is encrypted. The TLS client hello message, sent in clear text before the encryption keys are established, contains the TLS version, cipher suite list, supported extensions, and -- until TLS 1.3 encrypted SNI -- the server name indication. JA3 fingerprinting reduces this handshake data to a compact hash that characterizes the TLS client implementation, making it possible to identify specific malware families or C2 frameworks by their characteristic TLS negotiation behavior without inspecting any encrypted payload.

Beyond the handshake, behavioral features of encrypted sessions carry classification signal. Packet length distributions differ between interactive human sessions (variable, bursty) and automated beacon traffic (regular intervals, consistent packet sizes). Inter-arrival timing of encrypted packets reveals the underlying communication pattern: a Cobalt Strike beacon with a 60-second sleep interval produces a recognizable inter-arrival distribution even through TLS. Session byte counts and flow duration separate bulk data transfers from control channel keepalives. NTA tools that combine JA3 fingerprints with flow behavioral features can classify encrypted sessions with accuracy comparable to payload-based classification for known malware families, while also detecting unknown threats whose behavioral fingerprint deviates from any established baseline.

The practical limitation of ETA on military networks is the diversity of legitimate encrypted traffic. A classified enclave may run dozens of applications, each with distinct TLS implementation characteristics, producing a complex baseline of legitimate JA3 fingerprints and session behavior profiles. Maintaining an accurate allow-list of legitimate TLS fingerprints requires active management as applications update their TLS libraries. The most operationally practical approach is to baseline the JA3 fingerprint distribution per enclave and per destination IP range, alerting on fingerprints that appear for the first time rather than maintaining a manually curated whitelist. New fingerprints are reviewed against a known-good reference database and classified as legitimate, suspicious, or malicious based on their provenance.

Alert correlation with SIEM: reducing noise while preserving detection fidelity

The most common failure mode of NTA deployment in military environments is not insufficient detection sensitivity -- it is alert overload. An NTA sensor that monitors a busy classified network may generate thousands of low-confidence anomaly alerts per day, most of which are false positives from legitimate traffic that deviates marginally from the baseline. When these alerts flow into a SIEM without correlation logic, analysts face a triage burden that exceeds available staff capacity, and the high-confidence alerts that represent real threats are buried in noise. The solution is not to raise detection thresholds -- which reduces sensitivity and allows real attacks to go undetected -- but to build correlation logic in the SIEM that promotes isolated low-confidence NTA alerts to high-confidence incidents only when they are corroborated by independent evidence from other data sources.

The most effective correlation patterns combine NTA anomaly alerts with authentication telemetry, endpoint detection data, and DNS logs. A single NTA alert for anomalous SMB activity is low-confidence on its own -- it could be a misconfigured application or a one-off administrative action. The same NTA alert correlated with a Kerberos authentication failure from the same source host within five minutes, and a Windows Event ID 4624 logon event on the destination host using an account that does not normally log on to that host, creates a three-source corroboration that carries high confidence as a lateral movement indicator. SIEM correlation rules that define these multi-source evidence chains for the most critical attack techniques (lateral movement, credential dumping, data staging, command and control) dramatically reduce alert volume while preserving detection coverage for the highest-priority threats.

Alert suppression through asset context reduces noise without degrading detection. An NTA alert for a scan-like connection pattern from a host tagged in the asset inventory as a vulnerability scanner is suppressed automatically. An alert for unusual outbound traffic from a host tagged as a data diode is promoted immediately because data diodes should never initiate outbound connections. Integrating the NTA sensor's alert pipeline with a maintained asset inventory -- even a simple flat file mapping IP addresses to host roles -- allows a significant fraction of low-confidence alerts to be automatically closed or escalated based on whether the observed behavior is plausible for that host type. On military networks where host roles are relatively stable compared to dynamic enterprise environments, asset-context suppression can reduce false positive volume by 40 to 60% with no configuration overhead beyond maintaining the asset list.

Deployment architecture: tap placement, span ports, and sensor scalability

Effective NTA coverage requires traffic to reach the sensor losslessly. The two primary methods for delivering traffic to an NTA sensor are passive optical taps and SPAN (Switched Port Analyzer) ports. Passive optical taps split the optical signal on a fiber link and deliver a copy to the sensor without introducing any latency or creating a network-visible tap point. They are the preferred method for high-value links because they cannot be disabled by switch configuration changes and do not affect link performance under any traffic load. SPAN ports, configured on a managed switch, copy traffic from one or more source ports or VLANs to a designated monitor port. SPAN ports are more flexible and lower cost than physical taps but have important limitations: many switch platforms drop packets on the SPAN port under high load, and SPAN configuration is visible in the switch configuration and can be inadvertently modified during routine network changes.

Sensor scalability on high-throughput military backbones requires packet broker hardware between the tap and the sensor. A 10 Gbps inter-enclave link may carry 2 to 5 Gbps of actual traffic under peak load -- well within the processing capacity of a single NTA sensor -- but a 100 Gbps backbone link requires either distributed sensors or a packet broker that filters, load-balances, and deduplicates traffic before forwarding to the sensor tier. Packet brokers also enable tap aggregation: a single sensor can receive traffic from multiple taps through a broker that merges the feeds and applies filtering rules to reduce the volume the sensor must process. For classified enclaves where physical hardware must meet stringent security requirements, purpose-built packet broker appliances that have been validated for the relevant classification level are available from a small number of specialized vendors.

Sensor placement strategy should account for both coverage requirements and the network's segmentation architecture. The minimum viable tap set for a military enclave covers the perimeter (traffic entering and leaving the enclave), the inter-VLAN routing point (east-west traffic between segments within the enclave), and the server segment hosting authentication infrastructure and critical application servers. This three-point architecture provides coverage of all external threats and the most consequential internal lateral movement paths at a sensor count that is operationally manageable. Full coverage of every access switch segment requires significantly more sensors and bandwidth but provides visibility into intra-segment lateral movement that the three-point architecture misses. The risk-based decision on coverage depth must weigh the probability of intra-segment attacks against the operational cost of additional sensor infrastructure and alert volume on the enclave in question, informed by insider threat risk assessments specific to the organization.