Analyse d'Artefact : Logs Spécifiques Ivanti

Note

Résumé exécutif : une appliance Ivanti génère deux catégories distinctes de journaux : les logs système Linux standards (pour l’OS sous-jacent) et les logs applicatifs propriétaires (pour le service VPN/MDM). Une analyse forensique exhaustive nécessite de corréler ces deux sources pour comprendre à la fois l’exploitation initiale (couche web/application) et la persistance (couche OS). Étant donné qu’Ivanti utilise un formatage de journaux propriétaire et souvent obscur, les analystes DFIR doivent savoir exactement où chercher et comment parser les données avant de pouvoir chasser les traces d’exploitation de type zero-day.

1. Cartographie des fichiers de logs (où chasser)

L’emplacement des journaux diffère considérablement selon l’architecture spécifique du produit Ivanti. En supposant que les analystes effectuent une analyse hors ligne sur une extraction forensique montée (ex: montée dans /mnt/analyse/), voici les cibles critiques.

A. Ivanti Connect Secure (ICS / Pulse)

Les principaux journaux d’application pour ICS sont situés sur la partition de données inscriptible, spécifiquement dans /data/var/dlogs/.

Fichier de log	Valeur forensique critique
event.log	le journal système principal de l’application. Contient les démarrages de services, les erreurs internes et les actions système globales.
user_access.log	CRITIQUE. Trace les connexions VPN des utilisateurs. Détaille qui s’est connecté, quand, depuis quelle IP, et vers quel “Realm” (royaume d’authentification).
admin_access.log	CRITIQUE. Trace les authentifications sur la console d’administration web (/admin). Les analystes l’utilisent pour déterminer si un attaquant s’est connecté avec succès en utilisant des identifiants administratifs volés.
web_access.log	le journal des requêtes HTTP (similaire aux journaux d’accès Apache/Nginx). C’est le terrain de chasse principal pour l’exploitation web (ex: URI malveillantes) et les interactions avec les webshells déposés.

B. Ivanti EPMM (MobileIron)

L’architecture EPMM est plus proche d’un déploiement Linux standard (utilisant souvent Apache/Tomcat).

• Journaux Web : /var/log/httpd/ ou /var/log/apache2/ (access_log, ssl_access_log, error_log).
• Journaux d’application : /var/log/portal/ (journaux spécifiques au portail de gestion mobile).

2. Décoder le format propriétaire

Les journaux ICS ne sont pas toujours du texte clair et facile à lire. Ils peuvent comporter des délimiteurs étranges, des en-têtes binaires propriétaires, ou être compressés lors du processus d’exportation.

L’outil : Ivanti-Connect-Secure-Logs-Parser (Hexastrike) Pour analyser efficacement ces fichiers, les équipes DFIR s’appuient sur des parseurs communautaires pour nettoyer les données brutes.

• Fonction : il ingère les fichiers de logs bruts d’Ivanti et les convertit en formats structurés CSV ou JSON.
• Utilité : cela permet aux analystes d’importer les données dans un tableur ou un SIEM (ELK, Splunk) pour une génération rapide de la chronologie (timeline) et un filtrage par IP.

parse_ivanti_logs.sh

# Exemple d'utilisation du parseur Hexastrike sur une extraction ICS montée
python3 ivanti_parser.py -f /mnt/analyse/data/var/dlogs/user_access.log -o /tmp/parsed_user_access.csv

3. Threat Hunting : signatures d’attaque

Les analystes doivent rechercher les indicateurs spécifiques suivants au sein des fichiers de logs parsés.

A. Exploitation Web (web_access.log)

Recherchez des requêtes GET ou POST ciblant des fichiers qui ne devraient pas exister ou qui sont des indicateurs connus de CVE spécifiques.

• Webshells : recherchez des requêtes ciblant des fichiers .jsp, .php, .sh ou .pl (Perl) cachés dans des répertoires d’images ou de scripts.
• CVE-2023-46805 (Bypass Auth) : traquez les requêtes ciblant /api/v1/totp/user-backup-code/../../system/maintenance/archiving/cloud-server-test-connection.
• Suspicion générale : toute requête HTTP renvoyant un code d’état 200 (OK) sur un chemin très inhabituel ou comportant des séquences de traversée de répertoire (../ ou %2E%2E%2F).

B. Administrateurs malveillants (admin_access.log)

• L’admin inconnu : une connexion réussie au panneau d’administration depuis une adresse IP n’appartenant pas au personnel informatique légitime (ex: VPN commerciaux, nœuds de sortie Tor ou pays étrangers).
• Le compte fantôme : des journaux indiquant la création d’un nouveau compte administrateur local immédiatement après une requête web suspecte confirment une compromission totale du système.

C. Anomalies VPN (user_access.log)

• Credential Stuffing : des milliers d’échecs de connexion pour différents noms d’utilisateurs provenant d’une seule adresse IP.
• Détournement de session (Session Hijacking) : une session VPN unique qui change soudainement d’IP source en cours de route, ou un utilisateur se connectant simultanément depuis deux pays géographiquement éloignés (“Voyage impossible”).

4. Corrélation avec les journaux Linux standards

Même si l’appliance exécute des logiciels propriétaires, l’OS sous-jacent reste Linux. Une fois qu’un attaquant a exploité la couche web, il se retrouve dans un environnement shell Linux standard.

Journaux d'authentification (/var/log/secure)

Les attaquants activent ou manipulent souvent SSH pour établir une porte dérobée. Recherchez des connexions SSH réussies (Accepted password ou Accepted publickey) pour root ou admin. Sur une appliance Ivanti, le SSH est rarement exposé à Internet, ce qui fait d’une connexion SSH externe une alerte critique. (Voir Analyse des journaux d’authentification Linux).

Journaux Cron (/var/log/cron)

L’attaquant a-t-il créé une tâche planifiée pour assurer sa persistance ? Examinez les journaux cron pour identifier l’exécution de scripts inconnus à intervalles réguliers. (Voir Persistance héritée Linux).

5. Requêtes de Threat Hunting exploitables

Splunk (Exploitation Web)

hunt_ivanti_directory_traversal.spl

# Chasse aux traversées de répertoire et accès aux webshells dans les logs web_access.log parsés
index=ivanti_logs sourcetype=ivanti:web_access
| search uri_path="*../*" OR uri_path="*..%2F*" OR uri_path="*.jsp" OR uri_path="*.pl"
| table _time, src_ip, http_method, uri_path, status, bytes
| sort - _time

KQL (Anomalies VPN)

hunt_ivanti_vpn_anomalies.kql

// Concept : Chasse au "Voyage Impossible" dans les logs user_access.log parsés
// Nécessite un enrichissement géospatial dans Sentinel
IvantiAccessLogs
| where EventType == "VPN_Login_Success"
| summarize FirstLogin = min(TimeGenerated), LastLogin = max(TimeGenerated), IPCount = dcount(SourceIP), Locations = make_set(GeoLocation) by UserName
// Alerte si le même utilisateur s'est connecté depuis plus d'un pays distinct dans un laps de temps court
| where IPCount > 1 and array_length(Locations) > 1
| project UserName, FirstLogin, LastLogin, IPCount, Locations

---

Références et lectures complémentaires

• GitHub Hexastrike : Ivanti Connect Secure Logs Parser
• Architecture liée : Architecture et Versioning Ivanti
• Artefact lié : Journaux d’authentification Linux (auth.log, secure)
• Artefact lié : Historique Shell Linux (.bash_history)