Products Lemma APIProof issuance & verification platformTrust402Delegate to agents, and transactSealSign-in for the agent era — no keys handed over
Use cases Manufacturing & Critical InfraInspection Record AssuranceFinance & FinTechCounterparty Record VerificationPublic SectorCertificate-less ProceduresHealthcareQualified Worker AssuranceProcurement & Supply ChainSupplier Credential MonitoringMedia & ContentContent AuthenticityService & RetailCross-group IdentityAI Adoption (cross-industry)AI Run GovernanceDevelopers & Agent OpsAgent Authority Control ▸ Browse the use-case index
Pricing
Resources Critical BriefThe frontier of AI × trustBlogThinking and implementation notesDocumentationAPI & specsVerification CenterReal verification & issuance countsAbout usFRAME00, Inc.ContactSales & press inquiriesGlossaryDefinitionsFAQFrequently asked questions
Get Started ↗ JA
Home / Critical Brief / No. 140
No. 140 Pillar 04 · Regulatory Attribute Proof

AnonyMousKIT: AI voice agents posing as 'Apple Support' extracted unlock passcodes from stolen-iPhone owners

being able to state the passcode is treated as proof of ownership

Attribute Proof Bypass Identity & Auth
Incident date
2026-08-24
Published
2026-09-01
Authors
Lemma Critical Team
Related Pack
Pack A · Incident Response

TL;DR

On August 24, 2026, SOCRadar published an inside-out analysis of AnonyMousKIT, an AI-powered phishing-as-a-service platform built to defeat Activation Lock on stolen iPhones. A single resold codebase drives AI voice agents that pose as “Apple Support” to harvest unlock passcodes and two-factor codes. A flaw on the operators’ own side exposed their logs, so detection worked. What was missing was a layer that independently verifies, before an unlock, whether a caller claiming to be Apple actually is Apple.

What happened

  • SOCRadar Threat Research Unit (STRU) published its analysis of AnonyMousKIT’s internals on 2026-08-24.
  • The target is Apple’s Activation Lock, introduced in iOS 7, which ties a device to its owner’s Apple ID the moment Find My is enabled and renders a stolen device worthless without it.
  • A single panel codebase is resold across 506 domains and 168 storefront brands — a reseller ecosystem rather than a single attacker. A scan of the 506-domain family found 41 live backends exposing these logs, across 30 distinct installations on 42 domains; 318 domains are offline or sinkholed and 188 remain live.
  • A coding flaw on the operators’ own side — bare relative paths that resolve to the web root — exposed production logs, letting STRU examine backend source code and months of operational logs directly. Every deployment of that codebase inherits the flaw.
  • The AI voice channel is the second best-documented vector after email. From the operators’ account on the commercial voice platform Vapi, researchers recovered 200 call records, 55 conversation transcripts, and five configured personas. 179 of the 200 calls (90%) went to numbers in Brazil, and 178 used the Portuguese persona. The total cost was $19.24 — about 9.6 cents per call. The median call ran 22 seconds.
  • Channels are priced separately: email at 1.50 credits, SMS per sender ID, a recorded voice call at 1 credit, and an AI voice agent at 2 credits.

The attack proceeds in seven stages.

  1. Profile the stolen device’s model and Find My status (online/locked).
  2. Log the victim’s name, phone number, device model, and tracking link in the panel, drawn from the contact details Lost Mode displays.
  3. Deliver a lure via email, SMS, WhatsApp, recorded audio, or AI voice.
  4. The victim interacts with a spoofed map showing the device’s supposed location.
  5. Harvest the four- or six-digit passcode, Apple ID, and six-digit two-factor code. The AI agent opens by confirming ownership, has the victim read out the passcode and reads the digits back, then moves into a story about someone bringing the device to an Apple Store.
  6. Exfiltrate the harvested data to the panel and to Telegram.
  7. Use the credentials to disable Activation Lock and resell the device.

Timeline — disclosure and response

  • 2024-02: The panel codebase is first observed, traced back via a shared admin library hash on URLScan.
  • 2025-03: AI personas are built in English, Spanish, and Brazilian Portuguese.
  • 2025-08-31: The first AI voice call is recorded — the start of the 200-call log.
  • 2026-05-30: The last AI voice call is recorded.
  • 2026-07-30: The last email is logged in the exposed SMTP log.
  • 2026-07-31 to 08-04: STRU obtains the victim-facing kit and confirms the panel is active, connecting the panel logs to the capture page.
  • 2026-08-10: The last day of operator activity visible in panel logs. SOCRadar states the platform is live and operational as of that date.
  • 2026-08-24: SOCRadar publishes its analysis.

The figures in this brief come from SOCRadar’s self-published report, based on direct access to the operators’ exposed logs and panel source code. The report itself gives the persona naming two ways: its timeline says all five share the same translated identity, “Alice from Apple Support,” while its persona section says the three voice options share “Alice Dias, Apple Support.” The divergence in secondary accounts follows from each outlet quoting one of the two. Success rates warrant care. The report’s outcome column assigns all 200 calls to hung up, silence timeout, no answer, or platform error, and no count of captured credentials appears for any channel. For the one published transcript, however, the report states that the passcode was extracted and verified during the call. This brief treats that individual capture as fact; the overall success rate across the 200 calls is not published. No Apple statement on this matter could be confirmed at the time of writing.

