What This Column Is Reporting, and What It Is Not
For the last seven weeks I have been tracking an advanced operator I designate OBSIDIAN HALCYON. The designator is mine. The activity is real. The targeting set is identity provider infrastructure operated by mid-tier enterprises in three sectors that I will name. I am withholding the affected platform vendor and the affected build because the patch is not out yet. Naming the vendor before the patch ships would direct attacker attention to the very organizations now racing to remediate.
This column reports activity. It does not report exploits. I will describe what defenders need to know to act and nothing that would help an opportunist pivot off the column itself.
The Sector Pattern
OBSIDIAN HALCYON activity has been observed against identity provider deployments in three sectors. Federal civilian contractors with cleared-personnel staffing exposure are first in the count by volume. Healthcare technology firms with payer-side patient data integrations are second. Specialty financial services firms with above-average regional concentration in the southeast United States are third. The pattern is too tight to be opportunistic. The actor is hunting for a specific operational outcome, and the sector selectivity tells you what that outcome is. Identity providers sit at the intersection of access control, single sign-on, and authentication metadata. An adversary with sustained access to that intersection inherits a downstream attack surface that compounds.
The duration matters. Seven weeks is not a snatch-and-grab. Seven weeks is sustained presence, which means the operator has invested in operational security, in detection avoidance, and in patience. Patient operators are the expensive ones. They are funded by customers who can wait, and they are managed by leadership that grades on outcomes rather than activity.
The Defensive Read
If your organization operates an identity provider serving employees, contractors, or partners in any of the sectors above, your incident response team should already be in motion this week. Track the activity, not the artifact. Detection signatures that key on specific file hashes or specific command-and-control endpoints will lag the operator by definition because the operator is rotating those artifacts on a tempo your signature feed cannot match. Behavioral analytics on authentication metadata, on identity-store administrative API call patterns, and on session token lifetime anomalies will catch the activity the artifacts will not.
The questions to ask your identity team this week. Have administrative service principals authenticated from network locations inconsistent with their documented business owners over the last sixty days? Have token lifetimes for high-privilege accounts been adjusted in ways that increased the dwell time of stolen credentials? Have audit logs for the identity provider's administrative tier been forwarded to the security information and event management platform with the same fidelity and the same retention as the platform documentation specifies? If the answer to any of those is uncertain, that is where the work is.
What I Will Not Say
I will not give the vendor. I will not give the build. I will not give the CVE number for the bug that, when the public reporting catches up, will explain the operator's initial access vector. I will not give indicators of compromise at IOC-grade specificity because the operator rotates faster than my publishing tempo and posting stale indicators only convinces defenders they are clear when they are not.
I will say that the patch availability window appears, based on the cadence I have observed across prior similar campaigns, to be on the order of two to four weeks from this publication. Defenders who use that window to instrument behavioral detection on the identity tier rather than to wait for the patch will be ahead of the operator when the patch ships. Defenders who wait for the patch will spend the patch deployment window doing forensics on systems that have already been compromised.
Attribution Posture
I am not naming an attribution to a state or a known cluster in this column. The attribution work is underway. The signals point in a direction consistent with the operator's prior known tradecraft and with the working-hour rhythms of the activity, but the attribution case is not yet at the threshold where I am willing to put it in print. I will publish the attribution when it crosses the threshold. The defensive guidance does not depend on the attribution being final. The activity is the activity, and the response is the response.
What to Expect in the Public Reporting
The vendor will issue an advisory within the next two to four weeks, based on the cadence pattern. The advisory will reference the platform, the affected build range, and the CVE identifier. Vendor reporting will follow, likely under a different cluster designator. Threat intelligence vendors will publish technical analyses with file hashes, infrastructure diagrams, and behavioral signatures.
By the time that public reporting arrives, the defenders who acted on the framing in this column will already be hunting, already detecting, and already evicting. The defenders who waited will be reading the public reporting and trying to figure out whether their systems were affected during a window in which they had no instrumentation in place to know either way.
The cluster has a designator. It does not yet have a press release. By the time it does, your incident response team should already know what to do.




