InfernoGrabber : le ransomware navigateur écrit par une IA

Catégorie : Ransomware

Analyste : Gordon PEIRS

Famille : malware généré par un LLM (DeepSeek), qui se nomme lui-même « InfernoGrabber v9.0 ». Les antivirus le classent PyStealer, InfernoStealer ou TrojanRansom selon l'éditeur.

Type : analyse à partir des métadonnées VirusTotal, du rapport comportemental d'une sandbox tierce et de larges extraits du vrai code source, récupérés par un canal détourné (voir §2.1). Je n'ai pas le fichier complet, mais c'est une lecture directe du code et pas une synthèse de rapports.

Résumé

Check Point Research a documenté le premier cas connu où un LLM (DeepSeek), à partir d'un seul prompt qui ne mentionnait ni ransomware ni malware, a généré une chaîne d'attaque fonctionnelle : un « ransomware navigateur » qui exploite la File System Access API de Chromium, sans binaire natif ni installation. Plutôt que de résumer la presse, j'ai relu de larges extraits du vrai code source, récupérés dans le rapport d'une sandbox tierce (CAPE), et ça corrige plusieurs points du récit. D'abord, ce n'est pas vraiment « sans binaire natif ». Le script Python complet importe de vraies bibliothèques système (browser_cookie3, pyperclip, pyautogui, selenium) qui, une fois installées, donnent un accès à l'hôte bien au-delà du bac à sable du navigateur, même si l'extrait récupéré ne montre pas leur appel. Ensuite, des commentaires en russe dans le code (décodés depuis un encodage corrompu) et un compte Discord au nom d'affichage russe nuancent le récit « l'IA a agi seule », sans permettre d'attribution géographique certaine. Enfin, le schéma de la base de données interne trahit une ambition bien plus large (jetons Discord, cartes bancaires, webcam, micro) que la liste de capacités publiée par Check Point. Aucune activité réseau réelle n'a toutefois été capturée dans les deux rapports de sandbox disponibles.

1. Contexte et pourquoi ce sujet

Le 1er juillet 2026, Check Point Research a publié "Browser-Only Ransomware: From LLM Hallucinations to a Practical Attack Technique". L'article documente le premier cas connu où un modèle d'IA (DeepSeek) a construit, à partir d'un seul prompt qui ne contenait ni « ransomware » ni « malware », une chaîne d'attaque fonctionnelle qui combine : - un risque jusque-là considéré comme théorique : un « ransomware navigateur » sans binaire natif, sans installation, sans exploit ; - une vraie fonctionnalité légitime de Chromium : la File System Access API, qui donne à une page web un accès en lecture et en écriture à un dossier local après une seule autorisation de l'utilisateur.

J'ai choisi ce sujet pour changer complètement de terrain : pas de binaire à désassembler, du Python et du JS, et l'angle « l'IA auteur de malware » plutôt que « malware qui cible les outils d'IA ».

2. Acquisition : ce qui a été récupéré et ce qui ne l'a pas été

L'échantillon identifié par Check Point est deepseek_python_20260125_da0631.py, déposé sur VirusTotal le 25/01/2026.

2.1 Le vrai canal trouvé : les rapports de sandbox individuels contiennent un aperçu statique du fichier

L'endpoint /files/{id}/behaviours liste les sandboxes qui ont analysé l'échantillon, ici CAPE Linux et Zenbox, deux sandboxes tierces intégrées à VirusTotal. Chacune a son rapport HTML complet, accessible par /file_behaviours/{id}/html. Celui de CAPE Linux inclut un aperçu statique du fichier source, avec plusieurs milliers de caractères de code Python lisible, bien plus que les quelques URL de la vue « summary » agrégée. Ce n'est pas le fichier complet, parce que le panneau de prévisualisation de CAPE le tronque au-delà d'une certaine longueur, mais c'est un vrai extrait du vrai code, pas une reconstruction. Le contenu est au §6.

Côté méthode : c'est une acquisition partielle. J'ai lu une partie du code par le rapport HTML détaillé d'une sandbox précise, et non par la vue agrégée. Pour une lecture intégrale, il faudrait le fichier non tronqué.

3. Identité de l'échantillon

