Oddysee Rootkit Test

Publié le par Kareldjag

This rootkit is a pure "hider" (intrusion or hacker tool): it acts as an hidden service/driver.
But it does not hide its registry keys, that makes it easy to detect for users who know their system well.
In this example, we purposefully take the side and point of view of classical users who are not usually very knowledgeable about the ins and out of their pc on a deeperlevel, and therefore would like a clearer diagnosis of a rootkit presence.

Here's the scan of this rootkit on Virus Total:

It can be detected as a suspect object  (__o) by Sysinternals tools like Autorun, WinObj or LoadOrder:

Service/driver utilities are also helpful in being able to display the loaded driver (Drivers and Drvloader) or the service (OSRLoader):

More over, a simple dump of the registry can give us an indication of a system's infection:

It's important to note that the driver is only hidden as a system file (__oddysee.sys) and not as an object (active in memory): that's why most detectors dispaly it as a non hidden.

Here's the file after a reverse change of the SSDT hooks:

Unfortunately, most users are not able to make the difference.

This rootkit was tested against many rootkit detectors (latest versions), and only Gmer clearly identifies a rootkit presence (it shows that a hidden service/driver is running after a scan).
All other detectors are fully bypassed or partially bypassed.

Detection criteria:

Detectors which display a hidden running service/driver: Fully detected;
Detectors which not display the driver or SSDT hooks: Fully bypassed;
Detectors wich display only the driver as non hidden: Fully bypassed;
Detectors which display SSDT hooks only, or driver and SSDT hooks, or have the ability to detect hidden files: Partially bypassed.

Fully detected: Gmer: displays the service/driver, the SSDT hooks and the hidden service/driver clearly identified as hidden (marked in red).
In addtion, a popup dialog box confirms the diagnosis to the user.

1.Task detectors:

a) Fully bypassed:

- Hidden Finder:

- Process Hunter:

- Process Master:

b) Partially bypassed:

- IceSword  (driver and SSDT hooks)

NB. IceSword can also show the hidden files, but in real life situation, the user is not supposed to know the directory where files are hidden!

- DarkSpy: same as IceSword

- Helios: driver and hooks

Right click for a google search:

- Rootkit Unhooker beta 3: driver and hooks

The driver is not shown as "hidden from Windows API" :

No file is detected as hidden

-SEEM: driver, SSDT hooks, and shows that the service/driver is running (but not as hidden):

2. Rootkits scanners and checkers: only the hidden files and folder are displayed as hidden:

a) Partially bypassed:

- BitDefender Rootkit Uncover

- AVG antirootkit

- Sophos antirootkit

- RootkitRevealer

- F-Secure BlackLight

- Avira antirootkit:

- Archon Scanner: ??? trial key was not functional: or the tool is available as a simple trial (install and run, with no kind of key) or NOT!

b) Fully bypassed: since the product focuses on the registry, it is fully bypassed (no hidden reg keys):

- UnhackMe

- RootkiShark

- RKDetector (only the registry module is functional in the free version)

- KprocCheck: can only dispaly the driver but not the hooks:

- System Virginity Verifier ( only the  SSDT hooks made by the antivirus are displayed)

b) Partially bypassed:

- RAIDE: only the hooks in SSDT are detected:

- Rootkit Hook Analyzer: good detection of the SSDT hooks:


The majority of internet users needs a reliable and easy to follow and understand diagnosis of rootkit detection.
This was hopefully demonstrated in this test: there is no ideal detector for all rootkits, known or unknown.

But what would be the ideal goal of a better rootkit defense?

Intruder/hacker tool (pure hider) or automated malware (Haxdoor, Gomozom, SpamBot etc), a rootkit can be considered as an intrusion in a host.
In this case, an antirootkit should satisfy and correspond to the ABC of intrusion:

 "That which can not be prevented should be detected; that which can not be detected should be prevented".

Unfortunately, only a few antirootkits have prevention and detection features: Helios and Gmer.
Helios: real time detection, on demand scan and prevention features.
Gmer: on demand scan and prevention features.
Both can be considered as specialized HIPS.
We can also mention Kaspersky antivirus (proactive module) which provides real time (every minute) detection (effective) and rootkit prevention (not very effective).

UnhacKme provides also real time detection (every minute), but is not effective against unknown rootkits.

Other detectors (Task analyzers, scanners or checkers) only provide an on demand detection: in this case, their place is not in the line defense with the firewall and the antivirus, but in the security toolbox.
In real world of security situation, it can take only 10 minutes to install a rootkit, copy, exfiltrate and steal data, and remove intrusion traces (log zapping etc).
Users can't be expected to spend their time checking their system every hours or even minutes.

The rootkit phenomena is a marketing argument for the security industry, and rootkit detection is already (or planed to be) integrated in most security softwares (antivirus and HIPS) for home users.
This is the case of HIPS like AntiHook 3, Prevx (ineffective detection of installed rootkit), Online Armor (future version) and so on.
The Darkspy team also plans real time detection.

What is the future of rootkit detectors?

There is two evident solution evolving:

- from antirootkit to HIPS (already the case of GMER and Helios),

- from antirootkits to forensic analysis tools (already the case of the paid version of RKDetector).
Some free forensic analyzers tools like Intel RPIER already integrate well known antirootkit module like Rootkit Revealer:

As shown by our test, there is no perfect antirootkit.
The most important part relys on the human factor: who uses the detector is much more important than which detector is used.
There is no reliable intrusion (hacker or malware) diagnosis possible without a user having at least some minimum insight and knowledge.

Ideally, an antirootkit should take into consideration the following:

- prevention (service/driver installation, physical memory access for instance) and detection features,
- real time detection,
- SSDT hooks and hidden objects detection,
- ADS creation detection and prevention,
- integrate an hidden files scanner,
- ability to detect hidden connection,
- integrate a sniffer,
- rootkit eradication abilities (restoring the changes, unhiding, wiping),
- ability to be run from external drives,
- popup dialog box interaction,

 etc etc etc etc...

A few links:

A list of rootkit detectors can be found at antirootkit.com or at its clone rootkitshield.com.
There is also interesting tests and informations related to rootkit defense on the Sysinternals forum.


Pour être informé des derniers articles, inscrivez vous :

Commenter cet article

logo design 21/04/2010 15:33

Thanks for sharing this.

Julie 27/01/2007 11:52

Je suis très étonnée.

Alan 21/10/2006 16:15


I am the author of Oddysee rootkit, I am really impressed you even made a tech doc about it.

My main aim of this rootkit was to learn c and how the windows kernel does things thats why I never bothered about making it hidden "as-such", it was also made to be entered into a competition.

A simple
net stop __o
__oddysee /u
Will stop/uninstall the rookit, for people who are having problems.

Feel free to contact me on the email address provided, english only.


michel aparicio 08/11/2006 19:54

The main purpose of this little article is to show some drawbacks of rootkit detection with specialized detectors (=click and run a detector is not ALL).Not well known, Oddysee was an interesting choice because it does only hide its driver as a file and not as an active object.You'll find more on my old article: http://kareldjag.over-blog.com/article-895476.htmlIf you're interested about the subject, i sugest to take a look at the malware section of Sysynternals forum.