S0420: Dvmap
Analyst context for executives and security teams
Dvmap matters because it represents Android malware behavior that moves beyond ordinary app abuse into rooting and modification of system runtime libraries. For leaders, the practical issue is whether mobile devices used for business can still be trusted after suspected compromise, especially where rooted devices could weaken app isolation, security tooling, and code-signing protections.
Executive priority
Prioritize this as a mobile trust and incident-readiness concern rather than only a malware signature issue. Security leaders should ask whether Android fleet controls can identify rooted or tampered devices, whether high-risk mobile access is conditional on device integrity, and whether incident response has a clear path to quarantine, reimage, or retire devices where system libraries or signing policies may have been modified.
Technical view
ATT&CK provides no official detection text for Dvmap, so SOC and IR teams should validate coverage around the related behaviors: exploitation for privilege escalation, obfuscated files or information, runtime code download, system information discovery, system runtime API hijacking, disabling or modifying tools, and code signing policy modification. On Android, the highest-value validation is whether telemetry can show app installation source, post-install code retrieval, root or privilege-escalation indicators, protected system file changes, runtime library integrity changes, and security control tampering.
Likely telemetry
- Android MDM or mobile threat defense posture data showing root status, device integrity, OS version, and patch level
- Application inventory and installation provenance, including sideloaded or unexpected packages
- Network telemetry from mobile devices or gateways showing post-install code or payload downloads
- File and system integrity evidence for protected Android system/runtime libraries where available
- Signals of security tool interference, SELinux or policy changes, or reduced reporting from device security controls
Detection direction
- Because MITRE does not provide Dvmap-specific detection guidance, build detections around behavior chains rather than a single indicator.
- Tune for combinations: suspicious app plus runtime code download plus root/integrity change is more meaningful than any one event alone.
- Validate blind spots on personally owned or lightly managed Android devices, where system-level telemetry may be limited.
- Review false positives from legitimate device management, security testing, OEM update activity, and enterprise apps that legitimately collect device information.
- Use the relationship context to hunt for attempts to alter runtime execution flow, weaken security tools, or modify signing policy after privilege escalation.
Mitigation priorities
- Keep Android devices patched and prioritize vulnerability management for privilege-escalation exposure.
- Restrict business access from rooted, unmanaged, or integrity-failed devices through mobile device management and conditional access where applicable.
- Limit sideloading and require trusted app sources for managed devices.
- Ensure mobile security tooling can report device integrity, suspicious app behavior, and security-control tampering.
- Define IR procedures for suspected system-library modification, favoring device isolation and rebuild or replacement over simple app removal when root-level compromise is suspected.
Analyst notes and limits
The supplied ATT&CK object identifies Dvmap as Android rooting malware that injects malicious code into system runtime libraries and links it to several mobile techniques. The decision value is in testing whether the organization can detect and respond to mobile privilege escalation, runtime code loading, and system tampering, not in assuming a Dvmap-specific alert exists.
No official ATT&CK detection content, aliases, labels, or tactics were supplied. This take is limited to the Android platform, the Dvmap description, the SecureList reference, and the listed ATT&CK relationships. Local device management coverage and telemetry availability must be verified before assessing exposure or detection readiness.
Dvmap
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1407 | Download New Code at Runtime | Dvmap can download code and binaries from the C2 server to execute on the device as root.CitationSecureList DVMap June 2017 |
| Mobile | T1625.001 | System Runtime API Hijacking Sub-technique | Dvmap replaces `/system/bin/ip` with a malicious version. Dvmap can inject code by patching `libdmv.so` or `libandroid_runtime.so`, depending on the Android OS version. Both libraries are related to the Dalvik and ART runtime environments. The patched functions can only call `/system/bin/ip`, which was replaced with the malicious version.CitationSecureList DVMap June 2017 |
| Mobile | T1426 | System Information Discovery | Dvmap checks the Android version to determine which system library to patch.CitationSecureList DVMap June 2017 |
| Mobile | T1632.001 | Code Signing Policy Modification Sub-technique | Dvmap can enable installation of apps from unknown sources.CitationSecureList DVMap June 2017 |
| Mobile | T1629.003 | Disable or Modify Tools Sub-technique | Dvmap can turn off `VerifyApps`, and can grant Device Administrator permissions via commands only, rather than using the UI.CitationSecureList DVMap June 2017 |
| Mobile | T1404 | Exploitation for Privilege Escalation | Dvmap attempts to gain root access by using local exploits.CitationSecureList DVMap June 2017 |
| Mobile | T1406 | Obfuscated Files or Information | Dvmap decrypts executables from archive files stored in the `assets` directory of the installation binary.CitationSecureList DVMap June 2017 |
All related ATT&CK context
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 | 38f1650c781a… |
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]
SecureList DVMap June 2017
R. Unuchek. (2017, June 8). Dvmap: the first Android malware with code injection. Retrieved December 10, 2019.
Open source URL -
[2]
mitre-attack S0420Open 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.