Video injection attack

What a video injection attack is

A video injection attack consists of feeding an application's camera stream with content chosen by the attacker, without presenting anything to the sensor. The application receives images with the format and cadence it would expect from the physical camera, but those images never went through a lens.

The injected content can be a real video of the owner, obtained from a social network or a leak, or a synthetic face generated with a model. The generation technique is irrelevant: what defines injection is the point where it enters, not how the image was produced.

That's the difference that orders everything else. In a presentation attack the system correctly captures something fake. In an injection the system captures nothing: it receives a file and treats it as if it were a capture.

In application security the same name designates a different family of attacks, code or command injection against a database or an interpreter. These are different concepts that share a word: what is injected here is a video stream, not an instruction.

Presentation and injection are stopped by different controls

The two vectors are usually grouped under the same label, and that confusion leaves a gap open in most flows.

• Presentation attack — the attacker shows something in front of the real camera: a printed photo, a screen playing a video, a mask, a projected deepfake. The camera works normally and captures what's in front of it.
• Injection attack — the attacker intervenes in the channel: a virtual camera registered in the operating system, an emulator, a tampered device or an interception of the traffic to the server. There's nothing in front of the lens because the lens doesn't take part.

A system that analyzes the image looking for signs of presence can approve an injection without difficulty, because the injected image is that of a real person filmed by a real camera, at another time and in another place. The question liveness detection answers is whether what's seen corresponds to a live person. The question injection forces you to answer is a different one: whether that image comes from this device's camera, now.

How the attack runs, step by step

The sequence is more technical than that of a presentation attack, and once set up it repeats at no extra cost.

1. Get the material. A video of the owner or a synthetic face built from an image of them. In both cases, without access to any of the organization's systems.
2. Prepare the material for the flow. If the verification asks for gestures, the attacker records or generates them in advance, or builds an animation that responds in real time. The goal is to have an answer for every challenge the flow may ask.
3. Set up the injection point. A virtual camera that the operating system enumerates as one more capture device, an emulator that simulates a complete phone, or a real device modified to intercept the call between the application and the camera.
4. Run the verification. The application asks for the capture and receives the prepared video. The biometric comparison passes, because the face matches. The presence analysis may also pass, because it analyzes an image of a person who was indeed alive in front of some camera.
5. Repeat at scale. This is the step that sets injection apart from everything before it. A presentation attack is handcrafted and consumes time per attempt. An injection, once set up, is automated: the same environment processes signups in series, changing the input identity.

Step 5 is what turns the vector into a volume problem rather than isolated cases. The four before it require technical knowledge, but it's available knowledge, and virtual camera tools are legitimate products with legitimate uses.

Where it shows up in an identity journey

• Account signup with biometric capture — the most exposed moment, because the organization does not yet have any prior reference for that person.
• Access recovery with a face — where a flow is resolved by comparing against the capture from signup.
• Authorizing operations by biometrics — the confirmation a system asks for before a high-value action.
• High-volume remote channels — those running in the browser or in applications that do not control device integrity.

The controls that respond to this vector are not biometric: they are about integrity. Detecting virtual cameras and emulators, verifying the origin of the image, and checking the execution environment. Several depend on what the operating system and the device manufacturer expose, so no identity provider solves them alone.

Who it affects and what it costs

The vector attacks the capture channel, so it affects any process that trusts a remote camera without verifying where the image comes from.

• Financial services — fraudulent signups in series, which later feed other frauds. When injection is automated, the problem stops being one account and becomes a cohort of accounts opened in the same period.
• Betting and gaming platforms — age and identity verification evaded at scale, which is a regulatory exposure before an economic one.
• Government — procedures and benefits processed in someone else's name, in channels that usually accept a web browser, where this vector is harder to rule out.
• Background screening — false identity in a remote hiring or accreditation process.

The operational damage has a particular shape: the organization keeps an approved verification record, with its video and its biometric result, and that record is indistinguishable from a legitimate user's. The evidence that would normally serve to investigate is the one the attack fabricated.

Certification under ISO/IEC 30107-3 doesn't cover this vector

It's worth saying plainly, because it's the most costly confusion in this category when comparing vendors.

The ISO/IEC 30107-3 standard defines the method and metrics for evaluating presentation attack detection. An accredited lab builds attack instruments, presents them against the system under controlled conditions and measures how many are accepted. Its scope is presentation attacks: the ones that happen in front of the capture device.

The levels usually cited alongside the standard are not the standard's. The levels are the grades of iBeta's testing program, which applies that methodology: Level 1 uses low-cost, easy-to-build attack instruments, Level 2 adds instruments of greater sophistication and cost, and the lab added a Level 3 for highly prepared instruments. VU is certified by iBeta at Level 2.

An injection isn't presented to the capture device, so it falls outside the scope of that test. No certification under that standard, VU's included, says anything about a system's resistance to injection. A vendor that answers a question about injection by showing its liveness certification isn't answering the question.

What it is fair to ask any vendor, VU included, is which specific controls it applies against injection, how it evaluates them and with what third-party evidence, if any.

Which controls stop an injection

No control solves the vector on its own, and the two most decisive ones don't depend on the verification vendor. Naming the full list is the only way for it to be useful.

• Virtual camera detection — identifies capture devices registered by software instead of the machine's hardware. It's the most direct control and the first one an attacker tries to evade.
• Emulator and virtualized environment detection — recognizes when the application runs on a simulated phone and not a physical one.
• Device and application integrity — detection of rooting, jailbreak, runtime instrumentation and binary tampering. It's usually solved with mobile security tools, which are a different market from identity.
• Capture hardware attestation — verification that the image comes from the device's physical camera. It depends on the interfaces the operating system and the manufacturer expose; a vendor can integrate them, it can't replace them.
• Stream integrity verification — signing or sealing the capture at the point of origin, to detect whether the content was replaced between the camera and the server.
• Session and device signals — device reputation, repetition of the same material across different signups, interaction cadence, multiple signups from the same origin. They provide context the image analysis doesn't have.
• Analysis of the captured content — metadata, frame rate, compression patterns and artifacts that give away a played-back file instead of a live capture. It's a complementary control, not a substitute for the ones above.

Device integrity and hardware attestation aren't solved by a verification vendor alone. They depend on the guarantees the operating system exposes, and a vendor that claims to cover them independently is describing something the platform doesn't grant it. In a web browser the situation is even more restrictive: hardware attestation interfaces are scarce or nonexistent, so the same flow offers less certainty on the web than in a mobile application.

A team that builds its defense against injection solely with what its biometrics vendor sells is covering part of the problem, and it isn't the part the attacker attacks first.

How VU approaches it

VU applies certified liveness detection within the same flow that reads the document and compares the face. That certification, from iBeta at Level 2 against the ISO/IEC 30107-3 methodology, is evidence measured by a third party and covers presentation, not injection. The page repeats it here on purpose: the capability VU can demonstrate with an independent test is the presentation one.

The capability that groups the capture controls within the flow is Verify, and the one that provides device and session signals is Protect against fraud.