PDA

View Full Version : Debugger - Bypassing API hooking automatically - How?

live_dont_exist
August 13th, 2011, 02:17
Hi,
I was trying my hang out at Lenny Zeltser's latest malware challenge. There was a question there about a file that got downloaded on to a system and then hid itself. The question was 'What API's did it use to do this?'.

I managed to get the exact location of these "hidden files and reg keys" using Procmon and CaptureBat and could even cd into the "hidden" directory. Next up was the API question. Googling showed that it was the API called ntquerydirectoryfile which was responsible for displaying files in a directory [Output of "dir"] and RegEnumValue was responsible for viewing values of registry keys. So that's what the malware/rootkit was probably hooking.

The point though was..How do I actually confirm this? Running cmd or regedit did not show me these files or registry keys. So I thought, lets open up cmd in a debugger and see what happens. I opened up 'cmd' - F9'd it in Olly and typed in 'dir'. To my surprise the "hidden" directory revealed itself. The same behavior was found with 'regedit' as well. That confused me..I'll explain why.

Both cmd and regedit are 'User mode' programs. Olly is also a 'User mode' program. Olly is the parent for both these processes. So when i type 'dir' in cmd... instead of the program itself telling the OS to run 'dir' - Olly tells the OS to run 'dir' instead. That's it..rt? It doesn't modify anything AFAIK [Could be wrong].

So yes.. I got the answer to my question for the Lenny challenge, but it was just a stroke of luck to be frank. I had started putting breakpoints on RegEnumValue and Ntquerydirectoryfile when this happened.

Any thoughts?

Thanks
Arvind
Kayaker
August 15th, 2011, 01:15
Hi Arvind

Well that's a useful effect, and observation. Following along with the writeups of the interesting challenge I was able to extract the exe file from the pcap dump using NetworkMiner. I then took a look at things under Softice. From all appearances, Ollydbg restores the original index values of the ntdll calls for itself.

Once the malware is activated, you can see the hook under Softice for any random process:

Code:


:wc // to be able to "Save SoftIce History As" in Symbol Loader for output (toggle code window Off)



:addr winlogon

:u 7c90df5e



0008:7C90DF5E  JMP       0EA06009   // malware NtQueryDirectoryFile hook

0008:7C90DF63  MOV       EDX,7FFE0300

0008:7C90DF68  CALL      [EDX]

0008:7C90DF6A  RET       002C



Fire up Olly (no debugee yet) and you can see that its copy of ntdll is "clean". Isn't that cool?

Code:


:addr ollydbg

:u 7c90df5e



0008:7C90DF5E  MOV       EAX,00000091

0008:7C90DF63  MOV       EDX,7FFE0300

0008:7C90DF68  CALL      [EDX]

0008:7C90DF6A  RET       002C



So, do we know if this is something Olly actively does, purposely verifying the integrity of system calls in its image of ntdll from the original file, or is this some random act of serendipity?

Oh, here's a fun little corollary, pretend to open a file in Ollydbg and start in the C:\ directory. Notice how it automagically detects the "hidden" directory?

Cheers,
Kayaker
-Alex-
August 15th, 2011, 01:48
Any link for the challenge?
Kayaker
August 15th, 2011, 01:51
http://computer-forensics.sans.org/blog/2011/08/10/malware-analysis-challenge-to-strengthen-your-skills
Elenil
August 15th, 2011, 10:45
im interested new ppl like lifedontexits still have softice in their armory ?
live_dont_exist
August 15th, 2011, 11:15
Thanks a lot Kayaker! That's interesting. Do you think Olly would do that for any "API hooker"? Then we wont need Rootkit Revealer and other tools .

@Elenil: I've heard of Softice but you're right..as of now I'm just using Olly 1.10 , 2.01 and IDA's free version (mainly for graphs)

Arvind
vx000
August 15th, 2011, 20:10
Quote:
[Originally Posted by Kayaker;90888]
So, do we know if this is something Olly actively does, purposely verifying the integrity of system calls in its image of ntdll from the original file, or is this some random act of serendipity?


Just a guess, but isn't this purely a function of copy-on-write in Windoze?
Kayaker
August 16th, 2011, 00:57
Hi

Thanks for the insight. Following up on that, I decided to see what other differences one could find between the ntdll images that were hooked, and the 'clean' ntdll image used by Ollydbg. Perhaps if all else failed, something like this could be used to detect this type of memory hook or other alteration in system modules.

These are just observations, not fully tested under all conditions. Yeah, I know this is a bit 'dry', boring technical output and such, but that's the way it is


I began by using the PAGE command in Softice to display the page table information for the virtual address which contained the known NtQueryDirectoryFile hook. The Attributes flags indicated that this location was marked as "Dirty" and "Writeable" for all ntdll images, except of course for Ollydbg, where these bits were not set. The "Dirty" or Modified bit of a page table entry indicates it has been written to.

Code:


:addr notepad (or any random infected process)

age 7c90d000



Linear     Physical        Attributes

7C90D000   1344F000        P RW U    A D





:addr ollydbg

age 7c90d000



Linear     Physical        Attributes

7C90D000   03ADE000        P R  U    A



Another way of looking at that is with Windbg/Livekd. Here is a comparable output for the (hooked ntdll) process notepad. The !pte command again indicates the Dirty Bit has been set, as well as the Writeable bit. The !pfn command on the page frame number obtained from !pte also tells us the page has been Modified. The significant output has been highlighted.


Code:


kd> !process 0 0 notepad.exe

PROCESS 81f47020 Image: NOTEPAD.EXE



kd> .process 81f47020 // set context

Implicit process is now 81f47020



kd> !pte 7c90d000 // page table entry for virtual address of NtQueryDirectoryFile



               VA 7c90d000

PDE at   C03007C8        PTE at C01F2434

contains 123AA067      contains 1344F067

pfn 123aa ---DA--UWEV    pfn 1344f ---DA--UWEV





kd> !pfn 1344f

    PFN 0001344F at address 81204768

    flink       0000001B  blink / share count 00000001  pteaddress C01F2434

    reference count 0001   Cached     color 0

    restore pte 000000C0  containing page        0123AA  Active     M

    Modified



For Ollydbg we get what is expected to be "clean" results.

Code:


kd> !process 0 0 ollydbg.exe

PROCESS 82136da0 Image: OLLYDBG.EXE



kd> .process 82136da0

Implicit process is now 82136da0



kd> !pte 7c90d000



                VA 7c90d000

PDE at   C03007C8        PTE at C01F2434

contains 13B52067      contains 03ADE025

pfn 13b52 ---DA--UWEV    pfn 3ade ----A--UREV





kd> !pfn 3ade

    PFN 00003ADE at address 8108E4D0

    flink       0000001B  blink / share count 00000003  pteaddress E1417D3C

    reference count 0001   Cached     color 0

    restore pte 907C346A  containing page        002C63  Active      P

      Shared





Another thing I noticed when using the Softice QUERY command was that the Flags result was different for ntdll.dll in a hooked image, vs the clean image of Ollydbg. The Flags result corresponds to the MMVAD_FLAGS structure, see this link for details if interested.

What is the Flags field in the output of a SoftICE Query command?
http://www.woodmann.com/forum/showthread.php?t=6458


Specifically, the Vad->u.VadFlags.CommitCharge value was consistently 0x0A for any hooked ntdll, and half of that, 0x05, for Ollydbg. I believe CommitCharge relates to the physical memory usage of a process. I'm not sure of the significance of the difference that is shown - an indicator of copy-on-write?


Code:


:query notepad

Address Range      Flags            MMCI      PTE       Name

7C900000-7C9AF000  0710000A  823B32D8  E1417D08  ntdll.dll



:query ollydbg

Address Range      Flags            MMCI      PTE       Name

7C900000-7C9AF000  07100005  823B32D8  E1417D08  ntdll.dll



And using Windbg to get the same information:

Code:


kd> !process 0 1 notepad.exe

    VadRoot 82296e50 



kd> !vad 82296e50

VAD     level      start      end    commit

821ed760 ( 2)      7c900    7c9af    10 Mapped  Exe  EXECUTE_WRITECOPY





kd> !process 0 1 ollydbg.exe

    VadRoot 8225c900

 

kd> !vad 8225c900

VAD     level      start      end    commit

821a1a58 ( 3)      7c900    7c9af    5 Mapped  Exe  EXECUTE_WRITECOPY




That's as far as I've dug. So what would be next, a Windbg script to scan system images for various page bits being set which might indicate the images had been modified?

Kayaker
vx000
August 16th, 2011, 22:59
Nice work! Windbg script would be interesting. Can think of several applications.
blabberer
August 16th, 2011, 23:42
windbg script

here you got it just tell me if you want the copiuos data to be split with grep sed split uniq and catted to > blah.txt

Code:


c:\scripts>type vadmap.txt

.foreach ( place  {.shell -ci "!for_each_process  dt nt!_EPROCess @#Process Vadroot" sed -e s/.*:./""/ | sed s/.Void/""/ } ) {!vad place}



Code:


output

lkd> $$>a< c:\scripts\vadmap.txt



VAD     level      start      end    commit

86deb080 ( 0)         10       33         0 Mapped       READWRITE          Pagefile-backed section

86d496c0 ( 2)         40       40         0 Mapped       READWRITE          Pagefile-backed section

861e78d0 ( 3)         50      14f         0 Mapped       READWRITE          Pagefile-backed section

86d7dac8 ( 1)      7c900    7c9b1         5 Mapped  Exe  EXECUTE_WRITECOPY  \WINDOWS\system32\ntdll.dll



Total VADs:     4  average level:    2  maximum depth: 3

VAD     level      start      end    commit

86be0978 ( 1)          0       ff         0 Private      READWRITE         

86bd7038 ( 2)        100      100         1 Private      READWRITE         

86bd6458 ( 3)        110      110         1 Private      READWRITE         

86bd3860 ( 4)        120      15f         4 Private      READWRITE         

86d44e40 ( 5)        160      25f         7 Private      READWRITE         

86d442b0 ( 6)        260      26f         6 Private      READWRITE         

86bf2148 ( 7)        270      2af         4 Private      READWRITE         

86c84050 ( 8)        2b0      2ef         4 Private      READWRITE         

86bd0980 ( 9)        2f0      2f0         1 Private      READWRITE         

86a11178 ( 0)      48580    4858e         2 Mapped  Exe  EXECUTE_WRITECOPY  \WINDOWS\system32\smss.exe

86b7a7f0 ( 1)      7c900    7c9b1         6 Mapped  Exe  EXECUTE_WRITECOPY  \WINDOWS\system32\ntdll.dll

86baed48 ( 2)      7ffb0    7ffd3         0 Mapped       READONLY           Pagefile-backed section

86c68eb8 ( 3)      7ffd8    7ffd8         1 Private      READWRITE         

86d831a0 ( 6)      7ffdd    7ffdd         1 Private      READWRITE         

86c290a8 ( 5)      7ffde    7ffde         1 Private      READWRITE         

86b97098 ( 4)      7ffdf    7ffdf         1 Private      READWRITE         



Total VADs:    16  average level:    5  maximum depth: 9

VAD     level      start      end    commit

86cb93e8 ( 8)          0       9f       160 Private      READWRITE         

86cac0d0 (11)         a0       bf         0 Mapped  Phys READWRITE         NOCACHE Pagefile-backed section

86cb1110 (12)         c0       ce         0 Mapped  Phys READWRITE          Pagefile-backed section

86cb1558 (13)         cf       cf         0 Mapped  Phys READWRITE          Pagefile-backed section

86c864e0 (10)         d0       df        16 Private      READWRITE         

86ca7008 (11)         e0       ff         0 Mapped  Phys READWRITE          Pagefile-backed section

86cc6050 ( 9)        100      100         1 Private      READWRITE         

86ca0588 ( 7)        110      110         1 Private      READWRITE         

86c94500 ( 9)        120      15f         4 Private      READWRITE
Kayaker
August 17th, 2011, 23:52
Thanks, I found a useful test bed was simply a regular system with Comodo (or similar) installed. Comodo does several inline hooks of a number of system dlls for selected processes. Rootkit Unhooker/Code Hooks will give the details of these hooks. Some processes such as winlogon/csrss/smss seem to *not* be hooked by Comodo, so they provide the "control", whereas processes such as services/lsass/svchost *are* hooked and provide the test subjects. A memory browser such as SmidgeonSofts TopToBottomNt can be used to view the modified bytes.

In preliminary testing it seems that the !pfn command will consistently report whether a page has been (M)Modified, where a hook occurs, or remain in a (P)Shared state in modules where there is no hook. The !pte command doesn't seem as reliable as it did when testing the malware situation as previously detailed, i.e. it didn't report that the Dirty/Writeable bits had been set on the modified page, by the Comodo hooks. However, continuing with the !pfn command on the suspect pages anyway did expose the modification, if you understand what I'm getting at.



Hi Blabberer, I was hoping you'd drop in with one of your Windbg script magics
OK, so given what I just said about detecting the Comodo inline code hooks on system dlls such as ntdll/kernel32/advapi32/user32 - a hypothetical "ideal" script might check each PTE page frame (!pfn) where these code hooks occur (all in .text section) and report any pages listed by the !pfn command as "(M)Modified". (I'm just throwing around ideas...)
blabberer
August 18th, 2011, 09:06
Hi kayaker show me by example what you want and i will find a way to script it

like !pte ?

!pfn what

if you want all pfn that is in modified state (not sure of the terminology try and post back if this is what you are looking at it is a very huge output so run it and come back after very long time i never allowed it to finish ever when i tried this will hit ctrl+break )

Code:




lkd> .shell -o **********\pfndatabase.txt -ci "!pfn 0 1" grep -i M

<.shell waiting 10 second(s) for process>

.shell: Process exited



lkd> .shell -i **********\pfndatabase.txt cat -


output of cat redirected to windbg command window using read stdin arg -
Code:




 Page    Flink  Blk/Shr Ref V    PTE   Address  SavedPTE Frame  State

    2     1ff3        1     1 c0021320  4264000       80    92e Active   M     

    3     2135        1     1 c0021518  42a3000       80    92e Active   M     

    8      b79        1     1 c000b238  1647000       80    aa9 Active   M     

    9      d99        1     1 c000ada8  15b5000       40    3a4 Active   M     

    b      bb9        1     1 c0004e48   9c9000       80    c44 Active   M     

    d     48e4        1     1 c0041c90  8392000       80   7f47 Active   M     

    f     10c5        1     1 c00149e8  293d000       80    289 Active   M     

   14      c42        1     1 c0004dc0   9b8000       80    c44 Active   M     

   15      b04        1     1 c0004d18   9a3000       80    c44 Active   M     

   17      f0f        1     1 c0014460  288c000       80    289 Active   M     

   1b      b45        1     1 c000b110  1622000       80    aa9 Active   M     

   1d      f55        1     1 c0014690  28d2000       80    289 Active   M     

   21      b12        1     1 c000b000  1600000       80    aa9 Active   M     

   22     89e5        1     1 c07203e8 e407d000       c0  3a028 Active   M     

   33      a3d        1     1 c0004be8   97d000       80    c44 Active   M     

   48      b36        1     1 c000b0b8  1617000       80    aa9 Active   M     

   49      d28        1     1 c000edf0  1dbe000       80   7bf5 Active   M     

   4d      d48        1     1 c038d488 71a91000       60  3f3f1 Active   M     

   4e     1002        1     1 c0010f68  21ed000       80   78cc Active   M     

   60     759d        3     1 c070a318 e1463000       c0   73fd Active   M     

   6a      a34        1     1 c0004ba0   974000       80    c44 Active   M     

   6d     75de        2     1 c070a278 e144f000       c0   73fd Active   M



btw you were looking at ntdll in an ealier post so i modified the script that i posted in ealier thread to grep for modules that you can specify

Code:


.foreach (place { .shell -o c:\scriptresults\vadmapres.txt  -ci "!process 0 1" grep -i vadroot | sed s/.*VadRoot.// | sed s/.Vads.*// }  )  {} 

.foreach /f ( foo "c:\scriptresults\vadmapres.txt" {.shell  -ci "!vad foo"  cat - >> c:\scriptresults\vadmaparg1.txt }

$$>a< c:\scripts\grepvadforarg.txt ${$arg1}

.shell -x del c:\scriptresults\*.txt & exit





the nested script file contains



.shell -i c:\scriptresults\vadmaparg1.txt  cat - | grep -iE "${$arg1}" & echo **************************************************



and you can use it like



lkd> $$>a< c:\scripts\parsevad.txt ntdll|kernel32|user32|gdi32|advapi32


and the out put will be

Code:


86217f00 ( 3)      7c800    7c8f5         7 Mapped  Exe  EXECUTE_WRITECOPY  \WINDOWS\system32\kernel32.dll

865d86b0 ( 4)      7c900    7c9b1         7 Mapped  Exe  EXECUTE_WRITECOPY  \WINDOWS\system32\ntdll.dll

85e5ccb0 ( 7)      7e410    7e4a0         6 Mapped  Exe  EXECUTE_WRITECOPY  \WINDOWS\system32\user32.dll

86164b70 ( 6)      77dd0    77e6a         8 Mapped  Exe  EXECUTE_WRITECOPY  \WINDOWS\system32\advapi32.dll

86658b08 ( 9)      77f10    77f58         3 Mapped  Exe  EXECUTE_WRITECOPY  \WINDOWS\system32\gdi32.dll

8602ea98 ( 3)      7c800    7c8f5         7 Mapped  Exe  EXECUTE_WRITECOPY  \WINDOWS\system32\kernel32.dll

85e42ba0 ( 2)      7c900    7c9b1         7 Mapped  Exe  EXECUTE_WRITECOPY  \WINDOWS\system32\ntdll.dll

86ca7838 ( 5)      7e410    7e4a0         6 Mapped  Exe  EXECUTE_WRITECOPY  \WINDOWS\system32\user32.dll

869e7078 ( 6)      77dd0    77e6a         8 Mapped  Exe  EXECUTE_WRITECOPY  \WINDOWS\system32\advapi32.dll

86000aa0 ( 9)      77f10    77f58         3 Mapped  Exe  EXECUTE_WRITECOPY  \WINDOWS\system32\gdi32.dll

860301e0 ( 3)      7c800    7c8f5         7 Mapped  Exe  EXECUTE_WRITECOPY  \WINDOWS\system32\kernel32.dll

86c15a28 ( 2)      7c900    7c9b1         7 Mapped  Exe  EXECUTE_WRITECOPY  \WINDOWS\system32\ntdll.dll

85cf53d8 ( 5)      7e410    7e4a0         6 Mapped  Exe  EXECUTE_WRITECOPY  \WINDOWS\system32\user32.dll

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

.shell: Process exited
Kayaker
August 18th, 2011, 22:28
Thanks Blabberer. I'll start working on my Windbg script chops, which are about a half step past 'Hello World', and try to figure out where to go from here. Appreciate the help
NeOXOeN
August 19th, 2011, 02:17
nice reading i would say
Woodmann
August 20th, 2011, 00:14
You bastards amaze me .

Woodmann
blabberer
September 12th, 2011, 07:46
@ kayaker
did something or some pattern emerge out of the chaotic output

@WoodMann
Kayaker
September 12th, 2011, 23:13
Hi blabberer,

Sort of. I was working on a script which would potentially detect code modifications of system modules by looking for dirty/modified pages via !pte, and/or !pfn. As a framework I was using a combination of two examples in the Windbg debugger.chm file under "Debugger Command Program Examples" - Walking the Process List and Walking the LDR_DATA_TABLE_ENTRY List. These examples can be used to parse through every loaded module for each loaded process, and from within that loop further testing of various sorts could be done.

For example, if it was found that memory pages were modified for a process that corresponded to the .text section of ntdll, one could use the file on disk to pinpoint the specific addresses that had been changed. Nothing particulary new with that idea, just a variation on a system virginity verifier.


It was about this point that I realized that the existing !chkimg command could be used to the same end, and I kind of put the original idea on the backburner for now.

Here are a couple of articles discussing the !chkimg command:

http://www.dumpanalysis.org/blog/2007/11/22/crash-dump-analysis-patterns-part-38/
http://www.dumpanalysis.org/blog/2008/09/19/hooked-modules/



Here I used !chkimg to detect the ntdll hooks by the challenge malware.

Code:


kd> !process 0 0 explorer.exe



PROCESS 82156928 Image: explorer.exe



kd> .process 82156928

Implicit process is now 82156928



kd> !chkimg ntdll -d

    7c90d976-7c90d97a  5 bytes - ntdll!ZwEnumerateValueKey

        [ b8 49 00 00 00:e9 f5 7f 14 92 ]

    7c90df5e-7c90df62  5 bytes - ntdll!NtQueryDirectoryFile (+0x5e8)

        [ b8 91 00 00 00:e9 a6 80 14 92 ]

    7c90e45f-7c90e463  5 bytes - ntdll!ZwResumeThread (+0x501)

        [ b8 ce 00 00 00:e9 39 7d 14 92 ]

    7c90e975-7c90e979  5 bytes - ntdll!NtVdmControl (+0x516)

        [ b8 0c 01 00 00:e9 47 77 14 92 ]

    7c9161ca-7c9161ce  5 bytes - ntdll!LdrLoadDll (+0x7855)

        [ 68 6c 02 00 00:e9 7b bd 13 92 ]

25 errors : ntdll (7c90d976-7c9161ce)



I'm a little surprised however that the !chkimg -f (fix) command doesn't actually fix the modified bytes. It *says* it has, but on reloading kd or checking with some other memory viewer nothing has actually been changed. I don't *think* it's the malware preventing this, though that could be wrong, but for some reason I can't get "-f" to actually "-FIX".


As for the malware itself, it's fairly interesting and I was going to post a few things about it at some point, mainly strategies for its analysis. I don't know if anyone else has been looking at it, but I was going to recommend it if anyone is looking for a little malware ripping project.
blabberer
September 13th, 2011, 13:24
uh oh JMI where are you
http://www.woodmann.com/forum/showthread.php?12386-CreateThread-and-breakpoints

yes you can use !chkimg to check And WHEN I USED it it USED to FIX things i haven't used it lately

as for walking every module you can use the undocumented
!chkallimg


create the folder temp in c:\ first for some weird reason if the folder didnt exist

this command fails



will send the output to windbg command window and will delete the file

[CODE]
0 errors : ntdll
279 errors : nt (804d8fcf-806243d2)
804d8fc0 02 00 00 0f ae 03 0f ae 08 89 15 c0 f5 df ff *90 ................
804d8fd0 0f 29 04 24 e8 *c3 *62 *c1 *00 0f 28 04 24 8b 4d fc .).$..b...(.$.M.
...
804d93b0 24 01 00 00 8b f8 *e9 *0e *8d *c0 *00 db eb 00 66 39 $.............f9
...
804de770 89 55 0c *e9 *3d *0b *c1 *00 *cc *cc 89 5d 00 89 7d 04 .U..=......]..}.
.............................................
...................
Error for MRxVPC: Could not find image file for the module. Make sure binaries are included in the symbol path.
0 errors : wdmaud
0 errors : mrxdav
0 errors : ndisuio
Error for dump_atapi: Could not find image file for the module. Make sure binaries are included in the symbol path.
Error for ipnat: Could not find image file for the module. Make sure binaries are included in the symbol path.
..........................................
............................................

0 errors : mouclass
Error for fdc: Could not find module base
0 errors : TDI

if driver verifier is running

804f137b,1a37b, 804d7000
nt!CcSetActiveVacb+af, .text
8b,eb
804f137c,1a37c, 804d7000
nt!CcSetActiveVacb+b0, .text
12,f7
806241d0,14d1d0, 804d7000
nt!MiVerifierThunks+0, PAGE
d4,96
806241d1,14d1d1, 804d7000
nt!MiVerifierThunks+1, PAGE
d5,39
[CODE]
JMI
September 13th, 2011, 17:16
I'm right here. But not sure what you wanted/expected me to do.


Was I supposed to mention searching??

I don't want to end up sleeping with Woodmann's fishes.

Regards,
Kayaker
September 13th, 2011, 22:54
OK, so who called the Principal..?

Nice, undocumented Windbg. Actually, the deleted temp log file is more useful because it includes the symbol names for the modified bytes, whereas the command window output doesn't. I'm sure you noticed !chkallimg is simply a shortcut for the following command internally.

kd> !chkallimg
!for_each_module !chkimg -db -mmw c:\temp\chkimg_.log vrsSewl| @#ModuleName

So if called directly the logfile isn't deleted and you get yet another form of output:

Code:


7c90df5e|df5e|ntdll!NtQueryDirectoryFile+0|   .text|b8|e9

7c90df5f|df5f|ntdll!ZwQueryDirectoryFile+1|   .text|91|a6

7c90df60|df60|ntdll!ZwQueryDirectoryFile+2|   .text|0|80

7c90df61|df61|ntdll!ZwQueryDirectoryFile+3|   .text|0|14

7c90df62|df62|ntdll!ZwQueryDirectoryFile+4|   .text|0|92



I was looking at the exports of ext.dll, there's actually quite a number of "undocumented" Windbg commands aren't there? Something like the first 30 or so by ordinal it seems.



The behaviour of !chkimg -f with this malware is odd. If you correct the hooked bytes with RKU or manually with Softice, all is OK. There is no reinfection or anything of that sort (even though the malware does monitor for new processes through a CreateToolhelp32Snapshot thread loop).

To test why Windbg failed where the other methods didn't, I put a Softice breakpoint on ext.dll!chkimg and did a lot of tracing. Thunking down to dbgeng.dll I could see the modifed bytes being repaired correctly in a _mapped_ image of the infected ntdll. I wasn't able to find where this mapped image is presumably used to replace the original infected ntdll image, but it seems likely that is where it fails, maybe.

It's a bit disconcerting that under some unknown circumstances, !chkimg -f doesn't seem to work, even though it reports success. On an otherwise clean system it will repair modified bytes OK though. I tried removing all the hooks from kd.exe, just in case that was affecting !chkimg behaviour, but it made no difference. Remains a mystery for now.
blabberer
September 14th, 2011, 14:20
Quote:

I'm sure you noticed !chkallimg is simply a shortcut for the following command internally.

kd> !chkallimg
!for_each_module !chkimg -db -mmw c:\temp\chkimg_.log vrsSewl| @#ModuleName

So if called directly the logfile isn't deleted and you get yet another form of output:


never occured to me to call it directly that proves if one is an idiot to start with one will be an idiot to the end

look at my idiocy

Code:




0:004> bl

 0 e 7c90d0ae     0001 (0001)  0:**** ntdll!ZwCreateFile ".if ((poi(esp+8) & 0x00010000) > 0 )  {dt nt!_Object_attributes objectname poi(esp+0c)} .else {gc}"

 1 e 7c90d59e     0001 (0001)  0:**** ntdll!NtOpenFile ".if ((poi(esp+8) & 0x00010000) > 0 )  {dt nt!_Object_attributes objectname poi(esp+0c)} .else {gc}"

0:004> g

ntdll!_OBJECT_ATTRIBUTES

   +0x008 ObjectName : 0x011dde78 _UNICODE_STRING "\??\c:\temp\chkimg_.log"

eax=011dde90 ebx=00000000 ecx=7c9142af edx=7c980600 esi=7c90d59e edi=00204040

eip=7c90d59e esp=011dde24 ebp=011dde98 iopl=0         nv up ei pl zr na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246

ntdll!NtOpenFile:

7c90d59e b874000000      mov     eax,74h

0:004> dd esp+8 l1

011dde2c  00010080

0:004> ed esp+8 0

0:004> g


with this idiocy i get
Code:


0 errors : SHELL32 

0 errors : USER32 

7c868d8c,68d8c, 7c800000

kernel32!GetBinaryTypeW+80,   .text

60,62

7c9171ca,171ca, 7c900000

ntdll!LdrpCheckForLoadedDll+408,   .text

60,62

Could not delete file: c:\temp\chkimg_.log



0:000> .shell dir /b c:\temp

chkimg_.log

.shell: Process exited

Press ENTER to continue

<.shell waiting 1 second(s) for process>

<.shell process may need input>



0:000> .shell type c:\temp\chkimg_.log

7c868d8c|68d8c|kernel32!GetBinaryTypeW+80|   .text|60|62

7c9171ca|171ca|ntdll!LdrpCheckForLoadedDll+408|   .text|60|62

.shell: Process exited

Press ENTER to continue

<.shell waiting 1 second(s) for process>

<.shell process may need input>


iirc the output was same didnt notice anything much different in file and cmd window not sure if i looked right
Kayaker
September 14th, 2011, 23:22
You prevented the logfile from being deleted? Hardcore!
blabberer
September 16th, 2011, 19:06
hehe yep actually .shell command also creates a temp file shX.tmp in %temp% which some times i need to grab for this or that reason

so i use that trick most of the time

Code:


ntdll!_OBJECT_ATTRIBUTES

   +0x008 ObjectName : 0x00bae2a0 _UNICODE_STRING "\??\C:\DOCUME~1\Admin\LOCALS~1\Temp\shl42.tmp"

eax=00bae2c0 ebx=00000100 ecx=c0110080 edx=00200000 esi=7c90ff2d edi=00000000

eip=7c90d0ae esp=00bae224 ebp=00bae2b8 iopl=0         nv up ei ng nz na po nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000282

ntdll!ZwCreateFile:

7c90d0ae b825000000      mov     eax,25h

0:001> dd esp l4

00bae224  7c8109b6 00bae2c0 c0110080 00bae260


there are several other files that are deleted undocumented like dbg0.tmp in windbg folder
which iam yet to grab and take a look at

like below

Code:




0:001> g

ModLoad: 01d00000 01d48000   ********\symsrv.dll

ntdll!_OBJECT_ATTRIBUTES

   +0x008 ObjectName : 0x00bab740 _UNICODE_STRING "\??\**********\DBG0.tmp"

eax=00bab758 ebx=00000000 ecx=7c9142af edx=7c980600 esi=7c90d59e edi=00204040

eip=7c90d59e esp=00bab6ec ebp=00bab760 iopl=0         nv up ei pl zr na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246

ntdll!NtOpenFile:

7c90d59e b874000000      mov     eax,74h

0:001> dd esp l4

00bab6ec  7c831fe4 00bab758 00010080 00bab714


as you can see
one is ZwCreateFile CreateFile Api
other is NtOpenFile (called via DeleteFileA api
live_dont_exist
September 26th, 2011, 02:50
Right..so a bump again on this coz I was looking at Honeynet challenge 8 and trying to work my way through it. This is already solved and has solutions too, so I thought it would be a nice learning exercise. That's over here - https://www.honeynet.org/node/668

So if you guys remember the start of this thread, I had seen that malware otherwise hidden in CMD and regedit was visible when I opened CMD in Olly.. thats coz Olly was 'somehow' whopping the hooks itself while other debuggers were not. That's where this stands now.

Now this malware in the Honeynet challenge also seems to do exactly the same... except it is hidden from Olly as well .. I tried the same things... like opening CMD and regedit in Olly but it didnt get displayed. So I'm assuming Olly does NOT rewrite the hooks every time... but did it only for that 1 piece of malware which was earlier discussed. Is that rt?

Just to show you guys some more stuff and save your time (hopefully ) I'll show you what all I got so far:

4 attachments:
registry - Run key blank.. hooked I think
cmd - Appears to cd into the directory 'algonic' but doesnt actually go in and remains in C:\. Look at the output if I try to cd into some other non existent directory
Explorer - some funny blank folder, which you cant go into it keeps coming back to c: recursively but opening multiple subdirectories in the subpane..like a broken softlink
CaptureBat logs - to show you what the malware is doing

The other problem is that after the initial run.. there is nothing to hook to and try and see where the hooks are like discussed at the start of the thread. I'm still working my way through and reading solutions (all are very complicated ) , but as usual I thought I would post here too as it seemed to be related

Cheers
Arvind

--------------------
UPDATE: Updated the screenshot to include GMER detection. Gmer, a rootkit analyzer mentioned in a solution seemed to detect the hooks and I could copy files from the Gmer interface to my desktop. Is that the only way you generally retrieve files, otherwise not accessible? What if <ANY TOOL> does not detect these for whatever reason?
--------------------