Persona’s device-based injection attacks report 2026

Executive summary

Although AI is eroding the barrier for entry-level fraudsters, injection attacks remain an effort-intensive fraud vector for many bad actors. As a result, fraudsters who use injection attacks often target organizations where each successful attack yields a meaningful payout.

While injection attacks are also less prevalent than presentation attacks, that doesn’t mean fraudsters aren’t trying to scale injection-based fraud attacks.* For example, on multiple occasions, a Persona customer with a large global user base recorded more than 150 account-creation attempts with injected selfies in a 10-minute span.

In this report, we provide a brief overview of injection attacks and how they occur. Then, we take a closer look at two methods for detecting device-based injection attacks.

*Persona's 2026 selfie fraud report found that injection attacks make up about 14% of fraud attempts.

Key injection attack statistics

This report focuses on a subset of injection attack methods and related defenses. In particular, we examine whether we can use the camera label’s name (e.g., “Back Triple Camera” on an iPhone) and the absence of expected metadata (e.g., an iPhone missing a camera label) as indicators of an injection attack.

At a high level, here’s what we did and found:

• We analyzed seven million selfie verifications across organizations that frequently experience injection attacks.

• Five virtual camera labels accounted for about 60% of submissions flagged by camera-name rules. Recognizable virtual camera software accounted for 68% of those submissions, while individual phone-mirroring rigs accounted for 32%.

• After combining similarly named labels, we cataloged approximately 650 distinct camera device labels associated with failed selfie verifications. However, renaming a camera’s label is trivial for attackers, and label-name-based rules only caught 6,078 suspicious selfies.

• We tested an alternative approach and found 202,360 selfies (2.9% of all traffic) came from a camera that didn’t share expected metadata. This cohort had a 26% verification failure rate, roughly 3.25x the rate for similar legitimate traffic.

Skip ahead for a deeper dive into these findings, or start with an overview of injection attacks.

We previously found that about 14% of selfie fraud attempts are from injection attacks, and bad actors were 194% more likely to inject videos of real people than AI selfies.

Overview: injection attack features and methods

In the context of identity verification and fraud, an injection attack occurs when someone injects an image or video into a verification process. For example, a fraudster might inject a deepfake selfie and a matching fake ID into a selfie and government ID verification process when attempting to create a new account.

Fraudsters use high- and low-tech tools and methods to carry out injection attacks, and we’ll explore some of these below. We’ll also cover why detecting injection attacks requires different signals than detecting presentation attacks or deepfakes.

Detecting injection attacks versus presentation attacks

Injection attacks are different from another common attack vector, the presentation attack, in which someone presents fraudulent material to a camera.

Injection attacks are when fraudsters …	Presentation attacks are when fraudsters …
Use software or hardware to replace or intercept a camera stream.	Present an image, recording, or livestream to the capture device.
Manual review teams might be able to tell the content is injected, especially if they can review a video of the selfie.	Manual review teams might be able to easily distinguish presentation attacks from legitimate selfies.

Injection attack detection (IAD) and presentation attack detection (PAD) can both involve image-based analysis. However, some IAD methods require additional analysis to understand how the material is delivered.

The difference between detecting injection attacks and deepfakes

Injection attacks are the primary delivery method for deepfakes and other AI-generated or manipulated images and videos. However, IAD isn’t the same as deepfake detection because fraudsters may inject images and videos of real people rather than deepfakes. In fact, our earlier analysis found that attackers are nearly three times more likely to inject videos of real people.

Fraudsters can also use deepfakes in presentation attacks. For instance, they might print an ID with a deepfake portrait and then take a picture of it during a government ID check. As a result, deepfake detection often combines visual and delivery analysis, while IAD may focus on how the content enters the verification process.

Injection attack instruments

Fraudsters might steal, buy, or create the images and videos they inject, which are sometimes referred to as injection attack instruments (IAIs). These can include:

• AI-generated and AI-modified images and videos.

• Manually created or altered images.

• Recordings of real or generated material.

• A live stream altered with filters or a face swap.

For example, a fraudster might purchase a stolen ID and then use AI to create a deepfake selfie video based on the ID's portrait. Alternatively, fraudsters might set up a phishing website that tricks people into submitting selfies. They can then inject these stolen selfies into a selfie check.

Injection-attack methods

Injection attack methods (IAMs) can range in complexity. Basic attacks may involve the virtual camera tools that YouTube and Twitch streamers use legitimately every day. More complex attacks can involve emulated, jailbroken, or rooted mobile devices, as well as sophisticated code-based attacks.

This chart provides an overview of the common IAMs and submethods. The IAM glossary at the end has an explanation of each method.

Two approaches to detecting device-based injection attacks

This report focuses on two methods for detecting device-based injection attacks. The first uses relatively simple checks to flag basic attempts. The second is more difficult to build and maintain, but it can identify more sophisticated attacks.

Combined, they represent part of the device-based layer that Persona uses in its larger IAD framework. We’re starting with these because device-based injection attacks tend to be easier to conduct and are therefore more prevalent.

Method 1. Checking camera names against a deny list

One of the simplest methods for conducting injection attacks is to use desktop-based virtual cameras to insert a selfie into a verification flow. Fraudsters can choose from many virtual camera systems, including popular options that come preinstalled on devices or are available as free downloads.

Virtual cameras have legitimate use cases, such as livestreaming events, streaming video games, and recording podcasts. But it’s also easy to use them to inject recordings and live streams into a selfie verification request.

Five popular virtual cameras and one big caveat

We found that five camera labels accounted for about 60% of the injected selfies we flagged. Overall, 68% of the volume was attributable to recognizable virtual camera software.

Roughly one in ten labels contained a non-English name, such as caméra virtuelle. The remainder came from low-volume, phone-mirroring rigs. Below, you’ll find combined totals for similar labels, listed under each software’s English name.

Some customized camera labels appeared in multiple submissions. “Rudy’s S26 Ultra,” for example, appeared 43 times. We also detected 429 labels, including “Wesley’s Z Fold5,” that only appeared once. The data doesn’t show whether the people behind those one-off labels stopped after a failed attempt, switched methods, or renamed their cameras.

Camera labels aren’t reliable signals

It’s easy to rename a camera label, and some fraud toolkits include renaming as a built-in option. As a result, the list doesn’t necessarily identify the five virtual cameras fraudsters use most often or capture the full range of attacks we stopped.

But just because it’s easy to spoof doesn’t mean you should ignore the camera label. Checking labels and updating your deny list as new virtual camera software becomes available can be a simple way to stop basic injection attacks.

Tip: A missing camera label can be suspicious, particularly when you know which label the device should report. Look for mismatches as well, such as a device that reports two cameras when that model has three.

Method 2. Analyzing device metadata

There are many ways to detect virtual camera usage and, by extension, injection attacks without relying on the camera’s label.

For example, real devices may report metadata about the camera and the content, including:

• Camera position (front or back)

• Aspect ratio and resolution

• Frame rate (for video)

• ISO sensitivity

• Exposure

• White balance

Understanding what you can collect, how your systems may alter the results, and what legitimate submissions look like can help you detect injection attack setups. In particular, look for device and camera metadata that’s:

• Missing: The camera doesn’t report metadata that you’d expect a real camera to report, such as the ISO sensitivity.

• Mismatched: The reported specs don’t match the device’s capabilities. For example, a claimed camera type that can’t produce the expected resolution or frame rate. Or, a device type that doesn’t have the claimed camera(s).

• Changing: Unexpected changes in device or camera metadata during the verification process can be a strong tell.

Mismatched and changing metadata may be easier to detect than missing metadata. For example, an Android device should never report an iPhone camera. And the same camera should be used during the entire selfie capture process.

Deep dive: missing metadata

Without disclosing too many details that could help fraudsters, let’s take a closer look at how to detect injection attacks based on missing metadata.

Physical cameras produce metadata such as ISO sensitivity (how the sensor responds to light) and white balance (how the camera adjusts for the color of the surrounding light).

Virtual cameras don’t have physical sensors, so they can’t produce genuine sensor readings. They may omit these fields or report fabricated values. Missing data or values that don’t match the claimed device can therefore indicate the use of a virtual camera.

In our analysis, more than 200,000 selfie submissions lacked expected sensor metadata, including ISO sensitivity and white balance.

We also corroborated these findings using two of our fraud models that run multiple checks to detect injection attacks without analyzing camera metadata. As expected, the models flagged selfies missing sensor data at a much higher rate than they flagged selfies from similar traffic overall.

Why don’t the models flag 100% of the selfies with missing sensor data?

There are a few reasons the models didn’t flag more selfies.

First, earlier fraud checks stopped about 30% of selfies with missing sensor data before the liveness or deepfake detection models ran. For example, an organization may have flagged an attempt as fraud and ended the process early.

