Comment vérifier qu’un fichier n’est pas un malware : hachages, signatures et réalité

Vérification de la réalité : ce que « n’est pas un malware » signifie réellement

Commençons par la partie inconfortable : « malware » désigne un comportement et une intention, pas un format de fichier. Un binaire parfaitement signé et avec un hachage correct peut quand même être malveillant. Un scan antivirus propre peut rater une charge utile nouvelle. Un fournisseur « de confiance » peut livrer une mise à jour compromise.

Que pouvez‑vous donc faire ? Répondre à des questions plus étroites et opérationnellement utiles :

• Intégrité : Ce fichier est‑il exactement ce que l’éditeur a produit ? (Hachages, sommes de contrôle, builds reproductibles.)
• Authenticité : A‑t‑il été publié par l’entité que vous pensez ? (Signatures, chaînes de certificats, clés de confiance.)
• Provenance : Est‑il arrivé par le canal attendu, avec les métadonnées attendues ? (Dépôts de paquets, SBOM, attestations.)
• Indicateurs de risque : Ressemble‑t‑il à du connu‑malveillant ou suspect ? (Moteurs AV, réputation, analyse statique.)
• Comportement : Que fait‑il lorsqu’il est exécuté ? (Sandboxing, surveillance des egress, traçage des appels système.)

En production, vous ne vous arrêtez pas à « le hachage correspond ». La correspondance de hachage prouve la cohérence. Elle ne prouve pas la bienveillance. C’est comme confirmer que la livraison de repas est scellée ; cela ne vous dit pas si le chef vous vouait de l’animosité.

Une citation pour rester honnête. La ligne célèbre de Gene Kim est souvent paraphrasée ; c’est l’idée qui compte ici :

Gene Kim (idée paraphrasée) : Améliorer les résultats passe souvent par améliorer le système, pas par blâmer la personne qui a appuyé sur le bouton.

Vous construisez un système de vérification : étapes reproductibles, décisions claires et journaux expliquant pourquoi vous avez fait confiance. C’est de l’ingénierie de fiabilité appliquée à la chaîne d’approvisionnement.

Faits et historique intéressants (court, utile, lucide)

• MD5 était autrefois « suffisant » pour l’intégrité. En 2004 des attaques par collision pratiques ont été démontrées, et en 2008 des chercheurs ont créé un certificat CA forgé utilisant des collisions MD5. Si vous voyez MD5 comme seul mécanisme d’intégrité, prenez‑le comme un signal d’alarme.
• SHA‑1 a subi le même sort. La collision « SHAttered » en 2017 a rendu SHA‑1 inadapté à la résistance aux collisions. Beaucoup d’écosystèmes sont passés à SHA‑256+ après cela, mais la documentation ancienne reste comme une mauvaise odeur.
• Authenticode existe depuis les années 1990. La signature de code Windows n’est pas nouvelle ; la difficulté est l’hygiène opérationnelle : révocation, horodatage et compréhension de ce que « valide » signifie réellement.
• PGP précède les app stores modernes. PGP date de 1991. Les outils sont anciens, mais le concept — vérifier la signature d’un éditeur avec une clé de confiance — reste fondamental pour la vérification des paquets Linux.
• La révocation de certificats est compliquée en pratique. CRL et OCSP existent, mais les réseaux les bloquent, les clients tolèrent l’échec, et les équipes de sécurité découvrent « on ne peut rien révoquer sans casser la prod ».
• Les auteurs de malwares signent aussi le code. Les clés de signature volées et les certificats « sur le marché gris » reviennent régulièrement. Une signature prouve quelle clé a signé, pas que le signataire est bon.
• Les attaques de la chaîne d’approvisionnement ont pris de l’ampleur avec l’automatisation. CI/CD a augmenté la vitesse et le rayon d’impact. Si un attaquant peut atterrir dans votre build ou canal de mise à jour, vos utilisateurs vont vérifier et installer fidèlement l’artefact compromis.
• Les builds reproductibles sont une révolution silencieuse. Quand un projet peut prouver que quiconque peut reconstruire le même binaire depuis le code source, la vérification par hachage devient plus significative. Pas assez répandu, mais à privilégier.
• Les « bases de hachages » sont devenues un primitive de sécurité. Les équipes partagent des IOC comme des hachages, mais les attaquants re‑conditionnent facilement les binaires pour changer les hachages. Les hachages servent à faire des correspondances, pas à chasser un adversaire adaptatif.

Blague #1 : Les hachages sont comme des étiquettes de bagages : géniaux pour identifier votre valise, pas pour prouver qu’elle ne contient pas un furet.

Hachages : intégrité, pas confiance

Un hash cryptographique (SHA‑256, SHA‑512) vous donne une empreinte des octets. Si un seul bit change, le hash change. C’est pourquoi les hachages sont excellents pour détecter la corruption et la falsification.

À quoi les hachages sont bons

• Détecter la corruption accidentelle (téléchargements défaillants, stockage instable, modification par des proxies, copies multipart S3 cassées).
• Détecter la falsification peu sophistiquée (quelqu’un a remplacé le fichier sans mettre à jour la somme publiée).
• Identité d’artefact dans les pipelines (c’est exactement la sortie de build que nous avons testée et promue).

À quoi les hachages sont mauvais

• Établir qui a produit le fichier. Si l’attaquant peut changer le fichier, il peut généralement aussi changer le checksum publié à côté.
• Prouver la sécurité. Un match de hash peut signifier « vous avez reçu le malware prévu ».
• Survivre à un remballage mineur. Recompresser une archive ou changer des métadonnées change le hash.

La seule façon dont un hash publié vous apporte de la confiance

Un hash a du sens lorsqu’il est ancré à un canal de confiance que vous avez déjà. Exemples :

• Le hash est délivré par un canal différent du fichier (par ex., imprimé dans une note de release signée, ou dans un manifeste signé séparé).
• Le hash lui‑même est signé (fichier de checksums signé GPG, signature Sigstore, métadonnées de type TUF).
• Le hash se trouve dans un gestionnaire de paquets avec métadonnées vérifiées (apt, rpm) et vous faites confiance à la clé du dépôt.

Si le fichier et le checksum proviennent de la même page Web non authentifiée, considérez le checksum comme décoratif.

Signatures numériques : confiance, avec conditions

Les signatures sont la version adulte de « le checksum correspond », car elles lient les octets à une clé privée. Si vous faites confiance à la clé, vous pouvez faire confiance à la signature.

Trois modèles de signatures que vous rencontrerez

1. Modèle CA publique (X.509) : Utilisé par Windows Authenticode et macOS Developer ID. La confiance est déléguée aux autorités de certification que votre OS fait confiance.
2. Web‑of‑trust / clés épinglées (OpenPGP) : Courant pour les artefacts de release upstream et les écosystèmes Linux. Vous décidez quelles clés des mainteneurs vous faites confiance, puis vous vérifiez les signatures.
3. Journal de transparence / signature liée à une identité (moderne) : Systèmes qui enregistrent les signatures dans des journaux append‑only et lient des identités (souvent via OIDC). Puissant, mais il faut valider la politique : qui est autorisé à signer quoi.

Modes d’échec de vérification de signature à reconnaître

• Signature valide, mauvais signataire. La signature est cryptographiquement correcte, mais elle a été faite par « Some Random LLC » que vous ne connaissez pas. Ce n’est pas gagné.
• Signature valide, certificat révoqué. Votre outil peut ne pas vérifier la révocation, ou la politique réseau peut bloquer OCSP/CRL. « Valide » peut être « valide isolément ».
• Signature valide, mais horodatage manquant. Si le certificat expire demain, une signature horodatée peut rester valide ; une signature non horodatée devient problématique.
• Compromission de clé. Si la clé de signature est volée, les signatures deviennent une responsabilité. Il faut une révocation et une surveillance.

Les signatures sont nécessaires, pas suffisantes. Utilisez‑les comme contrôle d’admission : « cela vient de l’éditeur attendu ». Ensuite faites des contrôles comportementaux avant de le laisser approcher la production.

Blague #2 : Une signature valide signifie « quelqu’un avec une clé l’a signée », ce qui rassure sauf si la clé a été volée — comme un ticket de voiturier pour une voiture qui n’est pas la vôtre.

Tâches pratiques de vérification (commandes + sortie + décisions)

Voici les tâches que j’utilise réellement en réponse aux incidents et en exploitation routinière. Chacune inclut : une commande, à quoi ressemble une sortie « normale », et la décision suivante.

Tâche 1 : Calculer un hash SHA‑256 et comparer à une valeur attendue

cr0x@server:~$ sha256sum ./agent-installer-linux-amd64.tar.gz
b7f1b6a8c3c5b6e1d5a3e6b2d5d2f4f7e0a9c1b4d6b8a0c9f1e2d3c4b5a6d7e8  ./agent-installer-linux-amd64.tar.gz

Ce que cela signifie : Cette chaîne hexadécimale est le SHA‑256 du fichier. Comparez‑la à un SHA‑256 attendu provenant d’une source de confiance (de préférence un manifeste signé).

Décision : Si elle ne correspond pas exactement, arrêtez. Ne « réessayez pas » en espérant. Enquêtez sur le transport, les miroirs, les proxies ou la falsification.

Tâche 2 : Vérifier un fichier de checksum contre un ensemble de téléchargements

cr0x@server:~$ sha256sum -c SHA256SUMS
agent-installer-linux-amd64.tar.gz: OK
agent-installer-linux-arm64.tar.gz: OK

Ce que cela signifie : Les fichiers correspondent aux hachages listés dans SHA256SUMS.

Décision : Significatif uniquement si SHA256SUMS est lui‑même de confiance (idéalement vérifié par signature). Si le fichier de checksum provient du même endroit que les binaires, poursuivez mais ne l’appelez pas « vérifié ».

Tâche 3 : Vérifier une signature GPG d’un manifeste de checksums

cr0x@server:~$ gpg --verify SHA256SUMS.asc SHA256SUMS
gpg: Signature made Tue 14 Jan 2025 09:12:04 AM UTC
gpg:                using RSA key 2A1B3C4D5E6F7890A1B2C3D4E5F60718293A4B5C
gpg: Good signature from "Release Signing Key <release@example.org>" [unknown]

Ce que cela signifie : La signature correspond cryptographiquement. Notez cependant le label [unknown] : votre porte‑clé n’a pas établi la confiance.

Décision : Ne vous arrêtez pas à « Good signature ». Validez l’empreinte de la clé hors‑bande (canal séparé) ou via la politique d’épinglage de votre organisation. Si vous ne pouvez pas établir la provenance de la clé, considérez cela comme « intégrité avec astérisque ».

Tâche 4 : Inspecter l’empreinte de la clé GPG avant de lui faire confiance

cr0x@server:~$ gpg --fingerprint "Release Signing Key"
pub   rsa4096 2023-03-10 [SC]
      2A1B 3C4D 5E6F 7890 A1B2  C3D4 E5F6 0718 293A 4B5C
uid           [ unknown] Release Signing Key <release@example.org>

Ce que cela signifie : C’est l’identité de la clé que vous devez faire correspondre à une empreinte de confiance (ticket, annexe de contrat fournisseur, clé pré‑épinglée dans la gestion de configuration).

Décision : Si l’empreinte ne correspond pas à la valeur attendue, arrêtez. Si vous n’avez pas de valeur attendue, corrigez ce processus avant de « faire confiance » à la clé.

Tâche 5 : Vérifier la signature d’un paquet Linux et la confiance du dépôt (APT)

cr0x@server:~$ apt-cache policy nginx
nginx:
  Installed: 1.24.0-1~jammy
  Candidate: 1.24.0-1~jammy
  Version table:
 *** 1.24.0-1~jammy 500
        500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
        100 /var/lib/dpkg/status

Ce que cela signifie : Montre quel dépôt fournit le paquet. APT vérifie automatiquement les signatures des métadonnées du dépôt quand il est correctement configuré.

Décision : Si le candidat vient d’un dépôt inattendu, traitez‑le comme un incident de chaîne d’approvisionnement. Confirmez sources.list, le pinning et les clés du dépôt.

Tâche 6 : Vérifier la signature d’un paquet RPM

cr0x@server:~$ rpm -K ./vendor-agent-2.3.1-1.x86_64.rpm
vendor-agent-2.3.1-1.x86_64.rpm: digests signatures OK

Ce que cela signifie : Le digest et la signature du paquet valident par rapport aux clés installées dans le porte‑clé RPM.

Décision : Si cela affiche NOKEY ou échec de signature, n’installez pas. Obtenez la clé GPG correcte du fournisseur via un canal de confiance et revérifiez.

Tâche 7 : Vérifier la signature Authenticode sur Windows (PowerShell)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-AuthenticodeSignature .\VendorTool.exe | Format-List"
SignerCertificate : [Subject]
                     CN=Vendor Corp, O=Vendor Corp, L=San Jose, S=CA, C=US

Status            : Valid
StatusMessage     : Signature verified.
Path              : C:\Users\cr0x\Downloads\VendorTool.exe

Ce que cela signifie : Windows valide que le fichier est signé et que la signature cha îne jusqu’à une racine de confiance.

Décision : Si Status n’est pas Valid, arrêtez. Si c’est valide mais que le sujet ne correspond pas à l’éditeur attendu, arrêtez. Si c’est valide et que cela correspond, passez aux vérifications de réputation/comportement.

Tâche 8 : Valider la signature et la notarisation sur macOS

cr0x@server:~$ codesign -dv --verbose=4 /Applications/VendorTool.app 2>&1 | sed -n '1,12p'
Executable=/Applications/VendorTool.app/Contents/MacOS/VendorTool
Identifier=com.vendor.tool
Format=app bundle with Mach-O thin (arm64)
CodeDirectory v=20500 size=12345 flags=0x0(none) hashes=380+5 location=embedded
Signature size=9012
Authority=Developer ID Application: Vendor Corp (ABCDE12345)
Authority=Developer ID Certification Authority
Authority=Apple Root CA

Ce que cela signifie : Vous voyez les autorités de signature. C’est la vue « qui a signé ».

Décision : Confirmez que l’identité Developer ID correspond à ce que vous attendez. Puis vérifiez aussi l’évaluation de Gatekeeper :

cr0x@server:~$ spctl --assess --type execute --verbose=4 /Applications/VendorTool.app
/Applications/VendorTool.app: accepted
source=Notarized Developer ID

Ce que cela signifie : « accepted » avec « Notarized » est un signal plus fort que « signed only ».

Décision : Accepted + identité correcte vous amène à « raisonnable pour tester ». Cela ne signifie pas « sûr en production ».

Tâche 9 : Identifier le type de fichier et les tromperies évidentes

cr0x@server:~$ file ./invoice.pdf
invoice.pdf: PE32+ executable (GUI) x86-64, for MS Windows

Ce que cela signifie : Ce « PDF » est en réalité un exécutable Windows. Classique.

Décision : Traitez‑le comme hostile. Mettez en quarantaine et lancez le workflow d’incident. N’ouvrez pas « juste pour voir ».

Tâche 10 : Lister le contenu d’une archive sans exécuter quoi que ce soit

cr0x@server:~$ tar -tzf ./agent-installer-linux-amd64.tar.gz | head
agent/
agent/install.sh
agent/bin/agentd
agent/conf/agent.yaml
agent/LICENSE

Ce que cela signifie : Contrôle de base : vous voyez des chemins attendus. Recherchez aussi des éléments suspects : fichiers cachés, binaires inattendus, ou scripts « postinstall ».

Décision : Si vous voyez des éléments inattendus (par ex., .ssh/, cron.d/, ou des binaires ELF aléatoires), arrêtez et enquêtez.

Tâche 11 : Inspection statique de chaînes pour IOCs évidents

cr0x@server:~$ strings -n 10 ./agent/bin/agentd | egrep -i 'http|https|powershell|curl|wget|/bin/sh' | head
https://telemetry.vendor.example/api/v2
/usr/bin/curl
/bin/sh
POST /v1/register

Ce que cela signifie : Les chaînes ne sont pas une preuve, mais elles fournissent un signal peu coûteux. Voir /bin/sh ou curl dans un « agent simple » peut être normal — ou préoccupant selon vos attentes.

Décision : Servez‑vous de cela pour décider d’escalader vers une analyse plus profonde (sandbox, capture réseau, reverse engineering) avant toute exécution.

Tâche 12 : Vérifier les dépendances de bibliothèques dynamiques (Linux) pour des anomalies

cr0x@server:~$ ldd ./agent/bin/agentd | head
linux-vdso.so.1 (0x00007ffd1c7f9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3c9a1d0000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3c99fca000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3c99bd9000)

Ce que cela signifie : Les bibliothèques système normales sont attendues. Si vous voyez des chemins étranges (comme /tmp/libsomething.so) ou des chargeurs intégrés, c’est suspect.

Décision : Des chemins de dépendance inattendus signifient « pause » et enquêtez pour des tricks de loader ou des composants runtime trojanisés.

Tâche 13 : Scanner avec un moteur antivirus sur hôte (exemple ClamAV)

cr0x@server:~$ clamscan -r --infected --no-summary ./agent-installer-linux-amd64.tar.gz
./agent-installer-linux-amd64.tar.gz: OK

Ce que cela signifie : Aucun matching dans les signatures connues.

Décision : « OK » n’est pas feu vert, c’est « aucun hit connu ». Si c’est à haut risque (agents de production, installateurs privilégiés), continuez malgré tout avec provenance/signature et contrôles comportementaux.

Tâche 14 : Soumettre un hash à votre store de réputation interne (exemple local)

cr0x@server:~$ grep -i "b7f1b6a8c3c5b6e1" /var/lib/ioc/known_bad_sha256.txt
...output is empty...

Ce que cela signifie : Non présent dans la liste des mauvais connus.

Décision : L’absence de preuve n’est pas une preuve d’absence. Utilisez‑le comme un input, pas comme un verdict.

Tâche 15 : Observer le comportement du fichier dans un environnement contraint (vue réseau + processus sous Linux)

cr0x@server:~$ sudo systemd-run --unit=agent-test --property=PrivateNetwork=yes --property=NoNewPrivileges=yes --property=DynamicUser=yes ./agent/bin/agentd --version
Running as unit: agent-test.service
Agent v2.3.1

Ce que cela signifie : Vous avez exécuté le binaire avec réseau isolé et privilèges contraints. Il a renvoyé une chaîne de version et s’est terminé.

Décision : S’il tente de rester bloqué, de lancer des shells ou d’échouer de façon étrange, escaladez. S’il se comporte comme attendu, vous pouvez procéder à un test sandbox plus complet avec egress contrôlé.

Tâche 16 : Surveiller les connexions sortantes pendant un test

cr0x@server:~$ sudo ss -tpn | head
State  Recv-Q Send-Q Local Address:Port   Peer Address:Port  Process
ESTAB  0      0      10.0.2.15:45822     198.51.100.44:443  users:(("agentd",pid=2190,fd=9))

Ce que cela signifie : Le processus se connecte à une IP distante sur le port 443. Cela peut être normal (télémétrie, enregistrement) ou totalement inacceptable (infrastructure inconnue).

Décision : Comparez les destinations à la documentation du fournisseur et à votre allowlist. Un egress inconnu = « bloquer et enquêter ».

Tâche 17 : Vérifier le RPATH/RUNPATH embarqué d’un binaire ELF

cr0x@server:~$ readelf -d ./agent/bin/agentd | egrep -i 'rpath|runpath' || true
0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib]

Ce que cela signifie : Le binaire préfère les libs fournies à côté ($ORIGIN). C’est courant pour les applications fournisseurs.

Décision : Si RUNPATH pointe vers des répertoires inscriptibles ou inattendus (comme /tmp), c’est un vecteur classique de hijack. Considérez‑le comme suspect.

Tâche 18 : Vérifier le digest d’une image conteneur et la provenance de base (exemple Docker)

cr0x@server:~$ docker pull vendor/agent:2.3.1
2.3.1: Pulling from vendor/agent
Digest: sha256:4c1e9c2b3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f7081920ab
Status: Image is up to date for vendor/agent:2.3.1

Ce que cela signifie : Vous avez un digest de contenu. Pinner les déploiements par digest empêche les changements surprises sous un tag mutable.

Décision : Si vos manifests de production utilisent des tags sans digest, corrigez cela. Les tags mutables permettent de « vérifier » quelque chose lundi et d’exécuter autre chose mardi.

Playbook de diagnostic rapide

Ceci est la séquence « j’ai 15 minutes et un mauvais pressentiment ». Elle est optimisée pour attraper rapidement les catastrophes communes : binaires échangés, identités usurpées, canaux compromis et « c’est en fait un exécutable ».

Première étape : identifier ce que vous avez en main (format + origine)

1. Vérifiez le type de fichier : file sur Unix, Propriétés sur Windows, codesign sur macOS. Si le type ne correspond pas à l’histoire, vous avez terminé.
2. Vérifiez d’où il vient : dépôt de paquets vs téléchargement ad‑hoc vs pièce jointe d’e‑mail. « Pièce jointe d’e‑mail contenant un installateur » n’est pas un canal ; c’est un symptôme.
3. Vérifiez s’il est signé : Authenticode / codesign / GPG selon le type d’artefact. Les installateurs privilégiés non signés vont directement en zone de pénalité.

Deuxième étape : valider intégrité et authenticité

1. Hash‑ez le fichier : SHA‑256/512.
2. Validez le hash contre une source de confiance : idéalement un manifeste de checksum signé, pas un extrait de page Web.
3. Validez l’identité du signataire : le sujet du certificat / l’empreinte de la clé correspond‑elle à ce que votre organisation attend ?

Troisième étape : rechercher des signaux de risque peu coûteux (statique + réputation)

1. Scannez : AV local ou service interne de scanning. Servez‑vous‑en pour attraper du connu‑malveillant.
2. Inspectez le contenu de l’archive : listez les fichiers, cherchez scripts et mécanismes de persistance.
3. Strings + vérification des dépendances : triage rapide pour points de terminaison suspects, exécution de shells ou chargeurs étranges.

Quatrième étape : exécution contrôlée (uniquement si nécessaire)

1. Exécutez en sandbox / VM / unité contrainte : sans identifiants, réseau limité, journaux activés.
2. Surveillez l’egress : destinations, TLS SNI, requêtes DNS. Les malwares bavardent ; les applis légitimes « très télémétriques » aussi. Traitez les deux comme des décisions de politique.
3. Décidez de la portée du déploiement : canary d’abord. Toujours.

Si vous ne pouvez pas faire fiablement les étapes 1–3, ne prétendez pas que l’étape 4 est un « test sûr ». C’est juste jouer à chicken avec vos endpoints.

Trois mini‑histoires d’entreprise depuis le terrain

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Une équipe avait besoin d’un « patch d’urgence » d’un fournisseur pour un service critique. L’ingénieur support du fournisseur a envoyé un lien de téléchargement direct et un checksum dans le même fil d’e‑mail. L’ingénieur d’astreinte a suivi le runbook : vérifié le hash — puis l’a déployé pendant une fenêtre de maintenance.

Le patch s’est installé proprement. Puis des hôtes ont commencé à établir des connexions sortantes vers un domaine inconnu. Les logs d’egress se sont enflammés comme une démo de dashboard. L’équipe a supposé qu’il s’agissait du mécanisme de licence du fournisseur et a laissé faire pendant quelques heures en ouvrant un ticket.

Ce n’était pas la licence. Quelqu’un avait compromis la boîte mail de l’ingénieur support, remplacé le lien par un installateur trojanisé et inclus le checksum correspondant. L’étape de vérification du hash s’est exécutée à la perfection et n’a apporté strictement aucune sécurité parce que le checksum n’était pas ancré à un canal de confiance.

La contention a été simple — bloquer l’egress, faire tourner les identifiants, reconstruire les hôtes impactés — mais le suivi a été le vrai travail. Le runbook a été mis à jour pour exiger un manifeste de checksum signé ou un paquet depuis un dépôt, et pour considérer « checksum dans le même canal que le binaire » comme non fiable par défaut.

Le plus dur n’était pas le malware. C’était l’habitude humaine : « un checksum signifie que c’est bon ». Cette hypothèse est la façon dont on se fait posséder poliment.

Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux

Une équipe sécurité a introduit un scanning centralisé des téléchargements. Bonne idée. Ils l’ont aussi optimisé : au lieu de scanner chaque fichier, ils ne scannaient que les « nouveaux hachs ». Si le SHA‑256 avait déjà été vu, il était considéré comme préalablement nettoyé et autorisé.

Puis l’organisation s’est standardisée sur un installateur « thin wrapper » qui récupérait des composants depuis Internet à l’exécution. Le wrapper gardait un hash stable, donc le scanner le laissait passer. La charge utile qu’il récupérait changeait régulièrement. Parfois légitimement. Parfois non.

Pendant une coupure réseau, le wrapper est tombé sur un endpoint CDN secondaire qui n’était pas sur l’allowlist, et a récupéré un composant compromis. Le wrapper était « vérifié » et « déjà scanné », donc il a traversé les flottes. Les octets malveillants n’ont jamais été scannés car ils n’étaient pas présents sur disque au moment du scan.

La correction n’a pas été « scanner plus fort ». C’était architectural : interdire les installateurs qui fetchent du code non signé à l’exécution, exiger des digests épinglés pour les composants récupérés et surveiller les fetchs réseau pendant l’installation. Aussi : scanner le contenu décompressé/extrait, pas seulement le fichier conteneur.

L’optimisation est acceptable. Optimiser la mauvaise invariant est la façon de bâtir une voie rapide pour le mauvais.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe plateforme gérait un dépôt d’artefacts interne et exigeait que tout ce qui était déployé en production soit promu depuis un dépôt staging par digest. Chaque build produisait des artefacts immuables ; les déploiements faisaient référence à des digests, pas à des tags. Les équipes se plaignaient que c’était « lent » et « bureaucratique ».

Un jour, un tag de conteneur fournisseur a été remplacé silencieusement en amont. Même tag, nouveaux octets. Si vous tiriez par tag, vous obteniez ce que le registre servait ce jour‑là. Certaines équipes hors plateforme l’ont pullé directement. Leurs canaris ont immédiatement eu un comportement différent : nouveaux processus, nouvelles connexions sortantes, nouveaux appels système.

Les services gérés par la plateforme n’ont pas changé du tout. Ils étaient épinglés par digest et le miroir interne servait les octets déjà approuvés. L’équipe plateforme a remarqué le décalage amont lors d’une validation de synchronisation de routine : le tag mappait maintenant à un digest différent d’hier.

Résultat : incident contenu à un petit rayon d’impact. La discipline ennuyeuse — épinglage par digest, promotion interne et canaries — a transformé une surprise de la chaîne d’approvisionnement en une nuisance mineure plutôt qu’en compromission de flotte.

Les contrôles de sécurité qui fonctionnent ressemblent souvent à de la paperasserie fastidieuse, jusqu’au jour où ils vous sauvent.

Erreurs courantes (symptômes → cause → correctif)

Erreur 1 : « Le hash correspond, donc c’est sûr »

Symptômes : Vous avez vérifié une somme et avez quand même observé un comportement suspect, ou vous avez appris ultérieurement que le téléchargement était compromis.

Cause : Le checksum n’était pas ancré à la confiance. L’attaquant contrôlait à la fois le fichier et le checksum (même site, même e‑mail, même dépôt compromis).

Correctif : Exigez des signatures sur les manifestes de checksum, des empreintes GPG épinglées, ou la vérification des métadonnées du dépôt. Politique : « hash sans signature = intégrité uniquement ».

Erreur 2 : « Signé signifie digne de confiance »

Symptômes : Le fichier est signé, mais les outils de sécurité le signalent ; ou vous constatez qu’il est signé par un éditeur inattendu.

Cause : Mauvaise compréhension de ce que les signatures attestent. Une signature lie les octets à une clé, pas la moralité à une organisation. Les clés peuvent être volées ; les certificats peuvent être émis de façon frauduleuse.

Correctif : Appliquez des allowlists de signataires (sujet attendu, EKU attendu, chaîne attendue), vérifiez la révocation quand c’est possible et exigez l’horodatage pour les artefacts longue durée.

Erreur 3 : Faire confiance aux tags mutables et à « latest »

Symptômes : « On a vérifié l’image la semaine dernière » mais le comportement en prod a changé sans changement de code.

Cause : Les tags sont des pointeurs, pas des identités. En amont on peut retagger intentionnellement ou par erreur ; les registres peuvent être compromis.

Correctif : Déployez par digest. Miroir et promouvez les artefacts en interne. Traitez tout changement de mapping tag→digest comme une alerte.

Erreur 4 : Scanner les archives mais pas leur contenu extrait

Symptômes : L’AV dit que l’archive est propre ; après extraction, quelque chose déclenche l’EDR ou des scripts suspects apparaissent.

Cause : Les scanners sautent parfois l’inspection profonde (archives imbriquées, zip chiffrés, tarballs gigantesques). Ou la politique exclut les « non‑exécutables ».

Correctif : Extrayez dans un répertoire contrôlé et scannez l’arborescence extraite. Bloquez les archives chiffrées sauf exception métier explicite.

Erreur 5 : « On ne peut pas vérifier la révocation ; le réseau bloque »

Symptômes : Les signatures s’affichent « Valid » mais plus tard vous découvrez que le certificat avait été révoqué depuis des mois.

Cause : Les clients tolèrent l’échec des vérifications OCSP/CRL, ou l’accès sortant est bloqué. Beaucoup d’environnements choisissent involontairement « disponibilité plutôt que sécurité » ici.

Correctif : Centralisez la vérification dans une zone réseau qui peut atteindre les endpoints de révocation, ou utilisez le stapling quand c’est applicable. Au minimum, journalisez le contexte de vérification et traitez un statut de révocation inconnu comme un risque.

Erreur 6 : Exécuter « juste pour voir » sur une station avec des identifiants

Symptômes : Indicateurs de vol d’identifiants, nouvelles extensions de navigateur, tokens d’accès suspects, mouvement latéral.

Cause : Tester du code non fiable sur un appareil qui a des accès. C’est ainsi que le malware devient incident plutôt qu’une curiosité.

Correctif : Utilisez des VM isolées sans secrets, sans sessions SSO, et avec réseau contrôlé. Envisagez des hôtes d’analyse jetables.

Erreur 7 : Confondre « inconnu » avec « sûr » dans les systèmes de réputation

Symptômes : Un fichier n’est pas trouvé dans les listes known‑bad, donc il est approuvé. Plus tard il est malveillant.

Cause : Les systèmes de réputation sont clairsemés et retardés par conception. Les nouveaux malwares et charges ciblées n’ont souvent aucun hit public.

Correctif : Combinez réputation, provenance et signatures. Pour les logiciels privilégiés, exigez des métadonnées de release signées par le fournisseur et des workflows d’approbation internes.

Listes de contrôle / plan étape par étape

Checklist A : Vérifier un installateur ponctuel que vous n’avez pas construit

1. Enregistrez l’origine : qui l’a demandé, d’où il provient, quand vous l’avez récupéré et le chemin de transport (portail, e‑mail, pièce jointe de ticket).
2. Identifiez le type de fichier : file / Authenticode / codesign. Si mismatch, quarantaine.
3. Calculez SHA‑256 : conservez‑le dans votre ticket. Les hachages sont utiles pour la forensique même quand ils ne prouvent pas la sécurité.
4. Trouvez une source d’intégrité signée : SHA256SUMS signé GPG, dépôt OS, ou bundle d’application notarisé/signé.
5. Validez l’identité du signataire : empreinte ou sujet du certificat doit correspondre à votre allowlist, pas seulement « ça a l’air légitime ».
6. Scannez le fichier et son contenu extrait : considérez « OK » comme « aucun hit connu », pas comme approbation.
7. Triage statique : strings, dépendances, liste d’archive, scripts embarqués.
8. Exécution en sandbox : pas d’identifiants, réseau limité, observez processus et connexions.
9. Déploiement : canary d’abord, puis progression. Surveillez l’egress et la télémétrie des endpoints pour tout nouveau comportement.

Checklist B : Construire un pipeline interne d’« artefacts de confiance » (les choses ennuyeuses qui fonctionnent)

1. Faire respecter des IDs d’artefacts immuables : digest ou stockage adressé par contenu. Aucun « latest » mutable.
2. Centraliser l’ingestion d’artefacts : les téléchargements passent par un proxy/dépôt interne qui journalise et scanne.
3. Exiger des signatures : signatures fournisseur pour les artefacts tiers ; signature interne pour vos builds.
4. Épingler les racines de confiance : empreintes de clés fournisseurs connues, sujets de certificats attendus et clés de dépôt dans la gestion de configuration.
5. Stocker les métadonnées de provenance : infos de build, références SBOM (si disponibles), qui a approuvé et quels tests ont été exécutés.
6. Promouvoir, ne pas puller : la production ne pull que depuis votre dépôt « promu » interne.
7. Alerter sur la dérive : si le mapping tag→digest en amont change, traitez‑le comme un événement de chaîne d’approvisionnement.
8. Répéter la révocation : ayez un processus pour retirer une clé/certificat de la confiance et pour mettre rapidement en quarantaine des artefacts.

Checklist C : Ce qu’il faut journaliser pour que le futur‑vous puisse expliquer ce qui s’est passé

• Hash de l’artefact (SHA‑256) et taille
• Sortie de vérification de signature (y compris identité du signataire et statut de confiance)
• Canal source (nom du dépôt, portail, ID de ticket)
• Résultats de scan (version du moteur, horodatage des définitions)
• Notes de sandbox : destinations sortantes, processus lancés, écritures de fichiers
• Approbations de promotion et portée du déploiement

Si votre vérification n’est pas journalisée, elle n’a pas eu lieu. Ou pire : elle a eu lieu et vous ne pouvez pas le prouver, ce qui, en entreprise, équivaut à « ça ne s’est pas passé ».

FAQ

1) Si le SHA‑256 correspond au checksum publié par le fournisseur, suis‑je en sécurité ?

Vous êtes cohérent avec ce que le fournisseur (ou l’attaquant) a publié. Vous êtes plus en sécurité seulement si le checksum est délivré via un mécanisme de confiance : manifeste signé, dépôt de paquets de confiance ou canal authentifié séparé.

2) Pourquoi ne pas simplement utiliser VirusTotal ou un scanner en ligne ?

Dans les environnements d’entreprise, téléverser des binaires peut violer la politique et divulguer des logiciels propriétaires. De plus, « aucune détection » n’est pas une assurance. Utilisez le scanning interne et le sandboxing, et considérez la réputation externe comme un input optionnel quand c’est permis.

3) Quel hash devrais‑je utiliser aujourd’hui ?

SHA‑256 est la baseline. SHA‑512 est également acceptable. Évitez MD5 et SHA‑1 pour les décisions de sécurité ; ils restent utiles pour la déduplication non adversariale, pas pour la résistance à la falsification.

4) Quelle est la différence entre un fichier de checksum et un fichier de signature ?

Un fichier de checksum (comme SHA256SUMS) liste des hachages. Un fichier de signature (comme SHA256SUMS.asc) prouve qu’une clé particulière a signé cette liste de checksums. La signature est ce qui transforme une liste de checksums en quelque chose de potentiellement fiable — si vous faites confiance à la clé.

5) Une signature GPG indique « Good signature » mais la clé est « [unknown] ». Est‑ce mauvais ?

Cela signifie que votre modèle de confiance local n’a pas établi que vous faites confiance à cette clé. Cryptographiquement elle correspond, mais opérationnellement vous n’avez pas validé que la clé appartient bien à qui vous croyez. Épinglez l’empreinte via la politique de confiance de votre org.

6) Le fichier est signé, mais Windows SmartScreen avertit encore. Que faire ?

SmartScreen se base sur la réputation ; les binaires nouveaux ou rarement téléchargés peuvent provoquer un avertissement même s’ils sont signés. Vérifiez l’identité du signataire, validez le canal de téléchargement et testez en sandbox. Ne passez pas outre les avertissements sur des endpoints de production par impatience.

7) Un malware peut‑il être signé avec un certificat légitime ?

Oui. Les certificats peuvent être volés, obtenus frauduleusement ou délivrés à des entités prête‑nom. C’est pourquoi vous avez besoin d’allowlists de signataires et de contrôles de comportement/provenance.

8) Comment vérifier qu’une image conteneur « n’est pas un malware » ?

Commencez par épingler par digest et vérifier la signature/métadonnées de provenance si votre écosystème le supporte. Ensuite scannez les couches, inspectez le Dockerfile/le comportement de l’entrypoint et exécutez‑la dans un namespace sandbox avec surveillance de l’egress.

9) Ai‑je vraiment besoin de sandboxing si les signatures sont valides ?

Pour les installateurs et agents privilégiés : oui. Les signatures réduisent le risque d’usurpation, mais ne détectent pas un fournisseur compromis ou des mises à jour malveillantes. Le sandboxing attrape des comportements que vous n’accepteriez pas (egress inattendu, persistance, accès aux identifiants).

10) Quel est le contrôle de politique le plus efficace ?

Déployer uniquement depuis un dépôt d’artefacts interne promu avec épinglage par digest et vérifications forcées de signature/provenance. C’est peu glamour. Ça fonctionne aussi.

Conclusion : étapes pratiques suivantes

Si vous voulez qu’un fichier soit « pas un malware », ne discutez pas la philosophie. Construisez un pipeline qui rend difficile l’introduction d’artefacts trojanisés et facile leur détection.

1. Cessez de faire confiance aux checksums bruts. Exigez des manifestes signés ou la vérification via dépôt.
2. Épinglez les identités. Empreintes de clés fournisseurs, sujets de certificats attendus et clés de dépôt appartiennent à la gestion de configuration, pas à la mémoire des gens.
3. Déployez par digest. Les tags sont pour les humains ; les digests sont pour les systèmes qui n’aiment pas les surprises.
4. Sandboxez tout ce qui est privilégié. Installateurs, agents, modules noyau, clients VPN — testez comme si vous attendiez une trahison.
5. Journalisez les preuves de vérification. Hachages, sorties de signature, résultats de scan et approbations. Quand quelque chose tourne mal, il faudra que l’histoire soit écrite par les logs, pas par des impressions.

Le but n’est pas la certitude parfaite. Le but est que lorsque vous exécutez un fichier, vous puissiez expliquer exactement pourquoi vous lui avez fait confiance — et ce qui vous aurait fait arrêter.