Tema 4
Para analizar malware o comprender una explotación necesitamos saber cómo el sistema operativo organiza ejecución, memoria, permisos, archivos, servicios y eventos. El comportamiento malicioso se vuelve visible cuando entendemos qué partes del sistema está usando o alterando.
El malware no actúa en el vacío. Para ejecutarse necesita procesos, memoria, archivos, permisos, APIs, servicios, tareas y comunicación con el sistema operativo. Una vulnerabilidad tampoco existe aislada: depende de cómo una aplicación procesa datos, asigna memoria, valida permisos o interactúa con el entorno.
Por eso, antes de avanzar hacia análisis estático, dinámico o ingeniería inversa, necesitamos una base clara de sistemas operativos. No buscamos convertirnos en desarrolladores del kernel, sino entender los elementos que aparecerán constantemente en evidencias, herramientas y reportes.
Este tema se centra especialmente en conceptos comunes a Windows y Linux, con más detalle en Windows cuando hablamos de registro y persistencia, porque muchas familias de malware de usuario final apuntan a ese ecosistema.
El sistema operativo administra recursos y ofrece una interfaz para que los programas interactúen con hardware, archivos, memoria, red y usuarios. Para el analista, funciona como el escenario donde se observan acciones maliciosas.
Entre sus responsabilidades principales están:
Un proceso es una instancia de un programa en ejecución. Tiene un identificador, memoria asignada, handles, módulos cargados, variables de entorno, permisos y uno o más hilos. Un hilo es la unidad de ejecución que el sistema planifica sobre la CPU.
En análisis de malware, los procesos son una de las primeras fuentes de evidencia. Una muestra puede crear procesos hijos, inyectar código en procesos legítimos, finalizar herramientas defensivas o ejecutarse con nombres diseñados para confundirse con procesos del sistema.
| Elemento | Qué representa | Qué puede revelar |
|---|---|---|
| PID | Identificador del proceso | Relaciones entre eventos y actividad observada |
| PPID | Proceso padre | Cadena de ejecución y origen de actividad |
| Ruta del ejecutable | Ubicación del archivo en disco | Uso de carpetas temporales, perfiles de usuario o rutas sospechosas |
| Línea de comandos | Parámetros usados al iniciar | Descargas, scripts, comandos ocultos o abuso de herramientas legítimas |
| Usuario | Cuenta bajo la que corre | Privilegios, escalada o ejecución no esperada |
Un proceso nace, carga recursos, ejecuta instrucciones, interactúa con el sistema y termina. Cada etapa puede dejar evidencias o abrir oportunidades de análisis.
Muchas técnicas maliciosas intentan manipular este ciclo: ejecutar desde rutas temporales, cargar bibliotecas no esperadas, crear procesos suspendidos, inyectar código o reemplazar la imagen de un proceso legítimo.
Los sistemas modernos separan el espacio de usuario del espacio kernel. Las aplicaciones normales se ejecutan con restricciones, mientras que el kernel gestiona recursos críticos con privilegios altos.
Esta separación reduce el impacto de errores y ataques, pero no elimina el riesgo. Un exploit de usuario puede lograr ejecución dentro de un proceso limitado; un exploit de kernel puede escalar privilegios o evadir controles con mucho más impacto.
| Espacio | Qué ejecuta | Riesgo principal |
|---|---|---|
| Usuario | Aplicaciones, navegadores, scripts, herramientas | Robo de datos del usuario, ejecución limitada, persistencia local |
| Kernel | Núcleo del sistema, drivers, llamadas privilegiadas | Escalada de privilegios, rootkits, evasión profunda |
| Servicios privilegiados | Procesos del sistema con permisos elevados | Abuso de permisos, movimiento lateral o control del host |
Cada proceso tiene un espacio de memoria donde se cargan código, datos, bibliotecas, pila, heap y estructuras internas. Entender estas regiones ayuda a interpretar debugging, explotación de memoria e inyección de código.
En explotación, errores en stack o heap pueden alterar flujo de ejecución. En malware, la memoria puede contener configuración descifrada, payloads desempaquetados, claves o código inyectado.
Las regiones de memoria tienen permisos. Una página puede ser legible, escribible, ejecutable o una combinación. Las mitigaciones modernas intentan evitar que datos escritos por un atacante se ejecuten como código o que las direcciones útiles sean predecibles.
| Mitigación | Idea principal | Qué dificulta |
|---|---|---|
| DEP / NX | No ejecutar páginas marcadas como datos | Payloads colocados directamente en stack o heap |
| ASLR | Aleatorizar direcciones de memoria | Reutilizar direcciones fijas para controlar ejecución |
| Canaries | Detectar corrupción de stack antes de retornar | Buffer overflows simples contra direcciones de retorno |
| Control Flow Guard | Validar destinos de llamadas indirectas | Desvíos de flujo hacia ubicaciones inesperadas |
Estas defensas no hacen imposible la explotación, pero elevan el costo técnico y obligan a comprender mejor el entorno.
El sistema de archivos organiza datos persistentes. Para el malware, el disco puede servir para instalar componentes, guardar configuración, almacenar información robada, crear persistencia o dejar señuelos. Para el analista, los cambios en disco son evidencia central.
Rutas que suelen aparecer en análisis:
Los archivos tienen metadatos: tamaño, propietario, permisos, tiempos de creación, modificación y acceso, atributos y en algunos casos firmas digitales. Estos datos ayudan a reconstruir actividad.
Un analista debe tener cuidado: los tiempos pueden ser alterados, heredados de una copia, modificados por herramientas o afectados por zonas horarias. Aun así, al correlacionarlos con procesos, logs y capturas, aportan contexto valioso.
Los permisos determinan qué puede hacer un proceso según el usuario o cuenta bajo la que se ejecuta. Una muestra con permisos limitados tiene menos alcance que una ejecutada como administrador o sistema, aunque aún puede robar datos del usuario o persistir en su perfil.
Conceptos clave:
Muchas técnicas de explotación buscan pasar de un permiso bajo a uno alto. Muchas técnicas defensivas intentan que ese salto sea innecesario, detectable o imposible.
El registro de Windows es una base de configuración jerárquica usada por el sistema, aplicaciones y usuarios. Para el malware es atractivo porque permite guardar configuración, registrar ejecución automática, modificar políticas o alterar asociaciones.
| Área | Uso normal | Abuso frecuente |
|---|---|---|
| HKCU | Configuración del usuario actual | Persistencia sin privilegios administrativos |
| HKLM | Configuración global del sistema | Persistencia o cambios que afectan a todos los usuarios |
| Run / RunOnce | Inicio automático de programas | Ejecución persistente al iniciar sesión |
| Services | Configuración de servicios | Instalación de componentes residentes |
| Policies | Restricciones y políticas del sistema | Deshabilitar herramientas o modificar controles |
Los servicios permiten ejecutar procesos en segundo plano, muchas veces antes de que un usuario inicie sesión. Las tareas programadas permiten ejecutar acciones según horario, evento o condición. Ambos mecanismos son legítimos y muy usados por administradores, pero también por malware.
Indicadores de interés:
Las aplicaciones no manipulan recursos críticos directamente. Solicitan servicios mediante APIs y llamadas al sistema. Por eso, observar qué APIs usa una muestra ayuda a inferir comportamiento.
Ejemplos de familias de llamadas relevantes:
En análisis estático, los imports sugieren capacidades. En análisis dinámico, las llamadas observadas muestran qué capacidades se usaron realmente.
Los logs permiten reconstruir acciones que no siempre se ven en tiempo real. Pueden registrar inicios de sesión, creación de servicios, errores, bloqueos, conexiones, ejecución de scripts o cambios de política.
| Fuente | Qué puede mostrar | Uso en análisis |
|---|---|---|
| Eventos de seguridad | Logons, privilegios, auditoría, cambios de cuenta | Reconstruir acceso y uso de credenciales |
| Eventos de sistema | Servicios, drivers, errores y reinicios | Detectar instalación o fallas inducidas |
| Logs de aplicaciones | Errores y actividad específica de programas | Relacionar explotación con comportamiento de una app |
| Sysmon u otras fuentes extendidas | Procesos, red, archivos, hashes y comandos | Crear una línea de tiempo más completa |
Los programas cargan bibliotecas para reutilizar funciones. En Windows suelen ser DLL; en Linux, bibliotecas compartidas. El orden y la ubicación de carga son relevantes tanto para análisis como para explotación.
Una muestra puede cargar módulos legítimos, abusar de bibliotecas vulnerables o colocar una biblioteca maliciosa donde una aplicación la buscará primero. También puede resolver funciones dinámicamente para ocultar imports en análisis estático.
Las variables de entorno, archivos de configuración y parámetros de línea de comandos pueden modificar el comportamiento de un programa. El malware puede usarlos para localizar rutas, guardar estado, activar funciones o adaptarse al usuario actual.
En explotación, una configuración débil puede ser la causa del problema: rutas escribibles, permisos amplios, claves expuestas, secretos en variables de entorno o archivos con credenciales.
Por eso, durante el análisis conviene registrar tanto el binario como su contexto de ejecución. El mismo archivo puede comportarse distinto según usuario, permisos, red, idioma, dominio, hora o configuración presente.
Cuando una muestra se ejecuta, su comportamiento queda expresado en acciones del sistema operativo. El analista traduce esas acciones en hipótesis y conclusiones.
Una explotación exitosa suele manifestarse como un cambio observable: un crash, una excepción, una escritura fuera de límites, una ejecución inesperada, una lectura indebida o un cambio de privilegios. Para interpretar ese cambio se necesita entender cómo el sistema maneja memoria, procesos y permisos.
Ejemplos:
Comprender los fundamentos del sistema operativo permite transformar observaciones dispersas en una explicación coherente. Cada archivo creado, proceso iniciado, clave modificada o región de memoria alterada puede ser una pieza de la cadena de comportamiento.
En el próximo tema estudiaremos arquitectura x86/x64, ensamblador básico y modelo de ejecución, una base necesaria para debugging, ingeniería inversa y explotación de memoria.