Ingénierie de détection Linux avec Auditd

Introduction

Les systèmes Unix et Linux fonctionnent dans l'ombre et sous-tendent discrètement une grande partie de notre infrastructure technologique. Face à la complexité croissante des menaces qui visent ces systèmes, il est plus important que jamais de garantir leur sécurité.

Auditd est l'un des outils fondamentaux de l'arsenal des ingénieurs chargés de la détection de la sécurité au sein des systèmes Unix et Linux. Ce puissant utilitaire est conçu pour surveiller et enregistrer les événements du système, en fournissant une piste d'audit détaillée de qui a fait quoi et quand. Il agit comme un chien de garde, patrouillant et enregistrant des informations détaillées sur les appels système, les accès aux fichiers et les modifications du système, qui sont cruciales pour l'analyse médico-légale et la surveillance en temps réel.

L'objectif de cet article est multiple :

1. Notre objectif est de fournir des informations supplémentaires sur Auditd, de présenter ses capacités et l'immense pouvoir qu'il détient dans l'ingénierie de la détection de la sécurité.
2. Nous vous guiderons dans la mise en place d'Auditd sur vos propres systèmes, en l'adaptant à vos besoins spécifiques en matière de surveillance. En comprenant comment créer et modifier les règles Auditd, vous apprendrez à capturer le comportement exact que vous souhaitez surveiller et à interpréter les journaux résultants pour créer vos propres règles de détection.
3. Nous vous présenterons Auditd Manager, un outil d'intégration qui améliore l'utilité d'Auditd en simplifiant la gestion d'Auditd sur l'ensemble des systèmes.

À la fin de ce billet, vous aurez non seulement appris à utiliser Auditd Manager pour intégrer certaines de nos règles de détection prédéfinies dans votre stratégie de sécurité, mais vous aurez également acquis une connaissance approfondie d'Auditd et de la manière dont vous pouvez l'utiliser pour élaborer vos propres règles de détection.

Introduction à l'auditd

Auditd est un outil Linux conçu pour surveiller et enregistrer les événements du système afin de fournir une piste d'audit complète des activités des utilisateurs, des modifications du système et de l'accès à la sécurité. Auditd fonctionne en s'accrochant au noyau Linux, capturant des informations détaillées sur les appels système et d'autres événements système au fur et à mesure qu'ils se produisent. Ces événements sont ensuite enregistrés dans un fichier, ce qui permet d'obtenir un enregistrement horodaté. Les administrateurs peuvent définir des règles qui précisent les événements à enregistrer, ce qui permet de se concentrer sur des domaines d'intérêt ou de préoccupation spécifiques. Les données enregistrées peuvent être utilisées à diverses fins, de l'audit de conformité à l'analyse médico-légale détaillée.

Configuration de l'auditd

Pour commencer à utiliser Auditd, Elastic propose plusieurs options :

• Module Auditd d'Auditbeat
• Module Auditd de Filebeat
• Intégration des logs Auditd d'Elastic Agent
• Intégration de l'Auditd Manager d'Elastic Agent

Dans cet article, nous nous concentrerons sur les deux derniers, en tirant parti de l'agent Elastic pour ingérer facilement les journaux dans Elasticsearch. Si vous ne connaissez pas Elasticsearch, vous pouvez facilement créer un compte Elastic Cloud avec une licence d'essai de 30 jours, ou pour des tests locaux, vous pouvez télécharger le projet Elastic Container et définir la valeur de la licence à trial dans le fichier .env. fichier.

N'hésitez pas à suivre le processus en utilisant Auditbeat ou Filebeat - pour les instructions d'installation, consultez la documentation mentionnée ci-dessus. Comme l'intégration des journaux Auditd fonctionne en analysant le fichier audit.log, vous devez installer Auditd sur l'hôte Linux à partir duquel vous souhaitez collecter les journaux. Selon la distribution Linux et le gestionnaire de paquets choisi, le paquet Auditd doit être installé et le service Auditd doit être démarré et activé. Pour les distributions basées sur Debian :

sudo apt update
sudo apt install auditd
sudo systemctl start auditd
sudo systemctl enable auditd

Le fichier /var/log/audit/audit.log devrait maintenant être alimenté par les journaux d'Auditd. Ensuite, vous devez installer l'intégration Auditd Logs, créer une politique d'agent dans Fleet avec l'intégration nouvellement installée, et appliquer l'intégration à un agent Elastic compatible avec Auditd.

Les paramètres par défaut devraient suffire dans la plupart des cas. Ensuite, vous devez ajouter l'intégration à une politique d'agent, et ajouter la politique d'agent aux agents Elastic à partir desquels vous souhaitez collecter des données. L'agent Elastic envoie les journaux dans le répertoire logs-auditd.log-[namespace]. flux de données. Vous pouvez maintenant créer une nouvelle vue de données qui correspondra uniquement aux journaux Auditd entrants.

Vous pouvez maintenant explorer les journaux Auditd ingérés. Mais comme vous le remarquerez rapidement, Auditd n'enregistre pas grand-chose par défaut - vous devez utiliser les règles d'Auditd pour exploiter tout son potentiel.

Auditd rules

Les règles d'audit sont des directives utilisées pour spécifier les activités du système à surveiller et à enregistrer, ce qui permet un contrôle granulaire du processus d'audit de sécurité. Ces règles sont généralement configurées dans le fichier /etc/audit/audit.rules. Les règles d'audit se présentent sous la forme de 3 : control, file, et syscall. Pour plus d'informations, cliquez ici.

Règles relatives aux types de contrôle

Dans la plupart des cas, le type de contrôle est utilisé pour configurer Auditd plutôt que pour spécifier les événements à surveiller. Par défaut, le fichier de règles d'audit contient les paramètres de type de contrôle suivants :

-D
-b 8192
-f 1
--backlog_wait_time 60000

• -DLe fichier de règles est un fichier de règles : il supprime toutes les règles au lancement (Auditd analyse les règles dans le fichier de haut en bas). La suppression de toutes les règles au lancement garantit une configuration propre).
• -b 8192: définit la quantité maximale de tampons d'audit existants dans le noyau.
• -f 1: définir le mode de défaillance de l'Auditd pour qu'il enregistre les événements.
• --backlog_wait_time 60000: spécifie le temps (en ms) pendant lequel le système d'audit attendra que la limite de l'arriéré d'audit soit atteinte avant d'abandonner les enregistrements d'audit.

Règles du système de fichiers

En vous basant sur ces paramètres de type de contrôle par défaut, vous pouvez créer des règles de système de fichiers, parfois appelées "montres". Ces règles nous permettent de surveiller les fichiers d'intérêt pour les actions de lecture, d'écriture, de modification et d'exécution. Une règle de système de fichiers typique se présente comme suit :

-w [path-to-file] -p [permissions] -k [keyname]

• -wle chemin d'accès au fichier ou au répertoire à surveiller.
• -p: l'une des autorisations de lecture (r), d'écriture (w), d'exécution (e) ou de modification (a).
• -k: le nom d'un identifiant clé qui peut être utilisé pour faciliter la recherche dans les journaux d'auditd.

Si vous souhaitez surveiller les lectures, écritures et modifications du fichier /etc/shadow et enregistrer ces événements dans une clé nommée shadow_access, vous pouvez définir la règle suivante :

-w /etc/shadow -p rwa -k shadow_access

Règles d'appel au système

La véritable puissance d'Auditd se révèle lorsque vous travaillez avec ses règles d'appel système. Les règles d'appel système d'Auditd sont des configurations qui spécifient les appels système (syscalls) à surveiller et à enregistrer, ce qui permet un suivi détaillé de l'activité du système et des interactions avec le noyau du système d'exploitation. Étant donné que chaque appel de système est intercepté et mis en correspondance avec la règle, il est important d'exploiter cette fonctionnalité avec précaution en ne capturant que les appels de système intéressants et, si possible, en capturant plusieurs de ces appels de système dans une seule règle. Une règle syscall typique se présente comme suit :

-a [action],[filter] -S [syscall] -F [field=value] -k [keyname]

Vous pouvez utiliser l'indicateur -a suivi de action,filter pour choisir quand un événement est enregistré, où action peut être always (toujours créer un événement) ou never (ne jamais créer d'événement).

Le filtre peut être l'un des éléments suivants

• task: enregistre les événements liés à la création de tâches.
• entry: enregistre les points d'entrée des syscalls.
• exit: enregistre les sorties/résultats de l'appel système.
• user: enregistre les événements survenant dans l'espace utilisateur.
• exclude: exclut les événements de la journalisation.

Ensuite, vous avez :

