Ya llega BlueKeep... aka ejecución remota de código en RDP

El pasado martes 14 de mayo Microsoft lanzaba un parche para la vulnerabilidad CVE-2019-0708 bautizada también como BlueKeep, una vulnerabilidad en Remote Desktop Services de Windows que permite ejecución remota de código sin pre-autenticación, mandando simplemente paquetes especialmente modificados.

Tal y como reza Microsoft en su boletín, Windows 7, Windows Server 2008 R2 y Windows Server 2008 son vulnerables, así como los Windows 2003 y Windows XP, estos últimos y como ya sabemos ya fuera de soporte.

Evidentemente la criticidad de la vulnerabilidad causó un gran revuelo porque además abre la posibilidad de nuevo de armar malware "wormable" o autopropagable del tipo WannaCry. El resultado ha sido una avalancha de búsquedas de un exploit funcional que todavía hoy no ha cesado. Pero antes de avanzar cualquier PoC entendamos un poco en qué consiste la vulnerabilidad...

Análisis técnico CVE-2019-0708

Nos enfrentamos a una vulnerabilidad del tipo use-after-free en termdd.sys, un driver de kernel que usa el RDP (Remote Desktop Protocol) de Microsoft. Para entenderlo un poco mejor vamos a ilustrar el inicio de una comunicación RDP gracias a un buen esquema que encontré en el blog de Ixia:

Primero, tenemos una conexión X.224 iniciada por el cliente que se utiliza para realizar una solicitud de conexión al servidor, seguido de una confirmación de esta conexión.

Las siguientes peticiones "MCS Connect Initial y GCC Create", dentro del intercambio de mensajes para la Configuración Básica, contienen información de creación de canales virtuales, información relacionada con la seguridad y otros parámetros de capacidad y compatibilidad del cliente RDP. Dentro hay un campo de 8 bytes terminado en un byte nulo llamado "channelName_N" que se usa para especificar el nombre del canal.

Llegan nuevos 0-days de Windows... ¡SandboxEscaper ha vuelto!

Así es ella, repentina como el primer rayo de una tormenta, sin campañas ni anuncios rimbombantes, sólo necesita un repositorio en Github para desatar de nuevo toda su ira. Hablamos de SandboxEscaper, la enigmática investigadora que el año pasado sorprendió con la publicación de varios 0-days de escalado local de privilegios (en adelante LPE) y que hace unas horas publicó el código del primero de una serie de cinco exploits que irán desvelándose en breve: cuatro para LPEs y uno para escapar del Sandbox de IE.

Evil is coming!:
https://github.com/SandboxEscaper/polarbearrepo/

El primer 0-day (Bearpe) publicado y el que vamos a ver en este post es una vulnerabilidad que se aprovecha de las funciones de asignación de permisos a la hora de importar las tareas programadas (.job) antiguas, y permite a un usuario regular ejecutar cualquier cosa como SYSTEM. 

Descripción

Los componentes de front-end de Task Scheduler, como schtasks.exe, son interfaces que permiten a los usuarios ver, crear y modificar tareas programadas. La parte de back-end de Task Scheduler es un servicio de Windows que se ejecuta con privilegios de SYSTEM. Una de las librerías utilizadas por el servicio del Programador de tareas, schedsvc.dll, tiene una función llamada tsched::SetJobFileSecurityByName(), que establece los permisos de los archivos jobs. Los permisos de los archivos jobs en el directorio %Windir%\system32\tasks se modifican para otorgar al usuario llamante permisos completos al archivo de jobs que han creado.

En el punto donde se llama a la función SetSecurityInfo(), el servicio del Programador de tareas tiene el token de seguridad NT Authority\SYSTEM. Esto significa que el servicio del Programador de tareas puede otorgar permisos de acceso de usuario total a los archivos que solo pueden ser controlados por SYSTEM u otras cuentas privilegiadas.

El código de de la PoC de SandboxEscaper usa los binarios schtasks.exe y schedsvc.dll de Windows XP para aprovechar estos niveles de privilegios al configurar los permisos de archivos. Las versiones de Windows anteriores a Vista usaban archivos jobs en el directorio %Windir%\tasks. Las versiones heredadas de schtasks.exe harán que estos trabajos se migren al directorio %Windir%\system32\tasks cuando esas versiones de los programas se ejecuten en plataformas modernas de Windows. Junto con el token de seguridad de SYSTEM usado por el servicio del Programador de tareas, se puede aprovechar este comportamiento de migración junto con los hard links para otorgar permisos completos de archivos protegidos a cualquier usuario en un sistema Windows.

