Wissen Sie eigentlich, welche Rechte Ihr Webserver hat?

Der Webserver steht im Internet und muss jede Anfrage annehmen. Trotzdem darf er in vielen Netzen mit dem Domänencontroller sprechen – oft über unverschlüsseltes LDAP, nur damit sich Benutzer mit ihrem Domänenkonto anmelden können. Genau dieser Weg wird nach einem Einbruch zum Sprungbrett ins ganze Netz.

Warum das gerade jetzt zählt

Am 23. Oktober hat Palo Alto Networks (Unit 42) einen Angriff auf eine Regierungsstelle in Europa beschrieben, der über eine verwundbare PHP-Anwendung lief. Zwei Stunden nach dem Eindringen hatten die Angreifer Passwort-Hashes und MFA-Geheimnisse. Laut Bericht durchsuchten sie auf dem Webserver gezielt Passwortspeicher und LDAP-Konfigurationsdateien, suchten danach am Domänencontroller nach Administratorkonten, bauten einen NTLM-Relay-Tunnel ins Active Directory auf und versuchten, Domänen-Admin-Rechte zu erlangen. Die anfängliche Zuordnung zur PHP-Lücke PHP2Shell hat Unit 42 am 25. Oktober zurückgezogen – welche Lücke genutzt wurde, ist offen. Für diesen Beitrag spielt das keine Rolle: Der Webserver war das Einfallstor, das Ziel war die Domäne. Und die Angreifer wussten offenbar genau, wo auf einem Webserver die Zugangsdaten zum Active Directory liegen.

Die bequeme Lösung: Anmeldung per LDAP

Viele Webanwendungen – Ticketsystem, Zeiterfassung, Intranet, Wiki, Bürgerportal – sollen mit dem Domänenkonto funktionieren. Der schnellste Weg dahin ist fast immer derselbe: In der Anwendung einen LDAP-Server eintragen, ein Dienstkonto mit Kennwort hinterlegen, fertig. Das hat drei Folgen:

Dazu kommt: Damit LDAP funktioniert, muss die Firewall den Weg vom Webserver zum Domänencontroller öffnen. Genau diesen Weg nutzt ein Angreifer nach einem Einbruch.

Die bessere Lösung: Kerberos mit geschützten Konten

• Kein Kennwort auf dem Webserver: Der Browser holt sich beim Domänencontroller ein Ticket, die Anwendung prüft nur das Ticket. Benutzerkennwörter kommen beim Webserver gar nicht an.
• Eigenes Dienst- oder Maschinenkonto mit Service Principal Name (SPN): Die Anwendung bekommt eine eindeutige Identität, statt ein allgemeines Konto mitzubenutzen.
• Geschützt einrichten: Gruppenverwaltete Dienstkonten (gMSA) wechseln ihr Kennwort automatisch; wo die Anwendung das nicht unterstützt, ein langes, zufälliges Kennwort. Keine Delegierung an beliebige Dienste – wenn nötig, nur eingeschränkt auf das konkrete Ziel. Das Konto darf sich nirgends interaktiv anmelden.
• Nebeneffekt Einmalanmeldung: Benutzer im Netz melden sich nicht noch einmal an.

Wo Kerberos nicht geht – etwa bei Anwendungen, die nur LDAP können – mindestens LDAPS (verschlüsselt, Port 636) mit Channel Binding nutzen, ein Dienstkonto mit reinen Leserechten auf genau die nötigen Organisationseinheiten anlegen und den Zugriff an der Firewall auf genau diesen einen Domänencontroller und Port beschränken.

Segmentierung: Was darf der Webserver überhaupt erreichen?

So prüfen Sie es

# Auf dem Windows-Webserver ausführen (Name anpassen)
$dc = 'dc01.kommune.local'
88, 135, 389, 445, 636, 3268, 3269 | ForEach-Object {
    [pscustomobject]@{ Port = $_; Offen = (Test-NetConnection -ComputerName $dc -Port $_ -WarningAction SilentlyContinue).TcpTestSucceeded }
}

# Auf dem Domänencontroller: Protokollierung einschalten (nach der Auswertung wieder auf 0)
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics' -Name '16 LDAP Interface Events' -Value 2

# Nach einigen Tagen auswerten: welche Systeme binden unverschlüsselt?
Get-WinEvent -FilterHashtable @{ LogName = 'Directory Service'; Id = 2889 } |
    ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data } |
    Group-Object | Sort-Object Count -Descending | Select-Object Count, Name

Was zu tun ist

1. Webserver in eine eigene Zone: kein Webserver mit Internetanbindung im internen Netz.
2. Nur nötige Wege öffnen: auf genau ein Ziel und genau einen Port.
3. Anmeldung umstellen: wo möglich Kerberos mit eigenem, geschütztem Konto, sonst mindestens LDAPS mit Lesekonto.
4. Kennwörter auf dem Webserver minimieren und vorhandene Dienstkonto-Kennwörter nach einem Verdacht sofort erneuern.
5. LDAP-Signierung, Channel Binding und SMB-Signierung erzwingen – erst nach Auswertung von Ereignis 2889, sonst fallen Altsysteme aus.
6. Überwachen: Anmeldungen vom Webserver am Domänencontroller sind ein Alarmsignal.

Wie wir unterstützen

Solche Konstellationen finden wir in nahezu allen Umgebungen, die wir prüfen – teils von den Herstellern der Anwendungen selbst so eingerichtet, weil LDAP mit einem Dienstkonto der schnellste Weg zur Inbetriebnahme ist. Wir übernehmen die Bereinigung als Gesamtpaket oder in einzelnen Schritten:

Quellen & weiterführende Links

• Palo Alto Networks Unit 42

  Threat Brief: Critical Vulnerabilities in PHP (Fallbeschreibung vom 23.10.2026, Zuordnung zu PHP2Shell am 25.10.2026 zurückgezogen)
• The Hacker News

  PHP2Shell Exploitation Hits Government Entity Amid Global Scanning and Signs of AI-Assisted Hacking (25.10.2026)