[Local Admin Additions]

Well I'd probably need the dump of Raw Events from the machine when you were testing it to investigate this further (ProcMon trace could also be helpful) and also logs from the EI Agent (C:\ProgramData\ESET\INSPECT Connector\Logs).

This event is generated through ETW channel and should be the same as the log you can see in the Windows Event Log (4735 I think). I would also try reinstalling the connector just to be sure, and also the usual stuff, make sure the connector is on the latest version and that the operating system version is supported.

[Local Admin Additions]

Adding user through mmc.exe to local administrator group doesn't have effect on the F1000 functionality. It generates the same detection as any other method.

You do not see that it was done through mmc.exe because the User events are always tied to lsass.exe process.

[EDR Offline Mz Zone]

You also loose the regular EDR rule updates which are delivered to the server through the same mechanism as AV updates are. A new EDR rule module is usually released weekly. Without any internet connection you will receive updates only when upgrading the server with a new release (which can be several months apart).

 

When working within air-gapped networks, your best option is to invest resources into creating custom rules that fit your needs. Which of course is a lot of additional effort, but these are an unfortunate realities when working within such environments.

[EEI and DNS]

On 5/10/2024 at 2:51 AM, Marcos said:

EEI should use the primary and secondary DNS server configured in the system as far as I know.

While this is true for the server side features, this specific "Search Engine Integration" feature happens entirely in the users browser. The settings are just string templates that then get the hash appended to them and open a new tab when user clicks them.

[Exclusions Criteria Trigger Event]

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.

[ESET Inspect Canary Files, move to other folder ?]

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

[Exclusions Criteria Trigger Event]

It's not very clear what exactly are you asking about, an example with a screenshot would help us to better understand your problem.

On 3/26/2024 at 1:14 PM, tgr said:

So I want this detection to be seen as solved when the detection is triggered by a certain event.

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.

[Creating an exclusion for a vulnerability scanner detections]

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.

[ESET Inspect integration with Grafana]

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.

[Creating an exclusion for a vulnerability scanner detections]

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.

[Blocking Specific Programs]

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.

   

 

 

[Low reputation LiveGrid file - rule.]

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.

[Search URL or IP]

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.

[Advanced exclusion - please help]

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>

 

[ESET INSPECT Best practice guide?]

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.