Hunting for Mythic in network traffic

5 minute de lecture

Mis à jour :

Identification des Activités du Framework Mythic dans le Trafic Réseau

Les attaquants utilisent des frameworks avancés pour maintenir leur accès et se déplacer latéralement dans les réseaux compromis. Mythic, un framework de post-exploitation open-source, connaît une popularité croissante en raison de sa flexibilité et de ses multiples options de communication. Cet article détaille les méthodes pour détecter l’activité des agents Mythic en analysant le trafic réseau.

Points Clés

  • Mythic C2 : Une plateforme multi-utilisateurs pour la gestion d’agents malveillants durant des cyberattaques.
  • Architecture : Basée sur des conteneurs Docker, avec des composants serveur, agents et modules de transport en Python.
  • Flexibilité : Permet l’ajout de nouveaux agents et canaux de communication à la volée.
  • Stratégies d’Attaque : S’aligne avec plusieurs étapes de la chaîne d’attaque (Kill Chain) et les tactiques du framework MITRE ATT&CK, notamment le Pivotement, la Collecte, l’Exfiltration et le Commandement et Contrôle (C2).

Vulnérabilités et Méthodes de Détection

L’article se concentre sur la détection du trafic réseau des agents Mythic, en particulier ceux liés au Commandement et Contrôle (TA0011).

Modes de Communication :

  1. Communication Pair-à-Pair (P2P) : Les agents communiquent entre eux, formant une chaîne menant à un nœud en connexion directe avec le serveur C2.
    • Via SMB : Utilise des “named pipes” dont le nom correspond à l’UUID de l’agent. Les données sont encodées en Base64, puis chiffrées avec AES-256 et structurées au format MythicMessage.
      • Règles de Détection (Exemples) :
        • alert tcp any any -> any [139, 445] (msg:"Trojan.Mythic.SMB.C&C"; ... pcre:"/H[-ÿ]{2}([a-z0-9]){8}\-([a-z0-9]){4}\-([a-z0-9]){4}\-([a-z0-9]){4}\-([a-z0-9]){12}$/R"; sid:9000101; rev:1;)
        • alert tcp any any -> any [139, 445] (msg:"Trojan.Mythic.SMB.C&C"; ... pcre:"/^[a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}/" ; sid:9000102; rev:1;)
      • Limitation : La détection par signature est inefficace si le chiffrement SMBv3 est activé.
    • Via TCP : Utilise également la structure MythicMessage avec des données encodées en Base64 (UUID + AES256(JSON)). Le numéro de bloc est toujours 0x00000000.
      • Règles de Détection (Exemples) :
        • alert tcp any any -> any any (msg:"Trojan.Mythic.TCP.C&C"; ... pcre:"/^[-\]{1}[-ÿ]{1}$/"; flowbits:set,mythic_tcp_p2p_msg_len; sid:9000103; rev:1;)
        • alert tcp any any -> any any (msg:"Trojan.Mythic.TCP.C&C"; ... pcre:"/^[a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}/"; sid:9000104; rev:1;)
  2. Modules de Transport “Egress” (Sortants) : Permettent une communication plus discrète en utilisant des services externes.
    • Via Discord : La communication utilise HTTPS et est chiffrée en TLS. La détection nécessite le déchiffrement du trafic. Les données sont encapsulées dans la structure MythicMessageWrapper (contenu encodé en Base64). Une signature peut cibler les appels API POST vers /channels/<channel.id>/messages contenant un sender_id au format UUID.
      • Règle de Détection (Exemple) : alert tcp any any -> any any (msg:"Trojan.Mythic.HTTP.C&C"; ... pcre:"/"sender_id\":\"[a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}/"; sid:9000105; rev:1;)
      • Détection en trafic chiffré : Analyse comportementale des connexions TLS fréquentes vers discord.com.
        • Règle de Détection (Exemple) : alert tcp any any -> any any (msg:"NetTool.PossibleMythicDiscordEgress.TLS.C&C"; tls_sni; content:"discord.com"; ... sid:9000106; rev:1;)
      • Détection via DNS : Suivi des requêtes DNS multiples vers discord.com.
        • Règle de Détection (Exemple) : alert udp any any -> any 53 (msg:"NetTool.PossibleMythicDiscordEgress.DNS.C&C"; ... content:"|07|discord|03|com|00|"; ... sid:9000107; rev:1;)
    • Via GitHub : La communication utilise HTTPS. L’agent publie des commentaires et crée/modifie des branches dans un dépôt. Les données sont encodées en Base64. La détection peut se baser sur la présence d’UUID dans les requêtes de création de commentaires ou de branches.
      • Règles de Détection (Exemples) :
        • alert tcp any any -> any any (msg:"Trojan.Mythic.HTTP.C&C"; ... pcre:"/^[a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}/" ; sid:9000108; rev:1;) (Création de commentaire)
        • alert tcp any any -> any any (msg:"Trojan.Mythic.HTTP.C&C"; ... pcre:"/refs\/heads\/[a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}"/"; sid:9000109; rev:1;) (Création de branche)
        • alert tcp any any -> any any (msg:"Trojan.Mythic.HTTP.C&C"; ... pcre:"/"message":"[a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}"/"; sid:9000110; rev:1;) (Publication de fichier)
      • Détection en trafic chiffré : Analyse comportementale des sessions TLS fréquentes vers api.github.com.
        • Règle de Détection (Exemple) : alert tcp any any -> any any (msg:"NetTool.PossibleMythicGitHubEgress.TLS.C&C"; tls_sni; content:"api.github.com"; ... sid:9000111; rev:1;)
      • Détection via DNS : Suivi des requêtes DNS multiples vers api.github.com.
        • Règle de Détection (Exemple) : alert udp any any -> any 53 (msg:"NetTool.PossibleMythicGitHubEgress.DNS.C&C"; ... content:"|03|api|06|github|03|com|00|"; ... sid:9000112; rev:1;)
    • Via HTTP/HTTPS :
      • HTTP : Métadonnées non chiffrées, permettant la détection basée sur des signatures. Les UUID sont présents dans le paramètre query (GET) ou dans les données Base64 (POST).
        • Règle de Détection (Exemple) : alert tcp any any -> any any (msg:"Trojan.Mythic.HTTP.C&C"; ... pcre:"/[0-9a-fA-F]{8}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{12}/" ; sid:9000113; rev:2;)
      • HTTPS : Le déchiffrement est nécessaire. La détection peut se baser sur l’utilisation de certificats SSL par défaut propres à Mythic.
        • Règle de Détection (Exemple) : alert tcp any any -> any any (msg:"Trojan.Mythic.HTTPS.C&C"; ... content:"Mythic C2"; ... sid:9000114; rev:1;)
    • Via WebSocket : Communication full-duplex. Les données sont encodées en Base64 dans le champ data et contiennent la structure UUID+AES256(JSON).
      • Règle de Détection (Exemple) : alert tcp any any -> any any (msg:"Trojan.Mythic.WebSocket.C&C"; ... base64_data; pcre:"/^[a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}/i" ; sid:9000115; rev:2;)

Recommandations

L’analyse du trafic réseau par des solutions IDS/NDR est une méthode efficace pour détecter l’activité des agents Mythic, car les caractéristiques communes de communication restent stables.

  • Surveillance du Trafic Réseau : Utiliser des solutions NDR pour identifier les modèles de trafic caractéristiques du framework Mythic.
  • Détection Basée sur les Signatures : Créer des règles spécifiques à chaque protocole utilisé par Mythic, en se concentrant sur la recherche de chaînes UUID dans les données encodées.
  • Analyse Comportementale : En cas de chiffrement ou d’utilisation de canaux furtifs, privilégier l’analyse comportementale pour détecter des activités atypiques (fréquence des connexions, requêtes DNS inhabituelles).
  • Adaptation des Règles : Les règles proposées doivent être ajustées aux spécificités de chaque infrastructure pour minimiser les faux positifs, notamment en configurant les paramètres de threshold (count, seconds).
  • Solutions NDR : Des solutions comme Kaspersky NDR sont conçues pour détecter les menaces actuelles grâce à l’analyse des schémas de trafic, garantissant une haute efficacité dans la découverte des agents de post-exploitation.

Source