learn.hack.repeat

JADEPUFFER n’est pas le sujet, le vrai sujet, c’est la fin du temps humain

On 08/07/2026

dans Chiffrement, CVE, Ransomware, Sécurité

Pendant des années, on a utilisé l’IA pour défendre, en effectuant:

Détection
Classification
Priorisation des alertes
Aide à l’investigation
Résumé d’incident
Génération de règles

Puis, progressivement, on l’a vue apparaître côté offensif:

Rédaction de phishing
Génération de scripts
Aide au développement de malware
Traduction de payloads
Automatisation de reconnaissance

Mais dans la plupart des cas, l’humain restait au centre: Il décidait, il corrigeait, il relançait et il choisissait la prochaine étape.

Puis Sysdig a publié son analyse sur JADEPUFFER.

Ma première réaction a été assez simple :

Encore un titre sensationnaliste sur l’IA…

Puis j’ai lu le rapport… Et ce qui m’a marqué, ce n’est pas vraiment l’attaque elle-même, ce qui m’a marqué, c’est ce qu’elle révèle.

Avant d’aller plus loin, une précision importante : dans cet article, je vais volontairement distinguer deux choses.

D’un côté, ce que l’on sait, sur la base des éléments publiés par Sysdig, NVD, CISA et d’autres sources techniques.

De l’autre, mon analyse, en tant que praticien SOC qui passe une bonne partie de son temps à travailler avec des SIEM, des règles de détection, des playbooks et des processus de réponse.

Parce que les faits sont déjà intéressants, mais les conséquences possibles le sont encore davantage.

1. Ce que l’on sait réellement

Selon Sysdig, JADEPUFFER est ce qu’ils évaluent comme le premier cas documenté de ransomware agentique : une opération d’extorsion conduite de bout en bout par un agent basé sur un LLM. Le point important est la nuance : Sysdig parle d’une évaluation basée sur leurs observations, pas d’une certitude absolue sur toute la configuration de l’agent ou sur l’absence totale d’un humain derrière.

L’attaque commence par l’exploitation d’une vulnérabilité connue dans Langflow, identifiée comme CVE-2025-3248. Cette faille affecte les versions de Langflow antérieures à 1.3.0 et permet à un attaquant distant non authentifié d’exécuter du code arbitraire via l’endpoint /api/v1/validate/code. La vulnérabilité est classée critique avec un score CVSS 9.8.

Langflow n’est pas un détail anodin ici. C’est un framework open source permettant de construire des applications et workflows autour de LLM. Autrement dit, on parle d’un outil conçu pour orchestrer des flux d’IA, souvent connecté à des clés API, des credentials cloud ou des services internes. Sysdig souligne justement que ces serveurs sont attractifs parce qu’ils sont “AI-adjacent” et peuvent contenir des secrets sensibles dans leur environnement.

Une fois l’accès obtenu, Sysdig décrit une chaîne d’attaque comprenant plusieurs phases :

Les payloads observés étaient livrés sous forme de Python encodé en Base64 via l’endpoint RCE de Langflow. Sysdig mentionne plus de 600 payloads distincts et intentionnels dans une fenêtre compressée, ce qui soutient leur hypothèse d’une opération pilotée par agent plutôt que par un humain au clavier ou un simple script figé.

Le détail le plus étrange concerne la clé de chiffrement.

L’agent aurait généré une clé aléatoire, l’aurait affichée une fois, puis ne l’aurait ni stockée ni envoyée. Résultat : les données chiffrées deviennent probablement irrécupérables, même si la victime paye. Sysdig précise également que l’affirmation d’exfiltration venait du commentaire généré dans le code de l’agent, mais n’a pas été vérifiée indépendamment.

En clair : ce n’est pas seulement un ransomware, c’est un ransomware qui, accidentellement, se comporte comme un wiper.

2. Ce que JADEPUFFER n’est pas

Il faut éviter de raconter n’importe quoi. JADEPUFFER n’est pas la preuve que “l’IA pense” comme un humain. Ce n’est pas non plus la preuve que les attaquants humains ont disparu. Ce n’est pas une attaque révolutionnaire par ses techniques individuelles.

Sysdig le dit explicitement :

Les techniques observées ne sont ni nouvelles ni particulièrement sophistiquées. Ce qui est nouveau, c’est qu’un modèle a été capable de les enchaîner dans une opération complète, contre une infrastructure négligée et exposée.

Et c’est précisément là que ça devient intéressant, parce que pendant très longtemps, on a évalué la sophistication d’une attaque à travers les techniques utilisées.

Est-ce que l’attaquant utilise un exploit zero-day ?
Est-ce qu’il utilise un malware custom ?
Est-ce qu’il contourne l’EDR ?
Est-ce qu’il fait du living-off-the-land avancé ?
Est-ce qu’il exfiltre discrètement sur plusieurs semaines ?

Ici, ce n’est pas vraiment ça. La nouveauté n’est pas dans la technique, elle est dans l’orchestration.

3. L’attaque ne change pas. Le rythme, oui.

Rien de tout cela n’est nouveau:

Conti faisait déjà ça.
LockBit faisait déjà ça.
BlackCat faisait déjà ça.
Des groupes humains très organisés le faisaient depuis des années.

Mais avant, même lorsqu’un groupe était très bon, il y avait une réalité physique derrière l’opération : des humains. Des humains qui travaillent, qui lisent les résultats, qui hésitent, qui changent de stratégie, des humains qui font des pauses.

Nos défenses se sont construites autour de cette réalité, même si on ne le dit pas toujours, une grande partie de notre modèle SOC repose sur une hypothèse implicite : L’attaquant est rapide, mais il reste humain.

Et c’est peut-être cette hypothèse qui commence à casser.

Dans JADEPUFFER, Sysdig observe une adaptation en temps réel. Dans une séquence, l’agent passe d’un login échoué à une correction fonctionnelle en 31 secondes. Ce n’est pas simplement “rapide”. C’est une boucle d’essai, d’erreur, d’analyse et de correction à une vitesse qui met en difficulté nos processus humains.

Et c’est là que le sujet devient beaucoup plus sérieux, parce que le problème n’est pas seulement : une IA peut attaquer, le problème est : une IA peut attaquer plus vite que nos processus humains de défense.

4. Le temps humain devient une vulnérabilité

Dans un SOC mature, une alerte critique suit souvent un processus raisonnable.

Une alerte arrive → Un analyste la qualifie → Il cherche le contexte → Il regarde l’asset → Il vérifie l’utilisateur → Il corrèle avec d’autres événements → Il escalade si nécessaire → Un senior ou un incident handler confirme → Quelqu’un décide du containment → Puis seulement l’action démarre.

Et honnêtement, c’est normal.

On ne veut pas isoler un serveur de production sur un faux positif.
On ne veut pas désactiver un compte critique sans validation.
On ne veut pas casser un service client parce qu’un signal est mal interprété.

Donc on met de l’humain dans la boucle: c’est prudent, professionnel et responsable, mais face à un agent autonome qui enchaîne reconnaissance, exploitation, recherche de secrets, pivot et chiffrement, cette prudence devient aussi une faiblesse.

Pas parce que les analystes sont mauvais ni parce que les processus sont inutiles, mais parce qu’ils ont été conçus pour un adversaire humain.
Une attaque automatisée ne respecte pas nos délais d’escalade, elle ne s’arrête pas pendant qu’on ouvre un ticket, elle ne ralentit pas parce qu’un manager n’est pas disponible, elle ne dort pas.

Et c’est peut-être ça, le vrai changement, ce n’est pas seulement que l’attaquant va plus vite, c’est que notre temps de réaction devient une surface d’attaque.

5. Les signatures ne disparaissent pas. Elles perdent de la valeur relative.

Il serait faux de dire que les IoC, les signatures, YARA ou les détections classiques deviennent inutiles.

Ils restent utiles.

Ils continueront à détecter une énorme partie des menaces.
Ils resteront indispensables pour la chasse, le triage, l’attribution partielle, le blocage réseau, l’enrichissement CTI.

Mais ils ne suffisent plus.

Dans un monde où un agent peut générer du code unique, adapter ses payloads, commenter ses propres actions et modifier sa stratégie selon les erreurs rencontrées, une défense centrée uniquement sur l’artefact arrive trop tard.

Un hash est publié après l’attaque.
Un IoC est utile après observation.
Une règle sur un outil connu fonctionne si l’outil est réutilisé.

Mais si le payload est généré à la volée, adapté à l’environnement, puis supprimé, la valeur de la signature baisse.

La question devient alors :

Est-ce que je détecte l’outil, ou est-ce que je détecte l’intention ?

Un processus qui énumère massivement les variables d’environnement.
Un service d’orchestration IA qui lit des secrets.
Un container qui tente d’accéder à MinIO avec des credentials par défaut.
Un workload exposé qui scanne soudainement l’espace interne.
Une application IA qui établit une persistence cron.
Un serveur applicatif qui touche des bases de production qu’il ne devrait jamais voir.

Ce changement implique aussi une évolution de notre manière de construire les détections. Pendant longtemps, nous avons cherché des outils ou des indicateurs de compromission.

Demain, il faudra surtout détecter des intentions.

Ne plus seulement chercher Mimikatz, mais toute tentative de Credential Access. Ne plus seulement détecter vssadmin delete shadows, mais toute tentative de destruction des mécanismes de restauration. Ne plus seulement bloquer une adresse IP connue, mais identifier un système qui agit soudainement en dehors de son rôle normal.

6. Ce que ça change pour Microsoft Sentinel, Splunk, EDR et SOAR

Dans mon équipe, on passe beaucoup de temps dans Microsoft Sentinel: Règles analytiques natives, Custom Analytics Rules, règles par client, hunting queries, playbooks, corrélations, workbooks, tuning etc…

Et ce que JADEPUFFER illustre très bien, c’est que le SOC ne peut plus se contenter d’empiler des règles isolées.

Une règle qui dit ProcessCommandLine has "procdump" peut être utile, mais elle ne suffit pas contre un agent qui peut écrire son propre code.

Le vrai enjeu est de corréler.

Par exemple :

Exploitation d’une application exposée
Exécution de Python anormale
Accès à des variables d’environnement
Lecture de fichiers .env, credentials.json, config.yaml
Connexion à des services internes depuis un host qui ne devrait pas y accéder
Création d’un cron ou d’une tâche persistante
Accès à une base de données sensible
Modification ou suppression massive de données

Pris isolément, chaque signal peut être faible, mais ensemble, ils racontent une histoire. Et c’est exactement ce que doit faire un SIEM moderne.

Sentinel, Splunk ou d’autres plateformes ne doivent pas seulement “détecter une commande”, ils doivent aider à reconstruire une intention et dans ce contexte, les règles les plus utiles ne sont pas forcément les plus spectaculaires, ce sont celles qui détectent les transitions anormales :

Un outil d’IA exposé qui devient point d’entrée
Un serveur applicatif qui devient outil de reconnaissance
Un compte technique qui devient acteur d’administration
Un container qui devient pivot réseau
Une application qui devient opérateur offensif

