Diamonds or chains

By Rob MacGregor

What are they and why would you pick one over the other?

(Cyber) Kill Chain

The concept of the cyber kill chain is attributed to Lockheed Martin and their 2009 paper entitled ‘Intelligence-Driven Computer Network Defence Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains’[1]. It’s a defender-centric paper that describes the steps an attacker must take to successfully compromise their target and extract the information they’re after.

The theory is that as a defender all you need to do is disrupt one link in the chain, and the steps that then would have followed are no longer an issue.

Obviously not all steps are apparent to the defender. You may, possibly, be able to detect some of the reconnaissance steps if the attacker is browsing your web site. However you are highly unlikely to have any visibility of the weaponisation stage.

How much visibility you have of what follows will depend on how well you monitor your own network, including the mail server and endpoints.

Diamond Model

The Diamond Model was published by the Centre for Cyber Threat Intelligence and Threat Research in 2013[2]. It’s an intelligence-centric paper that details how to map an adversary’s TTPs (Tactics, Techniques and Procedures), building up Threat Intelligence.

This approach focuses much more on understanding the attacker – what tools and infrastructure they use and their motivations – than the Cyber Kill Chain^® approach.

Rather than looking at a series of events, the Diamond Model works on relationships between features. Instead of seeking to identify disruption points in single attacks it is intended to enable you to better understand the nature of the threat you are dealing with.

The purpose of this is to enable a more effective overall response. Instead of playing whack-a-mole with a persistent adversary you build up a picture of how they operate and address those facts directly.

This is valuable as you deal with more advanced attackers, such as those who, upon gaining an initial foothold, will establish alternative ways in (possibly using legitimate VPN credentials) and clean up the initial infection. When working through the Cyber Kill Chain^® on individual events you risk assuming that the absence of any further malicious activity means that the defensive measures in place worked. Using the Diamond Model, however, you have the ability to relate the event to others and spot the potential follow-on.

Which one?

Surely the recommendation is going to be the Diamond Model? After all, rather than putting out lots of individual fires isn’t it much better to address the cause of those fires.

Except that to understand the cause of those fires, you must first put out a number of them and study the remains.

In other words, both approaches are valid and relevant. As a defender you have to start with the Cyber Kill Chain^®. If you don’t disrupt the attacker and stop them stealing from you then you won’t have anything left to protect. You must however also be recording information that will help you build up the Diamond Model for each attack, even if initially you don’t use that information. Once you start working on your threat intelligence you should also be using publically (and privately) available information to help you fill out those models, and find links to other diamonds.

The more complete your understanding of the capabilities and technologies available to your attacker, the better placed you are to mitigate the majority of their attacks and to resist those that succeed.

Ultimately better intelligence on the threats you face, whether cyber attacks or more traditional threats to your business, will always help you manage them more effectively.

Samples

Kill Chain – Delivery Stage

The following are headers from a targeted spear phish attack.

Received: from [Redacted](172.18.46.252) by [Redacted](172.18.46.142) with Microsoft SMTP Server id 14.2.328.11; Tue, 10 Dec 2013 00:50:45 -0800

Received: from [Redacted]([172.17.198.41]) by [Redacted]with ESMTP; 10 Dec 2013 00:50:44 -0800

Received: from [74.208.4.200] ([74.208.4.200:52006] helo=mout.gmx.net) by mail19.prod (envelope-from <[email protected]>) (ecelerity 3.4.2.33817r(MessageSystems/Momo-dev:9fc2f41b555d)) with ESMTPS (cipher=AES128-SHA) id89/31-18381-4E5D6A25; Tue, 10 Dec 2013 08:50:45 +0000

Received: from abcnew.tk ([98.126.223.106]) by mail.gmx.com (mrgmxus002) with ESMTPA (Nemesis) id 0Lao5G-1VAPgv3HIW-00kOPw for <[Redacted]>; Tue, 10 Dec 2013 09:50:41 +0100

From: Linkedin Security Team <[email protected]>

To: REDACTED

Subject: [ATTENTION]Mail System Update Confirm

Thread-Topic: [ATTENTION]Mail System Update Confirm

Thread-Index: AQHO9YTqWe+ROT7bGU6e8cQCiJMg0Q==

Sender: "[email protected]" <[email protected]>

