AN1885: Analytic 1885
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
This analytic is about using operating-system API monitoring on devices that allow user access to the underlying OS. For leaders, the practical point is not “collect everything”: API monitoring can create large volumes of noisy data, and normal software often uses the same API functions. Its value is highest when used selectively and correlated with other events during investigation, high-risk change windows, or known suspicious activity.
Executive priority
Treat API monitoring as a targeted detection and incident-response capability rather than a default enterprise-wide control. In ICS environments, excessive endpoint telemetry can create cost, storage, and analyst-noise issues, while insufficient context can leave responders unable to explain suspicious host behavior. Leaders should ask whether SOC and IR teams know when API-level visibility is justified, how it is governed, and what other evidence sources are available to make the data actionable.
Technical view
The supplied ATT&CK analytic has no specified platform, tactic, or detection logic. The official description supports a narrow validation objective: where devices permit OS-level user access and installation of custom monitoring software, determine whether API-call telemetry can be collected under controlled circumstances and correlated with surrounding events. SOC and IR teams should avoid treating individual API calls as inherently malicious; the analytic value comes from context, timing, process/user association, and correlation with other host or operational events.
Likely telemetry
- OS API call monitoring data from devices where such monitoring is technically and operationally permitted
- Process execution and process lineage context surrounding API activity
- User/session context associated with the monitored OS activity
- Host event logs or endpoint activity records that can be correlated with API calls
- Change, maintenance, or investigation timelines used to distinguish expected from suspicious behavior
Detection direction
- Validate whether API monitoring is feasible only on relevant devices that expose underlying OS access; do not assume platform coverage because none is specified in the source object.
- Use API-call data as enrichment and correlation evidence, not as a standalone alert source, because benign API usage is common.
- Tune for specific investigative circumstances or correlated behavior rather than broad matching on API function use.
- Assess storage, performance, and analyst-noise implications before expanding collection.
- Document false-positive drivers such as normal administrative activity, approved software, maintenance windows, and legitimate applications calling common APIs.
Mitigation priorities
- Define governance for when OS API monitoring may be installed or enabled on ICS-related devices.
- Prioritize correlation-ready logging first: process, user, host, and event timing context should be available before relying on API-level data.
- Use API monitoring selectively during incident response, validation, or other specific circumstances where higher-fidelity context is needed.
- Review operational impact and data-handling requirements before collecting high-volume API telemetry.
- Maintain clear evidence procedures so API monitoring can support investigation and compliance narratives without overwhelming SOC workflows.
Analyst notes and limits
No ATT&CK relationships were supplied, so this take cannot tie AN1885 to a specific technique, tactic, platform, malware, group, or campaign. The key defensive interpretation is that API monitoring may help explain suspicious behavior when correlated with other events, but the source explicitly warns that the data volume and benign usage patterns can reduce standalone detection value.
Official detection content was not provided, platforms and tactics are not specified, and there is no relationship context. Local architecture, device capability, operational constraints, and existing telemetry must determine whether this analytic is practical or useful.
Analytic 1885
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 | 067646859026… |
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 AN1885Open 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.