ATTENTION Customers, All Partners and Employees: The Customer Support Portal (CSP) will be undergoing maintenance and unavailable on Saturday, November 7, 2020, from 11 am to 11 pm PST. Please read our blog for more information.
Traps ESM & Agent Version: 4.1.4
Background: So thanks to help of Glen in the LiveCommunity, we've gotten up and on our feet with regards to using the Traps VDI Tool to assess our systems before enterprise-wide deployment. The idea, of course, is to minimize the likelihood that Traps knocks over a legit process when we deploy en masse by using the Traps VDI tool to assess all of the hashes on a system, then identify all potential false positives, and adjust our master policy on the ESM appropriately.
Issue: After kicking off a VDI Assetment with "Wait for Wildfire", the tool works for a bit, assessing hashes and what not, but we've been "stuck" for hours (like 12+ hours) at the same point (530 unknown samples to be submitted to Wildfire). This has been the case for the last couple of days.
What we've done: We've restarted this process a couple of times and get the same results. Also, we've started from scratch, grabbing a new set of PE hashes with sigcheck. Same results. Also for the record:
On your console look at the Policies tab / Hash Control section. Set the search criteria as Endpoint IS (machine being scanned) and VERDICT ISN'T BENIGN then click search. This will return all of the hashes that are not benign from that machine and the status of wildfire uploads of them. This should at least give you a way to see where the ESM server is in evaluating the hashes.
I believe I may have experienced something similar a while ago. I had to open the TRAPS AGENT console on the endpoint, check in, close the TRAPS console on the agent, wait a couple minutes and then start the process of running the CYTOOL followed by the TRAPS VDI TOOL. That ensured that the local agent had made a successful connection to the ESM before running the tool.
Thank you for the tip. So I see that I'm getting hundreds of failures. This boggles my mind. I see WildFire working on the firewalls, I see other hosts able to submit files successfully to WildFire via Traps. What gives?
Couple of points - the second screenshot confirms that the client is uploading the files successfully to the ESM. As far as I'm aware there is no need to worry about the communications between the client and the server.
At this point there is a local user called "TrapsDownloader" which moves the files from the BITS folder in order to transfer to Wildfire. I would say it is at this point the wheels are coming off your bus :)
At this stage please run your mouse across the Upload Status icon to see what it says. You will need to check the Wildfire website to confirm if your upload limit is exceeded per day.
If its not due to the upload limit being exceeded then we can try checking a couple of places to see if its the second option.
Firstly in C:\ProgramData\Cyvera\Logs there is a log called Server_<Servername>.log which rotates after 20MB in size. In here see if you have an entry like this:
ERROR CyveraServer 4 Cyvera.Server.Facades.WildFire.WildFireUploadFileService WildFire Error when downloading to Temp Folder: Unauthorized, HTTP status:(Unauthorized).
If so then check your IIS logs and it is likely you have an entry (probably multiple) like this:
GET /BitsUploads/Wildfire_30_05_2018-04_06_59_940_2895659a-b743-49c5-bb8f-9942d94a8298.zip - 443 - 10.1.2.23 - - 401 2 5 0
From the above you can see a HTTP 401 (Unauthorized). In my case this also has a corresponding entry in the Windows Security log like this:
This is because our ESM server doesn't have the same name as on the certificate and therefore I need to enable BackConnectionHostNames to allow the local account to access the server via the CNAME.
Sorry if I have gone over known and taken for granted information.
Let me know if this helps or hinders. Probably want to make sure we are troubleshooting the same issue before making recommendations on changes ;)
# Edited to remove incorrect information. Forgot that "Upload limit exceeded" is in relation to the size of the files not number. Sorry for the misinformation.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!