Singularity, un sofisticado rootkit para el kernel de Linux diseñado para versiones del kernel 6.x, ha captado la atención significativa de la comunidad de ciberseguridad por sus avanzados mecanismos de sigilo y poderosas capacidades. Este módulo del kernel representa una preocupante evolución en la tecnología de rootkits, ofreciendo múltiples vectores de ataque y técnicas de evasión exhaustivas que desafían a los sistemas de detección actuales.

Fortinet ha revelado que actores de amenazas han encontrado una manera de mantener el acceso de solo lectura a dispositivos FortiGate vulnerables, incluso después de que se parcheara el vector de acceso inicial utilizado para vulnerarlos.

Investigadores de seguridad de Kaspersky han analizado un rootkit de firmware UEFI que parece apuntar a modelos específicos de placas base de Gigabyte y Asus. Apodado CosmicStrand y probablemente desarrollado por un actor de amenazas desconocido, de habla china, el rootkit se encontró ubicado en las imágenes de firmware de las placas base Gigabyte y Asus que usan el chipset H81, esto se refiere al hardware antiguo entre 2013 y 2015 que en su mayoría está descontinuado en la actualidad.

Investigadores de ESET descubren FontOnLake, una familia de malware que utiliza herramientas personalizadas y bien diseñadas para atacar sistemas operativos que funcionan bajo Linux. La naturaleza  de las herramientas de FontOnLake en combinación con su diseño avanzado y baja prevalencia sugieren que ha sido diseñado para ataques dirigidos

Lenovo no ha aprendido nada. En febrero de este año, la compañía fue el centro de una tormenta por Superfish, un adware preinstalado de fábrica en sus equipos que podía ser utilizado por terceros para robar información. Pues bien, lo han vuelto a hacer, y esta vez desde la BIOS y modificando hasta el arranque de Windows. El caso es doblemente grave porque, para colar ese Bloatware, Lenovo ha empleado técnicas de Rootkit.  

Bueno, pues después de daros la plasta con la parte “teórica”, vamos a ver algo más práctico, para empezar analizaremos el modus-operandi de un rootkit que trabaja en espacio de usuario. Ya se
explicó someramente como trabajan estos, y para ejemplificarlo que mejor que ponernos manos a laobra a despiezar un rootkit de este tipo, en este caso “shv6”.

Para ello nos vamos a servir de una VM con un Ubuntu Server instalado, con el únic oañadido de que contará con tripwire, programa que sirve para comprobar la integridad de los archivos instalados en nuestro sistema y que nos ayudará a ver mejor los cambios que se llevan acabo en el sistema por este tipo de rootkits.

• KernelSpace Rootkits

• UserSpace Rootkits

Con este primer post, vamos a introducir una serie de artículos en los que trataremos en profundidad los rootkits, desde un repaso histórico, pasando pos los fundamentos, los distintos tipos, hasta un análisis profundo de una serie de rootkits.

Los posts corren a cargo de Hendrix y de un servidor, esperemos que sean de vuestro agrado, y sin más dilación...

Muchos usuarios habrán oído hablar de los rootkits... Tienen ya una dilatada historia, aunque en sus orígenes provienen del entorno de los Sistemas Operativos Unix y sus derivados.

Originalmente los rootkits fueron diseñados para realizar funciones en beneficio del usuario, aunque posteriormente, y de ahí su actual “popularidad”, pasaron a ser usados por los hackers para diversos propósitos.

Alrededor del 2004 empezaron a aparecer los primeros ejemplares para los Sistemas Operativos Windows, creciendo exponencialmente el número de estos. Fue en este momento cuando el término “rootkit” saltó a la palestra y empezaron a refinarse enormemente hasta llegar a los ejemplares que tenemos hoy en día.

En este artículo vamos a tratar de definir un poco más técnicamente que es un rootkit, como actúa, y porque puede ser tan potencialmente peligroso.

En el presente artículo se va a tratar la detección de API Hooking en procesos mediante un módulo de Kernel. Un breve índice sobre los puntos que voy a tratar:

1. Diferencia entre manejo de direcciones en modo Kernel y modo Usuario
2. Trabajando sobre el proceso en modo Kernel
3. Leyendo memoria y código final

Diferencia entre manejo de direcciones en modo Kernel y modo Usuario:
-->
Como ya saben, no es lo mismo trabajar con memorias en un módulo de Kernel que en un proceso corriendo en modo usuario. La principal diferencia es que un módulo Kernel trabaja con direcciones físicas y los procesos con memoria virtual. Vamos a ver mas detalladamente que es cada cosa.