7. La réponse automatisée n’est plus un luxe

Si l’attaque se déroule à vitesse machine, la première réponse doit aussi pouvoir se déclencher à vitesse machine. Cela ne veut pas dire qu’il faut tout automatiser aveuglément, c’est même dangereux, mais cela veut dire qu’il faut distinguer deux niveaux.

D’un côté, les actions à faible risque : Enrichir une alerte, créer un ticket, notifier une équipe, capturer un snapshot, récupérer les processus actifs, collecter les connexions réseau, sauvegarder les logs volatils et augmenter la sévérité si plusieurs signaux convergent.

De l’autre, les actions à fort impact : Isoler un endpoint, désactiver un compte, révoquer une clé

Bloquer un flux réseau
Couper un service
Supprimer une session

Ces actions peuvent nécessiter validation humaine, mais dans certains scénarios, attendre est plus risqué qu’agir, c’est là que le SOAR devient stratégique. Pas comme gadget, pas comme “outil de confort”, mais comme mécanisme permettant de réduire le délai entre la détection et le containment.

La vraie question pour un CISO devient :

Quelles actions suis-je prêt à automatiser si l’attaque progresse plus vite que mon équipe ?

Ce n’est pas une question technique.
C’est une question de gouvernance.

8. Langflow est important. Mais Langflow n’est pas le sujet.

CVE-2025-3248 doit être patchée, les instances Langflow exposées doivent être inventoriées, les endpoints capables d’exécuter du code ne devraient pas être accessibles depuis Internet, les secrets ne devraient pas être présents en clair dans l’environnement d’un outil web exposé…

Tout cela est vrai, mais si on s’arrête à Langflow, on rate le message, car le vrai sujet est plus large :

Nous déployons de plus en plus de plateformes capables d’orchestrer du code, des données, des identités et des actions.

Langflow en est un exemple, mais on pourrait parler de n8n, d’Airflow, de GitHub Actions, de GitLab CI/CD, de Jenkins, de Kubernetes Operators, de MCP servers, l’agents IA internes, d’orchestrateurs cloud, de plateformes low-code, de notebooks partagés, d’outils d’automatisation IT, de pipelines de data ou de systèmes de déploiement.

Ces outils ont un point commun : ils sont puissants parce qu’ils automatisent, et c’est exactement pour cette raison qu’ils deviennent dangereux lorsqu’ils sont compromis.

Un outil d’orchestration, ce n’est pas “juste une application”, c’est souvent un point de concentration : de secrets, de permissions, de connecteurs, de chemins réseau, de logique métier et d’accès à la production.

Demain, ces plateformes pourraient devenir les nouveaux Domain Controllers, pas parce qu’elles remplacent Active Directory, mais parce qu’elles concentrent le pouvoir opérationnel. Et un attaquant agentique cherchera naturellement ces points de levier.

9. La souveraineté numérique : pas une garantie, mais une question de contrôle

Il y a aussi une dimension plus large: Langflow est open source.
Beaucoup d’outils critiques le sont: Kubernetes, Airflow, Terraform, TensorFlow, n8n, Jenkins et tant d’autres. L’open source est une force immense, mais l’open source ne signifie pas automatiquement “audité”, “sécurisé”, “gouverné”, “responsable”.

Une faille critique peut exister dans un outil largement utilisé, elle peut être corrigée puis rester exploitable pendant des mois sur des instances non patchées. C’est exactement ce que montre CVE-2025-3248 : la faille était connue, corrigée dans Langflow 1.3.0, ajoutée au catalogue KEV de CISA en mai 2025 et pourtant encore exploitable sur des systèmes négligés.

La souveraineté (on en parle un peu ces temps 🙂 ) ne veut pas dire “un outil suisse ou français n’aura jamais de faille”, ce serait faux.

La souveraineté, dans ce contexte, signifie plutôt :

Savoir quels outils critiques on utilise
Savoir qui les maintient
Savoir à quelle vitesse on peut patcher
Svoir si on peut auditer
Savoir si on peut forker
Savoir si on peut imposer des exigences contractuelles
Savoir si on peut survivre sans dépendre aveuglément d’un tiers

Ce n’est pas une question idéologique, c’est une question de contrôle opérationnel.

10. Ce que ça change pour les métiers de la sécurité

Si les attaques deviennent plus agentiques, les compétences nécessaires dans une équipe de sécurité évoluent, mais les fondamentaux restent nécessaires.

Il faudra toujours des gens qui comprennent les systèmes, les réseaux, les identités, les logs, les malwares, les vulnérabilités, mais certaines compétences vont prendre encore plus d’importance.

Analyse comportementale

Il ne suffira plus de savoir chercher un hash ou une commande, il faudra comprendre ce qui est normal pour un workload, un compte, un segment réseau, une application.

Un bon analyste devra être capable de dire :

Ce serveur peut techniquement faire ça, mais il n’a aucune raison métier de le faire.

C’est souvent là que se trouve le signal.

Architecture de segmentation

La segmentation ne peut plus être un dessin Visio, elle doit être testée. Si un serveur applicatif compromis peut joindre toutes les bases de données internes, alors la segmentation est théorique et face à un agent autonome, la segmentation théorique ne vaut rien.

Gestion des secrets

JADEPUFFER rappelle une vérité simple : les secrets sont la monnaie de l’attaque: Clés API, tokens cloud, credentials database, fichiers .env, secrets dans les variables d’environnement, credentials par défaut.

