Détection de fraude documentaire : ce qu'un PDF ne peut pas cacher

Nous pensions que la fraude documentaire était un problème visuel. Mauvaises polices. Colonnes mal alignées. Un logo qui semblait légèrement décalé. Nous avons construit des vérifications basées sur ce que les humains voient, car ce que les humains voient était tout ce que nous avions.

Puis un relevé bancaire est arrivé dans notre pipeline. Mise en page propre. Soldes corrects. Chaque vérification visuelle était validée. L'extraction s'est déroulée parfaitement. Mais quelque chose dans le fichier semblait lourd. Trop d'objets pour un relevé de six pages, comme une valise qui pèse plus lourd que son contenu ne le devrait. Nous l'avons ouvert dans un éditeur hexadécimal et avons trouvé trois sections de références croisées, deux polices qui n'apparaissaient que sur la page 4, et un opérateur /TouchUp_TextEdit MP : la propre trace laissée par Adobe Acrobat chaque fois que quelqu'un utilise « Modifier le texte et les images ».

Le relevé était un faux. Les chiffres étaient fictifs. Et nos yeux n'avaient aucune chance de le voir.

La fraude ne résidait pas dans ce que nous pouvions voir. Elle résidait dans la façon dont le fichier avait été construit.

La contrefaçon artisanale est morte

La fraude documentaire nécessitait autrefois du talent. Un faussaire avait besoin d'outils de conception, de connaissances en typographie, de patience et d'une compréhension raisonnable de ce à quoi un relevé bancaire devait ressembler.

C'était avant les fermes de modèles.

Aujourd'hui, il existe plus de 160 sites web vendant des modèles de documents préconçus : relevés bancaires, fiches de paie, déclarations fiscales, factures de services publics. Prix moyen : 28 $. Certains proposent des abonnements. L'acheteur remplit ses propres chiffres, exporte un PDF et le soumet pour un prêt, un bail ou une ouverture de compte. Les rapports de l'industrie analysant des centaines de millions de documents dressent un tableau cohérent : environ 1 sur 3 présente des problèmes d'intégrité structurelle, et la fraude en série (le même modèle réutilisé pour plusieurs demandes) a augmenté de plusieurs fois d'une année sur l'autre. Un seul cluster contenait plus de 23 000 documents coordonnés provenant d'une seule campagne.

Ce n'est plus de l'artisanat. C'est une chaîne d'approvisionnement.

Le mensonge au pixel près

Un analyste formé peut repérer les faux évidents. Mais l'écart entre « semble faux » et « semble vrai » s'est effondré. Les outils d'édition modernes produisent des résultats visuellement indiscernables de l'original.

Voici ce que nous avons dû apprendre à la dure : la qualité visuelle n'implique pas l'intégrité structurelle.

Un PDF n'est pas une image. C'est un programme. Si vous avez lu notre article sur les rouages des PDF, vous savez que chaque page est une séquence d'instructions de dessin : des glyphes placés à des coordonnées, enveloppés dans des objets, liés par des tables de références croisées, annotés avec des métadonnées, compressés dans des flux. Toute cette structure existe sous la surface visuelle.

Lorsque quelqu'un édite un PDF, il change ce que vous voyez. Mais il change aussi la structure. De nouvelles polices sont intégrées. Le nombre d'objets change. Les flux de contenu (content streams) sont réécrits. Les horodatages des métadonnées se mettent à jour (ou sont supprimés). Le style de codage interne du fichier (comment son trailer est organisé, quelles clés apparaissent dans sa table de références croisées, s'il utilise des fins de ligne LF ou CRLF) peut ne plus correspondre à ce que prétendent les métadonnées.

Un PDF peut mentir sur ce qu'il montre. Il ne peut pas facilement mentir sur la façon dont il a été construit.

Écouter le fichier

Nous avons dû arrêter de regarder la page et commencer à regarder à l'intérieur du fichier. Voici la piste d'indices que nous avons appris à suivre, couche par couche.

Ce qui est facile à falsifier

Chaque PDF porte des dates de création et de modification, une application productrice et souvent un champ auteur. Le producteur correspond-il à ce que vous attendriez de cette banque ? Y a-t-il un écart suspect entre la création et la modification ? Les champs de métadonnées ont-ils été entièrement supprimés ?

Mais les métadonnées sont le signal le plus faible. N'importe quel éditeur compétent peut les falsifier. Certaines banques légitimes envoient des PDF avec des métadonnées minimales. Et le simple fait de télécharger un PDF met à jour la date de modification dans certains visualiseurs. Les anomalies de métadonnées sont un point de départ, pas une conclusion.

L'empreinte que les faussaires ne peuvent pas effacer

C'est là que ça devient intéressant.

En 2021, les chercheurs Adhatarao et Lauradoux ont publié un article¹ montrant que le style de codage d'un PDF (la combinaison spécifique de clés dans son trailer, le format de sa table de références croisées, les octets magiques d'en-tête et les fins de ligne) agit comme une empreinte digitale pour le logiciel qui l'a créé.

LibreOffice inclut toujours une clé /DocChecksum. Microsoft Word utilise à la fois /Prev et /XRefStm dans son trailer. PDFLaTeX écrit une clé /info en minuscules là où tout le monde la met en majuscule. Le moteur Skia de Chrome omet /ID du trailer et utilise des fins de ligne LF.

Ces modèles survivent à la suppression des métadonnées. Vous pouvez supprimer la chaîne « Producer: LibreOffice » des métadonnées, mais vous ne pouvez pas facilement supprimer le /DocChecksum du trailer sans réencoder tout le fichier. L'empreinte structurelle révèle le véritable producteur même lorsque les métadonnées mentent.

Lorsque nous détectons une incohérence, par exemple si les métadonnées indiquent « BankingCorePlatform 4.2 » mais que l'empreinte structurelle indique LibreOffice, c'est un signal. Pas une preuve. Mais un signal qui mérite d'être corroboré.

L'opérateur mouchard d'Adobe

Les éditeurs PDF laissent des traces dans les flux de contenu eux-mêmes.

Adobe Acrobat insère un opérateur /TouchUp_TextEdit MP chaque fois que quelqu'un utilise l'outil d'édition de texte. C'est un opérateur de point marqué, faisant partie de la spécification PDF pour le balisage de contenu, réutilisé par Adobe pour suivre ses propres modifications. Chaque région modifiée en reçoit un. Modifiez cinq montants sur une page, obtenez cinq marqueurs. (Adobe n'a pas construit cela pour attraper les fraudeurs. Ils l'ont construit pour leur propre gestion de contenu. Il se trouve juste que nous trouvons cela utile.)

Iceni Infix, un éditeur PDF professionnel, utilise un mécanisme différent : des opérateurs /IceniObject <<...>> DP enveloppant les blocs de texte modifiés. Le dictionnaire contient des métadonnées sur la modification.

Ceux-ci ne sont pas cachés dans des endroits obscurs. Ils sont à l'intérieur du flux de contenu, juste à côté des instructions de dessin. La plupart des visualiseurs PDF les ignorent. Nous les lisons aussi directement que nous lisons les commandes de police.

Quand les polices vous trahissent

Les polices sont étonnamment bavardes. Un PDF généré par une seule application, en une seule passe, aura des caractéristiques de police cohérentes : même stratégie d'intégration, même convention de nommage des sous-ensembles (subsets), horodatages de création compatibles dans les tables internes de la police.

Un PDF qui a été édité raconte une histoire différente.

Une police qui n'apparaît que sur une seule page, alors que toutes les autres pages utilisent un ensemble différent, suggère que cette page a été modifiée ou assemblée séparément. Un sous-ensemble de police contenant 3 glyphes mais pesant 15 Ko. Ou un « sous-ensemble » avec plus de 500 glyphes, essentiellement la police complète, dans un document où tout le reste est correctement sous-divisé. Quelque chose cloche.

Ensuite, il y a les horodatages. La table head à l'intérieur d'une police TrueType contient une date de création. Lorsque cette date est éloignée de plusieurs années de la date de création du PDF, la police a probablement été intégrée à partir d'une source différente. Et la table OS/2 inclut un identifiant de fournisseur (vendor ID). Un document avec des polices provenant de trois fournisseurs différents est inhabituel si le producteur revendiqué est une application bancaire qui expédie son propre jeu de polices.

La meilleure partie ? Les éditeurs de polices laissent leur nom dans la table de noms de la police. Trouver des marqueurs « FontForge » ou « AFDKO » à l'intérieur d'une police censée provenir du système central d'une banque est... instructif.

L'historique de modification que les PDF ne peuvent pas supprimer

Les PDF prennent en charge les sauvegardes incrémentielles. Au lieu de réécrire tout le fichier, un éditeur ajoute de nouveaux objets et une nouvelle table de références croisées à la fin. Le contenu original reste intact plus haut dans le fichier.

