Job opportunity: DDoS Research Assistant for the Cambridge Cloud Cybercrime Centre

The Cambridge Cloud Cybercrime Centre is seeking a Research Assistant for DDoS measurement. The Centre’s overall objective is to create a sustainable and internationally competitive centre for academic research into cybercrime.

ThreatSTOP has sponsored this effort because we believe this type of research benefits the entire security community. More information about the job opportunity below, and here.

Job Ads: Cloud Cybercrime Centre

The Cambridge Cloud Cybercrime Centre (more information about our vision for this brand new initiative are in this earlier article) now has a Research Assistant position to fill:

…and with special thanks for the generosity of ThreatSTOP, who have funded this extra position:

  • We seek someone to work on distributed denial-of-service (DDoS) measurement. We have been gathering data on reflected UDP DDoS events for many months and we want to extend our coverage and develop a much more detailed analysis of the location of perpetrators and victims along with real-time datafeeds of relevant information to assist in reducing harm. Full details are here.

Please follow the links to read the relevant formal advertisement for the details about exactly who and what we’re looking for and how to apply.

New OpenSSH Vulnerability

new vulnerability has been found on OpenSSH which is used by almost all Linux/BSD distributions, as well as many network infrastructure devices to allow SSH connectivity. The vulnerability applies to any SSH device that allows for user/password logins as opposed to shared keys.  And, from my quick review of the vulnerability, it seems to be common on almost every device that has not had password logins specifically disabled. The vulnerability allows an attacker to attempt many thousands of passwords for a user, instead of the default 3-6, before being blocked.

What this means is that any vulnerable server or network device which allows user/password logins from the internet can be remotely accessed if it has a known standard username (e.g. root or admin) and any even slightly popular password. The good news for ThreatSTOP customers is that they are protected against the scanners that will be performing this attack. The attackers who are scanning for vulnerable systems will be reported to us via our feedback loop as it reports all the devices where we blocked the attacker’s access.

Important updates to the TS Critical target list

As with many other people in the cybersecurity world, ThreatSTOP received notification today about a spear phishing campaign using some of the zero day vulnerabilities leaked from “Hackinged Team” at the beginning of the month. ThreatSTOP is happy to report that we are blocking the IOCs in that notification for all our customers who use either the TSCritical Target List or the Lists that include it – BASIC or BOTNETS – in their firewall policy.

ThreatSTOP customers who upload logs should check for outbound connection attempts to TSCritical IP addresses in their reports. Any TSCritical hit is a significant cause for concern. We are adding many Angler Exploit Kit dropper sites to this list as well as other similarly critical malware. If customers want to learn why a particular IP address is in TSCritical, they should contact our Technical Support at

Fallout from the Hacking Team data dump

Recently the Italian group Hacking Team was compromised and, according to the attackers, had 400 GB of data stolen.

While the exact method of compromise has not been published, it was discovered that part of Hacking Teams toolset involved attacks against Adobe Flash, Windows, and iOS devices. While updates for Windows are not available, an update was published for Adobe Flash, and we recommend patching, and consider removing Adobe Flash from your systems.

Related to this, is the Angler Exploit Kit which is using a Flash zero-day exploit to distribute Cryptowall malware. ThreatSTOP’s services block the droppers that Angler Exploit Kit uses, and help secure networks from intrusions like this.

External links:


ThreatSTOP’s Anti-Venom for CVE-2015-3456

A critical vulnerability identified by the National Vulnerability Database as CVE-2015-3456 or VENOM was published yesterday. It affects all KVM guests running on QEMU–a widely used emulator for virtual server hosting. This command and control vulnerability may allow a malicious user to escape guest environments and take full control of the operating system hosting. Like Heartbleed and Shellshock last year, this is a significant risk for organizations that could lead to the exfiltration of sensitive and proprietary data. Unchecked, this can impact thousands of organizations and millions of end users that rely on affected virtual machines for the distribution of shared computing resources.

