blaub33r3
Goto Top

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

Content-ID: 666891

Url: https://administrator.de/forum/prozessbestimmung-einer-fehlgeschlagenen-kerberosauthentifizierung-666891.html

Ausgedruckt am: 25.12.2024 um 16:12 Uhr

148121
148121 19.05.2021 aktualisiert um 18:06:05 Uhr
Goto Top
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.
blaub33r3
blaub33r3 20.05.2021 um 09:15:31 Uhr
Goto Top
Schade leider darf ich das Tool wohl nicht nutzen...
Account Lockout and Management Tools dürfen nicht auf Servern angewendet werden face-sad
: 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
148121
148121 20.05.2021 um 09:35:30 Uhr
Goto Top
Was ist denn der Unterschied von einem Task und einem Prozess
Really??
Task = Scheduled Task
Prozess = Ausführender Assembly
blaub33r3
blaub33r3 21.05.2021 um 08:06:45 Uhr
Goto Top
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
148121
148121 21.05.2021 aktualisiert um 10:22:53 Uhr
Goto Top
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.
zur Umsetzung: Wie kann ich mir den Prozess zur ID ausgeben lassen?
Also wenn's daran schon scheitert ...
gps -id 12345 | select ProcessName,Path
blaub33r3
blaub33r3 21.05.2021 um 10:49:20 Uhr
Goto Top
Danke, danke für die Starthilfe face-smile !!

process

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
148121
148121 21.05.2021 aktualisiert um 11:13:22 Uhr
Goto Top
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 ...
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.
blaub33r3
blaub33r3 21.05.2021 um 15:57:45 Uhr
Goto Top
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?
148121
148121 21.05.2021 aktualisiert um 16:15:56 Uhr
Goto Top
Schon klar, habe ich schon verstanden. Deswegen habe ich dich auf das Skript oben verwiesen, dazu sagst du leider nichts....

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.
blaub33r3
blaub33r3 25.05.2021 um 10:01:00 Uhr
Goto Top
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
blaub33r3
blaub33r3 31.05.2021 um 11:27:40 Uhr
Goto Top
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