SOC Investigation Workbook Series - Volume 1

Investigating Impossible Travel Alerts Like a Tier 2 Analyst

Un workbook de campo para trabajar la alerta desde el primer triage hasta el cierre del ticket. Escrito por un gerente de ingeniería de ciberseguridad que revisa estás investigaciones por trabajo.

Dentro: ejemplos de alertas reales, Análisis de logs de sign-in, un flujo de trabajo de investigación paso a paso, árboles de decisión de verdadero positivo vs falso positivo, un recorrido completo y páginas de notas para el analista que se pueden completar.

Jbird | jbirdcyber.gumroad.com

---

Qué hay en este Workbook

• Sección 1: Overview del ataque - Qué significa realmente el Impossible Travel
• Sección 2: La alerta llega - Ejemplo de alerta, logs e indicadores
• Sección 3: El flujo de trabajo de la investigación - Del triage a la contención
• Sección 4: Recopilación de evidencia - Fuentes de logs, artefactos, preguntas
• Sección 5: Tomando la decisión - True Positive, False Positive, Benigno
• Sección 6: Recorrido completo de la investigación - De principio a fin
• Sección 7: Notas del analista - Tus páginas de investigación completables
• Sección 8: Referencia rápida - La versión de una sola página
• Bonus: Cómo aparece el Impossible Travel en tu entrevista

CÓMO USAR ESTE WORKBOOK: Lee las Secciones 1 a 6 una vez, de principio a fin. Luego mantén abierta la Sección 8 durante tu turno y usa la Sección 7 para documentar tus primeras investigaciones reales. Las páginas completables existen porque el hábito de tomar notas estructuradas es lo que separa a un analista que cierra tickets de uno que cierra investigaciones.

Una palabra antes de empezar

Estoy en el lado de la contratación para roles de SOC e ingeniería. El Impossible Travel aparece en casi todas las entrevistas de Nivel 1 y Nivel 2 que realizo porque es una de las alertas más comunes que un analista nuevo tocará, y también es una de las más fáciles de investigar mal.

Si puedes guiar a un entrevistador a través de todo lo que hay en este workbook, estarás por delante de la mayoría de los candidatos que veo.

Para quién es esto

• Aspirantes y analistas junior de SOC que quieran entrar en el primer turno ya sabiendo cómo trabajar está alerta.
• Personal de help desk y sysadmin pivotando hacía la seguridad que necesitan prácticas de investigación antes de tener un asiento en un SOC.
• Estudiantes de ciberseguridad e internos que siguen leyendo definiciones pero nunca han visto cómo se ven los logs reales.
• Cualquier persona con una entrevista de SOC en el calendario. La sección bonus al final es para ti.

Todo lo que hay aquí es consciente de la plataforma pero agnóstico a la plataforma. Los ejemplos se inclinan hacía Microsoft porque es donde la mayoría de ustedes aterrizará, con una variante de Okta incluida, y cada concepto se transfiere a cualquier stack que corra su empresa.

---

Sección 1 - Overview del ataque

Qué significa realmente el Impossible Travel

Buenas tardes, amigos. Dejemos la definición fuera del camino primero porque la mitad de la batalla con está alerta es entender lo que tu plataforma de identidad realmente te está diciendo.

Una alerta de Impossible Travel se dispara cuando una sola cuenta se autentica desde dos ubicaciones geográficas en un lapso de tiempo que ningún humano podría cubrir físicamente.

Un sign-in desde Nueva Jersey a las 9:02 AM seguido de un sign-in desde Lagos a las 9:47 AM es la forma clásica. Ningún vuelo te lleva allí en 45 minutos, por lo que la lógica de detección marca el par de sign-ins como sospechosos.

Aquí está la parte que confunde a los analistas nuevos. La alerta NO te está diciendo que una cuenta esté comprometida. Te está diciendo que existen dos sesiones que no pueden ser ambas la misma persona física ante un teclado.

Tu trabajo es determinar en cuál de estás tres categorías cae: una cuenta comprometida, una peculiaridad de cómo las redes modernas enrutan el tráfico, o un usuario haciendo algo inusual pero legítimo.

Por qué los atacantes disparan esta alerta

Los atacantes no se proponen disparar el Impossible Travel. Lo disparan como un efecto secundario de usar credenciales que robaron en alguna otra parte del mundo.

Las rutas más comunes que veo en incidentes reales:

• Phishing y kits de adversary in the middle. El usuario ingresa sus credenciales (y a menudo un código MFA) en una página de inicio de sesión falsa. La infraestructura del atacante reproduce la sesión desde su propio hosting, frecuentemente en otro país, a menudo en minutos del último sign-in del usuario legítimo.
• Malware infostealer. Stealers como las familias Lumma y RedLine roban credenciales guardadas en el navegador y session cookies de un dispositivo infectado, ya sea personal o corporativo. El comprador de esos logs se conecta desde donde quiera que se encuentre.
• Credential stuffing y reutilización de contraseñas. La contraseña personal del usuario se filtró en alguna brecha de terceros y ellos la reutilizaron en el trabajo. Herramientas automatizadas lo intentan desde infraestructura en la nube dispersa por todo el globo.
• Robo de session tokens. El atacante nunca escribe una contraseña. Un cookie o token robado les permite reanudar una sesión desde una infraestructura nueva, lo que todavía produce un evento de sign-in desde una ubicación inesperada.

El hilo común: el usuario legítimo se conecta desde su ubicación normal, el atacante se conecta desde la suya, y la matemática de detección hace el resto. Esa es exactamente la razón por la que está alerta merece ser tomada en serio a pesar de que genera constantes falsos positivos.

NOTA DEL GERENTE DE CONTRATACIÓN: Cuando le pregunto a un candidato sobre Impossible Travel en una entrevista, las respuestas débiles se detienen en la definición. Las respuestas fuertes mencionan inmediatamente VPNs y el enrutamiento de los proveedores móviles como explicaciones benignas, y luego explican cómo distinguirían la diferencia. Esa distinción es este workbook completo.

Por qué esta alerta está en todas partes

Si tu empresa utiliza Microsoft Entra ID (es posible que aún escuches a la gente llamarlo Azure AD), Okta, Google Workspace o cualquier proveedor de identidad moderno, alguna versión de está detección está activada por defecto o cerca de ello.

Microsoft la presenta a través de Entra ID Protection como la detección de atypical travel risk. Okta la identifica como anomalías basadas en velocidad. La mayoría de los SIEM envían una plantilla de regla para ello. A menudo es una de las primeras cinco alertas que un analista de Nivel 1 totalmente nuevo recibirá.

También es una de las más ruidosas. Dependiendo de qué tan distribuida esté tu fuerza laboral y de cuánto uso de VPN comercial se permitan tus usuarios, he visto colas donde 19 de cada 20 alertas de Impossible Travel se cierran como benignas.

Esa proporción es la trampa. Los analistas se anestesian, comienzan a cerrar alertas en piloto automático y la única cuenta comprometida real pasa desapercibida con una nota de cierre copiada y pegada. Los auditores notan ese patrón, y también lo hacen los revisores de incidentes como yo.

La forma del ataque en el mundo real

Un patrón que he trabajado personalmente: un usuario de finanzas recibió un phishing convincente con temática de factura un martes, ingresó sus credenciales en una página de inicio de sesión proxied, y el atacante se autenticó desde hosting en otra región 22 minutos después.

La alerta de Impossible Travel fue la única señal del primer día. El atacante pasó los siguientes dos días leyendo silenciosamente el buzón y configurando reglas de bandeja de entrada antes de intentar un fraude de pago.

El analista que lo detectó hizo una sola cosa bien que marcó la diferencia: en lugar de cerrar la alerta como otro falso positivo de VPN, revisó qué hizo realmente la nueva sesión después del sign-in. La actividad post-sign-in es donde las cuentas comprometidas se delatan, y martillearemos ese punto a lo largo de este workbook.

El robo de credenciales a gran escala hace que esto sea un problema de estado constante. Los mercados de credenciales robadas venden logins funcionales en bloque, y los ataques de replay de brechas significan que cualquier contraseña que tus usuarios reutilicen en cualquier lugar es efectivamente pública. Trata cada alerta de Impossible Travel como una pregunta en vivo, no como una formalidad.

Cómo funciona la matemática de detección

La detección toma la distancia geográfica entre dos ubicaciones de sign-in, la divide por el tiempo transcurrido entre ellas y compara la velocidad implícita contra un umbral (aproximadamente 900 a 1000 km/h, cerca de la velocidad de un avión comercial, en la mayoría de las implementaciones).

Algunas plataformas añaden machine learning encima para suprimir pares que involucran rangos de VPN conocidos o ubicaciones familiares, que es por lo que dos empresas que corren el mismo stack de identidad pueden ver volúmenes de alertas muy diferentes.

Conocer la matemática importa porque te dice lo que la detección no puede ver: un atacante conectándose desde una ciudad cerca de la del usuario, o un atacante que espera un día, nunca disparará la alerta.

El Impossible Travel atrapa a los atacantes descuidados o rápidos. Es una trampa, no un perímetro.

Dónde se sitúa esto en MITRE ATT&CK

Fase que observas	ID de la técnica	Cómo obtuvieron la credencial
Phishing / Adversary in the Middle	T1566, T1557	Phishing kit o AiTM proxy
El sign-in en sí mismo	T1078.004	Valid Accounts: Cloud Accounts
Variantes de Token replay	T1550.004	Use Alternate Authentication Material: Web Session Cookie
Mailbox staging que encuentras después	T1114.003	Email Collection: Email Forwarding Rule
Nuevo método MFA añadido	T1098.005	Account Manipulation: Device Registration

¿Por qué molestarse con el mapeo?

Porque tus escalaciones y notas de cierre leen diez veces más creíbles cuando hablan el mismo lenguaje que tu equipo de IR y tus ingenieros de detección. También es una forma muy barata de destacar en una entrevista cuando describes una investigación que realizaste.

---

Sección 2 - La alerta llega

Lo que realmente ves en la cola

A continuación se muestra una alerta representativa en el formato que produce Microsoft Sentinel cuando fluye una detección de atypical travel de Entra ID Protection. La cosmética del proveedor varía, los campos no. Aprende los campos y podrás trabajar está alerta en cualquier plataforma.

ALERT: Atypical travel
Severity: Medium
Tactic: Initial Access (TA0001)
Entity: mreyes@contoso.com
First sign-in:  2026-06-09 13:02 UTC   Newark, NJ, US   IP 68.197.44.121
Second sign-in: 2026-06-09 13:47 UTC   Lagos, NG        IP 102.89.33.210
Calculated travel speed: approx 11,400 km/h
Risk state: At risk
Risk level: Medium
Detection source: Entra ID Protection

Leyendo los logs de sign-in

La alerta es un puntero. La evidencia está en los logs de sign-in. Aquí están los dos eventos detrás de esa alerta, recortados a los campos que importan:

Evento 1 (línea base, probablemente el usuario real)

• Time: 13:02 UTC
• User: mreyes@contoso.com
• IP: 68.197.44.121 (Comcast, residencial, Newark NJ)
• App: Outlook desktop
• Client: Windows 11, native client
• Device: CONTOSO-LT-0457 (Entra joined, compliant)
• MFA: Satisfied by token claim
• Result: Success

Evento 2 (el que estás investigando)

• Time: 13:47 UTC
• User: mreyes@contoso.com
• IP: 102.89.33.210 (hosting provider ASN, Lagos NG)
• App: OfficeHome (browser)
• Client: Chrome 126, Windows 10
• Device: Unregistered, not compliant
• MFA: Satisfied by token claim
• Result: Success

Indicadores que vale la pena extraer inmediatamente

Antes de tocar una sola herramienta, el par de logs anterior ya te entrega señales. Entrena tu ojo para detectar estos en la primera lectura:

• Discordancia en el tipo de ASN. El Evento 1 es un ISP residencial. El Evento 2 es un hosting provider ASN. Los humanos reales navegan desde redes residenciales, móviles o corporativas. Los ASNs de hosting detrás de un sign-in de usuario significan VPN en el mejor de los casos y la infraestructura del atacante en el peor.
• Discordancia en el registro de dispositivos. El dispositivo del usuario normal proviene de una laptop cumplida y unida a Entra. La nueva sesión es de un dispositivo no registrado. Un dispositivo no registrado es una bandera amarilla, no una prueba de compromiso.
• MFA satisfied by token claim en ambos. No ocurrió un prompt MFA fresco. Esa frase es consistente con un replayed session token, que es exactamente lo que produce el phishing de adversary in the middle.
• Desviación de Cliente y OS. El usuario vive en el cliente de Outlook desktop en Windows 11. La nueva sesión es basada en navegador en Windows 10. No es condenatorio por sí solo, pero se acumula.

PATRÓN A MEMORIZAR: ISP residencial más dispositivo registrado más cliente familiar en un lado. Hosting ASN más dispositivo no registrado más sesión de navegador en el otro. Cuando los dos sign-ins en un par de Impossible Travel parecen dos estilos de vida diferentes, inclina tu investigación hacía el compromiso.

La misma alerta en un entorno de Okta

Misma idea de detección, cosmética diferente. Si tu organización corre Okta, el evento de velocidad se ve más parecido a esto en el System Log:

eventType: user.session.start
outcome.result: SUCCESS
actor.alternateId: mreyes@contoso.com
client.ipAddress: 102.89.33.210
client.geographicalContext: Lagos, NG
debugContext: behaviors {New Geo-Location=POSITIVE, New Device=POSITIVE, Velocity=POSITIVE, New IP=POSITIVE}
securityContext.asOrg: hostking ltd
securityContext.isProxy: false

Los campos a leer son idénticos en espíritu: el bloque behaviors es tu novedad de dispositivo y ubicación, asOrg es tu verificación de ASN, y isProxy es la bandera de anonimizador propia de Okta.

Cualquiera que sea la plataforma en la que aterrices, tu primer movimiento es encontrar dónde viven estos cinco hechos: IP, ASN, novedad de dispositivo, detalle de MFA y historial de ubicación. La investigación es agnóstica a la plataforma a partir de ahí.

---

Sección 3 - El flujo de trabajo de la investigación

Está es la columna vertebral del workbook. Cinco fases, en orden, cada vez. Omitir una fase es como dejar que las cuentas permanezcan comprometidas después de que el ticket diga resuelto.

Fase 1 - Triage inicial (primeros 5 minutos)

El triage responde a una pregunta: ¿está alerta merece una investigación real en este momento, o puede validarse rápidamente como benigna? Haz esto en orden:

• Extrae ambos eventos de sign-in de tus logs de identidad. Confirma los hechos de la alerta. Las detecciones a veces emparejan sign-ins incorrectamente, así que verifica tú mismo los timestamps, las IPs y las ubicaciones.
• Resuelve ambas IPs: ASN, organización y tipo de conexión (residencial, móvil, hosting, corporativa). Las búsquedas gratuitas están bien. Tu SIEM puede enriquecer esto automáticamente.
• Revisa el historial de sign-ins del usuario durante los últimos 30 días. ¿Ha aparecido este usuario desde la ubicación o ASN marcada antes? Un patrón semanal de la misma VPN anonimizadora se ve muy diferente a un primer sign-in desde un hosting provider.
• Nota el radio de impacto de la cuenta. Un sign-in marcado en una cuenta de administrador de dominio, aprobador de finanzas o asistente ejecutivo cambia tu urgencia incluso antes de confirmar cualquier cosa.

Fase 2 - Validación (¿es el segundo sign-in realmente el usuario?)

• Compara los identificadores de dispositivos. Un dispositivo registrado y cumplido en la sesión sospechosa es una prueba fuerte del usuario real. Un dispositivo no registrado es una bandera amarilla, no una prueba de compromiso.
• Revisa cómo se satisfizo el MFA. Un prompt MFA interactivo recién completado desde el teléfono registrado del usuario es significativo. Los token claims, los protocolos heredados que omiten el MFA o los fallos repetidos de MFA seguidos de un éxito merecen sospecha.
• Mira el user agent a través del baseline del usuario. Los clientes consistentes sugieren al usuario. Un string de cliente totalmente nuevo desde una geografía nueva se opone a la idea del usuario.
• Cuando la señal es ambigua, contacta al usuario fuera de banda. Llama al número en el sistema de RR.HH. o envía un mensaje al gerente del usuario. No envíes correos electrónicos a la cuenta que sospechas que está comprometida, porque si un atacante controla el buzón, estará feliz de confirmar que el viaje fue legítimo.

REGLA FUERA DE BANDA: Preguntar a un buzón posiblemente comprometido si está comprometido es el error de novato más común en la respuesta a compromisos de cuentas. Teléfono, Teams o Slack a un dispositivo verificado, o al gerente del usuario. Nunca el buzón sospechoso.

Fase 3 - Scoping (asume compromiso, mide el daño)

Solo entras en está fase cuando la validación no logra limpiar la sesión. A partir de aquí, trabajas como si la cuenta estuviera bajo el control del atacante hasta que se demuestre lo contrario. Escanea a través de cuatro áreas:

• ¿Qué tocó la sesión? Extrae la actividad del usuario desde el unified audit log o equivalente. Archivos accedidos, correos leídos, búsquedas realizadas, reglas creadas. Los atacantes buscan en los buzones términos como invoice, payment, wire y password en minutos después de entrar.
• Artefactos de persistencia. Nuevas reglas de bandeja de entrada (especialmente aquellas que reenvían externamente o eliminan respuestas), nuevos métodos MFA registrados, concesiones de aplicaciones, delegaciones de buzón y cambios en el correo o teléfono de recuperación. Estos sobreviven a un restablecimiento de contraseña si los pasas por alto.
• Movimiento lateral. ¿La IP o el ASN marcado tocaron otras cuentas? Busca en tus logs de sign-in la IP en toda la organización. Una IP golpeando cinco cuentas es una campaña, no un incidente.
• Privilegios. Mapea a qué puede llegar la cuenta: buzones compartidos, sistemas de finanzas, portales de administración, repositorios de código. Esto impulsa la severidad de la escalación.

Fase 4 - Escalación

Escala cuando cualquiera de estás sea cierta: confirmaste actividad del atacante, la cuenta es privilegiada o adyacente a finanzas, encontraste artefactos de persistencia, o el scoping muestra que más de una cuenta está involucrada.

Tu escalación debe entregar a Nivel 2 o IR un paquete, no un número de ticket. El paquete: la alerta, ambos eventos de sign-in con enriquecimiento, el timeline de actividad que construiste, artefactos encontrados y las acciones que ya tomaste con sus timestamps.

La Sección 7 de este workbook está estructurada para producir exactamente ese paquete.

Fase 5 - Consideraciones de contención

Conoce las reglas de compromiso de tu empresa antes de tocar nada. Donde el Nivel 1 está autorizado, la secuencia estándar de contención para un compromiso de cuenta confirmado es:

• Revoca todas las sesiones y refresh tokens primero. Un restablecimiento de contraseña por sí solo no expulsa una sesión que ya está autenticada.
• Restablece la contraseña y requiere el re-registro de MFA si el atacante añadió un método.
• Elimina la persistencia: borra reglas de bandeja de entrada maliciosas, revoca concesiones de aplicaciones sospechosas, deshace cambios de delegación.
• Bloquea la infraestructura del atacante donde tus herramientas lo permitan, y considera una regla de conditional access si el mismo ASN sigue apareciendo.
• Preserva la evidencia antes de la limpieza donde la política lo requiera. Exporta el slice del audit log y toma capturas de pantalla de las configuraciones de reglas antes de borrarlas.

EL ORDEN IMPORTA: Sesiones primero, luego contraseña. He revisado incidentes donde el analista restableció la contraseña, marcó el ticket como resuelto y el atacante siguió leyendo correos durante dos días más en un token que nunca fue revocado.

El Query Pack - Búsquedas que hacen el trabajo

Estas están escritas en KQL para Microsoft Sentinel y Defender porque es el stack más común en el que los analistas de nivel de entrada aterrizan. La lógica se transfiere directamente a Splunk SPL o cualquier otro lenguaje de consulta: mismos campos, diferentes sintaxis. Cambia los valores de la cuenta y la IP y ejecútalas en orden durante una investigación en vivo.

1. Extrae el baseline de sign-in de 30 días del usuario

SigninLogs
| where TimeGenerated > ago(30d)
| where UserPrincipalName =~ "mreyes@contoso.com"
| summarize Count=count(), FirstSeen=min(TimeGenerated),
            LastSeen=max(TimeGenerated) by IPAddress, Location, AppDisplayName,
            DeviceDetail_s = tostring(DeviceDetail.operatingSystem)
| sort by Count desc

2. Inspecciona el detalle completo del sign-in sospechoso

SigninLogs
| where TimeGenerated between (datetime(2026-06-09 13:40) .. datetime(2026-06-09 13:55))
| where UserPrincipalName =~ "mreyes@contoso.com"
| project TimeGenerated, IPAddress, Location, AppDisplayName,
          ClientAppUsed, DeviceDetail, AuthenticationRequirement,
          AuthenticationDetails, ConditionalAccessStatus, RiskLevelDuringSignIn

3. Busca la IP en toda la organización

SigninLogs
| where TimeGenerated > ago(7d)
| where IPAddress == "102.89.33.210"
| summarize Attempts=count(),
            Success=countif(ResultType == 0),
            Users=make_set(UserPrincipalName)
| extend CampaignFlag = iff(array_length(Users) > 1, "CAMPAIGN", "single")

4. Busca reglas de bandeja de entrada nuevas en la cuenta

OfficeActivity
| where TimeGenerated > ago(3d)
| where UserId =~ "mreyes@contoso.com"
| where Operation in ("New-InboxRule", "Set-InboxRule",
                      "UpdateInboxRules", "Set-Mailbox")
| project TimeGenerated, Operation, Parameters, ClientIP

5. Verifica nuevos métodos MFA y cambios en la información de seguridad

AuditLogs
| where TimeGenerated > ago(3d)
| where OperationName has_any ("security info", "StrongAuthentication",
                               "Register security info")
| where tostring(TargetResources) has "mreyes"
| project TimeGenerated, OperationName, InitiatedBy, Result

Ejecútalas una por una del uno al cinco y habrás cubierto el baseline, la validación, el scoping de campaña y los dos artefactos de persistencia más comunes. Eso es el 80 por ciento de una investigación defendible en cinco queries.

---

Sección 4 - Recopilación de evidencia

Dónde reside la evidencia

Cada afirmación en tu nota de cierre debe rastrearse hasta una línea de log. Estas son las fuentes que espero ver citadas en una investigación de Impossible Travel bien trabajada, en orden aproximado de frecuencia:

Fuente	Qué te proporciona	Plataforma típica
Logs de sign-in	Ambos eventos de sign-in, IP, dispositivo, cliente, detalle de MFA, resultados de conditional access	Entra ID, syslog de Okta, login audit de Google Workspace
Unified audit log	Actividad post-sign-in: acciones de buzón, acceso a archivos, búsquedas, creación de reglas	Microsoft Purview UAL, Google admin audit
Detecciones de riesgo	Otros eventos de riesgo en el mismo usuario: credenciales filtradas, IP anonimizada, propiedades desconocidas	Entra ID Protection, Okta ThreatInsight
Logs de métodos y auth	Registros de nuevos métodos, resultados de prompts, patrones de MFA fatigue	Logs de auth del proveedor de identidad
Logs de email	El phish que lo inició, reglas de reenvío activándose, envíos salientes desde la cuenta	Exchange message trace, secure email gateway
Telemetría de EDR	Si el endpoint del usuario muestra actividad de infostealer que explique el robo de credenciales	Defender for Endpoint, CrowdStrike, SentinelOne
Logs de VPN / red	Si la IP marcada es la salida de tu propia VPN corporativa o un proveedor SASE	Firewall, VPN concentrator, plataforma SASE

Artefactos a capturar sobre la marcha

• Ambos eventos de sign-in exportados en crudo, no capturas de pantalla de dashboards (aunque las capturas ayudan para las reglas de configuración).
• Resultados de enriquecimiento de IP: ASN, organización, tipo de conexión y cualquier hit de threat intelligence.
• El resumen del baseline de sign-in de 30 días del usuario: ubicaciones, dispositivos y clientes habituales.
• Cualquier regla de bandeja de entrada, registro de MFA o concesión de aplicaciones creados cerca del sign-in sospechoso, con timestamps exactos.
• Los resultados de la búsqueda de la IP en toda la organización para otros usuarios.

Preguntas que impulsan la búsqueda de evidencia

Si te detienes a mitad de la investigación, vuelve a está lista. Cada pregunta mapea a una fuente de logs anterior.

• ¿Podrían ambos sign-ins ser la misma persona en una VPN o un proveedor móvil que sale desde muy lejos?
• ¿Ha aparecido este usuario desde este ASN antes, y otros compañeros aparecen de él también?
• ¿Se satisfizo el MFA recién en la sesión sospechosa, o se llevó por un token?
• ¿Qué hizo la sesión sospechosa en sus primeros 30 minutos?
• ¿Cambió algo en la cuenta que sobreviviría a un restablecimiento de contraseña?
• ¿Es está la única cuenta que está IP ha tocado está semana?
• ¿Muestra el endpoint del usuario algún signo de malware infostealer que explique el robo de credenciales?

ESTÁNDAR DE DOCUMENTACIÓN: Escribe tus notas de modo que un tercero auditor que nunca te haya conocido pueda reconstruir la investigación. Cada cierre de falso positivo todavía necesita el rastro de evidencia. Cerrar alertas benignas con notas de una sola palabra es la forma más rápida de terminar en una reunión incómoda después de que la que no era benigna pase desapercibida.

---

Sección 5 - Tomando la decisión

Cada investigación de Impossible Travel termina en uno de tres veredictos. Aquí está lo que cada uno se ve en la evidencia, porque el veredicto debe caer de los hechos, no de tu instinto.

Veredicto 1 - True Positive (Cuenta comprometida)

• El sign-in sospechoso proviene de un ASN de hosting o anonimizador que el usuario nunca ha usado.
• Dispositivo no registrado, cliente desconocido o protocolo heredado en juego.
• La actividad post-sign-in muestra búsquedas de buzón por términos financieros, acceso masivo a archivos o reconocimiento.
• Aparecen artefactos de persistencia: reglas de reenvío, nuevos métodos MFA, concesiones de aplicaciones.
• El usuario confirma fuera de banda que la actividad no fue suya, o no puede ser contactado y la evidencia se acumula.

Veredicto 2 - False Positive (La lógica de detección falló)

• Una de las piernas del par es la salida de tu propia VPN corporativa o un proveedor SASE conocido.
• Enrutamiento de proveedores móviles: tráfico de teléfono saliendo desde un hub de la empresa de telefonía a cientos de millas del usuario. Extremadamente común, y la única fuente de ruido de Impossible Travel.
• VPN comercial que el usuario usa habitualmente, visible como un patrón repetitivo en su baseline de 30 días.
• Las bases de datos de geolocalización de IP simplemente están equivocadas sobre dónde se encuentra una IP, lo que sucede más de lo que los proveedores admiten.

Veredicto 3 - Benign True Positive (Viaje real, usuario real)

• El usuario realmente voló a algún lugar y la matemática de detección simplemente atrapó la brecha entre el aeropuerto y el hotel. El historial de sign-in muestra una secuencia de viaje plausible en lugar de un teletransporte.
• El dispositivo, el cliente y el comportamiento de MFA coinciden con el baseline del usuario. Misma laptop registrada, mismas apps, MFA interactivo fresco satisfecho normalmente.
• El contacto fuera de banda confirma el viaje. Anótalo y ciérralo, pero echa un vistazo a la actividad post-sign-in. Los viajeros en wifi de hotel también son víctimas primas de phishing.

Matriz de decisión

Señal	Se inclina a Compromiso	Se inclina a Benigno
ASN type	Hosting, anonymizer, primera aparición	Residencial, proveedor móvil, VPN corporativa, repeticiones en baseline
Dispositivo	No registrado, no cumplido, hardware nuevo	Registrado, cumplido, coincide con baseline
MFA	Solo token claim, protocolo heredado, nuevo método registrado	Prompt interactivo fresco en método registrado
Post-sign-in	Búsquedas financieras, creación de reglas, acceso masivo, concesiones de aplicaciones	Patrón de trabajo normal que coincide con el historial del usuario
Contacto del usuario	Niega actividad, inalcanzable, o responde solo a través del buzón sospechoso	Confirma viaje o uso de VPN fuera de banda

NINGUNA SEÑAL ÚNICA DECIDE. Pesa el stack. Un dispositivo no registrado por sí solo podría ser el nuevo teléfono de un usuario. Un dispositivo no registrado más un ASN de hosting más una regla de buzón creada cuatro minutos después del sign-in no es una coincidencia, es un veredicto.

Drill - Tres alertas, tú tomas la decisión

Lee cada escenario, decide tu veredicto, luego verifica la respuesta. Estos son compuestos de investigaciones reales y mapean directamente al tipo de preguntas de escenario que hago en las entrevistas de Nivel 1 y Nivel 2.

Escenario A

Ingeniero de ventas, sign-ins desde Chicago a las 08:15 y Ámsterdam a las 09:10. La IP de Ámsterdam resuelve a un proveedor de VPN comercial bien conocido. El baseline de 30 días del usuario muestra el mismo nodo de salida de VPN aproximadamente tres veces por semana, siempre desde la misma laptop registrada, siempre con prompts MFA frescos. La actividad post-sign-in es trabajo normal en CRM.

Veredicto: False Positive. El patrón de VPN repetitivo en el baseline es la clave. Mismo dispositivo, MFA fresco, actividad normal. Ciérralo citando la evidencia del baseline, y considera una solicitud de ajuste para suprimir los pares de VPN conocidos de este usuario.

Escenario B

Coordinador de RR.HH., sign-ins desde Denver a las 14:05 y Denver de nuevo a las 14:20, sin alerta de distancia de viaje en absoluto, pero se disparó una alerta separada de propiedades de sign-in desconocidas junto con un patrón de bajo y lento: cuatro prompts de MFA denegados durante dos horas, luego uno aprobado a las 16:44 desde una IP de proveedor móvil a dos estados de distancia. Post-sign-in, la sesión abrió inmediatamente la configuración de información de seguridad y registró una nueva app de autenticador.

Veredicto: True Positive. Este es MFA fatigue, no Impossible Travel, y ese es el punto del ejercicio. El patrón de prompts denegados seguido por una aprobación tardía y un nuevo registro de MFA inmediato es un compromiso de cuenta independientemente de qué detección lo detectó. Revoca sesiones, restablece, elimina el método no autorizado y verifica qué más tocó la sesión.

Escenario C

CFO, sign-ins desde Boston a las 07:50 y Londres a las 13:10. La IP de Londres es la red de invitados de una cadena de hoteles, clase residencial. El dispositivo es la laptop registrada del CFO, MFA interactivo fresco desde el teléfono registrado. El calendario muestra una reunión de la junta en Londres está semana. Actividad post-sign-in: correo normal, una aprobación de transferencia a un proveedor conocido.

Veredicto: Benign True Positive, con un paso extra. Viaje real, usuario real, y el stack de evidencia está limpio. El paso extra es esa aprobación de transferencia: en una cuenta ejecutiva, verifica que coincida con un pago esperado antes de cerrar. Treinta segundos de paranoia sobre acciones financieras siempre valen la pena. Documenta la confirmación de viaje y cierra.

---

Sección 6 - Recorrido completo de la investigación

Trabajemos la alerta de la Sección 2 de principio a fin, exactamente como yo esperaría que un analista sólido de Nivel 2 la ejecutara. Los tiempos son el tiempo transcurrido en la investigación.

00:00 a 00:05 - Triage

Extrae ambos eventos de sign-in.

• Hechos confirmados: residencial en Newark a las 13:02, ASN de hosting en Lagos a las 13:47.
• Enriquecimiento de IP en 102.89.33.210 devuelve un proveedor de hosting adyacente bulletproof con informes de abuso previos.
• El baseline de 30 días para mreyes muestra Newark y un egreso móvil de Filadelfia, nada más.
• Verificación de cuenta: Maria Reyes, cuentas por pagar.

Cuenta adyacente a finanzas más ASN de hosting significa que está es ahora una investigación prioritaria, no un claro en la cola.

00:05 a 00:15 - Validación

• El dispositivo en la sesión sospechosa no está registrado.
• El cliente es un navegador en Windows 10 contra un baseline de Outlook nativo en Windows 11.
• El MFA muestra satisfied by token claim, sin prompt interactivo.
• Tres de tres contra el usuario.
• Se realizó una llamada fuera de banda al número en el sistema de RR.HH.
• Maria responde desde su escritorio en Newark y no ha salido del estado.

El veredicto es ahora efectivamente un compromiso confirmado. El trabajo restante es el scoping y la contención.

00:15 a 00:40 - Scoping

El unified audit log para la sesión muestra, dentro de los 11 minutos posteriores al sign-in:

• Búsquedas de buzón para wire, invoice y remittance
• 14 correos abiertos en la carpeta de Pagos
• Una regla de bandeja de entrada llamada un carácter de punto que mueve mensajes que contienen invoice a RSS Feeds y los marca como leídos.

Preparación clásica de BEC.

• La búsqueda de IP en toda la organización encuentra que la misma dirección tuvo sign-ins fallidos contra dos otros usuarios de finanzas a las 13:31 y 13:39.
• El log de registro de MFA muestra un intento, no completado, de añadir un nuevo autenticador a las 13:58.
• Se capturaron capturas de pantalla y exportaciones de logs antes de cualquier limpieza.

00:40 a 00:50 - Escalación y Contención

Escalado a IR con el paquete completo: timeline, artefactos, cuentas afectadas.

• Con aprobación, se revocaron sesiones y refresh tokens a las 00:42 transcurridos.
• Restablecimiento de contraseña.
• La regla de bandeja de entrada se eliminó después de la exportación.
• El ASN de hosting se añadió a un bloque de conditional access.
• Los dos compañeros de trabajo objetivo reciben revocaciones proactivas de sesión y un aviso.
• La laptop de Maria recibe un escaneo de EDR para descartar un stealer local, que resulta limpio, consistente con la teoría de replay de token.

Causa raíz y cierre

El message trace encuentra un phish con temática de DocuSign entregado a las 12:38 que Maria hizo clic a las 12:55, siete minutos antes de su sign-in legítimo. El enlace resolvió a una página de inicio de sesión proxied, lo que explica el token robado y el MFA satisfied by token claim.

La nota de cierre documenta la cadena completa: phish, robo de token, detección de Impossible Travel, preparación de buzón, contención. Se envió feedback de detección: la alerta funcionó, y se envía una nueva solicitud de detección para reglas de buzón llamadas con caracteres únicos.

LO QUE HIZO BUENA Está INVESTIGACIÓN: El analista nunca confió en una sola señal, contactó al usuario fuera de banda, realizó el scoping antes de contener, preservó la evidencia antes de eliminar nada y revocó las sesiones antes de restablecer la contraseña. Estos son los hábitos que pregunto en las entrevistas.

---

Sección 7 - Notas del analista

Imprímelas o recréalas en tu herramienta de tickets. Complétalas durante tu próxima investigación real de Impossible Travel. La estructura a continuación es el paquete de escalación de la Sección 3, fase 4.

Checklist de Triage (ejecuta antes que cualquier otra cosa)

• Ambos eventos de sign-in extraídos de logs en crudo y hechos verificados
• Ambas IPs enriquecidas: tipo de ASN, organización, tipo de conexión anotados
• Baseline de 30 días revisado: ¿ASN marcado visto antes? S / N
• Privilegios de cuenta verificados: admin / finanzas / ejecutivo / estándar
• Detalle de MFA revisado: prompt interactivo o token claim
• Estado de registro de dispositivo en la sesión sospechosa anotado
• Actividad post-sign-in revisada para los primeros 30 minutos
• Usuario contactado fuera de banda (nunca a través del buzón sospechoso)
• Búsqueda de IP en toda la organización ejecutada en otras cuentas
• Cacería de persistencia: reglas de buzón / métodos MFA / concesiones / delegaciones

CONSEJO DE DOCUMENTACIÓN: Escribe tus notas de modo que un tercero auditor que nunca te haya conocido pueda reconstruir la investigación. Cada cierre de falso positivo todavía necesita el rastro de evidencia. Cerrar alertas benignas con notas de una sola palabra es la forma más rápida de terminar en una reunión incómoda después de que la que no era benigna pase desapercibida. Revisores verifican.

Investigación 1

Campo	Valor
Encabezado de investigación	Alert ID: ____________ Fecha/hora de apertura: ____________
Cuenta	____________
Notas de privilegios de cuenta	____________
Par de sign-in	Ubicación / IP / ASN / dispositivo / MFA

Hallazgos

Campo	Valor
Timeline de eventos (UTC)
Indicadores observados	IPs / dominios / hashes / cuentas
Causa raíz
Acciones tomadas	Con timestamps
Recomendaciones y feedback de detección

Investigación 2

Campo	Valor
Encabezado de investigación	Alert ID: ____________ Fecha/hora de apertura: ____________
Cuenta	____________
Notas de privilegios de cuenta	____________
Par de sign-in	Ubicación / IP / ASN / dispositivo / MFA

Hallazgos

Campo	Valor
Timeline de eventos (UTC)
Indicadores observados	IPs / dominios / hashes / cuentas
Causa raíz
Acciones tomadas	Con timestamps
Recomendaciones y feedback de detección

Glosario - Términos que encontrarás en el turno

Término	Definición
ASN	Autonomous System Number. Identifica la red a la que pertenece una IP. La forma más rápida de distinguir el tráfico residencial de la infraestructura de hosting.
AiTM	Adversary in the middle. Técnica de phishing que proxie la página de inicio de sesión real, capturando tanto la contraseña como el session token, derrotando a la mayoría del MFA.
Token claim	Un sign-in satisfecho por un token existente en lugar de un prompt MFA interactivo reciente. Normal para el usuario real, pero también lo es para los tokens replayed robados.
UAL	Unified audit log. El registro de Microsoft 365 de la actividad post-sign-in: acciones de buzón, acceso a archivos, búsquedas, cambios de reglas. Tu mina de oro de scoping.
Conditional access	Motor de políticas que permite o bloquea sign-ins basados en condiciones como ubicación, cumplimiento de dispositivos, y riesgo. También es tu palanca de contención.
Infostealer	Familia de malware que cosecha credenciales guardadas y cookies de sesión de máquinas infectadas, y luego las vende en lote.
BEC	Business email compromise. El objetivo final de la mayoría de los compromisos de cuentas es el fraude de pago ejecutado desde un buzón de confianza.
Inbox rule persistence	El atacante creó reglas para ocultar, reenviar o eliminar correos para que la víctima nunca vea el fraude en progreso. Sobrevive a un restablecimiento de contraseña si no se elimina.
MFA fatigue	Spam de prompts de push hasta que un usuario cansado apruebe uno. Alerta diferente, mismos músculos de investigación.
Out of band	Contactar a un usuario a través de cualquier canal que no sea la cuenta bajo investigación. No negociable en el trabajo de compromiso de cuentas.
Bulletproof hosting	Proveedores que ignoran las quejas de abuso, populares entre los atacantes. Un ASN con informes de abuso previos es una señal fuerte de compromiso.
Session revocation	Invalidar todos los tokens activos para una cuenta. Siempre antes del restablecimiento de la contraseña, nunca en lugar de él.
EDR	Endpoint Detection and Response. Herramientas que proporcionan telemetría sobre procesos y archivos en el dispositivo final.

---

Sección 8 - Referencia rápida

La versión de una sola página. Manténla abierta en el turno.

Primeros cinco minutos

• Verifica ambos sign-ins en los logs en crudo. Enriquece ambas IPs: el tipo de ASN es tu señal más rápida.
• Extrae el baseline de 30 días. Un ASN repetitivo es un patrón probable de VPN. Un hosting ASN por primera vez significa investigar.
• Verifica los privilegios de la cuenta. Las cuentas de finanzas, ejecutivos y administradores saltan la cola.

Decidiendo

• Stack de Compromiso: ASN de hosting, dispositivo no registrado, solo token claim de MFA, búsquedas financieras en el buzón, reglas de buzón nuevas, nuevos métodos MFA.
• Stack Benigno: Salida de VPN corporativa, enrutamiento de proveedores móviles, dispositivo registrado, MFA interactivo fresco, actividad normal.
• Ambiguo: contacta al usuario fuera de banda. Nunca a través del buzón sospechoso.

SI ESTÁ COMPROMETIDO: Revoca sesiones y tokens PRIMERO, luego restablece la contraseña. Caza la persistencia: reglas de buzón, reenvíos, registros de MFA, concesiones de aplicaciones. Busca la IP en toda la organización. Una IP, muchas cuentas significa campaña. Preserva la evidencia antes de la limpieza. Exporta logs, toma capturas de reglas. Escala con un paquete: timeline, artefactos, acciones tomadas.

SIEMPRE: Documenta cada veredicto, incluyendo falsos positivos, con un estándar listo para un auditor. Echa un vistazo a la actividad post-sign-in incluso en alertas que cierres como viaje imposible benigno.

---

Bonus - Cómo aparece esto en tu entrevista

Realizo entrevistas técnicas para roles de analista e ingeniería, e Impossible Travel es uno de mis temas favoritos porque pone a prueba el juicio, no la memorización.

Preguntas de la entrevista

Aquí están cinco preguntas en el formato exacto que pregunto, con lo que una respuesta fuerte debe cubrir. Cada respuesta es una sección de este workbook dicha en voz alta.

Pregunta 1: Se dispara una alerta de Impossible Travel en un usuario. Explícame tus primeros diez minutos.

Las respuestas fuertes verifican los sign-ins en crudo, enriquecen ambas IPs con énfasis en el tipo de ASN, extraen el baseline de 30 días, y verifican los privilegios de la cuenta antes de decidir qué tan profundo investigar. Las respuestas débiles saltan directamente a restablecer la contraseña.

Pregunta 2: ¿Cuáles son las explicaciones benignas para está alerta?

Salida de VPN corporativa, hábitos de VPN comercial visibles en el baseline, enrutamiento de proveedores móviles, error de base de datos de geolocalización, y viaje real. Nombrar el enrutamiento de proveedores móviles específicamente me dice que has trabajado en colas reales, porque es la fuente más ruidosa y casi nadie que estudia material genérico lo menciona.

Pregunta 3: El usuario dice que fue él. ¿Cómo lo verificas?

Contacta fuera de banda en un número conocido bueno. Si la confirmación llegó a través del buzón que sospechas que está comprometido, no vale nada. Puntos extra por decir que aun así echarías un vistazo a la actividad post-sign-in antes de cerrar.

Pregunta 4: Confirmas el compromiso. ¿Qué haces primero y por qué ese orden?

Revoca sesiones y refresh tokens antes del restablecimiento de la contraseña, luego caza la persistencia, luego preserva la evidencia antes de la limpieza. Los candidatos que explican por qué el restablecimiento de contraseña por sí solo falla (los tokens activos sobreviven) se separan inmediatamente.

Pregunta 5: ¿Cómo reducirías el ruido de está detección?

Las sugerencias de ajuste muestran un pensamiento de Nivel 2: suprimir pares de salida de VPN corporativa conocidos, construir baselines de VPN a nivel de usuario, aumentar la severidad cuando el ASN es de clase hosting o el dispositivo no está registrado, y emparejar la detección con Análisis de comportamiento post-sign-in. Estás demostrando que piensas en la detección, no solo en el ticket.

Ese es el workbook, amigos. Trabaja las próximas diez de estás alertas con está estructura y la número once se sentirá automática. Otros volúmenes en está serie cubren las otras alertas que vivirás en el turno.