Dominez le domaine. Relaie vers la royauté.
RelayKing est un outil complet de détection et d'énumération de relais conçu pour identifier les opportunités d'attaques par relais dans les environnements Active Directory. Véritables options de rapport. Couverture complète des attaques. Trouvez les vecteurs de relais cachés et rapportez-les dans le format de sortie de votre choix. Alimentez ntlmrelayx.py d'Impacket avec une liste cible organisée d'hôtes détectés et relayables. Ne manquez plus jamais un chemin de relais NTLM critique et exploitable dans le domaine.
Voir le blog associé publié sur le site de Depth Security pour plus de détails : https://www.depthsecurity.com/blog/introducing-relayking-relay-to-royalty/
**RelayKing N'EST PAS UN OUTIL OPSEC-FRIENDLY DANS CERTAINS MODES, PARTICULIÈREMENT EN MODE --audit.
RelayKing est fourni EN L'ÉTAT SANS AUCUNE GARANTIE. Voir le bas du readme.
# Use a venv. Save yourself the hassle.
# Clone repo:
git clone https://github.com/depthsecurity/RelayKing-Depth.git
#Navigate to cloned dir:
cd RelayKing-Depth/
# Configure Python venv:
virtualenv --python=python3 .
source bin/activate
# Install deps:
pip3 install -r requirements.txt
# Validate RelayKing installation was successful:
python3 relayking.py -h
--remove-mic de ntlmrelayx. Signalé comme ÉLEVÉ. Utilise l'UBR déjà interrogé par hôte, sans requêtes réseau supplémentaires.--audit, interroge Active Directory pour les noms de principaux de service dont les noms d'hôte n'ont pas d'enregistrement DNS. Un attaquant peut enregistrer le nom DNS manquant pour intercepter l'authentification NTLM destinée à ce principal de service. Les résultats sont divisés en vulnérables (aucun enregistrement DNS du tout) et probablement vulnérables (résolu uniquement via DNS générique). Signalé comme MOYEN. Les résultats complets sont écrits dans possible-ghost-spns.txt. Supprimez avec --no-ghosts.--ntlmv1 ou --ntlmv1-all - détection inter-protocole uniquement lorsque l'utilisation confirmée de Net-NTLMv1 est découverte)--remove-mic)possible-ghost-spns.txt(--audit) : Énumère tous les ordinateurs depuis AD via LDAP. Nécessite des identifiants AD à faibles privilèges et un DNS fonctionnel dans l'environnement. Forcer avec --dc-ip ou modifier /etc/resolv.conf.10.0.0.0/24)10.0.0.1-254)python3 relayking.py -u user -p pass -d domain.local <votre_ip_ou_nom_hote_cible>)--coerce-all combiné avec --audit et des identifiants à faibles privilèges pour forcer CHAQUE machine du domaine en vue d'un relais de comptes machines de masse. Très utile dans les environnements avec Net-NTLMv1 activé.--ntlmv1 ou --ntlmv1-all pour détecter les GPO LanMan au niveau du domaine. --ntlmv1-all vérifie TOUS les hôtes depuis AD et leurs valeurs de registre via RemoteRegistry. (nécessite un administrateur local).--gen-relay-list <fichier> pour produire un fichier cible prêt à être importé pour le commutateur -tf de ntlmrelayx.py.--audit lorsque des identifiants sont présents. Supprimez avec --no-ghosts. Les résultats complets sont écrits dans possible-ghost-spns.txt en parallèle du rapport principal ; le rapport lui-même affiche les 5 premiers pour éviter l'encombrement.-h, comme prévu :python3 relayking.py -h
python3 relayking.py -u ‘lowpriv’ -p ‘lowpriv-password’ -d client.domain.local --dc-ip 10.0.0.1 -vv --audit --protocols smb,ldap,ldaps,mssql,http,https --threads 10 -o plaintext,json --output-file relayking-scan --proto-portscan --ntlmv1 --gen-relay-list relaytargets.txt
python3 relayking.py -u ‘lowpriv’ -p ‘lowpriv-password’ -d client.domain.local --dc-ip 10.0.0.1 -vv --audit --protocols smb,ldap,ldaps,mssql -o plaintext,json --output-file relayking-scan --proto-portscan --gen-relay-list relaytargets.txt
python3 relayking.py -u ‘lowpriv’ -p ‘lowpriv-password’ -d client.domain.local -vv --protocols smb,ldap,ldaps,mssql,http,https -o plaintext SERVER1-EXAMPLE.LAB.LOCAL
python3 relayking.py --null-auth -vv --protocols smb,ldap,http -o plaintext 10.0.0.0/24
python3 relayking.py -u ‘lowpriv’ -p ‘lowpriv-password’ -d client.domain.local --dc-ip 10.0.0.1 -vv --audit --protocols smb,ldap,ldaps,mssql,http,https --threads 10 -o plaintext,json --output-file relayking-scan --proto-portscan --ntlmv1-all --gen-relay-list relaytargets.txt
--threads. Chaque thread principal obtient des threads de travail pour certaines tâches en dessous. HTTP, par exemple, utilise 20 threads par thread principal. Cela donne environ 200 threads HTTP ouverts pour scanner l'authentification NTLM HTTP. La plupart du temps, cela est bien toléré, mais si cela provoque des ralentissements/problèmes réseau, réduisez le nombre de threads. La valeur par défaut de 10 threads est de toute façon exceptionnellement rapide.--proto-portscan avec tous vos scans. Cela améliore considérablement les performances et empêche le scanneur d'attendre des timeouts sur des ports qui n'existent pas. Si cela pose problème, vous pouvez le retirer au détriment des performances de scan (mais cela ne devrait pas !)--max-scangroup, --split-into et --skip peuvent être utilisées pour contrôler le regroupement.--max-scangroup pour indiquer le nombre de cibles pour chaque groupe. Par exemple, --max-scangroup 100 divisera 299 cibles en 3 groupes. Les groupes auront des cibles de 100, 100 et 99.--split-into pour indiquer le nombre de groupes. Par exemple, --split-into 3 divisera 299 cibles en 3 groupes. Les groupes auront des cibles de 100, 100 et 99. Vous ne pouvez pas spécifier à la fois --max-scangroup et --split-into.--skip pour sauter des groupes. Par exemple, --max-scangroup 3 --skip 1 divisera 299 cibles en 3 groupes de 100, 100 et 99 cibles, et sautera le premier groupe puis commencera le scan à partir du deuxième groupe. Cela aide lorsque vous souhaitez redémarrer cet outil.--ntlmv1 ou -ntlmv1-all : Ajouter --ntlmv1 récupérera chaque GPO LanMan pour le domaine et rien d'autre. Nécessite des identifiants AD à faibles privilèges. --ntlmv1-all nécessite des identifiants administrateur et vérifiera chaque hôte individuel dans le domaine avec SMB ouvert pour la clé de registre LMCompatibilityLevel. Exécuter au moins --ntlmv1 est requis pour afficher/détecter les chemins de relais SMB inter-protocole.
--ntlmv1-all. De plus, très lourd et pas OPSEC-safe, mais exhaustif. Probablement déconseillé sauf si vous êtes en mode YOLO ou désespéré.-o json,plaintext) et --output-file relayking-scan produit relayking-scan.json + relayking-scan.txt, donc il n'est pas nécessaire de l'exécuter deux fois pour plusieurs formats. Disponibles : plaintext, json, xml, csv, grep, markdown (par défaut : plaintext)--coerce-all utilisera PetitPotam, DFSCoerce et PrinterBug sur TOUS LES HÔTES CIBLÉS. Elle force également en masse chaque machine du domaine sans exécuter l'audit de protocole complet. Fournir + en effectuera un audit du domaine une coercition de masse. ()--opsec-safe qui évite l'utilisation d'Impacket/autres bibliothèques Python empreintes. Pas trivial à implémenter.--ntlmv1, le validateur d'identifiants, le module Ghost SPN ET l'analyseur de cibles font tous chacun leur propre authentification. C'EST ABSOLUMENT RIDICULE et doit être consolidé pour utiliser un seul module d'authentification.-vv ou -vvv si vous rencontrez des erreurs. La journalisation continue de s'améliorer avec chaque version.--audit et RelayKing ne parvient pas à résoudre les hôtes dans DNS parce que leurs serveurs DNS refusent de résoudre leurs FQDN d'ordinateurs dans la zone DNS cible. Ce n'est pas un problème de RelayKing.En l'état. De nombreux bugs existent certainement. Voir ci-dessus. Non conçu ou destiné à des activités illégales/non autorisées, évidemment.
Considérez le comportement et la nature de TOUS les outils que vous exécutez pour un client et sur ses réseaux. Cela se fait en lisant le code source de l'outil et en comprenant son fonctionnement interne avant l'exécution, et non en exécutant aveuglément du code que vous avez trouvé sur GitHub. Bien que je puisse vous assurer qu'il n'y a pas de code délibérément malveillant/destructeur dans RelayKing, il est généralement de bonne pratique de valider tous les outils nouveaux/non utilisés avant de les exécuter. Faites confiance, mais vérifiez toujours.
Soyez prudent lors de l'utilisation lors d'exercices d'équipe rouge, en particulier avec les vérifications authentifiées et --audit. Vous SEREZ détecté et ce sera de votre faute ! Vous devriez avoir lu l'avertissement en haut du README si vous lisez cette phrase et ne le saviez pas déjà.
Bien que extrêmement improbable/imprévu, si RelayKing casse quelque chose, vous êtes seul, et ni l'Auteur ni Depth Security ne sont responsables des conséquences/problèmes/explosions nucléaires de retournement de bits géospatiaux qui pourraient éventuellement survenir (aussi improbable soit-il) de l'exécution de RelayKing. Votre kilométrage peut varier. RelayKing est, encore une fois, fourni SANS AUCUNE GARANTIE DE RÉSULTATS, FONCTIONNALITÉS, UTILITÉ OU COMPORTEMENT SPÉCIFIQUES - EXPLICITEMENT MENTIONNÉS ICI (ET/OU NON MENTIONNÉS) OU AUTREMENT IMPLICITES.
Le seul dépôt GitHub légitime de l'Auteur (logansdiomedi) se trouve à l'adresse https://github.com/depthsecurity/RelayKing-Depth - tous les autres sont des forks/copies/quoi que ce soit d'autre, l'Auteur ne les a probablement pas lus, validés, testés, analysés ou inspectés pour leur fonctionnalité/comportement/légitimité. Utilisez votre tête.
MIT License - voir le fichier LICENSE pour plus de détails
--dc-ip--krb-dc-only--dns-tcp-ns--audit--coerce--audit uniquement) : Après la fin du scan des hôtes, RelayKing interroge AD pour les SPN dont les noms d'hôte n'ont pas d'enregistrement DNS. Ce sont des candidats pour des attaques d'enregistrement DNS qui interceptent l'authentification NTLM. Le rapport inclut jusqu'à 5 résultats pour garder la sortie gérable ; la liste complète est toujours écrite dans possible-ghost-spns.txt dans le répertoire de travail. Passez --no-ghosts pour ignorer complètement cette vérification.--remove-mic de ntlmrelayx.