Preguntas de entrevista de DFIR (Forensics & Incident Response)

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.

Las copias de seguridad son necesarias pero no suficientes: la recuperación ante desastres y la continuidad de negocio son la capacidad probada de restaurar las operaciones dentro de los objetivos acordados de tiempo y punto de recuperación (RTO/RPO), lo que exige un plan documentado, dependencias mapeadas, runbooks y restauraciones validadas, no solo la existencia de archivos de copia. Afirmar que son lo mismo confunde una copia de datos con una capacidad operativa. El DR no es solo contratar un seguro, que transfiere la pérdida financiera pero no restaura los sistemas. Y las copias no hacen innecesario un plan de DR: las copias no probadas fallan habitualmente cuando por fin se necesitan. La aclaración: el DR debe ejercitarse, no presumirse.

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.

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.

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.

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.

Reduce los falsos positivos mediante ingeniería de detección, no cegándote. Reajusta para que las alertas disparen solo en patrones que importan — una misma contraseña probada en muchas cuentas (spraying), una cuenta atacada muchas veces (stuffing/fuerza bruta), viaje imposible — manteniendo los eventos brutos consultables en un panel. Luego mide la precisión de las alertas con el tiempo. Desactivar la regla elimina una señal real, una supresión global crea un punto ciego permanente, y contratar gente para triar puro ruido no escala y los quema.

Valida antes de escalar. Las VPN corporativas, los proxies en la nube (CASB o IP de servicio de M365) y los operadores móviles producen rutinariamente falsos «viajes imposibles»; comprueba las IP de salida, el resultado MFA y el dispositivo/user-agent antes de actuar. Bloquear en cada disparo causa fatiga de alertas y erosiona la confianza de los usuarios en el SOC. Asumir que siempre es un falso positivo deja pasar una apropiación de cuenta real. Escribir al jefe es lento y no es un control — los registros responden más rápido y con más fiabilidad.

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.

Tría por impacto y alcanzabilidad: el volcado de credenciales (firma de mimikatz) en un controlador de dominio es un evento sobre las joyas de la corona que puede llevar a la compromisión total del dominio, así que trabájalo primero. El escaneo de puertos externo ya fue bloqueado por el IDS, la extensión de navegador no aprobada es de baja gravedad, y un certificado TLS caducado en una máquina de prueba interna es informativo. La habilidad central del SOC es priorizar por radio de impacto y probabilidad de escalada, no por la antigüedad ni por lo «ruidosa» que sea la alerta.

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.

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.

La continuidad del negocio (BCP) es la estrategia amplia para mantener las funciones críticas del negocio operando durante y después de una interrupción; la recuperación ante desastres (DRP) es el subconjunto centrado en TI que restaura sistemas y datos. El RTO es el tiempo máximo tolerable para restaurar una función; el RPO es la pérdida de datos máxima tolerable medida en tiempo.

El análisis cuantitativo asigna valores monetarios concretos para calcular la pérdida esperada; el análisis cualitativo clasifica el riesgo en escalas relativas (alto/medio/bajo) mediante juicio experto. El cuantitativo usa SLE = valor del activo x factor de exposición, ARO = ocurrencias esperadas por año, y ALE = SLE x ARO para expresar la pérdida anual esperada en euros.

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.

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.

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.

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.

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 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.

ATT&CK es una base de conocimiento de tácticas reales del adversario (el porqué), técnicas (el cómo) y procedimientos. La usas para mapear tus detecciones existentes sobre la matriz, identificar brechas de cobertura y priorizar las técnicas usadas por los actores que realmente atacan tu sector. Ofrece un lenguaje común entre CTI, ingeniería de detección e IR, convirtiendo «¿estamos seguros?» en un mapa de cobertura concreto y medible, impulsado por el comportamiento real del adversario.

El purple teaming es colaborativo en lugar de adversarial: el lado rojo ejecuta TTP específicos y acordados (a menudo asociados a MITRE ATT&CK) mientras el lado azul observa su telemetría en tiempo real para confirmar si cada técnica se registra, alerta y es detectable. Mides la cobertura de detección técnica por técnica, ajustas detecciones y cierras brechas de inmediato, y luego vuelves a probar. El entregable es una detección mejorada y medible — no una lista de quién «ganó».

Un buen informe sirve a dos públicos: un resumen ejecutivo que encuadra el riesgo de negocio para la dirección, y hallazgos detallados y reproducibles con evidencias, calificaciones de riesgo precisas y remediación priorizada para el equipo técnico. El informe — no el exploit — es el entregable.

Un SDLC seguro integra la seguridad en cada fase en lugar de añadirla al final. Los requisitos incluyen casos de seguridad y de abuso, el diseño añade modelado de amenazas, el desarrollo usa codificación segura y SAST más escaneo de dependencias, las pruebas añaden DAST y pruebas de penetración, y operaciones añade monitorización, parcheo y respuesta a incidentes — desplazando la seguridad hacia la izquierda.

La fatiga de alertas es la desensibilización que aparece cuando los analistas enfrentan demasiadas alertas de bajo valor o falsos positivos, lo que les hace pasar por alto o atender con prisa las reales. Se combate ajustando las reglas ruidosas, priorizando por riesgo, deduplicando y agrupando alertas relacionadas, automatizando el enriquecimiento repetitivo con un SOAR y midiendo la calidad de las alertas, no solo el volumen.

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 EDR se centra en el endpoint: registra y responde a la actividad de procesos, archivos y red en los hosts. El XDR extiende esa correlación a varios dominios —endpoint, red, identidad, correo, nube— como una stack integrada de un mismo proveedor. El SIEM es la capa amplia de agregación de logs que ingiere datos de cualquier fuente, incluidas las no de seguridad, para detección, búsqueda y cumplimiento.

Primero entiende por qué la regla se dispara tanto: encuentra el patrón benigno común detrás del ruido. Luego escribe la exclusión más estrecha posible (host, cuenta o comportamiento específico), documenta la justificación y valida que un verdadero positivo seguiría disparándose. Evita supresiones amplias que crean puntos ciegos en silencio.

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.

Un SIEM ingiere y correlaciona logs de todo el parque para generar alertas: es tu capa de detección y búsqueda. Un SOAR se sitúa aguas abajo y automatiza la respuesta: ejecuta playbooks, enriquece las alertas mediante integraciones y gestiona los casos para que los analistas dediquen menos tiempo a pasos repetitivos.

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.