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.

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.

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