• -S: le syscall qui vous intéresse (nom ou numéro de syscall).
• -F: un ou plusieurs filtres pour choisir les éléments à comparer.
• -k: l'identifiant de la clé.

Grâce aux informations fournies ci-dessus, vous devriez être en mesure de comprendre les bases de la plupart des règles de l'Auditd. Pour plus d'informations et des exemples de valeurs qui peuvent être ajoutées à ces règles, vous pouvez lire ici.

L'élaboration et le test d'un fichier de règles Auditd complet et dédié à votre organisation peuvent sembler décourageants. Heureusement, il existe de bons exemples de fichiers de règles publics disponibles sur GitHub. Le modèle Neo23x0, qui constitue un bon équilibre entre visibilité et performance, est l'un de vos modèles préférés.

L'un des inconvénients de l'intégration des journaux Auditd est que vous devez installer manuellement Auditd sur chaque hôte que vous souhaitez surveiller, et appliquer manuellement le fichier de règles à chaque instance Auditd en cours d'exécution. Cela signifie que chaque fois que vous voudrez mettre à jour le fichier de règles, vous devrez le faire sur tous les hôtes. De nos jours, de nombreuses organisations utilisent des outils de gestion qui peuvent rendre ce processus moins fastidieux. Cependant, Elastic propose également un autre moyen d'ingérer les journaux Auditd grâce à l'intégration de l'Auditd Manager, qui allège la charge de gestion.

Introduction à Auditd Manager et à son installation

L'intégration du gestionnaire Auditd reçoit des événements d'audit du cadre d'audit Linux qui fait partie du noyau Linux. Cette intégration établit un abonnement au noyau pour recevoir les événements au fur et à mesure qu'ils se produisent. Le cadre d'audit Linux peut envoyer plusieurs messages pour un seul événement vérifiable. Par exemple, un appel syscall rename() entraîne l'envoi de huit messages distincts par le noyau. Chaque message décrit un aspect différent de l'activité en cours (l'appel système lui-même, les chemins d'accès aux fichiers, le répertoire de travail actuel, le titre du processus). Cette intégration combinera toutes les données de chacun des messages en un seul événement. Pour plus d'informations sur Auditd Manager, cliquez ici.

En outre, Auditd Manager résout le problème de la gestion, car il permet une gestion centralisée par le biais de Fleet. Une mise à jour de l'intégration sera automatiquement appliquée à tous les agents Elastic qui font partie de la politique d'agent modifiée.

La mise en place de l'intégration d'Auditd Manager est simple. Vous devez vous assurer que Auditd ne fonctionne plus sur nos hôtes, en arrêtant et en désactivant le service.

sudo systemctl stop auditd
sudo systemctl disable auditd

Vous pouvez maintenant supprimer l'intégration Auditd Logs de notre politique d'agent, et à la place installer/additionner l'intégration Auditd Manager.

Plusieurs options sont disponibles pour configurer l'intégration. Auditd Manager nous offre la possibilité de définir la configuration de l'audit comme étant immuable (de manière similaire à la définition de la règle de type de contrôle -e 2 dans la configuration d'Auditd), ce qui offre une sécurité supplémentaire dans la mesure où les utilisateurs non autorisés ne peuvent pas modifier le système d'audit, ce qui rend plus difficile la dissimulation d'une activité malveillante.

Vous pouvez utiliser la fonctionnalité Resolve IDs pour permettre la résolution des UID et des GID en fonction des noms qui leur sont associés.

Pour la gestion des règles d'Auditd, vous pouvez soit fournir les règles dans la section Règles d'audit, soit utiliser un fichier de règles et spécifier le chemin d'accès pour lire ce fichier. Le format de la règle est similaire à celui de l'intégration des journaux d'audit. Cependant, au lieu de fournir des drapeaux de contrôle dans notre fichier de règles, vous pouvez définir ces options dans les paramètres d'intégration.

Auditd Manager purge automatiquement toutes les règles existantes avant d'en ajouter de nouvelles dans la configuration, ce qui rend inutile la spécification de l'indicateur -D dans le fichier de règles. En outre, vous pouvez définir notre mode d'échec sur silent dans les paramètres, et vous n'avez donc pas besoin de fournir le drapeau -f non plus.

Vous pouvez également définir la limite de l'arriéré, ce qui revient à définir l'indicateur -b.

Il existe également une option de réglage de la stratégie de contre-pression, équivalente au réglage de --backlog_wait_time.

Enfin, cochez l'option permettant de conserver l'événement original, ce qui vous permettra de l'analyser plus facilement à l'avenir.

Vous pouvez maintenant enregistrer l'intégration et l'appliquer à la stratégie de l'agent pour les hôtes dont vous souhaitez recevoir les journaux Auditd.

Dépannage du fichier de règles d'auditd

Le fichier de règles fourni par Neo23x0 ne fonctionne pas par défaut pour Auditd Manager. Pour que cela fonctionne, vous devrez procéder à quelques ajustements mineurs tels que la suppression des indicateurs de type de contrôle, une conversion de l'UID en utilisateur pour un utilisateur qui n'est pas présent sur les systèmes par défaut, ou une entrée de règle redondante. Les changements à apporter seront en fin de compte propres à votre environnement.

Vous avez deux possibilités pour identifier les erreurs qui seront générées lors du copier-coller d'un fichier incompatible dans l'intégration de l'Auditd Manager. Vous pouvez naviguer jusqu'à l'agent qui a reçu la police et consulter l'erreur d'entrée d'intégration. Vous pouvez analyser les erreurs une par une et modifier ou supprimer la ligne en conflit.

Vous pouvez également utiliser l'onglet Découvrir, sélectionner notre vue de données Auditd Manger, filtrer les événements où le champ auditd.warnings existe, et passer en revue les avertissements un par un.

Par exemple, vous pouvez voir que l'erreur indique "type de règle inconnu", ce qui est lié au fait que l'Auditd ne prend pas en charge les règles de contrôle. Le message "failed to convert user 'x' to a numeric ID" (échec de la conversion de l'utilisateur 'x' en un identifiant numérique) est lié au fait que l'utilisateur n'existe pas dans le système. Enfin, la règle "x" est un doublon de "x" est liée aux règles dupliquées. Maintenant que vous avez supprimé les entrées conflictuelles et que l'état de notre agent est sain, vous pouvez commencer à analyser les données Auditd !

Analyse des événements de l'Auditd Manager

Maintenant que les données de l'Auditd Manager sont disponibles dans notre cluster Elasticsearch, vous pouvez créer une vue de données pour l'index logs-auditd_manager.auditd* afin de filtrer spécifiquement ces données. Le fichier de règles que nous avons mis en œuvre contient l'entrée suivante :

-w /etc/sudoers -p rw -k priv_esc

Cette opération capture les actions de lecture et d'écriture du fichier /etc/sudoers et écrit ces événements dans un journal avec la clé priv_esc. Exécutons la commande cat /etc/sudoers et analysons l'événement. Examinons d'abord quelques-uns des champs contenant des informations générales.

Vous pouvez voir que le fichier /etc/sudoers a été accédé par le binaire /usr/bin/cat par l'intermédiaire de l'appel de système openat(). Comme le propriétaire et le groupe du fichier sont root, et que l'utilisateur demandant l'accès à ce fichier n'est pas l'UID 0 (root), le syscall openat() a échoué, ce qui est représenté dans le journal. Enfin, vous pouvez voir le tag lié à cette activité spécifique.

En creusant un peu, vous pouvez identifier des informations supplémentaires sur l'événement.

Vous pouvez voir la ligne de commande du processus qui a été exécutée, ainsi que l'ID du processus et l'ID du parent du processus à l'origine de l'activité. En outre, vous pouvez voir de quelle architecture provient l'événement et par quel terminal tty (terminal connecté à l'entrée standard) la commande a été exécutée.

Pour comprendre les valeurs a0-3, vous devez vous plonger dans les appels syscall d'Unix. À ce stade, vous devriez savoir ce qu'est un syscall, mais pour être complet, un syscall Unix (appel système) est une interface fondamentale qui permet à un programme de demander un service au noyau du système d'exploitation, tel que des opérations sur les fichiers, le contrôle des processus ou les communications réseau.

Examinons l'appel de service openat(). En consultant la page de manuel open(2) (source), vous trouverez les informations suivantes.

openat() est une version évoluée de l'appel syscall open(), qui permet d'accéder à un fichier par rapport à un descripteur de fichier de répertoire (dirfd). Ce syscall permet à un programme d'ouvrir un fichier ou un répertoire - une opération cruciale pour de nombreuses tâches du système. Vous pouvez constater que la syscall fait partie de la bibliothèque C standard et qu'elle est disponible dans l'en-tête fcntl.h grâce à l'instruction include de #include <fcntl.h>.

En consultant le manuel, vous pouvez voir que la syntaxe de openat() syscall est la suivante :

int openat(int dirfd, const char *pathname, int flags, /* mode_t mode */);

• dirfd spécifie le descripteur de fichier du répertoire.
• *pathname est un pointeur sur le nom du fichier/répertoire à ouvrir.
• flags déterminer le mode de fonctionnement (par exemple, lecture, écriture, création, etc.).

Pour revenir à notre événement initial, vous êtes maintenant prêt à comprendre les champs auditd.data.a0-a3. Les valeurs a0 à a3 dans un journal d'auditd représentent les arguments transmis à un appel de système. Ces arguments sont essentiels pour comprendre le contexte et les spécificités de l'exécution de la syscall. Voyons comment ces valeurs sont liées à openat() et ce qu'elles nous apprennent sur l'opération tentée, sur la base de notre exploration précédente.

• auditd.data.a0 (dirfd) : La valeur a0, ffffff9c, indique une directive spéciale, AT_FDCWD, suggérant que l'opération est relative au répertoire de travail actuel.
• auditd.data.a1 (pathname) : La valeur a1, 7ffd0f81871d, représente une adresse mémoire hexadécimale pointant vers la chaîne de nom de chemin du fichier ou du répertoire cible. Dans ce cas, il s'agit d'une tentative d'accès au fichier /etc/sudoers.
• auditd.data.a2 (flags) : Reflété par la valeur a2 de 0, l'argument flags spécifie le mode d'accès au fichier. Avec 0 indiquant qu'aucun indicateur spécial n'a été utilisé, cela implique une opération par défaut - très probablement un accès en lecture seule.
• auditd.data.a3 (mode) : La valeur a3, également 0, devient pertinente dans les contextes où le fichier est créé, dictant les permissions définies sur le nouveau fichier.

Sur la base de l'analyse ci-dessus, vous avez maintenant une bonne compréhension de la manière d'interpréter les événements de l'Auditd Manager.

Une autre façon de se faire rapidement une idée de la signification d'un événement Auditd Manager est d'utiliser l'assistant IA intégré d'Elastic. Exécutons la commande whoami et examinons le champ auditd.messages dans l'événement.

Vous pouvez demander à l'assistant Elastic AI de faire le gros du travail et d'analyser l'événement, après quoi vous n'aurez plus qu'à consulter le manuel du syscall pour vous assurer qu'il était correct. Commençons par créer une nouvelle invite système, axée sur l'analyse des journaux Auditd, un peu comme ceci :

Vous pouvez maintenant utiliser l'invite système nouvellement créée et y coller votre message Auditd sans aucun formatage supplémentaire, et recevoir la réponse suivante :

Les outils d'IA générative sont très utiles pour recevoir une explication rapide d'un événement. Mais l'IA générative peut commettre des erreurs, vous devez donc toujours être conscient de l'utilité des outils d'IA pour ce type d'analyse et vérifier les résultats qu'ils génèrent. En particulier lorsque vous exploitez les résultats de ces outils pour développer des règles de détection, car une erreur mineure peut conduire à une logique erronée.

Exemples de règles de détection d'Auditd Manager

Après avoir lu la section précédente, vous devriez avoir suffisamment de connaissances pour commencer à analyser les journaux de l'Auditd Manager. L'ensemble actuel de règles de détection Elastic s'appuie principalement sur l'intégration d'Elastic Defend, mais le nombre de règles qui s'appuient sur Auditd augmente de manière significative. Cette section se penche sur plusieurs règles de détection qui exploitent Auditd, explique pourquoi et tente d'enseigner quelques techniques sous-utilisées pour l'écriture de requêtes de règles de détection.

Possibilité d'utilisation d'un shell inversé via UDP

La règle " Potential Reverse Shell via UDP " vise à identifier les "reverse shells" basés sur UDP. Comme Elastic Defend ne capture pas actuellement le trafic UDP, vous pouvez utiliser Auditd pour combler ce manque de visibilité. La règle s'appuie sur la logique suivante :

sample by host.id, process.pid, process.parent.pid
  [process where host.os.type == "linux" and event.type == "start" and event.action == "executed" and process.name : (
    "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "perl", "python*", "nc", "ncat", "netcat", "php*",
    "ruby", "openssl", "awk", "telnet", "lua*", "socat"
    )]
  [process where host.os.type == "linux" and auditd.data.syscall == "socket" and process.name : (
    "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "perl", "python*", "nc", "ncat", "netcat", "php*",
    "ruby", "openssl", "awk", "telnet", "lua*", "socat"
    ) and auditd.data.a1 == "2"]
  [network where host.os.type == "linux" and event.type == "start" and event.action == "connected-to" and
   process.name : (
    "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "perl", "python*", "nc", "ncat", "netcat", "php*",
    "ruby", "openssl", "awk", "telnet", "lua*", "socat"
    ) and network.direction == "egress" and destination.ip != null and
   not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")]

La règle s'appuie sur la fonctionnalité de l'exemple, qui décrit et fait correspondre une série d'événements non ordonnés chronologiquement. Ainsi, la séquence se déclenchera également si les événements se produisent dans la même milliseconde. En outre, nous nous appuyons sur une approche de liste blanche pour spécifier les binaires suspects capables d'établir une connexion inverse, ce qui permet de minimiser le taux de faux positifs.

Nous garantissons la capture des connexions UDP en exploitant les données Auditd relatives à l'appel de service. socket() syscall.

Nous constatons que la valeur a0 représente le domaine, a1 représente le type et a2 représente le protocole utilisé. Notre règle s'appuie sur la syntaxe auditd.data.a1 == "2", qui se traduit par le type SOCK_DGRAM, qui est UDP.

Enfin, nous veillons à ne capturer que les connexions réseau sortantes de l'hôte et à exclure les adresses de bouclage IPv4 et IPv6, les adresses IPv4 locales et multidiffusion, et à séquencer la requête par process.pid et process.parent.pid afin de nous assurer que les événements proviennent du même processus (parent).

Si nous voulons rechercher des processus suspects ouvrant des sockets UDP, nous pouvons interroger tous les syscalls socket() à l'aide de auditd.data.a1 == "2", compter le nombre d'occurrences distinctes de processus et les trier par ordre croissant pour trouver des anomalies. Pour ce faire, nous pouvons utiliser cette requête ES|QL :

FROM logs-*, auditbeat-*
| EVAL protocol = CASE(
    auditd.data.a1 == "1", "TCP",
    auditd.data.a1 == "2", "UDP"
)
| WHERE host.os.type == "linux" and auditd.data.syscall == "socket" and protocol == "UDP"
| STATS process_count = COUNT(process.name), host_count = COUNT(host.name) by process.name, protocol
| SORT process_count asc
| LIMIT 100

En examinant les résultats, nous pouvons voir apparaître un certain nombre de processus intéressants, qui pourraient constituer un bon point de départ pour la chasse aux menaces.

Shell inversé potentiel de Meterpreter

Un autre type intéressant de connexions inversées pour lequel nous avons utilisé Auditd est la détection du shell Meterpreter, qui est un shell inversé populaire utilisé dans le cadre du Metasploit-Framework. La règle Potential Meterpreter Reverse Shell exploite le comportement d'énumération d'hôtes par défaut de Meterpreter pour détecter sa présence.

sample by host.id, process.pid, user.id
  [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/etc/machine-id"]
  [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/etc/passwd"]
  [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/proc/net/route"]
  [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/proc/net/ipv6_route"]
  [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/proc/net/if_inet6"]

Lorsque Meterpreter démarre, il collecte des informations système par défaut, telles que la machine, l'utilisateur et les informations de routage IP, en lisant des fichiers système spécifiques. Nous pouvons observer ce comportement lors de la décompilation de la charge utile de Meterpreter, car les chemins sont codés en dur dans le binaire.

Notre logique de détection s'appuie sur auditd.data.a2 == “1b6”, car elle est cohérente avec le comportement du Meterpreter. Nous pouvons constater que Meterpreter exploite cette combinaison spécifique de syscall pour lire les fichiers en examinant la façon dont Meterpreter ouvre les gestionnaires de fichiers.

À titre d'information, vous trouverez dans la capture d'écran ci-dessous d'autres chemins d'accès à partir desquels Meterpreter effectue des lectures.

Nous pouvons exploiter ES|QL pour analyser un ensemble d'interpréteurs de commandes inversés Meterpreter, et découvrir facilement quels chemins de fichiers sont accédés par chacun d'entre eux.

FROM logs-*, auditbeat-*
| WHERE host.os.type == "linux" and event.action == "opened-file" and process.name in ("shell-x64.elf", "JBNhk", "reverse.elf", "shell.elf", "elf") and auditd.data.a2 == "1b6"
| STATS file_access = COUNT_DISTINCT(process.name) by file.path
| SORT file_access desc
| LIMIT 100

Dans cet exemple, nous n'analysons que 5 shells Meterpreter, mais en utilisant ES|QL, nous pouvons facilement étendre cette analyse à un plus grand nombre. Sur la base des informations ci-dessus, nous pouvons constater que les chemins sélectionnés pour la règle de détection sont présents dans les cinq échantillons.

En combinant la logique ci-dessus, nous pouvons potentiellement découvrir des charges utiles Linux Meterpreter.

Attaque par force brute détectée dans le cadre du programme FTP/RDP de Linux

Étant donné qu'il existe un grand nombre de clients FTP/RDP différents pour Linux, et que les journaux d'authentification ne sont pas tous mis en œuvre de la même manière, vous pouvez utiliser le champ auditd.data.terminal d'Auditd pour détecter les différentes mises en œuvre FTP/RDP. Notre logique de détection FTP se présente comme suit :

sequence by host.id, auditd.data.addr, related.user with maxspan=3s
  [authentication where host.os.type == "linux" and event.action == "authenticated" and 
   auditd.data.terminal == "ftp" and event.outcome == "failure" and auditd.data.addr != null and 
   auditd.data.addr != "0.0.0.0" and auditd.data.addr != "::"] with runs=5

  [authentication where host.os.type == "linux" and event.action  == "authenticated" and 
   auditd.data.terminal == "ftp" and event.outcome == "success" and auditd.data.addr != null and 
   auditd.data.addr != "0.0.0.0" and auditd.data.addr != "::"] | tail 1

Ici, nous enchaînons 5 tentatives de connexion échouées avec 1 tentatives de connexion réussies sur le même hôte, à partir de la même IP et pour le même utilisateur. Nous tirons parti de la fonction "tail" qui fonctionne de la même manière que "tail" sous Unix, en sélectionnant les X dernières alertes plutôt que toutes les alertes dans le délai imparti. Cela n'affecte pas l'interface des règles de détection SIEM, mais sert uniquement à faciliter la lecture, car les attaques par force brute peuvent rapidement donner lieu à de nombreuses alertes.

Bien que nous utilisions différents outils FTP tels que vsftpd, l'entrée auditd.data.terminal reste similaire d'un outil à l'autre, ce qui nous permet de capturer un plus large éventail d'attaques FTP par force brute. Notre règle de détection RDP s'appuie sur une logique similaire :

sequence by host.id, related.user with maxspan=5s
  [authentication where host.os.type == "linux" and event.action == "authenticated" and
   auditd.data.terminal : "*rdp*" and event.outcome == "failure"] with runs=10
  [authentication where host.os.type == "linux" and event.action  == "authenticated" and
   auditd.data.terminal : "*rdp*" and event.outcome == "success"] | tail 1

Étant donné que les champs auditd.data.terminal des différents clients RDP ne sont pas cohérents, nous pouvons utiliser des caractères génériques pour capturer leurs événements d'authentification.

Connexion réseau à partir d'un binaire avec région mémoire RWX

L'appel système mprotect() est utilisé pour modifier les protections d'accès à une région de la mémoire qui a déjà été allouée. Ce syscall permet à un processus de modifier les permissions des pages de son espace d'adressage virtuel, en activant ou en désactivant les permissions de lecture, d'écriture et d'exécution pour ces pages. L'objectif de cette règle de détection est de détecter les connexions réseau des binaires pour lesquels les autorisations de lecture, d'écriture et d'exécution de la région mémoire sont définies. Jetons un coup d'œil à l'appel de service.

Pour notre logique de règle de détection, la valeur prot est la plus importante. Vous pouvez voir que prot peut avoir les drapeaux d'accès suivants :

Comme indiqué, prot est un OU bit à bit des valeurs de la liste. Ainsi, pour les autorisations de lecture, d'écriture et d'exécution, nous recherchons un int de :

int prot = PROT_READ | PROT_WRITE | PROT_EXEC;

Cela se traduit par une valeur de 0x7 après la conversion en bits, et nous allons donc nous intéresser à une valeur de auditd.data.a2 == “7”. Nous avons créé deux règles de détection qui s'appuient sur cette logique - Exécution inconnue d'un binaire avec une région de mémoire RWX et Connexion réseau d'un binaire avec une région de mémoire RWX. Les règles de détection qui s'appuient sur des configurations spécifiques d'Auditd pour fonctionner, auront une note sur la règle à ajouter dans leur guide d'installation :

L'antériorité s'appuie sur le type de règle new_terms, qui nous permet de détecter des termes précédemment inconnus dans une fenêtre temporelle spécifiée. Cela nous permet de détecter les binaires avec des permissions RWX qui sont vus sur un hôte spécifique pour la première fois, tout en réduisant les faux positifs pour les binaires qui sont trop permissifs mais utilisés sur une base régulière.

Ce dernier s'appuie sur la logique de détection suivante :

sample by host.id, process.pid, process.name
[process where host.os.type == "linux" and auditd.data.syscall == "mprotect" and auditd.data.a2 == "7"]
[network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and
   not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")
]

Nous observons l'exécution d'un processus avec ces autorisations RWX, après quoi une connexion réseau (à l'exclusion des adresses loopback, multicast et link-local) est initiée.

Il est intéressant de noter que Metasploit attribue souvent ces autorisations RWX à des régions spécifiques de ses charges utiles générées. Par exemple, l'un des événements qui déclenchent cette logique de détection dans une pile de tests est lié à l'exécution de la charge utile Postgres de Metasploit pour Linux. En analysant le code source de ce payload, vous pouvez voir que la fonction payload_so définit les drapeaux PROT_READ, PROT_WRITE et PROT_EXEC.

Ensuite, une région de mémoire spécifique, avec une taille de page spécifique de 0x1000, reçoit les drapeaux d'accès RWX de la même manière que celle décrite précédemment.

Après avoir exécuté la charge utile et interrogé la pile, vous pouvez voir que plusieurs résultats sont renvoyés, qui sont tous liés à des charges utiles Metasploit Meterpreter.

Si vous vous concentrez sur la charge utile Postgres que nous avons analysée précédemment, vous pouvez voir le chemin d'exécution exact de la charge utile grâce à notre analyseur visuel d'événements. Elastic Security permet d'analyser tout événement détecté par Elastic Endpoint à l'aide d'un analyseur visuel basé sur les processus, qui montre une chronologie graphique des processus qui ont conduit à l'alerte et des événements qui se sont produits immédiatement après. L'examen des événements dans l'analyseur visuel d'événements est utile pour déterminer l'origine d'une activité potentiellement malveillante et d'autres zones de votre environnement qui pourraient être compromises. Il permet également aux analystes de la sécurité d'analyser en profondeur tous les hôtes, processus et autres événements connexes afin de faciliter leurs investigations.

Dans l'analyseur, vous pouvez voir que perl est utilisé pour créer et remplir la charge utile jBNhk dans le répertoire /tmp (avec les autorisations RWX) et pour lancer un shell Meterpreter inversé.

Conclusion

Dans cet article, nous avons plongé dans le monde de l'Auditd, en expliquant ce qu'il est et son objectif. Nous vous avons montré comment mettre en place et faire fonctionner Auditd, comment canaliser ces journaux dans Elasticsearch afin d'améliorer la visibilité Unix/Linux et vous permettre d'améliorer vos compétences en matière d'ingénierie de détection Linux. Nous avons discuté de la manière d'élaborer des règles Auditd pour garder un œil sur des activités spécifiques, et de la manière de donner un sens aux événements qu'elles génèrent. Pour vous faciliter la vie, nous avons introduit Auditd Manager, une intégration créée par Elastic pour vous décharger d'une partie de la gestion. Enfin, nous avons terminé en explorant diverses règles de détection et certaines des recherches qui ont permis de les créer, afin de vous permettre de tirer le meilleur parti de cette source de données.

Nous espérons que ce guide vous sera utile ! Incorporer Auditd dans vos systèmes Unix est une décision intelligente pour une meilleure visibilité de la sécurité. Que vous décidiez d'utiliser nos règles de détection prédéfinies ou de créer vos propres règles, Auditd peut vraiment renforcer votre sécurité Unix.