PT2.1 Phishing: Spearphishing Link (T1566.002)

1. Scene

It's 09:14 on a Wednesday. A finance analyst at Northgate Engineering receives an email that appears to come from the company's document management portal. The subject line reads "Shared Document: Q4 Budget Review. Action Required." The email contains a single link labelled "Open Document." The link points to a page that's visually identical to the Microsoft 365 login page, hosted on a domain registered three days ago.

The analyst clicks. They enter their credentials. The page thanks them and redirects to the real SharePoint site. From the analyst's perspective, nothing went wrong, they logged in and the document didn't load, probably a broken link.

From the attacker's perspective, they now have the analyst's username, password, and, if the phishing page was an AiTM proxy: the session cookie that bypasses MFA. The attacker authenticates to M365 within ninety seconds using the stolen credentials. Defender for Office 365 logged the URL click. Entra ID logged the sign-in from a new device and an unfamiliar IP. The sign-in logs show two authentications within two minutes from two different countries. But does any rule fire?

2. Learning Objectives

By the end of this sub you will be able to:

• Execute a simulated spearphishing link attack against your M365 dev tenant and observe the telemetry it produces in Entra sign-in logs, Defender for Office 365, and your secondary SIEM
• Identify the specific sign-in log fields that distinguish a phished credential login from a legitimate login
• Write and tune a Sigma rule that detects credential phishing through sign-in anomaly correlation without producing excessive false positives from legitimate travel and VPN use

3. The Technique

T1566.002. Phishing: Spearphishing Link

The attacker sends a targeted email containing a URL that directs the victim to a credential-harvesting page, a malware download, or an exploitation framework. T1566.002 is the link-based variant of T1566 (Phishing). The parent technique has three sub-techniques: spearphishing attachment (.001), spearphishing link (.002), and spearphishing via service (.003).

Why spearphishing links dominate M365 attacks

Spearphishing links are the most common initial access vector in enterprise M365 environments for three reasons:

No attachment to scan. The email contains only a URL: no malicious file for Defender for Office 365 to detonate in a sandbox. The malicious content lives on the attacker's infrastructure, not in the email. Safe Links evaluates the URL at click time, but the attacker controls what the URL serves and when.

AiTM proxy bypasses MFA. The most dangerous link-based attack isn't a simple fake login page, it's an Adversary-in-the-Middle (AiTM) proxy. The attacker runs a reverse proxy (Evilginx, EvilProxy, Modlishka) that sits between the user and the real Microsoft login page. The user sees the real Microsoft login form, because it IS the real form, proxied through the attacker's server. The user enters their password. Microsoft sends the MFA challenge. The user completes MFA. Microsoft issues a session cookie. The proxy captures the cookie in transit. The attacker now has a fully authenticated session token. MFA completed, Conditional Access satisfied.

The link looks legitimate. AiTM proxy domains often use lookalike URLs: login.microsoftonIine.com (capital I instead of lowercase L), portal.office365-review.com, sharepoint-external.northgateeng-uk.com. URL reputation services haven't seen the domain before (it was registered 48 hours ago), so they can't flag it as malicious at the moment of the click.

How an AiTM proxy works: the protocol level

Understanding the proxy mechanics explains why MFA doesn't help and why the detection signal is in the post-click sign-in logs, not in the email:

AiTM Proxy Flow. What Happens During a Phishing Link Click
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Step 1: User clicks phishing link
        → Browser navigates to attacker's proxy server
        → Proxy forwards the request to login.microsoftonline.com

