PowerShell Script - Possible Malicious Attack

[Marco2526 0]

Good day Everyone

We are currently experiencing an issue where a powershell script is running on a couple of our VM's. This script is causing havoc on our servers as it is using 100% of the CPU rendering it slow and non responsive. We have created a new VM to test however the Powershell script immediately attacks the new machine as soon as we bring it up. 

We do have ESET, which is active and up to date however it did not pick up anything before and after the script's dubious activity.

When viewing the PowerShell command in Task manager it brings up the following:

-NoP -Nonl -W Hidden "$mon = ([WmiClass] 'root\default:Win32_TaskService').properties['mon'].Value;$funs = ([WmiClass] 'root\default:Win32_taskService').Properties['funs'].Value ;iex ([System.Text.Encoding]::ASCII.Getstring([System.Convert]::FromBase64String($funs)));Invoke-Command -ScriptBlock $RemoteScriptBlock -ArgumentList @($mon, $mon, 'Void',0,",")"

We have softened the impact of this script by setting the priority to low and changed the affinity to 1 core via Task Manager however this script continues to run, we also checked the account that it is running on and we can see that it is running on the local system account, at first it was executed by our admin accounts.

I did use ProcessExplorer to get more information on it. According to ProcessExplorer I was able to determine a remote address ns3265193.ip-37-59-52eu:http and the state is connection established as per the below screen shot.

I also used to ProcessExplorer to generate a bit more information on the script:

I wrote the following Powershell script to see what properties the script is looking for:

([WmiClass] 'root\default:Win32_taskService').Properties['funs'].Value

This gave me the results in Base64 which I have decrypted and attached to this post. I am not the most code savvy person therefore I am not 100% sure what this script is doing. I do fear that this is something more serious as it hit us exactly two weeks ago and is really affecting our servers due to the CPU usage. As mentioned before we have lowered the impact on our servers however this threat is very much alive and is constantly running in our environment. 

If you need anything else from me feel free to ask and I will get it to you ASAP.

Kind regards

Decrypted.txt

Edited November 2, 2017 by Marco2526

[JamesR 48]

Sounds like you have malware using WMI for persistence.  Its likely using your server for bitcoin mining and might be trying to spread using EternalBlue.  This type of infection is typically the result of a Brute Force RDP attack that succeeded in guessing administrative credentials.  I highly recommend getting an expert on your system to assist with cleaning.  I'm going to try and provide some steps here for remediation.

1. Save the attached file and rename it to have an extension of .vbs (I will supply this in a PM directly to you.  This VBS will log any non-expected scripting in the WMI database)

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

3. Zip up and password protect the .txt file and attach it to a reply on this thread. (I will PM you the password to use.  7zip is a good tool to zip and password protect.)

I will use this log to help remediate the issue.  If you are running the script on multiple servers, just add the name of each server to the logs.

 

Some more info on what I believe you have been infected by can be found here (use google translate as needed): http://www.freebuf.com/column/149286.html

[itman 1,538]

Also recommend you run SysInternals Autoruns and look for any WMI command/consumer event scripts that you have not specifically created.

 

[Marco2526 0]

Hi JamesR

Thank you very much for your response to the matter. I completed the aforementioned as per your request.

Unfortunately I am unable to upload the file on this forum as it states that .7z is not an accepted format. It only accepts .rar, may I use winrar?

Kind regards

 

[JamesR 48]

Just messaged you a link to upload the files to.  Its a secure location that only I have access to.  You can also use WinRar if needed.

[Marco2526 0]

Hi James

Files have successfully uploaded. I feel more comfortable with the a secure location to share the files. 

Let me know if you require anything else from my side.

Appreciate the help!

EDIT: We have already contacted a security specialist who has taken a copy of one of our VM's and will be running a few tests in his lab. I would prefer that we leave no stone unturned. 

Edited November 2, 2017 by Marco2526

[Marco2526 0]

10 minutes ago, itman said:

Also recommend you run SysInternals Autoruns and look for any WMI command/consumer event scripts that you have not specifically created.

 

I will give this a shot.

Thanks for the tip.

[JamesR 48]

Here are some PowerShell commands to remove the WMI infections. 

1. First open PowerShell as admin

2. Run the commands

3. Reboot and rerun the vbs script I provided.  If its a one line text file, then you are clean on that server.

4. Verify servers and workstations are patched for EternalBlue using this tool https://help.eset.com/eset_tools/ESETEternalBlueChecker.exe (full instructions for use here: https://support.eset.com/kb6481/ )

5. Close port 3389 on your router (this is likely open and needs to be closed while you reset all passwords for all users)
To prevent an RDP brute force, you can enforce password policies to log out after a handful of attempts.  Also implementing 2FA will prevent a password from being used, if it is compromised.  ESET does have a 2FA product.  Let us know if you are interested in that.

 

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

This last command ins't needed for your environment.  But run it just in case my logging didn't find any ActiveScriptEventConsumer items.

 

 

 

[itman 1,538]

Are you running Win 10 on the clients? Also are you using AppContainer?

[Marco2526 0]

On 11/2/2017 at 9:48 PM, itman said:

Are you running Win 10 on the clients? Also are you using AppContainer?

Hi itman

Yes but few and far between. No we are not using AppContianer.

On 11/2/2017 at 7:28 PM, JamesR said:

Here are some PowerShell commands to remove the WMI infections. 

1. First open PowerShell as admin

2. Run the commands

3. Reboot and rerun the vbs script I provided.  If its a one line text file, then you are clean on that server.

4. Verify servers and workstations are patched for EternalBlue using this tool https://help.eset.com/eset_tools/ESETEternalBlueChecker.exe (full instructions for use here: https://support.eset.com/kb6481/ )

5. Close port 3389 on your router (this is likely open and needs to be closed while you reset all passwords for all users)
To prevent an RDP brute force, you can enforce password policies to log out after a handful of attempts.  Also implementing 2FA will prevent a password from being used, if it is compromised.  ESET does have a 2FA product.  Let us know if you are interested in that.

 

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

This last command ins't needed for your environment.  But run it just in case my logging didn't find any ActiveScriptEventConsumer items.

 

 

 

Hi James

Apologies for the delay, was working hard to squash this malware.

I would like to send you a huge thanks.

It seems your scripts have worked. A lot of our server VM's had the EternalBlue exploit thus the malware spread rapidly. All our VM's have been patched and the script has been cleared off our environment, everything appears to have stabilized. 

I will continue to monitor the situation to ensure nothing rears it's ugly head again.

Unfortunately we are unable to close port 3389 as we provide a service to our clients that require the RDP to our terminal servers. We have to consider an alternative in the near future to prevent this from happening again,

Again thank you very much for your help!!!

Kind regards  

Edited November 5, 2017 by Marco2526

[itman 1,538]

4 hours ago, Marco2526 said:

Unfortunately we are unable to close port 3389 as we provide a service to our clients that require the RDP to our terminal servers. We have to consider an alternative in the near future to prevent this from happening again,

Here's an article on preventing RDP brute force attacks: https://blog.watchpointdata.com/rdp-brute-force-attack-detection-and-blacklisting-with-powershell . You could duplicate the outbound Win firewall rule shown in Eset's firewall rules.

As far as AppContainer goes which I believe is only available on the Win Enterprise vers., it by default runs Powershell in Constrained Language mode which restricts what will be allowed. For example, Powershell assemblies running from a .Net based app are disallowed. Additional you can configure via AppContainer policy setting that only signed Powershell scripts are allowed to run.

[Marco2526 0]

17 hours ago, itman said:

Here's an article on preventing RDP brute force attacks: https://blog.watchpointdata.com/rdp-brute-force-attack-detection-and-blacklisting-with-powershell . You could duplicate the outbound Win firewall rule shown in Eset's firewall rules.

As far as AppContainer goes which I believe is only available on the Win Enterprise vers., it by default runs Powershell in Constrained Language mode which restricts what will be allowed. For example, Powershell assemblies running from a .Net based app are disallowed. Additional you can configure via AppContainer policy setting that only signed Powershell scripts are allowed to run.

Thanks for the information I will definitely look into this.