Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -40,6 +40,40 @@ This packing pattern (ATT&CK T1406.002) keeps the Accessibility module off-disk

---


### Social-engineered sideloading lures (dropper stage)

Some Accessibility RATs ship a **stage-1 dropper APK** that bundles the real implant (e.g., `payload.apk.xz`) plus **self-contained HTML pages** that mimic a trusted app-store update flow. Typical pattern:

- Page 1 fakes a download + "security scan" to build trust.
- Page 2 shows a fake Play Store listing with a green **UPDATE** button that triggers `REQUEST_INSTALL_PACKAGES`.
- Page 3 gives step-by-step instructions (with screenshots) to enable **"Allow from this source"**, completing sideloading.

This is purely **social engineering**, but it is extremely effective at getting users to grant both the install permission and Accessibility access. It is often paired with **localised** HTML to match the victim language.

### Fake Accessibility settings UI + silent permission escalation

Instead of opening the real Accessibility settings screen, malware can display a **pixel-perfect clone** (custom Activity/WebView) where all strings are operator-controlled (title, section headers, enable button text, info message). When the victim taps **Enable**, they grant the malicious `AccessibilityService`. Immediately after that, the service can:

- Navigate Settings via `AccessibilityService` APIs and **auto-grant dangerous permissions** (SMS, storage, notification listener, device admin).
- **Auto-dismiss permission dialogs** before they are visible to the user (some builders expose a `hide_permission_process`-style toggle).

If static tools refuse to extract `classes.dex` due to fake ZIP "encryption" flags, follow the **ZIP anti-reversing** workflow documented in [ZIP tricks](../../generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/zips-tricks.md) to recover the DEX first.

### Post-extraction triage: plaintext base64 config in DEX

After recovering `classes*.dex`, some implants store their full configuration as a **plain base64 blob** (no XOR/AES/string encryption). A quick triage loop:

```bash
# 1) find candidate blobs / tokens
strings classes.dex | rg -n "OBL_|[A-Za-z0-9+/]{80,}={0,2}"

# 2) decode the blob you found
printf '%s' '<base64_blob>' | base64 -d
```

Decoded configs may include **C2 host/port**, operator tokens, UI strings for phishing screens, and runtime mode flags.

## Requesting the permission

```xml
Expand Down Expand Up @@ -327,5 +361,5 @@ Background and TTPs: https://www.threatfabric.com/blogs/ghost-tap-new-cash-out-t
* [Android accessibility documentation – Automating UI interaction](https://developer.android.com/guide/topics/ui/accessibility/service)
* [The Rise of RatOn: From NFC heists to remote control and ATS (ThreatFabric)](https://www.threatfabric.com/blogs/the-rise-of-raton-from-nfc-heists-to-remote-control-and-ats)
* [GhostTap/NFSkate – NFC relay cash-out tactic (ThreatFabric)](https://www.threatfabric.com/blogs/ghost-tap-new-cash-out-tactic-with-nfc-relay)

{{#include ../../banners/hacktricks-training.md}}
* [Oblivion RAT - An Android Spyware Platform With a Built-In APK Factory](https://iverify.io/blog/oblivion-rat-android-spyware-analysis)
{{#include ../../banners/hacktricks-training.md}}