Skip to main content
Update April 28, 11:45 a.m. MDT: 

 

Please click here to see the most recent update.

 

 

UPDATE 4/28/17 11:45 a.m. MNT: We have 0 calls in queue on our phone line, and are working through about 80 tickets related to the False Positive repair utility. A good portion of those are simply awaiting customer verification.

 

Please note, the utility was built to address only this specific false positive issue. It will be deactivated in the future. 

 

If applications are operating normally on your systems, you do not need to implement the utility. 

 

If you haven’t yet submitted a support ticket and you need the repair utility, please do so here. Include your phone number as well with the support ticket.

 

Thank you.

 
Hi Folks

Just to recap, here is where we are at this point. The best current manual approach to fixing affected machines are the options posted on Webroot Support. There are several different specific techniques on that page that can be used for your critical situations. Its manual, but effective.

We are also continuing work on a "from the cloud" en masse approach to sending agent commands to restore from quarantine for all affected customers. It has proven to be trickier than we anticipated to get it right without downstream issues and test it with both live customers (using volunteers) and internal accounts. More on this as we progress it.

We are also working on a different approach in which you would download a small app that can be pushed to your endpoints that could be kicked off with a command and the app would do the restoration. This approach has not been completed or tested, so no timetable.

Lastly thank you to all on the forum especially those who have generously shared your own successful approaches with your colleagues here. Our support people are available to help of course, but its great to see the community sharing.

More news later.

MIke
@ I ran into this exact issue on several workstations today. Mostly it was catching our remote agent installer in our %netlogon% on all servers but then it was doubling and even tripling. I hadn't seen it on all of the workstations but I did find it quite odd that it wasn't showing up in the cloud console. 
@ Thank you for the update. I know you guys are taking a beating right now so thank you for sticking around with us. 🙂
@

 

That wasn't hard thanks for the update. Yes taking a beating because some of us have been trying to help clients through this since yesterday with no sleep, so sometimes frustration gets ahold of us. We appreciate your efforts and if you or who ever would continue with valuable updates like that it would be appreciated.

 

I have tried these steps so far and seem to be having a little success on some machines but have others that simple will not release the quarintined files

 

Posted by @

I know most of you know this but this is what has been working very well for us.

-Switch policy to unmanged in the Dashboard

-on local device, right click and Refresh Dashboard on WR tray icon

-on local device release the quaratined files

-on dashboard run the "Re-verify all file...." Agent command

-on local device, right click and Refresh Dashboard on WR tray icon

-Switch policy to back to the actual policy in the Dashboard

 

If anyone has had any luck getting commands to work from web console I would love to hear input.

 

Also does anyone know of a way to get agents to unmanaged if console command is not working????

 
 

Also does anyone know of a way to get agents to unmanaged if console command is not working????

 

This would be beyond valuable. I have had some success getting commands pushed to workstations but a few refuse to push out. Any suggestions would be appreciated.
UPDATE: We will be sending an email out to all our MSP partners for them to forward to their customers. It clearly states that Webroot was responsible for this issue, not our Partner MSPs, and reiterates the fact we are working on a comprehensive solution. Please be on the lookout. As a backup, we will post that email here on this thread.  
Please find the letter that our MSP partners may share with their customers who were affected here:

 

https:///webroot/attachments/webroot/ent2/1451/1/WebrootIncidentResponseLetter.pdf
@ Do you mean switching the policies to unmanaged or waiting on the command as it sits at "Not yet received"?

 

If it's for switching policies, I have not encountered any issue. Here is what I did in switching policies:

 

1.) Go to Webroot Console

2.) Endpoint Protect > Find the end point > Apply policy to endpoints > Unmanaged

2.) Log into the workstation, right click on the Webroot agent, hit Refresh Configuration

3.) Once policy is confirmed, Righ click Webroot > Open > PC Security (Cog next to it) > Quarantine > Select all that Apply > Restore

4.) This may have a while to release.

5.) Once complete, you can put the end point back into managed mode. (You can also run a verification but by that point, I didn't need to)

 

As for waiting on the commands, it took several hours for commands to be pushed as there is a huge backlog. Last night it took over 8 hours for the backlog to catch up. You can attempt to poll via the command line but I had very little success in this. 

 For 32bit Operating Systems, type:       "C:Program FilesWebrootWRSA.exe" -poll For 64bit Operating Systems, type:       "C:Program Files (x86)WebrootWRSA.exe" -poll  You have to make sure that the endpoint is online or it won't work! Had this happen to several today where the endpoint showed online but the workstation wasn't. I've only encountered 1 issue through all the endpoints I went through ( 200 + ). If you need anything else, feel free to PM me. 🙂
By the way - potentially get ready for an influx of angry Australian and New Zealand webroot customers.

 

We had a public holiday yesterday so people who were not monitoring their systems in a way that would have detected this will be walking into this issue now - it is 9.45am Sydney time.

 

From a very specific Australian (and possibly Canadian) perspective we saw Webroot delete IRESS - a very popular Australian share trading & market data application - think an Aussie Bloomberg.

 

We also lost a bunch of our PRTG probes at customer sites because the probes had Webroot installed, which detected the PRTG process as malicious.

 

We also lost HEAT security software for preventing USB use and whitelisting applications (ironically).

 

We also saw an issue where the top level of our portal wasn't showing the infections from some of our customers, leading us to miss some damage that was done until we had customers call in this morning.

 

Stay safe out there ANZACS...
@ Thanks for the heads up. 
@ I ran into a similar issue with 1 machine that would absolutely not giving over the quarantine files (even though the cloud console confirmed that the release had executed). I don't know what exactly I did to fix it but these are the steps that I did take and eventually it worked:

 

1.) Confirmed that the endpoint was set to "unmanaged" in the admin console.

