Most Windows lateral movement travels over the same SMB named pipes and RPC interfaces that administrators use every day, so it hides in plain sight unless someone parses that traffic and knows what normal looks like. MITRE D3FEND names this countermeasure IPC Traffic Analysis (D3-IPCTA) and defines it as "Analyzing standard inter process communication (IPC) protocols to detect deviations from normal protocol activity." It sits under the Detect tactic as a child of Network Traffic Analysis (D3-NTA) and analyses Intranet IPC Network Traffic. This card covers what the technique looks at, the single ATT&CK technique D3FEND relates to it, the MITRE CAR analytics behind it, where it is implemented in network sensors and Windows logging, how to verify it and where it fails. It is for detection engineers and SOC analysts; general sensor design is in the Zeek Network Monitoring Guide and the NDR Guide.
Key takeaways
- It is about protocol behaviour, not content. D3-IPCTA watches which named pipes, RPC interfaces and operations hosts use with each other, then flags deviations from normal use. D3FEND gives SMB, ZeroMQ and the Java RMI API as example protocols.
- Thin ATT&CK mapping, rich CAR analytics. D3FEND infers only one ATT&CK technique, BITS Jobs (T1197), through the Intranet IPC Network Traffic artefact. The practical value sits in the six MITRE CAR analytics D3FEND cites, which target SMB lateral movement, remote task scheduling and named pipe writes.
- Named pipe and operation names are the signal. Pipes such as ATSVC and WINREG, and RPC operations such as svcctl CreateServiceW or atsvc JobAdd, tell a far clearer story than byte counts.
- Volume is the stated limit. D3FEND warns that IPC can generate substantial data and that some IPC runs over loopback or shared memory that never reaches a network sensor. Plan for host telemetry as well as network parsing.
- Correlation beats single events. A file write to ADMIN$ followed by a service creation on the same host within minutes is lateral movement far more often than either event alone.
D3-IPCTA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-IPCTA (d3f:IPCTrafficAnalysis), synonym "IPC Analysis" |
| Tactic | Detect |
| Parent technique | Network Traffic Analysis (D3-NTA) |
| Digital artefact | Intranet IPC Network Traffic (D3FEND relation: analyzes): traffic that stays inside the network and uses a standard IPC networking protocol |
| D3FEND references | Six MITRE CAR analytics (CAR-2013-01-003, CAR-2013-05-003, CAR-2013-05-005, CAR-2013-09-003, CAR-2014-03-001, CAR-2015-04-001) and a Check Point patent on interprocess communication control |
| Typical data sources | Zeek smb_files, smb_mapping and dce_rpc logs; NDR protocol metadata; Windows Security event 5145; Sysmon events 17 and 18 |
| Typical outputs | Alerts on unusual pipe, share or RPC operation use; correlated lateral movement notices; scoping data after an intrusion |
| Main limitation | High legitimate volume, and IPC that never leaves the host or is encrypted end to end |
How it works
D3FEND's knowledge base article describes two collection routes. A network protocol analyser can parse SMB traffic to record system activity between machines, and a host-based monitoring agent can watch IPC that stays within one host. Both look for deviations from standard use. The CAR analytics D3FEND cites show what that means in practice.
| CAR analytic | What it looks for | ATT&CK mapping stated by CAR |
|---|---|---|
| CAR-2013-01-003 SMB Events Monitoring | SMB activity on 445/tcp (share enumeration, reads, writes) parsed from packet capture; CAR notes it is often more practical forensically, to scope an intrusion | T1021.002 SMB/Windows Admin Shares; T1039 Data from Network Shared Drive |
| CAR-2013-05-003 SMB Write Request | SMB writes, which need more access than reads and are therefore rarer | T1570 Lateral Tool Transfer; T1021.002 SMB/Windows Admin Shares; T1078.002 Domain Accounts, T1078.003 Local Accounts |
| CAR-2013-05-005 SMB Copy and Execution | A file written over SMB and then executed on the remote host | T1021.002 SMB/Windows Admin Shares; T1078.002 Domain Accounts, T1078.003 Local Accounts |
| CAR-2014-03-001 SMB Write Request, Named Pipes | Writes to named pipes over 445/tcp, with the pipe name taken from the protocol data; CAR names msftewds as usually benign, lsarpc as more interesting, and WINREG and ATSVC as linked to adversary activity | T1570 Lateral Tool Transfer (low coverage) |
| CAR-2015-04-001 Remotely Scheduled Tasks via AT | The JobAdd function called over the ATSVC named pipe after SMB authentication | T1053.002 At |
MITRE's BZAR project, maintained as a component of CAR, turns this into Zeek scripts. It combines an SMB write to ADMIN$ or C$ with a DCE-RPC execution indicator against the same host within a set period, using operations such as svcctl CreateServiceW, IWbemServices ExecMethod, atsvc JobAdd and ITaskSchedulerService SchRpcRegisterTask. Those map to T1569.002 Service Execution, T1047 Windows Management Instrumentation, T1053.002 At and T1053.005 Scheduled Task.
Protocols in scope
- SMB and named pipes: SMB on 445/tcp (and 139/tcp for NetBIOS sessions) carries file shares and the IPC$ share through which named pipes such as svcctl, atsvc, winreg, lsarpc and spoolss are reached.
- DCE-RPC: the endpoint mapper listens on 135/tcp, and RPC interfaces run either over named pipes or over dynamic TCP ports. Zeek records the endpoint, operation and named pipe for each call.
- Other IPC protocols: D3FEND lists ZeroMQ and Java RMI. Few network sensors parse these by default, so coverage usually comes from application logging or from flow baselines on their ports.
ATT&CK techniques D3FEND relates to D3-IPCTA
Relationship type: inferred only. D3FEND lists no hand-made ATT&CK mapping. It infers one relation because D3-IPCTA analyses Intranet IPC Network Traffic and BITS Jobs may produce that traffic. D3FEND labels such relations "inferred and experimental" (D3FEND 1.6.0, checked November 2026). The ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND relation | What IPC traffic analysis can show |
|---|---|---|---|
| T1197 | BITS Jobs (Execution, Persistence, Stealth) | BITS Jobs may produce Intranet IPC Network Traffic | BITS transfers from SMB file shares (Microsoft documents BITS for HTTP web servers and SMB file shares): a host pulling a file from an unusual internal share through BITS |
The CAR analytics above add the techniques D3FEND does not infer but that IPC analysis detects best in practice: T1021.002, T1570, T1039, T1053.002, T1053.005, T1569.002 and T1047. Treat those as CAR's and BZAR's mappings, not D3FEND's. Technique detail is in MITRE ATT&CK T1197 BITS Jobs, MITRE ATT&CK T1570 Lateral Tool Transfer, MITRE ATT&CK T1569 System Services and T1053 Scheduled Task/Job Defensive Guide. Host-only IPC abuse is covered by MITRE ATT&CK T1559 Inter-Process Communication.
Where it is implemented
Implementations are listed alphabetically; the order is not a ranking. Each row is described from the project's or vendor's own documentation.
| Implementation class | Example feature (documentation) | What it records |
|---|---|---|
| Host telemetry (Windows auditing) | Event 5145 "A network share object was checked to see whether client can be granted desired access", from the Audit Detailed File Share subcategory under Object Access | Account, source address, ShareName (including \\*\IPC$), RelativeTargetName and access rights; for named pipes the AppendData right reads as CreatePipeInstance |
| Host telemetry (Sysmon) | Event 17 PipeEvent (Pipe Created) and Event 18 PipeEvent (Pipe Connected), filtered with the PipeEvent tag | Named pipe creation and client connections on the host, including pipes used only locally |
| Network sensor (Zeek) | smb_files log (file actions FILE_OPEN, FILE_RENAME, FILE_DELETE, PRINT_OPEN, PRINT_CLOSE by default via logged_file_actions), smb_mapping log (path, service, share_type) and dce_rpc log (endpoint, operation, named_pipe, rtt) | Who opened which share, file and pipe, and which RPC operation was called |
| Network sensor (Zeek package) | MITRE BZAR scripts using SumStats to correlate SMB and DCE-RPC indicators and raise notices, with allow lists for tuning | Correlated lateral movement and execution notices |
Availability: event 5145 fires on every share access check, so Microsoft's guidance implies high volume on busy file servers; enable it on targeted servers first. Sysmon logs only what its configuration includes. Zeek sees SMB content only where traffic is not encrypted end to end: SMB 3 encryption hides file and pipe names from a passive sensor, so host telemetry carries that load. NDR products expose similar SMB and RPC metadata; see the NDR Buyer's Guide for evaluation questions.
Where identity fits
Almost every alert this technique raises carries an account. Remote service creation and task scheduling over RPC need administrative credentials, very often a service account, a deployment tool's account or a shared local administrator. Baselines are clearer when keyed on account as well as host: a backup service account writing to ADMIN$ on its scheduled window is normal; the same account calling svcctl CreateServiceW on a finance workstation is not. Correlate event 5145 SubjectLogonId with logon event 4624 to tie pipe access to the logon type. See the Active Directory Security Monitoring and Event IDs Guide and Detection Engineering for Non-Human Identities Guide.
Implementation steps
- Place sensors on east-west paths. Put a network sensor where workstation-to-server and server-to-server SMB and RPC traffic crosses, not only at the internet edge. Intranet IPC traffic is the artefact, so an edge-only sensor sees almost none of it.
- Turn on the protocol logs. Enable Zeek's SMB and DCE-RPC logging (or the NDR equivalent) and forward smb_mapping, smb_files and dce_rpc to the SIEM. On Windows servers in scope, enable Audit Detailed File Share and Sysmon pipe events.
- Build a baseline of who talks to whom. For two to four weeks, record which source hosts and accounts connect to ADMIN$, C$ and IPC$, which pipes they open and which RPC operations they call. Management servers, deployment tools and backup systems will dominate; list them by name.
- Write high-value rules first. Alert on remote service creation, remote task registration and WMI method execution from hosts outside the management list, and on writes to admin shares followed by execution on the same target, as BZAR does.
- Allow-list explicitly. Record each approved source, account and pipe in a reviewed allow list (CAR suggests treating spoolss as legitimate noise, for example). Avoid broad wildcard exclusions.
- Run in alert-only mode and tune. Keep new rules non-paging for two weeks, review every hit and adjust. Roll back by disabling a rule, not by deleting the underlying logging.
- Keep the raw logs for scoping. CAR notes that SMB monitoring is often most useful after an intrusion is found. Retain SMB and RPC metadata long enough to trace movement back to the first host.
How to verify it works
- Controlled admin actions: in an authorised test, have an administrator account from a non-management host create and delete a benign remote service and a remote scheduled task on a test server. Confirm the dce_rpc log shows svcctl and ITaskSchedulerService operations and that the rule fires.
- Admin share write and execute: copy a harmless file to ADMIN$ on a test host and run it remotely with an approved tool. Confirm the correlated alert appears and names the source host and account.
- Visibility check: compare the hosts in Zeek smb_mapping with the list of file servers and domain controllers. Missing servers usually mean a sensor gap or encrypted SMB.
- Host coverage check: confirm event 5145 and Sysmon events 17 and 18 arrive in the SIEM from each server in scope.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Servers with SMB and RPC visibility (network or host) | All domain controllers and file servers | Coverage of the main lateral movement paths |
| Remote execution operations from non-management hosts that alert | 100% in tests | Proves the core rule works |
| Allow-list entries with a named owner and review date | 100% | Stops silent exclusions growing |
| Weekly IPC alerts closed as benign | Falling after each tuning cycle | Shows the baseline is improving |
| Days of SMB and RPC metadata retained | Long enough to cover typical dwell time in your incident history | Supports scoping after detection |
Limits, bypasses and failure patterns
- Encrypted SMB blinds the wire: SMB 3 encryption is a good control, but a passive sensor then sees only connections, not pipes or files. Shift detail to host events rather than weakening encryption. See the SMB Protocol Security and Signing Guide.
- Local IPC never crosses the network: D3FEND notes that IPC may use loopback interfaces or direct memory access. Pipe impersonation and local RPC abuse need host analytics such as D3-SCA System Call Analysis.
- Allow lists that trust a whole subnet: attackers who land on a management server inherit its allow-listed behaviour. Key allow lists on host and account, and watch management servers more closely, not less.
- Alternative transports: RPC over dynamic TCP ports, WinRM or SSH moves the same intent outside SMB pipes. Pair this technique with D3-RTSD Remote Terminal Session Detection.
- Logging everything, reviewing nothing: event 5145 on every file server floods the SIEM. Scope to admin shares and IPC$ first.
- Unparsed protocols: ZeroMQ and Java RMI traffic is usually opaque to sensors; without application logs, only connection baselines remain.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring; SI-4(4) Inbound and Outbound Communications Traffic | Monitoring internal communications for unusual or unauthorised activity |
| NIST SP 800-53 Rev 5 | AU-12 Audit Record Generation | Generating share access and pipe events on hosts |
| NIST SP 800-53 Rev 5 | CM-7 Least Functionality | Disabling unneeded pipes, shares and RPC services reduces what must be monitored |
| NIST CSF 2.0 | DE.CM-01, DE.AE-03 | Networks monitored; information correlated from multiple sources |
| MITRE D3FEND | D3-NTA, D3-IPCTA | Parent and technique |
Related countermeasures
- Resource Access Pattern Analysis (D3-RAPA): account-level view of unusual resource access. See D3-RAPA Resource Access Pattern Analysis.
- Process Spawn Analysis (D3-PSA): catches what runs after a remote service or task is created. See D3-PSA Process Spawn Analysis.
- Network Traffic Community Deviation (D3-NTCD): a sibling under D3-NTA that flags hosts talking to groups they never normally reach. See D3-NTCD Network Traffic Community Deviation.
- Network Segmentation (M1030) and Disable or Remove Feature or Program (M1042): reduce SMB and RPC paths so fewer need watching. See M1030 Network Segmentation and M1042 Disable or Remove Feature or Program.
Practitioner checklist
- Place network sensors on internal SMB and RPC paths, not only at the edge.
- Log SMB share mappings, file actions and DCE-RPC operations to the SIEM.
- Enable Audit Detailed File Share and Sysmon pipe events on servers in scope.
- Baseline source host, account, share, pipe and RPC operation for two to four weeks.
- Alert on remote service, task and WMI execution from non-management hosts.
- Correlate admin share writes with execution on the same target.
- Keep allow lists per host and account, each with an owner and review date.
- Test with authorised remote admin actions at least quarterly.
- Retain SMB and RPC metadata for intrusion scoping.
Standards and references
- MITRE D3FEND: IPC Traffic Analysis (D3-IPCTA)
- MITRE CAR: CAR-2014-03-001 SMB Write Request, Named Pipes
- MITRE CAR: CAR-2013-01-003 SMB Events Monitoring
- MITRE CAR: CAR-2015-04-001 Remotely Scheduled Tasks via AT
- MITRE: BZAR (Bro/Zeek ATT&CK-based Analytics and Reporting)
- Microsoft Learn: Event 5145, network share object access check
- Microsoft Learn: Sysmon
- Microsoft Learn: Background Intelligent Transfer Service
Related NHI Mgmt Group resources: Zeek Network Monitoring Guide · Lateral Movement Guide · SMB Signing Guide · NDR Guide · MITRE D3FEND Guide