Azure ATP
AzureATP ist der Teil, bei dem auf lokalen Domain Controllern ein Agent installiert wird, der die lokalen Anmeldungen überprüft und einiges mehr.
Einrichtung eines Sensors
Azure ATP ist relativ schnell eingerichtet, da die Software nur auf die On-Premises Domain Controller installiert wird. Sie überwacht quasi per Netzwerkmitschnitt alle Anmeldungen und und Versuche auf die Domain Controller und kann damit schon als erste Verteidigungslinie betrachtet werden. In einem Firmen-LAN erfolgen die meisten Zugriffe schon "authentifiziert". Angriffe landen daher direkt oder indirekt sehr schnell auf einem Domain Controller und können dort erfasst werden. Das ist zwar kein Ersatz einer Überwachung aller anderen Dienste auf erfolgreiche oder erfolglose Anmeldungen aber ein erster Anfang. Ein Angriff auf einen Member-Server um das Kennwort des lokalen Administrators zu erraten, wird so natürlich nicht erkannt.
Die Installation startet derart, dass Sie in ihrem Azure Portal unter https://%tenantname%.atp.azure.com/configuration?tab=sensors die Installationsquelle herunterladen und sich den "Zugriffsschlüsse" für die spätere Installation merken.
Das Setup auf einem Domain Controller ist unspektakulär und die meisten Administratoren werden den Sensor auch direkt auf dem DC installiert. Es ist aber möglich den Sensor "daneben" auf einem eigeständigen System zu installieren, welcher dann die Netzwerkdaten durch ein Port-Mirroring auf dem Switch geliefert bekommt. So einen Sensor kann ein Angreifer dann nicht außer Kraft setzen.
Im zweiten Dialog müssen Sie dann den für ihren Tenant speziellen Zugriffsschlüssel eintragen.
Das war es auch schon fast. Der Dienst startet und überwacht Eventlogs und Zugriffe, die er in die Cloud meldet.
Anpassen der Gruppenrichtlinie
Damit die Überwachung richtig vollständig ist, müssen Sie allerdings ihre Gruppenrichtlinien etwas anpassen, so dass auch wirklich alle relevanten Einträge im Eventlog landen. Aber auch das erkennt schon der Agent und meldet es:
- Azure ATP Advanced Audit Policy check
https://docs.microsoft.com/de-de/azure-advanced-threat-protection/atp-advanced-audit-policy
Benutzeranmeldungen
Nach wenigen Minuten sollten die ersten Events im AzureATP-Portal erscheinen und es wird schnell sichtbar, wie Azure ATP funktioniert: Es überwacht, wer sich wo und wann anmeldet und stellt Beziehungen her. Nach einigen Tagen weiß Azure-ATP, auf welchen Endgeräten ich mich anmelde und worauf ich zugreife.
Solche Informationen sind natürlich nicht zur Überwachung von Anwender gedacht, wenn gleich man sie dazu missbrauchen könnte. Die Information, wann sich wer wo anmeldet ist aber eine Basisinformation, auf die bei anderen Vorgängen referenziert werden kann, z.B. um Missbrauch zu erkennen oder eine Historie im Falle eines erfolgreichen Einbruchs zu ermitteln.
LDAP Missbrauch
Genauso kann ich nach Computerm suchen, auf die zugegriffen wurde. AzureATP generiert daraus dann Alarme, wenn "ungewöhnliche" Zugriffe erkannt werden. Hier z.B. die Meldung, dass ein Server per LDAP ziemlich viele Dinge abgefragt hat.
Hierbei handelt es sich um ein Provisoining-System, so dass diese Meldungen in Ordnung sind. Wenn aber jemand anderes z.B. per Skript in Erfahrung bringen will, welche Konten z.B. in "Domain Admins" Mitglied sind um dann gezielt diese Konten anzugreifen, dann sollten Sie So einen Alarm ernst nehmen. Das ist dann vergleichbar mit "Gaunerzinken (https://de.wikipedia.org/wiki/Zinken_(Geheimzeichen))" an der Hauswand, d.h. da hat vieleicht jemand schon mal Vorarbeit geleistet.
Password Guessing
Die Überwachung des DCs erkennt aber auch Anmeldeversuche, die nicht funktioniert haben. Solche Versuche landen natürlich im Eventlog aber welcher Administrator schaut dort regelmäßig hinein und führt die Meldungen zusammen. Hier sehne Sie den Alarm eines Clients, der fast 40.000 Kombinationen von Benutzern und Kennworten durchprobiert und dabei auch drei Konten "gefunden" hat.
Er konnte sich aber nicht anmelden. Die anderen tausende Konten gibt es einfach nicht und erscheinen auch recht willkürlich. Dennoch könnte so ein Angreifer ja schon mal einen Glückstreffer landen. In meine Fall bin ich natürlich der Ursache auf den Grund gegangen, denn ein Computer namens "WIN-29J1B3IL2" gibt es nicht im einem LAN.
Hier sind es Anmeldeversuche per SMTP auf Exchange, der keinen anonymen Zugang zulässt. Details dazu finden Sie auf Password Spray.
Unsicherer Kennworte
AzureATP erkennt auch, wenn jemand per LDAP ohne Verschlüsselung auf die Server zugreift und damit das Kennwort der Person ungesichert über das LAN übertragen wird. Solche Vorkommen werden als Bericht an hinterlegte Benutzer gesendet oder lassen sich im Portal herunter laden.
In dem Beispiel hat eine Sophos-Firewall sich per Dienstkonto über LDAP an meinem DC angemeldet, um die Berechtigungsgruppen auszulesen und meine Anmeldung zu überprüfen. Der Fehler lag auch hier bei mir, weil ich am Anfang "nur" LDAP statt LDAPS genutzt habe, um per Wireshark zu analysieren, wie die Abfragen genau erfolgen. Ich habe dann einfach vergessen die SSL-Verschlüsselung wieder zu aktivieren.
Der Zugriff per LDAP ohne SSL wird sich ändern. Es war schon für 2019 geplant aber vermutlich wird ein Update im Januar 2020 dafür sorgen, dass LDAP ohne SSL intern nicht mehr möglich ist
- LDAP Channel Binding and LDAP Signing
Requirements - JANUARY 2020 Updates
https://techcommunity.microsoft.com/t5/Core-Infrastructure-and-Security/LDAP-Channel-Binding-and-LDAP-Signing-Requirements-JANUARY-2020/ba-p/921536 - ADV190023 | Microsoft Guidance for
Enabling LDAP Channel Binding and LDAP
Signing
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023 - CVE-2017-8563 | Windows Elevation of
Privilege Vulnerability (REQUIRED):
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-8563
Erforderliches Update auf allen Clients, damit diese mit dem Server-Updates im Jan 2020 weiter arbeiten können. - How to enable LDAP signing in Windows
Server 2008
https://support.microsoft.com/en-us/help/935834/how-to-enable-ldap-signing-in-windows-server-2008 - Domain controller: LDAP server signing
requirements and Simple Binds
http://setspn.blogspot.com/2016/09/domain-controller-ldap-server-signing.html
DC-Replikationsattacke
Diesen Event sollten Sie eigentlich nie bekommen oder zumindest nicht von unbekannten Systemen. Der hier benutzte API-Aufruf verwenden Domaincontroller, um Änderungen untereinander zu übertragen. Ich nutze die API per Skripte selbst z.B. in GET-ADChanges und beschreibe Sie auf DirSync-API. Wenn aber ein anderes System diese APIs nutzt, dann hat ein Konto zu viele Rechte und kann auch sensible Informationen wie z.B. Hash-Werte abgreifen.
Hier war es aber wieder ADSync, der bei der Umstellung einer Domäne von ADFS auf "Password Hash Sync" natürlich erstmalig alle Hashwerte der Kennworte auslesen und in die Cloud übertragen muss. Das Dienstkonto benötigt dazu die besonderen Rechte eine "DC Replikation" durchzuführen. Über LDAP alleine rückt ein Domain Controller die Hashwerte ja nicht einfach raus. Auch das erkennt AzureATP.
Berechtigungen
Die Berechtigungen, wer AzureATP einsehen darf, erfolgt über Rollenruppen im AzureAD.
- Azure ATP role groups
https://docs.microsoft.com/de-de/azure-advanced-threat-protection/atp-role-groups
Weitere Link
- Advanced Thread Protection - ATP
- EOP Quarantäne
- Password Spray
- GET-ADChanges
- Azure advanced threat detection
https://docs.microsoft.com/en-us/azure/security/azure-threat-detection - https://docs.microsoft.com/de-de/azure-advanced-threat-protection/atp-technical-faq
- Dokumentation zu Azure Advanced Threat Protection
https://docs.microsoft.com/de-de/azure-advanced-threat-protection/ - What is Advanced Threat Analytics?
https://docs.microsoft.com/de-de/advanced-threat-analytics/what-is-ata - Quickstart: Download the Azure ATP
sensor setup package
https://docs.microsoft.com/de-de/azure-advanced-threat-protection/install-atp-step3