The below mentioned Advisory from the United States CERT is remarkable and interesting in many ways. It is all about the BeagleBoyz (not Beastie Boys). You never heard of the BeagleBoyz? Maybe you heard of the Lazarus Group, APT38, Stardust Chollima or some of the other names this group has been given. Different researchers have identified the threat actors as being North Korean and their target clearly is to steal money through electronic banking systems.

The group, according to the advisory, is responsible for trying to steal almost 2$ Billion USD in cash since 2015 and have harmed many banking networks with destructive malware ever since.

About BeagleBoyz

The CERT advisory mentions two attacks, a cash-out scheme - that is, intercept ATM traffic and send bogus protocol messages to allow a ATM cash-out. The second attack is a well known attack on SWIFT payment processing infrastructure and is one of the reasons that the SWIFT consortium introduced the SWIFT customer security program (CSP), which lead to a number of initiatives to further secure the SWIFT infrastructure typically found in banks and other financial services institutions.

As the article states, the "widespread international bank robbery scheme that exploits critical banking systems may erode confidence in those systems and presents risks to financial institutions across the world." This is a really bad message as banking is built on trust and with our mostly electronic transactions nowadays trust is something that can be measured by the attacks and the attack impact we see. I would absolutely support the above statement about eroding the confidence in those systems and SWIFT has done good in introducing the CSP back a couple of years to fight back and regain trust in the system.

Going back to the article, there is a brilliant technical analysis of the TTPs used by the BeagleBoyz throught the attack using the MITRE ATT&CK framework. Reading the advisory it becomes clear, that attacks like this are not comparable to simple ransomware attacks, as the toolset and the methods used by the threat actors are so diverse and you can see how they adopt to the defense used by the victim companies.

Looking at this, it is also clear, that big organizations like banks have a hard time to fight back. A small, very sophisticated tiger team (sorry, Beagle team) works undercover and remains unseen most of the time, whereas on the other side we see a huge organization that is working with a lot of process and regulations. Chances are very high that big parts of the attacks remain unseen and therefore can be brought to success by the threat actors.

What has all of this to do with segmentation?

One crucial part in the launch of those attacks is to gain foothold in rather low value parts of the organization, e.g. infect a users machine, gain persistence, discover more of the network, try to steal credentials and move laterally.

This is where segmentation enters the scene, because without the ability to move laterally we will make it much harder for a attacker to move to more valuable targets (and at the same time stay undetected).

How do attackers move laterally you might ask? Well how would you do to get on to the next, more valuable host?

  • You would map out the network as much as you can, in order to find the next best target and go higher on the value ladder
  • You would probably try to RDP on the next best host if you find some credentials. 
  • You would probably use other protocols or applications to gain persistence or spread further and you would be looking to control as much of the infrastructure as possible.

Albeit segmentation can not fully prevent all of the above, it can make the life of an attacker much harder, and, maybe even more important, it will dramatically increase the risk for an attacker to be detected. Segmentation will not only control access and contain attacks, it will also make attacks visible on a map and in your Incident Response by alerting on policy violations. 

The SWIFT CSP was established with this in mind, protect the SWIFT environment from attacks and lateral movements by segmenting and isolating it off of the rest of the environment and control access to the SWIFT applications and terminals on a least privilege, need to access base.

Why am I not segmenting better?

This is the tricky part. We ALL know that our segmentation is not optimal. We all know that we should only open applications or services on a least privilege or need to access base. We have been knowing this for many years. Why are we not where we should be? Most people i speak to are convinced that microsegmentation would be the way to go. If only there would be an easy way to get there.

I will start with a simple, 5-step process. Of course this is by no means a full project description. If you look for that, i would recommend to look Nathanael Iversens great guide on how to deploy micro-segmentation.

Get the right tools

The right tool for getting this done depends a lot on application visibility, it will concentrate on writing scalable policy in a easy way that scales from 10s to 10.000s of workloads. It will be easy to plug into your current and future automation scenarios.

Decide what to segment first

This is never easy, because, right, decisions are never easy. But you can use some metrics to make your life easier:

  • Value of data
  • Compliance and audit requirements
  • Risk to the business
  • Application owner relationship
  • related active projects

In our above SWIFT scenario things are easy. There is a mandate to segment your SWIFT payment processing infrastructure and there is a huge, identified risk. This is what needs to be segmented first.

Map your application environment

In order to deliver progress, you need visibility in all your applications and have a real-time map of what is going on. How else would you identify systems connected to the things that you want to segment and decide where you would allow access and where not.

Test and enforce policy

Writing policy is hard. But you know what's similarly hard? Verifying that policy works. You may say it's easy. You just wait for the call to happen (the call saying that a application or functionality broke).

There needs to be a way to model, test and enforce policy in a stepped approach.

Decide what to segment next

Once you have your first applications segmented, you can just iterate on what you did and learned.

Now you just need to decide which application to focus on next and chip away and segment more applications. Stick to the "Decide what to segment first".

Further reading