LLM et analyse Wireshark — automatiser l'analyse réseau

L'analyse des captures reseau est l'une des taches les plus fastidieuses et les plus techniques en cybersecurite : une capture Wireshark d'une heure sur un reseau d'entreprise peut contenir des millions de paquets, necessitant des heures d'analyse experte pour en extraire les informations pertinentes. Les LLM pour l'analyse Wireshark et des captures reseau changent fondamentalement cette equation. En transformant les flux reseau en representations textuelles analysables par un LLM, il devient possible de generer des summaries intelligents en quelques secondes, de detecter automatiquement les comportements anormaux (Shadow IT, tunnels couverts, communications C2), et d'expliquer en langage naturel ce qui se passe reellement sur le reseau. En 2026, des pipelines complets allant du PCAP brut jusqu'a l'alerte SIEM contextualisee sont disponibles open source. Cet article vous presente l'architecture complete, le code Python, et les limites a connaitre pour deployer efficacement ces capacites dans votre SOC ou vos engagements de pentest.

Architecture pipeline PCAP vers LLM vers alerte

Le pipeline d'analyse reseau par LLM se decompose en quatre etapes sequentielles :

1. Extraction tshark : convertir le fichier PCAP en JSON structure avec tshark (CLI de Wireshark), en extrayant les champs pertinents par protocole (IP src/dst, ports, DNS names, TLS SNI, HTTP Host, payload statistics)
2. Agregation et contexte : aggreger les flux par paires IP, par domaine DNS, par application protocolaire pour reduire la taille du contexte a analyser par le LLM
3. Analyse LLM : soumettre l'agregation au LLM avec un prompt structure demandant l'identification des anomalies, la classification des flux et les recommandations
4. Alerting : formatter les sorties LLM en alertes SIEM (JSON CEF ou Syslog) pour integration dans le pipeline SOC

Flow summarization automatique par LLM

La summarization automatique des flux reseau est le premier cas d'usage accessible. Au lieu d'analyser des milliers de lignes de logs, l'analyste recoit un resume structure :

import subprocess, json, sys
import requests

TSHARK_BIN = "/usr/bin/tshark"
OLLAMA_URL = "http://localhost:11434/api/generate"
OLLAMA_MODEL = "llama3.3:70b"

def extract_flows(pcap_file, max_flows=500):
    # Extraire les flux TCP/UDP/DNS depuis le PCAP
    cmd = [
        TSHARK_BIN, "-r", pcap_file, "-T", "json",
        "-e", "ip.src", "-e", "ip.dst", "-e", "tcp.dstport",
        "-e", "udp.dstport", "-e", "dns.qry.name", "-e", "tls.handshake.extensions_server_name",
        "-e", "http.host", "-e", "frame.len",
        "-Y", "ip",  # filtre: paquets IP uniquement
        "-c", str(max_flows)
    ]
    result = subprocess.run(cmd, capture_output=True, text=True)
    try:
        packets = json.loads(result.stdout)
    except json.JSONDecodeError:
        return []

    flows = {}
    for pkt in packets:
        layers = pkt.get("_source", {}).get("layers", {})
        src = layers.get("ip.src", ["?"])[0]
        dst = layers.get("ip.dst", ["?"])[0]
        dns = layers.get("dns.qry.name", [""])[0]
        sni = layers.get("tls.handshake.extensions_server_name", [""])[0]
        http_host = layers.get("http.host", [""])[0]

        key = f"{src}->{dst}"
        if key not in flows:
            flows[key] = {"src": src, "dst": dst, "count": 0, "dns": set(), "sni": set(), "http": set()}
        flows[key]["count"] += 1
        if dns: flows[key]["dns"].add(dns)
        if sni: flows[key]["sni"].add(sni)
        if http_host: flows[key]["http"].add(http_host)

    # Convertir sets en listes pour JSON
    for k in flows:
        flows[k]["dns"] = list(flows[k]["dns"])[:5]
        flows[k]["sni"] = list(flows[k]["sni"])[:5]
        flows[k]["http"] = list(flows[k]["http"])[:5]

    return list(flows.values())[:50]

