False positive WAX####.tmp Amp detection?

[AnthonyHill51481]

I'm having some issues with Amp flagging some tmp files as malicious. I received 32 alerts from a single machine within an hour as Gen:Trojan.Heur.FU.RqZ@a0N@95j. The files are created by werfault.exe, which is a legitimate program. Werfault can run mulitple instances at a time, and the other instances are creating their own WAX####.tmp (The #### appears to be a string of 4 random characters generated for each tmp file) files and aren't generating these alerts. There was a single instance generating this alert, but not all of the WAX####.tmp files it created were flagged. I originally chalked this up as a false positive, but because of the explosion of alerts from this single machine, I'm now doubling back to verify before I brush it off. Has anyone else seen this type of behavior from werfault, and has it ever been a true positive? Thanks for your help and insights!

[JuliaMora15110]

Hi Anthony, I'm glad you asked this question because we have come across similar activity as well, where we get a Threat Not Quarantined alert for temporary (.tmp) files created by Werfault.exe. 

Even though we run a full scan and do file fetch, the .tmp file can't be retrieved or found and Cisco TAC can't analyze it apparently without the file in question. We still see these detections but have not seen any follow on activity like bad connections or command line. I'm guessing they are false positives but would like confirmation from Cisco Support. 

[Roman Valenta]

When it comes to events triggered by .*.TMP and what I have seen before, they are very tricky to avoid.

One of those most common scenarios are with chrome.exe and their updates or browser cache. As you know TMP files are typically created by applications to store some form of temporary data, in a permanent form rather than RAM, on your hard disk. TMP files are commonly produced either when a program can't allocate enough memory for its tasks, or as part of inter-process communication. TMP files are usually deleted automatically by their parent application (the software, game, application) which created them hence hard to catch later as they get destroyed in the process.

I also believe that on the detection that you are receiving on *.TMP files you are not able to fetch them and in most cases you might see message similar to “Quarantine Failed”

As I said earlier temporary files are placed on the machine during a installation or upgrade or some time by just simply visiting a website. It is common to see even legitimate software such as google.exe to generate this False Positive events. We always try to get our hands on these files and get them analyzed to avoid these events so if you can provide us with samples that will be great, as we will always submit them to our developers so they can "fine-tune" these detection but with out the file we can't just simply allow the detection.

As far for the quarantine-failure as I mentioned these files are usually short live so by the time we did analyze the file and based on many behavioral aspects we flagged this file as suspicious and go back and try to remove the file in many cases the file is simply not there because it gets auto-deleted by the system / program/ application . That’s why you see the message about failure to quarantine.

If this is something that keeps coming back and you can replicate this every time I would still open TAC case and ask for help from TAC and possible in-house replication.

[SEP-frustration]

I am almost certain this is a false positive. I keep receiving alerts from time to time with this exact same scenario.

[mski7861]

Normally when trying to identify if a detection is legitimate or a false positive, you can start with checking the sha against the VirusTotal database and you can search Talos.  You can also submit disposition changes for fp's.