CTI & OSINT

Analyse de la compromission des systèmes Ivanti Endpoint Manager Mobile (EPMM) – Rapport CISA AR25-261A

by  • 

Résumé exécutif

Le 18 septembre 2025, l’agence CISA (Cybersecurity and Infrastructure Security Agency) a publié un rapport d’analyse technique (référence AR25-261A) sur une campagne de compromission visant les systèmes Ivanti Endpoint Manager Mobile (EPMM). Des acteurs malveillants ont exploité deux vulnérabilités critiques (référencées CVE-2025-4427 et CVE-2025-4428) pour contourner l’authentification du produit EPMM puis exécuter du code arbitraire à distance sur le serveur. En abuser combiné, ces failles ont permis aux attaquants d’installer discrètement des programmes malveillants persistants – constitués de chargeurs (loaders) et d’écouteurs clandestins (listeners) – leur offrant un contrôle prolongé du système compromis tout en échappant aux détections traditionnelles. Ce rapport synthétise le fonctionnement de ces maliciels (injection de code via des filtres web Java), les techniques MITRE ATT&CK associées (évasion par obfuscation, chargement dynamique, canaux chiffrés, etc.), ainsi que les indicateurs de compromission identifiés. Enfin, il fournit des recommandations concrètes pour détecter ce type d’attaque, répondre efficacement à l’incident, remédier aux faiblesses exploitées et durcir la sécurité des déploiements Ivanti EPMM.

Vulnérabilités exploitées : CVE-2025-4427 et CVE-2025-4428

Les attaques se sont appuyées sur deux failles critiques révélées en mai 2025 dans Ivanti EPMM :

  • CVE-2025-4427 : une vulnérabilité de contournement d’authentification dans l’API d’EPMM, permettant à un utilisateur non authentifié d’accéder à des ressources protégées de l’application.
  • CVE-2025-4428 : une vulnérabilité d’injection de code au niveau de l’API d’EPMM, permettant à un attaquant (après exploitation de la première faille) d’exécuter du code arbitraire sur le serveur via des requêtes spécialement conçues.

Ivanti a fourni des correctifs pour ces failles le 13 mai 2025, mais une preuve de concept publique est rapidement apparue le 15 mai 2025, entraînant des exploitations actives immédiates. En combinant CVE-2025-4427 et CVE-2025-4428, un attaquant distant non authentifié peut obtenir une exécution de code arbitraire sur un serveur EPMM vulnérable. CISA indique que les systèmes Ivanti EPMM jusqu’aux versions 11.12.0.4, 12.3.0.1, 12.4.0.1 et 12.5.0.0 (c’est-à-dire non mis à jour au-delà de mi-mai 2025) sont touchés.

Dans le cas analysé par la CISA, les acteurs malveillants ont ciblé en particulier l’endpoint API **/mifs/rs/api/v2/** du serveur EPMM. Vers le 15 mai 2025, profitant de l’absence de correctif appliqué, ils ont envoyé à cet endpoint des requêtes HTTP GET contenant un paramètre **?format=** malveillant. Ce paramètre exploitait l’injection de langage d’expression Java (EL) permise par CVE-2025-4428, afin de forcer le serveur à exécuter des commandes système. Par ce biais, les attaquants ont pu effectuer diverses actions initiales à distance : collecte d’informations système, téléchargement de fichiers additionnels depuis Internet, listage du répertoire racine du serveur, cartographie du réseau local, exécution de scripts pour générer un vidage de mémoire (heapdump Java) et extraction des identifiants LDAP stockés. Ces actions leur ont fourni à la fois un premier pied-à-terre et des données sensibles, ouvrant la voie à l’implantation de leurs malwares persistants.

Charges utiles malveillantes analysées

Lors de l’investigation, la CISA a récupéré deux ensembles de fichiers malveillants que les attaquants avaient déposés sur le serveur compromis (dans le répertoire temporaire /tmp). Au total, cinq fichiers ont été identifiés, organisés en deux sets distincts. Chaque set comprend un chargeur (loader, un fichier JAR exécutable) et un écouteur malveillant (listener, une ou plusieurs classes Java injectées dans le processus du serveur EPMM). Ces composants agissent de concert pour établir une porte dérobée persistante sur le serveur : le loader installe l’écouteur dans l’application, et l’écouteur attend des commandes des attaquants pour les exécuter avec les privilèges du serveur.

  • Set 1 : web-install.jar (désigné Loader 1), ReflectUtil.class et SecurityHandlerWanListener.class.
  • Set 2 : web-install.jar (désigné Loader 2) et WebAndroidAppInstaller.class.

Set 1 – Loader 1 et écouteur SecurityHandlerWanListener : Le loader 1 est un JAR malveillant contenant la classe ReflectUtil. Lorsqu’il s’exécute sur le serveur (via l’exploitation initiale), il charge dynamiquement ReflectUtil.class dans le processus Tomcat d’Ivanti EPMM. Cette classe ReflectUtil joue le rôle d’injecteur : elle instancie et attache un nouveau filtre de servlet, SecurityHandlerWanListener.class, au sein du service web Tomcat. En d’autres termes, le malware s’insère dans la chaîne de traitement des requêtes HTTP du serveur EPMM.

Le composant SecurityHandlerWanListener ainsi injecté est un écouteur malveillant qui surveille le trafic HTTP entrant. Il est programmé pour intercepter des requêtes spécifiques – très probablement identifiées par un motif particulier connu de l’attaquant – et pour traiter des charges utiles cachées dans ces requêtes. Concrètement, lorsqu’une requête malveillante ciblée est reçue, SecurityHandlerWanListener va extraire la charge utile encodée qui y est dissimulée (par exemple dans un paramètre ou dans le corps de la requête), la décoder et la déchiffrer si nécessaire, puis en générer à la volée une nouvelle classe Java en mémoire. Cette classe malveillante temporaire est immédiatement chargée et exécutée, permettant à l’attaquant de faire tourner du code arbitraire sur le serveur à chaque requête de commande. En somme, le Set 1 établit une backdoor persistante qui exécute directement les instructions distantes de l’attaquant sur le serveur Ivanti, en passant par un filtre web clandestin.

Set 2 – Loader 2 et écouteur WebAndroidAppInstaller : Le loader 2 est un second JAR malveillant distinct qui, lors de son exécution, charge dynamiquement la classe WebAndroidAppInstaller. Ce composant s’attache lui aussi au serveur Tomcat d’EPMM en tant que listener caché, surveillant des requêtes HTTP prédéfinies. Lorsqu’une requête malveillante correspondant à son mode de déclenchement arrive, WebAndroidAppInstaller agit en plusieurs étapes : (1) il extrait un paramètre chiffré présent dans la requête (par exemple un champ « password » ou « key »), (2) il le déchiffre via AES en utilisant une clé symétrique codée en dur dans le malware, (3) il utilise ce secret pour déverrouiller ou générer la charge utile suivante – souvent en définissant et chargeant une nouvelle classe malveillante en mémoire, différente à chaque commande, (4) il exécute cette classe (réalisant l’action commandée par l’attaquant), puis (5) il chiffre et encode le résultat de cette exécution, et renvoie ce résultat chiffré à l’attaquant dans la réponse HTTP. Ce procédé en plusieurs phases fait du Set 2 un outil de commande et contrôle particulièrement furtif : l’attaquant peut interagir avec le serveur compromis, exécuter des actions arbitraires et recevoir les résultats, le tout via des requêtes web apparemment légitimes et en chiffrant les données échangées pour en masquer le contenu.

Dans les deux sets, les composants malveillants sont déguisés pour se fondre parmi les fichiers légitimes. Par exemple, ReflectUtil.class est placé dans un package Java nommé falsement org.apache.http (simulant un module Apache commun), et WebAndroidAppInstaller.class prétend appartenir au package com.mobileiron.service (MobileIron étant l’ancien nom de la solution Ivanti). Cette technique de mascarade (MITRE T1036) vise à tromper l’administrateur ou les outils de sécurité en faisant passer ces classes malicieuses pour des éléments normaux du logiciel.

Livraison du malware et tactiques d’évasion

Mode d’infection : Les attaquants ont livré leurs malware sur le serveur EPMM en plusieurs segments, plutôt qu’en un seul fichier complet, afin d’échapper à la détection. Chaque loader JAR (Loader 1 et Loader 2) a été découpé en multiples morceaux encodés en Base64 (technique d’obfuscation par segmentation, MITRE T1027.004). Ils ont ensuite exploité l’injection de code via le paramètre format : pour chaque segment, une requête HTTP GET distincte a été envoyée vers l’API vulnérable, contenant une expression EL Java chargée d’écrire le segment sur le serveur. La première requête créait le fichier (par ex. /tmp/web-install.jar) et y injectait le premier bloc de bytes décodés ; chaque requête suivante ajoutait (append) un nouveau bloc Base64 décodé à la suite du fichier jusqu’à reconstituer entièrement le JAR malveillant. Cette reconstruction incrémentale via l’expression EL peut être illustrée ainsi :

GET /mifs/rs/api/v2/featureusage?format=${...FileOutputStream("/tmp/web-install.jar", true).write(Base64.getDecoder().decode("[CHUNK]"))}

Ce type de payload inséré dans l’URL permet d’écrire successivement chaque chunk (morceau) de code dans le fichier ciblé. Au final, le malware est présent sur le serveur sans avoir jamais transité en clair intégralement sur le réseau, ni été écrit d’un seul tenant sur le disque.

Évasion et furtivité : Cette livraison par morceaux présente plusieurs avantages en termes de défense évasion. D’abord, chaque segment Base64 pris isolément ne ressemble pas à un malware identifiable, ce qui brouille les signatures pour les antivirus et IDS basés sur des motifs connus. Ensuite, le fait de transférer de petits blocs contourne d’éventuelles restrictions de taille ou contrôles de flux inhabituel sur l’API. De plus, en s’appuyant sur l’exploitation de l’EL côté serveur, les attaquants utilisent le propre moteur de l’application pour écrire les fichiers, ce qui peut ne pas alerter les mécanismes de sécurité (les actions étant exécutées comme des opérations internes légitimes du serveur Java). L’expression de création de fichier en mode append assure aussi que même si le serveur impose une limite de taille par requête, le malware complet peut être assemblé via de multiples petites écritures.

Une fois les fichiers malveillants écrits dans le répertoire /tmp (destination choisie possiblement parce qu’elle est temporaire et moins surveillée), les chargeurs sont exécutés pour installer les backdoors en mémoire. L’ensemble du processus minimise les traces : hormis la présence du fichier JAR dans /tmp, il n’y a pas de modification du code applicatif sur le disque (les classes injectées ne résident qu’en mémoire).

Outre le fractionnement Base64 et la mascarade décrits, d’autres techniques d’évasion MITRE ATT&CK ont été identifiées dans cette campagne :

  • Reflective Code Loading (T1620) : la classe ReflectUtil effectue un chargement de code en mémoire de façon dynamique, évitant d’écrire la charge utile (SecurityHandlerWanListener) sur le disque.
  • Deobfuscation/Decode (T1140) : ReflectUtil décode et décompresse la charge utile (bytecode de la classe malveillante) avant exécution, ce qui implique que celle-ci était stockée de manière chiffrée/encodée dans le loader.
  • Application Layer Protocol – Web Protocols (T1071.001) : les communications de commande passent par de simples requêtes HTTP(s) sur le port web de l’EPMM, se confondant ainsi avec le trafic applicatif normal.
  • Encrypted Channel – Symmetric Crypto (T1573.001) : WebAndroidAppInstaller utilise un chiffrement symétrique (AES) pour protéger les paramètres transmis par l’attaquant et les réponses renvoyées, rendant le contenu des échanges illisible pour un observateur intermédiaire.

Toutes ces techniques combinées rendent la détection du compromis plus difficile : le malware est fragmenté, furtif en mémoire, déguisé en composant légitime, et communique en chiffrant ses données via des canaux web standard.

Persistance de l’accès malveillant

L’installation de ces listeners malveillants au sein du service Ivanti EPMM a conféré aux attaquants un accès persistant à l’infrastructure. Tant que le serveur EPMM compromis fonctionne, les filtres clandestins (SecurityHandlerWanListener et WebAndroidAppInstaller) restent actifs en arrière-plan, prêts à traiter les requêtes de l’attaquant. Cela signifie que même après l’intrusion initiale, les adversaires peuvent, à tout moment, exécuter de nouvelles commandes sur le système en envoyant simplement les requêtes appropriées – sans besoin d’exploiter de nouveau la vulnérabilité tant que la porte dérobée n’est pas éradiquée.

Cette persistance au niveau applicatif s’apparente à une webshell sur mesure intégrée dans l’application EPMM : l’attaquant communique avec le serveur compromis en utilisant ses interfaces web légitimes (API REST), ce qui rend ses actions plus difficiles à isoler dans les journaux. De plus, comme les backdoors s’exécutent avec les mêmes droits que l’application EPMM, elles bénéficient d’un large accès (EPMM étant un outil de gestion, il a potentiellement accès à de nombreux terminaux, données d’annuaire, etc., ce qui peut amplifier l’impact de la compromission).

Il convient de noter que la persistance ainsi obtenue reste liée au runtime du serveur. Si le service Tomcat/Ivanti est redémarré ou le serveur rebooté, les composants malveillants injectés en mémoire seraient perdus (sauf si les attaquants réinjectent le loader via la faille ou s’ils ont prévu un mécanisme de relance). Toutefois, étant donné que ces vulnérabilités ont été couramment exploitées en mai 2025, il est possible que les attaquants aient implanté d’autres vecteurs de persistance (par exemple, création de tâches planifiées, nouveaux utilisateurs systèmes, etc.) en sus des listeners – aucune indication de tels ajouts n’est donnée dans le rapport AR25-261A, qui s’est focalisé sur l’analyse des malwares déposés.

En résumé, tant que le système n’est pas nettoyé et corrigé, les attaquants peuvent maintenir leur accès et revenir à volonté sur le serveur via les backdoors qu’ils y ont laissées. Cela souligne l’importance de détecter rapidement ces composants et d’engager une remédiation en profondeur.

Détection et surveillance

Détecter la présence de ces malwares et l’activité d’exploitation associée requiert une approche multi-couches étant donné leur furtivité. Voici les axes principaux de détection recommandés :

  • Indicateurs techniques (IoC) : Exploitez les informations d’IoC fournies par la CISA et d’autres sources : les hash cryptographiques des fichiers malveillants connus (par exemple, le SHA-256 du web-install.jar malicieux du Set 1 est c1f60ca5a5f7b94ab7..., celui du Set 2 est différent), les noms de fichiers ou de classes inhabituels (ReflectUtil.class, etc.), ou la présence anormale d’un fichier JAR web-install.jar dans le répertoire /tmp d’un serveur EPMM doivent alerter. CISA publie un fichier JSON contenant la liste complète des IoC (empreintes de fichiers, noms de classes malveillantes, éventuels domaines/IP de C2, etc.) liés à cette attaque – il est crucial de les intégrer dans vos outils de détection (scanners antiviraux, EDR, SIEM). Par exemple, la simple détection sur un système EPMM d’un fichier dont le hash correspond à l’un des loaders malveillants doit déclencher une alerte immédiate.
  • Analyse des journaux (logs) : Inspectez les logs du serveur Ivanti EPMM/Tomcat pour repérer des signes d’exploitation. Plus précisément, recherchez des requêtes HTTP suspectes sur l’API EPMM :
    • Des appels vers des endpoints inhabituels ou sensibles comme **/mifs/rs/api/v2/featureusage** (ou d’autres chemins non documentés) contenant le paramètre format suivi d’une chaîne encodée ou de syntaxe suspecte (${...}).
    • Des occurrences de commandes système ou d’outils réseau dans les paramètres ou URLs de requête (par ex. des séquences comme sh -i, curl, wget, ping, qui pourraient indiquer que l’attaquant a tenté d’exécuter des commandes shell via l’injection).
    • Des codes de statut HTTP anormaux ou volumineux (une série de 200 OK avec des tailles de réponse conséquentes correspondant possiblement au transfert de fichiers ou de données via la backdoor).
    Implémentez des règles de corrélation pour signaler ces motifs. Par exemple, une règle peut détecter toute chaîne ${...} dans un paramètre d’URL de requête vers /mifs/rs/api/, ou une autre peut alerter sur la présence simultanée des mots-clés GET, /api/v2/, et de commandes comme getRuntime ou FileOutputStream dans une même entrée de log – autant d’éléments caractéristiques de cette attaque.
  • Détection comportementale en mémoire : Surveillez le comportement du processus Java/Tomcat d’EPMM. L’injection de ces listeners pourrait se manifester par le chargement de classes non standards en mémoire. Des solutions EDR capables d’inspecter la JVM pourraient détecter le chargement d’une classe nommée SecurityHandlerWanListener ou WebAndroidAppInstaller, qui n’appartiennent normalement pas au produit Ivanti. De même, l’utilisation de fonctionnalités de réflexion (Reflection API) et de class loaders en cours d’exécution (ce que fait ReflectUtil) peut être un indicateur anormal dans le contexte d’un MDM et justifier une enquête.
  • Règles YARA/SIGMA : Pour faciliter la détection automatisée, CISA a publié des règles YARA ciblant ces malwares, ainsi qu’une règle SIGMA couvrant les traces laissées dans les journaux. Les règles YARA permettent de scanner des fichiers ou la mémoire à la recherche de constantes ou de motifs binaires propres aux loaders et listeners (par exemple, des chaînes de texte uniques présentes dans ReflectUtil.class ou la présence de certaines séquences hexadécimales caractéristiques). La règle SIGMA, quant à elle, formalise une détection des événements logs liés à l’exploitation (URL, commandes et IoC connus). Il est recommandé d’intégrer et d’adapter ces règles dans vos systèmes de surveillance opérationnelle pour une alerte précoce.

Nous reproduisons ci-dessous ces règles fournies par la CISA (à tester dans un environnement de test avant déploiement en production) :

Règles YARA (détection des composants malveillants Ivanti EPMM)

rule CISA_251126_01 : trojan hides_artifacts
{
    meta:
        author = "CISA Code & Media Analysis"
        incident = "251126"
        date = "2025-07-23"
        last_modified = "20250724_1615"
        malware_type = "trojan"
        description = "Detects malicious jar filter samples"
        sha256_1 = "c1f60ca5a5f7b94ab7122718a44b46de16c69d22c2eb62ce2948cab14bc78d50"  // Loader 1
    strings:
        $s0 = { 6F 72 67 2F 61 70 61 63 68 65 2F 68 74 74 70 2F 63 6C 69 65 6E 74 }    // "org/apache/http/client"
        $s1 = { 2F 77 6F 2F 52 65 66 6C 65 63 74 55 74 69 6C 2E 63 6C 61 73 73 }        // "/wo/ReflectUtil.class"
        $s2 = { 83 2E 9D 42 02 A3 81 42 02 B3 C7 57 34 C4 A8 21 }                      // [binary patterns]
        $s3 = { 8C 8E C0 B6 14 0E 92 08 89 EE EB 1A 11 7D F4 4E }
        $s4 = { 5B 97 FF F6 12 C9 16 F5 17 C8 5B 5F 44 0E 07 30 }
        $s5 = { A9 21 59 ED 8E 7A 28 D6 29 FA E3 D0 4C 3D 0F CE }
        $s6 = { 5A BD F7 24 E8 66 5F 07 2F 7C 0C 0E A9 E3 8D C5 }
        $s7 = { 05 1B AE 97 B1 88 FF 01 16 EF 3F 44 9E 5F 43 AE }
    condition:
        all of them
}

rule CISA_251126_02 : trojan
{
    meta:
        author = "CISA Code & Media Analysis"
        incident = "251126"
        date = "2025-07-23"
        last_modified = "20250724_1615"
        malware_type = "trojan"
        description = "Detects malicious servlet filter class loader samples"
        sha256_1 = "065c1c2fb17ba1c3f882bead409215df612673cd455698768ed71412f9190ba3"  // ReflectUtil.class
    strings:
        $s0 = { 6F 72 67 2F 61 70 61 63 68 65 2F 68 74 74 70 }                        // "org/apache/http"
        $s1 = { 63 6C 69 65 6E 74 2F 77 6F 2F 52 65 66 6C 65 63 74 55 74 69 6C }        // "client/wo/ReflectUtil"
        $s2 = { 53 65 63 75 72 69 74 79 48 61 6E 64 6C 65 72 57 61 6E 4C 69 73 74 65 6E 65 72 }  // "SecurityHandlerWanListener"
        $s3 = { 67 65 74 4C 69 73 74 65 6E 65 72 }                                    // "getListener"
        $s4 = { 61 64 64 4C 69 73 74 65 6E 65 72 }                                    // "addListener"
        $s5 = { 54 6F 6D 63 61 74 45 6D 62 65 64 64 65 64 43 6F 6E 74 65 78 74 }        // "TomcatEmbeddedContext"
        $s6 = { 67 7A 69 70 44 65 63 6F 6D 70 72 65 73 73 }                            // "gzipCompress"
        $s7 = { 67 65 74 41 70 70 6C 69 63 61 74 69 6F 6E 45 76 65 6E 74 4C 69 73 74 65 6E 65 72 73 }  // "getApplicationEventListeners"
        $s8 = { 73 65 74 41 70 70 6C 69 63 61 74 69 6F 6E 45 76 65 6E 74 4C 69 73 74 65 6E 65 72 73 }  // "setApplicationEventListeners"
        $s9 = { 65 76 69 6C 43 6C 61 73 73 4E 61 6D 65 }                                // "evilClassName"
    condition:
        all of them
}

rule CISA_251126_03 : trojan installs_other_components exfiltrates_data
{
    meta:
        author = "CISA Code & Media Analysis"
        incident = "251126"
        date = "2025-07-23"
        last_modified = "20250724_1615"
        malware_type = "trojan"
        description = "Detects malicious servlet filter class samples"
        sha256_1 = "b1b1cf33b8d3da35293d6b74c378f0cd9452a4351e26d07c896c4d9a8257ef89"  // SecurityHandlerWanListener.class
    strings:
        $s0 = { 53 65 72 76 6C 65 74 52 65 71 75 65 73 74 4C 69 73 74 65 6E 65 72 }      // "ServletRequestListener"
        $s1 = { 43 6C 61 73 73 4C 6F 61 64 65 72 }                                      // "ClassLoader"
        $s2 = { 53 65 72 76 6C 65 74 52 65 71 75 65 73 74 45 76 65 6E 74 }              // "ServletRequestEvent"
        $s3 = { 2F 48 74 74 70 53 65 72 76 6C 65 74 52 65 73 70 6F 6E 73 65 }            // "/HttpServletResponse"
        $s4 = { 48 74 74 70 53 65 73 73 69 6F 6E }                                      // "HttpSession"
        $s5 = { 48 74 74 70 53 65 72 76 6C 65 74 52 65 73 70 6F 6E 73 65 }              // "HttpServletResponse"
        $s6 = { 68 65 61 64 65 72 56 61 6C 75 65 }                                      // "headerValue"
        $s7 = { 37 63 36 61 38 38 36 37 64 37 32 38 63 33 62 62 }                        // Base64 chunk (example)
        $s8 = { 70 61 73 73 }                                                          // "pass"
        $s9 = { 53 65 63 72 65 74 4B 65 79 53 70 65 63 }                                // "SecretKeySpec"
        $s10 = { 15 68 74 74 70 73 3A 2F 2F 77 77 77 2E 6C 69 76 65 2E 63 6F 6D 2F }     // "https://www.live.com/" (possibly benign string)
        $s11 = { 52 65 66 65 72 65 72 }                                                // "Referer"
    condition:
        all of them
}

rule CISA_251126_04 : trojan hides_artifacts
{
    meta:
        author = "CISA Code & Media Analysis"
        incident = "251126"
        date = "2025-07-23"
        last_modified = "20250724_1615"
        malware_type = "trojan"
        description = "Detects malicious jar Tomcat listener shell samples"
        sha256_1 = "b618057de9a8bba95440f23b9cf6374cc66f2acd127b3d478684b22d8f11e00b"  // Loader 2
    strings:
        $s0 = { 63 6F 6D 2F 6D 6F 62 69 6C 65 69 72 6F 6E 2F 73 65 72 76 69 63 65 2F }  // "com/mobileiron/service/"
        $s1 = { 57 65 62 41 6E 64 72 6F 69 64 41 70 70 49 6E 73 74 61 6C 6C 65 72 2E 63 6C 61 73 73 }  // "WebAndroidAppInstaller.class"
        $s2 = { 5A 5D BB 33 C0 43 31 B0 2D DC 58 F2 75 44 CE E5 }                      // [binary patterns]
        $s3 = { 97 DC AC 0F A7 69 97 A4 5A 72 E8 96 AC 43 9E 01 }
        $s4 = { E0 E0 7E 40 F3 F8 87 30 C5 83 30 C5 43 14 E7 67 }
        $s5 = { DB E6 F7 F9 BD FC BE 75 00 BF 6F B3 59 B7 28 07 }
        $s6 = { C6 BF A4 1D 28 AB 7A B9 3E 09 B1 D8 E2 FA 09 36 }
        $s7 = { B8 0E 8E 0B 97 2D AE CF B4 B8 6E CD E5 E6 BA 92 }
    condition:
        all of them
}

