AMP Threat Detected/Quarantine Failure

[kevdpc]

I have a Windows file and print server which hosts roaming profiles. AMP frequently alerts for Threat Detected and then Quarantine Failure for files in the Downloads folder of roaming profiles. For example, an alert shows...

File full path: D:\roamingprofiles\username\Downloads\{89d97342-2cbe-49eb-96d2-6c0424962415}.tmp

While a file is downloading it will have a temporary name and then when it's finished it will change to the actual file name. I believe that AMP is detecting the temporary name as a threat and then quarantine fails because the file name changed so the "threat" file technically doesn't exist anymore.

I guess I'm just looking for confirmation about what I think is happening. Is a file name like {89d97342-2cbe-49eb-96d2-6c0424962415}.tmp a common name for a file that's in the process of being downloaded?

[Troja007]

Hello @kevdpc,

let me answer carefully.... if there is a file detected, AMP generates two events. One for the detection and a second one if a file has been quarantined or not. This information is also processed by the Backend Engines, e.g. to generte Cloud IOCs.
Detection: the connector hashes a file, so the file name is just an additional information. Even, if you are renaming a file, this is just an entry in the File Allocation Table of the File System.

If you see this event frequently, you may inspect the systems what is going on. 

You may share the hash256, otherwise it is hard to say anything about the file.

Greetings,
Thorsten

[kevdpc]

Thanks Thorsten. Are you saying that the filename doesn't really matter and my belief is incorrect? And that the connector hashes the file and identifies it by that hash, regardless of the file name? If that's the case, and the file rename wouldn't affect anything, then perhaps this file simply appeared and then disappeared. That would make sense since it does have a .tmp file extension.

How should I go about investigating this if the "threat" file is gone?

[Troja007]

Hello @kevdpc,
you are right, the file extension does not matter. In addition, the connector uses an own part of an engine for file type detection. Such messages can appear, if the file is just available for a very short time, OR, the endpoint does not have exclusive access rights to the file. E.g. file lock from the application.

What i meaned is, if such malicious files are seen again and again, it makes sense to investigate to figure out the root cause.

If a file is not available any more, you see the hash in the AMP console (available in the event). Now you can use Device Trajectory, File Trajectory and Threat Response to determine what happened.

Greetings,
Thorsten

[Brisbee]

I saw a new implementation where AMP was installed on a workstation with an existing anti-malware product as part of a plan to fully migrate to AMP.  The AMP policy wasn't properly configured to play well with the other AV.  AMP would occasionally detect a threat. The other AV would quarantine it before AMP.  AMP would reported two events: 1) detection and 2) failed quarantine.

We could verify this in the logs of the other AV product.  I also saw it in the file trajectory where the  mcshield process deleted the file.