Tout ce qui traîne sera essayé et un agent ne se fatiguera pas.

Automatisation de réponse

Un SOC qui dépend uniquement d’une validation humaine pour chaque action critique risque d’être trop lent, il faudra savoir construire des playbooks sûrs, gradués, auditables, réversibles quand c’est possible.

Threat modeling des agents

On ne peut plus modéliser uniquement “un attaquant humain avec des outils”, il faut aussi se demander :

Qu’est-ce qu’un agent autonome ferait s’il avait accès à ce système ?

Il énumérerait quoi ?
Il testerait quels secrets ?
Il pivoterait vers quoi ?
Il prioriserait quelles données ?
Il automatiserait quelles actions ?

C’est une nouvelle manière de penser l’attaque.

11. Ce qu’il faut faire demain matin

Il ne sert à rien de terminer sur “faites de la défense en profondeur”, tout le monde le sait. La vraie question est : par quoi commencer ?

1. Inventorier les outils d’orchestration

Pas seulement Langflow, mais tous les outils capables de déclencher des actions :

CI/CD
Automation IT
Orchestrateurs IA
Pipelines data
Notebooks
Plateformes low-code
Outils internes
Consoles d’administration exposées

Question simple :

Quels systèmes peuvent exécuter du code ou déclencher des actions en production ?

Ce sont des assets critiques.

2. Vérifier l’exposition Internet

Un endpoint capable d’exécuter du code ne devrait pas être exposé publiquement sans contrôle strict, cela paraît évident. Mais dans la vraie vie, des outils temporaires deviennent permanents, des POC deviennent prod, des ports restent ouverts, des instances “de test” contiennent des secrets réels.

3. Traquer les secrets

Chercher tous les éléments cités plus haut et surtout : ne pas seulement les trouver, mais aussi les révoquer quand cela est nécessaire, les déplacer dans un vault, limiter leur portée, surveiller leur usage.

4. Tester la segmentation

Pas avec une réunion, mais avec un test.

Depuis un serveur applicatif compromis, que peut-on joindre ?
Depuis un container exposé, quelles bases répondent ?
Depuis un outil d’orchestration, quels secrets sont accessibles ?
Depuis un compte technique, quels privilèges réels existent ?

5. Créer des playbooks de réponse gradués

Ne pas commencer par “isoler toute la prod”, commencer par :

Enrichissement automatique
Collecte volatile
Elévation de sévérité
Notification
Ticketing
Blocage conditionnel
Révocation conditionnelle
Containment avec validation

Le but n’est pas de remplacer l’humain, le but est de gagner les premières minutes.

6. Détecter les comportements d’intention

Exemples de chaînes utiles :

Application exposée → exécution de code → lecture de secrets
Container → scan interne → accès à MinIO/Nacos/DB
Compte technique → actions admin inhabituelles
Serveur IA → connexion cloud inhabituelle
Création de persistence après exploitation web
Lecture massive de configurations suivie de suppression

Ce sont ces chaînes qui racontent une attaque.

12. POC ou rupture ?

JADEPUFFER est probablement les deux, c’est un proof-of-concept dans le sens où :

Les techniques ne sont pas nouvelles
L’opération a commis des erreurs
La clé de chiffrement a été perdue
Certaines affirmations, comme l’exfiltration, ne sont pas vérifiées indépendamment
On ne connaît pas toute la configuration de l’agent

Mais c’est aussi un signal de rupture, parce qu’il montre qu’un agent peut enchaîner des étapes offensives de manière cohérente, parce qu’il montre que des vulnérabilités anciennes et des mauvaises configurations peuvent être exploitées à vitesse machine, parce qu’il montre que le coût d’orchestration d’une attaque complexe pourrait baisser.

Et parce qu’il pose une question désagréable :

Si le skill floor de l’attaquant baisse, combien d’organisations restent défendables avec leurs processus actuels ?

13. La vraie question : sommes-nous encore en train de défendre contre des humains ?

Pendant vingt ans, nous avons construit des défenses pour répondre à des humains augmentés par des outils.

Des humains rapides.
Des humains organisés.
Des humains compétents.
Mais des humains quand même.

Aujourd’hui, nous commençons peut-être à voir autre chose.

Des agents capables d’exécuter, d’essayer, d’échouer, de corriger, de continuer, de le faire vite et de le faire à grande échelle.

Cela ne rend pas nos SIEM inutiles.
Cela ne rend pas nos EDR inutiles.
Cela ne rend pas nos analystes inutiles.

Au contraire, mais cela signifie que nos SOC doivent évoluer.

Moins de dépendance au signal isolé et plus de corrélation comportementale, moins d’attente passive et plus de réponse automatisée contrôlée, moins de confiance implicite dans les outils d’orchestration et plus de segmentation réelle, moins de secrets exposés et plus de contrôle opérationnel.

JADEPUFFER n’est probablement pas le ransomware qui va mettre Internet à genoux, mais c’est peut-être l’un des premiers signaux faibles d’un changement beaucoup plus profond. Pendant des années, nous avons construit des défenses capables de réagir plus vite que des humains. Maintenant, il va peut-être falloir construire des défenses capables de réagir plus vite que des agents.

Et ce n’est pas du tout le même problème.

Références:
https://www.sysdig.com/blog/jadepuffer-agentic-ransomware-for-automated-database-extortion
https://nvd.nist.gov/vuln/detail/CVE-2025-3248
https://www.cisa.gov/known-exploited-vulnerabilities-catalog
https://github.com/langflow-ai/langflow
https://attack.mitre.org/matrices/enterprise/
https://genai.owasp.org/

