Prozess verstecken

L

littleben

0
Hallo zusammen,
zurzeit interessiert mich, wie ein Virus es schafft (und ich es schaffen könnte), ein Programm vor dem normalen Windows Taskmanager zu verstecken. Dass man es nie schaffen wird, ein Programm vollständig vor dem Benutzer zu verstecken, ist mir klar.

Und bevor Fragen aufkommen, wofür ich das brauche, erkläre ich es euch (kurz):
Normalerweise programmiere ich Anwendungen für relativ große Firmen (Verwaltung, Logistik, etc. -> konstruktive Programme).
Dabei kommt die systemnahe Programmierung (wenn man das so nennen darf) ein bisschen zu kurz. So interessiere ich mich seit kurzem für solche dunklen Seiten der Programmierung. Wie zum Beispiel die PE Infektion (was mir CDW super erklärt hat) oder ein Sniffer funktioniert.
Jedoch reicht es mir nicht, die Theorie irgendwo zu lesen, sonder will es anhand von Beispielen auch selbst ausprobieren. So habe ich es dank CDW geschafft ein Programm in ein anderes zu injizieren (auch wenn es das gleiche Programm nochmal war) und auszuführen. Hat mir volkommen gereicht!
Hoffe, dass ihr versteht, was ich damit sagen will. Auch wenn das viele sagen: Ich will nichts Böses machen, sondern nur das Wissen haben.

Nun wieder zurück zum Thema:
In anderen Foren habe ich schon einige Anhaltspunkte gefunden. Am meisten hat mich folgende Idee Überzeugt: Man erstellt ein Subprozess der svchost.exe, sodass dem Benutzer nichts auffällt.
Außerdem habe ich noch diese Ideen gefunden:
- Programm in Form eines Treibers
- Programm in Form eines Dienstes
- Programm den Titel "" gegeben
Da ich eigentlich nur in Delphi programmiere bin ich auf die uallCollection gestoßen. Mit dieser Komponente soll angeblich auch einiges möglich sein.
Mehr habe ich im Internet leider nicht gefunden. Doch ich bin mir sicher, wenn man weiß wo und mit welchen Stichwörtern, dann findet man wesentlich mehr Informationen.
Nun weiß ich überhaupt nicht, wie ich das in die Realität umsetzen kann(Delphi). Vielleicht könnt ihr mir helfen.

Bin auf eure Antworten gespannt!

Viele Grüße,
Benny
 
I.d.R. wird wahrscheinlich die Funktion die die laufenden Prozesse ausgibt gehookt und dementsprechend verändert das prozesse mit dem Namen X nicht angezeigt werden.
Ebenso kann man z.B. mit Dateinamen verfahren.
 
Zuletzt bearbeitet:
Unauffälliger geht es über DKOM (direct kernel object manipulation). Hier wird eine vom Kernel gepflegte Liste aller Prozesse verändert (EPROCESS), dabei wird der Prozess, der versteckt werden soll, aus der Liste ausgetragen. Es gibt noch weitere Ansätze, einer, der in die Kategorie "fancy" einzuordnen wäre, ist einen eigenen Scheduler zu schreiben.
 
WOW! Das mit DKOM hört sich sehr gut an. Habe auch sofort ein Beispiel gefunden: Dkom Process Hider - rohitab.com - Forums .Jedoch konnte ich diese Programm nur in meiner VB unter XP ausprobieren, da Win 7 das Ausführen blockiert (wie ich es hasse). Müsste ich dann in Delphi umschreiben.

Das mit dem Hook hört sich ebenfals gut an. Aber auch hier wüsste ich nicht, wie ich das anstellen soll.

Schonmal danke euch beiden!
 
Dieser Code funktioniert wahrscheinlich nicht unter Win 7, oder? Kannes leider nicht testen, da mein sche** Win 7 das permanent blockt! Kann man das abschalten?!
 
Wenn du Code nur kopieren möchtest, dann ist Hackerboard wohl das falsche Board für dich.

Der Code funktioniert angepasst für alle Betriebssysteme mit Windows NT Kernel.
 
littleben hat gesagt.:
Dieser Code funktioniert wahrscheinlich nicht unter Win 7, oder? Kannes leider nicht testen, da mein sche** Win 7 das permanent blockt! Kann man das abschalten?!
Zum Vergrößern anklicken....
An deiner Stelle würde ich W7 verfluchen, wenn es die uralt Angriffskonzepte NICHT blockieren würde ;)

Wenn du gerne alles ausprobieren möchtest, setze dir am Besten eine WinXP-VM auf.
 
Es wird nicht "geblockt" nur erschwert.

Noch einmal: Die grundsätzlichen Konzepte mit denen man schon bei XP Prozesse versteckte, gelten immer noch. Man muss sich aber eben etwas mehr Arbeit machen bzw. den Code anpassen. Man braucht mehr Rechte bzw. muss sich beispielsweise mit Patchguard auf x64 Systemen rumschlagen oder die Kernel-Strukturen anpassen. Aber letztendlich sind es vom Prinzip her die gleichen Methoden.
Einige wurden genannt:
- Usermode Hooking
- EPROCESS Unlinking (DCOM)
- Eigener Thread-Scheduler
 
