Jump to content

JamesR

ESET Staff
  • Content count

    35
  • Joined

  • Last visited

  • Days Won

    3

JamesR last won the day on June 26

JamesR had the most liked content!

3 Followers

About JamesR

  • Rank
    ESET North America

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

621 profile views
  1. @mayowa or others in similar situations. Reasons files on a server get encrypted, regardless of security solution: RDP Brute Force succeeded and security solution was removed, then encryption of files began. If Admin rights are gained to a network and an attacker logs in just like an Admin would, then nothing can protect you against any actions they would like to take (Install/uninstall applications, creation of new user accounts, password scrambling of accounts, encryption, stolen data, crypto-currency mining, etc). To mitigate this, either implement 2FA for RDP or only allow RDP to happen across a VPN (the VPN solution should use an authentication method that can not be brute forced. Implementing 2FA on VPN Authentication will prevent a brute force). Its good to know what ports are open on any public IPs for a network. Close any ports that have vulnerabilities or are hosting services that are susceptible to Brute Force attacks. NMAP command to identify open ports on a public IP: nmap -F %PublicIP% Only Shared Files on the server are encrypted due to a workstation which did not have protections installed If a workstation on a domain does not have protections installed and becomes infected, it can locate shares on a network and if the user on the workstation has proper rights to modify, delete, etc... then it will be able to encrypt the files on that share. This can not be stopped by protections on the server due to no process going active on the server. The server simply sees the user on the infected workstation requesting to modify the files and the server allows it. If a workstation where a user is logged in as Domain Admin (or enterprise admin, etc...) then the infection could reach out to any C$ to encrypt. Key problem here is that if you are not auditing systems to ensure security protection is deployed, then you might have an unprotected system that could lead to very serious damage. Disabling or altering of ESET settings beyond their defaults. Disabling items like "Cloud Based Detection" (ESET LiveGrid Reputation System) or other parts of protection will effectively remove layers of protection which are essential to preventing infections. To see if your security is working properly on machines, you can follow the steps on AMTSO to test if your Desktop Security Solutions are working properly. You need to ensure that you follow the instructions on the AMTSO site for each test. Some of the tests are meant to show detection only while a file is being downloaded and not detection while the file is on disk. You can find a list of tests here: https://www.amtso.org/security-features-check/ While these reasons might not be the only reasons someone sees an infection occur on their network, they are the most reasons I have seen.
  2. Using Notepad++ and Regex I was able to strip down all the irrelevant errors and attached the filtered log to this post. All the "archived damaged" and other errors can be ignored as they happen on all computers because ESET will try to treat each file it scans as an archive and will log when it fails to treat it as an archive. The only threat found was this: name="C:\Users\dcombs\Downloads\10.23_request.doc � ZIP � word/vbaProject.bin", threat="VBA/TrojanDownloader.Agent.EVX trojan", action="unable to clean", info="" It might be a good idea to turn on strict cleaning for your scans. This would lead to ESET attempting to delete the file when cleaning of the file is not possible. If you are wanting to see about having improved cleaning for this sample, then you would need to generate an ESET Log Collector log (aka ELC) and submit it to samples@eset.com. Use this KB to download and run ELC and ensure you select "Threat Detection" in the drop down list for ELC: https://support.eset.com/kb3466/ This KB can be used as a reference for submitting samples: https://support.eset.com/kb141/ esetlog_filtered.txt
  3. JamesR

    Malware Win32/Exploit.Agent.NZK

    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.
  4. JamesR

    Malware Win32/Exploit.Agent.NZK

    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.
  5. JamesR

    Malware Win32/Exploit.Agent.NZK

    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
  6. JamesR

    Malware Win32/Exploit.Agent.NZK

    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
  7. JamesR

    Malware Win32/Exploit.Agent.NZK

    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
  8. JamesR

    Malware Win32/Exploit.Agent.NZK

    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
  9. JamesR

    Malware Win32/Exploit.Agent.NZK

    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]
×