Jump to content

JS/Mindspark.E (still need proper solution)


cmit

Recommended Posts

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

  • Administrators
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.

Link to comment
Share on other sites

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?

mindspark cleaned.jpg

Link to comment
Share on other sites

13 hours ago, galaxy said:

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 by cmit
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by itman
Link to comment
Share on other sites

  • 2 weeks later...
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.

 

Link to comment
Share on other sites

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 by itman
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...