Boup

Identifier un binaire système avec hashlookup.circl.lu

TL;DR

Outil de triage, pas de détection. Sert à confirmer qu’un binaire est un fichier système/logiciel connu, pour réduire le volume à analyser à la main. L’absence de la base peut entraîner des vérifications complémentaires mais n’est pas une conclusion en soit sur la légitimité du binaire. Pour tester un binaire : https://hashlookup.circl.lu/lookup/sha256/<hash>

Contexte

Lors d’une investigation ou d’une analyse forensique, une des premières questions à trancher face à un binaire suspect est simple : s’agit-il d’un fichier du système d’exploitation, d’un paquet logiciel connu, ou d’un artefact qui mérite une analyse approfondie ?

Recalculer et comparer manuellement des hashes n’est pas réaliste à l’échelle d’une investigation, surtout quand il faut trier rapidement des dizaines ou des centaines de fichiers. C’est le rôle des bases de hash de référence : elles permettent de filtrer en priorité le “bruit” (binaires connus, sains) pour concentrer l’analyse sur ce qui ne l’est pas.

Le service hashlookup du CIRCL (Computer Incident Response Center Luxembourg) répond à ce besoin via une API publique.

Le service

Documentation officielle : https://www.circl.lu/services/hashlookup/

hashlookup est une API REST publique qui permet de vérifier si un hash de fichier est déjà référencé dans un ensemble de bases connues. Elle intègre notamment la base NSRL du NIST ainsi que plusieurs autres sources. Le service est gratuit et documenté via un Swagger OpenAPI.

Ce que fait le service : indiquer si un hash correspond à un fichier déjà répertorié dans une base de référence, et donner le contexte associé (nom du fichier, produit, système d’exploitation, taille, etc.).

Ce que le service ne fait pas : juger si un fichier est malveillant ou non. hashlookup n’est ni une base de malwares ni un antivirus. Un résultat positif confirme qu’un fichier est connu et donne du contexte, un résultat négatif ne prouve rien en soi.

Point d’attention important

L’absence d’un hash dans la base ne signifie pas que le binaire a été modifié ou est suspect. Beaucoup de fichiers légitimes ne sont tout simplement pas répertoriés. Par exemple, le hash du binaire ls sur macOS n’est, à date, pas connu du service.

Autrement dit : hashlookup permet d’éliminer rapidement les faux positifs (fichiers connus et légitimes), mais une absence de résultat ne doit jamais être interprétée comme un indicateur de compromission à elle seule. Elle doit simplement déclencher une analyse plus approfondie.

Sources intégrées

  • Builds courants de Windows 10 et Windows 11 (français, néerlandais, allemand, UK, US)
  • NIST NSRL : l’ensemble des hash sets RDS (Reference Data Sets) (current, modern, android, iOS, legacy)
  • Paquets Ubuntu, CentOS core OS, dépôt EPEL Fedor, Kali Linux, OpenSUSE, tar.gz d’OpenBSD, scripts CDNJS et dépôt public Snap.

Qu’est-ce que la NSRL ?

NSRL désigne la base de logiciels connus maintenue par le NIST : la National Software Reference Library. Plus d’informations sur le site du NIST : https://www.nist.gov/itl/ssd/software-quality-group/national-software-reference-library-nsrl

Utilisation de l’API

Documentation Swagger : https://hashlookup.circl.lu/

La casse du hash (majuscules ou minuscules) n’a pas d’importance dans les URL de requête présentées ci-dessous.

L’API accepte trois types de hash : SHA-256, SHA-1 et MD5. Les exemples suivants portent tous sur le même binaire, malloc2.exe, interrogé via ses trois hashes respectifs.

Requête par SHA-256

https://hashlookup.circl.lu/lookup/sha256/c16ab09b4923b268dc8ef235b6dec49e1ecfd4feb25ded1138f00fda8b15f37f
{
  "CRC32": "4A0D3F19",
  "FileName": "malloc2.exe",
  "FileSize": "9216",
  "MD5": "DE8F65B9DE9B6C92CFD99155B6DDB635",
  "OpSystemCode": {
    "MfgCode": "1006",
    "OpSystemCode": "362",
    "OpSystemName": "TBD",
    "OpSystemVersion": "none"
  },
  "ProductCode": {
    "ApplicationType": "Development Platform",
    "Language": "English",
    "MfgCode": "608",
    "OpSystemCode": "189",
    "ProductCode": "16402",
    "ProductName": "Microsoft Developer Network Development Platform - U.S.",
    "ProductVersion": "March 1997"
  },
  "RDS:package_id": "16402",
  "SHA-1": "F0FC35E58CEFFB1B6FF5732E5B3601AC0B1A10D3",
  "SHA-256": "C16AB09B4923B268DC8EF235B6DEC49E1ECFD4FEB25DED1138F00FDA8B15F37F",
  "SpecialCode": "",
  "db": "nsrl_legacy",
  "insert-timestamp": "1648622685.5923274",
  "source": "RDS_2022.03.1_legacy.db",
  "hashlookup:trust": 50
}

Requête par SHA-1

https://hashlookup.circl.lu/lookup/sha1/F0FC35E58CEFFB1B6FF5732E5B3601AC0B1A10D3

Retourne le même enregistrement que la requête SHA-256 ci-dessus.

Requête par MD5

https://hashlookup.circl.lu/lookup/md5/DE8F65B9DE9B6C92CFD99155B6DDB635

Retourne également le même enregistrement.

Lecture du retour de l’API

Les champs suivants sont particulièrement intéréssasnts :

  • db et source : indiquent de quelle base de référence provient l’entrée (ici nsrl_legacy), utile pour évaluer la fiabilité et l’ancienneté de la donnée
  • ProductCode et OpSystemCode : donnent le contexte d’origine du fichier (éditeur, produit, système cible)
  • hashlookup:trust : score de confiance associé à l’entrée, 50 = pas d’opinon particulère du CIRCL, 50< niveau de confiance faible, >50 provient de multiples sources, voir hashlookup/#hashlookup-trust.

Ces éléments permettent de documenter rapidement pourquoi un fichier a été écarté du périmètre d’analyse, ce qui est utile pour la traçabilité d’une investigation.

Pour conclure

hashlookup.circl.lu est un outil de triage, pas un outil de détection. Il sert à confirmer qu’un binaire correspond à un fichier système ou logiciel connu afin de réduire le volume de fichiers à analyser manuellement. Un hash absent de la base peut entraîner des vérifications complémentaires mais n’est pas une conclusion en soit sur la légitimité du binaire.