API von Reg.exe

[Metal_Snake2]

Hallo,

ich bin gerade dabei das Programm "Reg.exe" welches Standartmäßig (zumindes in XP) dabei ist zu analysieren.
Es ist ein Kommandozeilen- basierendes 32-bit programm. Habe es schon mit Regmon, Procmon analysiert jedoch bekomme ich einach
nicht heraus wie es das Programm schaft Einträge anzuseigen die z.B. Regedit/Regedit32 nicht findet. Reg.exe scheint auch nicht dei Native- API zu benutzen. Bin gerade verwirrt, kann es sein das dass Programm mit NTSetInformationKey einpaar besondere flags setzt vor dem lesen der Schlüssel Werte? Danke für lesen, ich hoff echt das mir jemand weiter helfen kann.

[Dezipaitor]

Was willst du denn machen?

[Olli]

Wie wäre es mit der gleichen Methode die auch bei Dateien funktioniert? Backup/Restore-Privileg um Dateien zu listen die man ansonsten nicht sehen kann? Immerhin gibt es Registry-APIs um ähnliches Backups von Schlüsseln und Hives anzufertigen, warum soll das hier nicht ähnlich funktionieren?

Die entsprechenden Funktionen werden auch importiert:

- AdjustTokenPrivileges
- LookupPrivilegeValueW
- OpenProcessToken

[Olli]

Es gibt einen Aufruf von AdjustTokenPrivileges in der ganzen Binärdatei (habe die 32bit-Version von Vista SP1) und die Funktion welche den Aufruf enthält - welche ich mal spontan SetPrivilegeByName genannt habe - nur viermal aufgerufen. Alle vier Aufrufe bestätigen exakt meine oben gemachte Annahme.

Code:

.text:010079F4 078                 push    2               ; int
.text:010079F6 07C                 push    offset Name     ; "SeBackupPrivilege"
.text:010079FB 080                 push    [ebp+lpSystemName] ; lpSystemName
.text:010079FE 084                 call    SetPrivilegeByName

Code:

.text:01007C75 074                 push    2               ; int
.text:01007C77 078                 push    offset aSerestoreprivilege ; "SeRestorePrivilege"
.text:01007C7C 07C                 push    [ebp+lpSystemName] ; lpSystemName
.text:01007C7F 080                 call    SetPrivilegeByName

Code:

.text:01007DDE 070                 push    2               ; int
.text:01007DE0 074                 push    offset aSerestoreprivilege ; "SeRestorePrivilege"
.text:01007DE5 078                 push    [ebp+lpSystemName] ; lpSystemName
.text:01007DE8 07C                 call    SetPrivilegeByName

Code:

.text:01007F37 070                 push    2               ; int
.text:01007F39 074                 push    offset aSerestoreprivilege ; "SeRestorePrivilege"
.text:01007F3E 078                 push    [ebp+lpSystemName] ; lpSystemName
.text:01007F41 07C                 call    SetPrivilegeByName

[Metal_Snake2]

Erstmal danke für die das Antworten!

Also ich glaub ich habe mich nicht genau genug ausgedrückt, deswegen hast du mich @Olli eventuell falsch verstanden.
Ich möchte keine Keys Laden, Speichern, Importieren oder Exportieren.

Ich mache es mal jetzt so konkret wie es nur sein kann weil ich echt am verzweifeln bin wie das funktioniert:

Also ich installiere mal aus spass den "Adramax Keylogger", der fügt einen Autostart eintrag in HKLM\...\Run hinzu.
Über dem Usermode per DLL- Injektion schaft er es indem er wie ich denke ziemlich viele Registry- WinAPIs hookt, den Autostart
Eintag für alle dei Anwendungen welche mit der DLL infiziert sind zu verstecken.

Mich wundert nun folgendes: Autorun, msconfig oder gar registrie Editoren welche auf dei Native API (NtQueryKey und co) aufsetzen
finden diesen Eintrag nicht! Wie schaft es das dieses kleinen prog "reg.exe" (ist meistens in System Verzeichnis)
über den Komandozeilenbefehl "Reg Query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run " trotzdem diesen versteckten Schlüssel Wert zu finden. Was natürlich sein könnte ist das es der Keylogger einfach nicht schaft seine DLL in den Adressraum von Reg.exe zu injezieren da es nur ein Komandozeilenbasierendes prog ist (ohne gui). Oder verwender reg.exe einpaar Tricks?

Edit: Ich hab gerad mir ProcMon nachgeschaut und es werden wirklich nicht die Dll in reg.exe injeziert.
Hmm und das ist jetzt wohl der vorteil von Reg.exe das es keine GUI...also Fenster hat?

[Olli]

Zitat:

Zitat von Metal_Snake2

Erstmal danke für die das Antworten!

Also ich glaub ich habe mich nicht genau genug ausgedrückt, deswegen hast du mich @Olli eventuell falsch verstanden.
Ich möchte keine Keys Laden, Speichern, Importieren oder Exportieren.

Es klang so, als wölltest du wissen, wieso reg.exe etwas sehen kann, was einige andere Programme nicht sehen. Das Backup-Privileg ermöglicht exakt das.

Zitat:

Zitat von Metal_Snake2

Mich wundert nun folgendes: Autorun, msconfig oder gar registrie Editoren welche auf dei Native API (NtQueryKey und co) aufsetzen
finden diesen Eintrag nicht! Wie schaft es das dieses kleinen prog "reg.exe" (ist meistens in System Verzeichnis)
über den Komandozeilenbefehl "Reg Query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run " trotzdem diesen versteckten Schlüssel Wert zu finden. Was natürlich sein könnte ist das es der Keylogger einfach nicht schaft seine DLL in den Adressraum von Reg.exe zu injezieren da es nur ein Komandozeilenbasierendes prog ist (ohne gui). Oder verwender reg.exe einpaar Tricks?

Wie startest du denn reg.exe? Von der Kommandozeile aus? Wenn ja, versuche mal folgendes. Schreibe ein kleines Programm und starte von dem aus via ShellExecute, ShellExecuteEx und WinExec jeweils einmal reg.exe und schau dir die Ausgabe an. Ein Verdacht wäre, daß der Keylogger nicht alle entsprechenden APIs hookt oder gar nur den Hook auf ShellExecute(Ex) registriert hat.

Zitat:

Zitat von Metal_Snake2

Edit: Ich hab gerad mir ProcMon nachgeschaut und es werden wirklich nicht die Dll in reg.exe injeziert.
Hmm und das ist jetzt wohl der vorteil von Reg.exe das es keine GUI...also Fenster hat?

Das wiederum könnte darauf hinweisen, daß das Hooking über Fensterhooks initialisiert wird. Daß also Fensterhooks die Methode sind um anfangs in den Adreßraum des Prozesses zu kommen in dem manipuliert werden soll.

[Metal_Snake2]

Also es liegt wirklich daran das die DLL nicht in Reg.exe indiziert werden konnte.

Also ich gehe jetzt mal einen schritt weiter und frage mich nun folgedes.

Wie schaft es das Autostart Manager Programm OSAM(Hier zu kriegen) ohne einen Kernelmode Treiber registry Einträge zu finden welche versteckt sind.

Ich mein ich habe mal zu testzwecken den "Elite Keylogger" runtergeladen und installiert, er verwendet einen "Low-Level" kernelmode- Treiber. Ok es werden einpaar SSDT- Funktionen gehookt und auch mehr, somit dürfte ja ein Programm welches nur im
Usermode rumspielt wie OSAM eigentlich keine chance haben an die Schlüssel ranzukommen. Aber irgendwie schaft es das Programm
die Einträge zu finden.

Ich hab mir folgendes überlegt:

Kann es sein das OSAM direkt von den Registry Hives auslies? Oder OSAM einen trick verwendet und ZW* Systemaufrufe vom Usermode ausführt, indem er die Methoden aus der NtDll verwendet, macht aber keinen unterschied zu NT* aufrufen.

Hab mich schon öfters gefragt wie das prog sowas schaft, ich hoffe Olli kannst mir weiterhelfen.

Danke

[Olli]

Zitat:

Zitat von Metal_Snake2

Ich mein ich habe mal zu testzwecken den "Elite Keylogger" runtergeladen und installiert, er verwendet einen "Low-Level" kernelmode- Treiber. Ok es werden einpaar SSDT- Funktionen gehookt und auch mehr, somit dürfte ja ein Programm welches nur im Usermode rumspielt wie OSAM eigentlich keine chance haben an die Schlüssel ranzukommen. Aber irgendwie schaft es das Programm die Einträge zu finden.

Da muesste man sich den Treiber und das Programm welches schafft ihn zu umgehen angucken.

Zitat:

Zitat von Metal_Snake2

Kann es sein das OSAM direkt von den Registry Hives auslies?

Unwahrscheinlich. Wenn ich mich recht entsinne, geht das nur unter ganz bestimmten Umstaenden.

Zitat:

Zitat von Metal_Snake2

Oder OSAM einen trick verwendet und ZW* Systemaufrufe vom Usermode ausführt, indem er die Methoden aus der NtDll verwendet, macht aber keinen unterschied zu NT* aufrufen.

Zw* == Nt* im Usermode. Und da alle Aufrufe durch das Callgate in den Kernelmode fuehren, sollte SSDT-Hooking hier effektiv sein.

[richard_boderich]

@Metal Snake

Probier mal ob mein Testprogramm die Autostarteinträge findet. Würde mich mal interessieren. Von Adramax hab ich nur ein Keylogger light getestet und der wird gefunden. Einfach die Exe starten und auf Scan Komplett drücken.

[Metal_Snake2]

@richard_boderich

ne dein Testprogramm findet nix, wie den auch...in dem Adressraum deines Progs. werden die DLLs von Adramax injeziert, also all deine Registry Aufrufe sind gehookt. Ich entnehme aus dem Registry-Pfad das du scheinbar mit der Nativen API arbeitest, aber auch die Funktionen hookt die DLL.

@Olli

Ich hab dem Autor vom OSAM geschrieben aber er antwortet nicht. Naja warum jetzt reg.exe die versteckten Einträge findet ist klar
aber wie es OSAM schaft ist mir schleierhaft.

Hat jemand ne idee?

[Olli]

Zitat:

Zitat von Metal_Snake2

@Olli

Ich hab dem Autor vom OSAM geschrieben aber er antwortet nicht. Naja warum jetzt reg.exe die versteckten Einträge findet ist klar
aber wie es OSAM schaft ist mir schleierhaft.

Hat jemand ne idee?

Warum kann es nicht der gleiche Grund sein?

Das einzige was ich bisher nicht begreife ist, dass eine injezierte DLL so wichtig sein soll, wenn doch der SSDT-Hook viel besser ist und man ohne eigenen Treiber nichts dagegen machen kann ...

Uebrigens koennte das OSAM-Programm ja schon nen Treiber haben. Huckepack, so wie ich es bspw. in meinem Hooktutorial erklaert habe.

[richard_boderich]

@Olli

Die Frage ist, was macht man, wenn das Rootkit via SSDT alle ZW Key Funktionen hookt. Dann kommt man doch um einen Driver gar nicht herum und dann ist doch auch die Frage welcher zuerst geladen wird? Der von der Malware oder der Eigene.
Außerdem müsste es doch auch Maßnahmen gegen DLL Injection geben oder etwa nicht?

PS:
Kann man sich dieses Hooktutorial irgendwo runterladen?

mfG Richard

@Metall Snake

Wie wäre es denn die Registry binär zu Öffnen und die Funktionen um auf Keys zu zugreifen selbst zu implementieren?

[Olli]

Zitat:

Zitat von richard_boderich

@Olli

Die Frage ist, was macht man, wenn das Rootkit via SSDT alle ZW Key Funktionen hookt. Dann kommt man doch um einen Driver gar nicht herum und dann ist doch auch die Frage welcher zuerst geladen wird? Der von der Malware oder der Eigene.
Außerdem müsste es doch auch Maßnahmen gegen DLL Injection geben oder etwa nicht?

Syscalls passieren ueblicherweise nur aus dem Usermode heraus. Solange kein Hotpatching innerhalb der eigentlichen Funktion sondern nur in der SSDT stattfinden ist es nicht allzu kritisch. Allerdings koennte ein neu geladener Treiber sofort gepatcht werden. Das waere aber aeusserst komplex.

Zitat:

Zitat von richard_boderich

Kann man sich dieses Hooktutorial irgendwo runterladen?

Hook tutorial Assarbad

Zitat:

Zitat von richard_boderich

Wie wäre es denn die Registry binär zu Öffnen und die Funktionen um auf Keys zu zugreifen selbst zu implementieren?

Schwer, weil die Hives normalerweise exklusiv geoeffnet werden. Wie man vom RootkitRevealer weiss, geht es - aber's ist schwer.

[Metal_Snake2]

hmm also das ist doch mal ne idee die hives binär einzulesen. Hat jemand nen link oder ne idee davon weil dan kann ich mir all
die Kernelmode spielereien sparen, die mit Delphi eh nicht zu machen sind ich von c/c++ und ddk oder wdk und co keine
ahnung habe.

[Olli]

Zitat:

Zitat von Metal_Snake2

hmm also das ist doch mal ne idee die hives binär einzulesen. Hat jemand nen link oder ne idee davon weil dan kann ich mir all
die Kernelmode spielereien sparen, die mit Delphi eh nicht zu machen sind ich von c/c++ und ddk oder wdk und co keine
ahnung habe.

Dreimal darfste raten wie der RootkitRevealer an die Hives im laufenden System rankommt ... :mrgreen: ... obwohl VSS koennte es eventuell auch ermoeglichen. Allerdings ggf. nicht mit einem Abbild der echten Registry in dem Moment sondern eben einem aelteren ...

[richard_boderich]

@Olli

Danke erstmal für die Infos. Noch zwei Fragen

1. Ist es möglich ein Reload der NTDLL durchzuführen bzw. eine 2 Instanz zu Laden und diese anstatt der gehookten zu verwenden?

2. Könntest du nochwas zu möglichen Maßnahmen gegen DLL Injection ausführen?

mfG Richard

[Olli]

Zitat:

Zitat von richard_boderich

1. Ist es möglich ein Reload der NTDLL durchzuführen bzw. eine 2 Instanz zu Laden und diese anstatt der gehookten zu verwenden?

Ich meine es sollte gehen, bin aber bei NTDLL nicht 100% sicher. Frag mal lieber brechi (Forenbenutzer hier).

Allerdings hilft das logischerweise nix gegen SSDT-Hooks, die zuvor ja im Gespraech waren.

Zitat:

Zitat von richard_boderich

2. Könntest du nochwas zu möglichen Maßnahmen gegen DLL Injection ausführen?

Auch da waere brechi sicher der bessere Ansprechpartner.

[Dezipaitor]

Und wie sieht es nun aus?

[Die Muhkuh]

Die werden sich schon melden, wenn sich was tut. Brauchst jetzt nicht jeden Thread aus der Senke holen :roll:

[DeddyH]

Ist ja schlimmer als taktaky mit seinen Ressourcen damals.

[Dezipaitor]

Nein, weil sie es vergessen und dann es einfach lassen. Mich interessiert es, ob es weitergeholfen hat. Dann mache ich mir nämlich einen Link darauf.

[Metal_Snake2]

also ich hab den autor von OSAM ne mail geschrieben und er hat mir folgende antwort geschrieben:

[...]
We using our technology of direct parsing of system registry, without
using any OS functions. [...]

also lesen sie die registry direkt ein ohne nen Treiber, komisch frag mich wie das gehen soll den die hives werden doch
exlusiv geöffnet.


Jedenfalls ist da wirklich was dran, den auch tools wie "SysInspector" arbeiten nur im Usermode und finden registry Einträge welche übern Kernelmode Rootkit- Treiber versteckt wurden.

Naja mein eigentliches bestrimmen war einfach halt herauszufinden wie diese Progs arbeiten.

Das mit SSDT- Hooks und co ist doch blöd, funzt das überhaupt mit Vista? Ich sollte villeicht mal echt versuchen
die Registry werte aus dem Kernel direkt auszulesen.

[Olli]

Zitat:

Zitat von Metal_Snake2

also ich hab den autor von OSAM ne mail geschrieben und er hat mir folgende antwort geschrieben:

[...]
We using our technology of direct parsing of system registry, without
using any OS functions. [...]

also lesen sie die registry direkt ein ohne nen Treiber, komisch frag mich wie das gehen soll den die hives werden doch
exlusiv geöffnet.

Also erstens wird es wohl kaum ohne OS-Funktionen (die umgehen einfach die Registry-APIs) gehen ... und zweitens, wer sagt dir denn, daß die keinen Treiber einsetzen? Den kann man doch Huckepack an die EXE hängen und bei Bedarf installieren.

Zitat:

Zitat von Metal_Snake2

Das mit SSDT- Hooks und co ist doch blöd, funzt das überhaupt mit Vista? Ich sollte villeicht mal echt versuchen die Registry werte aus dem Kernel direkt auszulesen.

Ja, es funktioniert bei 32bit Vista problemlos und bei 64bit Vista kann man es (wg. PatchGuard) mit ein wenig Arbeit auch erreichen. Microsoft bietet aber seit SP1 unter NDA für ISVs eine API an um sowas wie Hooks dokumentiert zu erlauben. Aber eben unter NDA.

[richard_boderich]

@Metal Snake

Zitat:
We using our technology of direct parsing of system registry.
Zitat Ende

Diese Aussage bedeutet nicht das sie keinen Treiber benutzten, sondern das sie die Registry Binär öffnen und die einzelnen
Keys parsen. (also die Strings suchen)

Zitat:
Ich sollte villeicht mal echt versuchen die Registry werte aus dem Kernel direkt auszulesen.
Zitat Ende

Aus dem Kernel direkt kannst du nix auslesen. Du kannst entweder die entsprechenden APis im Usermode nutzen (dort sind es die NT-Funktionen, also die Native APis die auf dem niedrigsten Level zugreifen) oder im Kernelmode die ZW-Funktionen. (das geht nur via Treiber)
Und damit siehts in Delphi mau aus.

mfG Richard

//Edit kannst du mir mal bitte per PN das/den Rootkit/keylogger schicken mit dem du testest?

[Metal_Snake2]

Also es gibt hier ein open source Dos Registry Viewer klack.
Es wurde in Pascal geschrieben und wird mit Open Pascal kompiliert.

Könnte ich nun die hives welche in "system32\config" sind so nun Binär auslesen?
Oder hat jemand eine Delphi fähige version?