Page 2 of 2 FirstFirst 12
Results 16 to 19 of 19

Thread: The Perfect Rootkit

  1. #16
    There is one other possible way to go about solving this problem, and that is to create no rootkit at all. I mean, what is a rootkit in essence? Something that allows you to maintain control over a machine once you have obtained access to it in some way(either by tricking the user, exploiting a vulnerability, or whatever). So, going on that, all we really need to do is inject a vulnerability into a permanently running and internet-accessible service. One way would be to patch the code in say, DCOM, to re-open one of the many now patched vulnerabilities that had been discovered a while back. Then, instead of having the command and control apparatus on each infected client, you maintain that apparatus on the controller's system, and it exists in the form of shellcode or shellcode that downloads, runs, and deletes some more complex application. Now, obviously simple code patching is very easy to detect, and it is just a simple PoC example of how this might be accomplished. But there are other things that can be manipulated at a very low level in the kernel, like say, manipulating some static NDIS buffers that are used in handling some extremely rare ICMP packet type to cause an overflow when they are accessed and used in the kernel.

    Obviously the above methods have the limitation that when the machine is shut down, the 'rootkit' dies. But there are other possible, even more subtle reboot-resistant methods, such as changing configuration files, or maybe even editing the raw NTFS disk structure to, when requesting access to some specific file (like say on a web server), actually redirect the reads/writes to some important system file that can be used to take over the system. The possibilities here are really as expansive as is your imagination, and there are definitely some methods I have thought of that are resilient enough to work practically in a lot of real world challenges. If done correctly, it would be impossible to detect such a rootkit in a generic way. Obviously it will still be detectable if a rootkit detector specifically discovers and analyzes your specific system, but in this case, since the possibilities are so endless, and the primary coding work is done on the controller side, it is extremely easy to change the type of exploit that you use to maintain access, and this makes your rootkit much more potentially dynamic and versatile.

  2. #17
    I disagree that maintaining control is a necessity of a rootkit - simply a hidden program. Would you want a program that does nothing loading and hiding itself? You can think of this in terms of our own health - there are viruses and infections people can get that have no realizable detrimental effects (like a tapeworm for a long while at least). Not surprisingly though, all my rootkit activity analysis always turn leads to bugs in software like AVG Free, random drivers for USB devices, etc. Conclusion about rootkits: without being able to fake memory reads, rootkits are just an insidious game that could potentially require a lot of tools to detect every generalized possibility though a BIOS/SMM/Hypervisor method is much harder to detect as black box methods have to be used.

    Anyone agree that there is probably an official sanctioned Microsoft spyware out there that is tightly kept secret and would not set off any Antivirus alarms while seeming innocuous ? See KB666666 .

  3. #18
    Quote Originally Posted by Snatch View Post
    Has anyone come across any rootkits that hook down to the process API, registry API, memory API and file API level and render themselves totally undetectable even by the most sophisticated reverse engineer?
    I think there's nothing perfect in the nature of things we create; there will be always a workaround, eventually someone will find out a solution. Nevertheless, a very stealth rootkit should perform two actions: what's inherent to its nature (obtain illegal access to private information and login credentials, etc.) covering itself in a layer consisting in a legitime OS/application function as a disguise to perform the malicious actions. I.E: some rootkit could consist in a tampered HTML render DLL from Mozilla Firefox, or an altered version alterada of the SSL/TLS v3 dynamic load library (ssl3.dll) to passively send login credentials to the attacker and gain access.

    This could be a starting point to try achieving an advanced level in hiding rootkit's activity and presence.

  4. #19
    Ideologies and pseudo wisdom are nice and all, but pertaining to the subject I think it'd be rustock.c, I've never seen anything more complex than it. It's only short coming was that it was partnered with a email based dropper; which is still effective, but AV vendors pick up on it quicker.

    Kernel mode rootkits are pretty much dieing on NT though, because of signing. It's all going to userland. You don't even have to hook the native API calls or manipulate tables to avoid the best AV solution out their considering the best heuristics are cryptographic functions based on signatures with trivial detection of common native API calls; that's all 2009 AVs in a nutshell, and their supposed rootkit protection isn't much better compared to something like GMER.

    My Rootkit(lazy version):

    Propagation: Remote Code Execution and Social engineering via email
    Remote Vector: MSRPC(with offset scanning and native process trampoline to avoid DEP and others) & SMTP Engine
    Format: PE with TheMida complexity VM, anti dump, code replacement, IAT mutation, etc..)or VMprotect. Plus a DLL with the same(avoids static signatures plus unpacking plus the hassle of being a single entity writing a mutation engine and VM in a short time span)
    Init: DLL puts a loader in a native PE then pretends to be a thread
    Payload: collects emails and sends and scans for new vulnerable hosts. You can side channel SSL traffic or try to get into a low level keyboard interface if you want assets.

    That's really lazy though. A cloak and dagger job would be a firmware based bootkit that exploits hardware virtualization architecture and spreads through a overflow in the tcpip.sys lookup table functions(any port=vulnerable even if it drops packets(it's on the local network stack with SYSTEM privileges, and infamous memory allocation functions are used in a lot in drivers, nobody dangerous is dumping key level code and analyzing it though))

    Even if found by some researcher what are people going to do mail in motherboards? Also the best possible way to use networking from a rootkit is through DNS abstraction like botnets are using to hide control nodes, and I read about using native NT shell network calls to bypass IDS systems once like ones used by NET STAT etc...

    The BIOS is the foundation for the ultimate malware on a IBM clone system. The MBR and H.A.L. on all operating systems have been tried and tested for decades, and can only make the process be a little harder to stop with packing algorithms, PE/ELF infection, and kernel hijacking, and maybe a RNG to do it all with.

    Personally I can stop pretty much anything software based on a NT system with group policies, DEP, and driver signing. Which are post SP2 and default already on vista. Before that it was group policies and packet filters, and I didn't bother with stack defender or anything. My servers have always been openbsd and apache based with heavy use of gcc allocator security.
    Last edited by daddy; June 19th, 2009 at 04:25.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

Similar Threads

  1. Amr Thabet: Reversing Stuxnet's Rootkit (MRxNet) Into C++
    By Silkut in forum Malware Analysis and Unpacking Forum
    Replies: 4
    Last Post: February 6th, 2011, 08:19
  2. Rootkit Analytics
    By Kayaker in forum Advanced Reversing and Programming
    Replies: 0
    Last Post: March 19th, 2009, 12:02
  3. Rootkit.Win32.TDSS.eyj Another custom packer/cryptor
    By Cthulhu in forum Malware Analysis and Unpacking Forum
    Replies: 3
    Last Post: February 6th, 2009, 17:25
  4. Question about Rootkit Unhooker
    By WaxfordSqueers in forum Malware Analysis and Unpacking Forum
    Replies: 15
    Last Post: February 1st, 2009, 23:06
  5. Rootkit Revealer
    By Silver in forum Tools of Our Trade (TOT) Messageboard
    Replies: 6
    Last Post: March 23rd, 2005, 18:55


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts