The core question we wanted to answer was simple: if an attacker requests a certificate they are not entitled to, does the CA keep a record of that? The answer is yes and more importantly, it keeps a record even when the request fails or is denied. Every certificate request, successful or otherwise, is permanently logged in the CA database. This makes the CA a valuable forensic source that is often overlooked in favor of network or endpoint telemetry.

During the Discovery phase, a misconfigured certificate template is discovered on ADCS. The template allows Enrollment Rights to all Domain Users, can be used for Client Authentication and has the SubjectNameEnrolleeSupplies flag. This can be abused to request valid Client Authentication certificates as any user in the domain by specifying valid UPN as the Subject of the certificate. Ultimately, this could lead to domain privilege escalation.

Through the misconfigured template, a new certificate was requested by specifying the administrator user as the subject.

The certificate was then used to authenticate as the administrator user to the Domain Controller, receiving a valid Ticket-Granting-Ticket (TGT). This TGT can then be used to perform any operation as the high-privileged administrator user on the domain.

By importing the ticket in the current process, we are then able to move laterally to other hosts on the domain.

Searching for a Fix: Math to the Rescue

After confirming that parse_ese was returning a time.Time object rather than a raw integer, we traced the issue into the underlying go-ese library. In parser/catalog.go, DateTime decoding depends on the column Flags value stored in the ESE catalog. When Flags=1, the library correctly decodes the value as a Windows FILETIME using WinFileTime64(). When Flags=0, it instead interprets the raw bytes as an OLE date value. Using esedbinfo (part of libesedb) to inspect the ADCS CA database schema, we found that every DateTime column was marked with Flags=0, causing go-ese to consistently take the wrong decode path. However, extracting the raw bytes directly from the database pages showed the values were actually stored as standard Windows FILETIMEs. Decoding the same bytes as a FILETIME produced timestamps that matched the output received from certutil exactly, while decoding them as OLE doubles resulted in near-zero floating point values that mapped to the incorrect date 1899-12-30. Cross-checking with ESEDatabaseView and esedbexport (part of libesedb) confirmed the issue: both tools ignored the Flags value and treated the columns as FILETIMEs, returning the correct timestamps. An initial fix that forced all Flags=0 DateTime columns to decode as FILETIMEs solved the ADCS issue but broke support for SRUDB.dat, which also uses Flags=0 but legitimately stores OLE date values. The final solution came from examining the decoded float ranges themselves. Valid OLE date values produce normal floating point numbers well above 1.0, while misinterpreted FILETIMEs produce extremely small near-zero values. Because the gap between the two formats is so large, the decoder can reliably determine the correct encoding directly from the value itself rather than relying solely on the incorrect catalog flag. The fix was a single additional conditional in the Flags=0 branch of the decoder: if the bytes interpreted as a float64 are greater than 1.0, treat them as an OLE double using the existing logic; otherwise treat them as a Windows FILETIME. 

All existing test fixtures continued to pass and the ADCS timestamps decoded correctly.

Paolo is a Senior DFIR Consultant with GuidePoint Security’s DFIR practice who helps organizations respond to complex cyber incidents with proven methodologies to give clients clear visibility into their environments, quickly uncover threats and contain intrusions from highly skilled adversaries targeting critical data and intellectual property. Before joining GuidePoint Security, Paolo worked at NetWitness as a Senior Incident Response Consultant, where he investigated a wide range of cyber threats—from opportunistic attacks to complex, nation-state–backed campaigns. His experience includes investigating incidents involving ransomware, advanced persistent threats (APTs), business email compromise and insider risks, across clients in multiple industries. Paolo holds a Master’s degree in Cyber Security and a Bachelor’s degree in Computer Science from the University of Trento, Italy.