Second, we train the liveness and deepfake detection models to determine whether a selfie contains a live person or a deepfake. Injection attacks can involve injecting a recording of a real selfie, so liveness detection and deepfake detection won’t necessarily trigger when this happens.

Third, there are legitimate reasons selfies may be missing sensor data (see the next section). This is why stacking signals and checks is important for increasing assurance and avoiding false positives.

A warning on false positives

Missing metadata can be an important signal in a multi-layered detection framework, but the lack of sensor data isn’t necessarily grounds for declining a verification on its own. Some browsers and devices omit certain fields or don’t report metadata. Collection workflows also might inadvertently delete data or fail to collect it.

How Persona detects injection attacks

The two examples above cover some of the methods Persona uses to detect device-based injection attacks. As with fraud prevention more generally, detection and prevention require multiple layers of defense.

Persona’s IAD framework combines various types of IAMs detection with image- and population-level analysis:

• Device: Checks whether the device or camera has missing, mismatched, or changing metadata. We also look for signs that the device is rooted, jailbroken, emulated, or simulated.

• Application: Detects app tampering and repackaging using several methods, including native Google and Apple app tools.

• Runtime: Inspects the runtime environment for signs of function hooking, where attackers redirect the native camera call to a video feed.

• Network: Assesses the risk of man-in-the-middle (MitM) attacks, in which bad actors try to intercept traffic and inject videos directly into our server.

• Image: Detects GenAI visual artifacts, such as blended items, malformed anatomy, pixel-level noise, and unnatural lighting.

• Population: Flags templates and known deepfake permutations based on insights from Persona’s work in fraud prevention across industries and regions.

Methodology and limitations

For this report, we examined 7,039,504 selfie verification results from 50 organizations. We focused on organizations that frequently experience injection attacks and are part of different industries, including fintech, online marketplaces, crypto, and gaming platforms.

Because we selected organizations with elevated injection-attack activity, these findings are specific to the study sample and shouldn’t be interpreted as attack rates across all Persona customers or the broader market.

The scope of our analysis also depends on when each organization requires selfie verification and what data it collects and verifies through Persona. For example, if an organization uses Persona to automate a step-up to selfie verification, the organization's sample will only include users who were flagged for another reason.

Injection-attack methods (IAM) glossary

A closer look at the ten injection attack methods (IAMs) mentioned in this report. Although we group these into four categories, the methods and categories aren’t mutually exclusive.

Device-based injection

Attackers use software or hardware to inject content into a capture request. Some of these tools have legitimate uses, so using them isn’t always an indication of fraudulent or malicious intent.

• Virtual cameras: Software that allows you to select a digital source and treat it like a physical camera. Attackers can use virtual cameras to replace a live camera feed with prerecorded, generated, or manipulated images and videos.

• Rooted or jailbroken devices: Attackers modify devices to bypass operating system restrictions. This makes it easier for them to interfere with a verification app, bypass security checks, or replace camera data.

• Emulated devices: Software that simulates a physical device, such as a phone. Attackers can use emulators to run verification apps in a controlled environment and automate attempts across multiple emulated devices without managing multiple phones.

• USB-based video sticks: Capture cards and other hardware that attackers can use to record, store, or inject content instead of a real camera or webcam.

Network-based injection

These attacks target verification data as it travels between a device and a server.

• Man-in-the-middle attacks: If attackers defeat or bypass a connection’s security protections, they can alter the submission and replace the content before it reaches the verification service.

Application-level injection

Attackers modify a verification app or bypass it to submit media outside of the intended capture process.

• App tampering and repackaging: Modifying an official app to change its behavior, such as disabling security checks or replacing captured media. Repackaging creates an installable version of the modified app that resembles the original.

• Custom client API calls: Bypassing the real verification app’s capture process and checks by submitting content directly from the attacker’s client to the service’s API.

Runtime-based injection

These techniques change how software behaves, and they often overlap with device- and application-level attacks.

• OS-level camera API hooking: Attackers intercept camera-related functions at the operating system (OS) level to replace the camera feed with another video source.

• App-level API hooking: Attackers interfere with an app while it’s running to modify its behavior. This can allow them to bypass security checks, alter verification data, or replace captured images without necessarily modifying the installed app.

• System library substitution: Attackers replace or redirect a software library that an app relies on with an attacker-controlled version. The substitute can change how a function works, such as how the app receives camera data.