YARA-X : un outil pour la détection des malwares et l’analyse de fichiers

de jabot

On 07/03/2025

dans Malware, Ransomware, Sécurité

La cybersécurité repose sur de nombreux outils permettant d’identifier, d’analyser et de bloquer les menaces avant qu’elles ne causent des dégâts. Parmi ces outils, YARA s’est imposé depuis des années comme une référence pour la détection de malwares et l’analyse de fichiers suspects. En 2024, une nouvelle version baptisée YARA-X a été introduite. Cette réécriture complète en Rust améliore la robustesse, les performances et l’expérience utilisateur.

Mais qu’est-ce que YARA-X, à quoi sert-il et pourquoi cette évolution était-elle nécessaire ? Cet article propose d’explorer les principales fonctionnalités de cet outil, son utilité en cybersécurité et son évolution depuis son lancement

Un bref historique de YARA

YARA a été créé en 2008 par Víctor M. Álvarez, chercheur en cybersécurité, dans le but de fournir un moyen plus flexible et efficace de détecter des malwares. Son idée était d’offrir un système de détection basé sur des règles personnalisables, permettant aux chercheurs d’identifier les menaces non seulement par des signatures statiques, mais aussi par des motifs comportementaux.

Rapidement adopté par les entreprises et les équipes de Threat Intelligence, YARA est devenu un standard dans la chasse aux menaces. Il a été intégré dans VirusTotal, l’un des outils d’analyse de malwares les plus utilisés au monde.

Cependant, au fil des ans, son code en C a montré ses limites : problèmes de gestion mémoire, maintenance complexe et performances limitées face aux besoins croissants des analystes. C’est pourquoi, en 2024, son créateur a annoncé YARA-X, une refonte complète en Rust, un langage plus moderne et sécurisé.

À quoi sert YARA-X ?

YARA-X permet de rechercher des motifs spécifiques dans des fichiers pour identifier des malwares. Il est utilisé par les analystes SOC, les chercheurs en cybersécurité et les entreprises pour détecter des menaces connues ou inconnues en s’appuyant sur des caractéristiques spécifiques du code malveillant. Contrairement à un antivirus classique, qui repose sur des bases de signatures, YARA-X permet d’écrire des règles personnalisées pour repérer des fichiers suspects selon des critères définis par l’utilisateur.

Il est couramment utilisé pour :

L’analyse de ransomwares en repérant des appels suspects à des fonctions de chiffrement.
La détection de backdoors en recherchant des communications cachées avec un serveur distant.
L’identification de trojans dissimulés dans des applications légitimes.
Le Threat Hunting, en surveillant des fichiers exécutables téléchargés sur un système.

Pourquoi une nouvelle version en Rust ?

YARA, bien que puissant, souffrait de limitations liées à son implémentation en C, notamment en termes de gestion mémoire et de compatibilité. YARA-X a été entièrement réécrit en Rust, un langage qui garantit une meilleure sécurité, une gestion plus efficace de la mémoire et des performances améliorées.

Les avantages de YARA-X incluent :

Une meilleure fiabilité, avec une réduction des erreurs de gestion mémoire.
Des analyses plus rapides, même sur des fichiers volumineux.
Une intégration facilitée avec d’autres outils grâce aux API en Python, Golang et C.
Une interface plus intuitive, avec des commandes simplifiées pour l’analyse des fichiers.

Test pratique : Détection d’une fonction cachée malveillante

Pour mieux comprendre comment YARA-X peut identifier des fichiers suspects, faisons un test concret avec un exemple simple.

Imaginons un exécutable Windows (malware.exe) qui semble inoffensif, mais qui cache une fonction de communication secrète avec un serveur distant. Cette fonction pourrait être utilisée par un malware pour envoyer des données volées ou télécharger une charge utile supplémentaire.

Avec YARA-X, nous pouvons examiner ce fichier pour repérer des appels suspects. Utilisons la commande suivante pour inspecter l’exécutable :

yr dump malware.exe

Résultat (extrait simplifié) :

pe:
  sections:
    - name: ".text"
      size: 4096
    - name: ".data"
      size: 2048
  imports:
    - name: "ws2_32.dll"
      functions:
        - "socket"
        - "connect"
        - "send"
        - "recv"
    - name: "kernel32.dll"
      functions:
        - "VirtualAlloc"
        - "CreateThread"

Ce résultat montre que l’exécutable importe des fonctions réseau (socket, connect, send, recv) depuis ws2_32.dll, une bibliothèque Windows utilisée pour les communications sur Internet. De plus, il appelle VirtualAlloc et CreateThread, qui sont souvent exploitées par des malwares pour injecter du code malveillant en mémoire.

Ces indices nous permettent de soupçonner que ce fichier pourrait contenir un trojan ou un backdoor.

Pour confirmer nos soupçons, nous pouvons écrire une règle YARA spécifique pour détecter ce type de comportement :

rule Suspicious_Network_Activity
{
    meta:
        description = "Détecte des exécutables contenant des appels réseau suspects"
        author = "Analyste Cybersécurité"
        date = "2025-03-07"

    strings:
        $socket = "socket" ascii
        $connect = "connect" ascii
        $send = "send" ascii
        $recv = "recv" ascii
        $virtualAlloc = "VirtualAlloc" ascii
        $createThread = "CreateThread" ascii

    condition:
        any of ($socket, $connect, $send, $recv) and 
        any of ($virtualAlloc, $createThread)
}

En exécutant cette règle sur notre fichier suspect, nous pouvons vérifier s’il correspond à ce modèle de comportement malveillant :

yr scan -r Suspicious_Network_Activity.yara malware.exe

Si l’exécutable correspond à notre règle, cela signifie qu’il contient une fonction cachée qui pourrait être utilisée à des fins malveillantes.

Adoption et évolution de YARA-X

Depuis son lancement en 2024, YARA-X a été adopté par plusieurs organisations et chercheurs en cybersécurité. Il est désormais inclus dans certaines distributions Linux et est disponible via Homebrew pour macOS. Son développement est actif et de nouvelles versions continuent d’optimiser ses performances et ses fonctionnalités.

Conclusion

YARA-X est une évolution majeure dans l’univers de la cybersécurité. Grâce à son moteur plus performant et à son intégration avec les langages modernes, il permet d’analyser efficacement des fichiers suspects et d’identifier des menaces avancées.

Que ce soit pour les experts en cybersécurité, les chercheurs ou simplement ceux qui s’intéressent à l’analyse des menaces, YARA-X offre un cadre puissant pour mieux comprendre comment fonctionnent les malwares et comment les détecter de manière proactive.

Avec un développement en constante évolution et une adoption croissante, YARA-X est bien parti pour devenir un outil incontournable de la cybersécurité moderne.

Plus d’information:
YARA is dead, long live YARA-X ~ VirusTotal Blog
GitHub – VirusTotal/yara-x: A rewrite of YARA in Rust.
What is YARA?

EDRSilencer : un outil Red Team détourné pour échapper aux solutions de sécurité

de jabot

On 21/10/2024

dans Malware, Ransomware, Sécurité

Les solutions de sécurité des entreprises sont de plus en plus perfectionnées, notamment grâce aux technologies de détection et réponse sur les endpoints (EDR). Mais récemment, un outil appelé EDRSilencer a refait surface, conçu initialement pour les tests de sécurité offensifs (Red Team). Malheureusement, cet outil est désormais utilisé par des cybercriminels pour contourner les mesures de protection des EDR dans des attaques réelles.

Qu’est-ce qu’EDRSilencer ?

EDRSilencer est un outil destiné aux professionnels de la cybersécurité qui réalisent des tests d’intrusion pour évaluer les vulnérabilités des infrastructures IT. Cependant, comme c’est souvent le cas avec des outils utilisés par les équipes de sécurité, des acteurs malveillants l’ont détourné de son usage initial pour le déployer dans des cyberattaques. Ce qui rend EDRSilencer particulièrement inquiétant, c’est sa capacité à désactiver ou contourner les solutions de sécurité sur les terminaux (comme les ordinateurs) de l’entreprise.

(EDRSilencer attack chain. Sources: Trend Micro)

En pratique, EDRSilencer intercepte les processus de communication entre un logiciel EDR et ses consoles de gestion. L’outil exploite des vulnérabilités dans la Windows Filtering Platform (WFP), une fonctionnalité native de Windows qui gère le trafic réseau et les communications des applications. Cela permet aux attaquants de bloquer les alertes générées par les EDR avant qu’elles ne soient envoyées aux équipes de sécurité, rendant leurs actions invisibles pendant un temps crucial.

Un danger pour plusieurs solutions EDR

Selon les chercheurs en cybersécurité de Trend Micro, EDRSilencer a été utilisé pour compromettre plusieurs des solutions de sécurité les plus répandues. Parmi celles-ci, on retrouve Microsoft Defender, FortiEDR de Fortinet, et Cortex XDR de Palo Alto Networks. En désactivant les processus d’alerte de ces outils, les attaquants peuvent se déplacer latéralement dans les réseaux d’entreprise sans déclencher d’alarme.

(Blocage du trafic d’exécutables codés en dur. Source : Trend Micro)

En outre, l’outil est hautement personnalisable. Les cybercriminels peuvent définir des filtres spécifiques dans EDRSilencer pour cibler certains processus ou services qu’ils souhaitent masquer, ce qui leur donne un contrôle fin sur les actions qu’ils souhaitent dissimuler aux solutions de sécurité. Par exemple, ils pourraient choisir de cacher les processus liés à des ransomwares ou d’autres logiciels malveillants tout en permettant d’autres processus de rester visibles, ce qui rend l’identification de l’attaque encore plus difficile.

Une menace croissante pour les entreprises

L’utilisation d’un outil comme EDRSilencer montre à quel point les cyberattaques sont en constante évolution. Les entreprises se retrouvent confrontées à des attaques de plus en plus sophistiquées, capables de déjouer les systèmes de défense les plus avancés. Ce genre de menace montre également que la cybersécurité ne peut pas reposer uniquement sur une seule couche de protection.

Il est fortement recommandé de mettre en place des stratégies de défense multicouche. Ces stratégies incluent non seulement des solutions EDR, mais aussi des systèmes de détection des anomalies comportementales, des pare-feux, et des politiques strictes de gestion des accès. De plus, appliquer le principe du moindre privilège sur les utilisateurs et les processus permet de limiter l’ampleur des dégâts en cas de compromission d’un système.

Pour une détection proactive des comportements liés à des outils comme EDRSilencer, il est recommandé de mettre en place des règles analytiques personnalisées dans votre SIEM. Ces règles peuvent surveiller les modifications inhabituelles des filtres de la Windows Filtering Platform (WFP) ou les interruptions des processus critiques des solutions EDR. La plupart des SIEM (Microsoft Sentinel, Splunk, QRadar, etc.) permettent de créer des alertes spécifiques à ces comportements, aidant ainsi à prévenir les attaques.

/* 
Exemple de requête KQL qui surveille les événements WFP (5156, 5157) et les interruptions ou modifications des processus liés à Microsoft Defender 
*/
SecurityEvent
| where EventID == 5156 or EventID == 5157  // Modification dans la WFP
| where ProcessName contains "MsMpEng.exe" // Microsoft Defender Antivirus Process
| where ActionType == "ProcessTerminated" or ActionType == "AuditPolicyChange"
| project TimeGenerated, Computer, Account, ProcessName, EventID, ActionType

En plus de la détection proactive des menaces par la surveillance des comportements suspects, des audits réguliers de la sécurité des infrastructures, sont des éléments clés pour se protéger contre des outils comme EDRSilencer. Cela montre l’importance d’être toujours en avance sur les cybercriminels, qui ne cessent d’adapter leurs techniques.

Conclusion

L’émergence de EDRSilencer comme outil dans les mains des attaquants illustre une tendance inquiétante dans le domaine de la cybersécurité. Des outils initialement développés pour aider les professionnels à tester et renforcer les systèmes de sécurité peuvent être utilisés à des fins malveillantes. Cela souligne l’importance d’une vigilance constante et d’une adaptation rapide face à des menaces toujours plus sophistiquées.

Plus d’information:
EDRSilencer red team tool used in attacks to bypass security
Silent Threat: Red Team Tool EDRSilencer Disrupting Endpoint Security Solutions | Trend Micro (US)

Insomni’hack 2024

de jabot

On 28/04/2024

dans Sécurité

Cela faisait très longtemps que j’avais envie d’assister à un rendez-vous incontournable dans le panorama de la cyber sécurité en Suisse romande comme l’est Insomni’hack, mais en raison de contretemps professionnels de dernière minute, de contraintes de calendrier ou autres covid, ça n’avait jamais pu se concrétiser… c’est maintenant chose faite 🙂

Pour ma première visite à Insomni’Hack, le SwissTech Convention Center s’est révélé être l’endroit idéal pour un événement de cette envergure. Les interactions avec les partenaires et exposants, passionnés et non intrusifs, ainsi que le niveau technique élevé des présentations, ont rendu cette expérience inoubliable.

Insomni’hack c’est donc avant tout un évènement pour technards, passionnés de sécu et de gentils hackers. Qu’on se situe du côté des organisateurs, exposants, conférenciers ou visiteurs, les échanges sont toujours riches en partage d’expérience, bonne humeur et convivialité!

Célèbre pour son CTF, remporté cette année par 0rganizers, Insomni’hack c’est aussi plus de 30 conférences techniques, ainsi que plusieurs workshops pour ceux qui voudraient faire du deep dive sur un des nombreux sujets abordés.

CTF is over! In the end, it was a very close call. Congrats to
🥇 @0rganizers, 🥈 @ECSC_TeamFrance & 🥉 @leetmore!

Thanks everyone for participating Insomni'hack CTF 2024, #INSO24, #CTF

Here's the final scoreboard. pic.twitter.com/cPBlh3nUvl
— Insomni'hack (@1ns0mn1h4ck) April 27, 2024

Pour ma part, j’ai été présent toute la journée de vendredi et j’ai notamment eu la chance de participer à deux conférences concernant l’OIDC dans le cloud ainsi que la sécurité AD DS.

Abus de la configuration OIDC dans les environnements cloud

L’une des sessions les plus enrichissantes a été celle de Christophe Tafani-Dereeper, intitulée « Abusing misconfigured OIDC authentication in cloud environments« . Cette présentation détaillée a exploré les failles de sécurité courantes associées aux configurations OIDC dans les pipelines CI/CD. Christophe a commencé par une introduction aux fondamentaux d’AWS IAM, expliquant la différence entre les utilisateurs IAM et les rôles IAM, ainsi que l’importance de la gestion sécurisée des politiques d’accès.

Le cœur de la présentation a traité des erreurs de configuration spécifiques qui permettent des escalades de privilèges et des attaques par exécution de code arbitraire. Christophe a illustré comment une politique de confiance mal configurée dans un rôle IAM peut être exploitée pour obtenir des accès étendus sur l’infrastructure AWS. Il a utilisé des exemples réels, montrant des scripts et des commandes pour démontrer comment les attaquants peuvent récupérer des jetons Web JSON (JWT) mal sécurisés et les utiliser pour assumer des rôles IAM vulnérables. Des conseils pratiques ont été donnés pour sécuriser les configurations, incluant l’utilisation de conditions strictes dans les politiques de confiance et la limitation des permissions accordées aux rôles.

Source: Abusing misconfigured OIDC authentication in cloud environments

Des études de cas ont clôturé la session, où Christophe a détaillé comment son équipe a identifié et signalé de manière responsable des rôles vulnérables, aidant ainsi plusieurs entreprises à améliorer leur posture de sécurité. Cette présentation a non seulement mis en lumière les risques liés à une mauvaise gestion des identités dans le cloud mais a aussi montré l’importance d’une vérification continue et rigoureuse des configurations de sécurité.

Burn it, burn it all : Persistance dans AD DS

La deuxième conférence, présentée par Volker Carstein (Aka Volker) et Charlie Bromberg (Aka Shutdown), nous a plongé dans le monde complexe de la persistance au sein des services de domaine Active Directory avec leur présentation intitulée « Burn it, burn it all« . Le duo a exposé diverses méthodes de persistance, allant des attaques GoldenGMSA à Skeleton Key, en passant par des techniques de délégation KRBTGT et des manipulations de l’SID history.

