Spyre

...un scanner d'IOC modulaire, autonome et simple, basé sur l'hôte

Spyre est un scanner d'IOC basé sur l'hôte, simple, construit autour du moteur de correspondance de motifs YARA et d'autres modules de scan. L'objectif principal de ce projet est de faciliter l'opérationnalisation des règles YARA et autres indicateurs de compromission.

Les utilisateurs doivent fournir leurs propres ensembles de règles. Le dépôt awesome-yara donne un bon aperçu des ensembles de règles YARA gratuits disponibles.

Spyre est conçu pour être utilisé comme outil d'investigation par les répondants aux incidents. Il n'est pas destiné à évoluer vers un service de protection des endpoints.

Pour commencer

Utiliser Spyre est simple :

1. Ajoutez des signatures YARA. Dans sa configuration par défaut, Spyre lira les règles YARA pour l'analyse des fichiers et des processus depuis filescan.yar et procscan.yar, respectivement. Les options suivantes existent pour fournir des fichiers de règles à Spyre (et seront essayées dans cet ordre) :

   1. Ajoutez les fichiers de règles dans un fichier ZIP et concaténez ce fichier ZIP au binaire.
   2. Ajoutez les fichiers de règles dans un fichier ZIP dont le nom de base est identique au nom de base du binaire du scanner, c'est-à-dire si le binaire Spyre s'appelle spyre ou spyre.exe, utilisez spyre.zip.
   3. Placez les fichiers de règles et le binaire du scanner dans le même répertoire.

   Le contenu du fichier ZIP peut être chiffré avec le mot de passe infected (standard de l'industrie antivirale) pour empêcher les logiciels antivirus d'analyser l'ensemble de règles, de le classer comme contenu malveillant et d'empêcher l'analyse.

   Les fichiers de règles YARA peuvent contenir des instructions include.

2. Déployez, exécutez le scanner

3. Collectez le rapport et les preuves

Configuration

La configuration au moment de l'exécution se fait via un fichier optionnel spyre.yaml.

Si un fichier ZIP a été concaténé au binaire Spyre, la configuration et les autres fichiers tels que les règles YARA sont lus uniquement depuis ce fichier ZIP. Sinon, ils sont lus depuis le répertoire dans lequel le binaire a été placé.

Voir le sous-répertoire example-configuration/ pour un exemple.

Configuration globale

• hostname / commutateur de ligne de commande --set-hostname : Définissez explicitement le nom d'hôte qui sera utilisé dans le fichier journal et dans le rapport. Cela n'est généralement pas nécessaire.

• max-file-size / commutateur --max-file-size : Taille maximale pour les fichiers à analyser avec des modules d'analyse de fichiers coûteux tels que YARA. Par défaut : 32 Mo

• proc-ignore-names / commutateur --proc-ignore : Noms des processus qui ne seront pas analysés avec les modules d'analyse de la mémoire des processus.

• paths / commutateur --path : Chemins à analyser avec les modules d'analyse de fichiers. Par défaut : / (Unix) ou tous les lecteurs fixes (Windows).

• report / commutateur --report : Définissez une ou plusieurs cibles de rapport. Par défaut : spyre_${hostname}_${time}.log dans le répertoire de travail courant, en utilisant le format simple. Un format de sortie différent peut être spécifié en ajoutant .

Configuration spécifique aux modules

Il existe actuellement trois domaines pour lesquels des modules d'analyse peuvent être implémentés : les vérifications au niveau système, les analyses de fichiers et les analyses de processus.

Vous trouverez ci-dessous les modules actuellement implémentés et les paramètres de configuration pris en charge.

• system
  • eventobj (Windows)
    • iocs
  • registry (Windows)
    • iocs
  • winkernelobj (Windows)
    • iocs
    • conficker, booléen : Les IOCs Conficker dynamiques (basés sur l'hôte/processus) doivent-ils être ajoutés à la liste des IOCs ? (Par défaut : false)
  • findwindow (Windows)
    • iocs
• file
  • yara
    • rule-files

Veuillez vous référer au fichier de configuration exemple example-spyre.yaml pour des conseils sur la façon de décrire les indicateurs de compromission pour chaque module.

Remarques sur les règles YARA

YARA est configuré avec les paramètres par défaut, plus les options explicites suivantes (cf. 3rdparty.mk) :

• --disable-magic
• --disable-cuckoo
• --enable-dotnet
• --enable-macho
• --enable-dex

Pour les analyses de fichiers, les variables suivantes sont définies :

• filename,
• filepath,
• extension,
• filetype (non actuellement renseignée lors de l'analyse)

Pour les analyses de processus, les variables pid et executable sont définies.

La métavariable spyre_collect_limit peut être utilisée pour limiter le nombre d'écritures collectées à partir des fichiers correspondants ou pour empêcher complètement la collecte de fichiers. Cela peut être utile pour limiter la taille des paquets de preuves et éviter de collecter des informations sensibles.

Construction

Spyre peut être construit pour les cibles Linux et Windows 32 bits et 64 bits.

Debian Buster (10.x) et versions ultérieures

Sur un système Debian/buster (ou un chroot) sur lequel les paquets suivants ont été installés :

• make
• gcc
• gcc-multilib
• gcc-mingw-w64
• autoconf
• automake
• libtool
• pkg-config
• wget
• patch
• sed
• golang-$VERSION-go, par ex. golang-1.8-go. Le Makefile sélectionnera automatiquement la version la plus récente à moins que GOROOT ne soit défini.
• git-core
• ca-certificates
• zip

Ceci décrit l'environnement de construction qui est régulièrement utilisé via CI.

Fedora 30 et versions ultérieures

La même construction a également été essayée avec succès sur Fedora 30 avec les paquets suivants installés :

• make
• gcc
• mingw{32,64}-gcc
• mingw{32,64}-winpthreads-static
• autoconf
• automake
• libtool
• pkgconf-pkg-config
• wget
• patch
• sed
• golang
• git-core
• ca-certificates
• zip

Une fois que tout est installé, tapez simplement make. Cela devrait télécharger les archives pour musl-libc, openssl, yara, les construire, puis construire spyre.

Les binaires spyre nus sont créés dans _build/<triplet>/.

Exécuter make release crée un fichier ZIP qui contient ces binaires pour toutes les architectures prises en charge.

Génération de binaires compatibles avec les anciens Windows XP, Windows Server 2003

La compatibilité avec ces systèmes a été supprimée avec Go 1.11, donc une chaîne d'outils Go 1.10 est nécessaire. Comme Go 1.10 ne prend pas en charge les modules Go, les dépendances Go tierces doivent être placées dans le répertoire vendor (via go vendor). Utilisez une version plus récente de Go pour cela (exécutez simplement go vendor) et définissez GOROOT pour pointer vers la chaîne d'outils Go 1.10 avant d'exécuter make.

MacOSX

Actuellement, la compilation croisée n'est pas prise en charge.

• GCC depuis Xcode
• Dépendances de construction depuis Homebrew :
  • gnu-make
  • autoconf
  • automake
  • libtool
  • pkg-config
  • wget
  • gpatch
  • gnu-sed
  • gnu-tar
  • go
  • git
  • ca-certificates
  • zip

Le make fourni par le système est trop ancien car Apple a décidé d'être allergique à la GPLv3. gmake de Homebrew fonctionne bien.

Codage

Voir HACKING.md

Copyright

Copyright 2018-2020 DCSO Deutsche Cyber-Sicherheitsorganisation GmbH

Copyright 2020-2021 Spyre Project Authors (voir : AUTHORS.txt)

Licence

Ce programme est un logiciel libre : vous pouvez le redistribuer et/ou le modifier selon les termes de la GNU Lesser General Public License telle que publiée par la Free Software Foundation, soit la version 3 de la Licence, soit (à votre choix) toute version ultérieure.

Voir le fichier LICENSE pour le texte complet de la licence.