JamesR

Hello, I tested and verified that file with hash 062683257386c9e41a1cd1493f029d817445c37f7c65386d54122fa466419ce1 is already detected as "Win32/Filecoder.BlackMatter.O". I do have a few questions: Can you verify what "detection engine" version is on your ESET Endpoints? Latest should be 29130 Open ESET on an endpoint, and go to "Update", then click "Show All Modules". Can you verify if you were hit with ransomware, or are you just testing samples? If you were hit with ransomware, then it means your network was compromised days prior to the ransomware deploying. Modern ransomware attacks begin as an adversary gaining access to your network, then living off the land to move around the network. Some methods of compromising a network, do not need any malware (RDP/RDS, SMB are just a few examples of services which can commonly lead to a full network compromise). You should be looking for signs of user accounts performing suspicious activity inside of Inspect (XDR). If you are simply performing tests, then you need to focus on verifying ESET is activated and updating and that you have not created exclusion which would prevent ESET from detecting samples.

As the problem is with MySQL being unable to start, you will need to look at the following logs/files for problems. C:\ProgramData\MySQL\MySQL Server 8.0\my.ini Verify this is configured properly by referencing: https://help.eset.com/ei_deploy/2.1/en-US/?mysql_installation.html C:\ProgramData\MySQL\MySQL Server 8.0\Data\%ServerName%.err Replace %ServerName% with the name of your server. Examine the end of this log for any entries which line up with when you attempt to start the MySQL service. This can help identify configuration problems, corruption, or lack of free RAM/Memory at start of service, or some other issue. Hardware requirements to double check: Verify there is at least 26 GB of free RAM/Memory prior to attempting to start MySQL This is the main issue I see when an On-Prem inspect server stops working after weeks/months/years of working fine, but no one is managing Inspect on a daily basis. This is assuming the my.ini is properly configured to allow MySQL to allocate up to 80% of all RAM (your screenshot shows the server having 32GB of RAM) to itself. Its not uncommon for systems using lower amounts of RAM to no longer have enough free RAM available to allow MySQL to start properly after months of Inspect data has been logged. This can be an even bigger issue when Inspect is not being managed daily to resolve detections. I recommend to watch the available memory via "TaskManager's Performance Tab" while starting the MySQL service, you might see that all available memory gets used up, or very close to 100% used. If this is the case...more RAM will need to be installed/added. The fix for this would be to increase the available RAM and to adjust the my.ini configuration accordingly (both innodb_buffer_pool_size and innodb_log_file_size Verify there is enough free space on each hard disk (from the logs you provided, this is likely not the issue). Other thoughts: Inspect version 1.12 is installed. Latest available is v2.1. But its likely you will need to correct the MySQL problems prior to upgrading. If MySQL wont run, then upgrading will fail.

Your rule looks good and ready for testing/use.

Just sharing how I would exclude this. It super similar to Marcos'. Main difference is that I am using "IpAddressV4" which should work for any networking event. The "DestinationIpAddressV4" may be restricted to Firewall IDS network connections...admittedly, I haven't tested yet. The operation type of "TcpIpConnect" is for outbound connections, and is my preferred method of restricting to outbound. If I wanted inbound, I would use the operation type of "TcpIpAccept" instead. <operations> <operation type="TcpIpConnect"> <operator type="and"> <condition component="Network" property="IpAddressV4" condition="is" value="13.69.128.10"/> </operator> </operation> </operations>

Correct. Its best to separate into 2 different exclusions.

I would not recommend this. When you create an advanced exclusion, which will use an <operation type="...">, you should have it match the operation type of the triggering event. If you try to use an exclusion with a "DllLoad" operation, and apply the exclusion to a rule which is looking for "CodeInjection", your exclusion will not work as expected. In short, mixing and matching different operations in an exclusion, can break your exclusion. Also, it appears you may be using an older version of our On Premise solution. I would recommend upgrading when you can. The rule tag "[F0413b][C]" is outdated and has been replaced with "[F0413b]".

