Jump to content
Nooch

Recurring Webroot tickets

Recommended Posts

Hello all. Relatively new to LT (deployed in March) and still working my way through things. I'm using Webroot primarily right now due to ease and portability, but have encountered a recurring ticket issue. I keep getting the following message in tickets:

 

"Webroot - 32 - Active Threats FAILED on \ at  for HKLM\SOFTWARE\WRData\Status:ActiveThreats result Value Not Found.Please make sure you have applied the correct policy to the Webroot agent."

 

Checking the registry on my LT server, I see that this set of keys actually lives in HKLM\SOFTWARE\Wow6432Node\WRData

 

Other than exporting the keys and dumping them into the place it wants to find them, any suggestions? I tried to find the monitor that is running this but I don't see it anywhere.

 

Thanks!

Anthony

Share this post


Link to post
Share on other sites

I *think* I found the issue...

 

First - the origin of the check

The monitor for this can be found by going to groups. There should be a group labeled Webroot, and inside there are various script based monitors. There are variations for 32 bit and 64 bit systems for each script.

 

The script in question is a simple registry check, looking for a 0 or 1 in a DWORD registry labeled ActiveThreats in HKLM\SOFTWARE\WRDATA\STATUS (or HKLM\SOFTWARE\Wow6432Node\WRDATA\STATUS if 64 bit). The PROBLEM is that the this ActiveThreats key does not exist in that location. It can (I think) be found at HKLM\SOFTWARE\WRDATA\THREATS\ACTIVE:Count (or HKLM\SOFTWARE\Wow6432Node\WRDATA\THREATS\ACTIVE:Count). Just updated the configuration on the monitor to reflect the same and pushing updates out to clients. We'll see how this goes.

 

Now if I can solve the Silent Agent alerts for webroot....web-groot...I am groot

Share this post


Link to post
Share on other sites

Yep, that seems to have done it. All the agents are reporting success now. I've not had a machine infected (you know, yet) but this change seems to do the job.

Share this post


Link to post
Share on other sites

Hi Guys,

 

There is a newer (Updated) version of the Webroot Integration that is being made available, the documentation has been updated on the webroot site that has this issue fixed.

Share this post


Link to post
Share on other sites

We found with this that some machines, for whatever reason just were not getting some registry entries created on install of the program and then failing those registry checks. I don't know why that is occurring we never investigated fully.

Some reg entries were being created and others were not, really weird.

I ended up building up a script and popping it into an Alert template that gets called when the registry check monitors fail. The script detects 32 or 64 bit arch, then checks each registry entry and creates it if it's not there, then closes the ticket when it's done. It seems to work fine.

WebRoot support verified it was okay to just create the missing reg entries like that, no restart or anything silly required.

 

Regards Peter.

Share this post


Link to post
Share on other sites

Peter - by chance is that script in the scripting section of the board? Sounds terribly useful.

 

Thanks!

Anthony

Share this post


Link to post
Share on other sites

We had run into the same issue a while back and i put together a script for the two alerts we were receiving. Active threats and Is silent. The script checks to see if the machine is 32 or 64 bit. then adds the required reg values. From that point, webroot is able to update those values as needed. Worked well for us. Let me know if you have any problems.

Webroot add reg keys.zip

Share this post


Link to post
Share on other sites
Hi Guys,

 

There is a newer (Updated) version of the Webroot Integration that is being made available, the documentation has been updated on the webroot site that has this issue fixed.

 

Did you folks see this posting?

Share this post


Link to post
Share on other sites

We've deployed the version 2 of the Webroot integration with Labtech, but we're running into an alerting issue not related to the missing key.

 

It seems as though Webroot just monitors the ActiveThreats registry key, looking for a 0,1, or non-existent key. What we need is to have Labtech generate a ticket (which syncs to CW) when a threat is detected AND what that threat is. I see that there's a registry key named LatestThreat, but that seems to be overwritten for each threat found. I've also found that if Webroot blocks a threat, the "ActiveThreat" key isn't updated (which I could see arguments for why it's not updating, but as we're considering migration off of Vipre and we don't trust that Vipre actually cleaned the threat, this makes us leery of trusting Webroot handling the threat without a notification/ticket too).

 

Any suggestions?

Share this post


Link to post
Share on other sites

In the registry you need to go to:

 

WRDATA>THREATS>Active

WRDATA>THREATS>HISTORY

 

to see that data, it's possible to pull it out with a script and list it in a ticket.

 

Regards Peter.

Share this post


Link to post
Share on other sites
In the registry you need to go to:

 

WRDATA>THREATS>Active

WRDATA>THREATS>HISTORY

 

to see that data, it's possible to pull it out with a script and list it in a ticket.

 

Regards Peter.

 

Can you provide a scripting example? I see an option for reading the registry, but only if a user is logged in......is that correct?

 

I was really hoping version 2 of the integration was actually much more "integrated".

Share this post


Link to post
Share on other sites

The v2 Webroot Plugin actually collects specific threat information and stores it in the Database, this information is collected from the Workstations / Servers every hour so the Remote Monitor is a little faster at alerting if a threat is detected. Instead of using a script or the likes you can simply build an internal monitor to provide a little more specifics on threat detection.

 

I've attached a monitor to this thread that will trigger if a threat has been detected on any computer within the last day and create a ticket.

WebrootThreatDetection.zip

Share this post


Link to post
Share on other sites

I imported the monitor and modified it a bit so it pulls both the threat name and the threat location. Thank you for your help.

 

Is it supposed to send threat updates every single hour? One of the machines I'm using to test hasn't been updated (lastUpdate field in plugin_webroot_threats) in over 2 hours (and there have been test threats detected on the machine during that timeframe).

Share this post


Link to post
Share on other sites

I believe the threat history is sent worth the resend system information command so the timing is dependant on your configuration

 

Sent from my SM-G900I using Tapatalk

Share this post


Link to post
Share on other sites

Thanks. Yeah, I see the schedule set to update every hour. I'm wondering if Webroot doesn't count something as a "threat" if it successfully takes care of the threat when it tries to run. In the Webroot plugin I see a "last deep scan" matching the last threat I tested, but the lastUpdated for the threat in the database doesn't match that record.

 

Also, do you happen to know how to update the "TestValue" in the monitor which reports the day/time of the last match? I know its pulling from the database field plugin_webroot_threats.InfectionDate. From what I can tell, its about 6 hours ahead of PDT and not sure if that's modifiable.

Share this post


Link to post
Share on other sites

Seems the times are all in GMT. working on a quick fix to that give me a few minutes, as for your history looking over some installs it seems that the list is being populated as per the registry : HKLM\Software\Wow6432Node\WRDATA\History so if your detection threat does not make it into that registry hive it won't make it back to LT.

Share this post


Link to post
Share on other sites

Ok, so this isn't perfect but its a work-around that will change the InfectionDate to your LabTech Server's Timezone, change the Field to Check value to: CONVERT_TZ(InfectionDate,'+00:00',@@global.time_zone)

Share this post


Link to post
Share on other sites

Just a note: I modified it a bit because it kept alerting of a virus threat within the past day, even if you resolved the ticket. I modified the following:

 

InfectionDate >= DATE_ADD(NOW(), Interval -180 MINUTE)

 

If there's an easier, more elegant way of taking care of this, I'd love to know. I also created a new Alert Template which auto calls the Webroot Full Scan script in addition to creating a ticket.

Share this post


Link to post
Share on other sites

I'm now on LT10 and am having another Webroot alerting issue. The above internal monitor works, however, when it fires off every hour it is sending the email alerts every hour. The history still shows the threat detected time (which is good), but the "Interval -180" (only alert if in the past 3 hours) doesn't seem to work anymore. For example, 6 hours after the original threat was detected it still sends alerts. Any ideas?

Share this post


Link to post
Share on other sites

Querying the LT database, I see the last infection day/time in GMT. In the above script, it was modified to report the local time I believe. Example alert:

 

1. Threat detected at 3:09pm Pacific

2. LT runs the internal monitor every hour (and sends email alerts every hour! I would love to stop that. I really only need the email alerts once)

3. Shortly after 12am that night the alerts (and email alerts) stopped.

 

Is this due to the timezone?

 

Example alert above db info:

 

ComputerID ThreatID Infection InfectionName InfectionDate lastUpdate

26 1 c:\\windows\\csc\\v2.0.6\\namespace\\server1\\users\\administrator\\my documents\\disk\\discover\\disk1\\install\\win32\\setup.exe W32.Worm.Gen 2015-05-07 22:09:42 2015-05-08 08:12:09

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×