![Helping Non-Security Stakeholders Understand ATT&CK in 10 Minutes or Less [VIDEO]](https://assets.crowdstrike.com/is/image/crowdstrikeinc/video-ATTCK2-1)
![Qatar’s Commercial Bank Chooses CrowdStrike Falcon®: A Partnership Based on Trust [VIDEO]](https://assets.crowdstrike.com/is/image/crowdstrikeinc/Edward-Gonam-Qatar-Blog2-1)
![Endpoint Protection and Threat Intelligence: The Way Forward [VIDEO]](https://assets.crowdstrike.com/is/image/crowdstrikeinc/GK-Blog_Images-1)
Many of CrowdStrike’s customers are often targeted by email phishing campaigns and strategic web compromises (also known as watering-hole attacks). These attacks use exploits to take advantage of vulnerable unpatched software installed on the victim’s computer. If an exploit is successful, then it will run an attacker’s payload, which will typically install malware bundled with the exploit itself and/or download malware from a remote server.
If you’re in charge of defending your enterprise’s network and you know that an adversary is sending your employees malicious email attachments, you would want to know the exploits’ payload functionality. For example, if you know that your company was targeted by an exploit whose payload communicates with http://evil.example.com, you’d want to ensure that your network’s IDS/IPS systems detect and prevent communication with that remote server. While antivirus products can often detect these exploits, these products won’t tell the user what the exploit’s payload is actually designed to do:
Security software that tries to determine a payload’s functionality via emulation or a sandbox will sometimes work, but it still requires knowledge of the exploit’s targeted environment, as the exploit may work in one system configuration but not another.
In-depth analysis of these threats is where CrowdStrike comes into play, where we focus on intelligence-driven security. Knowing that a computer received a phishing attempt is only half the battle -- the other half is knowing the functionality of the adversary’s payload. We were recently notified of a new Microsoft Word document that exploits CVE-2013-3906. While this is certainly the first blog post to discuss this vulnerability and related exploits, we want to be the first to show you an end-to-end walkthrough of a CVE-2013-3906 exploit analysis with a detailed focus on the payload. Research When we received the malicious Word document, we already knew that it contained an exploit for CVE-2013-3906. For one, we developed a YARA rule for CVE-2013-3906 exploits when Microsoft first announced the vulnerability, and this YARA rule detected the Word document immediately. And secondly, this document was already detected by 12 AV engines when it was released into the wild (though 32 other AV engines did not detect the file). When analyzing any file that contains an exploit, the most difficult part of the task is typically in finding the actual payload code. There are three main approaches for this stage of the analysis:- Statically search for shellcode in the exploit file This can be difficult if the file is very large or if the file contains obfuscated shellcode
- Understand the vulnerability well enough to know where the payload would exist in the exploit file This requires the vulnerability to be well documented, or it requires the researcher to analyze the vulnerability from scratch, which can be very time consuming
- Attempt to dynamically execute the exploit and its payload This works well as long as the exploit actually works in the dynamic analysis environment and a breakpoint can be set during some point of the exploit execution or payload execution
available for this vulnerability, we opted to use approach #3 for the sake of efficiency. The
Metasploit module for this exploit
shows the following crash information:
Based on this data, we can assume that the exploit is used to control register EAX and hijack the function OGL!GdipCreatePath (the comments in the Metasploit module more-or-less confirm this).
According to Microsoft, Office 2010 on Windows XP SP3 is vulnerable to this security issue, so we can use that configuration for our analysis environment to trigger the exploit, and we can make changes along the way if we find that the exploit requires a different configuration for the payload to run. Running the Exploit To investigate the exploit’s execution, we run Microsoft Word 2010 in a debugger on Windows XP SP3 and set a breakpoint on the CALL DWORD PTR DS: line in the OGL!GdipCreatePath function that was shown in the crash snippet above. Once the breakpoint is set, we open the malicious document in the running Word process and we see that our breakpoint gets hit:
However, we can see in OllyDbg’s hint pane that points to OGL.44024C6E, an address in Microsoft Office’s OGL.DLL module. This surely isn’t the result of a hijacked EAX value, and if we have the debugger continue execution of the process, we see that the breakpoint gets hit again with the same value for EAX(0x440583A8); this will actually be the value of EAX for many breakpoint hits at this address. We’re only interested in the case where EAX is hijacked by the exploit to point somewhere interesting, so we can replace our current breakpoint with a conditional breakpoint:
With our conditional breakpoint now set, we can continue execution of the process, during which we’ll break at the following point:
We can see above that now points to an address in msvcrt.dll. Below, we can see that the instruction at that address in msvcrt.dll acts as a stack pivot, setting the stack pointer to the value of EAX (0x200F06B0).
The result of the stack pivot can be seen in OllyDbg’s stack pane below, with the RETN instruction returning to 0x77C34FBF (the address on the top of the stack):
As can be seen below, the instruction at 0x77C34FBF POPs the stack value after 0x77C34FBF
If we were to continue execution, the Word process would crash, leaving the rest of the payload unexecuted. Based on these results, it is apparent that either the exploit is broken, or it is meant for a different environment than our test environment. In either case, we’d still like to know the intent of the payload, so we need to take a closer look at the memory region containing the pivoted stack:
As can be seen above, this heap memory region contains a 0x700-byte “header”, followed by a spray of 0x400 bytes (highlighted in gray), repeating 512 times. We can actually see this heap spray (of size 0x00081000 bytes) repeated throughout several heap memory regions:
This heap spray is a result of all of the activeX*.bin files embedded in the Word document, each of which contains the 512 occurrences of the 0x400-byte ROP-chain block highlighted above:
The stack pivot that occurred during our testing above resulted in a new stack pointer of 0x200F06B0. However, this value is 0x3B0 bytes into one of the repeated ROP-chain blocks (0x50 bytes before the beginning of the next ROP-chain block). Common sense would suggest that the ROP-chain execution was meant to begin at the beginning of the ROP-chain block, not 0x3B0 bytes into it.
We can test this hypothesis by running the exploit back through OllyDbg, and this time changing the value of ESP before executing the RETN instruction after the stack pivot to point to the beginning of the next ROP-chain block:
Note that we use 0x200F0704 instead of 0x200F0700, since 0x200F0700 points to the stack pivot instruction that was just executed.
Now when we step through the ROP-chain, we see the following instructions executed:
|
ESP Before Previous RETN |
Virtual Addresses of Instructions |
Instructions |
Comments |
|
0x200F0704 |
0x77C3B860 0x77C3B861 |
POP EAX RETN |
EAX = 0xFFFFFFFF |
|
0x200F070C |
0x77C1BE18 0x77C1BE1A 0x77C1BE1B |
NEG EAX POP EBP RETN |
EAX = 0x00000001 EBP = 0x84CBC460 |
|
0x200F0714 |
0x77C2362C 0x77C2362D |
POP EBX RETN |
EBX = 0x77C5D9BB |
|
0x200F071C |
0x77C2E071 0x77C2E072 0x77C2E074 |
XCHG EAX, EBX ADD BYTE PTR DS:, AL RETN |
EAX = 0x77C5D9BB EBX = 0x00000001 |
|
0x200F0720 |
0x77C50D13 0x77C50D14 |
POP EDX RETN |
EDX = 0xFFFFFFC0 |
|
0x200F0728 |
0x77C58FBC 0x77C58FBD |
XCHG EAX, EDX RETN |
EAX = 0xFFFFFFC0 EDX = 0x77C5D9BB |
|
0x200F072C |
0x77C1BE18 0x77C1BE1A 0x77C1BE1B |
NEG EAX POP EBP RETN |
EAX = 0x00000040 EBP = 0x6C5BA53B |
|
0x200F0734 |
0x77C58FBC 0x77C58FBD |
XCHG EAX, EDX RETN |
EAX = 0x77C5D9BB EDX = 0x00000040 |
|
0x200F0738 |
0x77C3EE15 0x77C3EE16 |
POP EBP RETN |
EBP = 0x77C3EE15 |
|
0x200F0740 |
0x77C3EEEF 0x77C3EEF0 |
POP ECX RETN |
ECX = 0x77C5D9BB |
|
0x200F0748 |
0x77C2A88C 0x77C2A88D |
POP EDI RETN |
EDI = 0x77C39F92 |
|
0x200F0750 |
0x77C3A184 0x77C3A185 |
POP ESI RETN |
ESI = 0x77C2AACC |
|
0x200F0758 |
0x77C3B860 0x77C3B861 |
POP EAX RETN |
EAX = 0x77C11120 (VirtalProtect) |
|
0x200F0760 |
0x77C12DF9 0x77C12DFA |
PUSHAD RETN |
PUSH EAX, ECX, EDX, EBX, ESP, EBP, ESI, AND EDI |
|
0x200F0744 |
0x77C39F92 |
RETN | |
|
0x200F0748 |
0x77C2AACC |
JMP DWORD PTR DS: |
VirtualProtect( This makes the page containing address 0x200F0764 executable |
|
0x200F074C |
0x77C3EE15 0x77C3EE16 |
POP EBP RETN |
EBP = 0x77C11120 (VirtalProtect) |
|
0x200F0764 |
0x77C35459 0x77C3545A |
PUSH ESP RETN |
Jumps to shellcode at 0x200F0768 |
The hard-coded addresses in the ROP-chain target msvcrt.dll version 7.0.2600.5512 (specific to Windows XP SP3), and while the ROP-chain is similar to public ROP-chains, it contains a few different ROP-gadgets, perhaps to subvert security software that would otherwise detect the publicly documented ROP-chains.
The shellcode at 0x200F0768 begins with a loop to XOR the obfuscated shellcode, followed by a Metasploit-based payload:
|
seg000:200F0768 seg000:200F076E seg000:200F0771 seg000:200F0773 seg000:200F0779 seg000:200F077B seg000:200F0780 seg000:200F0784 seg000:200F0785 seg000:200F0787 seg000:200F0789 seg000:200F078C seg000:200F078F seg000:200F0792 seg000:200F0794 seg000:200F0795 seg000:200F0820 seg000:200F079A seg000:200F079B seg000:200F079E seg000:200F07A4 seg000:200F07A8 seg000:200F07A9 seg000:200F07AE seg000:200F07B0 seg000:200F07B4 seg000:200F0812 seg000:200F0817 aRundll32 db 'rundll32',0 seg000:200F07B6 seg000:200F07B7 seg000:200F07BA seg000:200F07BB seg000:200F07BC seg000:200F07BE seg000:200F07BF seg000:200F07C0 seg000:200F07C5 seg000:200F07C6 seg000:200F07C7 seg000:200F07C8 seg000:200F07C9 seg000:200F07CA seg000:200F07CF seg000:200F07D1 seg000:200F07D3 seg000:200F07D5 seg000:200F07D7 seg000:200F07DA seg000:200F07DB seg000:200F07DC seg000:200F07DE seg000:200F07DF seg000:200F07E1 seg000:200F07E6 seg000:200F07E8 seg000:200F07E9 seg000:200F07EE seg000:200F0825 seg000:200F07F0 seg000:200F07F1 seg000:200F07F3 seg000:200F07F8 seg000:200F07FA seg000:200F07FB seg000:200F07FC seg000:200F07FD seg000:200F0801 seg000:200F0802 seg000:200F0803 seg000:200F0804 seg000:200F0806 seg000:200F080B seg000:200F080D seg000:200F0945 seg000:200F094A seg000:200F094F seg000:200F0951 seg000:200F0953 seg000:200F0955 seg000:200F0958 seg000:200F095A seg000:200F095F seg000:200F0961 seg000:200F0962 |
The shellcode above runs the program “rundll32” as a suspended process, injects code into that process, and creates a new thread in that process to run the injected code. The injected code is as follows, based on the reverse_tcp module and the shell module from Metasploit:
|
seg000:200F082A seg000:200F082B seg000:200F08B9 seg000:200F08BA seg000:200F08BF seg000:200F08C4 seg000:200F08C5 seg000:200F08CA seg000:200F08CC seg000:200F08D1 seg000:200F08D3 seg000:200F08D4 seg000:200F08D5 seg000:200F08DA seg000:200F08DC seg000:200F08DD seg000:200F08DE seg000:200F08DF seg000:200F08E0 seg000:200F08E1 seg000:200F08E2 seg000:200F08E3 seg000:200F08E4 seg000:200F08E9 seg000:200F08EB seg000:200F08ED seg000:200F08F2 seg000:200F08F2 seg000:200F08F7 seg000:200F08F9 seg000:200F08FB seg000:200F08FC seg000:200F08FD seg000:200F0902 seg000:200F0904 seg000:200F0909 seg000:200F090B seg000:200F090C seg000:200F090D seg000:200F090E seg000:200F0910 seg000:200F0912 seg000:200F0913 seg000:200F0914 seg000:200F0916 seg000:200F091D seg000:200F0921 seg000:200F0924 seg000:200F0925 seg000:200F0926 seg000:200F0927 seg000:200F0928 seg000:200F0929 seg000:200F092A seg000:200F092B seg000:200F092C seg000:200F092D seg000:200F092E seg000:200F092F seg000:200F0930 seg000:200F0935 seg000:200F0937 seg000:200F0939 seg000:200F093A seg000:200F093B seg000:200F093C seg000:200F093E seg000:200F0943 seg000:200F0945 seg000:200F094A seg000:200F094F seg000:200F0951 seg000:200F0953 seg000:200F0955 seg000:200F0958 seg000:200F095A seg000:200F095F seg000:200F0961 seg000:200F0962 |
With the adversary’s IP address discovered, CrowdStrike was able to notify our customers to help them better defend their networks. We were able to provide them with actionable intelligence that would not have been available to them with traditional security software.
