Injection Attacks: The Deepfake Threat Liveness Alone Misses

Selfie-based verification asks a person to prove they are a live human, present at onboarding, matching their document photo. Two attack classes target that step, and they fail in different ways. Confusing them leads teams to deploy defenses that stop one while leaving the other wide open.

Two Attack Surfaces, One Selfie

A presentation attack shows something fake to a genuine camera: a printed photo, a phone screen replaying a video, a silicone mask, or a paper cutout with eye holes. The camera captures real photons; the deception is physical.

An injection attack skips the camera. The attacker feeds pre-recorded or synthetic frames directly into the video pipeline using a virtual camera driver, an emulator, a rooted device, or a manipulated API call. The sensor never sees the subject. This matters because most liveness models were trained to spot physical artifacts — screen glare, moiré patterns, printed texture. A clean deepfake injected as a video stream carries none of those tells.

Industry telemetry has tracked a sharp shift toward injection. As consumer deepfake tools dropped in cost, attackers moved from holding a phone in front of a laptop to bypassing the capture device outright. A convincing face-swap video that once took hours of rendering can now be generated in minutes and streamed into a fake camera feed.

Why Passive Liveness Is Not Enough

Passive liveness analyzes a single frame or short clip for signs of life without asking the user to act. It is fast and low-friction, and it handles many presentation attacks well. But against injection, a passive model is only as good as its ability to detect that the frames are synthetic or replayed — a much harder problem than spotting a printed photo.

Active liveness asks for a randomized challenge: turn your head, follow a moving dot, blink on cue. This raises the bar for pre-recorded video, since the attacker cannot know the challenge in advance. Yet real-time deepfake pipelines can now respond to some challenges live. Challenge-response buys time; it is not a permanent moat.

The durable defenses target the pipeline itself:

• Device and environment integrity: detecting emulators, virtual cameras, rooted or jailbroken devices, and hooking frameworks that intercept the camera API.
• SDK-level capture binding: cryptographically signing frames at the sensor so injected streams fail attestation.
• Sensor consistency checks: confirming that image metadata, frame timing, and noise characteristics match a genuine camera rather than a rendered feed.
• Behavioral and temporal signals: micro-movements, natural latency, and reflection consistency that current synthesis struggles to reproduce.

Layering Signals Instead of Trusting One

No single check survives contact with a motivated attacker. A workable posture combines device attestation, capture-time binding, and liveness scoring, then routes borderline sessions to a fallback — a fresh capture, a document re-scan, or manual review. The goal is not a binary pass/fail on the selfie but a confidence score fed into the broader risk decision alongside document authenticity, device history, and network signals.

Chat-based verification changes the constraints here. When capture runs through a controlled SDK inside a Telegram or WhatsApp flow rather than an uploaded file, you can enforce that images originate from a live sensor rather than accepting an arbitrary attachment. Accepting a user-supplied file is the weakest possible input, because it discards every capture-time signal that would expose injection.

Keeping the Evidence, Minimizing the Exposure

Defending against these attacks generates data — raw frames, challenge responses, device attestation logs. Under data minimization principles, most of it need not persist. A defensible pattern is to retain the pass/fail decision, the model version, and a hash of the captured image for audit, while deleting raw biometric frames on a short, configurable schedule once verification completes. That preserves your ability to prove a check occurred without holding a growing archive of face data that becomes a breach liability. Treat biometric captures as the most sensitive category you process, and let retention windows reflect that. This is general information, not legal advice; confirm requirements against your applicable regime.