def analyze_with_llm(flows_summary):
    prompt = (
        "Tu es un analyste reseau expert en cybersecurite. "
        "Analyse ces flux reseau agrges et identifie: "
        "1) Communications suspectes ou anormales "
        "2) Shadow IT (services cloud non autorises) "
        "3) Potentiels C2 ou tunnels couverts "
        "4) Violations de politique reseau "
        "Sois concis et priorise par criticite.\n\n"
        "FLUX RESEAU:\n" + json.dumps(flows_summary[:20], indent=2)
    )
    response = requests.post(OLLAMA_URL, json={"model": OLLAMA_MODEL, "prompt": prompt, "stream": False})
    return response.json().get("response", "")

if __name__ == "__main__":
    pcap_file = sys.argv[1] if len(sys.argv) > 1 else "capture.pcap"
    flows = extract_flows(pcap_file)
    print(f"Extracted {len(flows)} flow pairs")
    analysis = analyze_with_llm(flows)
    print("LLM Analysis:\n", analysis)

Shadow IT detection dans les flux DNS et TLS

La detection du Shadow IT via les flux DNS et TLS est particulierement efficace car les applications SaaS non autorisees laissent toujours des traces dans les requetes DNS et les negotiations TLS (SNI - Server Name Indication).

Patterns DNS revelateurs de Shadow IT :

• Requetes vers des domaines LLM cloud non autorises (api.openai.com, generativelanguage.googleapis.com, api.anthropic.com)
• Requetes frequentes vers des services de cloud storage non references (dropbox.com, anonfiles.com)
• Requetes DNS vers des domaines recemment crees (high DGA score) pouvant indiquer du C2
• Volume anormal de sous-domaines d'un meme domaine (DNS tunneling)

Le LLM peut analyser une liste de domaines DNS et identifier semantiquement ceux qui correspondent a des services non autorises, en s'appuyant sur sa connaissance des services cloud populaires. Cette approche est plus flexible qu'une simple blacklist statique et peut identifier des services emergents non encore references.

ICS/OT anomaly detection via series temporelles

Dans les reseaux industriels ICS/OT, l'analyse des captures Wireshark par LLM présente des cas d'usage specifiques. Les protocoles industriels (Modbus, DNP3, EtherNet/IP, S7comm) ont des patterns de trafic tres predictibles en operation normale : requetes de lecture cycliques, pas de communications vers internet, topologie reseau fixe. Toute deviation de ces patterns est un indicateur potentiel de compromission.

