Preguntas de entrevista de Incident Responder

No. El antivirus es una señal, no una prueba. Omite ataques sin archivo y en memoria, muestras nuevas u ofuscadas, el abuso de herramientas legítimas (living-off-the-land) y los rootkits diseñados para ocultarse de él. La ausencia de prueba no es prueba de ausencia — la garantía real proviene de la telemetría EDR, el análisis forense de memoria, el análisis conductual y la caza de IOC. Tratar un análisis antivirus limpio como prueba de un sistema limpio es un error clásico de respuesta a incidentes.

No por sí solo. Muchos sistemas mantienen válidas las sesiones existentes y los tokens ya emitidos tras un cambio de contraseña — tokens de actualización OAuth, «contraseñas de aplicación», claves de API y cookies persistentes — así que un atacante con una sesión activa puede permanecer dentro. La respuesta correcta es cambiar la contraseña Y invalidar todas las sesiones y tokens, revocar las credenciales de aplicación y auditar los dispositivos MFA y los ajustes de recuperación. Creer que un restablecimiento solo expulsa al atacante es un error clásico de respuesta a incidentes.

No. La mayoría de las intrusiones reales establecen persistencia (servicios, tareas programadas, claves de inicio, implantes) que sobrevive a un reinicio, así que el atacante simplemente vuelve. Peor aún, apagar borra las pruebas volátiles — procesos en ejecución, conexiones de red, malware en memoria y claves de cifrado — que necesitas para acotar el incidente. Lo correcto es contener aislando el host mientras se preserva la memoria, y luego investigar. Reiniciar o apagar como «solución» es un instinto dañino.

Una reconstrucción fiable de un incidente surge de correlacionar telemetría independiente en una sola cronología: registros de autenticación, datos de proceso/ejecución del EDR, marcas de tiempo MAC del sistema de archivos, flujos de red y eventos del SIEM, para ordenar las acciones y acotar el alcance. Un solo registro o el evento más reciente por sí solo pierde la cadena y puede inducir a error o estar manipulado. Adivinar a partir de una fuente o preguntar al atacante no son métodos de investigación. La correlación entre fuentes independientes revela la actividad completa del atacante y resiste a un atacante que editó una de ellas.

La integridad probatoria se basa en hashear la imagen en la adquisición (por ejemplo, SHA-256) y verificar el hash después para probar que no fue alterada, mantener una cadena de custodia documentada, y analizar una copia de trabajo para que el original quede intacto. Renombrar el archivo no hace nada por la integridad, y comprimirlo para ahorrar espacio no prueba la integridad ni ayuda a la admisibilidad. Tocar el original arriesga una destrucción de pruebas que puede hacer que se descarte la evidencia. Hashea, documenta la custodia y trabaja sobre una copia verificada.

Un vacío en los registros locales durante un incidente puede significar registros borrados o manipulados, un paso antiforense común, así que no trates la ausencia de registros como ausencia de actividad. Coteja con registros centralizados/reenviados, EDR y datos de red que el atacante probablemente no pudo alterar, y documenta el vacío de integridad como un hallazgo. Suponer que el servidor estaba inactivo confía en pruebas que el atacante puede controlar, tratar el vacío como prueba de que no pasó nada es justo la conclusión que él quiere, y borrar más registros destruye lo que queda. Corrobora en su lugar con telemetría independiente.

Urgencia, autoridad y omitir la verificación son presión de ingeniería social de manual dirigida a una cuenta de alto valor. El agente debe seguir el proceso de verificación de identidad definido antes de restablecer nada, y escalar si no puede satisfacerse. Restablecer a demanda, usar una «pregunta de seguridad» adivinable como el color favorito, o enviar por correo la nueva contraseña al llamante entregan todos el control de la cuenta del directivo a un atacante.

