Preguntas de entrevista de Threat Intelligence

No. La MFA sube mucho el listón, pero los factores OTP y push son phisheables: los kits de adversario en el medio (p. ej. Evilginx) retransmiten el inicio de sesión y el código en tiempo real, y la fatiga MFA / push-bombing empujan al usuario a aprobar. Los códigos capturados son reutilizables dentro de su corta ventana. El error es «MFA = imposible de phishear»; lo que importa es el tipo de factor. La MFA resistente al phishing — passkeys FIDO2/WebAuthn ligados al origen del sitio — es lo que realmente lo derrota.

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.

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.

Un 30 % de clics es una línea base que mejorar, no una lista de personas a castigar: combinar formación dirigida por rol y un botón de reporte sin fricción con defensas técnicas (MFA, filtrado de correo, mínimo privilegio) para que un solo clic no derive en compromiso, y seguir la tendencia en el tiempo. Avergonzar públicamente a los empleados suprime el reporte del que dependes. Declarar al personal irrecuperable elimina un control que deberías reforzar. Otro correo alarmista a toda la plantilla no es una intervención medible ni cambia el comportamiento.

El gasto en seguridad debe seguir al riesgo, no a la moda: usar una evaluación de riesgos para dirigir el dinero donde el impacto al negocio y la probabilidad son más altos y la cobertura de controles actual es más débil, y luego medir la reducción lograda. Comprar lo que vende el proveedor popular ignora tu perfil de amenaza real y a menudo financia herramientas sin usar. Repartir el presupuesto por igual infrafinancia las pocas áreas que más importan. Copiar a los competidores asume que su perfil de riesgo es igual al tuyo, lo cual rara vez ocurre.

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.

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.

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.

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.

La IA ayuda al SOC triando y deduplicando alertas, resumiendo incidentes, enriqueciendo contexto, redactando detecciones y acelerando la incorporación de analistas, reduciendo la fatiga y el tiempo de permanencia. Los riesgos: conclusiones alucinadas o erróneas con seguridad, sesgo de automatización donde los analistas dejan de verificar, prompt injection mediante datos de logs o alertas controlados por el atacante, fuga de datos sensibles a modelos de terceros, y adversarios que usan las mismas herramientas. Mantén un humano en el bucle, verifica las salidas y aísla las entradas no confiables.

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

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.

Un IDS (sistema de detección de intrusiones) monitoriza el tráfico y genera alertas pero no bloquea — suele estar fuera de banda. Un IPS (sistema de prevención de intrusiones) se sitúa en línea en la ruta del tráfico y puede descartar o bloquear activamente el tráfico malicioso. El IPS previene, pero un falso positivo puede romper tráfico legítimo.

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.

Una vulnerabilidad es una debilidad (software sin parchear). Una amenaza es un actor o evento que podría explotarla (un grupo de ransomware). El riesgo es la combinación de la probabilidad de que una amenaza explote una vulnerabilidad y el impacto si lo hace. Riesgo = amenaza x vulnerabilidad x impacto, y es lo que realmente se prioriza.

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.

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.

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.

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.

La divulgación coordinada de vulnerabilidades es un proceso en el que un investigador reporta un fallo en privado al fabricante, ambas partes acuerdan la remediación y un plazo, y los detalles se publican solo cuando hay un parche disponible (o vence el plazo acordado). Equilibra dar tiempo a los defensores para parchear con el derecho del público a saber. Un fichero security.txt y una política clara hacen que reportar sea sin fricciones; los programas de bug bounty añaden recompensas estructuradas encima.

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 pentest busca cobertura amplia — encontrar tantas vulnerabilidades como sea posible en un objetivo delimitado. Un red team es emulación de adversario dirigida por objetivos: elegir una meta (p. ej. alcanzar los datos más valiosos), emular los TTP de un actor de amenaza concreto, mantenerse sigiloso para probar la detección y la respuesta, y evitar el escaneo ruidoso. El red teaming mide al equipo azul y a toda la organización, no solo al activo; ambos requieren reglas de enfrentamiento estrictas y autorización.

Una evaluación de riesgos identifica los activos y su valor, las amenazas y vulnerabilidades que podrían afectarlos, y luego estima el riesgo como función de la probabilidad y el impacto. Puedes hacerla cualitativamente (alto/medio/bajo, rápido y subjetivo) o cuantitativamente (SLE × ARO = ALE, basado en datos pero más difícil). Marcos como NIST RMF e ISO 27005 le dan estructura, y el resultado alimenta el tratamiento del riesgo: mitigar, transferir, evitar o aceptar.

El reconocimiento pasivo reúne información sin interactuar directamente con los sistemas del objetivo — OSINT, registros DNS, transparencia de certificados. El reconocimiento activo toca el objetivo, como el escaneo de puertos o la captura de banners, que es más ruidoso pero aporta más detalle.

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.

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.

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.