Mitchell
Members-
Posts
30 -
Joined
-
Days Won
2
Everything posted by Mitchell
-
This is possible, you just have to add the address and port to the allowed list in config. Pick the address based on the location of your ESET Inspect Cloud Instance eu01.agent.edr.eset.systems or IP 52.166.186.239 TCP/8093 ESET Inspect Cloud Connector Location: Europe us01.agent.edr.eset.systems or IP 40.83.252.19 TCP/8093 ESET Inspect Cloud Connector Location: USA jp01.agent.edr.eset.systems or IP 20.188.24.252 TCP/8093 ESET Inspect Cloud Connector Location: Japan
-
Update ESET Inspect Server
Mitchell replied to tgr's topic in ESET Inspect On-prem (Detection and Response)
You can just download the latest version from the download page, run the installer and it will perform the upgrade for you. (fields such as database credentials and connection settings for ESET PROTECT should already be pre-filled) -
Update ESET Inspect Server
Mitchell replied to tgr's topic in ESET Inspect On-prem (Detection and Response)
You can download the latest version from the download section: https://www.eset.com/int/business/download/inspect/ Keep in mind that depending on your environment and the version you are upgrading from the upgrade might take several hours. Some more information regarding this can be found in the help page: https://help.eset.com/ei_deploy/1.11/en-US/server_upgrade_through_esmc.html -
Hash Blocked by ESET Inspect
Mitchell replied to Mohsen Ghaffari's topic in ESET Inspect On-prem (Detection and Response)
The following buit-in rules have an action that can result in a blocked hash. (i'm not sure which of these are enabled by-default however): <name>Process has started from Recycle Bin folder [A0412]</name> <name>Suspicious executable created in %startup% folder [A0127b]</name> <name>Regsvr32 has dropped a suspicious executable [A0311]</name> <name>Certutil has dropped a suspicious executable [A0313]</name> <name>Process executed from ADS [A0417]</name> <name>Process with mimikatz-like executable metadata executed [A0423]</name> <name>Ransomware-like data written to file [A0603]</name> <name>Multiple file writes from a compromised process [A0606]</name> <name>Multiple file renames from a compromised process [A0607]</name> <name>Remote execution using renamed PsExec service [A0905]</name> <name>Canary File was Triggered [D0334]</name> <name>Suspicious Nvidia Signed module was dropped [E0464]</name> <name>Suspicious Nvidia Signed module was loaded [E0465]</name> <name>Explorer.exe Loading Suspicious .Net Assembly [E0472]</name> <name>Suspicious Compromised Process Loading .Net CLR DLL [E0473]</name> <name>Rundll32 loaded DLL with unusual extension [F0461]</name> <name>Windows Print Spooler loaded suspicious DLL from remote folder [A0441] </name> <name>Suspicious LoLBaS Execution: Control.exe loading DLL from ADS (Alternate Data Streams) [E0437]</name> <name>Suspicious DLL loaded from Alternate Data Stream [E0438]</name> Most likely on of these rules triggered and the hash of the file is now added to the "blocked hashes" list in the Inspect Web Console under "More > Blocked Hashes" -
ESET Inspect learn mode not working
Mitchell replied to WG-Goe's topic in ESET Inspect On-prem (Detection and Response)
The suggested exclusions will appear after the learning mode duration has ended. -
You can create a dynamic group with the following condition: and then create a "dynamic group changes" notification for that: You could also trigger the previously mentioned "run command" task using a joined dynamic group trigger or scheduled trigger on that group to "auto heal" affected systems. (but as previously mentioned, A reboot is probably preferred)
-
I can't reproduce this behavior on my test system, but had a look with Promon, at some point the installer creates the file: C:\Users\username\AppData\Local\Temp\2\ESE9EA6.tmp\ServerApi.dll Could it be that some other process is preventing the installer from either writing this file or loading the dll? Maybe creating a procmon capture during the installation attempt can shed some more light on what's going on. Also msi install log might have some additional clues about why it is failing. (if log file is not created, try running the installer with: msiexec /i ei_server_nt64.msi /lvx*! ei.install.log)
-
You can create a new policy in ESET PROTECT: Select the product ESET Inspect Connector (1) & define the correct hostname/IP of the server where you installed ESET Inspect Server component (2) & select the correct Certificate Authority. Assign the policy to the all group (or a different group if you prefer):
-
Latest upgrade stuck at 92%
Mitchell replied to j-gray's topic in ESET Inspect On-prem (Detection and Response)
By now your upgrade is probably finished, but you could look at show full processlist query for example: https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html -
Latest upgrade stuck at 92%
Mitchell replied to j-gray's topic in ESET Inspect On-prem (Detection and Response)
I believe this step can take a couple of hours in large environments. I would recommend letting the process continue, you could perhaps monitor activity on database side to make sure it is still doing something -
User synchronization task errors
Mitchell replied to j-gray's topic in ESET Inspect On-prem (Detection and Response)
I'm not sure, maybe you can find it if you enable trace level logging and check the ESET PROTECT trace logs after a failed run. I do know that this behavior is identified as bug that will be fixed in a future version. -
User synchronization task errors
Mitchell replied to j-gray's topic in ESET Inspect On-prem (Detection and Response)
The task is used to synchronize users from AD, mainly to show some additional info about the user triggering a detection, specifically the following fields when viewing a detection in INSPECT: (the fields in AD are empty in my case, so that's why the values are 'unkown') A possible work-around is to delete all 'computer users' from ESET PROTECT (if you are not using this functionality) after that sync task should work again, but I have seen the issue come back. If you don't care about the above information in the detection events, I would ignore the failing of the task, as it is not critical functionality. -
Windows Server 2022 compatibility
Mitchell replied to Markwd's topic in ESET Products for Windows Servers
I noticed the help page now lists "Microsoft Windows server 2022" as Supported OS: https://help.eset.com/efsw/8.0/en-US/system_requirements.html -
ESET API - List computers
Mitchell replied to Eric Schultz's topic in ESET PROTECT On-prem (Remote Management)
@Ievgen ParkhomenkoYou can find some example code at: https://help.eset.com/protect_install/81/api_examples/index.html?index.html -
ESET API - List computers
Mitchell replied to Eric Schultz's topic in ESET PROTECT On-prem (Remote Management)
This should give you: staticgroup_name,computer_name,computer_uuid: { "Era.Common.NetworkMessage.ConsoleApi.Reports.RpcGenerateReportRequest": { "reportTemplate": { "data": { "query_usage_definition_id": 21, "used_symbol": [ { "column_id": 673, "symbol_id": 673, "aggregation_parameter": {} }, { "column_id": 657, "symbol_id": 657, "aggregation_parameter": {} }, { "column_id": 644, "symbol_id": 644, "aggregation_parameter": {} } ] }, "rendering": { "draw_chart": False, "draw_table": True, "table": { "type_id": 100, "columns": [ { "column_id": 673, "order": 0, "width": 1, "label": {"type": 1, "literal": "staticgroup_name"} }, { "column_id": 644, "order": 0, "width": 1, "label": { "type": 1, "literal": "computer_name" } }, { "column_id": 657, "order": 0, "width": 1, "label": {"type": 1, "literal": "computer_uuid"} } ] } } } } } Example output: { 'Era.ServerApi.ReportCSVResponse': { 'reportCSV': 'staticgroup_name,computer_name,computer_uuid Lost & found,desktop-vhqqkoh,3752aa8e-2675-471c-9e61-474f2fbd7eea Lost & found,exchange.lab.local,178a0124-b66d-426b-8097-fb3261146eed Lost & found,azca.lab.local,c6ef236f-6db7-4873-9e0a-14487ac9c10b Domain Controllers,azdc01.lab.local,e6f28980-eae2-49d9-85f7-db30b7042931 Desktops,azwin10-02.lab.local,8737171e-408a-4b82-a006-a31a3c51c368 Servers,eei663777.lab.local,cd3814d2-ec00-4a43-8da2-652df3491c6f Servers,localhost,4b61b044-1f82-454d-9806-b54dfa838a14 Klant A,henks-mac.local,1397d5b6-ed44-4a40-ba8d-3b78a4a692b2 Klant A,iPhone,00029835-70ca-4b37-a7bc-86849556c23e Klant A,Android,0002c0b5-0a49-41ab-a4c0-5c2d01be2d1a Klant A,henks-mac.local,2b16e91c-1497-4e6f-8c01-21f6a2c52f5a' } } -
I haven't been able to reproduce the issue on the latest version of ESET Endpoint for mac OS (6.9.60), So upgrading seems to be the easiest fix. Edit: I'm not sure if there is a newer version of ESET Cyber Security though.
-
Seems that creating the following rule is sufficient: Name: Allow Teams Helper App: /Applications/Microsoft Teams.app/Contents/Frameworks/Microsoft Teams Helper.app Action: Allow Direction: In Protocol: TCP & UDP Ports: Remote Remote Port: All Destination: Entire internet