This leaves many people scrambling to find a signature to block Venom’s impact. Even HP has yet to find a remediation.  ThreatSTOP’s zero-day capability prevents Venom’s impact because it successfully cuts the lines of communication between a compromised system and the invading source. ThreatSTOP customers, partners and clients can block this attack.

As with many attacks of this nature, Venom exploits a weakness in software code that has existed for years but, had gone undisclosed until yesterday. Criminals exploiting this vulnerability on a single virtual machine could gain access to all virtual machines running on the host system, and harvest sensitive data passing unencrypted through the memory of any virtual machine on the system. However, exfiltrating this data requires a means of communication between the attacker and victim. Regardless of whether the attack vector is successful in gaining a foothold, any attempt of communication to or from a known bad actor is blocked, logged and reported by ThreatSTOP. If the malware or botnet cannot receive instructions or leak information to its source, the threat is neutralized; allowing IT/IS departments the critical time they need to fully remediate this new zero-day threat.

We recommend that any of our customers with Virtual Machines, especially large enterprise and hosting provider partners, update their ThreatSTOP policy definitions to include dynamic objects for critical and emerging threats, Unix servers, scanners, web attackers, botnets, malware, DShield lists, prohibited countries, and anonymous proxies. Additionally, ThreatSTOP recommends that all virtualization users apply the patches provided by the various Linux distributions to all Internet facing hosts as soon as possible.

Attacks like Venom, Heartbleed and Shellshock continue to escalate in frequency, rapidity and severity. Whether or not this particular bug has affected your systems already or not, it is only a matter of time before one does. Companies need the quickness and flexibility to protect itself in the critical hours, days or weeks before patches or signatures are developed and distributed.  The best way to achieve this is by leveraging ThreatSTOP’s collective security intelligence of known bad actors to stop them from “calling home.”

ThreatSTOP blocking Superfish

At ThreatSTOP we have been reading about the Lenovo/Superfish adware security hole with amazement. Not so much at the enormous gaping hole that has been discovered (sadly that seems to be SOP at too many places) but at the way that the various parties involved have completely failed to understand that they have created such an enormous gaping hole.

Given that the creators of the hole seem to be unclear on why they have caused a problem we now believe that it is worth blocking all connections to and its associated adware domains (e.g. ). The following IP addresses have been added to our system in the TSCriticalG feed that is present in most user policies either directly or because it is included in the BASIC policy:


This will not stop the gaping hole (which seems to get ever more gaping as people look at it more deeply), but it should help our customers determine which computers in their network are vulnerable because they will be the ones with dozens of connections to these IP addresses. Once these devices have been identified it is critical to both uninstall the software and verify that the offending root certificate(s) is removed from them.

Ramifications of the Anthem hack

The Anthem hack has been getting a lot of news coverage because it is one of the larger data breaches in recent years. Of course it is in fairly good company (Sony, Home Depot, Target spring to mind) but it has some features that are unique. These features mean that the impact on those whose data was stolen is probably less than some other hacks, but that doesn’t mean people can relax.

All the information so far seems to indicate that the hack was undertaken by a state sponsored group (see link above and also this one) which means that the hackers probably aren’t going to sell the details on the criminal underground for identity theft or other similar purposes. That’s good, it suggests the victims won’t discover that someone else has filed a tax return on their behalf to fraudulently claim a refund or do some other fraud on them. Unless of course they are the target of the breach.

Of course people who work in positions that may be of interest to spies (or relatives of such people) definitely DO need to be on the look out for carefully crafted spear-phish emails that convince them to open infected word documents or similar. Since the hackers have presumably got the details of many members of the same organization they will no doubt find it relatively simple to come up with a suitably plausible email from someone who seems to be a colleague.

On the other hand that doesn’t mean that the rest of the world can relax. There are already reports of scammers sending emails to anthem victims that try to trick them into handing over more details (though at least one of these turns out to be some good guys deliberately sending an email to try and educate) and there will no doubt be more.

The bottom line is that everyone should treat emails from “Anthem” or any of its related names (Wellpoint, Blue Cross etc.) with extreme suspicion and should NOT click on the links. It would also, undoubtedly help to have policies that block access to IP addresses in strange places, just in case.

« Older Entries