Purple Teaming Okta Detections with LimaCharlie

Identity is now where the most serious intrusions begin, and yet it is the one telemetry source most security teams instrument by guesswork. You cannot write a detection for an event you have never seen, and Okta gives you no safe way to see what an attack against it actually looks like. You are not going to red team your production identity provider. So the rules people ship for Okta tend to be borrowed, generic, and untested against a real adversary's footprints. Ken Westin, a Solutions Engineer at LimaCharlie, spent this session making the case that the way out of that bind is to manufacture the evidence yourself, safely, and write detections against what you observe rather than what you assume.

The detection you cannot copy from someone else

The most important claim Westin makes is almost an aside: Okta detections do not transfer cleanly between organizations. Every tenant has different processes and a different organizational structure, so a rule that makes sense in one environment is noise or blindness in another. He finds it genuinely difficult to write detections that work everywhere. That is an uncomfortable thing for a managed provider to hear, because the whole economic model of an MSSP or MDR depends on building something once and applying it across many customers. If identity detections are inherently local, the leverage has to come from somewhere other than the rule itself.

Westin's answer is that the leverage lives in the method, not the content. What you template across tenants is the loop: emulate an attack, watch the logs it produces, and write a rule against the specific event. The rule will be different for each customer, but the practice of grounding it in observed behavior is identical everywhere. He calls the underlying instinct, only half joking, "fool around and find out." When he started testing tools against Okta, he had no idea what to look for, because the documentation was thin, until he ran activity and read what came back. That is the part that scales, even when the resulting rules do not.

Manufacturing the evidence without touching production

This only works if you have somewhere to run attacks that is realistic but disposable. Westin is emphatic, more than once, that none of the offensive tooling belongs anywhere near a live Okta instance, and he does not want anyone telling their boss that Ken said it was fine. The substitute is Okta's free Developer Edition, which gives you API access and enough event volume to test against, throttled only on event counts. Against that he points Dorothy, an open source adversary emulation tool built specifically for Okta. Dorothy runs no exploits. You hand it an API token, which is the entire point, because the threat it models is the stolen or leaked developer key, the kind a developer leaves sitting on GitHub for an attacker to find. Its modules are organized by MITRE ATT&CK tactic, discovery, persistence, defense evasion, so anyone who has driven Metasploit will navigate it on instinct, and Westin tags his detections back to those same techniques.

The single most useful thing this exercise surfaces is a gap in visibility that no documentation would have told him about. Pure reconnaissance through the Okta API is silent. A who-am-I check, a query for every user without MFA enabled, a dump of policies, none of it generates a log. An attacker holding a token can map your tenant completely without tripping a thing. Logs only appear once the attacker acts, when they create a user or change a setting. You learn that not by reading Okta's manuals but by running the commands and watching nothing show up. That fact should reshape where a defender puts their attention, and it is invisible until you generate it.

Reading the footprints, then writing the rule

Westin's sample intrusion is deliberately ordinary. Steal a token, confirm through who-am-I that it carries super-user rights, dump the user list, create a new account, escalate it to super administrator, then disable MFA and set security questions. The escalation is the part worth dwelling on, because it is about persistence. If defenders notice the original token and revoke it, the attacker still owns a separate admin account from which to mint fresh tokens. A defender who only kills the obvious credential has not actually removed the intruder.

When that sequence runs, the events land in the LimaCharlie sensor timeline, where Westin treats anything that emits data, endpoint or log source alike, as a sensor. From the timeline he writes detection and response rules directly against the events he just produced. Most are pass-through rules: the Okta event already carries the identity and host context he needs, so he forwards it and, where it helps, adds severity or enrichment. The examples are concrete and earned. An administrator login is detectable because Okta redirects admins to an admin page and emits a distinct event, so an unexpected admin address can raise an alarm even when a failed login would not reveal the role. Token creation, MFA being disabled, and a user being created and then escalated each become a rule.

The detection that best illustrates the whole argument is the most local one. If only the designated administrator should ever create an API token, then any token created by anyone else fires a high-severity alert. That rule is worthless as a generic signature and decisive in the specific tenant it was written for, which is exactly Westin's point. For a provider, the work is fast to stand up: connecting Okta is three fields and under five minutes, an admin-screen token pasted into LimaCharlie, after which the logs sit beside endpoint and cloud telemetry in one multi-tenant platform with a full year of retention. The platform makes the data cheap to hold. The developer instance and Dorothy make the evidence safe to generate. What turns those into protection a customer can rely on is the discipline of writing each rule against behavior you have actually watched, one tenant at a time.