A threat actor has leaked online a database containing the personal and work information of thousands of US Department of Homeland Security employees. The hacker, who uses the handle Department of Peace, has leaked more than 41,000 records. According to the hacker, the data was stolen from an Okta single sign-on system used by DHS employees and contractors to access its central environment.
What happened
The leaked set is a staff directory with access context attached. The compromised data includes names, work email addresses and phone numbers, job titles, and office locations, as well as records showing which systems and internal applications each account can access.
Most of the leaked records reportedly contain information on US Customs and Border Protection (CBP), Immigration and Customs Enforcement (ICE), and Homeland Security Investigations (HSI) employees.
The origin of the data is a claim by the hacker, not a confirmed finding. Treat the attribution of source and the exact scope as unverified for now.
How it was done
The hacker says the data came from an Okta single sign-on system used by employees and contractors to access the central environment. No further technical detail on the method of access has been published in the source.
What matters for defenders is the shape of the data. An identity provider holds both the directory and the mapping of people to applications, so a single export can describe an entire organisation: who works there, what they do, and what each account is entitled to open.
Records showing which systems and internal applications each account can access.
What to check
Work through your own identity provider as if it were the target of a bulk export.
List every account that can read the full directory
In Okta, open the admin console and review Security, then Administrators, including custom admin roles scoped to read users and groups. Pull the same list for any downstream HR or ITSM connector service account. Any human account with a standing organisation wide read role is a finding.
Audit API tokens and OAuth scopes
Check Security, API, Tokens for tokens with no expiry, no network zone binding and an unknown owner. Review service apps granted okta.users.read or okta.apps.read. Revoke anything whose purpose nobody can name in one sentence.
Hunt for bulk reads in the system log
Query the Okta System Log for user.session.start by admins outside normal hours, and for repeated paginated calls to /api/v1/users or /api/v1/apps from one IP. A single client pulling tens of thousands of records in a short window is the pattern to alert on.
Bind admin access to device and network
Require phishing resistant factors for all admin roles and restrict admin sign in to managed devices and known network zones. Test by attempting an admin sign in from an unmanaged browser. If it succeeds with a push approval, tighten the policy.
Reduce what the directory stores
Review custom user profile attributes for office location, desk phone and internal system notes. Remove fields the identity provider does not need to make an access decision, and mark the rest as not readable by standard app integrations.
Prepare for directory data in attacker hands
Assume names, titles and application entitlements can be used to craft targeted help desk calls. Set an identity verification step for password and factor resets that does not rely on facts an attacker could read from a directory export, and rehearse it with your service desk.