Resumiendo, el código del exploit simplificado realiza por tanto lo siguiente:

CopyFile(L"bear.job", L"c:\\windows\\tasks\\bear.job",FALSE);
    system(command.c_str());
    DeleteFile(L"c:\\windows\\system32\\tasks\\Bear");
    CreateNativeHardlink(L"c:\\windows\\system32\\tasks\\bear", L"C:\\Windows\\system32\\drivers\\pci.sys");
    system(command.c_str());

Y paso a paso:

1.- Primero se copia la tarea (el fichero bear.job) en la carpeta de tareas antigua.
2.- Luego se ejecuta "schtasks /change /TN "bear" /RU username /RP password", esto dará como resultado una llamada al siguiente RPC "_SchRpcRegisterTask", que está expuesto por el servicio del programador de tareas.
3.- Después de eso se borra el archivo que se creó y se pone un hard link y se vuelve a ejecutar el mismo comando. De esa manera se llamará a  SetSecurityInfo en el enlace físico.

PoC

1. copiar polarbear.exe, bear.job, schtasks.exe, schtasks.dll de la carpeta "poc files" a una máquina virtual de prueba
2. ejecutar polarbear.exe pasando un nombre de usuario y contraseña de una cuenta local que no sea de administración. Ej. "polarbear.exe essbee polarbear"

Impacto

Se ha confirmado que el código publicado funciona en Windows 10 de 32 y 64 bits, así como en Windows Server 2016 y Windows Server 2019.

Obviamente para explotar la vulnerabilidad se necesita usuario y contraseña pero, una vez obtenido (guest por ej.) y al aprovechar el servicio del Programador de tareas de Windows, un atacante autenticado puede obtener acceso total a los archivos protegidos. Esto puede permitir un compromiso completo del sistema desde una cuenta de usuario de Windows limitada.

Por el momento no se han lanzado parches... y hace unas horas ya se han publicado dos nuevos exploits y quedan otros dos...

NAXSI: un WAF para NGINX

NAXSI es un WAF de código abierto, de alto rendimiento y de bajo mantenimiento para NGINX. El acrónimo significa Nginx Anti XSS y SQL Injection.

Técnicamente, es un módulo de Nginx disponible como paquete para muchas plataformas tipo UNIX. De manera predeterminada, lee un pequeño subconjunto de reglas sencillas (y legibles) que contienen el 99% de los patrones conocidos involucrados en las vulnerabilidades web. Por ejemplo, <, | o drop se supone que no son parte de una URI.

Siendo muy simples, esos patrones podrían coincidir con consultas legítimas, es deber del administrador de Naxsi agregar reglas específicas que incluyan en lista blanca los comportamientos legítimos. El administrador puede agregar listas blancas manualmente analizando el registro de errores de Nginx, o (recomendado) iniciar el proyecto con una fase de aprendizaje automático intensivo que generará automáticamente reglas de listas blancas con respecto al comportamiento de un sitio web.

En resumen, Naxsi se comporta como un firewall que dropeará todo por defecto, la única tarea es agregar las reglas de ACEPTAR requeridas para que el sitio web de destino funcione correctamente.

¿Por qué es diferente?

Contrariamente a la mayoría de los firewalls de aplicaciones web, Naxsi no se basa en una base de firmas como un antivirus, y por lo tanto no puede ser evitado por un patrón de ataque "desconocido".

¿En qué se ejecuta?

Naxsi debería ser compatible con cualquier versión Nginx. Depende de libpcre para su compatibilidad con expresiones regulares, y funciona muy bien en NetBSD, FreeBSD, OpenBSD, Debian, Ubuntu y CentOS.

Más info:

- Documentación
- Algunas reglas para el software principal
- Nxapi/nxtool para generar reglas.

Proyecto: https://github.com/nbs-system/naxsi

The hacker's hardware toolkit: un catálogo con más de 100 gadgets para hackers

El gran Yago Hansen (@yadox) ha decidido compartir "The hacker's hardware toolkit" que fue presentado en #HITBAMS2019 y #HITBHaxpo. Se trata de un catálogo con una gran colección de dispositivos de hardware para hackers, pentesters y red teamers.

Incluye más de 120 gadgets clasificados en ocho categorías diferentes, para que sea más fácil buscarlos:

1. Mini Computers: La mejor selección de mini PCs, mini placas base, etc. Las mejores herramientas para manejar todos los demás periféricos de hardware de tus proyectos. 
2. RF: Las mejores herramientas para hackear, analizar, modificar o responder a cualquier señal de radiofrecuencia. Herramientas para hackear controladores inalámbricos, GPS, teléfonos celulares, señales satelitales, etc. 
3. Wi-Fi: El kit de herramientas para un experto en Wi-Fi como Yago. Estas herramientas permiten el sniffing en modo monitor, enumeración, inyección, etc. Algunas herramientas como deautenticadores y amplificadores solo deben usarse en entornos de laboratorio. 
4. RFID / NFC: Bonita colección de herramientas profesionales y para principiantes para investigar sobre las tecnologías RFID y NFC basadas en tarjetas contactless LF (baja frecuencia) y HF (alta frecuencia), etiquetas y tarjetas. Herramientas de hacking para controles de acceso, garajes, tiendas, etc. 
5. HID / Keyloggers: HID (hardware input devices) como los ratones y los teclados USB están abiertos a un ataque de inyección de pulsaciones de teclas (keystrokes). Muchos de estos dispositivos como rubberducky, badusb, badusb ninja, etc. están aumentando sus capacidades y efectividad. Los keyloggers de hardware siguen siendo una de las mejores opciones para la captura de credenciales. 
6. Network: Los routers pequeños, los taps y otros dispositivos de red similares basados en Linux pueden ser el compañero perfecto para un pentesting interno. Aquí encontraremos muchos mini routers basados en OpenWRT / LEDE que se pueden personalizar para pentesting de red. 
7. BUS: Hay muchas tecnologías y protocolos de bus diferentes, y un hacker de hardware debe poseer muchas herramientas para descubrir y "hablar" con dichos buses. Algunas de las categorías incluidas aquí son: hacking de automóviles, hacking de placas base y PCB, industrial, etc. 
8. Accesorios: No son suficientes solo las herramientas anteriores para crear nuestro dispositivo de hacking propio. Si vamos a construir un sistema funcional, también necesitaremos muchos accesorios como baterías, cargadores, gps, sensores, DC-DC, equipos de laboratorio, etc.

El catálogo puede descargarse en formato PDF desde aquí.

Nota del autor: Aclarar que NO es un catálogo comercial, incluso si se ve así. Yago no tiene ningún interés personal en vender ninguna de las herramientas mostradas, sólo compartir muchas de las herramientas que ha usado para diferentes propósitos de hacking. Cualquier herramienta que no esté disponible para ser comprada online, será excluida del catálogo. Todas las herramientas muestran un precio aproximado y una tienda online donde se puede comprar. Todos los códigos OCR incluyen el enlace a una tienda online que se envía a Europa y, por supuesto, no son maliciosos.

Proyecto y términos para contribuciones: https://github.com/yadox666/The-Hackers-Hardware-Toolkit

Zombieload: nuevos bugs que permiten extraer información de procesadores Intel

Varios investigadores de distintas universidades han encontrado una nueva clase de vulnerabilidades en los procesadores de Intel que pueden usarse para robar información confidencial directamente del procesador.

Los errores recuerdan a otros de canal lateral como Meltdown, Spectre o Foreshadow, que explotaron una vulnerabilidad en la ejecución especulativa, una parte importante de cómo funcionan los procesadores modernos. La ejecución especulativa es una técnica de optimización que Intel agregó a sus CPU para mejorar la velocidad de procesamiento de datos y el rendimiento. Digamos que esta técnica ayuda a los procesadores a predecir en cierta medida lo que una aplicación o sistema operativo podría necesitar en un futuro próximo, lo que hace que la aplicación se ejecute más rápido y más eficiente. El procesador ejecutará sus predicciones si son necesarias, o las descartará si no lo son.

El ataque ha sido bautizado como "ZombieLoad" porque toma su nombre de "carga zombie", una cantidad de datos que el procesador no puede entender o procesar adecuadamente, lo que obliga al procesador a pedir ayuda al microcódigo del procesador para evitar un bloqueo. Las aplicaciones generalmente solo pueden ver sus propios datos, pero este error permite que los datos se filtren a través de esos límites. Los investigadores dijeron que ZombieLoad filtrará cualquier dato actualmente cargado por el núcleo del procesador. Intel dijo que los parches al microcódigo ayudarán a borrar los buffers del procesador, evitando que se lean los datos.

En la práctica, los investigadores demostraron en un video que los fallos se podían explotar para ver qué sitios web visitaba una persona en tiempo real, pero se podían reutilizar fácilmente para capturar contraseñas o tokens de acceso que se utilizan para iniciar sesión online de la víctima:

Url del video: https://youtu.be/wQvgyChrk_g

Compila y recorre las instrucciones en ensamblador de un programa con penguinTrace

penguinTrace es una herramienta que nos permitirá escribir código y ver cómo se ejecutan las instrucciones que lo componen. El objetivo es ayudar a las personas a comprender cómo se ejecutan los programas, o mejorar la comprensión del ensamblador.

Al escribir programas en C, es posible hacer que el compilador genere el ensamblado generado o desensamblar un binario para ver las instrucciones. Sin embargo, ver las instrucciones en forma estática no muestra el flujo a través del programa. Usando un depurador, se puede recorrer el programa, pero los depuradores proporcionan una gran cantidad de funciones y, por lo tanto, puede ser complicado mostrar las instrucciones que se están ejecutando.

La intención de penguinTrace es proporcionar una interfaz simple para compilar y recorrer un programa. También está diseñado para admitir diferentes arquitecturas, por ejemplo, ejecutarse en una Raspberry Pi (AArch64), así como en x86_64. Por esta razón, penguinTrace se ejecuta como un servidor web al que se puede conectar desde un navegador. Esto es más liviano que ejecutar un editor/depurador gráfico y significa que puede ejecutarse sin necesidad de un monitor. Tenéis más detalle aquí.

penguinTrace permite ejecutar código arbitrariamente como parte de su diseño. Por defecto, solo escuchará las conexiones desde la máquina local. Solo debe configurarse para escuchar las conexiones remotas en una red de confianza y no estar expuesto a la interfaz. Esto puede mitigarse ejecutando penguinTrace en un contenedor Docker:

docker build -t penguintrace github.com/penguintrace/penguintrace

Una vez que se construye penguinTrace, al estar integrado en un contenedor se puede ejecutar directamente así:

docker run -it -p 127.0.0.1:8080:8080 --tmpfs /tmp:exec --cap-add=SYS_PTRACE --cap-add=SYS_ADMIN --rm --security-opt apparmor=unconfined penguintrace penguintrace

FSP: herramienta que simula procesos de sandboxing para que no infecten nuestro sistema

Normalmente los desarrolladores de malware programan sus artefactos para que no se disparen si detectan que están dentro de una sandbox o una VM, o incluso la presencia de procesos de análisis. ¿Y si aprovecháramos ésto para proteger nuestro sistema? La idea está clara, simular que nuestra máquina es un sistema de análisis de malware para no infectarnos.

Fake Sandbox Processes (FSP) es un pequeño script en Powershell que simulará procesos falsos de análisis, sandbox y software de VM que algunos malware intentarán evitar. Podemos descargar el script original hecho por @x0rz aquí o una versión posterior optimizada de Phoenix1747.

Características del script

- Algunos tipos de spyware (normalmente avanzados) pueden dejar de ejecutarse correctamente siempre que se ejecuten los procesos creados.
- Requisitos: Powershell (preinstalado en Win 7 y posteriores), eso es todo.
- No hay carga del sistema.
- Fácil de usar.

Características del instalador

- Instala automáticamente el script en el directorio de inicio automático, de modo que no tengamos que ejecutarlo cada vez que volvamos a iniciar sesión.
- Requisitos: Sólo PowerShell.
- Viene también con un desinstalador para purgar todos los archivos.
- Todo incluido en un pequeño paquete offline.
- Actualizador opcional incluido.

Uso

Clic derecho en el archivo y elegir "Ejecutar con PowerShell"
~O~
Abrir la consola y pegar este comando (no olvidar poner la ruta correcta):

Powershell -executionpolicy remotesigned -F 'Your\Path\fsp.ps1'

Después de presionar enter, podremos elegir iniciar o detener todos los procesos.

Autoinicio

Para iniciar automáticamente el script, el autor hizo además un instalador: fsp-installer.bat, basta con ejecutarlo:

Proyecto: https://github.com/Phoenix1747/fake-sandbox

Comprometen más de 29 botnets de IoT con credenciales débiles

Un hacker con nick 'Subby' se hizo con más de 29 botnets de IoT en las últimas semanas haciendo fuerza bruta sobre los paneles de backend de sus servidores C2, debido a que éstos usaban credenciales débiles.

"Ahora, esta teoría ha sido llevada a la práctica por un threat actor llamado Subby, que ha hecho fuerza bruta al menos contra 29 IoT C2s y los ha comprometido utilizando credenciales extremadamente triviales", escribió Ankit Anubhav, investigador de seguridad de NewSky Security. "Según lo compartido por el threat actor, se puede ver que las credenciales utilizadas son bastante débiles".

Subby le dijo a Anubhav que algunos de los C2 asociados con las redes de bots de IoT estaban usando credenciales muy comunes, incluyendo "root: root", "admin: admin" y "oof: oof".

En una entrevista con Anybhav, Subby explicó que la mayoría de las redes de bots de IoT que él hackeaba fueron creadas por script kiddies que habían seguido tutoriales online.

"Es obvio por qué esto está sucediendo. Un gran porcentaje de operadores de botnets simplemente siguen tutoriales que se han extendido en la comunidad o están disponibles en YouTube para configurar su botnet. Al seguir estos tutoriales, no cambian las credenciales predeterminadas. Y si cambian las credenciales, la contraseña que suministran es generalmente débil y, por lo tanto, vulnerable a fuerza bruta", dijo Sabby a Anybhav.

Subby explicó que obtuvo el control de un total de más de 40.000 dispositivos en solo una semana, un "poder de fuego" desconcertante que podría ser objeto de abuso por parte de varios threat actors.

"En la primera semana de fuerza bruta, superé los 40.000 dispositivos. Posiblemente fue un número bastante inflado debido a las duplicidades. Está bien documentado que a los operadores de redes de bots les gusta aumentar su contador de bots. Estimo que el número está más cerca de 25.000 dispositivos únicos. Pude obtener un gráfico de tráfico de red fiable producido del tráfico generado de todas las redes de bots combinadas y fue un poco menos de 300 gbit/s", continúa Subby.

Sabby explicó que inicialmente hackeó las botnets de IoT para ver la eficiencia de usar fuerza bruta contra paneles de administración de C2 para hacerse con una red de bots, en lugar de usar exploits.

En definitiva, Sabby demostró que es muy fácil para los actores construir botnets de IoT que podrían usarse para muchas actividades maliciosas.

Fuente: A hacker has taken over at least 29 IoT botnets

QR-game: "hackea" una base de datos mediante códigos QR

Lo prometido es deuda, lo tenía pendiente publicar y aquí os traigo el detalle y código del juego de códigos QR que llevamos a Mundo Hacker Day 2019.

Como os dije en la crónica del congreso, la idea fue de un compi Amine Taouirsa al que le comenté que quería implementar una versión propia y llevarla también al evento. El juego se inicia generando un ticket en un impresora térmica con un código QR al registrar a un usuario en una base de datos SQLite. Luego, el usuario tiene que leerlo con su móvil y ser capaz de generar otros códigos que deben ser leídos por la cámara de una Raspberry Pi para conseguir primero acceso a la base de datos y segundo la contraseña del usuario 'admin'.

Los componentes que forman parte del "QR-Game" son:
- Arduino Uno: con un LCD 16x2, potenciómetro, switch, altavoz y resistencias.
- Raspberry Pi 3: con cámara JZK.
- Impresora térmica USB de 58mm
- Soportes y portátil.

Mi versión se basa en el proyecto "Crystal Ball' del libro de proyectos del Starter Kit de Arduino y su esquema mostrado abajo, añadiendo además un altavoz para reproducir un sonido o melodía al leer un código con la cámara, resetear o completar el juego.

Iniciación al reversing de firmware: extracción del sistema de archivos

No son poco frecuentes las noticias acerca de la aparición de backdoors presentes en miles y miles de dispositivos. Su descubrimiento, muchas veces explotado por atacantes malintencionados, suele ser el resultado de un análisis exhaustivo del firmware correspondiente. Si nunca os habéis enfrentado a este tipo de ejercicio, en el blog de 15/85 Security daban una breve introducción para extraer el sistema de ficheros de un binario, una buena piedra de toque:

1.- Descarga de firmware de prueba, en este caso la versión 1.14.04 de la cámara D-Link modelo DCS-932L:

$ wget ftp://ftp2.dlink.com/PRODUCTS/DCS-932L/REVA/DCS-932L_REVA_FIRMWARE_1.14.04.ZIP

$ unzip DCS-932L_REVA_FIRMWARE_1.14.04.ZIP
Archive:  DCS-932L_REVA_FIRMWARE_1.14.04.ZIP
  inflating: DCS-932L_REVA_RELEASENOTES_1.14.04_EN.PDF 
  inflating: dcs932l_v1.14.04.bin   

2.- Para empezar echamos un vistazo a las strings con 10 o más caracteres imprimibles:

$ strings -10 dcs932l_v1.14.04.bin | more

NetInitTcp
NetTcpSend
NetReceive
send_syn_ack
send_reset
ArpTimeoutCheck
HttpHandler
mpfd_decode
do_httpsvr
rf      - read/write rf register
rf r <reg>        - read rf register
rf w <reg> <data> - write rf register (reg: decimal, data: hex)
Signature: DCS-930            932L  Release 1.11 (2011-05-31)
*** failed ***
relocate_code Pointer at: %08lx
Please choose the operation: 
   %d: Load system code to SDRAM via TFTP. 
   %d: Load system code then write to Flash via TFTP. 
   %d: Boot system code via Flash (default).
   %d: Entr boot command line interface.
   %d: Load Boot Loader code then write to Flash via Serial. 
   %d: Load Boot Loader code then write to Flash via TFTP. 
 Please Input new ones /or Ctrl-C to discard
    Input device IP 
    Input server IP 
0x80200000
0x88001000
0x80100000
    Input Uboot filename 
    Input Linux FileSystem filename 
0x80800000
    Input Linux Kernel filename 
Entering HTTP server.
Entering program & boot linux.
Erase linux block (0x%x ~ 0x%x)
Erase linux block (0x%x ~ 0x%x
### ERROR ### Please RESET the board ###
Warning: Abort rw rf register: too busy
Warning: still busy
Error: rw register failed
rf reg <%d> = 0x%x
*** Error: D+/D- is 1/1, config usb failed.
config usb
Watchdog Reset Occurred
******************************
Software System Reset Occurred
Software CPU Reset Occurred
============================================ 
Ralink UBoot Version: %s
-------------------------------------------- 
(Port5<->None)
DRAM component: %d Mbits %s
DRAM bus: %d bit
...
...

3.- Ahora usamos binwalk, me atravería a decir la herramienta de facto cuando nos enfrentamos a análisis de firmware. Al ejecutarlo directamente nos devolverá varios "hits" del binario:

$ binwalk dcs932l_v1.14.04.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
106352        0x19F70         U-Boot version string, "U-Boot 1.1.3"
106816        0x1A140         CRC32 polynomial table, little endian
124544        0x1E680         HTML document header
124890        0x1E7DA         HTML document footer
124900        0x1E7E4         HTML document header
125092        0x1E8A4         HTML document footer
125260        0x1E94C         HTML document header
125953        0x1EC01         HTML document footer
327680        0x50000         uImage header, header size: 64 bytes, header CRC: 0x88345E96, created: 2016-09-09 13:52:27, image size: 3804958 bytes, Data Address: 0x80000000, Entry Point: 0x803B8000, data CRC: 0x531E94DE, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
327744        0x50040         LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 6558763 bytes

Mirando la primera línea, vemos que binwalk encontró un string U-Boot en 106352, ya sabéis, el cargador de arranque. Y por supuesto, en 327680, podemos ver un encabezado de uImage que nos indica que encontraremos la imagen del kernel del SO en un archivo LZMA que comienza en 327744.