Tips for Office VBA Macro analysis

[AtlBo]

I believe VB in Office is supposedly there for the sake of automation of MS Office/office tasks (as mentioned by @Andy Ful). Within Office, the language supports finding and grabbing data in row/column of a spreadsheet or database A, etc. to move the data to word B or to another Excel file or even mail it in Outlook or whatever. It can also fetch data in an MSO file or in some other standard database across the intra/internet, for example, when a file is opened, etc. I guess the problem is introduced as a result of the fact that VB can be also used to update files and tabs from outside of Office on a timed schedule, etc. and then that it can be used to manipulate non-Office files on a system (create/delete, etc.) Worst of all it can apparently be used to create an executable file outside of MSO. This should not be possible imo. As far as I know all of the functions of MSO are activatable and usable via VB macro in Office...almost an infinite combination of possibilites here. Then too I am 90% sure that Java or other languages can also be added to MSOs macro interface for use (just for knowledge sake if someone knows). VB is really powerful in Office though. Don't think companies would ever need another language for getting the most from MSO if it could be trimmed to a safe MSO only language.

As mentioned, one question I have is whether VB can be used from within MSO to create files of a format other than supported by MSO. I assume this is easily possible, since file drops can happen from an actual infected file. Seems to me this would be a good place to start limiting the capabilities of VB. Why shouldn't MS think of it as a macro language for use exclusively from within documents for operations on MSO documents?

Actually, I am fairly impressed that MS could easily clean up VB and limit its usability inside and outside of Office. The language seems to me to just simply be too powerful. MS could have a great leg up on everyone if VB were safe to use.

I also have had a similar question about VBS, which is why is it even useful or usable outside of Office. There are a dozen languages other than VB that someone could use for interacting with MSO data or automating tasks, etc. How many languages do there have to be? LOL, maybe the test for creating a safe new language for macros in MSO should be to ask of each capability whether in its current form it would run in a script host...if yes, then change or remove the capability. This would require companies to take the time to write apps in order to automate beyond simple macro in and across file automation. VB could be limited then to automation during standard use of MSOffice files...from one MSO document to another or from MSO document to a common database format or whatever...never creation of a file of a format other than MSO or known database (definitely not any sort of executable)...

I'm more or less a noob with VB, but I have seen how powerful it can be just within a single Office file. Excel can basically be turned into a program creation tool (even with only MSO data references), honestly, and it's very useful in this way. IMO, it's worth saving for that reason. That said, I could see why someone would just say punt MSO and go back to old school application building making use of old fashioned databases. Don't think this would be any safer though, considering VB should be improvable (in my best estimation anyway) to the point that it could be considered safe to use macros for working with MSO documents...

 

[509322]

The language seems to me to just simply be too powerful.

If you think it is powerful, then you ain't seen nothin' yet. PowerShell is to VB as a nuclear missile is to a bottle rocket.

We cannot protect people from Microsoft.

 

[AtlBo]

We cannot protect people from Microsoft.

Hmmm...well, I will say it. I didn't like the idea of command prompt in the beginning. Then I thought it was ludicrous later to have two such applications in Windows, while still believing command prompt was too powerful. PowerShell seems to me to be a computing blasphemy. I continue to wonder why MS didn't just refine the command dialog and focus on making it safe to have on a PC if it's going to be there. Primarily, however, I wondered why MS didn't just provide applications that support use of the capabilities of Windows, so that the swiss army knife could be simply disabled. Always been with you guys on that one, but I confess I run a few scripts for various reasons...

Imagine a caveman looking at Windows 3.1 back in 1995. That's was me, and I had to learn everything there was to learn about the OS. The focus for me was always on kernel data management and integration between Windows and the hardware interface. I became so lost in the nomenclature of Windows file names (back before information was readily available on the internet) in order to determine what it was that didn't sync properly with the hardware. Also, I wanted to understand MS' NTFS file extensions and what the types of files were supposed to do. Well, that was my introduction to thoughtless design..the art of a security vacuum if you will . As it turns out all of them can be used for anything...

 

[509322]

Hmmm...well, I will say it. I didn't like the idea of command prompt in the beginning. Then I thought it was ludicrous later to have two such applications in Windows, while still believing command prompt was too powerful. PowerShell seems to me to be a computing blasphemy. I continue to wonder why MS didn't just refine the command dialog and focus on making it safe to have on a PC if it's going to be there. Primarily, however, I wondered why MS didn't just provide applications that support use of the capabilities of Windows, so that the swiss army knife could be simply disabled. Always been with you guys on that one, but I confess I run a few scripts for various reasons...

Imagine a caveman looking at Windows 3.1 back in 1995. That's was me, and I had to learn everything there was to learn about the OS. The focus for me was always on kernel data management and integration between Windows and the hardware interface. I became so lost in the nomenclature of Windows file names (back before information was readily available on the internet) in order to determine what it was that didn't sync properly with the hardware. Also, I wanted to understand MS' NTFS file extensions and what the types of files were supposed to do. Well, that was my introduction to thoughtless design..the art of a security vacuum if you will . As it turns out all of them can be used for anything...

Microsoft's well-known, notorious way of solving security problems is not to remove the source of the security risk, but instead to add ever more increasing layers of convoluted complexity to solve the security problems that Microsoft itself created.

Spaghetti security on a duct-tape OS.

 

[shmu26]

Thanks @Andy Ful and @AtlBo for the explanations about VBS. That's interesting.
Regarding Atlbo's suggestions on controlling VBS actions, MS could create a "constrained language" for it (sort of like they did for Powershell), that would restrict it from performing actions outside of the MSO environment. How does that sound?

 

[Andy Ful]

Thanks @Andy Ful and @AtlBo for the explanations about VBS. That's interesting.
Regarding Atlbo's suggestions on controlling VBS actions, MS could create a "constrained language" for it (sort of like they did for Powershell), that would restrict it from performing actions outside of the MSO environment. How does that sound?

It is too late for that. VBScript is used mostly in Enterprises for compatibility with scripts from some years ago or for compatibility with old hardware. Those scripts might not work well in the "constrained language". It is like PowerShell 2.0 (but older) which also does not use "constrained language". In home environment Windows Script Host can be safely disabled in most cases.

 

[AtlBo]

It sounds good to me .

However, it's for me as much about which types of files MSO and VB can perform operations on as anything. Just limiting this would go a long way toward fixing the VB problem. What difference does it make what MSO downloads or uploads using the language as long as it's not an executable. For all purposes, we are back to discussing nothing but vulnerabilities of the actual MSO program instead of its macro language. There are still issues about data security in this scenario, of course. Noone wants their private research data, etc. being thrown around all over the world. However, I suppose 99+% of the real danger in macros is gone if association of VB to executables is removed. Now it's simply a matter of making sure that access to files is properly managed, so that the private data is protected. Well, that and removing Powershell's manipulative capabilities with regards to MSO from that template of disregard for securability.

With this in place, anyone could create what amounts to an application in Excel or even Access, using the tools there to update data automatically and etc., yet MSO would be powerless to execute or create and execute anything malicious, since VB no longer is able to perform this function. The workings of the created application would be contained inside a restricted MSO environment as you say.

 

[shmu26]

In home environment Windows Script Host can be safely disabled in most cases.

Yet it seems that Windows is still merrily using VBS and Wscript.
A couple days ago, I caught this script, blocked by OSArmor (default settings) on Win10 1809. Either it was a Windows maintenance script, or... oh no...

Date/Time: 10/23/2018 7:56:10 AM
Process: [6472]C:\Windows\System32\wscript.exe
Process MD5 Hash: F5E5DF6C9D62F4E940B334954A2046FC
Parent: [1304]C:\Windows\System32\svchost.exe
Rule: BlockVbsScripts
Rule Name: Block execution of .vbs scripts
Command Line: C:\WINDOWS\System32\WScript.exe "C:\WINDOWS\system32\gatherNetworkInfo.vbs"
Signer:
Parent Signer: Microsoft Windows Publisher
User/Domain: SYSTEM/NT AUTHORITY
System File: True
Parent System File: True
Integrity Level: System
Parent Integrity Level: System

EDIT: I just noticed that it says "Integrity Level: System". So it must be a Windows maintenance script. I don't think my system was totally pwned.

 

[AtlBo]

EDIT: I just noticed that it says "Integrity Level: System". So it must be a Windows maintenance script. I don't think my system was totally pwned.

I have seen this before @shmu26. I LOLed out of my eyesockets when I saw it for the first time I have to say. This is MS using the same bad practices they say others should never use. You haven't been pwned, but I am kind of surprised that happened in W10. I saw it in W7.

Here's some information:

What is GatherNetworkInfo.vbs and is it a Security Risk? - Appuals.com

 

[Eddie Morra]

Well... this thread has skyrocketed!

I was eyeing up the thread last night when it was booming with replies but I was distracted so I couldn't read what anyone was saying.

I'll catch up later... you guys are going to return tonight and find tons of Like spam on your Alerts.

 

[shmu26]

I have seen this before @shmu26. I LOLed out of my eyesockets when I saw it for the first time I have to say. This is MS using the same bad practices they say others should never use. You haven't been pwned, but I am kind of surprised that happened in W10. I saw it in W7.

Here's some information:

What is GatherNetworkInfo.vbs and is it a Security Risk? - Appuals.com

Thanks.
In earlier versions of Win10, there was a very similar script, but it ran from powershell. @Lockdown explained to me once or twice what it does, and how pitifully unnecessary it is.

@Eddie Morra, go ahead, spam me, I dare you

 

[Andy Ful]

...
With this in place, anyone could create what amounts to an application in Excel or even Access, using the tools there to update data automatically and etc., yet MSO would be powerless to execute or create and execute anything malicious, since VB no longer is able to perform this function. The workings of the created application would be contained inside a restricted MSO environment as you say.

You have just invented WD ASR rules.

 

[Andy Ful]

Yet it seems that Windows is still merrily using VBS and Wscript.
A couple days ago, I caught this script, blocked by OSArmor (default settings) on Win10 1809. Either it was a Windows maintenance script, or... oh no...

Date/Time: 10/23/2018 7:56:10 AM
Process: [6472]C:\Windows\System32\wscript.exe
Process MD5 Hash: F5E5DF6C9D62F4E940B334954A2046FC
Parent: [1304]C:\Windows\System32\svchost.exe
Rule: BlockVbsScripts
Rule Name: Block execution of .vbs scripts
Command Line: C:\WINDOWS\System32\WScript.exe "C:\WINDOWS\system32\gatherNetworkInfo.vbs"
Signer:
Parent Signer: Microsoft Windows Publisher
User/Domain: SYSTEM/NT AUTHORITY
System File: True
Parent System File: True
Integrity Level: System
Parent Integrity Level: System

EDIT: I just noticed that it says "Integrity Level: System". So it must be a Windows maintenance script. I don't think my system was totally pwned.

This script is part of Microsoft's networking controls to improve network-related performance of Windows. It is triggered with System rights by the scheduled task NetTrace/GatherNetworkInfo. Here is some information about it:
The GatherNetworkinfo.vbs Script
It also makes a deep analysis of the system: Architecture / Processor Information, Clean vs Upgraded system, Devices, Firewall settings, Operating System Information, Other system info, Power info, Services, User info.
The safest way is blocking VBScript or JScript when run as standard user (not elevated) - this can be done via Windows built-in SRP.

Edit.
I looked at my sheduled tasks and this task was never performed on my system.

 

[shmu26]

[QUOTE="Andy Ful, post: 772937, member: 32260"
The safest way is blocking VBScript or JScript when run as standard user (not elevated) - this can be done via Windows built-in SRP.
[/QUOTE]
Right. I like that.
ReHIPS is also set up somewhat similarly -- it has a different and more lenient set of rules for SYSTEM

 

[Andy Ful]

Back to VBA macros. @Eddie Morra showed how to use the debugger to start analyzing macros. One can also use Exploit Guard mitigation 'Do not allow child processes', ASR rules, 'Network protection', and 'Ransomware protection' for analysis (Audit mode). The Windows Event Viewer can be used to see the actions performed by the macro:
Import custom views to see attack surface reduction events
Of course, this has to be done only in the safe, malware testing environment.