j91321

It's not possible to automatically resolve them. MarkAsResolved works on detections. You can however prevent that event from triggering the detections in the first place. You can create an advanced exclusion with definition like this one: <definition> <operations> <operation type="CodeInjection"> <operator type="AND"> <condition component="CodeInjectionInfo" condition="is" property="CodeInjectionType" value="ApcQueue"/> <condition component="FileItem" condition="starts" property="Path" value="%PROGRAMFILES%\wsl\"/> <condition component="FileItem" condition="is" property="FileName" value="msrdc.exe"/> </operator> </operation> </operations> </definition> and apply it to the rules it triggers, most likely: Injection into trusted process [F0414b] Injection from an unpopular process [F0415] Similar exclusion already exists named: WSL2 Microsoft Remote Desktop Connection - [F0414b][F0415] although this one works for WSL installed from Windows Store. That may be a reason why it's triggering for you.

Normally there should be only one such folder in the profile. Is this by any chance a roaming profile?

It's not very clear what exactly are you asking about, an example with a screenshot would help us to better understand your problem. Based on this I think you want to keep the detection, but automatically resolve it? If that's the case, MarkAsResolved action may be the thing you are looking for. Check the rule Common Misconfigurations or Recurring Detections [X9803] as an example on how to use the MarkAsResolved action.

Some detections are tied to this "system" process, which is not real process, it's more of a placeholder for anything that originates in the kernel. These are just warning severity alerts and are prone to being on the nosier side. Unless you can see any value in the detection I suggest to also exclude it. It's a common mistake to be overly careful when creating exclusions. Alert fatigue from spammy detections is a bigger security risk than any coverage gaps you're likely to introduce with this specific exclusion.

You could use loki to ingest syslogs from ESET Protect which will also sends messages about Inspect detections. However I've not tried this setup myself.

It would be helpful if you could provide exact example of such detection. In the detection details you should see to which process is your detection attached to. Let's say the process is nmap.exe that we want to exclude: Click the Create Exclusion button and you can go through the wizard: This prevent nmap.exe from specific location to trigger this detection. You can use "Targets" to apply this only on certain computers or groups. If you'd like to also add specific IP address there (in case the triggering event is always the same) you'd need to use "Advanced Editor" on the same screen and write something like this: <definition> <process> <operator type="AND"> <condition component="Module" property="SignatureType" condition="greaterOrEqual" value="90"/> <condition component="FileItem" property="FileName" condition="is" value="nmap.exe"/> <condition component="FileItem" property="Path" condition="starts" value="%PROGRAMFILES(X86)%\nmap\"/> <condition component="Module" property="SignerName" condition="is" value="Insecure.Com LLC"/> </operator> </process> <operations> <operation type="TcpIpProtocolIdentified"> <condition component="Network" property="DestinationIpAddressV4" condition="is" value="192.168.1.122" /> </operation> </operations> </definition> It's the same logic as on the wizard screen I've just added specific IP address to be excluded.

The problem with the "AnyDesk Remote Desktop Silent Installation [D0443]" rule being broken is something called "Safety net". Before rule action such as KillProcess is executed several properties such as Signature Type is checked. If the executable has Signature Type "Trusted" the action is not taken. This is in theory to prevent accidental system instability by killing some system process. This applies only to automated actions, and not the Kill Process button in the Console. Unfortunately it has side-effect with dual use tools such as AnyDesk, which sometimes can have signature type set to Trusted and it prevents their killing. You can specify names that bypass this safety net feature in the C:\Program Files\ESET\INSPECT Connector\eiconnector.ini and add anydesk.exe to the ReputationExceptions= key. More granular controls are being worked on and also to be configurable from the console, to remediate this problem. Additionally if you feel adventurous enough you could create a custom HIPS rule (Advanced Setup->HIPS->Rules) like this. Granted it'll work only with the default paths of AnyDesk installations, but that's often enough to stop unsophisticated adversary that is just following a playbook.

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.

With ESET Inspect Cloud you mainly see Raw Events that are attached to triggered detection. Su unless this HttpRequest or TcpIpProtocolIdentified event triggered some detection rule you won't see it in EIC. You would need On-Prem version which stores all raw events.

I think you are a bit confused by the Event being ProcessCreated %WINDIR\ltsvc\ltsvc.exe%. If I understand it right the B1004 is connected to the bcedit.exe process. The process tree should look something like this: wininit.exe |-------> services.exe |-------> %WINDIR%\ltsvc\ltsvc.exe |-------> %SYSTEM%\bcdedit.exe +-------> Setting a dangerous boot configuration [B1004] What your exclusion is trying to do is exclude behavior when bcedit.exe would spawn ltsvc.exe, but it's the other way around, ltsvc.exe spawns bcedit.exe. You need to use parentprocess like this: <definition> <parentprocess> <operator type="AND"> <condition component="Module" condition="is" property="OriginalFileName" value="LTSVC.exe"/> <condition component="Module" condition="is" property="SignerName" value="Connectwise, LLC"/> <condition component="FileItem" condition="starts" property="FullPath" value="%WINDIR%\ltsvc\"/> </operator> </parentprocess> </definition>

I'd recommend to enable rules with tag Essential. Next it's worth reviewing rules that have automatic actions assigned. You can filter these by using the "Rule Actions" filter in the Rules list. You can also use other tags to better filter categories you're interested in and enabled rules based on that.