Windows Management Instrumentation (WMI) soll für Admins eine Möglichkeit bereitstellen, möglichst einfach auf Hardwaredaten und Einstellungen des Rechners lesend sowie auch schreibend über Scriptsprachen, die WMI unterstützen, zugreifen zu können. In unterschiedlichem Umfang ist WMI eigentlich auf jedem Windowsssystem vorhanden. Sehr einfacher Zugriff besteht auf die WMI zum Beispiel über Powershell. WMI funktioniert dabei auch über das Netzwerk - also nicht nur lokal.
Bei Nachforschungen zu WMI bin ich unter anderem auf folgenden - sehr informativen - Artikel gestoßen:
Für jemanden, der noch nie in der WMI herumprogrammiert hat, ist die Sache etwas schwer zu verstehen. Ich versuche das mal extrem zu vereinfachen.
Die WMI besteht aus unterschiedlichen Klassen. Jede Klasse hat quasi ihren eigenen Aufgabenbereich. In diesen Klassen sitzen Objekte, die quasi unterschiedliche Aufgaben aus diesem Aufgabenbereich abarbeiten können und die von Programmiersprachen gelesen und teilweise auch beschrieben werden können.
Die WMI verfügt dabei über eine eigene Datenbank, die scheinbar größtenteils unabhängig von der Registry ist.
Nun wäre es ja sehr interessant, wenn auch die Möglichkeit bestände, über WMI auf bestimmte Ereignisse, die auf dem Rechner stattfinden, Administrativ reagiert werden könnte - diese Möglichkeit gibt es auch - leider lässt sich das aber auch als Autostartmöglichkeit missbrauchen. Und zwar so, dass noch nicht einmal eine Datei auf dem Rechner zurückbleibt, die von einem Virenscanner überhaupt untersucht werden könnte.
Wir werfen jetzt mal einen Blick darauf, wie das geht - wir versetzen uns also in die Haut eines Malwareschreibers hinein:
- Zuerst benötigen wir mal ein regelmäßiges Ereignis, um damit den Start einer Malware steuern zu können. Ideal wäre da zum Beispiel ein Objekt in der Klasse __IntervalTimerInstruction. Mit einem solchen Objekt lassen sich intern im System Signale erzeugen, die nach Ablauf einer bestimmten Frist imm wiederkehren.
- Wir benötigen dann noch ein Objekt, was dieses Signal auffangen kann. Ein solches Objekt wäre ein Objekt der Klasse __EventFilter. Dieses Objekt fängt quasi nur unser zuerst erzeugtes Timersignal auf.
- Jetzt fehlt noch ein Objekt, was über WMI etwas ausführen kann. Wir schauen uns dazu mal die Klasse ActiveScriptEventConsumer an. Dort kann man sowohl unter ScriptFileName den Dateinamen eines Scriptes angeben, als auch unter ScriptText den kompletten Text des Scriptes in der WMI Datenbank speichern, ohne dass irgendwo eine eigene Datei auftaucht. Perfekt zum Ablegen unserer Malware als Script.
- Mit einem Objekt der Klasse __FilterToConsumerBinding verbinden wir nun das unter 3. erzeugte Objekt mit dem Empfänger des Signals, den wir im Schritt 2. erzeugt haben.
Was daraus entsteht, ist wirklich beeindruckend. Bei jedem Start des Rechnes wird so ein Script immer nach der im Timerobjekt eingestellten Intervallzeit ausgeführt. Das ganze läuft im Account System - dieser Account hat mehr Rechte, als sie die Gruppe der Administratoren besitzt und ist der Account des lokales Betriebssystems, in dem auch viele Dienste laufen.
Das gute an der Sache: Diese Objekte kann man erst erstellen, wenn Malware bereits administrative Rechte erreicht hat. Man sollte also generell aufpassen, was man auf einem System installiert - installiert man selbst zum Beispiel Malware, weil man einem Keygen oder Crack administrative Rechte zubilligt, hat man im Prinzip bei so einer Sache verloren.