Build Server Compromise and the Code-Signing Keys

The two keys have very different blast radius and the answer differs for each.

The software code-signing key is fully compromised. The attacker read the CI configuration, so assume they had the key-store password and copied the key file. With it they can sign any binary as the publisher, and because this is an OV certificate the signature validates immediately for every customer and for Windows; SmartScreen reputation may lag, but SmartScreen is a warning, not a control. This key must be revoked and replaced.

The EV key on the USB token is a different question, and the honest answer depends on evidence gathered in the first hours. If the token is non-exportable and requires a PIN per signature, file-level access to the build server does not extract the key. But any process on the build agent can ask the token to sign, so a nine-day shell means you cannot prove the key was not used. Hardware storage protects the key at rest; it does not protect against a compromised host. Assume misuse unless token audit logs and signing logs agree that no unexpected signatures were produced.

Driver signing is the higher-impact capability in either case. An attacker-signed kernel driver installs at high privilege and is trusted by the operating system's own policy, so prioritise the driver path in the investigation.

Treat both keys as requiring revocation, and run the investigation in parallel with revocation rather than before it. Waiting for certainty is how a nine-day exposure becomes a nine-week one.

Timestamps cut both ways, and this is the crux of the case.

An RFC 3161 timestamp proves a signature existed at time T. Verifiers accept a signature whose certificate has since expired or been revoked, provided the timestamp predates the revocation. That is exactly what you want for legitimate releases: customers can keep validating last quarter's installer after the key is revoked.

It also protects the attacker's artifacts. Anything signed in the nine-day window carries a timestamp from before the revocation, so it will keep validating after the certificate is revoked. Revocation stops new signatures from being trusted; it does not retroactively invalidate ones already made. Anyone telling customers that revocation makes the malicious builds harmless is wrong.

Sequence:

1. Freeze the build and preserve the server image before cleaning anything.
2. Build the artifact inventory for the window from CI logs, the signing or token audit log, repository timestamps, and hashes of everything published to the stable channel.
3. Request revocation through the CA, coordinated with Microsoft, with an advisory ready to publish at the same time. Revocation is public and permanent, so do it within hours, not days.
4. Start the replacement certificate application immediately. Organisation validation takes days and is the long pole for shipping a fixed build.
5. Publish a hash denylist and a signed list of affected versions, push detection signatures to EDR partners, and tell customers which versions to remove.
6. Rebuild from a clean environment under the new key, with the signing key moved out of the build job's reach entirely.

The durable fix is a signing service or HSM that requires an authenticated, audited call, so a shell on the build server gets you a build, not a key.

This is where the incident becomes a lasting problem, because their verification model assumes revocation information travels with the installer.

Those agents check a bundled CRL at install. The CRL on the next quarterly media was generated before the revocation, so it does not list the compromised certificate, and a malicious build from the nine-day window installs and passes every check the agent makes. Anyone who knows a customer is air-gapped has a durable delivery path.

Now: contact all 3,500 air-gapped customers out of band with affected version numbers and SHA-256 hashes before the next media shipment; have them block those versions by hash at their endpoint-management layer; and hold the quarterly media until it carries both a refreshed CRL and a signed hash denylist the installer enforces.

Afterwards: ship a signed artifact manifest with a monotonic release sequence number per channel, and make the installer reject anything older than the highest sequence it has seen. That defeats rollback and version pinning whether or not revocation data is fresh. Add a denylist channel updatable by signed media rather than only by CRL, and shorten the media interval for the driver package, which carries the highest privilege.

Record the residual risk: the air-gapped fleet will be up to a quarter behind on revocation data, so every control that depends on revocation must be paired with one that does not.