WMI Attacks

[shmu26]

The news says that WMI attacks are on the rise. What is meant by "WMI attack", and which Windows processes does it abuse?
Do the advanced security solutions that are commonly used by forum members provide adequate protection against this type of attack?

 

[TairikuOkami]

Basically Windows Management Instrumentation service. Disable it and most wmi commands will stop working, like taskkill.
That is the pros and the cons, since some commands can be useful, but WMI is not really necessary for everyday computing.

 

[Eddie Morra]

Windows Management Instrumentation (WMI) is liked by attackers because it can be used in file-less attacks, is simple to work and automate tasks with, and it is usually always enabled on a traditional Windows environment. You can use WMI straight from VBScript and PowerShell which is always a bonus for attackers because they tend to like using those as well.

I recommend you seek the official WMI documentation by Microsoft to learn more about what can be done with WMI. There's a lot that can be done with it.

Some vendors have written articles/papers on WMI from a threat-research perspective:
WMI Abused for Malware Operations - TrendLabs Security Intelligence Blog
Explained: WMI hijackers - Malwarebytes Labs
http://la.trendmicro.com/media/misc/understanding-wmi-malware-research-paper-en.pdf

 

[JM Safe]

WMI can be used also to manage processes operations in .NET

 

[Sunshine-boy]

With ERP beta you can control which process access the wmi.

 

[shmu26]

Does ERP have default rules for controlling WMI?

 

[Andy Ful]

Does ERP have default rules for controlling WMI?

Most WMI attacks use : wmic.exe, scrcons.exe, PowerShell, Windows Script Host, wbemtest.exe. They can be controlled via SRP or Anti-Exe. The best method is using default-deny setup and disabling active content in documents. Constrained Language Mode can stop WMI hijacking via PowerShell.
The alternative to disabling the WMI service can be configuring DCOM protocol to use a single port and then block that port (see the link below).
Setting Up a Fixed Port for WMI

Blocking WMI service can be risky even for computers in the home network.

 

[509322]

Does ERP have default rules for controlling WMI?

WMI is abused. It isn't the only actor in a "WMI attack." There isn't "WMI-only" malware, at least not that I am aware of.

WMI should not be disabled. However, all the stuff that calls it in an attack should be disabled and\or not used outright.

The answer is the same as the basic answer to all the other attacks out there ad infinitum... and that is to disable the commonly abused Windows processes (PowerShell, PowerShell_ISE, PowerShell .dll loading, wscript, cscript, etc, etc) and only allow stuff temporarily when you need it, don't use macros, use something other than Microsoft Office programs, etc.

It's the same thing. Over-and-over. It's a formula that works. Testing has proven it across decades over-and-over. It's a formula that will never go out of style because it will always work. Sort of like $500 wing-tip shoes. Understated. Reliable. Always work.

If you want convenience and usability, then you will have to sacrifice some security. You are not going to get the protections you want without some work and sacrifice. You cannot install a program and say to yourself "OK... now I'm protected." No matter how much they want you to believe that, it just ain't true... at least not in the sense that "I'm protected" means to you in your mind. What they mean is that figuratively... "You are decently protected - and not perfectly - with our soft installed." If you want very high protection, meaning security soft geek protection, then everyone who knows better knows that involves some form of default-deny where the user has had to make tweakings and configurations, reduced attack surface, and has accepted accepted some level of, what others incorrectly perceive and rate as, "unacceptable" inconvenience or annoyances.

 

[shmu26]

Thanks to all, especially @Andy Ful and @Lockdown.

What are the most common attack vectors for WMI attacks?
The first thing that comes to my mind is MS Office docs.
Lately I haven't heard so much about active PDF exploits in the wild. Is that because Adobe Reader's new AppContainer is effective?

 

[509322]

Thanks to all, especially @Andy Ful and @Lockdown.

What are the most common attack vectors for WMI attacks?
The first thing that comes to my mind is MS Office docs.
Lately I haven't heard so much about active PDF exploits in the wild. Is that because Adobe Reader's new AppContainer is effective?

1. Weaponized documents, scripts, malicious .exe... downloaded as email attachments or from unknown\untrusted sources.
2. Macros can, for example, call WMI and have it launch PowerShell or other interpreters in an unusal way.
3. They're just not finding the exploits. It's got nothing to do with AppContainer. I see people keep mentioning AppCotainers and browser sandboxes and such. While all of them add a layer of defense (equivalent to a speed bump here in the real world), they have been shown to be defeatable (just as everyone can get over a speed bump in the road). The best deterrent is not to use Adobe products. Anti-exploits aren't worth all the associated problems and annoyances - which I know you are already aware they're a real pain.
And don't gage things by the rate of exploit reports in the IT security news as it is a terrible indicator of what is actually happening in user-land.

 

[shmu26]

Executable script files and .exe files are protected pretty well by the popular default/deny solutions.
So the remaining attack vector is weaponized documents?

 

[509322]

So the remaining attack vector is weaponized documents?

If you need to use macros, then SRP is perfect. Just disable the usual suspects. That's because malicious macros achieve their dirty deeds by using the usual suspects.

Some weaponized documents are merely download cradles. While others, most often using macros that abuse Windows processes, can do more than merely download a file, or do stuff in more less-obvious ways.

 

[shmu26]

Most WMI attacks use : wmic.exe, scrcons.exe, PowerShell, Windows Script Host, wbemtest.exe. They can be controlled via SRP or Anti-Exe.

I see that you have all those processes covered in Hard_Configurator, they are on the sponsors list

 

[Andy Ful]

I see that you have all those processes covered in Hard_Configurator, they are on the sponsors list

Yes. The list is based on the Excubits Bouncer blacklist.
But, the crucial thing is disallowing the possibility of running the exploit or any malicious code. If not, then there is always the possibility to harm something. For example, the VBA Macro in malicious document (template) can use Scripting API for WMI. The exploit can use COM API for WMI, etc. Those possibilities are not common, because of the popularity and effectiveness, of scripts and scriptlets.

 

[TairikuOkami]

Most WMI attacks use : scrcons.exe, wbemtest.exe.

Thanks, never heard about those 2 exes, helped me to find some good articles about them.

http://la.trendmicro.com/media/misc/understanding-wmi-malware-research-paper-en.pdf
https://medium.com/@christoferdirk/cryptomining-malware-is-using-wmi-to-evade-antivirus-detection-248a91a620b9

 

[Andy Ful]

The below is a comprehensive review:
https://www.fireeye.com/content/dam...dfs/wp-windows-management-instrumentation.pdf