Muchísimas gracias de corazón a los colaboradores del blog, esta aventura habría sido muy diferente sin la ayuda de cada uno de vosotros. Tampoco queremos olvidar a cada uno de los lectores que han decidido usar su preciado tiempo en leernos post tras post. Gracias a todos, hemos logrado ser nombrados «9 Mejor Blog de Seguridad Informática de habla hispana» (Bitacoras XII), algo impensable en nuestros inicios allá por el 2014.

Ha sido un grandisimo placer.

The post sudo systemctl hibernate appeared first on S3lab.

Incluye funcionalidades como:

• Framework para descansar (con plugin de sol y playa 2.0).
• Chat para hablar con familiares y amigos.

The post apt-get install summer appeared first on S3lab.

Este blog comenzó sus andanzas el 31 de Marzo de 2014. Cuatro magníficos años que han pasado mas rápido de lo que Sonic tarda en acabar una maratón.

Hace un tiempo publicaron un articulo en Science que intentaba explicar porque el tiempo pasa volando cuando nos estamos divirtiendo. Sin enrollarnos mucho en el tema, todo indica a la clave para esto es la dopamina.

Esperamos que vosotros hayáis tenido tanta dopamina al leernos como nosotros al escribir.

The post document.write(‘blog 1461 days’) appeared first on S3lab.

Cuando tengais mas capas de ropa que un cebolla (no estoy hablando de Tor), recordar que los servidores podran tener la puerta del rack abierta de par en par.

Esperamos que disfrutéis de estas fechas tanto como vuestros servidores del frio.

The post Turning off server room coolers appeared first on S3lab.

Como estos magnificos momentos suelen venir de la mano de cortes de electricidad y agua, hemos decidido que aprovechando estas fechas, igual no nos vendrian mal unas pequeñas vacaciones (hasta septiembre).

Esperemos que estos meses veraniegos no sean tan desastrosos a nivel de brechas de seguridad y permitan que los sysadmins tambien puedan descansar con familia y amigos.

The post Under «Summer» Construction appeared first on S3lab.

Las sandbox ejecutan cada muestra en un entorno controlado para observar su comportamiento malicioso, pero normalmente estos sistemas carecen de información acerca de cómo está empaquetada la muestra. Si recordamos entradas previas de este blog, los autores de malware generalmente empaquetan sus programas para evitar su detección y dificultar la ingeniería inversa. A grandes rasgos, un programa empaquetado contiene una rutina encargada de descomprimir o descifrar una sección de código protegida, que más tarde será ejecutada. A menudo, los autores de malware utilizan varias capas de empaquetado, fuertes métodos de ofuscación de código para cada una de las capas, así como métodos para evadir herramientas como sandbox, debuggers, frameworks de instrumentación, etc.

En muchas ocasiones, el analista de malware necesita analizar en profundidad de forma estática la totalidad del código de la muestra. Si la muestra está empaquetada, es necesario desempaquetarla para obtener un volcado del código original. Para ello, existen diversas alternativas. Por un lado existen unpackers específicos, que son capaces de lidiar con un número limitado de packers conocidos. Por otro lado, existen algunas herramientas de desempaquetado generico basadas en heurísticas. Desafortunadamente, estas heurísticas en ocasiones no presentan una gran efectividad. Como último recurso, el analista debe desempaquetar manualmente la muestra, lo que requiere analizar el empaquetador y averiguar cómo protege el código original.

Si bien existen multitud de sandboxes que permiten analizar malware para extraer indicadores de su comportamiento, no hay apenas herramientas que permitan entender el funcionamiento de un packer. PackerInspector pretende llenar este hueco, de tal modo que se especializa en este tipo de análisis y ofrece un informe detallado sobre diferentes características del packer, obtenidas de forma estática y dinámica. Estas caracteristicas (número de capas, interacción entre las mismas, número de procesos e interacción entre ellos, estructura de las diferentes capas…), nos permiten categorizar la estructura del packer en 6 niveles de complejidad estructural. Por ejemplo, UPX, uno de los packers más sencillos tiene una complejidad de tipo 1 (Type-I), mientras que Armadillo con la protección CopyMem activada, presenta una estructura de complejidad 6 (Type-VI).

El grafo que mostramos corresponde a un packer con un único proceso (P0), y 4 layers (0 a 3). Cada layer contiene una serie de regiones (áreas de memoria escritas y ejecutadas). Por ejemplo, si una determinada región Ra es escrita por otra región situada en la layer 1 (Rb), y Ra es después ejecutada, entonces Ra formará parte de la layer 2. Cada región contiene una primera línea que nos indica el tipo de memoria (M (módulo), S (stack), H (heap)) y su comienzo mientras que la segunda línea indica su tamaño. La tercera línea muestra 3 valores separados por “#”, que indican: el número total de llamadas a la API realizadas desde la región, el número de funciones de la API diferentes utilizadas, así como la presencia de llamadas a ciertas funciones relacionadas con el código bootstrap insertado por compiladores. Finalmente, la última línea muestra el número de frames (cuando una región ha sido escrita y ejecutada en varios turnos). Además, los colores diferencian las regiones, siendo la región roja la última en ejecutarse en nuestra sandbox.

Estamos ante un packer que descifra una primera capa, y tras ello pasa a ejecutarla (la región situada en 0x401000). A continuación, la rutina situada en la región 0x4079b1 (layer 1), descifra una segunda capa y la ejecuta, que a su vez descifra el código original (layer 3), y lo ejecuta. Los conectores grises nos indican que solamente ha habido una transición del flujo de ejecución entre cada par de capas, mientras que los conectores verdes y rojos nos indican el número de bytes escritos por cada región a regiones en la siguiente capa (de color verde, excepto cuando existe una transición de ejecución además de la escritura, en cuyo caso se muestra en rojo). Finalmente, vemos que la región roja de la última capa contiene un número muy superior de llamadas a la API, además de llamadas a la API relacionadas con el código inicial insertado por el compilador. Todo ello nos indica que el binario original se encuentra en esta capa.

Si quieres aprender más sobre cómo funciona PackerInspector, puedes visitar la página de referencia. En nuestro estudio original, medimos la evolución de la complejidad del empaquetado de muestras enviadas a la sandbox Anubis a lo largo de varios años. Hoy, al publicar este servicio, damos continuidad a este estudio recogiendo estadísticas globales de la complejidad de las muestras que compartáis con nosotros.

PackerInspector permite el envío de muestras de forma pública y privada. Para poder hacer uso del envío privado, deberás iniciar sesión con una cuenta de Google (OpenID). Con este registro, no almacenamos información más allá de un identificador único por cuenta y aplicación. Para las muestras enviadas de forma pública,  el resultado del análisis será accesible por cualquiera en posesión de la url correspondiente. Sin embargo, si envías la muestra de forma privada, solamente tú podrás acceder al informe generado. Además, si estás registrado, podrás realizar un seguimiento de las muestras enviadas para su análisis, así como localizar informes de muestras enviadas anteriormente y utilizar la API pública para automatizar el envío de muestras y recopilación de resultados.

Happy reversing!

The post PackerInspector: Nuestra sandbox para packers appeared first on S3lab.