Build a Microsoft Sentinel Project: Detect Impossible Travel
A free, cloud-based build guide — no local VM, no software install. By the end, you’ll have a real detection rule and a workbook to show for it.
What you’ll build
This project detects “impossible travel” — a sign-in pattern where the same account logs in from two locations too far apart to be a real person traveling between them. It’s one of the most common cloud-security detections a SOC analyst works with, because it’s a strong early signal of a compromised account rather than a brute-force attempt in progress.
Microsoft’s own Sentinel documentation maps this exact scenario to MITRE ATT&CK Technique T1078 (Valid Accounts) — a genuinely different technique category from the Splunk project’s brute-force detection. Building both gives your portfolio real variety instead of two versions of the same skill.
Setup: get Sentinel running
Everything here runs in a browser — no local install, no VM.
What it actually costs: Sign up for an Azure free account, which includes credit and free service tiers. Per Microsoft’s own Sentinel documentation, the first 10 GB/day of data ingestion and Sentinel analysis charges are free for 31 days after you enable it on a Log Analytics workspace — enough for a portfolio project with room to spare.
You don’t need a company tenant with real sign-in history. If you’re working from a personal Azure account with no sign-in data yet, Sentinel’s sample data (available from the same onboarding flow) is enough to practice the detection logic below.
Protect yourself from surprise charges: Before building anything, set a budget alert in Azure (Cost Management + Billing → Budgets) for a low threshold like $5. This emails you automatically if usage starts climbing — a five-minute step that removes the actual risk of an unexpected bill, rather than just hoping the free tier covers everything.
Step-by-step build
Enable Sentinel on a Log Analytics workspace
From the Azure Portal, create a new Log Analytics workspace, then enable Microsoft Sentinel on top of it — Microsoft’s onboarding flow walks through both steps together the first time.
Connect a sign-in data source
Connect the Microsoft Entra ID data connector to bring in sign-in logs, or load Sentinel’s sample dataset if you don’t have real sign-in history to work with.
Write the detection query in KQL
This simplified version compares each user’s consecutive sign-ins and flags any pair from different cities within a short time window:
SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType == 0
| project UserPrincipalName, IPAddress, City = tostring(LocationDetails.city), TimeGenerated
| sort by UserPrincipalName, TimeGenerated asc
| serialize
| extend PrevCity = prev(City), PrevUser = prev(UserPrincipalName), PrevTime = prev(TimeGenerated)
| where UserPrincipalName == PrevUser and City != PrevCity
| extend MinutesBetween = datetime_diff('minute', TimeGenerated, PrevTime)
| where MinutesBetween < 60
// Flags a city change within 60 minutes for the same user — a simplified
// stand-in for full geo-distance/speed calculation, which Sentinel's
// built-in "Impossible travel" analytics rule template handles more
// rigorously. This version is for learning the underlying logic.
Adjust the 60-minute window based on what your data actually shows — the goal is understanding why a rapid city change is suspicious, not matching an exact production threshold.
Save it as a scheduled analytics rule
In Sentinel, go to Analytics → Create → Scheduled query rule. Set it to run hourly, tag it with MITRE ATT&CK technique T1078 (Valid Accounts) in the rule’s MITRE mapping field, and define a trigger condition of “results greater than 0.”
Build a workbook visualization
Create a Sentinel Workbook with a table or map visual showing flagged sign-ins by user, city, and time gap — this is what turns the raw query into something reviewable at a glance.
Capture your results
Screenshot the analytics rule configuration and the workbook. Note the specific detection details — which cities, how many minutes apart — rather than describing it generically.
Document the project
Turn this into a README a recruiter can actually skim in 30 seconds.
Get the README Template →Write it up like a real incident
Document the detection the way a real SOC analyst writes up a case.
Get the Incident Report Template →What this proves to an employer
This project demonstrates a distinctly different skill set from the Splunk brute-force project — cloud identity security, not on-prem log analysis:
Frequently asked questions
Do I need a real company’s Azure tenant to do this?
No — an Azure free account gives you your own tenant with $200 in credit, which is enough for this project. You can also use Sentinel’s built-in sample data if you don’t have sign-in history to work with yet.
Is Microsoft Sentinel actually free to use?
The first 10 GB per day of data ingestion and Sentinel analysis charges are free for 31 days after you enable it, per Microsoft’s own pricing documentation. That’s enough headroom for a portfolio project — just be aware charges can apply after the trial period or beyond that daily limit.
How is this different from the Splunk project?
The Splunk project detects a brute-force attack (repeated failed logins). This project detects valid-account misuse (a successful login used in a suspicious way) — a genuinely different detection skill, which is exactly the kind of variety a strong portfolio needs.
What if I forget about this and get charged later?
Set the budget alert described in the Setup section before you start — it’s the actual safeguard, not just remembering to check. If you want to be extra cautious, you can also delete the resource group when you’re done with the project, which removes everything in it at once.
Documented this one too? You’ve now got real variety.
A brute-force detection and an identity-misuse detection cover two genuinely different skill areas — exactly what a strong portfolio needs.
Back to the Portfolio Hub →