Analyse de trafic réseau d’un échantillon malveillant avec Wireshark

Wireshark est un analyseur de paquets réseau open-source permettant de capturer et d'inspecter en temps réel les données circulant sur un réseau. Il est largement utilisé en administration réseau et en cybersécurité pour analyser les protocoles, diagnostiquer des anomalies et détecter des activités suspectes.

Dans le cadre de ce travail pratique, j'ai utilisé Wireshark pour analyser un fichier de capture réseau (PCAP) contenant du trafic généré par un échantillon malveillant. L'objectif est de comprendre le comportement de ce dernier, d'identifier les protocoles utilisés et d'adopter une démarche méthodique d'analyse.

II. Methodologie

La démarche suivante a été adoptée pour mener à bien cette analyse :

• Ouverture du fichier PCAP dans Wireshark Analyse globale du trafic (volume, protocoles, longueurs des paquets)
• Filtrage et exploration des protocoles DNS, TCP et HTTP Analyse des communications (IP source et destination, ports, fréquence)
• Utilisation de GeoIP pour la localisation géographique Interprétation finale du comportement de l'échantillon

1. Environnement de travail

Pour garantir la sécurité de l’analyse, les précautions suivantes ont été prises nous avons travailler sur :

• Machine virtuelle (Kali Linux ou Ubuntu)
• Wireshark installé
• Base GeoLite2 (MaxMind) configurée
• Connexion Internet isolée (ou NAT)

​​​​Aucun code malveillant n'a été exécuté sur ma machine principale. Toutes les manipulations ont été réalisées dans un environnement virtualisé et isolé.

2. Objectif

Ce Lab a pour objectif de :

• Analyser un fichier de capture réseau (PCAP) contenant du trafic malveillant Identifier les protocoles utilisés par le malware (TCP, HTTP, DNS, ICMP)
• Détecter des comportements suspects (SYN scans, probes HTTP, sondes DNS)
• Comprendre la communication entre un malware et des serveurs distants
• Interpréter les résultats pour qualifier la menace

Téléchargement du fichier

On se connecte sur le site Malware Traffic Analysis afin de télécharger un fichier de malware pour l’étude

Ensuite, on sélectionne un échantillon récent puis on procède à son téléchargement.

Le fichier téléchargé est généralement compressé au format .zip. Pour le décompresser, un mot de passe est requis.

Le fichier téléchargé est généralement protégé par un mot de passe fourni par la plateforme

Exemple :
Si le fichier correspond à la date du 3 juin 1972, le mot de passe sera :
infected_19720603

Il est fortement recommandé d’effectuer cette manipulation dans une machine virtuelle afin d’éviter tout risque d’infection du système.

Nous allons maintenant dézipper le fichier téléchargé.

Ouverture du fichier sur wireshark

• Lancer Wireshark
• Cliquer sur :

File → Open

3. Sélectionner le fichier .pcap téléchargé
4. Charger la capture

Tous les paquets sont maintenant disponibles pour analyse

​

Analyse Globale du traffic

• Les protocoles utilisés :
  • TCP
  • DNS
  • HTTP / HTTPS
  • ICMP

Le volume de trafic:  Le volume de trafic correspond à la quantité de données échangées entre les machines.

• Pour voir les données sur les volumes nous allons cliquer sur statistiques et selectionner Packet length pour analyser la taille des packets.

​​​​​​​

​​​​​​​

À partir de ces données, nous voyons plusieurs informations, à savoir le volume global qui se présente comme suit sur la capture :

Ces chiffres nous donnent déjà une première indication : la taille moyenne est très faible (74 octets), ce qui suggère que les paquets contiennent peu de données utiles.

• Calcul du volume total approximatif

Pour estimer le volume total de données échangées, nous pouvons utiliser deux méthodes complémentaires.

Méthode 1 : à partir de la taille moyenne

La méthode la plus simple consiste à multiplier le nombre total de paquets par leur taille moyenne :

​​​​​​​

Méthode 2 : à partir des plages (plus précise)

Cette seconde méthode, que nous détaillerons dans la section 4, permet d'affiner le calcul. Elle aboutit à un volume d'environ 10,1 MB.

Ainsi, après recoupement des deux méthodes, nous retenons un volume total d'environ 10 Mo sur les 3 jours de capture.

Calcul du débit moyen

Pour mieux visualiser l'intensité du trafic, calculons maintenant le débit moyen.

Commençons par déterminer la durée exacte de la capture.

Le débit moyen s'obtient en divisant le volume total par la durée :

Interprétation :

Un débit de 0,3 kbit/s est extrêmement faible. À titre de comparaison, une connexion ADSL minimale est de 128 kbit/s, soit plus de 400 fois supérieure. Cela indique que le serveur a reçu très peu de données pendant ces 3 jours.

Calcul du taux de paquets

Enfin, calculons combien de paquets sont échangés chaque seconde en moyenne :

On retient : 0,5 paquet/seconde Interprétation : Environ un paquet toutes les 2 secondes. C'est un rythme très lent, typique d'un serveur peu sollicité ou d'une machine subissant des scans espacés.

Répartition par taille de paquet

Passons maintenant à l'analyse détaillée de la répartition des paquets par tranche de taille. Cette répartition est essentielle car elle nous renseigne sur la nature des échanges.

Effectuons les calculs de pourcentages pour voir le pourcentages du nombres de paquets qui circulent sur le reseaux.

Premier constat majeur : plus de 90 % des paquets font moins de 80 octets. C'est un chiffre très élevé qui oriente fortement l'interprétation vers des échanges de type "contrôle" ou "sondes minimales".

Interpretons maintenant chaque sous plage

Pour comprendre ce que chaque plage de taille signifie concrètement, il est nécessaire de connaître la structure d'un paquet réseau. C'est ce que nous allons détailler maintenant.

Prérequis : la taille des en-têtes

Dans un paquet Ethernet capturé, on a obligatoirement plusieurs couches de protocoles qui s'empilent.

Voici leurs tailles standards :

