An attacker who already holds valid access rarely needs malware on the wire: a Modbus write to a holding register, an FTP STOR to a server that only ever serves downloads, or a directory replication request from a workstation all look like normal protocol use until someone asks whether that command should have been sent. MITRE D3FEND names this countermeasure Application Protocol Command Analysis (D3-APCA) and defines it as "Analyzing application protocol level remote commands to detect unauthorized activity." It sits under the Detect tactic as a child of Network Traffic Analysis, and its one listed child is Remote Firmware Update Monitoring (D3-RFUM). This page explains what D3-APCA requires, which data sources expose commands, how to build and verify command analytics, and where they fail. It is written for detection engineers, NDR owners and OT security teams who know the basics in the NDR Guide.
Key takeaways
- Commands, not just connections. D3-APCA needs a parser that understands the application protocol, so it can see the verb (function code, FTP command, HTTP method, RPC operation, API verb), not only who talked to whom.
- Two ways to see commands. D3FEND states the commands "can be observed by monitoring network traffic or application logs", so a server audit log is as valid a source as a network sensor.
- Allowlists beat signatures where protocols are narrow. In OT and in service-to-service APIs, the set of legitimate commands per client is small enough to write down, and anything outside it is worth an alert.
- The ATT&CK links are inferred. D3FEND relates D3-APCA to the same broad list of network techniques as other Network Traffic Analysis children, because they share the Network Traffic artefact. Treat it as a list of places to look, not as coverage.
- Encryption decides the vantage point. TLS-wrapped protocols hide commands from passive sensors, so plan decryption points or application logs before promising detection.
D3-APCA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-APCA (d3f:ApplicationProtocolCommandAnalysis) |
| Tactic | Detect |
| Parent technique | Network Traffic Analysis |
| Child technique | Remote Firmware Update Monitoring (D3-RFUM), which detects OT Device Firmware Command and monitors OT Network Traffic |
| Digital artefact | Network Traffic (D3FEND relation: monitors) |
| Detection methods named by D3FEND | Signature-based or statistical analysis of parsed commands |
| D3FEND references | Two patents: Nozomi Networks, "Method and apparatus for detecting anomalies of an infrastructure in a network"; Fortinet, "Protocol based detection of suspicious network traffic" |
| Typical data sources | Protocol logs from Zeek, Suricata app-layer rules, OT monitoring sensors, server and API audit logs |
| Main limitation | Only as good as the protocol parser and the definition of "authorised"; blind to encrypted sessions without a decryption point |
How it works
D3FEND's description has three parts: parse the application layer protocol to understand the commands sent to a remote service, identify unauthorised commands with signature-based or statistical analysis, and observe those commands either in network traffic or in application logs. D3FEND lists no separate considerations section for the technique.
The two references show the two main designs. The Nozomi Networks patent identifies the protocol and every field in a packet, recognises the device by matching identification fields against a knowledge base of standard devices, retrieves the protocols and fields allowed for that device type, and signals an anomaly when the observed protocol or fields differ from the allowed ones. That is an allowlist per device class. The Fortinet patent processes captured traffic on a network security device and decides whether the protocol in use indicates a threat such as a botnet or advanced persistent threat. That is protocol-based signature detection.
In practice, command analytics fall into four patterns:
- Command allowlist per client: each client or role may send a known set of commands to a service (for example, the SCADA historian reads holding registers but never writes).
- Dangerous command signatures: commands that are rarely legitimate anywhere, such as firmware download, controller stop, or a directory replication request from a non-domain-controller.
- Command and argument context: a legitimate verb with an unusual argument, such as a write to a register range that controls a safety setpoint, or an upload to a path outside the expected directory.
- Statistical change: a client that suddenly issues a new command type, many more writes than its baseline, or a burst of failures and exception replies.
Where commands are visible
D3-APCA is a technique, not a product. The table lists data sources whose documentation exposes command-level fields. Network sources are listed alphabetically and named as examples of a class, not recommendations.
| Source | Command-level fields documented | Use for D3-APCA |
|---|---|---|
| Kubernetes API server audit log | Audit events record the requesting user, timestamp, resource and verb at the Metadata level; Request and RequestResponse levels add bodies. Enabled with --audit-log-path or a webhook backend | Application-log route: unusual verbs (create, delete, exec) by a service account against sensitive resources. See the Kubernetes Audit Log Detection Guide |
| Suricata app-layer rule keywords | ftp.command and ftp.command_data sticky buffers; http.method; dnp3_func, dnp3_obj and dnp3_ind; the modbus keyword matching function code, read or write access by table, address, value and unit | Signature route: alert on a specific command, argument or function in real time. See the Suricata IDS Guide |
| Zeek protocol logs | FTP::Info has command, arg, user, reply_code; DCE_RPC::Info has endpoint and operation; Modbus::Info has func, unit, pdu_type, exception; DNP3::Info has fc_request, fc_reply, iin | Logging route: every command recorded for allowlist and statistical analytics in a SIEM. See the Zeek Network Monitoring Guide |
| OT monitoring sensors and NDR platforms | Vendor protocol parsers for industrial and enterprise protocols, often with learned per-device command baselines | Faster start for many protocols; check which protocols, function codes and baselines are documented. See the OT Network Security Monitoring Guide |
Two practical notes from the documentation. Suricata's Modbus addresses start at 1, so a system that numbers registers from 0 needs one added to rule addresses. Suricata also notes that Modbus/TCP connections are often kept open, and suggests unlimited stream reassembly depth (stream.reassembly.depth: 0) so commands late in a long session are still inspected.
Example analytics by protocol
The rows below are examples to adapt, not a standard rule set. Each needs an owner, a written hypothesis and a test case.
| Protocol | Command or field | Example analytic |
|---|---|---|
| DCE/RPC (directory replication) | Zeek dce_rpc operation, for example a DRSUAPI replication call | Replication operation from a source that is not a domain controller (related to T1003.006 DCSync). See the Golden Ticket, Silver Ticket and DCSync Guide |
| DNP3 | Function code in request (dnp3_func, fc_request) | Control or restart functions from any host other than the authorised master station. See the DNP3 and DNP3 Secure Authentication Guide |
| FTP | Command and argument (ftp.command, command and arg) | STOR or APPE to a server whose role is read-only distribution; logins with new user names |
| HTTP and REST APIs | Method and path (http.method, API audit verb) | PUT, DELETE or administrative paths from clients that only ever read; methods such as TRACE where never used |
| Kubernetes API | Audit verb and objectRef | A workload service account that starts reading secrets or creating pods in other namespaces |
| Modbus/TCP | Function code, access type, address, value, unit | Any write to holding registers or coils from hosts outside the engineering workstation group; writes to safety-related address ranges; exception replies rising. See the Modbus TCP and Modbus Security Guide |
In OT, the child technique D3-RFUM narrows this to firmware update commands; deployment detail is in the MITRE D3FEND Remote Firmware Update Monitoring Implementation Guide. In NHI Mgmt Group's view (not a D3FEND mapping), command analytics in OT also give network evidence for ATT&CK for ICS techniques such as T0836 Modify Parameter, T0843 Program Download and T0858 Change Operating Mode. The FrostyGoop case, where malware interacted with controllers over Modbus, shows why writes deserve attention: see the FrostyGoop Modbus Malware Guide.
ATT&CK techniques D3FEND relates to D3-APCA
Relationship type: inferred only. D3FEND marks these as "related (inferred, experimental)" because D3-APCA monitors Network Traffic and each technique produces or uses network traffic (checked November 2026). The page also lists parent techniques without sub-technique IDs, such as Protocol Tunneling and Exploit Public-Facing Application; only rows with IDs are shown. The D3FEND ontology also relates some ATT&CK for ICS techniques to Network Traffic; they are not listed here. Every ID was checked against ATT&CK v20.
| ATT&CK tactic (v20) | Techniques (inferred via Network Traffic) | What command analysis can add |
|---|---|---|
| Command and control | T1071.001 Web Protocols, T1071.002 File Transfer Protocols, T1071.003 Mail Protocols, T1071.004 DNS, T1090.001 Internal Proxy, T1090.002 External Proxy, T1090.003 Multi-hop Proxy, T1090.004 Domain Fronting, T1573.001 Symmetric Cryptography, T1573.002 Asymmetric Cryptography, T1205.001 Port Knocking | Unusual methods, verbs or command sequences inside otherwise allowed protocols; most value where the protocol is cleartext or decrypted |
| Credential access and collection | T1003.006 DCSync, T1558.003 Kerberoasting, T1110.003 Password Spraying, T1110.004 Credential Stuffing, T1557.001 Name Resolution Poisoning and SMB Relay, T1557.003 DHCP Spoofing | Replication operations from non-domain-controllers; repeated authentication commands and failure replies |
| Lateral movement | T1021.001 Remote Desktop Protocol, T1021.004 SSH, T1550.001 Application Access Token, T1550.004 Web Session Cookie | API calls with a reused token from a client that never issued those verbs |
| Exfiltration | T1048.001, T1048.002, T1048.003 Exfiltration Over Alternative Protocol sub-techniques, T1567.001 Exfiltration to Code Repository, T1567.002 Exfiltration to Cloud Storage | Upload commands (FTP STOR, HTTP PUT or POST to storage APIs) from hosts that normally only download |
| Initial access and execution | T1566.001 Spearphishing Attachment, T1566.002 Spearphishing Link, T1204.001 Malicious Link | Limited: mail protocol commands and follow-on downloads |
| Persistence, privilege escalation and stealth | T1098.001 Additional Cloud Credentials, T1546.003 Windows Management Instrumentation Event Subscription, T1546.008 Accessibility Features, T1542.005 TFTP Boot, T1218.003 CMSTP | Cloud API calls that add credentials, TFTP read requests for boot images; host telemetry remains the primary source for the rest |
| Impact | T1565.002 Transmitted Data Manipulation, T1498.001 Direct Network Flood, T1498.002 Reflection Amplification, T1499.002 Service Exhaustion Flood | Request types used in amplification; commands that alter data in transit |
For command and control content, see MITRE ATT&CK T1071 Application Layer Protocol.
Where identity fits
Many unauthorised commands come from valid machine identities: a service account, an API token or a Kubernetes workload identity used outside its normal pattern. Pair each command allowlist with the identity that should issue it, not only the source IP, so a stolen token used from the right subnet still stands out. The DCSync row above is an identity attack seen entirely through one RPC operation.
Implementation steps
- Inventory protocols and parsers. List the application protocols on each segment and confirm your sensor or log source parses each one to command level. Unparsed protocols are out of scope until a parser exists.
- Decide the vantage point per protocol. Cleartext OT and legacy protocols suit passive sensors; TLS-wrapped APIs need application or audit logs, or a sanctioned decryption point.
- Write the authorised command model. For each service, record which clients or identities may send which commands, from engineering documentation and owners, not only from learning mode. Learned baselines can absorb attacker activity already present.
- Start with high-value, low-volume rules. Writes and control functions in OT, replication operations, firmware or program downloads, and administrative API verbs. These are rare and explainable.
- Pilot in alert-only mode. Run for two to four weeks (an example period), review every alert, and document benign causes such as maintenance windows and engineering laptops.
- Add statistical analytics later. New command types per client, write-rate changes and exception reply bursts, once the allowlist is stable.
- Roll back safely. These are detective rules, so rollback is disabling or re-scoping a rule. Keep versioned rule files. If an inline device blocks on the same signatures, separate that decision: blocking a legitimate OT command can stop a process.
How to verify it works
- Replay approved captures: replay recorded test sessions containing the target commands (a Modbus write, an FTP upload, a replication request in a lab domain) into the sensor and confirm each rule fires with the right fields.
- Exercise in a test environment: in OT, use a test bench or simulator, never a live process, to issue the commands the rules cover.
- Parser health: track the share of sessions per protocol that the parser decoded; a protocol that silently stops parsing makes every rule on it blind.
- Log pipeline health: alert when an audit log source stops sending, for example a Kubernetes API server with an unset --audit-log-path after an upgrade.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Critical services with a written command allowlist | Rising each quarter toward all in scope | Defines what "unauthorised" means |
| Test commands detected in scheduled replay | All defined cases, each quarter | Proves rules and parsers work |
| Sessions parsed to command level, per protocol | Tracked; investigate any fall | Parser gaps are invisible otherwise |
| Alerts closed as authorised change | Falling as change records are linked | Shows allowlists match operations |
| Median time from command alert to owner decision | Tracked per severity | OT write alerts lose value within minutes |
Limits, bypasses and failure patterns
- Encrypted sessions: a passive sensor sees no commands inside TLS, so teams believe a protocol is covered when only connection metadata is. Use application logs for those services.
- Authorised client, unauthorised intent: an attacker on the engineering workstation sends the same commands the engineer does. Tie alerts to change windows and identities, and keep host monitoring on those workstations.
- Learning mode as policy: accepting a learned baseline without review turns existing malicious or careless commands into the allowlist.
- Parser drift: vendor protocol extensions, non-standard ports and new firmware versions break parsing; commands go unlogged with no error in the SIEM.
- Too many low-value rules: alerting on every read creates noise that hides the rare write that matters.
- Logging secrets: FTP::Info includes a password field and API audit at Request level can capture bodies. Restrict access and control password capture so the detection store does not become a credential store.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Monitoring communications for unauthorised activity |
| NIST SP 800-53 Rev 5 | AU-12 Audit Record Generation | Generating the protocol and audit records the rules use |
| NIST SP 800-53 Rev 5 | CM-7 Least Functionality | Defining the permitted functions and commands per service |
| NIST CSF 2.0 | DE.CM-01, DE.AE-02 | Networks and services monitored; potentially adverse events analysed |
| NIST SP 800-82 Rev 3 | Guide to Operational Technology (OT) Security | OT monitoring context for command analysis on industrial protocols |
| MITRE D3FEND | Network Traffic Analysis, D3-APCA, D3-RFUM | Parent, technique and child |
Related countermeasures
- Network Traffic Analysis (parent): see the MITRE D3FEND Network Traffic Analysis Implementation Guide.
- RPC Traffic Analysis (D3-RTA): a sibling focused on RPC calls. See D3-RTA RPC Traffic Analysis.
- Network Traffic Signature Analysis (D3-NTSA): signature matching across traffic generally. See D3-NTSA Network Traffic Signature Analysis.
- Protocol Metadata Anomaly Detection (D3-PMAD): outliers in metadata where commands are not visible. See D3-PMAD Protocol Metadata Anomaly Detection.
- Administrative Network Activity Analysis (D3-ANAA): administrative protocol use. See D3-ANAA Administrative Network Activity Analysis.
Practitioner checklist
- List each in-scope protocol with the source that parses it to command level.
- Choose application or audit logs for encrypted protocols.
- Write a command allowlist per critical service, tied to client identity and role.
- Start with write, control, firmware, replication and administrative commands.
- Pilot in alert-only mode and document every exclusion.
- Keep detection rules separate from any inline blocking decision in OT.
- Replay test commands each quarter and record which rules fired.
- Monitor parser decode rates and log source health.
- Restrict access to command logs that may contain credentials.
Standards and references
- MITRE D3FEND: Application Protocol Command Analysis (D3-APCA)
- MITRE D3FEND: Remote Firmware Update Monitoring (D3-RFUM)
- NIST: SP 800-82 Rev. 3 Guide to Operational Technology (OT) Security
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- Suricata: Modbus keyword
- Suricata: DNP3 keywords
- Suricata: FTP keywords
- Zeek: Modbus protocol analyser script reference
- Kubernetes: Auditing
Related NHI Mgmt Group resources: MITRE D3FEND Guide · NDR Guide · Zeek Network Monitoring Guide · OT Network Security Monitoring Guide · MITRE D3FEND Remote Firmware Update Monitoring Implementation Guide