IA et cybersécurité : contrer Lazarus dans les drones

En 2025, des entreprises européennes de la défense liées — parfois de très près — au secteur des drones (UAV) ont été visées par une nouvelle vague d’attaques attribuée à Lazarus. Ce n’est pas « juste » un énième épisode d’espionnage numérique : c’est un signal fort sur la valeur stratégique des données industrielles (plans, logiciels embarqués, procédés de fabrication) et sur la façon dont les attaquants modernisent leurs chaînes d’infection pour passer sous les radars.

Dans notre série « Intelligence artificielle dans la cybersécurité », ce cas est un exemple très parlant : les techniques observées (leurres RH, outils open source piégés, chargement furtif de DLL, chiffrement systématique des charges utiles) mettent à l’épreuve les approches de sécurité trop “signatures-only”. La bonne nouvelle, c’est que l’IA appliquée à la détection et à la protection des données est précisément conçue pour repérer ce que l’attaquant essaie de rendre invisible.

Pourquoi le secteur UAV attire Lazarus (et pourquoi ça va durer)

Réponse directe : les drones concentrent de la propriété intellectuelle monétisable et militarisable, et Lazarus cible ce qui accélère un programme industriel. Quand un acteur étatique cherche à gagner des années de R&D, les environnements de conception, de test et d’industrialisation deviennent des cibles prioritaires.

Plusieurs signaux convergent :

• Accélération des programmes drones nord-coréens rapportée ces derniers mois, et recherche d’industrialisation à grande échelle.
• Contexte géopolitique : les équipements occidentaux déployés en Ukraine créent un intérêt immédiat pour tout ce qui touche à la performance, la résistance au brouillage, la navigation, la charge utile, ou la chaîne de maintenance.
• Logique “supply chain” : les attaquants ne visent pas uniquement “le fabricant final”. Une entreprise qui produit un composant (métallurgie, avionique, logiciels, capteurs) peut suffire pour récupérer un avantage.

Mon opinion : les organisations qui considèrent encore leurs données de production comme moins sensibles que leurs données “produit” font une erreur. Les procédés, la qualité, les outillages, les tolérances et les recettes d’assemblage valent parfois autant qu’un plan.

Le mode opératoire DreamJob : RH, open source et exécution furtive

Réponse directe : Lazarus combine ingénierie sociale et outils piégés pour obtenir une exécution volontaire, puis installe un RAT qui donne un contrôle total. La force de l’approche vient de sa simplicité : pas besoin d’exploit sophistiqué si la victime ouvre la porte.

Les attaques observées s’inscrivent dans la famille Operation DreamJob, connue pour ses faux recrutements :

1) Le leurre “offre d’emploi” (et pourquoi il marche encore)

Le scénario est rodé : un candidat “parfait”, une opportunité prestigieuse, un document de poste… et un logiciel “nécessaire” pour l’ouvrir. Le détail qui change tout : le lecteur PDF ou le plugin fourni est trojanisé.

Ce type de leurre reste efficace dans la défense et l’aéronautique pour une raison très humaine :

• la pression sur les talents (ingénieurs systèmes, IA embarquée, avionique),
• la normalisation des tests techniques,
• l’habitude d’échanger des documents et du code avec l’extérieur.

2) Les projets GitHub “empoisonnés” : l’open source comme camouflage

Les attaquants ont incorporé des routines malveillantes dans des projets open source, puis les ont livrés comme composants légitimes (plugins Notepad++, WinMerge, bibliothèques, viewers). Le bénéfice côté attaquant : un binaire qui ressemble à ce qu’on s’attend à voir sur une machine de dev ou d’ingénierie.

Deux conséquences pratiques pour les défenseurs :

• La question n’est plus “utilisons-nous de l’open source ?” (la réponse est toujours oui), mais “pouvons-nous prouver l’intégrité de ce que nous compilons/installeons ?”
• Les contrôles basés sur la réputation peuvent être insuffisants si l’artefact est nouveau, peu distribué, ou “custom”.

3) DLL side-loading et proxying : une exécution qui imite le légitime

Les chaînes d’exécution décrites s’appuient sur le chargement de DLL par un exécutable légitime (DLL side-loading). Les bibliothèques malveillantes reprennent des exports attendus (proxying) pour ne pas casser le programme, tout en déclenchant la charge utile.

Ce n’est pas “nouveau”, mais c’est terriblement rentable : la télémétrie ressemble à de l’activité normale (processus connus, DLL attendues), sauf que le chemin, le contexte et la séquence trahissent l’attaque.

C’est exactement le genre de nuance où la détection comportementale et l’IA font la différence.

ScoringMathTea : un RAT discret, stable et orienté espionnage

Réponse directe : ScoringMathTea est un RAT (Remote Access Trojan) utilisé comme charge principale, capable de piloter la machine et d’exfiltrer des données via des canaux chiffrés. Sa stabilité et sa réutilisation sur plusieurs années en font un “cheval de bataille” : pas forcément le plus sophistiqué, mais suffisamment fiable.

Ce qui compte pour votre gestion du risque n’est pas le nom du malware, mais sa logique :

• Contrôle à distance complet (commandes, processus, fichiers, informations système).
• Chiffrement et encodage des communications (l’objectif est de rendre le trafic moins lisible et moins détectable).
• Charges utiles chiffrées sur disque : pas de binaire “en clair” facile à isoler.
• Infrastructures de commande et contrôle hébergées sur des serveurs compromis, parfois camouflées dans des répertoires et thèmes typiques de CMS.

Autrement dit : l’attaquant n’a pas besoin de bruit. Il a besoin de temps. Et l’espionnage industriel, c’est du temps.

Là où l’IA aide vraiment : détecter l’anormal, protéger l’IP, casser la chaîne

