JamesR

Its working fine in my test environment. My environment is running: EEI Server version: 1.6.1755.0 EEI Agent version: 1.6.1738 (I need to update this) ESET Endpoint Security version: 8.1.2031 There is also a chance that the command logged is all that was executed on the endpoint. But its very important to know which version of EEI Server, EEI Agent, and ESET Endpoint product. Screen showing this working in my environment:

I think the time change occurring around when this started is just a coincidence. The error you are getting, indicates that your EEI server's Hard Drive is full (or almost full) or that it has run out of RAM. Please check how much free drive space you have on all drives for the EEI server. Even if you installed the SQL database on a second drive, if the main System Drive (C:\) is full, this could lead to SQL not being able to write to C:\Windows\Temp.

I agree with Marcos, this looks like a WMI persistent threat. Manually telling ESET to update its detection engine, should correct the issue of the threat continually being detected. Although, there is a good chance you may already have the update (ESET checks for these updates once per hour). If this does not fix the issue, definitely generate an Autoruns log. Lastly, its not uncommon for Servers to have been infected due to unexpected ports being exposed to the internet. I highly recommend you audit your public IP Addresses with some simple nmap scans to verify what ports are exposed to the internet. nmap -sV -Pn -F %PublicIPAddress%

Just so you are aware, Emotet uses an email phishing technique where it uses legitimate stolen emails and then spoofs the sender to make it look like a continued email communication. It sounds like these trojan downloaders are appearing via that tactic. Do not exclude them or you risk getting a very dangerous worm like Emotet on your network. "One of Emotet's most devious methods of self-propagation centers around its use of socially engineered spam emails. Emotet's reuse of stolen email content is extremely effective. Once they have swiped a victim's email, Emotet constructs new attack messages in reply to some of that victim's unread email messages, quoting the bodies of real messages in the threads." - https://blog.talosintelligence.com/2019/09/emotet-is-back-after-summer-break.html While the above is from 2019, Emotet has recently resurfaced. And there is always the chance some other attacker is imitating their tactics. Definitely focus on examining the email headers to verify the source IP addresses of the Emails. Its likely you are simply the target of a phishing attack.

It sounds like you have purchased 2 internet lines. One where you have a WIFI Router, and one where you are directly connected to the internet. You should put a router between your computer and the internet. You can easily purchase a router that uses a physical network cable instead of using wifi. Your Wifi router may even have extra Ethernet ports as well. But the key thing is, a router is what hides your computer from others being able to directly see and attack your computer. In short, you need some form of physical hardware that will assign your computer a private IP address, thus stopping the attacks. I would recommend a router that supports an Ethernet (hardwired) connection instead of Wifi. As you will need hardware to help protect your computer, there is not much else we can do on the forums. I highly recommended that you may want to talk with your ISP or a local computer technician to assist in configuring a router that will support a wired connection.

The ESET Log Collector log you supplied shows you have a public IP address directly on your computer. This means you are not behind a router. This is very insecure and you will continue to see these attacks until you place your computer behind a router. If you contact your Internet Service Provider (ISP), they may refer to a router as a gateway, residential gateway, 2 in 1 modem, etc... If my talk of Router/Gateway and Public IP address is a new concept for you, I recommend working with your ISP or a local computer technician who can assist in setting up a router to hide your computer from the internet. Again, I can not emphasize this enough, it is very dangerous to connect a computer directly to the internet where it will be assigned a public IP address. Doing so will lead to non-stop attacks like the ones ESET is showing you.

I do not believe the process path of VNC is a problem, its likely that you utilized a custom path for the install. However, if you have not installed VNC or do not allow it, remove it. The root of the problem is that the computer triggering these detections is exposed to the the internet (directly or via port forwarding). I highly recommend you perform an audit of your public IP addresses. If needed, contact your ISP to get a list of IPs you own/use from them or use google to search for "whats my IP address" on different segments of your network. Next, from a computer which is not on your network, perform an NMAP scan of your public IP addresses to see which ports are open to the internet and to attempt to identify what services are on those ports. Here is one example command you could use (the command is case sensitive): nmap -sV -F -Pn ipaddress Replace "ipaddress" with your public IP Address. Nmap results where ports are seen as "OPEN" or "Filtered" are exposed to the internet. Filtered simply means the port was seen but NMAP could connect to it. This could be due to the IP you are scanning from being blocked. Close any open ports that are not needed to be exposed to the internet. If you have ports you must have open, consider restricting which IP Addresses are allowed to connect to these port (only specific trusted IPs or maybe only IPs in specific regions). Also consider moving ports to only being accessible via a VPN. And consider applying 2FA to any ports which require users to enter their usernames and passwords (ESET does have a 2FA product, but it does not work with VNC by default). If you are wanting more logging on this, you can do 1 of 2 things (or both): Use Wireshark to capture network traffic on the computer in question Use port mirroring if needed Create a policy in ESET Security Management Center to enable Diagnostic logging to create a PCAP of network traffic In ESMC, create a New Policy and select your product (Likely "ESET Endpoint for Windows"). In Settings, navigate to "Tools (on left) > Diagnostics (on left) > expand "Advanced Logging" on right Turn on "Enable Network Protection Advanced Logging" You can turn on all diagnostics if you want, but you wont need every diagnostic log for this Apply the policy to the computer you want the diagnostic logs from. Do not forget to remove the policy from the computer after you have gathered logs while the attack was logged. Otherwise you will fill the Hard Drive rather quickly. The diagnostic logs will be saved locally to the computer that generated them in "C:\ProgramData\ESET\ESET Security\Diagnostics". The pcap files can be opened and examined in Wireshark. Once done gathering logs, ensure you turn diagnostic logging off. Diagnostic logging should only be used when needed, and not left on indefinitely.

One other thing. If you are using Services.msc to start the service, it is not uncommon that the Services.msc GUI can not handle a service that takes a long time to start. Instead, can you do the following after you get an error in Services.msc? Open the properties of your MySQL service and and copy the highlighted "Service Name:" at the top of the properties window. This will likely be mysql57 or mysql8 Open an administrative command prompt and issue the following command: sc query ServiceName Replace ServiceName with the name you identified in step one. Like: sc query mysql57 You should see that the service is still starting. Its not uncommon that the MySQL service will take a long time to start. It is allocating memory and hard drive space. If the service is never starting, check how much free space is on your hard drives. If none of the above works or helps, please ensure you gather the logs Marcos requested before replying.

Hello, please update the detection engine in ESET and the detection method should now be corrected, and the .xml no longer detected.

Which version of ESET is installed? If not on v7.x, you will want to upgrade to v7.x ASAP as it has Network Attack Protection which can block EternalBlue (MS17-010) and help prevent reinfection and assist in identifying IP addresses that are attacking computers on your network. This will also help you verify if this infection is spreading via a network exploit or not. From everything you have posted so far, I see no hard evidence of exploitation via MS17-010. Also, if you can provide logs using ELC (https://support.eset.com/kb3466/?locale=en_US&viewlocale=en_US) this can help identify what is occurring. When running ELC, please set the top drop down list to "Threat Detection".

I have replied directly to dandodds. I have been sick lately, but am feeling much better now.

@itman - Screenshot should be there now. Thanks.

If an issue like this ever returns, I recommend using ESET's Firewall to log or block the activity. To do this, simply make a firewall rule similar to the following: Then you should be able to see the offending exe in the Firewall Log for ESET.

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

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