TalkTalk customer data breached

Last week it was revealed that UK telecommunications company TalkTalk suffered a data breach in 2014, where customer details – such as account numbers, names and addresses – were stolen.  The stolen details were then used by scammers to trick people into believing they were being contacted by the company.  TalkTalk has said that the information stolen was ‘non-sensitive’ and it believes the attackers were able to access TalkTalk’s internal systems via a third-party that also had access to its network.

We see it time and time again – if an attacker wants to get in, they will.  This TalkTalk breach highlights not just the importance of organizations ensuring their own security policies are up to scratch, but also that of their third parties.  TalkTalk has done a great job in reacting to the situation by investigating when unusual events were reported, and then quickly informing customers of the situation.

It’s now clear just how important it is to have the ability to identify and respond to threats in as little time as possible.  While it seems TalkTalk has responded relatively quickly, it was through a rise in complaints from customers – rather than the company itself identifying unusual activity on its networks.  Most organizations currently operate in a mode where the time it takes to detect and respond to threats is months – or weeks at best.  In order to ensure that damage is limited, and to avoid becoming the next breaking news headline, businesses should aim to reduce this time to hours or minutes.

Traditionally, organizations have taken a relatively reactive approach to cyber security, but faced with the sophisticated threats of today, this needs to change.  However, there is so much noise on the network these days, with vast quantities of data moving around at breakneck speeds, that it can be difficult to proactively identify threats.  Security intelligence techniques allow security teams to see through the fog and target the threats that matter, so they can respond quickly and efficiently.  The faster businesses can find and shut-down threats, the more work hackers will have to do to succeed and, with any luck, one day in the future they’ll get tired of trying.

none | Uncategorized


Simulated cyber-threat thwarted at London’s BT Tower

Earlier this week, a simulated cyber terrorist strike took place at London’s BT Tower.  The event – part of the UK government-backed Cyber Security Challenge – was designed to mimic a sophisticated cyber-attack and tested the ability of amateur contestants to defend the building’s power-supply from hackers.  Those competing were selected following nine months of intensive assessments and the ten best from the day have been invited to compete in the grand final in March.

Real-life cyber attacks are becoming far more prevalent and we often find ourselves in a game of cat and mouse, trying to keep up with the perpetrators.  These schemes are excellent for weeding out talented people who can help defend critical infrastructure from hackers – and may one day be part of thwarting potentially dangerous threats.  Programs like these are great to see as they demonstrate that defending our boarders from cyber attacks is moving higher and higher up the political agenda.

However, we do need to be careful not to place too much credence on people alone.  While a workman can never blame his tools, it is also imperative to have the right systems in place to help identify and remediate potential threats.  There is now so much data passing through the networks of both private organizations and national infrastructure, that people alone cannot be the relied upon to identify when something is wrong.

Instead, security intelligence is paramount.  These systems are designed to monitor networks constantly in order to spot anomalies – and can process far more information in real-time than any human being.   There’s no doubt that we need the best people on the case, and events like this are an excellent way of finding them – let’s just also make sure they’re given the best possible tools to work with.

none | Uncategorized


Armed forces the latest to be warned against cyber attacks

A recent study by Lancaster University, The Future of Maritime Cyber Security, has found that Britain’s aircraft carriers and warships are at risk due to their reliance on ageing software.  The research team has warned that the Royal Navy and it’s international allies need to “fundamentally rethink” how they use technology on warships, as the software being used has a far shorter lifespan than the ships and aircraft carriers themselves.   As such, new cyber defense strategies need to be implemented and Navy personnel trained in how to be secure online.

All cyber attacks have their consequences and how far reaching the effects are clearly varies from case to case.  One thing I think we can all agree on though, is the havoc that would be wrought should the Navy come under attack.  While our armed forces are well acquainted with defending against the enemy, in the cyber world it can be far more challenging to determine exactly who that enemy is, and what they are doing.

We live in an age where the use of Advanced Persistent Threats (APTs) is on the rise, which, by nature, are often left unidentified for years.  The researchers from Lancaster are quite right to point out that the armed forces’ aircraft and warships are built to last, while the software is not.  However, all software is effectively under threat as soon as it is deployed, and understanding that is key for every organization – armed forces or otherwise.

The solution is not necessarily to constantly deploy new software to combat the risk – that just leads to a tedious game of cat and mouse.  Instead, it is imperative to constantly monitor the network for unusual activity in order to identify suspicious behaviour as quickly as possible.  The Navy is no stranger to intelligence – the more information you have, the better position you are in to defend yourself – and it is no different when it comes to cyber security.  For all of us, it is a case of when, not if, an attack takes place, but with the right security intelligence measures in place, the risk can be minimized.

