11-11-2015 07:13 AM - edited 02-20-2020 09:29 PM
Has anybody else experienced AMP blocking one of the last Microsoft updates. The file blocked is below along with threat name and hash. Also, is there a portal that gives more information on these threat names?
W32.Auto.EDEE5F.182447.in02
aaacf792b9f7596ce9888eda0a8593dd553b44a0615109fc068e1f96212c43f4
AAACF792B9F7596CE9888EDA0A8593DD553B44A0615109FC068E1F96212C43F4
11-11-2015 07:23 AM
Hi Austin,
Thanks for reaching out to us.
The following site operated by Cisco TALOS provides more information on our naming conventions for AMP.
http://www.talosintel.com/amp-naming/
Thanks and best regards,
Shyue Hong
--
Shyue Hong Chuang
Technical Marketing Engineer
Security Business Group
Cisco Systems
Email: schuang@cisco.com
Tel: +65 6317 5352
11-11-2015 07:35 AM
Can you explain what "Conviction of a file that takes place directly upon import (without Detonation)" means?
I'm a bit ignorant on this topic. Is this something that was convicted due to dynamic analysis or is the definition in a database somewhere?
11-11-2015 07:56 AM
Hi Austin,
It does look like the definition is in the AMP DB and returns as malicious based on a hash lookup without any (dynamic analysis) sandbox detonation. I did run it through the a Sandbox anyway to understand what is triggering and it does exhibit some behaviours but perhaps our malware research team may need to take a closer look. The following are a summary of the behavioral indicators flagged:
File Name of Executable on Disk Does Not Match Original File Name
Alternate Data Stream File Creation Detected
Process Modified an Executable File
Process Modified File in a User Directory
Downloaded PE Executable
Potential Code Injection Detected
Executable with Encrypted Sections
Outbound HTTP GET Request From URL Submission
Thanks and best regards,
Shyue Hong
11-11-2015 07:57 AM
Hi, Austin. Thanks for the question. This is actually a really timely coincidence, since today we happen to have several tech experts monitoring this very board for AMP questions. So the fact that we happen to have a couple of high-profile false positive incidents coming up today -- rare, but does happen from time to time -- actually gives me a great opportunity to explain how AMP works in situations like this.
Specifically for situations like this, there is the "whitelist" feature. Any time you find something that AMP classifies as a threat, but that you know to be benign, you can immediately resolve it via Application Control > Whitelists. Create a whitelist and add the SHA-256 of the file in question, and your AMP deployment will not convict the file.
Cisco works very hard to avoid falsely convicting files, but like I said, accidents and mis-classifications will happen occasionally. Our product has been built with this reality in mind. Our Talos team should have the underlying issue corrected soon, but you have complete control yourself in the meanwhile.
11-11-2015 08:09 AM
That's really good information. I was aware of the white list capability but was searching for a definite answer before doing so. My searches online didn't return any info like I expected due to the high profile nature.
Furthermore, I believe wsus got the update anyway via https. Immunet(clamAV) on my PC responded shortly after with some quarantined items. I'm not 100% sure that they're related as the filenames are different but I can post that information if you're curious.
11-11-2015 08:17 AM
Yes what a coincidence.
We started getting several false positives yesterday including Google Chrome updates, Internet Explorer updates... we were told that the developers are working on it.
Patrick
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide