Unir dos tablas — join para correlacionar

Cada fuente del SIEM responde una parte de la pregunta. El proveedor de identidad sabe desde dónde entró una cuenta, pero no qué hizo después. La auditoría de buzones sabe qué cambió en un buzón, pero muchas veces no guarda desde qué dirección. join junta las dos: para cada fila de la tabla de la izquierda busca las filas de la derecha que tienen el mismo valor en la columna que indicas detrás de on, y devuelve las parejas.

inicios
| where resultado == "correcto" and ip_origen == "198.51.100.23"
| join kind=inner (buzones) on cuenta

Dos costumbres hacen que un join sea legible y rápido. Se filtra antes de unir, para que la tabla de la izquierda llegue pequeña: unir la noche entera de inicios con todos los buzones produce miles de parejas que nadie va a leer. Y la tabla de la derecha va entre paréntesis, porque puede ser una consulta entera con sus propios filtros.

kind decide qué filas sobreviven. inner deja solo las que encuentran pareja en los dos lados: sesiones que tienen eventos de buzón. leftouter deja todas las de la izquierda, tengan pareja o no, y rellena con vacíos lo que falta: sirve cuando también te interesa la sesión que no hizo nada. leftanti deja las de la izquierda que no tienen pareja: «cuentas que iniciaron sesión desde otro país y no están en la lista de personas de viaje», «equipos del inventario que no mandaron ningún evento hoy».

Si no escribes kind, KQL no usa inner: usa una variante que se queda con una sola fila por cada valor de la izquierda antes de unir. Con una sesión por cuenta no se nota; con varias sesiones de la misma cuenta, algunas desaparecen del resultado sin ningún aviso. Por eso en una consulta de investigación el tipo se escribe siempre, aunque sea el que querías.

Unir por la cuenta trae todo lo que esa cuenta hizo en la tabla de la derecha, también lo de ayer y lo de la semana pasada. Si la sesión sospechosa es de las 03:41 y la cuenta mandó un correo normal la tarde anterior, el join devuelve los dos eventos de buzón pegados a la misma sesión, y un vistazo rápido los mezcla en la misma historia. La condición que falta es de tiempo: después del join, where hora1 > hora deja solo lo que pasó después de entrar.

Ese hora1 no es un error. Cuando las dos tablas tienen una columna con el mismo nombre, el resultado conserva las dos y a la de la derecha le añade un 1 al final: hora es la del inicio de sesión y hora1 la del evento de buzón; cuenta y cuenta1, lo mismo. Al terminar, un project con las columnas que cuentan la historia deja el resultado listo para el reporte.

La sesión correcta desde la dirección del rociado abrió el correo web de una cuenta de Delta Cargo de madrugada. Une esa sesión con la auditoría de buzones, quédate con lo que pasó después de entrar y lee la regla que se creó.