Malicious Powershell Script, Persistent WMI 2019

[dandodds 0]

We need some help removing the same powershell infection that that has been reported last year where the CPU runs at 100%. We have followed the instructions provided by JamesR with no success.

Article here: https://forum.eset.com/topic/14821-malicious-powershell-script-wmi-for-persistance/

The WMILister_30.vbs does find and remove some entries but they keep coming back. Powershell 99%.

 

Attached are the ESET Log Collector logs from the log collector as well as the logs from the WMILister_30.vbs

Please assist!

ELC_logs.zip WMILister_30 logs.zip

[itman 1,541]

2 hours ago, dandodds said:

We need some help removing the same powershell infection that that has been reported last year where the CPU runs at 100%.

This is usually indicative of a coin miner.

You can also try SysInternals Autoruns: https://docs.microsoft.com/en-us/sysinternals/downloads/autoruns. Download and unzip the folder; no installation required. Click on the WMI tab and see if anything is shown.

[dandodds 0]

4 minutes ago, itman said:

This is usually indicative of a coin miner.

You can also try SysInternals Autoruns: https://docs.microsoft.com/en-us/sysinternals/downloads/autoruns. Download and unzip the folder; no installation required. Click on the WMI tab and see if anything is shown.

An entry does show up. We keep removing it with the script and it doesn't appear to be permanent. All of the infectious entries in WMI come back. Maybe that WMILister_30.vbs needs another update? I'm hoping an ESET engineer sees this post.

[itman 1,541]

Eset staff, @JamesR , wrote the code. He only infrequently visits the forum. You should PM him about your issue for a faster response.

[itman 1,541]

7 minutes ago, dandodds said:

An entry does show up.

Run Autoruns.exe as Admin. Right click on the SCM Win Event. Select - "Delete." This should remove the entry.

BTW - you sure this is not a legit WMI consumer event? Appears to me it has something to do with possibly harvesting Event Log data. Using PowerShell to do this in Enterprise environments is quite common.

[dandodds 0]

31 minutes ago, itman said:

Run Autoruns.exe as Admin. Right click on the SCM Win Event. Select - "Delete." This should remove the entry.

BTW - you sure this is not a legit WMI consumer event? Appears to me it has something to do with possibly harvesting Event Log data. Using PowerShell to do this in Enterprise environments is quite common.

My research led to the original post here: https://forum.eset.com/topic/13651-powershell-script-possible-malicious-attack/ 

We are experiencing the same thing almost to the T. This only just started Monday and we haven't made any changes to logging so we are pretty confident it's malicious. It has affected a bunch of our servers.

 

 

Some of our older servers weren't patched for the EternalBlue until yesterday. So our fault on that end. We are running the WMILister_30.vbs because it does remove the WMI entries in those posts I have linked. Except they don't stay removed. My thoughts are maybe there is now something else the vbs script needs to look for and remove. Just a thought.

[itman 1,541]

Per the Process Explorer screen shot you posted. Click on the Explore tab next to the PowerShell AutoStart Location. Does it point to the WMI consumer event? If not, delete it from wherever it is located at. If that doesn't stop the activity, then do the following.

For the time being and assuming you don't use Powershell for anything, just create a HIPS user rule to block startup of C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe.

-EDIT- Also create an Eset firewall rule to block any outbound communication from C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe.

Edited March 13, 2019 by itman

[itman 1,541]

One finally comment about this attack for anyone reviewing this posting for future reference.

This attack although similar to that described in this posting: https://forum.eset.com/topic/13651-powershell-script-possible-malicious-attack/ was different. In that posting, the attacker was using WMI to maintain persistence of the malicious WMI command event. The referenced WMILister_30.vbs script developed by Eset was coded to not only remove the WMI command event, but also its persistent recreation capability via WMI.

In this posting's attack, it appears PowerShell was run via autorun capability; e.g. registry run key or Windows startup directory that re-created the malicious WMI consumer event at system boot time to maintain its persistence. Hence the reoccurrence of the WMI command event after WMILister_30.vbs script was deployed. 

This is a great example of how malware authors are constantly evolving their tactics to avoid mitigation methods.

[JamesR 48]

I have replied directly to dandodds.  I have been sick lately, but am feeling much better now.