New Emotet version using WMI -- ENS exploit expert rule

[wyrm]

Over the past week, we've seen a new strain of Emotet that completely bypasses ENS 10.5.x.  It doesn't follow the typical infection chain of WinWord > powershell > payload, or WinWord > cmd > powershell.  Instead, WinWord is utilizing WMI to launch powershell, causing the payload to not load as a child process of WinWord. The process chain becomes svchost.exe > wmiprvse.exe > powershell.exe

The ENS ATP module does not even triggers events for these threats.

As a result, utilizing Access Protection or existing Exploit rules to prevent Word from launching cmd/powershell is ineffective.  I want to prevent Word & Excel from running win32_process.create().  Does anyone know if an ENS expert exploit rule can be used to prevent this behavior?  Documentation for expert rules is very limited.

[ninov_n]

Hello,

I think that there are quite few options you can use and consider in this case. It should look something like below one:

Sample Expert Rule

Regarding additional documentataion and guidelines, you can refer to below guides and article:

https://docs.mcafee.com/bundle/endpoint-security-10.6.0-threat-prevention-client-product-guide-windo...

https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/27000/PD27227/en_US/...

https://kc.mcafee.com/corporate/index?page=content&id=KB89677

[wyrm]

Unfortunately, this is the documentation I've already seen and did not help in this case.  I found some built-in powershell-related exploit rules that I can utilize to kill the behavior further down the chain.

[Daveb3d]

This might work (I can't take credit for the rule)....  You will see some noise off it, but based upon my  limited testing it won't hinder the user.

Rule {
Process {
Include OBJECT_NAME {
-v "winword.exe"

}
}
Target {
Match SECTION {
Include OBJECT_NAME {
-v "%windir%\\System32\\wbem\\wmiutils.dll"
-v "%windir%\\SysWoW64\\wbem\\wmiutils.dll"
}
}
}
}

Alernatively, you can probably safely get away with a rule that just blocks this:

Include OBJECT_NAME { -v "powershell.exe" }
Include PROCESS_CMD_LINE { -v "*-e *" }

MAR makes this MUCH easier..  Process parentname equals "wmiprvse.exe" and Process name equals "powershell.exe" and Process cmdline contains "-e "

Dave

[wyrm]

Unfortunately, the expert rule does not work, but the payload is blocked with powershell exploit rule 6087 (similar to your 'powershell -e' rule) which we've already started testing in our environment.  I was hoping to block the WMI behavior but in hindsight, going after the powershell usage itself is probably the best approach.  There's always going to be new techniques to try and launch the same powershell scripts.  I just need to make sure this doesn't impact legit powershell usage in my company.

[wyrm · Accepted solution]

As info, McAfee released exploit rule 6131 this week: WeaponizedOLE object infection via WMI Description:-This event indicates an attempt to access WMI through WORD, EXCEL or POWERPOINT using macros. Using WMI the attacker can execute some other executable like powershell or wscript from WMIPRVSE which is a malicious activity and signifies infection.