Chelopher

Thanks @JPritchard we'll give it a try and see how it goes...

Hi there, We're running on a requirement to encrypt a Surface Laptop 3 with ESET Endpoint Encryption v5.0.1. We are not very familiar with these Surface models and reading article https://support.eset.com/en/kb7132-use-eset-endpoint-encryption-with-microsoft-surface-devices#pro4andlater it seems the models supported are Surface Pro 4 (and later), Surface Go and Surface Book so my here’s my question, Is the Surface Laptop 3 model supported? that particular one seems to be different from Pro, Go and Book models as you can see in the following links: https://www.microsoft.com/en-us/surface https://www.microsoft.com/en-us/p/surface-laptop-3/8vfggh1r94tm?activetab=overview I opened a case to Latin America support and they stated that even when installation of EEE in this model is possible, it is not recommended specially if it is not an INTEL processor, this particular machine has an AMD64 Family 23 Stepping 1 AuthenticAMD ~2100 Mhz. I just want to hear thoughts from you and see if somebody else has faced a similar requirement before. Thanks in advance.

Hi Marcos, I was wondering the same, how did you relate hash 0eac99e0dd18eeba2b4609955086a1dc8fb913431b4303e76bc793bd62244b20 to this Adrozek MS detection?

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!

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

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,