How often a rule triggers on an event, is dependent on a customer's environment. If a new process starts, and exhibits a behavior which would trigger a rule, that process will trigger the rule. From your screenshot you can see there is a different "Process Name (ID)" for each detection and the same executable each time. This tells me that the executable "7kmdtosm.exe" is being executed multiple times and performing actions which trigger rule "[C0628]". If you have confirmed these detections are not a sign of an attack, you can stop the rule from triggering on this behavior by creating an exclusion. I would recommend using the following Advanced Exclusion as a starting point. The following is an example of how to start building an exclusion for rule [C0628]. Ensure you customize this to match what you are seeing in your own environment. <definition> <process> <operator type="and"> <condition component="FileItem" property="FullPath" condition="is" value="C:\Full\Path\to\7kmdtosm.exe" /> </operator> </process> <!-- Following Operations describe the location and file extension which 7kmdtosm.exe would be writting to. You will need to ensure this matches data you see in your own environment by using the "Trigger Event" column in a detections list, or by opening the details of a detection and looking for the Trigger Event section. --> <operations> <operation type="WriteFile"> <operator type="and"> <condition component="FileItem" property="Path" condition="is" value="%HOME%\Documents" /> <condition component="FileItem" property="Extension" condition="is" value="xyz" /> </operator> </operation> <operation type="RenameFile"> <operator type="and"> <condition component="FileItem" property="Path" condition="is" value="%HOME%\Documents" /> <condition component="FileItem" property="Extension" condition="is" value="xyz" /> </operator> </operation> </operations> </definition>

Your rule is targeting a Process which will have low LiveGrid reputation and popularity. How are you testing the rule? If you are testing by simply downloading an EXE to the system, this will not trigger and would require a more advanced rule (<operations> section).

@Quizzical9796 What you are seeing is not caused by a threat. And it will be best for you to contact your local ESET support to get a ticket and potentially more thorough troubleshooting steps. Some things which can cause what you saw: Older version of ESET Endpoint Protection or Inspect Connector on the endpoint. Ensure you are using the latest versions of Endpoint and Inspect Connector (and latest Inspect Server...if you are using Cloud, you are on latest Inspect Server). Possible solution: Updating to latest versions of endpoint and inspect may resolve this problem Blocking of ESET servers on endpoints If your network is using a UTM/Next Gen Firewall, there is a good chance many of ESETs public servers are being blocked and could lead to ESET not being able to check the validation of a certificate seen on an executable. As the endpoints and the server will both be checking ESET servers for a multitude of things, it could be that your endpoints cant communicate with a handful of ESET servers while your Inspect server has no issues communicating with ESET servers. Possible solution: Ensure you have added ESET public servers to any whitelists/allow lists/exclusions on your UTM/Next Gen Firewall. Full list of servers with Domains/IPs is here: https://support.eset.com/en/kb332-ports-and-addresses-required-to-use-your-eset-product-with-a-third-party-firewall Your local support teams may be able to assist with identifying if there are any communication problems with any ESET servers which could cause what you are seeing.

I was able to get an exclusion working for rule "Powershell.exe creates an external network connection [A0502b]" which has a trigger event of " TcpIpConnect 123.234.231.210:443 (my.example.cloud.azure.com)" (No those are not real IPs or Domains for my test...just examples). Here is the exclusion I made that worked. You should be able to use your "Port" condition as well. Main difference between how I made the "Hostname" condition from yours, is that I used "is", where you used "contains". If it is an exact match, you should use "is". I would also recommend using "Starts" or "Ends" instead of "contains". If this does not help, please let me know what the rule name is so I can try and simulate this in my test environment. Also knowing the EI Server version and EI Connector version, may be important. <definition> <operations> <operation type="TcpIpConnect"> <operator type="and"> <condition component="Network" property="Hostname" condition="is" value="my.example.cloud.azure.com" /> </operator> </operation> </operations> </definition>

Just checked the file internally. We detect it as "Win64/Zemana.A potentially unsafe application".

Appologies for the delay, I didn't see a notification in my inbox (#PEBKAC) Should be something like this: <definition> <operations> <operation type="CreateProcess"> <operator type="AND"> <condition component="FileItem" condition="is" property="FileName" value="NameOfProcessSeen.exe" /> <condition component="FileItem" property="Path" condition="starts" value="C:\path\to\expected\file\"/> <!-- change the condition from "is" to "starts/ends/contains" as needed --> <condition component="ProcessInfo" property="CommandLine" condition="is" value="&quot;Helpdesk-XYZ&quot; -v &quot;v4.0&quot; -l &quot;webengine4.dll&quot; -a \\.\pipe\*.* -h &quot;C:\inetpub\temp\*.*&quot;"/> </operator> </operation> </operations> </definition> As you can see, all " became &quot; There are many other characters that sometimes need to be converted to their HTML Entity equivalent. The ones I most commonly run into are: & = &amp; " = &quot; < = &lt; > = &gt; If needed, you can use cyberchef's "To HTML Entity" to change a lot of characters into their HTML equivalent ( https://gchq.github.io/CyberChef/#recipe=To_HTML_Entity(false,'Named entities') )

I believe you are building an exclusion for rule "Generic IIS backdoor activity - child process [F0403]" (the ID at the end of the rule name is the most important identifier of the rule. Your exclusion will need to be an Advanced Exclusion and will need to be built to describe the child process to w3wp.exe Here is how to start building the Advanced Exclusion. Begin creating your exclusion as usual. When you get to the criteria you showed in your screenshot, use the "Advanced Editor" button on the top right of the screen. Build XML similar to the following examples and your exclusion should work. Example 1 - excluding single process with single command line <definition> <operations> <operation type="CreateProcess"> <operator type="AND"> <condition component="FileItem" condition="is" property="FileName" value="NameOfProcessSeen.exe" /> <condition component="FileItem" property="Path" condition="starts" value="C:\path\to\expected\file\"/> <!-- change the condition from "is" to "starts/ends/contains" as needed --> <condition component="ProcessInfo" property="CommandLine" condition="is" value="/some command /line parameters"/> <condition component="Module" condition="is" property="SignatureType" value="Trusted" /> <condition component="Module" property="SignerName" condition="is" value="Im a signature"/> </operator> </operation> </operations> </definition> Example 2 - excluding single process with multiple possible command lines <definition> <operations> <operation type="CreateProcess"> <operator type="AND"> <condition component="FileItem" condition="is" property="FileName" value="NameOfProcessSeen.exe" /> <condition component="FileItem" property="Path" condition="starts" value="C:\path\to\expected\file\"/> <operator type="or"> <!-- change the condition from "is" to "starts/ends/contains" as needed --> <condition component="ProcessInfo" property="CommandLine" condition="is" value="/some command /line parameters"/> <condition component="ProcessInfo" property="CommandLine" condition="is" value="/other possibleCommand /line parameters /as needed"/> </operator> <condition component="Module" condition="is" property="SignatureType" value="Trusted" /> <condition component="Module" property="SignerName" condition="is" value="Im a signature"/> </operator> </operation> </operations> </definition> Example 3 - Excluding multiple proccesses <definition> <operations> <operation type="CreateProcess"> <operator type="or"> <operator type="AND"> <!-- First process to describe --> <condition component="FileItem" condition="is" property="FileName" value="NameOfProcessSeen.exe" /> <condition component="FileItem" property="Path" condition="starts" value="C:\path\to\expected\file\"/> <condition component="ProcessInfo" property="CommandLine" condition="is" value="/some command /line parameters"/> <condition component="Module" condition="is" property="SignatureType" value="Trusted" /> <condition component="Module" property="SignerName" condition="is" value="Im a signature"/> </operator> <operator type="AND"> <!-- Next process to describe --> <condition component="FileItem" condition="is" property="FileName" value="SecondProcess.exe" /> <condition component="FileItem" property="Path" condition="starts" value="C:\DifferentPath\to\expected\SecondFile\"/> <operator type="or"> <!-- change the condition from "is" to "starts/ends/contains" as needed --> <condition component="ProcessInfo" property="CommandLine" condition="is" value="/more command line items"/> <condition component="ProcessInfo" property="CommandLine" condition="is" value="/other possibleCommand /line parameters /as needed"/> </operator> <condition component="Module" condition="is" property="SignatureType" value="Trusted" /> <condition component="Module" property="SignerName" condition="is" value="Im a DIFFERENT signature"/> </operator> </operator> </operation> </operations> </definition>

@kaboomcanuck Unfortunately your description of the issue does not allow us to identify the source of the TCP Port Scan (Win32/Botnet.generic) detections. This means we cannot yet state if these are being performed by an internal or external IP Address. The best way for us to see what was detected, would be to gather ESET Log Collector logs and provide them to us. At a minimum, please perform step 3 of Marcos' steps. If the source IPs are public IP addresses, and the local ports are not needed to be exposed to the internet, you should close off these ports from the internet (disable port forwarding, place device behind a NAT/Firewall, etc). Any services that can be used to administer a network, should not be exposed to all public IPs on the internet and should be restricted to only IPs which are trusted and allowed to connect. It would be best to block any and all public IPs to administrative services/ports and only allow access to these via private IPs and/or a VPN. If the source IPs are private IPs, you will need to locate the devices with these private IPs and identify if they are devices intended to be performing port scans of the network. If they are not intended to be performing port scans, you will want to ensure endpoint protection is installed and any AV scans have been performed to help rule out malware as the cause. Keep in mind that some software will actively scan a network to identify other devices and that it may not be malware performing the TCP Port scans.

Here is my suggestion with comments to explain what I changed in your exclusion <definition> <!-- <parentprocess> seciton not needed, as it is already built in to rule [F0404] --> <process> <operator type="AND"> <condition component="Module" property="SignatureType" condition="greaterOrEqual" value="90" /> <operator type="OR"> <!-- restricted CMD to only expected command lines. May want to modify to 'condition="is"' and use full command line. --> <operator type="AND"> <condition component="FileItem" property="FileName" condition="is" value="cmd.exe" /> <condition component="ProcessInfo" property="CommandLine" condition="starts" value="/c &quot;start php.exe eject"/> </operator> <condition component="FileItem" property="FileName" condition="is" value="conhost.exe" /> </operator> <operator type="OR"> <condition component="FileItem" property="Path" condition="starts" value="%SYSTEM%" /> <condition component="FileItem" property="Path" condition="starts" value="%WINDIR%\syswow64\" /> </operator> <condition component="Module" property="SignerName" condition="is" value="Microsoft Windows" /> </operator> </process> <!-- If exclusion is still not working, remove entire operations section and test. --> <operations> <operation type="CreateProcess"> <!-- Was using an "and", but a created process will only ever have a single full path --> <operator type="or"> <condition component="FileItem" property="FullPath" condition="is" value="c:\php\php.exe" /> <condition component="FileItem" property="FullPath" condition="is" value="c:\php\php-cgi.exe" /> </operator> </operation> </operations> </definition>

Since it is from internal IPs, you should verify if those IPs have Vulnerability scanners or software which may be port/service scanning (some software proactively does silent services scans on the network to identify remote machines and it can be hard to identify which software is doing this). Its more than just the TCP handshake. Its the TCP handshake followed by the initial request of RDP or SMB which ends before any real info is transferred. Service based port scans send the minimum amount of information required to attempt and identify what service may be hosted on a port. If you find these to be benign detections, you can use the following template to build an "Advanced Exclusion" for these: <definition> <operations> <operation type="TcpIpProtocolIdentified"> <operator type="or"> <!-- exclude specific IPs --> <condition component="Network" property="IpAddressV4" condition="is" value="192.168.2.123" /> <condition component="Network" property="IpAddressV4" condition="is" value="192.168.2.124" /> <!-- exclude specific subnets --> <condition component="Network" property="IpAddressV4" condition="isnot" value="192.168.5.0/24" /> <condition component="Network" property="IpAddressV4" condition="isnot" value="172.16.29.0/24" /> </operator> </operation> </operations> </definition> Note: To make an Adv Exclusion: While creating an exclusion, and on the "Criteria" section, click the "Advanced" button in the top right of the GUI.

"TruncateFile" is an operation which falls under "WriteFile" (yes, annoying that it isn't clearly labeled as such). But you should be able to modify your exclusion as follows to allow it to work. <operations> <operation type="WriteFile"> <operator type="OR"> <condition component="DestFileItem" property="Extension" condition="is" value="dce" /> <condition component="DestFileItem" property="Extension" condition="is" value="blabla" /> </operator> </operation> </operations>

@SEV0218 For rule "Protocol Mismatch - detected RDP communication over non-standard port [E0517]", it is important to identify if it is inbound or outbound events causing the detections. You can see the same issue you are speaking of has been addressed in this post here: Its very likely that you have ports exposed to the internet, and public IP Addresses are performing port scans of your public IPs and testing what is hosted on each port (AKA Service Scan). This can lead to inbound connections on ports like DNS (53) where the port is tested to see what is on. This will lead to RDP communication being seen on port 53 and other ports, as they are being tested to see if they host RDP on those ports. Its likely the port scans are also working to see if other services like SMTP, DNS, SMB, etc... are on any ports visible to the public. I highly recommend auditing what ports you need exposed to the internet and work towards closing any ports which should not be exposed to the internet. For ports you cannot close, you should work towards restricting who and what can access those ports.

In ESET Inspect the WMI Persistence events are made up of multiple parts. These parts are "Query", "Invoke", and "Set by user". From your screenshot, I can see that Whenever a query of: "select * from __namespacecreationevent", the action of "" will be invoked. And that this was set by a user with no name. The important part is, the item to be invoked, is nothing. This means nothing happens when the query criteria is seen on the system. In short, this Inspect detection by itself, is not malicious. I would recommend to look for other detections on the same computers which would add to the the story of what happened. If you see nothing on interest, then this is a false positive which should be excluded. If you decide there is no malicious activity which is related to this, and want to exclude this from triggering again, you can use the following as a template for creating the exclusion. <definition> <operations> <operation type="WmiPersistence"> <operator type="and"> <condition component="WmiPersistenceInfo" property="Query" condition="is" value="select * from __namespacecreationevent" /> <condition component="WmiPersistenceInfo" property="Handler" condition="isempty"/> <condition component="WmiPersistenceInfo" property="TriggeringUserName" condition="isempty"/> <!-- if the above does not work, try changing both "isempty" to "isnotset" --> </operator> </operation> </operations> </definition>

As rule F1108a is only looking for execution of netsh processes, there is no need to specify the "FileName" item in your exclusions. I will assume you are seeing something similar or identical to the following (screen is from my test environment): The exclusion I would recommend: <definition> <process> <operator type="AND"> <condition component="Module" property="SignatureType" condition="greaterOrEqual" value="90" /> <!-- Defining process name is not needed as the rule F1108a will only trigger for netsh. Including it is redundant --> <!--<condition component="FileItem" property="FileName" condition="is" value="netsh.exe" />--> <condition component="FileItem" property="Path" condition="is" value="%SYSTEM%\" /> <condition component="ProcessInfo" property="CommandLine" condition="is" value="interface tcp show global" /> <condition component="Module" property="SignerName" condition="is" value="Microsoft Windows" /> <condition component="ProcessInfo" property="ProcessOwner" condition="is" value="nt authority\system" /> </operator> </process> <parentprocess> <operator type="AND"> <condition component="Module" property="SignatureType" condition="greaterOrEqual" value="90" /> <condition component="FileItem" property="FileName" condition="is" value="msexchangehmworker.exe" /> <condition component="FileItem" property="Path" condition="is" value="%PROGRAMFILES%\microsoft\exchange server\v15\bin\" /> <!-- This OR operator is to list each possible command line you are seeing. Customize this to meet your needs--> <operator type="or"> <!-- I only had 5 of these -pipe: commands out of thousands of triggerd detections --> <operator type="and"> <condition component="ProcessInfo" property="CommandLine" condition="starts" value="-pipe:" /> <condition component="ProcessInfo" property="CommandLine" condition="ends" value=" -workerListening" /> </operator> <!-- This was the bulk of my detections where no command line was present...but these were also processes which were older than my retention and may not be needed for your environment --> <condition component="ProcessInfo" property="CommandLine" condition="isempty" /> </operator> <condition component="Module" property="SignerName" condition="is" value="Microsoft Corporation" /> <condition component="ProcessInfo" property="ProcessOwner" condition="is" value="nt authority\system" /> </operator> </parentprocess> </definition> As you can see, I am being a bit strict on this exclusion by clearly defining the behavior I want to exclude. This is because this is an exchange server and likely has some portion of itself, exposed to the internet (Email flowing from the internet, OWA, etc...). With the amount of Exchange exploits and zero days found in the past few years (ProxyShell, ProxyLogon, ProxyNotLogon, etc...), I would rather be very clear in what I am excluding on an exchange server. If you have problems making this exclusion working, try commenting out or removing the "SignatureType" and "SignerName" items. If your exclusion only works after that, let us know which EI Server and EI Connector versions you are using.

I think that will be enough info. I have 2 possibilities for you. Both use a parent child relationship. You will see I put a comment in both as you do not need to specify schtasks in the <process> section of the exclusion. Since the rule will only trigger on schtasks.exe, its not needed to include in the exclusion. But my exclusions do ensure your schtasks.exe is being run from expected locations. If all schtasks commands have a single unique item between every execution <definition> <process> <operator type="AND"> <!-- Not needed as rule is already confriming it must be this file name<condition component="FileItem" property="FileNameWithoutExtension" condition="is" value="schtasks"/>--> <condition component="FileItem" property="Path" condition="is" value="%SYSTEM%\"/> <condition component="ProcessInfo" property="CommandLine" condition="contains" value="/RU SYSTEM /SC ONCE /ST HH:MM /RL HIGHEST /TR FullPath of program.exe"/> </operator> </process> <parentprocess> <operator type="AND"> <condition component="FileItem" property="FileName" condition="is" value="program.exe"/> <condition component="FileItem" property="Path" condition="is" value="%SYSTEM%\"/> <condition component="ProcessInfo" property="CommandLine" condition="contains" value="-some /parent commandline"/> </operator> </parentprocess> </definition> If each execution of your schtasks could have more than one possible command line. Lets say you have 3 different unique parts to a command line. <definition> <process> <operator type="AND"> <!-- Not needed as rule is already confriming it must be this file name<condition component="FileItem" property="FileNameWithoutExtension" condition="is" value="schtasks"/>--> <condition component="FileItem" property="Path" condition="is" value="%SYSTEM%\"/> <operator type="or"> <condition component="ProcessInfo" property="CommandLine" condition="contains" value=" /RL HIGHEST "/> <condition component="ProcessInfo" property="CommandLine" condition="contains" value="/RU SYSTEM /SC ONCE "/> <condition component="ProcessInfo" property="CommandLine" condition="contains" value="/RU SYSTEM /ST HH:MM /TR FullPath of program.exe"/> </operator> </operator> </process> <parentprocess> <operator type="AND"> <condition component="FileItem" property="FileName" condition="is" value="program.exe"/> <condition component="FileItem" property="Path" condition="is" value="%SYSTEM%\"/> <condition component="ProcessInfo" property="CommandLine" condition="contains" value="-some /parent commandline"/> </operator> </parentprocess> </definition>

For this detection, we need a bit more info to assist in building/recommending an exclusion. Can you provide the following info? Name of executable which is parent to schtasks: Command line which goes with the parent of schtasks: Command line of schtasks process you are starting:

@Mauro Tre Thank you for gathering these final logs. This helped me to confirm my suspicions. There is no sign of any malicious scripts or executables being executed on your system. The on demand scans you are running, are scanning the WMI database and the specific location in the WMI causing detections is the "Windows PowerShell" event log. There are no infections living inside of the WMI database, its just a coincidence that one can access event logs via WMI, which means that ESET can access and scan the event logs via WMI. I am not finding any way to delete specific entries inside of an event log. It looks like Microsoft only allows for all entries to be cleared from an event log. What this means is that in order to stop the On Demand scan from triggering detections, you need to clear the "Windows PowerShell" event logs. Before clearing out the "Windows PowerShell" Event Viewer logs, definitely back them up first. Technically, you already backed them up with the second command I provided previously. Here are the steps to first backup, then clear the "Windows PowerShell" event logs Backup "Windows PowerShell" logs: Copy-Item -Path "$($env:SystemRoot)\System32\Winevt\Logs\Windows PowerShell.evtx" -Destination "$($env:USERPROFILE)\Desktop\ForESET_Windows_PowerShell.evtx" Clear "Windows PowerShell" logs: Clear-EventLog "Windows PowerShell" After this, you should no longer receive detections when running a scan with ESET. Summary of findings from all the logs we gathered: "Windows PowerShell" event viewer logs show logging of multiple PowerShell commands being executed as far back as 2021 ESET installed sometime in 2022 and immediately cleaned up multiple WebShells related to CVE-2021-26855 The above shows that it it is very likely that CVE-2021-26855 was used to remotely plant and execute the WebShells which were executing PowerShell commands that were then logged in the "Windows PowerShell" event logs -Edited- to add one picture showing the link between the ESET scan logs and the Event Viewer log containing the malicious PowerShell command.

@Mauro Tre I have 2 more logs I would like to gather from your computer. This will require you to manually run the 2 powershell commands. First open PowerShell as Admin Next run the following 2 commands Get-WmiObject -ComputerName "." -Query "SELECT * FROM Win32_NTLogEvent WHERE Logfile='Windows PowerShell' AND (RecordNumber=4363 OR RecordNumber=4362 OR RecordNumber=4361 OR RecordNumber=4360 OR RecordNumber=4359 OR RecordNumber=4358 OR RecordNumber=4357 OR RecordNumber=4356 OR RecordNumber=4355 OR RecordNumber=4354 OR RecordNumber=4353 OR RecordNumber=4352 OR RecordNumber=4351 OR RecordNumber=4350 OR RecordNumber=4349 OR RecordNumber=4348 OR RecordNumber=4347 OR RecordNumber=4346 OR RecordNumber=4345 OR RecordNumber=4344 OR RecordNumber=4343 OR RecordNumber=4342 OR RecordNumber=4321 OR RecordNumber=4320 OR RecordNumber=4319 OR RecordNumber=4318 OR RecordNumber=4317 OR RecordNumber=4316 OR RecordNumber=4315 OR RecordNumber=4314 OR RecordNumber=4313 OR RecordNumber=4312 OR RecordNumber=4311 OR RecordNumber=4310 OR RecordNumber=4309 OR RecordNumber=4308 OR RecordNumber=4307 OR RecordNumber=4306)" | ConvertTo-Csv -NoTypeInformation | Set-Content -Path "$($env:USERPROFILE)\Desktop\ForESET_PwshWmiQEventLog.csv" Copy-Item -Path "$($env:SystemRoot)\System32\Winevt\Logs\Windows PowerShell.evtx" -Destination "$($env:USERPROFILE)\Desktop\ForESET_Windows_PowerShell.evtx" This will save 2 files to your desktop ForESET_PwshWmiQEventLog.csv ForESET_Windows_PowerShell.evtx Please run the commands, then zip up the 2 logs on the desktop and provide them here. My theory is that there is no active infection or backdoor. And that sometime in the past, you had malicious PowerShell commands executed on your system, and these were logged to a Windows Event log. Gathering the above logs will help me to verify this and to form a plan to stop ESET from detecting these old event logs.

From looking at the logs provided, you only had detections by an On Demand Scan which successfully cleaned 54 WMI persistent threats. There are no other threats detected by any other part of ESET. From what I can see in the provided logs, your server appears clean. Also of note, ESET Log Collector shows it gathered registry information, but the registry folder is not contained in the provided zip file. This prevents us from performing any checking of the registry. By chance, did you delete this from the zip file prior to sharing here? Can you please elaborate on the symptoms you are seeing after a reboot?