La persistencia en Linux se esconde en las rutas de ejecución programada y de arranque: cron y timers/unidades de systemd, claves añadidas en authorized_keys SSH, archivos rc del shell y scripts de perfil modificados, y binarios de servicio o bibliotecas precargadas troyanizados. Revísalos sistemáticamente. El historial del navegador y la configuración del fondo de pantalla no son mecanismos de persistencia, y reiniciar no eliminará nada que se restablezca en el arranque — solo lo relanza. El propósito de la persistencia es sobrevivir a los reinicios, así que un reinicio no demuestra nada.

Un binario SUID-root se ejecuta con privilegios de root, y si es escribible por todos un atacante puede reemplazarlo o modificarlo para ejecutar código arbitrario como root — una vía clásica de escalada de privilegios local. Retira el bit SUID, corrige el propietario y los permisos, e investiga cómo apareció esta mala configuración, ya que puede indicar un compromiso. Cifrar el archivo deja intacta la ruta ejecutable, y renombrarlo solo traslada el problema sin eliminar la escalada. Ninguna de estas opciones aborda la causa raíz.

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.

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.

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.

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.

LSASS almacena credenciales y secretos en caché, así que un proceso inesperado leyendo su memoria es el sello del robo de credenciales (por ejemplo, un volcado de tipo mimikatz). Tría el proceso ofensor y su padre, aísla el host para detener el movimiento lateral, y rota las credenciales que pudieron capturarse — incluidas las cuentas privilegiadas y de servicio. No tiene nada que ver con el renderizado gráfico ni el espacio en disco, e ignorarlo como normal puede llevar a un compromiso de todo el dominio. Los distractores de apariencia inocua son justo cómo los analistas pasan por alto una intrusión activa.

Word generando un proceso hijo justo después de habilitar las macros es un patrón clásico de acceso inicial por documento malicioso. Aísla el host para limitar la propagación, captura las pruebas volátiles, e investiga el proceso generado, su actividad de red y cualquier persistencia. Pedir al usuario que cierre el archivo o reparar Office no aborda una carga útil en ejecución que quizá ya corrió. No hacer nada porque el archivo llegó por correo es al revés — el correo es justamente el vector de entrega de este ataque. Contén primero, luego investiga.

El software legítimo rara vez ejecuta PowerShell desde %TEMP% mediante una tarea programada recién creada — es una técnica común de persistencia y ejecución. Examina la definición de la tarea, el script invocado, el proceso creador y la cronología, contén el host y barre el entorno en busca del mismo patrón. Las actualizaciones no se ven así, confiar ciegamente en las tareas programadas ignora una TTP conocida, y borrar System32 rompe el sistema operativo sin hacer nada contra la amenaza. Las tres primeras opciones reflejan un criterio peligrosamente débil.

Las simulaciones ensayan el lado humano y de decisión de la RI — quién tiene autoridad para declarar un incidente, cómo fluye la comunicación legal/RR. PP./dirección y dónde se rompe el manual — para que la primera vez que tomes esas decisiones no sea durante una crisis real. Es mucho más barato encontrar brechas en un ejercicio que en plena brecha. No son una casilla de cumplimiento vacía, no sirven para asignar culpas por incidentes pasados, y son transversales, no solo del SOC — la dirección debe practicar las decisiones que solo ella puede tomar.

La brecha de un proveedor también es tu incidente: invocar la respuesta a incidentes para acotar qué datos e integraciones quedaron expuestos, rotar todos los secretos compartidos, claves API y relaciones de confianza SSO, evaluar tus propias obligaciones de notificación regulatoria y exigir al proveedor su divulgación. Esperar pasivamente al proveedor cede el control de tu propio calendario y obligaciones. Una rescisión pública del contrato es teatro prematuro antes de conocer siquiera tu exposición. Asumir que no te afectó omite precisamente la evaluación que esperan los reguladores y tus clientes.

Sin registros de auditoría del plano de control estás ciego ante quién hizo qué a nivel de nube, y la detección, la forense y el cumplimiento dependen de ese registro. Activa CloudTrail de inmediato, a nivel de organización, entregando a un bucket separado, con acceso controlado y resistente a manipulación (inmutable). Decir que no importa mientras nada vaya mal ignora que no tendrías historial cuando algo vaya mal. Esperar a un incidente significa que las primeras acciones decisivas ya quedan sin registrar e irrecuperables. Los registros de aplicación no capturan la actividad de API, IAM ni consola del plano de control.

Los datos de clientes expuestos públicamente son una exposición activa: remedia primero el acceso activando Block Public Access y corrigiendo la política del bucket y la política IAM para detener la fuga en curso. Luego extrae los registros de acceso (S3 server access logs / eventos de datos de CloudTrail) para evaluar qué se alcanzó realmente y activa los procesos de brecha y notificación según la política. Abrir un ticket para el próximo sprint deja datos regulados expuestos durante días. Copiar los datos a otro sitio crea una segunda copia pero deja el bucket original abierto. Renombrar no cambia nada de sus permisos.

Sigue el orden de volatilidad. La RAM, las conexiones de red activas y la tabla de procesos desaparecen al apagar; captúralas primero, luego toma una imagen forense del disco documentando los hashes y una cadena de custodia ininterrumpida. Un apagado limpio destruye la evidencia residente en memoria — incluido el malware sin archivos y las claves que solo viven en la RAM. Copiar-y-luego-borrar altera la escena y rompe la integridad. Ejecutar el antivirus de la empresa muta el sistema y puede poner en cuarentena o borrar el mismo artefacto que necesitas analizar.

La contención prima sobre la recuperación prematura: detén la propagación aislando los segmentos afectados y cortando el vector — desactiva la cuenta de servicio abusada, bloquea SMB entre segmentos, retira el host de staging — preservando evidencia, luego erradica y recupera. Restaurar en una red que aún cifra vuelve a perder los datos restaurados. Pagar el rescate no detiene el cifrado en curso y conlleva riesgo legal y de sanciones. Cortar la electricidad de todas las máquinas destruye evidencia volátil y puede corromper archivos a medio escribir, dificultando una recuperación limpia.

Erradicar antes de entender el alcance deja al atacante persistir en sistemas que no has encontrado y simplemente volver. Caza rápido los IOC y las credenciales robadas por todo el parque, identifica cada host afectado y cada mecanismo de persistencia, y luego erradica en todas partes a la vez. Borrar un solo host es un juego de whack-a-mole que alerta al atacante mientras deja intactos sus otros puntos de apoyo. Un apagón total de internet de una semana es desproporcionado y daña al negocio. Borrar solo el archivo de malware ignora la persistencia, el movimiento lateral y las credenciales ya robadas.

Descubrir una intrusión activa es una emergencia fuera de banda: las reglas de enfrentamiento deben definir una ruta de escalada, así que invócala de inmediato, preserva las pruebas y evita contaminar un incidente en curso. Seguir probando puede interferir con el atacante real o destruir las pruebas que necesitan los respondedores. Intentar expulsar tú mismo al atacante queda fuera de alcance, es arriesgado y puede alertarlo. Esperar al informe final podría significar días de brecha continua y pérdida de datos.

Consultas TXT de alto volumen y alta entropía, o subdominios largos hacia un solo dominio, son una firma clásica de tunneling DNS / C2-exfiltración: se cuelan datos dentro del DNS para evadir el filtrado de salida. Captura una muestra de consultas para analizarla, sinkholea o bloquea el dominio para cortar el canal, y pivota al host para hallar el proceso responsable. Descartarlo como caché normal o un sitio lento deja pasar una exfiltración en curso. Reiniciar el servidor DNS no hace nada contra el endpoint comprometido y solo interrumpe la resolución de nombres.

Asume que la contraseña ya está comprometida: fuerza un restablecimiento Y revoca las sesiones y tokens activos de la cuenta, porque un reset por sí solo no expulsa a un atacante que ya posee una sesión viva o un token de actualización. Luego caza inicios de sesión anómalos, solicitudes MFA, reglas de buzón y concesiones OAuth de la ventana de exposición. Borrar el correo o decirle al usuario que cambie la contraseña «la próxima vez» deja la cuenta abierta de par en par. Un análisis antivirus aborda el malware del endpoint, no las credenciales robadas en la nube.

El credential stuffing reproduce pares usuario:contraseña conocidos de brechas de terceros, apostando a la reutilización de contraseñas: alta tasa de éxito por intento, a menudo repartido entre muchas IP y dispositivos para parecer humano. El password spraying prueba una o dos contraseñas comunes (como Winter2026!) en muchas cuentas para mantenerse bajo los umbrales de bloqueo. El stuffing explota la reutilización; el spraying explota contraseñas compartidas débiles. La MFA derrota a ambos.

La Cyber Kill Chain modela una intrusión como siete etapas secuenciales: reconocimiento, armamentización, entrega, explotación, instalación, comando y control (C2) y acciones sobre objetivos. Los defensores asignan detecciones y controles a cada etapa; como las etapas son secuenciales, romper un solo eslabón —bloquear el correo de phishing, matar el C2— interrumpe todo el ataque. Empuja a detectar pronto en vez de solo en la brecha final.

La exfiltración por DNS codifica datos robados en consultas DNS (p. ej. etiquetas de subdominio largas enviadas a un servidor autoritativo controlado por el atacante), abusando de que el DNS casi siempre está permitido en salida y a menudo sin monitorizar. Detéctala con anomalías: volumen de consultas inusualmente alto a un dominio, subdominios largos / de alta entropía, muchos subdominios únicos por dominio padre, abuso de registros TXT/NULL y consultas a dominios recién registrados o raros.

El antivirus tradicional coteja archivos contra firmas de malware conocido y los bloquea o pone en cuarentena: bueno contra amenazas conocidas, débil ante ataques nuevos o sin archivo. El EDR registra de forma continua el comportamiento del endpoint (procesos, red, registro, memoria), usa analítica de comportamiento para detectar actividad sospechosa y permite a los respondedores investigar, cazar y contener o revertir de forma remota. El AV es prevención por firma; el EDR añade visibilidad, detección y respuesta.

El modelo clásico es PICERL: Preparación, Identificación (detección), Contención, Erradicación, Recuperación y Lecciones aprendidas. El NIST lo agrupa como Preparación; Detección y análisis; Contención, erradicación y recuperación; y Actividad posterior al incidente. El orden importa porque debes delimitar y contener antes de erradicar, y solo recuperas una vez eliminada la amenaza, o reinfectas. Es un bucle, no una línea: las lecciones aprendidas realimentan la preparación.

Un IOC es un artefacto forense de que algo malicioso ya ocurrió: un hash de archivo malicioso, una IP o dominio de C2, una clave de registro conocida como dañina. Un IOA es una señal de comportamiento de un ataque que se desarrolla, independientemente de las herramientas concretas, p. ej. un documento de Word que lanza PowerShell y luego sale a Internet. Los IOC son reactivos y fáciles de evadir cambiando un hash; los IOA capturan la intención y sobreviven a los cambios de herramienta.

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.

El orden de volatilidad clasifica la evidencia según lo rápido que se desvanece, para recopilar primero lo más frágil. A grandes rasgos: registros/caché de CPU, luego RAM y estado en ejecución (procesos, conexiones de red, ARP), luego archivos temporales/swap, luego disco, luego registro y datos de monitorización remotos y, por último, soportes de archivo y copias de seguridad. También trabajas sobre copias forenses, las hasheas y mantienes una cadena de custodia para que la evidencia siga siendo admisible.

En Windows, los hashes de cuentas locales (NTLM) viven en la subárbol SAM en C:\Windows\System32\config\SAM, protegido mientras el SO está en marcha; las credenciales vivas residen en la memoria de LSASS, y los hashes de dominio están en NTDS.dit en un controlador de dominio. En Linux, los hashes están en /etc/shadow (legible solo por root), mientras que /etc/passwd guarda los metadatos de la cuenta. Los atacantes los roban para crackear contraseñas sin conexión o hacer pass-the-hash.

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.

El ransomware es malware que cifra (y cada vez más exfiltra) datos y luego exige pago. En un caso activo: aislar los hosts afectados de la red sin apagarlos si puedes preservar la memoria, identificar el alcance, el paciente cero y la cepa, preservar la evidencia, encontrar y expulsar el punto de apoyo y cualquier puerta trasera, y luego restaurar desde copias offline reconocidas como limpias. Pagar es un último recurso y nunca garantiza la recuperación.

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.

Un honeypot es un sistema o servicio señuelo sin uso de negocio legítimo, expuesto deliberadamente para atraer atacantes. Como nada benigno debería tocarlo nunca, cualquier interacción es una alerta de alta confianza. Los honeypots de baja interacción emulan servicios de forma barata; los de alta interacción son sistemas reales que rinden inteligencia más rica pero conllevan más riesgo. Los honeytokens son la misma idea aplicada a credenciales, archivos o registros falsos. Valor: detección temprana, pocos falsos positivos e inteligencia de amenazas.

El registro Security es primario: 4624 inicio de sesión correcto (con tipo de inicio), 4625 inicio fallido, 4634/4647 cierre de sesión, 4672 privilegios especiales asignados, 4720 cuenta creada, 4688 creación de procesos (con línea de comandos si está habilitada) y 4768/4769 Kerberos. Añade 7045 instalación de servicio (registro System), 4698 tarea programada creada y el registro de bloques de script de PowerShell (4104). El tipo de inicio de sesión y la auditoría de líneas de comandos son lo que hace útiles estos registros.

CloudTrail registra cada llamada a la API en la cuenta — quién hizo qué, cuándo, desde dónde — dándote el rastro de auditoría con autoridad para investigaciones y cumplimiento. GuardDuty es un servicio gestionado de detección de amenazas que analiza CloudTrail, los flujos de VPC y los registros de DNS para sacar a la luz hallazgos como la exfiltración de credenciales o la minería de criptomonedas. CloudTrail es la fuente de verdad que debes proteger; GuardDuty convierte esa telemetría en alertas accionables.

Perfect Forward Secrecy (PFS) significa que cada sesión deriva una clave única de un intercambio de claves efímero que se descarta después. Si un atacante roba más tarde la clave privada de largo plazo del servidor, aún no puede descifrar el tráfico capturado previamente, porque esa clave nunca se usó para derivar las claves de sesión. Se logra con Diffie-Hellman efímero (DHE/ECDHE).

El phishing es ingeniería social que engaña a las personas para que revelen credenciales, envíen dinero o ejecuten malware, normalmente mediante correos o sitios falsos. La defensa es por capas: filtrado y autenticación de correo (SPF/DKIM/DMARC), MFA para limitar el daño de credenciales robadas, formación de concienciación y una forma sencilla de reportar mensajes sospechosos.

Un día cero es una vulnerabilidad que el fabricante aún no conoce (o no ha parcheado), por lo que los defensores han tenido «cero días» para arreglarla. Como no existe parche, la defensa se apoya en controles por capas, detección por comportamiento, segmentación, mínimo privilegio y respuesta rápida a incidentes en lugar de una firma.

Porque «eliminar» normalmente no borra los datos. Quita los metadatos del sistema de archivos (el puntero/la entrada de directorio) y marca los bloques como libres, pero los bytes originales permanecen en el disco hasta que el sistema operativo reutiliza esos bloques para nuevos datos. Hasta que ocurre esa sobrescritura, las herramientas forenses pueden extraer el contenido directamente.

Desde un punto de vista puramente de seguridad, un falso negativo suele ser peor: significa que un ataque real pasó sin detectarse, así que no hay respuesta, ni contención, y la brecha puede permanecer latente sin descubrirse. Pero los falsos positivos no son inofensivos: en grandes volúmenes provocan fatiga de alertas, donde los analistas empiezan a ignorar las alertas y se les escapa la real. La respuesta correcta nombra el compromiso, no solo un ganador.

No. El candado significa que el transporte está cifrado y que el certificado es válido para ese dominio: no dice nada sobre si el operador es honesto o el contenido es malicioso. Los certificados gratuitos y automatizados hacen que los sitios de phishing y malware casi siempre tengan también un candado perfectamente válido. HTTPS protege el canal, no el destino.

Una línea base es un modelo del comportamiento normal de un host, usuario, cuenta o segmento de red: qué procesos se ejecutan, quién inicia sesión desde dónde y cuándo, los volúmenes de datos típicos, los intervalos normales de beaconing. Una vez que conoces lo normal, las anomalías (pares de procesos padre-hijo raros, binarios vistos por primera vez, inicios de sesión a horas extrañas, salida de datos inusual) se vuelven detectables como desviaciones. Establecer una línea base es el fundamento de la detección de anomalías, pero requiere suficiente historial limpio y un manejo cuidadoso del cambio legítimo para no ahogarte en falsos positivos.

El beaconing C2 es el check-in periódico que un implante hace a su controlador. Cázalo en la telemetría de red/proxy/DNS buscando regularidad: conexiones a un destino a intervalos casi fijos (incluso con jitter), solicitudes pequeñas y uniformes, ratios bajos de datos-entrantes / datos-salientes, destinos raros de larga duración y huellas TLS/JA3 sospechosas o user-agents extraños. La señal es el ritmo y la rareza del destino, no el payload — que suele estar cifrado.

Parte de las técnicas que quieres detectar y luego trabaja hacia atrás hasta la telemetría que las revela — el mapeo de fuentes de datos de ATT&CK ayuda. En la práctica, las fuentes de mayor valor son la telemetría de endpoint de procesos/línea de comandos y carga de módulos (EDR/Sysmon), los registros de autenticación e identidad, el DNS y el flujo proxy/red, y los registros del plano de control de la nube. Luego auditas lo que realmente recopilas y retienes frente a lo que necesita cada técnica, exponiendo los puntos ciegos. Una técnica que no puedes ver en ningún registro aún no es cazable.

La ingeniería de detección trata las detecciones como un producto de software con un ciclo de vida: identificar una amenaza o técnica que cubrir, investigar la telemetría y el comportamiento, desarrollar la regla, probarla contra datos de verdaderos positivos y benignos, desplegarla (a menudo por fases), validarla con emulación de adversario y luego ajustarla continuamente para los falsos positivos y retirar las reglas que ya no se justifican. Cada etapa se documenta y se versiona, y la cobertura se rastrea frente a un marco como ATT&CK.

Los LOLBins (living-off-the-land binaries) son herramientas del sistema legítimas, firmadas y preinstaladas — como certutil, bitsadmin, mshta, rundll32, regsvr32, wmic, powershell — que los atacantes abusan para descargar, ejecutar o persistir mientras se camuflan con la actividad administrativa normal. Como el propio binario es de confianza, no puedes detectar sobre el archivo; detectas sobre el contexto: argumentos de línea de comandos anómalos, procesos padre inusuales, conexiones de red inesperadas desde estas herramientas, y ejecución desde rutas extrañas o por usuarios inusuales.

La Pyramid of Pain clasifica los tipos de indicadores según lo costoso que le resulta a un atacante cambiarlos una vez que detectas sobre ellos. Los hashes son triviales de alterar (abajo), luego las direcciones IP, los nombres de dominio, los artefactos de red/host, las herramientas y, finalmente, los TTP en la cima — que un atacante solo puede cambiar reconfigurando fundamentalmente su comportamiento. Detectar en los niveles superiores causa más « dolor » y es más duradero, así que los programas maduros invierten el esfuerzo de detección en los comportamientos y los TTP en lugar de solo los IOC.

La caza basada en TTP usa MITRE ATT&CK como mapa: elige una técnica relevante para tu modelo de amenazas (idealmente una con cobertura débil), forma una hipótesis concreta sobre cómo aparecería en tu telemetría, identifica las fuentes de datos que la revelan, consúltalas y analiza los aciertos. Una buena caza está acotada, guiada por hipótesis, ligada a un comportamiento real de adversario, es repetible y produce un resultado duradero — una nueva detección, una brecha de cobertura documentada o evidencia de que la técnica está ausente — independientemente de si encuentra una intrusión.

UEBA (User and Entity Behaviour Analytics) construye líneas base de comportamiento para usuarios y entidades (hosts, cuentas de servicio, dispositivos) y usa estadística o aprendizaje automático para puntuar las desviaciones como riesgo. Sobresale ante amenazas sin firma clara: credenciales comprometidas, abuso interno y movimiento lateral — p. ej. un usuario que de repente accede a sistemas que nunca toca, a horas inusuales, o que mueve volúmenes de datos anómalos. Complementa la detección basada en reglas en lugar de reemplazarla, y necesita ajuste para evitar falsos positivos por cambios de comportamiento legítimos.

La caza de amenazas es la práctica proactiva, guiada por hipótesis, de buscar en la telemetría actividad de un adversario que las detecciones existentes pasaron por alto. A diferencia del triaje de alertas — reactivo y que espera a que una herramienta se dispare — la caza parte de una pregunta (« si un atacante hiciera X, ¿qué evidencia vería? »), la pone a prueba contra los datos y o bien encuentra algo o bien produce una nueva detección. Asume que la prevención y las alertas son imperfectas y que un adversario decidido puede estar ya dentro.

Sigma es un formato YAML abierto y neutral respecto al fabricante para describir detecciones de SIEM. Defines un logsource (product/category, p. ej. Windows process_creation), un bloque detection con selecciones nombradas de coincidencias campo/valor, y una condition que las combina. Un conversor (como sigma-cli/pySigma) traduce la regla al lenguaje de consulta de tu backend real —Splunk, Sentinel, Elastic— de modo que una sola regla es portable. También lleva metadatos: title, level, status, falsos positivos y etiquetas ATT&CK.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

El DFIR sigue un proceso disciplinado: identificación (confirmar y delimitar el incidente), adquisición (preservar pruebas siguiendo el orden de volatilidad, con imágenes forenses y hashes), análisis (línea de tiempo, causa raíz, alcance del compromiso) e informe (hallazgos para audiencias técnicas y legales). La cadena de custodia documenta quién manipuló cada artefacto y cuándo, para que la prueba se sostenga si alguna vez llega a un tribunal. Preservar antes de remediar.

Traceroute descubre los routers entre tú y un destino explotando el campo TTL. Envía paquetes con TTL=1, luego 2, luego 3, y así sucesivamente. Cada router decrementa el TTL; cuando el TTL llega a cero, ese router descarta el paquete y devuelve un mensaje ICMP Time Exceeded, revelando su dirección. Al ir subiendo el TTL, traceroute mapea cada salto en orden hasta alcanzar el destino.

Una DMZ (zona desmilitarizada) es un segmento de red situado entre la Internet no confiable y la red interna de confianza, que aloja servicios expuestos al público como servidores web, de correo y DNS. Las reglas del cortafuegos permiten que Internet alcance la DMZ pero restringen estrictamente el acceso de la DMZ a la red interna. El objetivo es la contención: si un servidor público se ve comprometido, el atacante queda atrapado en la zona de amortiguación en lugar de aterrizar dentro de la LAN.

Cualquier usuario autenticado del dominio puede solicitar un ticket de servicio Kerberos (TGS) para cualquier cuenta con un SPN. Ese ticket se cifra con el hash de contraseña NTLM de la cuenta de servicio, así que lo extraes y crackeas la contraseña sin conexión — sin necesidad de acceso privilegiado para empezar, y es casi silencioso.

Una bind shell abre un puerto de escucha en el objetivo y espera a que te conectes a él. Una reverse shell hace que el objetivo se conecte hacia fuera a un listener que tú controlas. Las reverse shells suelen ganar porque el tráfico saliente esquiva las reglas de cortafuegos entrantes y el NAT.

Reducir la superficie de ataque (eliminar paquetes y servicios sin uso), forzar SSH solo por clave sin inicio de sesión root, mantener el sistema parcheado, ejecutar un cortafuegos de denegación por defecto que exponga solo los puertos necesarios, aplicar privilegios mínimos mediante sudo y permisos de archivos, habilitar auditd y registro centralizado, y añadir monitorización de integridad más un MAC como SELinux o AppArmor.

La fuerza bruta apunta a una sola cuenta con muchos intentos de contraseña, por lo que se ven muchos fallos concentrados en un mismo usuario. El password spray lo invierte: una o pocas contraseñas comunes probadas en muchas cuentas, de forma lenta y sigilosa, de modo que cada cuenta solo registra un par de fallos. La señal de detección es la proporción de cuentas frente a fallos y el timing, no el número bruto de fallos.

Casi todo pasa por el DNS, así que los logs de DNS revelan amenazas que otras fuentes pasan por alto: beaconing de command-and-control (llamadas regulares a un dominio), tunneling y exfiltración DNS (alto volumen de subdominios largos y codificados) y dominios generados algorítmicamente (DGA). Se detectan mediante patrones como la regularidad de las consultas, la entropía, los tipos de registro y el volumen, no por una sola resolución sospechosa.

El movimiento lateral es un atacante que usa un punto de apoyo para alcanzar otros sistemas. Los signos incluyen logons de red inesperados (tipo 3) y RDP (tipo 10), acceso a recursos compartidos admin como C$ y ADMIN$, herramientas de ejecución remota como PsExec, WMI y WinRM, patrones de pass-the-hash, y una cuenta normalmente local que de repente se autentica en muchos hosts.

ATT&CK es una base de conocimiento de tácticas y técnicas adversarias del mundo real. En un SOC mapeas cada regla de detección a las técnicas que cubre, construyes un mapa de cobertura (a menudo con el ATT&CK Navigator) y luego priorizas cerrar las brechas según qué técnicas son más relevantes para tu modelo de amenazas y sobre cuáles no tienes visibilidad alguna.

Examina el correo sin hacer clic: revisa las cabeceras y la autenticación del remitente (SPF/DKIM/DMARC), inspecciona las URL y adjuntos en un sandbox o con herramientas de reputación, y luego mide el alcance: quién más lo recibió, si alguien hizo clic o introdujo credenciales. Según los hallazgos, remedia purgando el correo, bloqueando los indicadores y restableciendo las credenciales expuestas.

Confirma que la alerta es real antes de actuar: lee qué se disparó y por qué, luego enriquécela: quién es el usuario, si la IP/geo/dispositivo de origen son esperados, si hay viaje imposible, si hubo fallos previos. Clasifica como verdadero o falso positivo, escala o contén si es real (desactivar la sesión, forzar un restablecimiento de MFA) y documéntalo todo para que el siguiente analista pueda seguir tu razonamiento.

4624 es un logon exitoso, 4625 es un logon fallido y 4688 es una creación de proceso. En una investigación usas 4625 para detectar ataques de credenciales, 4624 (con su tipo de logon y su origen) para confirmar un acceso exitoso y cómo ocurrió, y 4688 para ver qué se ejecutó realmente, idealmente con la auditoría de línea de comandos habilitada.