DLL Injection verhindern



  • 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



  • LoadLibraryEx mit LOAD_LIBRARY_AS_DATAFILE ?

    Konsequenterweise müßte der Hook dann sämtliche Sprungadressen entsprechend anpassen. 🙂



  • LoadLibrary ruft doch auch nur NtCreateFile auf 😉



  • Bei mir aber NTDLL.LdrLoadDll.

    Btw. sollen etwa (zur Sicherheit) sämtliche NTDLL-Funktionen gehookt werden?
    Und soll auch noch so ein fetter Hook nicht auffallen?



  • wieso soll der auffallen? und wieso sämtliche funktionen?ich sagte doch CreateFile und ggf. 2,3 andere reichen vollkommen. und am besten macht man das mit nem kleinen treiber der einfach die einträge in der KeServiceDescriptorTable ändert. was is daran fett? 🙂



  • MisterX schrieb:

    ich sagte doch CreateFile und ggf. 2,3 andere reichen vollkommen.

    Vorausgesetzt der Programmierer hält sich auch dran.

    MisterX schrieb:

    und am besten macht man das mit nem kleinen treiber der einfach die einträge in der KeServiceDescriptorTable ändert.

    Ist ja unter WIN64 auch kein Problem. 🙂


  • Mod

    ... selbst unter 32bit auf Vista oder Windows 7 wirst Du etwas Probleme haben, diesen Treiber in Betrieb zu nehmen!



  • desinjector schrieb:

    MisterX schrieb:

    ich sagte doch CreateFile und ggf. 2,3 andere reichen vollkommen.

    Vorausgesetzt der Programmierer hält sich auch dran.

    wie? alles geht über NtCreateFile, da kommt er nicht drum herum 😕


Anmelden zum Antworten