dynamic analysis

All posts tagged dynamic analysis

Right, it’s time to start the fun stuff — dynamic analysis, where we run the malware sample and see what happens. What could possibly go wrong?!

Overview

I started off by running the malware sample with my malware analysis script, which has provided a bit of an overview of what’s going on:

INFO:[*] <832:828> 0x405052: VirtualAlloc(0x0,0x14538 (83256),0x1000,0x040) = 0x1a0000
INFO:[-]   Request for EXECUTEable memory
INFO:[*] VirtualAlloc()d memory address 0x1a0000 written from 0x405083 (sample!0x5083): mov byte ptr [ecx + edi], al
INFO:[*] VirtualAlloc()d memory address 0x1a0000 accessed (1) from 0x405083
INFO:[-]   Enabling tracing
INFO:[E] Reached tracing limit of 250000 instructions
INFO:[D] Single-step instruction limit reached -- stopping tracing
INFO:[*] VirtualAlloc()d memory address 0x1a6c82 accessed (1) from 0x405083
INFO:[-]   Enabling tracing
INFO:[E] Reached tracing limit of 250000 instructions
INFO:[D] Single-step instruction limit reached -- stopping tracing
INFO:[*] VirtualAlloc()d memory address 0x1ad904 accessed (1) from 0x405083
INFO:[-]   Enabling tracing
INFO:[E] Reached tracing limit of 250000 instructions
INFO:[D] Single-step instruction limit reached -- stopping tracing
INFO:[*] VirtualAlloc()d memory address 0x1a0000 written from 0x404dff (sample!0x4dff): mov dword ptr [edi], eax
INFO:[*] VirtualAlloc()d memory address 0x1a0000 accessed (1) from 0x404dff
INFO:[-]   Enabling tracing
INFO:[*] VirtualAlloc()d memory address 0x1a0004 written from 0x404e11 (sample!0x4e11): mov dword ptr [edi + 4], ebx
INFO:[E] Reached tracing limit of 250000 instructions
INFO:[D] Single-step instruction limit reached -- stopping tracing
INFO:[*] VirtualAlloc()d memory address 0x1a0448 accessed (1) from 0x404dff
INFO:[-]   Enabling tracing 
INFO:[E] Reached tracing limit of 250000 instructions
INFO:[D] Single-step instruction limit reached -- stopping tracing
INFO:[*] VirtualAlloc()d memory address 0x1a0890 accessed (1) from 0x404dff
INFO:[-]   Enabling tracing 
INFO:[E] Reached tracing limit of 250000 instructions
INFO:[D] Single-step instruction limit reached -- stopping tracing

It looks like the sample is doing something in a loop around 0x405083, and again in a loop around 0x404dff, because the VirtualAlloc()d memory is accessed a number of times from those addresses (as indicated by the ‘INFO:[*] VirtualAlloc()d memory address 0x1a0000 written from …’ lines in the script output).

The second loop is logged a number of times with the accessed address increasing by 0x448 until it accesses memory at address 0x1b4118. That got me wondering why it would by accessing memory in 0x448 byte steps and went looking for the significance of 0x448 (encryption algorithm block size, or something like that), but couldn’t find anything.

It turns out that the memory address jumping by 0x448 was a consequence of my script disabling single-stepping after 250,000 instructions, for performance reasons. This is a good example of why it’s important to know how your tools work — so you can understand what their output means and what they are actually telling you!

Just reviewing the log output while reviewing this post, I had another lesson in why it’s important to know how your tools work, but also why you need to think about your log output too. I ended up reading more into my log output than I should have after noticing that there are two different log lines there — one saying ‘VirtualAlloc()d memory address … written from …’ and one saying ‘VirtualAlloc()d memory address … accessed (1) from …’.

The difference in the log message wording was making me think that the first log entry meant that the address was written, and the second meant that the memory was read. Looking at my script again I noticed that that isn’t the case. In fact, the ‘(1)’ after the ‘accessed’ is EXCEPTION_RECORD.ExceptionInformation[0], which is an indication of the type of operation that caused the fault, with ‘1’ signifying a memory write operation (and ‘0’ signifying a read operation). It’s been a while since I worked on my script as I’ve been working on my newer C++ malware debugger instead.

So, we seem to have two loops that manipulate the VirtualAlloc()d memory at 0x1a0000, one modifying it from 0x405083 (mov byte ptr [ecx + edi], al) and one modifying it from 0x404dff (mov dword ptr [edi], eax). The former looks like a classic base address plus index reference, modifying a byte at a time.

Next we see that the unpacked code is executed, and we have the entry point and the unpacking loop:

INFO:[*]   Found unpacked entry point at 0x1a3f7a called from 0x778a0a22 (push ebp) (after executing -1 instructions)
INFO:[-]   Unpacking loop at 0x405067 - 0x405091 (83255 iterations)
INFO:         0x405067: cmp dword ptr [start+0x3d7f9c], 0xa8
INFO:         0x405071: mov eax, dword ptr [start+0x3d8a00]
INFO:         0x405076: mov al, byte ptr [eax + edi + 0x1134b]
INFO:         0x40507d: mov ecx, dword ptr [start+0x3b9cbc]
INFO:         0x405083: mov byte ptr [ecx + edi], al
INFO:         0x405086: jne 0x40508a
INFO:         0x405088: call ebx
INFO:         0x40508a: inc edi
INFO:         0x40508b: cmp edi, dword ptr [start+0x3d7f9c]
INFO:         0x405091: jb 0x405067
INFO:[-]   Dumping 83256 bytes of memory range 0x1a0000 - 0x1b4537

The first thing we notice there is the interesting address from which the unpacked code was called, 0x778a0a22 — that looks like DLL memory. It also looks like a bug in my script, because the instruction at that address was decoded as ‘push ebp’ which isn’t going to initiate a jump/call (unless it generates an exception because of the value of ss:esp, or because ss:esp points to non-writable memory for instance). We’ll need to manually analyse the sample to find where the unpacked code is called from.

We then see that the block of unpacked code requests a second block of memory:

INFO:root:[*] <5000:4916> 0x1a4433: VirtualAlloc(0x0,0x12a67 (76391),0x1000,0x040) = 0x1c0000
INFO:root:[-]   Request for EXECUTEable memory

There is some modification of the second block of requested memory before my script detects control passing to it from 0x1a4467 (the first block of requested memory):

INFO:[*]   Found unpacked entry point at 0x1c0000 called from 0x1a4467 (jmp dword ptr [ebp - 4]) (after executing 82010 instructions)
INFO:[-]   Unpacking loop at 0x1a44a2 - 0x1a44a9 (18 iterations)
INFO:         0x1a44a2: mov dl, byte ptr [ecx]
INFO:         0x1a44a4: mov byte ptr [eax], dl
INFO:         0x1a44a6: inc eax
INFO:         0x1a44a7: inc ecx
INFO:         0x1a44a8: dec edi
INFO:         0x1a44a9: jne 0x1a44a2
INFO:[-]   Dumping 76391 bytes of memory range 0x1c0000 - 0x1d2a66

The process then exits after an exception:

INFO:[*] <5000:4916> Unhandled exception at 0xff50ffff (0xff50ffff): EXCEPTION_ACCESS_VIOLATION
INFO:[*] <5000:4916> Unhandled exception at 0xff50ffff (0xff50ffff): EXCEPTION_ACCESS_VIOLATION
INFO:[*] <5000:4916> Exit process event for C:\Users\bobby\sample.exe: 0xc0000005

0xc0000005 is the exit code from the process, and in this case it is the value STATUS_ACCESS_VIOLATION corresponding to the exception that occurred. It is interesting that the process tried to access memory at 0xff50ffff. This could be a bug, either inherent in the malware sample, or caused by my analysis script interacting with the malware sample, or it could be an anti-debug technique where the malware sample sets up an exception handler then deliberately generates an exception to see if its exception handler gets control. If not, it is likely a debugger has control. Again, something to check manually with a debugger.

So the sample requests a block of memory (0x1a0000), which two loops (one around the instruction at 0x405083 and the other around the instruction at 0x404dff) then populate and modify to create executable code, and then control is passed to it (entry point 0x1a3f7a). That ‘unpacked’ code requests a second block of memory (0x1c0000) which is then modified before control is passed to it (entry point 0x1c0000).

This blog post will focus on the first of those two loops, and the next post will focus on the second loop.

Manual Analysis Using x32dbg (x64dbg)

Right, so what have we got? We now have something to start with. Let’s revert our virtual machine (VM) to a snapshot (my malware analysis script actually runs the malware so we can’t trust the VM in its current state) and load the sample into a debugger and have a look at it. I’m going to use the x32dbg (the 32-bit version of x64dbg) debugger.

Let’s break after the first ‘unpacking’ loop (to 0x1a0000) to see what we’ve got, by setting a breakpoint at 0x405093 after the unpacking loop at 0x405067 – 0x405091 (see my script output above). We’ll see if we can resolve 0x778a0a22 to a name at this point, since my script seemed to think that this is where control passes to the unpacked code (I have my doubts!). If we can’t, we’ll try again once control is passed to the unpacked code, given my script is claiming that it was called from that 0x778a0a22 address it should be loaded by that point. It does look like a DLL address though so it may have been loaded at a different address.

I usually like to find the instruction that passes control to the unpacked code, as that is a convenient place to set a breakpoint to speed up manual analysis, but it’s not strictly necessary if you just want to determine what the malware is doing to the system. However, since I have my doubts about the unpacked code being called from 0x778a0a22, I want to try and find where this unpacked code is actually called from.

Once we hit the breakpoint after the first unpacking loop (0x405067-0x405091), we’ll have a look and see what we have at 0x1a0000, being the block of memory returned by the VirtualAlloc() call. My script output told us that that loop modifies the newly allocated memory block (at 0x1a0000 in the script output), so we should have some presumably unpacked code there that we can look at.

VirtualAlloc() isn’t guaranteed to give us a block of memory at the same address every time though. In fact, it allocates memory at a different address with the malware sample running in x32dbg than it does when my script runs it. Consequently we need to find the address of the allocated memory. This address is returned by VirtualAlloc() and hence we’ll find it in the eax register when VirtualAlloc() returns. Turns out we can do something a bit spiffy in x32dbg.

To get the address of the allocated memory we’ll put a logging only breakpoint immediately after the VirtualAlloc() call at 0x40504c, being 0x405052 (the first line of my script output (see above) gives us the address of the instruction immediately after the VirtualAlloc() call because it can only see the return address from VirtualAlloc() — it can’t see the actual address of the call instruction). This breakpoint will log the address returned by VirtualAlloc() so when we break at 0x405093, after the unpacking loop, we know the address of the newly allocated memory.

Once we have the address returned by VirtualAlloc() we can set a memory execute breakpoint on that block of memory. Setting the breakpoint on the whole block of memory is a bit overkill because we’ve been told (by my script) that it starts executing at 0x1a3f7a, but this will confirm that my script found the correct entry point. Also, if the malware uses a call instruction to execute the unpacked code then we’ll find a return address on the stack once that breakpoint is hit.

We’re not going to get that far in this post, but we’ll set the breakpoint now while we’re examining that part of the code, and also setting a breakpoint there now will stop the malware from running unchecked should something go wrong and we fail to stop it before it gets that far1.

Now, here’s the spiffy x32dbg bit. We can add an x32dbg command (membp eax,0,x) to the breakpoint at 0x405052 (being the return address from VirtualAlloc()) so that x32dbg automatically sets a memory execute breakpoint on the address returned by VirtualAlloc() for us — “the things we can do with technology today” (I don’t seem to be able to find that advert any more). The x64dbg documentation says that ‘If command condition is set, evaluate the expression (defaults to 1)’, but I found that I had to explicitly set it to ‘1’ to get the Command Text to run. If we can’t see a return address on the stack then we’ll have to do a bit more work to find where it is called from.

Go to 0x405052 (the address after the call to VirtualAlloc() just before the unpacking loop starts at 0x405067) in x32dbg and press SHIFT-F2 to set a conditional breakpoint. Set the following parameters:

Break Condition0 (don’t halt program execution)
Log TextVirtualAlloc({[ESP – 10]}, {[ESP – 0c]}, {[ESP – 08]}, {[ESP – 04]}): {EAX}
Command Textmembp eax,0,x
Command Condition1
Breakpoint configured to set a memory breakpoint on newly allocated memory

Note that the negative stack pointer (ESP) offsets are because this breakpoint is set at the instruction immediately after VirtualAlloc() returns, and VirtualAlloc() pops the arguments off the stack before returning. The negative stack pointer offsets are looking at the four values that were just popped (they are still accessible because nothing was pushed to the stack since VirtualAlloc() returned). In other words, it is accessing the four arguments that were passed to VirtualAlloc().

We should now have two breakpoints set. One at 0x405052, immediately after the VirtualAlloc() call, and one at 0x405093, immediately after the first unpacking loop.

AddressStateDisassemblySummary
00405052Enabledmov ebx,dword ptr ds:[<&SetFileApisToANSI>]breakif(0), log(“”VirtualAlloc({[ESP – 10]}, {[ESP – 0C]}, {[ESP – 08]}, {[ESP – 04]}): {EAX}””), cmdif(1, “”membp eax,0,x””)
00405093Enabledmov dword ptr ss:[ebp-14],esi
x32dbg breakpoints

Let’s run the malware sample and see what happens. The following snippet is the x32dbg log after hitting the entry point breakpoint, setting the above two breakpoints, and then running the malware sample:

INT3 breakpoint "entry breakpoint" at <sample.EntryPoint> (00408716)!
Breakpoint at 00405093 set!
Breakpoint at 00405052 set!
VirtualAlloc(0, 14538, 1000, 40): 190000
Memory breakpoint at 00190000 set!
INT3 breakpoint at sample.00405093!

You can see there that x32dbg has stopped at our 0x405093 breakpoint — the one after the first unpacking loop. The fourth line (‘VirtualAlloc(…)’) is the output from the logging only breakpoint at 0x405052. As you can see, it has logged the VirtualAlloc() arguments and also the return address. In this case (and this demonstrates what I was saying about the address differing between my script running the sample and x32dbg running the sample), VirtualAlloc() allocated memory at 0x190000.

The fifth line in the above x32dbg log output is the x32dbg membp() command setting the breakpoint at the address returned by the VirtualAlloc() call.

When the breakpoint at 0x405093 is hit, it’s just exited the first unpacking loop. We know from the 0x405052 breakpoint’s log message (and from my script’s output) that we should have some unpacked code/data at address 0x190000. Let’s have a look:

00190000031CE2add ebx,dword ptr ds:[edx]
0019000361popad
00190004A2 06CEBF46mov byte ptr ds:[46BFCE06],al
0019000958pop eax
0019000AF3:E7 AAout AA,eax
0019000D4Ddec ebp
0019000E3626:61popad
00190011E2 31loop 190044
00190013AEscasb
00190014C8 71A2 93enter A271,93
Disassembly of ‘unpacked’ code after first unpacking loop

That doesn’t look like valid code. It could be data — if it is, it’s not ASCII characters. Let’s disassemble from the known entry point, as that should definitely be valid code:

00193F7A5Dpop ebp
00193F7B0103add dword ptr ds:[ebx],eax
00193F7D9Cpushfd
00193F7E5Apop edx
00193F7F695A 4F 70A6B224imul ebx,dword ptr ds:[edx+4F],24B2A670
00193F863D C42983F3cmp eax,F38329C4
00193F8BF0???
00193F8CAClodsb
00193F8D4Ddec ebp
00193F8ED6salc
00193F8FF9stc
00193F900A08or cl,byte ptr ds:[eax]
00193F92AClodsb
00193F930F1EECnop esp,ebp
00193F965Bpop ebx
00193F971C EFsbb al,EF
Disassembly of ‘unpacked’ entry point after first unpacking loop

Ditto — that doesn’t look like valid code either. Remember though, that log messages from my unpacking script were suggesting that there were two unpacking loops because it noticed two different instructions modifying the newly allocated memory block at 0x190000/0x1a0000:

INFO:[*] VirtualAlloc()d memory address 0x1a0000 written from 0x405083 (sample!0x5083): mov byte ptr [ecx + edi], al
...
INFO:[*] VirtualAlloc()d memory address 0x1a0000 written from 0x404dff (sample!0x4dff): mov dword ptr [edi], eax

The fact that there are two instructions modifying the same target address suggests that there is more unpacking to do. Well that and the fact that there doesn’t appear to be executable code at the unpacked entry point after the first loop. Of course it could be that my script got the entry point incorrect, but we can verify that by letting the sample run until that memory execute breakpoint is hit, and then examining the eip register.

It is worth noting at this point that my unpacking script actually dumps unpacked memory to files, and we can actually use the UNIXTM objdump(1) command to disassemble them, however, we can’t see an instruction at offset 0x3f7a (corresponding to address 0x193f7a/0x1a3f7a):

$ objdump -b binary -m i386 -D sample.exe.memblk0x001a0000
...
3f78: df 79 e8 fistpll -0x18(%ecx)
3f7b: 01 00 add %eax,(%eax)
3f7d: 00 00 add %al,(%eax)
3f7f: c3 ret
3f80: 55 push %ebp
3f81: 8b ec mov %esp,%ebp
...

Just explaining those objdump command line arguments, the -b specifies the file format (elf, pe, pdb, srec, ihex, etc.). Since we just have raw opcodes with no file format headers, we specify ‘binary’. The -m specifies the architecture which we need to specify because objdump can’t get that information from a file header because there isn’t one. We specify i386 here to tell objdump that the binary data is i386 (or 80×86) opcodes. The -D says to disassemble all sections, as compared to -d which will only disassemble sections that are expected to contain code (like the .text section).

The reason we can’t see an instruction at offset 0x3f7a is because the 80×86 processor has variable length instructions — different instructions are encoded to a differing number of bytes. Consequently if we don’t have consecutive valid instructions from offset 0x0, we can’t guarantee that the instructions displayed above are correct, and they certainly don’t look correct apart from what looks like a function prologue at offset 0x3f80.

This is a property of the 80×86 processors that also allows for some anti-disassembly tricks, like jumping into the middle of an instruction. Something I was playing around with back in the nineties (back when I didn’t have lots of other stuff to get done), just to see if it is possible.

To get around this problem we can give objdump a starting address (or offset), and let’s go all out and tell objdump where the code was located in memory too. The –adjust-vma=0x190000 tells objdump to add 0x190000 to addresses, so that they match the addresses where the code will end up when it is unpacked in x32dbg); and –start-address=0x193f7a tells objdump to start disassembling from what is now address 0x193f7a (file offset of 0x3f7a plus the start-address of 0x190000)2:

$ objdump -b binary -m i386 -D --adjust-vma=0x190000 --start-address=0x193f7a sample.exe.memblk0x001a0000

sample.exe.memblk0x001a0000: file format binary


Disassembly of section .data:

00193f7a <.data+0x3f7a>:
193f7a: e8 01 00 00 00 call 0x193f80
193f7f: c3 ret
193f80: 55 push %ebp
193f81: 8b ec mov %esp,%ebp
193f83: 8d 45 c4 lea -0x3c(%ebp),%eax
193f86: 83 ec 3c sub $0x3c,%esp
193f89: 50 push %eax
193f8a: e8 0d 00 00 00 call 0x193f9c
...

Now we can see a valid instruction at address 0x193f7a. Using –adjust-vma to add the memory base address to all the file offsets means that all the relative addresses, like those in the call and jmp instructions for instance, are shown as the actual memory address which will make it easier to follow along in a debugger.

You’ll notice a difference in the instruction decoding done by objdump versus that done by x32dbg. objdump uses the AT&T style of instruction <src>, <dst> and parenthesis rather than brackets for the memory indirect addressing mode, as opposed to x32dbg which uses the Intel style of instruction <dst>, <src>. That can get confusing when switching between the two!

I did try to find what was at 0x778a0a22 (the address from which my script claimed the unpacked code was called) after loading the sample into x32dbg and running it to the first unpacked code entry point (0x1a3f7a), but all I got was bitter and a nasty little rash. It turned out that 0x778a0a22 wasn’t actually mapped, so I couldn’t see what was there when my script ran. As far as analysing the sample goes though, it’s largely irrelevant, but something that I should figure out to debug my script/algorithm.

Once the unpacked code starts running, and hence we know (or at least are more confident) that it is completely unpacked, we can set a breakpoint at 0x194467 (address corrected for x32dbg execution), where the second block of unpacked code is called from (‘Found unpacked entry point at 0x1c0000 called from 0x1a4467’). We should be able to automate that with x32dbg breakpoints.

Now we know from my script output that this unpacked code also includes an unpacking loop, but to keep you in suspense (more so that this post doesn’t get too long… well, even longer), let’s look at that in the next blog post.

  1. We can’t set a code breakpoint when we start our debugging session because that memory won’t exist (it’s dynamically allocated with VirtualAlloc()). We also can’t set a breakpoint as soon as that memory is VirtualAlloc()d either, because our breakpoint instruction (int 3) will be overwritten by the unpacking code in the malware. This would, however, be a good reason to use a hardware breakpoint rather than a software one. Let’s use a memory execute breakpoint (guard page) though in case, as stated above, the memory is modified more than once during unpacking. ↩︎
  2. The filename contains 0x001a0000 because my script created the file based on the memory address — 0x1a0000 — that was unpacked to when my script ran the sample. We’re using 0x190000 in the objdump command so that the addresses in the objdump output match what we’ll see in x32dbg (where the code will be unpacked to 0x190000) ↩︎

Malware often extracts an embedded PE (Portable Executable) file from within itself, and either overwrites its original process image, or starts and overwrites a new process (process hollowing), with the embedded image. What if you want to save a copy of this extracted PE file so that you can analyse it using something other than the debugger that you were running the sample in?

Continue Reading

Previous posts in this series have demonstrated how unpack.py, when used on a CryptoLocker variant, extracts the malicious PE file injected in to explorer.exe, and how it can also be used to analyse the injected PE file. This post demonstrates how unpack.py can now be used to analyse our CryptoLocker variant’s network communications by dumping the cleartext traffic sent over its HTTPS connections.

Continue Reading

Seeing an increase in MySQL attacks hitting your network and interested in knowing more about them? This post follows on from the previous post which discussed how to run a Cuckoo Sandbox analysis of a MySQL attack.

This post starts analysing the results and notices an issue with a particular malware trait and Cuckoo (v0.4.2). Awfully gripping stuff — I was on the edge of my seat, but then that could be because my table was too far away from my chair. Continue Reading

It’s nice to use dynamic analysis to corroborate the findings from static analysis, but what if you face an SQL attack? What if the attack caused the MySQL server to drop an executable file and pass control to it, or if the attack was exploiting a remote code execution vulnerability? I developed a Cuckoo package, misql.py, to allow me to dynamically analyse some of the effects of MySQL attacks. Continue Reading