A detection release for password-spray account takeover in Microsoft 365, published October 23, 2026. A new high-severity behavior rule, EntraID_SignIn_After_Block, alerts when an attacker who holds a user's password gets into the account after Conditional Access blocked their earlier attempts. It catches the Azure CLI password spraying that Huntress has reported since June 2026, when a risk policy stops the sprayer once and they come back from another address. A precision fix to EntraID_Valid_Password_Blocked ships with it.
No action is needed: the rules sync to every instance automatically.
\nEntraID_SignIn_After_Block needs Microsoft's sign-in risk rating, which the sign-in logs carry only for tenants with an Entra ID P2 licence. Other tenants get the value hidden, and the rule cannot arm. The improved EntraID_Valid_Password_Blocked works without P2.EntraID_SignIn_After_Block is built to be rare. It needs a correct password, a block rated high risk and a success from somewhere else, all within two hours, so password typos, travel and moves between office and home do not trigger it. Over the 14 days before release it would have fired once across the Fluency fleet: on the real compromise described below. Its severity is high for now and will be reviewed against the first weeks of live alerts.Password spraying against Microsoft 365 grew fast in 2026: Huntress saw credential spray attacks against its customers rise over 155 times in six months. One campaign made more than 81 million sign-in attempts between June 12 and June 26 against the Azure command-line client (Azure CLI), and compromised 78 accounts at 64 organizations. It signs in through Azure CLI's password-only flow (OAuth ROPC), which sends the password straight to Microsoft's token endpoint with no MFA prompt. The actor sprayed from a hosting provider's IPv6 range and from Tor exit nodes. When the provider shut it down, it moved to other providers and kept spraying low and slow: in July, about 900 attempts per address across some 12,800 addresses.
\nThe passwords come from old breaches that were never rotated. Accounts fall when MFA does not cover the sign-in: MFA required only for admins or some groups, only for some apps, only from untrusted locations, or left in report-only mode.
\nFluency saw the same pattern in a customer tenant in October 2026:
\nEach record looks normal on its own: the block is the policy working, and the success is a routine sign-in. Before this release, the blocked attempts raised EntraID_Valid_Password_Blocked alerts, but nothing tied them to the successful sign-in that followed.
| ID | Rule | Change | Severity | Fires when |
|---|---|---|---|---|
| 102185 | EntraID_SignIn_After_Block | New | High | A user signs in successfully within two hours after Conditional Access blocked a sign-in of theirs that Microsoft rated high risk and that presented their correct password, and the success comes from an IP address none of the blocked attempts came from. |
| 102127 | EntraID_Valid_Password_Blocked | Improved | Medium | Conditional Access blocks a sign-in that presented the user's correct password. It now matches Microsoft's \"Correct password\" result exactly, so a blocked sign-in with a wrong password (\"Incorrect password\") is no longer reported as a known password. |
For both rules, a block is a sign-in Conditional Access stopped by policy (result 53003 or 530032) or because the device was not compliant or not managed (53000, 53001).
\nEntraID_SignIn_After_Block does not fire for:
It is keyed on the user and alerts at most once per user in two hours. Each alert names the successful sign-in (IP address, network, country, application, resource, user agent, session and sign-in IDs) and the blocked attempts before it (their addresses and count, result code, risk level, country and sign-in ID), with the seconds between the last block and the success.
\nTreat an EntraID_SignIn_After_Block alert as a likely account takeover until you show otherwise.
An EntraID_Valid_Password_Blocked alert on its own means someone else knows the password, even though that attempt was stopped. Reset it and require MFA for that user.
To find these alerts, search behavior events by rule name. Each rule is also listed by name on the Behavior Rules page.
\nDetection shortens an attacker's window; MFA closes it. These steps follow Huntress's guidance and what we saw in the field:
\nA detection release for Microsoft Entra ID, published October 23, 2026. Four new behavior rules alert when an app (a service principal acting with no user signed in) assigns directory roles or adds credentials to other apps. An attacker does exactly this with a stolen app certificate or secret, as in the Storm-0940 compromise of ConnectWise's multi-tenant apps that Microsoft reported on October 21. Until now, role assignments and credential changes made by an app were only context, or one step of the EntraID_App_Takeover correlation.
No action is needed: the rules sync to every instance automatically. These notes also correct how the October 18–20 notes described EntraID_DeviceCode_UserApp.
EntraID_App_Privileged_Role_Assigned, EntraID_App_Role_Assigned and EntraID_App_Credential_By_App therefore start alerting about a week after they reach a tenant. EntraID_App_Self_Role_Assigned alerts from the start.Microsoft Threat Intelligence attributes the compromise to Storm-0940, a China state-aligned actor. It automated the attack with ARTEX, an open-source agentic AI penetration-testing framework. Its targets were ConnectWise Cloud Backup (formerly SkyKick) and the ConnectWise Cloud Management apps, which MSPs and their customers had consented to in their Microsoft 365 tenants.
\nUser-based rules miss this. No user signs in, so there is no MFA prompt, no risky sign-in and no new device. The app is one the tenant already trusts, so app-creation and consent rules do not fire either. What the audit log does show is a service principal assigning roles, often to itself, and adding secrets to other apps.
\n| ID | Rule | Severity | Alerts | Fires when |
|---|---|---|---|---|
| 102184 | EntraID_App_Self_Role_Assigned | Critical | Every time | An app assigns any directory role to its own service principal. Apps are given roles by an administrator, so an app granting itself one is never routine. |
| 102168 | EntraID_App_Privileged_Role_Assigned | High confidence | First time per app in 30 days | An app assigns a privileged directory role (Global, Exchange, Privileged Role or Application Administrator and the like) to a user or group, or any directory role to another service principal. |
| 102169 | EntraID_App_Role_Assigned | Medium | First time per app in 30 days | An app assigns a non-privileged directory role to a user or group. |
| 102170 | EntraID_App_Credential_By_App | Medium | First time per app in 30 days | An app adds a secret or certificate to another app or service principal, so that its access survives the original credential being revoked. An app re-keying itself, such as Entra Connect or a vendor's connector, is not counted. |
The role rules map to MITRE ATT&CK T1098.003 (Additional Cloud Roles), and the credential rule to T1098.001 (Additional Cloud Credentials).
\nSome apps do these things as their job: a just-in-time access broker grants admin roles every week, and CI pipelines rotate other apps' secrets. So the three first-time rules alert only the first time an app does it in 30 days, keyed on the app ID; repeats are not recorded. A compromised app that already does this routinely will not trip them. Self-assignment has no such allowance.
\nMicrosoft's own service apps are excluded by app ID: Privileged Identity Management, Microsoft support's GDAP access, Approval Management, ESTS, managed identities, Purview, Dynamics and AAD App Management. Role grants through PIM therefore stay with EntraID_Privileged_Role_Assigned (102119).
Each alert is keyed on the app's name. The app ID, service principal ID, role and target are in the event's attributes.
\nParser change. EntraID_AuditRules now also emits a line keyed on the acting app for role and credential operations. Its existing output, and the rules that read it, are unchanged.
| Step | Why it is not covered | What helps |
|---|---|---|
| The app signs in with a stolen credential | Most tenants do not collect service principal sign-ins, so an app that only reads (Graph reconnaissance, mail, files) leaves no trace. | Collect service principal sign-ins: select the ServicePrincipalSignInLogs category in the Entra ID diagnostic setting that feeds Entra ID Audit via Event Hubs. The Microsoft Graph template collects interactive sign-ins only. Volume varies widely between tenants, so check it first. Non-interactive user sign-ins are not needed for this. |
| The app uses Exchange Administrator | No rule yet looks at Exchange admin cmdlets run by an app identity. | Planned. |
| Tenants with only the Microsoft 365 audit log | The unified audit log's version of these operations is not matched yet. | Planned. Entra ID audit logs, through Event Hubs or Microsoft Graph, cover it today. |
| Key Vault secrets read in bulk | Key Vault logs are rarely collected. | Ask us for a hunt if you send Key Vault diagnostics. |
EntraID_DeviceCode_UserApp alerts on every matchThe October 18–20 notes said EntraID_DeviceCode_UserApp (102129) alerts only on a user's first device-code sign-in to an application. That was wrong. Every successful device-code sign-in to an application that is not an admin tool alerts at medium. A user's first such sign-in to an application in 30 days scores higher. The rule's own description is corrected in the next release. Its detection logic is unchanged.
| Alert | Check first | Respond |
|---|---|---|
EntraID_App_Self_Role_Assigned | The app's name, app ID and owner tenant (is it a vendor's multi-tenant app?), and the role it took. Check the vendor's security advisories. | Treat it as a compromise unless the vendor confirms the change. Remove the role, disable the service principal and remove its credentials. Then review what the app did after the grant: other role assignments, credentials added to other apps, password resets, mail access. |
EntraID_App_Privileged_Role_Assigned | Whether the app is a known access broker or automation (a JIT or PAM product, an identity governance tool), and who received the role. | If it is not expected, remove the assignment and contain the app as above. If it is an access broker, confirm the grant matches a request. |
EntraID_App_Role_Assigned | The role and the recipient, and whether the app manages roles as part of its job. | Confirm with the app's owner, and remove the assignment if it is not expected. |
EntraID_App_Credential_By_App | Which app was keyed, and what permissions that app holds. A secret added to a highly privileged app is the persistence step. | Remove the new secret or certificate from the target app and contain the acting app. Rotating the acting app's own credential does not remove the one it added elsewhere. |
Rule IDs are the same on every instance. To find these alerts, search behavior events by rule name. Each rule is also listed by name on the Behavior Rules page.
\nA reports release, published October 23, 2026. A scheduled report can now keep every day's result for 12 months. With the new fluency-report-rollup skill, Claude builds a month, a quarter or a trend from those daily results. It runs no long query, is not held to a report's 60-day limit, and states on the page which days it covers.
Report Archive is available on every instance. For analysts who build reports in Claude Co-Work or Claude Code, it needs two things: the archive turned on for the report, and the fluency-report-rollup skill.
A daily archive. A scheduled report with the archive turned on runs once a day for exactly the previous day, 00:00 to 24:00 in the archive timezone (UTC unless an administrator sets another). Each day's result is kept for 12 months, with its row counts and the version of the report script it ran on.
\nArchive tools on the MCP server. Three new tools on the tenant's MCP server let Claude work with the archive:
\n| Tool | What it does |
|---|---|
list_report_archive | Lists the archived reports, or for one report, its days with a coverage summary: missing, aborted and running days, and the script versions in the range. |
download_report_archive | Downloads one day, or a range of up to 92 days. |
backfill_report_archive | Runs the report for past days that are missing, in the background. |
The fluency-report-rollup skill (1.0.0). It checks coverage, reads the report's script to decide how each table combines, merges the daily results, and hands them to fluency-report to draw the page.
Running a 90-day report directly is slow, and many reports refuse ranges that long. An archived day is a finished result, so a month is 30 small results that already exist, and Claude only has to combine them correctly.
\nTurn the archive on for the report. Ask Claude Which reports are archived? If yours is not listed, an Ingext administrator turns the archive on in the report's definition. The report also needs a daily schedule:
\n\"scheduleFlag\": true,
\"schedule\": { \"interval\": \"daily\", \"hour\": 3, \"minute\": 15, \"timezone\": \"GMT\" },
\"archive\": { \"enabled\": true, \"timezone\": \"UTC\" }
archive.timezone sets where a day starts and ends; schedule.timezone only sets when the run fires. For a report managed in git, add the archive block to the report's file in the Scripts repo, next to schedule. The report editor on Reports → Scheduler does not show this block yet. Days exist from the moment the archive is on. Earlier days can be backfilled while their data is still in the datalake.
Install the skill. Install fluency-report-rollup from the ingext_skills repository; the packaged file is cowork/fluency-report-rollup.skill. It works with fluency-report, which draws the page, so install that too if you don't have it.
Adding up daily results is only right for some kinds of numbers, so the skill decides table by table from the report's script.
\n| The table holds | How the days are combined |
|---|---|
| Counts and sizes per key | Summed per key. A key that appears on only some days still counts. |
| A top-N list | Re-ranked from the summed table. Something ranked 11th every day can be first for the month, so daily top-10s are never combined. |
| Totals | Recomputed from the merged table. Six event types every day is six for the month, not 180. |
| A time series | Each hour kept once, then rolled up to days, or to months for a quarter. |
| Peaks, lows, latest state | The maximum, the minimum, or the newest day's value. |
| Averages and ratios | Recomputed from the summed parts when the report returns them; never an average of daily averages. |
Medians, percentiles, and distinct counts that come without a per-key table cannot be rebuilt from daily values. Claude says so and shows them per day, or leaves them out. It does not approximate them.
\nSystem_Event_Ingress_Report shows how much data a tenant ingests, by event type, product and destination, with a time series. It refuses ranges over 60 days, so a quarter can only be assembled from daily results. On a Fluency test tenant, Claude built it for the 30 days from September 23 to October 22, 2026 (UTC): 30 of 30 days, one script version throughout.
We also ran the report directly over the same 30 days and compared every table:
\n| Table | Assembled vs. direct run |
|---|---|
| Total ingress | 14,811,590,885 vs. 14,811,615,349 bytes (−0.0002%) |
| By event type, product, destination | Same keys; the worst single key differs by 0.015% |
| Daily series | The worst day differs by 0.0006% |
| Top event types and products | Identical order |
The small differences come from how metrics are measured at the edges of a time window, and they shrink as the period grows. The first time you assemble a report, ask Claude to spot-check one number against a direct run over the last 7 days.
\nSee Scheduling and Delivery for putting a report on a schedule.
", "url": "https://manual.ingext.io/release/2026-10-23-report-archive", "title": "Report Archive: Monthly and Quarterly Reports from Daily Runs", "summary": "A reports release, published October 23, 2026. A scheduled report can now keep every day's result for 12 months. With the new fluency-report-rollup skill, Claude builds a month, a quarter or a trend from those daily results. It runs no long query, is not held to a report's 60-day limit, and states on the page which days it covers.", "date_modified": "2026-10-23T13:55:00.000Z", "author": { "name": "Sysadmin", "url": "https://github.com/SecurityDo" }, "tags": [ "release", "reports", "ai" ] }, { "id": "https://manual.ingext.io/release/2026-10-23-teams-helpdesk-impersonation", "content_html": "A detection release for the help desk impersonation campaign that Microsoft Threat Intelligence reported on September 2, 2026, published October 23, 2026. The attacker poses as IT support or a colleague in a Teams chat, calls seconds later, and walks the user into a remote-support session or an installer. Two new high-confidence behavior rules cover the first two steps. O365_Teams_OnMicrosoft_Tenant_Chat alerts on the chat, when it comes from a throwaway *.onmicrosoft.com tenant. O365_Endpoint_Download_From_Azure_CloudApp alerts when a browser downloads an installer from the kind of throwaway Azure host these crews use to deliver it.
No action is needed: the rules sync to every instance automatically.
\nO365_Teams_OnMicrosoft_Tenant_Chat needs its Teams records (the Audit.General content type).O365_Endpoint_Download_From_Azure_CloudApp needs browser-download records, which Windows devices write to the same log once they are onboarded to Microsoft Purview. Devices already onboarded to Defender for Endpoint are in Purview's device list. Turn on device onboarding in the Purview portal under Settings → Device onboarding.onmicrosoft.com rarely open chats with staff. Expect an occasional chat alert when a small vendor or contractor whose tenant has no custom domain starts a chat. Close those as expected. Software vendors do not ship installers from *.cloudapp.azure.com, so the download rule should rarely fire on legitimate activity.The operator works from a Microsoft 365 tenant of their own. Setting one up takes minutes, and a new tenant's domain is on Microsoft's onmicrosoft.com by default. Some attacks open with mail bombing: the user's mailbox is flooded with subscription-confirmation emails, so a help desk offer to fix it is welcome. Posing as IT, the help desk or a colleague, the attacker opens a one-to-one Teams chat and calls within seconds. The name shown on the call can differ from the name on the account.
During the call, the attacker talks the user through one of these:
\n*.cloudapp.azure.com host, the default address of an Azure virtual machine, which anyone can create in minutes.In the intrusion Microsoft reported, the operator then runs PowerShell, installs an MSI silently from attacker-controlled cloud storage, and stages a portable Node.js runtime with an encrypted JavaScript implant. The implant persists under an EdgeUpdate Run key or Startup shortcut, and its first tasks check the machine's antivirus and display adapter to spot a sandbox. The operator then enumerates the domain and moves over WinRM to file, database and application servers, domain controllers and certificate authorities. Microsoft describes this as activity that can precede ransomware or data theft. The installers are rebuilt often, so published file hashes go out of date quickly. Storm-1811, a Black Basta ransomware actor, has used the same help desk lure over Teams since 2024.
| ID | Rule | Severity | Fires when |
|---|---|---|---|
| 102180 | O365_Teams_OnMicrosoft_Tenant_Chat | High confidence | A user of a *.onmicrosoft.com tenant outside your organization creates a Teams chat with one or more of your users. Lookalike tenants, such as a copy of your own company name on onmicrosoft.com, are matched. The sender's display name does not matter. |
| 102181 | O365_Endpoint_Download_From_Azure_CloudApp | High confidence | A browser on a managed Windows device downloads an installer, executable, script, shortcut, archive or disk image (for example .msi, .exe, .ps1, .js, .lnk, .zip or .iso) from a *.cloudapp.azure.com host. |
O365_Teams_OnMicrosoft_Tenant_Chat does not fire for:
#EXT# accounts);It is keyed on the external account. If one attacker account messages several employees, the alerts land on one entity and Fluency's risk scoring groups them into one case. An attacker who rotates tenants produces one case per account. Each alert lists the external account and tenant ID, the users in the chat, the participating domains, the chat thread ID and the chat type.
\nO365_Endpoint_Download_From_Azure_CloudApp does not fire for:
*.blob.core.windows.net), which delivered the MSI in the intrusion Microsoft reported;It is keyed on the employee who downloaded the file. Each alert lists the file, its SHA-256 hash, the host it came from, the device, the browser and the client IP.
\nAfter the call, the attack moves to the endpoint. If you collect Microsoft Defender XDR, CrowdStrike Falcon or SentinelOne alerts, each alert becomes a Fluency behavior on the user and device it names, with the process command line where the vendor provides it. Microsoft lists Defender XDR detections for the implant, the Node.js loader, rundll32 launches, Active Directory enumeration and WinRM lateral movement in this campaign. Defender's mail-bombing and Teams-impersonation alerts arrive the same way, and get triaged with everything else instead of waiting in the Defender queue.
No log shows what was said on a call or what was on a shared screen. Your EDR's process telemetry is what shows which programs ran afterwards.
\nStart from the users in the alert, and work through them in this order. A user who called back or accepted the chat request most likely believed the caller. Teams CallParticipantDetail records in the audit log show which calls were answered, once they arrive.
| Priority | Users | Why |
|---|---|---|
| 1 | Shared their screen or granted remote control, downloaded or ran anything (including an O365_Endpoint_Download_From_Azure_CloudApp alert), or answered and then called back or accepted the chat | The attacker may have had hands on the computer, or will be back. |
| 2 | Answered a call | The attacker may have asked for a password, an MFA approval or a remote session. |
| 3 | Chat only, no call | Warn them. |
A clean sign-in history does not clear a user. The attacker works through the employee's own computer during the call, so the sign-ins in the record are the employee's own.
\nnode.exe running from %LocalAppData%, an EdgeUpdate Run key or Startup shortcut, new services and scheduled tasks, credential dumping, and WinRM or other connections to other hosts.O365_Endpoint_Download_From_Azure_CloudApp alert, check in your EDR whether the file ran, and add its SHA-256 hash and the download host to your EDR's block indicators.CallActivityEvents table in Advanced Hunting shows which attacker calls included screen sharing.O365_Teams_OnMicrosoft_Tenant_Chat does not match them. If you do not use Quick Assist for IT support, remove or block it.To find these alerts, search behavior events by rule name. Each rule is also listed by name on the Behavior Rules page.
\nA detection release for Microsoft Entra ID and Microsoft 365, rolled out October 18–20, 2026. It adds 19 alerting behavior rules and 12 context rules covering three campaigns reported by Microsoft Threat Intelligence (Storm-2755's adversary-in-the-middle (AiTM) session theft, Storm-2372's device-code phishing, and Storm-3119's takeover of whole tenants through a registered app) plus detections for persistence, privilege and sign-in abuse. Five older rules are retired or removed.
\nNo action is needed: the rules sync to every instance automatically.
\nOffice365_* rules need the Microsoft 365 unified audit log (Office365 Audit API or Office 365 Audit). An instance with only the Microsoft 365 audit log still gets the AiTM capture, mail and file activity, broker-phish and inbox-rule detections.EntraID_Valid_Password_Blocked, EntraID_DeviceCode_UserApp, EntraID_High_Risk_App_Permission, EntraID_Privileged_Role_Assigned) to fire on planned admin work and on users blocked by your own Conditional Access policies.Each new rule is either a detection, which raises a behavior alert at the severity shown, or context, which adds an event to the user's timeline without raising an alert. Severity levels and the high-confidence tag are described in Risk Scoring.
\nSeveral of the strongest detections are correlations. They follow one session, one user or one app across sign-in and audit records for hours or days, and alert only when the whole pattern appears. This keeps them quiet on normal activity that looks like a single step of an attack.
\nStorm-2755 sends victims to a fake Microsoft 365 sign-in page through search ads and SEO poisoning. The page relays the real sign-in, so the victim completes MFA and the attacker keeps the session token. The actor then replays the token, searches for payroll and HR content, hides replies with inbox rules, and in one reported case changed the victim's bank details in the payroll system.
\nMFA does not stop this: the stolen token is an already-authenticated session, and the attacker never sees an MFA prompt. The useful signals are the proxied sign-in itself, and the same session ID appearing later from networks the user has never used.
\n| ID | Rule | Severity | Fires when |
|---|---|---|---|
| 102111 | EntraID_AiTM_Capture | High confidence | An interactive sign-in ends in a specific error code after MFA was met. A phishing proxy relaying the sign-in drops a field Entra ID asks for, and the session it got still works. Users' own sign-ins almost never end this way. |
| 102105 | Office365_AiTM_Capture | High confidence | The same capture, from the Microsoft 365 unified audit log. |
| 102113 | EntraID_AiTM_Session_Replay | High confidence | Any later sign-in or token refresh on the captured session ID, from a network the user did not have at the time of capture. The user's own office, home and company proxy are not raised. High confidence for 14 days after the capture, medium from 14 to 90 days. |
| 102114 | EntraID_AiTM_Session_Activity | High confidence | Exchange, SharePoint or OneDrive activity under the captured session from a new network: the reconnaissance stage, where Storm-2755 searched for payroll and banking content. |
| 102106 | Office365_InboxRule_Odd_Name | High | An inbox rule is created or renamed with a name made only of punctuation or a single character, which is how BEC actors keep the rule from standing out. Rules with ordinary names are not matched. |
New and changed authentication methods (how the attacker adds their own MFA method) go on the user's timeline as context, so an investigation of these alerts shows them.
\nStorm-2372 builds rapport with a target over WhatsApp, Signal or Teams, then sends a fake Teams meeting invitation whose \"meeting ID\" is a device code. When the user enters it at microsoft.com/devicelogin, the attacker's device receives the user's tokens. Since February 2025 the actor has used the Microsoft Authentication Broker client ID, which lets it register a device in Entra ID and keep access.
\nThe user signs in to a real Microsoft page and completes MFA, and Teams Rooms devices, desk phones and admin tools use the same flow legitimately. The rules separate the two by what happens next: whether the approved session turns up from another network or country.
\n| ID | Rule | Severity | Fires when |
|---|---|---|---|
| 102129 | EntraID_DeviceCode_UserApp | Medium | Every successful device-code sign-in to an application that is not an admin tool (the broker, Office, Teams, Outlook). A user's first one to an application in 30 days scores higher. Azure CLI, Azure PowerShell and the Graph command-line tools are not matched. |
| 102115 | EntraID_DeviceCode_Phish | High confidence | A session approved with a device code signs in or refreshes its token from a new network, in a new country, within an hour. |
| 102109 | Office365_Broker_Phish | High confidence | A broker-approved session signs in or refreshes its token from a network it had not used: high confidence within an hour when the country is also new, medium otherwise and for up to 14 days. Also raised when a device registered to the user within 10 minutes of the approval then signs in from a new network. |
A Teams room or phone set up with a code signs in from its own network in the same country, so it does not raise the phish alerts.
\nStorm-3119 (YAM Store) is an access broker that resells hijacked Microsoft 365 tenants to phishing operators. With a compromised Global Administrator it provisions an app (the PnP Management Shell service principal), grants it broad Microsoft Graph and SharePoint permissions such as AppCatalog.ReadWrite.All, and adds a client secret. From then on the app works with no user signed in: it resets passwords without forcing a change, assigns licenses and grants privileges. Microsoft and Health-ISAC seized the group's domains on October 14, 2026.
The app's client secret is a separate credential, so resetting the admin's password and revoking their sessions leaves the app working. Each step on its own also looks like ordinary admin work, which is why this detection follows one app through all of them.
\n| ID | Rule | Severity | Fires when |
|---|---|---|---|
| 102157 | EntraID_App_Takeover | Critical, High or Medium | Within 72 hours: critical when an app holding a high-risk permission acts on users, roles or licenses; high when a new or newly keyed app does; medium when an app gets a high-risk permission and a new secret. Each level alerts once per app, keyed on the admin who set the app up. Released October 19. |
| 102118 | EntraID_High_Risk_App_Permission | Medium | An app is granted a high-risk Graph or Exchange permission. On October 19 the list gained User.ReadWrite.All, User-PasswordProfile.ReadWrite.All and AppCatalog.ReadWrite.All. |
If you set up PnP or other automation apps yourself, expect a medium EntraID_App_Takeover alert that you can close as expected.
These cover techniques that the campaigns above, and others such as Midnight Blizzard, use once they have a foothold.
\n| ID | Rule | Severity | Fires when |
|---|---|---|---|
| 102120 | EntraID_Federation_Changed | High | A domain is set to federated, or its federation settings change. A rogue trust lets an attacker sign in as any user of the domain. |
| 102121 | EntraID_Elevated_Access | High | A Global Administrator elevates to User Access Administrator over all Azure subscriptions. |
| 102117 | EntraID_FIC_Changed | Medium | A federated identity credential is added to or removed from an app. Tokens from that issuer then sign in as the app without a secret, and secret rotation does not remove them. |
| 102119 | EntraID_Privileged_Role_Assigned | Medium | A user, group or app is given a privileged Entra ID role or the Azure Owner, User Access Administrator or RBAC Administrator role: directly, through PIM, or as eligible. |
| 102128 | EntraID_High_Risk_SignIn | High | Entra ID Protection rates a sign-in high risk at sign-in time. |
| 102125 | EntraID_MFA_Fatigue | High | More than 2 MFA denials or timeouts for one user in an hour (push bombing). |
| 102126 | EntraID_MFA_Fraud_Reported | High | A user reports an MFA prompt as fraud. |
| 102124 | EntraID_Brute_Force_User | Medium | More than 15 failed interactive sign-ins for one user in an hour, from any number of IPs. Catches botnets that send one attempt per IP. |
| 102127 | EntraID_Valid_Password_Blocked | Medium | Conditional Access blocks a sign-in right after the correct password was entered: whoever made the attempt knows the password. Users on unmanaged devices or in blocked countries also trigger it. |
These add events to the timeline, or feed the correlations above, without raising alerts. Some are used only inside a correlation and do not appear as events on their own.
\n| ID | Rule | Records |
|---|---|---|
| 102131 | EntraID_App_Created | An app registration or service principal created (managed identities and Microsoft's own apps excluded). Feeds EntraID_App_Takeover. |
| 102130 | EntraID_App_Credential_Change | A secret or certificate added to or removed from an app. Feeds EntraID_App_Takeover. |
| 102139 | EntraID_Admin_Password_Reset | A password reset by an admin or an app. Feeds EntraID_App_Takeover. |
| 102134 | EntraID_Role_Member_Added | A non-privileged role assignment. Feeds EntraID_App_Takeover. |
| 102156 | EntraID_App_License_Change | A license change made by an app. Feeds EntraID_App_Takeover. |
| 102116 | EntraID_DeviceCode_Consent | A user entered a device code. Recorded for every application. Feeds EntraID_DeviceCode_Phish and Office365_Broker_Phish. |
| 102110 | Office365_Broker_Consent | A broker sign-in approved on Microsoft's \"Are you trying to sign in?\" page. Feeds Office365_Broker_Phish. |
| 102108 | Office365_Device_Registration | A device registered to a user. Feeds Office365_Broker_Phish. |
| 102112 | EntraID_AiTM_Session | Sign-in session lines used to learn each user's networks. Used only inside the AiTM correlation. |
| 102107 | Office365_AiTM_Session | Mail and file activity with its session. Used only inside the AiTM correlation. |
| 102102 | EntraID_User_Add_Authentication_Method | An authentication method registered. Changed from a high alert to context: a passkey rollout raised one alert per user. |
| 102103 | EntraID_User_Update_Authentication_Method | An authentication method changed. Changed from a high alert to context, for the same reason. |
A rule taken out of the release is deleted from each instance at its next sync.
\n| ID | Rule | Status | Why, and what covers it now |
|---|---|---|---|
| 101907 | AzureAD_SFA_Login_Success | Retired | Older log format. Replaced by EntraID_SFA_Login_Success (102104). |
| 101984 | AzureAD_User_Add_Authentication_Method | Retired | Duplicated the new rule. Replaced by EntraID_User_Add_Authentication_Method (102102). |
| 102095 | AzureAD_User_Update_Authentication_Method | Retired | Duplicated the new rule. Replaced by EntraID_User_Update_Authentication_Method (102103). |
| 102122 | EntraID_Attack_Tool_UserAgent | Removed | A list of tool user agents was noisy and hard to validate: legitimate clients send library and headless-browser user agents too. The user agent stays on every sign-in alert. |
| 102123 | EntraID_Password_Spray_IP | Removed | Failures per source IP move to a daily password-spray report. EntraID_Brute_Force_User stays. |
| Alert | Check first | Respond |
|---|---|---|
EntraID_AiTM_Capture, Office365_AiTM_Capture | The URL the user clicked (often a search ad or an email link), the sign-in's IP and ASN, and whether the detected OS matches the user agent (a mismatch is common for a proxy). | Revoke the user's sessions now, before a replay. Reset the password, and review MFA methods and inbox rules. |
EntraID_AiTM_Session_Replay, EntraID_AiTM_Session_Activity | The new networks and countries, the apps used, and which mail or files were read. | Revoke sessions and refresh tokens, remove attacker MFA methods and inbox rules, and check payroll and banking changes. |
Office365_Broker_Phish, EntraID_DeviceCode_Phish | Ask the user whether they entered a code, and from what message. Check for a device registered right after the approval. | Revoke sessions, delete the attacker's registered device, and block the device-code flow with Conditional Access where it is not needed. |
EntraID_App_Takeover | The app's name and owner, who granted its permissions and added its secret, and which users it changed. | Contain the app first: disable it and remove its secrets and role assignments. Then secure the admin account. A password reset alone leaves the app's secret working. |
EntraID_Federation_Changed, EntraID_FIC_Changed | Whether the change was planned. For a federated credential, the issuer and subject, and whether the issuer is outside the tenant. | Revert an unplanned trust or credential, then review sign-ins through it. |
Rule IDs are the same on every instance. To find these alerts, search behavior events by rule name; each rule is also listed by name on the Behavior Rules page.
\nThe v2 interface is available on every instance, and every escalated case now carries an AI investigation report. Detections gain parser rules, and Entra ID audit and sign-in logs, including non-interactive sign-ins, can be collected through Azure Event Hubs.
\n/v2 after your instance's address, for example https://<companyname>.app.ingext.io/v2. The current interface stays at the same address.Fluency now supports parser rules alongside EventWatch rules. A parser rule looks like an EventWatch rule without the event selector: instead of selecting events from the whole stream, it receives the events a parser hands to it on a named channel.
\nPlatform_Channel, for example Platform_Channel(\"Office365Exchange\", {obj}).fpl_rule processor on that channel does the matching and captures the attributes, and a match goes straight to the correlation service, bypassing EventWatch.See Detections.
\nSee Entra ID Audit via Event Hubs.
", "url": "https://manual.ingext.io/release/2026-10-13-platform-update", "title": "October 2026 Platform Update", "summary": "The v2 interface is available on every instance, and every escalated case now carries an AI investigation report. Detections gain parser rules, and Entra ID audit and sign-in logs, including non-interactive sign-ins, can be collected through Azure Event Hubs.", "date_modified": "2026-10-13T00:00:00.000Z", "author": { "name": "Sysadmin", "url": "https://github.com/SecurityDo" }, "tags": [ "release", "platform" ] }, { "id": "https://manual.ingext.io/release/v2.6.50", "content_html": "A milestone release. EventWatch now runs under the job manager, which extends exactly-once processing through rule evaluation and lets the processing pipeline scale past 1 TB per day. The release also adds KQL search history, a send_email MCP tool, and SentinelOne, CrowdStrike Falcon, LDAP, Duo and Abnormal Security applications.
send_email sends email through the instance's notification endpoints. See MCP Server.Five more data sources can be queried with KQL as typed tables: Zscaler, Cisco Meraki, F5 BIG-IP LTM, Palo Alto Networks Cortex alerts and incidents, and Qualys, each released with sample queries. Windows audit events, whose schema shipped in v2.6.16, gain sample queries too.
\n| Data type | Source |
|---|---|
Zscaler | Zscaler |
Meraki | Cisco Meraki |
F5BigIPLTM | F5 BIG-IP Local Traffic Manager |
CortexAlert, CortexIncident | Palo Alto Networks Cortex XDR |
Qualys | Qualys |
They join the FortiGate traffic and event tables and the Office365, WindowsAudit, GSuite and CloudTrail schemas added in v2.6.16. Sample queries for WindowsAudit, covering event logs from Windows servers, ship with this release.
The record's time is the timestamp column, so a time filter is written where timestamp > ago(1d). Columns from the Azure Monitor tables, such as TimeGenerated, do not exist here.
WindowsAudit
| where timestamp > ago(1d)
| summarize Events = count() by EventID
| order by Events desc
See KQL for the data model and query cost.
", "url": "https://manual.ingext.io/release/2026-06-30-kql-data-types", "title": "New KQL Data Types", "summary": "Five more data sources can be queried with KQL as typed tables: Zscaler, Cisco Meraki, F5 BIG-IP LTM, Palo Alto Networks Cortex alerts and incidents, and Qualys, each released with sample queries. Windows audit events, whose schema shipped in v2.6.16, gain sample queries too.", "date_modified": "2026-06-30T00:00:00.000Z", "author": { "name": "Sysadmin", "url": "https://github.com/SecurityDo" }, "tags": [ "release", "kql" ] }, { "id": "https://manual.ingext.io/release/v2.6.28", "content_html": "The Microsoft 365 applications can be set up with an app registration you create yourself, instead of through admin consent. Workday, Abnormal Security, Azure Event Hubs and Qualys move to the new platform, and resource polling for Office 365 and SentinelOne runs as a separate job.
\nThe Office365, Office365 Resource Watch and Azure Directory Audit templates support manual configuration as well as admin consent:
\nOne app registration that holds the permissions of all three applications can serve all three, using the same client ID and secret.
\nManual setup suits a tenant where the consent flow is blocked, for example by browser protection, or where policy requires an app registration you own. Admin consent remains the default.
\nSee Install Application from Template, Office 365 Activity API, Office 365 Resource Watch and Azure AD audit.
\nThese applications are now available on the new platform:
\n\nThe first versioned release of Ingext Skills adds two skills that turn natural-language questions into validated, ready-to-run queries, with no query language required: ingext-kql for events in the data lake, and ingext-promql for platform health. Ten skills ship in this release, and all of them are open source.
Ask a question about your logs and get back a correct KQL query against sign-ins, audit logs, file activity and network traffic. For example:
\nQueries are checked against the table schemas and validated before you run them.
\nAsk about throughput, volume and reliability across the platform. For example:
\nAnswers come only from the known metrics catalog, so the skill does not guess at metric names.
\nThe skills, release notes and sources are in the ingext_skills repository. Each skill carries a version number; to check whether an installed skill is current, compare it with the released version in the repository. In Claude, installed skills are listed under Customize → Skills.
\nThe skills work through the platform's MCP server. See MCP Server.
", "url": "https://manual.ingext.io/release/2026-06-18-ingext-skills", "title": "Ingext Skills: Ask Your Data in Plain English", "summary": "The first versioned release of Ingext Skills adds two skills that turn natural-language questions into validated, ready-to-run queries, with no query language required: ingext-kql for events in the data lake, and ingext-promql for platform health. Ten skills ship in this release, and all of them are open source.", "date_modified": "2026-06-18T00:00:00.000Z", "author": { "name": "Sysadmin", "url": "https://github.com/SecurityDo" }, "tags": [ "release", "ai" ] } ] }