Step 2: Microsoft login page loads, through the proxy
        → User sees the REAL Microsoft login form
        → The proxy passes every pixel through unchanged
        → The URL bar shows the attacker's domain, not Microsoft's
           (this is the only visible indicator, and users don't check)

Step 3: User enters username + password
        → Browser sends credentials to the proxy
        → Proxy forwards credentials to Microsoft
        → Microsoft validates the password, correct
        → Proxy captures the password in transit ← CREDENTIAL STOLEN

Step 4: Microsoft sends MFA challenge
        → Challenge passes through the proxy unchanged
        → User sees the Authenticator push / SMS code / FIDO prompt
        → User completes MFA on their real device

Step 5: Microsoft issues session cookie
        → Cookie passes through the proxy to the user's browser
        → Proxy captures the session cookie in transit ← TOKEN STOLEN
        → User's browser receives the cookie and loads M365
        → From the user's perspective: successful login, nothing unusual

Step 6: Attacker replays the session cookie (seconds to hours later)
        → Attacker injects the cookie into their own browser
        → Microsoft sees a valid session. MFA already completed
        → No new MFA prompt: the cookie carries the MFA claim
        → Conditional Access evaluates: registered device? No.
           But the token has the MFA claim, so policies that require
           "MFA" are satisfied. Policies that require "compliant device"
           or "Entra-joined device" may block, if configured.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Detection window: between Step 6 (attacker replays) and whenever
the session is revoked. Median: 1–15 minutes from credential theft
to first attacker action. The email is not the detection signal.
The post-click sign-in anomaly is.

What the attacker does with the stolen session

The session cookie gives the attacker full access to the user's M365 environment, as if they were the user. Typical post-access actions within the first 5 minutes:

Attacker's Post-AiTM Playbook (first 5 minutes)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
00:00  Inject session cookie into browser/tool
00:30  Read the user's mailbox, search for "password", "VPN",
       "credentials", "bank", "wire transfer"
01:00  Create an inbox forwarding rule: all incoming mail
       forwarded to attacker's external address (T1114.003)
       This persists even after the session is revoked.
02:00  Search OneDrive/SharePoint, download sensitive documents
       (contracts, financials, customer data)
03:00  Access the GAL (Global Address List), identify high-value
       targets for the next phishing wave (CEO, CFO, IT admins)
04:00  Send phishing emails FROM the compromised account to
       internal users — "internal spearphishing" (T1534)
       These bypass external email filtering entirely.
05:00  If the user has admin privileges: access Entra ID,
       create a new service principal, or register a device
       for persistent access
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The inbox forwarding rule is the most dangerous post-action
because it persists after password reset and session revocation.
If you respond to a T1566.002 compromise, check forwarding
rules FIRST.

Why Safe Links can't catch AiTM

Microsoft Safe Links evaluates URLs at click time, it follows the URL, checks the destination for known malicious patterns, and blocks if the page matches known phishing signatures. AiTM proxies evade this because:

• The proxy domain is new (registered 24–72 hours ago): no reputation data
• The proxy serves the real Microsoft login page: the content looks legitimate
• Safe Links follows the URL to the proxy, which returns the proxied Microsoft content. Safe Links sees a "login page" which is technically correct
• The proxy may detect Safe Links' User-Agent and serve clean content to the scanner while serving the phishing page to real browsers

4. Safety and Legal

5. The Attack

Spearphishing link attacks have two phases: the delivery (the email) and the harvest (the credential capture + replay). In a real attack, the attacker prepares infrastructure first: a proxy server, a lookalike domain, a phishing template. In the lab, you simulate the effect without building full AiTM infrastructure (the capstone in Module 14 uses Evilginx for the complete chain).

What the attacker's infrastructure looks like

Before the phishing email is sent, the attacker has:

Attacker Infrastructure. AiTM Phishing Setup
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. A VPS (cloud server) running Evilginx, EvilProxy, or Modlishka
   - Cost: $5–20/month from any cloud provider
   - Location: often in the target's country (to avoid geo-blocking)

2. A lookalike domain registered 24–72 hours ago
   - Example: login-microsoftonline.northgateeng-review.com
   - Registered via a domain registrar that doesn't verify identity
   - SSL certificate: Let's Encrypt (free, automated)
   - DNS: Cloudflare or similar CDN (hides the real server IP)

3. A phishing template matching the target organization
   - SharePoint document sharing notification
   - HR benefits update
   - IT password reset notification
   - Spoofed sender: sharepoint@northgateeng.com (display name)
   - Reply-to: legitimate-looking address

4. An exfiltration channel for captured credentials/tokens
   - Telegram bot, webhook, or database on the VPS
   - Real-time notification when a credential is captured
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Total setup time: 2–4 hours. Total cost: <$30.
This is why phishing is the dominant initial access vector —
the barrier to entry is almost zero.

Lab simulation: three approaches

You can't (and shouldn't) set up a real AiTM proxy in the course lab. Instead, you simulate the detection-relevant effects: two sign-ins from the same user within minutes, from different contexts.

Approach 1. Microsoft Attack Simulation Training (recommended)

In your M365 dev tenant, you can simulate a phishing email using Microsoft's Attack Simulation Training (included with E5):

# Connect to Security & Compliance PowerShell
Connect-IPPSSession -UserPrincipalName admin@yourname.onmicrosoft.com

# Alternatively, use the Defender portal GUI:
# security.microsoft.com → Email & collaboration → Attack simulation training
# → Simulations → Create simulation → Credential Harvest → Spearphishing Link

In the Defender portal:

1. Go to Email & collaboration → Attack simulation training
2. Click Simulations → + Launch a simulation
3. Select Credential Harvest as the technique
4. Select a phishing template (e.g. "Document shared via SharePoint")
5. Target user: t.ashworth@yourname.onmicrosoft.com
6. Configure the landing page (the fake login page)
7. Launch the simulation

This sends a realistic phishing email to Tom Ashworth's mailbox in your dev tenant. The email contains a link to a Microsoft-hosted credential-harvesting page.

Phase 2. Click the link and enter credentials

1. Open Outlook Web Access in an InPrivate/Incognito window
2. Sign in as t.ashworth@yourname.onmicrosoft.com
3. Open the simulation email
4. Click the phishing link
5. On the fake login page, enter Tom Ashworth's credentials
6. The page captures the credentials and redirects

Phase 3. Simulate the attacker's credential replay

Now simulate what the attacker does with the stolen credentials. Open a different browser or a new InPrivate window and sign in as Tom Ashworth, but from a different context to create the detection signal:

# Use PowerShell to authenticate with the stolen credentials
# This creates a sign-in from a non-browser context (suspicious)
$cred = Get-Credential  # Enter t.ashworth / PurpleLab2026!
Connect-MgGraph -Credential $cred -TenantId "yourname.onmicrosoft.com"

# Access some data as the "attacker"
Get-MgUser -Top 5 | Select-Object DisplayName, UserPrincipalName

This produces two sign-in events in rapid succession: the legitimate browser sign-in (the user clicking the link) and the PowerShell sign-in (the attacker replaying the credential). The time gap, the different client app, and the different device fingerprint are the detection signals.

Alternative, manual simulation without Attack Simulation Training:

If Attack Simulation Training isn't available or you want more control:

# Send a test email to t.ashworth with a link to a local credential page
# (Use a simple HTML page on PT-LINUX01 as the "phishing page")
Send-MailMessage -From "sharepoint@yourname.onmicrosoft.com" `
    -To "t.ashworth@yourname.onmicrosoft.com" `
    -Subject "Shared Document: Q4 Budget Review" `
    -Body "Click here to view: http://10.0.0.20:8080/login" `
    -SmtpServer "yourname-onmicrosoft-com.mail.protection.outlook.com"

Then sign in as t.ashworth from two different contexts within 5 minutes to create the anomaly signal.

6. What Just Fired

Entra ID Sign-in Log: the legitimate sign-in (user clicking the link):

{
  "createdDateTime": "2026-04-28T09:14:32Z",
  "userDisplayName": "Tom Ashworth",
  "userPrincipalName": "t.ashworth@yourname.onmicrosoft.com",
  "appDisplayName": "Office 365 SharePoint Online",
  "clientAppUsed": "Browser",
  "ipAddress": "203.0.113.10",
  "location": {
    "city": "London",
    "countryOrRegion": "GB"
  },
  "deviceDetail": {
    "deviceId": "",
    "displayName": "",
    "operatingSystem": "Windows 11",
    "browser": "Edge 124"
  },
  "status": {
    "errorCode": 0,
    "additionalDetails": "MFA completed"
  },
  "riskLevelDuringSignIn": "none",
  "conditionalAccessStatus": "success"
}

Entra ID Sign-in Log: the attacker's credential replay (90 seconds later):

