113 lines
4.9 KiB
TeX
113 lines
4.9 KiB
TeX
\documentclass[a4paper,french,12pt]{article}
|
|
|
|
\title{Cyber attaque et défense \\ TP3~: NTLMv2/SMB Relay}
|
|
\author{Adam Belghith, Tunui Franken, Maroua Ombaya}
|
|
\date{Dernière compilation~: \today{} à \currenttime}
|
|
|
|
\usepackage{styles}
|
|
\usepackage{enumitem}
|
|
\usepackage{tikz}
|
|
\usetikzlibrary{shapes}
|
|
|
|
\begin{document}
|
|
|
|
\maketitle
|
|
|
|
\clearpage
|
|
|
|
|
|
\paragraph{Prérequis}
|
|
|
|
\begin{itemize}
|
|
\item Environnement Active Directory fonctionnel~:
|
|
\begin{itemize}
|
|
\item Windows 2016 Server promu en Contrôleur de Domaine.
|
|
\item Deux postes de travail Windows 10 ayant rejoint le domaine.
|
|
Le firewall et l'antivirus doivent être désactivés.
|
|
\end{itemize}
|
|
\item Machine d'attaque.
|
|
\end{itemize}
|
|
|
|
\section{\texttt{ntlmrelayx} avec un payload Meterpreter}
|
|
|
|
En utilisant ce que vous avez appris à faire lors du TP1 et en lisant la documentation de \texttt{ntlmrelayx}, exécutez un payload de type Meterpreter (ou tout autre outil de votre choix) sur la seconde machine.
|
|
Vous pouvez également utiliser MultiRelay (inclus dans Responder) pour arriver au même résultat.
|
|
|
|
On commence par lancer \texttt{msfconsole} sur la machine d'attaque (Kali) pour disposer d'un service en écoute sur le port 9875 et prévu pour un payload Windows avec un \texttt{reverse\_tcp}~:
|
|
|
|
\includegraphics[width=\linewidth]{./img/msfconsole_listen.png}
|
|
|
|
Ensuite, on va utiliser \texttt{ntlmrelayx} pour faire lancer un payload Meterpreter, avec l'IP de la machine Kali en guise de destination.
|
|
|
|
Mais on a besoin d'uploader le payload sur la cible.
|
|
Pour cela, on va demander à \texttt{ntlmrelayx}, de faire exécuter le payload généré par \texttt{msfvenom}, via l'option \texttt{-e}.
|
|
|
|
Commençons donc par créer le payload avec \texttt{msfvenom}~:
|
|
|
|
\includegraphics[width=\linewidth]{./img/msfvenom_create_payload.png}
|
|
|
|
Ceci nous donne un exécutable \texttt{reverse.exe}.
|
|
|
|
En lançant le payload avec \texttt{ntlmrelayx}~:
|
|
|
|
\includegraphics[width=\linewidth]{./img/ntlmrelayx_with_payload.png}
|
|
|
|
\ldots{} on obtient bien un shell Meterpreter~:
|
|
|
|
\includegraphics[width=\linewidth]{./img/meterpreter_run_success.png}
|
|
|
|
\section{Tentative d'attaque sur le DC}
|
|
|
|
Faisons la même chose en prenant cette fois le Domain Controller de l'AD pour cible~:
|
|
|
|
\includegraphics[width=\linewidth]{./img/ntlmrelayx_on_dc.png}
|
|
|
|
On lance une tentative de connexion SMB depuis un des clients Windows, et cette fois la connexion échoue~:
|
|
|
|
\includegraphics[width=\linewidth]{./img/smb_failed.png}
|
|
|
|
La signature SMB est activée par défaut sur les contrôleurs de domaine AD\@.
|
|
Elle permet de vérifier l'origine et l'authenticité d'une requête SMB, rendant impossible une attaque par relai SMB\@.
|
|
|
|
On peut vérifier que \texttt{SMB Signing} est actif sur le DC~:
|
|
|
|
En lançant \texttt{gpedit.msc}, on accède au paramètre voulu~:
|
|
|
|
\includegraphics[width=\linewidth]{./img/smb_signing_active.png}
|
|
|
|
|
|
\section{Remédiation et contre-essai}
|
|
|
|
Nous avons pu voir que l'attaque ne fonctionne par sur un DC, pour la simple raison que le SMB Signing est activé sur le DC\@.
|
|
Depuis Windows 11 pro, Microsoft active le SMB Signing par défaut sur tous les postes, non seulement sur les serveurs AD DC\@.
|
|
|
|
C'est la solution contre cette attaque.
|
|
Activons le SMB Signing sur la machine W10A, et retentons la même attaque que précédemment.
|
|
|
|
Pour faire ça proprement, on va imposer le SMB Signing grâce à une GPO depuis le DC~:
|
|
|
|
\includegraphics[width=\linewidth]{./img/smb_signed_gpo.png}
|
|
|
|
On relance \texttt{msfconsole}, \texttt{ntlmrelayx}, et on fait une tentative d'accès à un partage réseau inexistant, et on constate l'échec de l'attaque~:
|
|
|
|
\includegraphics[width=\linewidth]{./img/smb_failed_bis.png}
|
|
|
|
\section{Synthèse de l'attaque}
|
|
|
|
Nous avons réussi une attaque de relai SMB via l'interception de requêtes LLMNR/NBT-NS\@.
|
|
|
|
Lorsqu'un client effectue une tentative de connexion SMB sur un partage de fichiers inexistant, la requête DNS associée est en échec.
|
|
Le fallback de cette requête est une requête LLMNR/NBT-NS qui expose les hashs NTLM de l'utilisateur.
|
|
|
|
Le mot de passe de l'utilisateur ne nous intéresse pas, on va plutôt faire un vol de session.
|
|
Pour cela, nous redirigeons la requête LLMNR/NBT-NS ailleurs, pour utiliser les droits associés à la requête et effectuer une action différente.
|
|
|
|
L'outil \texttt{ntlmrelayx} permet justement de faire cette redirection, appelée \emph{relai SMB}, et d'utiliser la redirection pour lancer une commande arbitraire.
|
|
|
|
Avec un payload \texttt{msfvenom} en guise de commande \texttt{ntlmrelayx}, on peut obtenir directement un shell Meterpreter via \texttt{msfconsole}.
|
|
|
|
Bien sûr, tout ceci repose sur le fait que le relai SMB soit possible, ce qui nécessite que la cible accepte des requêtes SMB provenant d'une source différente que prévue.
|
|
Le SMB Signing permet de vérifier l'origine et l'authenticité de la requête SMB, bloquant ainsi toute tentative d'attaque par relai SMB\@.
|
|
|
|
|
|
\end{document}
|