Threat Hunt Plan: ABB dynovaPRO and Keycloak Reset-Credentials Account Takeover — Identity, Cloud Session and DER Control Hunt

Revision 1.1 — September 22, 2026

Hunt Objective and Scope

This hunt determines whether the Keycloak reset-credentials authentication bypass (CVE-2026-18963, CVSS v3.1 9.1) was used against the organization, either through its ABB dynovaPRO energy management accounts before ABB's cloud fix on 2026-08-27 12:00 (CEST), or through any self-hosted Keycloak or Red Hat build of Keycloak server the organization operates. The objective is to identify accounts whose passwords were reset without the owner's involvement, sessions established with those credentials, and any follow-on configuration change or control command issued to EV chargers, battery energy storage, or photovoltaic assets supervised by dynovaPRO.

Environment in scope: internet-facing and internal Keycloak 26.x servers (bare metal, VM, container, Kubernetes) and their reverse proxies; Active Directory where Keycloak federates users over LDAP with password writeback; corporate email that receives dynovaPRO notification mail; endpoints used by facility, fleet and energy managers to reach dynovaPRO; and site OT networks hosting chargers, storage and PV inverters with their site controllers or gateways. Affected upstream releases are 26.0.0–26.4.14, 26.5.0–26.6.5 and 26.7.0–26.7.1; releases before 26.0.0 are outside the published affected range.

Time window: 2026-08-17 (earliest public disclosure date cited; the CVE record lists 2026-08-18) to present for self-hosted Keycloak; 2026-08-17 to 2026-08-27 12:00 CEST for dynovaPRO account resets, extended to present for sessions and control activity attributable to any account reset in that window. Where logging retention allows, extend back 30 days before disclosure to establish a password-reset baseline.

Exploit mechanics that drive the detections (from the public proof of concept and the upstream fix): the attacker opens the reset-credentials flow, posts tryAnotherWay=on to corrupt the flow's session state, submits the victim's username (this sends the victim a genuine reset email), re-enters the flow, and is advanced to the UPDATE_PASSWORD required action without ever presenting the emailed action token. The observable difference from a legitimate reset is therefore a password update with no preceding EXECUTE_ACTION_TOKEN event or /login-actions/action-token request in the same authentication session.

External attack-surface hypothesis H-1 is included because Keycloak is a web-facing identity service that is routinely published to the internet; execute it first, as its output scopes H-2. CVE-2026-18963 was not in the CISA KEV catalog as of the 2026-09-21 catalog release.

Hypotheses and Hunt Procedures

Hypothesis 1: an external actor can reach an internet-facing instance of Keycloak or Red Hat build of Keycloak operated by the organization, observable as an exposed Keycloak login or admin service in passive internet-scan indices. Execute FIRST; its output scopes the internal hypotheses.

MITRE ATT&CK: Reconnaissance | T1595 — Active Scanning | defender-side passive discovery of the Keycloak endpoints an actor would enumerate before sending crafted reset-credentials requests. Initial Access | T1190 — Exploit Public-Facing Application | CVE-2026-18963 is exploitable by any unauthenticated party that can reach the realm login endpoints. ICS | T0883 — Internet Accessible Device | applies where the Keycloak realm fronts an OT or DER management application.

Collection Queries — passive external indices (STRICTLY passive; never probe target infrastructure; API keys by env-var name only: SHODAN_API_KEY, CENSYS_API_SECRET, CENSYS_ORG_ID, NETLAS_API_KEY):

Analysis Queries:

• Attribute each hit with at least two independent ownership signals (PTR, ASN, certificate CN/SAN, RDAP, own cloud inventory) before reporting; an unattributable hit is inconclusive, not negative.
• Version-triage each banner or login-page resource path (Keycloak serves theme resources under a versioned resources path) against the affected ranges, and record each index's scan timestamp; a stale banner is a prompt to verify, not evidence of safety.
• Corroborate in at least two of Shodan, Censys and Netlas before escalating. Absence from an index is evidence only that the index did not observe the host.
• Historical pivot: establish whether each exposed instance was reachable between 2026-08-17 and its patch date; continuous exposure across that window means the instance should be presumed enumerated and receives the exhaustive H-2 pass.
• Record whether the exposed realm fronts an OT, DER or remote-access application; internet reachability of identity infrastructure serving a control environment is a finding under IEC 62443 and NERC CIP independent of confirmed exploitation.

