Tips for Office VBA Macro analysis

[Eddie Morra]

Hiya

I noticed that there isn't a discussion thread for malware analysis on Office VBA Macro's yet... maybe it is time we started one. It could be really helpful to other members of the community if people contribute to this discussion because malicious Microsoft Office documents are incredibly prevalent in the wild (one of the most loved deployment methods by malware spreaders in the current era we live in) and most of the time, it's going to be a malicious macro script instead of an RCE vulnerability being used to gain code execution on the machine.

I'll start us off with one dynamic tip...

1. Start the Microsoft Office software the malicious document is for (e.g. msword.exe).
2. Break-point on / use API Monitoring on NtCreateProcess (NTDLL), NtCreateProcessEx (NTDLL) and NtCreateUserProcess (NTDLL).
3. If the malicious macro script attempts to spawn a process, your break-point/API monitoring hook will be triggered.

You can then check the arguments for the API call to determine the image file name of the target to be executed (as well as command-line information).

This trick can be helpful to dynamically analyse whether the script has dropped any PE's to disk and is trying to initiate usage of them (e.g. rundll32.exe to work a dropped DLL, spawn a new process for a dropped executable, etc.) or is trying to move to another script interpreter like PowerShell.exe.

This thread doesn't need to be a full-on analysis discussion, but it could be used to exchange quick tips which will help others when analysing Microsoft Office documents. I'm sure other members like @Andy Ful will have some tips to share when it comes to deobfuscation of scripts!

Ciao

 

[shmu26]

So here's a question from someone without a technical background:
AFAIK the typical MS Office macro attack is going to leverage Windows Script Host at the first stage. Is a script file typically spawned at some point in the sequence, or is the code loaded directly into wscript?

 

[509322]

So here's a question from someone without a technical background:
AFAIK the typical MS Office macro attack is going to leverage Windows Script Host at the first stage. Is a script file typically spawned at some point in the sequence, or is the code loaded directly into wscript?

Malicious Office documents are typically used as download cradles.

First off, you have to have macros enabled. If you don't do that, then there is nothing to worry about. Period.

Secondly, a malicious Office document should be easy for most people to immediately pick-off as being bogus. (I am not even going to address a document that contains an obviously suspicious download link.)

Thirdly, and I just don't know where this comes from, there are those that fret that an Office document created at safe party A will somehow end up malicious by the time it hits their system, party B. Or that shared documents are at huge risk of being malicious or somehow being made malicious. There are those that think documents without macros are malicious. This is all just plain crazy paranoia. Needless, and not based in reality.

Malicious Office documents are blown way out of proportion.

Most people here and out there... they want it all to be taken care of by the security soft they installed. They are addicted to and therefore enslaved by the security soft. "How dare you expect us to actually do some work !" And it is pointless... if they simply use something other than Office or just don't enable macros. 99.99 % of people don't need macros. And macros don't magically get injected into malicious documents.

Malicious Office documents is one of the most fear-driven, paranoid security topics out there.

 

[ForgottenSeer 69673]

I use LibreOffice and it has an option to run a macro. I have not checked it on a macro to see if it offers a popup to run it or auto runs it. There is no option that I can see to turn it off.

 

[509322]

I use LibreOffice and it has an option to run a macro. I have not checked it on a macro to see if it offers a popup to run it or auto runs it. There is no option that I can see to turn it off.

You got to reach out to LibreOffice on that one.

The specificity of macros is another huge misunderstanding. That means a malicious macro made in Office for Office more than likely will not work in another office suite.

Some people think a malicous macro is generic and will work if macros are enabled in any office suite. No. It doesn't work that way.

 

[Eddie Morra]

Is a script file typically spawned at some point in the sequence, or is the code loaded directly into wscript?

It can be either but it is attack-dependent. It depends on what the malware author decided to do.

They can download a PowerShell script to-disk and then spawn PowerShell.exe to run the script, or they can spawn PowerShell.exe and pass command line arguments without needing to download and drop anything additional to-disk.

For some reason, Microsoft allow networking routines to be used by Office VBA Macro's - supporting downloading functionality. I have no idea who in the world is actually going to need this for a legitimate purpose, but it is what it is.

 

[shmu26]

Malicious Office documents are typically used as download cradles.

This might answer my question. I recall from the old CS videos, before Comodo even had embedded code detection, that Comodo would stop every malicious doc she ran on her desktop. So Comodo was stopping the payload, but not the script that spawned it?

If this is the case, then you don't even need to worry about the macros so much, as long as you have some kind of default/deny setup, even just something that blocks unsigned files = the payload.

 

[509322]

For some reason, Microsoft allow networking routines to be used by Office VBA Macro's - supporting downloading functionality. I have no idea who in the world is actually going to need this for a legitimate purpose, but it is what it is.

If you can figure that one out, then you need to be made CEO of Microsoft.

 

[509322]

This might answer my question. I recall from the old CS videos, before Comodo even had embedded code detection, that Comodo would stop every malicious doc she ran on her desktop. So Comodo was stopping the payload, but not the script that spawned it?

If this is the case, then you don't even need to worry about the macros so much, as long as you have some kind of default/deny setup, even just something that blocks unsigned files = the payload.

Like Eddie said, you can have self-contained attacks that do not need a download using the network. The macro can call an interpreter (or sponsor) and pass arguments to it. And bazang !

Just disable the usual suspects and you can let malicious documents have at it on your system all day long without worry. Sort of like sitting inside a Merkeva while someone is shooting at it with an AK47.

 

[shmu26]

Like Eddie said, you can have self-contained attacks that do not need a download using the network. The macro can call an interpreter (or sponsor) and pass arguments to it. And bazang !

Whether or not the payload is downloaded, the typical attack will spawn an exe file, one way or another?
I know there are more advanced attacks that can spawn dll files, but I am asking about the garden-variety malicious doc.

 

[Andy Ful]

My observations about malicious macros.

1. Most macros simply download payloads and execute them.
2. Macros can use wscript (cscript) or any other interpreter (PowerShell, mshta.exe, hh.exe, etc.) as a child process of an office application to run the script (scriptlet) payload.
3. Macros can use interpreters to download and run payloads filelessly.
4. Macros do not need any interpreter to download and run payloads (also filelessly).
5. Macros can run payloads without spawning typical child processes.
6. Macros can run any type of payloads (also shellcode).
7. Macros are very dangerous, but malc0ders are usually too lazy, and use mostly the point 1.

Macros in documents can be easily disabled (no alert) by using the right setting in Word, Excel, etc. But, this setting can be easily changed by any malware. More safe are Windows policies which can be changed only with admin rights.

 

[509322]

My observations about malicious macros.

1. Most macros simply download payloads and execute them.
2. Macros can use wscript (cscript) or any other interpreter (PowerShell, mshta.exe, hh.exe, etc.) as a child process of an office application to run the script (scriptlet) payload.
3. Macros can use interpreters to download and run payloads filelessly.
4. Macros do not need any interpreter to download and run payloads (also filelessly).
5. Macros can run payloads without spawning typical child processes.
6. Macros can run any type of payloads (also shellcode).
7. Macros are very dangerous, but malc0ders are usually too lazy, and use mostly the point 1.

Macros are not dangerous if people do not enable macros. Only the brain dead cannot grasp this ON\OFF concept.

And Microsoft's solutions to deal with them is even worse than the malicious macros in the first place.

 

[509322]

Whether or not the payload is downloaded, the typical attack will spawn an exe file, one way or another?
I know there are more advanced attacks that can spawn dll files, but I am asking about the garden-variety malicious doc.

It can be .exe, script file, .tmp file, etc. There is a long list of executable code\file types.

What @Andy Ful mentions about shellcode is mostly within the realm of exploits.

I don't understand why the issue of malicious macros is such a focus. If you don't use macros, then you have nothing to worry about. A malicious macro can't magically enable itself. You have to enable macros for it to run.

 

[509322]

I've seen people who will not use a security solution because in some report or video it did not do well against a malicious document. And the person doesn't even have Microsoft Office installed ! Not having Office installed means that person is immune to Microsoft Office-based attacks !

The logic goes something like this... if the security product cannot handle malicious documents, then it must be flawed in some other hidden, unknown ways.

Wut ?

This is the stupidity on the forums.

 

[ForgottenSeer 69673]

Ok I did a bit of searching on LibreOffice and macros. I appears that if a document has a macro, LibreOffice will kick up a security warning just like Microsoft asking you to enable macros but it also allows you to go to tools , organize macros and delete the macro module all together. I see they even have a macro debugger in LibreOffice. Organizing Libraries and Modules - LibreOffice Help

 

[Andy Ful]

...
If you don't use macros, then you have nothing to worry about. A malicious macro can't magically enable itself. You have to enable macros for it to run.

Macros are not so dangerous because the malc0ders are lazy. Any simple exploit can change the macro setting to allow macros without alert and download/open the malicious document with advanced malicious macro. It can be used to bypass the security based on whitelisting or standard AV.

 

[AtlBo]

For some reason, Microsoft allow networking routines to be used by Office VBA Macro's - supporting downloading functionality. I have no idea who in the world is actually going to need this for a legitimate purpose, but it is what it is.

Doesn't this have to do mostly with updating data within office files across the internet or just maintaining updated and synced data banks? Grabbing data for presentations or reports and this kind of thing is what I mean. Yes, you can for this just write the app, but MSO does seem to be to be much more powerful to me with this capability in place. Generally, I think this is usually accounting data or sales data that is updated to a main database and from there referenced. So I think MS opened the internet channel to VB.

My question is, why isn't VB more tailored for safe use and use within Office only? By this I mean, why can't there be a secure and usable channel for working with office files via macro across the internet or an intranet that uses a properly refined and limited language? Seems to me there could be correlative software in MSO, also, designed for enforcement of security policy for office documents across an intranet or the internet. This would be "support" and assist with security policy enforcement, but MS obviously doesn't understand the first thing about the corporate work environment and how rigid it really must be. Don't think MS has 5 seconds thought in the securability of MS Office at this point, in spite of the fact that it's a main channel for potential trouble. All of this is strange to me considering the size of MS itself.

If you can figure that one out, then you need to be made CEO of Microsoft.

By the way, I read of an instance where a company was using office to maintain and monitor the functions of machinery across an entire assembly line. On the surface, I thought it was a kind of a cool idea, but it sure seemed clumsy to me to be using Excel to view data about the machines along the line, knowing the bits I know about Office and macros. They don't run very fast in my experience when operating on an Excel sheet or Word or whatever page. This company I think was updating data every 2 seconds. Working with data that way in Office is dangerous, anyway. You can grab data and it only be partly updated...if you grab it from an updating file. All kinds of weird things can happen.

Before running a questionable macro one thing I guess someone could do would be to take it to Microsoft Answers or StackOverflow and ask what the macro does.

 

[Eddie Morra]

I think that malicious Office VBA Macro's are dangerous in the sense that there's a lot of novices out there - both Home and Enterprise customers - who fail to grasp simple things such as not allowing macro's to run in the first place. While education on cyber-security has improved throughout businesses in most mainstream countries, it still isn't that pretty, and there's still a large group of people who will fall for simple tricks.

Realistically, malicious Office VBA Macro's aren't dangerous to people who follow good security practices and thus: a). do not use Microsoft Office in the first place; or b). use Microsoft Office but do not allow macro's to run. It's even better when you block script interpreters like PowerShell from being able to be used. The Web version of Microsoft Office still offers a lot of functionality and does not support macro's - you'll generally be safe on there.

Macro's aren't the only threat with Microsoft Office documents though. There have existed Remote Code Execution (RCE) vulnerabilities in the past (which have been used in the wild when they are not patched, or still are used for victims who are using outdated versions of Microsoft Office software) which can allow an attacker to gain code execution without any further user-interaction other than opening the malicious document. However, such are usually used in targeted attacks where the attacker is resourceful and knows what they are doing (which isn't usually the case with home-based attacks, let's face it). Due to this, such isn't really that much of a threat to average home-users, unless you truly have something valuable that an resourceful threat actor is after.

@Lockdown is completely correct about paranoia and people's expectations. I've seen what he has seen with people dropping security solutions over a malicious macro... even though, the simple option would be to just not run suspicious documents and certainly not then allow the macro to run in the first place. From a logical standpoint, no security software is going to prevent 100% of all types of attacks, it just isn't feasible... and thus dropping an Anti-Virus product because you as the user stupidly allowed a macro to run for no reason is bizarre at best.

Anti-Virus solutions are supposed to be back-ups and assist you but they are in no way a full replacement for your brain - something that many seem to forget.

Before running a questionable macro one thing I guess someone could do would be to take it to Microsoft Answers or StackOverflow and ask what the macro does.

I think this is a bad idea because if the Microsoft Office document is indeed malicious, you'd be potentially leading other people who are not skilled in cyber-security and malware analysis into catching an infection. You'd essentially be accidentally and unintentionally putting other people at risk, because you'd be spreading the malware, but not with the intention of anyone being hit by it.

Even if you were to note that the attachment may be malicious, it won't change much - people get curious and start looking at things they shouldn't. People on StackOverflow or Microsoft forums do not expect to find live malicious code (e.g. through downloads) and such isn't permitted there either, so you'd be violating the rules and then you'd be blamed for any damages.

Your best and safest bet is submitting the document to Anti-Virus vendors via their research labs which check submissions and add them to the database if they can confirm malicious activity or not; such employees will be skilled in malware analysis and digital forensics and will have a job for doing this.

 

[shmu26]

Although you need to ENABLE macros, there are all kinds of ingenious social engineering tricks that will motivate the unwitting novice to click here, follow the arrow, click there...
That's what worries me.

 

[Eddie Morra]

Although you need to ENABLE macros, there are all kinds of ingenious social engineering tricks that will motivate the unwitting novice to click here, follow the arrow, click there...
That's what worries me.

You're completely right. I agree.

Social engineering is huge and it goes way beyond malware development and spreading... it's to do with how our brains actually work and finding ways to trick us into doing things we wouldn't normally do.

As an example, you may have been taught to not give out certain information to strangers in real-life or online. However, through social engineering - some things may work on some people and not on others and vice-versa - you may break that rule without even realising it, and you may never notice until it is too late.

The same can be applied to a malicious download or a phishing website.

Social engineering is exploitation of us as human beings.