Cas pratiques SOC analyst

Contexte : Un utilisateur signale que son compte a été verrouillé suite à plusieurs tentatives de connexion échouées. Le Problème : Vous devez déterminer s'il s'agit d'une simple erreur de mot de passe ou d'une tentative d'attaque par force brute. Contraintes : Vous disposez des logs d'authentification incluant IP source, nombre de tentatives et localisation approximative. Aucune analyse forensique avancée n'est requise. Livrable attendu : Examiner les logs, identifier les indicateurs d'attaque éventuelle et recommander les actions appropriées (réinitialisation, surveillance accrue, escalade).

Contexte : Le système de protection endpoint remonte une alerte indiquant la détection d'un fichier malveillant sur un poste utilisateur. Le Problème : Vous devez déterminer si l'alerte est critique et nécessite une isolation immédiate du poste. Contraintes : Vous disposez du nom du fichier, du chemin d'accès et du hash associé. Vous devez vérifier si le fichier est connu comme malveillant et analyser son contexte d'exécution. Livrable attendu : Analyser les informations disponibles et décider si l'incident doit être escaladé, isolé ou classé comme faux positif.

Contexte : Vous êtes analyste SOC junior et recevez une alerte indiquant une connexion SSH inhabituelle sur un serveur de production en dehors des heures de bureau. Le Problème : L'alerte indique une connexion depuis une adresse IP externe inconnue. Vous devez déterminer s'il s'agit d'une activité légitime ou potentiellement malveillante. Contraintes : Vous disposez uniquement des logs d'authentification, de l'adresse IP source et de l'heure de connexion. Aucune analyse forensique avancée n'est requise. Vous devez documenter clairement votre raisonnement. Livrable attendu : Analyser les logs fournis, identifier les éléments suspects (IP, horaire, tentatives multiples) et rédiger une conclusion indiquant si l'incident nécessite une escalade.

Contexte : Le pare-feu interne détecte plusieurs tentatives de connexion séquentielles vers différents ports depuis un poste utilisateur. Le Problème : Ce comportement peut indiquer un scan interne ou une mauvaise configuration applicative. Contraintes : Vous disposez des logs indiquant IP source, ports ciblés et fréquence des tentatives. Vous devez analyser la nature du comportement sans interrompre immédiatement l'activité. Livrable attendu : Identifier si le comportement correspond à un scan de ports interne et recommander les actions appropriées (isolation, investigation complémentaire ou clôture).

Contexte : Le SIEM génère de nombreuses alertes indiquant des tentatives de brute force sur un service web interne. Le Problème : Après analyse préliminaire, il semble que ces alertes proviennent d'un outil interne de supervision qui teste régulièrement la disponibilité du service. Extrait de log : Multiple failed login attempts from 10.0.0.15 Contraintes : Vous ne devez pas désactiver totalement la règle de détection. Il faut ajuster la corrélation pour éviter les faux positifs tout en conservant la capacité de détecter une attaque réelle. Livrable attendu : Identifier la cause du faux positif et proposer une modification de règle ou d'exception permettant de conserver une surveillance efficace.

Contexte : Une règle SIEM censée détecter les connexions administrateur en dehors des horaires de bureau ne génère aucune alerte. Le Problème : Après vérification, la condition horaire semble incorrecte. Configuration actuelle : Trigger if login_time BETWEEN 08:00 AND 18:00 Cette règle détecte les connexions pendant les heures normales au lieu des heures inhabituelles. Contraintes : Vous devez corriger la logique sans supprimer la règle existante. La détection doit cibler uniquement les connexions administrateur hors plage horaire autorisée. Livrable attendu : Corriger la condition logique de la règle et expliquer brièvement la correction apportée.

