Last Updated: 2017-01-06 19:42:13 UTC
by John Bambenek (Version: 2)
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.
bambenek \at\ gmail /dot/ com
Last Updated: 2017-01-06 15:41:48 UTC
by John Bambenek (Version: 1)
UK Law Enforcement authorities released an alert on Wednesday about a new tactic to install ransomware. There are generally two approaches to ransomware attacks, "napalm the earth" and what I call "high-interaction" ransomware attacks that involve some layer of victim communication. Napalm the earth favors quantity over quality, where high-interaction employs some targeting, lures and direct communication with the victim. In short, the attackers have some preparation before the attack.
In this case, the attackers would cold call schools under the guise of being from the "Department of Education" and request the direct email address of the head teacher or head financial officer. Sometimes it was to send testing guidance, others it was to send mental health assessment forms. They would then send a zip file with a document file and, if opened, start the chain of infection to install ransomware. So there are several interesting things going on.
The cold call is an attempt to claim legitimacy so the recipient is not only expecting an email but that the email is relevant to them and requires their attention.
The attack is targeted to those in the administrative level in a school, so odds are if there are access controls, those individuals probably have complete rights to everything. Even if they don't, they do have access to the most sensitive and valuable information.
Once infected, the victims would have to pay up to £8,000 to recover their files.
Their are some mistakes the attacker has made that might help the attentive listener (they say Department of Education when its the Department for Education in the UK) that indicate the attacker was likely not from the UK. In high-interaction attacks, it is these subtle mistakes that provide the essential clues that something is not right. One of the most successful phishes I have seen by success rate was the infamous "fake subpoena" phish. Even there, you can recognize the use of British English which would never be in US legal process.
Other key ransomware defenses would help here too: strong backups, updated endpoint protection and up-to-date patches.
In the end, the best defense is an attentive and security-conscious user.
bambenek \at\ gmail /dot/ com