Cela signifie qu'un PDF peut contenir son propre historique de modification. Les objets de page originaux, les objets de page modifiés et la piste qui les relie. Nous pouvons compter les révisions (plus d'une est inhabituelle pour un relevé généré par une banque), identifier quels objets ont changé, détecter le contenu modifié après l'application d'une signature numérique, et repérer les fichiers qui ont été réenregistrés par un outil différent sans changer le contenu (une technique d'obfuscation courante).

Trois sections de références croisées ou plus dans un relevé bancaire constituent un signal critique. Les banques génèrent les relevés en une seule passe. Elles ne reviennent pas en arrière pour les éditer.

Une anomalie est une coïncidence

Voici la partie que la plupart des articles sur la détection de fraude omettent : les signaux individuels ne sont pas fiables.

Un manque de métadonnées ? Le serveur de la banque pourrait avoir un décalage d'horloge. Une isolation de police sur une page ? Cela pourrait être un changement de mise en page légitime entre les sections. Un nombre d'objets élevé ? Certains générateurs de PDF sont verbeux. Chaque signal que nous avons décrit a une explication innocente.

La clé n'est pas un signal unique. C'est la convergence.

Nous organisons les preuves forensiques en six domaines : contenu, typographie, métadonnées, structure, média et sécurité. Chaque domaine capture une dimension différente de l'intégrité du document. Une découverte dans un domaine est une note. Des découvertes dans deux domaines sont une préoccupation. Des découvertes dans trois domaines ou plus forment un motif difficile à justifier.

Un document avec des métadonnées supprimées et rien d'autre ? De nombreux documents légitimes ont des métadonnées minimales. Score faible.

Ce même document avec des métadonnées supprimées, plus des polices qui ne correspondent pas au producteur revendiqué, plus un flux de contenu contenant des marqueurs d'éditeur, plus deux sauvegardes incrémentielles ? Maintenant, vous avez des preuves provenant de quatre domaines. Chaque découverte a individuellement une explication innocente. Ensemble, la probabilité que les quatre soient des coïncidences chute rapidement.

Un mensonge est une anomalie. Quatre mensonges forment un motif.

Le système de notation reflète cela. Une découverte dans un seul domaine ne reçoit aucune amplification. Deux domaines corroborants : 1,25x. Trois ou plus : 1,5x. Un faux sophistiqué qui laisse des traces à travers plusieurs couches forensiques est signalé beaucoup plus agressivement qu'un document qui a simplement des métadonnées inhabituelles.

Inverser la question

Les signaux forensiques détectent les anomalies. Mais la détection d'anomalies a un problème de symétrie : un document provenant d'une source inhabituelle mais légitime semble tout aussi « anormal » qu'un document falsifié.

Les modèles (templates) inversent la question. Au lieu de demander « qu'est-ce qui ne va pas avec ce document ? », vous demandez « ce document correspond-il à un exemple connu et valide ? »

Pour les types de documents à fort volume (relevés bancaires de grandes institutions, factures de services publics de grands fournisseurs), nous construisons des référentiels de modèles à partir d'échantillons vérifiés. Un modèle capture les empreintes structurelles (polices attendues, modèles de métadonnées, caractéristiques de mise en page) et l'identité visuelle. Nous apprenons au système à quoi ressemble un vrai relevé de la Société Générale : pas seulement le logo, mais la mise en page, la zone d'en-tête, les motifs structurels. Ainsi, lorsqu'un nouveau document arrive, nous pouvons dire « ceci est cohérent avec ce que nous avons vu auparavant » ou « ceci ne correspond à rien de ce que nous connaissons ».

Une forte correspondance de modèle est un signal de confiance : une preuve positive que la structure visuelle du document correspond à des exemples vérifiés. Lorsque des signaux forensiques se déclenchent malgré une correspondance de modèle, c'est particulièrement intéressant : cela suggère que quelqu'un a construit un document pour ressembler à un modèle connu, mais que les rouages internes racontent une autre histoire.

Ce que nous ne pouvons pas (encore) attraper

Nous n'allons pas prétendre que cela attrape tout. Ce n'est pas le cas.

Les soumissions d'images seules déjouent l'analyse structurelle. Si quelqu'un photographie un écran montrant un faux relevé, le résultat est un JPEG dans une enveloppe PDF. Il n'y a pas de flux de contenu à analyser, pas de polices à inspecter, pas d'historique de révision. L'analyse se rabat sur la forensique d'image (analyse spectrale, motifs de bruit, artefacts de blocs DCT), qui est un jeu différent et plus faible.

Le saut de format est une évasion délibérée. Environ 1 soumission à haut risque sur 4 utilise un format de fichier différent du document source. Quelqu'un génère un PDF, fait une capture d'écran, soumet la capture d'écran en JPEG, puis l'enveloppe à nouveau dans un PDF. Chaque conversion supprime les preuves forensiques. C'est l'équivalent documentaire du blanchiment d'un numéro de série.

La reproduction parfaite de modèle est possible. Si un fraudeur obtient le logiciel exact et la configuration utilisée par une banque, il peut produire des PDF avec des empreintes structurelles correspondantes. Aucune incohérence à détecter. Le document semble légitime car il a été produit par des outils légitimes. À ce stade, la fraude est dans le contenu, pas dans le contenant.

C'est pourquoi la détection de fraude est un problème à plusieurs niveaux. La forensique structurelle attrape la classe de fraude où le contenant contredit ses prétentions visuelles. La validation du contenu (les chiffres s'additionnent-ils ? l'équation du solde tient-elle ?) en attrape une autre. L'analyse de réseau (avons-nous vu ce modèle exact chez différents demandeurs ?) en attrape une troisième.

Aucune couche unique n'est suffisante. La question est toujours : combien de couches un fraudeur devrait-il déjouer simultanément ?

Les leçons qui ont survécu à la production

Lorsque nous avons commencé à construire cela chez Holofin, nous pensions pouvoir simplement compter les anomalies. Signaler tout ce qui a plus de cinq signaux. Et voilà.

Nous avons rapidement réalisé qu'un comptage brut de signaux est inutile. Vingt signaux de faible gravité dans un domaine (disons, un générateur de PDF verbeux qui déclenche une douzaine de vérifications structurelles) ne sont pas aussi significatifs que trois signaux de gravité moyenne dans trois domaines différents. Le nombre de signaux était du bruit. La convergence des signaux était l'information.

Nous avons donc reconstruit autour de quelques principes :

• Les signaux sont bon marché, les conclusions sont coûteuses. Exécuter des dizaines de vérifications est rapide. Les interpréter correctement est la partie difficile. Les comptages bruts sont trompeurs. Ce qui compte, c'est si les signaux se corroborent entre les domaines.

• La confiance exige des preuves, pas seulement l'absence de risque. Un scan propre ne mérite pas le statut « de confiance ». Cela nécessite une preuve positive de modèle, une correspondance vérifiée par rapport à un référentiel connu. L'absence de signaux de fraude peut signifier que le document est propre. Cela peut aussi signifier que c'est un format que nous n'avons pas encore appris à analyser. Nous préférons dire « nous ne savons pas » plutôt que « ça a l'air bon ».

• Pas de pile ou face. Chaque signal est calculé à partir de la structure binaire du fichier. Même entrée, même sortie, à chaque fois. Pas de confiance de modèle, pas de réglage de température, pas de variation entre les exécutions. Lorsqu'un signal forensique se déclenche, il pointe vers un fait structurel spécifique (un objet, une entrée de table de police, un opérateur de flux de contenu) que vous pouvez ouvrir dans un éditeur hexadécimal et vérifier vous-même. Les scores de risque « boîte noire » sont inutiles en matière de conformité.

• Tout expliquer. Un analyste voyant « risque élevé » doit pouvoir retracer l'évaluation jusqu'à des conclusions spécifiques, des signaux spécifiques, des octets spécifiques dans le fichier. Si nous ne pouvons pas expliquer le score, le score ne vaut rien.

La vérité qui dérange sur la fraude documentaire est qu'elle est asymétrique. Forger un PDF visuellement convaincant prend 28 $ et vingt minutes. Détecter cette contrefaçon nécessite d'examiner le fichier à un niveau que la plupart des humains ne voient jamais : binaires de polices, opérateurs de flux de contenu, structures de tables de références croisées, chaînes de révision.

Mais l'asymétrie va dans les deux sens. Un faussaire peut faire ressembler un PDF à n'importe quoi. Faire en sorte qu'il soit construit comme le vrai est un problème beaucoup plus difficile. L'empreinte structurelle d'un véritable relevé bancaire (ses polices, son style de codage producteur, sa génération en une seule passe, ses métadonnées cohérentes) est le résultat accumulé d'une pile logicielle spécifique traitant des données réelles.

Reproduire cela est possible. Le reproduire à grande échelle, sur des dizaines de types de documents, tout en obtenant le bon contenu, les soldes corrects et des dates plausibles ?

Ce n'est plus un problème à 28 $.