48046
Dec 28, 2008, updated at Jan 07, 2009 (UTC)
6405
10
0
injected Prozess ermittlen
Hallo !
Da ja mittlerweile das Netz immer mehr mit Trojanern und ähnlichem überschwemmt wird, würde ich gerne wissen, wie man einen Trojaner nicht nur anhand eines evtl. laufenden Prozesses ermitteln kann, sondern auch deren injectete Datei herausfindet.
Beispiel:
- Alle aktuellen Browser-Fenster sind geschlossen.
- Datei xy.exe (ein Trojaner) injected sich in den aktuellen Browserprozess.
- Dieser laufende Browserprozess ist dann mittels Kontrolle diverser ProzessMonitore nachweisbar.
Aber die eigentliche Trojanerdatei xy.exe die sich irgendwo im Betriebssystem eingenistet hat, läßt sich mit dieser
Methode nicht lokalisieren. Eine Möglichkeit wäre noch mit diversen Tools die StartUp-Einträge durchzugehen, ActiveX etc.. Ebenso kann man zwar auch z.B, per netstat oder noch komfortabler mit TCPView die Ein- und ausgehenden Verbindungen abchecken. Jedoch keine der genannten Methoden läßt mir Rückschlüße auf den wirklichen Dateinamen des Trojaners!
Daher, gibt es nicht ein Tool, welches mir anzeigt was für eine Datei sich in den Browserprozess injected hat? - Bzw. welche Datei überhaupt diesen laufenden Browserprozess aufgerufen hat?
P.S. Natürlich alles unter Berücksichtigung eines aktuell laufenden AntiViren-Programms. Trotzdem kann es ja sein, dass die Signatur des Trojaners neu ist und somit noch unbekannt für das jeweilige AntiVirenTool. - Also meine Anfrage zielt darauf ab, noch nachträglich einem
eingeschleusten Trojaner auf die Spur; respektive auf die Ursprungsdatei zu kommen...
Gruß
ELMI
Da ja mittlerweile das Netz immer mehr mit Trojanern und ähnlichem überschwemmt wird, würde ich gerne wissen, wie man einen Trojaner nicht nur anhand eines evtl. laufenden Prozesses ermitteln kann, sondern auch deren injectete Datei herausfindet.
Beispiel:
- Alle aktuellen Browser-Fenster sind geschlossen.
- Datei xy.exe (ein Trojaner) injected sich in den aktuellen Browserprozess.
- Dieser laufende Browserprozess ist dann mittels Kontrolle diverser ProzessMonitore nachweisbar.
Aber die eigentliche Trojanerdatei xy.exe die sich irgendwo im Betriebssystem eingenistet hat, läßt sich mit dieser
Methode nicht lokalisieren. Eine Möglichkeit wäre noch mit diversen Tools die StartUp-Einträge durchzugehen, ActiveX etc.. Ebenso kann man zwar auch z.B, per netstat oder noch komfortabler mit TCPView die Ein- und ausgehenden Verbindungen abchecken. Jedoch keine der genannten Methoden läßt mir Rückschlüße auf den wirklichen Dateinamen des Trojaners!
Daher, gibt es nicht ein Tool, welches mir anzeigt was für eine Datei sich in den Browserprozess injected hat? - Bzw. welche Datei überhaupt diesen laufenden Browserprozess aufgerufen hat?
P.S. Natürlich alles unter Berücksichtigung eines aktuell laufenden AntiViren-Programms. Trotzdem kann es ja sein, dass die Signatur des Trojaners neu ist und somit noch unbekannt für das jeweilige AntiVirenTool. - Also meine Anfrage zielt darauf ab, noch nachträglich einem
eingeschleusten Trojaner auf die Spur; respektive auf die Ursprungsdatei zu kommen...
Gruß
ELMI
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 104838
Url: https://administrator.de/contentid/104838
Printed on: April 25, 2024 at 16:04 o'clock
10 Comments
Latest comment
Beispiel:
- Alle aktuellen Browser-Fenster sind geschlossen.
- Datei xy.exe (ein Trojaner) injected sich in den aktuellen
Browserprozess.
Wie? der Browser ist geschlossen, aber läuft "aktuell"? Erklär mal.- Alle aktuellen Browser-Fenster sind geschlossen.
- Datei xy.exe (ein Trojaner) injected sich in den aktuellen
Browserprozess.
Process Explorer zeigt Dir alles an, was ein Prozess and dlls usw. geladen hat, ich denke nicht, dass Du mehr bekommst, sofern Du den Aussagen eines infizierten Systems über haupt Glauben schenken darfst. Zuverlässig beurteilen lässt es sich nur, wenn man den DAtenverkehr am Gateway oder von weiteren Rechnern aus analysiert.
Meine Meinung zum Thema "Schwemme" von Malware: Man muss wirklich einiges missachten, um sich zu infizieren. Ich sehe keine steigende Gefahr. Wie gedenkst Du Dich zu infizieren?
Nun, wenn man seinen Browser schließt, und immer noch im TASK-Manager einen Browser-Prozess hat, ist dies kein besonders gutes Zeichen, denn es kann auf einen Trojaner hinweisen der sich in den Browserprozess injected hat (FW-Bypass++). Diese Methode wird von modernen Trojanern gern angewendet, um an den entsprechenden FireWalls vorbei zu kommen.
Ich möchte lediglich die infizierte Ursprungsdatei auffinden, das muß doch möglich sein, ohne sein System komplett neu Aufsetzen oder ein Backup zurückspielen zu müssen!
Es gibt doch sicherlich ein paar Spezialisten hier die entweder eine Methode kennen, oder ein Tool, mit dem man dies analysieren kann!?
Gruß
ELMI
Process Explorer zeigt Dir alles an, was ein Prozess and dlls usw. geladen hat,
Ja das ist richtig, nützt mich aber im beschriebenen Fall nichts, da ich die im Beispiel genannte "xy.exe" ausfindig machen möchteMeine Meinung zum Thema "Schwemme" von Malware: Man muss
wirklich einiges missachten, um sich zu infizieren. Ich sehe keine steigende Gefahr.
Dies ist nicht zwingend meine persönliche Meinung, sondern offizielle Aussagen mancher AntiVirenTool-Hersteller, dass sie mit den bisher angewandten Methoden und der Heuristik im Prinzip "am Ende" sind und der Flut und den neuen Cryptmethoden moderner Trojaner / Viren und Würmer nicht gerecht werden. Mit anderen Worten, es muß über neue Methoden der Erkennung nachgedacht werden. Aber das ist wieder ein anderes Thema...wirklich einiges missachten, um sich zu infizieren. Ich sehe keine steigende Gefahr.
Wie gedenkst Du Dich zu infizieren?
Nun ich denke, von der Gefahr sich zu infizieren, kann sich keiner wirklich freisprechen. Um dies 100% zu gewährleisten, müsste schon der PC 24h ausgeschaltet bleiben Ich möchte lediglich die infizierte Ursprungsdatei auffinden, das muß doch möglich sein, ohne sein System komplett neu Aufsetzen oder ein Backup zurückspielen zu müssen!
Es gibt doch sicherlich ein paar Spezialisten hier die entweder eine Methode kennen, oder ein Tool, mit dem man dies analysieren kann!?
Gruß
ELMI
Zitat von @DerWoWusste:
> Beispiel:
> - Alle aktuellen Browser-Fenster sind geschlossen.
> - Datei xy.exe (ein Trojaner) injected sich in den aktuellen
> Browserprozess.
Wie? der Browser ist geschlossen, aber läuft
"aktuell"? Erklär mal.
Das ist recht einfach, Prozesse lassen sich versteckt starten sondern auch komplett verstecken. Man kann einen Schad-Prozess in den Adressbereich eines unverdaechtigen Prozesses laden. Dazu bedarf es nicht einmal mehr eines Kernel-Hooks [DKOM-Technik], wenn wir und einmal den Fu-Rootkit betrachten:> Beispiel:
> - Alle aktuellen Browser-Fenster sind geschlossen.
> - Datei xy.exe (ein Trojaner) injected sich in den aktuellen
> Browserprozess.
Wie? der Browser ist geschlossen, aber läuft
"aktuell"? Erklär mal.
The FU rootkit can hide processes, elevate process privileges, fake out the Windows Event Viewer so that forensics is impossible, and even hide device drivers (NEW!). (Look, Mom, no hands!) It does all this by Direct Kernel Object Manipulation (TM); no hooking! This project has been evolving other time. It was originally conceived as a proof-of-concept. FU is a play on words from the UNIX program "su" used to elevate privilege.
Ein bisschen Einfuehrungsliteratur zum Thema Process Injection:
1.Three Ways to Inject Your Code into Another Process
2. Zum Experimentieren: Process Injection
3. Analyse des W32/StormWorm.gen1
4. Blackhat-PPS "VICE-Catch the Hookers", Folien 51 - 57.
saludos
gnarff
Keiner da, der diesbezühlich einen Tipp hat?
ELMI
ELMI
Reacting…
A simple strategy to find unauthorised changes in the file system is the calculation of cryptographic checksums for all essential system files, which normally never change. To do this you have to start with a completely clean/safe system and copy the baseline to a cd or a removable device. You also have to compare the new and old checksums on a regular basis to see if there have been any unauthorised changes. The most used program that does the job well is Tripwire, but there are lots of other alternatives out there. But with LKM-rootkits Tripwire is useless because it will then trust on manipulated system-calls of the Operating System.
Even methods based on a specially developed security-kernel-modules which detect and prevent the installation of rootkits by guarding the system 24/7, aren't immune to these kinds of attacks. Certainly in the generation of kernel-memory-patching-rootkits like KIS there are specific attacks implemented which systematically can either bypass or terminate such security-kernel-modules.
Kernel-based rootkits are in general to detect by tests which are run on the infected system, because those tests are influenced by the manipulated kernel. This can be prevented by not trusting the system-calls without any suspicion, but comparing it with the information directly from the kernel-memory. 'Check-ps' [BSD] is a usable tool that uses this method. The program compares certain information with the information that is read directly from the RAM.
An example of an infected system is that the output of 'netstat -anlt' (all open TCP-ports) and the output of a direct port scan is different (nmap 127.0.0.1 -p 1-65535). Differences in open server ports most likely mean that there is a hidden backdoor present on the system.
But this is not enough to determine wetter or not the system is infected, there will have to be an extensive analysis: all data on the hard disk has to be analysed from a clean system install and checked, if there is a baseline of checksums present. The best way to do this is to boot from cd, which doesn't use the installed system. Although most installations cd's give the option to do this, it is best to make a boot-cd yourself which is compatible with RAM-disc.
Oder in anderen Worten, vergleiche die Checksummen einer sauberen, identischen Installation mit denen der in Frage stehenden.
Feliz año nuevo
gnarff
A simple strategy to find unauthorised changes in the file system is the calculation of cryptographic checksums for all essential system files, which normally never change. To do this you have to start with a completely clean/safe system and copy the baseline to a cd or a removable device. You also have to compare the new and old checksums on a regular basis to see if there have been any unauthorised changes. The most used program that does the job well is Tripwire, but there are lots of other alternatives out there. But with LKM-rootkits Tripwire is useless because it will then trust on manipulated system-calls of the Operating System.
Even methods based on a specially developed security-kernel-modules which detect and prevent the installation of rootkits by guarding the system 24/7, aren't immune to these kinds of attacks. Certainly in the generation of kernel-memory-patching-rootkits like KIS there are specific attacks implemented which systematically can either bypass or terminate such security-kernel-modules.
Kernel-based rootkits are in general to detect by tests which are run on the infected system, because those tests are influenced by the manipulated kernel. This can be prevented by not trusting the system-calls without any suspicion, but comparing it with the information directly from the kernel-memory. 'Check-ps' [BSD] is a usable tool that uses this method. The program compares certain information with the information that is read directly from the RAM.
An example of an infected system is that the output of 'netstat -anlt' (all open TCP-ports) and the output of a direct port scan is different (nmap 127.0.0.1 -p 1-65535). Differences in open server ports most likely mean that there is a hidden backdoor present on the system.
But this is not enough to determine wetter or not the system is infected, there will have to be an extensive analysis: all data on the hard disk has to be analysed from a clean system install and checked, if there is a baseline of checksums present. The best way to do this is to boot from cd, which doesn't use the installed system. Although most installations cd's give the option to do this, it is best to make a boot-cd yourself which is compatible with RAM-disc.
Oder in anderen Worten, vergleiche die Checksummen einer sauberen, identischen Installation mit denen der in Frage stehenden.
Feliz año nuevo
gnarff
Hier nochmal meine Frage. Ich suche ein Tool, oder einen entsprechenden Hinweis um auf die Ursprungsdatei, die einen injecteten Prozess gestartet hat, rückschließen zu können.
ELMI
ELMI
Hallo ELMI,
Das Vergleichen von Checksummen ist kinderleicht
Als Tool, empfehle ich Dir das Fsum Frontend
Vorgehensweise:
1. Auf einem Rechner installierst Du das gleiche Betriebssystem, wie das, welches sich auf dem kompromittierten Rechner befindet.
2. Installiere alle Anwendungen, die auch auf dem kompromittierten Rechner installiert sind.
3. Bringe den Referenzrechner auf den gleichen Update- und Patchstand.
4. Erzeuge von allen relevanten Dateien auf dem Referenzrechner die Pruefsumme.
5. Erzeuge von allen relevanten Datein auf dem kompromittierten Rechner die Pruefsummen.
6. Vergleiche die Pruefsummen der Dateien auf dem kompromittierten Rechner mir denen des Referenzrechners.
7. Als Ergebnis aus den Schritten 1 - 6 erhaeltst Du die Information, welche Datei/-en korrumpiert sind.
Vorgehensweise [Vorbeugend]:
1. Auf dem sauberen Betriebsystem/Server installierst Du Tripwire und konfigurierst es entsprechen Deinen Anforderungen.
2. Erzeuge von den relevanten Dateien auf dem/den zu schuetzenden Rechner/-n die Pruefsummen.
3. Sollten Veraenderungsversuche daran Vorgenommen werden, schlaegt Tripwire Alarm.
saludos
gnarff
Das Vergleichen von Checksummen ist kinderleicht
Als Tool, empfehle ich Dir das Fsum Frontend
Vorgehensweise:
1. Auf einem Rechner installierst Du das gleiche Betriebssystem, wie das, welches sich auf dem kompromittierten Rechner befindet.
2. Installiere alle Anwendungen, die auch auf dem kompromittierten Rechner installiert sind.
3. Bringe den Referenzrechner auf den gleichen Update- und Patchstand.
4. Erzeuge von allen relevanten Dateien auf dem Referenzrechner die Pruefsumme.
5. Erzeuge von allen relevanten Datein auf dem kompromittierten Rechner die Pruefsummen.
6. Vergleiche die Pruefsummen der Dateien auf dem kompromittierten Rechner mir denen des Referenzrechners.
7. Als Ergebnis aus den Schritten 1 - 6 erhaeltst Du die Information, welche Datei/-en korrumpiert sind.
Vorgehensweise [Vorbeugend]:
1. Auf dem sauberen Betriebsystem/Server installierst Du Tripwire und konfigurierst es entsprechen Deinen Anforderungen.
2. Erzeuge von den relevanten Dateien auf dem/den zu schuetzenden Rechner/-n die Pruefsummen.
3. Sollten Veraenderungsversuche daran Vorgenommen werden, schlaegt Tripwire Alarm.
saludos
gnarff
Hi gnarff !
Deine Bemühungen in allen Ehren. Das was Du mir auflistest, ist nicht das, wonach ich gefragt habe.
Denn wenn ich den Aufwand betreibe, auf einem Refernzrechner das gleiche Betriebssystem zu installieren, die gleichen Patches und Updates und es mit den gleichen Programmen auf ein und denselben Stand zu bringen. Dann ist das ein Aufwand, der in keinem Verhältnis mehr steht, werder zur Sache, noch zum Zeitaufwand. Da könnte ich auch in 5 Minuten mein Image zurückfahren und mich genüßlich dabei zurücklehnen und wäre 100% sicher, das alles Virenfrei ist.
Außerdem zielt diese Antwort meilenweit an meiner Frage vorbei.
Und was Tripwire betrifft, so ist das auch nur eine scheinbare Sicherheit. Werden z.B. Systemdateien in den Überwachungs-Focus gestellt, so verändern sich diese gegebenenfalls schon beim nächsten Windows-Update im Inhalt und Größe. Dort würde Tripwire also auch Alarm schlagen, was ja dann nichts mit einer evtl. Infizierung zu tun hätte. Tut mir Leid, aber so etwas sind nur halbe Lösungen und sagen nichts wirklich aus.
Deine Bemühungen in allen Ehren. Das was Du mir auflistest, ist nicht das, wonach ich gefragt habe.
Denn wenn ich den Aufwand betreibe, auf einem Refernzrechner das gleiche Betriebssystem zu installieren, die gleichen Patches und Updates und es mit den gleichen Programmen auf ein und denselben Stand zu bringen. Dann ist das ein Aufwand, der in keinem Verhältnis mehr steht, werder zur Sache, noch zum Zeitaufwand. Da könnte ich auch in 5 Minuten mein Image zurückfahren und mich genüßlich dabei zurücklehnen und wäre 100% sicher, das alles Virenfrei ist.
Außerdem zielt diese Antwort meilenweit an meiner Frage vorbei.
Und was Tripwire betrifft, so ist das auch nur eine scheinbare Sicherheit. Werden z.B. Systemdateien in den Überwachungs-Focus gestellt, so verändern sich diese gegebenenfalls schon beim nächsten Windows-Update im Inhalt und Größe. Dort würde Tripwire also auch Alarm schlagen, was ja dann nichts mit einer evtl. Infizierung zu tun hätte. Tut mir Leid, aber so etwas sind nur halbe Lösungen und sagen nichts wirklich aus.
Zitat von @48046:
[...]Denn wenn ich den Aufwand betreibe, auf einem Refernzrechner das
gleiche Betriebssystem zu installieren, die gleichen Patches und
Updates und es mit den gleichen Programmen auf ein und denselben Stand
zu bringen. Dann ist das ein Aufwand, der in keinem Verhältnis
mehr steht, werder zur Sache, noch zum Zeitaufwand. Da könnte ich
auch in 5 Minuten mein Image zurückfahren und mich
genüßlich dabei zurücklehnen und wäre 100%
sicher, das alles Virenfrei ist.
Ja, Dies oder eine Neuinstallation, sind der korrekte Weg bei Kompromittierung eines Produktionssystems.gleiche Betriebssystem zu installieren, die gleichen Patches und
Updates und es mit den gleichen Programmen auf ein und denselben Stand
zu bringen. Dann ist das ein Aufwand, der in keinem Verhältnis
mehr steht, werder zur Sache, noch zum Zeitaufwand. Da könnte ich
auch in 5 Minuten mein Image zurückfahren und mich
genüßlich dabei zurücklehnen und wäre 100%
sicher, das alles Virenfrei ist.
Und was Tripwire betrifft, so ist das auch nur eine scheinbare
Sicherheit. Werden z.B. Systemdateien in den Überwachungs-Focus
gestellt, so verändern sich diese gegebenenfalls schon beim
nächsten Windows-Update im Inhalt und Größe. Dort
würde Tripwire also auch Alarm schlagen, was ja dann nichts mit
einer evtl. Infizierung zu tun hätte. Tut mir Leid, aber so etwas
sind nur halbe Lösungen und sagen nichts wirklich aus.
[...]
Ich code in VB6 (zwar nicht die Welt, aber immerhin) und verstehe
auch etwas von Assembler.
Sehr schoen, dann weisst Du ja auch, wie man einen Dissasembler und Debugger wie es der IDA Proeiner ist handhabt.auch etwas von Assembler.
Installiere Dir VMware.
Besorg Dir Viruspattern, analysiere sie und schreib Deine eigene Implementation eines heuristischen Scanners.
Mit anderen Worten bau Dir ein eigenes Malwaretestlabor, beschaeftige Dich mit
Malware Reverse Engineering und mach den Job selbst, denn darauf laeuft es hinaus; dann waeren wir allerdings bei Deinem:
Mit anderen Worten, es muß über neue Methoden der Erkennung nachgedacht werden. Aber das ist wieder ein anderes Thema...
Und das moechtest Du ja nicht.
Dein Anliegen wurde geloest, weil es ein solches Tool wie Du es suchst nicht gibt, wuerde es dieses geben, dann haette ich es Dir hier bestimmt gepostet.
Saludos
gnarff
Bei Sicherheitsuebrpruefungen werden vornehmlich Opensource-Tools eingesetzt, ganz einfach deshalb, weil man im Notfall nachvollziehen koennen muss, warum es bei einem Testergebnis z.B.zu einem false positive gekommen ist.
Dein Beispiel mit dem Druckertreiber hinkt und ich habe auch niemals gesagt, das JEDER die Arbeitsweise eines Druckertreibers verstehen muss.
Ich jedoch muss dies unter Umstaenden, denn eine Sicherheitsueberpruefung kann durchaus mitbeinhalten, z. B. die Sicherheit von Druckern im Netzwerk zu bewerten, siehe hierzu auch Bruce Schneiers Beitrag Printer Security und Hacking Network Printers
Saludos
gnarff
Dein Beispiel mit dem Druckertreiber hinkt und ich habe auch niemals gesagt, das JEDER die Arbeitsweise eines Druckertreibers verstehen muss.
Ich jedoch muss dies unter Umstaenden, denn eine Sicherheitsueberpruefung kann durchaus mitbeinhalten, z. B. die Sicherheit von Druckern im Netzwerk zu bewerten, siehe hierzu auch Bruce Schneiers Beitrag Printer Security und Hacking Network Printers
Saludos
gnarff
