ROFI_1969 0 Geschrieben 7. April 2022 Melden Geschrieben 7. April 2022 (bearbeitet) Sehr geehrte Kollegen, ich habe da mal eine Frage, die ich zwar schon zig-fach im Internet gelesen habe, aber bislang habe ich noch keine befriedigende Antwort gefunden, die mir auch wirklich erklärt, warum das so ist: Es geht um das Ereignis im Windows Event Log, wenn jemand versucht, sich mit falschem Login und Passwort anzumelden. Protokolliert wird dies mit der EventID 4625. Die Failure Reason ist mit 2313 protokolliert (Unknown user name or bad password). Im TargetUserName wird auch der böse Benutzer protokolliert (in meinem Fall ROGERS). Die ProcessId, welche hierfür verantwortlich war, hat aktuell die Id 616. Dies ist bei mir die LSASS.EXE (Local Security Authority Subsystem Service). Nun meine Frage: In sehr vielen Fällen wird die IP-Adresse des Angreifers unter z. Bsp. <Data Name="IpAddress">44.33.22.11</Data> protokolliert. Dies hilft, eine Firewall Regel einzurichten, um den Banausen zu blocken. In sehr vielen Fällen aber, wie auch im unten beschriebenen Fall, wird leider nur ein Minus-Zeichen protokolliert. Weshalb ist das so? Warum wird manchmal die IP-Adresse des Angreifers protokolliert und warum manchmal nicht? <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="2022-04-07T07:28:46.747178700Z" /> <EventRecordID>122520213</EventRecordID> <Correlation /> <Execution ProcessID="616" ThreadID="9276" /> <!-- lsass.exe --> <Channel>Security</Channel> <Computer>subdomain.mydomain.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">ROGERS</Data> <Data Name="TargetDomainName" /> <Data Name="Status">0xc000006d</Data> <Data Name="FailureReason">%%2313</Data> <Data Name="SubStatus">0xc0000064</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> <!-- Warum fehlt hier die IP-Adresse? --> <Data Name="IpPort">-</Data> </EventData> </Event> bearbeitet 7. April 2022 von ROFI_1969
NorbertFe 2.283 Geschrieben 7. April 2022 Melden Geschrieben 7. April 2022 vor 32 Minuten schrieb ROFI_1969: Nun meine Frage: In sehr vielen Fällen wird die IP-Adresse des Angreifers unter z. Bsp. <Data Name="IpAddress">44.33.22.11</Data> protokolliert. Dies hilft, eine Firewall Regel einzurichten, um den Banausen zu blocken. Wenn man von extern so bis zu deinem Server kommt, dann hilft das "Banausen blocken" auch nicht mehr. ;) Ich würd mir eher den Kopf machen, warum du solche Einträge überhaupt im Log hast.
daabm 1.431 Geschrieben 7. April 2022 Melden Geschrieben 7. April 2022 Aktivier mal das Netlogon Debug Logging (Nltest /DBFlag:2080FFFF - Neustart von irgendwas nicht erforderlich), dann findest die Quelle normalerweise in %Windir%\Debug\Netlogon.Log. Ursache sind transitive Logons, wir haben das z.B. bei VPN-Einwahlen oder Proxy-Authentifizierungen. Die RAS-Server stehen in einer trusted Domain, in der eigentlichen User-Domäne fehlt dann die Client-IP.
Empfohlene Beiträge
Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren
Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können
Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!
Neues Benutzerkonto erstellenAnmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden