Rootkit kinderleicht und einfach entfernen ?

[dapansen]

Hi,

auf Wunsch von Forenwanderer werde ich meine ersten Auswertungen direkt schon vor der Ergebnisfindung posten.

Ich hatte eigentlich vor zuerst mal das Ergebis zu bestätigen, und dann mit diesem gemeinsam nach Außen aufzutreten.

Problemstellung:
SemperVideo.de hat in einem Video behauptet, dass sich grds. mit einem Dateiabgeleich eine mittels Root-Kit-Technik versteckte Datei finden läßt. Im Grunde bezog sich diese Aussage (lt. SemperVideo) auf eine von den Microsoft-Experten für die Root-Kit-Findung selbst empfohlene Technik. (Den Link auf die Microsoft-Seite hab ich schon hier gepostet).

Da ich diese Methode ebenfalls für gangbar halte und Forenwanderer der Meinung ist, dass sich eine Datei mittels Root-Kit-Technik verstecken läßt, die NICHT aus einem anderen System "gesehen" wird, wollten wir einen Test durchführen.

Um hier einen Test durchführen zu können, hat Forenwanderer mir ein "infiziertes" System zur Verfügung gestellt, auf dem sich mindestens eine Datei (die, die gefunden werden will) mittels Root-Kit-Technik versteckt.

Zwischenergebnis: Ein erster Test des Dateiabgleichs, der durchgeführt wurde, zeigt dass der Dateiabgleich nicht zu funktionieren scheint. Jedenfalls zeigten die Dateien keine Unterschiede.

Die Dateiauflistung (die identisch ist) habe ich hier (http://rapidshare.de/files/44626354/dat ... h.zip.html) hochgeladen.

Die Frage ist jetzt, ob das Ergebnis verläßlich ist.

Die Installation ist nicht ohne einige Abstürze über die Bühne gegangen. Das Windows-Grundsystem installierte sich bis auf zwei kleinere Fehlermeldungen tadellos. Nach dem ersten Reboot wird noch sog. "Windows Postinstallation (WPI) durchgeführt, die mehrmals so heftig abstürzt, dass es nur über einen Reset neu gestartet werden kann.

Nachdem es so aussieht, als wenn die WPI durchgelaufen ist, läßt sich mit dem System nicht mehr arbeiten. Es loggt sich unregelmäßig von selbst aus und meldet das der Rechner gesperrt ist.

Ein Video wie der Bootvorgang und das anschließende "Aussperren" aussieht, habe ich hier (http://rapidshare.de/files/44625586/mal ... 2.avi.html) online gestellt.

Mir ist jetzt nicht klar, ob diese Beeinträchtigung durch die Abstürze bei der Installation verursacht wurden, oder ob das Auswüchse des Root-Kit sind.

Insoweit ist eine Frage, wann die Root-Kit Datei in dem kompletten Prozess installiert wurde.

Wenn dies während der Installation des Grundsystems passiert ist, sollte die Datei auf dem System sein. Dann wurde sie nicht gefunden.

Sollte dies erst während der WPI gesehen sein, kann es sein, dass die Root-Kit-Datei aufgrund eines Absturz garnicht implementiert wurde.

Das dürfte sich aber leicht feststellen lassen, indem Forenwanderer sagt, welche Datei auf dem System sich "versteckt".

Ein weiterer Dateiscan über ein Ubuntu System habe ich hier (http://rapidshare.de/files/44627881/inf ... u.txt.html) online gestellt.

Diese hab ich noch nicht in die Suche nach der Datei mit einbezogen, weil das meiner Meinung nach zu sehr von der SemperVideo.de/Microsoft Methode abweichen würde.

Die derzeit abschließende Frage lautet: Welche Datei versteckt sich in welchem Verzeichnis?

Viele Grüße

dapansen

[forenwanderer]

Sorry dapansen,

da hast du mich falsch verstanden. Ich habe dir die Dokumentation der Maleware per PM zukommen lassen. Mir ging es nur generell darum, dass wir beide unsere Ergebnisse chronologisch veröffentlichen. Das hast du jetzt schon getan, ohne meine Antwort auf deine letzte PM abzuwarten. Das ist aber schon gut so...

SemperVideo.de hat in einem Video behauptet, dass sich grds. mit einem Dateiabgeleich eine mittels Root-Kit-Technik versteckte Datei finden läßt.

Das war in der Tat, der Stein des Anstoßes, jedoch nicht allein. Wer behauptet denn, dass jede Maleware die gleichen Stealth- Techniken (die gleiche Rootkit- Technik) wie der Testkandidat Vanquish verwendet ? Die Definition des Begriffes "Rootkit" beschreibt etwas grundlegend anderes, als es für Maleware missbraucht wird. Dort beschränkt man sich darauf, dass die Maleware sich vor dem User oder dessen eingesetzten Tools mehr oder weniger gut verstecken kann. SemperVideo bricht die Definition noch weiter herunter und stellt es so dar, als wäre die Methode, wie sie Vanquish praktiziert die einzig relevante. So ist es aber eben nicht. Wer schreibt denn den Malewareautoren vor, dass sie gefälligst diese (bekannte) Methode verwenden müssen ?

Die Dateiabgleichmethode kann folglich nur erfolgreich sein, wenn genau diese Technik angewendet wird und keine andere. Das wäre das Ende jeglicher Maleware, weil sie ja kinderleicht aufgespürt werden könnte. Einen Test mit diesen Vorgaben könnte man sich schenken und deshalb habe ich eben andere Rootkit (Stealth) Techniken verwendet, wenn auch etwas unorthodox, wie sich herausstellen wird - ich bin eben kein professioneller Malewareschreiber...

Mit meiner Veröffentlichung warte ich jedoch noch, bis du auf die PM geantwortet hast, dapansen, da es dir zusteht, dies als erster zu erfahren. Trotzdem möchte ich noch einiges aus dem CoBi- Forum aufarbeiten, damit man nicht unbedingt dort nachlesen muss. Daher zitiere ich einige Eckpunkte...

Bei einem Root-Kit-Virus wird (i.d.R.) überhaupt keine Datei infiziert. Der kommt als eigene Datei daher, die allenfalls wiederum von einer anderen Datei vor dem Löschen geschützt wird. Die anderen Dateien auf dem System werden nicht angegriffen.

Das kann man pauschal so nicht sagen. Die Rootkit- Eigenheit bestimmter Maleware ist nur ein Teil der Maleware selbst. Maleware versucht sich, der Erkennung durch den User und dessen eingesetzte Sicherheitstools zu entziehen. Wie die Maleware das anstellt, ist nicht eindeutig definiert, sondern ist eine sehr individuelle Sache und rein abhängig vom Einfallsreichtum des entsprechenden Malewareautors. Die angewandte Rootkit- Technik des Beispiels Vanquish ist keineswegs repräsentativ. Deshalb kann ich diesen Ausführungen keineswegs zustimmen und meine Testmaleware wird dies auch widerlegen.

Normale Viren sind darauf aus, den Wirt (also den Computer) zu killen, also lahm zu legen. Damit zwingen sie den Benutzer das System neu aufzubauen und töten sich damit im Endeffekt selbst.

Was sind "normale" Viren ? Viren, wie sie hier beschrieben werden, kenne ich noch aus DOS- Zeiten, als diese nicht den heutigen kriminellen Zielvorgaben folgten. Die Energie der Programmierer hatte andere Ziele.

Root-Kit-Viren sind viel cleverer. Die lassen den Wirt leben damit sie selbst leben können. Sie wollen sich ja über andere Boot-Sektoren (CD, DVD, Diskette, Internet) verbreiten. Es ist nicht das Problem, dass der Root-Kit-Virus "Probleme" macht. Es ist das Problem, dass er schwer zu entfernen ist.

Das ist grundsätzlich bei Maleware so und ist nicht begrenzt auf Rootkits der Marke Vanquish. Falsch ist jedoch, dass solche Maleware sich über Bootsektoren verbreiten würde, das wären dann wiederum die sog. Bootsector- Viren, die auch beinahe ausgestorben sind und aufgrund ihrer doch stark begrenzten Größe kaum Stealth- Techniken wie Rootkits beinhalten konnten. Die Größe von Bootsector- Viren ist auf wenige Bytes (max. 1024 Bytes) beschränkt.

Also ein Root-Kit-Virus besteht aus 3 oder 4 Dateien und einigen Registry-Einträgen

Woher stammt diese Erkenntnis ? Dies ist eine reine Mutmaßung und trifft allenfalls auf Kollege Vanquish zu, ist aber nicht repräsentativ.

Wenn sein Virenscanner den Root-Kit-Virus erkennt, weiss der Scanner auch wie der Virus sich versteckt. Einen Root-Kit-Virus kann man mit einem simplen Datei-Abgleich finden. Ist natuerlich aufwendig, wuerde aber auch komplett ohne Virenscanner gehen. Natuerlich sind dann evtl. noch die Registry-Einträge drin, aber die Schaden dem System nicht.

An dieser Stelle habe ich mich dann auch in die CoBi- Diskussion eingemischt. Ich werde auch beweisen, dass ein Virenscanner eben nicht das Virus und seine Auswirkungen flächendeckend findet und unschädlich macht und dass der Dateiabgleich nur in extrem begrenztem Rahmen erfolgversprechend ist.
Besonders die Aussage, dass von der Maleware erzeugte Registry Einträge keinen Schaden verursachen könnten, ist Teilaspekt meiner Test- Maleware und wird auch dies widerlegen.

Ist doch paradox, zu glauben, dass der Virenscanner den Root-Kit-Virus erkennt, ihn aber danach nicht entfernen kann.

Ich stimme zu, dass es paradox ist und dennoch werde ich herausstellen, dass nicht selten ein Virenscanner zwar die Maleware erkennt (womöglich nur teilweise, weil sie eben mit Stealth- Techniken, sich dem Scanner entziehen konnte), aber dennoch nicht entfernen kann. Dazu auch später mehr...

Natürlich, das war eine bespielhafte Demonstration. Es wird nicht bei jedem Virus gleich verlaufen. Aber deswegen sollte man jetzt nich von jedem Virus und jeder Root-Kit-Variante ein eigenes Video erstellen. Denn eins ist bei jeder Malware gleich. Wenn man sie erstmal erkannt hat, ist das Entfernen einfach. Problematisch ist die Zeit bis man ihn erkannt hat.

Ich zitiere nochmals ein Statement aus den CoBi- Thread, der nun für den Test interessant wird. dapansen, du gibst selbst zu verstehen, dass sich Vireninfektionen unterschiedlich zutragen. Der letzte Satz ist interessant und bezeichnend. Man muss die Maleware erkennen und in allen Teilen finden, um sie entfernen zu können. Da gebe ich dir recht, doch allein an meiner bescheidenen Testmaleware wird deutlich werden, wie schwierig dies ist und aufgrund der Tatsache, dass Maleware sich selbst modifizieren kann, ein weitgehend sinnloses Unterfangen.

Unterschiedlich haben wir auch den sog. Soll- Zustand betrachtet bzw. wie dieser definiert ist:
Dein Standpunkt:

Ich (als User) hab den Verdacht das sich bei mir Programme/Dateien mit der sog. Root-Kit-Technik verstecken. Jetzt weise ich Windows an mir alle Dateien aufzulisten und das Ergebnis in eine Datei zu schreiben. Damit habe ich den Soll-Zustand. Jetzt wird sofort eine Live-CD gebootet und die wird ebenfalls angewiesen alle Dateien aufzulisten. Die Dateien die sich mittels Root-Kits auf der installierten Version verstecken können, können sich nun nicht mehr verstecken. Also werden Sie mit aufgelistet. Wenn ich sorge habe, dass das PE-Windows ebenfalls Dateien versteckt, nehm ich ein Ubuntu zum auflisten.

Mein Standpunkt:

Du bekommst damit keinesfalls den Soll- Zustand. Der Soll- Zustand liegt deutlich zurück und ist nicht mehr per Dateiabgleich zu ermitteln. Der Test von SemperVideo bezieht sich meines Erachtens auf ein kontrolliertes Infizieren eines überschaubaren Systemes. Es wird schlicht und einfach vernachlässigt, dass aktive Malware nicht wartet bis der User sie bemerkt. Deine Argumentation beruht darauf, dass dein Verdachtsmoment unmittelbar vor der Aktivierung der Malware liegt, was nur funktionieren kann, wenn man bewußt bekannte Malware kontrolliert installiert. So wurde es im SemperVideo gemacht und hat wenig mit der Realität zu tun.
Wenn ein User oder gar DAU den Verdacht äußert, sich evt. Maleware "eingefangen" zu haben, liegt die tatsächliche Infizierung meist (computertechnisch betrachtet) weit zurück. Ein IT- Profi merkt das womöglich deutlich früher, jedoch gibt es auch dann bereits keinen definierten Soll- Zustand mehr, auf welchen man für einen Dateiabgleich zurückgreifen könnte.

An diesem Punkt haben wir dann diesen Praxistest vereinbart, wobei mich leider stört und ich auch nicht verstehe, dass plötzlich kaum noch Interesse von anderen Forenmitgliedern bestand.

Gruß,
Forenwanderer

[EnnoK]

So. Habe mir mal den kompletten Thread im CoBi-Forum angetan...
Daß das Interesse da nachgelassen hat, könnte daran liegen, daß ihr dem ursprünglichen Fragesteller keineswegs, und vor allem zeitnah, geholfen habt und euch stattdessen mit ellenlangen Texten bewerft (auch wenn sie interessant sind).
Nichtdestotrotz freu ich mich schon auf ein Ergebnis eures Experiments.

Und zu experimentellen Viren:
Ich denk Firmware-"Viren" sind garnicht so weit hergeholt. Bei welcher Firmware (abgesehen vom BIOS) gibt es denn Sicherheitsvorkehrungen? Ich würde sowas eher in der Firmware vom DVD-Laufwerk verstecken. Grafikkarte, Festplatte, Motherboard (integrierte Netzwerkkarte) werden deutlich häufiger getauscht.

Zur Erkennung von Rootkits per Dateivergleich:
Sicher wäre es bei einem reinen frisch aufgesetztem System auf diese Weise möglich. Aber sobald andere Installations/Deinstallationsvorgänge dazwischen kommen, die nicht auf einer Sicherheitskopie erfasst sind, wird das sehr schwierig.
Am sichersten wären Veränderungen zu finden, wenn ein Vergleichsprogramm einen Überblick über alle Dateien ordentlich installierter Software erhält und nichtzuzuordnende Dateien besonders überprüft... da aber haufenweise Software in unzähligen Varianten existiert und einer solchen Software nicht unbedingt bekannt sind, werden da haufenweise Dateien zu unrecht verdächtigt...

Schädlichkeit von Registrierungseinträgen:
Man braucht kein großartiges Rootkit um Schäden anzurichten, wie Forenwanderer gezeigt hat. Ein einfaches Script, daß ein paar Einträge umbiegt und schon ist der Schaden immens. Wenn es die richtigen sind, könnte es so einen weiteren Admin installieren, der sich dann Remote im System anmelden kann... unbedarfte Nutzer würden das in den seltensten Fällen entdecken. Und ein Viren-/Rootkitscanner der auf soetwas prüft ist mir nicht bekannt. In diesem Zusammenhang möchte ich an den Serviceaccount von Microsoft erinnern, der in XP eingebaut, aber auch recht schnell per Update deaktiviert wurde.

Letzten Endes:
Wer sich einen Computer zulegt, sollte sich auch über potentielle Gefahren im klaren sein, und sich absichern. Beim Autokauf weis der Käufer in der Regel auch, daß ein Auto gefährlich sein kann und schaut ob z.B. Airbags installiert sind. Und den Zugang zum Auto wird er auch beschränken.

[thbrueck]

Nun ja, Ennok, den CoBi- Thread und seine Ausgangssituation, dass der User dort irgendwelche Probleme auf Papi's PC durch Kasperky mitgeteilt bekommen hat, hat im Grunde mit dem hier geschilderten Test nichts mehr zu tun. Nicht zuletzt deshalb, glaube ich, sollte man es differenziert betrachten. Wir wollen hier in diesem Thread ja nicht das Problem des TO aus dem CoBi- Forum lösen.


thbrueck

[EnnoK]

Jo. Hab ich schon so verstanden. Bezog sich ja auch nur auf die letzte Äusserung vom Forenwanderer:

wobei mich leider stört und ich auch nicht verstehe, dass plötzlich kaum noch Interesse von anderen Forenmitgliedern bestand.

[forenwanderer]

Zur Erkennung von Rootkits per Dateivergleich:
Sicher wäre es bei einem reinen frisch aufgesetztem System auf diese Weise möglich. Aber sobald andere Installations/Deinstallationsvorgänge dazwischen kommen, die nicht auf einer Sicherheitskopie erfasst sind, wird das sehr schwierig.
Am sichersten wären Veränderungen zu finden, wenn ein Vergleichsprogramm einen Überblick über alle Dateien ordentlich installierter Software erhält und nichtzuzuordnende Dateien besonders überprüft... da aber haufenweise Software in unzähligen Varianten existiert und einer solchen Software nicht unbedingt bekannt sind, werden da haufenweise Dateien zu unrecht verdächtigt...

Hallo Ennok,

du bist dem gleichen Mißverständnis aufgessen wie ich auch. SemperVideo bezieht sich anscheinend nur auf reine Userland- Rootkits, die ausschließlich die Win- API manipulieren. Für diesen Fall kann eine solche Dateiabgleichmethode durchaus erfolgversprechend sein, wo hingegen Maleware- Scanner versagen. Aber dazu kann dir dapansen sicher genaueres sagen. Für mich war allerdings zu keinem Zeitpunkt ersichtlich, dass SemperVideo dies so voraussetzt.

Schädlichkeit von Registrierungseinträgen:
Man braucht kein großartiges Rootkit um Schäden anzurichten, wie Forenwanderer gezeigt hat. Ein einfaches Script, daß ein paar Einträge umbiegt und schon ist der Schaden immens. Wenn es die richtigen sind, könnte es so einen weiteren Admin installieren, der sich dann Remote im System anmelden kann... unbedarfte Nutzer würden das in den seltensten Fällen entdecken. Und ein Viren-/Rootkitscanner der auf soetwas prüft ist mir nicht bekannt. In diesem Zusammenhang möchte ich an den Serviceaccount von Microsoft erinnern, der in XP eingebaut, aber auch recht schnell per Update deaktiviert wurde.

Auch hierzu kann dapansen etwas erklären, da ich ihn auch hierbei falsch verstanden hatte...

Die Auflösung, was die Testmaleware nun so alles angerichtet hat, werde ich nach Absprache mit dapansen in Kürze veröffentlichen.

Gruß,
Forenwanderer

[Klinkenputzer]

@ forenwanderer

An diesem Punkt haben wir dann diesen Praxistest vereinbart, wobei mich leider stört und ich auch nicht verstehe, dass plötzlich kaum noch Interesse von anderen Forenmitgliedern bestand.

Du hattest schon im Cobi-Forum Recht, als du bemerktest, dass das Interesse sehr mager ist. Es wurde erst besser, als du es erwähntest. Ich war zwar eine Woche lang auf einem Seminar, habe aber jeden Abend mal kurz nach Neuigkeiten geschaut. Ich kann, wie schon im Cobi-Forum erwähnt, zu dem Thema aus "Unwissenheit" nichts sagen, aber ich verfolge is immer noch mit dem gleichen Interesse, das ich ich auch schon im Cobi-Forum hatte.
Ich finde dieses "magere Interesse" selber auch sehr schade, da ich mir (wahrscheinlich nur ungefähr) denken kann, wieviel Arbeit es für depansen und auch für dich macht, einen solchen "Beweis" oder "Gegenbeweis" zu liefern. Es wäre für jeden, den das Thema irgendwann mal betrifft, sehr hilfreich.
Doch bin ich überzeugt, dass mehr interessierte Zuschauer oder Leser dieses Thema auch hier verfolgen.
Forenwanderer, du sagtest mir einmal, dass Feedback motiviert.

Ich kann euch beiden nur sagen, dass ich den Hut ziehe vor Menschen, die sich trotz Desintresse so hingebungsvoll einem Thema widmen, dass zwar für sehr viele Menschen hilfreich sein könnte, aber doch so wenig Anklang findet.
Lasst euch nicht entmutigen, denn wichtig ist nicht unbedingt die jetzige Menge der Teilnehmer. Eventuell erntet ihr den Dank für eure Mühe später, vielleicht aber auch nie.
Doch das wichtigste ist doch das Ergebnis.

Gruß Uwe

[forenwanderer]

Hallo,

Hier ist nun die Auflösung, was die Testmaleware so alles anstellt, wenn sie einmal gestartet wird:

Sobald die Maleware einmalig ausgeführt wird, wobei es sich tatsächlich um die Datei winsystem.exe handelt, werden folgende Dinge ausgeführt:

Zunächst wird der Bildschirmschoner in der Registry manipuliert:

Code: Alles auswählen

HKEY_CURRENT_USER\Control Panel\Desktop  "ScreenSaverIsSecure", "Reg_SZ", "1"
HKEY_CURRENT_USER\Control Panel\Desktop, "ScreenSaveTimeOut", "Reg_SZ", "1"
HKEY_CURRENT_USER\Control Panel\Desktop, "ScreenSaveActive", "Reg_SZ", "1"

Das ist ein simples Ablenkungsmanöver, das ja offensichtlich sehr gut funktioniert hat. Wäre ein Bildschirmschoner in deinem Testfeld installiert gewesen, hätte sich dieser im Sekundentakt eingeschaltet, so dass der Anwender damit beschäftigt ist, diesen lästigen Mißstand zu beseitigen, was mitunter einen einfachen Anwender schon überfordern kann. Im Testszenario hat der Sicherheitsparameter nur allein zugeschlagen, was sich darin äußerte, dass dein System sich zur Anmeldemaske verabschiedete. Dies gibt der Maleware einen Zeitvorspruch weitere Dinge zu tun, ohne dass der User etwas dagegen unternehmen kann bzw. zu sehr verwirrt wird.
Unerklärlich war der beschriebene Umstand, dass man vom System ausgesperrt wird. Dies ist definitiv keine Auswirkung dieser Testmaleware, wie sich aus der Beschreibung ergeben wird.

Maleware bedient sich gerne solcher Ablenkungsmanöver und die Screensaver- Variante ist schon etwas in die Jahre gekommen und galt zu Windows 3.x- Zeiten noch als Joke- Programm. Heutzutage werden gerne Popups dafür verwendet.

Als nächstes legt die Testmaleware einige eigene Registry Keys an, die in diesem Fall allerdings harmlos sind. Es geht lediglich darum zu zeigen, dass durchaus durch Manipulation der Registry die Dateiabgleichmethode gegen Absurdum geführt werden kann, wenn man es geschickt anstellt.

Code: Alles auswählen

HKEY_CURRENT_USER\ENVIRONMENT\forenwanderer1
HKEY_CURRENT_USER\ENVIRONMENT\forenwanderer2
HKEY_CURRENT_USER\ENVIRONMENT\forenwanderer3
HKEY_CURRENT_USER\ENVIRONMENT\forenwanderer4

HKEY_CURRENT_USER\ENVIRONMENT, "forenwanderer1", "REG_EXPAND_SZ", "c:\windows\temp
HKEY_CURRENT_USER\ENVIRONMENT, "forenwanderer2", "REG_EXPAND_SZ", "%windir%"
HKEY_CURRENT_USER\ENVIRONMENT, "forenwanderer3", "REG_EXPAND_SZ", "%systemdrive%"
HKEY_CURRENT_USER\ENVIRONMENT, "forenwanderer4", "REG_EXPAND_SZ", "%windir%\system32

Diese Einträge erweitern die Environment- Variablen Tabelle, was man auch über Start > Systemsteuerung > System > Erweitert > Umgebungsvariablen nachvollziehen kann. Dies ermöglicht der Maleware, auch von anderen Stellen aus aktiv zu werden, selbst wenn die Pfadangaben nicht mehr stimmen würden.

Der nächste Schritt sollte eigentlich für einen erfolgreichen Dateiabgleich kein Problem darstellen, wobei die Definition des Zeitpunktes eine wesentliche Rolle spielt. Nur der Abgleich vor und nach der Infizierung kann dies bewirken, keinesfalls ein Abgleich vom infizierten System gegenüber einer Live- CD, weil hier ja eigentlich nach Definition der SemperVideo - Gestalter gar nichts versteckt wurde:
Im Verzeichnis
c:\Dokumente und Einstellungen\All Users\Anwendungsdaten\

wird eine Datei mit Namen acrobatreader.log angelegt, die Informationen sammelt, welcher User sich wann eingeloggt hat. Ich brauche sicher nicht zu erwähnen, dass auch jede andere Information, die auf dem System zu finden ist, so aufgezeichnet werden kann. Diese Datei ist also nach Infizierung zusätzlich auf dem System vorhanden und kann nur festgestellt werden, wenn die Soll- Zustände vor der Infizierung festgehalten würden. Das entspricht allerdings nicht den Vorgaben von SemperVideo...

Als nächtes werden alle Verknüpfungen des angemeldeten Users vom Desktop gelöscht. Solche Erscheinungen bis hin zu einem völlig leeren Desktop werden oft gemeldet, wenn Systeme von Maleware befallen sind. Auch dies stellt eher ein Ablenkungsmanöver dar und simuliert einen Betriebssystemfehler, den es tatsächlich sogar schon bei Windows 2000 früher gab.

Nun wird's richtig interessant - die Test- Maleware macht sich erneut an der Registry zu schaffen:

Code: Alles auswählen

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU, "NoAutoUpdate", "REG_DWORD", "00000001")
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU, "ScheduledInstallTime", "REG_DWORD", "00000012")
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU, "AUOptions", "REG_DWORD", "00000002")
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU, "ScheduledInstallDay", "REG_DWORD", "00000001")

Hiermit wird schlicht und ergreifend die WindowsAutoUpdate- Funktionalität abgeschaltet. Ein Versuch, das WindowsAutoUpdate über das Sicherheitscenter wieder zu aktivieren, wird nicht funktionieren...
(auch dies ist ein typisches Symptom von Maleware)

Natürlich muss Maleware möglichst lange aktiv bleiben und deshalb werden gerne die Registry Keys für den Autostart manipuliert:

Code: Alles auswählen

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, "Autoruns1", "REG_SZ", "bootcfg.exe")
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, "Autoruns2", "REG_SZ", "c:\bootcfg.exe")
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, "Autoruns3", "REG_SZ", "c:\Windows\bootcfg.exe")
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce, "Autoruns1", "REG_SZ", "winsystem.exe")
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce, "Autoruns2", "REG_SZ", "c:\winsystem.exe")
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce, "Autoruns3", "REG_SZ", "c:\Windows\winsystem.exe")

Hierin begründen sich dann auch die Fehlermeldungen nach nicht gefunden Dateien, die evt. von einem Antimaleware- Programm gelöscht wurden. Das hat später übrigens wiederum erhebliche Auswirkungen auf die Dateiabgleichmethode...

Nebenbei wird an dieser Stelle noch mal kurz die öffentliche IP ermittelt, nicht die lokale, da die öffentliche primär wichtiger ist...

