WMI - ein Segen für die Admins oder ein Fluch für die Sicherheit? Dateilose Malware ohne normalen Autostarteintrag...

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Unsere Datenschutzerklärung wurde aktualisiert. Mit der Nutzung unseres Forums akzeptierst Du unsere Datenschutzerklärung. Du bestätigst zudem, dass Du mindestens 16 Jahre alt bist.

    • WMI - ein Segen für die Admins oder ein Fluch für die Sicherheit? Dateilose Malware ohne normalen Autostarteintrag...

      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:
      1. 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.
      2. 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.
      3. 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.
      4. 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.


      ________________________________________________________

      PPFScanner PPFS Android MisterXMail@web.de
      Mfg AHT

      Dieser Beitrag wurde bereits 7 mal editiert, zuletzt von AHT ()

    • Wie kann man solche Malware finden?

      Die Suche nach Malware unterscheidet sich recht wenig vom Schreiben von Malware. Oft werden die gleichen Ansätze, gleiche APIs und ähnliche Vorgehensmethoden werwendet. So ist das auch hier. Auch hier bietet Powrshell neben einer Möglichkeit, die Malware zu installieren und auszuführen, eine ganz ähnliche Möglichkeit, nach solcher Malware zu suchen.
      Wir schauen uns dazu dieses Powershell Script einmal an:

      Quellcode

      1. Get-WmiObject -Namespace root\subscription __EventConsumer | Where-Object {$_.CommandLineTemplate -or $_.ScriptFileName -or $_.ScriptText} | Select-Object -Property Name,CommandLineTemplate,WorkingDirectory,ExecutablePath,ScriptingEngine,ScriptText,ScriptFileName | Format-List
      Das Powershell Script listet die Inhalte an Objekten in der Klasse __EventConsumer. Diese Klasse fasst eigentlich alle "Consumer Objekte" in einer Klasse zusammen - also alle Möglichkeiten, über so eine Kombination, wie ich sie oben beschrieben habe, etwas auszuführen.
      Sind bestimmte Members, die auf ausführbare Scripte verweisen können, in dem Objekt vorhanden, werden sie gelistet - ansonsten eben nicht.
      Ob das dann herauskommende Ergebnis wirklich Malware ist, müsste durch eine weitere Analyse sicher gestellt werden.

      Fall es Verbesserungsvorschläge für das oben genannte Script gibt - immer raus damit! Das Ergebnis ist ja bereits gekürzt (wie oben beschrieben).

      Über die Kommandozeile und WMIC lassen sich ähnliche listen erstellen - hier ungekürzt:

      Quellcode: WMI Malwaresuche.bat

      1. wmic/namespace:\\root\subscription PATH __EventConsumer get/format:list
      ________________________________________________________

      PPFScanner PPFS Android MisterXMail@web.de
      Mfg AHT
    • Weitere Möglichkeit für dateilose Malware mit anderer WMI Klasse?

      Neben dem ActiveScriptEventConsumer eignent sich auch die Klasse CommandLineEventConsumer zum automatishen Starten einer Malware. Wenn sich über diese Klasse Powershell starten lassen sollte, wäre auch an der Stelle der Start einer dateilosen Malware möglich. Die Sache habe ich aber noch nicht ausgetestet.
      ________________________________________________________

      PPFScanner PPFS Android MisterXMail@web.de
      Mfg AHT

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von AHT ()

    • Gerade ausgetestet: Die Sache funktioniert auch mit dateiloser Malware mit der Klasse CommandLineEventConsumer , wenn man Powershell zur Ausführung nimmt.
      Damit ist über WMI an mehreren Stellen Malware möglich, die keine eigene Datei hat und sich mit Systemrechten nach einer einstellbaren Zeit immer wieder von selbst ausführt.
      Ein Graus für jeden Virenscanner....

      Wenn ich die Sache hier so gut erklären konnte, dass sie neben mir auch noch von anderen verstanden wurde, würde ich mich sehr freuen.
      ________________________________________________________

      PPFScanner PPFS Android MisterXMail@web.de
      Mfg AHT
    • Gute Startadresse, wen´s interessiert: LINK

      Edit: Damit ist jeder PC ein offenes Buch, auch von Remote Locations wie Langley, Moskau etc. Ein Password wird die Herren von der NS (Nazionalen Sicherheit) nämlich sicher nicht aufhalten. Somit sind PCs nicht "Malware-gefährdet", sondern primär Spionageinstrumente. Unter "ferner liefen" rechnen sie auch was für User aus. Wir leben in seltsamen Zeiten ...

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von p. specht ()