Jump to content

Unable to set up actions for a rules (ESET Inspector)


Recommended Posts

Hi there,

I'm trying  to understand how the <action> </action> feature works . According to the official rule manual implementation you can use several actions that will be triggered along with your rule:

"actions—allow to block an executable immediately after rule triggering. Action names are:
· TriggerDetection—if no actions specified in the actions tag field, this action is executed by default, and the
detection is triggered in EEI. If other actions are specified, and the user still wants to trigger detection, this action
has to be added
· MarkAsScript—marks an executable as script
· HideCommandLine—removes command line string from a process
· BlockProcessExecutable—blocks a process hash (ban hash via the rule)
· CleanAndBlockProcessExecutable—cleans and blocks a process hash
· BlockParentProcessExecutable—blocks a parent process hash
· CleanAndBlockParentProcessExecutable—cleans and blocks a parent process hash
· DropEvent—drops an event which triggered the rule"

This was extracted from from PDF ESET ENTERPRISE INSPECTOR RULES guide that comes with the INSPECTOR, however browsing for more information on a web I found this statement:

"A rule is defined using XML-based language. Rules are matched on the server asynchronously, so there is some time interval when recent events are sent from client to server and then processed by rules. Therefore, a rule cannot block execution of a process or operation (rules are intended for ex-post detection of any suspicious/malicious activity, not for their prevention). A matched rule can only notify security engineers by raising the detection."

This was taken from https://help.eset.com/eei/1.4/en-US/rule_edit.html?rules.html

So I'm kinda confused. I have tried to implement actions of my rules using these patterns:


<action name="BlockProcessExecutable" />

AND

<actions>
            <action name="TriggerDetection" />
            <action name="DropEvent" />
            <action name="BlockProcessExecutable" />
 </actions>

 

No matter where I place these lines my rules generate detections but the actions are not working.  Is this feature already implemented or am I misunderstanding its usage?

 

Thanks in advance,

 

 

PDF Manual.JPG

ESET web Site.JPG

Link to comment
Share on other sites

  • ESET Staff

Hello Chelopher,

thank you for notifying us about discrepancy between help site info and rules guide info. Correct information is in rules guide, misinformation on help site should be fixed shortly.

As for actions, I did not find any problems. I've tested "BlockProcessExecutable" action and did not have any problems as you can see in attached screenshot. I've used following rule:

<?xml version="1.0" encoding="utf-8"?>
<rule>
    <definition>
        <process>
            <condition component="FileItem" property="FileName" condition="contains" value="blockmeplease" />
        </process>
    </definition>
    <description>
        <name>Blocked process - blockmeplease [TEST]</name>
        <category>Default</category>
    </description>
    <actions>
        <action name="BlockProcessExecutable" />
    </actions>
</rule>

I can think of two things why it did not work for you:

  1. There is certain time period during which the changes from server propagates to endpoints. Therefore the rule for blocking process executable can trigger only after this period
  2. Certain executables cannot be blocked by design - this applies mostly to system components such as lsass.exe or svchost.exe. In this case there would be info in server log:
    %timestamp% Info: Rule block hash: process "%processname%" is TRUSTED - will not block. Blocking rule: "%rulename%"

     

block_action.png

Link to comment
Share on other sites

Rule1.thumb.JPG.cff27b0d7a067821596b35a056ab4abd.JPGRule1.thumb.JPG.cff27b0d7a067821596b35a056ab4abd.JPGHi Miroslav,

Thanks for your quick response, really appreciate it. 

This is what we've been trying to do: The following rule is meant to detect when the psexec.exe (which is part of the PSTools ) is fired up in a particular machine:

 

<?xml version="1.0" encoding="utf-8"?>
<rule>
    <description>
        <os>Windows</os>
        <category>SOC-Customized</category>
        <explanation>This rule is triggered psexec is started.
                      
       </explanation>
        <name>Not CISD authorized Pstools version execution detected</name>
        <severity>50</severity>
    </description>
    <definition>
        <process>
            <operator type="and">
                <condition component="FileItem" property="FileName" condition="ends" value="psexec.exe" />
                <condition component="Enterprise" property="ComputerName" condition="is" value="XXXXXXXXXX" />
            </operator>
        </process>
        <operations>
            <operation type="WriteFile">
                <condition component="FileItem" property="Path" condition="starts" value="%RemoteDrive%" />
            </operation>
            <operation type="RegSetValue">
                <condition component="RegistryItem" property="Key" condition="ends" value="HKCU\software\sysinternals\psexec" />
            </operation>
        </operations>
    </definition>
    <actions>
        <action name="TriggerDetection" />
        <action name="BlockProcessExecutable" />
    </actions>

</rule>

As you may know psexec is used to establish connections via command prompt to a remote computer, so we'd like to test if the Inspector is able to block the psexec once it is fired up in this local machine.

The rule logic is working as expected (see the screenshots attached), however, even when it creates a detection, it seems the action block is not doing anything as the connection with the remote computer remains untouched and psexec keeps running on the local computer. I understand there's a delay cause the machine has to send the logs to the server but isn't supposed the psexec.exe to be blocked once the detection takes place?

 

Thanks in advanced.

 

 

rule2.PNG

Edited by Chelopher
Misspelled
Link to comment
Share on other sites

The only way to unconditionally block all local PsExec execution is by setting a debugger reg. key as noted in this article: https://gallery.technet.microsoft.com/Block-PsExec-Execution-4a86c023

Additionally, when PsExec is run remotely by an attacker, it drops PsExecSvc.exe on the target device, creates a service for it, and starts it via svchost.exe. Again, this is mitigated via a reg. debugger entry:

Quote

How do we stop it? I reckon that the easiest way is to use good old Image File Execution Options (IFEO) mechanism again but this time we create the key “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\PSEXESVC.exe” and in there create the REG_SZ value called “Debugger” and set it to “svchost.exe”.

https://guyrleech.wordpress.com/2017/06/28/petya-disabling-remote-execution-of-psexec/

Finally PsExec can be renamed which would defeat the debugger mitigation.

Eset needs to flag PsExec, PsExecSvc, etc. by hash as a PUA's and throw an alert at attempted file creation time.

Edited by itman
Link to comment
Share on other sites

Good evening @itman,

 

Thanks for sharing  that information. The reason why we want to use the ESET Inspector is because more than just blocking psexec,  we want our support teams to use only a customized version we have of this tool. Having said that, we´re planing to have a rule that will compare the hashes and triggers a detection if the psexec used is other than the one we have whitelisted. 

Thinking beyond this particular pstools requirement, I'd like to understand how the pure <actions> feature works since we have in mind to take adavantage of it in our environment.   

Once again, thank you very much!

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...