Hacker Hat-trick at TalkTalk

For the third time this year the UK broadband provider TalkTalk have seen their online defenses fall to cyber attackers.

While the company has been quick to notify their customers of the breach (it was observed on Wednesday this week and reported the following day) and are currently working with law enforcement, details are still relatively sparse. Given the very short period between detection of the attack and public notification, it is unlikely any significant cyber forensics exercise has been conducted… so it’ll likely take those tasked with the investigation a couple of weeks to get a solid understanding of the scope of the breach and what was likely touched or stolen by the attackers.

Regardless, the stories currently being published as to the nature of the breach and what has actually been stolen are confusing and the details often contradictory (see Business Insider, The Telegraph, BBC, and AOL). It would appear that the names, addresses, dates of birth, email addresses, telephone numbers, TalkTalk account information, and credit card and/or bank details of some 4,000,000 subscribers may have been stolen and that the data may not have been (completely?) encrypted… or maybe the encryption keys were similarly stolen.

Claim for the latest hack are also being attributed by some to a Russian Islamist group (referred to as the “Th3 W3b 0f H4r4m”) who has posted a claim online along with samples of the data purporting to have come from the TalkTalk site (see Pastebin - http://pastebin.com/HHT4BxJA).

Some stories refer to there being a DDoS attack or component. A DDoS attack isn’t going to breach an internet service and result in data theft, but it’s not unheard of for attackers to use such a mechanism to divert security teams and investigative resources while a more focused and targeted attack is conducted. It’ll be interesting to see if this actually happened, or whether the DDoS (if there was one) was unrelated… although it would be difficult to tell unless the attackers really messed up and left a trail of breadcrumbs – since DDoS services can be procured easily over the Internet for as little as $50 per hour from dozens of illicit (but professional) providers.

If there are lessons to be learned so far from this hat-trick breach, they include:

• Hackers are constantly looking for easy prey. If you’re easy pickings and you get a reputation for being a soft target, you should anticipate being targeted and breached multiple times and likely by different attackers.
• There should be no excuse for not carefully encrypting customer data, and using cryptographic techniques that make it impractical for attackers that do breach an organizations defenses to profit from the encrypted data they stole.
• Calling an attacker or the tools they use “sophisticated” and expecting the victims of the breach to consul themselves with the knowledge that the organization charged with protecting their data was defeated by a supposedly more advanced adversary is wrong. It simply underlines a failure to understand your adversaries and invest in the appropriate security strategies.

-- Gunter Ollmann

Persistent Threat Detection (on a Budget)

If there’s one simple – high impact – thing you could do to quickly check whether your network has been taken over by a criminal entity, or uncover whether some nefarious character is rummaging through your organizations most sensitive intellectual property out of business hours, what would it be? In a nutshell, I’d look to my DNS logs.

It’s staggering to me how few security teams have gotten wise to regularly interrogating the logs from their recursive DNS servers. In many ways DNS logging can be considered sprinkling flour on the floor to track the footsteps of the culprit who’s been raiding the family fridge. Each step leaves a visible impression of where and how the intruder navigated the kitchen, and their shoe size.

Whenever an electronic intruder employs their tools to navigate your network, tries to connect back to their command and control server, or attempts to automatically update the malicious binaries they've installed upon the system they have control over (or wish to control), those victim devices tend to repeatedly resolve the domain names that that attacker is operating from. Therefore, armed with a list of known bad domain names and/or IP addresses, it’s a trivial task to mine the DNS logs and identify any successful intrusions.

Depending upon how authoritative your “blacklist” of criminal domains is, and how picky you are about the IP destinations that the domain names are resolving to, you can rapidly spot those nefarious shoe impressions in the flour.

One word of caution though, this isn’t a comprehensive technique for detecting persistent threats operating within your network – but it is one of the simplest! It also has the highest impact – particularly if you’re operating on a shoestring budget.

An obvious limitation of DNS log mining is the depth and accuracy of the blacklist you’re matching DNS events to – so you’ll want to ensure that the list you’re using covers the types and classes of threats you’re most interested in detecting. While there are plenty of free blacklists out there, the vast majority of them deal with spam, phishing and drive-by hosts… so you’ll want to invest some time shopping around a little.

Here are a few tips to using DNS as a means of detecting persistent threats (advanced or otherwise):

• Turn DNS logging on! Seriously, do it now… you can read the rest of this blog after you've turned it on.
• Select a bunch of relevant blacklists that contain malicious domains associated with the threats (and criminal actors) you’re most interested in.
• Create a list of IP address ranges for countries, companies or regions that computer systems within your organization shouldn’t be communicating with, and use this as a second-pass filter for spotting other unwanted or likely malicious traffic.
• Scrape your DNS logs frequently – ideally at least once per week.
• If you’re worried about a handful of specific threats (e.g. a criminal operator or state that is likely targeting your organization), scrape your DNS logs for relevant domain names hourly – and alert upon their discovery.
• Even if you’re only scraping you’re DNS logs weekly, don’t throw them away after you’re done. Try to keep your DNS logs for multiple years at least. (Note: DNS logs compress to almost nothing – so they’re not going to take up much space).
• Consider scraping all the older logs (going back up to 5 years) once a month or so. New domains will be added to the blacklists you’re using over time, and new intelligence can shed new insight in to past intrusions. It’ll also help to establish when the intruder first compromised your network when you do find one.
• If your DNS server allows it, turn on logging of “failed” lookups – i.e. NX domain requests. While these events won’t help in your blacklist lookups, they will help identify malware families that make use of domain generation algorithms (DGA) as well as “broken” applications within your network that need some tuning in finding their legitimate destinations.
• DNS log scraping can be conveniently done off-line through simple batch script processing. So the impact on the team responsible for securing the corporate infrastructure is minimal after a nominal development investment.

If you’re not happy with the quality of the blacklist you’ll be able to bring to bear in uncovering the persistent threats likely already operating within your environment, or if it would be helpful to do a “one-off” check of your DNS logs and to help build the internal business case for investing in a more permanent detection solution, let me know.