Skip to main content
Tier One
High

Impossible travel: Chicago then Singapore in 22 minutes

A-1047

00:00time on this alert, target 10 minutes

Back to queue

Alert details

Source
Cloud Audit Log
Detection rule
CLOUD-IDENT-TRAVEL-004
Affected user
dtanaka
Affected host
LAPTOP-DTANAKA
Source IP
103.114.161.7
First seen
2026-07-24T14:18:00Z

Why this fired, in plain English

The same account signed in from two places too far apart for anyone to physically travel between in the time available.

Suggested playbook

Impossible travel / anomalous sign-in

  1. 1. Compare device IDs and user agents between the two sign-ins.
  2. 2. Check the VPN logs — corporate VPN egress is the single most common cause of false positives.
  3. 3. Check the IP owner: corporate egress, consumer ISP, hosting provider, or anonymizer?
  4. 4. Check MFA state on each sign-in.
Open the full checklist

Raw log evidence

Exactly what the tools recorded — 4 events.

  1. ts=2026-07-24T13:56:04Z src="cloud_audit" event=UserLoggedIn user="dtanaka@northwind-mfg.example" src_ip=98.207.44.12 geo="Chicago, US" device_id="D-77120" mfa=satisfied user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64)"

    A normal sign-in from the user's usual city, on their known laptop.

  2. Guided hint: this line matters

    ts=2026-07-24T14:18:12Z src="cloud_audit" event=UserLoggedIn user="dtanaka@northwind-mfg.example" src_ip=103.114.161.7 geo="Singapore, SG" device_id="unknown" mfa=not_required user_agent="python-requests/2.31.0"

    python-requests is a scripting library, not a browser. Real people do not sign in with it.

  3. Guided hint: this line matters

    ts=2026-07-24T14:18:44Z src="cloud_audit" event=New-InboxRule user="dtanaka@northwind-mfg.example" params="Name=..;MoveToFolder=RSS Feeds;SubjectContainsWords=invoice,payment,wire;MarkAsRead=true"

    A hidden mail rule that files anything about invoices or wires into an unused folder — a hallmark of business email compromise.

  4. Guided hint: this line matters

    ts=2026-07-24T14:19:03Z src="cloud_audit" event=MailItemsAccessed user="dtanaka@northwind-mfg.example" src_ip=103.114.161.7 item_count=284 folder="Inbox"

Related events

The order things happened in.

  1. 13:56Z

    Legitimate Chicago sign-in

  2. 14:18Z

    Singapore sign-in via python-requests

  3. 14:18Z

    Hidden inbox rule created

  4. 14:19Z

    284 mail items accessed

Enrichment lookups

Mock lookups. Run each one yourself — a real analyst never guesses what a lookup would have said. There is no "run everything" button on purpose.

0 of 4 lookups checked

  • Not checked yet.

  • Not checked yet.

  • Not checked yet.

  • Not checked yet.

Part of incident INC-2201

Account takeover of dtanaka — Singapore VPN

Three separate alerts fired across the shift. On their own each looks survivable. Together they are one intrusion: stolen password, MFA bypassed, mailbox looted, then cloud persistence.

What links them: Source IP 103.114.161.7 and the user dtanaka appear in all three.

  1. 1 · Credential access

    Correct password from Singapore, 11 MFA pushes denied. The password was already stolen.

    Open A-1071
  2. 2 · Impossible travel & collection

    Same IP finally signs in without MFA, creates a hidden inbox rule and reads 284 messages.

    A-1047 — you are here
  3. 3 · Cloud persistence

    Same IP creates a long-lived access key on an admin service principal — access that survives a password reset.

    Open A-1061

Tier 1 work is not just judging one alert. When the same user, host or IP shows up twice in a shift, link the tickets — the severity of the chain is always higher than the severity of its parts.

techniques

Your verdict

Keyboard shortcuts 1–4, or click. You can always change your mind afterwards.