Beyond the Sandbox: Leveraging Android Intrusion Logs to Expose Advanced Threats

Executive Summary

Some of the most important activity on a compromised Android device occurs when a threat attempts to move beyond the normal application sandbox: an unexpected process starts, a shell is opened, or a binary is staged outside the application’s lifecycle. Understanding those activities requires a multi-layered detection strategy, correlating trusted on-device operating-system telemetry with comprehensive real-time, run-time device, application, network, and phishing analysis.

Android provides that visibility through complementary security and network logging capabilities. For managed devices, Delegated Scope allows an enterprise to grant a specialized security application access to security logs without transferring broader device-management authority. Zimperium Mobile Threat Defense (MTD) has supported this model since Security Logging became available through Delegated Scope, working with our MDM integration partners to help enterprises use these signals for advanced detection and analysis.

Android’s new Intrusion Logging capability extends this value to another important group: users of supported devices who can now choose to collect and securely share similar security, DNS, and connection evidence through Advanced Protection. The objective is consistent—preserve high-value, OS-generated context so defenders can better understand what happened on a device regardless if it is a BYOD or Enterprise managed device.

What is Delegated Scope and how does Zimperium leverage its insights?

For years, Android has provided a secure way for enterprises to gather crucial forensic data from managed devices using a least-privilege model known as Delegated Scope. This architecture allows an organization's MDM to grant a specialized security application access to OS-level security and network logs without transferring broader device-management authority. The division of responsibility is deliberate: the MDM manages the device and applies policy, while a dedicated security solution handles threat detection and analysis.

Zimperium has long supported Delegated Scope, working closely with our MDM integration partners to make this security configuration practical and seamless for enterprises. Instead of relying on manual forensic workflows or keeping devices in vulnerable developer configurations, Delegated Scope allows Android to securely deliver relevant security audit data to Zimperium Mobile Threat Defense (MTD) as a standing collection strategy, for both detection and threat forensics.

By ingesting structured audit streams—such as process starts with associated file hashes, package-attributed DNS lookups, and exact ADB shell commands—MTD gains deep, system-level visibility. When correlated with Zimperium’s real-time, on-device behavioral AI engine, these OS signals empower our Deep Scan technology to turn isolated alerts into comprehensive, defensible forensic timelines.

That enterprise model remains highly valuable for managed fleets. But how does this necessary forensic visibility translate to the growing number of BYOD users? Enter Android’s new Intrusion Logging.

Intrusion Logging: Extending Access Through Advanced Protection

In 2026, Google introduced Intrusion Logging as part of Android Advanced Protection. Intrusion Logging now makes comparable evidence available through a user-controlled workflow. On supported devices—initially Pixel devices running Android 16 or later—the owner opts in through Advanced Protection. Android encrypts the logs on the device using keys protected by the user’s Google Account credentials and screen lock, then stores the encrypted archive for twelve months. Google cannot decrypt the content. When analysis is needed, the owner explicitly downloads, decrypts, and shares the logs. This privacy-preserving design gives the user control over highly useful, and potentially sensitive, forensic data.

This feature is an important evolution in consensual mobile forensics: it creates a purpose-built, longer-lived record of security-relevant activity that a device owner can share with a trusted analyst.

An Intrusion Logging bundle contains three complementary event categories: SecurityLog-derived security events, DNS events, and connection events. Many of the security events will be familiar to enterprises already using delegated Security Logging. Amnesty International’s Security Lab, a design partner of the new Intrusion Logging feature, highlighted several use cases that would add a lot of value in a real investigation. For example:

• A successful unlock, if you need to know whether the phone was used while it was out of the owner’s hands:
  
  

  {"security_event":{"keyguard_dismiss_auth_attempt":{"success":true,"method_strength":1}}}

• An ADB command, if you need to know whether someone, or some piece of malware, had a shell:
  
  

  {"security_event":{"adb_shell_cmd":{"command":"logcat"}}}

• A DNS lookup attributed to a package, so a hostname is no longer an orphan indicator:
  
  

  {"dns_event":{"package_name":"com.android.chrome","hostname":"www.web.com","ip_addresses":["/1XX.YYY.ZZZ.WWW"]}}

The DNS and connection records provide the same kind of package attribution that enterprises have used through delegated Network Logging. The distinction is primarily one of control and delivery: Delegated Scope is administered through enterprise policy on managed devices, while Intrusion Logging lets an individual user securely share a forensic archive without requiring full-device MDM enrollment.

MTD now supports this user-initiated path also. It complements rather than replaces the managed-device model. For BYOD users, contractors, and other users whose entire device may not be enrolled, Intrusion Logging provides a user initiated, consent-driven way to share security and network evidence for analysis.

On supported devices, enablement is available under Settings → Security & privacy → Advanced Protection → Intrusion Logging. The user must enable it before an incident for relevant activity to be preserved. Our MDM partners continue to enable the delegated logging scopes for managed devices.

Let’s take a look at a real-world malware example (RatHat) and value from enabling Intrusion Logging on Android.

RatHat: Intrusion Log Insights

In our initial analysis of RatHat, the zLabs research team unveiled an evasive Android threat that deliberately abandons the standard mobile application sandbox. Distributed via targeted lures and aggressive social engineering, RatHat pairs Accessibility abuse with autonomous local Wireless Debugging self-pairing. This technique allows it to break into an elevated shell environment (UID 2000), stage independent Go daemons, and persist out of its lifecycle even if a user uninstalls the main application.

While decompiling APK bytecode and reverse-engineering native libraries exposes an adversary's capabilities, threat researchers and incident responders face an immediate operational reality: static analysis reveals only intent. To uncover the actual execution and impact, they require a comprehensive solution that unifies a multi-layered Mobile Threat Defense (MTD) with deep, continuous OS-level forensic telemetry.

When an endpoint is compromised, forensic teams must verify whether the pairing sequence succeeded, what shell commands executed, and whether lateral movement or external command-and-control (C2) established a bridge. Android Intrusion Logs—specifically enterprise-level Android Security Logs and Network Logging—serve as an indispensable tool to reconstruct this attack chain and harvest dynamic Indicators of Compromise (IOCs).

Case Study: Tracking RatHat in Android Intrusion Logs

Correlating the technical behavior documented in our RatHat analysis with live security and network audit logs collected from an infected device exposes the entire kill chain.

Android Enterprise Intrusion Logs

Execution Footprint and Dual Keep-Alive Watchdogs

In the intrusion logs, the execution begins when the zygote forks the malicious package com.wkfuhirj.lchmwg (UID 10023):

Within milliseconds of launch, the malware spawns two distinct helper processes (guard1 and guard2). This directly mirrors the dual watchdog architecture identified in the RatHat reversing analysis, designed to enforce a silent recovery loop and redeploy background services if terminated.

Immediately following process initialization, the log records a key creation event:

This artifact identifies the initialization of RatHat's cipher subsystem, which handles on-device encryption for harvested lock-screen PINs, pattern geometry, and stolen credentials before exfiltration.

Evasion, Probing, and Network Masquerading

RatHat employs multi-tiered anti-analysis checks. Network logging captures the malware initiating active evasion probes against the local interface:

Connecting to TCP port 27042 is a standard probe to identify an active Frida server on the endpoint.

Simultaneously, the malware disguises its traffic behind a legitimate streaming service lure. Network events document rapid domain queries and HTTPS sessions to www.apps.disneyplus.com, disney.api.edge.bamgrid.com, and login.disney.com, leveraging embedded Chromium WebView instances to present an authentic interface to the user while covert setup actions proceed in the background.

Wireless Debugging Self-Pairing Dance

The turning point in RatHat’s infection chain is its pivot into local ADB. In network logging, this manifests as connections from the malicious package to high-range dynamic ports on localhost:

These sockets reflect the two-stage pairing workflow:

1. Authenticating against the local pairing port (41625) using the scraped pairing code.
2. Connecting to the active Wireless Debugging daemon port (35933) to instantiate a privileged shell session (UID 2000).

Privileged Staging and System Tampering via TAG_ADB_SHELL_CMD

Following loopback pairing, the security log records an adb_shell_interactive event, followed by shell commands executed under the shell identity. These entries capture binary staging into /data/local/tmp:

The malware extracts its Go agent (liblocal-service.so) directly from its APK native library path and stages it as /data/local/tmp/local-service. It then extracts the Fast Reverse Proxy client (frpc) from its external storage cache and stages it into /data/local/tmp/frpc, applying chmod 777 to execute both as out-of-lifecycle daemons.

Immediately after staging, the shell executes system modification commands to disable battery optimization and bypass Android background execution boundaries:

Steady-State Operation: Local Loopback IPC & Persistent C2 Egress

Once the daemons are active, the operational loop begins:

• Local Loopback IPC: The app initiates continuous loopback sockets to 127.0.0.1:7912 at short intervals. This represents the Java client communicating with the local Go daemon to relay commands and touch-logging data outside the view of normal application framework APIs.
• External Command & Control (C2): Simultaneously, the application resolves fegrs.adidasabc.com via DNS and maintains an outbound HTTPS connection to 8.231.120.246:443 every 60–90 seconds, serving as its primary external heartbeat and orchestration pipeline.

Recovered Incident Indicators of Compromise (IOCs)

Reconstructing the raw log files extracts forensic-grade indicators across every phase of execution:

How Zimperium MTD Detects and Neutralizes the Attack Chain

RatHat’s multi-tiered architecture, reliance on out-of-lifecycle daemons, and use of real-time GenAI decision loops illustrate why traditional, signature-based mobile security controls are insufficient. To effectively combat these sophisticated attacks, both enterprises and individual users require a corresponding multi-tiered detection solution. Defending against advanced mobile threats now demands a combination of real-time, on-device protection to stop the attack as it unfolds, paired with defensible forensics to validate the full scope of a compromise. Zimperium’s Mobile Threat Defense (MTD) provides this comprehensive zero-day coverage and forensic depth across every stage of the attack chain.

Zimperium Mobile Threat Defense (MTD)

For enterprise and BYOD mobile devices, Zimperium MTD detects and neutralizes RatHat through its use of on-device, dynamic detection engine and advanced operating-system telemetry:

• Zero-Day Malware Detection: Powered by a real-time, run-time AI engine, MTD flags the dropper and secondary payloads without relying on cloud-tethered lookups or static signatures, remaining unaffected by the bundle manipulation tailored to prevent analysis.
• Privilege Escalation & ADB Abuse: MTD monitors behavioral indicators as they occur, alerting on anomalous Accessibility Service exploitation, synthetic developer option activation, and local loopback pairing attempts targeting the device's internal ADB daemon.
• Network & Phishing Protection: MTD’s on-device web protection blocks malicious domains used in the initial smishing and malvertising distribution stages, while isolating active C2 communications and FRP reverse-proxy tunnels. This effectively prevents malicious actors from remotely controlling the device.
• Enterprise Visibility via Delegated Scope & Deep Scan: On managed devices, MTD leverages Android's Delegated Scope to securely access OS-level Security and Network Logs without requiring full MDM authority. MTD uses these complementary logs for advanced detection and deeper analysis through Deep Scan. This allows security teams to trace the exact execution of out-of-lifecycle daemons and connect isolated network events directly to the malicious application responsible.
• Consensual Forensics with Intrusion Logging: MTD also supports Android's new Intrusion Logging capability to extend this forensic depth to BYOD and supported personal devices. Through a privacy-preserving, user-controlled workflow, users can securely share a protected bundle of security, DNS, and connection events.

When real-time behavioral detection is paired with the evidentiary depth of Android Intrusion Logs and Deep Scan, organizations can achieve true full-lifecycle defense—detecting the initial intrusion as it happens and retaining complete visibility across every layer of the operating system.