Photographee.eu - Fotolia
Tips to track down and neutralize PowerShell malware
The benefit of PowerShell is its wide-ranging access to Windows systems, but industrious hackers can exploit its abilities to launch attacks from inside your data center.
Some organizations feel more secure keeping their servers hosted in their own data centers rather than the cloud. However, many in IT might not realize this makes their machines very attractive targets for hackers.
Malicious actors actively target servers in the data center to tap into the sheer amount of bandwidth and processing power they can use for their own nefarious deeds. In this article, we will look at how we uncovered and disabled PowerShell malware that ran its workload on a specific schedule.
System performance takes a nosedive
We knew something was wrong because the issues were obvious. The machine, whether it was a physical or a virtual server, would slow to a halt. We launched Task Manager and checked the details to see multiple instances of PowerShell.exe consuming as much CPU as possible.
We killed the PowerShell.exe processes, but it was a temporary fix, as the processes would respawn every two hours to restart its cryptomining operation.
To stop the PowerShell malware from running, we used this command to stop the automated process:
taskkill /IM PowerShell.exe /F
A look at Task Scheduler yielded no obvious clues. Normally, malware modifies a Windows file or creates a similar one that the antivirus does not pick up in a hidden folder. In this case, there were no hidden folders and all the system files looked normal when checking the creation date.
To dig deeper into the cause, we turned on PowerShell logging with Group Policy using the administrative templates. Within 30 minutes, we checked the logs and found the machine talking to several external IP addresses.
After identifying the external IPs, we created a new static route to send the traffic to nowhere. To do this, we launched an elevated command prompt and ran the following command, replacing X.X.X.X with the default gateway address:
route ADD 105.27.177.210 MASK 255.255.255.255 X.X.X.X if 1 -p
We ran the same command for the other external IPs found in the logs. Now, when the PowerShell malware tried to start, it would stop because it could not talk to the internet.
We removed the default gateway on servers that didn't require access to the internet. This offered the same result as null routing the IP and killed the process immediately after it launched.
Remove the infection from the WMI database
Ways to defend your infrastructure from
PowerShell-based malware
Next, we checked Windows Management Instrumentation (WMI) because a lot of WMI alerts appeared in the event log during the high CPU spikes when PowerShell.exe launched.
Run these PowerShell commands to check for a corrupt or infected WMI database -- gwmi is the alias for Get-WmiObject:
gwmi -Namespace "root/subscription" -class __FilterToConsumerBinding -Filter "Filter = ""__EventFilter.Name='SCM Event Filter'"""
gwmi -Namespace "root/subscription" -Class __EventFilter | Where Name -eq "SCM Event Filter"
gwmi -Namespace "root/subscription" -Class __EventConsumer | Where Name -eq "SCM Event Consumer"
If there is anything amiss, encrypted text will appear. Due to this obfuscation, the operating system may not recognize the PowerShell malware as a threat.
To remove the malware, we had to delete those entries from the WMI database using the Remove-Object pipe.
gwmi -Namespace "root/subscription" -class __FilterToConsumerBinding -Filter "Filter = ""__EventFilter.Name='SCM Event Filter'""" | Remove-WMIObject
gwmi -Namespace "root/subscription" -Class __EventFilter | Where Name -eq "SCM Event Filter" | Remove- WMIObject
gwmi -Namespace "root/subscription" -Class __EventConsumer | Where Name -eq "SCM Event Consumer" | Remove- WMIObject
Take extra steps to be safe
We also discovered the malware used IPv6 to tunnel traffic to IPv4. If you have a server that does not require IPv6, I suggest removing it by updating the registry and then removing the pass-through with the following commands:
reg add hklm\system\currentcontrolset\services\tcpip6\parameters /v DisabledComponents /t REG_DWORD /d 0xFF /f
Get-NetAdapterBinding -ComponentID "ms_tcpip6" | disable-NetAdapterBinding -ComponentID "ms_tcpip6" -PassThru
After rebooting the server, the multiple instances of PowerShell.exe stopped.