Un paquet TCP typique a donc au moins 54 octets. Si un paquet fait moins de 54 octets, cela signifie qu'il n'utilise pas TCP (il peut s'agir d'ICMP ou d'UDP, dont les en-têtes sont plus petits).

Notre paquet minimum est de 42 octets, ce qui confirme la présence de paquets non-TCP (probablement des ICMP).

Interprétation détaillée plage par plage

Voyons maintenant, pour chaque plage, ce qu'il est possible de transporter compte tenu de l'espace disponible après les en-têtes. 

Plage 40–79 octets

Calcul de la charge utile possible : La charge utile est ce qui reste après avoir enlevé les en-têtes.

Dans cette plage :

Interprétation finale : Cette plage correspond très majoritairement à des scans de ports (envoi de paquets SYN) et des probes HTTP extrêmement courts.

Le fait qu'elle représente 90 % du trafic est un indicateur fort d'une activité de reconnaissance automatisée.

Plage 80–159 octets

Calcul de la charge utile :

Ce qu'on peut mettre :

Une réponse HTTP courte : HTTP/1.1 404 Not Found\r\n\r\n = environ 30 octets.

Une réponse 200 OK sans corps : HTTP/1.1 200 OK\r\nContent-Length: 0\r\n\r\n = environ 40 octets. Une requête HTTP avec un en-tête Host : GET / HTTP/1.1\r\nHost: example.com\r\n\r\n = environ 45 octets.

Une redirection : HTTP/1.1 301 Moved Permanently\r\nLocation: /\r\n\r\n = environ 50 octets.

Interprétation finale :

Cette plage correspond à des petites réponses HTTP (404, 301, 200 sans contenu) ou des requêtes HTTP simples. On commence à voir apparaître un début d'échange applicatif, mais rien de volumineux.

Plage 160–319 octets

Calcul de la charge utile :

Ce qu'on peut mettre :

Des en-têtes HTTP complets avec User-Agent. Par exemple :

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 = environ 80 octets.

Ajoutons les autres en-têtes typiques (Host, Accept, Accept-Language, Connection, etc.) : on atteint facilement 150 à 250 octets de headers. Interprétation finale : Cette plage contient des requêtes HTTP avec en-têtes complets (typiques d'un navigateur ou d'un bot bien configuré), mais toujours sans corps de données (ce sont des requêtes GET).

On note que cette plage ne représente que 1,12 % du trafic, ce qui confirme la faible proportion de véritables requêtes HTTP structurées.

Plage 320–639 octets

Calcul de la charge utile :

Ce qu'on peut mettre : Un petit formulaire POST : key1=valeur1&key2=valeur2&key3=valeur3 = 200 à 500 octets.

Une réponse HTTP contenant un court message d'erreur ou une notification. Une requête API REST avec un petit payload JSON.

Interprétation finale : Cette plage (1,80 % du trafic) correspond à des corps de requête courts, typiquement des soumissions de formulaires (login, recherche) ou des appels API simples. C'est encore marginal. 

Plage 640–1279 octets

Calcul de la charge utile :

Ce qu'on peut mettre : Une page d'erreur personnalisée (par exemple, une page 404 avec un message et un peu de CSS). Un petit fichier CSS ou JavaScript (quelques centaines d'octets).

Une réponse JSON contenant une liste d'objets. Une icône (favicon) basique. Interprétation finale : Avec seulement 0,27 % du trafic, cette plage représente le début de vrais contenus web, mais de façon très marginale.

La grande majorité des réponses HTTP attendues (pages HTML complètes, images, fichiers) seraient bien plus grandes. 

Plage 1280–2559 octets

Calcul de la charge utile 

Contexte technique important :

Le MTU (Maximum Transmission Unit) standard d'Ethernet est de 1500 octets.

C'est la taille maximale qu'un paquet peut atteindre sans être fragmenté. Ici, le maximum observé est de 1519 octets, ce qui reste dans la limite (les 19 octets supplémentaires peuvent venir d'options ou de l'encapsulation).

Ce qu'on peut mettre : Une réponse HTTP avec un petit fichier (ex: une icône de 1 ko).

Un extrait de page web (début d'une page HTML). Un probe plus élaboré avec un corps conséquent. Interprétation finale : Seulement 20 paquets sur 132 564 (soit 0,02 %) atteignent cette taille.

C'est statistiquement négligeable. Aucun transfert volumineux n'a eu lieu.

En l'absence de paquets de taille MTU (1500 octets) en quantité significative, on peut affirmer qu'il n'y a eu ni téléchargement de fichier, ni exfiltration de données, ni chargement de page web complète. 

Ce que ces chiffres nous disent sur les échanges entre machines

Maintenant que nous avons quantifié et interprété chaque plage, synthétisons les enseignements sur la nature des échanges.

Synthèse des observations

III. Filtrage et Observation

Filtre DNS : dns

Dans une capture de scans/probes, le trafic DNS est généralement très faible, car : Les scanners utilisent directement des adresses IP (pas besoin de DNS) Les probes HTTP peuvent viser des noms de domaine (via l'en-tête Host), mais cela ne génère pas forcément de requête DNS séparée

En filtrant les paquets DNS, on observe un très faible volume : seulement une vingtaine de requêtes sur l’ensemble des 3 jours.

Chaque requête DNS est immédiatement suivie d’une réponse ICMP « Port unreachable » (port injoignable).

Exemple de sequence typique

Interprétation

La réponse « Port unreachable » signifie que : Le port UDP 53 (celui du service DNS) est fermé sur le serveur. Aucun serveur DNS n’écoute sur ce port. Les tentatives de sondes échouent systématiquement.

Aucune attaque DNS n’a réussi.

Filtre TCP:

Le TCP (Transmission Control Protocol) est le protocole utilisé par : Le web (HTTP/HTTPS) Les scans de ports (SYN scans) Les connexions SSH, FTP, email, etc. Dans ta capture nommée scans-and-probes-and-web-traffic, le TCP représente très probablement plus de 95 % du trafic.

on repère des paquets avec la mention [SYN]. Ce sont des tentatives de connexion entrantes.

Concrètement, quelqu'un essaie de se connecter au serveur sur différents ports. Exemples trouvés dans la capture :

Le  serveur reçoit des demandes de connexion sur des ports variés, y compris des ports typiquement Windows.

Des paquets sans données (Len=0) La plupart des paquets affichent Len=0, ce qui signifie longueur nulle. Autrement dit, ils ne transportent aucune donnée utile. Ce sont uniquement des paquets de contrôle (accusés de réception, fermetures de connexion, etc.). Il n’y a quasiment aucun échange de données réel sur mon serveur

Le trafic TCP sur le serveur est composé presque exclusivement de tentatives de connexion (scans de ports) et de paquets de contrôle. Il n’y a pratiquement aucun échange de données utile. le serveur n’est pas réellement visité, seulement sondé par des automates qui explorent Internet.

Filtre HTTP:

le protocole utilisé par les navigateurs web. C'est ici que l'on peut voir les sondes (probes) et les éventuelles vraies visites.

Les scanners ont tenté d'accéder à des fichiers qui ne devraient jamais être publics :

Face à ces requêtes, le serveur a répondu :

404 Not Found dans la grande majorité des cas → les fichiers n'existent pas

200 OK une seule fois → pour la page d'accueil (/)

400 Bad Request quelques fois → requêtes mal formées

IV.Analyse des communications

• Adresses IP source et destination

Dans Wireshark, j'ai utilisé le menu Statistiques → Endpoints → Onglet IPv4. Ce tableau affiche toutes les adresses IP qui ont communiqué avec mon serveur, ainsi que leur pays d'origine (colonne "Country").

Ce que nous observons:

Une répartition mondiale Les 281 adresses IP recensées viennent de nombreux pays différents à travers le monde :

Une IP se démarque L'adresse IP 5.143.245.194 située en Russie est la plus active : 30 paquets envoyés (contre 1 pour la plupart des autres) 16 kB de données reçues (le volume le plus important)

Un volume négligeable par IP Chaque IP reçoit généralement 500 à 900 bytes de données, soit l'équivalent de quelques phrases de texte. C'est un volume très faible.

Le serveur est contacté par des machines situées aux quatre coins du monde : Asie, Europe, Amérique du Nord et Moyen-Orient. La grande majorité de ces IP n'envoient qu'un ou deux paquets. Une seule IP (en Russie) est un peu plus active, mais sans excès.

Cela confirme qu'il s'agit d'un bruit de fond mondial, pas d'une attaque ciblée depuis un pays spécifique. 

• Ports utilisés
•  

Dans Wireshark, j'ai utilisé le menu Statistiques → Endpoints → Onglet TCP.

Ce tableau affiche toutes les adresses IP et les ports qui ont communiqué avec mon serveur.

Ce que j'ai observé Des ports source élevés et aléatoires Les scanners utilisent des ports source compris entre 30000 et 60000.

Voici quelques exemples :

Une même IP utilise plusieurs ports L'adresse 3.12.74.97 apparaît avec 6 ports différents (45198, 45212, 46764, 51146, 54332, 60280). Cela signifie que cette machine a envoyé plusieurs requêtes successives.

Une IP russe très active L'adresse 5.143.245.194 (Russie) est la plus active : elle apparaît avec plus d'une dizaine de ports différents. C'est le scanner le plus persistant de toute la capture.

Les scanners qui contactent mon serveur utilisent des ports source élevés et aléatoires, ce qui est typique des outils de scan automatisés.

Certaines machines, comme l'IP russe 5.143.245.194, sont particulièrement actives et utilisent de nombreux ports différents pour leurs sondes.

• Fréquence des échanges

Dans Wireshark, nous avons utilisé le menu Statistiques → IO Graph.

Cet outil affiche un graphique qui montre l'intensité du trafic dans le temps. L'axe horizontal représente le temps (les 3 jours de capture), et l'axe vertical représente le nombre de paquets par seconde.

Un trafic très faible Le graphique montre une ligne très basse, proche de 0, pendant pratiquement toute la durée de la capture.

Pas de pics suspects nous n'avons observé aucun pic massif qui pourrait indiquer une attaque soudaine (type DDoS) ou une vague de scan intense. Le trafic est remarquablement constant sur les 3 jours.

Des moments plus calmes Le trafic semble légèrement moins présent pendant les heures nocturnes (entre minuit et 6h du matin), mais la différence reste minime.

Le graphique IO Graph montre un trafic extrêmement faible et constant sur les 3 jours de capture, avec une moyenne d'environ 0,5 paquet par seconde.

L'absence de pics significatifs indique qu'il n'y a eu ni attaque soudaine, ni vague de scan intense. Il s'agit simplement du bruit de fond normal d'Internet : des scanners automatisés qui sondent mon serveur à un rythme très lent et régulier. 

V. Utilisation de GeoIP 

Dans une analyse réseau, il est souvent utile de savoir d'où viennent les connexions. Quel pays ? Quelle ville ? Quel fournisseur d'accès (AS) ?

Cela permet de : Repérer des connexions suspectes venant de pays inattendus

Visualiser la répartition géographique des scanners

Filtrer le trafic par pays pour se concentrer sur l'essentiel

GeoIP est une fonctionnalité de Wireshark qui permet d'associer une adresse IP à des informations géographiques (pays, ville, coordonnées GPS, AS).

Comment j'ai installé et configuré GeoIP Voici les étapes que j'ai suivies pour activer cette fonctionnalité.

1. Téléchargement des bases de données GeoIP

J'ai utilisé les bases de données gratuites GeoLite2 fournies par MaxMind. Elles existent en trois versions.

Pour les télécharger, je suis allé sur le site de MaxMind, j'ai créé un compte gratuit (nécessaire depuis quelques années) et j'ai téléchargé les fichiers au format .mmdb.

Configuration de Wireshark

Une fois les fichiers téléchargés et extraits  j'ai configuré Wireshark pour qu'il les utilise :

Dans Wireshark, j'ai ouvert Edit → Preferences (ou Wireshark → Preferences sur Mac) J'ai sélectionné Name Resolution dans la colonne de gauche J'ai cliqué sur le bouton Edit à côté de "MaxMind database directories"

J'ai ajouté le chemin vers le dossier contenant mes fichiers .mmdb

J'ai validé en cliquant sur OK Note importante : Vérifiez que l'extension des fichiers est bien en minuscules (.mmdb).

Wireshark ne lit pas les extensions en majuscules comme .MMDB.

Ajout d'une colonne "Pays" dans la liste des paquets

Pour visualiser rapidement le pays d'origine des paquets, j'ai ajouté une colonne dédiée : Clic droit sur l'en-tête des colonnes Column Preferences

J'ai ajouté une nouvelle colonne avec : Title : Pays Type : Custom Fields : ip.geoip.country (ou ip.geoip.src_country pour ne voir que la source)

VI. Comportement observé de l'échantillon

Le malware que j'ai analysé, adopte un comportement typique d'un scanner et collecteur d'informations.

Dans un premier temps, il envoie des SYN scans vers des ports variés.

Dans un second temps, il envoie des requêtes HTTP vers des fichiers sensibles.

Enfin, il réalise des sondes DNS.

Nous pouvons donc dire que ce malware ne s'installe ni ne se propage, mais se contente de sonder et scanner des cibles potentielles.

Types de communications utilisées

J'ai observé que le malware utilise principalement quatre types de communications.

Premièrement, des SYN scans (TCP) pour détecter des ports ouverts.

Deuxièmement, des requêtes HTTP pour chercher des fichiers sensibles comme .env.

Troisièmement, des sondes DNS vers des noms de domaine suspects.

Quatrièmement, des réponses ICMP "Port unreachable" envoyées par les cibles.

Nous remarquons que les paquets sont très petits, que le trafic est majoritairement sortant, et que les ports source sont élevés et aléatoires.

Indices montrant une activité malveillante

Plusieurs indices confirment qu'il s'agit bien d'un malware.

J'ai identifié des SYN scans, des requêtes vers des fichiers sensibles, des sondes DNS suspectes, une IP russe particulièrement active, des paquets très petits, et 281 adresses IP différentes contactées.

Nous pouvons affirmer que tous ces éléments sont caractéristiques d'un comportement malveillant.

Conclusion finale

Nous concluons que ce malware est un scanner automatisé qui cherche des cibles vulnérables. Ses tentatives ont majoritairement échoué, mais ce type de malware peut être dangereux s'il trouve un serveur mal configuré.

Compétences développées

À travers cette analyse, plusieurs compétences clés ont été développées. L'analyse de fichiers PCAP avec Wireshark a été maîtrisée, notamment l'utilisation de filtres avancés et des outils statistiques tels que les endpoints et l'IO Graph.

Les bases de l'investigation réseau en forensic ont été mises en pratique grâce à une méthodologie structurée : évaluation du volume de trafic, identification des protocoles, repérage des adresses IP suspectes, analyse des ports utilisés et mesure de la fréquence des échanges.

Enfin, la détection de menaces réseau a été abordée à travers l'identification de SYN scans, de requêtes HTTP vers des fichiers sensibles comme .env, et de sondes DNS anormales telles que Tversion.bind.

Ces compétences sont désormais transférables à d'autres contextes d'analyse, qu'il s'agisse d'investigations internes ou de veille en cybersécurité.