In the old days (and hopefully still today), malware researchers used to securely encrypt their virus collections using a tool like PGP to make sure that it didn’t fall into the wrong hands en route, and could only be decrypted by the person to whom they intended to send it.
Today, however, it’s not uncommon for an anti-virus company to ask a customer who thinks they have a malware-infected file or a false alarm to send it into their labs or support team, zipping it up with a password of ‘infected’.
The reason why a security firm’s team might ask you to submit a sample in a password-encrypted ZIP file is so that no anti-virus protection between your computer and theirs intercepts the file transfer, determines it is malicious and blocks its delivery.
More often than not the same password is used: “infected”. It doesn’t really matter that the password is a dictionary word, or easily guessed. The point is to prevent any automated systems from looking at it.
However, that choice of password may have to be reconsider if security researcher Brian Baskin is correct.
Baskin has blogged that he recently discovered his attempts to share password-protected ZIP files containing malware samples have failed.
The common factor? Baskin uses the password “infected” and the Gmail webmail service.
It doesn’t appear that Google is cracking every password-protected ZIP file (which would send shivers down the spines of those of us who are privacy conscious), but instead that it has hardcoded the ability to try the password “infected” on ZIP files.
Quite what the reason is for that is anyone’s guess.
But maybe it’s time to use a different password when submitting your samples to security companies.
Well, Google bought VirusTotal.com a few years ago, and many still wonder why… perhaps this new move has to do with it? Would be such a surprise for Google to launch it's own AV solution?
BTW, AV's could send the file encrypted with PGP, using a passwordless key. Or a random password, and send the password on some other email (privacy isn't a concern in this scenario).
Cheers!
VirusTotal says (in a comment to the linked post) it's got nothing to do with them.
There are a 1,000 ways around this of course.
I think scanning password protected ZIPs would be somewhat acceptable if a certain malicious spam campaign sends attachments with a fixed password. Perhaps an over-zealous programmer wasn't really aware of the use of 'infected' to send known/suspected malware around.
My theory is that a back-end antivirus that Google's using may have a signature for certain specific .zip files that have the password "infected". In other words, the hash of that encrypted .zip file got added to a malware signature database.
Specifically for this reason, antivirus software shouldn't flag .zip files with the password "infected" as infected, but I've seen it happen before.
Alex Petit-Bianco, evidently a Google Antivirus Infrastructure representative, replied to Brian Baskin's blog post:
http://www.ghettoforensics.com/2014/02/google-actively-scanning-malware-emails.html?showComment=1392834408425#c5605856553471851540
It appears that my hypothesis (which I detailed more thoroughly in an earlier comment on Brian's post) was more or less correct, or something very similar was occurring that produced the same outcome.
It's not exactly clear what was happening because of seemingly conflicting statements from this representative, who said that "one of our third party software components was checking for encryption using 'infected.' [sic] as a password" and "it decrypted a limited set of zipped payloads in attempts to search for malware." Why only a limited set? And I've never seen antivirus software with a toggle feature to try looking inside .zip files with a predefined password (although it's certainly possible that some antivirus may have that feature). It seems more likely that signatures were added to that antivirus software for the hashes of specific encrypted .zip files, as I proposed.
Most a/v teams actually REQUIRE virus samples (and false positives as well) to be sent as zip files with password "infected".
If you read their support pages it is a de facto standard if you have to deal with a/v companies, anf in my experience they will simply discard any out of standard file (different format or password), probably because of the very first support step is automated. A nd in my experience some of them does not even to mail you back for reporting it, as i you were a spammer.