The clearest warning signs are a computer account dNSHostName change, especially when paired with SPN deletion or a follow-on certificate request. Security teams should also treat 4742, 5136, 4741, and 4887 events as relevant telemetry. A certificate request whose subject matches a suspicious hostname change is a strong indicator of abuse.
What to watch for when CVE-2022-26923 exploitation starts
The earliest practical signal is often a change to a computer account’s dNSHostName, because that alteration is the setup step that makes certificate abuse possible. In real investigations, the change rarely appears alone, look for correlated directory modification activity, unexpected certificate issuance, and any account object updates that do not fit normal computer lifecycle behaviour.
For teams that want a high-confidence indicator, the most useful pattern is a hostname change followed by a certificate request that reflects that new name. That pairing is more meaningful than any single event ID in isolation, because it connects directory tampering to the PKI action that turns the change into usable trust material. The closer the timing, the stronger the suspicion.
Telemetry matters here because the attack is noisy at the object level but subtle in business impact. Event 4742 can show a computer account change, 5136 can surface directory object modification, 4741 can identify the creation of a new computer account, and 4887 can help spot certificate activity tied to the suspicious sequence. The most useful investigators correlate those events rather than treating any one of them as proof on its own.
How to interpret the event sequence correctly
Think of the exploitation path as a chain: a computer object is modified, a service principal name is disrupted or removed, and a certificate request follows that reflects the altered identity state. If you only alert on the certificate event, you miss the preparation step. If you only alert on the directory change, you may miss the moment the attacker converts that change into something operationally useful.
That is why the subject name in the certificate request matters. When the requested subject matches a freshly changed or suspicious hostname, the request is no longer routine PKI noise. It becomes evidence that the attacker is trying to obtain a certificate that aligns with the manipulated computer object, which is the practical abuse path in this CVE.
- Correlate object change, SPN change, and certificate request timing.
- Compare the new hostname against approved naming and asset records.
- Check whether the affected computer object should have been modified at all.
- Review whether the certificate request subject matches the altered name.
Why the telemetry is deceptive if viewed in isolation
Each individual event can have benign explanations in active directory, which is why exploitation can hide in plain sight. Computer accounts are routinely created and modified, certificate requests happen for legitimate operational reasons, and directory changes are common in managed environments. The difference is that active abuse tends to produce an odd sequence, an unusual identity change, followed quickly by a trust issuance that depends on that change.
Practically, that means defenders should treat context as the deciding factor. The same event IDs become far more meaningful when they appear on an account that did not recently undergo a planned build, rename, or certificate renewal. A clean baseline for computer object lifecycle is what separates routine administration from likely exploitation.
Risk and Threat Considerations
This exploitation path is dangerous because it converts a directory modification into a trust pivot. Once an attacker can manipulate the computer account state and obtain a matching certificate, the issue is no longer just tampering, it becomes a potential foothold for impersonation and downstream Active Directory abuse.
Failure mechanism: The attacker modifies the computer object, breaks or changes the SPN relationship, and then requests a certificate that aligns with the altered hostname so the new trust material can be abused for authentication or impersonation.
Impact: Security teams can lose trust in account state, certificate issuance, and directory integrity at the same time, which can enable broader privilege abuse, lateral movement, or stealthy persistence if the sequence is not detected quickly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1078 — Valid Accounts | Abuse of altered identity state can enable account impersonation and access retention. |
| T1558 — Steal or Forge Kerberos Tickets | The attack path targets trust material that can support forged authentication flows. | |
| Recommendation — Correlate suspicious directory changes with subsequent authenticated activity and investigate for identity abuse. Hunt for forged trust material and validate authentication events after suspicious directory and certificate changes. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Restricting and reviewing account changes reduces abuse of altered directory objects and certificates. |
| CIS-8 — Audit Log Management | Audit events are the core detection source for the suspicious change-and-request sequence. | |
| Recommendation — Tighten approval and review for computer account and certificate-related changes. Centralize and retain directory and certificate audit logs for sequence-based detection. | ||
Practitioner Guidance
What to verify: Confirm whether the computer object change was planned, who approved it, and whether the timing lines up with a certificate request from the same identity. If those three facts do not line up, treat the sequence as suspicious rather than administrative noise.
Decision rule: If you see a dNSHostName change plus a follow-on certificate request, investigate the object lifecycle first and the certificate second. That order helps you preserve the chain of evidence and stops teams from focusing only on the visible PKI symptom.
Practitioner takeaway: The most reliable detection strategy is sequence-based, not event-based, because this abuse works by turning a directory change into an authentication advantage.
Related resources from NHI Mgmt Group
- What are the signs that a Golden Ticket attack may be underway in Active Directory?
- What are the signs that Active Directory ransomware protection is failing?
- What are the signs that this Active Directory persistence technique is being misused?
- What are the signs that manual Active Directory permissions analysis is failing?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
