Malware Win32/Exploit.Agent.NZK

[kingsyno 0]

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

efsw_logs_1.zip

Edited February 14, 2018 by Marcos
Topic name edited

[Marcos 5,074]

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.

[JamesR 52]

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. Please download and generate an ELC log from here: https://www.eset.com/int/support/log-collector/

3. Also, please try this newer version of the WMILister v3.0 on the server.  Please supply any logs generated by this and ELC in a reply on the ESET Forums.  If any odd scripts are found, you will be prompted if you want to remove them.  It is best to review the log which will be saved inside of a Log folder in the same folder the utility was run from.

https://eset.sharefile.com/d-sb6232c1bc5240709

Run this command as admin (logs will be generated in same folder as tool and saved inside of a Logs folder):

cscript //nologo WMILister_30.vbs

If scripts are found, you will be prompted to remove the.

4. Reboot after stating "y" to prompt for cleaning.  To see advanced usage of this tool, please see this post: 

 

 

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 March 2, 2018 by JamesR
Updated URL and CMD line to point to v30 of tool.

[kingsyno 0]

Thanks. I will do so and revert

[kingsyno 0]

Hello Team,

 

Please see attached the Processlist and Pl. txt file

pl.txt

ProcessList (1).txt

[JamesR 52]

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. Please download and generate an ELC log from here: https://www.eset.com/int/support/log-collector/

2. Also, please try this newer version of the WMILister v3.0 on the server.  Please supply any logs generated by this and ELC in a reply on the ESET Forums.  If any odd scripts are found, you will be prompted if you want to remove them.  It is best to review the log which will be saved inside of a Log folder in the same folder the utility was run from.

https://eset.sharefile.com/d-sb6232c1bc5240709

Run this command as admin (logs will be generated in same folder as tool and saved inside of a Logs folder):

cscript //nologo WMILister_30.vbs

If scripts are found, you will be prompted to remove the.

3. Reboot after stating "y" to prompt for cleaning.  To see advanced usage of this tool, please see this post: 

 

 

 

Regards,

James

Edited March 2, 2018 by JamesR
Updated steps for WMILister for latest version.

[kingsyno 0]

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

[JamesR 52]

Perfect.  I have these logs.  Did not fully realize they were your logs.  Will have something for you once I get a free moment to build the powershell commands you need.  While waiting, please ensure your servers are patched for EternalBlue: https://help.eset.com/eset_tools/ESETEternalBlueChecker.exe

[JamesR 52]

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

[kingsyno 0]

Thanks James. It is all good now

[kingsyno 0]

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?

[kingsyno 0]

The Malware is occurring within the VLAN environment.

[Marcos 5,074]

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

 

[itman 1,659]

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 February 15, 2018 by itman

[itman 1,659]

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.

[JamesR 52]

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

[kingsyno 0]

Hello James,

 

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

[itman 1,659]

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 February 19, 2018 by itman

[kingsyno 0]

Hello all,

New win32/Exploit .Agent.NZK threat has occur again. Please advise.
Attached is the log file.

 

wetransfer-4b3a68.zip

[galaxy 11]

have you ever tried Emsisoft? Maybe the program can eliminate it.

[kingsyno 0]

The ERA console reported a Trojan on 3 of our windows server caused by (Win32/Rozena.XK, Win32/RiskWare.Meterpeter.G and Powershell/Agent.DG) all with objects file:///powershell.exe. The threat caused by Win32/Rozena.XK and Win32/RiskWare.Meterpeter.G is being cleaned but reoccurs after every 5 minutes. Please assist. Attached are the log files

logs_app.zip

logs_ibts.zip

logs_pd1.zip

Edited May 24, 2018 by kingsyno
Attachment

[kingsyno 0]

This is the eset log collector file link

https://wetransfer.com/downloads/b94b47ae2cd7eaa2be89245180b8deed20180523140733/9dedce75de905d6c2075ba651c676c7d20180523140734/15ed1a

[JamesR 52]

3 hours ago, kingsyno said:

The ERA console reported a Trojan on 3 of our windows server caused by (Win32/Rozena.XK, Win32/RiskWare.Meterpeter.G and Powershell/Agent.DG) all with objects file:///powershell.exe. The threat caused by Win32/Rozena.XK and Win32/RiskWare.Meterpeter.G is being cleaned but reoccurs after every 5 minutes. Please assist.

The threats Win32/Rozena and Win32/RiskWare.Meterpeter are both clear indicators that someone is exploiting this server from the outside.  You need to update all software on the server and secure any ports on your perimeter firewall to stop this from happening.  If you believe all software is already updated on the server, then I would suggest you invest in a pentest where the pentester could tell you what services are exploitable from outside your network.  If the holes in the network are not located, isolated, and corrected, you will continue to have security breaches reoccur and ESET will continue to detect the tools being placed by the exploitation of the server.  ESET is doing its job and detecting and removing these, but if the door is wide open (server is exploitable) then these malicious tools will keep reappearing on the server.

[kingsyno 0]

Thank you James. This is well noted but how do we get rid of the threat now?

[JamesR 52]

Patch the server and the threat detection's will stop.  Or disconnect the server from the network and the detection's will stop.  ESET is cleaning the threats off and a hacker is placing them back due to the fact that the server (or another server) is exploitable from the outside world.  I strongly advise that you seek help from a penetration testing team to locate the holes in your network which are being exploited.

Not patching the server and all software on the server will lead to detection's continuing while the server is connected to the network.  In short, the only way to fix this issue is to harden the server (all servers on the network) to stop the intruder who is attacking your network from the outside.

Until the server is patched or exploitable services no longer available to the internet, there is no further help we can provide here.