PowerShell Script 100% CPU Load - Malicious Attack

[Killian Occelli 0]

Hi Everyone,

I have the same problem as Marco2526 PowerShell Script - Possible Malicious Attack.

I tested the commands below, but the fourth doesn't work.

Get-WMIObject -Namespace root\Subscription -Class __EventFilter -filter "Name= 'SCM Event Filter'" |remOVe-WMIObject  -Verbose
Get-WMIObject -Namespace root\Subscription -Class CommandLineEventConsumer -Filter "Name='SCM Event Consumer'" | Remove-WMIObject -Verbose
Get-WMIObject -Namespace root\Subscription -Class __FilterToConsumerBinding -Filter "__Path LIKE '%SCM Event Consumer%'" | REmOVE-WMIObject -Verbose
([WmiClass]'root\default:Win32_TaskService') | Remove-WMIObject -Verbose

Get-WMIObject -Namespace root\Subscription -Class  ActiveScriptEventConsumer -Filter "Name='SCM Event Consumer'" | Remove-WMIObject -Verbose

I have the error "Cannot convert value "root\default:win32_TaskService" to type "System.Management.ManagementClass. Error: "Not found "

You can find the dump of the WMILister_20.vbs script in my post.

dumpedscript.txt

It's on a VM with Windows Server 2008 R2.

Thanks in advance.

 

 

 

 

 

[JamesR 52]

Killian,

--Edit--

I updated the script based off of one what I saw in one of your logs.  An extra class named Office_Updater.  Script that is attached should be named WMILister_22.txt.  Please use this regardless of if you are no longer getting Powershell using 100% of CPU.  There are some embedded EXE's in your WMI database and I updated this script specifically so we can identify them and I can assist in getting that cleaned up from your server.

--End Edit--

 

You might be clean by now if you ran the 4 powershell commands and rebooted.  The 4th powershell command likely failed because you do not have an "ActiveScriptEventConsumer" entry in the WMI database to clean up (this area shows as not logged in the log you provided).  If you are uncertain if you are now clean or not, you can do the following:

1. Save the attached file and rename it to have an extension of .vbs (this is a slightly improved version of the script you ran.  One tiny bug fix and some extra logging of WMI Queries which can assist with removal of bad scripts.)

2. From an administrative command prompt, change directories to where you saved the .vbs file and run the command:
cscript //nologo WMILister_22.vbs > DumptedScripts.txt

3. Attach the log here and I can assist with verifying if you are clean or what your next steps should be.

 

****IMPORTANT****

This type of infection is very commonly introduced after a successful RDP Brute force attack.  This means someone likely has access to RDP into your server (or servers) with full administrative privileges.  You may need to close port 3389 to the outside world and then change all passwords for all accounts with RDP access.  I highly recommend implementing 2FA to protect RDP or implement a VPN with 2FA (ESET Secure Authentication can implement 2FA on RDP and VPNs).

Also, this type of infection can use the EternalBlue exploit to assist in spreading to other computers on your network (it can also spread with the administrative rights it likely already has or obtained via mimikatz).  You should ensure you patch any computers and servers to prevent this exploit.  To find out if a machine is patched or not, you use the ESETEternalBlueChecker.
 - Tool located here: https://help.eset.com/eset_tools/ESETEternalBlueChecker.exe
 - Instructions for running are here: https://support.eset.com/kb6481/

 

WMILister_22.txt

Edited December 21, 2017 by JamesR
Updated Attachment

[Killian Occelli 0]

Dear James,

Thanks for your help.

After the reboot, the process come back after 30 minutes.

We have patched the server and reset all admin password after th at

You can find below the dump of the WMILister_22 script.

Dump221217.txt

Thanks in advance.

[itman 1,659]

Suspect the malware has created a scheduled task for persistence to recreate the WMI consumer/command events at system boot time which is common in this type of infection. Also, the same can be done from registry run keys and/or startup locations run at boot time.

[JamesR 52]

Killian,

Looks like you may have accidentally ran the old vbs script.  Attaching the latest one here.  I added logging line of the version of the tool to be the first line of the log.  So if you open the log, you should see "---WMILister Version:2.3---" as the first line.  Basically, I didnt get the embedded EXEs and one other part that would tell us if there is a scheduled task. 

The likely causes for reinfection are:

1. Scheduled task (usually running a y1.bat)

2. Other computers/servers on network are infected (this infection is a worm.  It can use 2 methods to spread across a network.  A. using admin credentials to spread.  B. Using EternalBlue exploit to spread.)

 

What we need to do to get you fully clean:

