RatHat Android Malware Uses AI to Automate Device Control — Detection and Response Guide for Defenders

Security researchers have disclosed a new Android malware family dubbed RatHat — a remote access trojan (RAT) that distinguishes itself from the crowded Android threat landscape with an AI-powered subsystem that helps operators remotely navigate compromised devices. Rather than relying solely on pre-scripted accessibility abuse or static UI coordinate taps (the classic approach for Android banking trojans and RATs), RatHat hands screen-state interpretation and navigation decisions to an AI model, allowing an operator to issue high-level objectives — "open the banking app," "approve this transfer," "read the 2FA code" — while the malware works out how to accomplish them on any device, any OS skin, any app version.

This matters for three reasons:

1. UI fragility is gone. Traditional Android overlay/tap automation breaks every time a target app updates its layout. An AI navigation layer adapts dynamically, dramatically lowering the operator's cost per victim and increasing dwell time.
2. The victim pool widens. Device fragmentation (Samsung One UI vs. Pixel vs. Xiaomi MIUI vs. carrier builds) has historically forced RAT operators to maintain per-variant automation scripts. RatHat's approach largely eliminates that constraint.
3. Accessibility-service abuse gets an upgrade. The likely enabler here remains the Android Accessibility API — the same abused by SpyNote, Hook, and GodFather-class malware — but with AI deciding the actions, behavior-based detection on the operator's script logic becomes useless. Detection must shift to the device-side primitives: accessibility service grants, screen capture sessions, overlay windows, and command-and-control traffic.

If your organization permits BYOD Android devices to access corporate email, VPN, or SaaS, you now have an AI-assisted operator potentially sitting inside a managed identity session. This post covers how the threat works from a defender's perspective, what you can realistically detect, and how to contain and remediate.

Technical Analysis

What RatHat Is

RatHat is an Android remote access trojan with a modular architecture consistent with modern commercial-grade Android malware:

• Remote device control — operators can issue commands to interact with the device in near-real time.
• AI-powered navigation subsystem — instead of hard-coded tap sequences, the malware captures screen state (via Accessibility node trees, screenshots, or both), feeds it to an AI model, and receives back structured actions (tap, swipe, type, scroll, back) that are executed on-device through the Accessibility API.
• Operator abstraction layer — the human operator expresses intent; the AI layer translates intent into UI actions. This mirrors the "agentic" pattern now common in legitimate automation tooling, repurposed for intrusion operations.

Affected Platforms

• Platform: Android (all versions where Accessibility Services can be granted to sideloaded applications — effectively the entire supported Android fleet, including Android 13–16, unless the device is hardened by MDM policy)
• Delivery vector (typical for this class): sideloaded APKs via phishing/smishing links, trojanized apps on third-party stores, droppers disguised as legitimate utilities, or malicious links delivered through messaging apps. As of this writing, no CVE is associated with RatHat — it does not require a vulnerability exploit. It relies on social engineering and abuse of legitimate Android APIs, which is precisely what makes it dangerous: there is nothing to patch.
• Exploitation status: Confirmed active in-the-wild distribution per the research disclosure. Not applicable to CISA KEV (no CVE). Treat as an active threat, not a theoretical one.

Attack Chain (Defender's View)

1. Lure & install — victim is socially engineered into installing an APK outside Google Play (or, in some campaigns, a dropper that later fetches the payload).
2. Permission escalation — the app requests high-value permissions: Accessibility Service access, screen capture (MediaProjection), notification read access, and often "display over other apps." Accessibility is the crown jewel — it grants read/write interaction with arbitrary app UIs.
3. C2 establishment — persistent channel to operator infrastructure (frequently WebSocket-based for low-latency interactive control, often wrapped in TLS).
4. AI-assisted operation — screen state is streamed or snapshotted to the operator/AI subsystem; returned actions are injected via Accessibility gestures. The operator can navigate banking apps, approve transactions, harvest OTPs from authenticator/SMS, exfiltrate files, and interact with corporate apps — including email and MFA approval prompts.
5. Persistence & defense evasion — hiding launcher icons, abusing battery-optimization exemptions to survive Doze, masquerading as system apps, and in some families, blocking uninstallation via Accessibility-driven interference with the Settings UI.

Why AI Changes the Detection Equation

Classic Android RAT detection often keys on known automation fingerprints: fixed coordinate tap patterns, hard-coded package-name target lists, or replayable command sequences. With an AI navigation layer:

• Tap coordinates become variable and human-like.
• Target app lists become irrelevant — the malware can operate against any app on demand.
• Command payloads shift from "execute step 47 of the banking script" to short semantic objectives, reducing static signature surface.

Detection therefore has to anchor on what cannot change:

• A non-system app holding an enabled Accessibility Service.
• MediaProjection (screen capture) sessions initiated by non-trusted apps.
• Persistent outbound TLS/WebSocket sessions from a sideloaded app to low-reputation infrastructure.
• Installation source anomalies (packages installed by the browser or file manager rather than com.android.vending).

Detection & Response

The detection surface for Android malware lives in three places: mobile telemetry (MDM/MTD), network egress, and the Windows/macOS/Linux endpoints and infrastructure around the mobile fleet (APK staging, ADB abuse, smishing infrastructure). The rules below target observable primitives from this threat class. Tune aggressively to your environment — a rule that's noisy in a developer-heavy org may be pristine in a finance org where sideloading is banned outright.

Sigma Rules

---
title: Non-System Application Accessibility Service Enabled (Android)
id: 8f2c1a47-3b9d-4e65-a712-9c4d6e8f0a21
status: experimental
description: Detects enablement of an Android Accessibility Service by a non-system, non-allowlisted package. RatHat-class RATs require Accessibility access to perform AI-driven UI automation, overlay injection, and gesture control. Enablement by any sideloaded package is a high-fidelity indicator in managed fleets.
references:
  - https://www.bleepingcomputer.com/news/security/new-rathat-android-malware-uses-ai-to-automate-device-control/
  - https://attack.mitre.org/techniques/T1517/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.collection
  - attack.t1517
logsource:
  product: android
  service: accessibility
detection:
  selection:
    event_type: 'accessibility_service_enabled'
    is_system_app: 'false'
  filter_allowlist:
    package_name:
      - 'com.google.android.marvin.talkback'
      - 'com.samsung.accessibility'
      - 'com.microsoft.launcher'
  condition: selection and not filter_allowlist
falsepositives:
  - Legitimate accessibility tools (password managers, automation apps like Tasker) installed intentionally by users
  - Enterprise MDM agents legitimately using accessibility APIs
level: high
---
title: APK Installed From Non-Play Store Source (Android Sideload)
id: 4d7e9b12-6a3f-48c5-b9e1-2f8a5c7d3e64
status: experimental
description: Detects Android package installations where the installer source is a browser, file manager, or messaging application rather than Google Play or an enterprise MDM store. Sideloading is the primary delivery mechanism for RatHat and comparable Android RATs.
references:
  - https://www.bleepingcomputer.com/news/security/new-rathat-android-malware-uses-ai-to-automate-device-control/
  - https://attack.mitre.org/techniques/T1476/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1476
logsource:
  product: android
  service: package_installer
detection:
  selection:
    installer_package_name:
      - 'com.android.browser'
      - 'com.android.chrome'
      - 'com.sec.android.app.myfiles'
      - 'com.google.android.apps.messaging'
      - 'org.telegram.messenger'
      - 'com.whatsapp'
  filter_enterprise:
    installer_package_name:
      - 'com.android.vending'
      - 'com.google.android.packageinstaller'
      - 'com.microsoft.intune'
  condition: selection and not filter_enterprise
falsepositives:
  - Developer devices installing test builds via ADB or file managers
  - Regions where alternative app stores (e.g., OEM stores) are standard
level: medium
---
title: Sideloaded App Establishing Persistent Outbound WebSocket or Long-Lived TLS Session
id: 2c5f8a91-7d4b-46e3-a8f2-9b1c3d5e7f08
status: experimental
description: Detects long-duration outbound connections (consistent with interactive RAT command channels over WebSocket or TLS) originating from Android applications not installed from trusted stores. RatHat requires a persistent low-latency C2 channel for real-time AI-assisted device control.
references:
  - https://www.bleepingcomputer.com/news/security/new-rathat-android-malware-uses-ai-to-automate-device-control/
  - https://attack.mitre.org/techniques/T1572/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.command_and_control
  - attack.t1572
logsource:
  category: network_connection
  product: android
detection:
  selection:
    is_trusted_install_source: 'false'
    connection_duration_seconds|gte: 300
  filter_known:
    DestinationHostname|endswith:
      - '.googleapis.com'
      - '.firebaseio.com'
      - '.whatsapp.net'
  condition: selection and not filter_known
falsepositives:
  - Legitimate push-notification channels from sideloaded but benign apps
  - Messaging and VoIP applications with long-lived sockets
level: medium

Note on the logsource: These rules assume Android telemetry ingestion (from an MTD such as Microsoft Defender for Endpoint on Android, Lookout, Zimperium, or your MDM's audit log export) normalized into your SIEM. If you lack mobile telemetry today, that gap is itself a finding — see Remediation.

KQL — Microsoft Sentinel / Defender

The query below hunts two correlated signals in Defender for Endpoint mobile telemetry: an Android app with a risky permission profile (Accessibility + screen capture) combined with sustained outbound network activity — the fingerprint of an interactive RAT session. The second query hunts smishing delivery at the network layer for fleets where mobile traffic traverses a monitored egress point.

// Hunt: Android apps with Accessibility + screen capture permissions generating
// sustained outbound connections — RatHat-class interactive RAT fingerprint.
// Requires: Defender for Endpoint on Android onboarded to Sentinel.
let Lookback = 7d;
let RiskyApps =
DeviceInfo
| where TimeGenerated > ago(Lookback)
| where OSPlatform startswith "Android"
| distinct DeviceId, DeviceName;
DeviceNetworkEvents
| where TimeGenerated > ago(Lookback)
| where DeviceId in (RiskyApps)
| where InitiatingProcessVersionInfoCompanyName !in~ ("Google LLC", "Microsoft Corporation", "Samsung Electronics Co., Ltd.")
| where RemoteUrl !has_any ("googleapis.com", "gstatic.com", "firebaseio.com", "microsoft.com", "office365.com")
| summarize
    ConnectionCount = count(),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated),
    RemoteHosts = make_set(RemoteUrl, 20),
    RemoteIPs = make_set(RemoteIP, 20)
    by DeviceName, InitiatingProcessFileName, InitiatingProcessFolderPath, RemotePort
| where ConnectionCount > 50 and (LastSeen - FirstSeen) > 1h
| extend SessionHours = datetime_diff("hour", LastSeen, FirstSeen)
| sort by ConnectionCount desc;

// Hunt: Package install events (via MDE mobile app inventory deltas) for apps
// not present on the corporate allowlist — review for sideloaded payloads.
// Correlate DeviceName against your MDM compliance state before escalating.
DeviceInfo
| where OSPlatform startswith "Android"
| join kind=inner (
    DeviceEvents
    | where TimeGenerated > ago(7d)
    | where ActionType == "AppInstalled"
) on DeviceId
| project TimeGenerated, DeviceName, FileName, FolderPath, ReportId
| sort by TimeGenerated desc;

Tune the company-name exclusions to your fleet's standard baseline. The ConnectionCount > 50 over a multi-hour window threshold filters routine app chatter while retaining interactive C2 behavior — adjust for your population size.

Velociraptor VQL

Android devices are not native Velociraptor targets, but RatHat operations leave artifacts on the surrounding infrastructure: APK files staged or downloaded on workstations (think tanks, testers, or users who sideload from desktop), and ADB sessions — which operators and some droppers abuse for payload delivery. This artifact hunts both on Windows endpoints.

-- Hunt for staged APK payloads and active ADB sessions on managed endpoints.
-- Relevant when users sideload Android apps from workstations or when droppers
-- abuse ADB for payload delivery.

-- Part 1: APK artifacts outside sanctioned tooling directories
SELECT
    FullPath,
    Size,
    Mtime,
    Ctime,
    hash(path=FullPath) AS Hash
FROM glob(
    globs=[
        'C:/Users/*/Downloads/**/*.apk',
        'C:/Users/*/Desktop/**/*.apk',
        'C:/Temp/**/*.apk',
        'D:/**/*.apk'
    ]
)
WHERE Mtime > now() - (7 * 24 * 3600)

-- Part 2: Active or recent ADB processes (potential device-compromise tooling)
SELECT
    Pid,
    Name,
    CommandLine,
    Exe,
    Username,
    CreateTime
FROM pslist()
WHERE Name =~ '(?i)adb'
   OR CommandLine =~ '(?i)adb (install|push|shell|connect)'

-- Part 3: Network connections held by ADB or unexpected tools talking to devices
SELECT
    Pid,
    Name,
    CommandLine,
    Status,
    'Laddr.IPv4' AS LocalIP,
    'Laddr.Port' AS LocalPort,
    'Raddr.IPv4' AS RemoteIP,
    'Raddr.Port' AS RemotePort
FROM netstat()
WHERE Name =~ '(?i)(adb|scrcpy|apk)'
   OR RemotePort == 5555

Port 5555 is the default ADB-over-network port — any connection to it from a workstation that isn't an authorized mobile developer's machine warrants immediate follow-up, as exposed ADB interfaces are a documented Android compromise path.

Remediation Script

This Bash script audits and hardens Android devices reachable via ADB (e.g., corp-owned test fleets or devices temporarily connected during triage): enumerating sideloaded packages, enabled accessibility services, and packages holding screen-capture permissions. Run it against each connected device during IR or fleet hygiene sweeps.

#!/usr/bin/env bash
# RatHat-class Android RAT audit — run against ADB-connected devices during IR.
# Requires: adb in PATH, device authorized. Read-only audit; no device changes.
set -euo pipefail

DEVICE_ID="${1:-}"
ADB="adb ${DEVICE_ID:+-s $DEVICE_ID}"
REPORT="rathat_audit_$(date +%Y%m%d_%H%M%S).txt"

echo "=== RatHat-Class Android RAT Audit — $(date -u) ===" | tee "$REPORT"

# 1. Enumerate third-party (non-system) packages — sideload surface
echo -e "\n[+] Third-party packages:" | tee -a "$REPORT"
$ADB shell pm list packages -3 2>/dev/null | tee -a "$REPORT"

# 2. Identify installer source for each third-party package
#    Anything NOT installed by com.android.vending or your MDM agent is suspect.
echo -e "\n[+] Installer source per package (non-Play sources highlighted):" | tee -a "$REPORT"
for pkg in $($ADB shell pm list packages -3 2>/dev/null | sed 's/package://' | tr -d '\r'); do
    installer=$($ADB shell pm get-installer-package-name "$pkg" 2>/dev/null | tr -d '\r')
    case "$installer" in
        com.android.vending|com.microsoft.intune*|com.google.android.packageinstaller)
            echo "  OK      $pkg  <- $installer" | tee -a "$REPORT" ;;
        *)
            echo "  SUSPECT $pkg  <- ${installer:-unknown/sideloaded}" | tee -a "$REPORT" ;;
    esac
done

# 3. Enabled accessibility services — the critical RatHat enabler.
#    Any third-party entry here on a non-accessibility-needs device is a finding.
echo -e "\n[+] Enabled Accessibility Services:" | tee -a "$REPORT"
$ADB shell settings get secure enabled_accessibility_services 2>/dev/null | tee -a "$REPORT"
echo "[+] Accessibility shortcut targets:" | tee -a "$REPORT"
$ADB shell settings get secure accessibility_shortcut_target_service 2>/dev/null | tee -a "$REPORT"

# 4. Packages holding dangerous permissions: screen capture, overlay, notifications
echo -e "\n[+] Packages granted SYSTEM_ALERT_WINDOW (overlay):" | tee -a "$REPORT"
$ADB shell appops query-op SYSTEM_ALERT_WINDOW allow 2>/dev/null | tee -a "$REPORT" || true
echo -e "\n[+] Notification listener services:" | tee -a "$REPORT"
$ADB shell settings get secure enabled_notification_listeners 2>/dev/null | tee -a "$REPORT"

# 5. Battery-optimization exemptions — persistence helper abused by RATs
echo -e "\n[+] Battery optimization exemptions (third-party entries suspicious):" | tee -a "$REPORT"
$ADB shell dumpsys deviceidle whitelist 2>/dev/null | grep -v "system" | tee -a "$REPORT" || true

# 6. Check whether Play Protect is enabled and last scan state
echo -e "\n[+] Google Play Protect / package verifier state:" | tee -a "$REPORT"
$ADB shell settings get global package_verifier_enable 2>/dev/null | tee -a "$REPORT"
$ADB shell settings get secure package_verifier_user_consent 2>/dev/null | tee -a "$REPORT"

echo -e "\n=== Audit complete. Findings written to $REPORT ==="
echo "Escalate any SUSPECT package, any third-party accessibility service, or"
echo "any unknown overlay grant to your IR team before user notification."

Remediation

There is no patch for RatHat — it exploits trust and legitimate APIs, not a code flaw. Remediation is architectural and procedural:

Contain an Active Infection

1. Isolate the device immediately. Place it in airplane mode (do NOT power off if forensic acquisition is planned — RAM-resident C2 state matters). Block the device identity at your IdP (revoke tokens/sessions in Entra ID/Okta), VPN, and MDM.
2. Assume credential compromise. Any app usable on that device — email, banking, authenticator, password manager, corporate SaaS — had its UI readable and operable by an AI-driven operator. Reset credentials for all accounts accessed on the device from a known-clean device, and revoke active sessions and OAuth grants. Rotate TOTP seeds where the authenticator app was accessible.
3. Review transaction and approval logs. Check financial approvals, MFA push approvals, helpdesk-initiated changes, and any "did you just log in?" events during the infection window. AI-assisted operators specifically target approval workflows.
4. Acquire forensics before wiping. Capture the APK (hash it), the enabled accessibility services list, installer provenance (pm get-installer-package-name), and network session logs from your egress proxy. Submit the hash to VirusTotal and your MTD vendor.
5. Factory reset the device — do not rely on "uninstall," as Accessibility-abusing RATs actively interfere with removal and may have deployed secondary payloads.

Harden the Fleet

• Block sideloading by policy. Enforce "install unknown apps = denied" for all sources via your MDM (Android Enterprise managed profile / fully managed device policies). On Samsung fleets, use Knox to restrict package installation to the managed Play Store only.
• Restrict Accessibility Services. Maintain an explicit allowlist of accessibility service packages via MDM. A non-allowlisted accessibility service on a corporate device should page the SOC — that single control would have flagged RatHat.
• Deploy mobile threat defense (Defender for Endpoint on Android, Lookout, Zimperium) and ingest that telemetry into your SIEM. If Android devices touch corporate data and generate zero SIEM events today, that is your first remediation item.
• Enforce Google Play Protect and verify it isn't disabled (package_verifier_enable = 1).
• Conditional access: require device compliance (no sideloaded apps, Play Protect on, minimum OS patch level) before granting access to email/VPN/SaaS. An AI-driven operator on a non-compliant device gets nothing.
• Egress filtering: alert on long-lived TLS/WebSocket sessions from mobile VLANs to newly-registered or low-reputation domains. Interactive RAT control channels are persistent by design.
• User training refresh: specifically on smishing and "install this app to continue" lures — the only delivery mechanism this threat class has.

Related Resources

Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub