Hi Antitrojaner,

Ich habe es endlich mal wieder geschafft, ein neues Spielzeug unter x64 zusammen zu basteln, nämlich einen unsichtbaren Treiber.
Nach Laden des Treibers entlädt sich dieser wieder, (nicht ohne die Liste mit den "unloaded drivers" vorgängig zu manipulieren), der Code werkelt jedoch munter weiter im Hintergrund, bis der PC heruntergefahren ist.

Auch ziemlich ausgeklügelte Anti-Rootkits können nicht aufdecken, dass etwas läuft, was genau das ist und vorallem, wer dafür verantwortlich ist.
Da ich mit Datei- und Speicheroperationen, insbesondere NtCreateSection usw. noch nicht fit genug bin, wird die Treiberdatei derzeit noch nicht versteckt - das kommt dann in der Version 2.0. Wird diese gelöscht, ist das Rootkit verschwunden.
Eine Steigerung wäre einzig noch die Verwendung von feinstem Direct-IO...vielleicht in V3.0 dann.

Da das Kernelmodul auch im abgesicherten Modus gestartet wird, bleiben zur Enthüllung - (Starteinträge) nur eine Offline-Analyse oder ein exakt passendes Vorgehen, was das Prozesse-Abschiessen betrifft.
Dass der Treiber "geladen" ist, lässt sich relativ leicht im Debug-Output (DebugView) erkennen.
Falls auch nach dem ersten Neustart nichts erkennbar ist, muss das Häklein bei "Enable Verbose Kernel Output" gesetzt werden.

Nur soviel vorneweg:
- Wir sind hier auf AMD64 - Hooks dürft ihr also vergeblich suchen.
- Ausserdem wollte ich auch keine (gefakten) Geräteobjekte erstellen, daher werdet ihr Callbacks ebenfalls erfolglos suchen.
- Die LoadImageNotifyRoutine ist zu bekannt, danach sucht ja eh jeder.
Und doch scheint der Starteintrag perfekt? versteckt zu sein...


Installation:
1.) Kernelmodul "PayLoad.sys" nach C: kopieren
2.) Im cmd-Fenster "bcdedit /set {current} testsigning YES" eingeben
3.) In der Registry unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services einen neuen Schlüssel "drvtriks" mit folgenden Werten erstellen:
ImagePath - REG_EXPAND_SZ - \??\C:\PayLoad.sys
Type - DWORD - 0x00000001
Start - DWORD - 0x00000001
Alternativ die beigelegte Registrierungsdatei (im Archiv) importieren.
NICHT via Service-Manager "sc.exe" installieren, das wird nicht funktionieren.

4.) PC neustarten, ODER im cmd "fltmc load drvtriks" eingeben.
5.) PC immer wieder herunterfahren und neustarten und den Debug-Output kontrollieren...


Getestet wurde auf Windows7 SP1 x64 und Windows 8.1 x64. Prinzipbedingt sollten auch Windows 7 SP0 und Windows 8 kein Problem darstellen.
Viel Spass!

Für 100%ige Entfernung die PayLoad.sys-Datei löschen, oder den PC plötzlich abstürzen lassen (Z.B. im Taskmanager den kritischen Prozess "smss.exe" beenden).


Grüsse - Microwave

P.S. RAR-Passwort: ring0-kit

V2.0 jetzt mit Dateisystem-Unterstützung, passender Reg-"Fix" ist im RAR-Archiv beigelegt.

1.) Datei drvtriks.sys unter C:\Windows\System32\drivers\ablegen, C:\PayLoad.sys bitte löschen.
2.) Reg-Datei importieren.
3.) Neustarten oder im cmd-Fenster "fltmc load drvtriks" eingeben.

Datei sollte nach Neustart ebenfalls verschwunden sein, wiederum getestet unter Windows 7 und Windows 8.1.


Die nächsten Versionen sollen eine Verschleierung vom Wasserzeichen "Testmodus..." bieten, wie auch Direkt-IO und eventuell das Abfangen von Systemabstürzen via KeRegisterBugCheckCallback, so dass auch ein künstlicher PC-Absturz nicht mehr zur Deaktivierung des Rootkits führen würde - mal schauen, was so möglich ist.
Ausserdem wäre es testweise an der Zeit, mal einen kleinen Keylogger zu implementieren...

Kennwort: ring0-kit2

Grüsse - Microwave

Habe es nun erweitert zu einem kleinen Keylogger, wobei ein Teil des Codes nicht von mir sondern vom Clandestiny-Rootkit "KLOG" stammt.
Allerdings verwende ich aus Gründen der Einfachheit keinen sogenannten "Filtertreiber", sondern der Code bringt
direkt im Treiberobjekt (nicht Geräteobjekt) des Tastatur-Klassentreibers (kbdclass.sys) einen sogenannten IRP-Hook an.
Zudem verlässt sich der Keylogger beim Datei-Verstecken auf einen undokumentierten Teil
des NTFS-Dateisystems, wodurch der Einsatz von Dateifiltern, ADS oder Hooks vermieden wird.

Die Offlineanalyse wird erschwert durch grenzwertig verschleierte Starteinträge in der Registry und die von NTFS versteckte Treiberdatei.

Wer sich nun zwar für die Materie interessiert, aber kein System besitzt, dem er einen Live-Test des Loggers zumuten möchte, kann sich die grundsätzliche Funktion
auch anhand des folgenden Youtube-Videos verbildlichen:
(Part1)

Die anderen können einfach die Systemdatei in C:\Windows\System32\drivers kopieren, den Reg-Fix
ausführen und in einem Admin-Command-Prompt "fltmc load drvtriks" eingeben.



Grüsse und viel Spass - Microwave

P.S. Archiv-Kennwort ist "test-rootkit".

Dein ernst? Viruse zum selber machen in einem TROJANER BOARD posten xD ich Feier dich gerad

mich würde mal ein FRST Log eines infizierten Systems interessieren

@Microwave

Also ich war dann mal so frei.

Win 7 x64 Home Premium mit MSE, alle Updates installiert und somit voll aktuell
in einer VM unter VMWare WS 10.0.03
Das Ergebnis findest Du im Anhang.

Scheint noch ein bisschen buggy zu sein.
Vor allem das Errorhandling lässt doch etwas sehr zu wünschen übrig.


@burningice

FRST64 bringt folgendes (nur die Einträge, will hier nicht die gesamten Logs hochladen):

FRST.TXT
==================== Drivers (Whitelisted) ====================
U5 drvtriks; C:\Windows\System32\Drivers\drvtriks.sys [20168 2014-09-21] () [File not signed]
==================== One Month Created Files and Folders ========
2014-09-28 22:32 - 2014-09-21 20:01 - 00020168 _____ () C:\Windows\system32\Drivers\drvtriks.sys


ADDITION.TXT
CodeIntegrity Errors:
===================================
Date: 2014-09-28 22:37:08.326
Description: Windows konnte die Abbildintegrität der Datei "\Device\HarddiskVolume2\Windows\System32\drivers\drvtriks.sys" nicht überprüfen, weil der Dateihash nicht im System gefunden wurde. Möglicherweise wurde durch eine kürzlich durchgeführte Hardware- oder Softwareänderung eine falsch signierte oder beschädigte Datei oder eine Datei, bei der es sich um schädliche Software aus einer unbekannten Quelle handelt, installiert.

Date: 2014-09-28 22:37:08.266
Description: Windows konnte die Abbildintegrität der Datei "\Device\HarddiskVolume2\Windows\System32\drivers\drvtriks.sys" nicht überprüfen, weil der Dateihash nicht im System gefunden wurde. Möglicherweise wurde durch eine kürzlich durchgeführte Hardware- oder Softwareänderung eine falsch signierte oder beschädigte Datei oder eine Datei, bei der es sich um schädliche Software aus einer unbekannten Quelle handelt, installiert.

That's all folks

Gruss

Werner

Hi werner1958, ich nehme an, dass du den Testmodus nicht aktiviert hast/hattest?

Andernfalls würde "0x7A", als NTSTATUS gelesen, bedeuten, dass deine ntoskrnl.exe eine benötigte Funktion nicht enthält. Da ich hier und dort undokumentierte Funktionen benutze, könnte dies zumindest sein, wäre aber unwahrscheinlich, da es auf beiden Windows 7-Systemen läuft, auf denen ich es probiert habe.

Da ich natürlich Software geschrieben habe, bei der ich Microsoft auf die Anfrage eines Zertifikats dafür im Mondschein begegnen kann, muss das Laden testsignierter Treiber auf dem Testsystem dauerhaft ("bcdedit /set {current} testsigning YES") zugelassen werden.
Selbst wenn man einmalig beim Windows-Start F8 drückt, wird der Treiber beim nächsten Startversuch nicht mehr funktionieren, es ist also nötig, über bcdedit zu gehen.
Selbstverständlich ist ebenfalls klar, dass genau dieses dauerhafte Zulassen im FRST und anderen Tools sichtbar ist,
dafür gibt's noch keine Lösung.

Und was meinst du mit Fehlerhandling, was zu wünschen übrig lässt?

@burningice: Aktuelle Logfiles mit aktuellem FRST64 sind angehängt.


Grüsse - Microwave

P.S. Vergesst bitte nicht, eine Datei "LOGGING_ON" (ohne Erweiterung) in eurem C:\-Laufwerk zu erstellen. Andernfalls werden die Tastenanschläge nicht gespeichert.

Microwave schrieb:

Die anderen können einfach die Systemdatei in C:\Windows\System32\drivers kopieren, den Reg-Fix
ausführen und in einem Admin-Command-Prompt "fltmc load drvtriks" eingeben.

Das habe ich nach Deiner Vorgabe in Deinem Posting gemacht.
Von Testmodus steht da nichts oder habe ich was an den Augen?

Ferner postest Du:

Selbstverständlich ist ebenfalls klar...

Das ist falsch!
Richtig müsste der Satz lauten:
"Mir ist selbstverständlich auch sonst alles Mögliche klar (zumindest glaube ich es),
aber ich werde einen Teufel tun das verständlich für andere zu formulieren".

Passend dazu schreibst Du dann wahrhaftig noch dieses:

P.S. Vergesst bitte nicht, eine Datei "LOGGING_ON" (ohne Erweiterung) in eurem C:\-Laufwerk zu erstellen. Andernfalls werden die Tastenanschläge nicht gespeichert.

kopfschüttelnden Gruss

Werner

Hi TB-Community

Habe eine neue Version erstellt, die sich nicht mehr durch simples Computer-Abstürzen bzw. Ausschalten entfernen lässt.
Durch Verwendung weiterer (undokumentierter) Techniken gestaltet sich auch die Offline-Entfernung eher schwierig.
GMER scheint den Treiber zu finden, dies ist dessen Verwendung von Raw Registry File Access geschuldet (Aus der gemappten Registrierungsstruktur-Datei wird der Treibereintrag bei Systemstart gelöscht, in der Raw-Datei auf der Festplatte ist er aber noch vorhanden ==> GMER sieht den eigentlich gelöschten Eintrag als "hidden" an - nach einer Weile schreibt Windows die Änderungen in der gemappten Datei jedoch wieder in die rohe Datei zurück und GMER findet nichts mehr).
Unter Verzicht auf Verwendung von zufälligen Dateinamen könnte GMER daher ebenfalls nichts (Verdächtiges) finden.

Eine Entfernungsmöglichkeit könnte sein, vom Reparaturmodus aus die Registrierung offline zu laden, den Schlüssel "Services" zu exportieren, im entstehenden .reg-File die unerwünschten Einträge zu entfernen (etwa mittels notepad) und die veränderte Datei wieder auf die Registry anzuwenden. Dies legt den Treiber lahm aufgrund des fehlenden Starteintrags.
Online geht dies nicht, da sich der Treiber dagegen wehrt.

Eine andere Möglichkeit besteht darin, den Callback-Thread für Dateiänderungen anzuhalten (Process Hacker 2.33 kann dies, damit muss nun der richtige Systemthread gefunden und angehalten werden), und mit PC Hunter x64 die Treiberdatei aus dem "C:\$Extend\$RmMetadata\"-Verzeichnis zu entfernen. Aufgrund fehlenden Binaries läuft der Starteintrag nun ins Leere...

Als dritte Möglichkeit kann die Testsignierung vom Reparaturmodus aus ausgeschaltet werden durch direktes Entfernen des fehlerhaften Testsignierung-Eintrags " 16000049" mittels Regedit. Mit bcdedit lässt sich die Testsignierung nicht deaktivieren, egal ob off- oder online.


Lauffähig & getestet unter Windows 7 SP1, Windows 8.1, Windows 10 Build 9901.
Für korrekte Funktion muss Testsignierung einmalig zugelassen werden und das Betriebssystem muss sich auf C: befinden.

Viel Spass!


Grüsse und guten Rutsch - Microwave

Pwd: infected

Servus Microwave,

klär mich doch bitte auf... welchen Sinn/Zweck hat deine ganze Arbeit?

Hi MKDB,

Sinn und Zweck der ganzen Spielereien (als nächstes wäre btw etwas wie "Magenta Rootkit" in Ring3 in meiner Pipeline..) ist zu verstehen versuchen, wozu die andere Seite fähig ist, um mich z.B. besser dagegen wappnen zu können. Spass macht es zudem auch irgendwie, wenn ich wieder sehen kann, wie "klug" Windows wieder mal mit dieser und jener Situation umgeht, oder ich mittels einfachsten Tricks reihenweise renommierte Tools auf's Kreuz legen kann
Irgendwie kam ich dann wohl auf die Idee, das hier zu posten..vielleicht als Abwechslung zu immer nur Adware..
Dachte auch, für den Einen oder Anderen ist's vielleicht noch interessant, da ja nicht unbedingt alltäglich.

Grüsse - Microwave