EXECVE auditd : auid, ses et arguments hexadécimaux

En bref. Avec une règle execve chargée, audit.log enregistre chaque programme exécuté sur l’hôte. Une exécution correspond à plusieurs enregistrements (SYSCALL, EXECVE, CWD, PATH, PROCTITLE) partageant le même horodatage msg=audit(sec.msec:serial). Regroupez par cet horodatage, décodez les arguments encodés en hexadécimal, et utilisez auid (l’utilisateur de connexion) et ses (la session de connexion) pour suivre un utilisateur à travers sudo -i jusque dans un shell root, là où auth.log devient aveugle.

L’hôte en dispose-t-il seulement ?

auditd est installé et activé par défaut sur RHEL et Fedora, pas sur Debian ni Ubuntu. Même là où il tourne, aucun enregistrement execve n’existe sans règle qui les demande, par exemple :

-a always,exit -F arch=b64 -S execve -k exec

Lisez /etc/audit/rules.d/*.rules dans l’image (et la sortie de auditctl -l si elle a été collectée à chaud) avant de tirer la moindre conclusion d’enregistrements absents. Sans règle execve, vous obtenez tout de même les événements de l’espace utilisateur : USER_AUTH, USER_LOGIN, USER_START, USER_END, USER_CMD (sudo), USER_CHAUTHTOK (changement de mot de passe), ADD_USER et les modifications de la configuration d’audit.

Un événement, plusieurs enregistrements

type=SYSCALL msg=audit(1789381120.086:181322): arch=c000003e syscall=59 success=yes exit=0 ppid=3200 pid=3204 auid=1001 uid=0 gid=0 euid=0 tty=pts1 ses=114 comm="tar" exe="/usr/bin/tar" key="exec"
type=EXECVE msg=audit(1789381120.086:181322): argc=4 a0="tar" a1="czf" a2="/tmp/.f.tgz" a3=2F7372762F66696E616E63652F513320636C6F7365
type=CWD msg=audit(1789381120.086:181322): cwd="/home/svc_backup"
type=PATH msg=audit(1789381120.086:181322): item=0 name="/usr/bin/tar" inode=13113204 ... nametype=NORMAL
type=PROCTITLE msg=audit(1789381120.086:181322): proctitle=74617200637A66002F746D702F2E662E74677A002F7372762F66696E616E63652F513320636C6F7365
type=EOE msg=audit(1789381120.086:181322):

Ces six lignes forment un seul événement. L’horodatage 1789381120.086:181322 se compose des secondes depuis l’epoch (UTC), des millisecondes et d’un numéro de série généré par le noyau. Ce numéro repart de zéro au démarrage : regroupez donc par l’horodatage complet, pas par le seul numéro de série. Les enregistrements de différents événements peuvent s’entrelacer dans le fichier ; le regroupement par horodatage gère ce cas.

Réassembler la ligne de commande

L’enregistrement EXECVE contient argc et un champ par argument :

Les valeurs entre guillemets (a1="czf") sont en texte clair.
Les valeurs hexadécimales sans guillemets (a3=2F7372...) sont encodées parce que l’argument contient une espace, un guillemet double, un caractère de contrôle ou des octets non ASCII. Le décodage de 2F7372762F66696E616E63652F513320636C6F7365 donne /srv/finance/Q3 close : un seul argument contenant une espace, que la ligne sudo en clair d’auth.log ne permet pas de distinguer de deux arguments.
Les arguments longs sont découpés : a1_len=N suivi de morceaux a1[0]=..., a1[1]=..., et une longue ligne de commande peut s’étendre sur plusieurs enregistrements EXECVE du même événement. Concaténez les morceaux dans l’ordre avant de décoder.
PROCTITLE contient la ligne de commande telle que le processus la voyait, encodée en hexadécimal avec des séparateurs NUL, et tronquée par le noyau pour les lignes longues. Préférez EXECVE lorsque les deux existent.

CWD donne le répertoire de travail, ce qui permet de résoudre les chemins relatifs des arguments. Les enregistrements PATH listent l’exécutable et le chargeur, avec inode et propriétaire.

auid et ses : suivre l’utilisateur jusqu’en root

L’enregistrement SYSCALL porte deux identités :

uid, euid : l’identité sous laquelle le processus tourne à cet instant (0 dans un shell root).
auid : l’UID de connexion d’audit, fixé une fois lorsque l’utilisateur se connecte (l’enregistrement LOGIN : old-auid=4294967295 auid=1001) et hérité par chaque processus enfant, y compris via sudo et su. 4294967295 signifie non défini : démons et processus lancés au démarrage.

Et une session :

ses : l’identifiant de session d’audit, fixé au même moment. Chaque commande de cette connexion, en tant qu’utilisateur ou en root, le porte.

En pratique : auth.log montre svc_backup lançant sudo -i à 10:04, puis plus rien jusqu’à la fermeture du shell. audit.log, pour ses=114, montre ce qui s’est passé dans ce shell :

type=SYSCALL ... auid=1001 uid=0 euid=0 tty=pts1 ses=114 comm="passwd" exe="/usr/bin/passwd"
type=SYSCALL ... auid=1001 uid=0 euid=0 tty=pts1 ses=114 comm="crontab" exe="/usr/bin/crontab" key="exec"
type=EXECVE  ... argc=4 a0="crontab" a1="-u" a2="svc_backup" a3="/tmp/.c"

uid=0 indique que root l’a exécuté ; auid=1001 indique qu’il s’agissait de la connexion de svc_backup. Le journal stocke les mêmes valeurs sous _AUDIT_LOGINUID et _AUDIT_SESSION, ce qui permet de relier les entrées du journal à la session d’audit.

RAW et ENRICHED

Avec log_format = ENRICHED (la valeur par défaut en amont dans les versions actuelles d’audit ; les distributions peuvent la modifier), auditd ajoute les noms résolus après un octet 0x1D, en majuscules : AUID="svc_backup" UID="root" SYSCALL=execve. Ces noms ont été résolus sur l’hôte d’origine, ce qui les rend plus fiables qu’un ausearch -i lancé sur un poste d’analyse doté d’un autre /etc/passwd. Avec RAW, résolvez les UID avec le /etc/passwd de l’image.

ausearch pour les grands classiques

ausearch -if audit.log -m EXECVE -ul 1001 -i        # tout ce qui a été exécuté sous l’UID de connexion 1001
ausearch -if audit.log --session 114 -i             # une session de connexion
ausearch -if audit.log -m USER_CMD -i               # commandes sudo, hexadécimal décodé
ausearch -if audit.log -m CONFIG_CHANGE,DAEMON_END -i   # altération de l’audit

-i interprète les valeurs à l’aide des fichiers de comptes de la machine d’analyse, sauf si le journal est au format ENRICHED.

Ce qu’il faut chercher

De la reconnaissance juste après la connexion : id, uname, cat /etc/passwd, sudo -l.
De la persistance : crontab, systemctl --user enable, des écritures sous /etc/systemd/system ou ~/.config/systemd/user.
De la préparation et de l’exfiltration : tar, zip, rclone, curl, scp avec des chemins vers des données sensibles.
De l’anti-forensique : rm de fichiers journal, scripts lancés contre /var/log/wtmp, ln -sf /dev/null ~/.bash_history, history -c (une commande interne du shell, donc sans enregistrement execve), auditctl -D ou -e 0.
Des lignes de commande évoquant un reverse shell : interpréteurs ou outils réseau dont les arguments redirigent un shell vers une adresse distante. Traitez une correspondance de motif comme une piste et lisez la liste complète des arguments.

Dans le navigateur

Linux Log Parser regroupe les enregistrements d’audit par horodatage, réassemble les arguments EXECVE y compris hexadécimaux et découpés, lit les journaux RAW et ENRICHED, utilise ses pour rattacher les commandes aux sessions reconstituées, et signale la persistance, les commandes d’effacement de journaux, les outils suspects et les motifs de type reverse shell. L’investigation pas à pas suit ses=114 de bout en bout, et la fiche auditd couvre les règles, la rétention et les types d’enregistrements.