Knight Office -- M365 AiTM Phishing Kit & Entra ID Persistence

Knight Office is an adversary-in-the-middle (AiTM) phishing-as-a-service kit, disclosed by Huntress on 2026-09-02 from a real intrusion its SOC opened on 2026-08-18, that steals Microsoft 365 session/OAuth tokens rather than passwords. A self-spoofed DocuSign-style lure (the From, To, and Return-Path headers are forged to the recipient's own address) routes victims through a legitimate Monday.com tracking redirect and a compromised Joomla website -- a chain built to blind email-security scanners and analysts -- to a SharePoint/Teams-themed phishing page (page title Login -- KNIGHT OFFICE, fronted by a Cloudflare Turnstile) that walks the target through Microsoft's own device-authentication code flow. A reverse proxy sitting between the victim and Microsoft captures the resulting session token and feeds it to the operator console at idoej[.]com (104.37.188[.]94), where it is replayed with a distinctive python-requests/2.34.2, OAuth2:Token client fingerprint.

What makes Knight Office worth a dedicated hunt is not the token theft itself -- that is now routine phishing-kit tradecraft, and Huntress explicitly ties it to sibling kits EvilTokens and Kali365 -- it is what happens after. The operator uses the stolen token to enroll an attacker-controlled device into the victim's Microsoft Entra ID tenant and binds a Windows Hello for Business (WHfB) passwordless key credential to the compromised account. That credential survives both a forced password reset and a full session-token revocation: the two standard "we think this account was phished" incident-response actions do not evict the attacker. Only an explicit review and removal of the rogue device and its WHfB/authentication-method registration closes the door back out.

Huntress has linked the single operator-console IP to at least nine token-replay logins against Microsoft 365 and Google Workspace identities within its own customer telemetry over a two-week window, and at least 700 phishing emails matching this lure's subject line and template reported through its Security Awareness Training platform since April 2026 -- this is an active, ongoing campaign, not a one-off intrusion.

Defender priority: this is primarily an identity hunt, not an endpoint hunt. The single highest-value action is reviewing every Microsoft Entra ID device registration and every new WHfB/passkey credential addition from the last 30 days against known onboarding baselines (Section 8, Q3-Q5) -- a rogue device registration paired with a new WHfB credential on an account that was not provisioning new hardware that day is the tell that password reset and token revocation alone will not remediate.

Disqualified / inaccessible: itsecurityguru.org's coverage of this story was located via search but returned HTTP 403 (Cloudflare bot-challenge) on fetch -- no verbatim snapshot could be saved, so per this pack's sourcing rule it is not cited and contributes zero claims here. No other outlet with independently-gathered (non-Huntress-derived) technical detail was found as of 2026-09-15.

Second-source policy applied: no independent confirmation of the atomic infrastructure IOCs (idoej[.]com, 104.37.188[.]94, the 25 .vu domains) was found -- expected 13 days after disclosure of a fresh campaign. Per the pack's second-source rule, every infrastructure IOC in Section 10 ships at action=detect / severity=high, not prevent/critical, until a second independent source corroborates them.

No fetched source contained instructions directed at the assistant (prompt injection); all three sources above were treated strictly as data.

Attack chain

Hunt hypotheses (ordered by fidelity)

Falcon endpoint telemetry alone cannot detect this campaign's persistence mechanism. Section 8's identity queries (Q1-Q6, Q8) require an Entra ID / Identity Protection connector feeding LogScale; only Q7 (DNS to known phishing domains) is native Falcon-sensor telemetry with no additional licensing. Say so plainly to stakeholders before promising detection coverage.

Tactic/technique/context reproduced from Huntress's own published mapping (attributed; IDs as published in the primary source and not independently re-derived), with a Query-or-Control column added by this pack.

The lure, redirect chain, and phishing page live entirely outside Falcon's telemetry surface. These native hunts cover that gap using the platforms that actually see them: Exchange Online / M365 Defender for the mail leg, and Microsoft Graph / Entra admin center for a direct audit-log review that does not depend on a LogScale connector being wired up yet.

Mail: self-spoofed lure + subject pattern (M365 Defender Advanced Hunting)

// Microsoft 365 Defender Advanced Hunting (KQL) -- self-spoofed lure subject
// Non-CQL: runs against EmailEvents in the M365 Defender / Sentinel portal, not Falcon LogScale
EmailEvents
| where Subject matches regex @"(?i)(signature required|lmportant|slgnature|verlvied).*ref[\s-]?id"
| where SenderFromAddress =~ RecipientEmailAddress
| project Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, SenderIPv4

Entra sign-in UA fingerprint, Sentinel/Log Analytics variant

For organizations that also run Entra sign-in logs through Sentinel rather than (or alongside) Falcon LogScale, the same Q1 logic as a KQL starter:

// Microsoft Entra sign-in log KQL starter (Sentinel / Log Analytics) -- token-replay UA
// Non-CQL: adapt field names to your workspace schema before running
SigninLogs
| where UserAgent has_any ("python-requests/2.34.2", "OAuth2:Token")
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, UserAgent, ResultType

Direct admin-center / Graph PowerShell audit pull

Usable immediately, with no SIEM connector required -- run this the same day this pack is deployed while the Falcon Entra connector is being validated:

# Entra ID device-registration + WHfB audit checklist (Microsoft Graph PowerShell)
# Non-CQL: run interactively by an admin with AuditLog.Read.All
Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"
Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Register device' or activityDisplayName eq 'Add device'" |
  Sort-Object ActivityDateTime -Descending | Select-Object ActivityDateTime, InitiatedBy, TargetResources

Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Add Windows Hello for Business credential'" |
  Sort-Object ActivityDateTime -Descending | Select-Object ActivityDateTime, InitiatedBy, TargetResources

Secure web gateway / proxy pivot

• Grep proxy/SWG logs for the page title string Login - KNIGHT OFFICE in captured page titles or TLS SNI logs for idoej.com.
• Grep for the Cloudflare Turnstile sitekey 0x4AAAAAADrkE-VuOnNDfr6W in any HAR captures or web-isolation logs -- a distinctive, low-FP fingerprint of this specific kit's phishing page.
• Historical retro-hunt only: outbound clicks through a Monday.com tracking redirect immediately followed by a hit on a compromised Joomla site are worth a one-time historical pull, but the specific Joomla host Huntress observed was already taken down at publication time.

This is an identity/SaaS-led hunt. Q1-Q6 and Q8 require Entra ID sign-in/audit logs ingested into Falcon LogScale (Identity Protection license + connector); only Q7 runs on standard endpoint sensor telemetry alone. SaaS/IdP field names and repo prefixes are parser-dependent per tenant — every identity query below carries an explicit NOTE: field unverified: validate in tenant line; confirm each against one live sample row before scheduling.

// HUNT: Knight Office Token-Replay User-Agent Fingerprint
// MITRE: T1528, T1550.001, T1557
// CONF: high  FP: low  COST: low | REQUIRES: repo=azure_signinlogs (Entra ID sign-in logs, Identity Protection / M365 connector)
// NOTE: field unverified: validate in tenant -- SaaS/IdP field names and repo prefix vary by connector; confirm against a live sample row
// FALSE POSITIVES: a first-party automation/CI job calling Graph or AAD endpoints with the Python `requests` library pinned to this exact version is rare but possible in a dev/test tenant
// TUNING: exclude documented service-principal/automation accounts that legitimately use python-requests against Graph, filtered by userPrincipalName
// LOOKBACK: 30d
userAgent = "python-requests/2.34.2" or userAgent = "OAuth2:Token"
| table([@timestamp, userPrincipalName, ipAddress, appDisplayName, clientAppUsed, userAgent, correlationId])
| sort(@timestamp, order=desc)

// HUNT: Post-MFA Authentication Broker Sign-In Repeated From One Source (Callback-Proxy Pattern)
// MITRE: T1557, T1111, T1078.004
// CONF: medium  FP: medium  COST: low | REQUIRES: repo=azure_signinlogs
// NOTE: field unverified: validate in tenant -- confirm appDisplayName string values against a live sample row
// FALSE POSITIVES: legitimate travel, corporate VPN/NAT egress, a shared branch-office IP, or an approved third-party MDM broker
// TUNING: exclude known corporate VPN/NAT egress ranges once confirmed benign, e.g. !cidr(ipAddress, subnet=["203.0.113.0/24"])
// LOOKBACK: 30d
appDisplayName = "Microsoft Authentication Broker" or appDisplayName = "OfficeHome"
| groupBy([userPrincipalName, ipAddress], function=[count(as=Hits), collect(userAgent), collect(appDisplayName)], limit=1000)
| Hits >= 3
| sort(Hits, order=desc)

// HUNT: Rogue Microsoft Entra Device Registration
// MITRE: T1098.005
// CONF: high  FP: low  COST: low | REQUIRES: repo=azure_auditlogs (Entra ID Directory Audit logs)
// NOTE: field unverified: validate in tenant -- operationName/category strings and the targetResources.* path per Microsoft's Entra audit log activity reference; confirm against a live sample row
// FALSE POSITIVES: legitimate bulk device enrollment (Autopilot/Intune rollout) or a new-hire onboarding wave
// TUNING: exclude the known Intune/Autopilot enrollment service principal and any documented bulk-provisioning change window
// LOOKBACK: 30d
operationName = "Register device" or operationName = "Add device"
| table([@timestamp, "initiatedBy.user.userPrincipalName", "initiatedBy.user.ipAddress", "targetResources.displayName", correlationId])
| sort(@timestamp, order=desc)

// HUNT: Windows Hello for Business Key Credential Bound Outside Baseline
// MITRE: T1098.005, T1556
// CONF: high  FP: medium  COST: low | REQUIRES: repo=azure_auditlogs
// NOTE: field unverified: validate in tenant -- confirm the exact operationName string your connector emits for a WHfB/passkey credential add
// FALSE POSITIVES: legitimate first-time WHfB enrollment during scheduled onboarding, or a user-initiated self-service device reset
// TUNING: exclude WHfB credential adds inside the account's documented onboarding window that correlate to an Intune Autopilot enrollment record
// LOOKBACK: 30d
operationName = "Add Windows Hello for Business credential" or operationName = "User registered security info"
| table([@timestamp, "initiatedBy.user.userPrincipalName", "initiatedBy.user.ipAddress", "targetResources.userPrincipalName", correlationId])
| sort(@timestamp, order=desc)

// HUNT: Correlated Persistence Chain -- Rogue Device Registration + WHfB Bind, Same Identity
// MITRE: T1098.005
// CONF: high  FP: low  COST: medium | REQUIRES: repo=azure_auditlogs; correlates Q3 and Q4 operation types on the same target user
// NOTE: field unverified: validate in tenant -- this assumes both operations resolve the same targetResources.userPrincipalName value; confirm on a sample pair before promoting to a scheduled search
// FALSE POSITIVES: a coordinated, change-managed device replacement/reimage performed by IT inside a documented window
// TUNING: exclude accounts with an open device-replacement change ticket at the time of the match
// LOOKBACK: 30d
defineTable(query={
    operationName = "Register device" or operationName = "Add device"
    | rename(field="targetResources.userPrincipalName", as=RegUser)
    | table([RegUser, @timestamp])
  }, name="rogue_device_regs", include=[RegUser, @timestamp])
| operationName = "Add Windows Hello for Business credential" or operationName = "User registered security info"
| rename(field="targetResources.userPrincipalName", as=RegUser)
| match(table="rogue_device_regs", field=RegUser, column=RegUser)
| table([RegUser, @timestamp, operationName])
| sort(@timestamp, order=desc)

// HUNT: Tencent Cloud Replay-Infrastructure Correlation (Support Signal Only)
// MITRE: T1090.003, T1665
// CONF: low  FP: high  COST: medium | REQUIRES: repo=azure_signinlogs
// NOTE: field unverified: validate in tenant -- Falcon does not natively expose ASN on sign-in log ingest; the ranges below are first/second-octet hints from the primary source, not full CIDR blocks
// FALSE POSITIVES: extremely high -- Tencent Cloud hosts a large number of legitimate SaaS/CDN tenants; a hit here is not actionable on its own
// TUNING: AND this query's hits against Q1 (UA fingerprint) or Q3/Q4 (device/WHfB persistence) before triage -- never promote this pattern alone to a blocking IOA or Custom IOC
// LOOKBACK: 30d
ipAddress = "43.*" or ipAddress = "170.106.*" or ipAddress = "162.62.*" or ipAddress = "49.51.*"
| table([@timestamp, userPrincipalName, ipAddress, userAgent, appDisplayName])
| sort(@timestamp, order=desc)

// HUNT: DNS Resolution of Known Knight Office Phishing Domains
// MITRE: T1566.002, T1204.001
// CONF: high  FP: low  COST: low | REQUIRES: DnsRequest telemetry (standard Falcon sensor -- no Identity Protection license needed)
// FALSE POSITIVES: none expected -- these are single-purpose phishing domains named in the primary source
// TUNING: none required at FP low -- but re-validate this domain list at deploy time, phishing-kit landing domains commonly rotate within 30-90 days
// LOOKBACK: 30d
#event_simpleName = DnsRequest
| DomainName = /^(advancedplacyncement|amstardmzsmc|arandasoftzfdware|avisoretentiunionllc|capitalflwxinancialpartners|certififiycationedge|connectivnqzityltd|crrbcearegroup|digitaltrafwwrficsystems|exceltecbusinessbwpsolutions|genamewwgdiamarketing|globaieflsoftinc|globalmixeucbdmodetechnologyinc|globalprojectspvtltd|joinbusinessmanagementconsdjeulting|kentmanqhfufacturingcompany|kleepxrnlinecorporation|knsinternacshtional|monttmmlrustcompany|mtprormtductions|realestatecotblrp|siottxgroup|summitcapitaltrapojininggroup|techcompositnkoes|techromixsolutionlonsinc)\.vu$/i or DomainName = /^idoej\.com$/i
| table([@timestamp, aid, ComputerName, UserName, DomainName])
| sort(@timestamp, order=desc)

// HUNT: Windows Hello for Business Pre-Auth Failure Fingerprint (Missing Device/NGC Key)
// MITRE: T1556, T1098.005
// CONF: high  FP: low  COST: low | REQUIRES: repo=azure_signinlogs; failure/error-reason text field
// NOTE: field unverified: validate in tenant -- confirm the exact failureReason/error text your connector emits for a missing device key (commonly an AADSTS50155-class or AADSTS53003-class error); the substrings below are a starting point, not guaranteed verbatim
// FALSE POSITIVES: a legitimate WHfB provisioning race condition on a brand-new managed device during normal Autopilot enrollment, which self-resolves within minutes with no externally-sourced success afterward
// TUNING: exclude devices with an open Intune Autopilot enrollment ticket at the time of the failure
// LOOKBACK: 30d
failureReason like "*device key*" or failureReason like "*NGC*" or failureReason like "*strong auth*"
| table([@timestamp, userPrincipalName, ipAddress, userAgent, failureReason, correlationId])
| sort(@timestamp, order=desc)

Honesty check: a classic Falcon Custom IOA is a host-based behavioral indicator (process tree pattern). Most of this hunt is identity/SaaS telemetry, which does not fit that model -- the right promotion path for those queries is an NG-SIEM Scheduled Search or Fusion SOAR workflow that raises an identity alert, not a host-based IOA that could trigger isolation. Only Q7 is a genuine endpoint Custom-IOA/Custom-IOC candidate.

All infrastructure IOCs below ship at action=detect / severity=high (not prevent/critical) per the second-source policy in Section 2 -- single-sourced to Huntress, 13 days post-disclosure. Every value traces to the saved source snapshot; see Section 18.

type,value,action,severity,expiration,description,tags
domain,idoej.com,detect,high,2027-03-15,Knight Office AiTM operator console (reverse IP of 104.37.188.94),campaign:KnightOffice
ipv4,104.37.188.94,detect,high,2027-03-15,Knight Office AiTM operator console + rogue Entra device registration source,campaign:KnightOffice
domain,advancedplacyncement.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,amstardmzsmc.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,arandasoftzfdware.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,avisoretentiunionllc.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,capitalflwxinancialpartners.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,certififiycationedge.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,connectivnqzityltd.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,crrbcearegroup.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,digitaltrafwwrficsystems.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,exceltecbusinessbwpsolutions.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,genamewwgdiamarketing.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,globaieflsoftinc.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,globalmixeucbdmodetechnologyinc.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,globalprojectspvtltd.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,joinbusinessmanagementconsdjeulting.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,kentmanqhfufacturingcompany.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,kleepxrnlinecorporation.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,knsinternacshtional.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,monttmmlrustcompany.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,mtprormtductions.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,realestatecotblrp.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,siottxgroup.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,summitcapitaltrapojininggroup.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,techcompositnkoes.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice
domain,techromixsolutionlonsinc.vu,detect,high,2027-03-15,Knight Office phishing landing domain,campaign:KnightOffice

# Knight Office -- behavioral / non-atomic signatures (not bulk-importable; hunt or correlate manually)
Email self-spoof: From header == To/recipient header == Return-Path header (all three match the victim's own address)
Lure subject regex: (?i)(signature required|approval pending|ref[\s-]?id|lmportant|slgnature|verlvied)
Phishing page title: Login - KNIGHT OFFICE
Cloudflare Turnstile sitekey: 0x4AAAAAADrkE-VuOnNDfr6W
Token-replay User-Agent: python-requests/2.34.2
Token-replay User-Agent literal string: OAuth2:Token
WHfB device-registration client string: Dsreg/10.0 (Windows 10.0.19044.1826)
Lure sender IP (single example case, not for standalone blocking): 154.127.53.78
Residential callback-proxy first hop (redacted by source, partial): 73.125.13.x (Comcast Cable / Spur-flagged proxy resale)
Token-replay hosting ranges (too broad to block -- correlation only): Tencent Cloud 43.x / 170.106.x / 162.62.x / 49.51.x

# Knight Office -- operator console / kit fingerprint
Console page title: Login - KNIGHT OFFICE
Backend stack: Python Flask + Flask-WTF
Bot-filtering front end: Cloudflare Turnstile (sitekey 0x4AAAAAADrkE-VuOnNDfr6W)
TLS: self-signed certificate observed on the operator console
Console features advertised: "Capture & Management from Single place", "Webmail access & auto-refresh",
  "Deploy custom links", "Real-time visitor statistics"
Related/sibling PhaaS kits (different infrastructure -- do not merge IOCs): EvilTokens, Kali365 / Octopi365

# Entra ID / M365 hardening spot-check -- run in order, all read-only
# 1) Is device-code flow still allowed org-wide?
Get-MgIdentityConditionalAccessPolicy | Where-Object { $_.Conditions.ClientAppTypes -contains "all" } |
  Select-Object DisplayName, State

# 2) Who can register/join devices to Entra ID without restriction?
Get-MgPolicyDeviceRegistrationPolicy | Select-Object AzureADJoin, AzureADRegistration

# 3) List WHfB/passkey credentials added in the last 30 days, newest first
Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Add Windows Hello for Business credential'" |
  Where-Object { $_.ActivityDateTime -gt (Get-Date).AddDays(-30) } |
  Sort-Object ActivityDateTime -Descending | Select-Object ActivityDateTime, InitiatedBy, TargetResources

# 4) Is token protection (device-bound tokens) enforced on any Conditional Access policy?
Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, SessionControls

All three playbooks below are read/write Graph PowerShell against Entra ID -- no endpoint agent, GPO, or registry change is involved, since this campaign's decisive control point is identity, not the endpoint.

Playbook 1: Restrict device-code flow

# Playbook 1 -- Restrict device-code flow via Conditional Access (Graph PowerShell)
# Prerequisites: Global Administrator or Conditional Access Administrator role; Microsoft.Graph PowerShell SDK installed
# Reboot required: No
# Rollback: Set the policy State back to "disabled" (see rollback command at bottom) -- reversible in seconds, no data loss

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

$params = @{
    DisplayName = "Block Device Code Flow - Knight Office response"
    State = "enabledForReportingButNotEnforced"   # start in report-only, then flip to "enabled" after a 1-week pilot
    Conditions = @{
        ClientAppTypes = @("all")
        Applications = @{ IncludeApplications = @("All") }
        Users = @{ IncludeUsers = @("All"); ExcludeGroups = @("<break-glass-and-documented-exception-group-id>") }
        Authentication = @{ AuthenticationFlows = @{ TransferMethods = "deviceCodeFlow" } }
    }
    GrantControls = @{ Operator = "OR"; BuiltInControls = @("block") }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

# Rollback:
# Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId <id> -State "disabled" 

Playbook 2: Restrict Entra device registration

# Playbook 2 -- Restrict Entra device registration to an admin-approved group
# Prerequisites: Global Administrator role; a pre-created "Approved Device Enrollers" security group
# Reboot required: No
# Rollback: revert AzureADJoin/AzureADRegistration back to "all", documented below -- reversible, no data loss

Connect-MgGraph -Scopes "Policy.ReadWrite.DeviceConfiguration"

$policy = Get-MgPolicyDeviceRegistrationPolicy
Update-MgPolicyDeviceRegistrationPolicy -DeviceRegistrationPolicyId $policy.Id -BodyParameter @{
    AzureADJoin = @{ AllowedState = "restricted"; AllowedGroups = @("<approved-device-enrollers-group-id>") }
    AzureADRegistration = @{ AllowedState = "restricted"; AllowedGroups = @("<approved-device-enrollers-group-id>") }
}

# Rollback:
# Update-MgPolicyDeviceRegistrationPolicy -DeviceRegistrationPolicyId $policy.Id -BodyParameter @{
#     AzureADJoin = @{ AllowedState = "all" }; AzureADRegistration = @{ AllowedState = "all" }
# }

Playbook 3: Enable token protection (pilot ring)

# Playbook 3 -- Enable Entra ID token protection (device-bound sessions) on a pilot Conditional Access policy
# Prerequisites: Microsoft Entra ID P2, Conditional Access Administrator role, a pilot ring group
# Reboot required: No (client-side, transparent re-auth on next token refresh for pilot users)
# Rollback: remove the SignInTokenProtection session control from the policy -- reversible; pilot users simply
#           lose the device-binding requirement on next sign-in, no account lockout risk

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

$params = @{
    DisplayName = "Pilot - Token Protection for Exchange/SharePoint - Knight Office response"
    State = "enabled"
    Conditions = @{
        Applications = @{ IncludeApplications = @("Office365") }
        Users = @{ IncludeGroups = @("<pilot-ring-group-id>") }
    }
    SessionControls = @{ SignInTokenProtection = @{ IsEnabled = $true } }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

# Rollback:
# Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId <id> -SessionControls @{ SignInTokenProtection = @{ IsEnabled = $false } }

Critical sequencing note: for this campaign, revoking sessions and resetting the password before removing the rogue device and WHfB credential does NOT evict the attacker -- they simply sign back in passwordlessly via WHfB. Eradication must happen before (or atomically with) the standard "reset and revoke" response.

Telemetry-ready and benign-baseline validation gates for every query above are detailed in Section 11; the second-source/provenance status of every shipped IOC is detailed in Section 2 and enforced mechanically at build time.

Full verbatim source snapshots (fetched 2026-09-15) are archived alongside this pack in KnightOffice-M365-AiTM-Hunt-sources/: 01-huntress-knight-office.txt, 02-huntress-kali365-context.txt, 03-msft-entra-audit-activities.txt.