JamesR

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>