Use case sources
Source reports and analysis supporting this case are listed below. AITBM interpretation and any indicative scoring are derived from this public evidence.
Facial biometric authentication services are commonly used by mobile applications for user onboarding, authentication, and identity verification for KYC requirements. The iProov Red Team demonstrated a face-swapped imagery injection attack that can successfully evade live facial recognition authentication models along with both passive and active liveness verification (https://en.wikipedia.org/wiki/Liveness_test) on mobile devices. By executing this kind of attack, adversaries could gain access to privileged systems of a victim or create fake personas to create fake accounts on banking or cryptocurrency apps.
ASSESSED SYSTEM
Representative configuration: a mobile financial-services application (for example a banking or cryptocurrency app) that performs KYC onboarding and authentication through a facial biometric service combining live facial recognition with both passive and active liveness detection on video from the user's Android device camera, and that authenticates the account when the check passes. The configuration assessed is the one the iProov Red Team evaded in MITRE ATLAS case study AML.CS0033, in which the device camera could be replaced by a streamed video feed through a virtual camera app that works on genuine, non-rooted Android devices.
OUT OF SCOPE
The attacker toolchain — the Faceswap real-time face-swapping application, Open Broadcaster Software, and the Virtual Camera: Live Assist app — and the social-network or black-market sources of victim images; any named biometric vendor, application, or financial institution (none is identified in the record); the downstream financial harm, which the record describes only as possible; and deployments that bind the capture stream to attested device hardware, which are a different configuration.
Architecture: Traditional ML / Classifier (decision tree Q6) — The decision tree resolves at Q6 by elimination. Q1 = NO and Q2 = NO: no agents, planner, task state, or tool invocation; the biometric service returns a verification decision. Q3 = NO: no model-invoked function or connector is described. Q4 = NO: no inference-time retrieval layer is described. Q5 = NO: the face recognition and liveness models classify the presented video; the deepfake was generated by the attackers' tooling, which is out of scope. What remains is a bounded face verification and liveness pipeline, the Q6 class. Tier 2: Tier 2 Consumer: KYC onboarding faces members of the public directly, and exploitation lets an attacker authenticate as a specific victim or open a fraudulent account, which affects individuals. Financial harm is stated only as a possible consequence, so nothing supports Tier 1.
Documented attack or failure path
- The researchers collected victim identity information and high-definition facial images from online social networks and/or black-market sites.
- They obtained a desktop real-time face-swap application, Open Broadcaster Software to stream video over the network, and a virtual camera app that substitutes the device camera with a video stream on genuine, non-rooted Android devices.
- They produced a live deepfake video mimicking the victim's appearance and registered a financial-services account with the victim's information.
- During identity verification, the application's facial recognition and liveness detection analysed what it treated as live video from the user's camera.
- The deepfake feed, streamed through OBS and injected through the virtual camera app, evaded facial recognition and both passive and active liveness verification, authenticating the researchers under the victim's identity.
- With an authenticated account under the victim's identity, the researchers impersonated the victim and evaded detection; the record states they could then have caused financial harm.
Layer 1 — Intrinsic Vulnerability Profile
Each sub-metric is placed on its five-level rubric by the evidence quoted beside it. Missing applicable evidence remains unknown. The displayed midpoint and interval are scenario values, not inferred control performance.
| Sub-metric | Score | Rubric basis | Evidence |
|---|---|---|---|
| Robustness (Ro) — scenario interval 0.08–0.76 (midpoint 0.42), Tier 2 MVT 0.50 indeterminate | |||
| Ro-1Adversarial Input Resistance | 0.25w 0.32 | The 0.25 anchor: purpose-built controls existed — face matching plus passive and active liveness checks — but they failed against a moderate-budget attack assembled entirely from publicly available tools. The 0.50 anchor requires resistance to common attacks with an attack success rate below 50%; camera-feed injection of a face-swap stream is a common, publicly tooled technique and no rejection rate is published. Not 0.00, because a dedicated liveness layer was operating and required a live, responsive deepfake stream rather than a replayed image. Acceptance of a substituted camera on a non-rooted device is part of the same input-channel failure; capture-source attestation has no separate observed evidence and remains UNKNOWN. | A real-time face-swap deepfake streamed into the onboarding session through a virtual camera app on a genuine, non-rooted Android device evaded the live facial recognition model and both passive and active liveness verification, and authenticated the red team under the victim's identity.source: secureflow/atlas |
| Fairness (Fa) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 2 MVT 0.55 indeterminate | |||
| Transparency (Tr) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 2 MVT 0.50 indeterminate | |||
| Privacy (Pr) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 2 MVT 0.55 indeterminate | |||
| Containment (Cn) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 2 MVT 0.55 indeterminate | |||
Unknown, not N/A: 21 applicable sub-metrics lack admissible public evidence. The lower, midpoint, and upper scenarios evaluate each at 0.00, 0.50, and 1.00 respectively; no weight is redistributed merely because evidence is missing.
Architecture-based NOT APPLICABLE: declared with an architecture rationale in the workpaper: Cn-5, Cn-6; NOT APPLICABLE by design for this architecture class: Cn-8, Cn-9.
Layer 2 — Operational Risk Posture
| Dimension | Score | Justification |
|---|---|---|
| AaAutonomy Amplification | 0.50w 0.25 | Human-on-the-loop anchor. A passing check authenticated the account under the victim's identity with no human review evidenced, releasing the account's routine functions. The biometric service executes no transactions itself, which keeps it below 0.75; its unreviewed decision is consequential, which places it above 0.25. |
| AsAttack Surface Exposure | 0.50w 0.35 | The 0.50 anchor: the onboarding flow is internet-facing to unauthenticated members of the public, with liveness and face-matching validation on the submitted video. The camera stream is attacker-substitutable on an ordinary device, but no RAG, web-scraping, multi-agent, or MCP ingestion is described that would support 0.75 or above. |
| CpCascade Potential | 1.00w 0.20 | No verified System Dependency Graph with DGC at least 0.90 is public for this configuration class, so the specification's worst-case default governs. The record states financial harm only as a possible next step, so the path to write-external financial capability is not observed and the score is not corroborated.GDCP: worst-case default — no verified dependency graph published elevated |
| RfRemediation Feasibility | 0.50w 0.20 | The defeated controls are learned face recognition and passive and active liveness judgments. Closing the path requires retrained or replaced presentation-attack and injection detection whose effectiveness is probabilistic and must be re-evaluated, together with capture-path integrity on the device. The record documents no remediation, so a deterministic or infrastructure-only fix is not evidenced. Not 0.75, because camera-stream substitution is a deployment-path weakness that external controls can remove rather than an inherent property of the model. |
Nelevated = 1 (dimensions strictly above 0.75) → CRM = 1.00.
Layer 3 — Public-evidence confidence diagnostic
| Component | Score | Basis |
|---|---|---|
| Pc — Public provenance evidence | 0.15 | Below the 0.25 anchor. The configuration class, the liveness modes, and the capture platform are described, but no model, vendor, application, or deployment owner is identified, and no AIBOM, configuration export, or evaluation artefact is public. |
| Ec — Public evaluation coverage | 0.04 | coverage 0.05 (1 of 22 applicable sub-metrics) × independence 1.00 × fidelity 0.85. No Full, Standard, or Lite pathway is claimed for a retrospective article. |
| Tf — Public-evidence freshness | 0.00 | Evidence dated 2024-10-01; age 747 days on the workpaper reference date. Components: T_calendar 0.00 · C_monitor 0.65 · C_event 0.65 · C_evidence 0.85. Binding term: T_calendar. Evidence age is measured from the MITRE ATLAS incident date 2024-10-01 (year granularity) to the 2026-10-18 evidence reference date, 720 days. agentic = false and baw = false: a bounded verification pipeline with no runtime tool reprovisioning, model-writable memory, online learning, or self-modifying configuration is described. C_monitor 0.65: the record states that the researchers impersonated the victim and evaded detection, so no detection signal is evidenced. C_event 0.65: the moderate row is applied for a demonstrated, unremediated weakness; no change event is documented. C_evidence 0.85: no remediation of the configuration class is documented. |
Public-evidence ACI = (Pc × Ec × Tf)1/3 = 0.03 — diagnostic status: Invalid as assessment-of-record evidence. It describes the evidence available to this case study, not the assurance of the underlying system, and is not inserted into the normalized-assurance scenario ERS.
Indicative ERS — normalized-assurance scenario
Published CVSS beside indicative ERS
Each published CVSS record is shown exactly as its scorer published it, one per vulnerability record, with the version, metric group and vector when stated, plus its source and access date. Records are never combined or inferred from a CVE's existence.
INDICATIVE ERS · NORMALIZED-ASSURANCE SCENARIO
3.6 midpoint, interval 1.2–5.9; Low-Moderate scenario band; ACI fixed at 1.00. The published CVSS records do not enter this calculation.
PUBLISHED CVSS
CVSS — no applicable published score verified.
CVSS describes an individual vulnerability as its scorer published it. Indicative ERS describes the assessed AI deployment under the normalized-assurance scenario, so the two values are not direct equivalents and neither replaces the other.
AIDEFEND defences → AITBM sub-metrics
Identifiers are quoted as they appear on the AIDEFEND in Action brief or in the AIDEFEND SecureFlow defense map (audited AIDEFEND dataVersion 2026.10.15); the sub-metric mapping is AITBM's own, from the specification's AIDEFEND tables reconciled at catalogue data version 2026.10.15. AIDEFEND renumbers identifiers between releases, so the data version travels with every mapping and neither side's IDs should be cited without one. A mapping identifies a possible evidence route; a recommendation does not prove that the control was implemented or effective and receives no scoring credit by itself.
| Technique | Defence | Priority | Evidences |
|---|---|---|---|
| AID-D-001.002 | Synthetic Media & Deepfake ForensicsExact SecureFlow defense-map identifier (flow atlas-aml-cs0033-deepfake-injection-kyc), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-8. Presence supplies no score credit. | Candidate evidence route | Ro-1 |
| AID-D-007.002 | Realtime Multimodal Stream & Session Anomaly DetectionExact SecureFlow defense-map identifier (flow atlas-aml-cs0033-deepfake-injection-kyc), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-8. Presence supplies no score credit. | Candidate evidence route | Ro-3 |
| AID-H-002.008 | Realtime Multimodal Input Stream SecurityExact SecureFlow defense-map identifier (flow atlas-aml-cs0033-deepfake-injection-kyc), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-8. Presence supplies no score credit. | Candidate evidence route | Ro-1 Ro-5 Fa-1 Fa-3 Cn-8 |
| AID-H-002.007 | External Media & Document Provenance VerificationExact SecureFlow defense-map identifier (flow atlas-aml-cs0033-deepfake-injection-kyc), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-8. Presence supplies no score credit. | Candidate evidence route | Ro-1 Ro-5 Fa-1 Fa-3 Cn-8 |
| AID-H-018.003 | High-Impact Independent Validation & Approval GateExact SecureFlow defense-map identifier (flow atlas-aml-cs0033-deepfake-injection-kyc), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-8. Presence supplies no score credit. | Candidate evidence route | Cn-1 Cn-6 Cn-7 |
| AID-D-002.002 | Labeled Performance Tracking with Ground Truth Feedback LoopExact SecureFlow defense-map identifier (flow atlas-aml-cs0033-deepfake-injection-kyc), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-9. Presence supplies no score credit. | Candidate evidence route | Ro-2 Fa-1 Fa-2 Tr-2 Cn-7 |
WHAT THIS CASE TEACHES
Representative-configuration scoring lets an unnamed KYC deployment be scored without inventing a vendor: the observed defeat of passive and active liveness by camera-feed injection places Ro-1 at 0.25, while the financial harm the record only calls possible leaves Cp at the specification default rather than corroborated.
Sources: AIDEFEND SecureFlow — Live Deepfake Image Injection to Evade Mobile KYC Verification · MITRE ATLAS case study AML.CS0033 · MITRE ATLAS Publishes Critical Vulnerability in the KYC Identity Process Discovered by iProov
SecureFlow attack flow
This record mirrors an AIDEFEND SecureFlow flow (MITRE ATLAS case-study conversion): an ordered attack path with MITRE ATLAS tactic and technique labels and the AIDEFEND controls matched to each step. The scenario above places only the control outcomes this flow and its primary references observed; the matched AIDEFEND controls are evidence routes and earn no score credit.
| MITRE ATLAS case study | AML.CS0033 (exercise) |
|---|---|
| Target | Mobile facial authentication service |
| Actor | iProov Red Team |
| Primary evidence date | 2024-10-01 |
| SecureFlow record updated | 2026-08-06 |
| AI layers | Predictive ML / computer vision |
| Risk impact | Credential and identity theft, Financial fraud abuse |
| Affected components | mobile facial recognition authentication service, passive and active liveness detection, virtual camera injection path, real-time face-swap deepfake video, financial services KYC onboarding |
Attack steps
| # | Step | ATLAS tactic / technique |
|---|---|---|
| 1 | Collect Victim Face ImagesThe researchers collected user identity information and high-definition facial images from online social networks and/or black-market sites. | AML.TA0002 AML.T0087 |
| 2 | Acquire Real-Time Faceswap ToolThe researchers obtained Faceswap (https://swapface.org) a desktop application capable of swapping faces in a video in real-time. | AML.TA0003 AML.T0016.002 |
| 3 | Acquire OBS Streaming SoftwareThe researchers obtained Open Broadcaster Software (OBS) (https://obsproject.com) which can broadcast a video stream over the network. | AML.TA0003 AML.T0016.001 |
| 4 | Install Virtual Camera AppThe researchers obtained Virtual Camera: Live Assist (https://apkpure.com/virtual-camera-live-assist/virtual.camera.app), an Android app that allows a user to substitute the devices camera with a video stream. This app works on genuine, non-rooted Android devices. | AML.TA0003 AML.T0016 |
| 5 | Generate Live Deepfake VideoThe researchers use the gathered victim face images and the Faceswap tool to produce live deepfake videos which mimic the victim's appearance. | AML.TA0001 AML.T0088 |
| 6 | Register Financial Services AccountThe researchers used the gathered victim information to register an account for a financial services application. | AML.TA0003 AML.T0021 |
| 7 | Trigger KYC Facial VerificationDuring identity verification, the financial services application uses facial recognition and liveness detection to analyze live video from the user's camera. | AML.TA0000 AML.T0047 |
| 8 | Inject Deepfake into Camera FeedThe researchers stream the deepfake video feed using OBS and use the Virtual Camera app to replace the default camera with feed. This successfully evades the facial recognition system and allows the researchers to authenticate themselves under the victim's identity. | AML.TA0004 AML.T0015 |
| 9 | Impersonate Victim IdentityWith an authenticated account under the victim's identity, the researchers successfully impersonate the victim and evade detection. | AML.TA0007 AML.T0073 |
| 10 | Cause Financial HarmThe researchers could then have caused financial harm to the victim. | AML.TA0011 AML.T0048.000 |
Threat references
Summary and attack steps reproduced from AIDEFEND SecureFlow (https://aidefendlabs.com/en/secureflow/?flow=atlas-aml-cs0033-deepfake-injection-kyc; AIDEFEND content CC BY 4.0), converted from MITRE ATLAS case study AML.CS0033 (Apache License 2.0; MITRE ATLAS is a trademark of The MITRE Corporation).