Fichier signé dans une alerte : vérifier la signature sans arrêter l’enquête

Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.

Une alerte porte sur un exécutable Windows. Sa fiche affiche un éditeur connu et une signature valide. Ce résultat mérite d’être conservé, mais quelle question permet-il de trancher ? Avant de classer l’alerte, le SOC doit relier le fichier examiné, les contrôles réellement effectués et l’activité qui a déclenché la détection.

Authenticode apporte des éléments sur l’identité du signataire et l’intégrité du contenu couvert par la signature, dans une chaîne de confiance. Son résultat doit être interprété dans ce périmètre. La méthode suivante concerne l’investigation d’un fichier Windows ; elle ne remplace pas une procédure d’analyse de malware. Source : Microsoft, Authenticode

1. Fixer l’identité du fichier réellement examiné

Notre recommandation : conserver la référence de l’alerte, le poste concerné, l’heure de l’observation et l’origine de la copie analysée. Relevez sa taille et une empreinte cryptographique du fichier complet, avec l’algorithme utilisé. Un même nom ou un même emplacement ne suffit pas à relier deux observations.

Vérifiez si le fichier a été remplacé entre l’alerte et la collecte. Une copie téléchargée depuis le site de l’éditeur peut servir de référence, mais elle ne prouve pas ce qui se trouvait sur le poste au moment des faits. Si la copie initiale manque, explicitez cette limite plutôt que de lui substituer silencieusement une version récente.

Attention aussi au type d’empreinte : Microsoft distingue le hash du fichier complet du hash Authenticode d’une image PE, dont le calcul exclut certaines zones, notamment liées à la signature. Deux valeurs portant le même nom d’algorithme ne sont donc pas nécessairement comparables. Source : Microsoft, types de hash

Documentez la méthode de calcul lorsque vous rapprochez un inventaire, une règle de contrôle applicatif et une collecte d’incident. Conservez l’original selon votre procédure de preuve et travaillez sur une copie. Examiner la signature ne nécessite pas de lancer l’exécutable suspect sur le poste de l’analyste.

2. Comprendre ce que l’outil a effectivement vérifié

SignTool distingue la recherche d’une signature intégrée ou d’un catalogue, les politiques de validation et la vérification de plusieurs signatures. Sa documentation précise aussi que la politique choisie compte et que le programme peut terminer avec des avertissements. Un résumé « signé » efface ces différences. Source : Microsoft, SignTool

Nous recommandons de conserver le résultat détaillé avec la version de l’outil, le système d’analyse, la politique appliquée et l’heure du contrôle. Identifiez la signature retenue, le certificat du signataire et, le cas échéant, le catalogue utilisé. Faites préciser le traitement des signatures multiples au lieu de supposer qu’une ligne de synthèse les couvre toutes.

Un outil qui ne trouve aucune signature intégrée n’a pas nécessairement recherché une signature par catalogue. Source : Microsoft, vérification d’une signature Inversement, la présence d’un certificat dans les propriétés d’un fichier ne documente pas à elle seule l’ensemble des contrôles de confiance. Avant de comparer deux résultats, vérifiez qu’ils portent sur le même fichier et le même mode de validation.

3. Conserver le contexte de confiance et les incertitudes

Un horodatage Authenticode valide peut permettre de vérifier une signature après l’expiration du certificat de signature, sous réserve des contrôles de confiance applicables. La seule date d’expiration affichée ne suffit donc pas à conclure. Faites examiner l’horodatage et le résultat de validation, sans l’interpréter comme une autorisation d’exécuter le fichier. Source : Microsoft, horodatage Authenticode

Les contrôles de révocation et les consultations réseau dépendent également du mode de vérification. La documentation WinTrust prévoit notamment des contrôles de révocation et un fonctionnement limité au cache local. Un environnement hors ligne doit être décrit comme tel dans la preuve. Source : Microsoft, paramètres WinTrust

Notre recommandation : distinguer une validation réussie, un refus identifié et un contrôle incomplet. Si les informations nécessaires ne sont pas disponibles, conservez l’incertitude et attribuez la vérification complémentaire. Ne désactivez pas un contrôle ou n’ajoutez pas un certificat de confiance simplement pour obtenir un résultat favorable.

Si les résultats diffèrent entre le poste concerné et l’environnement d’analyse, documentez l’écart : système, politique, magasins de confiance, heure et accès disponibles. Une nouvelle vérification explique l’état observé à cet instant ; elle ne réécrit pas automatiquement le résultat que le poste a pu obtenir au moment de l’incident.

4. Relier le fichier à l’activité qui a déclenché l’alerte

MITRE ATT&CK décrit l’utilisation de matériel de signature acquis ou volé pour signer des outils malveillants, avec une signature pouvant être valide. Cette possibilité justifie de poursuivre l’analyse du comportement ; elle ne démontre pas que le signataire du fichier examiné est compromis. Source : MITRE ATT&CK, Code Signing

Revenez à la détection : quelle activité faut-il expliquer, sur quel poste et à quelle heure ? Nous recommandons de relier le fichier aux observations disponibles sur son lancement, son contexte utilisateur, ses actions et ses communications. La vérification d’une copie sur disque doit rester distincte des preuves portant sur le processus effectivement observé.

Exemple entièrement fictif : un outil d’administration signé par un éditeur connu apparaît dans une alerte de transfert de fichiers. La signature valide aide à identifier l’outil collecté. L’enquête doit encore établir qui l’a lancé, vers quelle destination, avec quelles autorisations et quelles données ont été concernées. Un usage légitime confirmé et un usage non autorisé restent deux conclusions possibles.

Évitez une exception couvrant tous les fichiers d’un éditeur pour expliquer cette seule occurrence. Si une activité attendue est confirmée, limitez la décision au périmètre vérifié. Si le comportement reste inexpliqué, gardez le dossier ouvert selon votre procédure, même lorsque la signature est valide.

5. Séparer l’analyse locale des envois à un tiers

Sigcheck propose à la fois des vérifications locales, des recherches VirusTotal par hash et, avec une option distincte, l’envoi de fichiers inconnus au service. Ces fonctions n’ont pas la même portée en matière de partage. Source : Microsoft Sysinternals, Sigcheck

Avant un enrichissement externe, vérifiez les données transmises, le destinataire et l’autorisation applicable. Une recherche par empreinte et un téléversement du fichier sont deux décisions différentes. Un échec de recherche ne doit pas entraîner automatiquement l’envoi d’un binaire contenant des informations internes.

Nous recommandons de consigner séparément le résultat de signature et le résultat de réputation, avec leur date et leur source. Précisez ce que chaque service a réellement examiné. Aucune de ces observations ne dispense d’expliquer l’activité à l’origine de l’alerte.

6. Produire une conclusion que l’équipe suivante peut vérifier

Une fiche de décision devrait réunir l’identité du fichier collecté, le lien avec l’alerte, le mode de validation, le signataire, l’horodatage éventuel, le résultat détaillé et les limites du contrôle. Ajoutez les observations de comportement, la décision retenue, son responsable et ce qui doit encore être confirmé.

Pour tester la procédure, utilisez des fichiers de test inoffensifs et un environnement autorisé, avec un résultat attendu écrit à l’avance :

• Un fichier signé et une copie différente portant le même nom.
• Un fichier signé par catalogue, examiné avec puis sans recherche du catalogue.
• Un fichier comportant plusieurs signatures, dont les résultats doivent rester identifiables.
• Une signature horodatée dont le certificat de signature a expiré.
• Un contrôle dont les informations de révocation nécessaires sont indisponibles.
• Un outil signé dont l’utilisation autorisée et l’utilisation non autorisée sont décrites dans deux scénarios fictifs.

Vérifiez que la méthode conserve les avertissements, permet un statut indéterminé et ne transforme jamais une validation technique en clôture automatique. La conclusion utile précise ce que la signature établit, quel comportement a été expliqué et quelle preuve manque encore pour décider.