So und jetzt wird lustig hin und her kopiert:

winsystem.exe wird aus dem aktuellen "WorkingDir" ins Windows-, Windows\system32- und Temp- Verzeichnis kopiert. Aus dem Temp- Verzeichnis wird dann die Datei ins "MyDocuments"- Verzeichnis (nicht kopiert) bewegt und anschließend ins "Root"- Verzeichnis. Nebenbei wird dann die Datei auch noch ins "Autorun"- Verzeichnis kopiert und als autoexec.exe umbenannt. Diese "Copy" und "Move" Aktionen werden allerdings alle einzeln entweder abgebrochen oder ausgeführt, je nachdem, ob die zu kopierende Datei überhaupt (noch) existent ist. Im Root- Verzeichnis bleibt dann die Testmaleware als bootcfg.exe auf jeden Fall bestehen. Die Dateiabgleichmethode ist damit völlig überfordert und kann gar nicht das erhoffte Ergebnis liefern, weil die hier angewandte Stealth- Technik deutlich von der des Vanquish- Rootkit abweicht. Damit's noch verwirrender wird, kopiert die Testmaleware einfach als Nebeneffekt alle DLL- Dateien aus den System32- Pfad in den darüberliegenden Windows- Pfad. Das hat keine Nachteile auf die Funktionalität des Betriebssystemes, macht aber einen Dateiabgleich absolut irrsinnig.

Damit auch typische Malewareeigenschaften ausgelebt werden, versendet die Testmaleware über eine eigene SMTP- Engine eine Email an eine zuvor definierte Emailadresse, was völlig unbemerkt abläuft. Somit weiß ich, dass die Testmaleware am 29.01.09 um 15h22 in deinem Test erstmals aktiviert wurde.
Folgende Daten wurden übermittelt:

Code: Alles auswählen

9B4C3277A889486
192.168.128.78
C:\Documents and Settings\All Users\Application Data
2600
Administrator
C:\Documents and Settings\Administrator\×ÀÃæ\Documents and Settings\Administrator
0.0.0.0
9B4C3277A889486
C:\Documents and Settings\Administrator\×ÀÃæC:\Documents and Settings\Administrator\×ÀÃæ\winsystem.exeC:\Documents and Settings\Administrator\×ÀÃæ

Das Ganze sollte man als Datei "send.txt" im Root- Verzeichnis auf dem System finden.

Eigentlich sollte nun an dieser Stelle der aktuell verwendete Browser die Startseite von diesem Forum aufrufen... (Joke)

Um noch einen 2. Datenkanal zur Verfügung zu haben, wird auch noch per FTP die Datei "EventLog.bak" aus dem Root- Verzeichnis zu einem FTP- Server übertragen. Diese Datei wurde zuvor aus der Ereignisanzeige des Systemes erstellt und gibt genau die entsprechenden Infos aus.

