Issues with Traps VDI Tool sending hashes to Wildfire

[MikeBourda]

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:

1. We can ping the ESM server / ESM Console (same box for us) from the target host
2. We are running the VDI tool on the same host that we ran sigcheck against
3. Network seems fine.  Can ping from target host to ESM server, ESM server to internet.  I'm not seeing any drops in the firewalls.  I'm seeing traffic from the ESM to Wildfire. 

Any ideas?

[ron_downey]

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.

[MikeBourda]

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?

[ElasticSkyX]

Hi there,

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 🙂

Two options:

1. Wildfire actually has an upload limit of files in a day. If I remember correctly this is ~16,000 files.
2. There is an issue with TrapsDownloader accessing or authenticating to get the files uploaded from the client.

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 😉

Kind regards.

# 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.