Ursache für wpad DNS Abfragen ermitteln

Die ursprüngliche Motivation…

Beim Aufsetzen eines Pi-Hole DNS Servers bzw. beim Blick auf dessen Statistiken ist mir aufgefallen, dass Windows den DNS-Server mit hunderten DNS-Anfragen flutet.

Abgefragt wird der Hostname wpad in Verbindung mit dem lokalen DNS-Suffix, als z.B. wpad.fritz.box

Offenbar sucht hier etwas nach einer automatischen Proxy-Konfiguration. Das möchte ich zumindest auf dem Notebook abschalten.

Der erste Schritt war, die üblichen Verdächtigen manuell auf „Keinen Proxy verwenden“ zu konfigurieren.

Das waren bei mir z.B.

• Die Internetoptionen in der Systemsteuerung
• Firefox
• Thunderbird
• Alles, was unten rechts im Tray erscheint oder direkt nach dem Windows-Start Updates anbietet (nVidia GeForce Experience, Owncloud Client, ein Verschlüsselungsprogramm usw. usf.)
• „Herr der Ringe Online“ und dessen Launcher (was ca. 75% des Verwendungszweckes darstellt).

Leider Gottes: Die Abfragen sind nicht gerade weniger geworden. Wir müssen also suchen statt raten 🙂

Protokollierung aller DNS-Abfragen

Unter https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon laden wir uns den Sysmon herunter. Das ZIP-Archiv wird entpackt, das zu unserer Architektur passende Binary wird in einer administrativen Eingabeaufforderung / Powershell mit dem Parameter -i installiert:

Wie die Ausgabe vermuten lässt, wird ein Windows-Service installiert. Dieser macht letztendlich nichts Anderes, als unsere Ereignisanzeige vollzuschreiben.

Das Ergebnis finden wir dort unter Anwendungs- und Dienstprotokolle -> Microsoft -> Windows -> Sysmon -> Operational

Ein erster Blick offenbart, dass wir mit den Daten noch nicht viel anfangen können – die DNS-Abfragen fehlen (…sinnvollerweise, ansonsten würden wirklich zahlreiche Ereignisse protokolliert werden).

Wir müssen dem Sysmon also beipulen, dass er auch die DNS-Abfragen protokollieren soll.

Dafür erstellen wir in unserem vorhin entpackten Verzeichnis eine XML-Datei. In meinem Beispiel heißt die dnsabfragen.xml und hat folgenden Inhalt:

<Sysmon schemaversion="4.21">
 <EventFiltering>
  <DnsQuery onmatch="exclude" />
 </EventFiltering>
</Sysmon>

Wir gehen noch einmal in die administrative Eingabeaufforderung in den entsprechenden Ordner und und übergeben dem Dienst die Konfigurationsdatei mit dem Parameter -c:

Ein erneuter Blick in die Ereignisanzeige beweist, dass der Sysmon jetzt auch Ereignisse vom Typ 22 protokolliert.

Wir setzen einen Filter auf die ID, indem wir mit der rechten Maustaste auf das Protkoll klicken…

…im Kontextmenü „Aktuelles Protokoll filtern…“ auswählen…

…und die ID 22 in das Feld für die Ereignis-ID eingeben.

Nun heißt es „Abwarten und Tee trinken“. Irgendwann(!) wird unser Windows wieder einmal eine entsprechende DNS-Abfrage stellen.

Wir drücken also regelmäßig F5, schauen „immer wieder mal“ alle Ereignisse durch und werden irgendwann über kurz oder lang ein Ereignis finden, bei dem nach dem ominösen wpad-Host gefragt wird.

Hier ist es ja schon! 🙂

Interessant ist hier die „ProcessID“. In diesem Screenshot also der Prozess 2884.

Und der Übeltäter?

„Schuldiger“ im Sinne der Anklage ist laut der Ereignisbeschreibung das Programm svchost.exe

Dieses Programm ist aber letztendlich aber „nur“ eine Art Starter für Windows-Dienste. Mit anderen Worten: svchost.exe wird gestartet, lädt Programmcode aus einer DLL-Datei und etabliert diesen als laufenden Prozess.

Das macht Windows letztendlich mit diversen Diensten, so dass uns diese Angabe nicht weiterhilft. Ein Blick in den Task-Manager offenbart diverse Prozesse mit dieser Bezeichnung…

Unter https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer finden wir den „Process Explorer“. Das ZIP-Archiv wird entpackt und das entsprechende Binary wird mit administrativen Rechten gestartet.

Das bedeutet: Wir klicken das Programmsymbol mit der rechten Maustaste an und wählen im Kontextmenü „Als Administrator ausführen“.

Tun wir das nicht, würden wir „nur“ die Prozesse des jeweiligen Benutzers sehen. Wir suchen aber nach einem Systemprozess, der in einem Kontext läuft, an den wir als Otto-Normaluser (hoffentlich) nicht drankommen.

Die Prozesse sind freundlicherweise schon nach der Prozess-ID sortiert (Spalte PID).

Kleine Anmerkung: Zu meiner Schande muss ich gestehen, dass die Screenshots auf unterschiedlichen Computern angefertigt habe. Wir nehmen einfach mal an, dass wir eben die Prozess-ID 2980 anstatt der 2884 ermittelt haben 🙂

Wir suchen uns also die Zeile mit dem ermittelten Prozess…

…und klicken doppelt auf die entsprechende Zeile:

Voilà – wir haben unseren Verdächtigen ermittelt.

Auf unserem System läuft ein Dienst mit der Bezeichnung WinHttpAutoProxySvc, der letztendlich verantwortlich für die Abfragen ist.

Hier in diesem Artikel geht es ja ausschließlich um die Ermittlung des verursachenden Prozesses. Auf die Funktion und den Sinn und Zweck werde ich hier jetzt nicht weiter eingehen. Auch gibt es keine Empfehlung, diesen Dienst zu deaktivieren.

Aufräumen

Wie schon erwähnt, werden auf diese Art und Weise eine ganze Menge Ereignisse protokolliert.

Auch wenn es sich ressourcentechnisch sicher nur um einen Tropfen auf dem heißen Stein handelt – brauchen tun wir das jetzt nicht mehr.

Es bietet sich an, den Service wieder zu deinstallieren, was letztendlich mit dem Parameter -u erfolgt:

Bleibt eigentlich nur noch, „viel Erfolg“ bei der Suche zu wünschen 🙂