DC0112: API Calls

API-call evidence matters because mobile application behavior is often visible through what services, device capabilities, or operating-system interfaces the app invokes. For leaders, the value is not that an API call is inherently malicious; it is that API-call telemetry can help validate whether mobile activity is consistent with expected business use or requires investigation.

Executive priority

Treat this as a coverage and evidence question for mobile security readiness: can the organization preserve and review application API-call activity when investigating suspicious mobile behavior? Because ATT&CK provides no specific tactic, platform detail, or detection guidance for this data component, priority should be based on local mobile risk, regulated data exposure, and incident response evidence requirements.

Technical view

SOC, detection engineering, and IR teams should confirm whether mobile application API-call activity is available from approved telemetry sources and whether it can be correlated with application identity, device context, user context, timestamps, and other mobile events. Since no ATT&CK relationships or detection text are supplied, detections should be locally validated against known-good application behavior rather than assumed from this data component alone.

Likely telemetry

Mobile application API-call logs or traces where available
Application identity and version metadata
Device and user context associated with application activity
Timestamps and event correlation data
Related mobile security or application monitoring events

Detection direction

Validate whether API-call telemetry is actually collected for relevant mobile applications and retained long enough for investigations.
Baseline expected API-call patterns for business-approved applications before alerting on deviations.
Correlate API-call activity with device, user, and application context to reduce false positives.
Document blind spots where mobile operating system, application architecture, privacy controls, or tooling limits prevent API-call visibility.
Avoid treating API-call presence alone as malicious without supporting context.

Mitigation priorities

Prioritize inventory of mobile applications and the telemetry sources that can observe their behavior.
Define incident response evidence requirements for mobile application investigations, including API-call visibility where feasible.
Use least-privilege and approved application governance to reduce unnecessary access to sensitive device or service interfaces.
Review retention, privacy, and compliance requirements before expanding collection of application-level telemetry.
Test detection assumptions with benign application behavior and documented investigative scenarios.

Analyst notes and limits

This object is a mobile ATT&CK data component, not a technique. It describes API calls utilized by an application that could indicate malicious activity, but the supplied record includes no tactics, platforms, detection text, or relationship context. The practical takeaway is to validate evidence availability and analytic usefulness rather than infer a specific threat behavior.

The source fields are sparse. No official detection guidance, related techniques, platforms, or relationships were supplied, so this take cannot identify specific malicious patterns, affected mobile platforms, or guaranteed detection methods. Local environment telemetry and application baselines are required.

Official MITRE ATT&CK definition

API Calls

API calls utilized by an application that could indicate malicious activity

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release: 19.1
Object version: 2.1
Created: Mar 13, 2023, 19:59 UTC (UTC+00:00)
Modified: May 12, 2026, 15:12 UTC (UTC+00:00)
Raw hash: 4d66b865c32d6820...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	2.1	May 12, 2026, 15:12 UTC (UTC+00:00)	Current bundle	`4d66b865c32d…`

Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

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 DC0112
Open source URL

Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use

Analyst context for executives and security teams