[New Rule] `Successful Application SSO from Rare Unknown Client Device`

elastic / detection-rules

Other

1.92k stars 492 forks source link

Summary - What I changed

Added a rule that detects successful single sign-on (SSO) events to Okta applications from an unrecognized or "unknown" client device, as identified by the user-agent string. This activity may be indicative of exploitation of a vulnerability in Okta's Classic Engine, which could allow an attacker to bypass application-specific sign-on policies, such as device or network restrictions. The vulnerability potentially enables unauthorized access to applications using only valid, stolen credentials, without requiring additional authentication factors.

During investigation I noticed that registered client apps whom authenticate via SSO often have the client device reported as known with a custom user-agent. As a result, this detection will catch vulnerability exploit attempts, but is prone to FPs which is why a New Terms rule was created.

Hunting

No additional Hunting query is necessary for this as the Multiple Application SSO Authentication from the Same Source can be used to identify brute-forcing or modified to add unknown for okta.client.device if using Okta integration.

Checklist

[ ] Added a label for the type of pr: bug, enhancement, schema, Rule: New, Rule: Deprecation, Rule: Tuning, Hunt: New, or Hunt: Tuning so guidelines can be generated

[ ] Added the meta:rapid-merge label if planning to merge within 24 hours

[ ] Secret and sensitive material has been managed correctly

[ ] Automated testing was updated or added to match the most common scenarios

[ ] Documentation and comments were added for features that require explanation

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

[ ] Detailed description of the rule.
[ ] List any new fields required in ECS/data sources.
[ ] Link related issues or PRs.
[ ] Include references.

Rule Metadata Checks

[ ] creation_date matches the date of creation PR initially merged.
[ ] min_stack_version should support the widest stack versions.
[ ] name and description should be descriptive and not include typos.
[ ] query should be inclusive, not overly exclusive, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
[ ] min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
[ ] index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
[ ] integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
[ ] setup should include the necessary steps to configure the integration.
[ ] note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
[ ] tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
[ ] threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

[ ] building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
[ ] bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

[ ] Provide evidence of testing and detecting the expected threat.
[ ] Check for existence of coverage to prevent duplication.

elastic / detection-rules