Nitol Takedown: How ThreatSTOP can help identify affected machines.

September 21, 2012 by Leave a comment

There’s a lot of noise out there about “Nitol” and the takedown. What, exactly, does that mean to you?

Before we get into that, let’s do a quick re-cap on what has happened:

Microsoft received a court order to allow them to redirect all subdomains of a dynamic DNS provider called 3322.org. This enabled Microsoft to block tens of thousands of domain names that were being used to serve up malware and commit cybercrime. Now, instead of DNS requests for anything in 3322.org getting resolved by 3322.org’s servers, they’re being resolved via Microsoft’s security group. This applies equally to any domain that is not hosting cybercrime that happened to use 3322.org so that they could provide dynamic DNS (required in order to run your own web or mail server if you have a dynamic IP address, as with a home Internet connection).

It was only a matter of time before action was taken against 3322.org, as it was widely known as a popular haven for Malware authors and unresponsive to researchers and operators seeking to have malware domains shut down.

You can read more here:

Official Microsoft Blog

Krebs on Security

Full Set of Legal Docs

Now, what does this mean for you?

For starters, Microsoft has been granted quite a bit of power…and any connections from your network to anything in 3322.org and its subdomains will either be resolved, or not, based on what Microsoft decides. Currently, it appears that Microsoft’s approach is only intercepting some of the domain names, and recursively resolving the rest through the actual 3322.org nameservers.

In theory, this should only interfere with the malicious domains and do nothing to the legitimate ones. In order to be effective, the list of domains Microsoft is using MUST be accurate (ensuring no false positives), and the domain names Microsoft is intercepting must be the only names the malware uses. The first case seems to be true, but the second is problematic, as it has been our experience that most malware uses multiple ways to call home, and usually multiple domain names.

Gunter Ollmann of Damballa has a very good post discussing the issue with this sort of incomplete takedown.

There have been some problems with MX (mail exchanger, how the Internet routes e-mail) lookups, which have resulted in e-mail to legitimate sub-domains of 3322.org not being deliverable.  Microsoft is working to resolve them. Aside from this, there are many policy issues involved that are under discussion, but out of the scope of this post. If you want to learn more about that, Suresh Ramasubramanian has a very detailed discussion in his blog post.

So, what is ThreatSTOP doing about it?

Currently, ThreatSTOP is propagating a block on the sinkhole that Microsoft is using to trap the botnet domains.

Those IPs are in our Sinkhole feed, but we can’t publicize exactly which ones, due to reasons of confidentiality.

What this will do is stop connections to sinkholed domains from completing, and give you a log of when a system in your network tried to connect to those domains. The IP address that will show as making the attempted connection in your ThreatSTOP reports is the compromised endpoint.

If you are not a ThreatSTOP subscriber, you can use our ThreatCHECK tool on a system you are concerned about, or log all connections outbound on your firewall, and use our Sinkhole Check tool to see if you had any connections to known Sinkholes.

If you see connections to anything on our Sinkhole feed, you should consider that system as infected. Systems that are infected with Malware should be RE-INSTALLED. Cleaning can never guarantee removal of all malware, since, once they get control of a system, cybercriminals install custom software that antivirus may never get a signature for. If you want to know exactly WHICH malware a given sinkhole represents, please contact us.  If you need help, we’re here for you! Don’t hesitate to contact our support.

ThreatSTOP is actively involved in the security community, and works tirelessly to keep our data up to date, so you can stay ahead of the latest threats such as this one. If you aren’t familiar with ThreatSTOP then consider a trial on your firewall today.

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

Criminals don’t follow the rules

July 12, 2012 by Leave a comment

If you are a criminal and trying to steal things then breaking the law in other ways is unlikely to concern you. To me such a statement seems obvious, but apparently it isn’t – and I’m not just talking about cyber-criminals here.

The classic example in the physical world is the bank robber, who not only breaks the law by robbing the bank but also commits firearms offenses by being a felon in possession of one, violent crimes up to and including murder, traffic offenses in the getaway car and so on. The robber doesn’t care whether, as a result of running a red light, he causes a major traffic accident (as long as he’s not in it) – indeed he may actually like that because it slows down the pursuit.

