Resetting Passwords Leaves This Trap Intact
An incident can appear contained while its sign-in path still answers to somebody else. Replacing credentials should not substitute for checking that path.
Varonis’s controlled TrustSink demonstration required privileged compromise: Authentication Policy Administrator or Global Administrator. After Microsoft’s genuine sign-in, a convincing repeat password prompt captured plaintext, supplied a signed, cryptographically valid token and completed application access without error. Resets left the provider able to capture replacements. This establishes neither initial access nor observed exploitation.
Check authority
Microsoft’s management guide distinguishes policy configuration from app approval. That policy administrator role permits configuration; app consent needs at least Privileged Role Administrator. An unconsented method can be saved disabled, but cannot be enabled until consent exists. Assess the account’s actual rights and existing approvals before concluding which changes it could make.
The protocol reference describes checks on the provider’s token signature alongside its claims and issuer. BlackTree’s assessment is that this establishes which configured party answered; it cannot make a dishonest operator trustworthy. A completed login is therefore insufficient evidence that the path is safe.
Restore trust
Delete the unapproved method, app, service principal, grants, callbacks and keys used for signing; then rotate affected credentials. BlackTree also recommends invalidating sessions and reviewing subsequent activity. Record which objects were removed and which users need recovery, rather than treating a successful reset as proof of containment.
- Inventory every External Authentication Method provider, assigned group and business owner.
- Alert on new
externalAuthenticationMethodConfigurationentries outside an approved change. - Correlate Authentication Methods Policy revisions with app registrations, new service principals and consent grants.
- Review redirect and reply URLs, signing keys and issuers for infrastructure the organisation does not control.
- Search sign-in logs for unfamiliar external issuers carrying hardware-key claims such as
hwk. - Limit standing access to both roles required by researchers.
- Update the identity incident runbook so rogue providers are removed before password resets begin.
A legitimate third-party authentication integration may create similar objects, so detection cannot be a simple ban on external providers. The reliable baseline is ownership: every provider, service principal, application, permission grant, callback and signing key along this sign-in route should map to an approved service and named operator.
Restoring trust means checking who controls both the screen and the token exchange. Credential rotation belongs inside that investigation, with a named owner and evidence of the removal.
Sources
- Varonis research, dated 16 September 2026.
- BleepingComputer, 22 September 2026, 17:45 displayed; timezone unlabelled.
- Microsoft management guide and provider reference, both last updated 24 February 2026.
