6
SBS 2008 - Merkwürdige Einträge (ID-4625) im Security Log
Hallo Zusammen,
heute morgen wurde auf einem SBS2008 ein paar Loginversuche mit der ID:4625 geloggt.
Das Merkwürdige bei diesen Loginversuchen ist der Arbeitsstationsname und die Quell - IP-Adresse.
Als Arbeitsstationsname wird ein Client aus der eigenen Domäne angegeben. (lokaler Netbiosname), und als IP-Adresse ist die statische WAN-IP des Anschlusses, hinter dem der SBS2008 mit seinen Clients läuft.
Dass es ein Dienst ist, glaube ich eher nicht, weil:
- die statische WAN-IP des Anschlusses, wo der SBS2008 hinter steht, als Quelle angegeben ist.
- die verwendeten Benutzernamen, deren Anmeldung fehlgeschlagen, in dem Netzwerk nicht existieren. (Administrator und Firmenname).
Kann es sein, dass sich jemand von außen versucht einzuloggen, und dabei den Hostnamen + WAN-IP faked?? Das wäre ja der Hammer!
Irgend welche Ideen?
heute morgen wurde auf einem SBS2008 ein paar Loginversuche mit der ID:4625 geloggt.
Das Merkwürdige bei diesen Loginversuchen ist der Arbeitsstationsname und die Quell - IP-Adresse.
Als Arbeitsstationsname wird ein Client aus der eigenen Domäne angegeben. (lokaler Netbiosname), und als IP-Adresse ist die statische WAN-IP des Anschlusses, hinter dem der SBS2008 mit seinen Clients läuft.
Dass es ein Dienst ist, glaube ich eher nicht, weil:
- die statische WAN-IP des Anschlusses, wo der SBS2008 hinter steht, als Quelle angegeben ist.
- die verwendeten Benutzernamen, deren Anmeldung fehlgeschlagen, in dem Netzwerk nicht existieren. (Administrator und Firmenname).
Kann es sein, dass sich jemand von außen versucht einzuloggen, und dabei den Hostnamen + WAN-IP faked?? Das wäre ja der Hammer!
Irgend welche Ideen?
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: 158275
Url: https://administrator.de/forum/sbs-2008-merkwuerdige-eintraege-id-4625-im-security-log-158275.html
Ausgedruckt am: 23.12.2024 um 07:12 Uhr
6 Kommentare
Neuester Kommentar
Dein Interner Client kann das nicht sein den wenn du über eine Firewall von deinem Internen netz ins internet gehst darf das selbe packet nicht wieder über die Firewall rein. Ausser dein server steht hinter einer anderen firewall als deine clients.
Komischer fehler würde mal die Maschine die sich da laut clientname einloggen wollte untersuchen. Virus ?
LG Andreas Ausserwöger
Komischer fehler würde mal die Maschine die sich da laut clientname einloggen wollte untersuchen. Virus ?
LG Andreas Ausserwöger
Danke für die Antwort.
Der Client ist ein Windows 7 64Bit. Die Installation ist gerade mal 2 Wochen alt. Virenschutz ist ebenfalls von Anfang an vorhanden. (Gdata). Windowsupdates sind auch alle drauf. UAC ist an.
Ich werde ihn trotzdem mal durchchecken.
Gibt es sonst noch irgendwelche Möglichkeiten?
Gruß,
Sascha
Der Client ist ein Windows 7 64Bit. Die Installation ist gerade mal 2 Wochen alt. Virenschutz ist ebenfalls von Anfang an vorhanden. (Gdata). Windowsupdates sind auch alle drauf. UAC ist an.
Ich werde ihn trotzdem mal durchchecken.
Gibt es sonst noch irgendwelche Möglichkeiten?
Gruß,
Sascha
Wenn deine Clients hinter der selben Firewall stehen kanns nur ein externer sein. Vielleicht ein Laptop der zur firma gehört und von extern zugreifen will ?
kann ich nur schätzen ! Was war das den für ein loginversuch ? Normales anmelden an der domain ?
Schau mal ob du am client im Eventlog was findest !
LG Andreas Ausserwöger
kann ich nur schätzen ! Was war das den für ein loginversuch ? Normales anmelden an der domain ?
Schau mal ob du am client im Eventlog was findest !
LG Andreas Ausserwöger
Hier ein Ausschnitt aus dem Eventlog Sicherheit:
Antragsteller:
Sicherheits-ID: NULL SID
Kontoname: -
Kontodomäne: -
Anmelde-ID: 0x0
Anmeldetyp: 3
Konto, für das die Anmeldung fehlgeschlagen ist:
Sicherheits-ID: NULL SID
Kontoname: firmenname (manchmal auch "Administrator", den ist in der Domäne nicht gibt)
Kontodomäne: korrektedomäne.local
Fehlerinformationen:
Fehlerursache: Unbekannter Benutzername oder ungültiges Kennwort.
Status: 0xc000006d
Unterstatus:: 0xc0000064
Prozessinformationen:
Aufrufprozess-ID: 0x0
Aufrufprozessname: -
Netzwerkinformationen:
Arbeitsstationsname: bekannter-client (es wird der richtige NB-Name angegeben)
Quellnetzwerkadresse: xxx.xxx.xxx (WAN-IP dieses Anschlusses)
Quellport: 57873
Detaillierte Authentifizierungsinformationen:
Anmeldeprozess: NtLmSsp
Authentifizierungspaket: NTLM
Übertragene Dienste: -
Paketname (nur NTLM): -
Schlüssellänge: 0
Sehr interessant:
Beim Client wird um die gleiche Uhrzeit ein (!) erfolgreicher (!) Login von Outlook mit diesem besagten "Firmenamen" als Anmeldename protokolliert. ??
Anmeldeversuch mit expliziten Anmeldeinformationen.
Antragsteller:
Sicherheits-ID: Domäne\Anmeldename (existiert)
Kontoname: Anmeldename
Kontodomäne: DOMAENE
Anmelde-ID: 0x4b857
Anmelde-GUID: {00000000-0000-0000-0000-000000000000} <- die habe ich nicht genullt. Werden wirklich so ausgegeben!
Konto, dessen Anmeldeinformationen verwendet wurden:
Kontoname: firmenname
Kontodomäne: DOMAENE
Anmelde-GUID: {00000000-0000-0000-0000-000000000000}
Zielserver:
Zielservername: SERVER.domaene.local
Weitere Informationen: SERVER.domaene.local
Prozessinformationen:
Prozess-ID: 0x1220
Prozessname: C:\Program Files\Microsoft Office\Office14\OUTLOOK.EXE
Netzwerkinformationen:
Netzwerkadresse: -
Port: -
Outlook ist dort mit Exchange verbunden. Frage mich, wo 1. der komische Benutzername her kommt und 2. wieso die statische WAN-IP als Quelle vom Server gemeldet wird.
Da stimmt doch was nicht....!?
Gruß,
Sascha
Update: Ok, ich habe herausgefunden, dass bei dem Exchange-Konto die Einstellung zum Verbindungsaufbau über "http-proxy mit ssl" angeklickt war, wobei die externe FQDN angegeben wurde.
Ist in einem lokalen LAN ja nicht notwendig, also habe ich das mal deaktiviert.
Seltsam ist allerdings immernoch der Benutzername, mit dem sich versucht wurde anzumelden. (Administrator / Firmenname).
Antragsteller:
Sicherheits-ID: NULL SID
Kontoname: -
Kontodomäne: -
Anmelde-ID: 0x0
Anmeldetyp: 3
Konto, für das die Anmeldung fehlgeschlagen ist:
Sicherheits-ID: NULL SID
Kontoname: firmenname (manchmal auch "Administrator", den ist in der Domäne nicht gibt)
Kontodomäne: korrektedomäne.local
Fehlerinformationen:
Fehlerursache: Unbekannter Benutzername oder ungültiges Kennwort.
Status: 0xc000006d
Unterstatus:: 0xc0000064
Prozessinformationen:
Aufrufprozess-ID: 0x0
Aufrufprozessname: -
Netzwerkinformationen:
Arbeitsstationsname: bekannter-client (es wird der richtige NB-Name angegeben)
Quellnetzwerkadresse: xxx.xxx.xxx (WAN-IP dieses Anschlusses)
Quellport: 57873
Detaillierte Authentifizierungsinformationen:
Anmeldeprozess: NtLmSsp
Authentifizierungspaket: NTLM
Übertragene Dienste: -
Paketname (nur NTLM): -
Schlüssellänge: 0
Sehr interessant:
Beim Client wird um die gleiche Uhrzeit ein (!) erfolgreicher (!) Login von Outlook mit diesem besagten "Firmenamen" als Anmeldename protokolliert. ??
Anmeldeversuch mit expliziten Anmeldeinformationen.
Antragsteller:
Sicherheits-ID: Domäne\Anmeldename (existiert)
Kontoname: Anmeldename
Kontodomäne: DOMAENE
Anmelde-ID: 0x4b857
Anmelde-GUID: {00000000-0000-0000-0000-000000000000} <- die habe ich nicht genullt. Werden wirklich so ausgegeben!
Konto, dessen Anmeldeinformationen verwendet wurden:
Kontoname: firmenname
Kontodomäne: DOMAENE
Anmelde-GUID: {00000000-0000-0000-0000-000000000000}
Zielserver:
Zielservername: SERVER.domaene.local
Weitere Informationen: SERVER.domaene.local
Prozessinformationen:
Prozess-ID: 0x1220
Prozessname: C:\Program Files\Microsoft Office\Office14\OUTLOOK.EXE
Netzwerkinformationen:
Netzwerkadresse: -
Port: -
Outlook ist dort mit Exchange verbunden. Frage mich, wo 1. der komische Benutzername her kommt und 2. wieso die statische WAN-IP als Quelle vom Server gemeldet wird.
Da stimmt doch was nicht....!?
Gruß,
Sascha
Update: Ok, ich habe herausgefunden, dass bei dem Exchange-Konto die Einstellung zum Verbindungsaufbau über "http-proxy mit ssl" angeklickt war, wobei die externe FQDN angegeben wurde.
Ist in einem lokalen LAN ja nicht notwendig, also habe ich das mal deaktiviert.
Seltsam ist allerdings immernoch der Benutzername, mit dem sich versucht wurde anzumelden. (Administrator / Firmenname).
Na dann weisst du schon wo du suchen musst ! Hast du Outlook 2007 oder 2010 ?
Schau mal am Outlookkonto des clients unter weitere Einstellungen dann auf verbindungen ob da Verbindung mit Exchangeserver über HTTP eingeschaltet ist. Und Teste ob der fehler noch besteht wenn du das abschaltest.
LG Andreas Ausserwöger
Schau mal am Outlookkonto des clients unter weitere Einstellungen dann auf verbindungen ob da Verbindung mit Exchangeserver über HTTP eingeschaltet ist. Und Teste ob der fehler noch besteht wenn du das abschaltest.
LG Andreas Ausserwöger
Sorry Leute, aber diesen Thread habe ich total vergessen! Asche über mein Haupt!
Die Lösung war im Endeffekt eine Neuinstallations des Notebooks. Das Teil war vom Anwender her mit Scareware, Shareware, etc. total zugemüllt.
Nach der Neuinstallation hat er erst mal die lokalen Adminrechte entzogen bekommen, und die Richtlinien verschärft. Seitdem ist Ruhe im Karton.
Die Lösung war im Endeffekt eine Neuinstallations des Notebooks. Das Teil war vom Anwender her mit Scareware, Shareware, etc. total zugemüllt.
Nach der Neuinstallation hat er erst mal die lokalen Adminrechte entzogen bekommen, und die Richtlinien verschärft. Seitdem ist Ruhe im Karton.