A moment’s thought shows that the same applies to the cyber-criminal hoping to steal money using your electronic banking credentials. Just as the bank robber neutralizes the guards, the malware that infects your computer disables your anti-virus. And like the way the robber ignores traffic rules, the malware is not going to necessarily bother about using the nameservers, web proxy, configured default protocols etc., that have been set up to make your job as the defender easier. Moreover it certainly isn’t going to be concerned about obeying protocol conventions to call home and get the data back to the criminals. For example, it will pretend to be posting an image to google or yahoo but will actually not use a google IP address (or upload a real jpeg).

The problem here is that a lot of security tools work like traffic lights. They slow down and inspect the law-abiding genuine data flows but don’t do anything about the outlaw ones that, in one way or another, ignore or circumvent them.

The only way to stop them is the cyber equivalent of the roadblock that inspects every vehicle trying to go past and which is placed in such a way that all traffic has to go through it. In computer networking the only device in that position in the overwhelming majority of organizations is the Internet connected firewall.

Tools that don’t see every packet inbound and outbound can only stop malware that doesn’t make the simplest efforts to evade detection. Engineering around any type of protocol specific inspection, directory service, or other resources used by normal traffic is relatively trivial. In fact, in much the same way that the bank’s CCTV system shows the bank-robber’s masked face to investigators after they have fled with the cash, these systems might warn you that a particular computer is infected but they don’t do much about stopping the malware on the computer from calling home. They just make the criminal have to be marginally aware of the usual countermeasures – a bit like how the CCTV means the robber has to wear a disguise.

In the physical world the people that really care about security (e.g. the military) have adopted a policy of ensuring that everything going in and out of a secure location goes through a checkpoint and it is scanned (metal detector, ID check etc.) as it passes through. In theory, organizations have the same policy for the Internet when they place a firewall on the border of their network. In practice, these firewalls work more like the border between the US and Mexico: they are very restrictive on things coming in, but make only cursory checks of anything leaving, if at all. As anyone who has sat at the San Ysidro crossing for hours coming back from Baja knows, full scanning (deep inspection) leads to large increases in latency for legitimate traffic. The result is that, in most cases, organizations elect to skip it for most outgoing traffic and almost all incoming traffic that is related to an outgoing request.

The key insight behind ThreatSTOP is realizing that on the Internet, unlike in the physical world, traffic cannot lie about where it is going to (or coming from for TCP packets). We use a variety of sources and methods to figure out what actual IP addresses malware tries to go TO. This makes it possible for the firewall to block on the IP address. Firewalls are designed to do this very quickly for lots of source and destination pairs. The result is that good traffic is not slowed down.

ThreatSTOP allows your existing firewall to do the job you bought it for, for all traffic, not just the Internet equivalent of the door-to-door salesperson (spammer), gang attire wearing tagger (Website defacement) or opportunistic petty criminal.

With ThreatSTOP it doesn’t matter what the criminal malware does while it tries to call home from your network, it gets stopped (and the attempt logged) as soon as it tries to leave.

The malware can:

  • fake its protocol and port
  • run roughshod over or sneak around your web proxies, DNS and Active Directory (including any outsourced ones)
  • it can obfuscate urls and encrypt content
  • or try a dozen other tricks

but no matter what it has to use a REAL, non encapsulated, routable IP to actually communicate with its masters and “gang”.

If it tries to contact an IP address that we know is an active C&C host it is stopped at the firewall, the internal IP is logged, and there’s no way around our block.

Filed under Technology Tagged with , , , ,

Is there anything in Ukraine except cyber crime?

May 29, 2012 by Leave a comment

On the Kaspersky SecureList blog there’s an interesting post about recent developments for the SpyEye malware. The blogger explains how SpyEye supports a nice plugin architecture and how he examined an interesting new plugin that downloads a flash plugin for certain banking sites which can then switch on the victim’s webcam and stream the data back to the crooks.

So while this is clever, what has it got to do with ThreatSTOP or with the title of this post – the cyber crime in Ukraine? Well the answer is fairly simple. It seems that the malicious flash plugin is downloaded from the “statistiktop.com” domain which currently resolves to 91.206.200.17 and previously resolved to 91.206.200.79, both of which are IP addresses owned by a Ukrainian hosting provider. While said hosting provider is not the worst in our list its 512 IP addresses do contain a number of recent hits and the entire range has been blocked by us via the “Russian Business Network” feed for at least a year.

