Preguntas de entrevista de Malware Analyst / Reverse Engineer
Static and dynamic analysis, reverse engineering, sandboxing and understanding how malicious code behaves.
Tu antivirus marcó el archivo EICAR — ¿significa eso que estás infectado con un virus?
No. El archivo de prueba EICAR es una cadena ASCII deliberadamente inofensiva de 68 bytes que todos los fabricantes de antivirus acuerdan detectar, para verificar con seguridad la detección y las alertas sin tocar malware real. Una detección significa que tu antivirus funciona — no que estés infectado. No es un virus y no hace nada si se ejecuta. Confundir una detección de prueba EICAR con una infección real es una trampa común al inicio de carrera.
El análisis reveló los dominios C2 del malware y un mutex único. ¿Cuál es el entregable de mayor valor para el SOC?
El SOC necesita actuar, así que entrega contenido de detección estructurado y accionable: IOC de red, hashes, artefactos de host como el mutex, y firmas conductuales o YARA que pueda desplegar para cazar y bloquear. Un relato exhaustivo de llamadas a la API no es directamente operativo. Un solo hash lo cambian los atacantes trivialmente. Una atribución especulativa no sirve al SOC para defenderse. El objetivo: detecciones que el SOC pueda desplegar hoy.
Estás listo para ejecutar una muestra de forma dinámica. ¿Qué entorno es el apropiado?
Detona solo en una VM desechable y aislada, con snapshots y una red controlada (por ejemplo, servicios simulados o egress estrechamente monitorizado), de modo que el malware no pueda alcanzar producción ni internet sin control. El antivirus de tu portátil no contendrá de forma fiable malware activo. Un servidor de producción pone en riesgo sistemas reales. La máquina de un colega solo traslada el peligro. El aislamiento y los snapshots reversibles son el núcleo de un laboratorio de malware seguro.
Una amenaza se ejecuta solo en memoria, sin ningún archivo en disco. ¿Cómo la analizas?
El malware fileless vive en la memoria de los procesos (inyección, carga reflectiva, LOLBins), así que adquiere y analiza una imagen de memoria para hallar el código inyectado, los módulos sospechosos y las relaciones entre procesos. Un escaneo antivirus del disco y un disco limpio no te dicen nada de un implante en memoria. La papelera de reciclaje es irrelevante. El análisis de memoria es la herramienta adecuada cuando no hay archivo que triar, y debes capturar antes de reiniciar el host.
Un host muestra una nota de rescate. Apoyando al IR como analista de malware, ¿cuál es la primera contribución más útil?
La identificación de la familia guía las decisiones: a partir de la nota, la extensión y los IOC puedes señalar si existe un descifrador gratuito, los TTP típicos del grupo (incluido el robo de datos para extorsión) y el radio de impacto probable, alimentando al equipo de IR. Reformatear destruye la evidencia y la información de alcance. La gramática de la nota no es accionable. Recomendar negociar es una decisión de negocio y legal, no el primer paso del analista. Identifica primero, luego habilita al IR.
Durante el análisis dinámico la muestra contacta con un C2 activo y puede recibir comandos. ¿Cuál es el enfoque seguro?
Usa servicios de red simulados o un egress estrechamente monitorizado y no atribuible, para estudiar el comportamiento del C2 sin revelar tu IP real al atacante ni dejar que el host reciba comandos dañinos. Interactuar desde la IP corporativa alerta al operador y arriesga un daño real. Puentear el sandbox a la LAN invita a la propagación. Desactivar los logs tira los datos del análisis. Controla la red para observar sin exponerte ni ser instrumentalizado.
El análisis estático muestra entropía alta y casi ningún import o cadena legible — la muestra parece empaquetada. ¿Qué haces?
El packing oculta el código real, así que entropía alta más imports ausentes es señal de desempaquetar — detecta el packer y vuelca la imagen desempaquetada desde memoria una vez que el loader se ha ejecutado, y luego analiza la carga útil real. Las cadenas ilegibles son prueba de evasión, no de inocuidad. Declararlo falso positivo o renombrar la extensión ignora una muestra activamente ofuscada. La propia ofuscación es un fuerte indicador malicioso que conviene investigar.
Tu muestra no hace nada en el sandbox, pero el SOC la observó activa en un host real. ¿Cuál es la razón probable y tu respuesta?
El malware suele comprobar artefactos de VM/sandbox, tiempos de ejecución cortos o interacción del usuario y permanece inactivo si los detecta. Disfraza y endurece la VM de análisis, alarga la ejecución o pasa a bare metal, y extrae el comportamiento desde una imagen de memoria del host vivo. Suponer que está roto o que el host se equivocó ignora una muestra probadamente maliciosa en el mundo real. Reiniciar no cambia nada porque la lógica de evasión se dispara en cada ejecución.
El SOC te entrega un .exe sospechoso extraído de la máquina de un usuario. ¿Cuál es tu PRIMER paso de análisis?
Empieza con triaje estático en un entorno aislado: calcula hashes, extrae cadenas, inspecciona las cabeceras PE y los imports, y verifica la reputación, para entender la muestra antes de arriesgarte a ejecutarla. Ejecutarla en tu propia estación puede infectarte a ti y a la red. Subir muestras de clientes con nombres identificables filtra datos sensibles a terceros. Borrarla destruye la evidencia y la posibilidad de crear detecciones.
Nombra las formas comunes en que el malware persiste en un host Windows entre reinicios, y cómo las cazarías.
La persistencia es cómo el malware sobrevive a reinicios y cierres de sesión. Los básicos en Windows son las claves Run/RunOnce del registro (HKLM y HKCU), las tareas programadas y los servicios de Windows, además de las carpetas de inicio, las suscripciones a eventos WMI y el secuestro de DLL. Los cazas con autoruns/Sysinternals, Sysmon y los registros de eventos, buscando binarios sin firmar, rutas extrañas como %AppData% y entradas creadas justo tras el compromiso inicial.
Explica la inyección de procesos, da un par de técnicas y di cómo la detecta un equipo azul.
La inyección de procesos ejecuta el código del atacante dentro del espacio de memoria de un proceso legítimo para que la actividad se mezcle y herede la confianza de ese proceso. Las técnicas clásicas incluyen la inyección de DLL (CreateRemoteThread + LoadLibrary), el process hollowing (lanzar un proceso benigno suspendido, desmapearlo, escribir código malicioso) y la inyección APC. Los defensores la detectan con hooks de API del EDR, relaciones padre/hijo o regiones de memoria anómalas (RWX, memoria ejecutable sin respaldo en archivo) y eventos CreateRemoteThread de Sysmon.
Compara el análisis estático y dinámico de malware, incluyendo las fortalezas y límites de cada uno.
El análisis estático examina una muestra sin ejecutarla —hashes, cadenas, imports, encabezados y desensamblado—, así que es seguro y de cobertura completa, pero lo derrotan el empaquetado y la ofuscación. El análisis dinámico detona la muestra en un sandbox aislado y observa el comportamiento real —archivos, registro, procesos, red—, lo que atraviesa la ofuscación pero solo revela lo que se ejecuta en esa sesión y puede ser evadido por malware consciente del sandbox. Los analistas combinan ambos.
Define las categorías comunes de malware y explica cómo clasificas un ejemplar según su comportamiento.
Se clasifica según para qué está construido el ejemplar, observado a partir de su comportamiento y capacidades. Un dropper transporta y escribe una carga útil en disco; un loader recupera o inyecta la siguiente etapa, a menudo solo en memoria; un RAT da a un operador control remoto interactivo; un wiper destruye datos o registros de arranque sin intención de recuperación; el ransomware cifra archivos y exige un pago. Los ejemplares reales suelen combinar roles — un loader que despliega un RAT — así que se describe la cadena de capacidades en lugar de forzar una sola etiqueta, y se asigna cada comportamiento a técnicas ATT&CK.
¿Cuándo recurres a Ghidra o IDA frente a un depurador como x64dbg, y cómo se complementan?
Un desensamblador como Ghidra o IDA te da el mapa estático completo: referencias cruzadas, pseudocódigo decompilado y cada ruta de código se ejecute o no. Un depurador como x64dbg te permite ejecutar el ejemplar bajo control — poner breakpoints, inspeccionar registros y memoria, observar el descifrado ocurrir, y seguir la ruta que el código toma realmente con entradas reales. Se lee la estructura y la intención estáticamente, luego se adjunta el depurador para resolver lo que el análisis estático no puede: cadenas descifradas en tiempo de ejecución, APIs resueltas dinámicamente, cargas útiles empaquetadas y qué rama toma una condición. Los dos juntos cierran sus mutuas carencias.
¿Cuáles son las señales del beaconing de mando y control, y cómo se extraen los indicadores C2 de un ejemplar?
El beaconing de mando y control es el implante llamando periódicamente a casa en busca de instrucciones. Se reconoce por llamadas salientes regulares y de bajo volumen a un intervalo aproximadamente fijo — a menudo con jitter para no parecer mecánico — hacia un pequeño conjunto de destinos, con frecuencia sobre HTTP/HTTPS o DNS con cargas útiles codificadas o cifradas y un User-Agent o patrón de URI distintivo. Se extraen los indicadores estáticamente sacando dominios, IPs, URIs y claves de las cadenas y bloques de configuración, y dinámicamente detonando el ejemplar contra una red falsa y capturando las llamadas reales, luego se asigna el comportamiento a ATT&CK y se alimentan los IOC en la detección.
¿Qué son los packers y la ofuscación, y cómo se detectan en un binario?
El empaquetado comprime o cifra la carga útil real y le antepone un stub que la desempaqueta en memoria en tiempo de ejecución; la ofuscación transforma el código o los datos para resistir la lectura y las firmas. El empaquetado se detecta por una entropía de sección alta cercana a 8,0, una tabla de imports diminuta o solo de stub, nombres de sección inusuales o escribibles-ejecutables como UPX0, un punto de entrada fuera de .text, un gran tamaño virtual frente a un pequeño tamaño en bruto, y detectores como Detect It Easy o PEiD. Ninguno de estos es concluyente por sí solo, así que los analistas ponderan varias señales juntas y confirman observando el desempaquetado en tiempo de ejecución.
Guíame por el formato de archivo PE de Windows y qué partes inspeccionas al triar un ejemplar.
Un archivo PE empieza con la cabecera DOS y su puntero e_lfanew a las cabeceras PE/NT, que contienen el File Header y el Optional Header (punto de entrada, image base, subsistema). Está dividido en secciones — .text para el código, .data, .rdata, .rsrc para los recursos — cada una con una dirección virtual y un tamaño en bruto. Durante el triaje se lee la tabla de imports en busca de API sospechosas, la tabla de secciones por nombres extraños y entropía alta que insinúan empaquetado, el timestamp y el rich header, los recursos incrustados y cualquier firma digital. Las discrepancias entre estos elementos dicen mucho antes incluso de ejecutar el archivo.
Explica las técnicas comunes de inyección de procesos y las firmas de API y de comportamiento que las revelan.
La inyección de procesos ejecuta código malicioso dentro de otro proceso para ocultarse y heredar su confianza. La inyección remota clásica reserva memoria en un objetivo con VirtualAllocEx, escribe una carga útil vía WriteProcessMemory y la ejecuta con CreateRemoteThread. Las variantes incluyen la inyección de DLL vía LoadLibrary, el process hollowing que desmapea un proceso legítimo suspendido y reemplaza su imagen, la inyección APC que encola código en un hilo, y la carga reflexiva o mapeada manualmente que evita LoadLibrary por completo. Se detectan por las secuencias de API reveladoras, la memoria RWX en un proceso normalmente limpio, los hilos sin archivo de respaldo en disco y las anomalías padre-hijo.
Describe cómo construyes un laboratorio aislado para analizar malware vivo de forma segura.
Un laboratorio seguro aísla el malware de cualquier cosa que pudiera dañar. Ejecutas las muestras en VMs desechables sobre un hipervisor, tomas snapshots limpios para poder revertir tras cada detonación, y cortas el acceso real a la red usando una red host-only con una internet simulada (INetSim o FakeNet) o un segmento aislado (air-gap). Separas la máquina de análisis de una pasarela controlada, nunca analizas en tu host de uso diario, te endureces frente al VM-escape, manejas las muestras como zips protegidos con contraseña, y mantienes las herramientas e indicadores fuera de la VM de detonación. El objetivo es observar el comportamiento real garantizando que la muestra no pueda alcanzar producción ni internet.
¿Cómo detecta y evade el malware los sandboxes de análisis, y cómo lo contrarrestas?
El malware consciente del sandbox comprueba si lo están observando antes de portarse mal. Busca artefactos de VM e hipervisor (drivers, prefijos MAC, claves de registro, CPUID), herramientas de análisis y depuradores (nombres de proceso, IsDebuggerPresent, temporización del single-stepping), y señales de un usuario real (pocos procesos, sin documentos recientes, sin movimiento de ratón, poco uptime, disco pequeño). Puede demorarse con sleeps largos o solo activarse en una fecha, idioma o dominio concretos. Los analistas lo contrarrestan endureciendo la VM para que parezca real, parcheando las comprobaciones, adelantando los sleeps, simulando actividad del usuario y confirmando el comportamiento con desensamblado estático.
Explícame tus herramientas centrales para el análisis estático frente al dinámico de malware y cuándo usas cada una.
Las herramientas estáticas leen la muestra en reposo: PEStudio, CFF Explorer y pefile para cabeceras e imports, FLOSS y strings para el texto embebido, capa para el mapeo de capacidades, y Ghidra o IDA para el desensamblado. Las herramientas dinámicas la observan ejecutarse dentro de una VM aislada: Procmon y Process Hacker para la actividad del host, Wireshark e INetSim o FakeNet para la red falseada, Regshot para los diffs de antes/después, y x64dbg para el stepping controlado. El flujo de trabajo es triar estáticamente, detonar dinámicamente, y luego volver al desensamblador para rellenar los huecos de comportamiento.
Describe cómo desempaquetas una muestra packed para llegar al código original.
El desempaquetado recupera el código original que el packer ocultó. Para packers conocidos usas el desempaquetador correspondiente o un emulador. Para packers personalizados desempaquetas manualmente: ejecutas la muestra en un depurador, dejas que el stub descomprima el payload en memoria, encuentras el momento en que salta al original entry point (a menudo poniendo un breakpoint en memoria que pasa a ser ejecutable, o en el tail jump), luego vuelcas la imagen del proceso desde memoria y reconstruyes la import address table con una herramienta como Scylla o PE-sieve. El resultado es un PE ejecutable o analizable que contiene el payload real.
Explica cómo funcionan las reglas YARA y qué hace que una regla sea eficaz en lugar de frágil o ruidosa.
Una regla YARA tiene un bloque meta, una sección strings (patrones de texto, hex o regex, con comodines y saltos) y una condición que combina esas coincidencias con lógica booleana y de conteo. Una regla eficaz se apoya en algo duradero y distintivo — un stub de código único, un nombre de mutex, un marcador de configuración o una combinación de imports inusual — en lugar de valores que un atacante cambia trivialmente como un solo hash o una cadena genérica. Se equilibra la especificidad frente a los falsos positivos, se prueba contra un corpus limpio y se documenta la regla para que otros confíen en ella y la mantengan.
Consigue 100 preguntas de entrevista de ciberseguridad + respuestas
Déjanos tu correo y te enviaremos el pack en PDF gratuito y el mazo de flashcards.
Sin spam. Cancela tu suscripción cuando quieras.