{
  "createdDateTime": "2026-04-28T09:16:01Z",
  "userDisplayName": "Tom Ashworth",
  "userPrincipalName": "t.ashworth@yourname.onmicrosoft.com",
  "appDisplayName": "Microsoft Graph",
  "clientAppUsed": "Mobile Apps and Desktop clients",
  "ipAddress": "198.51.100.44",
  "location": {
    "city": "Amsterdam",
    "countryOrRegion": "NL"
  },
  "deviceDetail": {
    "deviceId": "",
    "displayName": "",
    "operatingSystem": "Windows 10",
    "browser": ""
  },
  "status": {
    "errorCode": 0
  },
  "riskLevelDuringSignIn": "none",
  "conditionalAccessStatus": "success"
}

Key differences between the two sign-ins:

• IP address: London (203.0.113.10) → Amsterdam (198.51.100.44), different countries, 90 seconds apart
• Client app: "Browser" → "Mobile Apps and Desktop clients", different application type
• App: "SharePoint Online" → "Microsoft Graph": the attacker accesses the API, not the portal
• Device ID: empty in both: no registered device (the attacker's machine isn't enrolled)
• Browser: "Edge 124" → empty: the attacker used PowerShell, not a browser
• Risk level: "none" in both. Entra ID Protection didn't flag it (this is the gap)

The detection signal is the correlation of these two events: same user, different locations, within minutes, with a client app change. Neither event is suspicious alone. Together they indicate credential theft.

Defender for Office 365. URL click telemetry:

{
  "Timestamp": "2026-04-28T09:14:28Z",
  "NetworkMessageId": "abc123-def456",
  "Url": "https://sharepoint-review.example.com/shared/q4-budget",
  "UrlAction": "ClickAllowed",
  "ActionType": "ClickAllowed",
  "UrlChain": [
    "https://sharepoint-review.example.com/shared/q4-budget",
    "https://login.microsoftonline.com/common/oauth2/authorize"
  ],
  "AccountUpn": "t.ashworth@yourname.onmicrosoft.com",
  "IsClickedThrough": true
}

The URL click was logged 4 seconds before the first sign-in. Safe Links evaluated the URL and allowed it (ClickAllowed). The URL chain shows the redirect from the phishing domain to what appears to be a Microsoft login page (the AiTM proxy).

7. The Detection

The detection for T1566.002 isn't in the email, it's in the post-click sign-in anomaly. The rule correlates two sign-ins from the same user within a short time window from different locations.

title: Potential Credential Phishing - Impossible Travel Sign-In
id: 8d2f4a01-3b5c-6d7e-9f0a-1b2c3d4e5f60
status: stable
description: |
    Detects two successful sign-ins from the same user within 10
    minutes from different countries. Indicates credential theft
    via phishing link or AiTM proxy.
logsource:
    product: azure
    service: signinlogs
detection:
    selection:
        Status.errorCode: 0
    timeframe: 10m
    condition: selection | count(Location.countryOrRegion) by
               UserPrincipalName > 1
level: high
tags:
    - attack.initial_access
    - attack.t1566.002
falsepositives:
    - Users on VPN with exit nodes in different countries
    - Users traveling between border cities
    - Mobile users with unstable connections switching towers

// Sentinel KQL — Impossible Travel Detection (Credential Phishing)
let timeWindow = 10m;
SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType == 0  // Successful sign-ins only
| project TimeGenerated, UserPrincipalName, IPAddress,
          Location = tostring(LocationDetails.countryOrRegion),
          City = tostring(LocationDetails.city),
          AppDisplayName, ClientAppUsed,
          DeviceId = tostring(DeviceDetail.deviceId)
| sort by UserPrincipalName asc, TimeGenerated asc
| extend PrevTime = prev(TimeGenerated, 1),
         PrevLocation = prev(Location, 1),
         PrevIP = prev(IPAddress, 1),
         PrevApp = prev(AppDisplayName, 1),
         PrevUser = prev(UserPrincipalName, 1)