In practical terms this means that anyone who uses ThreatSTOP would not have been infected by this malicious plugin (and of course it is likely that any call home from it would have been blocked by our SpyEye feed) but while that’s clearly a good thing, it isn’t the thrust of this post.

The point of this post is that, while the attack vectors get smarter using, for example, flash plugins to control a webcam, and they use endless multitudes of domain names as part of their business, the criminals keep on using the same limited numbers of “safe houses” and “fences” – or rather their cyber equivalent, bullet proof hosting companies and compromised servers – to transmit their malware and get the data back.

Many of the places the cyber criminals reuse a lot are in Eastern Europe. If you take a look at the current threat status part of our home page you’ll see that Ukraine is the ‘Worst Large Country’ with about 6% of the 12 million or so IP addresses assigned to it being on our lists. This is not a once time thing. The percentage of bad ip addresses has gradually crept up but Ukraine has been our “worst large country” during the entire time we have run this particular report. Apart from a brief period where the Penguins of Antarctica were our worst small country, that “honor” has almost always gone to one of Haiti, Latvia or the Seychelles. Interestingly Latvia, while still bad, only has 5.9% of its 1.6 million IP addresses on our lists which is a significant improvement and now better than Ukraine.

Fundamentally though, if you don’t do business with countries like Ukraine, you can protect yourself from a lot of malware by simply blocking traffic to/from those countries at the firewall. We created our “Eastern Europe” list precisely because we recognized that this was a useful thing to do. And really when more than 1 in 20 of the IP addresses in a country are suspicious it just makes sense to err on the side of caution.

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

New and Improved Botnet Feeds

March 15, 2012 by Leave a comment

ThreatSTOP has improved our botnet block list by adding a number of C&C servers and DNS servers for botnets that have been taken down by law enforcement. This includes the conficker C&C sinkhole servers (see http://www.confickerworkinggroup.org/wiki/ ) and the IP addresses that the DNS Changer botnet used as DNS servers when redirecting DNS on infected computers (see http://dcwg.org ). These have been added to both the botnets feed and to respective expert mode feeds – sinkhole and DNS changer. We have added these feeds as a service to our subscribers to help them identify computers on their networks that are still infected by these forms of malware as by blocking these addresses on the NAT device makes it easy to identify the infected internal host from its IP address. The “research” popup for a DNS Changer IP address looks like this:

DNS changer example

and for the other sinkholed malware (generally conficker), it looks like this:

Conficker example

In addition we have also added a new source of derived botnet data from Cyber TA. This new source adds about another 200 currently active C&C hosts as well as providing cross correlation of a number of other addresses that show up in other sources. This list is available as an individual feed for expert users (CyberTA-Botnet) as it has some known false positives in it.

Filed under News/Announcements, Uncategorized Tagged with , , ,

The mobile to cloud security challenge

February 28, 2012 by Leave a comment

ThreatSTOP is spending the week up in San Francisco at RSA. We will be on the Vyatta booth, #452, showcasing our joint solution for the protection and centralized management of virtual and cloud firewalls.

We started things off by attending the Cloud Security Alliance event on Monday morning.

There was one clear theme that emerged from the various panels and speeches – namely that the really big security challenge for cloud computing revolves around the fact that people want to be able to connect to the cloud from anywhere with whatever they happen to have at hand – a mobile handset, a tablet, a PC in an internet cafe and so on. This leads to a whole bunch of potential pain to do with device authentication, web security and the like.

As I listened however I realized that ThreatSTOP can offer a good deal to help with some of this. The most obvious thing that we can help with is stopping attacks on the cloud servers. This is because we have the IP addresses of currently active recon bots and other attacking computers. A cloud provider can (and we have customers who do) put ThreatSTOP on the firewall they have in front of their servers. This blocks all communications with those IP addresses a. As a result, the attacker thinks their is no server active at the target IP. Rather than waste time, resources, or potentially be detected by a darknet, they move on. Unlike signature based approaches, which accept the connections and inspect the data stream, the servers are not subjected to additional attacks and scans designed to enumerate and exploit known vulnerabilities.

ThreatSTOP can also be applied on a Vyatta VM which is used on a per hosted customer basis to protect their virtual infrastructure and not the entire hosting company. This means that each cloud customer can customize the block lists they select and use their own custom allow and deny lists, exactly the way they do on a standard physical firewall.

ThreatSTOP + Vyatta in a Virtual environment

However that’s only a part of the story. The other part is that we can protect the mobile device – at least when it’s on the corporate network – from bot infection and can detect when it has been compromised outside the corporate network and returns to it.

By stopping attacks on cloud servers and detecting when malware has infected the clients ThreatSTOP can protect your cloud and physical infrastructure in ways no other product can.

Filed under Technology, Uncategorized Tagged with , , , , , ,

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 , , , , ,

Krueger Wholesale Florist Uses ThreatSTOP to Block Botnets

August 24, 2011 by 2 Comments

Krueger Wholesale Florist, a Wisconsin-based distributor of fresh cut flowers, green plants and supplies to customers across a nine states, has deployed an EdgeWave iPrism Web Security solution to four separate locations with hundreds of employees.  One of the key reasons for EdgeWave’s win was ThreatSTOP, whose botnet blocklist is integrated into the iPrism.  This is often the case with EdgeWave, Simwood and other partners, where ThreatSTOP provides a key differentiator and value unavailable anywhere else.

John Troemel, IT Manager at Krueger Wholesale, was intrigued by  ThreatSTOP technology. Given the noticeable rise of criminal malware and challenges associated with a dynamically changing threat landscape, Troemel was intent on implementing a solution that would deliver proactive defense against these exploits. By simply checking the botnet category in the iPrism URL database, Troemel was immediately alerted to potential security risks he didn’t know existed. “Enabling the botnet defense showed me that there were some desktops trying to connect with Skype that should not be,” said Troemel. “This could have resulted in a potential security issue, but because of iPrism, I was able to fix that problem. I keep a really clean network, and iPrism really helps things stay even more secure.”

Read the story at Sys-Con Media.

Filed under News/Announcements, Specific Threats, Technology, ThreatSTOP in use Tagged with , , , ,

Academic Freedom Need Not Mean Botnet Infections

August 8, 2011 by Leave a comment

ThreatSTOP has a number of universities and places of higher education as clients and, it turns out, there’s a good reason for this. That reason is ‘Academic Freedom’ and the possibly unintended consequences of that on computers and networks.

Unlike other organizations, universities tend not to be allowed to limit the access of faculty or students to the Internet because of the need to not censor or interfere in Academic Freedom. This is a noble goal but, in today’s world where significant chunks of the Internet are places that only offer one thing – the chance for visitors to be electronically mugged – it is not a goal that leads to a university network that is free from malware. And it doesn’t help that, as part of the same freedom, university network users typically expect to be able to connect any computer with any OS they want and with or without any sort of malware protection. Given that Universities also have an obligation to protect research papers, student (and staff) personal information and so on there is an inherent dichotomy that must cause most university IT managers etc. ulcers.

ThreatSTOP however manages to reduce the strain because even the most ardent fan of academic freedom tends not to want to see his or her own computer ‘PWN3D’ by some criminal gang halfway around the world. Likewise academic freedom and lack of censorship tends not to mean that professors appreciate large amounts of spam in their inboxes or having their local departmental server taken over by a gang and used as a phishing server. Thus academics tend not to object to a firewall that merely blocks access to those comparatively few IP addresses that are known to be bad while permitting access to the billions that aren’t.

ThreatSTOP has an extremely low false positive rate which means there is little need to worry that a blocked address is actually harmless. Furthermore because we are extremely fast to add new addresses and  we actively remove IP addresses that are no longer actively bad, the lists we produce are ones that list just what is bad now, not what was bad last week or last year.

Our academic users typically see a huge reduction in malware on their networks once the implement ThreatSTOP as well as a significant reduction in spam and inbound attacks. The reduction in inbound spam and bandwidth is often entirely sufficient to justify the purchase of ThreatSTOP as this reduction significantly extends the life of mail-servers, virus-scanners, IDSes etc. and reduces the need to purchase additional connectivity to the Internet.

So if you’re reading this and work in a university, why don’t you give us a try?

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

The ineffectiveness of AV

August 5, 2011 by 3 Comments

Over at ZDnet Ed Bott has a report on the ineffectiveness of anti-vrus tools against current malware where he notes that many AV vendors only detect it a day or two after it has been distributed and that by then a new variant that they don’t detect has also been sent out. In the IT security space, this is not exactly new news. In fact here at ThreatSTOP, we’ve been using similar statistics in our sales pitch for about a year now and in fact the AV vendors themselves admit they have a problem. If you ask them in private that is.

The key thing to note is that most malware (his specimen is a good example) ‘calls home’ to a server owned (or PWN3d) by the crooks who distributed it in order to either download some more effective trojans or to inform the crooks of the juicy private data etc. it has found. It has to call home because without the call home it almost certainly can’t make money for the people who set it up because they need the data or the CPU power to do whatever it is they want.

“Call Homes’ are very rarely blocked because they generally look like regular web traffic. Sometimes it is unencrypted HTTP or IRC which a web-proxy or DPI device may be able to detect (though even that can be problematic – how do you tell the difference between a genuine sessionid in the GET url* (or cookie or AJAX like POST) and one that is encrypted personal data?) but these days it is quite likely to be encrypted HTTPS which they can’t. As far as the DPI device goes one HTTPS session looks very like another except for one teeny little detail. That critical detail, however, is the end-point. If the end point has a bad IP reputation then it makes sense to simply block all the traffic to it.

The key thing that we do at ThreatSTOP is distill gigabytes of threat data from multiple sources into a list of bad stuff that is easy to deploy on a firewall, web filter or other security device. All these devices have the ability to block thousands of IP addresses and networks (even a low end home firewall can typically block at least 1000), they just need that list delivered to them in a form they can easily user and which is regularly updated. That’s our trick and it works well everywhere it has been tried.

*Is a get for /story/SB10001424052702304563104576355623894502788-lMyQjAxMTAxMDMwMTEzNDEyWj.html?id=d1b07e586e12143b3a3f1d1a47e7d45a&ref=0971880107&nodeID=283155 genuine or your name, address and credit card details? What about an AJAX post?

Filed under Technology, ThreatSTOP in use Tagged with , , , ,

SonicWALL IP Reputation Fail

August 4, 2011 by Leave a comment

Since ThreatSTOP is an IP Reputation company, we naturally have a google news feed on the topic of ‘IP reputation’. Today, for some reason, it provided a link to the IP reputation page of the firewall vendor SonicWALL. Naturally I had to test the page out to see how well it did. I picked the 4 addresses currently listed on our home page as being the “worst of the web”:

The Worst IP Addresses for 4 Aug 2011

The Worst Addresses for 4 Aug 2011

The first of these addresses (49.212.100.60 from Japan) has been on our page for a few days now so I thought it would be likely to be listed by SonicWALL.

SonicWALL's IP reputation for 49.212.100.60Just for reference here is a screenshot of the ThreatSTOP opinion of this address which lists 5 currently active entries in feeds plus one past entry:The real IP reputation of 49.212.100.60However all the feeds are basically server side ones, so it occurred to me that perhaps SonicWALL is biased to client side threats like Malware droppers, trojans and bots.

Well I tried the next entry (209.85.51.152 – USA) and SonicWALL was still oblivious to any threat from it:while when I entered that address into our database I got even more hits:

As you can see this one is much more of a threat to regular users. It’s listed in the BLADE malware dropper list, a phishing list and two botnet C&C lists amongst others. So the hypothesis that SonicWALL’s IP reputation is user centric seems to be untrue also.

Just for completeness I queried the two South Korean entries (112.175.243.22 and 112.175.243.24) in the SonicWALL IP reputation engine with similar results:

Needless to say, here at ThreatSTOP we know rather more about both and in fact the latter address (112.175.243.24) has been on a total of 8 different lists since the middle of May which is quite impressive and puts it in the running for the IP reputation award for “most depraved newcomer 2011″

Just for fairness I plugged the 4 addresses into McAfee’s trusted source, which doesn’t share data with us, and all four were reported as bad.

All in all it has to be said that theSonicWALL’s IP reputation service seems to be rather less that efficacious. In fact it rather reminds me of 3 famous monkeys that are in the same country as the first IP address.

Mizaru kikazaru iwazaruThis isn’t exactly the attitude I’d want for an IP reputation service.

Filed under ThreatSTOP in use Tagged with , , , ,

← Older posts

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: