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:
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 262 Posts ISC Handler Jan 6th 2017 |
Thread locked Subscribe |
Jan 6th 2017 5 years ago |
I checked Sysinternals Process Explorer, which I run from time to time, and which I have configured to check VirusTotal. I couldn't find a definitive answer in Process Explorer help, but it looks like there's a menu option to "submit unknown executables." I assume with this option unchecked, anything in RAM for which the hash is unknown by VirusTotal is NOT being sent to VirusTotal. If the menu option is checked, I would assume anything in RAM for which the hash is unknown by VirusTotal is sent to VirusTotal, and is then made available for paid download. As an aside, VirusTotal was owned by Google the last time I checked. [This post was by 'robv'. I don't know why it says 'Anonymous'.]
|
Anonymous |
Quote |
Jan 7th 2017 5 years ago |
Sign Up for Free or Log In to start participating in the conversation!