Rewriting the guardrails: network zone and ThreatInsight bypass in Okta
Some attackers do not target a user. They edit Okta's defenses so their own sign-ins are trusted and detection goes blind, then walk in unchallenged.
Okta enforces who can sign in through network zones and detects bad behavior through ThreatInsight. An admin-level attacker can rewrite both rather than attack a single account.
How the attack works
The attacker edits a network zone to add their own address range so IP-based sign-on policies treat it as trusted, then disables ThreatInsight so Okta’s brute-force and known-bad-address detection stops firing. Sign-ins from the now-trusted zone skip the step-up challenges the policy used to enforce, and credential-stuffing attempts proceed without being blocked or risk-flagged, with at least one succeeding. Every change is recorded in the System Log as a configuration event. This maps to T1562, Impair Defenses, and T1078, Valid Accounts.
Why it works
No account was the target, so a password reset is the wrong reflex. The attacker removed the guardrails, so normal-looking sign-ins sail through and the usual dashboards stay quiet because detection itself was switched off.
How to fix it
Recognize this as defense impairment and restore the defenses. Revert the network zone and ThreatInsight settings from a known-good baseline, re-enable detection, and remove the attacker’s ability to edit security configuration. For the class, restrict who can edit zones and detection settings, require change review, baseline known-good, and alert on any change. Treat the blinded window as degraded assurance and scope from the raw System Log rather than the silent dashboards, because absence of alerts is not assurance.
Practice it
We built this as a GraphLattice Range scenario so responders learn to contain an attack on the controls themselves.