kingsyno

Malware Win32/Exploit.Agent.NZK

Recommended Posts

how do i get rid of the malware Win32/Exploit.Agent.NZK from the server

efsw_logs_1.zip

Edited by Marcos
Topic name edited

Share this post


Link to post
Share on other sites

First of all, enable HIPS and reboot the server as soon as possible. By disabling HIPS you lose important protection features, such as Advanced Memory Scanner, Exploit Blocker, Ransomware shield and Self-defense.

Please run the command "wmic process list >pl.txt" and attach pl.txt here.

Share this post


Link to post
Share on other sites

Kingsyno,

From looking at your logs, you may have a WMI Persistent threat on your server.  The reason I believe this is due to Powershell.exe being a child process to WmiPrvSE.exe.  This is typically indicative of the CommandLineEventConsumer (CLEC) WMI class being used to execute malicious Powershell scripts.  Please be aware that these CLEC WMI Scripts do have the ability to attempt to spread across a network using the EternalBlue exploit, which is why you are seeing the detection as Win32/Exploit.Agent.NZK.  Please do the following commands so we can verify this is a WMI Persistent threat and so we can help guide you through cleaning this threat off your computer:

1. Run the command Marcos provided from an Administrative command prompt.  This will allow us to see what Powershell is executing:

wmic process list > pl.txt

