API-Hooking greift nicht bei "Benutzer wechseln"

[peanut]

Hallo,

ich möchte den Aufruf an die folgenden API-Funktionen überwachen

CreateProcess
CreateProcessA
CreateProcessW

CreateProcessAsUser
CreateProcessAsUserA
CreateProcessAsUserW

CreateProcessWithLogonW

LoadLibrary
LoadLibraryA
LoadLibraryW
LoadLibraryEx
LoadLibraryExA
LoadLibraryExW
GetProcAddress

CreateRemoteThread

Ich habe das mittels einer DLL gelöst, die an jeden gestarteten Prozess gehängt wird. Hierfür habe ich einen Dienst installiert, der diese beim Hochfahren an jeden Prozess "klebt". Die DLL sorgt dann entsprechend dafür, dass sie auch in alle weiteren Prozesse geladen wird, die mit diesen ersten Prozessen erzeugt werden. Das funktioniert auch ganz gut - leider nur, wenn genau ein Benutzer aktiv ist! Sobald man unter Windows XP auf "Benutzer wechseln" geht, wird die DLL nicht an die Prozesse gehängt, die im Zugang des zweiten Benutzers ausgeführt werden, obwohl in winlogon.exe etc. auch meine DLL steckt, die eigentlich dafür sorgen soll, dass sie in jeden neuen Prozess geladen wird.

Meldet man sich dagegen ab, ohne "Benutzer wechseln" und meldet sich dann mit einem anderen Benutzer wieder an, wird die DLL wie gewünscht angehängt. Gleiches gilt für "Ausführen als", auch das funktioniert anstandslos.

Was geht hier schief? Verwendet Windows versteckte Funktionen, so dass mein hooking hier nicht greift?

Gruß peanut.

[Olli]

Zitat von peanut:

CreateProcess
CreateProcessA
CreateProcessW

CreateProcessAsUser
CreateProcessAsUserA
CreateProcessAsUserW

CreateProcessWithLogonW

LoadLibrary
LoadLibraryA
LoadLibraryW
LoadLibraryEx
LoadLibraryExA
LoadLibraryExW
GetProcAddress

CreateRemoteThread

Soso ... soll ich mal aufzählen, welche bösen Dinge man mit genau dieser Geschichte machen kann? ... dann wird hier gleich wegen Malware-Gefahr zugemacht.

Zitat von peanut:

Ich habe das mittels einer DLL gelöst, die an jeden gestarteten Prozess gehängt wird. Hierfür habe ich einen Dienst installiert, der diese beim Hochfahren an jeden Prozess "klebt". Die DLL sorgt dann entsprechend dafür, dass sie auch in alle weiteren Prozesse geladen wird, die mit diesen ersten Prozessen erzeugt werden. Das funktioniert auch ganz gut - leider nur, wenn genau ein Benutzer aktiv ist! Sobald man unter Windows XP auf "Benutzer wechseln" geht, wird die DLL nicht an die Prozesse gehängt, die im Zugang des zweiten Benutzers ausgeführt werden, obwohl in winlogon.exe etc. auch meine DLL steckt, die eigentlich dafür sorgen soll, dass sie in jeden neuen Prozess geladen wird.

Also du solltest definitiv deine Methoden überdenken. Sich in jeden Prozess einzuklinken ist hirnrissig. Sich in Winlogon einzuklinken würde ich noch schlimmer bewerten, aber mir fällt kein halbwegs diplomatisches Wort ein, also laß ich es.
Eine DLL führt Code immer im Kontext des Prozesses aus - eine DLL selbst besteht nur aus Daten und totem Code. Erst in einem Prozeß (noch exakter: in einem Thread!) wird diesem Code Leben eingehaucht. Wenn nun aber dein Code verursacht, daß Winlogon abschmiert, regt sich der Session-Manager (SMSS.EXE) darüber so auf, daß er nen Herzkasper kriegt und dem System sagt: mach blau, mir hat jemand meinen Freund abgemurkst. Und das System macht dann auch blau - mit nem Bluescreen.

Zitat von peanut:

Meldet man sich dagegen ab, ohne "Benutzer wechseln" und meldet sich dann mit einem anderen Benutzer wieder an, wird die DLL wie gewünscht angehängt. Gleiches gilt für "Ausführen als", auch das funktioniert anstandslos.

Was geht hier schief? Verwendet Windows versteckte Funktionen, so dass mein hooking hier nicht greift?

Windows verwendet nur mehrere WindowStations - mehr nicht. Wenn du rauskriegst, wie MS exakt die TS implementiert, kannst du vielleicht ein Vermögen machen ...

Such mal nach AppInitDlls (siehe auch AutoRuns Sysinternals).

[peanut]

Hallo Olli,

Zitat:

Soso ... soll ich mal aufzählen, welche bösen Dinge man mit genau dieser Geschichte machen kann? ... dann wird hier gleich wegen Malware-Gefahr zugemacht.

ich weiß, was man damit anstellen kann... Darum geht es mir aber gar nicht, das habe ich alles schon getestet. Außerdem wird diese Technik ohnehin von vielen malware-scannern erkannt. Zeitverschwendung, diese Technik für malware weiter zu beackern - sind andere Verfahren viel interessanter.

Ich wollte eigentlich nur erkennen, wer nen Prozess startet oder ne DLL lädt. Das bringt aber nicht viel, weil dann wieder irgend jemand mit dem Totschlagargument Kerneldriver oder selbst programmierter API ankommt und sagt: Du DAU, ich erstellt einen Prozess und Du merkst es gar nicht... Bis jetzt ist mir aber noch nichts besseres eingefallen Auf der anderen Seite muss man aber Adminrechte besitzen um nen Kerneldriver zu installieren, was ich bei meiner Annahme "unter der mein Rechner mit dem fertigen Prog betrieben werden soll" aber nicht voraussetze, so dass allenfalls Variante 2 zum Zuge kommt - und Adminrechte höchstens über nen Bug im OS erlangt werden können. Aber dieses Risiko muss man tragen (man kann auch überfahren werden, wenn man anständig den Zebrastreifen benutzt).

Zitat:

Also du solltest definitiv deine Methoden überdenken. Sich in jeden Prozess einzuklinken ist hirnrissig.Sich in Winlogon einzuklinken würde ich noch schlimmer bewerten, aber mir fällt kein halbwegs diplomatisches Wort ein, also laß ich es.

Ok - nur Übung macht den Meister und jeder fängt mal klein an.
Vielleicht sollte ich wirklich nicht jeden Prozess mit meiner DLL beglücken. Was die erwähnten Bluescreens betrifft: Da hatte ich schon das Vergnügen mit - das ist was ich meinte, das muss man probiert haben und dann weiß mans.

Zitat:

Eine DLL führt Code immer im Kontext des Prozesses aus - eine DLL selbst besteht nur aus Daten und totem Code.

Das ist mir klar, deswegen verändert meine DLL in ihrer main() auch die entsprechenden Stellen, wie sich das fürs API redirecting gehört.

Zitat:

Such mal nach AppInitDlls (siehe auch AutoRuns Sysinternals).

AppInitDlls habe ich schon probiert und mit AutoRuns hatte ich auch schon expermimentiert. Ich habe gehofft, dass es auch anders geht. Nach diesem Post komme ich mir ohnehin vor wie der letzte Hirni , vielleicht sollte ich das ganze Vorhaben stecken...

Gruß

peanut.

[Olli]

Zitat von peanut:

Ich wollte eigentlich nur erkennen, wer nen Prozess startet oder ne DLL lädt. Das bringt aber nicht viel, weil dann wieder irgend jemand mit dem Totschlagargument Kerneldriver oder selbst programmierter API ankommt und sagt: Du DAU, ich erstellt einen Prozess und Du merkst es gar nicht... Bis jetzt ist mir aber noch nichts besseres eingefallen Auf der anderen Seite muss man aber Adminrechte besitzen um nen Kerneldriver zu installieren, was ich bei meiner Annahme "unter der mein Rechner mit dem fertigen Prog betrieben werden soll" aber nicht voraussetze, so dass allenfalls Variante 2 zum Zuge kommt - und Adminrechte höchstens über nen Bug im OS erlangt werden können. Aber dieses Risiko muss man tragen (man kann auch überfahren werden, wenn man anständig den Zebrastreifen benutzt).

NtCreateSection ist dein Freund. Diese API bekommt alles in Sachen DLLs *und* Prozesse laden mit. Mußt nur die Flags auswerten. Diese API befindet sich in NTDLL.

Zitat von peanut:

Ok - nur Übung macht den Meister und jeder fängt mal klein an.
Vielleicht sollte ich wirklich nicht jeden Prozess mit meiner DLL beglücken. Was die erwähnten Bluescreens betrifft: Da hatte ich schon das Vergnügen mit - das ist was ich meinte, das muss man probiert haben und dann weiß mans.

Gut, solange du es nur bei dir probierst

Es gibt Spyware-Firmen, die das auch bei Ihren Kunden versuchen. Und dann gibt es noch andere unschöne Sachen, auf die ich nicht eingehen darf

Zitat von peanut:

AppInitDlls habe ich schon probiert und mit AutoRuns hatte ich auch schon expermimentiert. Ich habe gehofft, dass es auch anders geht. Nach diesem Post komme ich mir ohnehin vor wie der letzte Hirni , vielleicht sollte ich das ganze Vorhaben stecken...

Locker bleiben. Man ist doch kein "Hirni", nur weil was nicht auf Anhieb klappt. Alle fangen mal klein an

AppInitDlls sollte zumindest auch innerhalb der jeweiligen Terminalsessions funktionieren. Dürfte dir doch sehr entgegenkommen, oder? Ich nehme an, daß dein Service "interaktiv" läuft? Dann ist das was du beobachtest nämlich nichts als die normale Trennung dank WindowStations. Ach ja, interaktive Services sind out ...

[peanut]

Zitat von Olli:

NtCreateSection ist dein Freund. Diese API bekommt alles in Sachen DLLs *und* Prozesse laden mit. Mußt nur die Flags auswerten. Diese API befindet sich in NTDLL.

Ich habe gefunden, was Du gemeint hast Damit lässt sich das realisieren, was ich gerne möchte... DANKE DANKE DANKE!!!

Zitat von Olli:

AppInitDlls sollte zumindest auch innerhalb der jeweiligen Terminalsessions funktionieren. Dürfte dir doch sehr entgegenkommen, oder? Ich nehme an, daß dein Service "interaktiv" läuft? Dann ist das was du beobachtest nämlich nichts als die normale Trennung dank WindowStations. Ach ja, interaktive Services sind out ...

Ja, der Dienst ist "interaktiv" - das sollte man laut MSDN unterlassen Ich will für Meldungen und andere Dinge ein normales Programm im jeweiligen Benutzerzugang starten und mit dem Dienst über IPC kommunizieren. Ich hatte aber mit den anderen Dingen so zu kämpfen, dass ich das auf die lange Bank geschoben habe - wird aber noch verbessert.

Viele Grüße

peanut.

[Olli]

Zitat von peanut:

Ja, der Dienst ist "interaktiv" - das sollte man laut MSDN unterlassen I

Genau. Vista soll es wohl sogar komplett unterbinden. Da würde es also ohnehin nicht funktionieren