D3-ANAA Administrative Network Activity Analysis: Baselining Remote Admin Traffic to Catch Misuse

Attackers with valid credentials use the same RDP, SSH, WinRM and directory replication traffic as administrators, so the only reliable way to spot them on the wire is to know what normal administration looks like and flag what departs from it. MITRE D3FEND names this countermeasure Administrative Network Activity Analysis (D3-ANAA) and defines it as "Detection of unauthorized use of administrative network protocols by analyzing network activity against a baseline." It sits under the Detect tactic as a child of Network Traffic Analysis, and the digital artefact it analyses is Intranet Administrative Network Traffic: administrative protocol traffic that stays inside the organisation's own network. This card covers what D3-ANAA detects, which ATT&CK techniques D3FEND relates it to, where it is implemented, how to prove it works and where it falls short. It is written for detection engineers, network security teams and SOC leads who already run some form of network monitoring.

Key takeaways

• It is a baseline control. D3-ANAA does not look for malware in packets; it learns which hosts administer which systems over which protocols and alerts when that pattern changes.
• D3FEND relates it to eight ATT&CK techniques. All are inferred through the shared artefact Intranet Administrative Network Traffic, including DCSync (T1003.006), Rogue Domain Controller (T1207), Windows Management Instrumentation (T1047) and Password Spraying (T1110.003).
• The scope is internal traffic. The artefact is intranet administrative traffic, so the control is about lateral movement and abuse of admin channels inside the network, not exposed remote access at the edge.
• Encryption and inventory gaps are the main limits. D3FEND's own considerations name encrypted administrative traffic as a challenge and recommend integration with inventory management to cut false alarms.
• Most admin traffic today is non-human. Configuration management, backup, monitoring and deployment tools generate the bulk of SSH, WinRM and WMI sessions, so the baseline must model service accounts and automation hosts, not only people.

D3-ANAA at a glance

How it works

D3FEND's knowledge base article describes the pattern plainly: system administrators manage servers remotely over protocols such as RDP, SSH and SNMP, attackers with valid credentials use the same protocols to blend in, and monitoring that traffic makes it possible to detect when the protocols behave differently from a known baseline. The Vectra Networks patent that D3FEND cites describes the same method in MITRE's analysis: collect network traffic metadata directed at administrative services over a period of time, build a baseline, then flag activity outside it.

In practice a D3-ANAA analytic answers four questions for every administrative session it sees:

• Who is the client? Is the source a known administration host such as a jump server, privileged access workstation or automation server, or an ordinary user endpoint?
• What is the target? Has this client ever administered this server, and is the target in the asset class it normally manages?
• Which protocol? Does this pair normally use SSH, RDP or WinRM, or has a new admin protocol appeared between them?
• When and how much? Is the session at a usual time, with usual duration, volume and fan-out, or is one client suddenly touching dozens of servers?

The two MITRE Cyber Analytics Repository entries that D3FEND lists show the Windows side. The Remote Registry analytic (CAR-2014-11-005) notes that remote registry access runs over the WINREG named pipe on SMB, that the network traffic can be decoded with Wireshark or a similar sensor, and that the reliability of the analytic depends on correctly identifying pre-existing legitimate use. The WinRM analytic (CAR-2014-11-006) concerns Windows Remote Management, which listens by default on port 5985 for HTTP and 5986 for HTTPS from WinRM 2.0 onwards.

Reference: admin protocols a baseline should cover

Ports listed are common defaults (general practice, not taken from D3FEND); a baseline built on port numbers alone misses services moved to non-standard ports, which is why sensors that identify protocols from the traffic itself are preferred.

ATT&CK techniques D3FEND relates to D3-ANAA