Damit man auch noch etwas Spass bekommt, wird am Ende noch das Standardgateway der verwendeten LAN- Adapters auf 192.168.50.1 und der DNS- Eintrag auf 192.168.50.100 umgestellt. Das simuliert ein kleines HiJacking und ist auch ein gängiger Maleware- Mechanismus. In diesem Fall allerdings wird schlicht die Verbindung ins Internet abgeschaltet, es sei denn, man verwendet zufälligerweise die eingestellten Werte.

Was ich natürlich nicht sagen kann, ist, dass alle angestrebten Dinge auch tatsächlich funktionieren.

Dateien, die dazu gekommen sind, aber ich selbst nicht sagen kann, wo sie sich befinden, noch ob sie alle vorhanden sind:

winsystem.exe (kann 3mal zu finden sein)
autoexec.exe
bootcfg.exe (kann 2mal zu finden sein)
acrobatreader.log
send.txt
eventlog.bak

Das Verstecken wird einfach derart realisiert, dass bestehende Dateien kopiert, bewegt und umbenannt werden. Ursprünglich wollte ich sogar noch eine unwichtige Datei im Windows- bzw. Windows\System32 Pfad löschen, um den Zuwachs einer kopierten Datei auszugleichen, was ich aber dann doch verworfen hatte. Dies wäre allerdings auch eine recht simple Methode gewesen, den Dateiabgleich auszutricksen...

