Problèmes connus

Si DavRelayUp reste bloqué à l'une de ces étapes – essayez d'utiliser un port différent en précisant le paramètre [-p].

Exemples

https://github.com/Dec0ne/DavRelayUp/assets/54464773/4e791e8b-783c-48d3-b46b-8b22e2661ea1

Construction

0. Construire GoRelayServer (déjà construit et prêt dans ce dépôt, mais si vous voulez le faire vous‑même)
   root@kitploit:~

   PS C:\Tools\DavRelayUp> cd GoRelayServer
   PS C:\Tools\DavRelayUp\GoRelayServer> go build --buildmode=c-shared -ldflags="-s -w"  -o "../DavRelayUp/Costura64/GoRelayServer.dll" main.go
   

   Ceci construira la DLL GoRelayServer et l'enregistrera dans "DavRelayUp\DavRelayUp\Costura64\GoRelayServer.dll" – c'est le dossier depuis lequel Costura.Fody l'intégrera dans l'exécutable final DavRelayUp.exe.
1. Ouvrir KrbRelayUp.sln dans Visual Studio 2019
2. Assurez-vous que la configuration de la solution est définie sur Release et appuyez sur Générer (CTRL+MAJ+B)

À FAIRE

• Ajouter l'attaque ShadowCred comme méthode RELAIS
• Ajouter le support U2U pour permettre l'attaque sans nécessiter de compte machine

Atténuation & Détection

• Appliquer la signature LDAP et la liaison de canal LDAP pour atténuer le relai de l'authentification du compte machine vers LDAP. Cela peut être configuré via la stratégie de groupe « Configuration requise pour la signature du serveur LDAP du contrôleur de domaine ». (Merci à Will Dormann pour son tweet à ce sujet)
• Rendre les conditions requises de l'attaque plus difficiles à obtenir en définissant l'attribut MS-DS-Machine-Account-Quota dans l'AD à 0, supprimant ainsi la capacité de tout utilisateur d'ajouter un nouveau compte machine au domaine. Il s'agit d'un paramètre par défaut dangereux dans l'AD – assurez-vous de le modifier.
• Définir le drapeau « Le compte est sensible et ne peut pas être délégué » sur tous les comptes administrateur (ou les placer dans les utilisateurs protégés) ferait en sorte qu'il n'y ait aucun compte avec les privilèges requis pouvant être délégué pour terminer le chemin d'attaque. (Merci à Christoph Falta pour ce tweet)
• Ressources pour des règles possibles de surveillance et de détection :
  1. https://github.com/tsale/Sigma_rules/blob/main/windows_exploitation/KrbRelayUp.yml (@Kostastsale)
  2. https://twitter.com/SBousseaden/status/1518976397364056071 (@SBousseaden). Principalement la règle concernant l'authentification au Service Manager via Kerberos depuis 127.0.0.1, excellent travail !.
  3. https://www.linkedin.com/posts/john-dwyer-xforce_threathunting-threatdetection-blueteam-activity-6924739962131140608-py45/ (John Dwyer @TactiKoolSec)

Remerciements

• James Forshaw pour avoir compris comment utiliser les tickets de service Kerberos pour l'authentification LOCALE au Service Manager, ce qui était la pièce manquante du puzzle pour rendre cette primitive d'attaque uniquement locale (avant cela, nous devions exporter le ST vers une machine distante pour l'utiliser et obtenir un accès privilégié à notre machine cible).
• Kevin Robertson pour sa fonctionnalité New-MachineAccount utilisée dans ce projet.
• Cube0x0 pour sa fonctionnalité SharpSystemTriggers (plus précisément SharpEfsTrigger) utilisée dans ce projet.
• Elad Shamir pour ses recherches sur RBCD – Wagging the Dog
• Will Schroeder et tous ceux qui ont contribué à Rubeus que nous connaissons et aimons tous. En gros, toutes les fonctionnalités RBCD-S4U proviennent de là.
• Orange-Cyberdefense pour leur travail sur GOAD, le laboratoire de recherche Active Directory que j'utilise et que vous pouvez voir dans la vidéo de démonstration et les images.
• Shantanu Khandelwal pour son article de blog sympa sur Red Team: How to embed Golang tools in C#
• GoRelayServer a été construit sur la base du travail effectué sur go-ldap que j'ai modifié pour permettre le relai NTLM webdav-to-ldap. Merci également à Mariusz Banach pour SharpWebServer que j'ai utilisé pour apprendre comment fonctionne l'authentification NTLM webdav et l'ai implémenté comme écouteur serveur dans GoRelayServer.