Keypoints
- Sekoia.io integrates Okta and JumpCloud system logs into its SOC platform to gain visibility of IAM events and fields for precise detections.
- Detection focuses on behavioural analysis (not only CTI/IOCs) to spot attacker actions like brute force, session cookie reuse, account creation/deletion, privilege changes and excessive app access.
- Example Sigma/correlation rules are provided: a JumpCloud brute-force correlation, an Okta policy modification detection, and a multi-app access correlation to detect mass app launches.
- Key IAM artefacts to monitor include session cookies, API tokens, policy lifecycle events and detailed event fields (actor, target, outcome) that enable grouping and filtering.
- Testing in a controlled environment (Dorothy) is recommended to validate rule coverage for Discovery, Defense Evasion, Persistence and Impact and to measure false positives.
- Rule tuning and filters (by many event fields) are essential to reduce noise while keeping high-fidelity alerts for administrator-like actions.
MITRE Techniques
- [T1110] Brute Force – Detection of repeated authentication failures and subsequent success using correlation rules (JumpCloud example): ‘detecting brute force behaviour on JumpCloud’.
- [T1539] Steal Web Session Cookie – Session cookie theft and reuse to access dashboards without re-authentication: ‘attackers managed to retrieve session cookies from Okta customers, exploiting this data to access the dashboard’.
- [T1098] Account Manipulation – Creation, deletion or deactivation of user accounts and admin changes to accounts: ‘creation of user accounts to their deletion or deactivation’.
- [T1078] Valid Accounts – Use of valid or stolen credentials/tokens (including API tokens or reused sessions) to access resources and bypass authentication: ‘gain access to an account without authenticating, bypassing the login, password and MFA steps.’
- [T1087] Account Discovery – Discovery actions against the Okta environment as simulated by Dorothy modules: ‘Dorothy…provides many commands related to Discovery’.
- [T1562] Impair Defenses (Defense Evasion) – Simulation of defense evasion techniques in Okta to test detection coverage: ‘Dorothy…provides many commands related to…Defense Evasion’.
Indicators of Compromise
- [Session cookies] stolen session reuse – ‘session cookies from Okta customers’ (Okta session cookie reuse attack), and session cookie reuse detection context.
- [API tokens] administrative API tokens – ‘valid Okta API token with administrative roles’ (required by Dorothy) and monitoring token creation/revocation in IAM logs.
- [Event/action names] log fields and event actions used in rules – examples: “policy.lifecycle.update”, “user.authentication.sso”, “user_login_attempt”.
- [Domain] hosting and source context – blog.sekoia.io (article source), t7f4e9n3.rocketcdn.me (image hosting) as locations seen in the post content.
Identity-focused detection engineering workflow (technical summary):
Collect full system logs from IAM providers (Okta, JumpCloud) and ingest all relevant event fields (actor, target, event.action, event.category, action.outcome, okta.system.* fields). Use those fields to build high-fidelity behavioral detections rather than only IOC matches: examples include correlating repeated authentication failures to detect brute-force (group by source.user.name within a timespan), detecting session-cookie or API-token misuse by flagging unexpected successful authentications without preceding valid authentication events, and alerting on policy lifecycle events (policy.lifecycle.update/delete) to catch unauthorized policy changes.
Implement correlation rules that combine atomic detections into higher-confidence alerts: the post shows a Sigma-style correlation for many_failed_logins followed by login_success (ordered temporal correlation) to detect credential stuffing/brute-force, a value_count correlation to detect rapid multi-app launches (possible account compromise), and simple event.action filters for policy modifications. Ensure rules are filterable by fields (actor id, admin flag, source IP, application id) to reduce false positives from legitimate administrative activity.
Validate and tune rules in a controlled environment: run simulated attacker modules (Dorothy for Okta) that exercise Discovery, Defense Evasion, Persistence and Impact to verify which rules fire and where coverage gaps remain. Measure accuracy and responsiveness, iterate on thresholds, grouping keys and whitelists, and publish/share tuned rules (as Sekoia.io does) so they can be adapted across different IAM deployments.
Read more: https://blog.sekoia.io/iam-detection-engineering/