AN1875: Analytic 1875
Devices that provide user access to the underlying operating system may allow the installation of custom software to monitor OS API execution. Monitoring API calls may generate a significant amount of data and may not be useful for defense unless collected under specific circumstances, since benign use of API functions are common and may be difficult to distinguish from malicious behavior. Correlation of other events with behavior surrounding API function calls using API monitoring will provide additional context to an event that may assist in determining if it is due to malicious behavior.
Analyst context for executives and security teams
AN1875 highlights a defensive option for ICS environments where some devices expose access to the underlying operating system: monitoring OS API calls. The business value is not in collecting every API event, but in deciding when this high-volume telemetry is justified for incident response, validation of suspicious activity, or deeper investigation on systems where custom monitoring software can be installed.
Executive priority
Treat this as a targeted investigation and readiness capability, not a default enterprise-wide control. Leaders should ask which ICS assets actually permit OS-level access and custom monitoring, whether the volume and sensitivity of API telemetry can be handled, and when this evidence would be needed to support incident decisions, audit narratives, or operational resilience investigations. Because benign API use is common, budget and process should prioritize correlation and analyst workflow over raw collection alone.
Technical view
For SOC, detection engineering, and IR teams, the key validation is whether API monitoring can be deployed on relevant ICS devices and whether the resulting events can be correlated with surrounding activity. The official description notes that API calls are noisy and difficult to interpret in isolation, so teams should avoid treating single API events as high-confidence detections without additional context. Since no ATT&CK platforms, tactics, or explicit detection logic are provided, local scoping is required before building rules or response playbooks.
Likely telemetry
- OS API call monitoring from devices that allow user access to the underlying operating system
- Events from custom software installed for API monitoring where permitted
- Correlated host or device activity surrounding API function calls
- Investigation context from other events that occur before, during, or after suspicious API activity
Detection direction
- Validate whether any in-scope ICS devices support safe installation of custom API monitoring software.
- Use API monitoring selectively because benign API calls are common and event volume may be significant.
- Prioritize correlation with surrounding events rather than alerting on API calls alone.
- Define collection triggers, investigation use cases, and retention expectations before enabling high-volume monitoring.
- Document blind spots where devices do not expose OS access or cannot safely support custom monitoring.
Mitigation priorities
- Inventory ICS devices that provide user access to the underlying operating system and determine whether API monitoring is technically and operationally feasible.
- Establish when API monitoring should be enabled, such as during focused investigation or heightened monitoring, rather than assuming continuous collection is appropriate.
- Ensure collected API telemetry can be correlated with other event sources before relying on it for detection decisions.
- Create analyst guidance for distinguishing common benign API use from behavior requiring escalation.
- Review operational risk before installing custom monitoring software on sensitive ICS devices.
Analyst notes and limits
This object is a detection analytic in the ICS ATT&CK domain. Its useful decision point is telemetry governance: API monitoring may provide valuable context, but only when scoped to devices where OS-level access and custom monitoring are possible and when correlated with other evidence.
The supplied ATT&CK fields do not specify platforms, tactics, related techniques, detection logic, mitigations, or relationships. No claim can be made that this analytic detects a specific adversary behavior by itself or applies to all ICS assets. Local architecture, device safety constraints, and available telemetry determine practical applicability.
Analytic 1875
Devices that provide user access to the underlying operating system may allow the installation of custom software to monitor OS API execution. Monitoring API calls may generate a significant amount of data and may not be useful for defense unless collected under specific circumstances, since benign use of API functions are common and may be difficult to distinguish from malicious behavior. Correlation of other events with behavior surrounding API function calls using API monitoring will provide additional context to an event that may assist in determining if it is due to malicious behavior.
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 | e40f22a87158… |
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 AN1875Open 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.