Service-Account-Chaos in Windows-Domänen: Warum statische Passwörter ein unterschätztes Risiko sind
In fast jeder Windows-Domäne, die ich in den letzten Jahren analysiert habe, gibt es sie: Service-Accounts, deren Passwörter seit Jahren — manchmal seit über einem Jahrzehnt — nicht geändert wurden. SQL-Dienst-Konten, Backup-Agenten, Monitoring-Konten, Exchange-Dienste. Statisch. Unverändert. Vergessen.
Das ist kein Einzelfall, das ist die Regel. Und es ist eines der größten Sicherheitsrisiken, über das in mittelständischen IT-Umgebungen kaum gesprochen wird.
1. Was sind Service-Accounts — und warum sind sie anders?
Service-Accounts sind Active-Directory-Konten, die nicht für menschliche Benutzer gedacht sind, sondern für Dienste, Applikationen und automatisierte Prozesse. Typische Beispiele:
- SQL Server-Dienstkonten (
svc-sql) - Backup-Agenten (
svc-backup,svc-veeam) - Monitoring-Konten (
svc-zabbix,svc-nagios) - Exchange- und SMTP-Relaykonten
- Scheduled-Task-Konten für Skripte und Automatisierungen
- Dienstkonten für ERP- und CRM-Systeme
Das Problem: Bei normalen Benutzerkonten erzwingt Active Directory über Passwort-Policies regelmäßige Änderungen. Service-Accounts hingegen werden häufig von dieser Policy ausgenommen — weil eine automatische Passwortänderung den laufenden Dienst zum Absturz bringen würde.
Das ist technisch verständlich. Aber es führt dazu, dass diese Konten jahrelang mit demselben Passwort betrieben werden — oft mit weitreichenden Berechtigungen.
2. Die realen Risiken statischer Passwörter
Jedes Dienstkonto mit einem SPN (Service Principal Name) ist ein potenzielles Kerberoasting-Ziel. Angreifer können ohne Administratorrechte TGS-Tickets für diese Konten anfordern und offline cracken. Je länger ein Passwort unverändert bleibt, desto mehr Zeit hat ein Angreifer für den Angriff.
Ein Administrator, der das Unternehmen verlässt, hat möglicherweise Kenntnis von Dienstpasswörtern — sei es weil er sie eingerichtet hat, oder weil sie in Tickets, Teams-Chats oder Konfigurationsdateien kommuniziert wurden. Ohne Rotation behält er dieses Wissen dauerhaft.
Ein kompromittiertes Dienstkonto mit hohen Berechtigungen wird im Rahmen eines Angriffs gezielt für Lateral Movement genutzt. Je mehr Systeme dasselbe Dienstkonto verwenden, desto größer die Angriffsfläche.
Viele Administratoren speichern Dienstpasswörter in Konfigurationsdateien, Deployment-Skripten oder sogar in Klartext-Dateien auf Netzlaufwerken. Ein einziger Datenzugriff eines Angreifers gibt ihm damit Zugang zu zahlreichen Diensten.
3. Wie es in der Praxis aussieht
Ein typisches Bild aus einem realen Audit einer mittelständischen Windows-Domäne:
| Konto | Berechtigungen | Letztes Passwort-Reset | Risiko |
|---|---|---|---|
svc-sql |
Domain Admin | 2017 | Kritisch |
svc-backup |
Backup Operators | 2020 | Hoch |
svc-monitoring |
Read-Only Domain Controller | 2019 | Hoch |
svc-erp |
Domänen-Benutzer + DB-Admin | 2021 | Mittel |
Das Konto svc-sql mit Domain-Admin-Rechten und einem Passwort aus dem Jahr 2017 ist leider kein erfundenes Extrembeispiel. Wer regelmäßig AD-Audits durchführt, kennt solche Funde aus dem Alltag.
4. Was BSI, NIST und NIS2 fordern
Regelmäßige Passwortrotation für privilegierte Konten ist keine Empfehlung — sie ist eine Anforderung mehrerer regulatorischer Rahmenbedingungen:
Passwörter für privilegierte Konten müssen regelmäßig gewechselt werden. Für Service-Accounts empfiehlt das BSI mindestens 20 Zeichen Länge und eine Rotation bei sicherheitsrelevanten Ereignissen.
Passwörter sollen bei Verdacht auf Kompromittierung sofort gewechselt werden. Für automatisierte Konten gelten lange, zufällig generierte Passwörter als Best Practice.
Unternehmen müssen technische und organisatorische Maßnahmen zur Zugangs- und Identitätsverwaltung nachweisen. Statische Service-Account-Passwörter sind ein klarer Verstoß gegen diesen Grundsatz.
Zugang zu Systemen und Applikationen muss durch sichere Authentifizierungsverfahren geschützt werden. Regelmäßige Rotation privilegierter Passwörter ist Bestandteil dieser Anforderung.
5. Wann muss rotiert werden? Die Checkliste
Passwortrotation für Service-Accounts ist in folgenden Situationen zwingend erforderlich:
Ein Mitarbeiter mit Kenntnis der Passwörter verlässt das Unternehmen
Ein Sicherheitsvorfall wird vermutet oder festgestellt
Passwörter wurden über unsichere Kanäle kommuniziert (E-Mail, Teams, Ticket-System)
Ein externer Dienstleister hatte Zugang zu Dienstkonten und die Zusammenarbeit endet
Ein Compliance-Audit schreibt regelmäßige Rotation vor (ISO 27001, BSI, PCI DSS)
Das letzte Passwort-Reset liegt mehr als 90 Tage zurück (für hochprivilegierte Konten)
Das Konto ist in einem Kerberoasting-Scan als gefährdet markiert worden
6. Automatisierung als Ausweg
Manuelle Passwortrotation für Service-Accounts ist fehleranfällig und zeitintensiv — vor allem weil dabei immer auch die Dienste aktualisiert werden müssen, die das Konto verwenden. Ein vergessener Eintrag bedeutet, dass der Dienst nach der Rotation nicht mehr startet.
Der richtige Ansatz ist daher Automatisierung mit vollständigem Audit-Trail:
- Fälligkeit wird auf Basis des AD-Attributs
pwdLastSetberechnet - Neues Passwort wird automatisch generiert (konfigurierbare Policy, bis 128 Zeichen)
- Passwort wird per E-Mail an die zuständigen Empfänger zugestellt
- Für hochprivilegierte Konten: Passwort-Splitting nach dem Vier-Augen-Prinzip
- Alle Aktionen werden lückenlos in einem Audit-Log protokolliert
- Ausführung als Scheduled Task, vollständig unbeaufsichtigt
Der ISW AD Password Rotator automatisiert die BSI-konforme Rotation von Active-Directory-Passwörtern für Service-Accounts und privilegierte Benutzer — inklusive Vier-Augen-Prinzip, vollständigem Audit-Log und DSGVO-konformer Berichtsverwaltung. Als Standortlizenz ohne Abonnement.
Service-Account-Passwörter, die seit Jahren nicht geändert wurden, sind kein Kavaliersdelikt — sie sind eine ernsthafte Sicherheitslücke, die von modernen Angreifern systematisch ausgenutzt wird. BSI, NIST und NIS2 fordern klare Maßnahmen.
Der erste Schritt: Einen Überblick verschaffen, welche Service-Accounts überhaupt existieren und wann deren Passwörter zuletzt geändert wurden. Wer dabei systematisch vorgehen will, sollte auf Automatisierung setzen — statt auf gut gemeinte, aber selten eingehaltene manuelle Prozesse.