Réponse directe : l’IA renforce la cybersécurité quand elle relie des signaux faibles (poste, identité, processus, fichiers, réseau) pour détecter une attaque qui “ressemble” au normal. Dans un contexte APT, c’est souvent la seule manière de sortir du duel infini “nouvelle variante vs nouvelle signature”.

Détection : corréler les comportements, pas seulement les IOC

Une défense moderne contre ce type de campagne doit repérer des motifs comme :

• Un processus légitime (wkspbroker.exe, wksprt.exe) qui charge une DLL depuis un répertoire inhabituel.
• Une DLL qui présente des exports incohérents ou des patterns de proxying.
• Des séquences “lecture document → exécution binaire → injection/chargement réflexif → connexion sortante chiffrée”.

Les systèmes de détection alimentés par IA (UEBA, EDR avec modèles comportementaux) sont utiles parce qu’ils peuvent :

• établir une ligne de base par population de machines (postes d’ingénierie, machines de test, serveurs de build),
• alerter sur les enchaînements rares plutôt que sur un événement isolé,
• prioriser les incidents en fonction de la probabilité d’intrusion réelle.

Phrase à retenir : une APT n’est pas invisible, elle est “peu bruyante”. L’IA sert à entendre le bruit faible.

Prévention : réduire la surface “open source + plugins”

Voici ce qui fonctionne bien, même dans des environnements industriels où tout verrouiller est impossible :

1. Liste d’autorisation applicative (au moins sur les postes sensibles) : limiter les exécutables et DLL chargées hors emplacements standards.
2. Contrôle d’intégrité des binaires : hachage, signatures, validation des artefacts de build.
3. Politique stricte sur les plugins (Notepad++, WinMerge, viewers) : dépôt interne, versions approuvées, inventaire continu.
4. Isolation des environnements de test candidats : les “documents de recrutement” et exercices techniques doivent s’ouvrir dans des bacs à sable.

L’IA peut automatiser une partie de ce travail : classification des binaires rares, détection d’artefacts “jamais vus”, tri des alertes de contrôle applicatif.

Protection des données : empêcher l’exfiltration de savoir-faire

Lazarus cherche probablement du savoir-faire : plans, code, BOM, paramètres, rapports de tests, procédures d’assemblage. Beaucoup de programmes de sécurité se concentrent sur l’entrée (phishing) et sous-investissent sur la sortie (exfiltration).

Pour des organisations UAV/defense, je recommande une approche en trois couches :

• Cartographier l’IP critique (où sont les “joyaux” : PLM, Git, CAO, dossiers de production, bancs de test).
• Mettre du DLP pragmatique (pas maximaliste) : surveiller les volumes, les formats, les destinations, et surtout les événements rares.
• Déployer une détection d’anomalies d’exfiltration (IA) : un ingénieur qui compresse 8 Go de fichiers de test à 02h13 un samedi, ça doit déclencher une enquête.

Check-list opérationnelle (spéciale secteurs drones & défense)

Réponse directe : vous réduisez drastiquement le risque DreamJob en sécurisant le recrutement, le poste d’ingénierie et la chaîne de build, puis en surveillant l’exfiltration.

Voici une check-list concrète à mettre en œuvre en 30 à 90 jours :

• Process RH sécurisé

  • Canal unique pour les candidatures et pièces jointes
  • Ouverture des documents dans une sandbox
  • Interdiction d’installer un “lecteur” fourni par un tiers

• Postes d’ingénierie sous contrôle

  • EDR avec détection comportementale activée
  • Blocage/alerte sur chargement de DLL depuis répertoires non standards
  • Droits admin limités (au moins sur la navigation, la messagerie, les outils externes)

• Chaîne de développement et build

  • Dépendances open source “gelées” et vérifiées
  • Dépôt interne d’artefacts (plugins, librairies)
  • Analyse automatique des binaires “rares” (priorité aux DLL)

• Surveillance réseau & exfiltration

  • Détection d’anomalies sur flux chiffrés sortants et destinations nouvelles
  • Alertes sur volumes, compressions, archives, transferts hors horaires

Ce n’est pas de la paranoïa. C’est la base quand votre propriété intellectuelle a une valeur militaire.

Ce que ce cas dit de 2026 : l’IA côté attaquant, l’IA côté défense

Réponse directe : les APT industrialisent l’évasion et la personnalisation, donc la défense doit industrialiser l’observation, la corrélation et la réponse. On voit déjà une tendance : chaînes d’infection modulaires, artefacts différents selon la cible, contournement par “apparence légitime”.

En 2026, attendez-vous à :

• davantage d’attaques “recrutement + outils de dev”,
• plus de variantes conçues pour brouiller les règles statiques,
• une pression croissante sur la supply chain logicielle (plugins, librairies, dépendances).

L’IA n’est pas une baguette magique, mais elle est très bonne pour un point précis : repérer l’incohérence (un chargement de DLL, une séquence de processus, une exfiltration qui ne colle pas à l’habitude). Et dans l’espionnage, l’incohérence est souvent le seul indice.

Prochaine étape : évaluer votre exposition “DreamJob” avec une approche IA

Si vous travaillez dans l’aéronautique, la défense, les drones, ou votre chaîne de valeur, la question utile n’est pas “sommes-nous une cible ?” Vous l’êtes.

La question qui fait gagner du temps est : vos outils de détection et vos contrôles de données sont-ils capables d’identifier une attaque qui se cache dans le normal ? Si la réponse est “pas sûr”, c’est le bon moment pour cadrer un audit court : chemins de chargement DLL, inventaire plugins, sandbox documents, et détection d’anomalies (EDR/UEBA) sur postes sensibles.

Et vous, aujourd’hui, quelles équipes peuvent installer un outil “pour lire un document” sans que personne ne le voie ?