RevokeRadar - Certificate Revocation Feed#

RevokeRadar answers a question that a hash match alone cannot:

The binary is the genuine vendor release - but is the certificate that signed it still trusted?

A code-signing certificate can be revoked by its Certificate Authority after a binary ships - most urgently when the signing key is compromised (keyCompromise). Once that happens, every binary signed with that certificate is suspect, even ones that were legitimately published. RevokeRadar continuously watches the signing certificates of the software HashWatch tracks and flags the moment one is revoked.

How it works#

1. Signer extraction. When HashWatch ingests a Windows binary, it parses the Authenticode signature and records the signing certificate chain (signer, issuer, thumbprint, validity) on the hash record. See SigDiff.
2. Background revocation checks. A checker runs every 6 hours. For each distinct signing certificate, it fetches the issuer’s CRL (Certificate Revocation List) and checks whether the certificate’s serial number appears on it.
3. Recording. A newly-revoked certificate is written to the signer_revocations table with its revocation date, reason, and the check method (crl). Every hash record signed with that certificate gets a cert_revoked_at timestamp.
4. Surfacing. Revocations appear both on the public dashboard (no API key needed) and in the authenticated RevokeRadar API feed.

What it surfaces#

On the public dashboard (free, no API key)#

• A ⚠ RevokeRadar - Revoked Signing Certificates panel listing certificates that signed currently-tracked software and have since been revoked.
• A cert_revoked_at field on each hash record in the /public/hash-of-day response.

Via the API (teams tier)#

GET /api/v1/intel/revocations returns the full feed, including which vendors used each certificate and whether any currently-active binary (still “current” on the dashboard) was signed with it.

curl https://api.hashwatch.us/api/v1/intel/revocations \
  -H "X-API-Key: <team-id>.<secret>"

{
  "revoked_certs": [
    {
      "thumbprint": "a1b2c3d4e5f6...",
      "signer": "Acme Corp",
      "issuer": "DigiCert EV Code Signing CA",
      "revoked_at": "2026-04-15T00:00:00Z",
      "revocation_reason": "keyCompromise",
      "check_method": "crl",
      "affected_vendors": ["AcmeTool", "AcmeSetup"],
      "currently_active": true
    }
  ],
  "total": 1
}

Required permission: intel:revocations · Required tier: teams

Reading the feed#

Revocation reasons (RFC 5280 §5.3.1): unspecified, keyCompromise, cACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold. Treat keyCompromise and cACompromise as the most severe - they imply an attacker could mint validly-signed malware.

How to use it#

• Triage: if RevokeRadar shows currently_active: true for a certificate, any file on your estate signed by it (matching its thumbprint) warrants immediate review - even if the hash itself is a known_vendor_release.
• Threat hunting: pivot your EDR/SIEM on the certificate thumbprint across all endpoints to find every binary signed by the compromised key, not just the specific version HashWatch tracks.
• Monitoring: poll the feed (or watch the dashboard panel) so you learn about a revoked signer the same day the CA acts.

Scope & limits. RevokeRadar checks the signing certificates of software HashWatch tracks, via CRL. OCSP and certificates outside the tracked set are out of scope. A revoked certificate does not retroactively prove a specific file is malicious - it means the signature can no longer be trusted as proof of origin. Combine with other detections during an investigation.