Das "neue" ist halt UAC, was eben den netten elevated rights Dialog bringt. UAC blockt ja eh schon 95 % aller Malware...
 
enkore hat gesagt.:
Das "neue" ist halt UAC, was eben den netten elevated rights Dialog bringt. UAC blockt ja eh schon 95 % aller Malware...
Zum Vergrößern anklicken....

Njein. UAC ist eigentliche eine Pervertierung des Rechtemanagements. Es ist entstanden, weil User faul oder unwissend sind. (Was man ja nicht unbedingt verhindern kann)

So wie du es sagst, klingt es so, als wäre XP irgendwie fehlerhaft gewesen oder mit einer Sicherheitslücke behaftet. On the contrary: Würde man auf XP korrekterweise mit eingeschränkten Benutzerrechten arbeiten und mit korrekten Directory-ACLs, dann bräuchte man so einen Popans wie den UAC-Dialog nicht zu veranstalten.
Im Prinzip ist UAC so etwas wie ein "Ausführen als..." nur, dass Admin-Credentials automatisch angewendet werden, und man nur Ja oder Nein drücken muss.
 
EPROCESS Unlinking (DCOM) gefällt mir bis jetzt am besten. Würde sagen, dass diese Methode die sauberste ist. Auserdem konnte ich auch schon anhand des Beispiels verschiedene Prozesse verstecken, was mich beeindruckt hat.
@+++ATH0: Kannst du mir erklären, was das genau ist und macht: Eigener Thread-Scheduler.

Um mich mit dem Usermode Hooking zu beschäfftigen habe ich ja deinen Code (ist das auch Usermode hooking? Also API Hooking = Usermode hooking?).
 
littleben hat gesagt.:
EPROCESS Unlinking (DCOM) gefällt mir bis jetzt am besten. Würde sagen, dass diese Methode die sauberste ist. Auserdem konnte ich auch schon anhand des Beispiels verschiedene Prozesse verstecken, was mich beeindruckt hat.
Zum Vergrößern anklicken....
Kommt hin

littleben hat gesagt.:
@+++ATH0: Kannst du mir erklären, was das genau ist und macht: Eigener Thread-Scheduler.
Zum Vergrößern anklicken....
Naja du betreibst deinen eigenen Scheduler neben dem vom Kernel. Der Kernel weiß überhaupt nix mehr von deinen Prozessen, weil sein Scheduler nur ein Prozess in deinem Scheduler ist. So wie in Inception... ;)

littleben hat gesagt.:
Um mich mit dem Usermode Hooking zu beschäfftigen habe ich ja deinen Code (ist das auch Usermode hooking? Also API Hooking = Usermode hooking?).
Zum Vergrößern anklicken....
Usermode Hooking bedeutet, dass du lediglich die Win32 API veränderst. Kernel und Treiber wissen also noch bescheid, wenn der Task-Manager aber z.B. über die Process Status API nachfragt, ist dein Prozess weg. Antivirenprogramme und Tools wie Icesword sehen deinen Prozess jedoch immernoch.

Im Prinzip ist ein eigener Scheduler das coolste und sicherste. Man könnte theoretisch auch so weit gehen, dass man sich eine Art Miniatur-VM bastelt und den Kernel virtualisiert. Mit allen Treibern. Dann wäre das Betriebssystem deine Marionette - in jeder Hinsicht
 
Vielen Dank für die super Erklärung!
Also ist ein eigener Scheduler das aller Beste, d.h. noch besser als das EPROCESS Unlinking? Denke, dass dies auch das schwerste ist.
Würde am liebsten mal das EPROCESS Unlinking in Delphi ausprobieren. Denn die API zu hooken ist ziemlich unsicher, da der Prozess ja nur im Taskmanager nicht mehr sichtbar ist. Jedoch wäre dies für den Einstig ganz gut, oder? Habe dafür ja auch eine Vorlage von +++ATH0 http://www.hackerboard.de/code-kitchen/16976-prozess-verstecken-unter-xp.html. Für das Unlinking finde ich leider keine Beschreibungen oder Erklärungen, außer dort Dkom Process Hider - rohitab.com - Forums

EDIT: Hier hab ich doch noch etwas gefunden: http://www.wenpoint.com/securityinfo/rootkit/hiddenprocess-implies-attack.php
 
Zuletzt bearbeitet:
Vielleicht wäre die Lektüre, "Rootkits: Subverting the Windows Kernel" für den Anfang nicht schlecht.
Sonst lädst du dir noch mehr Missverständnisse auf. Es ist schwer zu helfen, wenn du nur sehr sehr rudimentäre Vorstellungen davon hast, von was wir reden.
Bestenfalls bespricht man konkrete und spezielle Fragen in einem Thread.
Man kann aber nicht das besprechen, was du nicht kennst und/oder kannst geschweige denn es in ein paar Sätzen beibringen.

Beispielsweise wird es wohl schwierig DKOM EPROCESS Unlinking mit Delphi zu bewerkstelligen, weil dazu ein Treiber notwendig ist und es für Delphi keine out-of-box Lösung dafür gibt. Zusammenkleistern könnte man da schon etwas, wie beispielsweise holy father damals das DDDK (Delphi Driver Development Kit), oder man könnte zumindest auf ungepatchten bzw. alten NT-Systemen so ein paar kernel-"exploits" nutzen um Code unter Ring0-Kontext auszuführen.
Es hilft aber nicht mit so etwas herumzuexperimentieren, wenn man nicht einmal auf normalem Wege einen Treiber ordentlich und "proper" zusammenbringt und versteht, wie der NT Kernel funktioniert und wie das Betriebsystem grundlegend von seiner Struktur her arbeitet.
This separates the men from the boys.
Skript-Kiddies nehmen den kurzen Weg und lernen nichts; haben am Ende mit einem übercoolen kopierten und nachgemachten Trick bzw. Code, ihr kleines Rootkit gebastelt - welchen sie nicht mehr anpassen können sobald sich irgendetwas ändert und sich zusätzlich nicht erklären können, warum er unter neuen Umständen crashed, warum er da mal nicht funktioniert usw.
Jemand, der sich ernsthaft dransetzt und etwas lernt, wird zwar sehr lange kein gutes rootkit zusammenkriegen, aber er weiss wie und warum der Code funktioniert, den er selbst geschrieben und nachvollzogen hat, er besitzt die Fähigkeit sich gemäß seines bisherigen Lernstands anzupassen, und behält die Orientierung, weiss vlt. wo er nachgucken muss oder was er testen könnte, um mehr Erfahrungen zu sammeln und sein Wissen zu erweitern.

Kurzum: Lehn dich nicht zu weit aus dem Fenster. Wenn du am Ende das Know-How haben möchtest, Prozesse zu verstecken, dann willst und musst du allgemeines Know-How über das Windows Betriebssystem mit NT-Kernel und Treiberentwicklung auf solchen Systemen haben.

Also brauchst du sowas wie:

Amazon.com: Windows® Internals: Including Windows Server 2008 and Windows Vista, Fifth Edition (Pro Developer) (9780735625303): Mark Russinovich, David A. Solomon, Alex Ionescu: Books

Amazon.com: Windows NT Device Driver Development (9781578700585): Peter G. Viscarola, W. Anthony Mason: Books

Zweiteres mag zwar schon sehr alt sein. Allerdings sind die Konzepte dahinter alle noch heute so. Deswegen ist das erste Buch zu empfehlen. Das was sich nämlich verändert hat, im Vergleich zu dem alten NT-Kernel kann man hier sehr gut nachvollziehen und anwenden. Gleichzeitig schult man damit Transfer-Vermögen!

und letztendlich das schon genannte:

Amazon.com: Rootkits: Subverting the Windows Kernel (9780321294319): Greg Hoglund, Jamie Butler: Books

Wenn man dieses Buch liest, und hat man gleichzeitig noch oberen beiden Bücher als Grundlage schon erarbeitet, versteht man dieses Buch wie ein Wirbelwind und ist wohlmöglich in der Lage selbst zu den Beispielen in dem Buch etwas beizutragen und sie zu erweitern. Würde man dagegen das Buch nur so lesen, könnte man vlt. gerade so die Beispiele darin ausprobieren und erhält ein kleinen aber nur sehr oberflächlichen Einblick.

Letztendlich kommt es darauf an wieviel Herzblut man in so eine Sache stecken will. Will man ewig darauf angewiesen sein naive Fragen zu stellen, zu Dingen, die eigentlich schon sehr fortgeschritten sind, während man selbst noch an der Oberfläche des Kenntnismeeres schwimmt, oder ist man bereit Luft zu holen und ordentlich einzutauchen?
 
Vielen Danke! Das ist wohl die Wahrheit. Bevor ich hier weiter dumm rumfrage werde ich mir erst einmal dieses Buch zulegen!!!

Vielen Dank für alle Antworten!

Grüße,
Littleben
 
Das Buch (Programming the Microsoft Windows Driver Model, w. CD-ROM (Microsoft Programming Series) , Walter Oney) ist zwar eher auf Hardware ausgerichtet, aber danach kannst du die IRPs singen ;) Man sollte beim Lesen aber immer die vollständigen Codebeispiele zur Hand haben. Vorteil: Anhand des Inhaltsverzeichnisses kann man sich wunderbar einen Plan bis zum fertigen Treiber machen - excellente für eigene Projekte...

Best practice zum Testen ist heutzutage (m.M.n.) eine 32-Bit Win XP VM. XP lässt problemlos unsignierten Code zu und hat an sich auch weniger Sicherheitsmechanismen o.ä. worauf man achten müsste. Zuguterletzt ist es ein recht bewährtes System zu dem man auch viel Material findet...
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben