Detection rules › Panther
Okta Username Above 52 Characters Security Advisory
On October 30, 2024, a vulnerability was internally identified in generating the cache key for AD/LDAP DelAuth. The Bcrypt algorithm was used to generate the cache key where we hash a combined string of userId + username + password. Under a specific set of conditions, listed below, this could allow users to authenticate by providing the username with the stored cache key of a previous successful authentication. Customers meeting the pre-conditions should investigate their Okta System Log for unexpected authentications from usernames greater than 52 characters between the period of July 23rd, 2024 to October 30th, 2024. https://trust.okta.com/security-advisories/okta-ad-ldap-delegated-authentication-username/
Rules detecting the same action
Other rules on this platform that filter on the same API call or operation.
- Failed Logins from Unknown or Invalid User (Kusto)
- First Occurrence of Okta User Session Started via Proxy (Elastic)
- High-Risk Admin Activity (Kusto)
- Multiple Okta Sessions Detected for a Single User (Elastic)
- Multiple Okta User Authentication Events with Same Device Token Hash (Elastic)
- New Device/Location sign-in along with critical operation (Kusto)
- Okta AiTM Session Cookie Replay (Elastic)
- Okta Login Signal (Panther)
Rule body yaml
AnalysisType: saved_query
QueryName: "Okta Username Above 52 Characters Security Advisory"
Description: >
On October 30, 2024, a vulnerability was internally identified in generating the cache key for AD/LDAP DelAuth. The Bcrypt algorithm was used to generate the cache key where we hash a combined string of userId + username + password. Under a specific set of conditions, listed below, this could allow users to authenticate by providing the username with the stored cache key of a previous successful authentication.
Customers meeting the pre-conditions should investigate their Okta System Log for unexpected authentications from usernames greater than 52 characters between the period of July 23rd, 2024 to October 30th, 2024.
https://trust.okta.com/security-advisories/okta-ad-ldap-delegated-authentication-username/
Query: |
SELECT
p_event_time as p_timeline,
*
FROM
panther_logs.public.okta_systemlog
WHERE
p_occurs_between('2024-07-22 00:00:00Z','2024-11-01 00:00:00Z')
AND actor:type = 'User'
AND eventType = 'user.session.start'
AND outcome:result = 'SUCCESS'
AND LEN(actor:alternateId) >= 52
ORDER by p_event_time ASC NULLS LAST
LIMIT 100
Detection logic
Stage 1: source
panther_logs.public.okta_systemlog
Stage 2: filter
actor:type eq "User"
eventType eq "user.session.start"
outcome:result eq "SUCCESS"
This rule also runs imperative logic the parser cannot express as a filter; the conditions above are the structured part it could extract.
Indicators
Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.
| Field | Kind | Values |
|---|---|---|
actor:type | eq |
|
eventType | eq |
|
outcome:result | eq |
|
Output fields
Fields the rule emits when it matches. Chronicle authors list these in the outcome block; they appear on the detection and $risk_score drives alerting. Sentinel / Defender XDR rules build them up through project / summarize / extend stages. Sentinel maps these into alert fields via entityMappings and customDetails; Defender XDR custom detections surface them as alert fields directly.
| Field | Source |
|---|---|
p_timeline | p_event_time |
* |