| where UserPrincipalName == PrevUser
| where Location != PrevLocation
| where datetime_diff('minute', TimeGenerated, PrevTime) < 10
| project TimeGenerated, UserPrincipalName,
          FromLocation = PrevLocation, ToLocation = Location,
          FromIP = PrevIP, ToIP = IPAddress,
          FromApp = PrevApp, ToApp = AppDisplayName,
          MinutesBetween = datetime_diff('minute', TimeGenerated, PrevTime),
          DeviceRegistered = iff(DeviceId == "", "No", "Yes")

// Defender XDR — Impossible Travel (Credential Phishing)
let timeWindow = 10m;
AADSignInEventsBeta
| where Timestamp > ago(1h)
| where ErrorCode == 0
| project Timestamp, AccountUpn, IPAddress, Country, City,
          Application, ClientAppUsed, DeviceId = ""
| sort by AccountUpn asc, Timestamp asc
| extend PrevTime = prev(Timestamp, 1),
         PrevCountry = prev(Country, 1),
         PrevIP = prev(IPAddress, 1),
         PrevApp = prev(Application, 1),
         PrevUser = prev(AccountUpn, 1)
| where AccountUpn == PrevUser
| where Country != PrevCountry
| where datetime_diff('minute', Timestamp, PrevTime) < 10
| project Timestamp, AccountUpn,
          FromCountry = PrevCountry, ToCountry = Country,
          FromIP = PrevIP, ToIP = IPAddress,
          MinutesBetween = datetime_diff('minute', Timestamp, PrevTime)

index=azure sourcetype="azure:signinlogs" ResultType=0
| sort 0 UserPrincipalName, _time
| streamstats window=2 current=t
    earliest(_time) as prev_time
    earliest(Location.countryOrRegion) as prev_country
    earliest(IPAddress) as prev_ip
    by UserPrincipalName
| eval time_diff_min = round((_time - prev_time) / 60, 1)
| where time_diff_min > 0 AND time_diff_min < 10
| where "Location.countryOrRegion" != prev_country
| table _time, UserPrincipalName, prev_country,
        "Location.countryOrRegion", prev_ip, IPAddress,
        time_diff_min, AppDisplayName

The rule uses a sliding-window comparison: for each successful sign-in, check if the same user signed in from a different country within the last 10 minutes. The prev() function in KQL and streamstats in SPL handle the sequential comparison.

Why sign-in correlation, not email filtering? Email-based detections (URL reputation, Safe Links) are bypass-able: the attacker controls the phishing infrastructure and can make URLs pass reputation checks at the moment of delivery. The sign-in anomaly happens after the phishing succeeds, and the attacker can't control the geographic distance between their infrastructure and the victim's location.

Known evasions:

• VPN exit in the victim's country: the attacker routes through a VPN server in the same country as the victim. The impossible-travel rule doesn't fire because both sign-ins appear local. Counter: add client app change as a secondary indicator (Browser → Desktop client within minutes).
• Slow replay: the attacker waits hours before using the stolen credentials. The 10-minute window misses it. Counter: extend the window for unregistered devices (empty DeviceId) to 60 minutes.
• Token theft without credential replay: AiTM captures the session cookie, not the password. The attacker replays the cookie: no new sign-in event, no impossible travel. Counter: monitor for token replay indicators (CAE claim challenges, unusual token lifetimes) in separate rules.

8. The Tuning Loop

False-positive sources:

VPN users with international exit nodes. Your organization uses a VPN provider with exit nodes in multiple countries. A user in London connects through an Amsterdam exit node: the sign-in shows Netherlands, then the user disconnects VPN and signs in directly, now showing UK. Two countries, five minutes apart. Legitimate. Fix: maintain a watchlist of known VPN exit IPs and exclude them from the country comparison, or compare at the city level within the same VPN provider's network.

// Tuning, exclude known VPN exit IPs
let VPNExitIPs = _GetWatchlist('VPNExitNodes') | project IPAddress;
SigninLogs
| where IPAddress !in (VPNExitIPs)
// ... rest of the impossible-travel query

Border-city commuters. A user works in a city near a national border (e.g. Geneva/Annecy, El Paso/Juárez, Windsor/Detroit). Their mobile device switches between country-level cell towers during the commute. Fix: exclude specific user/country pairs where the commute pattern is documented, or require a minimum distance threshold rather than just country difference.

Shared accounts. Two people sharing a service account sign in from different locations simultaneously. Fix: service accounts should be excluded from impossible-travel rules entirely and monitored through dedicated service-account-specific detections.

Baseline FP rate: 5–15 per day in an 800-user environment. Most are VPN-related. After tuning with a VPN watchlist, drops to 1–3 per day. The remainder are genuine anomalies worth investigating, even if benign, they represent sign-in patterns that would look identical to credential theft.

Continuous rhythm: review the VPN watchlist monthly. VPN providers change exit node IPs. New users join who travel internationally. The tuning that works this month may produce FPs next month.

9. Decision Exercise

Your impossible-travel rule fires. The alert shows:

User:         p.sharma@northgateeng.com
From:         London, GB (09:22)      App: Outlook Web
To:           Lagos, NG (09:28)       App: Microsoft Graph
Time gap:     6 minutes
Device ID:    empty (both sign-ins)

Priya Sharma is based in the London office. She has no travel scheduled. The second sign-in used Microsoft Graph (API access), not a browser. Neither sign-in used a registered device.

Which assessment is correct?

A. False positive. Priya may be using a VPN for personal reasons. Close the alert.

B. Suspicious, investigate immediately. The combination of impossible travel, client app change (browser to API), and empty device ID on both sign-ins is consistent with credential phishing followed by token replay.

C. Benign true positive. Priya's credentials were compromised but Conditional Access will block the attacker. No action needed.

D. Rule-logic FP: the 10-minute window is too aggressive. Widen to 30 minutes to reduce noise.

10. Try-it

Execute the full attack chain on your lab:

Step 1. Create the phishing simulation:

Use Attack Simulation Training in the Defender portal (security.microsoft.com → Email & collaboration → Attack simulation training) to send a credential-harvest simulation to t.ashworth@yourname.onmicrosoft.com.

If Attack Simulation Training isn't available, send a test email with a link to a local page and then sign in as t.ashworth from two different contexts within 5 minutes.

Step 2. Click the link and submit credentials:

Open OWA as t.ashworth, find the simulation email, click the link, enter credentials on the phishing page.

Step 3. Simulate the attacker replay:

Open a different browser. Sign in as t.ashworth using PowerShell:

Connect-MgGraph -TenantId "yourname.onmicrosoft.com"
# Enter t.ashworth credentials when prompted
Get-MgUser -Top 3 | Select-Object DisplayName
Disconnect-MgGraph

Step 4. Check all three SIEMs:

Run the detection query from each tab above. Record the results:

T1566.002. Spearphishing Link
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Target:    t.ashworth@yourname.onmicrosoft.com
Attack:    Credential harvest simulation + PowerShell replay
Time:      ____:____
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                  Detected?    MTTD
Sentinel:         [ ]          ____
Defender XDR:     [ ]          ____
Secondary SIEM:   [ ]          ____
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FPs observed: ____
Notes: ____

Expected result: the impossible-travel query should return at least one row showing t.ashworth signing in from two contexts within minutes. If the query returns nothing, check that sign-in logs are flowing to Sentinel (run SigninLogs | take 5 to verify).

Troubleshooting:

• No sign-in logs in Sentinel: check the Entra ID data connector in Sentinel (PT1.8 Step 6). Sign-in logs can take 5–15 minutes to appear after the event.
• Both sign-ins show the same location: you may be signing in from the same IP both times. Use a VPN or mobile hotspot for the "attacker" sign-in to create a geographic difference. Alternatively, modify the query to compare ClientAppUsed instead of location.
• Attack Simulation Training not available: this feature requires specific E5 licenses to be activated. It may take 24–48 hours after tenant creation. Use the manual email method instead.

Cleanup:

# Revoke t.ashworth's sessions (practice the response)
Connect-MgGraph -Scopes "User.ReadWrite.All"
Revoke-MgUserSignInSession -UserId "t.ashworth@yourname.onmicrosoft.com"
Disconnect-MgGraph

11. Reference Card