Jump to content

PuterCare

Members
  • Posts

    69
  • Joined

  • Last visited

About PuterCare

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    U.K.
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. I am unable to edit my last post, I added an allow policy for powershell to start conhost and now I can run powershell. Still not sure what was happening in the background to trigger this.
  7. 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.
  8. Thanks, I will try that. I just tried to run powershell and it was blocked by Eset with the same message so looks like something is running powershell in the background and it will trigger the rule. Not sure what that might be, a safe Windows component perhaps.
  9. 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.
  10. 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
  11. 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
  12. Are these default rules or something that is documented but needs to be set up? I had a look in the help files and found the built-in policies in ESMC/PROTECT. Thanks
  13. My issue resolved itself after a few hours but the techs advised I move to ESET Protect so I am setting up the new VA and pulling the DB across today.
  14. I see the below, only the bottom entry is available for EES, all the others are for EEA but usually I have several entries for EES.
×
×
  • Create New...