Jump to content

PuterCare

Members
  • Posts

    107
  • Joined

  • Last visited

Posts posted by PuterCare

  1. 2 hours ago, Marcos said:

    Yes, the latest installers are compatible with macOS Ventura. However, you will probably need to remove ESET applications and Installer from the Full disk access list and let them to be added automatically followed by a reboot as per https://support.eset.com/en/kb8339. On slower machines you may need to click slower if the above doesn't seem to work.

    The issue was already reported to Apple and we're waiting for a response.

    I have a user who has the latest version of Protect agent and EES installed, they upgraded to Ventura. I followed the steps in the guide but it doesn't help, I uninstalled and reinstalled but I have the same issue.

    Installer is not listed in full disk access, ESET Device Control is. I have tried removing that too but still it doesn't work. Any other ideas or is it just not working at the moment? Thanks

  2. I just had a weird issue so thought I would post in case this helps anyone else. I am onboarding macOS devices using Intune, part of my onboarding process installs Rosetta and then the Eset agent, Eset Protect then takes over and auto-installs EES and activates.

    All works nice and smooth but Friday I had a call to say a Mac that was onboarded that week (running Monterey) has no internet access. I did some troubleshooting and saw that on the network prefs screen the Eset firewall was stuck starting and the Eset proxy was not connected. Eset was not running on the menu bar.

    I went through the steps to uninstall Eset but it said that Rosetta was not installed and a button to install it, clicked that but it failed as there is no internet. 

    I fixed by manually removing Eset firewall and proxy from network prefs which allowed me to run the uninstaller, install Rosetta, uninstall Eset and I then pushed a fresh install from Protect which is working. 

    I hope this was an obscure glitch rather than anything that's going to cause issues going forward. It looks like somehow Rosetta was damaged or removed after Eset was installed. I don't have logs as I had to get the user up and running asap.

    Seems related to this: 

     

  3. Hi, I am trying to migrate my ESET PROTECT server from VMWare to Hyper-V on another host. I have set up the Hyper-V appliance and the server version is 9.0.2144.0 but on my VMWare appliance the server version is 9.0.2141.0. I have gone into the update task and 9.0.2141.0 is the latest version showing in the repo. 

    The migration guide says the source and destination must be on the same version, does anyone know how I can upgrade my VMware appliance so the server version matches? 

    Thanks

  4. 8 hours ago, TKirste said:

    Apparently an "update of Proxy-settings" solved this issue. I would have appreciated an communication about this solution since after all the trouble last week I was reluctant to allow any changes of anything. But glad the issue seems to be solved now. Thanks

     

    Is this something you needed to do on the endpoint or something Eset have fixed? Thanks

  5. I've had issues reported a few times over the past 6 months and on each occasion removing Eset Endpoint Security fixed. One of my clients got a new M1 Macbook last week on macOS 12.0.1, I connected, installed the Eset agent (had to install Rosetta 2 first) and pushed EES 6.11.1. Everything seemed ok but shortly after the client installed the macOS 12.1 update and since then they lost internet unless they entered recovery mode. 

    We tried going into network settings and adding a new internet connection but this did not help, we removed EES and the internet came back. 6.11.1 is supposed to be compatible with Monterey and there are no known issues listed, has anyone else experienced similar problems? 

    Thanks

  6. I have found a couple of other threads but they were incomplete. Is it possible to stop a client task before it runs (in the planned state) and after it has started to run?

    One scenario is if a client task has been scheduled and the client system is offline, it is added as a planned task but has not been sent to the agent yet. I want the ability to cancel this task so that when the system comes online it is not sent to the agent. 

    I have some client tasks that have been "running" for over a month now and they never complete so I would like to stop them, is this possible?

    Thanks

  7. Hi all,

    I recently added the default rules to protect against ransomware but now some legit connections to Sharepoint in powershell are being blocked. I have found the list of IPs to set up in the firewall to fix this (https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide) but some IPv6 formats are not accepted by Eset e.g. 2620:1ec:d::10/128.

    Is this as simple as /128 CIDR subnet is a single IP so I should just enter in 2620:1ec:d::10 and it will have the same effect? My IPv6 experience is poor..

    Thanks

  8. 5 minutes ago, carmik said:

    Very interesting! Have to ask: how did you isolate this task. That is, how did you go about investigating the cause of this?

    A bit of luck to be honest, I was looking through the event logs and nothing was of interest. I looked at the local Eset HIPS log to see if it happened at particular time intervals and it seemed random. I then went through scheduled task library looking at the action tab of each task hoping to find wscript.exe or a vbs file and I found this one. I then enabled history for the scheduled tasks, checked what the script did, checked the exe was clean and then ran the task manually which caused an alert to be sent and an entry was added to the HIPS log. I then searched the task name in Google to work out what it was for, looked in programs list and removed the Intel software and set the service to manual. 

    I'd love to know if there was a more surefire way to diagnose these were the script not to be set up in task scheduler for example.

  9. I've resolved this one now, in scheduled tasks I found "USER_ESRV_SVC_QUEENCREEK" which was set to run at logon. It would use wscipt.exe to run C:\Program Files\Intel\SUR\QUEENCREEK\x64\task.vbs. That VBS file contained:

    Set objShell = CreateObject("WScript.Shell") 
    objShell.Run("C:\WINDOWS\System32\cmd.exe /c ""C:\Program Files\Intel\SUR\QUEENCREEK\x64\task.bat"""), 0 
    Set objShell = Nothing 

    And task.bat just contained - "C:\Program Files\Intel\SUR\QUEENCREEK\x64\task.exe" 

    Unsure why it is such a messy way to run task.exe. Uploaded the exe to Virustotal and it was clear. Removed Intel Driver and Support Assistant and Intel Computing Improvement Program, set Energy Server Service queencreek service to manual. The scheduled task was removed when uninstalling the software. 

  10. 10 hours ago, itman said:

    To begin, dismhost.exe running from the user temp folder is OK.

    I monitor dism.exe execution via Eset HIPS and the only thing that starts it on my Win 10 20H2 installation is cleanmgr.exe running from a Microsoft set up scheduled task.

    The above said, PowerShell usage is "baked into" Windows and is used internally for many OS functions. As such, it is entirely possible Windows internally is initiating the above activity you posted. As I posted previously, I monitor all Powershell.exe startup via Eset HIPS. I also monitor my Windows Powershell event logs and I have multiple daily event log entries showing PowerShell running to perform required system maintenance activities. Also, I have never once received an alert from my Eset HIPS Powershell start up rule in regards to this activity. So however Windows is running Powershell in the background, the Eset HIPS doesn't detect this activity.

    Bottom line is I have seen enough to state that the recommended Eset HIPS rule to monitor child process startup from Powershell wasn't thoroughly tested and should not be used.

    Thanks for your time on this thread, I have disabled the powershell rule now. 

    I have one remaining alert that only affects one Endpoint therefore it is possible this is a malicious process:

    Source application: C:\Windows\System32\wscript.exe
    Executed operation: Start new application
    Target: C:\WINDOWS\System32\cmd.exe

    I will see if I can find any clues in event viewer about this one. 

  11. It is possibly connected to a Lenovo service such as one that Lenovo System Update runs, these are all Thinkpads. When I run System Update manually I get a lot of blocked processes. Could be unrelated but that is one thing all these endpoints have in common.

    I am also now receiving a lot of alerts for Powershell running dismhost.exe, I assume this could be Windows updates. After it gets blocked once, it gets blocked again but on each occasion the target is a different folder in the temp dir i.e.:

    Source application: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
    Executed operation: Start new application
    Target: C:\Windows\TEMP\876F365A CA98 4687 91F5 43B7FAE16537\dismhost.exe

    I also have wscript.exe trying to start cmd.exe. I am just concerned that some of these may be malicious processes, when I get time I will try to tweak with permissive rules or otherwise may just need to remove the policy.

  12. I have gone into event viewer, the event is in the Eset log at 08:00:15 so I have filtered the Application and System log to only show 07:59:30-08:00:20 but the only event shown has a source of "Security-SPP" and details "Offline downlevel migration succeeded.".

    Any ideas where else I can try to work out the source of this? I will set up the permissive rule anyway as I need access to Powershell.

  13. Thanks for that info. Yesterday I tried to replicate the same issue on my system by rebooting and signing in but nothing happened, but this morning I have received the same message. I went into my Eset HIPS log and it is listed but doesn't have any more info than what was in the email alert from PROTECT. 

    I browsed to the StartupInfo dir in that article but the latest date modified was yesterday.

    I can just disable the rule but I like to try and work out the cause first, just not sure how I can do that in this case. I can compare what services each system runs and what startup items there are and look for clues. If it triggered on every boot then would be easier as I could adjust my startup items to test.

  14. 1 minute ago, Marcos said:

    You should be able to solve it by disabling the rule "Deny child processes for powershell.exe".

    I figured it was probably a false positive but my thought was if Eset recommend those policies then best keep them in place if possible so I was trying to work out the cause first to see if it was anything important. Are there logs I can view on the local machine? Thanks

  15. I downloaded the recommended HIPS policy, uploaded to PROTECT and applied to one of my OUs. Since then I have received several of the same message from a few endpoints:

    Source application: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
    Executed operation: Start new application
    Target: C:\Windows\System32\Conhost.exe
    Action taken: Blocked

    These are AzureAD joined laptops, the only agent on them is Eset and the only other unusual thing I can think of is an Outlook add-in that inserts email signatures.

    I enabled "Log all blocked operations" in the policy but after the next email notification was received I ran the log collector task on that endpoint but there was nothing listed in the Logs, Diagnostic, HIPS section of PROTECT.

    I spoke to the users and they did not see anything strange other than the Eset pop-up and had not ran anything themselves. One user said it happened as soon as they signed into the laptop. 

    Is there a local HIPS log on the machine that I can view and work out what might be causing this? 

    Thanks

×
×
  • Create New...