L'EDR classique observe le comportement. Process DNA observe ce qu'un processus EST — un hash de la binaire sur disque. Comment ça marche, ce que ça détecte et ce que ça ne détecte pas.

Une règle classique de détection d'intrusion observe le comportement : appels réseau inhabituels, pics CPU anormaux, entrées cron suspectes. Cela fonctionne — jusqu'à ce qu'un attaquant remplace une binaire qui tourne déjà. Le service s'appelle toujours nginx. Le PID est le même. L'alerte ne se déclenche pas.

Le fingerprinting Process DNA prend le problème autrement : pas ce qu'un processus fait, mais ce qu'il est.

Comment l'agent calcule le hash

À chaque cycle d'inventaire (60 secondes par défaut), l'agent monsys itère sur tous les processus dans /proc :

for pid in /proc/[0-9]*/exe; do
    sha256sum $(readlink -f "$pid") 2>/dev/null
done

Dans l'implémentation Rust, cela passe par std::fs::read_link + sha2::Sha256. Le hash est calculé sur la binaire réelle sur disque — pas sur la mémoire du processus en cours, car un attaquant pourrait trop facilement la manipuler.

Le résultat par top-processus (tout ce qui a un RSS > seuil configurable, 50 MB par défaut) :

{
  "pid": 1842,
  "name": "nginx",
  "exe_path": "/usr/sbin/nginx",
  "exe_sha256": "a3f2c1...",
  "observed_at": "2026-05-25T09:14:02Z"
}

TOFU : Trust on First Use

La première fois que l'agent voit une binaire, le hub enregistre le hash comme baseline. C'est le modèle TOFU (Trust on First Use) : on fait confiance à ce qui tourne déjà au moment de l'installation, et on alerte sur toute déviation ensuite.

Avantage : pas de whitelist à maintenir. Inconvénient : si l'agent est installé après qu'un attaquant ait déjà remplacé une binaire, le hash malveillant est dans la baseline. C'est un compromis délibéré — déployez l'agent tôt, idéalement dans votre pipeline de provisioning.

Le problème des faux positifs : auto-updates

Supposons que nginx soit mis à jour via apt upgrade. La binaire sur disque change. Le hash ne correspond plus à la baseline. Sans logique supplémentaire : alerte Critical à chaque mise à jour de package.

monsys résout cela via le rebaseline manifest-aware. Le hub maintient un manifest de release par package/binaire. Quand un nouveau hash arrive :

Le hub vérifie si le hash apparaît dans le manifest pour la version actuelle du package sur cet agent.
Si oui : rebaseline silencieuse, pas d'alerte.
Si non : alerte Critical — la binaire a changé sans mise à jour connue.

Le manifest est alimenté par deux sources :

L'inventaire de packages que l'agent envoie déjà (dpkg -l, rpm -qa)
Optionnellement, un manifest pré-signé que vous injectez pour vos propres logiciels

# l'événement d'inventaire de package déclenche la recherche manifest
apt_package: nginx 1.25.4-1
→ hub: fetch known_hashes for nginx@1.25.4-1 from manifest_store
→ match found: rebaseline silently

Ce que Process DNA détecte que l'EDR rate

Les outils EDR standard tournent comme daemon user-space ou module noyau sur l'hôte. Ils voient les événements processus via netlink ou eBPF. Mais dans une VM isolée par hyperviseur — comme Claude Cowork ou n'importe quelle sandbox cloud — ces outils sont aveugles à ce qui se passe à l'intérieur du périmètre de la VM.

L'agent monsys tourne à l'intérieur de la VM. Le calcul du hash se fait localement sur l'hôte. Seul le signal agrégé (hash + métadonnées) remonte vers le hub — pas de contenu binaire brut, pas de lignes de log.

Scénarios d'attaque que Process DNA détecte :

Compromission de la chaîne d'approvisionnement — Un package npm est publié avec un postinstall malveillant qui écrase une binaire système. Le nom de la binaire est identique, mais le SHA256 est nouveau et n'est pas dans le manifest. Alerte dans le prochain cycle d'inventaire (max 60 secondes).

