IT-Service Walter
ISW Logon Sentinel
Zentrale Anmeldeüberwachung und revisionssichere Protokollarchivierung – für beliebig viele Windows-Domänen, mit und ohne Vertrauensstellung. Wer sich wann wo angemeldet hat, wer es vergeblich versucht hat, und der Beleg dafür, dass nichts fehlt: signiert, verkettet, nachprüfbar.
Warum die Anmeldeprotokolle nicht auf dem Domänencontroller bleiben dürfen
Das Sicherheitsprotokoll eines Domänencontrollers ist ein Ringpuffer. Bei ein paar hundert Megabyte reicht es Tage, bei einem Angriff Stunden – dann überschreibt es sich selbst. Wer bei einem Vorfall nachsehen will, was vor drei Wochen war, findet nichts. Und wer sich als Dienstleister um zwanzig Kunden kümmert, hat zwanzig Domänen, die einander nicht kennen und kennen sollen.
Weg vom Domänencontroller, bevor es überschrieben wird
Ein Agent liest das Sicherheitsprotokoll fortlaufend mit und meldet im Takt, den die Zentrale vorgibt – je nach Aufkommen alle 10 bis 60 Sekunden. Bricht die Verbindung ab, puffert er auf der Platte und liefert nach.
Mit und ohne Vertrauensstellung, ohne offenen Port
Der Agent meldet ausgehend über HTTPS. In den überwachten Domänen muss kein Port geöffnet, keine Vertrauensstellung eingerichtet und kein Fremdkonto angelegt werden – eine bestehende Vertrauensstellung stört aber auch nicht. So werden hundert Domänen handhabbar, eigenständige wie verbundene.
Archiv zuerst, Datenbank danach
Jedes Ereignis geht erst in das signierte Archiv, dann in die Datenbank. Bricht der Vorgang dazwischen ab, fehlt höchstens ein Auswertungsdatensatz – nie ein Beweis.
Stille ist ein Alarm
Ein Meldepunkt, der nichts liefert, ist der gefährlichste Zustand: Das Dashboard bleibt grün, weil nichts eingeht. Deshalb wird Schweigen selbst zum Alarm – nach einer einstellbaren Zeit, per Mail.
Drei Bestandteile, ein Weg
Agent auf dem Domänencontroller, Zentrale auf einem Server, Konsole am Arbeitsplatz. Alles spricht nur mit der Zentrale; dort liegt das Prüfprotokoll, das jeden Eingriff festhält.
Liest, puffert, meldet signiert
Windows-Dienst je Domänencontroller. Liest ab Lesezeichen, damit nach einem Neustart nichts doppelt und nichts verloren geht. Jedes Paket trägt eine fortlaufende Nummer und eine HMAC-Signatur mit einem Schlüssel, den nur dieser Agent hat.
Prüft stündlich die Überwachungsrichtlinie des Domänencontrollers und meldet, wenn eine Unterkategorie fehlt – statt zu warten, bis ein Prüfer es findet. Rollout ohne Parameter per Softwareverteilung oder Gruppenrichtlinie.
Archiviert, wertet aus, alarmiert
Windows-Dienst mit SQL Server oder SQLite darunter. Nimmt nur freigegebene Meldepunkte an, schreibt jedes Ereignis in eine Tagesdatei je Domäne, versiegelt sie beim Tageswechsel und hängt sie in die Hashkette.
Regelwerk mit Schwellwerten je Domäne, Alarme mit zwei Verteilern – der Sprühangriff um drei Uhr nachts geht an die Rufbereitschaft, der Wochenbericht nicht. Aufbewahrung und Löschung mit Nachweis.
Bedient, wertet aus, weist nach
Zwei Dashboards: „Betrieb und Abdeckung" beantwortet, ob die Überwachung selbst läuft. „Sicherheit und Analyse" zeigt Fehlversuche, Quellen, Konten und Alarme.
Ereignis- und Kontensuche, Regelwerk, Mandanten, Meldepunkte, Berichte und Prüfprotokoll. Spricht nur mit der Zentrale, angemeldet mit dem Windows-Konto – und der Name steht bei jedem Vorgang im Prüfprotokoll.
Welche Ereignisse ausgewertet werden
Der Punkt, an dem viele danebenliegen: Auf einem Domänencontroller entsteht eine fehlgeschlagene Domänenanmeldung als 4771 (Kerberos) oder 4776 (NTLM) – nicht zwingend als 4625. Eine Brute-Force-Erkennung, die nur auf 4625 hört, sieht die Angriffe schlicht nicht.
| Kennung | Bedeutung |
|---|---|
| 4624 | Anmeldung erfolgreich |
| 4625 | Anmeldung fehlgeschlagen |
| 4648 | Anmeldung mit expliziten Anmeldeinformationen |
| 4740 / 4767 | Konto gesperrt / entsperrt |
| 4768 | Kerberos-Ticket angefordert – die eigentliche Domänenanmeldung |
| 4771 | Kerberos-Vorauthentifizierung fehlgeschlagen |
| 4776 | NTLM-Anmeldeinformationen geprüft – die Spur, an der man NTLM-Nutzung erkennt |
| 4778 / 4779 | Sitzung wiederverbunden / getrennt |
Bewusst nicht im Standardprofil: 4769, das Kerberos-Diensteticket. Es entsteht bei jedem Zugriff auf jede Freigabe und ist der größte Mengentreiber überhaupt. Zusammen mit dem Filtern von Maschinenkonten sinkt die Menge typischerweise um den Faktor drei bis fünf – ohne dass die Erkennung darunter leidet. Für befristete Analysen lässt es sich zuschalten.
Das Regelwerk
Dreizehn Regeln, jede mit Schwellwert und Zeitfenster – einstellbar je Domäne, weil ein Terminalserver-Standort andere Zahlen produziert als eine Verwaltung mit dreißig Arbeitsplätzen. Gleichartige Befunde werden zusammengefasst: ein Alarm mit Zähler, nicht zweihundert Mails.
Angriffe erkennen
- Brute Force auf ein Konto
- Kennwortsprühangriff von einer Quelle – auch wenn die Quelle über Teredo, 6to4 oder ISATAP getunnelt erscheint; die Adressen werden auf die IPv4 zurückgeführt
- Erfolgreiche Anmeldung nach einer Fehlversuchsserie
- Häufung von Kontosperrungen
- Versuche mit deaktivierten oder abgelaufenen Konten
Schwachstellen und Auffälligkeiten
- Schwache Kerberos-Verschlüsselung (RC4, DES)
- NTLM-Nutzung – wo sie noch herkommt, mit Konto und Arbeitsstation
- Anmeldung außerhalb der Geschäftszeiten
- Neue Anmeldequelle für ein Konto
- Tier-0-Konto meldet sich an einem Arbeitsplatz an
Die Überwachung überwacht sich selbst
- Meldepunkt liefert nicht mehr
- Lücke in der Ereignisfolge
- Überwachungsrichtlinie auf dem Domänencontroller unvollständig
Diese drei sind die wichtigsten: Sie sagen, ob den anderen zehn überhaupt zu trauen ist.
Alarme, die man bearbeiten kann
Quittieren, schließen, als Fehlalarm einstufen – mit Benutzer und Zeitpunkt im Prüfprotokoll. Zwei Mailverteiler: Regelbetrieb und kritische Alarme. Eingriffe an der Überwachung selbst – Ablage gewechselt, Meldepunkt entfernt, Frist verkürzt – erzeugen eine eigene Meldung an die kritischen Empfänger.
Archiv und Beweiskraft
Die Frage, die bei einer Prüfung wirklich gestellt wird, lautet nicht „was habt ihr gesammelt", sondern „woher wisst ihr, dass nichts fehlt". Darauf antwortet das Archiv – und der Vollständigkeitsnachweis, der es zusammenfasst.
Tagesdatei je Domäne, versiegelt beim Tageswechsel
Komprimiert, gehasht, mit Nachweisdatei. Jeder Tag verweist auf den Hash des Vortags – eine Kette, die sich von der ersten Datei an durchrechnen lässt. Ein entfernter Tag oder eine veränderte Datei fällt dabei auf.
Signierte Nachweise
Jedes Kettenglied trägt eine RSA-Signatur der Zentrale. Das Roh-XML jedes Windows-Ereignisses liegt im Archiv – der eigentliche Beweis, nicht eine Interpretation davon.
Kette nachrechnen, jederzeit
In der Konsole auf Knopfdruck: jede Datei neu gehasht, mit dem Nachweis verglichen, die Kette durchgerechnet. Geprüft wird ab dem ersten archivierten Tag – Zeit vor der Inbetriebnahme ist keine Lücke.
Vollständigkeitsnachweis der Protokollierung
Der Agent zählt die Domänencontroller seiner Domäne aus dem Verzeichnis und meldet sie mit. Die Zentrale kann dadurch sagen: Diese Domäne hat drei Domänencontroller, es melden drei. Das steht im Bericht, zusammen mit Sequenzprüfung, Richtlinienbefund und Kette.
Getrennte Archive je Kunde
Archivpfad je Mandant, bei Bedarf je Domäne. Ein Kunde kann sein Archiv mitnehmen oder löschen lassen, ohne dass jemand in den Beständen anderer sucht. Umzüge kopieren und prüfen – sie verschieben nichts.
Aufbewahrung und Löschung mit Nachweis
Fristen je Mandant für Datenbank, Archiv und Alarme, Beweissicherung als Sperre. Jede Löschung steht im Löschprotokoll – das ist das Papier, das ein Datenschutzbeauftragter sehen will.
Sieben Berichte, die man weiterreichen kann
Jeden gibt es als HTML und als PDF, jeder lässt sich aus der Konsole per Mail versenden – der Versand steht mit Benutzer und Zeitpunkt im Prüfprotokoll.
Anmeldeübersicht
Wer sich wann wo angemeldet hat – nach Domäne, Konto, Quelle, Verfahren.
Fehlgeschlagene Anmeldungen
Mit Fehlergrund: Zwanzig „falsches Kennwort" sind ein Angriff, zwanzig „Konto deaktiviert" ein vergessenes Offboarding.
Gesperrte Konten
Sperrungen und Entsperrungen im Zeitraum, mit auslösender Quelle.
Alarmbericht
Alle Alarme des Zeitraums mit Zustand, Bearbeiter und Einstufung.
Nachweis der Aufbewahrung und Löschung
Fristen, Beweissicherung und jede ausgeführte Löschung – für den Datenschutz.
Vollständigkeitsnachweis der Protokollierung
Abdeckung je Domäne, Zustand aller Meldepunkte, Sequenzprüfung, Archivkette – für den Prüfer.
Managementbericht
Die Zahlen des Monats auf einer Seite, ohne Ereigniskennungen.
Gebaut für Dienstleister mit vielen Kunden
Ein Mandant je Kunde: eigener Archivpfad, eigene Fristen, eigene Berichte. Die Domänen eines Kunden werden ihm beim Aufnehmen des Meldepunkts zugeordnet – die Zentrale führt die Zuordnung, der Agent muss davon nichts wissen.
Freigabe statt Schlüsselverteilung
Ein neuer Agent meldet sich und wartet. Freigegeben wird in der Konsole – einzeln oder als Sammelfreigabe nach Sichtung der Liste. Ein gemeinsamer Aufnahmeschlüssel für den Massenrollout ist möglich, aber die Ausnahme; nach der Aufnahme hat jeder Agent seinen eigenen.
Wiederaufnahme wird abgewiesen
Wer sich unter dem Namen eines freigegebenen Meldepunkts meldet, ohne dessen Schlüssel zu haben, wird abgelehnt – und der bestehende Meldepunkt läuft weiter. Ein Angreifer kann sich weder als Domänencontroller ausgeben noch einen laufenden stilllegen.
Prüfprotokoll über die Überwachung
Freigaben, Fristen, Regeländerungen, Berichte, Archivprüfungen, Pfadwechsel – jeder bedienende Zugriff mit Windows-Konto und Zeitpunkt. Nur lesend, ohne Löschfunktion: Ein Protokoll, das der Bediener bereinigen kann, belegt nichts.
Was das Werkzeug bewusst nicht tut
Ein Beweismittel wird an der Stelle wertlos, an der ein Werkzeug es eigenmächtig anfasst.
| Grenze | Warum |
|---|---|
| Kein Verschieben von Archiven | Ein Pfadwechsel verschiebt nichts; Neues landet am neuen Ort, Bisheriges bleibt liegen. Die Bestandsübernahme kopiert versiegelte Tage und prüft jede Kopie gegen ihren Nachweis – die Quelle bleibt, bis ein Mensch sie nach eigener Prüfung entfernt. |
| Kein Bereinigen des Prüfprotokolls | Es gibt keine Löschfunktion. Bei einer Bestandsübernahme gehen die Einträge mit ihren ursprünglichen Zeitpunkten mit. |
| Kein Klartextgeheimnis | Schlüssel der Agenten und das SMTP-Kennwort liegen AES-256-verschlüsselt in der Ablage; der Hauptschlüssel DPAPI-geschützt in einem Verzeichnis, das nur SYSTEM und Administratoren lesen. Ein Schlüssel erscheint nirgends im Klartext, auch nicht im Ereignisprotokoll. |
| Keine Fernaktualisierung ohne Signatur | Ein Agentenpaket wird nur eingespielt, wenn jede Datei Authenticode-signiert ist und die eigenen Dateien vom selben Herausgeber stammen wie der laufende Agent. Einen Schalter zum Abschalten gibt es nicht – er wäre genau die Lücke, gegen die die Prüfung da ist. |
| Keine Verbindung nach außen | Zentrale, Agenten und Konsole sprechen nur miteinander. Kein Cloud-Dienst, keine Telemetrie, keine Internetverbindung nötig. |
Technik und Voraussetzungen
Ein Server für die Zentrale, ein Agent je Domänencontroller, eine Konsole am Arbeitsplatz. Wo kein Agent installiert werden darf, holt die Zentrale über WinRM ab – als Ausnahme, nicht als Regel.
| Punkt | Anforderung |
|---|---|
| Zentrale | Windows Server ab 2016, .NET 10, Windows-Dienst. Ablage SQL Server (empfohlen) oder SQLite für kleine Installationen; Wechsel mit Bestandsübernahme |
| Agent | Windows-Dienst auf jedem Domänencontroller, Windows Server ab 2016. Meldet ausgehend über HTTPS, puffert bei Ausfall, kein eingehender Port, keine Vertrauensstellung, kein Fremdkonto |
| WinRM-Abholung | Für Systeme ohne Agent: PowerShell-Remoting über WinRM im einstellbaren Takt – ohne Lesezeichen auf dem Ziel, deshalb nur, wo ein Agent nicht möglich ist |
| Konsole | Windows 10/11 oder Windows Server, .NET 10. Anmeldung an der Zentrale mit dem Windows-Konto (Kerberos/Negotiate), Zugriff auf eine Gruppe einschränkbar |
| Verbindungssicherheit | TLS mit angeheftetem Fingerabdruck des Zentralen-Zertifikats – strenger als eine Vertrauenskette, weil die eigenständigen Kundendomänen Ihrer Zertifizierungsstelle ohnehin nicht vertrauen. HMAC-Signatur je Paket |
| Archiv | Tagesdateien NDJSON, komprimiert, SHA-256-Hashkette mit RSA-signierten Nachweisen. Pfad je Mandant und Domäne, auch auf Freigaben |
| Mailversand | Eigener SMTP-Server, STARTTLS oder SSL, zwei Verteiler, Kennwort AES-256-verschlüsselt |
| Rollout | Agent ohne Parameter per Softwareverteilung; Vorgaben je Domäne aus einer Gruppenrichtlinie (Adresse, Fingerabdruck, Mandant). Fernaktualisierung signierter Pakete über die bestehende Verbindung |
| Nachvollziehbarkeit | Prüfprotokoll in der Zentrale, Ereignisprotokoll „ISW Logon Sentinel", Löschprotokoll, Reichweite des Sicherheitsprotokolls je Domänencontroller |
| Rahmenwerke | Protokollierung und Nachweis im Sinne von NIS2, BSI IT-Grundschutz (OPS.1.1.5, DER.1) und Art. 32 DSGVO; Datenschutzdokumentation liegt bei |
Bezug und Kontakt
Das Werkzeug wird als Lizenz erworben und läuft vollständig in Ihrer eigenen Umgebung. Fragen zum Umfang, zur Lizenzierung oder zum Einsatz über viele Kundendomänen beantworte ich am schnellsten am Telefon.
Support: support@it-service-walter.com
Schreiben Sie kurz, wie viele Domänen und Domänencontroller – dann fällt die Antwort konkreter aus.
Shop
Die Werkzeuge der ISW-ADTools-Reihe werden über den Shop von IT-Service Walter vertrieben – Lizenz ohne Abonnement, unbegrenzte Laufzeit. Alle Angaben zu Ausstattung und Lizenzierung stehen auf der Produktseite.