Contexte : Une alerte signale qu'un compte standard a exécuté une commande nécessitant des privilèges élevés. Le Problème : Vous devez déterminer si cette élévation de privilèges est légitime ou suspecte. Contraintes : Vous disposez des logs système indiquant l'utilisateur, la commande exécutée et l'heure. Aucun accès direct au poste n'est autorisé. Livrable attendu : Examiner les logs, identifier les incohérences éventuelles et proposer une action (surveillance, escalade, clôture de l'alerte).

Contexte : Plusieurs utilisateurs signalent un email suspect demandant une mise à jour urgente de mot de passe. Le Problème : Vous devez analyser les logs du serveur mail pour identifier l'origine du message et déterminer s'il s'agit d'une campagne de phishing. Contraintes : Vous disposez des en-têtes email, de l'adresse IP d'envoi et du domaine expéditeur. Vous devez vérifier la cohérence SPF/DKIM et identifier les anomalies évidentes. Livrable attendu : Examiner les éléments techniques fournis et produire une conclusion indiquant si l'email est frauduleux et quelles mesures doivent être prises.

Contexte : Une alerte indique une augmentation soudaine du trafic sortant depuis un poste utilisateur vers Internet. Le Problème : Vous devez déterminer si ce comportement correspond à une activité normale (mise à jour logicielle, sauvegarde cloud) ou à une possible exfiltration de données. Contraintes : Vous disposez des journaux de pare-feu indiquant IP source, destination, volume de données et port utilisé. Aucune analyse approfondie du contenu des paquets n'est demandée. Livrable attendu : Examiner les journaux, identifier les indicateurs suspects et rédiger un court rapport d'analyse indiquant le niveau de risque.

Contexte : Une alerte de proxy indique qu'un utilisateur a téléchargé un fichier exécutable depuis un site inconnu. Le Problème : Vous devez évaluer si ce téléchargement représente un risque pour l'organisation. Contraintes : Vous disposez de l'URL, du type de fichier, de l'heure du téléchargement et du poste concerné. Vous devez analyser la réputation du domaine et la cohérence avec l'activité professionnelle de l'utilisateur. Livrable attendu : Rédiger une analyse indiquant si le poste doit être isolé ou surveillé et justifier votre décision.

Contexte : Une solution UEBA signale qu'un utilisateur accède à un volume inhabituel de fichiers sensibles en dehors de ses habitudes normales. Le Problème : Vous devez déterminer s'il s'agit d'un changement légitime d'activité ou d'un comportement potentiellement malveillant. Contraintes : Vous disposez des historiques d'accès, des horaires habituels de connexion et du type de fichiers consultés. Aucune sanction ne doit être prise sans analyse solide. Livrable attendu : Évaluer les écarts comportementaux, contextualiser l'activité et formuler une recommandation argumentée (surveillance accrue, enquête approfondie ou clôture).

Contexte : Le pare-feu détecte des connexions HTTPS répétées vers un domaine nouvellement enregistré depuis un serveur interne. Le Problème : Ce comportement peut indiquer une communication avec un serveur de commande et contrôle (C2). Contraintes : Vous disposez des logs DNS, des flux réseau (IP, port, volume) et de la date d'enregistrement du domaine. Aucun accès au contenu chiffré n'est possible. Livrable attendu : Examiner les indicateurs disponibles, évaluer le niveau de risque et recommander les actions appropriées (blocage, isolation, surveillance renforcée).

Contexte : Une alerte indique qu'une stratégie de groupe (GPO) a été modifiée en dehors d'une fenêtre de maintenance. Le Problème : Vous devez déterminer si la modification est légitime ou potentiellement malveillante. Contraintes : Vous disposez des logs Active Directory, de l'identité de l'utilisateur ayant effectué la modification et de la description du changement. Aucune modification immédiate de la GPO n'est autorisée sans validation. Livrable attendu : Examiner les journaux, évaluer la légitimité de la modification et recommander une action adaptée (validation, rollback, escalade).

Contexte : Un audit révèle qu'une fuite de données progressive sur plusieurs semaines n'a pas été détectée. Le Problème : Les règles actuelles détectent uniquement les transferts massifs de données sur une courte période. Configuration actuelle : Trigger if outbound_traffic > 5GB in 1 hour Les exfiltrations lentes passent inaperçues. Contraintes : Mettre en place une règle détectant des volumes cumulés anormaux sur plusieurs jours. Limiter les faux positifs liés aux sauvegardes légitimes. Livrable attendu : Proposer une logique de détection adaptée aux exfiltrations progressives tout en conservant un seuil pertinent.

Contexte : Le SIEM génère de nombreuses alertes liées à des scans internes, y compris ceux provenant d'outils d'inventaire IT. Le Problème : La règle actuelle déclenche une alerte pour toute connexion vers plus de 10 ports différents en 1 minute. Configuration actuelle : Trigger if distinct_ports > 10 in 60 seconds Cela inclut des outils légitimes. Contraintes : Adapter la règle pour distinguer scans malveillants et outils d'administration connus. Conserver une capacité de détection efficace. Livrable attendu : Proposer une logique de filtrage ou d'exception permettant de réduire les faux positifs sans affaiblir la détection réelle.

Contexte : Une tentative de brute force réussie n'a pas été détectée par le SIEM malgré plusieurs échecs suivis d'une connexion réussie. Le Problème : La règle actuelle détecte uniquement les échecs répétés sans corréler avec une authentification réussie. Configuration actuelle : Trigger if failed_logins > 5 within 5 minutes Aucune condition ne vérifie la réussite ultérieure. Contraintes : Modifier la règle pour détecter une séquence "plusieurs échecs suivis d'un succès". Éviter les faux positifs liés aux erreurs utilisateur légitimes. Livrable attendu : Proposer une logique de corrélation améliorée permettant de détecter les compromissions potentielles après brute force.

Contexte : Plusieurs serveurs internes enregistrent des tentatives d'authentification provenant d'un même poste utilisateur. Le Problème : Ce comportement peut indiquer un mouvement latéral après compromission initiale. Contraintes : Vous disposez des logs d'authentification Kerberos ou NTLM, des adresses IP sources et des horodatages. Vous devez analyser la cohérence des accès avec le rôle de l'utilisateur. Livrable attendu : Identifier les indicateurs de mouvement latéral et proposer des actions adaptées (isolation du poste, réinitialisation des identifiants, investigation approfondie).

Contexte : Une alerte DLP signale l'envoi d'un fichier contenant des données sensibles vers une adresse email externe. Le Problème : Vous devez déterminer s'il s'agit d'une action légitime ou d'une tentative d'exfiltration. Contraintes : Vous disposez des métadonnées du fichier, de l'identité de l'utilisateur et du contexte d'envoi. Le contenu exact du fichier n'est pas accessible. Livrable attendu : Analyser le contexte, identifier les éléments à risque et recommander les actions appropriées (notification, blocage, escalade).

Contexte : Une alerte EDR remonte l'exécution d'une commande PowerShell encodée sur un poste utilisateur du service comptabilité. Le Problème : La commande semble télécharger du contenu depuis une URL externe inconnue. Vous devez déterminer s'il s'agit d'un outil légitime ou d'une tentative d'exécution malveillante. Contraintes : Vous disposez des logs EDR, de la ligne de commande complète, du hash du fichier téléchargé et des connexions réseau associées. Aucun accès direct au poste n'est autorisé dans un premier temps. Livrable attendu : Analyser les indicateurs fournis, identifier les éléments suspects (encodage, domaine externe, comportement anormal) et rédiger un rapport concluant sur la nécessité d'isoler le poste ou d'escalader l'incident.

Contexte : Une alerte signale qu'un compte standard a ajouté un utilisateur au groupe administrateur sur un serveur applicatif. Le Problème : Vous devez déterminer si cette action correspond à une tâche d'administration planifiée ou à une compromission. Contraintes : Vous disposez des logs système, des journaux d'authentification et de l'historique des modifications de groupes. Aucun arrêt immédiat du service n'est autorisé sans justification. Livrable attendu : Analyser la chronologie des événements, identifier les incohérences éventuelles et recommander une action (escalade, isolation, clôture avec justification).

Contexte : Une application cloud signale des connexions API valides provenant d'une localisation inhabituelle. Le Problème : Aucun échec d'authentification n'est observé, mais le comportement suggère un possible vol de token OAuth. Contraintes : Vous disposez des logs d'accès API, des adresses IP sources et des timestamps. Aucune réinitialisation immédiate des services n'est autorisée sans preuve solide. Livrable attendu : Examiner les patterns d'accès, identifier les anomalies géographiques ou temporelles et recommander une stratégie de révocation ou surveillance.

Contexte : Un compte de service possède des privilèges élevés et est utilisé par plusieurs applications. Le Problème : Aucune règle ne surveille les connexions interactives avec ce compte. Configuration actuelle : Exclude service_accounts from login_alerts Cela permet un usage malveillant sans alerte. Contraintes : Maintenir les opérations applicatives légitimes tout en détectant toute utilisation interactive anormale du compte. Livrable attendu : Définir une règle de détection adaptée surveillant les usages suspects des comptes de service.

Contexte : Une simulation d'attaque utilise uniquement des outils natifs du système (PowerShell, WMI, certutil) sans malware externe. Le Problème : Les règles actuelles déclenchent uniquement sur la détection de fichiers malveillants connus. Configuration actuelle : Alert if malware_signature_detected == true Aucune corrélation comportementale n'est configurée. Contraintes : Proposer des règles basées sur comportements anormaux (exécution inhabituelle d'outils système, téléchargements externes, encodage suspect). Livrable attendu : Définir une stratégie de détection comportementale adaptée aux attaques Living-off-the-Land.

Contexte : Un exercice Red Team démontre qu'une attaque Golden Ticket n'a pas été détectée par le SOC. Le Problème : Les règles actuelles surveillent les échecs d'authentification mais pas les anomalies dans les tickets Kerberos. Configuration actuelle : Alert if failed_kerberos_auth > threshold Aucune vérification des durées de validité ou SID suspects. Contraintes : Vous devez proposer une règle capable de détecter des tickets Kerberos anormalement longs ou utilisant des SID privilégiés inhabituels. Livrable attendu : Définir une logique de détection adaptée aux attaques Golden Ticket et expliquer les indicateurs clés surveillés.

Contexte : Aucun échec d'authentification n'est observé, mais un compte utilisateur accède à plusieurs serveurs sensibles inhabituels. Le Problème : L'attaquant pourrait utiliser des identifiants valides pour se déplacer latéralement sans générer d'échecs visibles. Contraintes : Vous disposez des journaux d'accès, des horaires habituels d'activité utilisateur et des corrélations IP source. Aucun outil d'analyse comportementale automatique n'est disponible. Livrable attendu : Identifier les anomalies d'accès, établir un schéma de mouvement latéral possible et recommander des actions de confinement adaptées.

Contexte : Sur une période de plusieurs semaines, des alertes isolées ont été enregistrées : exécution PowerShell, connexions RDP inhabituelles et trafic sortant chiffré vers des domaines peu connus. Le Problème : Individuellement, les alertes semblent bénignes, mais vous suspectez une campagne APT progressive. Contraintes : Vous devez corréler des événements provenant de plusieurs sources (EDR, pare-feu, SIEM, DNS). Aucun indicateur unique n'est suffisant pour conclure. Livrable attendu : Construire une analyse corrélée démontrant ou infirmant l'existence d'une attaque multi-étapes et recommander les mesures de réponse adaptées.

Contexte : Plusieurs alertes corrélées indiquent des authentifications anormales sur des contrôleurs de domaine ainsi que la création d'un compte administrateur inattendu. Le Problème : Vous devez déterminer si l'environnement Active Directory est compromis et identifier le point d'entrée initial. Contraintes : Vous disposez des logs d'authentification Kerberos/NTLM, des événements de création de comptes, des modifications de groupes sensibles et des connexions réseau associées. Aucune coupure immédiate des services AD n'est autorisée sans justification. Livrable attendu : Reconstituer la chronologie de l'attaque potentielle, identifier les comptes compromis et proposer un plan d'action incluant confinement, réinitialisation des identifiants et surveillance renforcée.

Contexte : Plusieurs fichiers critiques sur un serveur ont été chiffrés avant qu'une alerte ne soit déclenchée. Le Problème : Les premières activités suspectes n'ont pas été identifiées à temps par le SOC. Contraintes : Vous disposez des logs EDR, des journaux système et des connexions réseau précédant le chiffrement. L'objectif est d'identifier le vecteur initial d'infection. Livrable attendu : Reconstituer la chaîne d'événements, identifier le point d'entrée initial et proposer des améliorations de détection pour éviter une récidive.

Contexte : Un serveur interne communique régulièrement avec un service cloud légitime via HTTPS. Le Problème : Une augmentation progressive du volume de données sortantes est observée, mais le trafic semble légitime car il utilise un service reconnu. Contraintes : Vous disposez uniquement des métadonnées réseau (volume, fréquence, destination) et des journaux applicatifs. Aucun accès au contenu chiffré. Livrable attendu : Analyser les tendances de trafic, identifier les écarts comportementaux et déterminer s'il s'agit d'une utilisation normale ou d'une exfiltration masquée.

Contexte : Suite à une compromission confirmée d'un poste utilisateur, vous devez vérifier si d'autres machines ont été impactées. Le Problème : Aucun indicateur direct ne montre une propagation, mais des connexions internes suspectes ont été observées. Contraintes : Vous disposez des logs réseau, EDR et authentification sur une période de 30 jours. Aucune interruption massive des services n'est autorisée. Livrable attendu : Définir une méthodologie de threat hunting, identifier des indicateurs de compromission potentiels et proposer des actions de remédiation ciblées.