Virtual Camera Injection and Deepfakes in Video KYC

An injection attack puts a digital fake directly into the recognition software, before it runs any detection or recognition. The EU agency ENISA, in its March 2024 Remote ID Proofing Good Practices, says this needs no physical attack instrument shown to the camera. The fake bypasses presentation-attack-detection (PAD) controls, so the software "receives fraudulent input prior to performing detection and recognition".

The injected material can be a recorded, synthetic or live video, genuine or modified. ENISA lists deepfakes, face morphs, face swaps and recorded replays. A replay may contain genuine content that does not reflect who is authenticating now.

ENISA describes three ways to get the fake in:

• •Virtual camera. A program creates a software camera inside the operating system and replaces the physical camera's input with stored files. A variant uses an external video capture card. ENISA notes that virtual cameras are freely available utilities with legitimate uses.
• •Device emulator. The attacker runs a phone emulator on a computer. This gives access to the app's system calls and lets the attacker modify simulated sensor signals such as camera, GPS and accelerometer.
• •Function hooking. The attacker roots the phone (unlocks admin access), finds the app's camera code and swaps in a function that reads a local file, such as a deepfake video. The app "is not aware of the circumvention". ENISA says this generally needs hands-on knowledge of reverse engineering, debugging, rooting and scripting.

ENISA adds that the attacker needs control of the device, which means it is unsupervised. Methods can be combined, and success also depends on the quality of the fake.

The PAD testing standard covers attacks at the camera only, so injected video falls outside it. ISO/IEC 30107-3:2023 sets methods for testing and reporting PAD. It covers only attacks at the biometric capture device during presentation, and it excludes any other attacks and overall system-level security assessment.

Certification levels follow the same logic. iBeta describes Level 1 as a cooperative subject using equipment from a normal home or office, with 0% penetration permitted. Level 2 uses costlier equipment such as a 3D printer or resin mask, with 1% permitted. Both are set against the six attack types in ISO 30107-3, and iBeta's page does not mention injection attacks.

The injection counterpart is newer. CEN/TS 18099:2024 is a European technical specification, not a full European Standard, and it is valid from 16 December 2024. ENISA said in March 2024 that no globally accepted injection-detection standard yet existed.

The RBI requires liveness and spoof detection in V-CIP, but no wording naming deepfakes, injection attacks or virtual cameras was located in the V-CIP paragraph. The points below come from the Commercial Banks KYC Directions unless stated.

• •Liveness and matching. The V-CIP application must have face liveness and spoof detection plus face matching, with a high degree of accuracy. The bank stays ultimately responsible for customer identification. The NBFC Directions use the same wording for this point.
• •Gestures. Blinking, smiling or frowning is not mandatory for the liveness check, and special needs must be considered.
• •AI. The bank "may use" AI to keep V-CIP robust. The wording is permissive, in both versions.
• •Real-time proof. Questions and liveness prompts must vary in sequence or type, to show interactions are real-time and not pre-recorded. The bank must reject the account opening if it sees any prompting at the customer end.
• •Infrastructure. It must be capable of blocking connections from IP addresses outside India or spoofed addresses. It must also geo-tag recordings with live GPS co-ordinates, and encrypt data end to end.
• •Testing and audit. The V-CIP infrastructure needs vulnerability assessment, penetration testing and a security audit by auditors empanelled with CERT-In. Accounts go live only after concurrent audit.
• •Learning from forgery. The bank updates its technology and workflows from detected, attempted and near-miss forgery cases. It reports any detected forged identity through V-CIP as a cyber event.

Our search was as at 19 October 2026 and covered only part of the rest of the Directions. The NBFC version was checked for the liveness and AI points only.

ENISA says "no silver bullet exists" and recommends combining controls. Injection attack detection (IAD) sits where three fields meet: PAD, general synthetic-image detection, and cybersecurity techniques on the device and the data channel. ENISA splits the controls into two groups.

Preventive controls make injection harder:

• •Camera anti-tampering, which secures the path between the device camera and the app. ENISA calls this "under ongoing research and development", with maturity that varies.
• •Deterrent software controls: code obfuscation against reverse engineering, and runtime protection that detects rooted devices and function-hooking attempts and then ends or limits the app.

Detective controls spot an attack in the session:

• •Session metadata analysis, to detect a virtual camera or emulator. ENISA names stream resolution, GPS, accelerometer, gyroscope, timestamps, network information, and OS and user-agent fingerprinting.
• •Automated artefact detection of video, audio and biometric inconsistencies. ENISA prefers 3D face liveness over 2D, given improving deepfake quality.

Platform signals add a layer. Google's Play Integrity API reports whether the app is an unmodified binary and the device is genuine and certified. Google lists "emulated environments" among its targets, says it works best alongside other signals, and leaves the decision on a verdict to your backend. Apple's App Attest session from 2021 lets a server check that a request came from a genuine device running the genuine app, with the payload untampered. Apple's check detects a modified app, and the server must validate the attestation (the device-and-app proof).

In our reading of both pages, neither says these signals verify the pixels coming from the camera sensor. They attest to the app, the device and, for Apple, the request payload. Read this way, attestation is one layer among several.

The RBI asks for liveness and spoof detection and keeps responsibility with the bank. The PAD standard and iBeta levels are defined around presentation attacks, and the injection specification is recent. The practical implication is that the PAD standard and iBeta levels do not by themselves tell you about injection exposure.

Questions to ask your V-CIP vendor, each tied to a point above:

1. Which of the three methods (virtual camera, emulator, function hooking) does the system test for, and how?
2. Does it analyse session metadata, and which signals does it use?
3. How does the app detect rooted devices and function hooking, and what does it do when it finds them?
4. If it uses Play Integrity or App Attest, what other signals sit beside it, and what does your backend do with a failed verdict?
5. Is face liveness 2D or 3D, and does it rely on gesture prompts alone? The RBI's banks KYC Directions do not make gestures mandatory.
6. Has the system been assessed against the CEN/TS 18099 test plan, or only against PAD levels?
7. (Banks version) Does the CERT-In-empanelled penetration test cover the camera path? How do detected, attempted and near-miss cases feed back into updates and cyber-event reporting?