Rootkit Linux contournant Elastic EDR : Singularity révélé

  • Des chercheurs présentent Singularity, un rootkit Linux capable de contourner Elastic EDR grâce à des techniques avancées.
  • Stratégies clés : obfuscation des chaînes de caractères, randomisation des symboles, fragmentation et chargement en mémoire, et appels système directs.
  • Fonctions malveillantes : dissimulation de processus, de fichiers et de connexions, porte dérobée ICMP et élévation de privilèges.
  • Impact sur l'Europe et l'Espagne : nécessité urgente de surveiller l'intégrité du noyau et d'appliquer une défense approfondie grâce à l'analyse forensique de la mémoire.

Rootkit Linux contournant Elastic EDR

Un groupe de chercheurs a démontré que rootkit Linux appelé Singularity qui parvient à passer inaperçue auprès d'Elastic Security EDR, ce qui met en évidence d'importantes limitations de la détection au niveau du noyau. Cette preuve de concept n'est pas purement théorique : Elle combine des techniques d'obscurcissement et d'évasion. réduire à zéro les signaux qui trahiraient normalement un module malveillant.

Cette découverte inquiète les équipes de sécurité européennes, notamment en Espagne, car Elastic déclenche généralement plus de 26 alertes. contre les rootkits classiques, et dans ce cas précis, ils n'ont pas été déclenchés. L'étude, publiée à des fins pédagogiques par 0xMatheuZ, montre que méthodes basées sur la signature et le modèle Ils sont en difficulté face à des adversaires qui perfectionnent leur ingénierie.

Comment déjouer Elastic EDR : principales techniques d’évasion

Évasion EDR sous Linux

Le premier avantage de la singularité est le obfuscation de chaînes de caractères à la compilationDécompose les littéraux sensibles (par exemple, « GPL » ou « kallsyms_lookup_name ») en blocs contigus que le compilateur C peut comprendre. recompose automatiquementempêcher les scanners comme YARA de détecter les chaînes de caractères malveillantes continues sans sacrifier les fonctionnalités.

En parallèle, cela s'applique randomisation des noms de symbolesAu lieu d'identifiants prévisibles comme hook_getdents ou hide_module, il adopte des balises génériques avec des préfixes qui Ils imitent le noyau lui-même. (sys, kern, dev), brouillant la trace des fonctions suspectes et désarmant les règles de détection basées sur le nom.

L'étape suivante est le fragmentation des modules en fragments chiffrés qui ne sont réassemblés qu'en mémoire. Les fragments sont encodés avec XOR et un chargeur utilise memfd_create pour éviter de laisser des traces sur le disque ; lors de l'insertion, il utilise appels système directs (y compris finit_module) en utilisant l'assembleur en ligne, évitant les wrappers libc que de nombreux EDR surveillent.

Il camoufle également les auxiliaires ftrace : les fonctions généralement surveillées (telles que fh_install_hook ou fh_remove_hook) sont renommer de manière déterministe avec des identifiants aléatoires, en conservant leur comportement mais en brisant Signatures élastiques ciblant les rootkits génériques.

Au niveau comportemental, les chercheurs contournent les règles du reverse shell en écrivant d'abord la charge utile sur le disque, puis en l'exécutant avec Lignes de commande « propres »De plus, le rootkit masque immédiatement les processus en cours d'exécution à l'aide de signaux spécifiques, ce qui complique la corrélation. entre les événements et l'activité réelle.

Capacités et risques des rootkits dans les environnements européens

Risques liés aux rootkits sous Linux

Au-delà de l'évasion, Singularity intègre des fonctions offensives : elle peut masquer les processus dans /proc, en dissimulant les fichiers et répertoires associés à des modèles tels que « singularité » ou « matheuz », et dissimuler les connexions TCP (par exemple, sur le port 8081). Il permet également l'élévation de privilèges via signaux personnalisés ou variables environnementaleset offre une porte dérobée ICMP capable d'activer des shells distants.

Le projet ajoute des défenses anti-analyse, bloquant les traces et dossiers de désinfection pour réduire le bruit lors des analyses forensiques. Le chargeur est compilé statiquement et peut fonctionner dans des environnements moins surveillés, renforçant ainsi une chaîne d'exécution dans laquelle Le module entier ne touche jamais le disque Et par conséquent, l'analyse statique atteint ses limites.

Pour les organisations en Espagne et dans le reste de l'Europe qui dépendent d'Elastic Defend, cette affaire les oblige à règles de détection des avis et renforcer la surveillance de bas niveau. La combinaison de l'obfuscation, du chargement en mémoire et des appels système directs révèle une surface où les contrôles comportementaux sont limités. Ils ne capturent pas le contexte du noyau.

Les équipes SOC devraient donner la priorité aux surveillance de l'intégrité du noyau (par exemple, la validation LKM et les protections contre le chargement non autorisé), intègrent l'analyse forensique de la mémoire et Corrélation du signal eBPF avec la télémétrie système, et appliquer une défense en profondeur qui combine heuristiques, listes blanches, durcissement et mise à jour continue des signatures.

Dans les environnements critiques, il est conseillé de renforcer les politiques visant à réduire la surface d'attaque : limiter ou désactiver la possibilité de charger des modules, renforcer les politiques de sécurité, et capacités (CAP_SYS_MODULE)Surveillez l'utilisation de memfd_create et détectez les anomalies dans les noms de symboles. Le tout sans dépendre exclusivement d'EDR, mais en combinant différentes approches. plusieurs niveaux de contrôle et des vérifications croisées.

Le cas de la Singularité démontre que, face à des adversaires qui perfectionnent leur obscurcissement, les défenseurs doivent évoluer vers techniques d'analyse plus approfondies et orchestrée. Une détection fiable des menaces au niveau du noyau implique l'ajout d'intégrité, de mémoire et de corrélation avancée à l'EDR afin de réduire les angles morts et d'élever le niveau de résilience.