Relationship type: inferred only. D3FEND derives every row below through the shared digital artefact: D3-ANAA analyzes Intranet Administrative Network Traffic, and each of these ATT&CK techniques produces or may create that traffic in the D3FEND model. D3FEND labels these relations inferred and experimental (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.

D3FEND models RDP (T1021.001), SSH (T1021.004) and Remote Service Session Hijacking as producing the broader Administrative Network Traffic class rather than the intranet sub-class, so they do not appear in the inferred list even though, in NHI Mgmt Group's view, they are the most common things a D3-ANAA baseline catches. Treat the table as D3FEND's model, not a coverage claim. Deeper defensive detail sits in T1021 Remote Services, T1047 Windows Management Instrumentation Defensive Guide, MITRE ATT&CK T1207 Rogue Domain Controller and the Golden Ticket, Silver Ticket and DCSync Guide.

Where it is implemented

The broader monitoring architecture, sensor placement and IDS options are in the IDS and IPS Guide; full packet capture for investigation is in the Arkime Full Packet Capture Guide. The parent technique, Network Traffic Analysis, is summarised in the MITRE D3FEND Guide.

Where identity fits

The baseline is really a map of which identities administer which systems from where. Configuration management servers, backup agents, vulnerability scanners and CI runners hold SSH keys and service account passwords that open admin sessions all day; in most estates they produce far more admin traffic than humans do. Model each automation host and its service account as its own baseline entity, so that the same key appearing from a laptop, or a scanner account suddenly using RDP, stands out. Finding those keys in the first place is covered in How to Find ssh authorized keys across a server fleet.

Implementation steps

1. Define the authorised admin paths. List the jump hosts, privileged access workstations, PAM proxies and automation servers that are allowed to originate admin protocols, and which server groups each may reach. Pull this from the CMDB or inventory, since D3FEND specifically recommends inventory integration to reduce false alarms.
2. Place sensors on internal paths. Admin traffic is east-west, so sensors at the internet edge miss it. Cover the server VLANs, the domain controller segment and the management network that carries IPMI and SNMP.
3. Collect protocol-level logs. At minimum: SSH and RDP session records, SMB named pipe and DCE/RPC interface use, Kerberos and NTLM authentication, and flow data for WinRM, SNMP, IPMI and VNC ports.
4. Learn before alerting. Run a learning period (for example four weeks, an NHI Mgmt Group suggestion that should cover a monthly patch cycle) and record client, target, protocol, time and volume per pair.
5. Start with high-certainty rules. Replication requests from non-DC hosts, admin protocols from user endpoint ranges to servers, and new admin protocols between a pair are easier to tune than volume anomalies.
6. Add anomaly rules in shadow mode. Run fan-out, first-seen pair and off-hours rules without paging for two to four weeks, review every hit, and fix the cause (an unregistered automation host, a missing inventory entry) rather than raising thresholds.
7. Write the response. An admin session from an unexpected source is a potential intrusion in progress: identify the account used, check whether the source host is managed, and decide on session termination or credential revocation with the system owner.
8. Keep the baseline current. Feed change tickets and new automation hosts into the allow-list, and retire entries for decommissioned tools. Rolling back a noisy rule means returning it to shadow mode, not deleting it.

How to verify it works

• Controlled admin session test: with change approval, open an SSH or RDP session from an ordinary test endpoint to a server it has never administered and confirm the alert fires with source, target, account and protocol.
• Replication test: in an authorised exercise, confirm that a directory replication request from a non-DC test host raises the DCSync detection, whether from the network sensor or the identity sensor.
• Sensor coverage check: compare the list of server subnets with the subnets the sensors actually observe; an unmonitored VLAN is a blind spot that produces no alerts at all.
• Adversary emulation: include lateral movement over WinRM, WMI and SSH in purple team exercises and record which sessions were detected and how quickly.

Limits, bypasses and failure patterns

• Encrypted channels hide intent: D3FEND notes that administrative traffic can be encrypted. The sensor sees that an SSH or WinRM session happened, not what was run, so the analytic depends on who, where and when.
• Living inside the baseline: an attacker who compromises the jump host or the automation server inherits its normal admin paths. Pair D3-ANAA with host telemetry on those systems and with the controls in If your jump host and bastion is compromised.
• Baselining compromise: if an intruder is already active during the learning period, their sessions become part of normal. Review the first baseline by hand for admin paths nobody can explain.
• Edge-only sensors: monitoring the internet perimeter misses the east-west traffic this technique is about. Exposed remote access is a separate problem covered in Exposed RDP Compromise.
• Unregistered automation drowning the SOC: new monitoring, backup or deployment tools appear as anomalies every time. Without an inventory feed analysts start ignoring the alert class.
• Port-based rules only: moving SSH to a high port or tunnelling RDP inside another protocol defeats rules keyed on port numbers. Use protocol identification, and alert on admin protocols seen on non-standard ports.

Framework mapping

Related countermeasures

• Remote Terminal Session Detection (D3-RTSD): detects remote terminal sessions specifically; see D3-RTSD Remote Terminal Session Detection.
• Session Duration Analysis (D3-SDA): adds duration as a baseline dimension; see D3-SDA Session Duration Analysis.
• Domain Account Monitoring (D3-DAM): the host and directory view of the same privileged accounts; see D3-DAM Domain Account Monitoring.
• Authentication Event Thresholding (D3-ANET): catches spraying and stuffing from the authentication log side; see D3-ANET Authentication Event Thresholding.

Practitioner checklist

• Document every authorised admin source host and the server groups it may reach.
• Place network sensors on server, domain controller and management segments, not only at the edge.
• Collect SSH, RDP, SMB, DCE/RPC, Kerberos and NTLM protocol logs plus flow data for WinRM, SNMP, IPMI and VNC.
• Alert on directory replication requests from any host that is not a domain controller.
• Alert on admin protocols from user endpoint ranges to servers.
• Model each automation host and service account as its own baseline entity.
• Run anomaly rules in shadow mode before paging, and fix the root cause of benign hits.
• Test with a controlled admin session from an unexpected host every quarter.
• Feed inventory and change data into the baseline so new tools are expected, not alerted on.

Standards and references

• MITRE D3FEND: Administrative Network Activity Analysis (D3-ANAA)
• Google Patents: US20180077186A1 Method and system for detecting suspicious administrative activity
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• Microsoft Learn: Defender for Identity security alerts
• Microsoft Learn: Installation and configuration for Windows Remote Management
• Zeek documentation: ssh.log
• Zeek documentation: Common logs

Related NHI Mgmt Group resources: MITRE D3FEND Guide · Lateral Movement Guide · Active Directory Security Monitoring and Event IDs Guide · IDS and IPS Guide · Impacket Detection Guide