Le playbook de l'attaquant

1. Découverte : Les instances AEM exposées sur Internet peuvent être énumérées via des empreintes et des bannières de service.
2. Sondage : Les attaquants recherchent les points de terminaison vulnérables / chemins de débogage Struts et testent le comportement d'évaluation OGNL.
3. Recon (XXE) : Si la XXE est présente, l'attaquant lit des fichiers (configurations, keystores) pour collecter des identifiants et des points de terminaison.
4. RCE (CVE-54253) : Exploite le chemin d'évaluation pour obtenir l'exécution de code ; dépose des webshells, des backdoors, ou crée une persistance.
5. Post-exploitation : Se déplace latéralement, exfiltre des données, ou déploie des rançongiciels/cryptomineurs selon la cible.

Des preuves de concept et des démonstrations publiques ont été publiées dans des dépôts et des recherches de sujets qui agrègent les PoCs — inspectez-les uniquement pour la recherche et le contexte, ne les réutilisez jamais à des fins malveillantes.

Ce que je teste en premier

Quand je teste un environnement, je suis une petite liste de contrôle reproductible, sûre à montrer aux défenseurs et à publier :

• Inventaire : Trouver tous les hôtes AEM exposés sur Internet et internes, et enregistrer les versions. (Commencez par la capture de bannières + l'empreinte applicative.)
• Présence de points de terminaison : Rechercher les points de terminaison admin/debug ou les URLs liées à Struts (sondes non intrusives uniquement).
• Tests de reconnaissance XXE : Utiliser des charges utiles en lecture seule et contrôlées pour détecter le traitement d'entités externes — ne tentez pas de lire des fichiers sensibles sur des systèmes de production sans autorisation.
• Vérifications de configuration : Vérifier si les modes développeur/débogage sont activés, et si les ports d'administration sont exposés à Internet ou à des réseaux trop permissifs.
• Vérification du correctif : Confirmer qu'AEM est mis à jour vers les versions corrigées listées par Adobe dans leur avis.

Ces vérifications me permettent de trier rapidement le risque et de constituer un ensemble de preuves pour la remédiation sans effectuer d'actions destructrices.

Détection et actions de l'équipe bleue

Les défenseurs devraient se concentrer sur quelques indicateurs à fort signal :

• Signatures de logs : POSTs inattendus vers des points de terminaison Struts/OGNL, charges utiles longues contenant des marqueurs d'évaluation, et URIs de requêtes inhabituelles comme les chemins admin/debug. Surveiller et alerter sur ces motifs.
• Modèles d'accès : Hausses soudaines de requêtes provenant d'IP uniques frappant les points de terminaison de formulaires ; requêtes contenant du contenu XML là où du JSON est attendu (possibles essais de XXE).
• Anomalies sortantes : Tentatives de connexions sortantes (DNS/HTTP) des serveurs après le traitement d'une soumission de formulaire — cela peut indiquer une SSRF, des tentatives d'exfiltration XXE, ou des étapes de callback.
• Accès aux fichiers : Lectures inattendues de fichiers de configuration d'application, keystores, ou fichiers /etc dans les logs corrélés à des requêtes suspectes.

Les templates de détection ProjectDiscovery/Nuclei et de la communauté ont rapidement émergé pour ce problème ; les défenseurs peuvent utiliser des templates non exploitants pour identifier les hôtes vulnérables et générer des alertes sans exécuter de code d'exploitation.

Mitigation

1. Corriger immédiatement. Appliquer les correctifs recommandés par Adobe (AEM 6.5.0-0108 ou ultérieur selon le bulletin Adobe). Si vous êtes un ingénieur ops, priorisez les instances exposées à Internet et les clusters.
2. Renforcer le réseau. Restreindre les interfaces d'administration et de gestion avec des ACL/VPN ; éviter d'exposer les chemins d'administration à l'Internet public.
3. Règles WAF / Proxy. Créer des règles pour bloquer les charges utiles de type OGNL et les entrées XML malformées ; ajuster pour réduire les faux positifs.
4. Désactiver les modes dev/debug. De nombreuses compromissions proviennent de fonctionnalités de développeur laissées en place — s'assurer que les images de production sont dépourvues de points de terminaison de débogage et de modes développeur.
5. Inventorier et faire tourner les secrets. Si vous détectez des signes de compromission, faites tourner les clés, secrets et certificats qui ont pu être exposés via XXE ou lecture de configuration.
6. Orchestration et validation des correctifs. Ajouter des vérifications automatisées dans vos pipelines CI/CD ou ops pour vérifier les versions d'AEM et signaler les anomalies.

Divulgation responsable et note éthique

C'est un exemple classique de recherche à double usage : les articles techniques, PoCs et démos d'exploitation existent dans la nature et sont essentiels pour apprendre — mais publier un code d'exploitation pas à pas et armé pour une zero-day dans un logiciel d'entreprise largement déployé profite aux attaquants. Dans mon article, j'évite le code d'exploitation exécutable et me concentre sur la détection, les mitigations et les motifs de test sûrs. Citez les avis et les dépôts de PoC pour le contexte, mais ne publiez pas vous-même des charges utiles d'exploitation.

Conclusion et appel à l'action

Si vous gérez ou auditez des plateformes web d'entreprise, traitez AEM comme un actif de grande valeur : inventoriez chaque instance, corrigez ou mitigez rapidement, et ajoutez des contrôles de détection qui recherchent les empreintes de requêtes spécifiques et les comportements anormaux post-exploitation que j'ai décrits. Pour les auteurs : un article centré sur une CVE qui mélange l'aperçu technique, des recettes de détection sûres et un script d'automatisation qui vérifie uniquement les versions trouvera un écho fort auprès des publics rouge et bleu.