Response and developments:

  • SOCRadar published indicators of compromise alongside its analysis, sharing the findings as threat intelligence.
  • BleepingComputer, Help Net Security, and The Hacker News covered the report the same week.
  • The Hacker News noting that neither the report nor the companies involved have said whether the Vapi account was reported to Vapi or remains active. The platform itself, SOCRadar says, was live on the last day of collection (2026-08-10), and it continues to track it.

Why it wasn’t stopped

This incident’s failure is neither a break in Apple’s cryptographic authentication nor a design flaw in Activation Lock itself. Neither victims nor the call and delivery channels independently verified whether the party on the other end of a phone call, email, or WhatsApp message was actually “Apple Support” — a victim simply stating the passcode aloud was treated as proof of ownership.

Detection worked. SOCRadar exploited an implementation flaw on the operators’ own side to examine logs directly, surfacing call scripts, persona configurations, and victim data in full. What was missing sat one step earlier: verifying whether a caller claiming to be Apple actually is Apple.

“When we realised the iPhone 16 Pro Max was in lost mode, we had to retain it for security reasons and open a recovery case. Did you receive a text message with a security link to recover your device?” — from a recovered call transcript. SOCRadar writes that in this call the software extracted and verified the passcode for roughly ten cents.

What AI voice agents changed was not whether verification existed, but the cost of impersonation. Renting a commercial voice-AI service to build a persona made it possible to reproduce a natural-sounding conversation for roughly ten cents a call, automating and scaling — across languages and regions — a form of social engineering that once required manual labor. That 179 of the 200 calls went to Brazil shows the scaling can be aimed at a chosen region. A passcode is proof of knowledge, meant to be one part of an authentication a genuine owner performs with a legitimate counterpart. But over a channel where the counterpart’s identity is unverified, that knowledge is treated as grounds for an unlock action regardless of who it was actually disclosed to.

The same shape appears where an AI support flow granted account changes without independently verifying ownership in Brief 051, and where credentials left an organization before the sender was verified in Brief 047.

What proof would have changed

Proof before the action replaces “the caller could state the passcode” with “the disclosure could be verified as a response to a legitimate request from a verified party” as the basis for an unlock or account change. It does not stop impersonation from being generated. It keeps a successful impersonation from turning into an unlock.

The design Lemma offers against this gap:

  • Proof of caller identity: give the recipient an independently verifiable channel to confirm the identity of anyone claiming to be support — grounded in a checkable proof rather than a claimed name.
  • Binding the context of disclosure: ground the disclosure of credentials (passcodes, two-factor codes) in an independent cross-check against a legitimate channel, not a verbal confirmation in the moment.
  • Provenance of the action: record the provenance of an unlock or account change, tied to the verification process that authorized it.

What it does not do:

  • It does not recover stolen devices or take down phishing infrastructure. That is law enforcement's work.
  • It does not detect or block the generation of voice-AI impersonation, and assumes the cost of generating it keeps falling.
  • Proof can show that a disclosure was a response to a verified party; it cannot show whether the owner handed the credential to a third party themselves.

The difference from a call log is here: the record remains after the call, but it is not material for deciding, at the moment of disclosure, whether the credential should have been given to that caller.

Detection and this layer are complementary, not substitutes. The former surfaces the phishing infrastructure and reduces the number of paths; the latter makes “no unlock until the caller’s identity is verified” something you can check before the next persona is stood up.

Sources

“The last layer left in AI-era cyber defense”Pillar 04 — Regulatory Attribute Proof

Figures come from SOCRadar’s self-published report and were cross-checked against three independent outlets. The platform was reported live on the report’s last day of collection (2026-08-10); its status since then, and any Apple response, are unpublished as of writing.

This material is a structured analysis of public information; it is not an audit, diagnosis, or recommendation for any specific organization.

Cite this Brief

Lemma Critical Team. (2026).
"AnonyMousKIT: AI voice agents posing as 'Apple Support' extracted unlock passcodes from stolen-iPhone owners — being able to state the passcode is treated as proof of ownership".
Lemma Critical Brief No.140. Lemma / FRAME00, Inc.
https://lemma.frame00.com/critical/briefs/140-anonymouskit-activation-lock-ai-vishing/
Related BriefsRelated
No. 135 Expired Visa EMV contactless cards were shown to pass at checkout Attribute Proof Bypass No. 117 Speechify verified voice-cloning consent with a single checkbox Attribute Proof Bypass No. 084 Hong Kong deepfake video-call fraud: a real-time deepfake of the CFO and every colleague drove a ~$25.6M transfer Attribute Proof Bypass
Lemma

If it can't be verified,
it doesn't enter your operation.

Lemma attaches cryptographic proofs to data and AI execution, so the receiving side can confirm authenticity without asking the issuer. Detection stays; a proof layer is added in front of it.

Talk to enterprise See the verification center