none | Uncategorized


Lights, Case, Action!

LogRhythm released Case Management in its most recent update, and while I could wax lyrical about the merits of why you should be using this feature, I won’t.  Instead, I’ll show you a brief video demonstration of the new feature in action.  In this demo you’ll see the entire end-to-end analyst workflow, all the way from an Alarm being generated, through validation, and finally escalation and remediation.

So, without further ado! Roll the 20th Century Fox fanfare. Grab some jalapeno cheese popcorn and enjoy:

Watch on Youtube: Case Management in LogRhythm 6.3

Wasn’t that better than me writing a small essay on the topic?  In case you’re short on time here, is a quick recap of the video:

  • An alarm was triggered notifying necessary personnel of something bad happening on the network; in this case, a DNS query matching a user defined Threat List.
  • LogRhythm was used to seamlessly drilldown and pivot between search results to quickly find out “what else happened?”
  • A case was created around the event and all relevant information was brought together into a single place- the forensic Evidence Locker.
  • Finally – and perhaps most important of all -after investigation, the event priority was escalated to an incident and assigned to another colleague for remediation (the art of delegation!)

If you watch carefully, there are other features at play in this demonstration:

Threat Intelligence

This presentation is a great demo to show the use of Threat Lists.  In this example, a user-defined Threat List matches specific URLs being queried by endpoints via DNS (again please note, there’s nothing wrong with BMW’s website. They make great cars). If you’re not collecting endpoint DNS logging already I highly recommend you have a look into it. This method of looking for malicious activity can help detect threats that would otherwise not be seen, think fastflux, command and control channels, shared HTTPS servers, etc. Threat Lists within LogRhythm can contain a wide variety of things to look for such as processes, email subjects (phishing attacks), hashes, or as in this case, URLs. Threat Intelligence feeds are a great way to leverage the power of collective and shared knowledge.  If you’re not already using Threat Lists with your LogRhythm solution then enable the KB module and give them a whirl. Learn more about our Threat Intelligence Ecosystem here.

Data Masking

Another feature used in this presentation is Data Masking.  What’s Data Masking?  Well, it’s a LogRhythm feature that provides the ability to format Log Data.  The predominant use case is masking or obfuscating sensitive data, such as social security numbers or PAN data. We can also format logs that may have inconsistent formats (MAC address for example: some have colons or even dashes) in the above example, I removed redundant characters.  Let’s look at another quick example. A standard Microsoft DNS log looks like this:


Now for the keen-eyed, you may have noticed there are extra characters in the URL.  If one wanted to compare all the internal DNS queries made by endpoints against a Threat List then they’re not going to match in their default log format. That’s where Data Masking comes in. We can simply replace the erroneous characters and end up with a valid URL for comparing against our Threat List:

Web Pivot

Finally, the last point I’d like to make you aware of is the Web Pivot feature.  This feature is located in the Web Console and enables effortless drill down searching of meta-data fields. In this use case, we find an Alarm against Host-X and want to see all the activity carried out by that host in a surrounding time frame. With Web Pivot we simply click the metadata field of interest (the hostname) and specify a time period we want to search around (1 minute either side of the Alarm.) And, that’s it!

And there we are.  One of my favourite takeaways from demo’ing or training customers in Case Management is The Gru Moment when folks see how easy Case Management is and the benefits the feature can provide them.  Case Management neatly ties together the end-to-end analyst workflow, providing a great way to not only advance through the Security Intelligence Maturity Model, but also offering a way to improve the return on security investment across your organization.


none | GeneralSIEM


Detecting Lateral Movement From ‘Pass the Hash’ Attacks

Pass-the-hash attacks exploiting Windows operating systems aren’t anything new, in fact they’ve been around for donkey’s years; however, despite the exploit being nearly two decades old, still not much is known about the attack vector.  So, in this post, I’ll cover what a Pass-the-hash (PtH) attack is, some of the resources for mitigation and how you can use your LogRhythm SIEM to detect PtH resultant lateral movement from machine to machine.

But, first of all, what the heck is a PtH attack?  Well, let’s imagine a fun fair but not just any fun fair. At this particular fun fair proprietors are really concerned about their ride security and can only go on rides they’re authorised to ride on.  The whole authentication mechanism for each ride starts at the entrance, on their way in they present their two sets of ID and, in return, they’re given a scrambled token comprising the two IDs.  So far, so good.  Now they’ve got their token they look forward with glee to accessing all the rides of the fair, merrily presenting it for validation to each individual resource; however, a problem occurs in that everywhere an individual uses their token, a copy gets left behind at the ride stall. Even worse, the token is not a one-time use it will last all night.  What if some unscrupulous person were to get a copy of a proprietors token?  This person could access all the fun of the fair, hopping from ride to ride without true authorisation and even start gathering even more tokens!

And that is my highly untechnical analogy for PtH attacks; however, fortunately for all of us there are highly technical people on the interwebs including cleverer people who can explain PtH in far more technical terms – here’s Microsoft’s description on the whole PtH matter:

“The Pass-the-Hash (PtH) attack and other credential theft and reuse types of attack use an iterative two stage process. First, an attacker must obtain local administrative access on at least one computer.  Second, the attacker attempts to increase access to other computers on the network by:

  1. Stealing one or more authentication credentials (user name and password or password hash belonging to other accounts) from the compromised computer.
  2. Reusing the stolen credentials to access other computer systems and services.

This sequence is often repeated multiple times during an actual attack to progressively increase the level of access that an attacker has to an environment.”

Well, there you go.  Scary stuff!  This type of attack was first discovered in ’97 by Paul Ashton.  ’97 – the good old days – the days when you could leave your digital door unlocked with the key in the door and allow your neighbors in without fear.  But it’s not the good ‘ol times anymore, the lack of a salted NTLM hashed password value ultimately means you don’t need to crack a password in Windows, all you need to do is simply dump the hashed value from memory and pass that to a remote system.

Fortunately there are mitigations, lots of mitigations and best practices which should be adopted as mandatory in an enterprise.  These vary in detail, such as disabling NTLM and going pure Kerberos (which is open to Pass the Ticket attacks, but that’s another blog post) or rebooting systems when you’ve accessed them with privileged credentials, etc…  In fact there’s a 80 page document from Microsoft on the topic of mitigation.  80 pages!  Odds are, most companies will be vulnerable to this exploit in some manner.  Now even everyone’s favorite three lettered initialism of a security agency – the NSA – has a fantastic document on Windows Event log collection including a section on detecting PtH from log data (and yes, the posts finally going somewhere SIEM related!).

To quote section 4.15:

The successful use of PtH for lateral movement between workstations would trigger event ID 4624, with an event level of Information, from the security log. This behavior would be a LogonType of 3 using NTLM authentication where it is not a domain logon and not the ANONYMOUS LOGON account.

A failed logon attempt when trying to move laterally using PtH would trigger an event ID 4625. This would have a LogonType of 3 using NTLM authentication where it is not a domain logon and not the ANONYMOUS LOGON account.

That’s mildly interesting!  We can easily take that information and create LogRhythm SIEM correlation rules around these activities and give them a whirl.  Here’s our Correlation rule to detect successful PtH attacks.  We’re using a LogRhythm list of valid Domains we’d expect to see authentication activities from.


LogRhythm Correlation Rule (Click to Enlarge)

But first… what do these hashes actually look like?  Well, Blue Peter style, here are some I prepared earlier from our compromised host (not real hashes by the way, they’ve been altered as to not put passwords out on the internet!):


(Click to Enlarge)


Now amongst the list, is our test account appropriately named – “christest”

Let’s show an example of using the above hash to authenticate to another system on the network where we don’t know the password (and can hopefully get some more hashes!).


(Click to Enlarge)

Well, that went well.  But what actually just happened?  Using the hash value extracted from memory on our first compromised host we then successfully authenticated to another server in the network without ever knowing the underlying password.


SmartResponse Alarm Indicating Successful PtH Attempt (Click to Enlarge)

So let’s try the same out for a failed PtH attempt:


(Click to Enlarge)


SmartResponse Alarm Indicating Failed PtH Attempt (Click to Enlarge)

Now one question you may be asking – why did the above example fail?  There could be several reasons, such as the local account we’re trying to access via a remote machine doesn’t exist, it has a different password (hence different hash), perhaps they’re running Windows 8/2012 on-wards, maybe the destination system has installed KB2871997 (which is a good thing to do), or someone couldn’t use metasploit properly. Either way it’s all interesting to know about.

And there we have it.  A brief overview of how you can start to use log data to detect activities that could otherwise be extremely difficult to detect.  I’d highly encourage you to read up on Pass-the-hash detection, Pass-the-ticket mitigation and Golden Ticket attacks. These attack vectors aren’t as well known to most folks but are frequently used by malicious actors, APT and even by penetration testers.  As always. defence in depth layers should help pick up hashdump utilities but prevention eventually fails so detection is key.

Sources and recommended reading:


none | GeneralSIEM