Date: Tue, 10 Dec 2013 00:50:49 -0800

Message-ID: <[email protected]>

Reply-To: Linkedin Security Team <[email protected]>

Content-Language: en-US                     

X-MS-Exchange-Organization-AuthAs: Anonymous

X-MS-Exchange-Organization-AuthSource: [Redacted]

X-MS-Has-Attach:

X-MS-TNEF-Correlator:

X-Mailer: mlx 5.1.7

Content-Type: multipart/alternative; boundary="_000_0ca9b59ffb2975dfadfc33b9a5455b05abcnewtk_" MIME-Version: 1.0

I’ve highlighted several items. Those in yellow are infrastructure indicators in the diamond model. Those in cyan are potential capability indicators. From a defensive purpose you may review those items to look for signatures you could write to find suspicious activity. In this case it may be as simple as looking for emails relaying through mail.gmx.com that originate in 98.126.0.0/16 where the From and Sender headers don’t match.

The final highlight is the originating timezone which may help identify where in the world the email originated (a possible adversary indicator). This can be misleading so by itself should not be relied upon.

The link in the body is to http[:]//mail-linkedin.tk/mail/auth.php.  The domain would again be infrastructure.

Kill Chain – Exploit/Install Stages

From a kill chain perspective this is (most frequently) the program you run that then is responsible for giving the adversary access. These can be hard to separate, practically speaking.

In this case the link provides a file called 1.exe, with an MD5 hash of 4D0515C5F978DA9759514AB0DE513915. Both of these are capability indicators in terms of the diamond model. It is likely that the file will undertake actions (such as ensuring it runs on boot, dropping other files and so on) that can be further linked as capability.

Kill Chain – Command & Control/Act on Objectives stages

Now we get on to the network traffic and local actions that are driven by the operator. For example, the beacons may look like:

GET /aotj/581/link.php?a=5&z=SGVsbG8gV29ybGQ&f=476f6f6462796500 HTTP/1.1

Host: mail-linkedin.tk

User-agent: Mozilla 4.4

Accept-Encoding: gzip

For the diamond model this again identifies some infrastructure and some capability. Further activity will similarly allow us to identify capability and infrastructure. From a defensive perspective we again have a number of things we can signature to help us spot further, or related, activity.

Practical Application Example

Here is a worked example as if it was a series of attacks observed by an IT Security team. We will demonstrate how to map observations to points in both the Kill Chain and the Diamond Model.

Day One

Bob, the PA to your director Mo Angleton, calls you to say that he’s having problems opening a document from the new head of finance. You wander over, sure it’s a PEBCAK error. Asking him to demonstrate the problem you watch him double click the attachment to the email, see the long pause and then a blank PDF document open.

The pause strikes you as odd, as does the use of PDF. You ask Bob to open the email up again and as you read down the email it strikes you that the domain for the email address is wrong, it should be .com, and the email is rather brief – little more than “see attached”.

Pulling up task manager you see that Internet Explorer is listed as running, yet no window is open. Reaching around the back of the PC you pull the network cable, fearing the worst…

What do you have now? You have a number of artefacts already, and once you perform some analysis on your network logs and the PC you’ll have some more.

Obviously we also have the Victim for the Diamond Model – that’s us.  We can now go and write some IDS signatures for the network traffic, ensure that the relevant IP addresses, email addresses and domains are blocked and submit the attachment to the AV provider.

Oh, and probably send out an email warning people that the company is being targeted by spear phishing, with pointers to the e-learning they’ve all been asked to do.

Day Two

Reviewing the logs for the mail server and firewall you see a few more attempts to deliver other attacks and you have some quarantined emails from other IP addresses. You add those IP addresses to the block lists and your models and pull out the other emails to see if anything else has changed. Running the attachments in your malware sandbox you see that the network traffic hasn’t changed, they’ve just been packaged differently.

Confident in your ability to block any further attempts you go back to the rest of your work. It isn’t until late afternoon that it occurs to you to search the mail server’s logs to see if there have been any previous attacks from the same IP addresses or email address. You do find one from last week, but fortunately the recipient is on holiday. Quickly you arrange to have the email quarantined before they return.

Day Three

Who on earth puts standard acetate sheets into laser printers?

Day Four

Ten new starters turned up that need laptops – why did nobody tell us they were coming?

Day Five

You come in to see that overnight the IDS lit up like the proverbial Christmas Tree. Oh, and the network health dashboard has an orange indicator. From 19:00 there were hits on that new signature every 5 minutes. They stopped just after 05:20 this morning, which is probably a good thing – right?

The internal source was unsurprisingly Bob’s PC, which you quickly have disconnected from the network, again, until you can examine it. A quick glance at the network health dashboard shows that the orange warning is because the bandwidth usage is significantly higher than usual – starting at about 07:50. It is dropping back to normal now though.

After talking to Bob, an examination of his PC and reviews of logs and packet capture it’s now lunchtime, but you have more information. You now have:

The diamond models make it clear there are connections between the initial compromise and the later events. Each has the same email tool (X-Mailer: enom1856), the same implant and they share a common C2 domain.

What have we learned so far?

1. The attacker is persistent – they have made multiple attempts and keep changing their approach until they achieve success;
2. They have only used one tool so far – every attack has used the same approach with the same implant;
3. The e-learning package on spotting phishing attacks isn’t working;
4. The attacker has exfiltrated a large volume of data already; and,
5. The domain registration information for example.net may provide us with further information.

We can infer a number of things from this too:

1. The attacker has done their research – while it is quite public that Frank Smith has just taken the Head of Finance position, Bob’s existence as PA to the Director of IT isn’t (you think);
2. They are after information that the firm has – the FTP upload demonstrates that;
3. There is a human driving this – the implant was beaconing for hours before the activity changed, it was then some time before exfiltration started;
4. The attacker works office hours (most do), so 05:20 for us is likely between 09:00 to 17:30 for the attacker – and probably between 09:00 and 14:30 given that the activity was ongoing when you pulled the plug at 08:30; and,
5. They may be relatively unsophisticated – they’re emailing executables – however it may just be that they aren’t risking their better quality tools until they know this won’t work.

There are a number of potential red-herrings:

1. The geo-location data for the C2 nodes – there is no reason to assume that the attackers are using local (to them) infrastructure, and indeed many use nodes that are local to the victim;
2. Domain registration information can be faked, the DNS for a legitimate domain can be hacked and web sites can be compromised; and,
3. Email headers are trivial to fake – the only ones you can trust are those your own mail server (or that of your mail provider) adds.

Day Eight

Having had the weekend to think things over, you start dropping the various items of information into search engines and malware search sites.

As you find reports from others you fill out further diamond models. Patterns will start developing as you see the range of capability, infrastructure and targets.  This will enable you to start building that vital threat intelligence. How does this group operate? How sophisticated are they? Do they have any known links to other groups or organisations? All of this, and more, will help you identify the risks to your organisation and help identify the steps you can take to reduce those risks.

Outcome A

In this case the collective knowledge identifies this as BASILISK GAZE, a relatively new and immature group operating in the UTC+06:00 timezone. The targets have all been in the energy sector, or supporting sectors.

The attack method is always an attachment in email and so far they only send executables. Only 2 implants have been observed, the other being Poison Ivy with the default password. All observed exfiltration has been over FTP to an IP in the netblock 198.51.100.0/24.

Outcome B

In this case the collective knowledge identifies this as NIGHTMARE GREEN, a relatively sophisticated group operating in the UTC+04:00 timezone. Targets are highly diverse relating primarily to the energy sector and law firms – plus supporting sectors. Some victims have reported finding compromises that have been active for more than a year with unknown volumes of data stolen.

The attacks seem to start with low quality social engineering emails and executable attachments, moving up through higher quality emails with exploits against a range of PDF and Office programs. Lately there have been indications of the use of watering hole attacks. As yet the group has not been observed using any zero day vulnerabilities.

Implant quality is also varied, from the relatively unsophisticated HTTP implant up to versions with HTTPS, UDP and ICMP capabilities. Newer versions that use TOR have been observed in the last few weeks. Exfiltration methods also vary, with FTP, HTTP and UDP observed. The attackers regularly use legitimate remote access methods after the initial compromise, removing all traces of their implant.

Going forwards

One of those two outcomes will give you a warm feeling that you can remain on top of the threat with relatively little effort. The other, well, resisting it will clearly be harder. Either way, with intelligence on the threat you can make significantly more effective plans to tackle the associated risks.