2.) Refreshed the workstation's endpoint.

3.) Confirmed that the user account that I was in was added to the local administrator group (I had a lot of files that were in the C:WindowsSystem ) and UAC was disabled. (I don't know if this matters but worth a shot)

4.) Could confirm that the files were still in the Webroot Quarantine (You should be able to see them in the C:Quarantine or even though the endpoints quarantine)

5.) Right clicked on the workstation's webroot > PC Security (cog) > Block / Allow

6.) Allowed ALL currently blocked files and saved. 

7.) Went back to PC Security > Quarantine > Release

 

It took a few minutes and I checked the folders that the .exe were in, and I could confirm that the programs were back in their place. This was the only one computer that I ran into out of the 200+ that I worked on. Let me know if this works for you. :)

 

 
Appreciate the advice :)



I'd already pushed from the console but certain systems aren't reporting back to the cloud.

I've run wrsa.exe -poll from each of the systems with no success.

 

Not sure what to do with them, they're workstations that are locked down with no access to modify webroot outside of the cloud console (We won't be doing that again I don't think lol)

 

It's been 24+ hours, I'm considering just going into safemode and removing webroot and taking my chances as we need to get these up and running again.
UPDATE APRIL 25, 2017:  We have a final beta version of the false positive repair utility ready for immediate evaluation. We need five additional customers to participate in our test. If you would like to participate, please call our support team at one of the following numbers:

 

 

Business support phone numbers



US Support (toll free)

1-866-254-8400



Australia Support (toll free)

Australia Support (direct line)

1 800 848 307

+61 (0) 8071 1903



Ireland Support (toll free)

1 800 902 213



UK Support (toll free)

+44 (0) 808 101 7260
@ please call 1 866 254 8400  and if someone from Australia answers, ask for Shawn or Lucas. They are triaging this in our Broomfield office. Please post back here if you have problems and we will troubleshoot. 
I have called the number and a ticket was created for me. She said she would send it to escalations in Australia because the US office is closed. I didn't see the note about Sean or Lucas. Ticket number is 85056. I would like to test.



I do want to say after manually cleaning a few computers, they did get flagged again with quarantined files. The machine are XP.
@ Thank you! I've notified Shawn about this issue and he'll reach out. 
UPDATE: We continue to make progress on a resolution to our false positive issue. 

 

We created a comprehensive repair utility, and have successfully completed QA. We are currently rolling out the utility to a group of beta customers to ensure it works for our broader customer base. We expect to complete that work soon, and then will make it available incrementally to the entire customer base to ensure a successful deployment.

 

Stay here for ongoing updates.

 

Our Support team remains available to those of you who need urgent assistance, and we thank you for working with us through this challenging issue.

 
Can anyone offer suggestions for a computer that has been almost completely disabled by these false positives? I cannot boot to safe mode or safe mode with networking to performing any of the gui-based fixes. sfc /scannow via windows 10 startup troubleshooting is unsuccessful. I was able to capture the dlb.db file from the broken laptop's hard drive (per tech support's instructions) and load it on an unmanaged webroot endpoint to view all of the files that were quarantined. The list has got to be 200-300 items long and is 95% registry entries. How can I get this broken laptop working again? Support has suggested various fixes (none of which have worked) but has also stated that these fixes don't apply to the registry files that were incorrectly quarantined. Help!
@ you might be boned dude. Good luck.
@ @ will this utility be able to run from the command line silently with no user input from the SYSTEM user context? That is what MSPs will require so we can easily script it in our RMM systems like Kaseya and Labtech.
I saw the letter MSPs can use, but what about regular small businesses?  I would like an official letter too that I can share with executives that are beating down my door.  

 

Thanks!
@ I was doing some beta testing last night and yes, you can run from CMD. It is an executable that does run silently by default so you can push it out via your RMM tool.
@ I would snag a Windows 10 repair disk/USB image and try to repair from boot.  What a mess, I'm sorry you have to deal with that.  
Good morning.

 

I arrived today to find some PC's that had been repaired yesterday exhibiting the same behavior today. Key notes:

 


  1. We have followed previous recommendations for MSP's
  2. Files were added to the exclusion list both with MD5 hashes as well as by folder path.
  3. Application files were flagged again but this time with a different infection.
  4. The malware group reported is win32.autoblock.1
  5. I was again able to restore from quarantine as we are now running almost every client as "Unmanaged"
  6. I ran the wsalogs.exe utility to grab full diagnostic logs as well as scan logs from a single workstation before performing the manual repair.
  7. I still see agent commands in the GSM from yesterday as "Not yet recieved"
  8. I provided an update to my ticket already logged with  Webroot Support as well as sent direct emails to my Channel Account Manager and the Sales Engineer I worked with in beta testing yesterday afternoon
At this point, I'm unable to tell how widespread the issue is. So far, it's not as broad as what we saw originally but I have multiple clients running the same EHR application that is getting quarantined.

 

Are there any additional updates or is anyone else out there experiencing the same issue?

 

Regards,

Jared
Good idea to have a doc users can use to show to their management (vs an MSP doc). We will post such a doc later this morning.

Reply


Terms & Conditions