JamesR

Okay, so after 1:25h it finally finished. So if anyone else has this occurrence. Get some tea and wait patiently. 🙂

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>  

The easiest way how to safely test executable being low popularity is to just take some known executable e.g. notepad.exe and append a random byte at the end of the file with hex editor. It should still remain a valid PE and usually have 0 popularity and low reputation.

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

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

"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>  

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.

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:   

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>  

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

@3D Joe Ng
While hardening your SQL Server is a very good idea, there is a good chance that persistence was already added to the SQL server and that detections by ESET will continue until the persistence is removed.  In my last DM to you, I provided a simple way to log SQL persistence.
Where you able to run the final batch file I provided?  If yes, can you please supply the zip file generated?
There are many types of SQL Persistence, and if your MS SQL is hosting more than one instance, each instance will need to be checked.  There are the following types of MS SQL persistence:
Stored Procedures At start of MS SQL service, a procedure will start and execute ever certain amount of seconds/minutes/hours A stored procedure can be "encrypted" to hide its definition from being easily seen More info on Stored Procedures here: https://blog.netspi.com/sql-server-persistence-part-1-startup-stored-procedures/ Triggers DDL Triggers - Data Definition Language Triggers Server based triggers which can be set to execute when specific queries like CREATE, ALTER, or DROP are used These triggers can be "encrypted" to hide the definition from being easily seen DML Triggers - Data Manipulation Language Triggers Database based triggers which can be set to execute on specific queries like INSERT, UPDATE, or DELETE Untested if these can be "encrypted" but it should be assumed that they can be encrypted as well Logon Triggers As their name implies, these are triggers which execute queries whenever a user logs in to MS SQL. And can theoretically, prevent a user from logging in. Untested if these can be "encrypted" but it should be assumed that they can be encrypted as well More info on Triggers here: https://blog.netspi.com/maintaining-persistence-via-sql-server-part-2-triggers/ Other notes In order to allow MS SQL to execute external applications, the use of advanced options is needed.  You will want to check and disable these settings (Ensure you make not of what you changed, and monitor your SQL server for any issues afterwards.  Your SQL server may have legitimately been using these settings) "show advanced options" - Allows the following settings to be used "xp_cmdshell" - Allows MS SQL to directly execute external applications like Ping.exe or any other executables on disk. "Ole Automation Procedures" - Allows MS SQL to execute Windows Script Host and VBScript macros, which allows wscript.shell to execute other executables on the computer's disk, without the use of xp_cmdshell. "clr enabled" - Allow you to store .net code inside of SQL which can be executed by a stored procedure. This is one of the more powerful ways of providing code execution to SQL. But these should easily be spotted when reviewing all stored procedures on a server.

I do not recommend simply changing the port any service uses.  It is to simple to run a port scan on all ports to identify the service which is running on them and does not stop an attack on any service which is exposed to the internet.
It would be better to close easily brute forced ports/services off from any inbound public IPs.  If you do need to have the port open to the internet, it should be restricted only to allow specific public IP addresses, otherwise, you will end up having password guessing attacks occur.  This holds true for SQL, RDP, SMB, SSH, and many many other services.
If you change the default port, and expose it to the internet, you have opened the door to being attacked.

FTL,
Thanks for the additional info.  Its starting to sound like your server may be hosting Remote Desktop Services with Remote Desktop Gateway.  Which will have ntoskrnl.exe listening on port 443 for RDP requests to forward to other servers.  While this might be intended, the trigger event info you shared shows an IP from Russia attempting the connection (I used this site to look up the location of the IP address: https://www.maxmind.com/en/geoip-demo).
I highly recommend reviewing the roles installed on the server to verify if "Remote Desktop Services" (previously called Terminal Services) is one of the installed roles.
These detections could very well be a sign of an RDP Brute Force attack from undesired IP addresses.  If this server is an RDP Gateway, and 443 needs to be open to the internet, I would recommend restricting which blocks of IPs you allow to connect.  Geo-IP Blocking could help reduce connections from attackers, but any compromised device in your country, could continue an attack.  And ensure you are using 2fa on any RDP logins (especially Admin logins).
With that said, there is still a chance its not Remote Desktop Services with an RDP Gateway.  That is just what I would expect at this point.
If you have a list of IP Addresses which are allowed to connect, that you want to exclude from triggering this detection, you can use the following exclusion as a template to modify and meet your needs.  Then you will only get detections on untrusted IP addresses:
<definition> <process> <!-- Describe process to apply exclusion too --> <operator type="and"> <!-- SignatureType of 90 = Trusted --> <condition component="Module" property="SignatureType" condition="greaterOrEqual" value="90"/> <condition component="FileItem" property="FullPath" condition="is" value="%SYSTEM%\ntoskrnl.exe" /> <condition component="ProcessInfo" property="ProcessOwner" condition="is" value="nt authority\system"/> </operator> </process> <operations> <operation type="TcpIpProtocolIdentified"> <!-- List of IP Addresses to exclude from triggering detection. Accepts CIDR notation. --> <operator type="or"> <condition component="Network" property="IpAddressV4" condition="is" value="172.16.0.0/12" /> <condition component="Network" property="IpAddressV4" condition="is" value="192.168.5.123" /> </operator> </operation> </operations> </definition>  
Side note: RDP can be brute forced, and its not uncommon for someone to have setup a secondary admin account, with a weaker password and no 2FA, to use incase their primary account is not working (disabled due to bad passwords, or 2FA isnt functioning as expected).  It is not uncommon that a ransomware attack starts with a form of brute force on exposed services (RDP, SMB, vCenter/ESXi web console, etc...).  Also, if some form of Remote Code Execution is discovered, or only known to attackers, it could allow them to walk right in without authentication (In 2017 WannaCry used an RCE on SMB to spread without needing any credentials).

@j-gray I've pinged some people internally to get the communication on that case moving.

@j-gray I've pinged some people internally to get the communication on that case moving.

@itman
They were not drivers.  They were text files containing PowerShell scripting and saved as .sys files.  Just a simple technique to try and hide on a system.  I always advise against relying on a file name and/or file path to decide what a file contains or is.
In this case, the malware is reading the contents of the .sys files, and converting them to UTF8 to get PowerShell code to execute.  Here is a snip it of the command being executed to read from the file, prior to executing the contents.

@itman
They were not drivers.  They were text files containing PowerShell scripting and saved as .sys files.  Just a simple technique to try and hide on a system.  I always advise against relying on a file name and/or file path to decide what a file contains or is.
In this case, the malware is reading the contents of the .sys files, and converting them to UTF8 to get PowerShell code to execute.  Here is a snip it of the command being executed to read from the file, prior to executing the contents.

For those managing multiple computers via ESET Protect, and would like a more streamline way of removing this software from all computers, this can be done for the installed software, but not for the browser plugins.  Browser plugins are managed by the individual browsers, and not directly by the OS.
 
These steps are not working 100% for the Bing Software mentioned in this thread.  If I can improve upon this, I will post later.
 
Here are the steps to use ESET Protect to uninstall 3rd party software which can be seen by ESET:
This will guide you through the following:
Ensure ESET Protect can see installed non-ESET Applications Create a dynamic group to group all computers with unwanted applications Create tasks that will run... ...anytime a computer has the undesired software installed and shows up in the dynamic group (thus uninstalling the unwanted software anytime a new computer joins this group) ...one time run of the tasks on computers that already joined the group while you created the tasks (to uninstall the unwanted software from computers that had already joined this group)  
I. Setup ESET Management Agent to report non-ESET Applications (only needed if not already configured)
In ESET Protect, navigate to "Policies > New Policy" Name the policy "Report Non-ESET Applications" In "Settings" ensure you select "ESET Management Agent" from the drop-down at the top Expand "Advanced Settings" and locate and turn on "Report non-ESET-installed applications" Assign to either the "All" group, or to specific groups/computers of desire. Continue and finish creating the policy At this point, it may take a bit for the non-ESET software to be reported to ESET Protect.  Your endpoints will need to check in once to get the policy, then check in again to supply the new info, then ESET Protect will need to parse and put the info into the database.  Default check in times are 10 minutes.  So you should start seeing the non-ESET applications in about 30 minutes in the following area:
II. Check to see if ESET Protect sees the 3rd party applications:
In ESET Protect, open the details of an individual computer, then click on "Installed Applications" If you can see Non-ESET applications, your settings are applied and working. You can also check to see if you see your undesired software is visible and has a "Yes" in the column "Agent supports uninstall" which means ESET can attempt to uninstall this software III. Create a dynamic group to group all computers with undesired software (this will help you see how many computers you have with the unwanted software, and allow for a quick way to uninstall the software)
In ESET Protect, click on Computers on the left, locate "Windows Computers" in the list of Groups. Click on the gear to the right of this, and select "New Dynamic Group" Name the group "Has Unwanted Software" in the "Template" section, choose "New" and set the following: Name: Unwanted Software Expression: Operation: AND (All conditions have to be true) Click Add Rule and choose: "Installed Software > Application Name", and click OK Click Add Rule and choose: "Installed Software > Application Vendor", and click OK For Application Name, set to "is one of" and fill in the name "Microsoft Bing Service" In the Application Name section, click "Add" and then fill in the name "Bing Wallpaper" For Application Vendor, set to "is one of" , and fill in "Microsoft Corporation" Should look like this: Click Finish Over a short time, you will see computers start to appear here.  Next we will make a task to remove the undesired software. IV. Create a task to start uninstalling unwanted software
In ESET Protect, click on Computers on the left, then locate your newly made dynamic group named "Has Unwanted Software" Click the gear next to the group name and click "Tasks > New Task..." Name the task "Uninstall unwanted software - Microsoft Bing Service" and in the "Task" drop down, select "Software Uninstall" and click "Continue" In this Settings section, click on "<Select package to uninstall>" and select the first piece of software to uninstall "Microsoft Bing Service" You may desire to click on "Uninstall all versions of package" to ensure any version gets removed. Click "Continue" to get to the targets and ensure your desired target group "Has Unwanted Software" is showing in the list and then click "Continue" In the "Trigger section" set the trigger type to "Joined Dynamic Group Trigger" (this will run this task on any computer as it gets added to our dynamic group, but not on computers already in this group.  We will remedy this shortly.) Continue and finish. On your group "Has Unwanted Software" click the gear and choose "Tasks > Run Tasks" Click on "Add Tasks" and find and checkmark your "Uninstall unwanted software - Microsoft Bing Service" and click OK For the "Trigger" section, ensure trigger type is "As Soon As Possible" and click finish. Repeat steps 1 through 11 but: in step 4 select "Bing Wallpaper" in step 3 and 10 use the task name "Uninstall unwanted software - Bing Wallpaper"

Well.... I just found the issue. The upgrade process populates the EI admin logon and password. It just so happens that it was populating the admin account in a case-sensitive manner, as the account exists in the EP console (e.g. CAPAdmin).
When I used the login id capitalized as it exists in EP console, the user is blocked. When I enter the login id in all lower case, the upgrade was able to complete.
I confirmed the same logging into the EI console; account as configured in EP is CAPAdmin. Log into EI console with CAPAdmin = user is blocked. Log into EP console as capadmin = successful login.

For those managing multiple computers via ESET Protect, and would like a more streamline way of removing this software from all computers, this can be done for the installed software, but not for the browser plugins.  Browser plugins are managed by the individual browsers, and not directly by the OS.
 
These steps are not working 100% for the Bing Software mentioned in this thread.  If I can improve upon this, I will post later.
 
Here are the steps to use ESET Protect to uninstall 3rd party software which can be seen by ESET:
This will guide you through the following:
Ensure ESET Protect can see installed non-ESET Applications Create a dynamic group to group all computers with unwanted applications Create tasks that will run... ...anytime a computer has the undesired software installed and shows up in the dynamic group (thus uninstalling the unwanted software anytime a new computer joins this group) ...one time run of the tasks on computers that already joined the group while you created the tasks (to uninstall the unwanted software from computers that had already joined this group)  
I. Setup ESET Management Agent to report non-ESET Applications (only needed if not already configured)
In ESET Protect, navigate to "Policies > New Policy" Name the policy "Report Non-ESET Applications" In "Settings" ensure you select "ESET Management Agent" from the drop-down at the top Expand "Advanced Settings" and locate and turn on "Report non-ESET-installed applications" Assign to either the "All" group, or to specific groups/computers of desire. Continue and finish creating the policy At this point, it may take a bit for the non-ESET software to be reported to ESET Protect.  Your endpoints will need to check in once to get the policy, then check in again to supply the new info, then ESET Protect will need to parse and put the info into the database.  Default check in times are 10 minutes.  So you should start seeing the non-ESET applications in about 30 minutes in the following area:
II. Check to see if ESET Protect sees the 3rd party applications:
In ESET Protect, open the details of an individual computer, then click on "Installed Applications" If you can see Non-ESET applications, your settings are applied and working. You can also check to see if you see your undesired software is visible and has a "Yes" in the column "Agent supports uninstall" which means ESET can attempt to uninstall this software III. Create a dynamic group to group all computers with undesired software (this will help you see how many computers you have with the unwanted software, and allow for a quick way to uninstall the software)
In ESET Protect, click on Computers on the left, locate "Windows Computers" in the list of Groups. Click on the gear to the right of this, and select "New Dynamic Group" Name the group "Has Unwanted Software" in the "Template" section, choose "New" and set the following: Name: Unwanted Software Expression: Operation: AND (All conditions have to be true) Click Add Rule and choose: "Installed Software > Application Name", and click OK Click Add Rule and choose: "Installed Software > Application Vendor", and click OK For Application Name, set to "is one of" and fill in the name "Microsoft Bing Service" In the Application Name section, click "Add" and then fill in the name "Bing Wallpaper" For Application Vendor, set to "is one of" , and fill in "Microsoft Corporation" Should look like this: Click Finish Over a short time, you will see computers start to appear here.  Next we will make a task to remove the undesired software. IV. Create a task to start uninstalling unwanted software
In ESET Protect, click on Computers on the left, then locate your newly made dynamic group named "Has Unwanted Software" Click the gear next to the group name and click "Tasks > New Task..." Name the task "Uninstall unwanted software - Microsoft Bing Service" and in the "Task" drop down, select "Software Uninstall" and click "Continue" In this Settings section, click on "<Select package to uninstall>" and select the first piece of software to uninstall "Microsoft Bing Service" You may desire to click on "Uninstall all versions of package" to ensure any version gets removed. Click "Continue" to get to the targets and ensure your desired target group "Has Unwanted Software" is showing in the list and then click "Continue" In the "Trigger section" set the trigger type to "Joined Dynamic Group Trigger" (this will run this task on any computer as it gets added to our dynamic group, but not on computers already in this group.  We will remedy this shortly.) Continue and finish. On your group "Has Unwanted Software" click the gear and choose "Tasks > Run Tasks" Click on "Add Tasks" and find and checkmark your "Uninstall unwanted software - Microsoft Bing Service" and click OK For the "Trigger" section, ensure trigger type is "As Soon As Possible" and click finish. Repeat steps 1 through 11 but: in step 4 select "Bing Wallpaper" in step 3 and 10 use the task name "Uninstall unwanted software - Bing Wallpaper"

For those managing multiple computers via ESET Protect, and would like a more streamline way of removing this software from all computers, this can be done for the installed software, but not for the browser plugins.  Browser plugins are managed by the individual browsers, and not directly by the OS.
 
These steps are not working 100% for the Bing Software mentioned in this thread.  If I can improve upon this, I will post later.
 
Here are the steps to use ESET Protect to uninstall 3rd party software which can be seen by ESET:
This will guide you through the following:
Ensure ESET Protect can see installed non-ESET Applications Create a dynamic group to group all computers with unwanted applications Create tasks that will run... ...anytime a computer has the undesired software installed and shows up in the dynamic group (thus uninstalling the unwanted software anytime a new computer joins this group) ...one time run of the tasks on computers that already joined the group while you created the tasks (to uninstall the unwanted software from computers that had already joined this group)  
I. Setup ESET Management Agent to report non-ESET Applications (only needed if not already configured)
In ESET Protect, navigate to "Policies > New Policy" Name the policy "Report Non-ESET Applications" In "Settings" ensure you select "ESET Management Agent" from the drop-down at the top Expand "Advanced Settings" and locate and turn on "Report non-ESET-installed applications" Assign to either the "All" group, or to specific groups/computers of desire. Continue and finish creating the policy At this point, it may take a bit for the non-ESET software to be reported to ESET Protect.  Your endpoints will need to check in once to get the policy, then check in again to supply the new info, then ESET Protect will need to parse and put the info into the database.  Default check in times are 10 minutes.  So you should start seeing the non-ESET applications in about 30 minutes in the following area:
II. Check to see if ESET Protect sees the 3rd party applications:
In ESET Protect, open the details of an individual computer, then click on "Installed Applications" If you can see Non-ESET applications, your settings are applied and working. You can also check to see if you see your undesired software is visible and has a "Yes" in the column "Agent supports uninstall" which means ESET can attempt to uninstall this software III. Create a dynamic group to group all computers with undesired software (this will help you see how many computers you have with the unwanted software, and allow for a quick way to uninstall the software)
In ESET Protect, click on Computers on the left, locate "Windows Computers" in the list of Groups. Click on the gear to the right of this, and select "New Dynamic Group" Name the group "Has Unwanted Software" in the "Template" section, choose "New" and set the following: Name: Unwanted Software Expression: Operation: AND (All conditions have to be true) Click Add Rule and choose: "Installed Software > Application Name", and click OK Click Add Rule and choose: "Installed Software > Application Vendor", and click OK For Application Name, set to "is one of" and fill in the name "Microsoft Bing Service" In the Application Name section, click "Add" and then fill in the name "Bing Wallpaper" For Application Vendor, set to "is one of" , and fill in "Microsoft Corporation" Should look like this: Click Finish Over a short time, you will see computers start to appear here.  Next we will make a task to remove the undesired software. IV. Create a task to start uninstalling unwanted software
In ESET Protect, click on Computers on the left, then locate your newly made dynamic group named "Has Unwanted Software" Click the gear next to the group name and click "Tasks > New Task..." Name the task "Uninstall unwanted software - Microsoft Bing Service" and in the "Task" drop down, select "Software Uninstall" and click "Continue" In this Settings section, click on "<Select package to uninstall>" and select the first piece of software to uninstall "Microsoft Bing Service" You may desire to click on "Uninstall all versions of package" to ensure any version gets removed. Click "Continue" to get to the targets and ensure your desired target group "Has Unwanted Software" is showing in the list and then click "Continue" In the "Trigger section" set the trigger type to "Joined Dynamic Group Trigger" (this will run this task on any computer as it gets added to our dynamic group, but not on computers already in this group.  We will remedy this shortly.) Continue and finish. On your group "Has Unwanted Software" click the gear and choose "Tasks > Run Tasks" Click on "Add Tasks" and find and checkmark your "Uninstall unwanted software - Microsoft Bing Service" and click OK For the "Trigger" section, ensure trigger type is "As Soon As Possible" and click finish. Repeat steps 1 through 11 but: in step 4 select "Bing Wallpaper" in step 3 and 10 use the task name "Uninstall unwanted software - Bing Wallpaper"

For those managing multiple computers via ESET Protect, and would like a more streamline way of removing this software from all computers, this can be done for the installed software, but not for the browser plugins.  Browser plugins are managed by the individual browsers, and not directly by the OS.
 
These steps are not working 100% for the Bing Software mentioned in this thread.  If I can improve upon this, I will post later.
 
Here are the steps to use ESET Protect to uninstall 3rd party software which can be seen by ESET:
This will guide you through the following:
Ensure ESET Protect can see installed non-ESET Applications Create a dynamic group to group all computers with unwanted applications Create tasks that will run... ...anytime a computer has the undesired software installed and shows up in the dynamic group (thus uninstalling the unwanted software anytime a new computer joins this group) ...one time run of the tasks on computers that already joined the group while you created the tasks (to uninstall the unwanted software from computers that had already joined this group)  
I. Setup ESET Management Agent to report non-ESET Applications (only needed if not already configured)
In ESET Protect, navigate to "Policies > New Policy" Name the policy "Report Non-ESET Applications" In "Settings" ensure you select "ESET Management Agent" from the drop-down at the top Expand "Advanced Settings" and locate and turn on "Report non-ESET-installed applications" Assign to either the "All" group, or to specific groups/computers of desire. Continue and finish creating the policy At this point, it may take a bit for the non-ESET software to be reported to ESET Protect.  Your endpoints will need to check in once to get the policy, then check in again to supply the new info, then ESET Protect will need to parse and put the info into the database.  Default check in times are 10 minutes.  So you should start seeing the non-ESET applications in about 30 minutes in the following area:
II. Check to see if ESET Protect sees the 3rd party applications:
In ESET Protect, open the details of an individual computer, then click on "Installed Applications" If you can see Non-ESET applications, your settings are applied and working. You can also check to see if you see your undesired software is visible and has a "Yes" in the column "Agent supports uninstall" which means ESET can attempt to uninstall this software III. Create a dynamic group to group all computers with undesired software (this will help you see how many computers you have with the unwanted software, and allow for a quick way to uninstall the software)
In ESET Protect, click on Computers on the left, locate "Windows Computers" in the list of Groups. Click on the gear to the right of this, and select "New Dynamic Group" Name the group "Has Unwanted Software" in the "Template" section, choose "New" and set the following: Name: Unwanted Software Expression: Operation: AND (All conditions have to be true) Click Add Rule and choose: "Installed Software > Application Name", and click OK Click Add Rule and choose: "Installed Software > Application Vendor", and click OK For Application Name, set to "is one of" and fill in the name "Microsoft Bing Service" In the Application Name section, click "Add" and then fill in the name "Bing Wallpaper" For Application Vendor, set to "is one of" , and fill in "Microsoft Corporation" Should look like this: Click Finish Over a short time, you will see computers start to appear here.  Next we will make a task to remove the undesired software. IV. Create a task to start uninstalling unwanted software
In ESET Protect, click on Computers on the left, then locate your newly made dynamic group named "Has Unwanted Software" Click the gear next to the group name and click "Tasks > New Task..." Name the task "Uninstall unwanted software - Microsoft Bing Service" and in the "Task" drop down, select "Software Uninstall" and click "Continue" In this Settings section, click on "<Select package to uninstall>" and select the first piece of software to uninstall "Microsoft Bing Service" You may desire to click on "Uninstall all versions of package" to ensure any version gets removed. Click "Continue" to get to the targets and ensure your desired target group "Has Unwanted Software" is showing in the list and then click "Continue" In the "Trigger section" set the trigger type to "Joined Dynamic Group Trigger" (this will run this task on any computer as it gets added to our dynamic group, but not on computers already in this group.  We will remedy this shortly.) Continue and finish. On your group "Has Unwanted Software" click the gear and choose "Tasks > Run Tasks" Click on "Add Tasks" and find and checkmark your "Uninstall unwanted software - Microsoft Bing Service" and click OK For the "Trigger" section, ensure trigger type is "As Soon As Possible" and click finish. Repeat steps 1 through 11 but: in step 4 select "Bing Wallpaper" in step 3 and 10 use the task name "Uninstall unwanted software - Bing Wallpaper"

For those looking for assistance in removing this software, here are some steps to remove this from individual computers:
Windows + R type "Appwiz.cpl" and press enter Find and uninstall/remove (at the end of the uninstall, you may be directed to a Microsoft web page asking if you meant to uninstall and asked if you want to reinstall.  Just close this): Microsoft Bing Service Bing Wallpaper After that, start opening each web browser and checking for Bing Homepage/Search extensions/plugins and remove them (the prior uninstall leaves these in place and does not remove them). Chrome: In the address bar, navigate to "chrome://extensions/" and click "remove" to any thing like: "Microsoft Bing Homepage & Search for Chrome" After removal, you may be taken to a web page asking if you want to reinstall the extension.

For those looking for assistance in removing this software, here are some steps to remove this from individual computers:
Windows + R type "Appwiz.cpl" and press enter Find and uninstall/remove (at the end of the uninstall, you may be directed to a Microsoft web page asking if you meant to uninstall and asked if you want to reinstall.  Just close this): Microsoft Bing Service Bing Wallpaper After that, start opening each web browser and checking for Bing Homepage/Search extensions/plugins and remove them (the prior uninstall leaves these in place and does not remove them). Chrome: In the address bar, navigate to "chrome://extensions/" and click "remove" to any thing like: "Microsoft Bing Homepage & Search for Chrome" After removal, you may be taken to a web page asking if you want to reinstall the extension.