JamesR

@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

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.

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.

@CAB Please download and generate an ELC log from here: https://www.eset.com/int/support/log-collector/ Also, please try this newer version of the WMILister v3.0 on the server. Please supply any logs generated by this tool to me or Marcos so we can ensure we improve in product detection/cleaning. 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: cscript //nologo WMILister_30.vbs If scripts are found, you will be prompted to remove them. The prompt will remove all scripts it finds if you tell it to. Here is an example output for no scripts found: Advanced use: This version 3.0 has command line switches. Use this command to see possible switches: cscript //nologo WMILister_30.vbs /? These are the possible commands to scan and clean remote machines (Port 135 inbound and port 445 outbound both need to be open on remote machine. Same open ports are seemingly used for malware to spread, so infected computers likely already have these ports open). Examples of switch usage are: Machine Name: cscript //nologo WMILister_30.vbs /s:MachineName IP Address: cscript //nologo WMILister_30.vbs /s:10.20.30.40 Force Cleaning with no prompt (use at own risk as this risks removal of non malicious WMI Scripts): cscript //nologo WMILister_30.vbs /f cscript //nologo WMILister_30.vbs /s:MachineName /f cscript //nologo WMILister_30.vbs /s:10.20.30.40 /f

Clean up the tasks and kill powershell and reboot for good measure. That will have those computers cleaned up 1. Delete tasks 2. from admin CMD: taskkill /im powershell.exe /f && shutdown -r -f -t 0 If it comes back, let us know. From my brief analysis of your logs, I didn't see any network spreading capabilities, but I could have overlooked something.

@Lockbits, Just started reviewing your logs. Here is a brief description of what I am seeing. While this is using powershell to execute an Encoded script, WMI is not used for persistence. Looks like its just scheduled tasks used for persistence (as @Marcos said). It is reading a registry value for data. Haven't dived in deep enough to analyze what that data is. Marcos will definitely be able to help get some detection of this added in product. ELC should have everything we need for samples. If we need something extra, Marcos or I will reach out. I do plan on eventually taking my WMILister and incorporating some checks for powershell misuse in scheduled tasks, but dont wait for that. Could be a long while before I get around to that.

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

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

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

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

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]

I would highly recommend to audit what ports are open to the internet and close any that are not needed to be open. Also, if any ports used for remote access (RDP, VNC, etc...), you may want to examine if any over seas IP addresses have been connecting. A simple nmap scan of your public IP can be as follows: nmap -F <IPAddress>

@randomguy 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: This log will also let me know if it is indeed a WMI Persistent threat. Since autoruns flagged WMI, it likely is using WMI persistence and if I remember correctly, autoruns doesn't properly disable WMI scripting (I could be wrong on this and I am not near a test environment). Regards, JamesR

Just an update here. I am working with AdmBr directly. Thanks to @itman for looping me in to this. These Powershell threats are intriguing. Looks like he might already be cleaned up. My WMILister showed no WMI scripts, so I really do not think this is one of the WMI Persistent infections seen in the other forum threads. But I suspect something was coming in via MySQL. I have seen before where SQL Jobs were used to execute multiple cmd commands. From the logs that were provided to me (ESET Log Collector and WMILister logs) it looks like the original symptoms may already be taken care of. There were no connections to any suspect IPs that I saw in his logs. What may have resolved this issue was updating of MySQL and Java. If we get any solid leads on what resolved the issue or how this threat was persisting, I will post a summary of those findings in hopes that it would help any others out there. Of course, I will omit any sensitive info about the server or environment.

Killian, OK, I think I have a plan of attack that should get you cleaned up. I have 4 Powershell commands which have some slightly different, yet very important differences from the original commands you ran. The best method to clean your network is to use the last script I provided on any computers you suspect are infected. If its log has more than just the note lines of the following, then run the commands listed further below: ---WMILister Version:2.3--- ---Possible embeded EXEs--- <Might see this listed a lot, but if not info is below it, then its just a bug I need to fix. If log is empty, no bad scripts were found. Assuming all machines are patched for EternalBlue, here are the steps that should get you back to a clean state. 1. Disconnect infected computers/servers from network 2. Run Powershell with administrative privileges and execute the following commands. If any error out, screenshot them and post them here with a log from the WMILister as well: Get-WMIObject -Namespace root\Subscription -Class __FilterToConsumerBinding -Filter "__Path LIKE '%SCM Event Logs Consumer%'" | Remove-WMIObject -Verbose Get-WMIObject -Namespace root\Subscription -Class CommandLineEventConsumer -Filter "Name='SCM Event Logs Consumer'" | Remove-WMIObject -Verbose Get-WMIObject -Namespace root\Subscription -Class __EventFilter -Filter "Name='SCM Event Logs Filter'" | Remove-WMIObject -Verbose ([WmiClass]'root\default:Office_Updater') | Remove-WMIObject -Verbose 3. Reboot computer ASAP and leave disconnected from network while you repeat the above steps on any other computers or servers which are infected. 4. Leave computers which were infected off the network for at least 2 hours (if possible) after cleaning. Verify if any malicious Powershell processes start up. Reconnect to network, and after about 2 more hours, verify if any malicious Powershell processes return. If malicious processes return after connecting to the network, you still have infected computers which are spreading the infection back to cleaned computers. The most difficult part of cleaning this type of infection from your network is that a single computer could potentially spread the infection back to computers you cleaned. That's why its so important to disconnect any infected computer from the network and leaving them disconnected while cleaning. Any computers which are getting reinfected, you will want to triple check if they are patched for EternalBlue. If infection keeps coming back, Wireshark logging during the time of reinfection may help us identify which machine is still infected and reinfecting computers and SysInspector logs from those computers will help us identify anything that is not hiding in the WMI.

