Message-ID: <3FE7B54D.6030708@brvenik.com>
From: security at brvenik.com (Jason)
Subject: Removing ShKit Root Kit

>>OK, so how does the attacker get the ADS to run? If you open 
>>something.txt in notepad, it doesn't launch the ADS 
>>'trouble.exe' as an executable file. It's ignored.

The easy answer is start a command prompt and type

start something.txt:trouble.exe

it does not even have to be tagged .exe or .com or whatever. As an 
exercise, copy notepad.exe to calc.exe:notepad and then launch a command 
prompt and type "start calc.exe:notepad" You should be looking at 
notepad. I no longer have a handy M$ system to verify the steps on so if 
it does not work play with it for a few minutes.

a shortcut, email, service... are all entry points for this and you 
still have that rotten code on the system.

even removing the troubled txt file may not solve the problem. IIRC the 
host file can be deleted and even overwritten without having an impact 
on the ADS.

so you pull out the trusty CD and reinstall over the old image and you 
could be in the same position.

>>
>>Remember, the machine was formatted and reinstalled from clean media. 
>>However that ADS was called is now long gone...
> 
> 
> Until you restored it from backup.
> 
> Formatting and reinstalling the OS is only half the battle.  If you
> restore the data that was on the compromised disk, you cannot possibly
> guarantee its integrity unless you did checksums on every file prior to
> the compromise, can you?
> 

Depending on the nature of the system it may be critical to evaluate all 
transactions real or otherwise since the known good backup, this would 
not be possible without the backup of the data. If it requires a hand 
audit of each transaction compared to a known good image then the only 
way is with this data.

A larger problem lies in identifying the last known good backup, how 
exactly are you going to know this without at least a rudimentary manual
audit of the system as it is now and as it was for the backups until the 
differences are found and source identified?

what about repeated compromise? competing rootkits? How do you identify 
the critical point of change? Even supposedly known good backups can be 
considered suspect in this situation and this cannot be resolved without 
doing the analysis.

> There's an assumption going on here - that it's not possible to
> compromise "data" in ways that could endanger a machine.  Yet, some have
> already suggested possibilities - ADS, accounts in databases and other
> types of software that have their own account mechanisms, macros in
> documents, etc., etc.  All an attacker needs is a way to begin the
> process - something that the user would execute - like say an email
> message?  Then the code can be hidden inside existing files and
> reassembled by the stub that began the process.  Many "modern" viruses
> begin with a small executable that then fetches the rest of the code,
> "compiles" it and bam, you're compromised again.
> 

or a simple nibble over text channels in an existing unpatched custom 
application that only allows us to write one byte at a time to an 
arbitrary file and then execute it.

just in case someone wants to say that text only executables can not be 
made and used, several tools for this can be found online. Bookmarks 
from an old system provides these direct links to some.

http://groups.google.com/groups?selm=3nolav%248ir%40gagme.wwa.com&output=gplain
http://www.simtel.net/product.php?url_fb_product_page=43214
http://www.simtel.net/product.php?url_fb_product_page=43215

A little bit later after doing a steno decrypt of the content hidden in 
the images on that web server and the compromise is back on a fully 
patched fresh system with known good/safe restored data. OMG WTF?

> 
> As someone tasked with security in an organization, why should we make
> assumptions about *anything* that existed on a compromised box?
> 

We finally agree on something Paul. I knew the day would come :-)

Powered by blists - more mailing lists