AN1739: Analytic 1739
Correlates anomalous modifications to boot-time or logon-time initialization artifacts (for example, init.rc, vendor init scripts, app_process or shell hijacks, and malicious BOOT_COMPLETED BroadcastReceivers) with subsequent unauthorized script execution after boot. From the defender’s perspective this appears as integrity or attestation failures on the system partition, unexpected writes to protected init paths, new apps registering for boot events, and privileged processes invoking scripts or binaries from non-standard locations shortly after the device boots.
Analyst context for executives and security teams
This Android detection analytic matters because it focuses on persistence that survives device reboot: changes to boot-time or logon-time initialization artifacts followed by unauthorized script execution after boot. For leaders, the practical issue is not just malware on a phone; it is whether managed mobile devices can be trusted after restart and whether integrity, attestation, and boot-event monitoring can prove that protected system areas have not been altered.
Executive priority
Prioritize this where Android devices support regulated work, privileged users, field operations, or cyber-physical workflows. The business question is whether the organization can detect and respond when a device’s startup path is modified to re-run unauthorized code. This supports mobile security assurance, incident response scoping, compliance evidence for device integrity controls, and decisions about isolating or re-enrolling suspect devices.
Technical view
Validate Android-focused monitoring for anomalous modification of boot-time or logon-time initialization artifacts, including init.rc, vendor init scripts, app_process or shell hijacks, and apps registering BOOT_COMPLETED BroadcastReceivers. The analytic’s decision point is correlation: integrity or attestation failures, unexpected writes to protected init paths, or new boot-event registrations should be linked with privileged processes invoking scripts or binaries from non-standard locations shortly after boot. No ATT&CK tactics or relationship context were supplied, so teams should map this locally to their mobile threat model and response playbooks.
Likely telemetry
- Android device integrity or attestation results
- System partition integrity signals
- File or configuration change evidence for protected init paths
- Application manifest or registration evidence for BOOT_COMPLETED BroadcastReceivers
- Process execution telemetry after device boot
Detection direction
- Test whether telemetry is retained across device reboot and available quickly enough to correlate startup changes with post-boot execution.
- Tune for combinations of signals rather than single events: protected-path modification, boot-event registration, integrity failure, and privileged execution from unusual locations.
- Review false positives from legitimate OS updates, vendor maintenance activity, enterprise mobile management actions, or approved applications that register for boot events.
- Identify blind spots on unmanaged Android devices, devices without attestation, limited process telemetry, or insufficient visibility into protected system paths.
- Ensure alert triage includes device boot time, modified artifact, registering application, executing process, path reputation, and whether the device remains compliant.
Mitigation priorities
- Establish a trusted baseline for Android device integrity and boot-related configuration where supported.
- Require mobile management or security controls that can surface attestation failures, system partition integrity issues, and suspicious boot-event registrations.
- Restrict or review applications that request boot-start behavior, especially on devices used by privileged users or operational teams.
- Define incident response actions for suspect persistence after reboot, such as isolation, evidence preservation, re-enrollment, or device replacement based on local policy.
- Use findings as compliance evidence for mobile device integrity monitoring and response readiness rather than assuming the analytic alone proves full coverage.
Analyst notes and limits
The supplied object is a detection analytic for Android in the mobile ATT&CK domain. Its value comes from correlating boot/startup artifact modification with unauthorized execution shortly after reboot. Because no official detection text, tactics, or relationships were supplied, local validation is required to determine exact data sources, thresholds, and response actions.
This take is limited to the provided ATT&CK fields and external reference for AN1739. It does not establish active exploitation, attribution, prevalence, impact, or guaranteed detectability. Coverage depends on Android fleet management, attestation support, endpoint telemetry depth, and access to startup-related file, application, and process evidence.
Analytic 1739
Correlates anomalous modifications to boot-time or logon-time initialization artifacts (for example, init.rc, vendor init scripts, app_process or shell hijacks, and malicious BOOT_COMPLETED BroadcastReceivers) with subsequent unauthorized script execution after boot. From the defender’s perspective this appears as integrity or attestation failures on the system partition, unexpected writes to protected init paths, new apps registering for boot events, and privileged processes invoking scripts or binaries from non-standard locations shortly after the device boots.
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.1 | Current bundle | f37c3585282c… |
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 AN1739Open 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.