.webp)
State-of-the-art liveness detection is now good enough to catch a deepfake held up to a camera. That success created a new problem: rather than fight the camera, attackers learned to skip it. An injection attack feeds a deepfake directly into the verification software, as though it came from the device's camera, and it has become the fastest-growing threat to remote identity verification. One benchmark spanning early 2024 to early 2026 found injection attacks surging ninefold year over year, the fastest-rising vector it tracked.
This guide explains how injection attacks feed deepfakes into verification: what they are, where they strike in the verification pipeline, the specific technical methods attackers use, why they defeat conventional liveness checks, and what actually stops them. It is written for the identity, fraud, and security teams who build or buy verification systems and need to understand the threat at the level the attackers do.
The distinction at the heart of this is simple. A presentation attack shows something fake to a real camera. An injection attack removes the camera from the equation. That single difference is why a system can pass every presentation-attack test and still be wide open.
- An injection attack bypasses the camera entirely, feeding a deepfake straight into the verification software instead of showing it to a lens.
- Because no real scene is captured, injection defeats the camera-based artifacts that presentation-attack detection relies on.
- Virtual cameras are the most common method, since they need the least skill; advanced attacks use emulators, SDK function hooking, or transport-layer interception.
- CEN/TS 18099 separates the attack method (how the deepfake is delivered) from the instrument (the deepfake itself), and is the first standard built to test injection resistance.
- A product can pass PAD certification (ISO/IEC 30107-3) and still have zero resistance to injection attacks.
- iProov recorded native virtual camera attacks up 2,665% year over year; Entrust reports injection attacks up 40% and deepfakes now one in five biometric fraud attempts.
- Human reviewers catch high-quality deepfakes only about 24.5% of the time, so manual review is not a backstop.
- Defense means scoring the capture path, not just the image: stream integrity, device and session checks, and deepfake payload detection layered together.
What Is an Injection Attack?
An injection attack is a method of defeating biometric verification by inserting a synthetic or pre-recorded video stream directly into the software capture layer, before any liveness or face-match check runs. There is no physical scene, no lens, and no genuine capture event. The system receives frames that look like they came from a camera but were placed there by the attacker.
The European standard built specifically for this threat, CEN/TS 18099, draws a useful distinction that clarifies the whole category. It separates the injection attack method, meaning how the fake is delivered, from the injection attack instrument, meaning what gets delivered. The method might be a virtual camera, an emulator, a hooked software function, or manipulated network traffic. The instrument is the payload itself: the deepfake video, synthetic face, or manipulated image sequence the attacker wants the system to accept. Understanding both halves matters, because they are defeated by completely different controls, and this piece is closely related to the broader picture in our guide to how deepfakes bypass KYC.
Where Injection Fits in the Verification Pipeline
A remote verification system moves a biometric through a chain of stages: data capture, signal processing, matching against a reference, and a final decision. Liveness detection, the check meant to confirm a real person is present, almost always runs at the data capture stage, on the assumption that the camera feed is trustworthy.
That assumption is the whole vulnerability. Because liveness runs at capture, an attacker who inserts a deepfake after the physical camera but before the software reads the frame lands the fake upstream of every downstream check. The liveness model, the face-match, and the decision engine all evaluate the injected stream as though it were genuine. This is precisely why attackers moved to injection: modern liveness systems can readily spot a screen or a mask presented to a lens, so the rational move is to bypass the capture stage where that detection lives rather than try to beat it head-on.
How Injection Attacks Work: The Attack Vectors
Injection methods range from trivial to highly technical. Most real-world fraud clusters at the easy end, but the sophisticated methods are what make injection so hard to shut out completely.
Virtual Cameras
A virtual camera is software that presents itself to the operating system as an ordinary webcam while feeding in whatever video the attacker chooses. Legitimate versions of this technology exist for background replacement on video calls, which is part of what makes it so accessible. The attacker points the verification app at the virtual camera instead of the real one and pipes in a deepfake. This is the most common injection method by a wide margin, precisely because it requires so little sophistication.
Emulators and Rooted Devices
Instead of a virtual camera on a normal machine, an attacker can run the verification app inside a mobile device emulator, an environment where the camera feed is entirely under their control. A related approach uses a rooted or jailbroken physical device with tamper-detection bypassed, giving the attacker low-level control over what the app receives. Both let the attacker substitute the camera input without the app recognizing the substitution.
SDK and Function Hooking
More capable attackers target the software development kit that a verification provider ships to its client apps. By reverse-engineering the SDK, they locate the specific function calls that capture and transmit camera frames, then use hooking frameworks to intercept those calls and replace the real frames with a deepfake. This attacks the integration itself rather than the device, and it can defeat systems that assumed the SDK was a trusted boundary.
Transport-Layer Interception
At the most sophisticated end, an attacker manipulates the network traffic between the client and the verification server, swapping the genuine biometric payload for a synthetic one while it is in transit. Here the deepfake never touches the device's capture path at all; it is inserted into the data stream on its way to the server.
Why Injection Beats Traditional Liveness
The uncomfortable truth for many verification stacks is that passing a presentation-attack test proves very little about injection resistance. The two threats are tested by entirely different frameworks. ISO/IEC 30107-3 defines how to evaluate presentation attack detection, the ability to catch photos, masks, and replays shown to a camera. It was never designed to address injection, which enters below the sensor. As iProov puts it, a vendor can hold PAD certification and still have zero resilience to injection attacks.
This matters because presentation-attack detection has become table stakes, which can create false confidence. A buyer sees a liveness certification and assumes the system is secure, when the certification speaks only to spoofs shown to the lens. Injection sidesteps every camera-based tell: there is no glare, no screen bezel, no missing depth, because no physical scene was ever recorded. Manual review does not rescue the situation either. Reviewers identify high-quality deepfakes only about a quarter of the time, worse than a coin flip, and people are even less able to catch a live video deepfake than a still image.
The regulators and standards bodies have caught up to this gap. CEN/TS 18099 is the first technical specification dedicated to injection attack detection, tested by independent labs against methods like virtual cameras, USB cameras, function hooking, and rooted devices. The forthcoming ISO/IEC 25456 aims to globalize those requirements, and NIST's updated digital identity guidelines now require, at higher assurance levels, that a biometric system confirm the signal came from a real, live person rather than a replayed or manipulated input.
Common Mistakes IDV Teams Make
Equating liveness certification with injection resistance. PAD certification under ISO/IEC 30107-3 says nothing about whether a system can detect an injected stream. Injection resistance needs its own testing, against CEN/TS 18099.
Analyzing only the image, not the path. A system that scores the pixels but never asks where the frames came from cannot see a virtual camera or a hooked SDK. The camera path carries the strongest injection signals.
Trusting the SDK as a fixed boundary. Attackers reverse-engineer client SDKs and hook the frame-capture calls. Integration integrity has to be verified, not assumed.
Relying on active liveness prompts. Asking a user to blink or turn does not help when the entire feed is injected, because a pre-rendered or real-time deepfake can perform the requested action on cue.
Leaving manual review as the safety net. With human accuracy on strong deepfakes near a quarter, a reviewer is not a reliable last line of defense.
How to Detect and Stop Injection Attacks
Because injection has two halves, the delivery method and the payload, effective defense addresses both, and no single signal is sufficient. The guiding principle from recent industry and standards work is to score the capture path, not just the camera output.
The first half is capture-path and environment integrity. This means confirming that frames originate from a genuine device camera rather than a virtual one, detecting emulators and rooted devices, verifying SDK and session integrity to surface function hooking, and validating the biometric payload in transit to catch transport-layer swaps. Device sensor signals help here too: motion data from a phone's accelerometer and gyroscope during capture is hard for an injected stream to reproduce and adds no friction for the user.
The second half is detecting the synthetic payload itself. Even a perfectly delivered injection still carries a deepfake, and that deepfake leaves artifacts: unnatural blends where a swapped face meets the jawline, the absence of a real camera sensor's noise fingerprint, and temporal inconsistencies across frames. This is where DuckDuckGoose's DeepDetector fits into a verification pipeline, analyzing the delivered image and video for the signatures of synthetic media so that a deepfake is flagged even if it reaches the matching stage. Paired with capture-path integrity checks, payload detection closes the gap from both directions, which is exactly the layered, defense-in-depth approach that CEN/TS 18099 and NIST's guidelines now push toward. Mordor Intelligence names DuckDuckGoose AI among the major companies in the fake image detection market.
Frequently Asked Questions
What is an injection attack in identity verification?
It is a method of defeating verification by inserting a deepfake video directly into the software capture layer, so the system processes attacker-supplied frames as though they came from a real camera. There is no physical scene and no genuine capture, which is what separates it from a presentation attack.
How is an injection attack different from a presentation attack?
A presentation attack shows a fake, such as a photo, mask, or replayed video, to a real camera. An injection attack bypasses the camera entirely and feeds a synthetic stream into the software. They require different defenses, and detecting one does not mean a system can detect the other.
Why can injection attacks defeat liveness detection?
Liveness detection runs at the point of capture and assumes the camera feed is genuine. Injection places the deepfake upstream of that check, so the liveness model, face-match, and decision engine all evaluate the fake as if it were real. Camera-based tells like glare or depth do not exist because no scene was captured.
What is a virtual camera attack?
It is the most common injection method. The attacker uses software that presents itself to the system as a normal webcam while feeding in a deepfake stream. The verification app reads from the virtual camera instead of the real one and never sees the substitution.
Does PAD or liveness certification protect against injection attacks?
Not on its own. Presentation attack detection certification under ISO/IEC 30107-3 tests only spoofs shown to a camera. Injection resistance is tested separately, under the CEN/TS 18099 specification. A system can be PAD certified and still have no defense against injection.
How can organizations detect injection attacks?
By scoring the capture path in addition to the image: confirming frames come from a genuine camera, detecting virtual cameras, emulators, and rooted devices, verifying SDK and session integrity, validating the payload in transit, and layering synthetic-media detection to catch the deepfake itself. No single check is enough, so controls are stacked.
What standards address injection attacks?
CEN/TS 18099 is the first technical specification dedicated to injection attack detection, complementing ISO/IEC 30107-3 for presentation attacks. The forthcoming ISO/IEC 25456 aims to globalize injection-detection requirements, and NIST's digital identity guidelines require injection safeguards at higher assurance levels.
Which industries are most exposed to injection attacks?
Any sector relying on remote biometric onboarding, including financial services, crypto exchanges, telecommunications, healthcare, and gaming. Crypto has been especially hard hit, with one benchmark recording a sharp rise in deepfake-related incidents, and injection is now the fastest-growing vector across verification networks.
.png)
About the author
