L'engagement "Summit" consiste en une simulation de menace en mode purple-team visant à améliorer les capacités de détection et de mitigation de PicoSecure face à des échantillons de malware exécutés sur des postes de travail internes. L'objectif principal est d'augmenter le coût opérationnel pour l'adversaire en identifiant et en bloquant progressivement les indicateurs de compromis (IoC) et les techniques observées, suivant la hiérarchie de la "Pyramid of Pain".
Après plusieurs interventions en réponse à incident, PicoSecure a initié une campagne de threat simulation et detection engineering. En collaboration avec un pentester externe, l'équipe a suivi une approche itérative : le testeur développe et exécute des variantes de malware sur une machine utilisateur simulée, tandis que l'équipe defensive configure et affine les contrôles de sécurité afin d'empêcher l'exécution ou la persistance du malware et de détecter ses activités.
- Compréhension avancée des concepts SIEM et des pipelines d'ingestion de logs.
- Analyse et corrélation de logs réseau et endpoints.
- Conception et mise en œuvre de règles de détection et de prévention (hash, IP, domaine, registre, comportements réseau).
- Cartographie des activités malveillantes aux techniques MITRE ATT&CK.
- Élaboration de mesures de mitigation et d'améliorations opérationnelles pour réduire la surface d'attaque.
- SIEM (ingestion et corrélation de logs)
- Outils d'analyse réseau (par ex. Wireshark ou équivalent)
- Outils de génération de télémétrie et d'attaques contrôlées
- Système de gestion des règles/pare-feu centralisé
- Outil de détection/monitoring des modifications de registre et de fichiers
Résumé : Un binaire malveillant identifié comme sample1.exe a été soumis à l'analyse. L'analyse a produit l'empreinte SHA-256 du fichier.
Action défensive : Création d'une règle de prévention bloquant l'exécution du binaire identifié par sa valeur SHA-256. Cette mesure vise à empêcher l'exécution de cette instance précise du malware.
Justification : Blocage simple et immédiat pour l'instance observée. Méthode efficace contre les échantillons inchangés mais fragile face aux modifications binaires.
MITRE ATT&CK (indicateur) : indicateur basé sur fichier (hash).
Résumé : Le testeur a modifié le binaire (sample2.exe) de sorte que sa valeur hash a changé, rendant la règle de l'étape 1 inefficace. L'analyse a montré que le binaire tentait d'établir une connexion vers une adresse IP suspecte.
Action défensive : Création d'une règle de pare-feu réseau bloquant toute communication entre le périmètre interne (source : n'importe quelle IP de l'entreprise) et la destination suspecte (IP), sur le port observé.
Justification : Le blocage de la destination réseau empêche la communication C2 ou le téléchargement additionnel, indépendamment des modifications binaires côté client.
Limite : Si l'adversaire change d'infrastructure (nouvelle IP), la règle devient obsolète.
MITRE ATT&CK (indicateur) : réseau / communication malveillante.
Résumé : L'attaquant a modifié l'infrastructure pour utiliser un nom de domaine plutôt qu'une IP fixe, introduisant une résolution DNS dynamique vers différentes adresses IP. Le blocage IP précédent n'est plus suffisant.
Action défensive : Mise en place d'une règle de blocage au niveau DNS/pare-feu applicatif pour interdire les résolutions/connexions vers le domaine malveillant identifié.
Justification : Le blocage par domaine compense la variabilité IP et prive l'adversaire d'un point de contact résilient.
Remarque opérationnelle : Surveiller les faux positifs potentiels et mettre en place une procédure de whitelisting contrôlée si nécessaire.
MITRE ATT&CK (indicateur) : utilisation de domaines pour C2 / résilience.
Résumé : L'analyse des traces a montré que l'échantillon tente de modifier une clé de registre nommée DisableRealtimeMonitoring.
Action défensive : Déploiement d'une règle de détection sur les modifications de clé de registre sensibles. La règle trace les événements de création/modification pour la clé ciblée et alerte l'équipe. L'événement est enrichi avec l'ID de phase ATT&CK correspondant (Defense Evasion — TA0005).
Justification : Empêcher la désactivation des protections en détectant la tentative de modification du système de protection en temps réel. La détection précoce permet d'interrompre l'attaque avant persistence ou exfiltration.
MITRE ATT&CK : TA0005 — Defense Evasion.
Résumé : Les journaux réseau montrent une connexion sortante périodique toutes les 30 minutes vers un serveur externe suspect. Les métadonnées de la connexion (remote IP, port, taille du paquet ~97 bytes, fréquence) confirment un canal C2. De plus, des commandes sont exécutées à distance.
Action défensive : Création d'une règle de détection réseau qui alerte sur la combinaison : remote IP + port (Any) + taille de flux = 97 bytes + périodicité = 1800s. L'alerte est corrélée avec logs d'exécution de processus pour confirmer l'activité de commande à distance. L'événement est annoté avec l'ID ATT&CK TA0011 (Command and Control).
Justification : Détecter et interrompre le canal C2 réduit la capacité de l'adversaire à contrôler l'hôte et à mener des étapes ultérieures (exfiltration, mouvements latéraux).
Remarque : Surveillance continue et blocage/desconnexion si confirmé.
Étape 6 — Preuve d’exfiltration : création/modification d’un fichier log contenant sorties de commandes (Exfiltration)
Résumé : Les logs d'activité montrent que la sortie de commandes sensibles (liste d’administrateurs, informations système, adresses IP détaillées) est écrite dans un fichier log, indiquant une collecte d'informations potentiellement destinée à exfiltration.
Action défensive : Mise en place d’une règle de détection sur la création/modification du fichier de log concerné (ou sur motifs de contenu spécifiques), déclenchant une alerte d’exfiltration. L’événement est identifié comme TA0010 (Exfiltration) dans la matrice MITRE ATT&CK. Des mesures complémentaires ont été recommandées : isolation de l’hôte, capture mémoire/disk, et analyses forensiques.
Justification : La détection de la phase d'exfiltration permet d'agir avant que les données sensibles quittent l'environnement, et fournit des artefacts pour l’enquête.
- Approche graduelle efficace : Le passage d’indicateurs fragiles (hash) à indicateurs robustes (domaine, comportement réseau, modifications de registre) illustre une stratégie défensive adaptée à l’évolution de l’attaque.
- Remédiation et containment : A chaque étape, la combinaison détection (SIEM) + prévention (pare-feu/DNS blocking/règles endpoint) a permis de réduire la capacité opérationnelle de l’adversaire.
- Améliorations proposées :
- Automatiser la corrélation entre détections endpoint et réseau pour accélérer le containment.
- Ajouter des règles heuristiques basées sur comportement (ex. pattern de fréquence de connexions) pour détecter C2 polymorphe.
- Mettre en place des playbooks d’incident (runbooks) pour isolation automatisée et collecte d'artefacts.
- Maintenir une liste de domaines/IP suspects mise à jour et intégrée à la gestion centralisée des règles.