Le moyen le plus rapide d'empirer dans les FFC avec l'IA est de traiter le modèle comme un distributeur automatique. Il suffit de coller l'invite, d'attendre une charge utile, de la copier dans un terminal et d'espérer qu'un drapeau tombe. Cela fonctionne assez souvent sur des défis faciles pour créer de mauvaises habitudes. Elle échoue dès que le problème devient complexe, bruyant ou tout simplement bizarre.
Une meilleure façon d'utiliser l'IA dans les CTF est de la considérer comme un compresseur d'espace de recherche. Elle peut trier les indices plus rapidement que vous, expliquer une syntaxe peu familière, générer des squelettes de solveur approximatifs, résumer les captures de paquets, traduire les résultats du décompilateur en langage clair et vous aider à comparer une hypothèse à une autre. Ce qu'il ne fait toujours pas, c'est exactement ce pour quoi les bons joueurs de CTF sont payés dans le monde réel : décider de ce qui est important, savoir quand une réponse "plausible" est fausse, préserver l'état à travers une longue chaîne d'expériences, et prouver l'impact au lieu de le narrer. La recherche publique actuelle va dans le même sens. Les travaux de la NYU sur les CTF offensifs et sécuritaires ont montré que les LLM pouvaient battre le participant humain moyen dans certains contextes de compétition, mais que leurs résultats entièrement automatisés restaient inégaux et fortement dépendants des catégories. Leurs travaux ultérieurs sur les repères et les cadres, l'ensemble de tâches professionnelles CTF de Cybench, les rapports publics Cybench d'Anthropic et les recherches plus récentes sur les pentests basés sur la planification montrent tous le même schéma : les modèles s'améliorent, mais l'autonomie s'effondre toujours en ce qui concerne la planification à long terme, le raisonnement complexe et l'utilisation d'outils spécialisés. (arXiv)
C'est cette lacune qui est à l'origine de tout le jeu. Si vous utilisez l'IA comme un coéquipier qui vous aide à penser plus vite, et non comme un substitut à la pensée, elle devient immédiatement utile. Si vous l'utilisez comme un oracle, elle transforme un défi gagnable en un générateur d'hallucinations. Le bon état d'esprit n'est pas "Le modèle peut-il résoudre ce problème à ma place ?". Il s'agit plutôt de se demander "Quelles sont les parties de ce problème qui sont répétitives, à faible effet de levier ou dont le format est suffisamment lourd pour qu'un modèle puisse les accélérer sans devenir le décideur ?" Cet état d'esprit correspond mieux à la manière dont les tests de sécurité réels sont décrits dans la norme NIST SP 800-115 et dans le guide OWASP des tests de sécurité sur le web, qui mettent tous deux l'accent sur la planification, les tests techniques, l'analyse des résultats et l'atténuation des effets plutôt que sur l'utilisation aléatoire d'outils. (Centre de ressources en sécurité informatique du NIST)
L'IA dans les FFC commence par un environnement de pratique adéquat
Avant le flux de travail, les invites ou les outils, vous avez besoin d'un lieu légal pour vous entraîner. Pour l'expérimentation de l'IA sur le web, la Web Security Academy de PortSwigger est l'une des options les plus propres parce qu'elle est gratuite, explicitement présentée comme sûre et légale, et organisée autour de classes de vulnérabilités concrètes plutôt que de vagues descriptions de défis. picoCTF est également utile parce qu'il associe la pratique et la compétition à un matériel d'apprentissage structuré sur la cryptographie, l'exploitation du web, la criminalistique, l'exploitation binaire et l'inversion de code. Hack The Box gère également une plateforme CTF officielle pour les jeux CTF en direct. Si vous souhaitez tester le comportement de votre flux d'IA sous pression, ces environnements vous permettent d'obtenir un retour d'information rapide sans pour autant tomber dans le piège des tests non autorisés. (PortSwigger)
Cette distinction est plus importante avec l'IA qu'avec la prise de notes ordinaire ou les scripts de résolution. Un être humain peut généralement savoir quand il s'éloigne d'un cas de défi pour s'approcher d'un actif réel. Un modèle ne le peut pas. Si vous donnez à un agent une URL et une instruction vague telle que "énumérer tout", il n'a aucune idée de ce qu'est l'infrastructure du concours, de ce qu'est la production, de ce dont le taux est limité pour une raison précise, et de ce que vous êtes réellement autorisé à toucher. Une bonne hygiène en matière de CTF a toujours exigé la connaissance du champ d'application. Une bonne hygiène de l'IA en matière de CTF l'exige deux fois.
Une règle pratique consiste à commencer chaque défi en écrivant quatre choses avant que le modèle n'intervienne : la plate-forme, l'instance cible exacte, la catégorie de défi à laquelle vous pensez qu'elle pourrait appartenir et l'ensemble de fichiers ou d'artefacts dont vous disposez localement. Cela semble trivial, mais cela permet d'éviter un nombre surprenant d'absurdités. Il empêche le modèle d'inventer des points d'arrivée adjacents, de mélanger deux catégories ou de suggérer des outils qui ne correspondent pas à l'ensemble d'artefacts dont vous disposez réellement. Cela facilite également le débogage ultérieur, car vous pouvez déterminer si l'échec est dû au défi, au modèle ou à vos propres hypothèses erronées.
Comment utiliser l'IA dans les FFC sans perdre le contrôle du flux de travail ?
Les flux de travail les plus efficaces en matière d'IA CTF sont ennuyeux, dans le bon sens du terme. Ils sont structurés. Ils enregistrent ce qui s'est passé. Ils facilitent la répétition de la même étape ultérieurement. La norme NIST SP 800-115 décrit les tests de sécurité technique comme un processus qui comprend la planification, l'exécution des tests, l'analyse des résultats et l'élaboration de stratégies d'atténuation. Les conseils de l'OWASP en matière de tests traitent également les tests comme une discipline progressive, et non comme une séquence d'astuces déconnectées les unes des autres. Ce modèle s'adapte mieux au travail des FFC que la plupart des gens ne le pensent. Un drapeau n'est que la dernière ligne d'une boucle beaucoup plus large : réception, classification, conception de l'expérience, exécution, vérification et tenue de registres. (Centre de ressources en sécurité informatique du NIST)
Le tableau ci-dessous est la façon la plus simple d'envisager le rôle de l'IA dans cette boucle.
| Phase de la FFC | Travail à haute valeur ajoutée en matière d'IA | L'homme possède encore | Mode de défaillance commun |
|---|---|---|---|
| Admission et classification | Résumer le texte de l'épreuve, l'étiqueter probablement par catégorie, extraire les noms de fichiers, les points d'extrémité, les protocoles, les encodages. | Décider si l'hypothèse de la catégorie est crédible | Une première classification erronée fait déraper l'ensemble du flux de travail |
| Recon et analyse des artefacts | Générer des analyseurs, regrouper des indices, proposer des commandes de triage rapides, normaliser les sorties | Choisir ce qui vaut vraiment la peine d'être testé | Une énumération excessive et des impasses bruyantes |
| Génération d'hypothèses | Suggérer des classes de bogues probables, des directions de résolution ou des familles d'exploits. | Classer les hypothèses et choisir l'expérience minimale suivante | Des affirmations confiantes mais non étayées |
| Échafaudage d'exploitation ou de résolution | Rédiger des scripts, construire des modèles de charge utile, traduire les résultats des outils, créer des harnais. | Valider chaque hypothèse clé et l'adapter à l'état de la situation | Code fragile et étapes hallucinées |
| Vérification et rédaction | Reformater les traces, résumer les différences, nettoyer les scripts, rédiger des notes | Confirmer la preuve et rejeter les faux positifs | Transformer un récit en "preuve" sans preuve |
Ce tableau n'est qu'une synthèse de ce que la littérature de référence et les documents officiels sur les outils impliquent déjà. Les LLM sont à l'aise lorsque la tâche est structurée, locale et riche en texte. Ils sont beaucoup moins à l'aise lorsqu'ils doivent maintenir un long plan, utiliser correctement plusieurs outils spécialisés et s'adapter à un échec partiel sans dériver. Les travaux de la NYU CTF ont montré des écarts de performance par catégorie, tandis que les recherches ultérieures sur l'étalonnage et la planification ont continué à pointer du doigt l'utilisation d'outils et la cohérence à long terme en tant que points de pression. La documentation des outils raconte la même histoire dans la direction opposée : pwntools, angr, Burp, TShark, Ghidra et Volatility sont tous forts parce qu'ils exposent des primitives précises et inspectables. L'IA est d'autant plus utile qu'elle s'appuie sur ces primitives, et non qu'elle les remplace. (arXiv)
Un simple flux de travail en cinq boucles fonctionne bien dans presque toutes les catégories. Tout d'abord, recueillez les faits du défi sans interprétation : texte de description, pièces jointes, URL, binaires, captures de paquets, hachages, captures d'écran, bannières de service et toutes les réponses initiales. Deuxièmement, demandez au modèle de classer le problème et dressez la liste des inconnues, pas des solutions. Troisièmement, concevez la plus petite expérience susceptible de tuer une hypothèse. Quatrièmement, exécutez cette expérience et saisissez les résultats exacts. Cinquièmement, demandez au modèle d'expliquer l'écart entre les attentes et la réalité. Si vous répétez ces cinq étapes, vous obtiendrez de meilleurs résultats que si vous essayez d'avoir une longue conversation au cours de laquelle le modèle s'associe librement au drapeau.
Un modèle d'invitation qui fonctionne réellement dans les FFC
La plupart des mauvaises sessions de CTF avec l'IA commencent par une mauvaise invite. La pire version est longue d'une ligne, surchargée d'espoir et dépourvue de toute structure : "Résolvez ce défi web pour moi". Cela ne dit rien au modèle sur ce que vous savez, sur les artefacts existants, sur les actions autorisées ou sur le niveau de certitude dont vous avez besoin avant d'exécuter quelque chose. Comme le modèle doit combler ces lacunes d'une manière ou d'une autre, il les remplit généralement avec de la fiction.
Une meilleure invite comporte cinq blocs. Le premier bloc est faits. N'y placez que des données observables : texte de contestation, noms de fichiers, extraits de sortie, en-têtes, fragments d'assemblage, résumés PCAP ou le message d'erreur exact que vous avez vu. Le deuxième bloc est inconnues. Indiquez ce que vous ne savez pas encore. Le troisième bloc est actions autorisées. Si vous ne voulez qu'une hypothèse, dites-le. Si vous voulez un script d'aide Python, dites-le. Si vous ne voulez pas de force brute, dites-le. Le quatrième bloc est forme de sortie requise. Demandez des hypothèses classées, des niveaux de confiance, des étapes de validation minimales ou un bref échafaudage de résolution. Le cinquième bloc est conditions d'arrêt. Indiquez au modèle qu'il doit s'arrêter lorsqu'il atteint un point où une exécution réelle ou une validation humaine est nécessaire.
Voici un modèle de base qui fonctionne bien dans toutes les catégories :
Vous participez à un défi CTF autorisé.
Faits :
- Plate-forme : picoCTF
- Catégorie : web
- Cible : URL de l'instance de défi uniquement
- Comportement observé :
- GET / renvoie 200
- /robots.txt existe
- POST /api/check-stock accepte XML
- Rejouer la même demande de stock ne change rien
- Artéfacts :
- Une paire de requêtes et de réponses Burp
- Un fichier de résultat ffuf
- Une capture d'écran de la page d'administration
Inconnu :
- Si le bogue est XXE, SSRF, ou les deux
- Si des noms d'hôtes internes sont joignables
- Si les différences de réponse sont significatives ou non
Actions autorisées :
- Expliquer les classes de bogues probables
- Suggérer les trois prochaines étapes de validation les plus petites
- Rédiger un script de requête Python minimal
- Ne pas présumer de la réussite
- Ne pas prétendre qu'un drapeau est atteignable à moins que les preuves ne le confirment
Résultats requis :
1. Hypothèses classées avec scores de confiance
2. Les éléments de preuve qui étayent chaque hypothèse
3. Une expérience minimale suivante par hypothèse
4. Un court script Python seulement si nécessaire
5. Une liste des hypothèses qui doivent encore être vérifiées
Ce type d'invite a deux avantages. Il contraint le modèle et accélère l'examen ultérieur. Au lieu de lire un mur de suppositions, vous obtenez une file d'attente. Vous réduisez également le risque que le modèle traite le contenu du défi comme des instructions. Les conseils de l'OWASP en matière d'injection rapide sont directement pertinents ici. L'organisation définit l'injection rapide comme une vulnérabilité causée par des entrées utilisateur ou externes qui modifient le comportement prévu du modèle, et elle recommande spécifiquement de séparer clairement le contenu non fiable, les tests contradictoires et la gestion des entrées externes en fonction des limites. Dans le contexte de la FFC, le texte du défi, les fichiers téléchargés, les pages web, les notes de synthèse et même les chaînes de caractères cachées dans les artefacts sont tous considérés comme des contenus non fiables. (Série d'aide-mémoire de l'OWASP)
Il est facile de sous-estimer ce dernier point. Lorsque vous utilisez l'IA dans les CTF, le défi n'est pas seulement la chose que vous attaquez. Il s'agit également d'une partie de l'input qui attaque votre modèle.
Comment utiliser l'IA dans les CTF en ligne
Les CTF Web sont ceux où l'IA se sent la plus productive, et c'est précisément pour cela que les gens sont négligents. Le modèle est capable de reconnaître des modèles de bogues familiers sur le web. L'académie de PortSwigger couvre les mêmes classes que celles qui dominent de nombreux CTF Web, notamment l'injection SQL, XXE, SSRF, la traversée de chemin et l'injection de modèle côté serveur. Le Top 10 actuel de l'OWASP place toujours l'injection dans l'ensemble de sensibilisation standard pour les applications web. Cela ne signifie pas que le modèle peut repérer le bogue de manière fiable à partir d'une capture d'écran. Cela signifie qu'il existe une riche bibliothèque de modèles disponibles une fois que l'on dispose de suffisamment d'éléments pour réduire l'espace de recherche. (PortSwigger)
La première erreur dans les FFC sur le web est de demander au modèle une classe de vulnérabilité avant d'établir une base de référence. Commencez par des faits ennuyeux. Quelles sont les routes existantes ? Lesquelles redirigent. Quels sont les paramètres pris en compte ? Quels types de contenu sont acceptés. Si l'application se comporte différemment pour GET par rapport à POST, JSON par rapport aux données de formulaire, XML par rapport à JSON, ou un cookie par rapport à un autre. S'il y a une exposition au réseau, Nmap est toujours la bonne primitive pour la découverte d'hôtes et de services. Sa documentation est très claire sur le fait que le balayage des ports est fondamentalement destiné à trouver des services joignables et que les ports ont plus de deux états. Cela est important car un port filtré et un port fermé impliquent des étapes très différentes. Lorsque la détection de version fonctionne, Nmap peut également vous indiquer quelles familles de services sont susceptibles de se trouver derrière les ports ouverts. (Nmap)
Pour la découverte de contenu, ffuf reste l'un des moyens les plus faciles de donner à un flux de travail d'IA un véritable effet de levier, car l'outil est simple, rapide et structuré. Le projet officiel le décrit comme un fuzzer web rapide et documente les utilisations courantes telles que la découverte de contenu, la découverte de serveur virtuel, le fuzzing de paramètres et le fuzzing de données POST. Cela en fait un bon outil pour la génération assistée par modèle de listes de mots ciblés et de règles de correspondance, en particulier lorsque vous disposez déjà de quelques indices provenant du défi ou du cadre d'application. (GitHub)
Un parcours minimal autorisé de découverte de contenu pourrait ressembler à ce qui suit :
ffuf -u https://challenge-instance/FUZZ \N -w ./wordlists/common-web.txt
-w ./wordlists/common-web.txt \N- -mc 200, 204, 301, 302, 307, 401, 403
-mc 200,204,301,302,307,401,403 \N- -fc 404 \N- -fc 404 \N- -fu
-fc 404 \N- -of json
-of json \N- -of json \N- -of json \N- -of json
-o ffuf-results.json
L'IA est utile avant et après cette commande, pas à sa place. Avant l'exécution, elle peut générer une petite liste de mots thématiques à partir d'indices contenus dans le titre du défi, de noms de variables JavaScript ou de noms d'itinéraires que vous avez déjà vus. Après l'exécution, il peut regrouper les résultats en points de terminaison d'authentification probables, en chemins d'administration probables, en actifs statiques, en préfixes d'API et en impasses. Ce qu'il ne doit pas faire, c'est vous dire que /debug-old est "probablement vulnérable", simplement parce que son nom est intéressant.
Une fois que vous avez trouvé du trafic intéressant, Burp devient le centre de gravité. Burp Repeater existe pour une seule raison : modifier et renvoyer un message HTTP ou WebSocket intéressant jusqu'à ce que vous appreniez quelque chose. Decoder existe pour transformer et identifier les encodages. Comparer existe pour différencier des éléments de données similaires, y compris des messages HTTP quasi-identiques. Ces trois outils correspondent presque parfaitement à la manière dont l'IA devrait être utilisée dans les FFC sur le web : Repeater pour les expériences contrôlées, Decoder pour la transformation et la normalisation, Comparer pour un raisonnement discipliné avant-après. (PortSwigger)
Si vous voulez qu'un modèle vous aide, donnez-lui des observations jumelées. Montrez-lui la demande normale et la demande anormale. Montrez-lui la réponse inchangée et la réponse modifiée. Montrez-lui la requête qui renvoie un 403 et celle qui renvoie un 200 après qu'un seul paramètre a été modifié. La qualité du raisonnement du modèle s'améliore considérablement lorsque vous fournissez des deltas au lieu d'artefacts isolés.
C'est là qu'un petit harnais Python peut faire gagner du temps. L'abécédaire de picoCTF enseigne les requêtes HTTP en Python pour le travail de défi, et cette habitude de base s'adapte étonnamment bien. Pour un CTF web, votre objectif n'est pas d'écrire un client géant. Il s'agit d'encoder une micro-expérience répétable afin de pouvoir modifier une variable à la fois et de stocker le résultat. (L'abécédaire de la FCDQ)
import http.client
import json
HOST = "challenge-instance"
PATH = "/api/check-stock"
xml_payloads = [
"""
11"",
"""
<!DOCTYPE foo [ ]> ]>
&xxe;1"""
]
results = []
for payload in xml_payloads :
conn = http.client.HTTPSConnection(HOST)
conn.request(
"POST",
PATH,
body=payload,
headers={
"Content-Type" : "application/xml",
"User-Agent" : "ctf-lab-test"
}
)
resp = conn.getresponse()
body = resp.read().decode(errors="replace")
results.append({
"status" : resp.status,
"reason" : resp.reason,
"body_prefix" : body[:400]
})
conn.close()
print(json.dumps(results, indent=2))
Ce code n'est pas passionnant, et c'est pour cela qu'il est bon. Il fournit un résultat structuré sur lequel le modèle peut raisonner. Au lieu de demander "Est-ce XXE ?", vous pouvez demander "Pourquoi la deuxième charge utile produit-elle une augmentation de la longueur du corps et une erreur d'analyse différente de la première charge utile ?" Cette question est beaucoup plus proche de la façon dont les acteurs du web réfléchissent réellement.
Lorsque l'IA est bien utilisée dans les CTF sur le web, elle accélère le triage des catégories. SQLi en est un exemple classique. PortSwigger définit l'injection SQL comme une interférence avec les requêtes qu'une application adresse à sa base de données, ce qui peut exposer ou modifier des données. Il s'agit d'une description précise, mais elle ne permet pas de savoir si le défi utilise un contexte de chaîne de caractères, un contexte numérique, un canal booléen aveugle, un canal d'erreur ou un chemin hors bande. Le modèle peut vous aider à énumérer les possibilités, mais il vous faut encore déterminer le contexte de manière expérimentale. (PortSwigger)
Il en va de même pour XXE et SSRF. Les définitions de PortSwigger sont importantes car elles vous indiquent ce qu'il faut rechercher. XXE commence souvent par un traitement XML et peut exposer des fichiers côté serveur ou des systèmes internes. SSRF démarre lorsque le serveur effectue une requête en votre nom et peut parfois être poussé vers le localhost ou des points d'extrémité internes. Dans les laboratoires de PortSwigger, ces classes sont clairement séparées pour l'enseignement, mais les FFC les confondent souvent. Un analyseur XML avec un support d'entité externe peut devenir un chemin SSRF si l'entité pointe vers un point de terminaison interne de métadonnées ou d'administration. L'IA est véritablement utile dans ces situations car elle peut proposer la chaîne la plus courte entre "le puits XML existe" et "la récupération interne pourrait être possible", mais vous avez toujours besoin de la réponse du serveur pour le prouver. (PortSwigger)
La traversée de chemin et le SSTI forment une autre paire intéressante. La traversée de chemin consiste à lire des fichiers en dehors des limites du répertoire prévu. Le SSTI consiste à faire interpréter par un moteur de modèles des données contrôlées par l'utilisateur d'une manière qui peut conduire à l'exécution de code. Ces deux types de problèmes méritent d'être observés attentivement. Les défis liés à la traversée de chemin sont souvent liés à la normalisation, au filtrage ou à des chemins de fichiers inattendus. Les défis liés au SSTI sont souvent liés à l'identification du moteur, aux bizarreries syntaxiques et aux hypothèses du bac à sable. L'IA est capable de générer des syntaxes candidates ou des modèles de contournement une fois que l'on sait dans quelle famille de moteurs on se trouve. Elle n'est pas douée pour décider de la famille de moteurs à partir d'un vague problème de rendu. (PortSwigger)
Le piège le plus difficile à éviter pour les utilisateurs d'IA est la logique d'entreprise. Les modèles adorent les vulnérabilités nommées car ils peuvent retrouver des schémas familiers. Ils se débattent davantage lorsque le défi est un bogue de flux de travail, une limite de privilège, une confusion de session ou une transition d'état qui ne devient visible qu'après plusieurs requêtes ordinaires. Dans ces cas, utilisez l'IA pour la comptabilité. Demandez-lui de créer un tableau d'état. Demandez-lui de résumer quels cookies apparaissent après quelles actions. Demandez-lui de regrouper les itinéraires par état d'authentification. Demandez-lui de comparer les corps de réponse et les ensembles d'en-têtes. Ne lui demandez pas la cause première tant que la machine d'état n'est pas déjà sur papier.
Si vous utilisez un espace de travail dédié à l'IA pentest au lieu d'un onglet de chat, les mêmes principes s'appliquent. La documentation publique de Penligent décrit les tâches créées par les opérateurs, les temps d'exécution configurables de Python et de Bash, la possibilité d'invoquer des outils déjà installés dans Kali tels que nmap et hydreet l'importation en un clic des configurations d'outils les plus courantes. Sa page produit met également l'accent sur les messages-guides modifiables, le contrôle du champ d'application, la prise en charge de nombreux outils industriels et les résultats fondés sur des preuves. Dans un laboratoire CTF en ligne, ces fonctionnalités sont moins importantes parce qu'elles sont tape-à-l'œil que parce qu'elles réduisent la prolifération des contextes. Vous pouvez conserver les scripts générés, les résultats des outils et vos propres vérifications manuelles dans un seul flux de travail au lieu de les disperser dans l'historique des terminaux et les fenêtres de discussion. (Penligent)
Comment utiliser l'IA dans les CTF d'exploitation binaire ?
L'exploitation binaire est le domaine dans lequel l'IA semble la plus intelligente de loin et la plus faible de près. De loin, cela semble parfait pour un LLM. Il y a le code, la sortie du décompilateur, l'assemblage, les bogues de mémoire et le besoin de scripts Python. De près, la partie la plus difficile n'est pas la génération de texte. Il s'agit d'une interaction précise avec un processus cible et d'une attention impitoyable aux détails que le modèle lisse souvent.
La documentation officielle de pwntools explique exactement pourquoi la bibliothèque est devenue un standard : elle offre un moyen uniforme de communiquer avec les processus, les sockets et les services distants. La documentation de corefile souligne un autre point important. Les dumps du noyau sont utiles non seulement pour le débogage manuel, mais aussi pour l'automatisation. Vous pouvez utiliser une adresse d'écrasement et un motif cyclique pour calculer les décalages rapidement sans faire l'arithmétique à la main. Il s'agit là d'un point de passage idéal entre le jugement humain et l'accélération de l'IA. (Documentation de Pwntools)
Un modèle pratique pour l'IA dans pwn consiste à diviser le travail en quatre couches. Tout d'abord, le modèle explique le binaire à un niveau élevé : protections, chemin d'entrée probable, fonctions suspectes et classe de corruption possible de la mémoire. Deuxièmement, vous effectuez de courtes expériences pour confirmer la classe. Troisièmement, le modèle rédige un échafaudage pwntools. Quatrièmement, vous déboguez l'échafaudage comme un développeur d'exploit normal. Le détail important est que l'exploit n'appartient jamais au modèle. Il est seulement rédigé par le modèle.
Un échafaudage minimal de pwntools pour un défi autorisé pourrait ressembler à ceci :
from pwn import *
context.binary = ELF("./chall")
context.log_level = "info"
HOST = "challenge-instance"
PORT = 31337
def start() :
if args.REMOTE :
return remote(HOST, PORT)
return process(context.binary.path)
io = start()
# Exemple d'interaction, remplacer par une logique spécifique au défi
io.recvuntil(b"> ")
io.sendline(b "A" * 128)
# Garder la sortie visible pour le triage
print(io.recvall(timeout=1).decode(errors="replace"))
Cet exemple est volontairement simple. Il ne s'agit pas d'un exploit. C'est un harnais. Dans de nombreux challenges pwn, la première chose dont vous avez besoin n'est pas une chaîne ROP. C'est un moyen fiable de piloter le programme, de regarder où il se plante et de comparer les résultats sous de petites variations d'entrée.
Lorsque le problème est un simple débordement, les corefiles vous aident à transformer un crash en un offset. La documentation de pwntools montre explicitement ce flux de travail : générer un motif cyclique, planter le processus une fois, charger le core dump, et vérifier où le motif a abouti. (Documentation de Pwntools)
from pwn import *
payload = cyclique(256)
p = process(["./chall", payload])
p.wait()
core = Coredump("./core")
offset = cyclic_find(core.eip if context.bits == 32 else core.rip)
print(f "Offset : {offset}")
L'IA est douée pour assembler ces étapes, en particulier lorsque vous lui fournissez le décalage du crash, les propriétés de sécurité et la sortie du décompilateur pour la fonction vulnérable. Elle sait dire : "Vous avez probablement besoin de contrôler le RIP après 72 octets, voici un harnais plus propre, voici comment construire une charge utile avec platet voici une liste de contrôle pour ret2win versus ret2libc". Il est moins bon pour savoir si le crash s'est produit avant une vérification de la pile canari, si un décalage par rapport à la première modifie l'alignement d'une manière qui brise vos hypothèses, ou si le service distant se comporte différemment de votre libc local.
C'est pourquoi angr peut être utile, mais seulement à des moments précis. La documentation d'angr définit l'exécution symbolique comme l'exploration de multiples chemins d'exécution en utilisant des variables symboliques et la résolution de contraintes plutôt que des entrées concrètes fixes. Pour les CTF, c'est très utile lorsque le binaire est vraiment un système de contraintes déguisé : un labyrinthe de vérifications sur les octets d'entrée, une branche de succès enfouie, ou une routine de validation avec de nombreuses conditions linéaires ou bitwise. Si le défi est mieux compris comme "trouver l'entrée qui fait prendre au programme le chemin B", l'exécution symbolique est bien adaptée. Si le défi est en fait un toilettage du tas, un comportement de course ou une interaction étroite avec l'état du processus, l'exécution symbolique ne peut que faire perdre du temps. (Documentation Angr)
Un très petit exemple d'angr ressemble à ceci :
import angr
proj = angr.Project("./chall", auto_load_libs=False)
state = proj.factory.entry_state()
simgr = proj.factory.simgr(state)
simgr.explore(find=lambda s : b "Correct" in s.posix.dumps(1))
if simgr.found :
found = simgr.found[0]
candidat = found.posix.dumps(0)
print(candidat)
Ce script n'est pas une solution universelle. Il s'agit d'un rappel de la bonne question. Si la condition de succès de la binaire est textuellement visible et basée sur le chemin, l'IA peut vous aider à obtenir une expérience angr plus rapidement. Si le binaire est vraiment lié à une corruption de la mémoire ou à un état d'exécution subtil, l'IA devrait vous aider à instrumenter, et non à fantasmer.
Ghidra répond au même schéma. La page du projet de la NSA le décrit comme un cadre complet de rétro-ingénierie logicielle avec désassemblage, décompilation, graphique et écriture de scripts. Ces fonctionnalités sont importantes car elles permettent de découper un gros binaire en tranches gérables. Le modèle doit rarement voir l'ensemble du binaire en une seule fois. Il doit voir une fonction, une chaîne d'appels, un groupe de branches ou un voisinage de chaînes suspectes. Une bonne inversion avec l'IA est locale. Une mauvaise inversion avec l'IA est "J'ai collé 7000 lignes de pseudo-C et maintenant le modèle dit que le bogue est probablement dans principal." (GitHub)
Les travaux de référence publics confirment cette prudence. Dans l'étude NYU 2024, les modèles pouvaient résoudre certaines tâches de pwn et d'inversion, mais les performances variaient fortement d'une catégorie à l'autre, et l'analyse des échecs effectuée par les auteurs incluait des sorties vides, une mauvaise exécution des commandes, un code défectueux et un contexte de défi manquant. Des recherches plus récentes sur les agents indiquent toujours que les systèmes forts ont des difficultés avec les plans à long terme, les outils spécialisés et les indices liés à l'expérience. En d'autres termes, les modèles actuels peuvent aider au milieu du travail de pwn, mais ils ont toujours besoin d'un humain pour garder l'exploit honnête. (arXiv)
Comment utiliser l'IA pour inverser les FFC
L'inversion récompense la patience plus que l'intelligence, et l'IA a tendance à simuler l'intelligence. C'est dangereux. La bonne façon d'utiliser l'IA dans l'inversion n'est pas de lui demander d'inverser le défi. Il s'agit de lui demander de réduire la confusion locale.
Commencez par le même triage que vous feriez sans l'IA. Exécuter cordes. Identifiez les bibliothèques importées. Recherchez les encodages évidents, les messages d'erreur, les chemins d'accès aux fichiers ou les marqueurs de format. Ouvrez le fichier binaire dans Ghidra. Trouvez le point d'entrée et les fonctions qui touchent réellement les données contrôlées par l'utilisateur. Décidez ensuite du type d'aide que vous souhaitez obtenir du modèle.
Certaines des meilleures utilisations sont presque éditoriales. Demandez au modèle de renommer les variables d'une seule fonction décompilée en fonction de leur utilisation. Demandez-lui de résumer le flux de contrôle en langage clair. Demandez-lui de deviner quelles branches correspondent à la validation ou à l'anti-analyse. Demandez-lui de transformer trois fonctions disjointes en un récit linéaire. Demandez-lui de déterminer si une boucle bytewise ressemble davantage à une somme de contrôle, à une table de substitution ou à une routine de décodage par étapes. Il s'agit là de questions locales. Elles fonctionnent parce que le modèle fait correspondre des modèles à un petit artefact bien délimité.
Ce qui ne fonctionne pas bien, c'est une synthèse globale trop précoce. Dès que vous collez cinq fonctions sans rapport entre elles et que vous demandez "Que se passe-t-il ?", le modèle commence à combler les lacunes sémantiques par une histoire. En inversant les rôles, on s'aperçoit que l'histoire n'est pas chère et qu'elle est erronée plus souvent qu'on ne le pense. Un meilleur schéma consiste à faire en sorte que le modèle gagne sa synthèse globale en réussissant d'abord plusieurs petites synthèses locales.
Voici une approche pratique. Créez un dossier pour le défi avec une courte note de texte. Chaque fois que vous inspectez une fonction manuellement, notez le nom de la fonction, les données qu'elle touche et ce que vous pensez être sa tâche. Demandez ensuite au modèle de ne traiter qu'une seule unité à la fois. Cela présente deux avantages. Premièrement, vous conservez votre propre raisonnement au lieu de laisser le modèle l'écraser. Deuxièmement, vous pouvez comparer l'interprétation du modèle à vos notes et repérer les cas où il commence à s'adapter de manière excessive.
Le même principe s'applique à l'obscurcissement. Si un défi d'inversion cache la logique derrière des chaînes encodées, des tables emballées ou des artefacts de construction suspects, le modèle peut aider à décoder et à classer les modèles, mais il ne doit pas devenir votre source de vérité. Cela devient encore plus évident lorsque vous examinez un cas réel comme CVE-2024-3094 dans xz. La description de NVD explique qu'un code malveillant a été introduit dans les fichiers d'archive en amont et a extrait un objet préconstruit à partir de fichiers de test déguisés au cours du processus de construction, modifiant des fonctions spécifiques dans la bibliothèque résultante. C'est une leçon parfaite pour les joueurs qui inversent les rôles : le comportement intéressant peut se trouver en dehors du chemin source évident, et les artefacts du moment de la construction peuvent avoir autant d'importance que la logique du moment de l'exécution. (NVD)
L'inversion avec l'IA s'améliore considérablement lorsque vous vous rappelez que le modèle est plus fort pour la traduction que pour la découverte. Laissez-le traduire l'assemblage en récit, transformer des tableaux bizarres en données structurées, expliquer les artefacts du compilateur et élaborer de minuscules émulateurs pour les routines suspectes. Ne le laissez pas décider de la "signification" de l'ensemble du code binaire tant que vous ne disposez pas d'une carte.
Comment utiliser l'IA dans les FFC en crypto-monnaie ?
Les CTF cryptographiques révèlent les limites des modèles linguistiques plus rapidement que n'importe quelle autre catégorie. Les résultats de 2024 NYU constituent un avertissement utile à cet égard. Dans l'ensemble de données qu'ils ont sélectionné, les performances en matière de cryptographie étaient particulièrement faibles par rapport à des catégories telles que l'inversion et certaines tâches de pwn. Cela ne devrait pas surprendre quiconque a passé du temps sur le CTF crypto. De nombreux défis cryptographiques reposent sur une structure exacte, et non sur une vague correspondance sémantique. Si le modèle n'a pas la bonne prise algébrique sur le problème, tout le Python du monde ne le sauvera pas. (arXiv)
Cela ne rend pas l'IA inutile dans le domaine de la cryptographie. Elle modifie simplement la description du travail. Le modèle est le plus performant lorsque le défi nécessite encore une classification. S'agit-il probablement d'une substitution, d'une transposition, d'un formatage de bloc, d'un abus de XOR, d'une superposition de codage de base ou d'un problème de contrainte ? Les indices importants se trouvent-ils dans la taille de l'alphabet, les blocs répétés, la fréquence des octets, le préfixe fixe ou la réutilisation des clés ? Que devriez-vous extraire avant même d'essayer de résoudre le problème ? Ce sont de bonnes questions d'IA car elles vous aident à décider si vous devez ouvrir CyberChef, écrire un analyseur syntaxique ou passer à un solveur SMT.
Le site de CyberChef le qualifie de "couteau suisse du cyberespace", et cette description est exacte pour les travaux de cryptographie CTF. Il est excellent pour la partie du flux de travail où l'on ne prouve pas encore un théorème, mais où l'on teste seulement si les données se comportent comme une compression, un hexagone, une base64, un XOR, un JSON, un codage URL ou une combinaison de ces éléments. L'IA s'associe bien à CyberChef parce que le modèle peut proposer un petit nombre de chaînes de transformation probables basées sur la structure visible des données, et vous pouvez les confirmer ou les rejeter immédiatement. (GCHQ)
Z3 est le contraire. Le guide de Microsoft le décrit comme un prouveur de théorèmes et un solveur SMT qui vérifie la satisfiabilité des théories soutenues. C'est important lorsque votre défi cryptographique cesse d'être une question de devinettes pour devenir une question de contraintes. Si l'énigme dit vraiment "Trouvez des octets qui satisfont ces conditions arithmétiques et bitvectorielles", le modèle doit cesser d'improviser et vous aider à formaliser le système. (Microsoft GitHub)
Voici un petit exemple :
from z3 import BitVec, Solver
a = BitVec("a", 8)
b = BitVec("b", 8)
c = BitVec("c", 8)
s = Solveur()
s.add(a ^ b == 0x12)
s.add(b ^ c == 0x34)
s.add(a + c == 150)
si s.check().r == 1 :
m = s.model()
print(m[a], m[b], m[c])
L'intérêt de cet extrait n'est pas le jeu mathématique. Il s'agit du changement de flux de travail. Une fois que le défi devient un système formel, la meilleure tâche de l'IA est de vous aider à coder le système correctement et d'expliquer les résultats du résolveur, et non de deviner la réponse en prose.
La génération d'analyseurs est un autre domaine dans lequel l'IA fonctionne bien en cryptographie. De nombreux défis cryptographiques de difficulté moyenne ne concernent pas la cryptanalyse avancée. Il s'agit d'extraire les bons octets d'un format désordonné, de diviser les blocs correctement, d'interpréter l'endianage ou de convertir les vues textuelles et binaires sans commettre d'erreurs stupides. Les modèles sont souvent très efficaces pour transformer ces tâches en petits scripts. Il s'agit là d'une valeur réelle. Mais il ne faut pas la confondre avec l'intelligence cryptographique.
Un moyen fiable de garder le modèle honnête est de demander l'élimination, et non l'identification. Au lieu de demander "Quel est ce cryptogramme ?", demandez "Sur la base de la longueur du texte crypté, de l'alphabet et du modèle de répétition, quelles familles communes deviennent moins probables ?" Cela encourage le modèle à raisonner à partir des propriétés au lieu de chercher le nom le plus familier. Cela vous évite également de perdre une heure parce que le modèle a appelé quelque chose "comme Vigenere" alors que le vrai problème était juste XOR avec une clé réutilisée et une couche de cadrage bizarre.
Le modèle est également utile lorsque vous avez déjà résolu le problème. Demandez-lui d'expliquer pourquoi la solution a fonctionné. Demandez-lui de réécrire votre script de départ en une version plus propre et documentée. Demandez-lui de résumer les indices qui ont réellement compté. Ces tâches postérieures à la résolution renforcent la reconnaissance des modèles pour les défis cryptographiques futurs d'une manière que l'invite "résolvez-moi d'un coup" ne peut jamais faire.
Comment utiliser l'IA en criminalistique et dans le cadre du PCAP ?
Les CTF de criminalistique sont souvent écrasants parce que les artefacts sont nombreux et que le drapeau est petit. C'est exactement le type d'asymétrie où l'IA peut aider, à condition d'éviter la tentation de tout mettre en contexte en même temps.
Commencez par séparer les types d'artefacts. La capture de paquets est un flux de travail. Les preuves relatives au système de fichiers en sont une autre. L'analyse de la mémoire en est une autre. Le modèle ne doit pas avoir à déduire ce qu'il examine. Votre première tâche consiste à réduire chaque artefact à un index gérable : protocoles intéressants, fichiers intéressants, processus intéressants, horodatages intéressants.
Pour le travail sur les paquets, TShark est idéal car il expose la même logique de filtre d'affichage que Wireshark sous une forme scriptable. La page de manuel insiste sur le fait que les filtres d'affichage sont puissants et qu'ils sont spécifiés à l'aide de la commande -Ytandis que les filtres de capture sont différents et spécifiés avec -f. Cette distinction est importante dans les FFC car, souvent, il ne s'agit pas de récupérer quoi que ce soit. Il s'agit plutôt de découper un PCAP existant à plusieurs reprises, en posant à chaque fois une question plus précise. (Wireshark)
Un simple triage de premier passage sur un PCAP de contestation autorisé pourrait ressembler à ce qui suit :
tshark -r challenge.pcap \N-Y 'http.
-Y 'http.request || dns || tcp.flags.syn==1' \N -T fields
-T champs \N- -e frame.time \N
-e frame.time \N- -e ip.src \N
-e ip.src \N- -e ip.dst \N- -e ip.src \N
-e ip.dst \N- -e _ws.col.Protocol \N
e _ws.col.Protocol \N -e _ws.col.Info \N -e _ws.col.Protocol \N
-e _ws.col.Info
Ce résultat est suffisamment petit pour qu'un modèle puisse le résumer de manière sensée. Une fois ce résultat obtenu, l'IA peut aider à regrouper le trafic par phase, à regrouper les destinations suspectes, à identifier les rafales ou à faire remarquer qu'un POST HTTP est suivi d'une consultation DNS, puis d'une deuxième connexion qui pourrait avoir de l'importance. Ce qu'elle ne doit pas faire, c'est déduire une exfiltration simplement parce qu'un nom de domaine semble étrange. L'ordre chronologique et le contenu sont toujours importants.
L'analyse de la mémoire est similaire. La documentation de Volatility 3 explique que le cadre organise l'analyse à travers des couches de mémoire, des modèles et des objets, des tables de symboles et un contexte contenant les structures pertinentes. Cela nous rappelle que l'analyse de la mémoire est structurelle. Une bonne utilisation de l'IA dans l'analyse de la mémoire signifie qu'il faut fournir au modèle des sorties de plugin structurées, et non des dumps bruts. Donnez-lui pslist, netscanLes lignes de commande, les modules chargés ou les manipulations suspectes. Demandez-lui de les mettre en corrélation. Demandez-lui d'établir une chronologie. Demandez-lui quel plugin supplémentaire permettrait de distinguer au mieux deux explications concurrentes. (Volatilité 3)
Un modèle de base pourrait être le suivant :
python3 vol.py -f memory.raw windows.pslist
python3 vol.py -f memory.raw windows.cmdline
python3 vol.py -f memory.raw windows.netscan
Une fois que vous disposez de ces résultats, l'IA peut s'avérer véritablement utile. Elle peut repérer qu'un processus a un parent inhabituel, qu'une ligne de commande contient un fragment PowerShell codé ou qu'un socket d'écoute est apparu peu après un processus enfant suspect. C'est le genre de relations qui échappent aux humains lorsqu'ils sont fatigués. Mais encore une fois, la preuve vient des artefacts, pas du résumé.
L'analyse judiciaire des systèmes de fichiers suit la même règle. Utilisez l'IA pour cataloguer, comparer et classer. Ne lui demandez pas d'extraire le sens d'une archive. Si vous récupérez des chaînes de caractères d'une image, demandez au modèle de les regrouper en identifiants, URL, horodatages ou marqueurs de fichiers. Si vous découpez plusieurs fichiers, demandez au modèle de comparer les en-têtes et d'en déduire les types probables. Si vous extrayez l'historique du navigateur ou de l'interpréteur de commandes, demandez-lui de proposer une chronologie. Il s'agit là de tâches visant à "réduire l'entropie". C'est là que l'IA gagne sa vie.
L'erreur la plus fréquente dans les CTF de criminalistique est de sauter la discipline narrative. Le nom d'un processus semble bizarre et les gens se tournent vers les logiciels malveillants. Une requête DNS semble bizarre, les gens pensent donc à l'exfiltration. Un JPEG contient des octets supplémentaires, ce qui incite les gens à opter pour le stego. L'IA ne fait qu'empirer les choses, à moins que vous ne la forciez à passer en mode "preuve". Faites-lui dire quels artefacts soutiennent chaque affirmation. Faites-lui distinguer les preuves directes des déductions. Faites-lui dresser une liste d'explications alternatives. Cette seule habitude améliore les performances des humains et de l'IA.
Comment utiliser l'IA dans les CTF sans laisser le modèle vous attaquer ?
Le risque le plus intéressant dans le jeu CTF assisté par l'IA est que le défi peut attaquer votre assistant. Les conseils de l'OWASP en matière d'injection d'invite sont particulièrement pertinents à cet égard. Le projet distingue l'injection directe et indirecte et note que les sources externes telles que les sites web ou les fichiers peuvent contenir du contenu qui modifie le comportement du modèle lorsqu'il est interprété par ce dernier. Le guide recommande également de séparer et d'identifier clairement le contenu externe, de tester les limites de confiance et de traiter le modèle comme une voie d'attaque possible plutôt que comme une aide neutre. (Projet de sécurité Gen AI de l'OWASP)
Dans un flux de travail CTF, cela signifie que le texte du défi, le HTML, les fichiers README, les commentaires du code source, les PDF, les chaînes cachées, les captures d'écran, les blobs base64 et même les métadonnées des images doivent être traités comme des données non fiables. Un défi malveillant ou délibérément trompeur pourrait inclure des instructions destinées à un modèle, et non à vous. Le contenu n'a même pas besoin d'être évident pour l'homme. L'OWASP note que les injections d'invite n'ont pas besoin d'être visibles par l'homme tant que le modèle les analyse. Concrètement, cela signifie qu'un document d'apparence parfaitement ordinaire peut toujours empoisonner la prochaine étape de votre assistant. (Projet de sécurité Gen AI de l'OWASP)
La première défense est architecturale. Ne mélangez pas les instructions du système, vos propres règles de travail et le contenu brut du défi dans une masse indifférenciée. Étiquetez les sections. Utilisez des marqueurs explicites pour le texte non fiable. Limitez la tâche du modèle. "Résumer le HTML non fiable suivant et n'en extraire que les routes et les formes observées" est une instruction beaucoup plus sûre que "Lisez cette page et dites-moi ce qu'il faut faire ensuite".
La deuxième défense est opérationnelle. Ne jamais exécuter automatiquement la sortie du modèle dans un shell ou un système en aval. Le document de l'OWASP sur la gestion des sorties non sécurisées indique que le risque apparaît lorsque les sorties du modèle sont transmises à des interpréteurs de commandes, des navigateurs ou d'autres composants sans validation ou assainissement. Il énumère explicitement des résultats tels que XSS, CSRF, SSRF, l'escalade des privilèges et l'exécution de code à distance lorsque la sortie LLM est gérée de manière non sécurisée. Dans un FFC, ce n'est pas théorique. Si votre flux de travail permet à un modèle de transformer un indice décodé en une commande shell et de l'exécuter, vous venez de donner aux données de défi un chemin vers l'exécution. (Projet de sécurité Gen AI de l'OWASP)
La troisième défense est sociale et non technique. Ralentissez avant de faire confiance. Si le modèle suggère une charge utile, demandez sur quelle observation il est basé. S'il suggère une commande, demandez ce qui pourrait falsifier l'hypothèse sous-jacente de la commande. S'il suggère un exploit complet, demandez quelle condition préalable est la plus susceptible d'échouer. Ces questions constituent une bonne pratique du CTF, même sans IA. Avec l'IA, elles sont obligatoires.
Les erreurs de l'IA qui font perdre le plus de points en CTF
La première erreur majeure est l'enfermement dans une catégorie. Le modèle voit XML et décide que le problème est XXE. Vous passez alors trente minutes à pousser des charges utiles XXE dans une fonction de vérification des stocks qui, en fait, veut seulement que vous remarquiez un modèle SSRF ou une fuite d'informations d'identification dans un deuxième point de terminaison. Le remède consiste à imposer des hypothèses classées au lieu d'une seule étiquette. Faites en sorte que le modèle argumente en faveur des deuxième et troisième choix.
La deuxième erreur est la privation de preuves. Les gens nourrissent un modèle avec un seul symptôme et s'attendent à ce qu'il raisonne comme un humain qui a regardé le défi pendant une heure. Ce n'est pas le cas. Si vous voulez une bonne aide, donnez-lui une requête de base, une requête mutée et la différence précise entre les réponses. Donnez-lui le désassemblage d'une fonction et le décalage du crash. Donnez-lui la tranche PCAP et le timing de la salve DNS. Chaque artefact supplémentaire mis à la terre réduit les degrés de liberté du modèle.
La troisième erreur est le gonflement du contexte. Le fait de déverser un binaire complet, un PCAP complet, trois captures d'écran et un historique de conversation complet dans une invite rend rarement le modèle plus intelligent. Il le rend généralement plus bancal. Les petites fenêtres contextuelles ne sont pas le seul problème. Les grandes fenêtres encouragent un raisonnement diffus. La meilleure solution consiste à pré-trier les artefacts avec de vrais outils, puis à ne donner au modèle que la partie qui compte.
La quatrième erreur est le culte du script. Le code généré par l'IA semble satisfaisant. Dans les CTF, cela peut créer une dépendance. Mais un script qui s'exécute n'est pas la même chose qu'un script qui prouve quoi que ce soit. Les travaux de benchmarking ont à plusieurs reprises mis en évidence des modes d'échec liés à des sorties vides, des commandes non exécutées et un code erroné, même lorsque le raisonnement qui l'entoure semble plausible. Traitez le code de l'IA comme le premier jet d'un coéquipier junior. Vous l'inspectez, le minimisez et le testez contre une condition minuscule avant de lui confier l'ensemble du défi. (arXiv)
La cinquième erreur est de ne pas prendre de notes parce que "le modèle se souvient". Il ne se souvient pas de la même façon qu'un joueur discipliné. Il se souvient du contexte symbolique jusqu'à ce qu'il ne s'en souvienne plus. Les notes battent les vibrations. Enregistrez les demandes. Enregistrez les révisions de scripts. Sauvegarder les hachages. Enregistrer les décalages. Enregistrer les hypothèses qui ont été tuées et pourquoi. Cette habitude vous permet également d'améliorer vos comptes rendus post-CTF, ce qui, à son tour, améliore vos futures requêtes à l'IA, car vous disposez d'exemples plus clairs de votre propre raisonnement pour apprendre.
De vrais CVE qui vous permettent de mieux réussir les CTF
Les CTF sont plus efficaces lorsqu'ils aiguisent votre intuition pour les systèmes réels. Le moyen le plus simple de rendre plus utile la pratique des FFC assistée par l'IA est d'ancrer les modèles de défis dans des vulnérabilités réelles. Non pas parce que chaque FFC reflète la production, mais parce que les meilleures leçons des FFC portent sur la structure : comment les entrées atteignent un interprète, comment la normalisation échoue, comment les limites des privilèges apparaissent, comment les artefacts cachés modifient la confiance.
CVE-2021-41773 et pourquoi le détournement de chemin n'est jamais qu'une question de points et de barres obliques
NVD décrit la CVE-2021-41773 comme une faille dans le serveur HTTP Apache 2.4.49 causée par une modification de la normalisation des chemins d'accès. Un attaquant pourrait utiliser la traversée de chemin pour faire correspondre des URLs à des fichiers en dehors des répertoires configurés par des directives de type Alias. Si ces fichiers n'étaient pas protégés par la directive exiger que toutes les demandes refusées par défaut, les requêtes pouvaient aboutir. Si CGI est activé pour les chemins d'accès aliasés concernés, le problème peut se transformer en exécution de code à distance. La NVD note également que ce problème est connu pour être exploité dans la nature, et la CISA a souligné par la suite que les problèmes liés au serveur Apache HTTP exploités concernaient les versions 2.4.49 et 2.4.50. (NVD)
Pourquoi est-ce utile pour les joueurs de CTF ? Parce qu'il enseigne la forme réelle de la traversée d'un chemin. Le bug n'est pas "quelqu'un a oublié de bloquer ../." Le bogue concerne la normalisation, le mappage des chemins, la configuration du déploiement et ce que le serveur est autorisé à exposer en dehors des limites prévues. En termes de CTF, c'est la différence entre un défi ludique de lecture de fichier et une chaîne de traversée significative. L'IA peut vous aider à générer des variantes de traversée, mais le raisonnement intéressant est environnemental. Quels sont les répertoires accessibles ? Quelle étape de normalisation n'est pas respectée. Si la divulgation du fichier est le point final ou seulement le pont vers quelque chose de plus grand.
La leçon sur l'atténuation est également importante. La solution n'est pas une expression magique. Il s'agit d'une correction de version, d'une gestion correcte des chemins d'accès et d'une configuration défensive qui empêche les fichiers situés en dehors des répertoires prévus d'être servis ou exécutés. Il s'agit du même raisonnement défensif que les bons joueurs de CTF sur le web finissent par intérioriser : la vulnérabilité réside dans les limites de la confiance, et non dans la syntaxe seule. (NVD)
CVE-2021-44228 et l'habitude de la CTF de suivre les données dans un interpréteur
CVE-2021-44228, Log4Shell, reste l'un des exemples les plus clairs de la raison pour laquelle "l'entrée contrôlée par l'utilisateur atteint un interpréteur" est un modèle offensif essentiel. La NVD indique que les versions concernées de Log4j2 permettaient aux messages ou paramètres de journal contrôlés par l'attaquant de déclencher des recherches JNDI vers des points d'extrémité contrôlés par l'attaquant, rendant ainsi possible l'exécution de code à distance lorsque la substitution de la recherche de message était activée. Le même document indique que la version 2.15.0 désactive ce comportement risqué par défaut et que la version 2.16.0 supprime complètement cette fonctionnalité. Le guide Log4j de la CISA considère également Log4Shell comme un problème critique d'exécution de code à distance et signale la désactivation de JNDI dans les correctifs ultérieurs. (NVD)
En quoi cela est-il pertinent pour les CTF ? Parce qu'elle entraîne le type exact de raisonnement pour lequel l'IA a souvent besoin d'aide. Le défi n'est pas simplement de "repérer l'injection". Il s'agit de "suivre le flux de données de la source au puits, puis de remarquer l'étape de résolution externe qui transforme les données en contrôle". De nombreuses FFC pour le web et les applications diverses sont des versions simplifiées de ce même mouvement cognitif. Un en-tête, un paramètre ou une chaîne enregistrable n'a pas d'importance parce qu'il existe. Il est important parce qu'un composant en aval l'interprète.
Lorsque vous utilisez l'IA pour relever des défis avec cette structure, ne demandez pas seulement des charges utiles. Demandez une analyse de la trajectoire. Quel composant consomme l'entrée. S'il existe une transformation intermédiaire. Si la résolution externe, la mise en page, l'interprétation de la base de données, l'interprétation du shell ou la désérialisation font partie de la chaîne. Ce type de demande rend le modèle beaucoup plus utile que "Donne-moi une chaîne Log4Shell". Il reflète également le travail d'atténuation réel : patcher le composant, réduire les caractéristiques dangereuses et contraindre le comportement de l'interpréteur. (NVD)
CVE-2021-3156 et la leçon de Pwn cachée dans l'analyse des arguments de tous les jours
Le NVD décrit le CVE-2021-3156 comme une erreur de type "off-by-one" dans le sudoedit -s avant sudo 1.9.5p2 qui peut produire un débordement de tampon basé sur le tas et une escalade locale des privilèges vers root. Il s'agit d'un magnifique cas d'enseignement pour les joueurs de pwn car il provient d'une gestion d'argument d'apparence normale dans un programme largement déployé, et non d'un binaire jouet cassé de manière caricaturale. (NVD)
La leçon de la CTF est que la corruption de la mémoire se cache souvent dans la logique d'analyse qui semble "administrative" plutôt qu'exotique. Le traitement des arguments, les échappements, les citations, les conditions limites, les champs de longueur et les comportements spécifiques à un mode sont tous des endroits privilégiés pour les bogues. L'IA peut être utile ici lorsque vous lui fournissez un petit patch diff, une logique d'analyseur décompilée ou un comportement de crash et que vous lui demandez d'expliquer quelle transition d'état permet d'atteindre le débordement. Elle est beaucoup moins utile si vous lui demandez de générer un exploit final à partir de la seule description du CVE.
La leçon sur l'atténuation est tout aussi importante. La mise à jour vers une version corrigée est la solution sur le plan opérationnel, mais pour le raisonnement par défi, le véritable enseignement est plus profond : les bogues de privilèges locaux sont souvent liés à des transitions négligées à l'intérieur de chemins de code fiables. Cela en fait un matériau idéal pour une explication assistée par l'IA et un matériau terrible pour une exploitation par l'IA seule. Le modèle peut vous aider à comprendre l'erreur de délimitation. Vous avez toujours besoin d'un humain pour conduire le raisonnement de l'exploit avec précision. (NVD)
CVE-2024-3094 et pourquoi les joueurs qui inversent les rôles devraient se préoccuper des pipelines de construction
Le CVE-2024-3094 dans xz concerne beaucoup plus de catégories de CTF qu'on ne le pense à première vue. NVD indique qu'un code malveillant a été découvert dans les fichiers d'archive xz en amont à partir de la version 5.6.0 et que le processus de construction a extrait un objet préconstruit d'un fichier de test déguisé, modifiant des fonctions spécifiques dans la bibliothèque résultante. L'alerte de la CISA sur l'incident indique que le code malveillant pourrait permettre un accès non autorisé aux instances SSHD concernées. (NVD)
Il s'agit d'un cadeau pour les spécialistes de l'inversion et de la criminalistique. Il enseigne que la chose à laquelle vous faites confiance par habitude peut ne pas être celle à laquelle vous devriez faire confiance. Le référentiel source peut ne pas correspondre à l'artefact de la version. Le fichier intéressant peut être étiqueté comme données de test. Le chemin de l'exploit peut être introduit pendant la construction, et non pendant la logique d'exécution évidente. L'IA est véritablement utile dans ce domaine pour la comparaison des artefacts, la synthèse des scripts de construction et le regroupement des anomalies. Elle n'est pas digne de confiance si vous la laissez se débarrasser de détails disgracieux avec une explication lisse.
La leçon sur l'atténuation renvoie à nouveau clairement à l'instinct de la FFC. La provenance est importante. Les artefacts de publication sont importants. La reproductibilité est importante. Si un défi ou un incident réel contient plusieurs représentations du "même" programme, le décalage lui-même peut être un indice. Cette habitude de comparer les sources, la construction et le comportement est précieuse bien au-delà d'un seul cas de chaîne d'approvisionnement. (NVD)
Transformer la pratique de l'IA CTF en un meilleur pentesting
La plus grande valeur à long terme de l'IA dans les CTF n'est pas la vitesse. C'est la discipline. Les FFC compriment le raisonnement offensif en un cycle court : observer, émettre des hypothèses, tester, vérifier. Si l'IA vous rend plus paresseux à l'une de ces étapes, cela vous nuit. Si l'IA vous rend plus systématique, elle vous aidera non seulement dans les concours, mais aussi dans le travail réel de pentest.
C'est pourquoi les habitudes les plus utiles de l'IA dans les CTF sont presque ennuyeusement opérationnelles. Conservez la paire de requêtes qui a prouvé l'existence du bogue. Sauvegarder la révision du script qui a finalement fonctionné. Conservez le décalage du crash et le hachage binaire. Sauvegardez l'artefact exact qui vous a fait changer d'avis. Il ne s'agit pas seulement d'habitudes de rédaction. C'est le début d'un travail de sécurité reproductible, qui est exactement la norme que le NIST et l'OWASP essaient de pousser les gens vers de vrais programmes de test. (Centre de ressources en sécurité informatique du NIST)
L'une des raisons pour lesquelles un outil comme Penligent peut s'intégrer naturellement dans ce flux de travail est que son matériel public n'est pas encadré uniquement par le chat. La page d'accueil met l'accent sur les flux de travail agentiques contrôlés par l'opérateur, l'édition rapide, les contrôles de portée, la prise en charge d'un grand nombre d'outils et les résultats fondés sur des preuves, tandis que la documentation décrit l'invocation des outils Kali installés et la configuration des moteurs d'exécution Python et Bash pour les scripts générés. Dans un contexte de CTF, cela ne résout pas les problèmes comme par magie. En revanche, il est plus facile de conserver les éléments de votre flux de travail d'IA qui comptent dans le travail réel : des limites explicites, des scripts pouvant être réexécutés et des artefacts qui ne disparaissent pas lorsqu'une fenêtre de discussion devient désordonnée. (Penligent)
L'article de Penligent sur l'IA dans le cadre du CTF présente également un point architectural utile : séparer l'intention, la planification, l'exécution et le traitement des preuves. Même si vous n'utilisez jamais cette pile exacte, la séparation est un bon conseil. Une longue conversation sur l'IA contenant le texte du défi, les ébauches du résolveur, les sorties du terminal, les expériences de la charge utile et les conclusions, le tout mélangé, devient rapidement impossible à auditer. La décomposition du flux de travail en étapes explicites permet au modèle et à l'opérateur d'être plus honnêtes. (Penligent)
La règle de base est simple. Utilisez l'IA pour resserrer la boucle, pas pour la rendre plus floue.
Les meilleurs joueurs de CTF IA vérifient toujours tout
Si vous voulez retenir une phrase, c'est celle-ci : L'IA est meilleure dans les FFC lorsqu'elle vous aide à mener plus de bonnes expériences, et non pas lorsqu'elle vous donne plus de réponses.
Les données publiques actuelles soutiennent un point de vue équilibré. Les points de référence montrent de réels progrès. Les modèles peuvent aider dans les tâches offensives structurées, et certains peuvent surpasser les participants moyens dans des contextes spécifiques. Dans le même temps, les performances restent très sensibles à l'orchestration, à l'outillage, à la catégorie et à la configuration de l'évaluation. Les travaux d'étalonnage au niveau professionnel, la recherche des fournisseurs sur les évaluations cybernétiques et les documents de pentest basés sur la planification montrent encore des limites en ce qui concerne la cohérence à long terme, les outils spécialisés et le raisonnement par état. (arXiv)
Ce n'est pas une déception. C'est une feuille de route. Dans les CTF sur le web, laissons l'IA classer et comparer. Dans les pwn, laissons-la échafauder et expliquer. Dans l'inversion, qu'elle résume localement. Dans le domaine de la cryptographie, l'IA doit formaliser et éliminer. En criminalistique, qu'elle regroupe et raconte à partir de preuves. Dans chaque catégorie, faites en sorte qu'il gagne la confiance, un artefact à la fois.
Les joueurs qui tirent le meilleur parti de l'IA ne sont pas ceux qui demandent de la magie. Ce sont ceux qui savent exactement où finit la magie et où commence la mesure.
Pour en savoir plus
La Web Security Academy de PortSwigger reste l'un des meilleurs points de départ pour une pratique sûre et légale de l'Internet, avec une couverture solide des vulnérabilités. (PortSwigger)
Les guides d'apprentissage et l'abécédaire de picoCTF valent la peine d'être ouverts pendant que vous travaillez, car ils contiennent des informations générales sur l'exploitation du Web, la cryptographie, la criminalistique, l'exploitation des binaires et l'inversion. (picoCTF)
Pour le travail de pwn, gardez la documentation officielle de pwntools à proximité, en particulier les sections sur le processus et l'interaction à distance et le flux de travail de corefile. (Documentation de Pwntools)
Pour l'exécution symbolique et la résolution de chemins binaires, la documentation officielle d'angr est la bonne référence. (Documentation Angr)
Pour l'inversion, la page officielle du projet Ghidra est le point de départ qui fait autorité. (GitHub)
Pour le travail sur les paquets et la mémoire, les documents officiels de TShark et Volatility 3 sont les références les plus utiles à associer à l'analyse assistée par l'IA. (Wireshark)
Pour savoir ce que l'IA peut et ne peut pas faire dans les FFC de sécurité offensive, le NYU CTF Bench, Cybench et les documents de référence publics connexes sont plus instructifs que les démonstrations sur les médias sociaux. (GitHub)
Pour ce qui est de la discipline de travail dans les tests réels, le NIST SP 800-115 et le guide de test de sécurité Web de l'OWASP sont toujours d'actualité. (Centre de ressources en sécurité informatique du NIST)
Pour les documents spécifiques à Penligent qui sont réellement pertinents pour ce sujet, les pages les plus utiles sont la page d'accueil, la documentation et l'article sur le flux de travail de l'IA de la FFC sur les chaînes étayées par des preuves, que vous pouvez réexécuter. (Penligent)
French 
English 
German 
Spanish 
Portuguese 
Japanese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew