Log in

View Full Version : dumping hidden persistant malware

_genuine
July 23rd, 2012, 23:21
Hi ladies,

Im analyzing a piece of malware, I've been able to document its behavior and also been able to clean it from the system quite easily, my next course of action is to analyze the code to document 'how' it does its magic. The first approach id like to take it to see if i can get a clean dump of the process, it uses the persistence method of an autorun entry replacing itself with taskman on logon in the registry, it also hides its executable from the disk. (Which can be retrieved using GMER). The executable it packed or obfiscated, which is why i'd like to see if i can get a running dump of the file. The problem is, on boot up, the process only briefl appears and then its gone. doing its thing in silence. My question is, is there a tool out there that can be used to dump a file on bootup? or can you guys give some advice as to how you would get a dump of this file that only briefly starts on boot up on the system ( by boot i mean on logon) Thanks for any insights.
Kayaker
July 24th, 2012, 00:22
Hi

As an offhand idea, set the /BREAK switch in boot.ini, with the appropriate /DEBUG switches. This will cause a break on HAL initialization. With a suitable VM/Windbg setup you can use the .reboot command to start the process. This will break very early in bootup so you'll need to step ahead until your malware loads. You might be able to set a breakpoint on the malware process load itself with a proper Windbg command.

Another thing you could check is to see if BootlogXP records the malware loading, and if the order is consistent you could even break on the process loaded just before the malware

http://greatis.com/utilities/bootlogxp/index.html

Let us know if you can trap the little bugger.
_genuine
July 24th, 2012, 00:37
Thanks for the insight Kayaker, your responds has me thinking that maybe if i reinstall SICE on this VM I can probably catch this thing, but its been quite some time since ive used SICE, and as far as i remember, it does not have dumping capabilities. I will grab that bootlogxp program, but im fairly sure its boot is consistant. I've tried to go with the more cat and mouse technique where i tried to beat its termination by having process hacker run on startup and dump it as quickly as i could, but im not as fast as i thought i was. I wanted to avoid having to do a setup with windbg as my host machine right now is a MACbook pro, and i would have to have two VMs running in order to have a decent remote setup like the one you described. If there are any tools that do bootlogging and have some kind of framework available i am willing to code up an extension to dump processes on bootup for such a tool as well.
blabberer
July 30th, 2012, 17:25
if you employ /break in windbg on the initial break you can also
set up a break on nt!PspCreateProcess; do a gu ( go up )
and grab the last created process from
nt!psActiveProcessHead.blink

a small conditional breakpoint script shown below will print out all the process that are created on reboot of my sample virtual machine (look for calc.exe whose parent is explorer.exe that's my autorun malware )

Code:


bu nt!PspCreateProcess ".printf \"parent process %ma\\t\", @@c++( ( (nt!_EPROCESS *)@$proc)->ImageFileName);gu;.printf \"created %ma\\n\",@@C++( ( (nt!_EPROCESS *)@@masm( ( poi( nt!PsActiveProcessHead+4 )-88) ) )->ImageFileName);g";


instead of hardcoding 88 etc you can use #containing record macro to get the offset of ActiveProcessLink (which in xpsp3 is at 0x88 from start of Eprocess)

pasted below is a dump of all process that were created in my vpc

instead of /break i used a running windbg to utilize exception handling viz sx


Code:




kd> sxe ibp;.reboot 

Shutdown occurred at (Tue Jul 31 03:47:24.000 2012 )...unloading all symbol tables.

Waiting to reconnect...

Connected to Windows XP 2600 x86 compatible target at (Tue Jul 31 03:47:36.968 2012 ), ptr64 FALSE

Kernel Debugger connection established.  (Initial Breakpoint requested)

Symbol search path is: SRV*F:\symbols*http://msdl.microsoft.com/download/symbols

Executable search path is: 

Windows XP Kernel Version 2600 UP Free x86 compatible

Built by: 2600.xpsp.080413-2111

Machine Name:

Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055b1c0

System Uptime: not available

Break instruction exception - code 80000003 (first chance)

*******************************************************************************

*                                                                             *

*   You are seeing this message because you pressed either                    *

*       CTRL+C (if you run kd.exe) or,                                        *

*       CTRL+BREAK (if you run WinDBG),                                       *

*   on your debugger machine's keyboard.                                      *

*                                                                             *

*                   THIS IS NOT A BUG OR A SYSTEM CRASH                       *

*                                                                             *

* If you did not intend to break into the debugger, press the "g" key, then   *

* press the "Enter" key now.  This message might immediately reappear.  If it *

* does, press "g" and "Enter" again.                                          *

*                                                                             *

*******************************************************************************

eax=00000001 ebx=80087000 ecx=80550d74 edx=80550d44 esi=80087000 edi=00000000

eip=804e3592 esp=80550d60 ebp=80550ee8 iopl=0         nv up ei pl nz na po nc

cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00000202

nt!RtlpBreakWithStatusInstruction:

804e3592 cc              int     3



kd> bu nt!PspCreateProcess ".printf \"parent process %ma\\t\", @@c++( ( (nt!_EPROCESS *)@$proc)->ImageFileName);gu;.printf \"created %ma\\n\",@@C++( ( (nt!_EPROCESS *)@@masm( ( poi( nt!PsActiveProcessHead+4 )-88) ) )->ImageFileName);g";

kd> g





parent process 	created 

parent process System	created smss.exe

parent process smss.exe	created autochk.exe

parent process smss.exe	created csrss.exe

parent process smss.exe	created winlogon.exe

parent process winlogon.exe	created services.exe

parent process winlogon.exe	created lsass.exe

parent process services.exe	created svchost.exe

parent process services.exe	created svchost.exe

parent process services.exe	created svchost.exe

parent process services.exe	created svchost.exe

parent process services.exe	created svchost.exe

parent process winlogon.exe	created logonui.exe

parent process winlogon.exe	created userinit.exe

parent process userinit.exe	created explorer.exe

parent process services.exe	created spoolsv.exe

ERROR: DavReadRegistryValues/RegQueryValueExW(4). WStatus = 5

ERROR: DavReadRegistryValues/RegQueryValueExW(5). WStatus = 5

ERROR: DavReadRegistryValues/RegQueryValueExW(6). WStatus = 5

parent process services.exe	created vmsrvc.exe

parent process services.exe	created mscorsvw.exe

parent process services.exe	created smlogsvc.exe

parent process services.exe	created vpcmap.exe

parent process explorer.exe	created vmusrvc.exe

parent process explorer.exe	created calc.exe <-------- my autorun malware  

parent process services.exe	created alg.exe

parent process explorer.exe	created taskmgr.exe

parent process svchost.exe	created wuauclt.exe

parent process taskmgr.exe	created cmd.exe

parent process cmd.exe	created netstat.exe

parent process cmd.exe	created hostname.exe

parent process cmd.exe	created tasklist.exe

parent process svchost.exe	created wmiprvse.exe

parent process cmd.exe	created wmic.exe

parent process explorer.exe	created rundll32.exe

parent process explorer.exe	created verclsid.exe

parent process explorer.exe	created verclsid.exe

parent process explorer.exe	created IEXPLORE.EXE

parent process explorer.exe	created procexp.exe

parent process explorer.exe	created Winobj.exe

watchdog!WdUpdateRecoveryState: Recovery enabled.
_genuine
July 30th, 2012, 18:27
Thanks for the detailed response blabberer! you seem to be quite the beast on windbg scripting, unfortunately im not as skilled, I have a question about your script, while I can pretty much get the gist of what its doing, how do i employ in my virtual environment? I can connect via COM to the VM and run that script when the OS is loading? Or run it in WINDBG locally within the infected machine?
Also does WINDBG have the capability to dump the process? That is really my main goal, I've verified already that it runs on startup, but i would like to do something along the lines of, break when the process has fully started (All modules have loaded and it has been 'unpacked' in memory), suspend it and dump a full image. I can do these things with a process that is running, but this particular malware quickly kills itself. It doesnt seem to run much code at all, but i would still like to analyze what it does on initialization.
Once again thanks and i will play around with your script just to see how it works.

regards,
gen
Kayaker
July 30th, 2012, 22:31
That is very cool blabberer. I just added to my ongoing file called blabberer_windbg_trix.txt.

I like that sxe ibp Initial break point event flag. That way you don't need to modify the remote boot.ini with the /BREAK switch. Nice.


If I can make a slight diversion, since it's so useful, the other script I like is the one for listing drivers on boot you showed us in this post:

http://www.woodmann.com/forum/showthread.php?9201-Ring-0-anti-debugger-code-in-Daemon-Tools&p=61827&viewfull=1#post61827

To clarify one small point on its use, the script as blabberer wrote it, and how it looked written with the bl command was like this:

Code:


kd> bp 8049a037 ".printf \"%y\\n\", poi(eax+2c);g"

kd> bl

 2 e 8049a037     0001 (0001) nt!IopLoadDriver+0x66f ".printf \"%y\n\", poi(eax+2c);g"


The magic address 8049a037 and offset nt!IopLoadDriver+0x66f you need to derive for your own system. What that offset is really pointing to is where the Entry Point of regular drivers are called from in IopLoadDriver, that is the specific breakpoint being set.

While the registers used might be different in different OS versions, the syntax is generally consistent since Win2K, not sure offhand what it looks like in Win7. You can use the Windbg "u nt!IopLoadDriver" command (or IDA) to scan for the pattern.

So for my own system I determined that the IopLoadDriver pattern occurred here

Code:


805a69c9    push    dword ptr [ebp-90h]

805a69cf    push    edi

805a69d0    call    dword ptr [edi+2Ch] // driver Entry Point called


and the Windbg breakpoint I set using blabberers scriptlet was then:

Code:


kd> bp 805a69d0 ".printf \"%y\\n\", poi(edi+2c);g"

kd> bl

 0 e 805a69d0     0001 (0001) nt!IopLoadDriver+0x669 ".printf \"%y\\n\", poi(edi+2c);g"





As for breaking on a process that runs during startup, you could try this. I discovered this trick from

Break on user mode module load
http://analyze-v.com/?p=682

and used it successfully in this thread

http://www.woodmann.com/forum/showthread.php?14576-Your-free-airline-ticket-is-ready&p=91631&viewfull=1#post91631


As a further test, I created an autostart entry in the VM of a VM/WinDbg/VirtualKD setup for notepad under
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

On the initial Windbg break as the VM was starting up I set up the exception command to break on the process loading

Code:


kd> !gflag +ksl

kd> sxe ld notepad.exe


Windbg broke again (the VM screen showed the "Loading your personal settings" message) and I checked we were in the proper context

Code:


kd> !process -1 0

PROCESS 81430da0  SessionId: 0  Cid: 0000    Peb: 00000000  ParentCid: 0490

    DirBase: 0a2df000  ObjectTable: e1d7ba68  HandleCount:   0.

    Image: NOTEPAD.EXE


At this stage we're still not at the Entry Point of the process, so what I had done before was to use the @$exentry pseudoregister in a further breakpoint, as either of the following:

Code:


kd> bp /p @$proc @$exentry

kd> ba e1 /p @$proc @$exentry



kd> ? @$exentry


In all cases I got the following error:

Bad register error at '@$exentry'

Odd. Any guesses blabs?



Oh well, there's more than one way to find the Entry Point.

Code:


kd> lm m notepad

start    end        module name

01000000 01014000   NOTEPAD    (deferred) 



kd> !dh -f 1000000



File Type: EXECUTABLE IMAGE

OPTIONAL HEADER VALUES

    739D address of entry point


And the next breakpoint becomes instead

Code:


kd> bp /p @$proc 100739d

kd> bl

 0 e 0100739d     0001 (0001) NOTEPAD!WinMainCRTStartup

     Match process data 81430da0


This will get us to the Entry Point of the process that loads during bootup.


I think someone had asked that question in another thread, about an easy way of dumping a full image in Windbg. It's a good question. We're used to quick tricks like OllyDump or using OllyBone or the "ESP trick" to find the OEP of packed executables. I don't know of any shortcuts with WinDbg. Other than .writemem and manual tracing to OEP and rebuilding as required.

Kayaker
blabberer
July 31st, 2012, 05:19
@_genuine

i hope you have setup a kernel debugging connection (i reread your post and you mention mac i haven't kded with mac so i cant say how to do it in mac the following description is for windows os)

assuming you have a pc running windows os xpsp3

and you can install your favourite vm inside it (i play with virtual pc )

in the vm install xpsp3 again

the physical computer running the vm is called host computer which will also run the windbg / kd

the vm is called target and you need to setup kd connection in this vm (com / 1394 / virtual kd /fancy usb/ etc)

assuming you have a valid connection between windbg running on host and os running on target

you can issue

sxe ibp;.reboot
in windbg

this will modify the event handling status of initial break point to enabled and will reboot the target computer

once rebooted windbg will break again on the initial breakpoint (this is the earliest break possible when kernel is loading

and it is at the end of hal phase initialisation when a few essential modules have been loaded and not even System process has been created)

at the break you set a breakpoint (copy paste the script as a single line in windbg command browser ) on nt!pspCreateprocess as posted earlier) and run the windbg with g

on each and every process creation windbg will print out the parent process and child process

if you want to break on every process created you would need to remove the last g in the script and enter g manually every time

the process context on every break would be of parent process not child process

the child process has no active threads yet

as far as dumping is considered you would need to setup further breakpoints
based on process matching and some times trial and error on system apis that are bound to be called for any process initialization


@kayaker

sxe ld will work only once during the first time a modules symbol is loaded
ld does not work for repeated creation of the same process

cpr and epr both work in user mode only these events arent generated in kernel mode

so sxe ld might work if you do a .reboot and say notepad.exe is loaded for first time
but if you do say start -> run -> notepad a few times you will see that sxe ld does not break
it is because the symbols is already loaded (try lm m note* and you would see notepad symbol in deferred list)

? $exentry

and ? @$exentry both work an initialised process with active threads i think (it really never worked for me actually speaking)

while i played with it it returned entry point of ntoskrnl.exe several times in the past
so i normally do not use it

see a trace below i have broken on an internal breakpoint (made by windbg on sxe ld mods) and you can see the current process is explorer.exe

but $exentry returning entry point of ntoskrnl.exe

Code:




kd> .lastevent;   !process -1 0;    ? $ip;   ? $exentry;     ? $exentry -nt;     kb3;    !grep -i -e "entry " -c "!dh nt"   





Last event: Hit breakpoint 10000   <------------------- bp id is 10000 internal bpid

  debugger time: Tue Jul 31 15:23:01.796 2012 (UTC + 5:30)  





PROCESS ffaf6da0  SessionId: 0  Cid: 0570    Peb: 7ffdd000  ParentCid: 0554

    DirBase: 0044d000  ObjectTable: e1d75c40  HandleCount: 394.

    Image: explorer.exe  <----------------- current proc is explorer.exe



Evaluate expression: -2141717310 = 8057fcc2   <------------iam in kernel address space



Evaluate expression: -2140476628 = 806aeb2c   <-------------wtf ????



Evaluate expression: 1932076 = 001d7b2c  <------------@sck#% it is ntos entry point   see the last expression evaluated 



 (might be because of kestackattach and arbitrary process context execution not sure ) 



ChildEBP RetAddr  Args to Child              

f9536d38 804de7ec 01edd3f4 001f0fff 00000000 nt!NtCreateProcessEx+0x7e  iam not mad i ran some process from start -> run 

f9536d38 7c90e4f4 01edd3f4 001f0fff 00000000 nt!KiFastCallEntry+0xf8

01edd00c 7c90d14c 7c8192ce 01edd3f4 001f0fff ntdll!KiFastSystemCallRet





  1D7B2C address of entry point     <---------- see  ep matches with !dh nt output

i believe that it is better to have a sure shot address by spleunking

rather than these whimsical and mostly unsupported / undocumented / UNKNOWN / RARELY understood pseudo registers