ThreatSTOP releases new reporting features

September 11, 2011 by Leave a comment

This weekend we have put our new log-parsing and reporting code into production. The new code significantly increases our speed of log parsing (by about two orders of magnitude) and it provides a lot more help to help our users research what particular blocked threats were caused by. As product manager I am very pleased to say that it is a massive improvement over the previous stuff but, for our existing users, there are a couple of niggles.

The first is very simple: please clear your browser cache before visiting the reporting section of the ThreatSTOP website because otherwise it will look very strange as there are clashes in the javascript/css code. The second is that one of the new features – filter report by feed – is not working consistently on the production server/database, although needless to say it worked and still works flawlessly on our test servers. We are, of course, working on identifying why it does not always work, but in the mean time be aware that if you do filter by feed and get 0 responses this may not be accurate (if you get a non-zero number then this will be correct, the issue is that sometimes we get 0 results back when we should have had some) Update: The search by feed only works with logs parsed by the new log parser system and thus is unlikely to work for logs uploaded before last Friday.

Ok beyond the niggles what will our customers notice? the log parsing code is effectively invisible, but the recent delays between log submission and being able to view reports should now be gone. On the reporting front the changes are rather more obvious:

ThreatSTOP New Report SummaryThere are some new choices to filter data by and, for users with multiple devices, we have improved the information in the pulldown that allows you to choose the device. You can filter the results based on a specific feed or IP address and can use the “*” wildcard when searching for an address. Examples are “192.168.*.*” and “192.*.100.*”. Also we note the last time we processed a log in addition to the summary statistics of the report.

Improved Device Pulldown (shows device name, ip address and type) New feeds filter pulldown.

When looking at the detailed reporting pages users will immediately notice that IP addresses are all underlined with a dotted line. Hovering a mouse over a particular IP address brings up a menu of drill down options.

The top link on the drilldown list (Research) is a report on what we at ThreatSTOP know about the address, that is to say it is essentially the same as the what we used to report in a separate popup window. The astute will note that the new popup window has options to allow the user to add this ip address to either a custom block list or a custom white (allow) list.

New "Research" popup

Clicking on the Add to White list button leads to a dialog like this (The block list button has an equivalent one):

Add to white list dialog

The next item down (Domains) is a popup that displays a report from the SIE Passive DNS reportpassive DNS database about what DNS queries have resolved to that address. This is generally more useful for outbound analysis where the list can identify a phishing site or a known botnet C&C host domain name. Although the example above shows just three names, frequently these ip addresses will have been used by thousands of different domains (note that we do not display more than 10,000 domains).

The remainder of the links open external windows to other (malware) research sites that we find useful in identifying information about a particular ip address. If anyone has other sites they find useful we will be glad to add them too.

All these reporting changes are also added, where relevant, to other sections of the website such as the check logs feature.

Finally – if you are still reading this far – here is a worked example of how to use the new features to confirm a bot C&C host and thus identify infected machines on your network. This is a real customer but the internal infected addresses have been obfuscated to preserve some anonymity. First run a report for recent outbound traffic filtering on the “BOTNET” feed and then click on “outbound connections” list.

Botnet reportNext click on the “Research” tab for the Destination IP to learn that this address is a known C&C host:Botnet-C&C identifiedThen confirm by checking on the Domains link to see what sorts of names have been resolving to this address:10k domains” src=”http://threatstop.files.wordpress.com/2011/09/ts-report-10.png” alt=”Botnet C&C with >10k domains” width=”416″ height=”590″ />Finally click on say the McAfee link to confirm that this is not just a figment of ThreatSTOP’s imagination. Now that it has been confirmed that the IP address is bad the source IP addresses (192.168.x.51 and 192.168.x.52 in this case) should be noted down and the computers using them identified for immediate remediation.

Filed under News/Announcements, ThreatSTOP in use Tagged with , , , , ,

ThreatSTOP blocking possible Conficker variant

December 31, 2010 by Leave a comment

Over the last couple of days we’ve seen an increasing number of outbound DNS queries to ip addresses on our block lists – principally to ones on the DShield 4000. Since the destination servers are frequently in China and the subscribers have little to do with China this looks unlikely to be genuine traffic. It is however somewhat suggestive of Conficker and other similar fastflux DNS malware which “call home” via a DNS lookup to some randomly generated subdomain of an otherwise apparently genuine domain. The DNS lookup resolves (usually) to a fastflux intermediary that communicates with the botmaster, The DNS server itself is generally not ‘bad’ per se but it will be under the control of the cyber crooks because they have to feed it the zone changes so frequently and this level of activity would raise a flag in any legitimate DNS hosting service.

By blocking these DNS lookups the malware is unable to call home and thus it is effectively neutralized. Unfortunately that does not always mean it is simple to identify the infected machine for remediation. In many cases the source IP address of the blocked lookup is the network’s DNS server and thus it is necessary to analyze the DNS server logs for SERVFAIL entries and determine what IP address made the query that led to this.

However sometimes it turns out that the compromised machine makes the DNS lookup itself. In this case the malware will have modified the machines IP stack so that it queries the criminal’s DNS by default. This, needless to say, is a wonderful way for the crooks to do man-in-the middle attacks to harvest login details.

ThreatSTOP’s blocklists include the known criminal DNS servers and hence our subscribers are protected from accessing these machines, whether directly or indirectly via the subscriber’s DNS server. Since the hosts are on the DShield list (and we will also add any that aren’t to our emergency feed over the next few days) all subscribers – even ones using our free ‘community’ edition – will be protected.

 

Filed under Specific Threats, ThreatSTOP in use Tagged with , , , , ,

Introducing the BOTNETS block list

September 1, 2010 by 1 Comment

Recently I blogged that we had added the abuse.ch ZeuS Tracker botnet list as a block list source. Last week we confirmed that it worked by seeing that our customers had connections to addresses on that list that were blocked by ThreatSTOP, and which came from systems later confirmed to be infected.

As a result, and because botnet activity seems to be on the increase in recent days, we have now created a dedicated “BOTNETS” block list that includes the addresses from ZeuS and from our other botnet feeds. As of a few minutes ago the entire feed is 2097 ip addresses of which about a fifth (431) are from the ZeuS feed. These numbers are going to vary over time as we will update this list every two hours.

It is critical to note that our list has success because bots are extremely hard to detect using traditional methods – this report from last year states that antivirus programs are not good at all:

” installing an anti-virus product and maintaining it up to date reduces the probability to get infected by Zeus by 23%, compared to running without an anti-virus altogether. The effectiveness of an up to date anti virus against Zeus is thus not 100%, not 90%, not even 50% – it’s just 23%.”

Because of the way the ZeuS bot “calls home” – DNS lookups to any one of (at time of writing) 1431 domains, most of which are so-called fastflux domains that change the addresses they resolve to every few minutes, followed by encrypted (HTTPS) communication with a C&C host – usually proxied – network level protection that works on signature analysis is also ineffective. It may be possible to identify that an SSL session with youwillfindtheresomethinginterestinf.com or dadadsaaa.wapdodoit.ru (two of the domains currently used by ZeuS) is suspect, but how about yourgoogleanalytics.com (another one of the currently active domains)?

The simple answer is that no IPS, deep packet inspector or web traffic analyzer will be able to block these communications in time either, all they may do is raise an alert that some traffic just left the organization and while you may manage to detect and remove the bot after it has called home (though as this article notes ZeuS changes names etc. frequently so that can be hard).

The statistics above also show something else. ZeuS uses over 1400 domains at any one time but those domains resolve down to just 400-450 ip addresses. Any modern firewall can block 450 or so addresses, indeed that list is small enough that routers and layer 3 switches could too, but blocking DNS lookups to 1400 or more domains is much harder since it is difficult for a firewall to determine that a particular ip address is one that is resolved by a ZeuS owned domain and because the name space of domains is so much larger than the ip address space.

Any ThreatSTOP subscriber can and should use our new BOTNETS list on firewall that has significant outbound traffic to the Internet from users behind it. If you aren’t yet a ThreatSTOP subscriber then this is yet another reason why you should be.

Filed under Specific Threats, ThreatSTOP in use Tagged with , , ,

No We Don’t Need to Live With Infection

August 14, 2010 by Leave a comment

A recent column by John Dix in Network World paints a rather depressing picture of the state of the Internet when it comes to malware. Mr Dix points out that there are millions of compromised computers (bots) out there and that while network security people can block some of the worst there are a lot that they cannot block because these other threats are quiet enough to not be detected by current IPS/IDS etc. devices. His essential claim is that we just have to assume that every network is penetrated and/or vulnerable to penetration by cyber-criminals. The article quotes various security professionals as stating that the dangerous bot attacks are stealthy and slow moving with the attack gradually building up to its most serious level over a period of days or even weeks.

He indicates that the Zeus botnet is one of the ones people can protect against which is somewhat ironic as just a day later The Register and others reported a major data breach caused by Zeus which seems to have netted about $1 million from some UK banks.

