An unauthenticated account-takeover bug in one of the most widely deployed open-source identity providers. A credential stealer that impersonates the Windows lock screen inside a trusted collaboration channel. And a policy toggle that should have existed two years ago. Today’s brief covers three stories that converge on a single operational truth: identity infrastructure is the primary attack surface, and the defenses are only as strong as the weakest flow in the chain.

In the News

Keycloak Password-Reset RCE Lets Unauthenticated Attackers Hijack Any Account (CVE-2026-18963, CVSS 9.1)

Keycloak — the open-source IAM platform that underpins SSO, federation, and user management for thousands of enterprise deployments — has a critical flaw in its password-reset flow. CVE-2026-18963 allows an unauthenticated remote attacker to trigger a password reset for any user account in the deployment. No prior credentials. No MFA bypass. No social engineering. The attacker sends a crafted request to the password-reset endpoint, and the target account’s password is overwritten.

The severity here is not theoretical. Keycloak is the identity backbone for organizations that chose open-source IAM over commercial platforms like Okta or Entra ID. If an attacker resets an admin account, they control the identity provider itself — every downstream application that trusts Keycloak for authentication is compromised in a single step. This is MITRE ATT&CK T1098 (Account Manipulation) at the identity-provider tier, which is as high-impact as it gets.

Red Hat shipped patches immediately. The remediation is straightforward: patch Keycloak to the fixed version and audit password-reset logs for anomalous activity. Specifically, look for reset events targeting privileged accounts, resets originating from unexpected IP ranges, or reset volume spikes that deviate from baseline. If your organization federates Keycloak through a downstream MFA provider, confirm that the MFA enforcement still applies after a password reset — some configurations re-authenticate without a second factor after a reset flow completes.

What defenders should do: Patch immediately. Audit password-reset audit logs for resets targeting admin or service accounts. Enforce phishing-resistant MFA as a compensating control so that a compromised password alone cannot complete authentication.

SynkLoader Malware Steals Credentials via Fake Windows Lock Screens in Teams Phishing

A new malware family called SynkLoader is being distributed through Microsoft Teams phishing messages. The attack chain is deceptively simple: a Teams message contains a link or attachment that drops SynkLoader on the endpoint. Once running, SynkLoader renders a full-screen overlay that is a pixel-perfect replica of the Windows lock screen. The user, believing their session has locked, types their password. SynkLoader captures it and exfiltrates it to the attacker’s command-and-control infrastructure.

This is credential theft inside a trusted channel, which makes it particularly effective. Users do not question a lock screen prompt — it is a reflexive action. And because the delivery vector is Teams rather than email, traditional email security controls never see the payload. The technique maps to MITRE ATT&CK T1056.002 (Input Capture: GUI Input Capture) for the credential harvest and T1566.003 (Phishing: Phishing via Service) for the delivery mechanism.

The primary countermeasure is phishing-resistant MFA — specifically FIDO2 or passkeys. If the user authenticates with a hardware-bound credential, the password SynkLoader captures is insufficient to replay the session. The secondary countermeasure is EDR that detects full-screen overlay behavior and unsigned processes rendering OS-lookalike UI elements.

What defenders should do: Deploy phishing-resistant MFA (FIDO2/passkeys) to eliminate password replay. Ensure EDR policies flag full-screen overlay processes. Block external Teams message delivery from untrusted tenants where operationally feasible.

Microsoft Teams Now Lets Admins Block External Bots from Meetings

Microsoft released a new meeting-protection policy that lets Teams administrators block external bots from joining meetings. The policy is a direct response to the TWINLOOT and CoSnitch campaigns, where attackers registered malicious OAuth applications that joined meetings autonomously, exfiltrated transcripts, and injected prompts into AI-assisted meeting summaries.

The policy is off by default. Admins must enable it manually in the Teams admin center. This is the non-human identity governance problem in miniature: most organizations cannot answer the question “which OAuth apps have meeting-join permissions in our tenant?” without a dedicated discovery tool. The new toggle is necessary but insufficient — it blocks external bots at the meeting boundary but does nothing to inventory or risk-score the internal OAuth apps that already have delegated permissions.

What defenders should do: Enable the external bot blocking policy in the Teams admin center. Conduct an OAuth app inventory across your Microsoft 365 tenant. Revoke meeting-join permissions from any app that does not have a documented business justification.

Defender Action Items

  • Keycloak (CVE-2026-18963): Patch to the fixed version immediately. Query password-reset audit logs for resets targeting admin or service accounts from unexpected source IPs. Enforce phishing-resistant MFA downstream of Keycloak so password-only authentication is never sufficient.
  • SynkLoader / Teams phishing: Deploy FIDO2 or passkey authentication to eliminate password replay risk. Configure EDR to alert on unsigned processes rendering full-screen overlays. Review Teams external access policies and restrict inbound messages from untrusted tenants.
  • Teams external bot policy: Enable the new meeting-protection policy in the Teams admin center. Inventory all OAuth apps with delegated meeting-join or calendar-read permissions. Revoke unnecessary grants.
  • Device-code phishing (from threat pulse): Monitor OAuth consent logs for device-code flow grants from untrusted locations. Consider conditional access policies that block device-code flows entirely for high-privilege accounts.
  • AWS key sprawl: Scan public repositories for exposed AWS access keys. Rotate any long-lived keys and migrate to short-lived STS credentials. Enforce least-privilege IAM policies and enable AWS CloudTrail for key-usage auditing.

Detection Queries

Anomalous Keycloak password-reset activity — Splunk SPL query targeting reset events for privileged accounts or unusual volume:

index=keycloak sourcetype="keycloak:events" event_type="RESET_PASSWORD"
| stats count by user, src_ip, _time
| where count > 3 OR match(user, "admin|root|service")
| sort -count

This query surfaces password-reset events where a single user is reset more than three times or where the target is a privileged account. Tune the threshold to your baseline. False positives are low — legitimate mass resets should be correlated with a change-management ticket.

References

Subscribe to The Identity Brief

Get The Identity Brief in your inbox (Mon/Wed/Fri) — Human, machine, and AI identity security — NHI, ITDR, and the IAM market.