Wer dies gerne selbst auf einem Testsystem ausprobieren möchte, dem kann ich gerne die Testmaleware zur Verfügung stellen. Ich weise jedoch darauf hin, dass jeder für etwaige Schäden selbst verantwortlich ist, wenn er unsachgemäß die Testmaleware auf einem Produktivsystem testet. Bei Interesse sendet mir einfach eine PM oder Email...

Interessant dürfte auch sein, wie einzelne Virenscanner auf die Testmaleware reagieren. Vielleicht kann dies freundlicherweise jemand mitteilen.


Gruß,
Forenwanderer

[dapansen]

Hallo an alle,

ich kann die von Forenwanderer genannten Ergebnisse entsprechend bestätigen.

Wie so oft in diesem Medium, in dem "Gelesenes" anders rüber kommt als "Gesprochenes", gab es auch hier einige Mißverständnisse.

Es geht ja im Grund um Dateien, die sich mit "Rootkit-Techniken" vor dem Auffinden verstecken. Jedoch gibt es zwei verschiedene Meinungen bzw. Auffassungen was Rootkit Technik ist.

Der klassische Ansatz, versteht darunter den Administrator-Bausatz, welche Aufgrund seiner "überlegenen" Rechte Manipulationen vornehmen kann, die vom normalen User nicht auffindbar sind. Das ist auch die Definition, die Forenwanderer unter Rootkit versteht.

Irgendwann in den letzten Jahren hat sich aber noch eine zweite Auffassung von Rootkit durchgesetzt. Ob Microsoft oder die Computerzeitschriften-Presse die o.g. Definition "kastriert" hat kann ich nicht genau sagen. Ich weiss, dass die C'T z.B. vor Jahren mal einen Artikel über Rootkit-Trojaner gebracht hat. Aber wer den Stein zuerst ins Rollen gebracht hat, kann ich jetzt nicht mehr sagen. Diese "kastrierte" Auffassung fasst unter Rootkit lediglich die Manipulation auf, die die API von Windows in der Art verändert, dass der User von Windows "belogen" wird.

