Security incident? Suspected breach? 09 71 18 27 69csirt@synacktiv.com

KYC : Bypass age verification using generative video models

Written by Kevin Tellier, Léo Desmonts - 06/07/2026 - in Pentest - Download

Historically reserved for the banking sector, the KYC (Know Your Customer) process is now making its way into many online services, driven by increasingly strict legislation on anonymity and age verification. To comply, platforms deploy significant measures aimed at guaranteeing the "proof of life" of the user behind their webcam or smartphone. However, the meteoric rise of generative video AI models completely reshuffles the deck, offering attackers formidable and accessible tools to fool these systems. The French PVID framework aims to counter this new threat.

This article establishes a state of the art of current verification mechanisms, before detailing how we used AI to successfully bypass the age verification system of a website relying on AWS Rekognition.

Looking to improve your skills? Discover our trainings sessions! Learn more.

Introduction

KYC (Know Your Customer) is a process that aims to link a physical person to a user by ascertaining their identity. Historically, this practice was mostly reserved for financial institutions. Today, it applies, and increasingly tends to apply, to more and more online services. The goal is to establish a relationship of trust: the company must know precisely who it is dealing with before providing a service. With the strengthening of digital legislation, KYC has become a mandatory step in the fight against crimes facilitated by the digital world, such as identity theft or money laundering. More recently, many countries have been reinforcing their legislative arsenal in order to make age verification mandatory for access to certain online services, with pornographic websites and social networks squarely in their sights. 

This article seeks to establish a state of the art on KYC methods and existing bypass techniques. We will compare AI-based bypass solutions using local models and a low-cost infrastructure against a cloud equivalent (deepfake-as-a-service). We will close with a concrete example of bypassing age verification on an adult website. If it is mainly this part you are interested in, you can jump right to it.

The reference frameworks

