cmit 2 Posted September 7, 2018 Posted September 7, 2018 Still has this issue even with ESET v7 on multiple domain computers. Can't waste time one-by-one checking Chrome on affected domain computers. Already checked this thread (https://forum.eset.com/topic/13073-jsmindsparke/) but could ESET experts kindly help ESET customers to talk to Google how to properly resolve this? Also, is it always only from Google Chrome or could also be from somewhere else?
Administrators Marcos 5,739 Posted September 7, 2018 Administrators Posted September 7, 2018 Please refer to https://support.eset.com/kb6551/. It is important to disable syncing of extensions to stop PUA extensions from being synced and detected again.
cmit 2 Posted September 7, 2018 Author Posted September 7, 2018 7 minutes ago, Marcos said: Please refer to https://support.eset.com/kb6551/. It is important to disable syncing of extensions to stop PUA extensions from being synced and detected again. Checked manually and found out one of our domain computers (Win 7 x64) does not have Google Chrome installed nor Firefox. Only Internet Explorer as the web browser. This 'disable syncing' "solution" does not apply if no Chrome installed, right?
Administrators Marcos 5,739 Posted September 7, 2018 Administrators Posted September 7, 2018 2 minutes ago, cmit said: Checked manually and found out one of our domain computers (Win 7 x64) does not have Google Chrome installed nor Firefox. Only Internet Explorer as the web browser. This 'disable syncing' "solution" does not apply if no Chrome installed, right? If running a full disk scan with strict cleaning doesn't remove the PUA, please gather logs with ESET Log Collector and upload the generated archive here.
cmit 2 Posted September 7, 2018 Author Posted September 7, 2018 1 hour ago, Marcos said: If running a full disk scan with strict cleaning doesn't remove the PUA, please gather logs with ESET Log Collector and upload the generated archive here. attached screenshot and checked the directory, ESET does remove it (from real-time), but same issue re-occurred again on and off multiple times. what am I missing?
galaxy 11 Posted September 8, 2018 Posted September 8, 2018 (edited) Do you always have the problem on the same PC Edited September 8, 2018 by galaxy
cmit 2 Posted September 8, 2018 Author Posted September 8, 2018 (edited) 13 hours ago, galaxy said: Do you always have the problem on the same PC It happened on multiple domain computers (Win7 x64). Not always on the same PC. Sometimes same PC has same issue multiple times on and off, sometimes happened on different computer(s). So far the applications (Process Name) that cause this behavior are Google Chrome and Firefox. Edited September 8, 2018 by cmit
itman 1,924 Posted September 8, 2018 Posted September 8, 2018 I don't know what version of Chrome you are using. But the current versions with sandboxing configured, I thought were supposed to prevent something like a .js script being dropped into %LocalAppData%\Temp folder.
cmit 2 Posted September 8, 2018 Author Posted September 8, 2018 4 minutes ago, itman said: I don't know what version of Chrome you are using. But the current versions with sandboxing configured, I thought were supposed to prevent something like a .js script being dropped into %LocalAppData%\Temp folder. Latest version (updated automatically). What about Firefox?
itman 1,924 Posted September 8, 2018 Posted September 8, 2018 (edited) 1 hour ago, cmit said: Latest version (updated automatically). What about Firefox? According to this: https://superuser.com/questions/1309249/is-firefox-really-that-insecure-for-not-having-sandbox-like-chrome , FireFox also has a sandbox. Since you're using Eset Endpoint, I believe it supports wildcards in file names for the HIPS. Create a HIPS ask or block rule that will monitor anything written to %LocalAppUser%\Temp\*\*.js. Note that I believe you will have to specify the full user path name. Don't know if Eset supports the %% notation in a HIPS rule. Also if you create a block rule, make sure you specify that logging is enabled and set it to "warning." This will ensure its written to the event log. This will at least point you to the source process that is creating the *.js script in the Temp directory. Edited September 8, 2018 by itman
cmit 2 Posted September 20, 2018 Author Posted September 20, 2018 On 9/8/2018 at 3:46 PM, itman said: According to this: https://superuser.com/questions/1309249/is-firefox-really-that-insecure-for-not-having-sandbox-like-chrome , FireFox also has a sandbox. Since you're using Eset Endpoint, I believe it supports wildcards in file names for the HIPS. Create a HIPS ask or block rule that will monitor anything written to %LocalAppUser%\Temp\*\*.js. Note that I believe you will have to specify the full user path name. Don't know if Eset supports the %% notation in a HIPS rule. Also if you create a block rule, make sure you specify that logging is enabled and set it to "warning." This will ensure its written to the event log. This will at least point you to the source process that is creating the *.js script in the Temp directory. Sorry a bit confused. Everytime this MindSpark issue happened, it created a sub-folder within this Win7 domain user's AppData\Local\Temp\ folder. ESET handled it by deleting that subfolder (scoped_dir..........). Could you specify what I should put in the rule? I know ESET handled it every time it happens but I need to know why only this user keeps getting this alert (on same computer) and how to stop it happening again? Example logs: Quote 9/20/2018 2:37:07 AM - Module Real-time file system protection - Threat Alert triggered on computer 701D08: C:\Users\701user4\AppData\Local\Temp\scoped_dir1784_9512\CRX_INSTALL\js\PartnerId.js contains JS/Mindspark.G potentially unwanted application. 9/19/2018 21:31:33 PM - Module Real-time file system protection - Threat Alert triggered on computer 701D08: C:\Users\701user4\AppData\Local\Temp\scoped_dir1784_29990\CRX_INSTALL\js\PartnerId.js contains JS/Mindspark.G potentially unwanted application. 9/19/2018 16:07:56 PM - Module Real-time file system protection - Threat Alert triggered on computer 701D08: C:\Users\701user4\AppData\Local\Temp\scoped_dir1784_29116\CRX_INSTALL\js\PartnerId.js contains JS/Mindspark.G potentially unwanted application.
itman 1,924 Posted September 20, 2018 Posted September 20, 2018 (edited) 17 minutes ago, cmit said: Sorry a bit confused. Everytime this MindSpark issue happened, it created a sub-folder within this Win7 domain user's AppData\Local\Temp\ folder. ESET handled it by deleting that subfolder (scoped_dir..........). Could you specify what I should put in the rule? I know ESET handled it every time it happens but I need to know why only this user keeps getting this alert (on same computer) and how to stop it happening again? What I was referring to browser-wise is that the browser, if properly sandboxed configured, should not allow file creation in the user's AppData\Local\Temp\ folder. For example, both IE11 and Edge(Win 10) use appcontainer as their sandboxing mechanism. If using IE11 on Win 7, advanced appcontainer protection is activated by selecting "Enhanced Protected Mode" and "64 bit process" for the same option. Note these protections only apply to 64 bit IE11 running on 64 bit Win 7. If this issue persists across multiple web sites the user visits, the source most likely is a browser plug-in or extension for Chrome or FireFox. Edited September 20, 2018 by itman
Recommended Posts