GREY-X // WINDOWS LAB
netsh interface portproxy — TCP PORT FORWARDING
Windows possède nativement un mécanisme permettant de rediriger des connexions TCP d’un port local vers une autre adresse et un autre port.
La commande utilisée est :
netsh interface portproxy
C’est particulièrement intéressant en cybersécurité pour comprendre :
Port Forwarding
TCP Redirection
Pivoting
Network Segmentation
Access Control
Contrairement à :
netsh winhttp
qui concerne la configuration d’un proxy WinHTTP, portproxy travaille au niveau du trafic TCP.
01 // Le concept
Link to heading
Imaginons :
ATTACKER
│
│ TCP :8080
▼
WINDOWS PIVOT
│
│ TCP :80
▼
INTERNAL SERVER
Le poste Windows joue ici le rôle d’intermédiaire.
L’attaquant se connecte à :
WINDOWS:8080
et Windows transmet la connexion vers :
INTERNAL-SERVER:80
On peut représenter le flux :
CLIENT
│
│ TCP :8080
▼
WINDOWS
│
│ TCP :80
▼
SERVER
02 // Syntaxe
Link to heading
La syntaxe principale est :
netsh interface portproxy add v4tov4 ^
listenaddress=0.0.0.0 ^
listenport=8080 ^
connectaddress=10.10.20.10 ^
connectport=80
Les paramètres importants :
listenaddress
→ adresse sur laquelle Windows écoute
listenport
→ port exposé localement
connectaddress
→ destination réelle
connectport
→ port de destination
Dans notre exemple :
0.0.0.0:8080
↓
10.10.20.10:80
03 // Comprendre v4tov4
Link to heading
La commande :
v4tov4
signifie :
IPv4 → IPv4
Windows propose également des variantes pour les environnements IPv6.
Dans un laboratoire IPv4 classique, on utilisera généralement :
netsh interface portproxy add v4tov4
04 // Créer une redirection
Link to heading
Exemple de laboratoire :
Windows Pivot
192.168.1.50
Serveur interne
10.10.10.20:80
Sur Windows :
netsh interface portproxy add v4tov4 ^
listenaddress=192.168.1.50 ^
listenport=8080 ^
connectaddress=10.10.10.20 ^
connectport=80
La topologie devient :
CLIENT
│
│ 192.168.1.50:8080
▼
WINDOWS
│
│ 10.10.10.20:80
▼
INTERNAL SERVER
Le client n’a donc pas besoin de se connecter directement au serveur interne.
05 // Lister les règles
Link to heading
Pour afficher les règles existantes :
netsh interface portproxy show all
Exemple :
Listen on ipv4: Connect to ipv4:
Address Port Address Port
--------------- -------- --------------- --------
192.168.1.50 8080 10.10.10.20 80
Cette commande est particulièrement importante en audit.
Elle permet de découvrir :
ports exposés
destinations internes
interfaces utilisées
redirections TCP
06 // Tester le port
Link to heading
Après avoir créé une règle, on peut vérifier que Windows écoute :
netstat -ano | findstr :8080
Ou avec PowerShell :
Get-NetTCPConnection -LocalPort 8080
L’objectif est de vérifier :
LISTENING
sur le port configuré.
07 // Tester depuis une autre machine
Link to heading
Depuis une machine du laboratoire :
curl http://192.168.1.50:8080
ou avec PowerShell :
Test-NetConnection 192.168.1.50 -Port 8080
Le flux attendu est :
Client
│
│ :8080
▼
192.168.1.50
│
│ :80
▼
10.10.10.20
08 // Pourquoi c'est intéressant en Red Team ?
Link to heading
portproxy devient particulièrement intéressant lorsqu’une machine possède accès à plusieurs réseaux.
Exemple :
INTERNET
│
│
┌──────▼──────┐
│ Windows │
│ Pivot │
│ │
│ 192.168.1.50│
│ 10.10.10.50 │
└──────┬──────┘
│
│
INTERNAL NETWORK
│
┌────────┴────────┐
▼ ▼
10.10.10.20 10.10.10.30
WEB DB
La machine Windows possède une visibilité réseau que l’autre machine n’a peut-être pas.
On peut alors étudier le concept :
ACCESS
↓
PIVOT
↓
PORT FORWARD
↓
INTERNAL SERVICE
Dans un pentest autorisé, cela permet notamment de démontrer l’impact d’une compromission d’un poste disposant d’une double connectivité.
09 // Port forwarding ≠ routage
Link to heading
C’est une distinction importante.
Avec portproxy :
TCP CONNECTION
↓
PORT FORWARD
↓
DESTINATION
Ce n’est pas la même chose qu’un routeur IP classique.
Le port forwarding concerne ici une connexion TCP donnée.
On peut donc avoir :
192.168.1.50:8080
↓
10.10.10.20:80
sans transformer Windows en routeur permettant automatiquement à tout le trafic IP de traverser la machine.
10 // Supprimer une règle
Link to heading
Pour supprimer la redirection :
netsh interface portproxy delete v4tov4 ^
listenaddress=192.168.1.50 ^
listenport=8080
Puis :
netsh interface portproxy show all
La règle ne doit plus apparaître.
Dans un laboratoire, toujours nettoyer les règles après les tests.
11 // Un exemple avec SSH
Link to heading
Dans un laboratoire, on peut également rediriger un port TCP utilisé par SSH.
Par exemple :
Windows Pivot
192.168.1.50:2222
↓
Linux interne
10.10.10.20:22
Configuration :
netsh interface portproxy add v4tov4 ^
listenaddress=192.168.1.50 ^
listenport=2222 ^
connectaddress=10.10.10.20 ^
connectport=22
Un client autorisé peut alors tester :
ssh [email protected] -p 2222
Le chemin devient :
SSH CLIENT
│
│ :2222
▼
WINDOWS
│
│ :22
▼
LINUX INTERNAL
Cela constitue un excellent laboratoire pour comprendre le TCP port forwarding.
12 // Attention au pare-feu Windows
Link to heading
Créer une règle portproxy ne signifie pas nécessairement que le port est accessible depuis le réseau.
Le pare-feu Windows peut bloquer :
TCP 8080
Il faut donc distinguer :
Portproxy
+
Firewall
+
Network reachability
Une règle peut exister mais rester inaccessible depuis une autre machine.
Dans un laboratoire, on peut vérifier avec :
Test-NetConnection 192.168.1.50 -Port 8080
13 // Le rôle de IP Helper
Link to heading
Le fonctionnement de portproxy dépend notamment du service Windows :
IP Helper
On peut vérifier son état avec :
sc query iphlpsvc
ou :
Get-Service iphlpsvc
Dans un environnement de laboratoire, cela permet de comprendre pourquoi une configuration portproxy peut ne pas fonctionner comme prévu.
14 // Côté Blue Team
Link to heading
portproxy est également intéressant du point de vue défense.
Une règle inattendue peut révéler :
port forwarding non autorisé
pivoting
exposition d'un service interne
configuration temporaire oubliée
Un administrateur peut donc régulièrement vérifier :
netsh interface portproxy show all
et rechercher les règles inconnues.
On peut ensuite corréler avec :
Windows Firewall
Event Logs
netstat
services
processus
connexions réseau
Une règle seule ne prouve pas une compromission.
Mais une règle inconnue vers :
10.10.10.20:22
sur un poste utilisateur mérite clairement une investigation.
15 // Mini-lab GREY-X
Link to heading
Topologie Link to heading
CLIENT
192.168.1.10
│
▼
WINDOWS PIVOT
192.168.1.50
10.10.10.50
│
▼
SERVER INTERNE
10.10.10.20:80
Étape 1 — Créer la redirection Link to heading
Sur Windows :
netsh interface portproxy add v4tov4 ^
listenaddress=192.168.1.50 ^
listenport=8080 ^
connectaddress=10.10.10.20 ^
connectport=80
Étape 2 — Vérifier Link to heading
netsh interface portproxy show all
Étape 3 — Vérifier l’écoute Link to heading
netstat -ano | findstr :8080
Étape 4 — Tester depuis le client Link to heading
curl http://192.168.1.50:8080
Étape 5 — Nettoyer Link to heading
netsh interface portproxy delete v4tov4 ^
listenaddress=192.168.1.50 ^
listenport=8080
Puis :
netsh interface portproxy show all
16 // Commandes à retenir
Link to heading
netsh interface portproxy show all
→ afficher les redirections.
netsh interface portproxy add v4tov4 listenaddress=192.168.1.50 listenport=8080 connectaddress=10.10.10.20 connectport=80
→ créer une redirection TCP IPv4 → IPv4.
netsh interface portproxy delete v4tov4 listenaddress=192.168.1.50 listenport=8080
→ supprimer une redirection.
netstat -ano | findstr :8080
→ vérifier l’écoute locale.
sc query iphlpsvc
→ vérifier le service IP Helper.
17 // La vision pentest
Link to heading
Dans un scénario de pivoting :
ATTACKER
│
│ TCP
▼
┌──────────────┐
│ Windows │
│ Pivot │
└──────┬───────┘
│
portproxy
│
▼
INTERNAL SERVER
La commande :
netsh interface portproxy
permet donc d’étudier une technique fondamentale :
utiliser une machine intermédiaire pour rendre accessible un service TCP situé sur un autre réseau.
Pour un pentester, cela permet de démontrer les conséquences possibles d’une machine compromise disposant d’une connectivité privilégiée.
Pour un défenseur, cela rappelle qu’une machine Windows possédant plusieurs interfaces réseau doit être surveillée comme un point potentiel de pivot.
18 // À retenir
Link to heading
netsh winhttp
→ configuration proxy WinHTTP
netsh interface portproxy
→ redirection TCP
net use
→ connexions SMB
net share
→ partages Windows
icacls
→ permissions NTFS
On commence alors à avoir une véritable boîte à outils native Windows :
WINDOWS NATIVE TOOLS
│
┌────────────┼────────────┐
▼ ▼ ▼
SMB ACL TCP
│ │ │
net use icacls portproxy
│ │ │
└────────────┼────────────┘
▼
NETWORK ANALYSIS
│
▼
SECURITY LAB
portproxyne crée pas un proxy HTTP. Il crée une redirection TCP.
GREY-X — Forward. Pivot. Understand. Secure.