Killian, Looks like you may have accidentally ran the old vbs script. Attaching the latest one here. I added logging line of the version of the tool to be the first line of the log. So if you open the log, you should see "---WMILister Version:2.3---" as the first line. Basically, I didnt get the embedded EXEs and one other part that would tell us if there is a scheduled task. The likely causes for reinfection are: 1. Scheduled task (usually running a y1.bat) 2. Other computers/servers on network are infected (this infection is a worm. It can use 2 methods to spread across a network. A. using admin credentials to spread. B. Using EternalBlue exploit to spread.) What we need to do to get you fully clean: 1. Ensure you have an Antivirus solution on all machines (if you don't have any current AV on any computers/servers, let me know) 2. Submit samples of the embedded EXEs that the attached script file will dump to your Antivirus company (I can assist in making a package to submit to your AV vendor.) - Submitting these samples is very important as it will ensure your AV will be able to block these files when they are extracted from the WMI database and any other machines that are infected will start getting alerts as well. 3. Patch any and all machines on your network against EternalBlue. 4. Have patience. Network spreading worms can be very frustrating to get cleaned up. The larger the network, the more time it takes to clean these nasties up. I will PM you with a few questions that are a bit more specific about your network. WMILister_23.txt

Killian, --Edit-- I updated the script based off of one what I saw in one of your logs. An extra class named Office_Updater. Script that is attached should be named WMILister_22.txt. Please use this regardless of if you are no longer getting Powershell using 100% of CPU. There are some embedded EXE's in your WMI database and I updated this script specifically so we can identify them and I can assist in getting that cleaned up from your server. --End Edit-- You might be clean by now if you ran the 4 powershell commands and rebooted. The 4th powershell command likely failed because you do not have an "ActiveScriptEventConsumer" entry in the WMI database to clean up (this area shows as not logged in the log you provided). If you are uncertain if you are now clean or not, you can do the following: 1. Save the attached file and rename it to have an extension of .vbs (this is a slightly improved version of the script you ran. One tiny bug fix and some extra logging of WMI Queries which can assist with removal of bad scripts.) 2. From an administrative command prompt, change directories to where you saved the .vbs file and run the command: cscript //nologo WMILister_22.vbs > DumptedScripts.txt 3. Attach the log here and I can assist with verifying if you are clean or what your next steps should be. ****IMPORTANT**** This type of infection is very commonly introduced after a successful RDP Brute force attack. This means someone likely has access to RDP into your server (or servers) with full administrative privileges. You may need to close port 3389 to the outside world and then change all passwords for all accounts with RDP access. I highly recommend implementing 2FA to protect RDP or implement a VPN with 2FA (ESET Secure Authentication can implement 2FA on RDP and VPNs). Also, this type of infection can use the EternalBlue exploit to assist in spreading to other computers on your network (it can also spread with the administrative rights it likely already has or obtained via mimikatz). You should ensure you patch any computers and servers to prevent this exploit. To find out if a machine is patched or not, you use the ESETEternalBlueChecker. - Tool located here: https://help.eset.com/eset_tools/ESETEternalBlueChecker.exe - Instructions for running are here: https://support.eset.com/kb6481/ WMILister_22.txt

Using your sysinspector, I found the following info: 1. Both mrwdaasmd64.exe and pdrws.exe are copies of wscript.exe (this will prevent the HIPS rule ITMAN mentioned from stopping this infection) 2. You have a shortcut in your User's startup folder which is pointing to the pdrws.exe To remove this infection from your computer, please do the following: 1. Run the command taskkill /im emfnsqkj\mrwdaasmd64.exe /f & taskkill /im pdrws.exe 2. Rename the folder "c:\users\fakhriatulyaya\appdata\roaming\emfnsqkj" to "emfnsqkj_vir" 3. Move the shortcut file located in "c:\users\fakhriatulyaya\appdata\roaming\microsoft\windows\start menu\programs\startup\" into the "emfnsqkj_vir" folder (you might need to turn on viewing of "Hidden" and "System" files to see the shortcuts). Check the "Properties" of any shortcuts to find the wone that is loading the "pdrws.exe" 4. Reboot your computer and verify detection stops occurring. 5. If all is well, generate an ESET Log Collector ( https://download.eset.com/com/eset/tools/diagnosis/log_collector/latest/esetlogcollector_enu.exe ) and place the generated .zip in the "emfnsqkj_vir" folder, then zip up and password protect the "c:\users\fakhriatulyaya\appdata\roaming\emfnsqkj_vir" folder. Use the password "infected" without quotes, and submit the sample to samples@eset.com Let me know if this helps.

Here are some PowerShell commands to remove the WMI infections. 1. First open PowerShell as admin 2. Run the commands 3. Reboot and rerun the vbs script I provided. If its a one line text file, then you are clean on that server. 4. Verify servers and workstations are patched for EternalBlue using this tool https://help.eset.com/eset_tools/ESETEternalBlueChecker.exe (full instructions for use here: https://support.eset.com/kb6481/ ) 5. Close port 3389 on your router (this is likely open and needs to be closed while you reset all passwords for all users) To prevent an RDP brute force, you can enforce password policies to log out after a handful of attempts. Also implementing 2FA will prevent a password from being used, if it is compromised. ESET does have a 2FA product. Let us know if you are interested in that. Get-WMIObject -Namespace root\Subscription -Class __EventFilter -filter "Name= 'SCM Event Filter'" |remOVe-WMIObject -Verbose Get-WMIObject -Namespace root\Subscription -Class CommandLineEventConsumer -Filter "Name='SCM Event Consumer'" | Remove-WMIObject -Verbose Get-WMIObject -Namespace root\Subscription -Class __FilterToConsumerBinding -Filter "__Path LIKE '%SCM Event Consumer%'" | REmOVE-WMIObject -Verbose ([WmiClass]'root\default:Win32_TaskService') | Remove-WMIObject -Verbose Get-WMIObject -Namespace root\Subscription -Class ActiveScriptEventConsumer -Filter "Name='SCM Event Consumer'" | Remove-WMIObject -Verbose This last command ins't needed for your environment. But run it just in case my logging didn't find any ActiveScriptEventConsumer items.

Just messaged you a link to upload the files to. Its a secure location that only I have access to. You can also use WinRar if needed.

Sounds like you have malware using WMI for persistence. Its likely using your server for bitcoin mining and might be trying to spread using EternalBlue. This type of infection is typically the result of a Brute Force RDP attack that succeeded in guessing administrative credentials. I highly recommend getting an expert on your system to assist with cleaning. I'm going to try and provide some steps here for remediation. 1. Save the attached file and rename it to have an extension of .vbs (I will supply this in a PM directly to you. This VBS will log any non-expected scripting in the WMI database) 2. from an administrative command prompt, change directories to where you saved the .vbs file and run the command: cscript //nologo WMILister_20.vbs > DumpedScrpts.txt 3. Zip up and password protect the .txt file and attach it to a reply on this thread. (I will PM you the password to use. 7zip is a good tool to zip and password protect.) I will use this log to help remediate the issue. If you are running the script on multiple servers, just add the name of each server to the logs. Some more info on what I believe you have been infected by can be found here (use google translate as needed): http://www.freebuf.com/column/149286.html

From the log you provided, only the E: drive appears to be affected. This is likely a drive that is hosting shares to the network. If this is true, then it is not the Server itself which is infected and there is another computer on your network which is infected and likely not protected by a security product. These can be tricky to resolve, but if you examine the Threat Logs in the ESET Security product installed on the server, instead of ERA, then you should see a column indicating a user name which is generating the threat alert. As long as it shows an actual username (not "NT Authority/System") you will now have the user account which is creating the malicious .lnk files and you simply need to identify which computer that user is logged in from. If the above doesn't work, you can try and isolate which computers are not protected by an ESET Product in ERA and then install ESET on those computers. However, this isn't fool proof as a computer which is on your network, but not in Active Directory wont show in ERA. Attached screen shows where to go in ERA to sort your lists to find computers which don't have ESET Security products installed. In short, your server is protected but you have at least 1 or more computers on your network, which are not protected by ESET. Once you find these computers, you will be able to remedy your situation.

Sentroshi, If you can provide me with the ESET logs in a PM, I can try to help verify what is causing the alerts to trigger. Please follow the instructions below and then PM me the zip file made. 1. Download the ESET log collection tool by clicking or copy/pasting the following URL into the address bar of your web browser: ------------------------------------------------------------------------------ hxxp://download.eset.com/special/ESETLogCollector.exe ------------------------------------------------------------------------------ 2. Save the file "ESETLogCollector.exe" to the desktop of your system. 3. Right-click the file and select "Run as administrator". If prompted, enter the username and password for an administrative account. 4. Click "Accept" to accept the End-User License Agreement (EULA). 5. Click "Collect & Archive". This will generate a zipped archive containing logs from your system and any installed ESET antivirus product. The archive will be saved using the file path and file name specified in the "Save archive as" field. Please wait until you see the message "All files have been collected and archived." It may take some time to process.

Hello, For any Gigabit users recieving BSOD's, can you try the following to uninstall System Information Viewer from Programs/Features? System Information Viewer will be labeled as SIV. Steps for those with ESET already installed and recieving BSOD's: 1. Boot to Safe Mode 2. Open an administrative command prompt and run the following 2 commands to allow unisntalls (we will undo this later): REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\MSIServer" /VE /T REG_SZ /F /D "Service" REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\MSIServer" /VE /T REG_SZ /F /D "Service" 3. Navigate to "Control Panel" then "Programs and Features" 4. Locate SIV and uninstall it 5. Back in your administrative command prompt, run the following 2 commands undo what was done in step 2 REG DELETE "HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\MSIServer" REG DELETE "HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\MSIServer" 6. Reboot your computer and verify if all is well. Steps for those who do not have ESET installed: 1. Navigate to "Control Panel" then "Programs and Features" 2. Locate SIV and uninstall it 3. Install ESET and update If this works to resolve the issue, please reply to this post.