Le LLM peut analyser des summaries de trafic Modbus/DNP3 et identifier : des echanges avec des adresses IP inhabituelles (ordinateurs d'ingenierie non authorises), des commandes d'ecriture sur des registres normalement en lecture seule, des variations dans la periodicitice des requetes de polling, ou des communications hors des heures normales de maintenance. Ces capacites de detection OT par LLM sont detaillees dans notre article sur l'IA et la cybersecurite industrielle OT.

Prompt engineering pour l'analyse reseau

La qualite de l'analyse LLM des captures reseau depend fortement du prompt engineering utilise. Les prompts optimaux pour l'analyse reseau incluent :

• Contexte organisationnel : indiquer au LLM le type d'organisation (banque, hopital, site industriel) pour adapter son evaluation des risques
• Baseline normale : fournir une description du trafic normal attendu pour faciliter la detection des anomalies
• Focus d'analyse : preciser si l'objectif est la detection de C2, de Shadow IT, d'exfiltration ou d'autres categories specifiques
• Format de sortie structure : demander une sortie JSON pour faciliter l'integration avec les outils SIEM

Le prompt chain est particulièrement efficace pour l'analyse reseau : un premier LLM classe les flux par categorie (normal, suspect, critique), un second approfondit l'analyse des flux suspects, et un troisieme genere les recommandations de remediation. Cette approche reduit les hallucinations en limitant chaque LLM a une tache specifique bien definie.

Integration Zeek et Suricata avec LLM

L'integration de Zeek et Suricata avec un LLM est plus efficace que l'analyse directe de PCAP car ces outils produisent deja des logs structures et enrichis. Zeek genere des logs conn.log (connexions TCP/UDP), dns.log (requetes DNS), http.log (trafic HTTP) et ssl.log (connexions TLS) en format JSON, directement consommables par un LLM sans preprocessing complexe. Suricata fournit des alertes avec signature et score de severite que le LLM peut contextualiser et prioriser. L'architecture optimale pour un SOC est : Zeek/Suricata pour l'extraction et la detection signature-based, LLM pour l'enrichissement semantique et la priorisation contextuelle, SIEM pour la correlation et le stockage. Pour l'integration dans une architecture SOC complete, consultez notre article sur le SOC augmente par IA.

Construction d'un baseline reseau avec LLM -- apprentissage automatique du normal

La construction d'un baseline reseau automatise par LLM est une capacite avancee qui ameliore considerablement la pertinence des analyses subsequentes. En soumettant regulierement des summaries de captures reseau des periodes "normales" a un LLM, on peut construire une description semantique du comportement reseau attendu : "Sur ce reseau industriel, le trafic normal se compose de requetes Modbus cycliques toutes les 100ms vers les PLC 192.168.10.1 a 192.168.10.20, de mises a jour Windows nocturnes vers WSUS.corp.local, et de backup vers 10.0.50.100 entre 2h et 5h du matin." Cette baseline semantique, stockee dans un document ou une base vectorielle, peut etre injectee dans le contexte du LLM lors des analyses futures pour permettre une detection d'anomalies contextualisee. L'approche est particulierement efficace pour les reseaux OT/ICS ou le trafic legitime est extremement predictible et ou toute deviation merite investigation. Pour les aspects de detection d'anomalies dans les environnements industriels, notre article sur l'IA et la cybersecurite industrielle OT detaille les specifites de ces reseaux.

Automatisation du reporting d'analyse reseau

L'automatisation du reporting d'analyse reseau par LLM transforme les donnees brutes de captures en livrables professionnels. Un pipeline complet peut generer automatiquement : un rapport executif resume en 1 page avec les 3 risques principaux en langage business, un rapport technique detaille avec les indicateurs techniques et les requetes tshark/Zeek permettant de reproduire les findings, des alertes SIEM au format JSON CEF ou Syslog pret a integrer, et des fiches de remediation par systeme impacte. La generation automatique de ces livrables reduit de 70 a 80% le temps de post-traitement apres une analyse reseau, permettant aux analystes de se concentrer sur la validation des findings et les actions de remediation plutot que sur la redaction des rapports. Pour les engagements de pentest ou d'audit, ce pipeline de reporting automatise s'integre dans la methodologie generale decrite dans notre guide complet du pentest. La documentation systematique des findings reseau contribue egalement a l'audit de conformite ISO 27001 en fournissant des preuves de surveillance continue du reseau.

Limites et faux positifs de l'analyse LLM reseau

Les limites de l'analyse LLM des captures reseau sont importantes a connaitre pour eviter les pieges operationnels :

• Limite de contexte : les grandes captures (centaines de milliers de paquets) ne peuvent pas etre soumises directement a un LLM. L'agregation prealable est indispensable mais peut masquer des anomalies dans les details.
• Hallucinations sur protocoles rares : les LLM sont moins fiables sur des protocoles industriels peu representes dans leurs donnees d'entrainement (Modbus, DNP3, CAN bus). Valider systematiquement leurs conclusions sur ces protocoles.
• Depandance au contexte organisationnel : un trafic tout a fait normal dans un contexte (traffic vers AWS depuis une startup cloud-native) peut sembler suspect dans un autre (meme traffic depuis un reseau industriel ferme). Le LLM a besoin de ce contexte pour faire des evaluations pertinentes.
• Absence de memoire : un LLM sans base de connaissance persistante ne peut pas corréler des captures prises a des heures differentes. L'integration avec un SIEM pour la correlation temporelle est indispensable.

Cas d'usage avances -- detection C2 et exfiltration

La detection des communications C2 (Command and Control) via l'analyse LLM des captures reseau est un cas d'usage avance particulierement pertinent. Les frameworks C2 modernes (Cobalt Strike, Metasploit, Havoc, Sliver) utilisent des protocoles standard (HTTP/S, DNS) pour se fondre dans le trafic legitime, rendant leur detection difficile pour les IDS signature-based. Le LLM peut identifier des patterns subtils revelateurs : beaconing regulier (connexions sortantes a intervalles fixes vers un meme domaine), domain fronting (SNI different du Host HTTP), DNS beaconing avec des sous-domaines trop regulierement generes, ou trafic HTTPS avec des tailles de paquets inhabituellement uniformes. Pour la detection de l'exfiltration de donnees, le LLM analyse le volume de donnees sortantes par destination, les uploads vers des services de stockage cloud, et les flux DNS anormalement larges (DNS tunneling). Une analyse spectrale de la frequence du beaconing (Fast Fourier Transform sur les timestamps de connexion) peut etre soumise comme donnees numeriques supplementaires au LLM pour ameliorer la detection. Ces capacites de detection avancee positionnent le pipeline LLM reseau comme un complement puissant aux solutions NDR commerciales pour les SOC qui ne peuvent se permettre ces outils couteux. Pour l'integration dans votre architecture de detection, consultez notre article sur les attaques sur les architectures RAG qui utilise des techniques similaires d'analyse de patterns.

Analyse des protocoles applicatifs -- HTTP, DNS, TLS en profondeur

L'analyse approfondie des protocols applicatifs par LLM revele des informations que l'analyse de flux TCP/UDP seul ne peut pas fournir. Pour HTTP/HTTPS, les User-Agents anormaux (outils de scanning, malwares specifiques), les en-tetes HTTP inhabituals, les patterns d'URL de C2 (chemins aleatoires ou structures trop regulieres) et les codes de retour HTTP suspects (503 reguliers pouvant indiquer un staging C2) sont autant d'indicateurs analysables semantiquement par un LLM. Pour DNS, au-dela de la detection du Shadow IT, le LLM peut identifier les requetes de type NXDOMAIN en masse (DGA -- Domain Generation Algorithm), les requetes vers des TLD inhabituels pour l'organisation, et les transferts de zone DNS non autorises. Pour TLS, l'analyse des certificats (Organisation, date d'expiration, CA inhabituelle) et des suites de chiffrement (suites obsoletes ou inhabituelles pouvant indiquer des outils malveillants specifiques) fournit des indicateurs supplementaires. La combinaison de ces analyses par protocole dans un prompt multi-angle permet au LLM de construire une image complete du comportement reseau et d'identifier des patterns d'attaque qui ne seraient pas visibles en analysant chaque protocole separement. Pour les aspects de detection au niveau des endpoints complementant l'analyse reseau, consultez notre article sur le pipeline de detection ML qui presente des architectures similaires.

FAQ -- LLM et analyse de captures reseau

Qu'est-ce que la flow summarization par LLM dans le contexte reseau ?

La flow summarization par LLM dans le contexte reseau designe la capacite d'un modele de langage a analyser des donnees de flux reseau (connexions TCP/UDP, requetes DNS, trafic HTTP/TLS) et a generer un resume intelligible et actionnable en langage naturel. Au lieu d'un analyste passant des heures a parcourir des milliers de lignes de logs Zeek ou des paquets Wireshark, le LLM produit en quelques secondes un rapport structuré identifiant les communications anormales, les services non autorises, les potentiels indicateurs de compromission et les recommandations de remediation. La valeur ajoutee par rapport a des outils de detection classiques (IDS, NDR) reside dans la capacite a expliquer pourquoi un comportement est suspect et a le contextualiser dans la politique de securite de l'organisation.

Comment detecter le Shadow IT via l'analyse DNS avec un LLM ?

La detection du Shadow IT via l'analyse DNS par LLM exploite deux capacites complementaires. Premierement, la connaissance semantique du LLM sur les services cloud populaires : en soumettant une liste de domaines DNS resolus, le LLM peut identifier semantiquement ceux qui correspondent a des services potentiellement non autorises (outils de productivite IA, services de stockage cloud, applications SaaS non validees). Deuxiemement, sa capacite a identifier des patterns anormaux : volume eleve de requetes vers un domaine peu connu, domaines recemment enregistres, pattern de sous-domaines caracteristique du DNS tunneling. La combinaison de ces deux capacites permet une detection plus complete et flexible qu'une blacklist statique, au prix d'un risque de faux positifs que la validation humaine doit filtrer.

Pourquoi Zeek est-il preferable a Wireshark brut pour l'analyse LLM ?

Zeek produit des logs structures et normalises directement en JSON, ce qui reduit considerablement le preprocessing necessaire avant de les soumettre a un LLM. Une capture Wireshark brute necessite une extraction tshark, une aggregation et une normalisation avant d'etre analysable. Zeek enrichit automatiquement les logs avec des informations de session (duree, volume de donnees, nombre de paquets), des metadonnees applicatives (User-Agent HTTP, certificats TLS, types de fichiers transferes) et des indicateurs comportementaux (connexions courtes multiples suggerant du scanning). Cette richesse semantique ameliore considerablement la qualite de l'analyse LLM. De plus, Zeek peut operer en temps reel sur des liens a haut debit, permettant une analyse LLM quasi-temps-reel integrable dans un pipeline SOC, la ou Wireshark est principalement un outil d'analyse forensique a posteriori.

Quelle difference entre l'analyse LLM reseau et un IDS/NDR classique ?

Un IDS (Intrusion Detection System) comme Suricata ou Snort et une solution NDR (Network Detection and Response) detectent les menaces via des signatures (patterns specifiques connus) et des heuristiques statistiques (anomalie par rapport a une baseline). Leur force est la detection rapide et precise des attaques connues et documentees dans leurs bases de regles. Le LLM complemente ces approches avec une dimension semantique et contextuelle : il peut expliquer pourquoi une alerte est pertinente dans le contexte de l'organisation, identifier des comportements anormaux qui ne correspondent a aucune signature mais sont semantiquement suspects, et prioriser les alertes en tenant compte du contexte metier. Le modele optimal est la combinaison des deux : IDS/NDR pour la detection signature-based en temps reel, LLM pour l'enrichissement, la priorisation et l'explication des alertes generees.

Quels sont les risques de confidentialite de l'analyse LLM reseau ?

L'analyse des captures reseau par LLM cloud pose des problemes de confidentialite significatifs : les captures PCAP contiennent souvent des informations sensibles (credentials en clair si protocoles non chiffres, contenu de communications internes, informations sur la topologie interne du reseau). Envoyer ces donnees a une API LLM cloud (OpenAI, Anthropic, Google) implique un transfert vers des infrastructures tierces qui peut violer des obligations contractuelles, reglementaires (RGPD) ou des politiques de securite internes. La solution est l'utilisation de LLM locaux (Ollama avec Llama 3.3 ou Mistral) qui garantissent que les donnees reseau restent dans l'infrastructure interne. Pour les reseaux industriels OT notamment, le LLM local est la seule option acceptable compte tenu de la sensibilite des donnees de configuration et de la topologie des systemes de controle.

Performance et optimisation du pipeline d'analyse reseau

L'optimisation des performances du pipeline LLM reseau est critique pour une utilisation en production. Les principaux leviers sont : la reduction du contexte soumis au LLM via une agregation aggressive (top 50 flux par volume, top 20 domaines DNS, top 10 anomalies statistiques plutot que la totalite des flux bruts), le choix d'un modele LLM adapte a la tache (Llama 3.3 8B suffit pour la classification basique, 70B est necessaire pour le raisonnement complexe sur des patterns d'attaque avances), et l'utilisation du streaming pour obtenir des analyses partielles rapidement sur les grandes captures. Pour un usage en SOC temps reel, l'objectif de latence est inferieur a 5 secondes entre la reception d'une alerte Suricata et la disponibilite du resume LLM enrichi pour l'analyste. Avec un GPU A100 et Ollama (Llama 3.3 70B quantize en Q4), cette latence est atteignable sur des summaries de 2000 tokens ou moins. Pour les environnements a forte contrainte de performance, envisagez un modele plus leger (Llama 3.2 3B fine-tune sur des donnees cybersecurite) pour un pre-tri rapide avant une analyse approfondie par un modele plus grand. La mise en place d'un cache Redis pour les analyses de flux connus reduit egalement la charge sur le LLM pour les patterns recurrents. La configuration optimale dépend de votre architecture specifique detaillee dans notre article sur les benchmarks de serveurs LLM.

Conclusion

L'analyse des captures reseau par LLM est une evolution majeure des capacites analytiques disponibles pour les equipes SOC et les pentesters. Elle ne remplace pas Wireshark, Zeek ou Suricata -- elle les complemente en ajoutant une couche de comprehension semantique et de generation de recommandations en langage naturel. Pour commencer, deployer un pipeline tshark + Ollama local sur des captures non sensibles pour evaluer la pertinence des analyses sur votre contexte specifique, puis etendre progressivement a l'integration dans votre SIEM. Consultez notre article sur le SOC augmente par IA pour l'architecture complete et notre guide sur la cartographie du SI pour documenter ces nouveaux composants.