Natuerlich ist das auch eine Rootkit-Technik, jedoch wird lt. der Microsoft Website (Link hatte ich hier schon gepostet) das ganze als "die" Rootkit-Technik angesehen. Wie gesagt, die CT sieht es (zumindest in mehreren Artikel auch so) und auch die ganzen Rootkit-Scanner von diversen Herstellern sehen auch in Rootkit nur diese "API-Manipulation".

Auf SemperVideo.de hat es ein Video zu Rootkit-Techniken gegeben, in der die API-Methode theoretisiert wurde. Das Video das hier dann Grundlage für meine Aussage wurde, dass ich den Dateiabgleich für korrekt halte, bassiert auf diesem Theorie-Video.

Also wenn man der Microsoft-Definition von Rootkit folgt, dann funktioniert der Dateiabgleich. Das ist auch der Grund warum Microsoft diesen selbst auf den eigenen Webseiten empfiehlt.

Wenn man aber der richtigen Definition von Rootkit folgt, dann kann der Dateiabgleich eigentlich nur in einem Fall von Rootkit funktionieren.

Forenwanderer hat einen eigenen "Rootkit" entwickelt, der natürlich niemals durch Dateiabgleich UND auch niemals von irgendeiner Anti-Rootkit-Software entdeckt worden wäre.

Insoweit muss man sagen, dass die entsprechenden Softwareprodukte alle nichts taugen. Das werden die aber nicht gerne hören, und Microsoft wird weiter die eigene Definition als die richtige Definition "pushen" (embrace & extent ).

Und am Ende wird sicher die originale Bedeutung verschwinden.

cu

Tom

[thbrueck]

Hallo,

ich habe dann mal aus Interesse Kaspersky Internet Security 2009 sowie Symantec Norton Internet Security 2009 auf die Testmaleware angesetzt.



KIS hat die Maleware tatsächlich entdeckt und als potentiell gefährlich eingestuft, gibt aber die Entscheidung an den Anwender weiter, wie zu verfahren ist. Möglicherweise würde KIS mit jeder ausführbaren Datei, die es nicht kennt, ebenso verfahren. Im Grunde wäre dies im Moment nichts anderes wie die Vorgehensweise der UAC von Windows Vista.



Führt man die Datei trotz dieser Warung aus, überschlagen sich die Ereignisse. Wenn auch nur der Process autoexec. exe größtenteils aufgelistet wird, wird auch die Basisdatei winsystem.exe aufgeführt. Da man diese allerdings zuvor quasi als vertrauenswürdig ausgeführt hat, fällt sie kaum noch ins Gewicht. Bootcfg.exe wurde auch nachgefragt und vom Anwender ausgeführt. Ab diesem Zeitpunkt durfte die Maleware ihre Aufgaben (Registry Änderungen usw.) durchführen und verweilte fortan im System, als gehöre sie dazu. Man könnte auch sagen: "Gefahr erkannt, aber nicht gebannt, sondern der Verantwortung des Anwenders anvertraut"

Was macht wohl der Testsieger aus etlichen PC- Zeitschriften Tests - NIS2009 ?



Die Basisdatei winsystem.exe wird erkannt, aber leider auch noch 3 False Positives.



Man muss hierzu erwähnen, dass die Maleware vor der Installation von NIS2009 bereits ausgeführt wurde. Nach der NIS- Installation geschah erst einmal nichts, erst ein manuell initiierter Scandurchlauf brachte dann dieses Ergebnis. Ein vorher installiertes NIS hätte sicher die Testmaleware ähnlich wie KIS2009 behandelt und bei der Ausführung nachgefragt.



Detailangaben, wie ein Menüpunkt verspricht, konnte NIS2009 zur Testmaleware nicht machen. Wie denn auch, wenn diese Maleware der Symantec- Datenbank (noch) fremd ist.



Enttäuschend war allerdings, dass die anderen Dateien von NIS2009 überhaupt nicht gefunden wurden. Hier war KIS2009 etwas besser, machte aber bei der späteren Behandlung eine schlechtere Figur.

Beide Suiten konnten die Testmaleware zumindest teilweise entdecken und auch teilweise an ihren Aktionen hindern, solange der Anwender nicht explizit die Datei entgegen der Warnungen ausführt. Stellt man sich vor, dass jemand sich ein Programm aus dem Internet herunterlädt, kann man in den meisten Fällen davon ausgehen, dass jener Anwender diese Datei ebenso ausführt, weil es ja sein Wille und Ziel war, diese Datei auszuführen, womöglich mit der festen Überzeugung, dass die heruntergeladene Datei ja zweifelsfrei keine Maleware, sondern der dringend benötigte Bildschirmschoner oder der wichtige Cheat für ein Spiel ist.

Im Grunde verhalten sich die kostenpflichtigen Programme genauso wie die kostenlose UAC von Vista, die aber wegen ihrer Nervigkeit schon mal gerne deaktiviert wird. Ein Benutzerkonto mit eingeschränkten Rechten hätte die Infektion überhaupt nicht zugelassen, aber würde den ungeduldigen Anwender doch zu sehr beschränken.

thbrueck