11
Prozessbestimmung einer fehlgeschlagenen Kerberosauthentifizierung
Guten Nachmittag liebe Gemeinde
Also ich investigiere Anmeldefehlschläge eines Adminkontos.
Hintergrund DC meldet Fehler mit Konto: Admin1 in der Form einer fehlerhaften Vorauthentifizierung von Kerkeros.
Quelle: krbtgt/domäne
Benutzernutzername: Admin1
Die Quelle der Anfrage habe ich über die Logs auf dem DC ausfindig machen können.
Dann jump ich nun dort hin und schau mir die Logs an.
Aus irgendwelchem Grund, logt sich der Admin1 jede Stunde seit jedem Tag 1x bis X-Mal [X = ca. 10 Mal im Schnitt] am DC an, und versuchte so die registierten Anmeldefehler, die ich oben am Anfang angab.
Nun bin ich auf eine heiße Spur gestoßen, und hoffe darüber den Service oder einen Scheduled Task zu finden, der die ganze Zeit versucht den Admin1 zu missbrauchen^^?
- <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>4672</EventID>
<Version>0</Version>
<Level>0</Level>
<Task>12548</Task>
<Opcode>0</Opcode>
<Keywords>0x8020000000000000</Keywords>
<TimeCreated SystemTime="2021-05-19T13:05:37.119940100Z" />
<EventRecordID>5123157</EventRecordID>
<Correlation ActivityID="{4209002E-4C84-0000-3700-0942844CD701}" />
<Execution ProcessID="712" ThreadID="1816" />
<Channel>Security</Channel>
<Computer>censored</Computer>
<Security />
</System>
- <EventData>
<Data Name="SubjectUserSid">S-1-5-21-3941519396-2606466931-4110164396-1184</Data>
<Data Name="SubjectUserName">Admin1</Data>
<Data Name="SubjectDomainName">censored</Data>
<Data Name="SubjectLogonId">0x276c100</Data>
<Data Name="PrivilegeList">SeSecurityPrivilege SeBackupPrivilege SeRestorePrivilege SeTakeOwnershipPrivilege SeDebugPrivilege SeSystemEnvironmentPrivilege SeLoadDriverPrivilege SeImpersonatePrivilege SeDelegateSessionUserImpersonatePrivilege</Data>
</EventData>
</Event>
Wie finde ich über <Task>12548</Task> / <Execution ProcessID="712" ThreadID="1816" /> nun weitere heiße Informationen?
Viele Grüße, Blaub33r3
Also ich investigiere Anmeldefehlschläge eines Adminkontos.
Hintergrund DC meldet Fehler mit Konto: Admin1 in der Form einer fehlerhaften Vorauthentifizierung von Kerkeros.
Quelle: krbtgt/domäne
Benutzernutzername: Admin1
Die Quelle der Anfrage habe ich über die Logs auf dem DC ausfindig machen können.
Dann jump ich nun dort hin und schau mir die Logs an.
Aus irgendwelchem Grund, logt sich der Admin1 jede Stunde seit jedem Tag 1x bis X-Mal [X = ca. 10 Mal im Schnitt] am DC an, und versuchte so die registierten Anmeldefehler, die ich oben am Anfang angab.
Nun bin ich auf eine heiße Spur gestoßen, und hoffe darüber den Service oder einen Scheduled Task zu finden, der die ganze Zeit versucht den Admin1 zu missbrauchen^^?
- <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>4672</EventID>
<Version>0</Version>
<Level>0</Level>
<Task>12548</Task>
<Opcode>0</Opcode>
<Keywords>0x8020000000000000</Keywords>
<TimeCreated SystemTime="2021-05-19T13:05:37.119940100Z" />
<EventRecordID>5123157</EventRecordID>
<Correlation ActivityID="{4209002E-4C84-0000-3700-0942844CD701}" />
<Execution ProcessID="712" ThreadID="1816" />
<Channel>Security</Channel>
<Computer>censored</Computer>
<Security />
</System>
- <EventData>
<Data Name="SubjectUserSid">S-1-5-21-3941519396-2606466931-4110164396-1184</Data>
<Data Name="SubjectUserName">Admin1</Data>
<Data Name="SubjectDomainName">censored</Data>
<Data Name="SubjectLogonId">0x276c100</Data>
<Data Name="PrivilegeList">SeSecurityPrivilege SeBackupPrivilege SeRestorePrivilege SeTakeOwnershipPrivilege SeDebugPrivilege SeSystemEnvironmentPrivilege SeLoadDriverPrivilege SeImpersonatePrivilege SeDelegateSessionUserImpersonatePrivilege</Data>
</EventData>
</Event>
Wie finde ich über <Task>12548</Task> / <Execution ProcessID="712" ThreadID="1816" /> nun weitere heiße Informationen?
Viele Grüße, Blaub33r3
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 666891
Url: https://administrator.de/contentid/666891
Ausgedruckt am: 22.11.2024 um 18:11 Uhr
11 Kommentare
Neuester Kommentar
Wie finde ich über <Task>12548</Task> / <Execution ProcessID="712" ThreadID="1816" /> nun weitere heiße Informationen?
Siehe dazu:Account Lockout and Management Tools
https://webware2.wordpress.com/2010/06/15/how-to-use-account-lockout-and ...
Fehlerhafte Anmeldeversuche protokollieren
Ansonsten auch nen Tasktrigger auf das Event und lass da ein Powershell Skript laufen das dir den Prozess zur ID ausgeben lässt.
Gruß w.
Schade leider darf ich das Tool wohl nicht nutzen...
Account Lockout and Management Tools dürfen nicht auf Servern angewendet werden
: Do not use this tool on servers that host network applications or services.
Und der Server macht irgendwas mit im Zusammenhang mit "ManagedEngineDesktopCentral"
Das wäre echt hilfreich gewesen. Dann schau ich mal wie das mitm Tasktrigger funktioniert.
Was ist denn der Unterschied von einem Task und einem Prozess?
Wer hätte gedacht, dass es so anspruchsvoll ist, diesen Task ausfindig zu machen :D CooL!
Greetings, B33r3
Account Lockout and Management Tools dürfen nicht auf Servern angewendet werden
: Do not use this tool on servers that host network applications or services.
Und der Server macht irgendwas mit im Zusammenhang mit "ManagedEngineDesktopCentral"
Das wäre echt hilfreich gewesen. Dann schau ich mal wie das mitm Tasktrigger funktioniert.
Was ist denn der Unterschied von einem Task und einem Prozess?
Wer hätte gedacht, dass es so anspruchsvoll ist, diesen Task ausfindig zu machen :D CooL!
Greetings, B33r3
Was ist denn der Unterschied von einem Task und einem Prozess
Really??Task = Scheduled Task
Prozess = Ausführender Assembly
Moin,
zum Verständnis:
muss es das PS Skript aktuell getriggert zur EventID 4672 werden damit man den aktuellen Prozessnamen zur ProcessID bekommt?
zur Umsetzung: Wie kann ich mir den Prozess zur ID ausgeben lassen?
Grüße B33r3
zum Verständnis:
muss es das PS Skript aktuell getriggert zur EventID 4672 werden damit man den aktuellen Prozessnamen zur ProcessID bekommt?
zur Umsetzung: Wie kann ich mir den Prozess zur ID ausgeben lassen?
Grüße B33r3
Zitat von @blaub33r3:
Moin,
zum Verständnis:
muss es das PS Skript aktuell getriggert zur EventID 4672 werden damit man den aktuellen Prozessnamen zur ProcessID bekommt?
Ja.Moin,
zum Verständnis:
muss es das PS Skript aktuell getriggert zur EventID 4672 werden damit man den aktuellen Prozessnamen zur ProcessID bekommt?
zur Umsetzung: Wie kann ich mir den Prozess zur ID ausgeben lassen?
Also wenn's daran schon scheitert ...gps -id 12345 | select ProcessName,Path
Danke, danke für die Starthilfe 
!!
Warum empfiehlst du mir das mit dem aufkommen des Events zu Triggern, ich könnte doch auch rückwirkend einfach nachschauen?
Verändert sich die ID einfach so schnell mal, dass ich nicht an den entsprechend Prozess mehr ran komme?
Grüße
!!Warum empfiehlst du mir das mit dem aufkommen des Events zu Triggern, ich könnte doch auch rückwirkend einfach nachschauen?
Verändert sich die ID einfach so schnell mal, dass ich nicht an den entsprechend Prozess mehr ran komme?
Grüße
Zitat von @blaub33r3:
Warum empfiehlst du mir das mit dem aufkommen des Events zu Triggern, ich könnte doch auch rückwirkend einfach nachschauen?
Wenn der Prozess aber zwischenzeitlich schon wieder beendet ist nützt das nichts ...Warum empfiehlst du mir das mit dem aufkommen des Events zu Triggern, ich könnte doch auch rückwirkend einfach nachschauen?
Verändert sich die ID einfach so schnell mal, dass ich nicht an den entsprechend Prozess mehr ran komme?
Wenn er sich denn schon beendet hat, ja.Schau dir doch mal das Skript im dritten Link oben an, vermutlich reicht das schon.
Nochmal von vorne, Und btw ich habe wenig bis garkeine Erfahrung auf dem Gebiet. Das ist alles neu für mich.
Was ich weiß:
Auf DC1 / DC2 werden Events vom Typ 4771(F): Fehler bei der Kerberos-Vorauthentifizierung für ein Admin-Konto "Admin" festgestellt.
Die SourceIP habe ich bestimmt. Ein weiterer Server, dessen Funktion mir unbekannt ist nennen wir "Server".
Der Client von Admin sei "Client".
Anhand der LogProtokolle sehe ich dass sich fast minütlich das Computerkonto vom Admin" und das Benutzerkonto "Admin" selbst am "Server1" ..... Was auch immer jetzt passiert in dieser "BLACKBOX" versucht über die KerberosVorauthentifizierung sich am DC zu athentifizieren.
Über die ProzessID am DC konnte ich nur feststellen, dass es der Prozess für die Anmeldung gewesen ist:
Microsoft Windows Operating System's Local Security Authority Subsystem Service (lsass.exe)
Wie aber finde ich Hinweise welcher Dienst / Prozess nun genau besprochen sein könnten.
Eine alternative Lösung kam mir in den Sinn: Alte Daten aus der Anmeldeinformationsverwaltung löschen....vielleicht behebt sich damit das Problem.
Wie soll ich weiter vorgehen am Besten, damit ich diesen Prozess / Service finde von Server1 finde, der den Admin nutzt aber durch die Authentifizierung am DC scheiert?
Was ich weiß:
Auf DC1 / DC2 werden Events vom Typ 4771(F): Fehler bei der Kerberos-Vorauthentifizierung für ein Admin-Konto "Admin" festgestellt.
Die SourceIP habe ich bestimmt. Ein weiterer Server, dessen Funktion mir unbekannt ist nennen wir "Server".
Der Client von Admin sei "Client".
Anhand der LogProtokolle sehe ich dass sich fast minütlich das Computerkonto vom Admin" und das Benutzerkonto "Admin" selbst am "Server1" ..... Was auch immer jetzt passiert in dieser "BLACKBOX" versucht über die KerberosVorauthentifizierung sich am DC zu athentifizieren.
Über die ProzessID am DC konnte ich nur feststellen, dass es der Prozess für die Anmeldung gewesen ist:
Microsoft Windows Operating System's Local Security Authority Subsystem Service (lsass.exe)
Wie aber finde ich Hinweise welcher Dienst / Prozess nun genau besprochen sein könnten.
Eine alternative Lösung kam mir in den Sinn: Alte Daten aus der Anmeldeinformationsverwaltung löschen....vielleicht behebt sich damit das Problem.
Wie soll ich weiter vorgehen am Besten, damit ich diesen Prozess / Service finde von Server1 finde, der den Admin nutzt aber durch die Authentifizierung am DC scheiert?
Schon klar, habe ich schon verstanden. Deswegen habe ich dich auf das Skript oben verwiesen, dazu sagst du leider nichts....
Außerdem
Außerdem
Account Lockout and Management Tools dürfen nicht auf Servern angewendet werden
Sind ja auch für die Verwendung am Client gedacht ... Wie willst du sonst den Prozess ausfindig machen? Am Server wird niemals die Anwendung die am Client dafür verwantwortlich ist auftauchen ... die kennt nur der Client und dafür ist das primär gemacht. Wenn du sie nicht nutzen kannst dann frag deinen Ausbilder.
Du bist vielleicht aus Erfahrung und Wissen bereits drei Schritte weiter als ich.
Und ich muss nochmal nachbohren, um das Prinzip zu verstehen, von dem du hier ausgehts, dass es alles vom Client ausgeht. Davon bin ich bis gerade noch garnicht ausgegangen - begründe ich aber gleich nochmal^^...Damit ich verstehe was ich nun wo machen soll erstmal:
Hier mal kurz nochmal ne Kette der Abhängigkeiten
DC <---> DeploymentServer <---> Client des Admins
1. DC meldet fehlerhafte Anmeldungen vom AdminKonto. (Quelle des Authentifizierungsversuchs war laut Protokoll der DeploymentServer)
2. Die fehlerhaften Anmeldeversuchen des Admins Konto kamen vom DeploymentServer und nicht vom Client des Admin direkt.
3. In den Logs vom DeploymentServer konnte sich der Client erfolgreich anmelden.
Soll ich jetzt das Skript auf dem Deploymentserver laufen lassen oder auf dem Client des Admin "Account Lockout" ausführen?
Dachte der Fehler kommt alleinig vom Deploymentserver und der Client hat da keine Aktien mehr drin gehabt.
Grüße
Und ich muss nochmal nachbohren, um das Prinzip zu verstehen, von dem du hier ausgehts, dass es alles vom Client ausgeht. Davon bin ich bis gerade noch garnicht ausgegangen - begründe ich aber gleich nochmal^^...Damit ich verstehe was ich nun wo machen soll erstmal:
Hier mal kurz nochmal ne Kette der Abhängigkeiten
DC <---> DeploymentServer <---> Client des Admins
1. DC meldet fehlerhafte Anmeldungen vom AdminKonto. (Quelle des Authentifizierungsversuchs war laut Protokoll der DeploymentServer)
2. Die fehlerhaften Anmeldeversuchen des Admins Konto kamen vom DeploymentServer und nicht vom Client des Admin direkt.
3. In den Logs vom DeploymentServer konnte sich der Client erfolgreich anmelden.
Soll ich jetzt das Skript auf dem Deploymentserver laufen lassen oder auf dem Client des Admin "Account Lockout" ausführen?
Dachte der Fehler kommt alleinig vom Deploymentserver und der Client hat da keine Aktien mehr drin gehabt.
Grüße
Hallo liebe Leut!
https://www.computerweekly.com/de/ratgeber/So-lassen-sich-Kerberos-Schwa ...
Zitat vom Link:
krbtgt ist normalerweise deaktiviert. Das bedeutet das einmal erstellte Standardpasswort wird nur selten geändert.
Frage hierzu: Das Passwort wurde ursprünglich für diesen User von wem erstellt? Von Microsofts Kerberos Dienst selbst?
Wenn das Passwort also in die falschen Hände gerät, kann ein Angreifer sich also selbst die ganze Zeit selbst authentifizieren....
Das Problem wurde laut der o.a. Quelle von MS utner https://www.microsoft.com/en-us/download/details.aspx?id=36036 behandelt,
hierbei handelt es sich um ein Skript dass die Passwörter des Users "krbtgt" abändert automatisch.
Kann man das Skript bedenkenlos anwenden und wie oft sollte man das anwenden? Was ist die MIT-Implementierung?
Fazit:
Es gibt wohl ein Skript dass die Passwörter für den krbtgt User ändert weil es MS aufgrund von Sicherheitslücken empfiehlt regelmäßig durchzuführen.
Zeitgleich werden mögliche Probleme bei der Authentifizierung via Kerberos minimiert. (Es könnte also auch für meine Anmeldeproblematik sich positiv auswirken)
Habt ihr Erfahrung damit? Kann ich es einfach mal auf dem DC anwenden? Interessanterweise hat der DC2 keinen solchen User. Damit kämen wir zu meiner letzten Frage,
in dem Artikel wird beschrieben, dass man Kerberos auf einem "gehärten" Server nur laufen lassen sollte, was bedeutet dies?
Viele Blaub33r3
https://www.computerweekly.com/de/ratgeber/So-lassen-sich-Kerberos-Schwa ...
Zitat vom Link:
krbtgt ist normalerweise deaktiviert. Das bedeutet das einmal erstellte Standardpasswort wird nur selten geändert.
Frage hierzu: Das Passwort wurde ursprünglich für diesen User von wem erstellt? Von Microsofts Kerberos Dienst selbst?
Wenn das Passwort also in die falschen Hände gerät, kann ein Angreifer sich also selbst die ganze Zeit selbst authentifizieren....
Das Problem wurde laut der o.a. Quelle von MS utner https://www.microsoft.com/en-us/download/details.aspx?id=36036 behandelt,
hierbei handelt es sich um ein Skript dass die Passwörter des Users "krbtgt" abändert automatisch.
Kann man das Skript bedenkenlos anwenden und wie oft sollte man das anwenden? Was ist die MIT-Implementierung?
Fazit:
Es gibt wohl ein Skript dass die Passwörter für den krbtgt User ändert weil es MS aufgrund von Sicherheitslücken empfiehlt regelmäßig durchzuführen.
Zeitgleich werden mögliche Probleme bei der Authentifizierung via Kerberos minimiert. (Es könnte also auch für meine Anmeldeproblematik sich positiv auswirken)
Habt ihr Erfahrung damit? Kann ich es einfach mal auf dem DC anwenden? Interessanterweise hat der DC2 keinen solchen User. Damit kämen wir zu meiner letzten Frage,
in dem Artikel wird beschrieben, dass man Kerberos auf einem "gehärten" Server nur laufen lassen sollte, was bedeutet dies?
Viele Blaub33r3