The latter article illustrates clearly the weak point of these attacks – the need for the infected machines to “call home” to the command and control (C&C) host to get instructions and to report passwords and other sensitive data. And this, combined with the slow motion attack profile that Mr Dix’s experts describe, is why he is wrong. The various malware research groups such as Shadow Server, the Malware Threat Center and so on are able to identify the currently active C&C hosts for almost all botnets and to identify networks which are likely to be used as a base for bot controllers. At ThreatSTOP we build block lists of these IP addresses that our subscribers can use to stop and log any “call home” attempt.

One of our subscribers, who discovered a botnet on his network thanks to ThreatSTOP, was able, just recently, to take a long vacation for the first time in years because now there are no more than a handful infected computers on his network at anyone time instead of upto 1000. Moreover the process of downloading the list of infections each morning and remedying the compromised systems is now something that he can leave to a junior underling.

ThreatSTOP subscribers do not need to concede the network to the bot herders and our service meets the requirements of proactivity and actionable intelligence that Dix and his experts say is the key to the future. With ThreatSTOP there is no longer any need to live with knowledge that your network is infected.

Filed under Technology, ThreatSTOP in use Tagged with , ,

More on the Stuxnet Siemens Exploit

July 21, 2010 by 2 Comments

Yesterday I guest blogged at Control Global about remediation steps for process automation networks and I’ve been thinking some more about the topic.

I suspect that while this particular attack seems to have been deliberately designed to attack specific Siemens infrastructure using known Siemens weaknesses (hard coded passwords, inappropriate admin rights etc.) there is absolutely nothing about this that means that it applies only to Siemens – indeed recent news indicates that a new payload is being delivered that may do different things.

The key here is that the payload, and new variants of the worm spread because the worm can “call home” so while the initial attack seems to have done nothing to systems that were not Siemens WinCC devices apart from spread, there is no reason to assume that this will continue. Thus, as I said in that post, and as we say repeatedly on this blog, it is critical that organizations reconsider the “default allow” rule for outbound traffic that is in probably the majority of firewalls. Sure some firewalls block traffic out except on certain ports (e.g. HTTP), force traffic to pass through proxies, or block traffic from certain core data center servers/networks but very few actually look at the destination of traffic leaving the network.

There is an argument that says that SCADA devices should never be able to connect to the Internet and this is in many cases true. However the way that buildings have been wired up and ip networks/addresses configured it can be almost impossible to tell whether the computer trying to connect to something on the Internet is in fact a piece of automation equipment or, say, the laptop of a technician who needs to download a product manual to do maintenance on the automation equipment. Best practice for IT departments is of course to separate networks for general use from those for specific critical functions and to not allow traffic from the critical networks to leave the building. However, unless these networks are blocked from communication with anything else – the “airgap” firewall – there remains the risk that these devices can be controlled by external hackers. If, for example, an engineer remotely logs into a device and controls it from his desk – something that I know happens in a number of places – then if that engineer’s desktop computer becomes controlled by the hacker the hacker has access to the devices as well, albeit indirectly.

Hence, also, another reason why relying on the fact that the current versions of a worm are specific to certain industrial devices is to allow one to be lulled into a false sense of security.

On a slightly different note. In a number of cases people have wondered why Siemens uses known default passwords. Partly this is down to the fact that the products, and the product mindset, were for a closed, secure environment without access to the Internet. Partly it is down to the fact that even the slightest change could cause something to go wrong. This also explains why patching industrial devices is something that is not done frequently. If, for example, you are controlling a process in a chemical plant, then you probably cannot reboot the computer except after a laborious shutdown sequence that takes place once a year because doing so costs millions of dollars. Moreover if the patch turns out to have (say) a memory leak that manifests itself after 200 days, you are in big trouble because on day 201 you lose control of the chemical process and that may well cause a leak, explosion, fire etc. If a system is tested with user “X” password “Y” and runs successfully without falling over for a year then why take the risk that user “Xx” or password “Zz” will work too. What happens if there is a garbage collection failure that causes a few Kb to be lost each time the device remotely logs in and which is partially dependent on password length? if your new password is longer then that might be just enough to mean that the system runs out of memory in 340 days instead of 370, and thus that it crashes on December 15th instead of making through to the scheduled reboot on Dec 27..

Putting all this together, the simplest way to minimize the risk for the current network is to stop all computers in the network from “calling home” when infected rather than just concentrating on the SCADA ones. This gives you the breathing space to consider re-engineering your network so that critical devices are more effectively isolated.

Filed under Specific Threats, ThreatSTOP in use Tagged with , , , ,

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: