An AiTM phishing email delivered at 09:45 followed by a sign-in from a new IP at 10:23 and an inbox rule creation at 10:31 is an attack chain — but only if you can prove the temporal proximity. Time window correlation joins events from different tables within a defined time window, establishing that events are related by timing rather than just by entity. This is the pattern that turns three separate events into one attack narrative.
Deliverable: Production-ready KQL patterns for temporal proximity joins — correlating events across tables within specified time windows.
⏱ Estimated completion: 25 minutes
Timing is the correlation
Two events share the same user. That proves they happened to the same person. Two events that share the same user and occur within 30 minutes of each other prove they are likely part of the same session. Two events that share the same user, occur within 30 minutes, and represent logically sequential steps in an attack chain (phishing → sign-in → persistence) prove the attack chain.
Time window correlation is the KQL pattern that establishes temporal proximity.
The between clause enforces temporal ordering: the sign-in must occur after the phishing email and within the specified window. Without temporal ordering, the join would also match sign-ins that happened before the email — which are not causally related.
Figure TH2.12 — Three temporal correlation patterns. Each establishes a different type of relationship between events.
Try it yourself
Exercise: Run the phishing → sign-in correlation
Run Pattern 1 against your environment. How many users had a phishing email delivered followed by a risky sign-in within 48 hours? Even zero results is informative — it means no confirmed AiTM chain in the last 7 days. If results appear, they are high-priority investigation targets.
⚠ Compliance Myth: "Temporal correlation proves causation — if two events are close in time, one caused the other"
The myth: If a phishing email and a risky sign-in happen within 48 hours, the phishing email caused the compromise.
The reality: Temporal proximity is a strong indicator, not proof. The phishing email may be unrelated to the sign-in — the user may have been compromised through a different vector (credential stuffing, access broker, another phishing email not detected as malicious). Temporal correlation elevates the result from an indicator to a high-priority lead. Confirmation requires the additional enrichment dimensions from TH1.4 — particularly the behavioral dimension (what did the session do after the sign-in?) and the geographic dimension (does the sign-in IP match the phishing infrastructure?).
Extend this approach
The `between` clause in KQL enforces a time window. For strict ordering (A before B), use `B.Time between (A.Time .. (A.Time + window))`. For proximity without ordering, use `abs(datetime_diff('minute', A.Time, B.Time)) < threshold`. Campaign modules specify which pattern is appropriate for each technique — AiTM requires ordering (phish before sign-in), shared infrastructure does not.
The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.