Lorsqu’un équipement périmétrique Ivanti est compromis, l’exécution de commandes directement sur le shell en direct (live) est fortement restreinte et forensiquement risquée. Les acteurs de la menace modifient fréquemment les binaires intégrés (comme ls ou ps) via des rootkits pour dissimuler leur présence.
La procédure DFIR standard exige l’acquisition d’une image disque complète ou d’une extraction de fichiers exhaustive (ex: via une cible KAPE personnalisée) et son montage sur une station de travail forensique Linux isolée. Tout au long de ce guide, nous supposerons que le système de fichiers racine de l’appliance Ivanti compromise est monté sur /mnt/analyse/.
2. Sous le capot : architecture héritée vs moderne
L’architecture logicielle d’Ivanti a évolué. L’identification de la génération du système d’exploitation sous-jacent est critique, car elle dicte les chemins des fichiers et les capacités de persistance de l’attaquant.
Architecture héritée (Legacy)
Cibles : les versions 9.x et 22.x d’Ivanti Connect Secure (ICS), ainsi que la plupart des anciens déploiements EPMM.
Base : un noyau Linux vieillissant, souvent basé sur un CentOS 6 fortement personnalisé ou un Linux 2.6.
Posture de sécurité : le système de fichiers racine est monté en lecture seule (Read-Only) par défaut pour empêcher toute falsification, mais les répertoires cruciaux (/var, /tmp, /data) restent inscriptibles. Il est dépourvu de SELinux. Cet environnement est hautement propice aux webshells Perl/CGI traditionnels.
Architecture moderne
Cibles : les nouvelles versions d’ICS (souvent commercialisées sous le nom d’ISA - Ivanti Secure Access) fonctionnant en version 25.x et ultérieures.
Base : une base d’OS moderne (probablement AlmaLinux ou RHEL récent).
Posture de sécurité : introduit SELinux en mode Enforcing. Cela modifie fondamentalement les TTPs de l’attaquant, car le dépôt de webshells dans des répertoires web arbitraires est bloqué par les politiques de contrôle d’accès obligatoire (MAC).
3. Le piège de la double partition (Active vs Rollback)
C’est l’écueil le plus critique lors d’une analyse de disque hors ligne. Pour faciliter les mises à jour de firmware sans risque, les appliances Ivanti utilisent un système à double partition (souvent appelé “Slot 1” et “Slot 2”).
La partition active : le système qui était en cours d’exécution au moment de l’acquisition.
La partition inactive (Rollback) : la version précédente du firmware, conservée en tant que sauvegarde.
Pour déterminer quelle partition exécutait activement l’OS compromis, les analystes doivent interroger le chargeur de démarrage (bootloader) et les métadonnées du système de fichiers depuis leur station d’analyse.
Analyser le chargeur de démarrage GRUB :
vérifiez le fichier de configuration GRUB sur la partition de démarrage montée pour voir quelle entrée du menu est définie par défaut.
cat /mnt/analyse/boot/grub/grub.conf (ou grub.cfg). Cherchez la ligne default=X.
Vérification des MAC times (La sécurité infaillible) :
utilisez les horodatages du système de fichiers (MAC times). Vérifiez les dates de dernier accès (atime) ou de modification (mtime) sur des répertoires dynamiques comme /var/log à travers les deux partitions. La partition active présentera des horodatages corrélant avec l’heure de l’incident ou de l’acquisition forensique. Les horodatages de la partition inactive dateront de plusieurs mois ou années.
Pour confirmer si l’appliance était vulnérable à un zero-day spécifique (ex: CVE-2026-1281), vous ne pouvez pas deviner en vous basant sur les dates des fichiers. Vous devez extraire le numéro de build exact.
Lors de l’analyse du système de fichiers monté, les analystes DFIR doivent concentrer leurs efforts sur des points de montage virtuels et des répertoires spécifiques où les attaquants sont contraints d’opérer.
/ (Racine) : contient l’OS de base et les binaires. Souvent en lecture seule sur les versions héritées. Les attaquants n’y touchent que rarement, sauf pour déployer des rootkits avancés ou patcher des binaires CGI natifs.
/data ou /var :la zone chaude. C’est la partition inscriptible. Elle contient les journaux système, les configurations VPN (/data/system/), et constitue le point de chute principal des webshells de l’acteur de la menace (car il ne peut pas écrire ailleurs). Si votre collecte forensique (comme un triage KAPE) a manqué le répertoire /data, vous êtes complètement aveugle.
Avant d’exécuter le moindre grep ou scan YARA contre l’image montée, assurez-vous d’avoir accompli les points suivants :
Confirmer la partition :“suis-je absolument certain que c’est la partition qui était active durant la fenêtre de la compromission ?”
Noter la version : extrayez le numéro de build exact et croisez-le immédiatement avec les avis de sécurité d’Ivanti et le KEV de la CISA pour identifier les vecteurs potentiels d’accès initial.
Localiser le montage /data : vérifiez que la partition de données inscriptible a été acquise avec succès et montée correctement au sein de votre arborescence /mnt/analyse/.