I Infected my iPhone with Russian Spyware. Here's What I Found.

High-level summary

• The video analyzes a sophisticated iOS spyware / one‑click exploit toolkit nicknamed “Karuna” found in the wild. It is a multi‑stage exploit chain that begins from the browser (WebKit) and escalates to the kernel to install implants with system privileges.
• Public research on the campaign comes from Google’s Threat Analysis Group (TAG) and a blog/group referred to in the transcript as iVerify. The author also collaborated with several researcher friends and a tool referred to as “clawed AI” to extract and analyze payloads.

What the author did (hands‑on guide / test setup)

1. Used a sacrificial iPhone 6S running a vulnerable iOS version and visited an active malicious URL.
2. Set up a man‑in‑the‑middle (MITM) proxy on macOS and installed a profiling/certificate on the iPhone to log HTTP(S) requests.
3. Connected the iPhone via USB and captured live system logs using idevicesyslog to observe background process activity during exploitation.

Technical breakdown of the exploit chain

• One‑click browser exploit: malicious, heavily obfuscated JavaScript exploits a WebKit bug to gain memory read/write inside Safari.
• Multiple staged payloads: different JS payloads are served depending on device and iOS version. Google reports roughly 23 different exploits covering iOS 13 → 17.2.1.
• Example (iOS 14 test device): stage‑1 exploit called “buff out” (transcript reference CVE 202130952) — an integer overflow in WebKit.
• Post‑WebKit stages:
  • Bypass pointer authentication and achieve code execution in the browser.
  • Escape the sandbox and execute a kernel privilege‑escalation exploit to obtain kernel memory read/write and cross‑process capabilities.
• Implant delivery: later JavaScript stages contain compressed/encoded dynamic libraries that are extracted at runtime and injected into privileged system processes rather than spawning separate unsigned binaries.

Implant behavior and modules (reverse‑engineered findings)

• First injection target: powerd (the system power management daemon running as root). The injected library causes powerd to make network requests (observed as thousands of show.html requests) — an unusual behavior and a useful indicator of compromise (IOC).

PowerD implant (PowerD1)

• Anti‑analysis checks: detects Corellium and checks device serials.
• Cleanup / anti‑forensics: deletes crash logs for webcontent, powerd, and system panics.
• Network behavior: makes HTTP requests to download additional modules and dynamically injects those modules into other processes.
• Low‑level APIs used: vm_write, vm_protect, memory allocation, pthread_create — indicating cross‑process memory writes and thread creation in target processes (presumably enabled by the earlier kernel exploit).
• Role: primarily prepares and injects further implant modules rather than directly harvesting large amounts of data itself.

Other implants observed (from static analysis)

• SpringBoard implant — orchestrates other injections.
• SMS implant — calls private APIs to send SMS silently (speculated uses: propagation or social engineering).
• Main data‑collection modules — search system data for sensitive keywords and wallet/seed phrase indicators.

Intended purpose and data collection

• Two observed deployments:
  • Earlier deployment attributed to a suspected Russian group for espionage.
  • Later deployment attributed to a financially motivated Chinese group focused on cryptocurrency theft.
• Collected data sources include Notes, Messages, Camera Roll, and third‑party app data.
• The implant builds a keyword list (examples: seed / backup phrase, authentication code, credit card, passport, bank account) and POSTs matches to attacker servers.

Indicators of compromise and mitigation advice

• IOC examples:
  • powerd making network requests (unusual for that daemon) — check live syslog for anomalous network activity from powerd.
  • Missing crash logs that appear to have been deleted by the implant’s cleanup routine.
  • Network requests to show.html endpoints and unusual JavaScript fetches initiated when visiting web pages.
• Practical mitigation advice:
  • Keep iOS up to date.
  • Inspect system logs and crash logs if you run a vulnerable version.
  • Avoid visiting unknown or suspicious links.
  • Do not attempt this analysis on production devices unless you are experienced and accept the risk.

Caution: the author warns against attempting these tests unless you are experienced and prepared for the risks.

Tools, research resources, and tutorials mentioned

• MITM proxy on macOS + iPhone profile installation for logging HTTP(S) traffic.
• USB syslog capture using idevicesyslog.
• Static reverse engineering with IDA Pro to analyze implant binaries.
• Related content: prior videos on iOS browser exploitation and potential future deep dives into the Karuna chain and specific exploit techniques.
• Public writeups: Google Threat Analysis Group blog and posts from iVerify (transcript variants: I Verify / i Verify / Iver Verify) that include exploit-to‑iOS‑version mappings and lists of IOCs.

Limitations and cautions in the analysis

• JavaScript exploit code is heavily obfuscated; the video does not fully reverse every exploit stage.
• Dynamic linking between kernel exploit mechanisms and injection capability is not fully traced in the video.
• The analysis emphasizes observed behavior, implant functionality, and static reversing of extracted modules rather than a complete technical root‑cause reconstruction of each vulnerability.

Main speakers and primary sources referenced

• Video author: an iOS security researcher and channel narrator who performed the hands‑on infection and analysis.
• Google Threat Analysis Group (TAG) — public research on Karuna.
• iVerify — referenced as a blog/source for IOCs and analysis.
• Additional contributors: “clawed AI” and various researcher friends who helped extract implants.