efrei/cyber-attaque-defense/tp3/main.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}