DLL Injection verhindern



  • Hallo,
    kann ich mein Programm davor schützen, das eine DLL injectet wird? Wenn ja wie?



  • Ich denke nicht, dass diese Methode besonders schön ist aber du kannst eine DLL in jeden laufenden Prozess injecten, OpenProcess detouren und wenn das Programm deinen Prozess öffnen will einfach fehlschlagen lassen. 😋



  • das ist keine programmtechnische frage. lass das programm mit entsprechenden rechten laufen, dann kann ein prozess eines normalen users es nicht öffnen.



  • Holgerftw schrieb:

    Hallo,
    kann ich mein Programm davor schützen, das eine DLL injectet wird? Wenn ja wie?

    Einfach eine selbstgeschriebene DLL laden und in der DllMain "DLL_THREAD_ATTACH" auswerten.

    -> Wird schließlich immer dann durchlaufen wenn im Prozess ein Thread oder ein Remotethread gestartet wird. <-



  • desinjector schrieb:

    Wird schließlich immer dann durchlaufen wenn im Prozess ein Thread oder ein Remotethread gestartet wird. <-

    Es ist ja nicht so, daß man für das Injizieren von Fremdcode einen Thread erstellen müßte.



  • audacia schrieb:

    Es ist ja nicht so, daß man für das Injizieren von Fremdcode einen Thread erstellen müßte.

    Das hat der OT auch nicht gefragt. Und komm jetzt wieder nicht damit, daß eh alles zwecklos ist.



  • desinjector schrieb:

    audacia schrieb:

    Es ist ja nicht so, daß man für das Injizieren von Fremdcode einen Thread erstellen müßte.

    Das hat der OT auch nicht gefragt.

    Es ging, wenn ich das recht verstanden habe, um das Injizieren von DLLs. Und sobald man Code in einen fremden Prozeß injizieren kann, kann man auch DLLs laden.

    desinjector schrieb:

    Und komm jetzt wieder nicht damit, daß eh alles zwecklos ist.

    Ich kann mich nicht erinnern, mich hier zuvor als überzeugter Nihilist geäußert zu haben 😕



  • audacia schrieb:

    Ich kann mich nicht erinnern, mich hier zuvor als überzeugter Nihilist geäußert zu haben 😕

    Bitte vielmals um Entschuldigung. Beim "Antwort schreiben" ist mir die Kaffetasse umgekippt. Das hat meine Antwort negativ beeinflußt. 😞

    audacia schrieb:

    Und sobald man Code in einen fremden Prozeß injizieren kann, kann man auch DLLs laden.

    OK. Aber der Code muß auch ausgeführt werden. Via Remotethread wäre schlecht (-> eigene DLL).
    Also irgendwo in die EXE injizieren an einer Stelle, wo früher oder später der Thread "von selbst" vorbeikommt.
    Aber sämtliche geeigneten Stellen in der EXE sind dem Programmierer bekannt.
    Und eventuell gehookte Funktionen in "Standard-DLLs" lassen sich auch erkennen.



  • desinjector schrieb:

    Also irgendwo in die EXE injizieren an einer Stelle, wo früher oder später der Thread "von selbst" vorbeikommt.

    Gar nicht nötig. Man könnte einen laufenden Thread direkt entführen.



  • audacia schrieb:

    Man könnte einen laufenden Thread direkt entführen.

    Keine der besseren Ideen falls das Programm eh nur einen Thread hat. 🙂
    Und Get/SetThreadContext verursacht nur heftigste Synchronisierungsschwierigkeiten und sorgt letztendlich dafür, daß zwar eine DLL injectet wird, sie aber ohne Funktionalität ist. In etwa liegt sie dann nur im Speicher und "tut" nichts.



  • Nachtrag:
    Eine gut programmierte Multithread-Anwendung bemerkt immer wenn ein selbsterzeugter Thread irgendwie "verschwindet".



  • Aber nicht wenn ich den Thread, der das überwacht, auffresse 😋



  • desinjector schrieb:

    Und Get/SetThreadContext verursacht nur heftigste Synchronisierungsschwierigkeiten und sorgt letztendlich dafür, daß zwar eine DLL injectet wird, sie aber ohne Funktionalität ist. In etwa liegt sie dann nur im Speicher und "tut" nichts.

    Das reicht aber vollauf, um etwa WinAPI-Aufrufe zu hooken.

    desinjector schrieb:

    Eine gut programmierte Multithread-Anwendung bemerkt immer wenn ein selbsterzeugter Thread irgendwie "verschwindet".

    Du meinst, sie stürzt ab oder bleibt hängen? 🤡

    Nein, um das Verschwindenlassen eines Threads geht es ja auch nicht, eher um das kurzfristige Entführen zwecks Aufrufs von LoadLibrary(). Oben vorgeschlagenem Thread-Detektionsansatz könnte man dann begegnen, indem man vor der Erstellung eines Threads DisableThreadLibraryCalls() aufruft, dann mittels IPC die injizierende Anwendung dazu bringt, mit CreateRemoteThread() einen Thread zu erstellen, so daß es der attackierten Anwendung nicht hilft, CreateThread() zu hooken.



  • audacia|off schrieb:

    indem man vor der Erstellung eines Threads DisableThreadLibraryCalls() aufruft, dann mittels IPC die injizierende Anwendung dazu bringt, mit CreateRemoteThread() einen Thread zu erstellen, so daß es der attackierten Anwendung nicht hilft, CreateThread() zu hooken

    Ach nein, dann hätte die attackierte Anwendung auch gleich DisableThreadLibraryCalls() abfangen können 🙄

    Bleibt also das Hooken von WinAPI-Aufrufen als Anwendungsmöglichkeit.



  • Böser Bube schrieb:

    Aber nicht wenn ich den Thread, der das überwacht, auffresse 😋

    Der Witz ist ja grade, daß das alles ohne "Guard-Thread" funktioniert. :p

    audacia|off schrieb:

    Oben vorgeschlagenem Thread-Detektionsansatz könnte man dann begegnen, indem man vor der Erstellung eines Threads DisableThreadLibraryCalls() aufruft, dann mittels IPC die injizierende Anwendung dazu bringt, mit CreateRemoteThread() einen Thread zu erstellen, so daß es der attackierten Anwendung nicht hilft, CreateThread() zu hooken.

    Mal abgesehen davon, wann und wo das aufgerufen werden soll, kennt eine Anwendung zu jeder Zeit die Anzahl ihrer Threads.

    audacia|off schrieb:

    Bleibt also das Hooken von WinAPI-Aufrufen als Anwendungsmöglichkeit.

    Dann greift alles vorhin schon gesagte. Gehookte WinAPI-Aufrufe zu erkennen gehört bereits zum Standardrepertoire.



  • Gehookte WinAPI-Aufrufe zu erkennen gehört bereits zum Standardrepertoire.

    Und wie geht das konkret?



  • Zum Beispiel durch Vergleichen der ersten "paar" Bytes der API-Funktion mit denen in der entsprechenden DLL auf der Festplatte.



  • Und wie soll dieser Vergleich stattfinden, wenn ich CreateFile und Co. alles gehooked habe und solche Versuche gleich abfange?



  • Sämtliche Funktionen gehookt? Ein etwas unrealistisches Szenario.

    -> Brauche ich CreateFile und Co. um an eine Datei auf der Festplatte heranzukommen?



  • ja


Anmelden zum Antworten