Hypothesis 2: an unauthenticated actor has reset user passwords on a self-hosted Keycloak server through the reset-credentials flow without the email verification step, observable as SEND_RESET_PASSWORD followed by UPDATE_PASSWORD/UPDATE_CREDENTIAL for the same user with no intervening EXECUTE_ACTION_TOKEN event, and as reset-credentials POSTs carrying tryAnotherWay=on, in Keycloak event logs, reverse-proxy access logs and LDAP writeback events in Active Directory.

MITRE ATT&CK: Initial Access | T1190 — Exploit Public-Facing Application | crafted requests to /realms/<realm>/login-actions/reset-credentials bypass email verification. Persistence | T1098 — Account Manipulation | the attacker sets a new password on the victim account. Defense Evasion | T1078 — Valid Accounts | subsequent sign-ins use the attacker-set credential and appear legitimate.

Collection Queries:

CrowdStrike Falcon LogScale (CQL) — inventory every host running a Keycloak server and extract the distribution version where the install path carries it (the official container image installs to an unversioned /opt/keycloak, so an empty kcVersion means "check the image tag", not "unaffected"):

CrowdStrike Falcon LogScale (CQL) — inbound connections from public addresses to the default Keycloak HTTP/HTTPS listener ports:

Keycloak server-side logging prerequisites (enable before the hunt if not already on): Realm settings → Events → User events settings → Save events ON with SEND_RESET_PASSWORD, RESET_PASSWORD, EXECUTE_ACTION_TOKEN, UPDATE_PASSWORD, UPDATE_CREDENTIAL, LOGIN and LOGIN_ERROR selected; Admin events ON with representation. The jboss-logging listener writes SUCCESS events at DEBUG by default, so raise it to INFO or they never reach stdout; for the Datadog Keycloak integration, also emit JSON over syslog. Keycloak 26 logs both the deprecated UPDATE_PASSWORD and the new UPDATE_CREDENTIAL (credential_type=password) for the same change; hunt on both. Saved events in the database are retained only per the realm's expiration setting — export them before they age out.

BPF / tcpdump — rolling capture on the reverse-proxy-to-Keycloak backend segment where TLS is terminated at the proxy (plaintext HTTP on the backend):

Datadog Log Search (Keycloak integration; source:keycloak is the integration's fixed source value — attribute names below depend on your pipeline, confirm them in the Log Explorer facet panel):

Datadog Live Process Monitoring (Infrastructure > Processes — NOT a log source):

Data source gap note: if Keycloak event logging was not enabled at INFO before the hunt, reset events for the exposure window may exist only in the realm's saved-events store (Realm settings → Events → User events) or not at all; fall back to reverse-proxy access logs (source:nginx or source:haproxy) and Active Directory LDAP writeback events below, and record the gap in the report.

Windows Event IDs to collect (domain controllers, where Keycloak LDAP user federation has password writeback):

• 4724 — An attempt was made to reset an account's password (Subject = Keycloak LDAP bind account)
• 4723 — An attempt was made to change an account's password
• 4738 — A user account was changed (pwdLastSet updated)
• 4624 — Successful logon for a reset account shortly after the reset (Logon Type 3 or 10)

YARA file-system scan — staged exploit scripts on Keycloak hosts, jump hosts and analyst workstations:

Analysis Queries:

CrowdStrike Falcon LogScale (CQL) — where Keycloak event logs are ingested into Falcon Next-Gen SIEM, flag users whose password changed after a reset request with no EXECUTE_ACTION_TOKEN event in between (the emailed link was never used):

CrowdStrike Falcon LogScale (CQL) — rarest source IPs completing password changes (one IP resetting many users is the campaign signature):

Wireshark display filters (backend PCAP):

Datadog Log Analytics:

Datadog Audit Trail (Datadog itself federated to Keycloak via SAML — a hijacked Keycloak account signs straight into Datadog):

Datadog CloudTrail (AWS IAM federated to Keycloak via SAML or OIDC):

Datadog Monitor:

Windows Event Log PowerShell analysis — LDAP writeback resets performed by the Keycloak bind account, followed by a logon within one hour:

YARA memory scan — scripting interpreters holding a crafted reset-credentials request (Falcon RTR can run the same command remotely via runscript on an isolated host):

Hypothesis 3: an unauthenticated actor has taken over ABB dynovaPRO user accounts belonging to the organization before the 2026-08-27 cloud fix, observable as unsolicited dynovaPRO password reset emails in mail logs followed by user-reported lockouts, ABB account notifications, or new sign-in sources in dynovaPRO user activity.

MITRE ATT&CK: Initial Access | T1078.004 — Valid Accounts: Cloud Accounts | the attacker signs in to the dynovaPRO SaaS tenant with a credential it set itself. Persistence | T1098 — Account Manipulation | the victim's password is replaced without their knowledge.

Collection Queries:

Exchange Online message trace — identify the dynovaPRO notification sender from one known-good reset mail first. Get-MessageTraceV2 returns at most 10 days per query and 5000 rows, and reaches back 90 days, so the window is split in two and should be run before 2026-11-15:

Datadog Log Search (email gateway or Microsoft 365 logs forwarded to Datadog; adjust source to your integration's tag):

CrowdStrike Falcon LogScale (CQL) — endpoints that resolve dynovaPRO hosts, to build the population of legitimate users (ABB does not publish the dynovaPRO FQDN; confirm it from a user's browser and tighten the pattern):

BPF / tcpdump — site-gateway uplink capture to preserve cloud-to-site sessions for H-4 (metadata only; payload is TLS):

Windows Event IDs to collect: none are generated for a SaaS password reset; collect 4624/4625 on the manager workstations only if a reset user also reused the same password for a domain account (credential reuse check).

Analysis Queries:

• Join the reset-mail list against the user roster: every recipient who did not request a reset (confirm with the user) is a presumptive takeover and must reset per ABB's direction; ABB has already disabled accounts it identified, so any account still active with an unrequested reset needs a direct query to ABB service.
• Request from ABB (via the local ABB service organization) the sign-in and change history for each affected user between 2026-08-17 and the account's forced reset.

CrowdStrike Falcon LogScale (CQL) — hosts with a first-ever dynovaPRO resolution in the window (a new machine using a manager's account); 1786924800000 is 2026-08-17T00:00Z:

Wireshark display filters (site uplink PCAP — TLS metadata):

Datadog Log Analytics:

Datadog Audit Trail: not applicable to the dynovaPRO SaaS itself; use the Hypothesis 2 Audit Trail query where Keycloak also backs Datadog SSO.

Datadog Monitor:

Windows Event Log PowerShell analysis — failed-then-successful domain logons for reset users (password reuse by the attacker):

Hypothesis 4: an actor holding a hijacked dynovaPRO account has issued unauthorized configuration changes or control commands to EV chargers, battery energy storage or PV inverters, observable as setpoint, schedule or mode changes originating from the cloud-connected site controller in OT monitoring platforms, site controller logs and SNMP data.

MITRE ATT&CK: ICS Initial Access | T0859 — Valid Accounts | control arrives through an authenticated cloud session. ICS Impair Process Control | T0836 — Modify Parameter | charging limits, dispatch and inverter setpoints altered. ICS Impair Process Control | T0855 — Unauthorized Command Message | start/stop or mode commands relayed from cloud to device.

Collection Queries:

OT Data Collection: Claroty xDome — `Network → Communication → Communication Analysis` → Side A: the DER site controller/gateway asset · Communication: `Protocol = Modbus`, `Port = 502` · Side B: `Purdue Level = 1` · Time Frame `Past Month`; then `Alerts & Threats → OT Activity` filtered to write and mode-change events for the same assets, exported CSV. API: `POST /api/v1/ot_activity_events/`.

OT Data Collection: Claroty CTD — on-premises: Assets filtered to the DER site controller and inverter/BMS assets → Events export for the window; retrieve PCAP from the CTD appliance while it is still within local retention.

OT Data Collection: Dragos Platform — Query the Industrial Protocols QFD for Modbus writes from the site controller to battery and inverter assets between 2026-08-17 and present; in the `Communications Hub`, filter source = site controller, protocol = Modbus, and export PCAP for the window from SiteStore.

OT Data Collection: Nozomi Guardian — run the N2QL queries below via `GET /api/open/query/do?query=<N2QL>` and review the `Variable view` for setpoint excursions.

OT Data Collection: Armis Centrix — ASQ for cloud sessions from site assets to dynovaPRO and for Modbus sessions into storage and inverter devices:

OT Data Collection: Tenable OT — `Events`: filter `Event Category` = Configuration Events with event types `Change in state` across the window for the site controller and inverter assets; API `POST /graphql` `eventAggregations(...)`.

OT Data Collection: Forescout eyeInspect — `Command Center → Alerts` for the window with `l7_proto` = Modbus and `src_ip` = the site controller; retrieve the PCAP for each `alert_id`.

SNMP polling — site switch port facing the DER site controller and the controller itself:

BPF / tcpdump — Modbus TCP writes on the site OT segment:

Historian / SCADA correlation: export battery state-of-charge, charge/discharge power, charger session and inverter active/reactive power setpoints for the window; mark every step change with no matching operator action, schedule or ABB service ticket.

CrowdStrike Falcon LogScale (CQL) — Windows or Linux site controllers and HMIs with a Falcon sensor: outbound sessions to dynovaPRO hosts, by process:

Datadog Log Search (site controller syslog forwarded to Datadog):

Windows Event IDs: on Windows-based site HMIs, collect 4624 (Logon Type 10) and 4688 process creation to rule out a parallel local path.

Analysis Queries:

Wireshark display filters (Modbus writes and function codes):

Baseline deviation: compare the register write set and write rate per source from the site controller against the 30 days before 2026-08-17; a new register, a new writer, or writes outside operating schedules are escalation candidates.

CrowdStrike Falcon LogScale (CQL) — rare processes on site controllers reaching dynovaPRO (anything other than the vendor agent):

Datadog Log Analytics:

Datadog Audit Trail: not applicable; control activity is in the OT and site-controller sources above.

Datadog Monitor:

Windows Event Log PowerShell analysis — new services or scheduled tasks on Windows site HMIs in the window:

Threat Actor Profile

Opportunistic actors: the most likely population. A public Python proof of concept and a single-prerequisite attack (a known username or email address) put the flaw within reach of low-sophistication actors who spray reset requests at internet-facing Keycloak realms. ABB's observation of 26 password change events across 9 customers is consistent with this testing or reconnaissance pattern. TTPs: scanning for /realms/ endpoints, scripted reset-credentials requests, credential set and immediate sign-in.

Ransomware and initial access brokers: moderate sophistication; value hijacked identity-provider accounts, including realm administrators, as a single sign-on foothold into every federated application, including VPNs and cloud consoles. TTPs: T1190, T1078, follow-on MFA registration and session persistence.

Hacktivists: low to moderate sophistication; energy and EV charging assets are attractive for visible disruption. Access path is the dynovaPRO account itself; TTPs are parameter changes and start/stop commands (T0836, T0855).

Nation-state actors: high sophistication; interest in distributed energy resources and grid-edge control is documented, and a cloud management plane that aggregates many sites is a high-value target. No attribution to this CVE has been published.

Insiders: a former employee who knows colleagues' usernames or email addresses needs no other information to exploit the flaw.

Data Sources Required

Identity: Keycloak user and admin event logs (jboss-logging at INFO, or the realm saved-events store), Keycloak HTTP access logs, reverse-proxy or load-balancer access logs, Active Directory Security logs where Keycloak performs LDAP password writeback.

Email: Exchange Online message trace (90-day reach, 10-day windows) or secure email gateway logs covering dynovaPRO notification mail.

Endpoint: CrowdStrike Falcon (ProcessRollup2, DnsRequest, NetworkReceiveAcceptIP4), Windows Security, System and Task Scheduler logs, Sysmon where deployed.

Network: PCAP from the proxy-to-Keycloak backend and the DER site uplink and OT segment; firewall and NetFlow at the site edge.

OT/ICS: Claroty xDome or CTD, Dragos, Nozomi, Armis, Tenable OT and Forescout eyeInspect exports; historian trends for charger, storage and PV setpoints; site controller logs; SNMP counters and traps.

Vendor: dynovaPRO user sign-in and change history requested from ABB service for affected accounts.

External attack surface: Shodan, Censys and Netlas queried read-only for exposed Keycloak services; the CISA KEV catalog; the organization's authoritative public IP and cloud asset inventories, without which exposure attribution cannot be made.

Detection Signatures

SIGMA rules:

Snort/Suricata rules (Suricata 8 syntax; deploy on the plaintext proxy-to-Keycloak backend or on a TLS-inspecting sensor):

YARA rules:

Keycloak_ResetCreds_Exploit_Script targets staged exploit tooling on disk, keyed to the public proof of concept and any script built on the same chain. It requires the reset-credentials path together with the tryAnotherWay flow-corruption parameter or two of the Keycloak form identifiers the chain scrapes, and a scripting HTTP-client marker; Keycloak's own theme templates contain the form ids but not a client library, and the 200 KB cap excludes Keycloak JARs and log archives. The PoC's default User-Agent string is a standalone high-confidence branch.

Keycloak_ResetCreds_Exploit_Memory targets the in-memory form of the same tooling in a running interpreter, where the request has been assembled but no file may remain on disk. It requires the tryAnotherWay=on form body or the PoC User-Agent, alongside an update-password form field, so a browser rendering a normal Keycloak page, which never holds both, does not match; scan interpreters only, not browsers.

Indicators of Compromise

Network IOCs: POST to /realms/<realm>/login-actions/reset-credentials with body tryAnotherWay=on; several reset-credentials re-entries for the same tab_id from one client; POST to /login-actions/required-action?execution=UPDATE_PASSWORD with no preceding GET to /login-actions/action-token from the same client; User-Agent cve-2026-18963-poc (public PoC default — trivially changed, so absence proves nothing); one source IP completing resets for several users; external access to the master realm admin console.

Host IOCs: Keycloak SEND_RESET_PASSWORD followed by UPDATE_PASSWORD/UPDATE_CREDENTIAL for the same userId with no EXECUTE_ACTION_TOKEN in between; AD event 4724 by the Keycloak bind account followed by 4624 from an unfamiliar address; scripts matching Keycloak_ResetCreds_Exploit_Script on disk.

OT/operational IOCs: dynovaPRO reset emails that the recipient did not request before 2026-08-27 12:00 CEST (the exploit sends the victim a genuine reset email); charger, storage or PV setpoint and schedule changes with no operator record; new Modbus writers or register sets from the DER site controller; controller restarts (coldStart/warmStart traps) coinciding with cloud sessions.

External-exposure indicators: a two-engine-confirmed, owned Keycloak login or admin service visible in passive indices with an affected version and exposure spanning 2026-08-17 to its patch date.

False Positive Baseline

1. Users legitimately requesting their own password reset: these show an EXECUTE_ACTION_TOKEN event and an action-token request between the reset email and the password update.

2. Help-desk or administrator-initiated resets through the Keycloak admin console, recorded as admin events rather than user reset-credentials events.

3. Users who genuinely select "Try Another Way" during sign-in with multiple credential types; the reset-credentials flow rarely offers it, so repeated occurrences from one client remain suspicious.

4. Keycloak LDAP synchronization jobs updating AD attributes (4738) without a 4724 reset.

5. ABB's own remediation: users forced through a reset after 2026-08-27 by ABB, and dynovaPRO accounts ABB disabled; these appear as resets without prior compromise and should be confirmed with ABB.

6. Scheduled charging, storage dispatch and PV curtailment programs that change setpoints on a recurring schedule.

7. Security scanners, authorized penetration tests using the public PoC, and uptime monitors requesting Keycloak pages from fixed addresses.

8. EASM misattribution: shared hosting, CDN or cloud load-balancer addresses returning a Keycloak page that belongs to another tenant; require two ownership signals before treating a hit as the organization's.

Escalation Criteria

1. Any Keycloak user whose password changed after a reset request with no EXECUTE_ACTION_TOKEN in between, or any single IP completing resets for two or more users.

2. Any reset-credentials POST carrying tryAnotherWay=on followed by a required-action UPDATE_PASSWORD POST from the same client, or any request with the cve-2026-18963-poc User-Agent that was not an authorized test.

3. Any dynovaPRO user who received an unrequested reset email and whose account shows sign-ins or changes that the user does not recognize.

4. Any unexplained charger, battery or PV setpoint, schedule or mode change during or after the window that correlates with a reset account's session.

5. Any YARA hit on Keycloak_ResetCreds_Exploit_Script against files on Keycloak servers, jump hosts or user workstations.

6. Any YARA hit on Keycloak_ResetCreds_Exploit_Memory against a running interpreter process.

7. A two-engine-confirmed, owned, internet-exposed Keycloak instance running an affected version, or one whose exposure spans the 2026-08-17 to patch-date window.

8. Discovery of an exposed Keycloak instance not in the organization's asset inventory (shadow infrastructure), or a future CISA KEV listing for CVE-2026-18963.

9. A reset of any Keycloak realm administrator (including the master realm) or AD 4724 by the Keycloak bind account for a privileged or OT administrative account.

Hunt Completion Criteria and Reporting

The hunt is complete when every Keycloak server has been inventoried with version and patch status; Keycloak, proxy and AD reset activity has been reviewed for the full window (or the logging gap documented); every dynovaPRO reset email in the window has been dispositioned with the recipient; OT and historian data for every site supervised by dynovaPRO has been reviewed for unexplained changes; sessions for any account reset in the window have been revoked; and the external sweep has been completed in at least two engines.

The report must contain: the Keycloak inventory and patch status; the list of reset events and dispositions; affected dynovaPRO users and the ABB-provided history; OT change findings with timestamps and assets; YARA scan coverage and results for both rules; escalations raised; external sweep coverage, per-hit provenance (engine, query, scan timestamp, ownership signals); data source gaps; and a recommendation to make the Keycloak exposure sweep and reset-without-token monitors recurring controls.

Advisory IoC Reference