Clients versuchen DNS per LLMNR Protokoll aufzulösen, komische Fehler im Security-Eventlog (ID 4776)

[mcdaniels 29]

Hallo,

mir ist heute aufgefallen, dass unser DC, der alle FSMO hat im Sicherheits-Eventlog alle Minuten (oder tlw auch kürzere Abstände) eine Event ID 4776 (Überwachung gescheitert) protokolliert, deren Inhalt offenbar der Versuch ist die Anmeldeinformation für ein Konto zu prüfen.

 

Gestartet haben die Einträge am 3. November.

 

Inhalt:

Es wurde versucht, die Anmeldeinformationen für ein Konto zu überprüfen.

Authentifizierungspaket: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0

Anmeldekonto: (ist leer)

Arbeitsstation: \\HOME_DS

Fehlercode: 0x0000064

 

Es gibt bei uns kein: \\HOME_DS (ich nehme mal an, das scheint ein Client zu sein?

 

Ich habe dann Wireshark angeworfen und festgestellt, dass diese HOME_DS Anfragen von einem Plotter kommen und das LLMNR Protokoll betreffen und auch die IP 224.0.0.252 im Spiel ist, die eindeutig etwas mit LLMNR zu tun hat.

 

Also Plotter mal testweise abgedreht....

 

Die Meldungen gingen aber weiter (auch jetzt noch). Per Wireshark kann ich den String \\HOME_DS aber nicht mehr in der Paketinfo finden.

 

Weitere "Wireshark-Forensik" brachte dann zu Tage, dass sich offenbar mehrere Domänen-PC des LLMNR Protokolls bedienen, obwohl sie Domänenclients sind und DNS ordnungsgemäß auflösen könnten. Im Wireshark sieht man auch, dass sie FQDN per LLMNR auflösen wollen, die problemlos via DC-DNS aufgelöst werden könnten.

 

Soweit ich mich richtig informiert habe, ist das LLMNR Protokoll dafür da, um in kleinen Netzwerken den DNS quasi zu ersetzen. Oder, besser formuliert, kann es in Netzen ohne DNS eingesetzt werden.

 

Für mich ist jetzt völlig unklar:

Wie es sein kann, dass die Clients LLMNR sprechen wollen, obwohl sie den DC DNS verwenden können um die angefragten Namen aufzulösen und

vor allem weshalb diese gescheiterten Überwachungen mit der Arbeitsstation \\HOME_DS weitergehen, obwohl der Wireshark nichts mehr sieht.

 

Ich habe auch gelesen dass LLMNR gerne missbraucht wird (LLMNR poisoning) um User quasi auf andere Seiten umzuleiten... Ist jetzt natürlich ein etwas fader Beigeschmack, obwohl ich nicht denke, dass wir kompromittiert worden sind. Zumindest konnte ich bislang nichts finden... Das heißt wiederum noch lange nicht, dass trotzdem etwas im Argen liegt.

 

Was mich aber stutzig macht ist, dass die Einträge am 3.11 gestartet sind. (Ohne Aktion unsererseits)

 

Wenn ich mir die Queries anschaue, dann spricht hier zumindest gegen eine MITM-Attack (LLMNR poisioning) dass die ursprüngliche LLMNR Query dann nicht von einem "anderen" Endpunkt beantwortet wird. Es kommt anscheinend ganz einfach gar keine Antwort. Momentan spielt sich wohl lt. Wireshark  wenig ab. Der DC protokolliert aber nach wie vor oben erwähnte Meldung.

 

Aktuell sieht es so aus (Queries aber kein Response):

 

Kann sich hier jemand vorstellen was hier los sein könnte?

 

Ich könnte / sollte wohl jedenfalls mal LLMNR und NBT-NS abdrehen. Allerdings muss dieses Verhalten ja von "irgendjemandem" oder "irgendetwas" ausgelöst werden....

 

Vielen Dank im Voraus!

bearbeitet Freitag um 20:02 von mcdaniels

[NorbertFe 2.035]

vor 3 Stunden schrieb mcdaniels:

Ich könnte / sollte wohl jedenfalls mal LLMNR

Das ist ja auch sehr empfohlen, dass llmnr per gpo deaktiviert wird. :)

 

netbios sollte afair bei nicht Verwendung von smbv1 sowieso nicht mehr zur Verfügung stehen.

[mcdaniels 29]

vor 7 Stunden schrieb NorbertFe:

Das ist ja auch sehr empfohlen, dass llmnr per gpo deaktiviert wird. :)

 

netbios sollte afair bei nicht Verwendung von smbv1 sowieso nicht mehr zur Verfügung stehen.

Hallo, ja das hab ich auch gelesen... Und werde ich auch umsetzen. Allerdings trotzdem komisch was da läuft. V.a. mit diesem komischen HOME_DS. Mal weiter wiresharken...

 

 

[NorbertFe 2.035]

Per gpo abschalten und dann mal mit wireshark schauen was noch zu finden ist.

[mcdaniels 29]

Ich halte euch auf dem Laufenden... DANKE!

[cj_berlin 1.320]

Bei HOME_DS klingelt beim ganz ganz leise was... aber ich komme nicht drauf, in welchem Log oder Trace ich das schon mal gesehen habe. Ist es möglich, dass auf dem Gerät, das die Abfrage macht, irgendwelche Apps installiert sind, die nix mit Arbeit zu tun haben? Waschmaschinen-Steuerung, Luftqualität, sowas?

 

LLMNR, falls nicht totgetreten, wird versucht, nachdem DNS fehlgeschlagen ist. Bedeutet vermutlich, dass der Versuch, HOME_DS per DNS aufzulösen, nicht in einem autoritativen NXDOMAIN gipfelte, sondern ergebnislos verhallte.

bearbeitet Samstag um 08:44 von cj_berlin

[daabm 1.355]

DS - "Disk Station"? Dann wäre es ein Synology...

Und LLMNR kann man - wenn man eine brauchbare DNS-Infrastruktur hat - problemlos deaktivieren, vermeidet dann auch ganz viel unnötigen Traffic im Netz.

[mcdaniels 29]

Hallo eine Synology ist im Einsatz aber die darf und kann DNS. Ich werde dem am Montag auf den Grund gehen  (hoffe ich)

 

Die unnötigen Protokolle werde ich definitiv abdrehen.

 

Interessant nebenbei: Bei Ping auf 224.0.0.252 meldete sich der Plotter mit der IP 192.168.10.80... Kann mir das jemand erklären?

bearbeitet Sonntag um 10:28 von mcdaniels

[daabm 1.355]

Auf den Synos läuft ja i.d.R. noch jede Menge App-Kram, vielleicht ist was davon dafür verantwortlich. Aber so tief steck ich in den Dingern nicht drin

[mcdaniels 29]

vor 18 Stunden schrieb daabm:

Auf den Synos läuft ja i.d.R. noch jede Menge App-Kram, vielleicht ist was davon dafür verantwortlich. Aber so tief steck ich in den Dingern nicht drin

stimmt schon.

 

Nach wie vor beschäftigt mich aber, weshalb das an einem Sonntag um ca. 07.00h angefangen hat (Da ist niemand in der Firma).

[NorbertFe 2.035]

Solange man nicht genau weiß, welches Gerät da rumblökt, wirds natürlich immer schwer. Was spricht denn wireshark dazu, wer da broadcasts schickt?

[mcdaniels 29]

vor 11 Minuten schrieb NorbertFe:

Solange man nicht genau weiß, welches Gerät da rumblökt, wirds natürlich immer schwer. Was spricht denn wireshark dazu, wer da broadcasts schickt?

 

du meinst wer hier mit der 224.0.0.252 rumballert? Das sind offenbar ein paar Clients, soweit ich am Freitag dann noch gesehen habe und es war auch ein Plotter im Spiel.

 

Was ich halt auch überhaupt nicht mehr verstehe ist, dass der DC hier noch immer im Eventlog dies \\HOME_DS Probleme protokolliert, obwohl ich es im Wireshark nicht finde. Ich werde den  Wireshark mal auf dem DC installieren, vielleicht sehe ich dort ja mit dem ProcessMonitor etwas....

bearbeitet Sonntag um 10:45 von mcdaniels

[NorbertFe 2.035]

Wenn man wireshark nicht auf einem dc installieren will, geht das übrigens auch mit netsh.

https://www.faq-o-matic.net/2018/11/27/netzwerktrace-ohne-zusatztools-erzeugen/

 

das nur als Hinweis.

 

zu Plotter usw. Das sind Funktionen, die man immer als erstes abschalten sollte. Gibt’s ja noch ein paar weitere, die bei Nichtnutzung im Idealfall nur Traffic verursachen und im worstcase Lücken öffnen die man ohne sie nicht hätte.

[mcdaniels 29]

vor 11 Minuten schrieb NorbertFe:

Wenn man wireshark nicht auf einem dc installieren will, geht das übrigens auch mit netsh.

 

Danke für die Info. Ganz wohl ist mir dabei eh nicht... Oha, das stammt ja direkt von dir

 

vor 11 Minuten schrieb NorbertFe:

zu Plotter usw. Das sind Funktionen, die man immer als erstes abschalten sollte. Gibt’s ja noch ein paar weitere, die bei Nichtnutzung im Idealfall nur Traffic verursachen und im worstcase Lücken öffnen die man ohne sie nicht hätte.

 

Absolut korrekt.

bearbeitet Sonntag um 12:09 von mcdaniels

[NorbertFe 2.035]

vor einer Stunde schrieb mcdaniels:

Oha, das stammt ja direkt von dir

Jupp, kommt aus einem Projekt, wo man nix auf dem DC installieren durfte ;)