Skip to content
English
Contact us
  • There are no suggestions because the search field is empty.

Investigating a Microsoft 365 AiTM Detection

In Attic, we offer features to detect and mitigate Adversary-in-the-Middle (AiTM) attacks on your Microsoft tenant. This article describes how to follow up on a detection.

Information Available

Whenever a detection occurs, we provide the following information about the attack:

  • AiTM Phishing website URL

  • IP address of the victim

  • Date/time of detection (UTC)

Using Web Browsing Logs to Identify the Victim

The most effective way to discover who was a victim and whether the attack was successful is to use your web browsing logs.

Step 1: Broadening the Search with UrlClickEvents

Before looking at network connections, check if the user interacted with the link via Outlook or Teams. Microsoft Defender for Office 365 logs these in the UrlClickEvents table. This captures the click even if the final network connection was blocked.

Go to Advanced Hunting in your Microsoft Defender dashboard and run: 

UrlClickEvents
| where Url contains "akxrnh.com" // Replace with the phishing domain
| project Timestamp, DeviceName, AccountUpn, Url, ActionType

Look for ActionType values like ClickAllowed or IsClickedThrough.

Step 2: Identifying the Device with DeviceNetworkEvents

If you have Defender for Endpoint, search for the specific device that connected to the phishing domain: 

DeviceNetworkEvents
| where RemoteUrl contains "akxrnh.com" // Replace with the phishing domain

Check the DeviceName and InitiatingProcessAccountUpn fields to identify the targeted employee.

Checking Identity Protection & Sign-in Logs

If web logs are unavailable or inconclusive, you must check for signs of a hijacked session.

Step 3: Search for Identity Protection Alerts

AiTM attacks often trigger specific "Risk Detections" because the attacker is replaying a stolen session token from a different location. Open the Microsoft Entra Admin Center and go to Protection > Identity Protection > Risk detections. Look for:

  • Anomalous Token: The primary indicator that a session cookie was stolen and used on a different machine.

  • Unfamiliar sign-in properties: Triggered when the attacker uses a browser or device fingerprint that doesn't match the user's history.

  • Atypical Travel: If a user "moves" between countries faster than a plane could fly.

Step 4: Review Sign-in Logs

Search your Microsoft Entra ID Sign-in logs.

  1. Filter by the victim IP shared in the Attic detection.

  2. Look for "Success" from uncommon countries. If you see a successful login from a region where you have no employees, the attack was likely successful.

Why You Might Not Find the Event

It is common to receive a detection but find no matching logs in your environment. This typically happens because:

  • Unmanaged Devices: If the employee clicked the link on a personal phone or home computer not enrolled in Defender, no DeviceNetworkEvents will exist.

  • Proxy Networks: Sophisticated criminals use residential proxy networks. The IP address used to visit the phishing site (which Attic sees) might not match the IP address they use to sign into Entra ID, hiding the correlation.

The Golden Rule: If you see "Successful" sign-ins from "weird" countries or strange ISP providers (like digital cloud hosting) around the time of the detection, treat it as a compromise even if you can't find the original URL click.