1. Ensure you have an Antivirus solution on all machines (if you don't have any current AV on any computers/servers, let me know)

2. Submit samples of the embedded EXEs that the attached script file will dump to your Antivirus company (I can assist in making a package to submit to your AV vendor.)
     -  Submitting these samples is very important as it will ensure your AV will be able to block these files when they are extracted from the WMI database and any other machines that are infected will start getting alerts as well.

3. Patch any and all machines on your network against EternalBlue.

4. Have patience.  Network spreading worms can be very frustrating to get cleaned up.  The larger the network, the more time it takes to clean these nasties up.

 

I will PM you with a few questions that are a bit more specific about your network.

WMILister_23.txt

[itman 1,659]

On ‎12‎/‎22‎/‎2017 at 12:42 PM, JamesR said:

The likely causes for reinfection are:

1. Scheduled task (usually running a y1.bat)

As far as this .bat based infection, here is an interesting article on it for reference: http://securityaffairs.co/wordpress/63488/malware/advanced-memory-cryptoworm.html

The .bat script is propagated to the victim by email or message. Once the user clicks on it, the .bat file would run. Likewise could also be done at system startup as mentioned previously via scheduled task or registry run key or startup directory. The .bat script runs PowerShell to create and execute a WMI consumer event to download and run a script called info6.ps1 from http://118.184.48.95:8000/.

This activity can be stopped by creating a HIPS rule to block powershell.exe startup by cmd.exe.

[Killian Occelli 0]

Dear James,

Thanks for your help.

We ran the new vbs script. Attaching the latest dump here.

We have patched our VMs that are infected.

Dump261217.txt

[JamesR 52]

Killian,

OK,  I think I have a plan of attack that should get you cleaned up.  I have 4 Powershell commands which have some slightly different, yet very important differences from the original commands you ran.  The best method to clean your network is to use the last script I provided on any computers you suspect are infected.  If its log has more than just the note lines of the following, then run the commands listed further below:

---WMILister Version:2.3---
---Possible embeded EXEs---   <Might see this listed a lot, but if not info is below it, then its just a bug I need to fix.
If log is empty, no bad scripts were found.

 

Assuming all machines are patched for EternalBlue, here are the steps that should get you back to a clean state.

1. Disconnect infected computers/servers from network

2. Run Powershell with administrative privileges and execute the following commands.  If any error out, screenshot them and post them here with a log from the WMILister as well:
Get-WMIObject -Namespace root\Subscription -Class __FilterToConsumerBinding -Filter "__Path LIKE '%SCM Event Logs Consumer%'" | Remove-WMIObject -Verbose

Get-WMIObject -Namespace root\Subscription -Class CommandLineEventConsumer -Filter "Name='SCM Event Logs Consumer'" | Remove-WMIObject -Verbose

Get-WMIObject -Namespace root\Subscription -Class __EventFilter -Filter "Name='SCM Event Logs Filter'" | Remove-WMIObject  -Verbose

([WmiClass]'root\default:Office_Updater') | Remove-WMIObject -Verbose

3. Reboot computer ASAP and leave disconnected from network while you repeat the above steps on any other computers or servers which are infected.

4. Leave computers which were infected off the network for at least 2 hours (if possible) after cleaning.  Verify if any malicious Powershell processes start up.  Reconnect to network, and after about 2 more hours, verify if any malicious Powershell processes return.  If malicious processes return after connecting to the network, you still have infected computers which are spreading the infection back to cleaned computers.

The most difficult part of cleaning this type of infection from your network is that a single computer could potentially spread the infection back to computers you cleaned.  That's why its so important to disconnect any infected computer from the network and leaving them disconnected while cleaning.  Any computers which are getting reinfected, you will want to triple check if they are patched for EternalBlue.  If infection keeps coming back, Wireshark logging during the time of reinfection may help us identify which machine is still infected and reinfecting computers and SysInspector logs from those computers will help us identify anything that is not hiding in the WMI.

[Randika 0]

On 12/27/2017 at 4:27 AM, JamesR said:

Killian,

OK,  I think I have a plan of attack that should get you cleaned up.  I have 4 Powershell commands which have some slightly different, yet very important differences from the original commands you ran.  The best method to clean your network is to use the last script I provided on any computers you suspect are infected.  If its log has more than just the note lines of the following, then run the commands listed further below:

---WMILister Version:2.3---
---Possible embeded EXEs---   <Might see this listed a lot, but if not info is below it, then its just a bug I need to fix.
If log is empty, no bad scripts were found.

 

Assuming all machines are patched for EternalBlue, here are the steps that should get you back to a clean state.

1. Disconnect infected computers/servers from network

2. Run Powershell with administrative privileges and execute the following commands.  If any error out, screenshot them and post them here with a log from the WMILister as well:
Get-WMIObject -Namespace root\Subscription -Class __FilterToConsumerBinding -Filter "__Path LIKE '%SCM Event Logs Consumer%'" | Remove-WMIObject -Verbose

Get-WMIObject -Namespace root\Subscription -Class CommandLineEventConsumer -Filter "Name='SCM Event Logs Consumer'" | Remove-WMIObject -Verbose

Get-WMIObject -Namespace root\Subscription -Class __EventFilter -Filter "Name='SCM Event Logs Filter'" | Remove-WMIObject  -Verbose

([WmiClass]'root\default:Office_Updater') | Remove-WMIObject -Verbose

3. Reboot computer ASAP and leave disconnected from network while you repeat the above steps on any other computers or servers which are infected.

4. Leave computers which were infected off the network for at least 2 hours (if possible) after cleaning.  Verify if any malicious Powershell processes start up.  Reconnect to network, and after about 2 more hours, verify if any malicious Powershell processes return.  If malicious processes return after connecting to the network, you still have infected computers which are spreading the infection back to cleaned computers.

The most difficult part of cleaning this type of infection from your network is that a single computer could potentially spread the infection back to computers you cleaned.  That's why its so important to disconnect any infected computer from the network and leaving them disconnected while cleaning.  Any computers which are getting reinfected, you will want to triple check if they are patched for EternalBlue.  If infection keeps coming back, Wireshark logging during the time of reinfection may help us identify which machine is still infected and reinfecting computers and SysInspector logs from those computers will help us identify anything that is not hiding in the WMI.

Hi James,

you are a life saver, I was having the same scenario which i was able to remove the PS scripts with you method. Any more suggestions that we have to look in-to maybe on the firewall to disable these type of malicious code entering to the local network?

 

Thnx once again

Edited February 7, 2018 by Randika
added Content

[JamesR 52]

I would highly recommend to audit what ports are open to the internet and close any that are not needed to be open. Also, if any ports used for remote access (RDP, VNC, etc...), you may want to examine if any over seas IP addresses have been connecting.

A simple nmap scan of your public IP can be as follows:

• nmap -F <IPAddress>