Log in

View Full Version : How to analyze on a live system that is infected?

peekr
July 23rd, 2010, 21:02
How to analyze on a live system that is infected?

Attack begins with ARP from the gateway device.
ARP replies with no requests and ARP Ping Scans.

Firewall delays infection, does not prevent.
Anti-virus and Anti-Malware does not detect active infection.
Driver on disk before infection 33kb, after 36kb, in memory 54kb+.
Memory Item 54kb+ is detected as TR/Rootkit.gen after copying from memory.

While using Sandboxie 96% of the time, it still get's into the system.

Tools I have used but may not know how to use completely:

Windbg
FTK Imager lite 2.9
Memoryze
Moonsols Windows Memory Toolkit Community Edition
GMER
Radix

I have used win32dd to create a crash dump memory image.
Using Windbg i have disassembled the infected driver from start address to end address. I am sure there is more components to the malware than just this one driver.

Are there steps I am missing?

What do I do next?

How will setting up a malware analysis environment help me?
Kayaker
July 23rd, 2010, 23:20
Hi

I moved your post to a separate thread, where it's more appropriate.

A couple of things I don't quite understand. What do you mean by the driver on disk is 33kb before infection, 36kb after? You make that sound like a regular driver is being infected, or are you saying that is the actual full rootkit driver?

If you've got the driver and have analysed it, can you tell what it is doing, such as loading another driver, hiding registry entries or files, etc? If it's encrypted/obfuscated and you can't tell with a static analysis, you might be able to use a VM to load it separately and trace through it (Softice/WinDbg).

Can you also explain what you mean by the Sandboxie statement - it still gets into the system? If you're already infected, using a VM now (except for maybe a separate analysis of the driver as mentioned above, or possibly allowing infection and comparing snapshots to see what occurs), is like closing the barn door after the horse leaves anyway.

Did you try Rootkit Unhooker? It may tell you about various hooks (like GMER should), but also about kernel callbacks, which are critical to be aware of with many driver rootkits.

Kayaker
peekr
July 24th, 2010, 06:02
I am new to debugging, so there maybe misunderstandings on my part.

I have gone through malware cleaning sessions that go nowhere.
It was recommended to learn how to debug to figure out what's happening.
It was agreed that there is rootkit behavior, but standard tools are not discovering any positives.


[Originally Posted by Kayaker]A couple of things I don't quite understand. What do you mean by the driver on disk is 33kb before infection, 36kb after? You make that sound like a regular driver is being infected, or are you saying that is the actual full rootkit driver?

After a clean install Windows/System32/Drivers/WDFLdr.sys is 33kb.
(I don't know if the size changes over time.)
ARP Spoofing attack and ARP Ping Scan appear first.
Next, various app crashes,e.g. browser, flash.
Next, firewall network monitor.
Next, Real Network.
Next, GMER crash - Safe Mode, GMER crash.
Check WDFLdr.sys and it's now 36kb in it's location, Windows/System32/Drivers.
Scan with Mandiant Memoryze, all accept acquire process. WDFLdr.sys size is 54kb. From previous installation, before reinstall, Mandiant Memoryze WDFLdr.sys size 64kb.
Both files, from Mandiant scans are listed by Avira as TR/Rootkit.Gen while the actual file on disk has no detection.
I can provide copies of both Memoryze files if needed.


[Originally Posted by Kayaker]If you've got the driver and have analysed it, can you tell what it is doing, such as loading another driver, hiding registry entries or files, etc? If it's encrypted/obfuscated and you can't tell with a static analysis, you might be able to use a VM to load it separately and trace through it (Softice/WinDbg).
This is what I am trying to understand, how to debug.
Along with most drivers dumped from memory with Mandiant, I have a memory crash dump from win32dd.exe ready for Windbg, 2gb.


[Originally Posted by Kayaker]Can you also explain what you mean by the Sandboxie statement - it still gets into the system?[QUOTE]
Infection point is the gateway.
Sandboxie only protects the browser, other components are exposed.
I get infected with or without Sandboxie, without is faster.
Without Firewall and Sandboxie, 24hrs. With Firewall and Sandboxie, 1week.
End result is the same, infected.

[QUOTE][Originally Posted by Kayaker]Did you try Rootkit Unhooker? It may tell you about various hooks (like GMER should), but also about kernel callbacks, which are critical to be aware of with many driver rootkits.
Have tried,
RKU - crashed on low level disk scan
GMER - just crashed
VBA Anti-Rootkit - inconclusive
Radix - ?

Hey, while writing this I was able to complete an RKU scan. No crash.
Silkut
July 24th, 2010, 08:10
Can you provide the GMER crash dump ? I'll submit it to the author?
Thanks.
hering
July 24th, 2010, 08:53
Dude, I work at Symantec and there´s a kinda cool bootable CD for this, check here ("http://www.symantec.com/norton/support/kb/web_view.jsp?wv_type=public_web&docurl=20080827141031EN&ln=en_US") for the Norton Bootable Recovery Tool.

http://www.symantec.com/norton/support/kb/web_view.jsp?wv_type=public_web&docurl=20080827141031EN&ln=en_US

There´s also the Symantec Endpoint Recovery Tool but you have to purchase SEP suite in order to download it, if you have any license for that application you´re good to go, if not download the NBRT, I had good experiences at removing rootkits and bootkits.


Oh, and just one more thing; if you´re going to send us some evidence, please use 7zip or some not widely used compression tool. f you have a threat and does all that you said, we have a good chance that is compression-aware and can jump off the compressed file. Also, put a password on it.

I volunteer to check out for the evidence, this seems challenging. Anyone else?
: )
Silkut
July 24th, 2010, 09:36
As described in the topic rules, you can upload samples, zipped, renamed (non clickable format) and password protected with big red letters above the download link...
Woodmann
July 24th, 2010, 14:45
Howdy,

The only other tool I have is Rootkit Buster.
Maybe give that a try.

Woodmann
peekr
July 24th, 2010, 17:21
I am interested in learning how to analyze these files.

@silkut

I didn't save any of the crash dump files from GMER. I have reinstalled.
I will do this for the future.

The files below are either obtained from memory or unallocated space.
The first 3 links are from the previous install, 2 and 3 are from unallocated space and have no extension.
All are password protected "infected".
The last one is from the current running system.

The following files are possible Malware and should be treated as infected
Woodmann
July 24th, 2010, 19:04
Howdy,

I tried the 4th one.
Scanned the .zip with Comodo and Clamwin.
Results say no problem.

Fire up WinRar and scan from that and it defeats
both Comodo and Clamwin.
It shuts down the scan immediately.

I will assume when you say sandboxie you mean a VM?

I might have to dig out the "junk box" to play with this one.

Woodmann
esther
July 24th, 2010, 19:49
*I will assume when you say sandboxie you mean a VM?

howdy Woody,
Sandboxie is NOT a good VM.I call it a emulator,not a true VM,coz it will infect your os when running virus,malwares.Tried that,it sucks :P
VM or virtualbox is the best choice!
Pls take care of your junks too
peekr
July 27th, 2010, 03:23
Quote:
[Originally Posted by Woodmann]I will assume when you say sandboxie you mean a VM?

I don't have any VM set up. I just use Sandboxie to help protect while surfing.

I have unassembled the call functions.
uf /c <address>

Code:
0: kd> uf /c 8026d0a2

Flow analysis was incomplete, some code may be missing

WDFLDR!RtlUnicodeStringCopyString <PERF> (WDFLDR+0xa2) (8026d0a2)

  WDFLDR!RtlUnicodeStringCopyString <PERF> (WDFLDR+0xa2) (8026d0a2):

    call to 13bc906d


The first call, I'm having trouble locating.
Loaded modules start at 74e20000, so am not sure what is being called.
Typing u + 13bc906d returns Memory access error.

Code:
0: kd> uf /c 8026e1f8

WDFLDR!WdfLdrOpenRegistryDiagnosticsHandle (8026e186)

  WDFLDR!WdfLdrOpenRegistryDiagnosticsHandle+0x49 (8026e1cf):

    call to nt!ZwOpenKey (81c7e9f8)


This is the second call outside of wdfldr.sys memory address.

Which does:
Code:
0: kd> u 81c7e9f8

nt!ZwOpenKey:

81c7e9f8 b8bd000000      mov     eax,0BDh

81c7e9fd 8d542404        lea     edx,[esp+4]

81c7ea01 9c              pushfd

81c7ea02 6a08            push    8

81c7ea04 e865dd0000      call    nt!KiSystemService (81c8c76e)

81c7ea09 c20c00          ret     0Ch

nt!ZwOpenKeyTransacted:

81c7ea0c b8be000000      mov     eax,0BEh

81c7ea11 8d542404        lea     edx,[esp+4]

0: kd> u 81c8c76e

nt!KiSystemService:

81c8c76e 6a00            push    0

81c8c770 55              push    ebp

81c8c771 53              push    ebx

81c8c772 56              push    esi

81c8c773 57              push    edi

81c8c774 0fa0            push    fs

81c8c776 bb30000000      mov     ebx,30h

81c8c77b 668ee3          mov     fs,bx


Is the process I'm following O.K.? Follow the call functions to see what is happening.
Along with call functions, what other functions should I think about tracing?

The third call outside of wdfldr.sys memory space is calling a device driver, I think.

Code:
0: kd> uf /c 8026e241

WDFLDR!WdfLdrDiagnosticsValueByNameAsULONG (8026e20c)

  WDFLDR!WdfLdrDiagnosticsValueByNameAsULONG+0x35 (8026e241):

    call to hal!KeGetCurrentIrql (81fa7104)

  WDFLDR!WdfLdrDiagnosticsValueByNameAsULONG+0x4e (8026e25a):

    call to WDFLDR!DbgPrint (802700c8)

  WDFLDR!WdfLdrDiagnosticsValueByNameAsULONG+0x5a (8026e266):

    call to WDFLDR!DbgPrint (802700c8)

  WDFLDR!WdfLdrDiagnosticsValueByNameAsULONG+0x78 (8026e284):

    call to WDFLDR!WdfLdrOpenRegistryDiagnosticsHandle (8026e186)

  WDFLDR!WdfLdrDiagnosticsValueByNameAsULONG+0x8d (8026e299):

    call to WDFLDR!DbgPrint (802700c8)

  WDFLDR!WdfLdrDiagnosticsValueByNameAsULONG+0xb0 (8026e2bc):

    call to nt!ZwQueryValueKey (81c7eee4)

  WDFLDR!WdfLdrDiagnosticsValueByNameAsULONG+0xc6 (8026e2d2):

    call to WDFLDR!DbgPrint (802700c8)

  WDFLDR!WdfLdrDiagnosticsValueByNameAsULONG+0xe8 (8026e2f4):

    call to WDFLDR!DbgPrint (802700c8)

  WDFLDR!WdfLdrDiagnosticsValueByNameAsULONG+0xf4 (8026e300):

    call to WDFLDR!DbgPrint (802700c8)

  WDFLDR!WdfLdrDiagnosticsValueByNameAsULONG+0x105 (8026e311):

    call to WDFLDR!WdfLdrCloseRegistryDiagnosticsHandle (8026e174)

  WDFLDR!WdfLdrDiagnosticsValueByNameAsULONG+0x114 (8026e320):

    call to WDFLDR!DbgPrint (802700c8)

  WDFLDR!WdfLdrDiagnosticsValueByNameAsULONG+0x11f (8026e32b):

    call to WDFLDR!DbgPrint (802700c8)

  WDFLDR!WdfLdrDiagnosticsValueByNameAsULONG+0x13b (8026e347):

    call to WDFLDR!DbgPrint (802700c8)

  WDFLDR!WdfLdrDiagnosticsValueByNameAsULONG+0x147 (8026e353):

    call to WDFLDR!DbgPrint (802700c8)

  WDFLDR!WdfLdrDiagnosticsValueByNameAsULONG+0x158 (8026e364):

    call to WDFLDR!__security_check_cookie (80270089)


which does:

Code:
0: kd> u 81fa7104

hal!KeGetCurrentIrql:

81fa7104 64a024000000    mov     al,byte ptr fs:[00000024h]

81fa710a c3              ret

81fa710b cc              int     3

81fa710c cc              int     3

81fa710d cc              int     3

81fa710e cc              int     3

81fa710f cc              int     3

hal!HalpInitIrqlAuditFlag:

81fa7110 8bff            mov     edi,edi


I'm reading Memory Dump Analysis Vol. 1

peekr
Kayaker
July 27th, 2010, 07:58
Hi

I had a really quick look at your attached files a couple of days ago. I may be wrong, but I'm not sure if the wdfldr.sys image dumps are going to indicate much.

I think the first thing to ask is - if you've identified the trojan as TR/Rootkit.gen, then what is it's usual behaviour? I know that's rather generic, but search around and find out what that trojan family normally does - dumps some files? (reports will probably give different names from what you might have), adds certain registry entries? (again reports might be slightly different, so don't assume the behaviours are etched in stone).

IF the trojan is modifying the system file wdfldr.sys, which seems to be the direction you're following - have there been any previous reports of that? With any trojan? I'm not familiar with that driver (Vista+ system driver is it?)

This change in file size seems odd. In one case you've got the file on disk increasing by 3kb, and in another the memory size changes by 10kb after infection? I don't understand any of that. If the trojan is adding code, which would be pretty unique added to a driver, you should be able to find that by comparing before/after disassemblies/hex, no?

You might be correct in looking for calls outside of wdfldr.sys memory space, but the call to hal!KeGetCurrentIrql looks totally normal and benign. If you really want to check, disassemble the uncorrupt wdfldr.sys and see if WDFLDR!WdfLdrDiagnosticsValueByNameAsULONG normally calls hal!KeGetCurrentIrql (as an example).

The other problem with analyzing a dump of the driver is that the INIT section is missing (which is perfectly normal since that pageable section often disappears from memory soon after driver initialization). Unfortunately it also sort of corrupts the IDA disassembly a bit, cross references may be in error or incomplete, so be aware of that. Compare with a virgin disasm for verification.


You may have better luck with the 2 unnamed memory dumps you created. What made you dump those sections in particular btw? If they are trojan related, they may be easier to analyze and find out what they are up to. They both seem to be PE files (one of them has 2 MZ headers so may be 2 files in sequence), but they seem to be a bit corrupt - you might have to rebuild them to get a usable disassembly (imports missing, I think one of them had no Entry Point).

It's great that you're analyzing this, but you posted some code there that at first glance seems like it might be normal wdfldr.sys code (unless you've got a reason to believe otherwise). I just hate to see you waste time on stuff you think might be suspicious, when it's really not (especially if you're not familiar with "normal" driver code/functions), i.e. following a red herring.

It seems to me there must be a better way to get a handle on your infection than diving into the middle of that driver dump

btw, in case you're not familiar with this site, if you really want to get into memory dump analysis:
http://computer.forensikblog.de/en/

Kayaker
peekr
July 27th, 2010, 09:56
Quote:
[Originally Posted by Kayaker]You might be correct in looking for calls outside of wdfldr.sys memory space, but the call to hal!KeGetCurrentIrql looks totally normal and benign. If you really want to check, disassemble the uncorrupt wdfldr.sys and see if WDFLDR!WdfLdrDiagnosticsValueByNameAsULONG normally calls hal!KeGetCurrentIrql (as an example).

You may be right, but I had to do some work to be able to ask a question.
Unassemble addresses of the driver.
Find and unassemble call functions to see what the calls are doing.
Follow the chain until it ends, then next call function.
I am learning.

Quote:
[Originally Posted by Kayaker]You may have better luck with the 2 unnamed memory dumps you created. What made you dump those sections in particular btw? If they are trojan related, they may be easier to analyze and find out what they are up to. They both seem to be PE files (one of them has 2 MZ headers so may be 2 files in sequence), but they seem to be a bit corrupt - you might have to rebuild them to get a usable disassembly (imports missing, I think one of them had no Entry Point).

A complete memory dump is what I used to do the unassembly of the wdfldr.sys with Windbg. I used win32dd.exe to create a crash.dmp of ram.
I was having malware behavior but no tool seeing it. Either good malware or buggy computer. GMER and RKU were crashing, usually a sign of malware activity.
I used Mandiant Memoryze to scan the ram after guided malware cleaning came up empty but still had symptoms. The Audit Log from Memoryze, which has copies of files from memory, was scanned by Avira. Avira flagged wdfldr.sys in the audit log directory as TR/Rootkit.gen. I did submit the file to Avira also and still same result.
Also, I checked the unallocated space for deletions possibly made by malware using FTK Imager lite 2.9. Check partitions, check MBR, the first 16 sectors of NTFS partition.
If I'm infected it's hiding very well. TR/Rootkit.Gen probably isn't the only thing lurking, they usually like company.

Quote:
[Originally Posted by Kayaker]It's great that you're analyzing this, but you posted some code there that at first glance seems like it might be normal wdfldr.sys code (unless you've got a reason to believe otherwise). I just hate to see you waste time on stuff you think might be suspicious, when it's really not (especially if you're not familiar with "normal" driver code/functions), i.e. following a red herring.

I wasn't trying to post "Suspicious" code. Just posting the beginning to see if I'm on the right track with the process, of course I have a lot more reading to do. The code I did paste very well could be normal, remains to be seen on my end. As for a copy that is uncorrupted, I may have to look on a recovery partition or the manufacturer re-image disc.
When I had a VM set up in the past only the surfing Guest would get infected, not the Host. That suggests to me a MITM attack. DNS Rebinding, arp poisoning, route mangling, etc.

Quote:
[Originally Posted by Kayaker]It seems to me there must be a better way to get a handle on your infection than diving into the middle of that driver dump.

I already exhausted one support request that came up empty. If you have a suggestion I'm all ears.
A well respected malware researcher has told me that debugging is the only way to be sure there is no malware on a system, and relying on report tools will lead to a false sense of security. I trust his advice and have chosen to follow this road.

I may have to return to a VM setup so I don't have to spend hours restoring the system.

Thanks for your input.
Kayaker
July 27th, 2010, 15:27
By an uncorrupted copy of wdfldr, I just meant check the file/dump from a clean install or separate computer with same OS version. Comparing the two disassemblies/function tracing side by side might ease the analysis of the infected version so you can quickly eliminate what should be there.

Stupid question, but does a dump of a clean wdfldr pass the Avira scan? There's no chance of a false positive in that particular file dump? I guess I'm still questioning that wdfldr.sys is the intended target of the trojan. It's possible of course, but that would mean you (probably) found something new and not widely reported before, and would also mean that XP computers are unaffected (a large trojan target audience!)

Are there any known reported vulnerabilities with the version of wdfldr you have?


The new MoonSols Windows Memory Toolkit by Matthieu Suiche, the author of win32dd, might be helpful. The free community edition has the newest version of win32dd, for memory dumps, as well as scripts to generate hibernation file and raw dumps. You might get some more information that way.

http://moonsols.com/blog/2-blog/9-moonsols-windows-memory-toolkit

Another way of exploring the memory of your infected system that might work is TopToBottomNT.

http://www.smidgeonsoft.prohosting.com/software.html
Woodmann
July 27th, 2010, 19:55
Howdy,

I withheld comment because I am a rookie in this field.

I looked at them and I dont see anything unusual
but I just thought that was because the file was "washed".

"Washed" meaning the file had been stripped of other info's.

Woodmann
peekr
July 31st, 2010, 08:13
Quote:
[Originally Posted by Kayaker]The new MoonSols Windows Memory Toolkit by Matthieu Suiche, the author of win32dd, might be helpful. The free community edition has the newest version of win32dd, for memory dumps, as well as scripts to generate hibernation file and raw dumps. You might get some more information that way.

http://moonsols.com/blog/2-blog/9-moonsols-windows-memory-toolkit

This is what I am using. The code above was harvested from a dump using moonsols.

Quote:
[Originally Posted by Kayaker]By an uncorrupted copy of wdfldr, I just meant check the file/dump from a clean install or separate computer with same OS version. Comparing the two disassemblies/function tracing side by side might ease the analysis of the infected version so you can quickly eliminate what should be there.

To do this I would have to change my current set up to include a VM, maybe make an image of the system, reinstall, then I would be able to compare.

Thank you for asking those questions, they are very useful.

Thank you for the links.
NtToptoBottom reminds me of Process Explorer.
peekr
August 1st, 2010, 22:56
Can I run PEid on a 2gb memory.img?
Will it only look for a few PE Headers?
Can I copy the PE Header section, save as...? and scan it with a PE tool?

I put the memory into a hex editor and searched for strings.
I found one UPX packer (not 2.0), a PE header overwritten with font file names, and a couple where only MZ and PE are visible.

A few PE headers had google results for vundo, tr/rootkit.gen, and game password stealer. Not conclusive, but interesting.

TCPIP.sys seems to be the most scanned file at Virus Total.