rule CISA_251126_05 : trojan installs_other_components exfiltrates_data
{
    meta:
        author = "CISA Code & Media Analysis"
        incident = "251126"
        date = "2025-07-23"
        last_modified = "20250724_1615"
        malware_type = "trojan"
        description = "Detects malicious Tomcat listener shell class samples"
        sha256_1 = "df501b238854d6579cafebeba82581a728e89ed1f6cd0da54c79ef4eb6f4f9fd"  // WebAndroidAppInstaller.class
    strings:
        $s0 = { 43 6C 61 73 73 4C 6F 61 64 65 72 }                                    // "ClassLoader"
        $s1 = { 6D 6F 62 69 6C 65 69 72 6F 6E 2F 73 65 72 76 69 63 65 }                // "mobileiron/service"
        $s2 = { 57 65 62 41 6E 64 72 6F 69 64 41 70 70 49 6E 73 74 61 6C 6C 65 72 }    // "WebAndroidAppInstaller"
        $s3 = { 61 64 64 4C 69 73 74 65 6E 65 72 }                                    // "addListener"
        $s4 = { 73 65 72 76 6C 65 74 52 65 71 75 65 73 74 4C 69 73 74 65 6E 65 72 43 6C 61 73 73 }  // "ServletRequestListenerClass"
        $s5 = { 61 64 64 41 70 70 6C 69 63 61 74 69 6F 6E 45 76 65 6E 74 4C 69 73 74 65 6E 65 72 4D 65 74 68 6F 64 }  // "addApplicationEventListenerMethod"
        $s6 = { 62 61 73 65 36 34 44 65 63 6F 64 65 }                                  // "base64Decode"
        $s7 = { 63 6F 6E 74 65 6E 74 54 79 70 65 }                                    // "contentType"
        $s8 = { 08 72 65 73 70 6F 6E 73 65 }                                          // possibly part of "response"
        $s9 = { 33 63 36 65 30 62 38 61 39 63 31 35 32 32 34 61 }                      // partial hex pattern (could be part of hashed data)
        $s10 = { 6B 70 61 73 73 6C 6F 67 69 6E }                                      // "kpasslogin" or similar
        $s11 = { 53 65 72 76 6C 65 74 52 65 71 75 65 73 74 4C 69 73 74 65 6E 65 72 }    // "ServletRequestListener"
        $s12 = { 53 65 63 72 65 74 4B 65 79 53 70 65 63 }                              // "SecretKeySpec"
    condition:
        all of them
}

(Les règles YARA ci-dessus ciblent respectivement : 01) Loader 1 (web-install.jar Set 1), 02) ReflectUtil.class, 03) SecurityHandlerWanListener.class, 04) Loader 2 (web-install.jar Set 2), 05) WebAndroidAppInstaller.class. Chaque règle utilise une combinaison de chaînes ASCII (noms de packages, de classes, constantes) et de motifs binaires extraits des échantillons pour une détection fiable.)

Règle SIGMA (détection d’activité d’exploitation Ivanti EPMM)

title: Detects Artifacts Based on MAR-251126 (Ivanti EPMM CVE-2025-4427/4428)
id: 83df757f-54e7-44a0-be21-ae2306ca3240
status: test
description: Detects abused URL paths and suspicious commands used by threat actors on Ivanti EPMM (MDM) based on CISA MAR-251126.
references:
  - 'MAR-251126'
  - 'https://projectdiscovery.io/blog/ivanti-remote-code-execution'
  - 'https://labs.watchtowr.com/expression-payloads-meet-mayhem-cve-2025-4427-and-cve-2025-4428/'
# (Références supplémentaires sur les vulnérabilités et attaques Ivanti)
author: CISA Code & Media Analysis
date: 2025-08-08
modified: 2025-08-13
tags:
  - cve.2025.4427
  - cve.2025.4428

logsource:
  product: ivanti_epmm      # Adaptation potentielle selon la source de logs
  service: webserver
detection:
  keywords:
    - 'GET'
  api_path:
    - '/mifs/rs/api/v2/*'
  susp_commands:
    - 'sh -i'
    - 'invoke'
    - 'java'
    - '/dev/tcp/'
    - 'getRuntime'
    - '.jar'
    - '.class'
    - 'evilClassName'
    - 'ping'
    - 'dig'
    - 'curl'
    - 'wget'
    - 'fetch'
    - 'echo'
  chmod_usage:
    - 'chmod'
  file_rights:
    - '+x'
    - 'a+r'
    - '755'
    - '/tmp'
  known_artifacts:
    - '/mi/tomcat/webapps/mifs/401.jsp'
    - '/mi/tomcat/webapps/mifs/css/css.css'
    - '/mi/tomcat/webapps/mifs/session.jsp'
    - '/mi/tomcat/webapps/mifs/baseURL.jsp'
    - 'c1f60ca5a5f7b94ab7122718a44b46de16c69d22c2eb62ce2948cab14bc78d50'  # hash Loader1
    - 'b618057de9a8bba95440f23b9cf6374cc66f2acd127b3d478684b22d8f11e00b'  # hash Loader2
    - '065c1c2fb17ba1c3f882bead409215df612673cd455698768ed71412f9190ba3'  # hash ReflectUtil
    - 'df501b238854d6579cafebeba82581a728e89ed1f6cd0da54c79ef4eb6f4f9fd'  # hash WebAndroidAppInstaller
    - '1b1dda5e8e26da568559e0577769697c624df30e'  # ex. hash d'un JSP malveillant
    - 'ac389c8b7f3d2fcf4fd73891f881b12b8343665b'  # (autres hash IoC du JSON)
    - '82.132.235.212'
    - '37.219.84.22'
    - '88.194.29.21'
    - '27.25.148.183'
    - '91.193.19.109'
    - '47.120.74.19'
    - '100.26.51.59'
    - '150.241.71.231'
    - '5.181.159.149'
    - '45.38.17.43'
condition: |
  keywords and api_path and susp_commands or 
  keywords and api_path and chmod_usage or 
  chmod_usage and file_rights or 
  known_artifacts
falsepositives:
  - Legitimate admin scripts using similar commands
  - Automated backup or monitoring touching /tmp and using chmod (rare)
level: high

Interprétation de la règle SIGMA : Cette règle se concentre sur la détection dans les logs des signes d’exploitation et de malveillance : elle cherche les requêtes GET sur l’API EPMM (/mifs/rs/api/v2/*) contenant des commandes suspectes (sh -i, appels à java, invocation de shell via /dev/tcp/, etc.), des modifications de permissions de fichiers (utilisation de chmod avec +x ou 755 sur des fichiers dans /tmp), ainsi que la présence de chemins ou fichiers inhabituels (plusieurs fichiers JSP dans l’arborescence /mi/tomcat/webapps/mifs/ qui pourraient être des webshells) et des hashes ou IP connus associés à cette campagne. La condition logique combine ces éléments pour déclencher une alerte quand plusieurs sont observés conjointement. En cas de déclenchement (niveau high), cela suggère fortement qu’une exploitation de CVE-2025-4427/4428 et une injection de malware ont eu lieu sur un serveur EPMM.

Réponse à incident

En présence d’indicateurs d’une telle compromission, une réaction rapide et méthodique est impérative. Les grandes étapes de réponse à incident recommandées sont :

  1. Isolation du système compromis : Mettez immédiatement en quarantaine ou hors-réseau le ou les serveurs EPMM affectés pour empêcher l’exfiltration de données ou la progression de l’attaque. Par exemple, déconnectez le serveur du réseau ou bloquez son accès depuis Internet (si applicatif) afin de couper la communication avec les attaquants tout en préservant l’état du système pour analyse.
  2. Collecte d’artefacts et analyse initiale : Recueillez un maximum d’éléments forensiques sur le serveur avant toute modification. Dressez la liste des processus en cours et des services actifs (pour repérer un éventuel processus Java anormal ou chargement suspect de librairies). Examinez les journaux d’événements (système, applicatifs) à la recherche de connexions inhabituelles ou d’authentifications suspectes. Inventoriez les connexions réseau établies depuis/vers le serveur (par exemple, via un netstat ou outils EDR) pour identifier d’éventuels canaux de C2 ou déplacements latéraux. Réalisez une image disque complète et une capture de la mémoire RAM du serveur compromis – ces instantanés seront précieux pour une analyse approfondie hors-ligne et pour disposer de la trace intégrale des malwares en mémoire.
  3. Évaluation de l’ampleur de la compromission : Sur la base des indices récoltés, déterminez si l’attaque s’est limitée au serveur EPMM ou si l’adversaire a pu compromettre d’autres machines du réseau (mouvement latéral) ou obtenir des privilèges étendus (par ex. usage des identifiants LDAP volés pour rebondir). Si l’analyse initiale indique que l’accès malveillant a été contenu à EPMM et qu’aucune propagation n’est détectée, vous pourrez concentrer les efforts sur ce serveur. En revanche, si des signes d’activité malveillante plus large sont trouvés (ex. logs montrant des connexions de l’attaquant sur d’autres systèmes, création de comptes suspects, etc.), il faudra étendre la réponse à l’échelle de l’entreprise.
  4. Containement et éradication : Si l’atteinte semble circonscrite à EPMM, prévoyez la réinitialisation des informations d’identification associées (comptes d’administration EPMM, comptes d’utilisateurs dont les appareils sont gérés, comptes de service, etc.), car elles ont pu être compromises (surtout si les attaquants ont extrait des identifiants LDAP ou autres). Si une compromission étendue est confirmée, enclenchez votre plan de réponse aux cyberincidents global : mobilisez l’équipe de Threat Hunting pour inspecter l’ensemble du SI à la recherche des tactiques de l’attaquant, segmentez ou éteignez temporairement les systèmes affectés au-delà d’EPMM, et préparez un plan d’éradication coordonnée (nettoyage de malware sur tous les hôtes, changement généralisé des mots de passe, etc.). Dans tous les cas, pour le serveur EPMM lui-même, la CISA recommande fortement de procéder à une réinstallation complète (re-image) de la machine compromise une fois les analyses terminées, afin d’éliminer toute persistance furtive qui aurait pu être manquée.
  5. Notification aux autorités compétentes : Pensez à déclarer l’incident auprès des organismes appropriés (par exemple le CERT national, ou pour les organisations américaines, la CISA via son portail ou numéro d’urgence). Fournissez-leur les détails de l’attaque et idéalement des échantillons de malware (en utilisant, aux USA, le formulaire de soumission de malware de la CISA en indiquant l’identifiant d’incident qui vous sera communiqué). Cette coopération aide la communauté à mieux comprendre et contrer la menace, et vous pourriez en retour recevoir des indications ou assistance supplémentaires.
  6. Restauration et suivi : Après éradication, reconstruisez un environnement sain pour le service EPMM (système d’exploitation réinstallé, application Ivanti EPMM mise à jour vers la dernière version corrigée) avant de le reconnecter en production. Surveillez ensuite de près ce nouvel environnement pour tout signe de réinfection ou de tentative d’accès suspecte, particulièrement dans les premières semaines suivant l’incident. Profitez-en pour appliquer les mesures de durcissement décrites ci-dessous, afin de prévenir une récidive.

Remédiation et durcissement des systèmes Ivanti EPMM

Afin de corriger les failles exploitées et de renforcer la sécurité des systèmes Ivanti EPMM à l’avenir, appliquez les mesures suivantes :

  • Mise à jour immédiate du produit Ivanti : déployez les patches officiels d’Ivanti adressant CVE-2025-4427 et CVE-2025-4428 sur tous vos serveurs EPMM. S’assurer que les versions utilisées sont au moins : 11.12.0.5, 12.3.0.2, 12.4.0.2 ou 12.5.0.1 (versions dans lesquelles les failles ont été corrigées en mai 2025). La mise à niveau logicielle est la seule façon de supprimer le vecteur d’attaque principal et d’empêcher une ré-exploitation identique.
  • Renforcement des contrôles d’accès et de la surveillance des EPMM (HVA) : traitez vos serveurs de gestion de terminaux mobiles (MDM) tels qu’Ivanti EPMM comme des actifs à haute valeur (High-Value Assets). Ils ont des privilèges très larges (contrôle de milliers d’appareils, accès à des données sensibles), et constituent donc des cibles de choix. Isolez autant que possible ces serveurs du reste du réseau : placez-les sur un segment réseau dédié, appliquez des règles de pare-feu restrictives (seules les communications strictement nécessaires doivent être autorisées, par ex. depuis les appareils mobiles gérés ou les administrateurs autorisés). Activez une journalisation exhaustive de toutes les actions sur ces systèmes (logs d’accès API, actions d’administration) et intégrez-les à votre SIEM pour un suivi en continu. Envisagez des contrôles d’intégrité réguliers sur les fichiers de l’application (pour détecter toute modification non autorisée, bien qu’ici les malwares étaient principalement en mémoire).
  • Authentification renforcée : implémentez une authentification multi-facteur (MFA) robuste pour l’accès à l’interface d’administration EPMM et de manière générale pour les comptes administrateurs dans l’entreprise. Bien que dans ce cas précis l’attaque ne requière pas de compte (vulnérabilité pré-authentification), une MFA protège contre d’autres vecteurs d’attaque comme le vol de mot de passe ou l’exploitation d’une faille d’accès initial. Privilégiez des mécanismes résistants au phishing (U2F/WebAuthn, certificats client, etc.). Vérifiez également que les comptes par défaut ou de service sur EPMM ont des mots de passe forts et uniques.
  • Principes de sécurité by design : appliquez les bonnes pratiques générales de sécurité des applications et serveurs exposés :
    • Désactivez ou restreignez les interfaces et API non utilisées de l’EPMM pour réduire la surface d’attaque (par exemple, si certaines API REST ne sont pas nécessaires, bloquez-les via la configuration ou un proxy).
    • Mettez en place des listes de contrôle d’accès (ACL) au niveau de l’API EPMM si le produit le permet, comme recommandé par Ivanti, pour n’autoriser que les adresses IP légitimes à interroger l’API.
    • Surveillez l’utilisation des comptes administrateurs EPMM : toute connexion inhabituelle (horaires anormaux, adresse IP source inconnue) doit générer une alerte et être vérifiée.
    • Segmentez les droits accordés aux comptes d’intégration de l’EPMM : par exemple, si EPMM communique avec un annuaire LDAP, veillez à ce que le compte LDAP utilisé ait les privilèges minimum nécessaires.
    • Exécutez des exercices de tests de pénétration focalisés sur vos déploiements EPMM et plus largement vos applications web exposées, afin d’identifier proactivement d’autres éventuelles vulnérabilités ou mauvaises configurations.
  • Sauvegardes et plans de continuité : assurez-vous de disposer de sauvegardes récentes et isolées (stockées hors-ligne) de la configuration de vos serveurs EPMM et des données critiques associées. En cas de compromission, cela facilitera une restauration rapide sur une version saine du logiciel. Testez régulièrement vos procédures de reprise afin de minimiser le temps d’interruption en cas d’incident majeur.

En appliquant ces mesures de remédiation (patch du logiciel vulnérable) et de durcissement (restrictions supplémentaires, surveillance accrue, bonnes pratiques générales), les organisations peuvent significativement réduire la probabilité d’une telle compromission et en limiter l’impact. L’alerte de la CISA AR25-261A sert de rappel que les systèmes de gestion centralisée, tels qu’Ivanti EPMM, doivent être protégés avec le plus haut niveau de sécurité, compte tenu des conséquences potentiellement systémiques de leur compromission.

Enjoy !

Sources officielles

  • CISA – Analyse AR25-261A : Malicious Listener for Ivanti Endpoint Mobile Management Systems
  • CISA – Malware Analysis Report AR25-261A (PDF) : « Malicious Listener for Ivanti EPMM Systems »
  • CISA – Fichier d’indicateurs MAR-251126.r1.v1 (JSON) : IoCs et artefacts associés à AR25-261A (TLP:CLEAR)