Show the actual path of a virus

Userlevel 4
I have never really been unhappy with webroot until I got this response, Do I really have to request a new feature to actually show me where the virus was detected? 
Take a terminal server with 20-60 users on it, All that webroot provides is %appdata%somevirus.exe with no indication under which profile it was detected. I'm just blown away that I have even request this basic piece of information as a new feature. Webroot should at the very least report the username but even better would be the path of the user such as \servershareJDoeAppData . 
Thank you for contacting Webroot. The paths are normalized or short hand path names, so for example %cache% could equal c:usersxxxxxxxxxxxappdatalocalmicrosoftwindows emporary internet filescontent.ie5iu5420v7 

We normalize common paths to reduce bandwidth in communicating with the cloud and increase the speed of our Cloud based database. This is similar to the inbuilt Windows environment variables such as %AppData%. 

I agree that non normalized paths would be of greater use to the end customer. I suggest you enter this issue as a feature request on our community so that we can gauge its popularity and gather a development priority for it. 

Please post your idea on the Webroot Community Feature Requests page. The Webroot Community Feature Requests page is an online forum where you can vote on and discuss ideas. Ideas submitted on the Webroot Community will be reviewed by our Development team, and considerations such as the number of votes, practicality, and feasibility of implementation will be taken into account when planning future releases. 

19 replies

Userlevel 7
I understand Webroot's reasoning for consumers, but businesses need detailed information. 
Userlevel 7
Badge +56
I will Kudo this as I find it satisfactory for consumer but Business version needs more Details.
Userlevel 1
I know that the emails we receive include the username, not sure if it's any use in a terminal server environment - we run several, but haven't had an alert from them yet!
An endpoint has recently detected an infection:
Hostname: HOST
Username: username
Group Name: GroupName
Policy Name: Recommended Defaults
Keycode: xxxx
Infection List:
SETUPTOPARCADEHITS.EXE, Uncategorized Malware, %temp%, 3849C15B4FE6464FEF67916481E128BA               
IMGBURN.EXE, Uncategorized Malware, %cache%, 7FBE4FA9BC6BE1B81F98DD6F41B4B053
Userlevel 5
The agent does log the specific paths so we will evaluate how we can better provide this information to the admin either in the console or by request via agent command, etc... Can anyone think of any other situations other than terminal servers where the normalized path would cause confusion? Thanks all, -Shawn
Userlevel 7
Hi Shawn,
Because of different users and system contexts, %temp% could refer to multiple locations, including C:WindowsTemp. But thinking about this more, I do understand where Webroot is coming from. I guess you're architected where you're trying to deduplicate infection pathes as much as possible to reduce IOPS and make it easier on threat research.
In call center environments where multiple people share a computer this would be an issue as well.
Shawn, something I would really really love is an agent command to retreive the log from the endpoint. I've considered using the download and execute command to make a script to upload it to an FTP site, but that's not very sexy.
This would be a cheap way for you to get the administrator more information. Instead of updating your cloud to deal with more columns for features that aren't a high priority, just make local client logging more robust and maybe upload the last 3 days of the log to the console whenever an infection is detected.
Of course, I'm full of cool ideas for Webroot to spend years implementing :)
That is my burden. :(
Userlevel 5
That is correct that normalized paths make threat research much smoother and enables us to create rules that span much further that if specific paths are used.

I do like your point about single systems with multiple users. I can see that being an issue when trying to track an infections origin.

With all the new active directory related data points soon coming to a Webroot console near you, this may also help to display the information you are looking for so lets revisit this after the next console release and see if we have already addressed this.
I also liked your comment aboput being able to use an agent command to request agent logs and being able to access or view those via the console. This is not far fetched at all and I would not be surprised to see this in the near future.
Thank you again for all your participation!
Userlevel 4
I think similarly for many infections it just shows %temp% as path, where in fact these infections came via browser. I would love to see the URL that relates to the browser infection.
Yes, seeing that a detection is in %assembly% isn't going to cut it for a business.  That's not even a real windows environment variable.  I had to go to the client to track down where on the machine it was....
Also a +1 from my side; I've seen %cache% and %assembly%.
Of course in our company network it's easy to look at the client log file, but if the client is only connected in a public network I won't be able to access the log.
I like the idea from @ although FTP isn't encrypted... 😉
Userlevel 4
Badge +7
+1 from us, too.
%appdata% and %temp% are fine to report as the path, because you can do Start>>Run and type either of those locations in, and Windows Explorer will open them. However you can't do that for %cache%. We support many shared workstations where multiple users log in. So it would be very helpful to have the absolute path (c:userswhoeveretc...) in those cases.
Userlevel 7
Badge +29
Being able to know when users are logged into a server through a terminal session and if they execute something, we need to know EXACTLY where this is held and if Webroot has taken definitve action on it.
As a new customer of Webroot I find this the most frustrating feature so far.  I kind of understand the reason but I doubt adding the full path to the console makes that much difference to the bandwidth unless you have 100's of warning per day.  Given how few warnings most people get it's not likely to cause any noticable impact on performance.
Badge +3
The explanations given above (cloud storage space and threat research) don't stack up.
In the case of storage, it really is a trivial amount of data.
For threat research, there is nothing stopping webroot using the env variable for their internal threat research and STILL giving full full path to the admin.
We are an MSP and have many Citrix/RDS environments to manage. Webroot won't be evaluated further if simple requests like this continue to be ignored years after they are made.
I have added my kudos and wish to chime in with my own frustration that this is still lacking. I see that this request goes back into 2015... are we really asking that much of Webroot?
Badge +8
I have to agree with the sentiment here. We really need to know the full path of the issues.
This is the first issue with WebRoot I have found that motivated me to persue. I love the product.
Once again, I agree with the people expressing their displeasure with this lack of a feature or a need for the entire actual path of the location of the virus or infection being available some way somehow.  It is frustrating to see a network continue to notify of infections even though they are being caught without having an easier way to find the root of the problem without having to take down a 60 node network and look at every computer one by one.
Userlevel 7
Badge +35
We appreciate your suggestion and have taken it into consideration. This feature is not something that is on our current roadmap, but we will keep it in mind if anything changes. Thank you!

Had been trialing WR on my RDS farms. Was going great, until an infection - it was impossible to locate the source. Reading this thread is enlightening.


On our mutli-user servers when a detection is made, I found a log file at this location which shows the actual path to the infections:




I agree having this information provided in other contexts (particularly the email alerts) would be much more helpful.