Jump to content

BStudentCFA

Members
  • Posts

    13
  • Joined

  • Last visited

Reputation

0 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Appears to be fixed, several notes. I don't have anything to send because it turns out I already deleted that stuff last night / early morning, and did a few other things. Note that there's one thing not mentioned in that link you sent, which I think is fairly new: you can now go into your Google account and set a password to encrypt not only your credentials, but all Sync stuff. So sync wont begin on your Chrome browser in a new session until you've entered the password- that should offer some additional protection. FYI: My New tab is totally vanilla - google, linkedin, my bank, etc on all platforms Search engines was another story - there's two lists of "Search Engines:" the Default Search Engines - Google / Bing / Yahoo / Ask - that one had Google as the main search engine, but also listed other mainstream engines name above which I consider sketchy - I killed everything but Google (I imaging DDG is probably allowable but it was not on the list). Funmoods was listed as a search engine on the second list titled "Other search engines" list, which literally has about 100 websites that aren't really search engines, with Amazon at the top (sorfted alphabetically). The "Other search engines" list is a big bag of WTF: stuff like Macy's, the DMV, etc, are listed as search engines. Apparently it's a list of sites where you have used a search box on that web site. I don't think it is exclusively google, since Amazon is at the top and AFAIK their onsite search isn't powered by Google. I have no idea how funmoods would have gotten on there, possibly accidental click - or maybe on the search box of someone else's site. IMPORTANT: the "%LOCALAPPDATA%\Google\Chrome\User Data\Default\Web Data" file is a sqlite3 database that contains anything you have typed into a form or cut / pasted, including (it looks like) entered via google autofill. So this file contains name, address, social, credit card numbers, etc unencrypted on your hard drive. This is not secondhand information: I loaded the file into datagrip and was shocked at what they leave lying around on my computer. You can look at it from the command line with sqlite3. Google keeps your sensitive personal info locked tight on their own servers, but not in this file. Personally, I am turning off "autofill" and am not syncing form-filling data, forever. Anyway, I'll let you know if this comes back. Thanks for your help!
  2. Hey if it's less work that's a win in my book. The last full scan I ran was clean, the newer ones are local - I'm running a full threat scan now with infection back in place, will go for a run. I'll send the log and give FRST a shot when I get back.
  3. Hi Aura, I read that post last night before running my experiments, and I have read your extensive interactions with other users. Maybe I'm missing something, but double-check what I wrote carefully and let me know your thoughts on why this isn't working for me, I believe my reasoning is solid but I learned long ago that humility makes me smarter, so please don't hesitate to point out the flaws in my approach: Again, I have Macs, Androids, Linux boxes, and Windows. All running Chrome. The critical problem which AFAIK makes the suggested solution not work for me is that the same data which appears in Win10 under: %LOCALAPPDATA%\Google\Chrome\User Data\Default\Web Data ... ALSO appears in the cache of the Mac, Android, and Linux platforms wherever they are stored: Syncing with any of them causes the malware to be propagated. The particular one I have, funmoods , is not detected by MWB for Mac or Android, nor is it detected on the one AV (bitdefender) that I have on my Linux boxes. The suggested solution requires cleaning all infected machines: MWB cannot do this because it does not detect funmoods on Mac or Android. This is what I was verifying last night: the PC can be re-infected by a single android, Mac, or Linux platform that is running chrome and syncing. Best I can tell, the only good news is that the infection is taking place in a fairly low-security cache and the data does not appear to be encrypted. Since that file is basically mysql, I can probably write a python script that can pull the records from the file and do an A/B where the only thing that has changed in the file is the removed infection coming back. If i can find those records, then I can probably connect my android devices and mount their filesystems, find the corresponding file, and remove the same records. I would expect that being unix and linux, the same file should be similarly find-able and clean-able with the same script on Mac and Ubuntu. Again, maybe I'm missing something, but ... ACTUALLY the same scheme might work without any code if I can find the file locations and the data are binary-compatible: just have MBAM clean the Win box, and physically copy the clean file to appropriate locations on other platforms if I can get the permission bits to line up. I suspect that the files would be bin compatible b/c they are MySql and doing so makes the google devs lives easier without risk. Anyway, I am completely open to the idea that I'm missing something more obvious, but I'm certain that article isn't it. Or hey, I've got an idea: Malwarebytes could fix it. They're in that business, right? They would have to do it as a chrome addin, though, in order to disinfect any platform running chrome. And they should really get on it quick. If I was a virus writer I'd be riding this cross-platform exploit to the bitcoin bank, baby. - B
  4. FYI I do not eat with a Mac. Too late to edit spelling wrecker damage: replace "eat" with "mean" ...
  5. https://forums.malwarebytes.com/topic/215437-chrome-pups-arent-going-away-because/ Retitled linked topic to make it easier to find. ... Sorry about the bump but it was too late to edit original title...
  6. The reason that these pups are not going away is because they are syncing across Chrome on all devices including Mac Linux Android and PC. It is the same file being sent by Chrome across all platforms. It is only detected by Malwarebytes on the PC, it is not detected by malwarebytes for Android or for Mac. I tried the following experiment: I disable all of my devices except for say, one mac and one PC and I clean the PC and then I let the PC in the Mac sync the infection comes back to the PC even though the Mac tested clean (I eat with the Mac version of Malwarebytes). The same is true for Android and Linux. Android tests clean, I cannot tell you about Linux other than it does not show up in bitdefender. I performed an additional experiment to test the hypothesis that the infection is syncing with the Google cloud as well, in addition to syncing with other machines- however I do not think that's the case because when I disable all devices except one PC, and then clean the one PC with Malwarebytes, the one PC does not get infected until I fire up Chrome on another device. Perhaps Malwarebytes could list these PUPs along with the platform-specific virus definitions for mac and Android, however that will not fix the problem for Linux, and something else has to be done there. If you have a beta version of malwarebytes for Linux this would be a good time to release a limited functionality version of it to just do this one thing. - B
  7. ISSUE RESOLVED: Steps to fix: Directed browser to Kaspersky.com Bought the Total Protection Product ($60) Downloaded Installed Updated definitions Goodnight!
  8. Well I'm running on top of defender etc. And too many anti-X programs will eventually step on each other.
  9. Me too tried everything: Win 10 x64 all updates, using win defender MWB Premium Version 3.1.2.1733 Component pkg: 1.0.122 Update Pkg 1.0.1973 Scans for 1 second and quits Web protection was off, hangs when started Exploit just won't turn on Malware and Ransomware protection must be started manually Early-start and delay make no difference
Back to top
×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.