09/18/2026, 14.18
Condividi su Facebook Condividi su Twitter Condividi su Pinterest Condividi su Telegram Condividi su WhatsApp

Singularity: el rootkit que blinda el núvol Linux contra Elastic Defend

El rootkit Singularity aconsegueix evadir Elastic Defend manipulant eBPF i YARA. Analitzem el risc per a les infraestructures tecnològiques de Catalunya i Espanya.
Singularity: el rootkit que blinda el núvol Linux contra Elastic Defend
En síntesi
  • El rootkit Singularity eludeix la detecció d'Elastic Defend mitjançant la manipulació de mapes eBPF.
  • Utilitza tècniques d'ofuscació, fragmentació de mòduls i randomització de símbols per evitar regles YARA.
  • L'atac explota la confiança en determinats processos per suprimir la telemetria de càrrega de mòduls.
  • Aquest descobriment posa en dubte la infalibilitat dels EDR basats en eBPF per a la protecció del kernel Linux.

La seguretat a nivell de kernel en sistemes Linux ha experimentat un salt qualitatiu amb la implementació de programes eBPF, que permeten una visibilitat profunda sense comprometre el rendiment. No obstant això, la recerca recent del seguretat 0xMatheuZ ha revelat una vulnerabilitat conceptual crítica: el rootkit anomenat Singularity és capaç de cegar Elastic Defend, una de les solucions d'EDR (Endpoint Detection and Response) més utilitzades en entorns empresarials.

L'anatomia d'una evasió sistemàtica

L'objectiu de Singularity no és simplement infiltrar-se, sinó fer-ho sense deixar rastres en la telemetria del sistema. En un entorn estàndard amb Elastic Defend 9.5.2 instal·lat sobre Ubuntu (kernel 6.8), la càrrega d'aquest rootkit sense modificacions generaria fins a 76 alertes. La majoria d'aquestes deteccions provenen de regles YARA que analitzen el fitxer del mòdul al disc, mentre que la resta prové del monitoratge en temps real basat en BPF.

Per superar aquests obstacles, el rootkit implementa una estratègia de múltiples capes. En primer lloc, utilitza la randomització intel·ligent de noms de símbols i la fragmentació de mòduls. En lloc de carregar un objecte de kernel unitari i reconegut, Singularity divideix el seu codi, l'encodifica mitjançant XOR i l'injecta directament a la memòria utilitzant memfd_create. Aquesta tècnica evita que el fitxer tocai el disc en un format que les regles YARA, com ara Linux_Rootkit_Generic, puguin identificar.

El punt feble de la confiança en eBPF

El nucli de la vulnerabilitat resideix en com Elastic Defend gestiona els processos confiables. El programa eBPF encarregat de monitoritzar la càrrega de mòduls verifica si l'identificador del procés actual (PID) es troba en un mapa de processos confiables abans de recollir la telemetria. Si el procés és classificat com a confiable, el programa BPF finalitza prematurament, evitant la generació de l'esdeveniment que alimentaria la regla de detecció de flags de contaminació (taint_flags).

Singularity no es limita a esperar que un procés confiable execute la càrrega. El carregador del rootkit localitza dinàmicament el mapa BPF corresponent, ja que els identificadors dels mapes poden canviar cada vegada que l'agent d'Elastic es reinicia. Aquesta capacitat de manipulació directa de l'estat de monitoratge permet que el rootkit es registri temporalment com a entitat confiable, suprimint així qualsevol alerta sobre la càrrega de mòduls no signats o externs.

Tècniques avançades d'ofuscació i persistència

Més enllà de la ceguesa del monitor, Singularity aplica mètodes per ocultar la seva activitat una vegada establert al kernel. Una de les funcions més destacades és l'ofuscació del framework Ftrace. El rootkit canvia els noms de les funcions d'ajuda de Ftrace per evitar que els sistemes de detecció comportamental identifiquen els patrons habituals de hooking, que és la tècnica clàssica per interceptar crides al sistema.

L'evasió EDR està passant de la simple evitació —com l'ús de syscalls directes per saltar els hooks de libc— a l'atac directe contra l'estat de monitoratge de l'EDR, rewriting la seva pròpia visibilitat des de dins.

Aquest enfocament, descrit detalladament a matheuzsecurity.github.io, demostra que els sensors basats en eBPF, si no tenen implementat un control estrict de security_bpf_map, són vulnerables a l'envenenament de mapes. Això significa que l'atacant no només es torna invisible, sinó que pot manipular què veu veure l'administrador de seguretat.

El risc dels mòduls no signats i el taint kernel

Des de la versió 8.14, Elastic Defend ha integrat la detecció de càrrega de mòduls via BPF. Amb la versió 9.5, s'ha afegit el camp taint_flags, dissenyat específicament per detectar mòduls que contaminen el kernel per no estar signats o per haver estat construïts externament. Singularity ataca precisament aquest mecanisme.

Quan el rootkit aconsegueix que el programa BPF surti prematurament, la telemetria necessària per avaluar si el mòdul ha contaminat el kernel mai arriba a la regla de detecció EQL. El resultat és un sistema que reporta estar saludable mentre un objecte malicios a nivell de kernel té control total sobre la màquina, incloent la capacitat d'establir shell inverses via ICMP per evitar la detecció de trànsit de xarxa convencional.

Anàlisi de la superfície d'atac

L'estudi de gbhackers.com subratlla que el problema no és una falla de codi puntual, sinó una vulnerabilitat en el model de confiança. Moltes solucions de seguretat assumeixen que certs processos del sistema són inherentment segurs. Singularity demostra que qualsevol procés amb prou privilegis pot ser utilitzat per manipular els mapes de memòria on l'EDR guarda la seva llista de confiança.

Aquesta tècnica de bypass és especialment perillosa perquè no depèn de vulnerabilitats de dia zero en el kernel, sinó de la lògica operativa de l'agent de seguretat. La combinació de fragmentació de mòduls, XOR encoding i el bypass de telemetria BPF crea un camí d'atac que és gairebé invisible per a les eines de monitoratge tradicionals i modernes per igual.

Impacte en l'ecosistema empresarial de Catalunya i Espanya

Per a les empreses tecnològiques de Barcelona i el mercat espanyol, aquesta notícia té implicacions directes en la gestió de la infraestructura crítica i el compliment normatiu. Catalunya s'ha consolidat com un hub de centres de dades i startups d'IA que depenen massivament de clústers de Linux i orquestradors de contenidors. La dependència d'EDRs per garantir la seguretat de aquests entorns pot generar una falsa sensació de protecció si no s'apliquen polítiques de Hardening estrictes.

En el context de l'AI Act de la Unió Europea, les empreses que desenvolupen sistemes d'IA d'alt risc hauran de demostrar que les seves infraestructures són robustes davant ciberatacs. Un rootkit que pot cegar la telemetria del sistema pot comprometre la integritat dels models d'IA i les dades d'entrenament, fent que els auditors no puguin confiar en els logs de seguretat generats per l'EDR. L'ecosistema d'empresa català, molt orientat a la digitalització industrial, ha de transitar cap a un model de Zero Trust no només a nivell de xarxa, sinó també a nivell de kernel, limitant estrictament la càrrega de mòduls no signats i monitoritzant l'accés als mapes BPF.

Preguntes freqüents

Què és exactament el rootkit Singularity?

És un rootkit per a Linux dissenyat per evadir les solucions de seguretat Elastic Defend, utilitzant tècniques d'ofuscació i manipulació de la telemetria eBPF.

Com aconsegueix Singularity que Elastic Defend no detecti la càrrega de mòduls?

Manipula els mapes de processos confiables de l'eBPF d'Elastic. Si el procés que carrega el mòdul apareix com a confiable, l'EDR deixa de recollir telemetria i no genera alertes.

Les regles YARA són inútils contra aquest atac?

No són inútils, però Singularity les evita fragmentant el mòdul, encodificant-lo amb XOR i carregant-lo directament a la memòria sense escriure fitxers reconegibles al disc.

Quina és la recomanació per a les empreses que utilitzen Elastic Security?

Es recomana revisar les polítiques de càrrega de mòduls del kernel, implementar la signatura obligatòria de mòduls i monitoritzar qualsevol canvi sospitós en els mapes BPF del sistema.


Fonts: Gbhackers, Matheuzsecurity (2) ·

glacom · Intel·ligència artificial per a empreses: els models corren als teus servidors, les dades no surten →
Hai una domanda su questo dossier?

Scrivila qui: Susanna, l assistente AI di glacom, ti risponde via email con un approfondimento gratuito.

Nessuna consulenza personalizzata (finanziaria, legale o medica): solo informazione e fonti. Email usata solo per rispondere.

oppure scrivile su: WhatsApp · Telegram · SimpleX · Delta Chat · Email

Condividi su Facebook Condividi su Twitter Condividi su Pinterest Condividi su Telegram Condividi su WhatsApp
Printable version
CLOSE X
Comparteix aquesta notícia
See also
Quishing i codis QR amb HTML: la nova amenaça per a les empreses
Descobreix com el quishing evoluciona amb codis QR basats en taules HTML per saltar els filtres de seguretat i comprometre les credencials corporative…
18/09/2026 12:44
Tencent Hy4: la compressió extrema que democratitza la IA de frontera
Tencent llança Hy4, un model de 770 milions de paràmetres. Amb la tècnica Sherry, el model es redueix de 1,5TB a 214GB per funcionar en hardware local…
18/09/2026 11:18
F/ai: el pacte dels gegants de la IA per impulsar startups a Europa
OpenAI, Google, Meta i Microsoft s'uneixen a l'acceleradora F/ai a París per fomentar startups europees, mentre Meta ajusta el seu model Avocado.
18/09/2026 07:54
La Fiscalia General del Estado implementa IA per a seguretat vial
La Fiscalia General del Estado adopta una eina d'IA per automatitzar escrits de seguretat vial. Un pas clau cap a la digitalització de la justícia a E…
18/09/2026 05:55
La Comissió Europea prohibirà xarxes socials als menors de 13 anys
La Comissió Europea proposa el EU KIDS Act per limitar l'accés a xarxes socials fins als 15 anys i obligar les plataformes a ser segures per disseny.
18/09/2026 05:55