Living-off-the-land — Un attaquant remplace /usr/bin/curl par une version patchée qui exfiltre des credentials mais fonctionne normalement. Process DNA piège ça au moment où la nouvelle binaire apparaît pour la première fois comme top-processus.

Fileless avec composant disque — Les attaques pures en mémoire ne sont pas visibles pour Process DNA (les honeypots sont la couche complémentaire pour ça). Mais dès qu'un payload écrit quelque chose sur disque et l'exécute, c'est enregistré.

La corrélation mouvement latéral

Les événements Process DNA se combinent avec le reste du pipeline de corrélation SMART. L'exemple le plus parlant : un changement de binaire suspect sur le serveur A, suivi d'une connexion SSH réussie du serveur A vers le serveur B en cinq minutes.

Le LateralMovementWorker (cadence : 60s) JOIN :

SELECT
    pd.agent_id      AS source_agent,
    pd.exe_path,
    pd.exe_sha256,
    ae.target_agent_id,
    ae.auth_user,
    ae.observed_at   AS ssh_at
FROM process_dna_alerts pd
JOIN auth_events ae
    ON ae.src_ip = (SELECT ip FROM agents WHERE id = pd.agent_id)
    AND ae.observed_at BETWEEN pd.observed_at - INTERVAL '5 min'
                            AND pd.observed_at + INTERVAL '5 min'
    AND ae.success = true
WHERE pd.baseline_match = false
  AND pd.tenant_id = $1

Résultat : un seul événement de détection avec les tags MITRE T1078 (Valid Accounts) + T1036 (Masquerading), avec un lien direct entre le swap de binaire et le mouvement latéral.

Opérationnel : ce que vous voyez dans le dashboard

Quand Process DNA détecte une déviation, une alerte Critical apparaît avec :

exe_path : le chemin de la binaire suspecte
baseline_hash : le hash connu comme bon
observed_hash : le nouveau hash inconnu
first_seen_pid : l'ID du processus
manifest_checked : true/false (une mise à jour de package était-elle attendue ?)

Via le bouton AI Explain (llama3.1:8b local), vous obtenez un résumé lisible :

"La binaire /usr/sbin/sshd a un SHA256 inconnu. Aucune mise à jour de package correspondante trouvée dans l'inventaire. Cela peut indiquer une installation OpenSSH compromise. Action recommandée : comparez le hash avec sha256sum /usr/sbin/sshd sur le serveur, vérifiez la provenance du package avec dpkg -V openssh-server, et envisagez IsolateNetwork via Emergency Actions."

Limites — à nommer honnêtement

Process DNA ne fonctionne pas sur :

Les payloads in-memory only sans composant disque (injection shellcode, reflective DLL loading)
Les attaques scriptées via Python/Bash/PowerShell — la binaire de l'interpréteur ne change pas, seul le contenu du script
Les processus sous le seuil RSS — les petits processus (< 50 MB par défaut) ne sont pas fingerprintés pour limiter l'overhead ; c'est configurable

Pour les deux premières catégories, les canaries honeypot sont la couche complémentaire : un attaquant qui lit un chemin canary en mémoire déclenche tout de même une alerte.

Récapitulatif

	EDR traditionnel (externe)	Process DNA (monsys)
Visibilité dans sandbox VM	✗ (périmètre hyperviseur)	✓ (tourne dans la VM)
Détection swap binaire	Basée comportement (lente)	Comparaison de hash (< 60s)
Faux positifs sur updates	s.o.	Supprimés via manifest
Corrélation mouvement latéral	Silo	Intégrée (LateralMovementWorker)
Overhead	Module noyau / agent	~5 MB binaire Rust, < 1 % CPU

Process DNA n'est pas un remplacement de la stack EDR complète pour les organisations avec un SOC dédié. C'est une couche qui fonctionne là où l'EDR est aveugle — dans le périmètre VM — et qui se corrèle avec le reste du pipeline sans nécessiter de plateforme séparée.

Vous voulez tester ? Installez l'agent sur un serveur, attendez le premier cycle d'inventaire, puis remplacez une binaire manuellement. L'alerte apparaît dans les 60 secondes. Les cinq premiers serveurs sont gratuits : monsys.ai/fr/signup.

Process DNA : comment un hash SHA256 de /proc/<pid>/exe surprend un attaquant