AN1924: Analytic 1924
Consult asset management systems which may help with the detection of computer systems or network devices that should not exist on a network. Monitor for network traffic originating from unknown/unexpected devices or addresses. Local network traffic metadata could be used to identify unexpected connections, including unknown/unexpected source MAC addresses connecting to ports associated with operational protocols. Also, network management protocols such as DHCP and ARP may be helpful in identifying unexpected devices. Monitor for new master devices communicating with outstations, which may be visible in alarms within the ICS environment. Monitor for unexpected ICS protocol functions from new and existing devices. Monitoring known devices requires ICS function level insight to determine if an unauthorized device is issuing commands (e.g., a historian). Monitor for new master devices communicating with outstation assets, which may be visible in asset application logs.
Analyst context for executives and security teams
This analytic is about finding devices that should not be present or should not be talking in an ICS network. For executives and security leaders, the value is operational assurance: unknown devices, unexpected masters, or unauthorized ICS functions can undermine trust in control-system communications even before a confirmed incident is declared.
Executive priority
Prioritize this as an asset visibility and operational resilience question: can the organization prove which devices are expected on ICS networks, which systems are authorized to act as masters, and which devices are allowed to issue operational protocol functions? The decision value is strongest for incident readiness, audit evidence, and cyber-physical risk reduction because weak asset inventories or missing network metadata can delay containment decisions in industrial environments.
Technical view
SOC, IR, and detection teams should validate whether asset management systems, local network metadata, DHCP, ARP, ICS application logs, and ICS alarms can identify unknown source MAC addresses, unexpected addresses, new master-to-outstation communications, and unexpected ICS protocol functions. The supplied ATT&CK object does not specify platforms or tactics, so implementation should be mapped to the local ICS architecture and protocol set rather than assumed from ATT&CK metadata.
Likely telemetry
- Asset management system records for expected computers and network devices
- Local network traffic metadata, including source addresses and source MAC addresses
- DHCP activity that can reveal new or unexpected devices
- ARP activity that can reveal local network presence and address mappings
- ICS protocol metadata, especially functions issued by new or existing devices
Detection direction
- Baseline expected devices, addresses, MAC addresses, masters, outstations, and permitted ICS protocol functions before alerting aggressively.
- Tune detections for unknown or unexpected devices connecting to ports associated with operational protocols.
- Validate alerts for new master devices communicating with outstations using ICS alarms and asset application logs where available.
- Include known devices in monitoring; the object explicitly notes that an unauthorized device role or command source may come from a system that is otherwise known, such as a historian issuing commands.
- Account for false positives from maintenance windows, commissioning, replacements, temporary engineering workstations, and legitimate network changes.
Mitigation priorities
- Establish and maintain an authoritative ICS asset inventory with expected network identities and roles.
- Define approved master/outstation relationships and permitted ICS protocol functions for critical assets.
- Ensure network monitoring covers local traffic metadata and management protocols such as DHCP and ARP where appropriate.
- Integrate ICS alarms and asset application logs into SOC or incident response workflows for validation of new master communications.
- Create change-control and maintenance processes that distinguish authorized new devices from unexpected network presence.
Analyst notes and limits
This is a detection analytic from the ICS ATT&CK domain, external ID AN1924, tied to MITRE URL https://attack.mitre.org/detectionstrategies/DET0792#AN1924. Its practical emphasis is not a single signature but a visibility pattern: compare observed ICS network behavior against an expected asset and communication baseline.
The supplied object has no official detection field, no platforms, no tactics, and no relationship context. This take therefore cannot infer affected technologies, adversary use, active exploitation, or guaranteed coverage. Local ICS architecture, protocols, logging availability, and asset inventory quality determine how actionable the analytic is.
Analytic 1924
Consult asset management systems which may help with the detection of computer systems or network devices that should not exist on a network. Monitor for network traffic originating from unknown/unexpected devices or addresses. Local network traffic metadata could be used to identify unexpected connections, including unknown/unexpected source MAC addresses connecting to ports associated with operational protocols. Also, network management protocols such as DHCP and ARP may be helpful in identifying unexpected devices. Monitor for new master devices communicating with outstations, which may be visible in alarms within the ICS environment. Monitor for unexpected ICS protocol functions from new and existing devices. Monitoring known devices requires ICS function level insight to determine if an unauthorized device is issuing commands (e.g., a historian). Monitor for new master devices communicating with outstation assets, which may be visible in asset application logs.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | b758b2034970… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1924Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.