Audit-Logging für ADCS – was protokolliert werden muss

Kurzfassung vorab: Die CA-Auditierung ist bei ADCS standardmäßig aus — und genau das ist der Grund, warum Konfigurationsänderungen wie bei ESC4 monatelang unbemerkt bleiben. Protokollieren allein reicht nicht: Logs, in die niemand schaut, sind eine Alarmanlage mit abgeklemmtem Lautsprecher. Dieser Artikel zeigt, welche Ereignisse du zwingend aktivieren musst, welche Event-IDs wirklich zählen und wie du aus reinem Mitschreiben eine echte Erkennung machst, die bei verdächtigen Mustern Alarm schlägt.

Abb. 1: Audit-Logging-Pipeline für ADCS — von den Ereignisquellen über Weiterleitung und SIEM bis zur automatischen Alarmierung bei verdächtigen Mustern.

1. Warum Standard-ADCS praktisch blind ist

Eine frisch installierte Windows-CA protokolliert ihre sicherheitsrelevanten Vorgänge nicht. Die CA-Auditierung ist per Default deaktiviert — und selbst wenn du sie aktivierst, landen die Ereignisse nur dann im Security-Log, wenn zusätzlich die Objektzugriffs-Überwachung im Betriebssystem eingeschaltet ist. Diese Doppelbedingung übersieht fast jeder, der sich nicht gezielt damit beschäftigt. Das Ergebnis: Eine Standard-CA weiß nicht, wer wann welches Zertifikat beantragt hat, wer Vorlagen geändert oder CA-Einstellungen verstellt hat.

Für die Sicherheit ist das fatal. Erinnere dich an ESC4 aus dem ESC-Spoke: Ein Angreifer mit Schreibrecht auf eine Vorlage macht sie kurz zu einer ESC1-Vorlage, nutzt sie aus und dreht die Änderung zurück. Ohne aktivierte Auditierung bleibt von diesem Vorgang exakt nichts übrig. Mit aktivierter Auditierung dagegen siehst du die Vorlagenänderung (Event-ID 4899), die verdächtige Ausstellung (4887) und die Rück-Änderung — drei Puzzleteile, die zusammen das Bild ergeben.

2. Die beiden Schalter, die du umlegen musst

Audit-Logging für ADCS scharfzuschalten ist eine Sache von zwei Befehlen — vorausgesetzt, du kennst beide. Der erste aktiviert die CA-interne Auditierung, der zweite die OS-seitige Überwachung, ohne die der erste folgenlos bleibt:

Der AuditFilter-Wert 127 schaltet alle sieben Kategorien scharf. In den meisten Umgebungen ist das die richtige Wahl — die Ereignismenge ist überschaubar, und du willst im Zweifel zu viel statt zu wenig protokolliert haben. Die sieben Kategorien decken vom Start/Stopp des CA-Dienstes über Backup/Restore und Zertifikatsanträge bis zu den sicherheitskritischen CA-Konfigurations- und Rollenänderungen alles ab.

3. Die Event-IDs, auf die es ankommt

Wenn die Auditierung läuft, produziert sie eine Reihe von Event-IDs im Security-Log. Nicht alle sind gleich wichtig. Diese Referenz zeigt, welche du im Normalbetrieb nur sammelst und welche eine sofortige Alarmierung verdienen:

Abb. 2: Die wichtigsten ADCS-Event-IDs — Konfigurationsänderungen (rot) gehören in die Alarmierung, Normalbetrieb (grün) wird gesammelt.

Die rote Gruppe ist die entscheidende: 4890 (Zertifikatmanager-Einstellung geändert), 4892 (CA-Eigenschaft geändert) und 4899 (Zertifikatvorlage aktualisiert) sind die Ereignisse, die im normalen Betrieb fast nie auftreten — und wenn doch, dann sollte jemand davon wissen. Eine Vorlagenänderung um drei Uhr nachts, die niemand beauftragt hat, ist genau das Signal, das den Unterschied zwischen „Vorfall bemerkt" und „Vorfall nach sechs Monaten im forensischen Gutachten entdeckt" ausmacht.

Die grüne Gruppe — vor allem 4886 (Anforderung empfangen) und 4887 (Zertifikat ausgestellt) — fällt im Normalbetrieb massenhaft an. Diese Ereignisse alarmierst du nicht einzeln, sondern wertest sie auf Muster aus: ungewöhnliche SAN-Inhalte, Ausstellungen außerhalb der Geschäftszeiten, ein einzelnes Konto, das plötzlich auffällig viele Zertifikate zieht.

4. Vom Log zur Erkennung — die Pipeline

Aktivierte Auditierung ist die Pflicht, eine funktionierende Auswertung die Kür — und der Punkt, an dem die meisten Projekte einschlafen. Die Logs liegen lokal auf der CA, niemand schaut hinein, und im Ernstfall sind sie womöglich schon überschrieben. Eine belastbare Pipeline besteht aus drei Stufen:

Für den Anfang muss es kein großes SIEM sein. Selbst eine geplante PowerShell-Auswertung, die täglich die kritischen Event-IDs aus dem Security-Log zieht und per Mail meldet, ist unendlich viel besser als gar nichts:

5. Praxis-Beispiel — die Musterwerk GmbH

Die Musterwerk GmbH, der Industrie-Mittelständler mit rund 1.200 Mitarbeitern, kam nach einem Sicherheitsvorfall in einem anderen Systembereich mit einer klaren Frage: „Würden wir es überhaupt merken, wenn jemand an unserer PKI manipuliert?" Die ehrliche Antwort beim ersten Blick lautete nein. Die CA-Auditierung war deaktiviert, die wenigen lokal vorhandenen Logs wurden nirgendwo zentralisiert, und eine Alarmierung existierte nicht.

Wir haben in einem ersten Schritt beide Audit-Schalter gesetzt und über das vorhandene Windows Event Forwarding die CA-Ereignisse an den bereits betriebenen Log-Collector angebunden. Im SIEM wurden zwei Regelsätze definiert: einer, der die kritischen Konfigurations-Event-IDs (4890, 4892, 4899) sofort an das IT-Team meldet, und einer, der ausgestellte Zertifikate auf SAN-Einträge mit privilegierten Kontonamen prüft — die ESC1-Signatur.

Der Test war eindrucksvoll: Im kontrollierten Versuch änderte ein Teammitglied testweise eine Vorlage — und keine zwei Minuten später lag die Alarm-Mail im Postfach des Verantwortlichen. Musterwerk hatte damit für überschaubaren Aufwand genau die Sichtbarkeit gewonnen, die vorher fehlte. Der eigentliche Wert zeigte sich ein halbes Jahr später, als eine nicht abgesprochene Vorlagenänderung eines externen Dienstleisters sofort auffiel und geklärt werden konnte, bevor daraus ein Problem wurde. Gesamtaufwand der Einrichtung: rund zwei Beratungstage.

Verwandte Themen

Pillar-Seite: Active Directory Certificate Services – der komplette Leitfaden

Häufige Fragen (FAQ)

Ist die ADCS-Auditierung standardmäßig aktiv?

Nein. Die CA-Auditierung ist bei einer frisch installierten Windows-CA deaktiviert und muss bewusst eingeschaltet werden. Selbst nach dem Aktivieren landen die Ereignisse nur dann im Security-Log, wenn zusätzlich die Objektzugriffs-Überwachung für „Certification Services" im Betriebssystem aktiviert ist. Diese Doppelbedingung wird häufig übersehen.

Wie aktiviere ich das Audit-Logging für ADCS?

Mit zwei Schritten: „certutil -setreg CA\AuditFilter 127" aktiviert alle sieben CA-Auditkategorien (danach den CA-Dienst neu starten), und „auditpol /set /subcategory:»Certification Services« /success:enable /failure:enable" schaltet die nötige OS-seitige Überwachung scharf. Beide zusammen sind Pflicht — nur einer von beiden erzeugt keine verwertbaren Logs.

Welche Event-IDs sind bei ADCS am wichtigsten?

Sicherheitskritisch sind die Konfigurationsänderungen: 4890 (Zertifikatmanager-Einstellung geändert), 4892 (CA-Eigenschaft geändert) und 4899 (Zertifikatvorlage aktualisiert) — diese gehören in eine sofortige Alarmierung. Die Ausstellungs-Events 4886 (Anforderung empfangen) und 4887 (Zertifikat ausgestellt) fallen massenhaft an und werden auf Muster ausgewertet, nicht einzeln alarmiert.

Wie erkenne ich einen ESC1-Angriff im Log?

Über die ausgestellten Zertifikate (Event-ID 4887): Suche nach einem SAN, der einen privilegierten Kontonamen wie „Administrator" oder einen Domain-Admin enthält, obwohl das antragstellende Konto nicht privilegiert ist. Dieses Muster ist der Fingerabdruck von ESC1. Eine einzige gut gebaute SIEM-Regel auf diese Konstellation fängt den gefährlichsten Angriffspfad ab.

Reicht es, die Logs nur lokal auf der CA zu speichern?

Nein. Lokale Logs auf der CA sind im Ernstfall genau das, was ein Angreifer manipuliert oder durch Überschreiben verschwinden lässt. Die Ereignisse gehören per Windows Event Forwarding oder SIEM-Agent weg vom potenziell kompromittierten System auf einen zentralen, manipulationssicheren Speicher mit definierter Aufbewahrungsfrist — sechs Monate sind ein vernünftiges Minimum.

Brauche ich zwingend ein SIEM für ADCS-Audit-Logging?

Für den Einstieg nicht. Ein SIEM mit Korrelation und Alarmierung ist die Kür, aber selbst eine geplante PowerShell-Auswertung, die täglich die kritischen Event-IDs aus dem Security-Log zieht und per Mail meldet, ist unendlich viel besser als gar keine Auswertung. Wichtig ist, dass überhaupt jemand oder etwas regelmäßig hinschaut — Logs ohne Auswertung sind wertlos.

Nächste Schritte mit boddenberg.de

Audit-Logging ist der Unterschied zwischen einer PKI, die Vorfälle bemerkt, und einer, die sie erst im forensischen Gutachten entdeckt. Drei Wege, das aufzusetzen:

Kontakt: Uli Boddenberg · boddenberg.de · Dortmund