Helpdesk-Nachahmung erzeugt jetzt Anmeldeinformationen, die eine Passwortzurücksetzung überdauern

Der Anruf kommt über Teams. Der angezeigte Name sieht aus, als würde jemand aus der IT-Abteilung anrufen. Die Person am anderen Ende der Leitung ist geduldig, hilfsbereit und bittet den Mitarbeiter, Quick Assist zu öffnen, damit sie einen langsam laufenden Rechner überprüfen kann. Für die meisten Beschäftigten ist das ein ganz gewöhnliches Gespräch mit dem IT-Helpdesk. Bei der von Microsoft am 2. November beschriebenen Angriffskampagne war dies jedoch der erste Schritt, um ein Domänenkonto-Zertifikat zu erstellen, das auch nach jeder Passwortänderung weiterhin gültig blieb.

Die von SC Media aufgegriffene Sicherheitswarnung, die sich auf Informationen von The Hacker News stützt, beschreibt zwei Angriffe mit einem ähnlichen Ablauf. Im ersten Fall gaben sich die Angreifer als IT-Support-Mitarbeiter aus und überzeugten Beschäftigte davon, eine Quick-Assist-Sitzung zu starten. Anschließend nutzten sie den Fernzugriff, um eine anfällige Vorlage der Active Directory Certificate Services (AD CS) auszunutzen – ESC1 – und Zertifikate für privilegierte Konten anzufordern. Im zweiten Fall erzwangen die Angreifer mithilfe der PetitPotam-Methode eine Authentifizierung des Domänencontrollers. Anschließend fingen sie über ein ESC8-Relay ein Zertifikat des Domänencontrollers ab.

Die Empfehlungen von Microsoft sind kurz und eindeutig: Supportanfragen müssen über einen internen Kommunikationskanal verifiziert werden, unnötige Berechtigungen zur Zertifikatsregistrierung sind zu entfernen, und Extended Protection for Authentication muss auf den Webregistrierungsendpunkten aktiviert werden.

Das ist die Kurzfassung des Vorfalls. Doch es lohnt sich, genauer hinzusehen, was tatsächlich erbeutet wurde.

Das Zertifikat, das einen Passwort-Reset überlebt

Wenn ein Unternehmen eine solche Kompromittierung entdeckt, besteht die erste Reaktion meist darin, Passwörter zurückzusetzen und bestehende Sitzungen zu beenden. Das ist notwendig, macht ein bereits ausgestelltes Zertifikat jedoch nicht ungültig.

Ein von AD CS ausgestelltes Zertifikat ist ein eigenständiges Authentifizierungsmittel. Damit kann sich der darin benannte Benutzer oder Computer ohne Passwort authentifizieren. Das Zertifikat bleibt so lange gültig, bis es abläuft oder ausdrücklich widerrufen wird. Im Fall von ESC1 ermöglichte eine Zertifikatvorlage, bei der der Antragsteller den Namen des Zertifikatsinhabers selbst festlegen konnte, die Ausstellung eines Zertifikats im Namen eines privilegierten Kontos.

Die öffentlich zugänglichen Sicherheitsempfehlungen sind eindeutig: Diese Angriffsmethoden beruhen auf Fehlkonfigurationen und nicht auf Softwarefehlern. Deshalb gibt es auch keinen Patch, der das Problem behebt. Die Lösung liegt im operativen Betrieb: Fehlkonfigurierte Vorlagen müssen identifiziert, unnötige Registrierungsberechtigungen entfernt und bereits ausgestellte Zertifikate überprüft werden.

Für die meisten Leser ist der letzte Satz in diesem Absatz der entscheidende. Wenn ein Zertifikat im Namen eines privilegierten Kontos angefordert wurde, darf man nicht davon ausgehen, dass der Sicherheitsvorfall mit der Änderung des Passworts beendet ist. Das Zertifikat kann weiterhin zur Authentifizierung verwendet werden, bis es jemand findet und widerruft. Diese Suche erfolgt nicht automatisch. Sie setzt voraus, dass das für das Identitätsmanagement zuständige Team weiß, wonach es suchen muss.

Die Verifizierung beim Helpdesk ist die entscheidende Schutzmaßnahme

Es ist wichtig, Beschäftigte darin zu schulen, solche Anfragen nach Fernzugriff abzulehnen. Das gesamte Risiko kann jedoch nicht allein auf sie abgewälzt werden.

In den meisten mittelständischen Unternehmen wird der First-Level-Support von einer einzelnen Person oder einem sehr kleinen Team übernommen. Quick Assist ist dabei wahrscheinlich ein völlig legitimes und regelmäßig genutztes Werkzeug. Wenn das einzige Schutzinstrument ein einmal jährlich angesehenes Security-Awareness-Video ist, verlangen wir von den Anwendern eine Entscheidung, die eigentlich durch einen klar definierten Prozess geregelt sein sollte.

Der wirksamere Schutz liegt in der Verifizierung: Jede Anfrage nach Fernzugriff, die über Teams, Telefon oder Chat eingeht, muss anhand eines bestehenden Tickets oder eines durch eine Führungskraft genehmigten Rückrufs überprüft werden, bevor Quick Assist gestartet wird.

Hier zeigt sich der praktische Nutzen eines Security-Awareness-Trainings. Ein Managed Cyber Awareness Programm kann einen solchen Helpdesk-Anruf genauso realitätsnah simulieren wie einen Phishing-Link. Gleichzeitig können die Beschäftigten den konkreten Satz einüben, mit dem sie eine verdächtige Anfrage höflich ablehnen:

„Ich rufe den Service Desk unter der offiziell veröffentlichten Telefonnummer zurück.“

Das ist kein Satz aus einem Richtliniendokument, sondern eine konkrete Verhaltensweise, die auch dann funktioniert, wenn tatsächlich ein verdächtiger Anruf eingeht.

Entscheidend ist, dass der Prozess auf beiden Seiten funktioniert. Wenn ein Mitarbeiter selbst beim Service Desk anruft, muss der Service Desk seine Identität überprüfen. Ruft hingegen der Service Desk den Mitarbeiter an, muss dieser die Identität des Anrufers verifizieren. Eine angezeigte Telefonnummer oder ein Name in Teams ist kein Identitätsnachweis.

Die Zertifikatsinfrastruktur ist wahrscheinlich älter als das aktuelle Team

Der schwierigere Teil dieser Angriffskampagne betrifft einen Dienst, den viele Unternehmen dieser Größenordnung vor Jahren eingerichtet und anschließend kaum noch überprüft haben.

AD CS wurde häufig installiert, um Maschinenzertifikate beispielsweise für WLAN- oder RDP-Verbindungen auszustellen. Die Person, die damals die Zertifikatvorlagen und deren Konfiguration verstand, hat das Unternehmen inzwischen möglicherweise längst verlassen.

Im Laufe der Zeit sammeln sich in den Vorlagen immer mehr Registrierungsberechtigungen an, ohne dass sich noch jemand daran erinnern kann, warum diese ursprünglich vergeben wurden. Die ESC1-Schwachstelle hängt in der Regel davon ab, wer Zertifikate anfordern darf und ob der Antragsteller den Namen des Zertifikatsinhabers selbst festlegen kann.

Diese Probleme lassen sich auch ohne ein umfassendes PKI-Modernisierungsprojekt aufdecken. Voraussetzung ist allerdings, dass die Organisation AD CS als Bestandteil ihrer Identitätsinfrastruktur betrachtet und nicht als vergessenen Hilfsdienst im Hintergrund.

Wenn der Service Desk die Eingangstür ist, dann ist AD CS der Ersatzschlüssel. An dieser Stelle treffen die beiden Teile der Angriffskampagne aufeinander: Ein Mitarbeiter gewährt Fernzugriff, und der Angreifer gelangt anschließend zu einer Zertifikatvorlage, über die er sich mehr Berechtigungen verschaffen kann, als ihm ursprünglich zustehen.

Die von Microsoft empfohlenen Gegenmaßnahmen erfordern keinen großen technischen Entwicklungsaufwand. Es handelt sich hauptsächlich um Konfigurationsänderungen und die Ausführung eines Prüfskripts.

Drei Prüfungen für dieses Quartal

Bevor der nächste Anruf über Teams eingeht, kann ein kleines Infrastruktur- oder Identitätsmanagement-Team drei konkrete Maßnahmen umsetzen:

• Alle AD-CS-Zertifikatvorlagen überprüfen: Listen Sie sämtliche Zertifikatvorlagen auf, für die eine Registrierungsberechtigung (Enroll) besteht, und kennzeichnen Sie alle Vorlagen, bei denen der Antragsteller den Subject Alternative Name (SAN) selbst festlegen kann. Ein privilegiertes Konto darf nicht über eine Vorlage erreichbar sein, die von einem gewöhnlichen Arbeitsplatzrechner aus genutzt werden kann.
• Ein verbindliches Verifizierungsverfahren für den Service Desk einführen: Lassen Sie ein schriftliches Prüfverfahren für eingehende und ausgehende Supportanrufe erstellen, testen und unter den Beschäftigten verbreiten. Das Verfahren sollte direkt neben dem Telefon liegen und nicht ausschließlich Bestandteil des jährlichen Schulungsmoduls sein.
• Die Sicherheit der webbasierten Zertifikatsregistrierung erhöhen: Aktivieren Sie Extended Protection for Authentication auf den Webregistrierungsendpunkten und entfernen Sie alle Registrierungsberechtigungen, denen kein aktueller Systembedarf mehr zugrunde liegt.

Die Angriffskampagne wird so lange funktionieren, wie sich die ersten Minuten eines solchen Anrufs für Angreifer leicht ausnutzen lassen.

Die Frage, vor der die für das Risiko verantwortliche Führungskraft steht, ist eigentlich viel einfacher: Wissen wir heute mit Sicherheit, ob ein gewöhnlicher Arbeitsplatzrechner ein Zertifikat im Namen eines Domänenadministrators anfordern kann?

Wenn die Antwort darauf nicht sofort gegeben werden kann, sollte genau dort das nächste Sicherheitsaudit beginnen.