To frame these verifications from a technical standpoint, several standards have been created. In France, ANSSI has set up the PVID framework (Prestataire de Vérification d'Identité à Distance — Remote Identity Verification Provider). It mandates "proof of life" tests to ensure that the user is physically present behind their camera and is not using a mere photo, a pre-recorded video or a mask.

At the European level, the eIDAS regulation serves as the framework. Its purpose is to harmonise practices across member states: a digital identity validated in one country must be recognisable throughout the European Union. Furthermore, the PVID framework is designed to meet at least the requirements of eIDAS.

Internationally, approaches vary by geographic region. The United States, for example, has no centralised framework. Obligations are risk-based and depend heavily on the sector of activity. One example of guidance is NIST SP 800-63, which concerns digital identity and focuses on the analysis of contextual data. In other countries, such as India with the Aadhaar system, the state uses a centralised biometric database to identify each citizen.

The stakes of KYC

For companies, the main stake is the balance between compliance and customer experience. On the one hand, complying with standards such as PVID is a strict legal obligation for certain activities, such as the AML-CFT (LCB-FT) framework imposed on the financial sector. On the other hand, KYC is the first point of contact with the user. If it is too complex or too long, it can create friction that may push the customer to abandon the process. The challenge is therefore to offer a verification journey that is both robust and smooth for the user.

On the user side, KYC is often perceived as a constraint, oscillating between security and privacy. In a world where digital identity theft is highly prevalent, these procedures guarantee that no one will be able to open a bank account or take out a loan in their name. However, this implies entrusting sensitive data (identity document, biometric data, etc.) to third-party platforms. The stake for the user is therefore trust: they accept the constraint of KYC on the condition that their data is protected and that the process is not excessively intrusive.

More recently, in addition to the financial sector and online gambling, pornographic websites and social networks have been thrust into the spotlight. In France, the law of 21 May 2024 tasks ARCOM with establishing age-verification requirements. This authority is then able to order the blocking or delisting of platforms that do not meet these requirements. A number of pornographic websites have already faced delisting, in particular Pornhub, the 4th most visited site in France with 417 million visitors in 2022. The consequence is then a drop of around 28% in traffic in France over the 2nd half of 2025, even though France was one of the most represented countries on the site before the block. This drop in traffic is not, however, total: indeed, the law designates access from the French geographic area (by IP). The use of a VPN therefore makes access to the site possible, including for minors.

The PVID framework

The PVID framework defines a very rigorous technical framework aimed at guaranteeing that the digital identity issued has the same value as a face-to-face confirmation.

ANSSI defines three main phases in this process:

  1. Data acquisition: the user is guided to capture images or videos of the identity document as well as biometric data (video selfie, dynamic challenge).
  2. Data verification: the system verifies the authenticity and validity of the identity document and proceeds to the assessment of the proof of life. The verification often involves validation by a human operator. This verification is not made mandatory by the framework except for the resolution of a doubt or alert raised by the automated system. In practice, the framework imposes the same guarantee as a face-to-face check with "a person generally trained in face comparison", making the human a recurring component in a framework-compliant service.
  3. The decision: the system returns the verdict of the process (success or failure). In addition to the verdict, the PVID provider must compile and retain an evidence file, containing all the elements supporting the decision, in case of dispute.

The following diagram illustrates the PVID process in broad strokes. Note that the framework does not aim to impose technologies, but only the framework itself. It is therefore possible to implement a compliant PVID solution that differs in part from this diagram.

PVID process.
PVID process.

eIDAS, on which PVID is based, defines two security levels. The first is the substantial level. This level tends to reduce, as its name suggests, the risk of identity theft substantially. It targets the classic use cases of PVID KYC (for example, opening a bank account). It is the one that guarantees the value of a face-to-face check. Today, four operators are certified at the substantial level in France: Docaposte IOT, IDnow, NjF Vision and Namirial.

The second level is the high level. It is reserved for sensitive actions such as qualified electronic signatures (electronic signature of level 3 and 4) or notarial deeds. This level is the equivalent of the issuance of an identity document at a town hall or police station. Note that no operator is currently certified by ANSSI for this level. It therefore remains, to this day, purely theoretical for this framework.

Finally, PVID also imposes sovereignty and IT security constraints: the provider must protect the integrity of the captured data against interception and ensure that the execution environment has not been compromised. However, this aspect does not fall within the attack surface considered by the majority of attackers, and will therefore not be explored further in this article.

State of the art

As described in the previous section, the PVID framework uses several pieces of data, including images of the identity document and of the user's face. Within the scope of this study, we position ourselves as an attacker in possession of a valid identity document belonging to a third party.

Bypassing a KYC system requires two vectors: images capable of defeating the liveness analysis, and a means of presenting these images to the system. We will use the term injection to refer to the presentation of the fraudulent images.

Data injection

Regarding injection, the PVID framework provides for two main cases:

  • physical presentation to the camera (a photo, a mask, makeup);
  • injection of a video by replacing the data source during the acquisition phase.

Nowadays, modern liveness detection systems have almost no chance of being fooled by a physical presentation without significant resources. Indeed, only the use of latex masks of the kind used in cinema and made to measure, accompanied by an appropriate makeup job, makes it possible to obtain good results, at a fairly significant cost (around €10,000). The rest of this article will therefore focus on injection methods at the acquisition level.

There are today several techniques for injecting a pre-recorded video, or one generated on the fly using artificial intelligence. It is for example possible to use kernel drivers to emulate image sources, and to use them during capture. This is what is done by the virtual cameras of OBS. On a device you fully control, it is possible to add a virtual camera very easily. On Linux, the kernel module v4l2loopback allows this manipulation:

$ modprobe v4l2loopback devices=1 video_nr=10 card_label="Logitech HD Pro Webcam C920" exclusive_caps=1 max_buffers=2

This new virtual camera, onto which a video stream is injected, can be used in a browser for example:

New video device detected.
New video device detected.

By streaming a video to the new device:

$ ffmpeg -re -stream_loop -1 -i demo.mp4 \
    -f v4l2 -vcodec rawvideo -pix_fmt yuv420p \
    -s 1920x1080 -r 60 \
    /dev/video10
Fake image streamed on the new video device.
Fake image streamed on the new video device.

In the case where the KYC procedure is to be carried out on a smartphone (which is often the case), it is possible to intercept calls to the cameras' API with Frida and redirect the buffers so that they read from an MP4 file and not the physical sensor. Likewise, by going through a mobile emulator, the virtual cameras will be easily configurable to suit our needs.
    
All of these techniques, historically effective and easy to implement, are countered by several measures from KYC operators. The goal is to no longer naively process the data received by the server, and thus to be able to verify the origin of the video.

The most effective measures concern captures made from a smartphone. It is for example possible to use the sensor attestation mechanism. The application can call upon the Secure Element of the device, if it has one, to sign a buffer. If the video comes from another source (Frida buffer or virtual camera), the signature will be invalid or missing.

In the same spirit, to guarantee that the application is executed on a smartphone, the Play Integrity API for Android and App Attest for iOS make it possible to verify whether the application is not running in a virtual machine or on a rooted device (mainly by analysing memory and system properties). Forcing the integrity of the smartphone is a first possible measure to counter opportunistic attackers. However, forcing the use of these mechanisms automatically disqualifies any alternative mobile operating system that does not offer them.

Finally, one of the strengths of smartphone capture is access to motion data. KYC solutions therefore have the option of using motion metrics (accelerometry). This data makes it possible to analyse the accelerometric background noise. Indeed, holding a smartphone in hand creates tremors. If the accelerometer returns a fixed value, or a loop, the solution can conclude that a data injection is probably underway. In addition to the value alone, it is possible to correlate the value with the video images. Even if the gyroscope values are not suspicious in themselves, if they are inconsistent with the images provided by the video sensors, that is also a strong signal of an image injection.

Other, more generic detection methods also exist. The latter are not specific to the use of a smartphone, and can be applied in a desktop environment. The verifications can be performed server-side or client-side, with WebAssembly. It is regularly the second option that is chosen, because it offers real-time, intermediary-free telemetry capabilities, hence more precise ones. Hardware-consistency verification first makes it possible to compare the number of CPU cores declared by the browser with the actual performance measured via intensive computation loops in WASM, a discrepancy often betraying an emulated environment. Next, clock detection uses WASM counters to detect the micro-latencies induced by a debugger or to distinguish an authentic hardware clock from a virtualised clock, which is generally more irregular. Finally, anti-hooking measures target the interception of functions such as navigator.mediaDevices.getUserMedia: the module verifies whether the function indeed points to native code and ensures that no "monkeypatching" has been applied. For example, in the case where format constraints on videos are too demanding, the following code makes it possible to hook the getUserMedia function, and to lower the resolution constraint to accept any video.

// Save original function
const originalGetUserMedia = navigator.mediaDevices.getUserMedia
// hook function to intercept contraints
navigator.mediaDevices.getUserMedia = async function(constraints) {
  // Delete unecessary keys to remove the need to provide them
  for (const key of ["facingMode", "frameRate", "deviceId"]) {
    if (constraints && constraints.video && Object.hasOwnProperty.call(constraints.video, key)) {
      delete constraints.video[key];
    }
  }
  // Relax mandatory keys to broader values
  if (constraints && constraints.video) {
    constraints.video.width = { min: 1, ideal: 1920, max: 3840 };
    constraints.video.height = { min: 1, ideal: 1080, max: 2160 };
  }
  // Call original function with new contraints
  return originalGetUserMedia.call(navigator.mediaDevices, constraints);
};

Note that presenting low-quality videos has multiple advantages, such as generation time, with a lower level of detail making detection more complex. It is therefore sometimes necessary to upscale the quality and the frame rate of an initial video, in order to meet strict constraints. Audits conducted by Synacktiv have revealed that the implementation of the Lanczos algorithm (for resolution) and the "Motion Interpolation" function (for frame rate) of the FFmpeg tool offer a good results/execution-time ratio. The following command makes it possible to upscale a 480p video to 720p, and to go from 25 to 30fps.

$ ffmpeg -i input.mp4 -vf "scale=1280:720:flags=lanczos,minterpolate=fps=30" -c:v libx264 -c:a copy output.mp4

Finally, it is crucial to note that if the KYC process does not require the use of a native mobile application, webcam verification in a browser (Desktop) constitutes the path of least resistance for an attacker. On a desktop operating system, the isolation between the browser and the system is much less strict. Virtual cameras are perceived there as standard peripherals, and the web capture APIs (WebRTC) do not yet have "chain of trust" mechanisms as mature as those of mobile environments. If the workflow allows switching to a computer, the attacker will systematically favour this vector for its ease of manipulation.

Bypassing liveness

It is reasonable to assume that anti-injection measures will be bypassed by determined attackers. This chapter will therefore take inventory of the main liveness measures, which is the decisive phase during a KYC process.

Detection techniques

There are three categories of detection techniques: passive detection, active detection and human verification. Obviously, combining techniques from all three categories greatly improves the effectiveness of a detection solution.

Passive detection

Passive detection analyses the video stream without imposing any particular action on the user. The goal is to detect physiological or physical signals that are impossible to reproduce faithfully with a photo or a replayed video.

A first approach relies on textural and spectral analysis. A paper print or a screen presents a uniform texture and a homogeneous light reflection, characteristic of a flat surface. Conversely, human skin presents micro-variations in texture and a localised reflection (mainly on the forehead, the nose and the cheekbones). These properties are analysed via texture descriptors such as LBP (Local Binary Patterns) or CNNs trained specifically on fraud datasets.

Next, modern algorithms incorporate an analysis of micro-movements. Breathing, ocular saccades or facial micro-expressions produce image deformations whose frequency distribution is characteristic of a living being. A deepfake would be more likely to present either an absence of these signals, or an overly regular distribution.

Finally, more recent and particularly robust, is the detection of the cardiac signal by rPPG (remote photoplethysmography). By analysing the minute colour variations on the surface of the face caused by blood flow, it is possible to extract a heart-rate signal. A photo or a pre-recorded video obviously does not present this signal, or presents it in a manner inconsistent with the capture conditions. This method is nevertheless sensitive to lighting variations and to video compression, which makes it a good technique in theory, but difficult to apply to KYC processes in uncontrolled environments.

Active detection

Unlike passive detection, active detection relies on challenges, and therefore requires an action on the part of the user, or at the very least actively creates an interaction with them.

The most widespread challenge is the head movement: the user is invited to turn their head according to instructions displayed on the screen. The randomness of the sequence aims to render the replay of a pre-recorded video ineffective. This challenge is also relatively effective against classic deepfakes that apply a mask which ends up deformed beyond a certain angle. Coupled with a strict time constraint, this mechanism is relatively effective against opportunistic attacks.

In the same spirit are voice challenges. The user is invited to pronounce a sequence of words. In addition to lip synchronisation, some implementations cross-reference the audio analysis with facial movements to detect any inconsistency between the two streams.

A third, more sophisticated approach, developed and patented by iProov under the name Flaskmark, relies on the projection of coloured light flashes via the device's screen onto the user's face. As the sequence is random, the solution relies on the difficulty of reproducing light reflections on the face in near real time with an AI model. This solution has the other major advantage of not requiring any direct action from the user, even though it is an active solution.

Human verification

Human verification remains, to this day, one of the mechanisms most difficult to fool systematically. Operators trained in detecting fakes manually review the verification videos: they look for inconsistencies on the face such as "glitches", and detect contextual inconsistencies such as artificial lighting, suspicious outlines around the face or hesitant user behaviour.

However, human verification is not without limits. Fatigue, cognitive biases and the processing throughput of verification centres can lead to verification errors. Moreover, deepfakes generated by recent generative video models reach a level of realism sufficient to fool a non-specialist observer, especially when the quality of the video is degraded.

Bypassing using Artificial Intelligence

Recent developments in the field of artificial intelligence have seen the emergence of diffusion models capable of performing several types of tasks:

  • image-to-video: Generation of a video from a reference image and a prompt;
  • text-to-video: Generation of a video from a written prompt describing the desired content of the video;
  • video-to-video: Modification of a video from another video and a prompt of instructions;
  • video-to-text: Textual description of a video, often embedded in so-called "vision" models, such as the latest series of Qwen3.6 models.

 
A wide range of models covering more specific needs is also offered: depth estimation, object detection, classification, etc.
 
The video-to-video category is of particular interest to us in the case of deepfake generation, because it makes it possible to obtain more natural movements by providing a video of an actor as input. The offering of video models is very rich, both in open-source and in closed-source, where some of the main players, such as Alibaba, release the older versions of their closed-source models as open-source on the huggingface platform.

The most emblematic open-source model in the video-to-video category is Wan2.2 Animate, developed by Alibaba (also the authors of the Qwen suite). This 14-billion-parameter model makes it possible to replace a person in a video with another person, with a single photo as the only reference.

The advantages over traditional deepfakes are multiple. First, deepfakes based on a face-swapping approach require a more or less lengthy training phase to obtain convincing results. Generative video models, on the other hand, require no training phase. The downside is a slightly longer rendering time. Next, in order to obtain a convincing result, it was necessary to have a morphology and a hairiness similar to those of the victim. Indeed, traditional deepfakes merely apply the victim's mask onto the reference video. As a result, the proportions of the face are distorted and the hair is not replaced.

The approach of using generative video models is slightly different: the Wan 2.2 Animate model requires a pose mask in order to extract the movements of the face and then animate the reference image. Thus, no mask is applied over the original face, which removes the appearance of obvious outlines that can be found on a deepfake and, above all, the proportions of the victim are preserved. In particular, head movements do not reveal any deformation of the mask.

Video file

Despite these many advantages, a few areas for improvement remain. In particular, the movement of the eyes and the mouth is often imperfect. These points were, moreover, raised by the operators during PVID audits.

As mentioned earlier, some challenges rely on the use of light flashes on the user. Among the two models tested, only Wan 2.2 Animate takes into account the variation in the lighting environment.

Video file

The passing of an object in front of the person's face, the head movements and the pronunciation of words also work with a perfectly acceptable level of realism.

Two approaches were evaluated for generative video deepfake generation:

  • Self-hosted solution on a server equipped with an NVIDIA RTX 5090 graphics card (32GB VRAM);
  • Cloud-hosted solution with Comfy Cloud.

ComfyUI

Both approaches use the ComfyUI interface for its intuitiveness, the large number of workflows and components available. Indeed, many platforms offer turnkey solutions for producing generative video deepfakes (Kling, Wan, Luma, Higgsfield). However, the flexibility provided by Comfy, in particular the ability to combine several tasks in a single workflow and the fine-tuning of settings, steered us towards this solution.

Presentation of the interface

ComfyUI interface.
ComfyUI interface.

The interface proposes linking functional blocks together in order to constitute a workflow. Each of these nodes (blocks) corresponds to a Python function in the form of a black box accepting parameters and outputs of different natures: images, video, number, text, etc. Each node can then be linked via an input/output pair of the same type (for example, an output of type image can be sent to an input of type image on another node).

A set of nodes constitutes a workflow that can be exported and reused turnkey by the community. A library of additional modules developed by the community makes it possible to add new nodes, to download models directly from Huggingface or even workflows.

Performance

Although the workflows are heavily optimised to reduce VRAM usage, it is worth varying the different parameters, in particular the size of the models used, in order to optimise resources as best as possible and find a balance point between quality and speed.

Indeed, many KYC platforms impose a constrained time between the sending of a challenge and its resolution. The time is deliberately quite generous in order to take into account technical constraints such as connection drops or slow connections. Thus, the challenge is very often to optimise each node of the workflow to obtain a fast result.

The processing time of a workflow is heavily influenced by the resolution of the input data. For example, generating a video in 1080p at 60 FPS is much longer than a video in 360p at 20 FPS. It is then advisable to identify the technical limits accepted by the KYC service. As presented earlier, it is also possible to upscale the resolution and to inject frames, these processes being very often far less costly in computation time.

By optimising the workflow in order to produce 5-second videos in the format 480x720p30FPS with an RTX 5090, the rendering time is around 3 minutes with the Wan 2.2 14B Animate model.

By way of comparison, using a similar workflow with the closed-source model Kling 3.0 on Comfy cloud takes around 7 minutes (the performance is rather disappointing and probably explained by the time it takes to be allocated a GPU).

Demonstration

In order to illustrate the bypass capabilities against a non-PVID KYC system in a concrete case using age verification, an adult video site was selected. Other examples exist, such as banks, but for legal reasons they were not retained (the creation of bank accounts under a false identity being punishable by law).

When accessing the site from France, the traditional form asking the visitor to confirm their adulthood had been replaced by a message informing that French legislation requires age verification provided by the British service AgeGo.

AgeGo age verification.
AgeGo age verification.

This service offers several verification methods:

  • Selfie: Video verification of the user's face requiring them to align their head within a circle. Algorithmic verification only.
  • Selfie + identity document: Comparison of an identity document with the previous method.
  • Bank card (not available in France): Verification from a bank card, no biometric verification.
  • Digital identity: Use of the Yoti Digital ID application. This method then reuses the Selfie + identity document mechanism.

On the analysed site, only the Selfie and Yoti methods are available:
 

AgeGo verification methods.
AgeGo verification methods.

For this demonstration, the simplest method was chosen, Selfie verification. Once this method is selected, the challenge is relatively simple and uses a local machine learning model for face detection (Blazeface 1.0.2 with TensorFlow.js) and AWS Rekognition.

AWS Rekognition offers several video recognition services (celebrity identification, age verification, gender, etc.). Several types of challenges are offered by this service, here FaceMovementChallenge. The service claims to put in place mechanisms for detecting deepfakes, pre-recorded video injection or physical masks.

Analysis of the verification process

The verification mechanism begins with the creation of a server-to-server session as described in the documentation of the AgeGo service via the following request:

GET /s2s/start/?nonce=n8c4zzfpme1mo8zy&isu=d3d3Lnh2aWRlb3MuY29t&siteid=73&ch=eyJicmFuZHMiOlt7ImJyYW5kIjoiTm90L0EpQnJhbmQiLCJ2ZXJzaW9uIjoiOCJ9LHsiYnJhbmQiOiJDaHJvbWl1bSIsInZlcnNpb24iOiIxNDIifSx7ImJyYW5kIjoiR29vZ2xlIENocm9tZSIsInZlcnNpb24iOiIxNDIifV0sIm1vYmlsZSI6ZmFsc2UsInBsYXRmb3JtIjoiV2luZG93cyIsImFyY2hpdGVjdHVyZSI6ImFtZDY0IiwiYml0bmVzcyI6IjY0IiwibW9kZWwiOiIiLCJwbGF0Zm9ybVZlcnNpb24iOiIxMCIsImZ1bGxWZXJzaW9uTGlzdCI6W3siYnJhbmQiOiJOb3QvQSlCcmFuZCIsInZlcnNpb24iOiI4In0seyJicmFuZCI6IkNocm9taXVtIiwidmVyc2lvbiI6IjE0MiJ9LHsiYnJhbmQiOiJHb29nbGUgQ2hyb21lIiwidmVyc2lvbiI6IjE0MiJ9XX0%3D HTTP/2
Host: myapi.agego.com
[...]

The following parameters are present:

  • nonce: Nonce used subsequently to prevent replay attacks;
  • isu: Identifier specific to the user;
  • siteid: Site identifier;
  • ch: JSON structure describing the browser used by the user.

The GET /api/session/self endpoint returns the user's attributes:

{
    "is_user": false,
    "is_valid": true,
    "site_id": 73,
    "site_name": "Xvideos",
    "is_verified": false,
    "logo_filename": "site_logos/466d1cdb426a9ac6eb142711243bed20.png",
    "methods": [
        "photo-age-with-id-fallback",
        "yoti-age-verification"
    ],
    "doubleAnonymityMethods": [
        "photo-age-with-id-fallback",
        "yoti-age-verification"
    ],
    "origin": "AS8QfJEaDuPbmiYUILNw4Jm5j2LjX8FI9HuHqO",
    "is_child": false,
    "should_register": false,
    "has_otp": false,
    "passkey_scanned": false
}

From it one can list the available verification methods and the user's verification state with the "is_valid" attribute.

The GET /api/config/aws endpoint, which comes a little later in the process, returns a Cognito Identity Pool:

{
    "region": "eu-west-1",
    "cognito_identity_pool_id": "eu-west-1:9ad6f3b1-6a50-4392-adb2-afc0dbb92fba"
}

Cognito is an AWS IAM service allowing the integration of authentication and user-management mechanisms. An Identity Pool is a directory of federated identities that can be used to request credentials granting access to AWS services.

We then observe that the application retrieves credentials for this same Identity Pool via the AWSCognitoIdentityService.GetCredentialsForIdentity action:

POST / HTTP/2
Host: cognito-identity.eu-west-1.amazonaws.com
[...]

{"IdentityId":"eu-west-1:607701a0-6de1-c5fb-e37c-35389610fb49"}

[...]
HTTP/2 200 OK
{
    "Credentials": {
        "AccessKeyId": "ASIAWA5YBUBW3U5OKT4X",
        "Expiration": 1774014481,
        "SecretKey": "HES[...]cpv",
        "SessionToken": "IQoJb3JpZ2luX2VjEG0aCWV1LXdlc3QtMSJGMEQCIHuxUMGnJLS0T4RUTyT3p/[...]
    },
    "IdentityId": "eu-west-1:607701a0-6de1-c5fb-e37c-35389610fb49"
}

These credentials could be used directly on the AWS API or CLI to access services.

Before the challenge is launched, a verification session is created on the AgeGo API, which provides a token used subsequently to obtain the results of the Rekognition service:

GET /api/verify/photo-age-fallback/create-liveness-session HTTP/2
Host: myapi.agego.com
X-Ag-Sid: CCLhOA2plrO6YYWB39k5MjGepIgqbBZxtMQWBlIGtm18ZH2NQCIbA7DBZ130Ul
X-Verification-Method: photo-age-with-id-fallback
[...]

HTTP/2 200 OK
[...]
{"token":"3b41c11e-c1b7-425d-8b16-afab79c3c942","provider":"aws"}

 

A websocket session is started via the GET /start-face-liveness-session-websocket endpoint on the host streaming-rekognition.eu-west-1.amazonaws.com (service hosted in Ireland). 

GET /start-face-liveness-session-websocket?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIAWA5YBU[...]0320%2Feu-west-1%2Frekognition%2Faws4_request&X-Amz-Date=20260320T124823Z&X-Amz-Expires=299&X-Amz-Security-Token=IQoJ[...]ZYh&X-Amz-Signature=047915034c671cd8ce42c01cd91c1e470645124bfa4f64dd671c9c6f2add2481&X-Amz-SignedHeaders=host&attempt-count=2&challenge-versions=FaceMovementAndLightChallenge_2.0.0%2CFaceMovementChallenge_1.0.0&precheck-view-enabled=0&session-id=bdaf1a7f-3847-4f67-aa13-5abe70a9bd0e&video-height=1080&video-width=1920&x-amz-user-agent=aws-sdk-js%2F3.967.0%20ua%2F2.1%20os%2FWindows%20lang%2Fjs%20md%2Fbrowser%23Google-Chrome_142%20api%2Frekognitionstreaming%233.967.0%20m%2FE%20aws-amplify%2F6.16.2-framework%2F3-ui-react-liveness%2F3.6.0 HTTP/1.1
Host: streaming-rekognition.eu-west-1.amazonaws.com
[...]

HTTP/1.1 101 Switching Protocols
[...]

Next, a few websocket exchanges make it possible to fix the challenge and its configuration:

Websocket exchange 1.
Websocket exchange 1.
Websocket exchange 2.
Websocket exchange 2.

Once the face is identified, signed video chunks in webm format are sent over the same websocket channel, until the end of the challenge:

Websocket exchange 3.
Websocket exchange 3.

Finally, the challenge is verified with the token retrieved earlier:

GET /api/verify/photo-age-fallback/verify-selfie?token=3b41c11e-c1b7-425d-8b16-afab79c3c942 HTTP/2
Host: myapi.agego.com
[...]
HTTP/2 200 OK
[...]
{"status":true,"age_verified":true,"should_register":true}

The user's verification state then switches to true:

GET /api/session/self HTTP/2
[...]
HTTP/2 200 OK
[...]
{
    "is_user": false,
    "is_valid": true,
[...]

Instrumenting the bypass solution

As we observed during the analysis of the verification process, a signature of each video chunk is put in place within the websocket exchange. The simplest solution then remains to emulate a video stream via the kernel module v4l2loopback.

As the challenge consistently consists of moving the head backward and then forward, it is necessary to record a model video serving as the basis for the deepfake generation. Thus, aligning the face with the challenge makes it possible to solve the challenge systematically.

However, a video device cannot be used simultaneously by two programs. As the goal is both to capture the challenge video with OBS and to retransmit the webcam stream to the verification web page, it is necessary to proceed as follows:

  • Creation of a v4l2loopback device:
$ modprobe v4l2loopback devices=1 video_nr=10 card_label="Shared_Webcam" exclusive_caps=1
  • Addition of a V4L2 source in OBS.
  • Starting the Virtual Camera (assigned to the v4l2loopback device, /dev/video10).
  • Recording the verification session via the "Start Recording" button in OBS:
OBS interface.
OBS interface.

The recording of the challenge can then be used in the ComfyUI workflow:

ComfyUI workflow.
ComfyUI workflow.

This workflow performs the following tasks:

  • Extraction of the first frame of the previously recorded video;
  • Ageing of the person's face via the NanoBanana Pro image model;
  • Generation of the deepfake with the Kling 3.0 model.

Submitting the challenge

The video obtained in the previous step can then be loaded directly into OBS by loading a source of type Media and ticking the "loop" option.

The virtual camera now broadcasts the deepfake video in a loop and is ready to be used to submit the challenge.

Streaming of the fake video.
Streaming of the fake video.
Video file

The challenge then passes the algorithmic validation and grants access to the site's content.

Validation of the AgeGo challenge.
Validation of the AgeGo challenge.

Attempts to replay videos were also carried out. Replaying the video without modification fails; however, moving the video within OBS during the challenge is enough to bypass this limitation.

Conclusion

KYC is a current issue that must face technical challenges in the wake of new, ever more convincing technologies. The arrival of generative video models reshuffles the deck, both for algorithmic and human verification mechanisms. This technology fills the shortcomings of the face-swapping approach to deepfakes (training, realism, prerequisites for the actor).

Via the use of online video-generation services based on a generative video model, it is quite simple to bypass the age-verification mechanisms, notably those put in place on pornographic websites.

Frameworks such as PVID provide a framework and technical guarantees for these verification mechanisms. In constant evolution, the new methods tested during audits are referenced by ANSSI in an approach of continuous adaptation. Recent findings prompt the consideration of new detection methods, potentially themselves based on generative video models or on digital-identity services.

Bibliography