Jump to content

Chelopher

Members
  • Posts

    10
  • Joined

  • Last visited

Everything posted by Chelopher

  1. Hi Kstainton, This is what they provided to us: [Ticket#1139121] - Sesión Rescue ID: 967123251. We saw the steps you mentioned on a Forum however, this particular model does not have that option so we will experiment setting the recovery to EFI USB and let you know.
  2. Hi Kstainton, We contacted them since last week. Here's the log you requested: 14/10/2022-15:53:50 : Please select process to perform: 14/10/2022-15:53:58 : 1 14/10/2022-15:53:58 : Error flag set. (A00) 14/10/2022-15:53:58 : 14/10/2022-15:53:58 : Master Disk is missing data. 14/10/2022-15:53:58 : 14/10/2022-15:53:59 : System Data block 14/10/2022-15:53:59 : 14/10/2022-15:53:59 : 14/10/2022-15:53:59 : Decryption process can not begin. 14/10/2022-15:53:59 : ************** 14/10/2022-15:53:59 : ERROR 14/10/2022-15:53:59 : ************** 14/10/2022-15:53:59 : 14/10/2022-15:53:59 : Please contact support, providing the information above (0x8) 14/10/2022-15:53:59 : ************** 14/10/2022-15:54:02 : 14/10/2022-15:54:02 : -------------------------------------------------- That is happening with all of them.
  3. Hi Team, We're experiencing a very strange problem with some of our laptops that are installed with FDE. I should start by saying that these computers are brand new and they're being encrypted with FDE for the first time. The instalaltion and encryption process happens smoothly, as per AIS logs info a workstation ID is assigned correctly to the computer (that assigned workstation Id matches with the one listed for the computer in question on ESET Protect Console) and final user is able to setup his/her password. During boot up, owners are shown with FDE credentials black screen so they enter their password and everything works as expected at that point. Problems start to come up 48 hours later of the initial FDE setup, all of a sudden, owners report that their FDE password is not alonger ccepted and when we try to do a recovery via Console we realize that the worksation ID listed at the bottom of the FDE credential screen does not match with the one listed in the console for that computer. If we search on console using the new Workstation ID (the one listed on the client's FDE black screen) no computer associated to it can be found. The discrepancy between workstation ID invalids all the recovery options available forcing the O.S to be wiped out. We've faced this problem around 5 times particularly with HP laptop model Laptop 15-dw3xxx, any ideas about what could be causing this? Thanks in advanced.
  4. I used to be able to test the LiveGuard functionality former known as Dynamic Threat Defense using the file "EdtdTestFile.exe " available on https://help.eset.com/elga/en-US/test_functionality.html, I did several test two weeks ago cause I needed to setup an exclusion for a developers team. In all those test, the file was sent, analized and then removed since it was cataloged as malicious. Now I've been requested to create another exclusion and it turns out that no matter its location, the EdtdTestFile is being ignored by Liveguard despite the fact that I'm chaging its hash using the Add-Content command as the instructions state. Did something change?
  5. 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.
  6. Hi Marcos, I was wondering the same, how did you relate hash 0eac99e0dd18eeba2b4609955086a1dc8fb913431b4303e76bc793bd62244b20 to this Adrozek MS detection?
  7. 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!
  8. 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.
  9. 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,
×
×
  • Create New...