Account Lockout durch AzureVM
Je mehr Dienste man auch über das Internet bereit stellt, desto eher werden Angriff auf Konten gefahren. Beliebt ist natürlich der Administrator, da das Konto ja entsprechend bekannt ist. Aber wenn Sie einen Angriff erkannt haben, ist es nicht immer einfach die Quelle dingfest zu machen. Einige Wochen früher habe ich schon bei einem Kunden einen alten Eintrag in Docker dingfest machen können. Siehe auch Account Lockout mit Docker. Diesmal war es RDP mit Azure.
Angriffe erkennen
Es gibt verschiedene Wege solche Angriffe zu erkennen. Wenn es ein IIS ist, dann fallen natürlich mehrere "401 Authentication Required" auf. Siehe dazu auch Dreimal 401 mit Negotiate und HTTP Authentication. Sie können auch das Security Eventlog auf 4776 oder 4740-Events überwachen. Aber diesmal bin ich über einen anderen Weg auf die Attacke gekommen. Ich habe für eine Fehlersuche mein Skript GET-ADChanges eingesetzt, um die Änderungen im Active Directory zu überwachen und dabei ist mir folgendes aufgefallen:
Was oder wer auch immer scheint mir hier den Administrator immer wieder auszusperren. Die Uhrzeit links (17:12:35 - 17.13.32) zeigt, dass allein 7 Versuche in ca. einer Minute erfolgt sind. Das war auch keine einmalige Aktion sondern kontinuierlich. Da musste ich dann mal hinterher.
Suche nach dem Lockout
Windows protokolliert fehlerhafte Anmeldungen, wenn Sie dies im Audidlog aktiviert haben. Das geht über Gruppenrichtlinien aber auch über lokale Sicherheitsrichtlinien. Letztere können auch per Kommandozeile gesetzt werden
REM Aktivierung der Anmeldeueberwachung fuer Deutsche und englische Server auditpol /set /category:"Logon/Logoff" /success:enable /failure:enable auditpol /set /category:"An-/Abmeldung" /success:enable /failure:enable
Seltener wird die Option zum Deaktivieren gebraucht. Vermutlich eher von Einbrechern, um danach weitere Spuren zu verhindern
REM Deaktivierung der Anmeldeueberwachung fuer Deutsche und englische Server auditpol /set /category:"Logon/Logoff" /success:enable /failure:enable auditpol /set /category:"An-/Abmeldung" /success:enable /failure:enable
Eventlog auf dem PDC Emulator
Wir sollten ja alle wissen, dass der "Lockout"-Status immer auf dem PDC-Emulator aktuell gepflegt und nicht über die normale AD-Replikation abgeglichen wird. Also gilt mein Blick dem Security Eventlog auf dem PDC-Emulator. Wie nicht anders zu erwarten finden sich die 4776 Events sehr schnell und in hoher Anzahl. Man hätte schon früher drauf kommen können, wenn ich eine Überwachung etabliert hätte. Bei einem Test-Lab gelten aber andere Prioritäten.
Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 06.02.2019 17:50:31 Event ID: 4776 Task Category: Credential Validation Level: Information Keywords: Audit Failure User: N/A Computer: dc1.uclabor.de Description: The computer attempted to validate the credentials for an account. Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Logon Account: ADMINISTRATOR Source Workstation: Error Code: 0xC000006A Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" /> <EventID>4776</EventID> <Version>0</Version> <Level>0</Level> <Task>14336</Task> <Opcode>0</Opcode> <Keywords>0x8010000000000000</Keywords> <TimeCreated SystemTime="2019-02-06T16:50:31.386079200Z" /> <EventRecordID>5996792</EventRecordID> <Correlation /> <Execution ProcessID="596" ThreadID="2516" /> <Channel>Security</Channel> <Computer>dc1.uclabor.de</Computer> <Security /> </System> <EventData> <Data Name="PackageName">MICROSOFT_AUTHENTICATION_PACKAGE_V1_0</Data> <Data Name="TargetUserName">ADMINISTRATOR</Data> <Data Name="Workstation"> </Data> <Data Name="Status">0xc000006a</Data> </EventData> </Event>
Soweit nicht unerwartet aber die wichtigste Information fehlt natürlich. Aus dem Event geht nicht hervor, welcher Client den Zugriff versucht hat. Das Feld "Workstation" ist leer. Es gibt Fundstellen im Internet, dass das normal ist, wenn der Client nicht zuverlässig bestimmt werden kann. SMB/LDAP-Signing sollen hier notwendig sein. Bestätigen kann ich das nicht
Analyse mit Netlogon auf dem PDC-Emulator
Da das Eventlog hier nicht mehr Daten liefert, musste ich NETLOGON etwas genauer auf die Finger schauen. Also Debugging eingeschaltet und mit get-content die Datei überwacht und etwas gewartet.
Nltest /DBFlag:2080FFFF get-content c:\windows\debug\netlogon.log -wait -tail 1 nltest /dbflag:0x0
Nicht vergessen danach das Tracing wieder abzuschalten. Die Ausgaben enthalten schon ein paar interessante Zeilen:
02/06 17:05:32 [LOGON] [5568] UCLABOR: SamLogon: Transitive Network logon of (null)\ADMINISTRATOR from (via DC2) Entered 02/06 17:05:32 [LOGON] [5568] UCLABOR: SamLogon: Transitive Network logon of (null)\ADMINISTRATOR from (via DC2) Returns 0xC000006A 02/06 17:05:45 [LOGON] [4492] UCLABOR: SamLogon: Transitive Network logon of (null)\ADMINISTRATOR from (via DC2) Entered 02/06 17:05:45 [LOGON] [4492] UCLABOR: SamLogon: Transitive Network logon of (null)\ADMINISTRATOR from (via DC2) Returns 0xC000006A
Wir sehen die Versuche des "Administrator und woher sie gekommen sind. Auch der Fehlercode "0xC000006A" ist ein Hinweis auf "Account Lockout". Also weiter zum anderen DC2
Analyse auf DC2
Auf dem DC, von dem die Anfrage auf den PDC-Emulator weiter gegeben wird ist aber auch im Eventlog der 4776-Event Eintrag zu sehen:
Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 06.02.2019 17:59:14 Event ID: 4776 Task Category: Credential Validation Level: Information Keywords: Audit Failure User: N/A Computer: dc2.uclabor.de Description: The computer attempted to validate the credentials for an account. Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Logon Account: ADMINISTRATOR Source Workstation: Error Code: 0xC000006A Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" /> <EventID>4776</EventID> <Version>0</Version> <Level>0</Level> <Task>14336</Task> <Opcode>0</Opcode> <Keywords>0x8010000000000000</Keywords> <TimeCreated SystemTime="2019-02-06T16:59:14.313257800Z" /> <EventRecordID>2641349</EventRecordID> <Correlation /> <Execution ProcessID="524" ThreadID="5108" /> <Channel>Security</Channel> <Computer>dc2.uclabor.de</Computer> <Security /> </System> <EventData> <Data Name="PackageName">MICROSOFT_AUTHENTICATION_PACKAGE_V1_0</Data> <Data Name="TargetUserName">ADMINISTRATOR</Data> <Data Name="Workstation"> </Data> <Data Name="Status">0xc000006a</Data> </EventData> </Event>
Der Computername ist hier aber ebenso leer wie im 4740 Event, der hier auch noch sichtbar wird:
Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 06.02.2019 17:37:05 Event ID: 4740 Task Category: User Account Management Level: Information Keywords: Audit Success User: N/A Computer: dc2.uclabor.de Description: A user account was locked out. Subject: Security ID: SYSTEM Account Name: DC2$ Account Domain: UCLABOR Logon ID: 0x3E7 Account That Was Locked Out: Security ID: UCLABOR\Administrator Account Name: Administrator Additional Information: Caller Computer Name: Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" /> <EventID>4740</EventID> <Version>0</Version> <Level>0</Level> <Task>13824</Task> <Opcode>0</Opcode> <Keywords>0x8020000000000000</Keywords> <TimeCreated SystemTime="2019-02-06T16:37:05.624120100Z" /> <EventRecordID>2640936</EventRecordID> <Correlation /> <Execution ProcessID="524" ThreadID="6912" /> <Channel>Security</Channel> <Computer>dc2.uclabor.de</Computer> <Security /> </System> <EventData> <Data Name="TargetUserName">Administrator</Data> <Data Name="TargetDomainName"> </Data> <Data Name="TargetSid">S-1-5-21-11949449-30417519-71842111-500</Data> <Data Name="SubjectUserSid">S-1-5-18</Data> <Data Name="SubjectUserName">DC2$</Data> <Data Name="SubjectDomainName">UCLABOR</Data> <Data Name="SubjectLogonId">0x3e7</Data> </EventData> </Event>
So kommen wir hier leider nicht weiter.
Netlogon auf DC2
Also habe ich auch hier noch mal das Netlogon-Debugging aktiviert und etwas abgewartet. Nach wenigen Sekunden dann die nächsten Zugriffe.
02/06 17:08:03 [LOGON] [5108] UCLABOR: SamLogon: Transitive Network logon of (null)\ADMINISTRATOR from (via PRTG) Returns 0xC000006A 02/06 17:08:08 [LOGON] [5108] UCLABOR: SamLogon: Transitive Network logon of (null)\ADMINISTRATOR from (via PRTG) Entered 02/06 17:08:08 [CRITICAL] [5108] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimate for 0xc000006a) 02/06 17:08:08 [LOGON] [5108] UCLABOR: SamLogon: Transitive Network logon of (null)\ADMINISTRATOR from (via PRTG) Returns 0xC000006A
Hier sehe ich dann den Verweis auf meinen PRTG-Server. Sie können schon ahnen, was nun kommt:
Eventlog
Die Hoffnung stirbt zuletzt aber ich habe vergebens gehofft. Natürlich finden sich auch hier die 4776 und 4740 Events im Security Eventlog:
Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 2/6/2019 8:58:01 PM Event ID: 4776 Task Category: Credential Validation Level: Information Keywords: Audit Failure User: N/A Computer: PRTG.uclabor.de Description: The computer attempted to validate the credentials for an account. Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Logon Account: ADMINISTRATOR Source Workstation: Error Code: 0xC0000064 Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" /> <EventID>4776</EventID> <Version>0</Version> <Level>0</Level> <Task>14336</Task> <Opcode>0</Opcode> <Keywords>0x8010000000000000</Keywords> <TimeCreated SystemTime="2019-02-06T19:58:01.061087300Z" /> <EventRecordID>105730642</EventRecordID> <Correlation /> <Execution ProcessID="516" ThreadID="1648" /> <Channel>Security</Channel> <Computer>PRTG.uclabor.de</Computer> <Security /> </System> <EventData> <Data Name="PackageName">MICROSOFT_AUTHENTICATION_PACKAGE_V1_0</Data> <Data Name="TargetUserName">ADMINISTRATOR</Data> <Data Name="Workstation"> </Data> <Data Name="Status">0xc0000064</Data> </EventData> </Event>
Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 2/6/2019 8:57:58 PM Event ID: 4625 Task Category: Logon Level: Information Keywords: Audit Failure User: N/A Computer: PRTG.uclabor.de Description: An account failed to log on. Subject: Security ID: NULL SID Account Name: - Account Domain: - Logon ID: 0x0 Logon Type: 3 Account For Which Logon Failed: Security ID: NULL SID Account Name: ADMINISTRATOR Account Domain: Failure Information: Failure Reason: Unknown user name or bad password. Status: 0xC000006D Sub Status: 0xC000006A Process Information: Caller Process ID: 0x0 Caller Process Name: - Network Information: Workstation Name: - Source Network Address: - Source Port: - Detailed Authentication Information: Logon Process: NtLmSsp Authentication Package: NTLM Transited Services: - Package Name (NTLM only): - Key Length: 0 This event is generated when a logon request fails. It is generated on the computer where access was attempted. The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe. The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network). The Process Information fields indicate which account and process on the system requested the logon. The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases. The authentication information fields provide detailed information about this specific logon request. - Transited services indicate which intermediate services have participated in this logon request. - Package name indicates which sub-protocol was used among the NTLM protocols. - Key length indicates the length of the generated session key. This will be 0 if no session key was requested. Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" /> <EventID>4625</EventID> <Version>0</Version> <Level>0</Level> <Task>12544</Task> <Opcode>0</Opcode> <Keywords>0x8010000000000000</Keywords> <TimeCreated SystemTime="2019-02-06T19:57:58.014290800Z" /> <EventRecordID>105730638</EventRecordID> <Correlation /> <Execution ProcessID="516" ThreadID="1648" /> <Channel>Security</Channel> <Computer>PRTG.uclabor.de</Computer> <Security /> </System> <EventData> <Data Name="SubjectUserSid">S-1-0-0</Data> <Data Name="SubjectUserName">-</Data> <Data Name="SubjectDomainName">-</Data> <Data Name="SubjectLogonId">0x0</Data> <Data Name="TargetUserSid">S-1-0-0</Data> <Data Name="TargetUserName">ADMINISTRATOR</Data> <Data Name="TargetDomainName"> </Data> <Data Name="Status">0xc000006d</Data> <Data Name="FailureReason">%%2313</Data> <Data Name="SubStatus">0xc000006a</Data> <Data Name="LogonType">3</Data> <Data Name="LogonProcessName">NtLmSsp </Data> <Data Name="AuthenticationPackageName">NTLM</Data> <Data Name="WorkstationName">-</Data> <Data Name="TransmittedServices">-</Data> <Data Name="LmPackageName">-</Data> <Data Name="KeyLength">0</Data> <Data Name="ProcessId">0x0</Data> <Data Name="ProcessName">-</Data> <Data Name="IpAddress">-</Data> <Data Name="IpPort">-</Data> </EventData> </Event>
Leider sind aber auch hier die IP-Adressen und Ports und der Workstation-Name wieder leer. Auch die angezeigte ProzessID "516" oder ThreadID "1648" haben im Task-Manager keine Entsprechung
NETLOGON.LOG
Und wieder habe ich das NETLOGON-Logging aktiviert, auch wenn es nur ein Member-Server ist. Hier sind die gleichen Meldungen zu sehen. Aber neben dem "ADMINISTRATOR" kommen hier noch sehr viel andere Konten zum Vorschein. Da versucht jemand also tatsächlich eine Dictionary-Attacke gegen meinen Server.
02/06 21:03:50 [LOGON] [5532] SamLogon: Network logon of (null)\ADMINISTRATOR from Entered 02/06 21:03:50 [CRITICAL] [5532] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimate for 0xc000006a) 02/06 21:03:50 [LOGON] [5532] SamLogon: Network logon of (null)\ADMINISTRATOR from Returns 0xC000006A 02/06 21:03:53 [LOGON] [5532] SamLogon: Network logon of (null)\ADMINISTRATOR from Entered 02/06 21:03:53 [CRITICAL] [5532] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimate for 0xc000006a) 02/06 21:03:53 [LOGON] [5532] SamLogon: Network logon of (null)\ADMINISTRATOR from Returns 0xC000006A 02/06 21:03:53 [LOGON] [5532] SamLogon: Network logon of (null)\CONTABILIDAD from Entered 02/06 21:03:53 [CRITICAL] [5532] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimate for 0xc0000064) 02/06 21:03:53 [LOGON] [5532] SamLogon: Network logon of (null)\CONTABILIDAD from Returns 0xC0000064 02/06 21:03:54 [LOGON] [5532] SamLogon: Network logon of (null)\CCISUPPORT from Entered 02/06 21:03:54 [CRITICAL] [5532] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimate for 0xc0000064) 02/06 21:03:54 [LOGON] [5532] SamLogon: Network logon of (null)\CCISUPPORT from Returns 0xC0000064 02/06 21:04:23 [LOGON] [1648] SamLogon: Network logon of (null)\ADMIN from Entered 02/06 21:04:23 [CRITICAL] [1648] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimatefor 0xc0000064) 02/06 21:04:23 [LOGON] [1648] SamLogon: Network logon of (null)\ADMIN from Returns 0xC0000064 02/06 21:04:26 [LOGON] [1648] SamLogon: Network logon of (null)\ADMINISTRATOR from Entered 02/06 21:04:26 [CRITICAL] [1648] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimatefor 0xc000006a) 02/06 21:04:26 [LOGON] [1648] SamLogon: Network logon of (null)\ADMINISTRATOR from Returns 0xC000006A 02/06 21:04:27 [LOGON] [1648] SamLogon: Network logon of (null)\ADMINISTRATOR from Entered 02/06 21:04:27 [CRITICAL] [1648] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimatefor 0xc000006a) 02/06 21:04:27 [LOGON] [1648] SamLogon: Network logon of (null)\ADMINISTRATOR from Returns 0xC000006A 02/06 21:04:28 [LOGON] [1648] SamLogon: Network logon of (null)\CLIENT from Entered 02/06 21:04:28 [CRITICAL] [1648] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimatefor 0xc0000064) 02/06 21:04:28 [LOGON] [1648] SamLogon: Network logon of (null)\CLIENT from Returns 0xC0000064 02/06 21:04:30 [LOGON] [1648] SamLogon: Network logon of (null)\OWNER from Entered 02/06 21:04:30 [CRITICAL] [1648] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimatefor 0xc0000064) 02/06 21:04:30 [LOGON] [1648] SamLogon: Network logon of (null)\OWNER from Returns 0xC0000064 02/06 21:04:37 [LOGON] [1648] SamLogon: Network logon of (null)\ADMINISTRATOR from Entered 02/06 21:04:37 [CRITICAL] [1648] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimatefor 0xc000006a) 02/06 21:04:37 [LOGON] [1648] SamLogon: Network logon of (null)\ADMINISTRATOR from Returns 0xC000006A 02/06 21:05:08 [LOGON] [5532] SamLogon: Network logon of (null)\ADMINISTRATOR from Entered 02/06 21:05:08 [CRITICAL] [5532] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimatefor 0xc000006a) 02/06 21:05:08 [LOGON] [5532] SamLogon: Network logon of (null)\ADMINISTRATOR from Returns 0xC000006A 02/06 21:05:12 [LOGON] [5532] SamLogon: Network logon of (null)\ADMINISTRADOR from Entered 02/06 21:05:12 [CRITICAL] [5532] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimatefor 0xc0000064) 02/06 21:05:12 [LOGON] [5532] SamLogon: Network logon of (null)\ADMINISTRADOR from Returns 0xC0000064 02/06 21:05:13 [LOGON] [5532] SamLogon: Network logon of (null)\METASYSSYSAGENT from Entered 02/06 21:15:20 [LOGON] [4232] SamLogon: Network logon of (null)\AFG from Returns 0xC0000064 02/06 21:15:20 [LOGON] [4232] SamLogon: Network logon of (null)\EZERBA from Entered 02/06 21:15:20 [CRITICAL] [4232] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimate for 0xc0000064) 02/06 21:15:20 [LOGON] [4232] SamLogon: Network logon of (null)\EZERBA from Returns 0xC0000064 02/06 21:15:50 [LOGON] [1960] SamLogon: Network logon of (null)\ADMINISTRATOR from Entered 02/06 21:15:50 [LOGON] [4232] SamLogon: Network logon of (null)\DARREN from Entered 02/06 21:15:50 [CRITICAL] [1960] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimate for 0xc000006a) 02/06 21:15:50 [LOGON] [1960] SamLogon: Network logon of (null)\ADMINISTRATOR from Returns 0xC000006A 02/06 21:15:50 [CRITICAL] [4232] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimate for 0xc0000064) 02/06 21:15:50 [LOGON] [4232] SamLogon: Network logon of (null)\DARREN from Returns 0xC0000064 02/06 21:15:52 [LOGON] [4232] SamLogon: Network logon of (null)\ADMINISTRATOR from Entered 02/06 21:15:53 [CRITICAL] [4232] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimate for 0xc000006a) 02/06 21:15:53 [LOGON] [4232] SamLogon: Network logon of (null)\ADMINISTRATOR from Returns 0xC000006A 02/06 21:15:53 [LOGON] [4232] SamLogon: Network logon of (null)\EZERBA from Entered 02/06 21:15:53 [CRITICAL] [4232] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimate for 0xc0000064) 02/06 21:15:53 [LOGON] [4232] SamLogon: Network logon of (null)\EZERBA from Returns 0xC0000064 02/06 21:15:57 [LOGON] [5580] SamLogon: Network logon of (null)\ADMINISTRATOR from Entered 02/06 21:15:57 [CRITICAL] [5580] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimate for 0xc000006a) 02/06 21:15:57 [LOGON] [5580] SamLogon: Network logon of (null)\ADMINISTRATOR from Returns 0xC000006A
Taskmanager
Jetzt wurde es doch mal Zeit im Taskmanager zu schauen, ob ich etwas finde. Der "LogonType =3" im Eventlog ist ja ein Hinweis auf ein "Network Logon". Im Ressourcen Manager ist sind dann schon ein deutlicher Hinweis zu sehen, auch ohne mit Wireshark die Pakete mitschneiden zu müssen.. Der Terminal Server Dienst hat doch sehr viele Verbindungen von unterschiedlichen offen. Nur eine davon ist meine eigene Verbindung.
Ich habe dann dennoch mit Wireshark mal alle Pakete auf 3389 mitgeschnitten und in 15 Minuten haben 76 unterschiedliche Client IP-Adressen insgesamt 207 Verbindungen versucht. Sie sehen auch gut, dass ein Client es mehrfach versucht.
So kann man schon einige Kennwort durchprobieren, wenn denn keine Account Lockout Policy gesetzt wäre. Dass der Angreifer etwas ineffektiv ist, sehen Sie weiter oben im NETLOGON-Log, da er den User "ADMINISTATOR" anscheinend immer wieder und mit hoher Zahl versucht. Sonst würde bei dem Konto ja nicht das Feld "LockoutTime" immer wieder neu geschrieben. Es sind also entweder unterschiedliche Angreifer oder die Bots sind nicht ordentlich synchronisiert.
Source IPs
Ich habe mal ein paar Quell-IP-Adressen analysiert und es sind sowohl dynamische IP-Adressen als auch AmazonAWS-Instanzen darunter
Name: ri.emai1.info Address: 23.21.234.12 Name: ec2-18-197-229-132.eu-central-1.compute.amazonaws.com Address: 18.197.229.132 Name: 23.91.71.59.ipdns.io Address: 23.91.71.59 Name: 5F9A16EC.rev.sefiber.dk Address: 95.154.22.236
Es sollte für Provider eigentlich sehr einfach sein, solche hohen Verbindungsversuche auf bekannten Ports wie 3389 zu erkennen und den Client zu blocken. Aber das würde ja aktive Mitarbeit kosten und mehr Bandbreite ist dann wohl billiger. Würde ein Taxi-Fahrer, der einen Einbrecher zu seinem Ziel bringt so handeln?
Übersicht
Der Angriff hat sich also auf folgende Systeme ausgewirkt. Ich bin sicher, dass sehr viele VMs in Azure per RDP erreichbar sind, weil Azure diese Veröffentlichung quasi alleine einrichtet.
DAs bedeutet aber auch, dass bei einer Kopplung der Systeme in Azure mit dem Firmennetzwerk über einen VPN-Tunnel nun das bisher interne geschlossene Netzwerk plötzlich zumindest über einen Dienst erreichbar ist.
Abhilfe
In meinem Fall ist das Problem nur daher zu einem Problem geworden, weil der PRTG-Host nicht in meinem eigenen lokalen Netzwerk stand, welches durch Firewall adäquat abgesichert ist. Diese VM läuft in Azure und hier richtet Microsoft per Default natürlich eine Erreichbarkeit über RDP ein. die VM bekommt einen öffentlichen DNS-Namen in der Form "<computername>.cloudapp.net" und ist über 3389 erreichbar. Damit haben wir drei Optionen, diese Zugriff zu erschweren oder zu verhindern
- Anderer Port
Sie können einfach einen anderen Port nutzen, z.B. 13389 statt 3389 und darauf hoffen, dass ein Angreifer nicht erst durch einen Portscan auf diesen Port aufmerksam wird. Sicher ist das nicht aber erschwert schon vieles - RDP-Veröffentlichung schließen oder
einengen
Wenn Sie nicht permanent per RDP auf den Server zugreifen müssen, dann können Sie im Admin-Portal diese Freischaltung über Netzwerk-ACLs einfach einfach reglementieren. Hier habe ich den Zugang auf die statischen öffentlichen IP-Adressen von Net at Work beschränkt. Jede Änderung hier benötigt natürlich etwas Zeit, bis diese umgesetzt ist. Sie können aber auch den Server über ein IPSEC-VPN von intern mit einer privaten IP-Adresse erreichen. - IPSec-Tunnel
Eine dritte Option ist die Erreichbarkeit des Ports über IPSEC zu sichern. Hier können Sie dann mit Client-Zertifikaten arbeiten, d.h. ihr Client muss sich an der Gegenstelle erst authentifizieren, ehe Daten übertragen werden. Allerdings ist das nicht trivial, da IPSEC natürlcih auf IP-Adressen und nicht DNS-Namen geht. Man müsste also schon beständige IP-Adressen in Azure nutzen.
Leider habe ich keinen Weg gefunden, wie ich für die RDP-Verbindung ein Client Zertifikat vorschreiben muss um die Username/Kennwort-Optoin abzuschalten
Ich habe einfach eine Access-Liste gesetzt. Bei einer "ClassicVM ist das unter den Endpoints:
Bei einer neuen VM ist es unter Netzwerk. Microsoft markiert diesen Zugang sogar deutlich mit einem gelben Warnhinweis
Diese Einstellung können Sie natürlich auch per PowerShell vornehmen, so dass die Öffnung/Sperrung sogar teilweise automatisierbar ist.
Hinweis: Die Richtlinien wirken sich nur auf neue Verbindungen auf. Eine bestehende Verbindung wird nicht unterbrochen.
- Manage endpoint access control lists
using PowerShell in the classic deployment
model
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-acl-powershell - Set up endpoints on a Windows virtual
machine by using the classic deployment
model
https://docs.microsoft.com/de-de/previous-versions/azure/virtual-machines/windows/classic/setup-endpoints
Just in Time VM Access
Die Problematik mit offenen RDP und SSH-Zugängen ist Microsoft natürlich nicht unbekannt. Seit März 2018 gibt es daher auch eine neue Funktion, um diese Zugänge besonders zu sichern. Schade allerdings, dass diese Funktion einen Aufpreis kostet.
This feature is available in the
standard pricing tier of Security Center, and you can try
Security Center for free for the first 60 days.
Quelle:
https://azure.microsoft.com/de-de/blog/just-in-time-vm-access-is-generally-available/
Wer ohne diese Funktion auskommen muss, wird daher weiter einfach mit Firewall-Regeln arbeiten.
-
https://azure.microsoft.com/en-us/pricing/details/security-center/
https://azure.microsoft.com/en-us/free/ - Just-in-Time VM Access is generally
available
https://azure.microsoft.com/de-de/blog/just-in-time-vm-access-is-generally-available/ - Manage virtual machine access using
just-in-time
https://docs.microsoft.com/en-us/azure/security-center/security-center-just-in-time - Announcing the Just-In-Time VM Access
public preview
https://azure.microsoft.com/en-us/blog/announcing-the-just-in-time-vm-access-public-preview/
Unter dem Security Center zeigt Microsoft auch als Werbung an, was so alles erfasst werden würde.
Zusammenfassung
Die Erweiterung ihres eigenen Netzwerk um VMs und Dienste in Azure bedeutet auch, dass neben ihrer eigenen Firewall nun auch die Accesslisten in Azure zu betrachten sind. Wenn Sie einfach nur eine VM bereitstellen, dann bekommen Sie nicht nur einen RDP-Zugang zu dieser VM über einen öffentlichen Namen sondern zugleich einen Hintereingang, über den Angreifer auch ihre Active Directory Konten sperren können. Die Verwaltung der Azure-VMs erfolgt aber meist nicht durch die Personen, die ihre Firewall verwalten. Das sind also neue Herausforderungen an die Organisation.
Ich bin sicher, dass diese RDP-Versuche sich nicht gezielt auf meine VM gerichtet haben. Insofern sollte nun jeder, der VMs in Azur betreibt, den Zugang per RDP vielleicht etwas enger fassen oder nur bei Bedarf über das Portal freigeben. Dies ist zumindest bei produktiven Systemen geboten. Bei reinen Testumgebungen könnte man es noch durchgehen lassen. Aber achten Sie auch hier darauf, das ihre Kennworte ausreichend sicher sind.
Weitere Links
- TrackLoginEvents
- Auditing
- DoS mit Account Lockout
- Account Lockout mit Docker
- Dreimal 401 mit Negotiate
- HTTP Authentication
- 4776(S, F): The computer attempted to
validate the credentials for an account.
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4776 - 4740(S): A user account was locked out.
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4740 - Account lockout
http://www.windowstricks.in/2009/07/account-lockout.html - Account lockout caller computer name
blank, CISCO, workstation and domain
controller
http://www.windowstricks.in/2016/06/account-lockout-caller-computer-name-blank-cisco-workstation-domain-controller.html - Azure AD and ADFS best practices:
Defending against password spray attacks
https://www.microsoft.com/en-us/microsoft-365/blog/2018/03/05/azure-ad-and-adfs-best-practices-defending-against-password-spray-attacks/ - Securing Remote Access to Azure Virtual
Machines over the Internet
https://blogs.msdn.microsoft.com/azuresecurity/2015/09/08/securing-remote-access-to-azure-virtual-machines-over-the-internet/ - Appendix A: Security monitoring
recommendations for many audit events
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/appendix-a-security-monitoring-recommendations-for-many-audit-events - Windows event log data sources in Log
Analytics
https://docs.microsoft.com/en-us/azure/azure-monitor/platform/data-sources-windows-events - Azure network security overview
https://docs.microsoft.com/en-us/azure/security/security-network-overview - Remote Desktop Connection (RDP) –
Certificate Warnings
https://blogs.technet.microsoft.com/askpfeplat/2017/12/18/remote-desktop-connection-rdp-certificate-warnings/ - Are My RDP Connections Really Secured by
a Certificate?
https://blogs.technet.microsoft.com/askpfeplat/2018/05/28/are-my-rdp-connections-really-secured-by-a-certificate/ - Tip: Secure RDS (Remote Desktop
Services) Connections with SSL
https://docs.microsoft.com/en-us/previous-versions/technet-magazine/ff458357(v=msdn.10) - IPBan - Windows Server überwacht
fehlerhafte Logins und sperrt SourceIP in
Windows Firewall
https://www.digitalruby.com/ipban/
https://www.digitalruby.com/download/ipban-software-download/
https://GitHub.com/DigitalRuby/IPBan