Currently Office Malware is 3 steps generally:
1. Encrypt/Obfuscate Your #Macro Dropper
2. Get Your Powershell/Java/JS/DLL flavor of the week onto the victim ASAP
3. Bug out
I want to change all of this, however before we do that we need to upgrade Office Malware
1. Encrypt/Obfuscate Your #Macro Dropper
2. Get Your Powershell/Java/JS/DLL flavor of the week onto the victim ASAP
3. Bug out
I want to change all of this, however before we do that we need to upgrade Office Malware
For now lets focus on the first step and why obfuscating/encrypting your macros not ideal.
1. Your code will eventually get deobfuscated
2. Your code is not unique - same sample <-> many targets
3. Most obfuscation methods = Noise/Signatures
4. Your code becomes evidence
1. Your code will eventually get deobfuscated
2. Your code is not unique - same sample <-> many targets
3. Most obfuscation methods = Noise/Signatures
4. Your code becomes evidence
Back in the 90s and early 2000s macro's had the ability to modify their own code using the VBE object.
You could literally write VBA code to write VBA code in itself.
Polymorphic macro viruses like W97M.Evolution and other nasties used this change their code on every exec
You could literally write VBA code to write VBA code in itself.
Polymorphic macro viruses like W97M.Evolution and other nasties used this change their code on every exec
Microsoft eventually removed the security feature of interacting with the VBE object by adding a security UI element in Office that prevents it.
This the ClickWall that prevents all of those shenanigans.
This the ClickWall that prevents all of those shenanigans.
Technically you can modify a registry key to get back into the poly macro party, but Office read's the key's value at launch - before Macro's execute and therefore cant be bypassed*
* there are a few ways to change the key and get this back but thats for another time and day
* there are a few ways to change the key and get this back but thats for another time and day
So losing this feature essentially made macro code static.
Your VBA code was in the document and therefore it stayed there even when your malware or pen test tool was analyzed it was all there laid out for the RE tools & team to take apart.
Your VBA code was in the document and therefore it stayed there even when your malware or pen test tool was analyzed it was all there laid out for the RE tools & team to take apart.
A few years ago some Macro VBA code started implementing Documents.Variables
This is a special RW section in Office documents that allows variables to be written to the document and stored there on every execution.
Malware authors used it to put DLL payloads - this is a waste.
This is a special RW section in Office documents that allows variables to be written to the document and stored there on every execution.
Malware authors used it to put DLL payloads - this is a waste.
I gave a presentation at #Hushcon on how Document.Variables can be used to store code & and then deleted upon execution
So Macros now do this:
1. Macro Executes
2. Macro reads features, variables, and obfuscation keys are stored in Doc.Vars
3. Macro nukes all vars after exec.
So Macros now do this:
1. Macro Executes
2. Macro reads features, variables, and obfuscation keys are stored in Doc.Vars
3. Macro nukes all vars after exec.
RE & Sandbox get already executed doc and analyze it and it breaks (or better yet exec diff code to throw off RE team #opsec)
There is 2 issues with this:
A. Email Sever still has unexecuted sample and can be used to RE
B. All the cool kids like @decalage2 added Doc.Vars sigs
There is 2 issues with this:
A. Email Sever still has unexecuted sample and can be used to RE
B. All the cool kids like @decalage2 added Doc.Vars sigs
So how do we fix this?
We need a way to get polymorphic self-deleting code into a document at runtime with as little red flags as possible.
And with that, let me introduce you to 2 wonderful methods:
InlineShapes.AddPicture & Range.EnhMetaFileBits
We need a way to get polymorphic self-deleting code into a document at runtime with as little red flags as possible.
And with that, let me introduce you to 2 wonderful methods:
InlineShapes.AddPicture & Range.EnhMetaFileBits
AddPicture is exactly what it says on the tin.
It adds a picture from src to the document as an inlineshape object.
And as i mentioned in early tweets - it will happy grab an image from HTTP[S] and slam it right into your document
It adds a picture from src to the document as an inlineshape object.
And as i mentioned in early tweets - it will happy grab an image from HTTP[S] and slam it right into your document
Another key point with this is we dont need to call any Win32 API or outside code to get this file.
The request is done via Office itself and thus making your code less likely to get caught.
Additionally InlineShapes are used in legit macro often.
The request is done via Office itself and thus making your code less likely to get caught.
Additionally InlineShapes are used in legit macro often.
The other part of this puzzle is EnhMetaFileBits and its really the star of the show
This allows VBA to read the content of a image file.
And since this file is embedded in the document, we are not reading any external files - again a win for anti-heuristics.
This allows VBA to read the content of a image file.
And since this file is embedded in the document, we are not reading any external files - again a win for anti-heuristics.
Combining these 2 you can use the EMF file to store commands and strings.
Use the following code to download and read variables from img files.
Your macro should be a husk file that calls functions/methods (ie via CallbyName) with these variables and contain garbage functions
Use the following code to download and read variables from img files.
Your macro should be a husk file that calls functions/methods (ie via CallbyName) with these variables and contain garbage functions
Your Opsec is now this:
- Send Malicious Office File with partial code (husk)
- Target Executes Office File
- Target's Office Connects over HTTPS to your C2C
- Sever Validates Target & Delivers Image
- Malicious Office Reads Image Commands
- Nuke Image
- C2C hosts fake payload
- Send Malicious Office File with partial code (husk)
- Target Executes Office File
- Target's Office Connects over HTTPS to your C2C
- Sever Validates Target & Delivers Image
- Malicious Office Reads Image Commands
- Nuke Image
- C2C hosts fake payload
- Or tear down C2C up to you
After your malware is discovered and tossed in a sandbox they will see:
- HTTPS to C2C
- downloaded an image
- read byte content content
- used bytes to perform actions
RE will be never 100% accurate since its only partial
After your malware is discovered and tossed in a sandbox they will see:
- HTTPS to C2C
- downloaded an image
- read byte content content
- used bytes to perform actions
RE will be never 100% accurate since its only partial
TLDR; InlineShapes.AddPicture + Range.EnhMetaFileBits lets macro malware develop polymorphic self-deleting code that would be very hard to RE if your delivery macro malware is laid out properly.
I should prob just get a medium for all of this.
Anyways enjoy kids
I should prob just get a medium for all of this.
Anyways enjoy kids
