AN1727: Analytic 1727
The defender correlates application registration for system event triggers (e.g., broadcast receivers, WorkManager, JobScheduler, SMS/BOOT events) with subsequent execution of application code immediately following the triggering event, without direct user interaction. Confidence increases when execution occurs in background or locked state, is tied to sensitive triggers (SMS received, boot completed, connectivity change), and produces follow-on file or network activity inconsistent with the application’s expected role.
Analyst context for executives and security teams
This analytic is about finding Android apps that wake up and run code automatically after system events, such as SMS receipt, device boot, or connectivity changes, without a user opening the app. For leaders, the practical value is assurance that mobile security monitoring can distinguish expected background behavior from suspicious persistence or automation patterns that may create data-loss, fraud, privacy, or operational risk on managed Android devices.
Executive priority
Prioritize this where Android devices are used for sensitive business workflows, regulated data access, field operations, or executive communications. The key decision is whether the organization has enough mobile telemetry and policy control to prove that apps registering for sensitive system triggers are expected, governed, and monitored. This supports incident readiness, compliance evidence around mobile device oversight, and budget decisions for mobile detection and response capabilities.
Technical view
SOC and detection teams should validate whether Android telemetry can correlate three elements: an app’s registration for system event triggers, the relevant system event occurring, and application code executing immediately afterward without direct user interaction. Higher-priority cases include execution while the device is locked or in the background, triggers such as SMS received, boot completed, or connectivity change, and follow-on file or network activity that does not match the application’s expected role. Because no ATT&CK tactic or relationship context is supplied, this should be treated as a behavior-level mobile detection analytic rather than evidence of a specific campaign or technique chain.
Likely telemetry
- Android application registration or manifest data for broadcast receivers, WorkManager, JobScheduler, and related system-trigger mechanisms
- System event logs or mobile security telemetry for SMS received, boot completed, connectivity change, and similar triggers
- Application execution telemetry showing background or locked-state activity without direct user interaction
- Mobile network activity associated with the application after the trigger
- File activity associated with the application after the trigger
Detection direction
- Confirm that the telemetry source can correlate trigger registration, trigger occurrence, and immediate app execution in time order.
- Tune around expected enterprise apps that legitimately run after boot, connectivity changes, scheduled jobs, or messaging events to reduce false positives.
- Prioritize alerts when background or locked-state execution follows sensitive triggers and is followed by unexpected network or file activity.
- Use application allowlists, app ownership, and business-role context to separate managed enterprise behavior from unapproved or anomalous apps.
- Identify blind spots where MDM, EDR, or mobile telemetry shows installed apps but not system-trigger registration, device state, or post-trigger activity.
Mitigation priorities
- Establish an approved Android application inventory and remove or restrict unapproved apps on managed devices.
- Apply mobile device management controls that limit risky app installation sources and enforce baseline device policy where available.
- Review apps that request or use sensitive trigger-based background behavior against their business purpose.
- Ensure mobile incident response playbooks include collection of app inventory, trigger registration evidence, device state, and post-trigger network or file activity.
- Use least-privilege mobile access policies so suspicious background app behavior does not automatically translate into access to sensitive business systems.
Analyst notes and limits
This object is a mobile ATT&CK detection analytic for Android. It focuses on correlation of system-event trigger registration with subsequent background execution and follow-on behavior. No relationships, tactics, aliases, or official detection implementation are supplied, so local engineering must define the exact data sources, timing thresholds, and triage criteria.
The supplied ATT&CK fields do not provide tactic mapping, relationship context, adversary use, mitigation mappings, or vendor-specific detection guidance. This take should not be read as evidence of active exploitation or as confirmation that any environment has coverage; coverage depends on Android telemetry depth and local mobile management controls.
Analytic 1727
The defender correlates application registration for system event triggers (e.g., broadcast receivers, WorkManager, JobScheduler, SMS/BOOT events) with subsequent execution of application code immediately following the triggering event, without direct user interaction. Confidence increases when execution occurs in background or locked state, is tied to sensitive triggers (SMS received, boot completed, connectivity change), and produces follow-on file or network activity inconsistent with the application’s expected role.
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 | 88048c195ce3… |
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 AN1727Open 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.