Volker et Charlie ont commencé par expliquer le concept de GoldenGMSA, détaillant comment les attaquants peuvent exploiter les clés KDS root pour prendre le contrôle de comptes de service gérés par groupe (gMSA). Ils ont démontré, en direct, comment extraire et calculer les mots de passe des gMSA à partir d’informations système apparemment bénignes.

La discussion s’est ensuite tournée vers la technique du Skeleton Key, où ils ont illustré comment l’injection dans le processus LSASS permet de créer un mot de passe maître pour n’importe quel compte sans altérer les mots de passe existants. Cette partie de la session a mis en évidence les risques de sécurité liés aux contrôleurs de domaine et l’importance de surveiller et de sécuriser ces systèmes critiques.

Pour conclure, ils ont abordé des techniques plus avancées telles que la manipulation de l’SID history et l’exploitation de l’objet AdminSDHolder pour obtenir une persistance quasi-indétectable dans des environnements AD. Chaque technique était accompagnée d’exemples de code, de recommandations pour la mitigation et d’histoires de cas réels, rendant la session à la fois éducative et profondément technique.

Rideau de fin et à l’année prochaine!

Je tiens à exprimer ma gratitude envers l’organisateur de l’évènement, Orange Cyberdefense Suisse ainsi que tous les sponsors et exposants, tout particulièrement: Kyos, Yes We Hack, Kaspersky, Zscaler, Palo Alto Networks, et Boll pour leur accueil chaleureux sur leur stand. Leur engagement envers la communauté de la sécurité informatique est la clé de la réussite de ces échanges enrichissants.

Avec des souvenirs plein la tête, pas mal d’articles à lire et de sujets à approfondir, je suis plus que jamais motivé à revenir à Insomni’hack l’année prochaine. Et qui sait, peut-être même pour participer au célèbre CTF 😉

Plus d’information:
https://www.insomnihack.ch/
https://docs.google.com/presentation/d/1TwGYsxgJRWRhm9aO8SIK4NIhwYaXZelWzWk337DTxUk/edit?usp=sharing
https://drive.google.com/file/d/11tfRmol18T7itiZXbAS03OFu3UoRAwhC/view

Le groupe cybercriminel chinois Earth Krahang porte atteinte à la sécurité de 70 organisations dans 23 pays

de jabot

On 25/03/2024

dans CVE, Phishing, Sécurité

Une campagne de cyberespionnage avancée attribuée au groupe cybercriminel chinois Earth Krahang a porté atteinte à la sécurité de 70 organisations dans le monde, y compris des ministères des affaires étrangères et d’autres agences gouvernementales, en déployant un arsenal sophistiqué d’outils pour compromettre des infrastructures clés et récolter des informations sensibles.

Ce groupe a utilisé des techniques avancées telles que l’exploitation de vulnérabilités dans des serveurs exposés à Internet, des emails de spear-phishing et des attaques par force brute pour installer des portes dérobées personnalisées et mener des activités de cyber-espionnage.

Les attaquants ont spécifiquement exploité des vulnérabilités telles que CVE-2023-32315 et CVE-2022-21587 pour accéder à des réseaux compromis et y persister. En outre, ils ont utilisé des emails de spear-phishing à thème géopolitique pour inciter les destinataires à ouvrir des pièces jointes malveillantes ou à cliquer sur des liens, ce qui facilite l’installation de logiciels malveillants et l’extraction ultérieure d’informations.

Une fois dans le réseau, Earth Krahang a utilisé des infrastructures compromises pour héberger des charges utiles malveillantes, rediriger le trafic d’attaque et utiliser des comptes de messagerie gouvernementaux piratés pour cibler d’autres gouvernements ou contacts avec des courriels de spear-phishing. Dans un cas notoire, ils ont utilisé un compte de courrier électronique compromis d’une entité gouvernementale pour envoyer une pièce jointe malveillante à 796 adresses électroniques appartenant à la même entité.

Chaîne d’infection d’une attaque de spear-phishing de Earth Krahang (voir la section ATT&CK de MITRE pour plus de détails sur chaque identifiant de technique).
Source: trendmicro.com

Compte tenu de la sophistication et de l’ampleur de la campagne Earth Krahang, il est vivement conseillé aux organisations gouvernementales et aux autres entités cibles potentielles de rester vigilantes face à toute activité suspecte sur leurs systèmes. Dans ce contexte, la mise en œuvre des mises à jour de sécurité en temps opportun devient un pilier essentiel. En outre, la sensibilisation des employés aux risques inhérents à l’ingénierie sociale et aux attaques de spear-phishing, associée à l’adoption de mesures d’authentification multifactorielle, sont des stratégies clés pour atténuer le risque de compromission.

Dans ce scénario, la collaboration avec des partenaires de confiance spécialisés dans la protection contre les cybermenaces peut fournir une couche de sécurité supplémentaire. Des entreprises comme Swisscom, qui ont fait leurs preuves en matière de détection et de réponse aux menaces numériques, proposent des solutions qui peuvent être cruciales pour anticiper, identifier et neutraliser les attaques avant qu’elles n’affectent les opérations critiques. L’utilisation de leurs services de protection contre les cybermenaces n’est pas seulement une mesure proactive, mais aussi un investissement dans la continuité et la résilience des opérations face à l’adversité dans le cyberespace.

Plus d’information:
https://www.trendmicro.com/en_us/research/24/c/earth-krahang.html
https://www.bleepingcomputer.com/news/security/chinese-earth-krahang-hackers-breach-70-orgs-in-23-countries/
https://nvd.nist.gov/vuln/detail/CVE-2023-32315