Entretien cybersécurité : un cas SOC pour analyser des logs et justifier une escalade

En entretien cybersécurité, vous pouvez devoir qualifier une alerte SOC avec des preuves incomplètes. Vous devez expliquer quelles observations justifient une investigation, lesquelles peuvent être reliées et ce qu’il manque avant d’annoncer une compromission ou une exfiltration.

Le cas original de ce guide combine une authentification réseau, un processus PowerShell et des requêtes vues par un proxy. Construisez une chronologie, une table de confiance et une escalade concise. Commencez aussi par Design a Security Monitoring Framework pour discuter des champs nécessaires à une investigation, sans transformer une règle d’alerte en verdict.

Périmètre des preuves : les pages Microsoft et les RFC citées fondent les mécanismes techniques. Les événements, machines, destinations et échanges sont fictifs et normalisés pour cet exercice ; ils ne sont pas des exports EVTX ni le schéma d’un fournisseur de proxy. Huit vérifications Python contrôlent leur cohérence. Elles n’évaluent ni un détecteur réel ni une réponse à incident. Aucun témoignage de candidat ne décrit un format d’entreprise garanti.

Lire le paquet avant de raconter une attaque

Le SOC reçoit une alerte sur le poste W12. Une tâche d’inventaire y est normalement attendue, mais son propriétaire n’a pas encore confirmé le comportement observé. Le paquet contient huit livraisons de journal pour sept événements distincts : x3 a été livré deux fois. Tous les horaires suivants sont en UTC, le même jour fictif.

Le paquet fournit une correspondance entre W12 et 192.0.2.40 valable de 9 h 55 à 10 h 10. Elle aide à rattacher l’adresse source à un poste sur cette période. Les adresses sont tirées des blocs de documentation décrits par la RFC 5737 ; elles ne désignent pas une infrastructure à examiner.

La ligne a1 n’arrive dans le collecteur qu’à 10 h 12. Si vous triez par réception, elle apparaît après les POST. Si vous triez par heure d’événement, elle les précède. Gardez les deux horloges et vérifiez leur qualité : le paquet les suppose comparables, mais une vraie enquête doit considérer dérive et fuseaux.

Le doublon x3 conserve le même identifiant stable et le même contenu, sauf l’heure d’ingestion. Le comptage naïf produit 160 000 octets pour les POST ; le comptage dédupliqué produit 80 000. Cette correction dépend de notre convention d’identifiant. Dans un système réel, vérifiez sa portée avant de supprimer deux requêtes qui auraient seulement le même contenu.

Relier un processus à une connexion sans inventer le reste

Microsoft indique que Sysmon peut journaliser la création des processus et les connexions réseau. Les champs ProcessGuid et ProcessId participent à leur corrélation. La présence d’un événement dépend aussi de la configuration ; son absence ne suffit pas à démontrer qu’aucune connexion n’a eu lieu.

Dans notre paquet, p2 et n1 partagent W12 et l’instance G-shell. Nous pouvons donc relier ce processus à cette connexion au proxy, selon la normalisation fournie. Le processus ne se connecte pas directement à l’adresse d’un service externe dans n1 : la destination observée est le proxy. Le journal réseau ne contient pas l’URL du POST.

Les lignes x2 et x3 concernent W12 quelques secondes plus tard. Leur attribution à G-shell reste une hypothèse, mais le paquet ne fournit ni identifiant de requête partagé ni association proxy-processus. Un autre processus du poste pourrait avoir émis ces requêtes. Une chronologie proche justifie une recherche complémentaire ; elle ne remplace pas une clé de jointure.

Demandez la ligne de commande, les détails de l’agent parent, les chemins et les éléments de réputation disponibles. Ici, la ligne de commande et le hash manquent. « PowerShell » décrit un outil, pas son intention. Un script d’administration autorisé et une activité malveillante peuvent employer le même exécutable ; le contexte doit départager les hypothèses.

L’instance G-update de l’autre processus n’est pas G-shell. Le GET de mise à jour ne prouve pas que les POST sont normaux, et leur proximité ne rend pas l’outil de mise à jour malveillant. Gardez ces activités séparées tant que les observations ne les relient pas. Un nom de fichier ressemblant à un produit connu ne valide pas non plus sa provenance.

Interpréter 4624 et les identifiants de session

La documentation Microsoft de l’événement 4624 décrit une ouverture de session réussie. Le type 3 correspond à une connexion réseau. Les champs d’origine et les identifiants permettent certaines corrélations, avec des limites liées au protocole et à la disponibilité des informations.

Dans a1, c’est FS7 qui enregistre une session pour le compte de service, depuis l’adresse associée à W12. Cette observation mérite une comparaison avec l’usage attendu du compte. Elle ne prouve ni lecture d’un fichier sensible ni mouvement latéral malveillant. Le type de connexion n’explique pas à lui seul l’action métier accomplie après l’authentification.

Le LogonId 0x77 appartient à FS7 ; le processus p2 sur W12 porte 0x41. Ne les fusionnez pas en une session globale. Même une égalité numérique sur deux machines ne suffirait pas à établir cette identité. Le nom de compte commun ouvre une piste, mais ne montre pas que le processus est à l’origine de la connexion à FS7.

Demandez les événements pertinents sur FS7, leur configuration d’audit et les accès attendus pour ce compte. Le propriétaire confirme à 10 h 20 qu’une tâche d’inventaire est prévue, mais ne confirme encore ni PowerShell ni un téléversement externe. Cette déclaration est une information de contexte, pas une analyse du programme ni une preuve de compromission.

Vous pouvez dire : « L’utilisation du compte depuis W12 est documentée ; son caractère autorisé reste à vérifier. » Cette formulation indique le motif d’investigation sans conclure que les identifiants ont été volés. Si de nouveaux éléments montrent une exécution approuvée, votre hypothèse doit évoluer et la trace de décision doit rester lisible.

Ne pas traduire le statut 200 en exfiltration confirmée

La RFC 9110 définit le sens HTTP de 200 et rappelle que le contenu de la réponse dépend de la méthode. Ce code ne décrit pas la sensibilité des données envoyées. Dans notre paquet, il est enregistré par le proxy ; nous n’avons pas de journal applicatif de la destination.

Le champ client_to_proxy_bytes mesure ici les octets du client vers le proxy selon la convention de l’exercice. Il ne mesure pas uniquement un fichier ni uniquement une charge utile. Le compteur upstream_bytes_sent est absent. Nous ne savons donc pas calculer les octets transmis par le proxy au service externe, encore moins identifier un document confidentiel.

Le 403 de x2 puis le 200 de x3 ne prouvent pas un contournement de protection. Il pourrait s’agir de requêtes différentes ou d’une variation de traitement ; les éléments pour expliquer la transition manquent. Le compteur nul de x2 décrit seulement ce champ pour cette ligne. Il ne garantit pas qu’aucune autre activité n’a atteint la destination.

Une conclusion prudente est : « Un POST avec 80 000 octets client vers proxy est enregistré ; l’origine exacte, le contenu et la transmission externe restent à établir. » Pour progresser, demandez les champs du proxy qui précisent le traitement et la destination, ainsi que les éléments autorisés de télémétrie endpoint. Ne récupérez pas de contenu utilisateur sans nécessité ni procédure adaptée.

Construire une échelle de confiance utile à la décision

Attribuez un niveau de confiance à chaque proposition, pas sur un pourcentage global inventé. Vous pouvez avoir une forte confiance dans la nécessité d’investiguer tout en restant incertain sur la technique employée et l’impact. Une escalade n’exige pas de terminer le récit d’une attaque ; elle doit rendre visible la décision qu’un autre intervenant peut prendre.

Comparez au moins deux explications : une tâche d’administration dont le comportement n’est pas encore documenté, et une utilisation non autorisée d’un outil légitime. Pour chacune, nommez l’élément qui ferait changer votre position. Une validation du propriétaire doit identifier le script ou la tâche concernée, pas seulement confirmer que « l’inventaire existe ».

Précisez aussi les limites de couverture. Le paquet n’indique pas tous les postes, tous les horaires ni tous les canaux réseau. L’absence d’autres lignes dans ce petit extrait ne permet pas de conclure que l’incident est isolé. Votre prochaine recherche doit préciser une fenêtre horaire et un ensemble de postes, afin qu’un résultat négatif ait un sens.

Rédiger l’escalade sans annoncer un résultat non observé

Note proposée à 10 h 22 : « W12 présente une exécution PowerShell sous le compte de service et une connexion de cette instance au proxy. Le proxy enregistre ensuite deux POST, dont un statut 200 avec 80 000 octets client vers proxy après déduplication. L’attribution de ces POST au processus et l’envoi externe ne sont pas établis. FS7 contient une session réseau du même compte depuis W12, sans corrélation de session démontrée avec le processus. »

Décision demandée : « Merci de qualifier la tâche avec l’équipe endpoint et son propriétaire, puis d’évaluer une mesure de confinement selon la procédure et l’impact sur le poste. À recueillir en priorité : ligne de commande, identité du script, détails de traitement proxy et activité du compte sur FS7. Prochain point proposé à 10 h 30. »

Cette note ne signifie pas qu’un poste a été isolé ou qu’un compte a été désactivé. Dans une vraie organisation, les autorités et procédures de réponse déterminent ces actions. En entretien, expliquez les conséquences possibles d’un confinement sur l’activité et comment vérifier son application. N’annoncez pas une mesure accomplie lorsque vous l’avez seulement recommandée.

Conservez le paquet original, ses identifiants et les transformations de déduplication dans l’outil prévu. Limitez les copies de données sensibles et séparez les notes de raisonnement des événements sources. Un hash peut contrôler l’intégrité d’une copie ; il ne garantit pas que le journal d’origine disait la vérité ni qu’il était complet.

S’entraîner à défendre chaque lien

Ces tâches entraînent des compétences voisines, sans constituer un examen SOC officiel. Répondez d’abord à Design a Security Monitoring Framework avec ce paquet. Demandez ensuite à un partenaire d’ajouter une confirmation ou une contradiction : votre escalade doit changer avec les preuves, tout en conservant ses limites.

Sources and Further Reading

• Microsoft Learn — Sysmon
• Microsoft Learn — Événement Windows 4624
• RFC 9110 — HTTP 200 OK
• RFC 5737 — Adresses IPv4 de documentation