APT-Q-27 Souffle de Dragon : Analyse de RONINGLOADER et Gh0st RAT

Résumé

Dragon Breath est un APT de cybercriminalité chinois ciblant les utilisateurs sinophones dans la région Asie-Pacifique. Le groupe utilise des techniques avancées, notamment des installateurs trojanisés, le chargement latéral de DLL et des pilotes de noyau signés pour déployer la chaîne d’infection RONINGLOADER et des variantes personnalisées de Gh0st RAT. Les acteurs ont également démontré la capacité de compromettre les fournisseurs de certificats et d’obtenir du matériel de signature de code pour leur malware.

Enquête

Le rapport examine l’évolution de Dragon Breath de 2020 à 2026, documentant sa transition des attaques par point d’eau au chargement latéral de DLL avancé et à l’abus du Protected Process Light (PPL). Il met en lumière une intrusion en 2026 impliquant DigiCert, où le groupe aurait obtenu du matériel de signature de code. L’analyse couvre également plusieurs techniques d’injection, y compris l’abus d’objets de pool de threads et la terminaison de processus en mode noyau.

Atténuation

Les organisations devraient valider les contrôles de sécurité des points de terminaison contre les techniques d’attaque simulées de Dragon Breath et renforcer les protections autour de l’exécution des applications. Des politiques de contrôle des applications strictes doivent être appliquées, tandis que les défenseurs surveillent la création de services non autorisés et le chargement latéral de DLL suspect. La détection de l’abus du Protected Process Light (PPL) et des politiques WDAC non autorisées ou non signées est également critique.

Réponse

Si une activité Dragon Breath est détectée, les hôtes affectés doivent être immédiatement isolés et recherchés pour des comptes locaux non autorisés et la persistance via Windows Services. Les intervenants devraient examiner de près l’activité d’injection de processus impliquant des processus système de confiance tels que TrustedInstaller.exe or taskhostw.exe. Les certificats de signature de code doivent être validés, et les modifications apportées à Windows Defender ou aux produits de sécurité régionaux doivent être examinées.

Exécution de simulation

Prérequis : Le contrôle préalable de la télémétrie et de référence doit être réussi.

Justification : Cette section détaille l’exécution précise de la technique de l’adversaire (TTP) conçue pour déclencher la règle de détection. Les commandes et la narration DOIVENT refléter directement les TTP identifiés et viser à générer exactement la télémétrie attendue par la logique de détection. Des exemples abstraits ou non liés entraîneront un mauvais diagnostic.

• Narration d’attaque et commandes : Un adversaire a obtenu un accès initial et tente d’établir un canal de commande et contrôle (C2) persistant. Pour échapper à la détection basée sur les signatures traditionnelles et aux pare-feu qui ne recherchent que des requêtes HTTP/S standard, l’attaquant déploie un agent léger qui initie une requête de mise à niveau WebSocket. En passant d’une requête HTTP GET standard à une connexion WebSocket, l’attaquant établit un canal de communication bidirectionnel, lui permettant d’émettre des commandes et de recevoir des données (telles que des frappes clavier ou l’exfiltration de fichiers) en temps réel sous couvert de trafic web persistant.

• Script de test de régression :

   # Script de simulation pour imiter une poignée de main/connexion WebSocket
    # Cela utilise une implémentation de socket PowerShell pour initier une connexion de type WebSocket.
    # Remarque : Cela nécessite un auditeur actif ou un service d'écho WebSocket public pour le succès.
  
    $wsUri = "wss://echo.websocket.org" # Utilisation d'un service d'écho public pour la simulation
    Write-Host "[*] Tentative d'établir une connexion WebSocket à $wsUri..."
  
    try {
        $ws = New-Object System.Net.WebSockets.ClientWebSocket
        $ct = New-Object System.Threading.CancellationTokenSource
        $connectTask = $ws.ConnectAsync($wsUri, $ct.Token)
  
        # Attendre la connexion pour simuler l'événement 'Network Connection'
        if ($connectTask.Wait(10000)) {
            Write-Host "[+] Connexion WebSocket établie avec succès."
            Write-Host "[!] Vérifiez votre SIEM pour les alertes 'Protocole : WebSocket'."
  
            # Envoyer un petit battement cardiaque pour garder la socket ouverte
            $buffer = [System.Text.Encoding]::UTF8.GetBytes("Ping")
            $sendTask = $ws.SendAsync((New-Object ArraySegment[byte]($buffer)), [System.Net.WebSockets.WebSocketMessageType]::Text, $true, $ct.Token)
            $sendTask.Wait(5000)
  
            # Garder la connexion ouverte brièvement pour assurer la capture de la télémétrie
            Start-Sleep -Seconds 10
            $ws.CloseAsync([System.Net.WebSockets.WebSocketCloseStatus]::NormalClosure, "Fermeture", $ct.Token).Wait()
        } else {
            Write-Host "[-] Délai de connexion dépassé. Assurez-vous que la cible peut atteindre l'URI WebSocket."
        }
    } catch {
        Write-Error "[-] Erreur lors de la simulation : $($_.Exception.Message)"
    } finally {
        if ($ws) { $ws.Dispose() }
    }

• Commandes de nettoyage :

   # Aucun artefact persistant n'est créé par le script PowerShell.
    # Assurez-vous que toutes les connexions ouvertes manuellement sont fermées.
    Write-Host "[*] Nettoyage de l'environnement de simulation..."
    Stop-Process -Name "powershell" -ErrorAction SilentlyContinue