DC0119: Application Assets
Application Assets represent static or packaged resources bundled with an application that may contain executable logic, configuration data, or hidden payloads.
These assets may include embedded binaries, scripts, configuration files, libraries, or other resources stored within the application package. Adversaries may hide malicious components within application assets to evade detection during installation or initial inspection.
Examples
Android:
- Embedded .dex files loaded dynamically - Hidden native libraries in APK assets - Dropped payloads stored within the app sandbox
iOS:
- Embedded frameworks - Configuration files within the application bundle - Hidden scripts or secondary binaries packaged with the app
Collection Methods - Mobile EDR application inspection - Static application analysis - Application package scanning during install or sideload events
Analyst context for executives and security teams
Application Assets are the static resources bundled inside a mobile app package, such as libraries, configuration files, embedded binaries, scripts, or hidden payloads. The business significance is that risk may be present before an app ever runs: malicious or risky logic can be packaged in places that basic installation checks or superficial reviews may miss. For leaders, this makes mobile application vetting, sideload governance, and inspection evidence important parts of mobile risk management.
Executive priority
Prioritize this where the organization allows enterprise mobile apps, third-party mobile apps, sideloading, or mobile apps that handle sensitive business data. The key decision is whether the organization can prove that mobile application packages are inspected beyond app metadata and permissions, including packaged assets that may contain executable logic or configuration. This supports incident readiness, compliance evidence, and control assurance for mobile application risk.
Technical view
SOC, mobile security, and IR teams should validate whether their mobile inspection process can identify suspicious or unexpected packaged resources inside application bundles. MITRE lists collection methods including Mobile EDR application inspection, static application analysis, and application package scanning during install or sideload events. Since no official detection logic is provided, teams should focus on coverage validation: whether embedded binaries, scripts, configuration files, libraries, embedded .dex files, hidden native libraries, embedded frameworks, secondary binaries, and dropped payload-like resources are visible to tooling and retained for analysis.
Likely telemetry
- Mobile EDR application inspection results
- Static mobile application analysis output
- Application package scan results during install events
- Application package scan results during sideload events
- Inventories of packaged application resources such as libraries, scripts, configuration files, binaries, frameworks, and embedded executable artifacts
Detection direction
- Confirm that mobile app inspection covers packaged assets, not only permissions, signatures, or app store metadata.
- Tune review workflows to flag unexpected executable logic, embedded libraries, secondary binaries, or configuration files inside application packages when inconsistent with the app’s stated purpose.
- Validate visibility during sideload events, because packaged assets may be present before runtime behavior is observed.
- Account for false positives: legitimate apps may include frameworks, libraries, configuration files, or embedded resources for normal functionality, so findings require application context and baseline comparison.
- Because ATT&CK provides no official detection text and no relationships for this object, detection engineering should be based on local mobile app inventories, approved application behavior, and inspection-tool evidence.
Mitigation priorities
- Establish or verify mobile application package scanning for enterprise-approved apps and sideloaded apps.
- Require static analysis or Mobile EDR inspection for apps that access sensitive business data or are distributed outside tightly controlled channels.
- Maintain an approved inventory of expected mobile applications and, where feasible, expected packaged components for high-risk apps.
- Use inspection results as evidence for mobile governance, incident response triage, and compliance readiness.
- Escalate suspicious packaged assets to mobile malware analysis or incident response workflows rather than relying on installation-time checks alone.
Analyst notes and limits
This data component is most useful as a coverage checkpoint: can the organization see what is bundled inside mobile applications before or during installation? The supplied ATT&CK object is a data component, not a technique, and has no tactics, platforms, relationships, aliases, or official detection logic. Android and iOS examples are present in the official description, but the object’s platform field is not specified.
Assessment requires local evidence from mobile EDR, static analysis, application package scanning, install or sideload monitoring, and application inventory processes. The supplied ATT&CK fields do not support claims about active exploitation, specific adversaries, prevalence, business impact, or guaranteed detection coverage.
Application Assets
Application Assets represent static or packaged resources bundled with an application that may contain executable logic, configuration data, or hidden payloads.
These assets may include embedded binaries, scripts, configuration files, libraries, or other resources stored within the application package. Adversaries may hide malicious components within application assets to evade detection during installation or initial inspection.
Examples
Android:
- Embedded .dex files loaded dynamically - Hidden native libraries in APK assets - Dropped payloads stored within the app sandbox
iOS:
- Embedded frameworks - Configuration files within the application bundle - Hidden scripts or secondary binaries packaged with the app
Collection Methods - Mobile EDR application inspection - Static application analysis - Application package scanning during install or sideload events
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 | 2.1 | Current bundle | 87f2197eca8f… |
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 DC0119Open 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.