2. Download the following file (WMILister_28.vbs from here:  https://eset.sharefile.com/d-s3ecb8308e7f4efd9) and run it from an administrative command prompt as follows:

cscript //nologo WMILister_29.vbs >> WMILog.txt

Reply to this post and attach both text files attached.  You should have "pl.txt" and "Log.txt".

 

Regards,

JamesR

 

 

Notes from your logs:

From the ProcessTree.txt, we can see Powershell.exe having a parent process of WmiPrvSE.exe

            WmiPrvSE.exe (3440), Start Time: 07.02.2018 09:21:07, User Name: NT AUTHORITY\NETWORK SERVICE, [N/A]
            WmiPrvSE.exe (3508), Start Time: 07.02.2018 09:21:07, User Name: NT AUTHORITY\SYSTEM, [N/A]
                powershell.exe (5928), Start Time: 07.02.2018 10:55:39, User Name: NT AUTHORITY\SYSTEM, [N/A]
                    conhost.exe (1808), Start Time: 07.02.2018 10:55:39, User Name: NT AUTHORITY\SYSTEM, [N/A]
                    powershell.exe (5504), Start Time: 07.02.2018 10:55:59, User Name: NT AUTHORITY\SYSTEM, [N/A]
                        conhost.exe (5648), Start Time: 07.02.2018 10:55:59, User Name: NT AUTHORITY\SYSTEM, [N/A]

Edited by JamesR
Updated URL and CMD line to point to v29 of tool.

Share this post


Link to post
Share on other sites

Notes from logs:

This is definitely a WMI persistent infection.  I can see powershell executing a very long base64 encoded powershell script which also extracts malicious EXEs from the WMI database.

Powershell process running this command:
     powershell.exe -NoP -NonI -W Hidden  -E JABzAHQAaQBtAGUAPQBbAEUA.....

Decoding the full base64 string shows that malicious EXEs are stored in this Class in the WMI database:
     root\default:Win32_Services

This infection will utilize the EternalBlue exploit to attempt to spread across your network.  You will want to ensure you are fully patched by running this tool: https://help.eset.com/eset_tools/ESETEternalBlueChecker.exe

 

 

Remediation:

Anyways, to clean this, please do the following.  I updated this script last night so that it will give you the powershell commands to remove the infection.

1. Download the following file (WMILister_29.vbs from here: https://eset.sharefile.com/d-s3ecb8308e7f4efd9) and run it from an administrative command prompt as follows:

cscript //nologo WMILister_29.vbs >> WMILog.txt

2. Open the WMILog.txt and scroll to the bottom (CTRL + END).  The section titled "---Powershell Commands to Remove Found Items---" will have the Powershell commands to remove the infection.  Just launch Powershell as admin and run each of the commands.

3. Reboot after running the commands.

Also, if you could reply with the WMILog.txt, it could be used to help other clean this infection off their servers.

 

Regards,

James

Share this post


Link to post
Share on other sites

Thanks James. I could not upload the Log.txt but the ESET team in Nigeria has sent a zip file directly to your mail

Share this post


Link to post
Share on other sites

Sorry for the delays.  Was actually helping someone via a remote session where this very same infection was spreading through their network and we were not sure of the culprit machine.  Had to use some Wireshark skills to narrow it down.

 

Here are the Powershell commands to run as amdin:

Get-WMIObject -Namespace root\subscription -Class __FilterToConsumerBinding -Filter "Consumer='CommandLineEventConsumer.Name=\'DSM Event Log Consumer\'' AND Filter='__EventFilter.Name=\'DSM Event Log Filter\''" | Remove-WMIObject -Verbose
Get-WMIObject -Namespace root\subscription -Class CommandLineEventConsumer -Filter "Name='DSM Event Log Consumer'" | Remove-WMIObject -Verbose
Get-WMIObject -Namespace root\Subscription -Class __EventFilter -filter "Name= 'DSM Event Log Filter'" | Remove-WMIObject -Verbose
([WmiClass]'root\default:Win32_Services') | Remove-WMIObject -Verbose

Share this post


Link to post
Share on other sites

Hello James, this threat has come up again after 24hours on two servers for now. And the script above has been re-run and looks ok again. what do you advice we do next?

Share this post


Link to post
Share on other sites

The Malware is occurring within the VLAN environment.

Share this post


Link to post
Share on other sites

Did you also test the system for EternalBlue vulnerability using the appropriate checker tool https://help.eset.com/eset_tools/ESETEternalBlueChecker.exe as advised above? If the system is vulnerable, you should install the appropriate Windows updates to prevent the system from being infected from another machine in the network by exploiting a SMBv1 vulnerability:

https://docs.microsoft.com/en-us/security-updates/securitybulletins/2017/ms17-010

 

Share this post


Link to post
Share on other sites
3 hours ago, kingsyno said:

Hello James, this threat has come up again after 24hours on two servers for now.

What was provided previously is a method to remove the malware's persistence via WMI use. It will not prevent you from being re-infected by the same or like malware if your servers are vulnerable.

Make sure your servers are fully patched with all available OS and application software updates. Make sure all Eset security features and options are enabled; it was noted previously that you had the HIPS disabled.

Finally, it should be noted that attacks like and similar to that occurring on your servers have been overwhelmingly shown to be RDP brute force attacks where the attacker repeatedly tries to guess logon credentials to gain access to the server. You need at a minimum to create new secure passwords for your servers. You also need to lockdown RDP access to the servers. One alternative is to use VNC.  

Edited by itman

Share this post


Link to post
Share on other sites

As an interim mitigation while you implement what I previously posted, you can try to stop the Powershell aspects of the attack by doing the following:

1. Assuming you are not using Powershell for any valid remote connection activities, block all inbound and outbound communication from powershell.exe in your firewall. This will prevent the attacker from communicating with his remote C&C servers.

2. Assuming you are not internally using Powershell via command shell execution, create a HIPS block rule with logging enabled to block any startup of powershell.exe from cmd.exe. You will need to monitor your HIPS log to ensure you are not blocking any valid Powershell script execution.

3. Create a HIPS rule to block any startup of powershell.exe from wmiprvse.exe. Again this assumes you presently do not have any WMI consumer events that validity use powershell.exe. This rule needs to be monitored to ensure it is actually blocking powershell.exe. The rule might need to be modified to block all application startups from wmiprvse.exe. Again this modification will prevent any legit process execution from WMI if same exists.

Share this post


Link to post
Share on other sites

Top ways initial infection occurs for this threat:

1. RDP Brute Force attack successfully obtained admin password/s and a malicious actor placed the infection on network

  • This can actually lead to reinfection if a malicious actor still has access to your environment via RDP.  You will need to audit Active Directory for all Domain Admin, Enterprise Admin, Schema Admin, and other Admin groups.  Then change all passwords to both Admin and NonAdmin accounts and implement an account lockout policy to prevent from being brute forced again.  Also, implementing 2FA will stop a leaked or stolen or obtained password from being used again.

2. File Sharing ports are open to the internet (ports 135, 136, 137, 139, and 445).  Having these ports open to the internet is just allowing problems to walk in.

  • Its not a bad idea to make a list of all public IP Addresses for a company and then run some nmap scans to see which ports are open.  My favorite scan is:
    nmap -F %address%

     

3. Its possible that this infection is coming in via malicious email attachments, like .doc MS Word files with not so nice macros in them.

 

Reasons for reinfection:

1. See items 1 and 2 from initial infection.  This should be the number one priority to investigate and lock down your Public IP Address from the world.

2. This infection is a worm.  It can spread to other computers on your network.  Having even one machine out of a 1000 remain infected can lead to reinfection of other computers.  It spreads in 2 ways:

     a. Use of EternalBlue exploit to spread to un-patched computers.  This is why its so important to verify all computers on a network are patched for EternalBlue: https://help.eset.com/eset_tools/ESETEternalBlueChecker.exe

     b. Use of WMI to remotely execute commands on other computer in network.  This infection can use mimikatz to grab passwords of any logged on users, then elevate its rights and use those rights to spread to other machines by using Microsofts own WMI API to execute on any computer it can find on your network.

3. Having one computer on your network which does not have some form of endpoint security can leave you searching for months for the culprit which is re-infecting your network.  If it ever comes down to finding this computer, your best bets are NMAP scans of your network and Wireshark logs on machines which are getting reinfected.  For Wireshark logs, you need to ensure you are logging while reinfection is happening or you will have not captured the needed data.  Parsing Wireshark logs takes time and effort and its best to have other logs (like detected threats logs and such) to correlate the time stamps with.

 

 

There could be reasons for reinfection I am overlooking, but in companies I have helped in the past 10 or so years, its those reasons which are almost always what causes initial infection or reinfection.

 

Regards,

James

Share this post


Link to post
Share on other sites

Hello James,

 

Could you help with remote session to these servers? 4 of these servers keep reoccurring after the steps above. Please assist.

Share this post


Link to post
Share on other sites

In regards to RDP security, the University of California - Berkley has an excellent publication that I advise be read in its entirety. Below are some key excerpts from it:
 

Quote

Set an account lockout policy

By setting your computer to lock an account for a period of time after a number of incorrect guesses, you will help prevent hackers from using automated password guessing tools from gaining access to your system (this is known as a "brute-force" attack). To set an account lockout policy:

1. Go to Start-->Programs-->Administrative Tools-->Local Security Policy
2. Under Account Policies-->Account Lockout Policies, set values for all three options. 3 invalid attempts with 3 minute lockout durations are reasonable choices.

Change the listening port for Remote Desktop

Changing the listening port will help to "hide" Remote Desktop from hackers who are scanning the network for computers listening on the default Remote Desktop port (TCP 3389). This offers effective protection against the latest RDP worms such, as Morto. To do this, edit the following registry key (WARNING: do not try this unless you are familiar with the Windows Registry and TCP/IP): HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp. Change the listening port from 3389 to something else and remember to update any firewall rules with the new port.

Enable Network Level Authentication

Windows Vista, Windows 7, and Windows Server 2008 also provide Network Level Authentication (NLA) by default. It is best to leave this in place, as NLA provides an extra level of authentication before a connection is established. You should only configure Remote Desktop servers to allow connections without NLA if you use Remote Desktop clients on other platforms that don't support it.

Use RDP Gateways

Using a RDP Gateway is strongly recommended. It provides a way to tightly restrict access to Remote Desktop ports while supporting remote connections through a single "Gateway" server. When using an RD Gateway server, all Remote Desktop services on your desktop and workstations should be restricted to only allow access only from the RD Gateway. The RD Gateway server listens for Remote Desktop requests over HTTPS (port 443), and connects the client to the Remote Desktop service on the target machine.

https://security.berkeley.edu/resources/best-practices-how-articles/system-application-security/securing-remote-desktop-rdp-system

Edited by itman

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Recently Browsing   0 members

    No registered users viewing this page.