Releasing Your Inner TIBER in Regulated Adversary Simulations

Welcome survivors of this uh amazing day of cyber security. So before you all going to run off to have some coffee, please welcome on stage for releasing your inner tipper in regulated adversary simulations, Mr. Marco Buri.

[Music]

[Music]

Okay, good afternoon. Good to be here at Besides Talin. Such a great event organization and participation from the audience. So kudos to the organizational team and you uh coming to take part of this event. Now this talk is about cyber threat intelligence and red teaming in context of regulated cyber exercises which are a thing that are now happening in the financial sector in Europe. So before we get started, can we have a show of hand hands who is already working in cyber threat intelligence or aspires to work in this field? Okay. Yeah. Just few. What about red teaming or penetration testing? Working already or aspiring to work in this field? Okay. Not so many. So looks like the

audience is mostly blue teamers or recovering testers then. But uh I hope that you can take a lot from this this talk too. So uh I've worked in this field quite a quite a while now and currently I'm working at the central bank in Finland. I've been involved in implementing the Tyber framework typer FI since 2020 and prior to this I was uh nine years in consulting uh delivering uh red team projects amongst other things. So I'll try to source from these experiences for the talk today um some of my some of the things that I think that are interesting about the type of framework so that you know to give us a highlight and and pointers for you and

maybe this inspires you to learn more about the framework and how to develop your professional skills in red teaming. Um and that brings me to the motivation for this talk. So there's two reasons for this. One is that now that in Europe we have these regulated framework for red teaming that's creating a lot of demands for a lot of demand for highly skilled um cyber threat analysis work but also red teaming deliverables. So if you are a professional who aspires to work in these fields and and you want to be on the top of your game um in cyber threats or or red team testing, this is something that you should be interested about and there's going to be

professional opportunities around this area. And the second motivation is that I think the type of framework is pretty pretty good the guidance. So if even if you deliver uh red team projects using other frameworks and and methods, I think you should be looking at this and maybe it's a source of in inspiration about how to improve your deliveries um using the other methods regardless if your uh clients were in other critical sectors like energy or telecommunications or completely like different businesses like ICT platforms providers or or whatnot. A bit of disclaimer here. So this is not a full training on Tyber. Uh to make good use of our time together this afternoon, I necessarily cut off a lot

of details from here. So if you are going to be delivering any of these regulated tests, you definitely should be checking out the official requirements from the authorities and the and the guidelines. Now um this talk is being videoed. So if you feel like I'm going going through some of the details too quickly, you'll have an opportunity to circle back and and check out the details later. Now we know that all businesses or any business can become a target or a victim of cyber crime nowadays and it can be a motivation mo motivated by u financial gains uh by the threat actors. So financial sector entities meaning banks, insurance companies, payment uh services providers, they are no different as

targets from from this point of view. But why are authorities nowadays so interested and lawmakers about financial sector in particular that they are making these new regulations and guidances for red teaming? Well, um the thing is that you know it can be difficult to source exact details about how common um uh cyber crime is in a specific sector. But if we look at for example this NISA threat landscape report that was released uh early this year um you can see some statistics that they had sourced from 23 and early parts of 24. Uh you should check out the report in detail. There's there's good information there. But for for the interest of this talk, I want you to

focus on the uh prominent threat categories. Now there's not a lot of surprises here. But if we look at look at some of them, they are not so interesting about uh from tyber and authority point of view like like DOS or individual customers of of banks getting scammed to give away their banking credentials or fake invoices and those sorts of things. uh we as authorities are interested about this field from the point of view that we want to ensure that the critical uh ICT systems and services that support the critical business functions in these entities are resilient against cyber crime and cyber attacks. The reason being that the financial system it's a it's an interconnected system. So if one

uh large entity becomes um um victim of an incident, it can have ripple effects across the financial system. So the the whole financial stability really relies on that the individual components meaning the companies and entities are well protected on their own. I wanted to bring a topical example what kind of uh threat actors we are concerned about particularly. So I found this recent case uh UNC 2891 and an ATM attack that they had um conducted a bit earlier. So this threat actor group UNC2891 has been documented by Mandant already a couple of years ago and in their reporting at that time they described the threat actor as very sophisticated uh fluent in ops being able to stay

hidden uh fluent in Linux and Unix um operations uh making use of private and and public malware and back doors. But the recent case uh as documented by group IB, a different company uh describes an attack against an ATM backend system. And what happened according to that report was that the thread actor was able to gain initial access on the ATM backend system by placing um a remote access device that operated over 4G. And then once they had access to that local area network, they were able to move laterally uh find servers to infect and created an additional uh command and control channel via an internet connected server. And based on the analysis of of the

tools that the threat actor had left behind when it was um detected and eradicated from the system, uh it's believed that their end goal was to um uh affect the backend system so that later they would have been able to use fraudulent uh cards to withdraw cash from ATM machines and the ATMs would have recognized and allowed those transactions. So if we look at the uh steps in that attack through attack path through the lens of uh unified killchain in throughout phases it looks something like this. So there was the initial access using the device a lot of uh back doors and and you know um kernel rootkit tooling used C2 channels using uh DNS

and so forth. So I want you to think about these level of threat actors. These are the ones that we are concerned about in typer tests. So these are the kind of attack scenarios. As threat intelligence analysts, we need to be able to imagine, describe and justify. And as red team testers, we need to be able to simulate and execute these kind of tests uh without the defending teams, the blue teams in the target organization knowing that this is happening. So this is the this is the level we are going for. So how did we come here? A brief history about the evolution of red teaming. If you've been around for a while, you know

that the cyber security red teaming started to gain maturity in the early 2010s. And why that happened at that time was that some large global enterprises were getting hacked by very advanced criminal criminal groups that had lots of motivation, a lot of capabilities and time to breach these entities. And the companies made the observation at the time that maybe we are doing cyber security wrong um or at least we are verifying our controls wrong previously by doing isolated pentests or you know relying too much on infrastructure controls. We should probably simulate these kind of adversaries on our own. As you know the financial sector is um amongst the first to adopt all new ideas especially in the in the area of

security and that's why already in 2018 a a group of um central banks in Europe came together and they released this cyber EU framework cyber as you can see comes comes from Freddy intelligence-based ethical red teaming and it wasn't a mandatory framework at the time it was a a playbook that describe the best practices how entities in financial sector could could conduct these kind of adversarial simulations or or red team tests. Um so fast forward to this year. So what happened in January is that a new piece of European law came in effect called DORA digital operations resilience act. And now it introduced a new term called TPT, threat penetration tests, which is describing the same thing only now it's

mandatory for some entities in Europe, the mo the largest the the the most influential um financial entities. So in each member state going forward there's going to be an authority who assigns this TPT responsibility to banks, insurance companies or other you know service providers in this field that you as an entity are required to do the TPT testing every 3 years or so uh going forward. Now as the DORA came in effect at the same time the the central banks released a new version of the Tyber EU. So it's now a guideline and playbook how to run those um how to run those TLPT tests. So how to be compliant with DORA TPT requirements and apply best practices in

in cyber security red teaming in financial sector context. So that's the background why we are here now. So let's have a look at who are the stakeholders in this uh type of ecosystem and how do the projects then look like. So there's a in each member state there's the authority they've let the entities know that you are going to be requiring to do this testing but the thing is that the entity can't decide when they are doing going to be doing the testing the authority will later go to each individual bank or or insurance company and say that by the way your project started now today. So the then the entity gets organized they will launch and organize this

project according to the type of playbook and the project will take about 18 months on calendar. So it's a quite a large undertaking. It's not a small pentest project. One of the first things that they will do is they will look at the professional services market and try to source the best possible threat intelligence provider and the red team testing provider for their project. Now the authorities are not g giving any recommendations about this. It's for the entity to look at the available market and source the providers from there. It can be one company delivering both of these services or it can be two companies who have joined forces and offer for a single project. Then another

group of stakeholders are the blue teams. So as you know in red teaming it's understandably the goal that we are trying to execute and plan and execute all the testing so that it remains hidden from the IT security teams everybody who is involved in in running the security defenses on on day-to-day uh operations. So they are not in the know until late in the project when it's time to it's time to go through the reporting from the from the red team. The authority appoints the test manager who will liase with the project and the entity will set up a control team which is a team who is running the project on at the entity. So if you've ever

participated in in test projects or or uh crisis management exercises where there was a team called a white team well this is the same only now in in typo it's called a control team to put emphasis on the fact that these are the people who are going to be accountable and controlling every aspect of this this project's uh successful execution. The type of projects have only three phases, three main phases and the testing phase is split into two parts. So there's the threat intelligence and red teaming. And we'll be mostly discussing these two going forward. So I'll just quickly recap what the other two parts are about. So the preparation phase is about getting the project uh

started and organized. So uh you you appoint the control team and um uh document the scope for the for the threat intelligence to start you source the service providers from the market and start the risk management process and then in the closer phase we will in include the blue team uh in the mix. So they are brought in they are told that okay there was this uh red team and here are the red teamers you should probably look at their reporting and have a bit of workshopping to get the maximum learnings from these projects and project and and highlight the areas that we could be remedying or improving improving as controls going forward. So that's the closer phase.

Now let's dive a bit deeper in the threat intelligence part then. So what happens there? Um as I said as a starting point they have a list of uh ICT systems and and services from the control team. But this is not an IT asset inventory or anything like that. This is the list of those applications that are critical in supporting the critical business functions. But like in a bank it's um deposit taking and and giving out loans and pay you know um um operating payments these kind of like core processes. So the control team will need to identify and list those critical applications and systems in connection of these critical functions. So the thread intelligence analysts will then

have a look at the list and and amend it with their enrich it with their own own sources and thinking. So they will have a look at um you know uh what are the technologies involved? What are the providers involved? Uh is there a internet footprint to these services or systems? What's their vulnerability history? But also analyze the business. So why is this application there? Who is using it? how they are using it, where is it at, what are the contents and how this could be relevant for for the criminals to target. So this is a one one set of information and then the other set of information that the um the threat analyst will work with is the um

threat landscape information. So they will look at the all the known threat actors operating in in a financial se in financial sector space and could that could be possibly targeting this kind of entity that we are now running the project for and then it becomes an it becomes a task of trying to find the best match uh between these two. So they are trying to combine these data sets to create the best plausible scenario ideas for this test projects project. So first the list is long um you know they are just ideas for now and the thread intelligence team will work with the control team to to find the justification which ones are the best to select to go forward for

refinement and documentation and then take to the red team testing. So the list can be long at first, but the at the end of the threat intelligence phase, you only have typically from five to uh sorry, from three to five scenarios that are moved forward to the actual red team uh testing phase. So uh the scenarios of obviously they have a verbose explanation about what's actually happening in this scenario and they also include the the TTP. So these are the steps that the threat we imagine that the threat actor would be taking with all of our knowledge about this threat actor its past activities its motivation its capabilities the tooling they have used before. So all this

information is is brought in and this is basically the deliverable from the threat intelligence phase. Three to five scenarios very well very thoroughly explained and justified with all the facts included. Now as the these are these projects are always time box exercises. So it means that we need to uh bend the realms of reality a bit to assist these uh service providers to do the best work possible and in thread intelligence phase that means for example that they have typically free access uh to the information within the entity. So they get to interview the control team or other experts. Uh they can request documentation. So this is not a matter of running some public scanning and on

open source intelligence. they will actually get to look at how this company operates, how it IC, how its ICT is sourced and so what kind of technologies the ICT is built on. Now here are some common elements that are included that are you know very topical nowadays. Uh just an example so the um all sorts of supply chain issues are topical of course nowadays. So whether that's professional services subchain u um professional services like consultants that you're bringing in your organization they could be a vector for initial access maybe their equipment is compromised or maybe uh they are working with bad intentions but also um the software as um as a supply chain issue. So every company is bringing in

open-source software. Maybe they are sourcing the software components from wrong locations and some of them are poisoned when you bring them in. You know the VPN vendors have had a bad time over the past few years with all the vulnerabilities that have been going on. So definitely makes an interesting and and topical initial access vector for the type of tests and then the physical breakin um always relevant whether that's to to bring a remote access device like in the ATM case or whether it's to plant a key locker or something similar and then if we look at common end goals well in financial sector entity entities there's always uh part of parts of the business and ICT

operations that deal with payment materials and payment transactions, payment messaging. So, um obviously that's a good way from an attacker's point of view to monetize their their attack. So, those are, you know, common targets. Um double extortion, so excfiltrating the data, threatening to release it, but also encrypting it on site and and extorting with the ransomware for its its uh release. And as you know in the financial sector a lot of them are moving in the cloud but have another foot still on on premises. So those on premises environments legacy environments typically make a nice nice target for red teaming and and uh easier then navigate there and than in cloud native solutions. Okay. So now we move to red teaming. We

have a short list of those scenarios. They are well described. So what is there for the red team to do but to execute all the steps right? Well the reality of course is a bit more complex than that. So one of one of the reasons so we might change the attack path how they were described in the scenarios to how they are actually executed. And one of the reasons why we might be wanting to do that is that initial act initial access activities um are expected to be very noisy. So as you know a lot of enterprises are now putting effort at the edge protection with the EDRs and fishing training to the fishing simulations to the employees

and these kind of things. So if we think that the initial access can be very noisy and we don't want to needlessly alert the blue team right when we are starting the red team test. So we might take the attack chain attack path apart and simulate the latter part first latter parts first and when once we are done with this we will late in the project circle back and simulate that we would have been able to do the initial access parts too. We are just doing it in this fashion for a reason. Now it often happens that more than one leg up. So leg up is a help from the control team for the for the red team to

to make progress. more than one leg up is needed from the control team. And um this could be a situation for example that somewhere during the lateral movement uh the red teamers are stuck in a certain network segment and they know that the the target the objective is going to be in another segment but they can't find a way to move move between these these networks. It's so well isolated. So the control team might might come in and provide some kind of leg up so that they can they can uh jump past this point and then continue with the other steps in the attack path. So this is not a test in the skill of

the red teamers. So that's why it makes sense to give them help so that they can they can test as many uh parts of these attack paths as possible and not get stuck in one one point of on the attack path needlessly. Then another complication that might arise is that when the red team testers are executing the attack path, they might recognize that there's actually a better way forward. Our scenario description says that we should be doing this thing. But in our professional opinion, now that we are looking at the environment, there's actually a better better uh venue in our our view. So how about we go that way instead? So they are the testers are expected to flag

these points for the control team and have a discussion whether it makes sense to take this alter alternate way instead. And sometimes it happens that you know it turns out that it's it's actually a better idea to do what the red team suggested regards regardless of how the scenario was was described. So what happens to those other ideas that were never never then executed they were tabled at the time? Well, the testers are according to the framework they are required to make documentation of this so that during the closer phase when they are the red teamers are workshopping with the blue team these are revisited. So there's going to be a purple team testing or there's going to

be tabletop workshopping around that hey if he we had taken the other option here what might have happened then would that been a more impactful or better way to reach the goals or not? What do you think is their learning point here for us? And then the last example here uh is a situation where one of the scenario gets burned. So the B scenario here gets caught by the by the uh blue team and they remove all the access and it can't be continued. But then there was another scenario a that was more successfully successfully executed by the by the testers that somewhere in the middle turned out to be similar to the scenario B. So let's say that the initial access

vectors for the scenarios they were they were not the same and the flags and the targets at the end they were not the same either but somewhere in the middle they had a similar like um accessing a network or similar credentials or you know similar lateral movements. So it becomes a consideration for the red team and a control team. Um now that we've successfully completed the scenario A, why don't we just reuse the access that we have there and complete with the remaining steps of the scenario B. Again we have to remember here that this is not a test on the skill skills of the red teamers and the best value for for learnings comes from when we are able to

do as many tests as possible. So that's why you know this kind of deviation is often allowed uh when it doesn't put the when it doesn't risk the scenario a also getting getting caught. So sometimes the the the project becomes a learning point for the red team testers also and one of the common points I point I already mentioned that the red team testers thinks think that this is a test on them. So they might you know feel pride in asking for legups or proposing for legups to the control team. So this is u false thinking. Um we are in a time pros project. The red team phase typically takes from 12 weeks to 15 weeks on calendar. So it doesn't make

a lot of sense to spend lots of you know several weeks getting with the red team stuck in a certain point in the attack path. you know if they are finding too much difficulties just you know propose and get a leg up and and we'll get more learnings from the project that way. Um another one is that um um that there might be overconfidence from the red team about their tooling. Let's say that they've previously worked in other other sites of other types of of red team assignments and now they come to a finance sector uh entity for the first time that they are not really expecting that the typical baseline in security controls is a bit higher than in in

other types of businesses you know in the financial sector. So might they might be overconfident that our tooling has always worked. We're going to be deploying this and boom they get caught right out the gate. So this has happened and this is a of course a bit of an embarrassing learning point tool which is which is why I want to kind of like send out this message and warm that warn everyone that they they can be this can actually happen. And the last point here is about communication. So the control team is accountable for managing all the risks uh during the project and some of these tests are going to be um executed against targets and systems that have

never been pentested or red teamed in production ever before and they are dealing with payment transactions. So if anything goes wrong, if there's any hiccup there can be like serious monetary uh consequences. So it's a very delicate matter and the red teamers are expected to be serious people about you know considering that there is this risk and and you need to be careful how you dread about this but serious about how they communicate about their activities where they're at what are they planning to do next and what are the possible you know risks about the next steps and this communication h between the control team and the red team happens daily during the some phase

cases of the red team testing especially when they reach very close to the critical critical assets in the environment and not all good not all testers are good in communication. So so this is um uh a thing to to uh a lesson to learn or you know um to apply in your your projects also how to improve and make sure that the communication will work. Now I mentioned the legups previously and again we use that to maximize the progress during the testing phase and and by maximizing the progress we also maximize the learnings that we get from each of the project. Uh there's basically two categories of legups. So the one category is information and the other is access. So

the information is any any guidance that the control team can give to the red team by validating if they are on the correct path. what are the you know IP addresses or system names or database names or whatnot they should be looking for or um you know you know uh giving information about the network architecture or anything really that might help the red team to red team testers to focus on the right right things and not spending too much time in the dark. Uh the access legups are then concrete assistance that the red team testers might receive in form of getting accounts or new privileges or um you know physical access or maybe the control team will even help to to plant

you know u test malware in the system. So they would install it on behalf of the red team because the red team wasn't able to get the initial access otherwise. And in some cases, the control team might provide bypass mechanisms. For example, help them bypass a firewall or let's say that the control team really needs to get an get a foothold on a on a system that has an EDR, but they are not able to get a get past that EDR or it's it's deemed very risky. So, it might be possible that the control team will actually disable the EDR temporarily on that system to allow this red teaming activity. and not have the red team

testing spend weeks or months of time in in creating an exploit for that EDR tool. So, um these are always proposed by the by the uh testers and then the control team has to has to approve them. um it's getting really it's getting tougher and tougher for the control teams to provide these legups and the reason is that the IT change control and change management processes tend to be very strict nowadays. So imagine that some control team member like the CISO walks to an IT admin and tells them that by the way you need to punch holes to a firewall and I can't tell you why because it's a red team, right? So obviously that's not going to happen.

So, so how are the control teams going to work around this? It's a topic that you know we have blue teamers here in the audience. This is maybe one one learning point for you to take home also that at the same time it's good that you have strict processes but you need to kind of like build these mechanisms in your processes so that if exe executive management knows that now there's this you know red team exercise going on. They would have some kind of lever that they could activate and then implement these legup changes covertly in your in your environment. And the other other um hindrance is the uh the AM processes. So if the if the leg up would involve

the control team to create uh fake accounts in your environment or or give privileges to users that they shouldn't have. that can be increasingly difficult also because these AM changes are so well monitored and they can be you know steps of approvals that are normally required and all this automation is monitoring these changes. So similarly as as the other one you know something to consider how you're going to be enabling these red team tests uh going forward in your in your environ in your organization. Okay. So I I hope some of this was interesting and I think some some of these uh some of you in the audience might be looking to to become top

professionals in either cyber threat intelligence or or red teaming and and be kind of become part of uh delivering the type of projects. So what to do next? So the professional advice that I could give you then is to look out what the common professional development path might look like for these professions and keeping in mind that the people we really consider the core core team for these kind of deliveries are already at the top of their game. So they pretty they they are um um always very senior in their in their field already and tr don't try to skip the spokes in the ladder. I know that it can be frustrating for a junior person to be in

this field and and you're seeing that the the other guys are doing this very cool stuff, but I'm still the still um stuck with these support stuff and basic things. But this is really about u building your skills and and and um gaining that professional experience by doing the basic things first. And similarly of course for the red teaming red teaming you need to be becoming an expert in in pentesting first to become a champion in in red team testers. There's really no skipping that spoke in the latter. I want to highlight this this point last that um sometimes I see very you know um young professionals eager to get into this field and eager to get to the red

teaming but I kind of like recognize after discussing them that they they tend to think that they can somehow skip the point where they become experts in information technology first. So in my opinion at least of course this is not a rule but in my opinion you can't become an expert redteamer being an expert in networking operating systems applications how do all of those stuff work vulnerability vulnerable how those vulnerabilities can be exploited in pentests and then consider the becoming an expert in red teaming how these can be chained together uh to bypass the controls and defenses is in some of the most complex assignments you can you can get your hands on or participate in as a

consultant. That's a talk. Thank you very much for your attention. [Applause]

I think we're open to questions. Yeah.