Certiception

Certiception est un honeypot pour les services de certificats Active Directory (ADCS), conçu pour piéger les attaquants avec un appât réaliste et attrayant qui déclenche des alertes très pertinentes.

Développé par la Red Team de SRLabs, Certiception crée un modèle de certificat à l'apparence vulnérable dans votre environnement ADCS, configure des restrictions pour empêcher l'exploitation et facilite la mise en place d'une alerte efficace.

Initialement présenté à Troopers24, Certiception est accompagné d'un guide stratégique pour une déception efficace : Le guide de la déception pour les red teamers

tl;dr : Du point de vue de l'attaquant : ça semble vulnérable, l'exploitation échoue.

Contexte

Lors de nos missions de Red Team et de gestion d'incidents, nous observons régulièrement que les déplacements latéraux et l'élévation de privilèges passent inaperçus. Lorsque des détections se déclenchent, elles ne sont pas traitées rapidement, car les faux positifs sont monnaie courante. Nous pensons que les honeypots internes (alias canaris, alias technologie de déception) sont un moyen efficace pour les défenseurs de détecter les menaces qui franchissent les défenses initiales.

Les honeypots internes sont des pièges intentionnels placés dans votre réseau à destination des attaquants. Ils semblent vulnérables mais déclenchent une alerte en cas d'exploitation. Voici pourquoi nous pensons que la déception a un fort potentiel :

• Effort et coût faibles : La mise en place peut s'appuyer sur des outils existants tels qu'un SIEM.
• Alertes très pertinentes : Un honeypot déclenché signale une menace significative, les alertes méritent donc d'être investiguées.
• Faible bruit : Conçus pour ne se déclencher que sur une activité malveillante, les honeypots internes ont un faible taux de faux positifs.

Malgré leur potentiel, nous rencontrons régulièrement des configurations de déception fondamentalement inefficaces. Pour aider les défenseurs à créer des honeypots plus efficaces, Certiception est fourni avec un guide de stratégie de déception complet.

Active Directory Certificate Services (ADCS) est un emplacement idéal pour un honeypot :

1. Accès facile : Accessible à tous les utilisateurs du domaine, ADCS est facile à découvrir pour les attaquants.
2. Enjeux élevés : Les vulnérabilités peuvent conduire à une compromission complète du domaine, ce qui rend l'exploitation très attractive.
3. Notoriété : Les vulnérabilités et les outils d'exploitation sont largement connus.
4. Authenticité : Les modèles ADCS vulnérables sont courants, ce qui ne suscite guère de méfiance.
5. Sous-surveillé : De nombreux réseaux surveillent à peine ADCS, ce qui encourage même les attaquants prudents à tenter l'exploitation.

C'est pourquoi nous avons créé Certiception.

Concept

Certiception installe une nouvelle AC dans votre environnement et configure un honeypot ESC1.

Elle est implémentée sous forme d'un playbook Ansible qui appelle plusieurs rôles. Globalement, les étapes suivantes sont exécutées :

• Mettre en place une nouvelle AC, ajouter un modèle ESC1 « vulnérable » et ne l'activer que sur la nouvelle AC
• Installer et configurer le module de stratégie TameMyCerts pour empêcher l'émission si les demandes de signature de certificat contiennent un SAN
• Activer le journal d'audit étendu pour inclure les noms de modèles dans les journaux d'événements
• Afficher une règle SIGMA pour configurer l'alerte dans votre SIEM
• Mettre en place des vérifications continues avec Certify pour détecter toute autre AC activant le modèle vulnérable (pas encore publié, sera ajouté au dépôt dans les prochains jours)

Des paramètres tels que le nom de l'AC ou du modèle peuvent être personnalisés pour déguiser le honeypot.

Voici donc comment fonctionne Certiception :

La prise en charge d'autres types de vulnérabilités ESC et la possibilité d'ajouter des modèles leurres à des AC existantes sont prévues pour l'avenir.

Alertes

Certiception utilise les événements Windows intégrés de l'AC et les événements générés par le module de stratégie TameMyCerts. Pour obtenir les événements AC intégrés avec les informations requises, Certiception active le journal d'audit étendu sur le serveur AC leurre.

Nous suggérons de configurer des alertes sur les événements critiques et moyens :

Certiception génère des règles SIGMA prêtes à l'emploi pour les deux alertes. Vous devez simplement vous assurer que les ID d'événements correspondants sont intégrés dans votre SIEM, puis configurer les alertes avec les règles SIGMA.

Les futures versions pourraient introduire des règles SIGMA nouvelles ou supplémentaires.

Utilisation

Suivez ces étapes pour configurer votre honeypot ADCS.

Prérequis

• Serveur Windows joint au domaine pour installer l'AC
• Machine disposant d'Ansible et d'une connectivité WinRM vers le serveur pour cloner ce dépôt et exécuter Certiception
• Privilèges d'administrateur local sur le serveur pour installer l'AC et les protections contre l'exploitation
• Compte Enterprise Admin pour enregistrer la nouvelle AC
• Compte de domaine de base sans aucun privilège pour exécuter les vérifications continues Certify

Installation de Certiception

Note : nous améliorons encore la stabilité dans différentes configurations de laboratoire concernant les comptes utilisés pour les tâches d'installation. Si vous voulez l'essayer, il vaut probablement mieux attendre encore une semaine :)

1. Configurez vos paramètres généraux de domaine et de connexion Ansible dans inventory
2. Personnalisez les paramètres de votre honeypot dans host_vars/honeypotCA.yml
3. Créez une exception EDR pour le futur emplacement de Certify (utilisé pour surveiller si des AC non leurres activent le modèle vulnérable, pas encore requis car la surveillance basée sur Certify n'est pas encore publiée)
4. Exécutez le playbook Ansible Certiception

ansible-playbook -i inventory playbooks/certiception.yml

4. Intégrez les journaux d'événements du serveur dans votre SIEM et configurez les alertes avec les règles SIGMA affichées
5. Vérifiez et testez manuellement votre configuration

Considérations de sûreté et de sécurité

Cet outillage est fourni sans aucune garantie. Il combine des logiciels existants et automatise l'installation et la configuration. Vous êtes responsable de toutes les étapes d'installation et de configuration effectuées par Certiception.

Si vous utilisez cet outil, nous vous recommandons vivement de lire le code source pour comprendre ce que vous configurez et de vérifier votre configuration après l'installation.

De plus, nous recommandons de tenir compte des points suivants :

1. Au moment de la publication, l'outil n'a pas encore été examiné par la communauté - attendez-vous à des améliorations de sécurité et de durcissement au fil du temps. Nous ne recommandons pas de l'exécuter sans modification dans votre environnement de production.
2. Un honeypot ADCS n'a de sens que si l'équipe PKI en assume la responsabilité. Lors de modifications de configuration, il faut prendre en compte les implications sur le honeypot. Par exemple, lors de la migration de l'AC leurre vers un nouveau serveur sans migrer également le module de stratégie, le modèle leurre devient exploitable.
3. Outre le modèle leurre, votre AC leurre doit être sécurisée, durcie et gérée comme toute autre AC ADCS de votre réseau.
4. L'AC configurée par cet outil est une AC simple dont le certificat d'AC est stocké sur le disque et sans HSM.
5. Certiception met en place une vérification de base des modèles réellement vulnérables à l'aide de Certify sur le serveur AC. Pour les environnements de production, nous recommandons d'exécuter ces vérifications continues sur une machine séparée. Les vérifications ne doivent pas seulement reposer sur des commandes « find » pour identifier les modèles, mais aussi tenter d'exploiter le modèle leurre (autorisé dans le SIEM) afin de détecter les changements de configuration qui le rendent exploitable sur l'AC leurre.

Travaux futurs

• Prendre en charge le placement de modèles leurres sur des AC existantes
• Implémenter la prise en charge d'un plus grand nombre d'erreurs de configuration ESC (par ex. ESC3 et ESC8)
• Implémenter des garde-fous supplémentaires et des options de durcissement pour éviter que les choses tournent mal
• Utiliser des comptes à privilèges réduits au lieu d'un compte Enterprise Admin
• Ajouter un message d'erreur moins suspect lors des CSR refusées
• Étudier et atténuer les moyens d'empreinte (fingerprinting) de Certiception
• Renforcer la surveillance continue destinée à détecter et à atténuer les configurations non sécurisées
• Durcissement du script d'installation (par ex. étudier l'exposition des identifiants des comptes utilisés)

Licence

• Certiception de SRLabs est publié sous la Licence Apache-2.0
• L'ADCSTemplate d'Ashley McGlone est disponible selon les termes de la Licence MIT
• Le TameMyCerts d'Uwe Gradenegger relève de la Licence Apache-2.0

Remerciements

• Uwe Gradenegger pour son excellent blog sur la PKI et ADCS et en tant que développeur du module de stratégie TameMyCerts
• Ashley McGlone pour les scripts ADCSTemplate que nous utilisons pour créer le modèle leurre
• @harmj0y et @tifkin_ pour leurs recherches sur ADCS et l'outil Certify correspondant
• @ly4k_ qui a découvert ESC9 et ESC10 (et développe Certipy)
• @sploutchy pour ESC11
• Hans-Joachim Knobloch pour ESC12
• @Jonas_B_K et @_wald0 pour l'audit d'ADCS avec Bloodhound et ESC13
• @PyroTek3 pour ses travaux précédents sur les honeypots Active Directory
• @gentilkiwi pour son inspiration, comme celle-ci
• Tous les amis et collègues qui ont apporté leurs idées et retours pour notre conférence et notre développement