Noms de détection par vendeur (échantillon) : Microsoft Trojan:Python/InfernoStealer.MMK!MTB, Kaspersky Constructor.Python.Agent.l (catégorie Kaspersky pour les outils générateurs/builders, ce qui colle avec un artefact de génération LLM plutôt qu'un malware écrit à la main), ESET Python/Spy.Agent.CYT, TrendMicro Trojan.Win32.Pystealer.VSNW02G26, BitDefender/Emsisoft/GData/VIPRE/Arcabit Generic.PyStealer.AD.7125BC1B (moteur Bitdefender partagé par plusieurs revendeurs).

4. Architecture (d'après le rapport Check Point)

Utilisateur → page web "AI Discord Avatar Upscaler" (lure)
  → showDirectoryPicker() : demande d'accès à un dossier (ex. Photos/DCIM)
    → énumération récursive du dossier en JavaScript
      → lecture des fichiers via handles de fichiers du navigateur
        → transmission au backend Flask (exfiltration)
          → chiffrement in-place dans le processus navigateur
            → overlay de rançon (paiement Bitcoin exigé)

Le fichier unique deepseek_python_20260125_da0631.py contient à la fois : - Un serveur Flask (backend Python) : routes de réception des données exfiltrées, panneau d'administration - Le HTML/JS servi aux victimes (frontend), embarqué dans des templates Python

5. Le point central du rapport Check Point : ce qui marche vraiment vs ce qui est halluciné

C'est la partie la plus intéressante de ce cas, et la raison pour laquelle il ne faut pas prendre le titre « ransomware généré par IA » au pied de la lettre.

Check Point qualifie la plupart de ces tentatives d'« hallucinations IA » : des fonctions qu'une application web ne peut techniquement pas réaliser dans le bac à sable du navigateur, mais que le modèle a écrites comme si elles marchaient. Le nom que le malware se donne (« InfernoGrabber v9.0 », qui évoque un grabber complet) décrit donc surtout une ambition, pas son comportement réel.

Ce que ça dit de DeepSeek comme générateur de malware : le modèle a produit un code en partie fonctionnel à partir d'un prompt qui évitait les mots « ransomware » et « malware » tout en gardant l'intention. D'après Check Point, il refuse systématiquement les demandes directes (« génère un ransomware »), mais on contourne ce refus en découpant la demande. Dans une de ses réponses, le modèle aurait lui-même décrit sa sortie comme un « piège qui combine une interface d'upscaler IA convaincante avec un comportement caché de type ransomware ». Il « savait » donc ce qu'il générait, et il a continué.

6. Recoupement indépendant : le rapport comportemental sandbox VirusTotal

VirusTotal a exécuté ce script dans ses propres sandboxes (Linux et Windows). Je n'ai donc pas eu à l'exécuter moi-même.

6.1 Un vrai webhook Discord d'exfiltration retrouvé en mémoire

Parmi les URL observées en mémoire pendant l'exécution en sandbox :

https://discord.com/api/webhooks/1465066143516459277/g5X5V-ehzLCWP_S1kOkR4-EL2fdhev3xznUV3OtVUNJ0sNA

Vérification indépendante (une requête GET en lecture seule, qui ne poste rien sur le webhook) :

{"message": "Unknown Webhook", "code": 10015}

Au moment de cette vérification, le webhook est déjà mort, supprimé par l'attaquant ou désactivé par Discord Trust & Safety. Un webhook Discord est une infrastructure qu'on peut signaler et faire désactiver, mais celui-ci n'est plus actif : il n'y a rien à signaler.

L'ID du webhook (1465066143516459277) est un snowflake. Une fois décodé, il donne une création le 25/01/2026 à 19:29 UTC, le jour même du dépôt sur VirusTotal et de la date inscrite dans le nom du fichier (deepseek_python_20260125_da0631.py). Le canal d'exfiltration a donc été créé le jour où l'échantillon a été généré et soumis. Il ne vient pas d'une campagne antérieure.

6.2 Autres éléments retrouvés en mémoire

• cdn.discordapp.com/avatars/422811769203851274/3a2ee1c7e9297563376cc2f3ad88c79a.webp, image d'avatar Discord utilisée dans l'interface leurre ("upscaler"). L'ID a été résolu en profil via un service de lookup public (japi.rest, qui interroge l'API Discord avec son propre bot ; pas besoin de token personnel). Le compte : username bogatov, nom d'affichage ТОТ САМЫЙ ("celui-là même", en russe), créé le 12/03/2018 (concorde avec le décodage du snowflake), utilisateur Nitro (bannière animée), membre d'un serveur au tag de clan ST (guild 1049805573190864916, créée le 06/12/2022, badge de clan présent sur le CDN, donc Guild Tag actif d'un serveur établi). L'avatar CDN répond toujours (HTTP 200) et son hash correspond, confirmant qu'on regarde le bon compte. Le serveur ST a son widget désactivé (code 50004) et n'est pas résoluble par l'ID seul via les canaux non authentifiés : son nom et ses membres nécessiteraient un code d'invite ou un bot déjà présent, non disponibles ici.

Attribution. Convergence notable : le code est commenté en russe (§6bis.2) et l'avatar du leurre appartient à un compte russophone actif. L'hypothèse "avatar tiers récupéré au hasard" tient donc moins ; le plus probable est que l'auteur a réutilisé son propre compte Discord (ou un compte associé) pour le leurre, ce qui pointe vers un opérateur russophone. Ce n'est cependant pas une preuve : un leurre "upscaler d'avatar Discord" affiche par construction un vrai avatar, et l'auteur a pu emprunter celui d'un tiers russophone. Le propriétaire de l'avatar est identifié (bogatov/ТОТ САМЫЙ) ; l'équation "ce compte = l'opérateur" reste probable mais non démontrée. Aucune donnée personnelle réelle (nom civil, e-mail, IP) n'est exposée par ce lookup, seulement le profil pseudonyme public. - html2canvas.hertzen.com/dist/html2canvas.min.js, bibliothèque tierce légitime de capture d'écran DOM-vers-canvas, cohérente avec la fonctionnalité "capture d'écran" mentionnée par Check Point comme tentée (mais non fonctionnelle selon eux, possible que la bibliothèque soit chargée sans que l'intégration fonctionne réellement). - code.responsivevoice.org/responsivevoice.js?key=H3t4r7kP, bibliothèque de synthèse vocale tierce (avec une clé API en clair), ce qui colle avec un overlay de rançon qui "parle" pour intimider la victime. - Fichiers audio mixkit.co (cris d'horreur : "mixkit-scary-scream", "mixkit-horror-scream", "mixkit-terrified-scream"), effets sonores d'intimidation pour l'overlay de rançon. - Signature Yara detected TrojanRansom en mémoire du process python.exe (sévérité HIGH), confirme la classification ransomware au niveau comportemental, pas seulement statique. - Signature "Creates a process in suspended mode (likely to inject code)". Question ouverte : à vérifier si c'est un vrai comportement d'injection ou un artefact générique de l'interpréteur Python/multiprocessing sur Windows (le thème "hallucination IA" de ce cas incite à la prudence avant de conclure à une vraie capacité d'injection).

6bis. Lecture directe du code source : ce que ça change au récit de la presse

En fouillant les rapports de sandbox individuels (§2.1), j'ai trouvé dans le rapport CAPE Linux un aperçu statique de plusieurs milliers de caractères du vrai fichier deepseek_python_20260125_da0631.py. Ce n'est plus une déduction à partir d'un résumé tiers. C'est une lecture directe, même partielle.

6bis.1 Ce n'est pas "sans binaire natif" : c'est un script Python natif complet avec de vraies bibliothèques système

Les vrais imports du fichier :

import os, sys, json, base64, logging, sqlite3, threading, hashlib, uuid, time, random, string
import requests, re, subprocess, zipfile, io, hashlib, secrets
from datetime import datetime
from flask import Flask, request, render_template_string, Response, jsonify, send_file, redirect
from flask_sock import Sock
import websocket
import qrcode
from cryptography.fernet import Fernet
import browser_cookie3
import pyperclip
import pyautogui
import psutil
import GPUtil
import socket, struct, select
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

browser_cookie3 (vol de cookies des navigateurs installés), pyperclip (accès au presse-papiers), pyautogui (capture d'écran, automatisation de la souris et du clavier) et selenium (pilotage d'un vrai navigateur) sont des bibliothèques Python légitimes et fonctionnelles si elles sont installées. Ce ne sont pas des capacités de « navigateur sandboxé », ce sont des capacités natives au niveau de l'hôte. Ça contredit en partie le récit repris par la presse généraliste (« sans binaire natif », « browser-only »). Tel qu'il est écrit, le « paquet complet » est un script Python natif dont les dépendances, une fois installées, donnent un vrai accès au système, pas seulement ce que peut faire une page web dans le bac à sable de Chromium. La partie « navigateur » décrite par Check Point (File System Access API) est sans doute ce qui est livré à la victime, le JS servi par Flask. Ce fichier Python, lui, est l'outil complet de l'attaquant (serveur et automatisation). Les titres de presse (« browser ransomware », « no-install attack ») écrasent cette distinction.

Vérification dans le code récupéré : dans les ~8 Ko lisibles (imports, config, classe InfernoDB), ces bibliothèques natives n'apparaissent que dans les lignes import. Elles ne sont jamais appelées. Je n'ai trouvé aucun pyautogui.screenshot(...), browser_cookie3.chrome(...), pyperclip.paste(...) ou webdriver.Chrome(...) dans ce que j'ai récupéré (recherche par motif dans les deux rapports de sandbox et le résumé comportemental). Les seules fonctions visibles sont __init__ et init_tables, celles de la classe base de données. L'aperçu CAPE se coupe au milieu de la table microphone_captures, avant tout code métier qui appellerait ces bibliothèques. Je ne peux donc ni confirmer ni infirmer leur usage réel. L'affirmation « capacités natives réelles » s'arrête aux imports. Et comme aucune des deux sandboxes VT n'a réussi à faire tourner le script jusqu'au bout (§6bis.3), il n'y a pas de confirmation dynamique non plus.

6bis.2 Des commentaires en russe : signal d'attribution qui nuance "l'IA a agi seule"

Les commentaires du code (décodés depuis un encodage mojibake dans le rapport HTML) sont en russe :

Liste complète des commentaires cyrilliques de l'extrait : КОНФИГ АДА (config de l'Enfer), ИНИЦИАЛИЗАЦИЯ (initialisation), Логирование всего (journalisation de tout), БАЗА ДАННЫХ АДА (base de données de l'Enfer), puis les en-têtes de tables Жертвы (victimes), Discord токены, Банковские карты (cartes bancaires), Крипто кошельки (portefeuilles crypto), Кейлоггер, Скриншоты, Вебкамера, Микрофон. Le thème "Ад/Enfer" (le mot Ада est le génitif de "enfer") colle avec le nom auto-attribué "InfernoGrabber".

Ce que ça dit, et ce que ça ne dit pas. Ces commentaires ne figurent pas dans le rapport de Check Point, qui précise d'ailleurs : "We do not have the prompt submitted to the AI model that produced this sample". Ils ne connaissent pas la langue du prompt, et mon observation du russe ne doit rien à leur analyse. Il ne faut pas la surinterpréter. Des commentaires en russe sont aussi compatibles avec un prompt rédigé en russe (le modèle aurait alors généré le code, commentaires compris, sans retouche humaine) qu'avec une retouche par un opérateur russophone. Ils ne prouvent donc pas une édition humaine après génération, contrairement à ce qu'on pourrait conclure trop vite. Ce qu'ils indiquent de plus solide, c'est un opérateur probablement russophone, côté prompt ou côté édition. Ça nuance surtout le raccourci de presse « l'IA anglophone a tout fait seule », sans permettre d'attribution géographique certaine : un prompt traduit ou un opérateur non russophone qui s'appuie sur un modèle multilingue restent possibles. Ce signal est renforcé de façon indépendante par le compte Discord dont l'avatar sert au leurre, résolu en bogatov / ТОТ САМЫЙ (nom d'affichage russe), voir §6.2. Question ouverte : l'extrait seul ne permet pas de trancher entre prompt en russe et édition humaine.

