Monday, April 7, 2014

OPSEC vs. virustotal

So you just found malware running on one of the systems in your enterprise.  Do you upload it to virustotal.com to see how many antivirus vendors detect the malware?  The answer to this question is an overwhelming NO!  Don't do it. The temptation is understandable, but just what are you giving away to your attacker?

Anything you upload to virustotal.com (or any other public malware site for that matter) will eventually be shared to other antivirus vendors.  What happens if the attacker created a sample for your environment, suppose with a unique hash?  Suppose that you work at SuperMegaBank and you have been targeted by Eastern European bad guys.  Because they don't like being caught, they create a new piece of malware, with a unique hash, just for you.  When you send this to any public site, it will eventually get back to antivirus vendors (in fact, eventually all of them).  Any decent attacker has a lab with a number of AV products.  When the antivirus vendors incorporate your sample into the updated definitions, your attacker will know they've been found out.  Unfortunately for them, by this time you have removed the malware from your environment and they are back to doing initial access operations.

The more immediate concern is that most sites have a search feature.  Using this feature, anyone with API access (or in some cases just a web browser) can determine whether a given sample has ever been submitted or analyzed.  The problem here is that as soon as you upload the sample, anyone searching by hash can determine that the file has been analyzed.  This of course includes your attacker.  Obviously, if your attackers know that you are onto them, that's not a good thing.  They may change out their tools and/or go to ground.  That leaves you holding the bag, trying to find attackers that are now doing their best to hide from you.

The only question now is "do attackers really do this?"  I can't say for sure, but I've observed what I consider to be some pretty strong circumstantial evidence.  I've worked several incident response cases where the first responders uploaded samples to virustotal.com.  In every one of these cases, the attacker went to ground.  This left us with a much harder task of detection and remediation than we would have experienced if we'd only kept the sample to ourselves.  Is virustotal.com a useful tool?  Absolutely, I love it.  But is it appropriate for uploading samples in an incident response?  Absolutely not.  Period.  Practice good OPSEC.

11 comments:

  1. Agreed, that's why it's important to design and implement your on lab to perform your in house malware analysis and reengineering.

    ReplyDelete
  2. Absolutely! I tell advise all my clients to build some in-house capability and have contacts ready to outsource the overflow to trusted parties.

    ReplyDelete
  3. Something not mentioned is the potential for the exposure of sensitive information (domains, network paths, credentials, etc.) when samples are arbitrarily uploaded to public sites, like VT.

    Something else to consider is that if your detection mechanism is based on hashes, then you're sitting on the bottom of the Pyramid of Pain. This means that your detection mechanism is trivial to bypass...flip a single bit in the PE file where the execution of the tool isn't affected (like in the compile time) and it's game over. The same tool/malware can be used again, and not detected.

    In every one of these cases, the attacker went to ground. This left us with a much harder task of detection and remediation than we would have experienced if we'd only kept the sample to ourselves.

    If the detection mechanism was based on the use of hashes, I am wondering how you knew that the bad guys "went to ground" after the samples were uploaded.

    ReplyDelete
  4. Harlan, our detection wasn't based on hashes. Agreed that doing detection that way puts you at the bottom...

    We found evidence that the attackers began upgrading their backdoor in the network a few hours after the sample was uploaded to virustotal. We hypothesize that they were performing regular searches against virustotal for their own tools and found that we were onto them. So it was the attacker's counter detection that was based on hashes, NOT our detection.

    ReplyDelete
    Replies
    1. Jake,

      Sorry, I guess I misunderstood, "This left us with a much harder task of detection..."...

      Delete
  5. Take a hash of the malware. Search VT for the hash. In all my work with VT, I've not seen that they report how many times a given hash has been searched for, but I imagine they have that data. If you're really assuming breach, assume VT is also breached, how does that affect your IR TTPs?

    To Harlan's point about flipping a single bit, this is one place where Authenticode hashes and/or SSDeep can come in handy.

    ReplyDelete
    Replies
    1. I think that the direction should be more along the lines of what David Bianco talked about in his "Pyramid of Pain" blog post. If you get to the point where you're detecting TTPs, your detection process has matured to the point where you're able to detect when those TTPs change.

      One of the things that is very often missed when malware if found on a system is the opportunity to discover how it got there in the first place. I've found pretty significant changes to the "accepted" or assumed TTPs, based on analyzing more than just a malware sample.

      Delete
  6. Man, this is great brain spillage! Keep it going!

    ReplyDelete
  7. Dave, you are correct. They don't show how many times a hash has been searched for. If you want to just search for a hash, you can do so without fear if you presume that VT isn't compromised. Personally, I think that's a pretty fair assumption.

    However, when you upload the sample, everyone who bothers searching can see that the sample has been found.

    As to your point of SSDeep, I agree that it's useful for detecting nearly identical samples. Yara is also useful for malware classification. But VT isn't really a malware classification tool (unless you consider the AV vendor labels "classification").

    ReplyDelete
  8. If you are so worried about attackers checking a given hash against VT, the trivial solution is just to a change a byte of, for example, the DOS stub (E.g. This program cannot be run in DOS mode -> This pr0gram cannot be run in DOS mode). This makes the hash differ but the detections will not change, AV signatures will still match. Don't really understand the concern when you can do something as simple as this to avoid the scenario you mention.

    ReplyDelete
  9. Yes I agree. But more because Virus Total is not very effective and does not seem to pick up even half of other similar engines. Also if your attacker is that lame and malicious you will have already felt his ill way before you notice the malware.

    ReplyDelete