SANS ISC: Internet Security | DShield

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

Like many security researchers, I employ a variety of OPSEC techniques to help detect if I have been targeted by something for whatever reason. One of those techniques I use in Virustotal is basically a vanity Yara rule that looks for a variety of strings that would indicate malware was specifically targeting me or some data was uploaded that references me.  Virustotal Intelligence is a useful too for doing that and many researchers have paid for access which allows you to also download samples that have been uploaded.

Recently, my vanity Yara rule has been bombarding me with samples that are flagging on some of those keywords.  What's interesting is that those files weren't malware or anything even capable of being infested with malware.  It turns out they are actually SQLite databases of a cookie story (and flagging off some relevant domains I'm monitoring for).

Here are screen shots of the Hex and Strings dump from Virustotal intelligence for one of the files:

There isn't anything special about the database per se (except there are some domains in there I care about), what makes this interesting is that someone was sending ALOT of SQLlite cookie databases to Virustotal making those cookies available for anyone with a paid account to download.  Plenty of tracking cookies and things of minimal consequence, but there were cookies for Gmail, Facebook, etc and as many readers know, those cookies never expire, meaning operational login credentials are out in the wild (the example file I chose above, if you could figure out the hash, only has cookies from 2011).

This begs the question of why these files were uploaded in the first place.  This goes back to research I presented at THOTCON in Chicago last year (a great conference, you should go). You can read the slides here. What that research showed was there were tons of SSH private keys, GPG private keys (most of which had no passwords), config files with database authentication information and so on.  All of those files are text which have no reason ever to be sent to a sandbox (you can't execute text).  The same is true for a SQLlite database, what exactly are you going to sandbox?

The reality is, there is some automated solutions out there that submit EVERYTHING they see to Virustotal and use that information to make security decisions. It's been known this happens and Virustotal doesn't like it one bit. For organizations, however, that are using those solutions, everything that passes through that solution is being sent to Virustotal and able to be downloaded by many researchers, and not just myself.  That means if you have sensitive documents that you don't want others to see, your security solution may be sending it automatically to Virustotal as part of routine scanning (call it "machine learning" if you like) to see if it's bad but in so doing, they are exposing and sending your sensitive information to third parties. This includes sensitive documents (which have some reason to be sandboxed due to macros), but in many cases it's just scanning things no reason to ever be sandboxed.

The takeaway for your organizations is to check if you have security tools that are sending your internal files out to "the cloud" and then making it available to others.  There is no felony if I download trade secrets from my competitor if they are freely available on Virustotal. Good news is that it's easy to look for (search for tons of things being sent to Virustotal). The bad news is, despite the dust-up last year, it's still happening.

--
John Bambenek
bambenek \at\ gmail /dot/ com
Fidelis Cybersecurity