6bis.3 Portée du projet révélée par le schéma de base de données

Le schéma SQLite (InfernoDB) définit des tables bien plus détaillées que ne le laisse penser la liste de capacités de Check Point : victims (fingerprinting matériel complet : GPU/CPU/RAM/disques/polices/logiciels installés/interfaces réseau/MAC), discord_tokens (avec des champs billing, payment_sources, subscriptions, gift_codes, backup_codes, ce qui vise clairement une prise de contrôle complète du compte et pas un simple token), credit_cards, une table de suivi en temps réel de la souris, du scroll et des fenêtres, screenshots, webcam_captures, microphone_captures (avec un échantillonnage audio détaillé). Ces tables sont-elles remplies par du code qui marche, ou restent-elles vides, ce qui irait dans le sens des « hallucinations » de Check Point ? L'extrait ne permet pas de le dire. Mais l'ambition de conception dépasse de loin le « ransomware avec un peu de vol de données ».

Aucune activité réseau n'a été capturée dans les deux sandboxes VT. Dans CAPE Linux, tous les onglets réseau sont vides (« Nothing to display »). Dans Zenbox, deux IP apparaissent : 8.8.8.8, un simple test de connectivité, et 150.171.22.17, un serveur Microsoft Skype/Teams que Shodan InternetDB confirme comme de la télémétrie de la VM de sandbox, pas l'infrastructure de l'attaquant. Ça colle avec l'hypothèse d'un plantage précoce du script (dépendances comme selenium/pyautogui/GPUtil absentes de l'environnement de sandbox) avant d'atteindre la logique réseau, ce qui expliquerait aussi que le webhook Discord n'ait jamais reçu de vraie requête POST de test.

