Un mal nécessaire.

Les 3 façons de faire de la délégation Kerberos.

Exemple pratique : se faire passer pour n'importe qui.

PSEXEC -i -s -d PowerShell

$u = New-Object System.Security.Principal.WindowsIdentity("piaudonnmsdn@verenatex.com") 
$u.Impersonate()

On va tous mourir ! Il faut désactiver la délégation !

1. Il faut s'assurer que seulement les administrateurs de domaine peuvent configurer la delegation. C'est un paramètre de sécurité généralement configure dans la Default Domain Controller Policy:
2. Il faut s'assurer qu'on utilise la délégation sur le bon compte et que c'est bel et bien requis pour l'application. Configurer la delegation peut des fois s'avérer laborieux. On teste plein de possibilités, et puis hop cela marche et on touche plus... Du coup, il est bien possible que certains comptes ait été touchés pour rien. Il faut les corriger.
3. Il faut s'assurer qu'on utilise la délégation contrainte en spécifiant les services (SPN) plutôt que la méthode old school Windows 2000 Server lorsque la délégation est nécéssaire.
4. Et enfin securiser les groupes administrateurs locaux des serveurs où les comptes sont utilisés. En utilisant la fonctionalité de groupes restreints des stratégies de groupe par exemple.

Lister les comptes à risque.

1. Lister les comptes machines configurés pour la délégation à la mode 2000:

   Get-ADObject -LDAPFilter:"(&(objectCategory=computer)(objectClass=computer)(userAccountControl:1.2.840.113556.1.4.803:=524288))"

   Notez que cela retourne aussi les contrôleurs de domaine. Pas de panique, c'est attendu, pas besoin de les modifier.
2. Lister les comptes utilsateurs configurés pour la délégation à la mode 2000:

   Get-ADObject -LDAPFilter:"(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=524288))"

3. Lister les comptes machines configurés pour la délégation avec transition de protocole :

   Get-ADObject -LDAPFilter:"(&(objectCategory=computer)(objectClass=computer)(userAccountControl:1.2.840.113556.1.4.803:=16777216))"

4. Lister les comptes utilsateurs configurés pour la délégation avec transition de protocole :

   Get-ADObject -LDAPFilter:"(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=16777216))"

Le transfert d'évènements, c'est quoi ?

Magie ?

Préparer le serveur qui va recevoir les évènements

1. S'il n'est pas déjà configuré pour écouter sur le réseau, configurer le service WinRM (Windows Remote Management). Il est déjà activé et configuré pour écouter par défaut avec Windows Server 2012 et Windows Server 2012 R2. Si ce n'est pas le cas, ou si vous souhaitez vérifier, vous pouvez exécuter les commandes suivantes (notez que si c'est déjà configuré sur votre système et que vous re-exécutez les commandes, cela ne cassera rien et vous dira juste que c'est en fait déjà configuré). Pour configurer le service, ouvrez une console en mode administrateur et tapez :

   winrm qc

   Le message suivant va s'afficher :
   Tapez Y puis [Enter]. Le message suivant va s'afficher :
   Cela va automatiquement activer les règles de pare feux pour autoriser les connections entrantes pour WinRM.
2. Activez le service de transfert et de collection des évènements. Ouvrez l'observateur d'évènements et cliquez sur la section Abonnements (Subscriptions). Cliquez sur Oui (Yes). Cela va activer le service Windows Event Collector. Notez que dorénavant, lorsque vous allez dans la partie Abonnements, on ne vous demandera plus d'activer le service. Notez aussi que le service est configuré en Delayed Start. Donc si la machine vient juste de démarrer et que vous accédez à la partie Abonnements de l'Observateur d'évènements tout de suite, il se peut que le service ne soit pas encore démarré et dans ce cas vous verrez de nouveau le pop-up (cela n'efface rien des éventuelles configurations que vous auriez pu faire auparavant).

Préparer l'abonnement

<QueryList>
 <Query Id="0" Path="Security">
  <Select Path="Security">
  Event[
   System[
    EventID=4624
   ] and EventData[
      Data[@Name="LmPackageName"]="NTLM V1" and Data[@Name="TargetUserSid"]!="S-1-5-7"
   ]
  ]
  </Select>
 </Query>
</QueryList>

Préparer et abonner les serveurs

1. Configurer l'adresse à laquelle le serveur va aller vérifier s'il a des abonnements.
2. S'assurer que le plug-in responsable de scruter les évènements 4624 a bien la permission de lire le journal de sécurité.

• Computer Configuration > Policies > Administrative Templates > Windows Components > Event Forwarding > Configure target Subscription Manager. Activez le paramètre et entrez l'URL suivante : Server=https://<serveur configure pour la collection>:5985/wsman/SubscriptionManager/WEC (le port sera ouvert et vous avez exécuté WimRM qc sur la machine de destination et cela a aussi activé la règle de pare feu). N'oubliez pas le début Server=. Cela fait bien partie du paramètre comme vous pouvez le voir dans la capture suivante :

• Computer Configuration > Policies > Administrative Templates > Windows Components > Event Log Service > Security. Dans la partie Log Access, entrez la valeur suivante: O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20) La partie (A;;0x1;;;S-1-5-20) est celle qui ajoute NETWORK SERVICE la permission de lire le journal (si cette notation vous parait mystérieuse, je vous invite à vous documenter sur le format SDDL (en anglais). Voici à quoi cela ressemble dans la stratégie de groupe :

Voilà !

NTLM 101

1. Alice accède au partage.
2. Le serveur de fichier lui signale qu'il faut s'authentifier avec NTLM, et pour cela, le serveur de fichier génère un Challenge (un nombre aléatoire) et l'envoie à Alice.
3. Alice utilise ce Challenge, elle prend le condensé de son mot de passe (hash), le passe dans une fonction avec le Challenge et obtient une Réponse (NTLM Response). Elle envoie le tout au serveur de fichier.
4. Idéalement, le serveur de fichier doit vérifier si la Réponse est la bonne. Et pour ce faire, le serveur a besoin du condensé de mot de passe pour Alice puis, a besoin d'effectuer le même calcul qu'elle pour vérifier s'il obtient la même réponse. Mais Alice étant une utilisatrice du domaine, le serveur de fichier ne connaît pas son condensé de mot de passe... Et du coup le serveur envoie le tout à un serveur qui lui connaît le condensé et pourra faire le calcul : le contrôleur de domaine. C'est un concept clé de l'authentification NTML appelé : NTLM Pass-Through (on passe à travers le serveur pour l'authentification).
5. Le contrôleur de domaine a reçu du serveur de fichier le nom d'utilisateur, le Challenge et la Réponse. Il calcule sa propre réponse basée sur sa connaissance du condensé de mot de passe pour Alice (c'est dans la base de données Active Directory) et la compare avec la réponse envoyée. Si c'est la même, il répond au serveur de fichier que c'est bon. Si ce n'est pas bon, il en fait de même.
6. Si le serveur de fichier a reçu l'accord du contrôleur de domaine, Alice peut continuer d'accéder au serveur de fichier, sinon Alice n'a pas accès.

Et la version alors?

Auditer tout cela...

• Sur le serveur où se trouve la ressource : 4624
• Sur le contrôleur de domaine : 4776

1. SRV01 accepte NTLMv1.
2. SRV02 envoie du NTLMv1.
3. Le contrôleur de domaine à qui l'authentification NTLM Pass-Through a été transférée accepte aussi NTLMv1.

auditpol /get /category:"Logon/Logoff"

System audit policy
Category/Subcategory                      Setting
Logon/Logoff
  Logon                                   Success and Failure
...

Filtrer les évènements relatifs a l'utilisation de NTLMv1

<QueryList>
 <Query Id="0" Path="Security">
  <Select Path="Security">
  Event[
   System[
    EventID=4624
   ] and EventData[
      Data[@Name="LmPackageName"]="NTLM V1"
   ]
  ]
  </Select>
 </Query>
</QueryList>

Bruit anonyme et filtre final

<QueryList>
 <Query Id="0" Path="Security">
  <Select Path="Security">
  Event[
   System[
    EventID=4624
   ] and EventData[
      Data[@Name="LmPackageName"]="NTLM V1" and Data[@Name="TargetUserSid"]!="S-1-5-7"
   ]
  ]
  </Select>
 </Query>
</QueryList>

Étape suivante, collecter l'information sur tous les serveurs

Pourquoi désactiver NTLMv1?

Section: Security Considerations for Implementers tirée de [MS-NLMP]: NT LAN Manager (NTLM) Authentication Protocol

Je n'ai aucune idée de qui (ou quoi) l'utilise dans mon environnement...

1. La manière forte: désactiver la fonctionnalité, et regarder fixement le téléphone en espérant que l'on n'a rien cassé.
2. La manière faible: envoyer un message à toutes les applications et leur demander, s'ils leur plaisent, de ne pas utiliser NTLMv1. Bon, en général, soit ils ne savent pas qu'ils l'utilisent, soit ils ignorent le message et quand tu le désactives, ils ont l'impression que vous avez utilisé la première manière...
3. La manière geek! On active l'audit (la plupart du temps, une grande partie de cet audit est déjà configuré par défaut), et on observe qui l'utilise (en éventuellement, on peut travailler avec eux -une fois identifié- pour s'en débarrasser).

Phase 1 : Identifier qui et quoi utilisent NTLMv1 dans votre environnement.

Phase 2 : Consolider l'information.

Phase 3 : Contacter les applications.