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.
This type of camera hijack attack can evade the traditional live facial recognition authentication model and enable access to privileged systems and victim impersonation.
Two individuals in China used this attack to gain access to the local government's tax system. They created a fake shell company and sent invoices via tax system to supposed clients. The individuals started this scheme in 2018 and were able to fraudulently collect $77 million.
ASSESSED SYSTEM
The ML-based live facial recognition service the Shanghai government tax office's tax system used for user identity verification, in the configuration exploited from 2018: a mobile client captures video of the account holder, the facial recognition model verifies the claimed identity, and a positive verification lets the account holder act in the tax system, including issuing invoices. In the exploited state the capture path accepted video supplied by a virtual camera application on customised Android ROMs, and the model accepted photo-derived synthetic video with blinking effects as a live presentation.
OUT OF SCOPE
The attackers' tooling — customised low-end phones and ROMs, the virtual camera application, and the photo-to-video software — is attacker infrastructure and is not assessed. The black-market source of identity data and face photos, the tax system's account-registration checks on personal data, and its invoice-processing logic lie outside the verification boundary. The model, its vendor, and the post-incident configuration are not identified in the record and are not assessed.
Architecture: Traditional ML / Classifier (decision tree Q6) — The decision tree resolves at Q6 by elimination. Q1 = NO and Q2 = NO: no coordinating agents, planner, task state, or tool invocation; the service returns a verification decision. Q3 = NO: the model calls no functions or connectors; account functions are performed by the relying tax application. Q4 = NO: the record describes no inference-time retrieval layer. Q5 = NO: the verification service generates no open-ended content; the synthetic video came from the attackers' own tooling, which is out of scope. What remains is a bounded face verification model with liveness-oriented checking, the image-classifier example of the Q6 class. Tier 2: Tier 2 Consumer: the service verifies members of the public who interact with it directly through a mobile client, and exploitation lets an attacker impersonate specific individuals whose identities were stolen, which is the defining Tier 2 criterion. The approximately USD 77 million loss arose in the relying tax workflow rather than from an autonomous decision of the verification model, so it is carried by the corroborated Cp rather than by raising the tier to Tier 1.
Documented attack or failure path
- The attackers obtained victims' identity information and high-definition face photos from an online black market.
- They used the victims' identity information to register new accounts in the tax system.
- They acquired customised low-end mobile phones with customised Android ROMs and a virtual camera application, together with software that turns static photos into videos with realistic effects such as blinking eyes.
- During identity verification, the virtual camera application presented the generated video to the ML-based facial recognition service in place of a live camera feed.
- The facial recognition service accepted the synthetic video and verified the attackers as the victims.
- Using the verified accounts, the attackers sent invoices through the tax system to supposed clients of a shell company, collecting approximately USD 77 million fraudulently in a scheme that began in 2018.
Observed controls and bounded outcomes
Positive credit is given only where the record directly demonstrates a control operating. Recommended or merely presumed controls receive no positive scoring credit.
- The service required a live video presentation rather than a still image: the record describes the target as a live facial recognition authentication model, and the attackers had to animate the static photos they bought, adding motion cues such as blinking, before the presentation passed. The control raised the attack cost but did not stop the attack; it is the reason Ro-1 is placed at 0.25 rather than 0.00.
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: a basic control existed — the model expected a live presentation, so the attackers had to synthesise motion cues rather than present a still photo — but it failed against commodity photo-animation and virtual-camera tooling, and no rejected session is reported. The 0.50 anchor requires resistance to common adversarial attacks with an attack success rate below 50%; photo animation combined with camera-feed substitution is a common, publicly tooled technique and no rejection rate is published. Not 0.00, because a liveness-oriented control demonstrably shaped the attack. The capture path's acceptance of a virtual camera on modified ROMs is recorded as part of the same input-channel failure; no separate capture-source attestation evidence exists. | The live facial recognition model accepted synthetic video generated from static black-market photos with added blinking effects and injected through a virtual camera application on customised Android phones, and it verified the attackers as the victims on the accounts they had registered; the scheme ran from 2018 until discovery.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 positive verification decision was accepted by the tax system with no per-case human review evidenced, and it unlocked account functions including invoice issuance. The verification model executes no action itself, which keeps it below the 0.75 supervised-autonomy anchor; its decision is consequential and unreviewed, which places it above the 0.25 human-gated anchor. |
| AsAttack Surface Exposure | 0.50w 0.35 | The 0.50 anchor: the verification service faces external members of the public through a mobile client, with liveness-oriented validation on the presented video. The capture stream was wholly attacker-controllable on a modified device, but the record describes no RAG, web-scraping, multi-agent, or MCP ingestion 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, so the specification's worst-case default applies. It is also corroborated by the observed path: an unreviewed verification decision gave the attackers access to a tax-system invoicing workflow that issued fraudulent invoices worth approximately USD 77 million, an ungated path from the entry-exposed capture channel to write-external financial capability.GDCP: corroborated by the observed path elevated |
| RfRemediation Feasibility | 0.50w 0.20 | The defeated control is a learned face verification and liveness judgment. 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 client. The record documents no remediation, so a deterministic or infrastructure-only fix (0.00 or 0.25) is not evidenced. Not 0.75, because substitution of the camera stream 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 deployment owner (the Shanghai government tax office) is identified, but the model, its vendor, the liveness method, the client application, and the verification workflow are not documented, and no AIBOM, configuration export, or evaluation artefact is public. Scored 0.15 because only one of the three 0.25-anchor elements (model name, vendor, deployment owner) is satisfied. |
| 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 2020-01-01; age 2482 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 2020-01-01 (year granularity; the scheme itself began in 2018) to the 2026-10-18 evidence reference date, 2455 days, so the calendar term dominates every other freshness signal. agentic = false: a bounded verification classifier has no runtime tool reprovisioning or credential reissuance. baw = false: no model-writable memory, online learning, agent messaging, or self-modifying configuration is described. C_monitor 0.65: the scheme accumulated approximately USD 77 million before discovery and no detection by the verification service is evidenced. C_event 0.65: the moderate row is applied for an exploited, unremediated weakness; no model or architecture change event is documented. C_evidence 0.85: no fix to the capture path or the liveness model is documented, so the exposure is unresolved on the public record. |
Public-evidence ACI = (Pc × Ec × Tf)1/3 = 0.00 — 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-cs0004-camera-hijack-facial-recognition), verified against AIDEFEND dataVersion 2026.10.15; matched to attack steps step-6, step-7. Presence supplies no score credit. | Candidate evidence route | Ro-1 |
| AID-H-002.007 | External Media & Document Provenance VerificationExact SecureFlow defense-map identifier (flow atlas-aml-cs0004-camera-hijack-facial-recognition), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-6. Presence supplies no score credit. | Candidate evidence route | Ro-1 Ro-5 Fa-1 Fa-3 Cn-8 |
| AID-M-003.002 | General Predictive Performance & Operational BaseliningExact SecureFlow defense-map identifier (flow atlas-aml-cs0004-camera-hijack-facial-recognition), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-7. Presence supplies no score credit. | Candidate evidence route | Ro-2 Fa-2 Fa-4 Tr-1 Tr-2 |
| AID-D-002.002 | Labeled Performance Tracking with Ground Truth Feedback LoopExact SecureFlow defense-map identifier (flow atlas-aml-cs0004-camera-hijack-facial-recognition), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-7. Presence supplies no score credit. | Candidate evidence route | Ro-2 Fa-1 Fa-2 Tr-2 Cn-7 |
| AID-D-015 | High-Risk Approval Bypass & HITL Activity DetectionExact SecureFlow defense-map identifier (flow atlas-aml-cs0004-camera-hijack-facial-recognition), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-8. Presence supplies no score credit. | Candidate evidence route | Fa-2 Tr-2 Cn-6 |
| AID-H-018.003 | High-Impact Independent Validation & Approval GateExact SecureFlow defense-map identifier (flow atlas-aml-cs0004-camera-hijack-facial-recognition), 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-M-006.001 | HITL Checkpoint Design & DocumentationExact SecureFlow defense-map identifier (flow atlas-aml-cs0004-camera-hijack-facial-recognition), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-8. Presence supplies no score credit. | Candidate evidence route | Cn-2 Cn-6 |
| AID-M-006.003 | HITL Escalation Topology & Audit Event ContractExact SecureFlow defense-map identifier (flow atlas-aml-cs0004-camera-hijack-facial-recognition), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-8. Presence supplies no score credit. | Candidate evidence route | Cn-2 Cn-6 |
WHAT THIS CASE TEACHES
A biometric verification failure with large real-world fraud still yields one directly observed sub-metric: AITBM scores the liveness control that was defeated (Ro-1 0.25), carries the USD 77 million downstream reach through corroborated Cp rather than a higher tier, and leaves capture-source integrity UNKNOWN instead of inferring it.
Sources: AIDEFEND SecureFlow — Camera Hijack Attack on Facial Recognition System · MITRE ATLAS case study AML.CS0004 · Faces are the next target for fraudsters (wsj.com)
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.CS0004 (incident) |
|---|---|
| Target | Shanghai government tax office's facial recognition service |
| Actor | Two individuals |
| Reporter | Ant Group AISEC Team |
| Primary evidence date | 2020-01-01 |
| SecureFlow record updated | 2026-08-02 |
| AI layers | Predictive ML / computer vision |
| Risk impact | Credential and identity theft, Financial fraud abuse |
| Affected components | facial recognition authentication service, mobile camera input path, virtual camera application, synthetic face video, tax-system account and invoice workflow |
Attack steps
| # | Step | ATLAS tactic / technique |
|---|---|---|
| 1 | Collect Victim Identity and Face PhotosThe attackers collected user identity information and high-definition face photos from an online black market. | AML.TA0002 AML.T0087 |
| 2 | Register Tax-System AccountsThe attackers used the victim identity information to register new accounts in the tax system. | AML.TA0003 AML.T0021 |
| 3 | Acquire Customized Mobile PhonesThe attackers bought customized low-end mobile phones. | AML.TA0003 AML.T0008.001 |
| 4 | Install Virtual Camera ToolingThe attackers obtained customized Android ROMs and a virtual camera application. | AML.TA0003 AML.T0016.001 |
| 5 | Generate Blinking Face VideosThe attackers obtained software that turns static photos into videos, adding realistic effects such as blinking eyes. | AML.TA0003 AML.T0016.000 |
| 6 | Feed Synthetic Video to Facial RecognitionThe attackers used the virtual camera app to present the generated video to the ML-based facial recognition service used for user verification. | AML.TA0000 AML.T0047 |
| 7 | Evade Liveness and Impersonate VictimThe attackers successfully evaded the face recognition system. This allowed the attackers to impersonate the victim and verify their identity in the tax system. | AML.TA0004 AML.T0015 |
| 8 | Use Verified Account for Invoice FraudThe attackers used their privileged access to the tax system to send invoices to supposed clients and further their fraud scheme. | AML.TA0011 AML.T0048.000 |
Threat references
Summary and attack steps reproduced from AIDEFEND SecureFlow (https://aidefendlabs.com/en/secureflow/?flow=atlas-aml-cs0004-camera-hijack-facial-recognition; AIDEFEND content CC BY 4.0), converted from MITRE ATLAS case study AML.CS0004 (Apache License 2.0; MITRE ATLAS is a trademark of The MITRE Corporation).