7. Ce qui reste ouvert

Deux questions restent ouvertes (points 1 et 2). Les quatre autres vérifications sont closes.

1. Le reste du fichier, au-delà de la troncature de CAPE : c'est le vrai blocage. La troncature tombe au milieu de la table microphone_captures (bloc utile ≈ 8 Ko sur 160 Ko), et le rapport Zenbox ne contient aucun aperçu de code : sa structure HTML n'a pas de panneau de prévisualisation du source. Il reste à essayer un compte VT premium ou partenaire (le /download gratuit renvoie 403), ou à contacter Check Point Research.
2. Capacités réelles ou hallucinées (§6bis.1) : dans le code récupéré, browser_cookie3/pyperclip/pyautogui/selenium sont importés mais jamais appelés, et le code qui les appellerait est au-delà de la troncature. La réponse dépend du point 1.
3. Le compte Discord 422811769203851274 (§6.2) : le snowflake donne un compte de mars 2018, l'avatar est toujours en ligne sur le CDN et le profil se résout en bogatov. Que ce compte soit celui de l'opérateur reste probable, pas démontré.
4. Les commentaires en russe (§6bis.2) : Check Point ne les mentionne pas et n'a pas le prompt. La conclusion se limite à « opérateur probablement russophone ».
5. La File System Access API : une reproduction pédagogique est disponible, fsapi-demo.html (énumération récursive en lecture seule d'un dossier jetable, sans chiffrement ni exfiltration).
6. Autres webhooks ou adresses Bitcoin (§6.1) : aucune adresse Bitcoin valide (les candidats base58 ont tous un checksum invalide, ce sont des fragments de blobs base64 en mémoire), et aucun autre webhook que celui déjà connu.

8. Limites (état actuel)

• Je n'ai lu qu'une partie du code source : l'extrait tronqué de l'aperçu statique de CAPE Linux, pas le fichier complet.
• L'affirmation « la plupart des capacités sont des hallucinations non fonctionnelles » vient de Check Point. Ma lecture la nuance en partie (les imports de vraies bibliothèques comme pyautogui/selenium suggèrent une ambition plus native que « browser-only »), sans trancher : je n'ai vu que les imports, pas le code qui les utilise.
• Aucune des deux sandboxes VT n'a fait tourner le script jusqu'à une activité réseau. Je n'ai donc aucune confirmation dynamique indépendante du webhook Discord en action, ni des capacités natives du §6bis.1. Tout repose sur la lecture statique du code et sur ce qu'affirme Check Point.
• Le webhook Discord retrouvé (version complète et version tronquée, testées toutes les deux) est mort, je l'ai vérifié, mais je ne sais pas depuis quand ni qui l'a désactivé.
• Rien ne confirme qu'un ID Discord trouvé dans les URL correspond à l'attaquant plutôt qu'à un avatar d'exemple.
• La piste des commentaires en russe est une observation brute, pas une attribution. Elle peut aussi venir d'un prompt traduit, d'un opérateur non russophone qui utilise un outil de traduction, ou d'un autre scénario. Je la présente comme une nuance au récit de la presse, pas comme une attribution géographique.
• Le comportement « process en mode suspendu » est peut-être un faux positif générique de sandbox et non une vraie capacité d'injection. Non tranché.

9. IOCs consolidés (état actuel)

10. Reproduire l'analyse

Le journal détaillé est dans runbook.md.

Une démonstration pédagogique isolée du mécanisme côté client (File System Access API) est disponible : fsapi-demo.html. À ouvrir dans un navigateur Chromium, sur un dossier de test jetable. La page se limite à énumérer récursivement le dossier en lecture seule, pour illustrer la primitive centrale (une seule autorisation de l'utilisateur donne un accès récursif à tout le dossier). Elle ne reproduit ni le chiffrement ni l'exfiltration du malware.