Red Team Village - Executing Red Team Scenarios with Built-in Scenario Place
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Uyan, Erdener
Gülgün, Gökberk
Red Team activities are undoubtedly one of the fastest developing solutions against the cyber attacks of today. In this talk, we'll take a look at our work on an open-source proactive machine learning powered automation tool that performs red team simulations. This automation tool provides the opportunity to try out all available attack scenarios, thereby helping the community, especially organizations, to develop mechanisms to protect against these attacks before attackers do. Currently, red, blue and purple teams are improving day by day with the contributions made by open source. We will demonstrate the scenario playbook developed to collect the scenarios prepared for the red, blue and purple team on a single scenario place. The aim of this playbook is to protect the systems from such attack vectors, to examine the attack scenarios, to protect their systems by viewing the protection mechanisms and to contribute to these scenarios. With the built-in Scenario Place, people can either run these scenarios or check the scenario configurations on their systems. All scenario titles are prepared in accordance with MITRE and Cyber Kill Chain. All scenarios from various teams such as Atomic Red Team, Mitre and TIBER-EU are fed into the application as input.
 Hello, hello everyone. This is Ardena. I'm here with my colleague Gökberg. Hi. Thanks for joining our session. We are very excited to be part of the Red Team with you this year. The title of our session is Executing Red Team Scenarios with Built-in Scenario Place. First of all, let's start with introducing ourselves a little bit. Hi everyone. I am Gökberg. I am a penetration tester and red team operator. I have worked across a very tough industries including financial service and government service. Currently, I am working as an offensive security engineer at an industry leading bank. I plan and conduct full scope Red Team engagements that simulate realistic and targeted attacks. Also, I am responsible for performing host infrastructure penetration testing, web and mobile application testing, social engineering engagements, source code revives and wireless penetration tests. In the past, I have given several presentations on malware analysis, red team operations, exploit development and IoT security. Thank you Gökberg. And my name is Ardena. I have about 10 years of experience in IT and information security. During this time, I had a chance to work at research institutes, a Fortune 100 company and a bug bounty company. I took roles in development teams, in security operations and application security teams, that are focused on security tool development, penetration testing and vulnerability assessments. Currently, I am working as an application security engineer. Today, we are going to talk about our tool called Red Team Built-in Scenario Place. Also called Manticore platform. We are going to demonstrate how to execute some adversary emulation scenarios like a ransomware attack with these two. We'll start the discussion with a brief introduction to what MITRE attack framework is. Then we'll discuss the challenges concerning adversary emulation and these simulation tools, to show a little bit about why we needed to build, why we wanted to build such a tool. And later we'll talk about the features of this open source scenario place. Through the end, we will demo the tool and we are going to show the user interface, some scenario cards on it. And we will execute some sample scenarios like APT 29, LOL beans and a simplified ransomware scenario using the command line client. Finally, we will finish with the future work. Alright, let's start. So, as we all know, Red Team activities are one of the fastest developing solutions against today's cyber attacks. And recently the number of tools that propose to help Red Teams is increasing quite rapidly. And following this trend, we have also created an adversarial emulation tool for Red Teams. This is an open source tool and its aim is to aid a Red Team to execute several types of attack scenarios. It also gives more visibility to the blue teams to see what's being executed on their endpoints or what malicious traffic is going through their network during a Red Team exercise. So, the initial version of this tool was presented at the previous Red Team event back in May. And since then it has been improved with scenarios and it has been published on GitHub. Basically, we have categories of scenarios as network based and point based and APT group based. And there is also a section for blue team techniques showing some hardening controls related to executed scenarios. You can find the GitHub professor linked on the slides here. All the scenarios inside the repo that we are releasing are mapped to the MyTress attack framework. And the techniques and the tactics can be found in this framework. I'll talk about the framework in a minute. You will see the reference numbers, the attack IDs of the scenarios, of the techniques inside the configuration files for each scenario if you go to the GitHub repository. But we will go into detail about this. So, what is MyTress attack framework? Now, for those of you who see this for the first time, let me briefly explain it. This is when you visit this website attack.mitre.org, you see a matrix of items called attack matrix of enterprise. The columns of this matrix are tactics and tactics are mainly the objective of the attack attempt. The goal that an attacker tries to achieve. So, you can see 12 columns here. Each of them represents an attack goal. And under each attack goal, there are techniques. And each of these techniques has an attack ID with it. So, in total, there are 12 tactics listed in MyTress and these tactics have around 250 different techniques. This framework is a great knowledge base classifying these adversary tactics and techniques that are used to attack targets in real life. Of course, this framework is not only beneficial for red teamers, but also organizations are also benefiting from it to learn about the attack methods. And the framework is open to any person, an organization for use at no charge. And just like how OWASP's top-down framework is being embedded in most application security tools, a great resource like this one is becoming a fundamental reference of red teams and adversarial emulation tools. So, our open source tool is no exception for this. And as I said, there are 12 tactics, almost chronologically starting with the initial access and going to the impact goal of an attack. So, in the initial access part, the attacker is trying to penetrate the target. And then comes the execution, when the attacker is simply trying to run a malicious code. And the list goes on, actually. I'm not going into details a lot. Just to see some examples for techniques, let's take the execution tactic. So, for the execution tactic, there are 10 techniques listed underneath it. Some of these have some subcategories as well. The techniques listed here are about the methods that an attacker can use to run code, basically execute a code on a local or remote system to reach their main objective. This execution tactic is also often interconnected with other tactics. For example, as a red teamer, your execution technique of using command and scripting interpreter could be running a PowerShell script to perform a file download from a root server that will be used for the discovery goal. So, it would be related to the discovery goal in that sense. You can check out the market's website for more details. And we have seen that there are many great talks in the program about this framework. And we suggest that you check them for getting more insights about it. We just tried to mention the technique and tactic idea here, how we mapped it in R2. Next, the offensive teams have some common exercises like vulnerability assessments, penetration testing and adversarial emulation. Keeping the first two, the last one, adversarial emulation is what we focus actually right now. And it's an activity where the teamers, as the name refers, try to emulate or imitate how an adversary performs during a real life attack. The platform build demo here is focused on adversarial emulation. As I said, performed inside the network of an organization. So, in a way, you can think that initial access tactic has been achieved. And we are moving on to the other tactics. Therefore, we can say that this tool will be most useful for internal red teams or purple teams. Now, let's discuss some issues faced with adversarial emulation and what we want to see with this tool. So, it's not going to be an answer to all these problems. The tool is not going to be an answer to all these problems, but we think it's a step to solve some of them at least. First of all, emulating adversarial behavior is costly because their techniques are complex and requires time. And it's not common to see the tools created or used by malicious actors in the wild. That's why, adversarial emulation is an expensive exercise. Next thing is the scenario transparency. We have seen that adversarial emulation tools do not provide transparency in their scenarios. That's what we wanted to avoid by this tool. In our experience, we saw that there is a need for collaboration between red and blue teams, especially for internal security teams of big organizations. Blue teams cannot easily see the adversarial emulation behavior due to lack of a black-box nature of the red team's attacks. This causes a problem in terms of improving their incident response capabilities efficiently. Another problem is tool availability. While emulating adversaries, tool availability is another issue. Red teams cannot easily find the tools used by the malicious actors, just like we mentioned in the cost challenge. Therefore, bringing all publicly available scenarios together, we think it will be the best option for red teams. Repeatability is another issue in adversarial emulation. Why? Because sometimes during the red team engagement, a test may fail. But the device configuration may be changed at a later point by someone or by some service account. So, the same test may pass on another try. Therefore, it would be great to have some parts of adversarial emulation engagements automated, continuous and repeatable. It's nice to have a system where the security teams are able to schedule these tests to run as frequent intervals. Another issue is that adversarial emulation exercises have some malicious software used by the red teams. So, these malicious software can cause unexpected situations on corporate devices and networks. It's also a great idea to have visibility on which software will be used during the engagement. What's more, there are also some challenges with regards to other tools used by the red teams. Like, for the on-premise installation of simulation tools, updated attacks cannot easily be imported into the infrastructure, into the platforms. With these tools, the security engineer has the chance to point to a URI, to a repo where everything is up to date. Investigating different commercial or open source tools, we could get the idea, general idea of how many scenarios are available for a security team. So, we saw that there are about 2,000 scenarios in the wild and all of them cannot be reached from a single place. Most of the tools used for the emulation also do not take advantage of the open source government. Having a place of scenarios and risk by the red team community would be valuable to everyone. Reporting, on the other hand, is also another issue for the simulation tools. These tools do not provide enough information for understanding the attack surface and attack vectors. And finally, simulation tools are too complex for creating and updating scenarios. They don't have a general structure like a standard model for scenarios. We tried to standardize this by a scenario model in the JSON format that you can see in the slide. So, we have the ID specific to the scenario with the initials of the tactic used there, and the tactic names, the description and name of the scenario, and the mapping to the MITRE attack framework. We also have the type of the scenario, like is it an endpoint scenario, is it a network or an APT. And also describing the platform, the operating system that it targets. And so overall, the Mantcor platform, as we call it, this built-in scenario place has the following features. First of all, the tool and the methodology we use in emulating adversarial attacks with this tool is open source. And therefore, this is very cost-effective compared to commercial tools. We prepared a scenario environment that makes it faster and less complicated for red teamers. They can easily apply the tests from different open sources like atomic red team or red canary. It gives red teamers the access to the scenarios according to specific attack types as divided in MITRE categories. But more important, the blue teamers will be able to see these attacks within a transparent process. The config files clearly show the sources of threat scenarios and the payloads used within it. Of course, organizations may still prefer to perform the blind engagement, blind red team engagement, depending on their security maturity, but the team visible engagement plan can be much more helpful for most of the organizations. Blue teams, we talked about blue team detection and prevention to distribution of scenarios. While checking the scenarios, we saw that commercial and open source tools mostly have bias towards windows environments. And the number of scenarios is distributed like 60% windows and 20% for macOS and 20% for Linux environments. With the community support, it's possible to increase scenarios on the Mac and Linux side as well. And therefore, balancing this distribution would be a good product at the end. With this platform, APT scenarios can also be recreated and visible to both red teams and blue teams. Since everyone can contribute, red teams will have the chance to add advanced attack scenarios in their toolbox and build a community to protect and improve defense against attack and threat scenarios. Now I will stop sharing the screen and your pair is going to tell you how we structured this tool, showing the GitHub repository and finally the more exciting part. We will show the demo of the tool and we'll finally talk about our future work. Hello again. Now we will look at, we will continue with the presentation. Now we will look at public threat repository. For this presentation, we released some complex scenarios on our GitHub account. We are mapping these scenarios to the Mitre. So far, we published three complex scenarios named as APT29, LOE beans and ransomware. Next, this public repository includes public the known scenarios. You can see this on our GitHub repository. Later, we will go deeply into it. In the next slides, we will look at public threat scenarios, public scenario repository. We released threat scenarios on our GitHub account. All scenarios are again prepared with triggers to Mitre. From these scenarios, complex scenario groups are generated. For example, if you look at ransomware emulation, ransomware emulation includes two scenarios included in public scenario repository. It has two JSON files with their IDs. These include attack type, attack perils and platform information. I will show you later that. For ransomware emulation, in this section, we will look at ransomware emulation scenarios for generating public scenarios. We have two different implementations for ransomware emulation. One of them is written by Go. The other one is PowerShell based. This released implementation is not covering all steps of real ransomware attack, but this is on purpose. Because we wanted to release a simplified implementation of this scenario. There is no CC or server communication or encrypting all files. We are encrypting a file that we create on the fly and decrypt it in this file. Adding the few missing points, these implementations can be converted to full ransomware emulation. Yet, our aims is to test if a defense mechanism could prevent the core function of ransomware which is encrypting files. In this section, we will speak about Mantra Adversary Emulation CLI Tool. This tool is working with public threat scenarios which I showed earlier in another repository. As we said before, we have seen that Adversary Emulation Tools do not provide transparency in some of their scenarios. Here, we publish command line based Adversary Emulation Tool that is fully open source to bring some visibility to how emulation works. All threats and scenarios are public and configurable. Red Teamers, Blue Teamers can easily edit this tool according to their aim. Also, this CLI is developed in Go language for achieving multiple platform execution. This tool includes single config line which is shown here, public scenarios, payloads and threats. With this config line, command line based tool emulates adversary. Now, we will look at our demo for this presentation. We have one remote machine and we will run Adversary Emulation Scenarios here. For looking scenarios which are used by the CLI Tool, here we can see public threat repository. Here, we can see three different kinds of scenario collection. There are many scenarios in our backlog and we are importing all of these gradually and these scenarios can be easily updated. The all kind of scenarios is compatible with Mitre. Firstly, we will look at our built-in scenario place before the demo. Demo of the CLI Tool. Here, we can see which is shown in our public GitHub repository scenarios. We can see here too. For example, for PowerShell, one of the example scenarios, execute PowerShell from the CMDXA. Executable to collect and compress files of specific extensions. It is used by the Windows platforms. It is designed for the Windows platforms. There, we can see Mitre tags, Mitre tag name. Also, we can go into the scenario here. If we go here, we can see scenario. If we click it on it, we can see there is a simple structure of the JListetage scenario. Here, the technique, attack ID, name, type, platform and command and interface. You can see here, PowerShell is the interface. Also, you can see here the ID. Also, we said before too, we have many scenarios in our backlog. We will try to import all of these scenarios and we will publish them to Red Timers, Blue Timers, Purple Timers. For now, we will execute the scenarios with our CLI tool instead of using interface. Next, we will look at our CLI tool, which is published on GitHub repository again. Here, we can see our Adversary Emulation Client CLI tool. You can easily compile this on your own infrastructure. Also, for ease of use, we publish the release. Here, you can go into the release and you can download config.ini file and you can download Mantikor CLI executable. You can run this executable with config.ini file, within same directory. Config.ini file includes three components. One of them is public thread group URL, which is used for complex scenario collection. Other one is public thread scenario URL section. It shows thread scenario repository. Last one is the payload location, which is used for scenario payloads. For execution, as we told before, you simply compile or download executable and config.ini file. You cite necessary URLs for parsing repository on the platform. In the thread group URL, you can give multiple URLs for emulation as it accepts an array of URLs. Now, we will firstly emulate LOI BINCE emulation for doblanding a file from a remote server. As we can see here, we give thread group URL. We are coming our tools. Here, our config.ini file and Mantikor CLI executable. When we run it, emulation is starting. Here, we have some connection problems here. I will connect again. If we can see here, you can see LOI BINCE emulation binaries for doblanding malicious executable. One of them is using Sartutil for doblanding a file from a remote server. In the description, we can see this steps doblanding a file from a remote web server to host using Sartutil. Also, we have a different second scenario uses bitsadmin.executable to dobland a file from a remote server. And scenario that can be seen here. Next, we will emulate ransomware which is published on the Mantikor Github repository. If we go there, clearly we can see it includes two phases. And for generating these scenarios we used ransomware emulation repository. One of them is GO base ransomware emulation. Second one is PowerShell base ransomware emulation. If we edit our thread group URL. Then we are running our CLI again. Firstly, GO base multiplatform ransomware emulation is simulated. Also, secondly, PowerShell base ransomware emulation is simulated. For example, if we look at the first scenario, first isk is generated, then encrypted isk is generated via public k, then decrypted isk via generated private k. Then here we can see encrypted file content and decrypted file content here. And we can finally see the scenario result here. If you wonder for example, ransom emulation executable here listed. It is, as we said before, it is compiled from this repository. You can easily compile that and you can run in your infrastructure. Finally, we will add APT29 emulation URL in config file which does not show all scenarios, but few of them we will try to emulate. For being clear, if we go into APT21 JSON file, there we can see different scenario phases and you can easily go into the it in our GitHub repository. For example, in one of the example screen capture native api calls were used to collect a screenshot. It imports to get screenshot ps.phile, then called the function and we will emulate now this one. We are closing that. I will check config file again. Here we can see scenario execution is continuing. Here we completed partially APT29 emulation. There is a, as we told before, it is partial. We have a different kind of scenarios. You can clearly go down in the GitHub repository. We are trying to generate, we will try to import all available scenarios into our platform. Easily people can reach them and they can generate complex scenarios from them. If we go into the content, our slides. For the feature work, we are continuing to add all available scenarios to the repository. We are also working on the feature of running scheduled scenarios throughout the UI. Another plan is the integrate our threat intelligence framework into this scenario tool to contribute to the scenario generation and attack prevention. For the public release, we will add reporting feature that will be added. On the other hand, for achieving purple team, we will add security management software integration into our CLI tool and UI user interface. So, the red team, blue team can query which scenario is detected or prevented. In the next, we are waiting for the community support for this tool. Thanks for listening. If you have any questions, please ask us live in Discord. Also, you can reach us if you want from this email address. Also, we are waiting for your support on our GitHub platform. Thank you so much again.
 Hello, hello everyone. This is Ardena. I'm here with my colleague Gökberg.  Hi.  Thanks for joining our session. We are very excited to be part of the Red Team with you this year.  The title of our session is Executing Red Team Scenarios with Built-in Scenario Place.  First of all, let's start with introducing ourselves a little bit.  Hi everyone. I am Gökberg. I am a penetration tester and red team operator.  I have worked across a very tough industries including financial service and government service.  Currently, I am working as an offensive security engineer at an industry leading bank.  I plan and conduct full scope Red Team engagements that simulate realistic and targeted attacks.  Also, I am responsible for performing host infrastructure penetration testing, web and mobile application testing,  social engineering engagements, source code revives and wireless penetration tests.  In the past, I have given several presentations on malware analysis, red team operations,  exploit development and IoT security.  Thank you Gökberg. And my name is Ardena. I have about 10 years of experience in IT and information security.  During this time, I had a chance to work at research institutes, a Fortune 100 company and a bug bounty company.  I took roles in development teams, in security operations and application security teams,  that are focused on security tool development, penetration testing and vulnerability assessments.  Currently, I am working as an application security engineer.  Today, we are going to talk about our tool called Red Team Built-in Scenario Place.  Also called Manticore platform.  We are going to demonstrate how to execute some adversary emulation scenarios like a ransomware attack with these two.  We'll start the discussion with a brief introduction to what MITRE attack framework is.  Then we'll discuss the challenges concerning adversary emulation and these simulation tools,  to show a little bit about why we needed to build, why we wanted to build such a tool.  And later we'll talk about the features of this open source scenario place.  Through the end, we will demo the tool and we are going to show the user interface, some scenario cards on it.  And we will execute some sample scenarios like APT 29, LOL beans and a simplified ransomware scenario using the command line client.  Finally, we will finish with the future work.  Alright, let's start.  So, as we all know, Red Team activities are one of the fastest developing solutions against today's cyber attacks.  And recently the number of tools that propose to help Red Teams is increasing quite rapidly.  And following this trend, we have also created an adversarial emulation tool for Red Teams.  This is an open source tool and its aim is to aid a Red Team to execute several types of attack scenarios.  It also gives more visibility to the blue teams to see what's being executed on their endpoints or what malicious traffic is going through their network during a Red Team exercise.  So, the initial version of this tool was presented at the previous Red Team event back in May.  And since then it has been improved with scenarios and it has been published on GitHub.  Basically, we have categories of scenarios as network based and point based and APT group based.  And there is also a section for blue team techniques showing some hardening controls related to executed scenarios.  You can find the GitHub professor linked on the slides here.  All the scenarios inside the repo that we are releasing are mapped to the MyTress attack framework.  And the techniques and the tactics can be found in this framework.  I'll talk about the framework in a minute.  You will see the reference numbers, the attack IDs of the scenarios, of the techniques inside the configuration files for each scenario if you go to the GitHub repository.  But we will go into detail about this.  So, what is MyTress attack framework?  Now, for those of you who see this for the first time, let me briefly explain it.  This is when you visit this website attack.mitre.org, you see a matrix of items called attack matrix of enterprise.  The columns of this matrix are tactics and tactics are mainly the objective of the attack attempt.  The goal that an attacker tries to achieve. So, you can see 12 columns here.  Each of them represents an attack goal.  And under each attack goal, there are techniques.  And each of these techniques has an attack ID with it.  So, in total, there are 12 tactics listed in MyTress and these tactics have around 250 different techniques.  This framework is a great knowledge base classifying these adversary tactics and techniques that are used to attack targets in real life.  Of course, this framework is not only beneficial for red teamers, but also organizations are also benefiting from it to learn about the attack methods.  And the framework is open to any person, an organization for use at no charge.  And just like how OWASP's top-down framework is being embedded in most application security tools,  a great resource like this one is becoming a fundamental reference of red teams and adversarial emulation tools.  So, our open source tool is no exception for this.  And as I said, there are 12 tactics, almost chronologically starting with the initial access and going to the impact goal of an attack.  So, in the initial access part, the attacker is trying to penetrate the target.  And then comes the execution, when the attacker is simply trying to run a malicious code.  And the list goes on, actually. I'm not going into details a lot.  Just to see some examples for techniques, let's take the execution tactic.  So, for the execution tactic, there are 10 techniques listed underneath it.  Some of these have some subcategories as well.  The techniques listed here are about the methods that an attacker can use to run code,  basically execute a code on a local or remote system to reach their main objective.  This execution tactic is also often interconnected with other tactics.  For example, as a red teamer, your execution technique of using command and scripting interpreter could be running a PowerShell script  to perform a file download from a root server that will be used for the discovery goal.  So, it would be related to the discovery goal in that sense.  You can check out the market's website for more details.  And we have seen that there are many great talks in the program about this framework.  And we suggest that you check them for getting more insights about it.  We just tried to mention the technique and tactic idea here, how we mapped it in R2.  Next, the offensive teams have some common exercises like vulnerability assessments,  penetration testing and adversarial emulation.  Keeping the first two, the last one, adversarial emulation is what we focus actually right now.  And it's an activity where the teamers, as the name refers, try to emulate or imitate how an adversary performs during a real life attack.  The platform build demo here is focused on adversarial emulation.  As I said, performed inside the network of an organization.  So, in a way, you can think that initial access tactic has been achieved.  And we are moving on to the other tactics.  Therefore, we can say that this tool will be most useful for internal red teams or purple teams.  Now, let's discuss some issues faced with adversarial emulation and what we want to see with this tool.  So, it's not going to be an answer to all these problems.  The tool is not going to be an answer to all these problems, but we think it's a step to solve some of them at least.  First of all, emulating adversarial behavior is costly because their techniques are complex and requires time.  And it's not common to see the tools created or used by malicious actors in the wild.  That's why, adversarial emulation is an expensive exercise.  Next thing is the scenario transparency.  We have seen that adversarial emulation tools do not provide transparency in their scenarios.  That's what we wanted to avoid by this tool.  In our experience, we saw that there is a need for collaboration between red and blue teams,  especially for internal security teams of big organizations.  Blue teams cannot easily see the adversarial emulation behavior due to lack of a black-box nature of the red team's attacks.  This causes a problem in terms of improving their incident response capabilities efficiently.  Another problem is tool availability.  While emulating adversaries, tool availability is another issue.  Red teams cannot easily find the tools used by the malicious actors, just like we mentioned in the cost challenge.  Therefore, bringing all publicly available scenarios together, we think it will be the best option for red teams.  Repeatability is another issue in adversarial emulation.  Why? Because sometimes during the red team engagement, a test may fail.  But the device configuration may be changed at a later point by someone or by some service account.  So, the same test may pass on another try.  Therefore, it would be great to have some parts of adversarial emulation engagements automated, continuous and repeatable.  It's nice to have a system where the security teams are able to schedule these tests to run as frequent intervals.  Another issue is that adversarial emulation exercises have some malicious software used by the red teams.  So, these malicious software can cause unexpected situations on corporate devices and networks.  It's also a great idea to have visibility on which software will be used during the engagement.  What's more, there are also some challenges with regards to other tools used by the red teams.  Like, for the on-premise installation of simulation tools, updated attacks cannot easily be imported into the infrastructure, into the platforms.  With these tools, the security engineer has the chance to point to a URI, to a repo where everything is up to date.  Investigating different commercial or open source tools, we could get the idea, general idea of how many scenarios are available for a security team.  So, we saw that there are about 2,000 scenarios in the wild and all of them cannot be reached from a single place.  Most of the tools used for the emulation also do not take advantage of the open source government.  Having a place of scenarios and risk by the red team community would be valuable to everyone.  Reporting, on the other hand, is also another issue for the simulation tools.  These tools do not provide enough information for understanding the attack surface and attack vectors.  And finally, simulation tools are too complex for creating and updating scenarios.  They don't have a general structure like a standard model for scenarios.  We tried to standardize this by a scenario model in the JSON format that you can see in the slide.  So, we have the ID specific to the scenario with the initials of the tactic used there,  and the tactic names, the description and name of the scenario, and the mapping to the MITRE attack framework.  We also have the type of the scenario, like is it an endpoint scenario, is it a network or an APT.  And also describing the platform, the operating system that it targets.  And so overall, the Mantcor platform, as we call it, this built-in scenario place has the following features.  First of all, the tool and the methodology we use in emulating adversarial attacks with this tool is open source.  And therefore, this is very cost-effective compared to commercial tools.  We prepared a scenario environment that makes it faster and less complicated for red teamers.  They can easily apply the tests from different open sources like atomic red team or red canary.  It gives red teamers the access to the scenarios according to specific attack types as divided in MITRE categories.  But more important, the blue teamers will be able to see these attacks within a transparent process.  The config files clearly show the sources of threat scenarios and the payloads used within it.  Of course, organizations may still prefer to perform the blind engagement, blind red team engagement,  depending on their security maturity, but the team visible engagement plan can be much more helpful for most of the organizations.  Blue teams, we talked about blue team detection and prevention to distribution of scenarios.  While checking the scenarios, we saw that commercial and open source tools mostly have bias towards windows environments.  And the number of scenarios is distributed like 60% windows and 20% for macOS and 20% for Linux environments.  With the community support, it's possible to increase scenarios on the Mac and Linux side as well.  And therefore, balancing this distribution would be a good product at the end.  With this platform, APT scenarios can also be recreated and visible to both red teams and blue teams.  Since everyone can contribute, red teams will have the chance to add advanced attack scenarios in their toolbox and build a community to protect and improve defense against attack and threat scenarios.  Now I will stop sharing the screen and your pair is going to tell you how we structured this tool, showing the GitHub repository and finally the more exciting part.  We will show the demo of the tool and we'll finally talk about our future work.  Hello again.  Now we will look at, we will continue with the presentation.  Now we will look at public threat repository. For this presentation, we released some complex scenarios on our GitHub account.  We are mapping these scenarios to the Mitre.  So far, we published three complex scenarios named as APT29, LOE beans and ransomware.  Next, this public repository includes public the known scenarios.  You can see this on our GitHub repository.  Later, we will go deeply into it.  In the next slides, we will look at public threat scenarios, public scenario repository.  We released threat scenarios on our GitHub account.  All scenarios are again prepared with triggers to Mitre.  From these scenarios, complex scenario groups are generated.  For example, if you look at ransomware emulation, ransomware emulation includes two scenarios included in public scenario repository.  It has two JSON files with their IDs.  These include attack type, attack perils and platform information.  I will show you later that.  For ransomware emulation, in this section, we will look at ransomware emulation scenarios for generating public scenarios.  We have two different implementations for ransomware emulation.  One of them is written by Go.  The other one is PowerShell based.  This released implementation is not covering all steps of real ransomware attack, but this is on purpose.  Because we wanted to release a simplified implementation of this scenario.  There is no CC or server communication or encrypting all files.  We are encrypting a file that we create on the fly and decrypt it in this file.  Adding the few missing points, these implementations can be converted to full ransomware emulation.  Yet, our aims is to test if a defense mechanism could prevent the core function of ransomware which is encrypting files.  In this section, we will speak about Mantra Adversary Emulation CLI Tool.  This tool is working with public threat scenarios which I showed earlier in another repository.  As we said before, we have seen that Adversary Emulation Tools do not provide transparency in some of their scenarios.  Here, we publish command line based Adversary Emulation Tool that is fully open source to bring some visibility to how emulation works.  All threats and scenarios are public and configurable.  Red Teamers, Blue Teamers can easily edit this tool according to their aim.  Also, this CLI is developed in Go language for achieving multiple platform execution.  This tool includes single config line which is shown here, public scenarios, payloads and threats.  With this config line, command line based tool emulates adversary.  Now, we will look at our demo for this presentation.  We have one remote machine and we will run Adversary Emulation Scenarios here.  For looking scenarios which are used by the CLI Tool, here we can see public threat repository.  Here, we can see three different kinds of scenario collection.  There are many scenarios in our backlog and we are importing all of these gradually and these scenarios can be easily updated.  The all kind of scenarios is compatible with Mitre.  Firstly, we will look at our built-in scenario place before the demo.  Demo of the CLI Tool.  Here, we can see which is shown in our public GitHub repository scenarios.  We can see here too.  For example, for PowerShell, one of the example scenarios, execute PowerShell from the CMDXA.  Executable to collect and compress files of specific extensions.  It is used by the Windows platforms.  It is designed for the Windows platforms.  There, we can see Mitre tags, Mitre tag name.  Also, we can go into the scenario here.  If we go here, we can see scenario.  If we click it on it, we can see there is a simple structure of the JListetage scenario.  Here, the technique, attack ID, name, type, platform and command and interface.  You can see here, PowerShell is the interface.  Also, you can see here the ID.  Also, we said before too, we have many scenarios in our backlog.  We will try to import all of these scenarios and we will publish them to Red Timers, Blue Timers, Purple Timers.  For now, we will execute the scenarios with our CLI tool instead of using interface.  Next, we will look at our CLI tool, which is published on GitHub repository again.  Here, we can see our Adversary Emulation Client CLI tool.  You can easily compile this on your own infrastructure. Also, for ease of use, we publish the release.  Here, you can go into the release and you can download config.ini file and you can download Mantikor CLI executable.  You can run this executable with config.ini file, within same directory.  Config.ini file includes three components. One of them is public thread group URL, which is used for complex scenario collection.  Other one is public thread scenario URL section.  It shows thread scenario repository.  Last one is the payload location, which is used for scenario payloads.  For execution, as we told before, you simply compile or download executable and config.ini file.  You cite necessary URLs for parsing repository on the platform.  In the thread group URL, you can give multiple URLs for emulation as it accepts an array of URLs.  Now, we will firstly emulate LOI BINCE emulation for doblanding a file from a remote server.  As we can see here, we give thread group URL.  We are coming our tools. Here, our config.ini file and Mantikor CLI executable.  When we run it, emulation is starting.  Here, we have some connection problems here.  I will connect again.  If we can see here, you can see LOI BINCE emulation binaries for doblanding malicious executable.  One of them is using Sartutil for doblanding a file from a remote server.  In the description, we can see this steps doblanding a file from a remote web server to host using Sartutil.  Also, we have a different second scenario uses bitsadmin.executable to dobland a file from a remote server.  And scenario that can be seen here.  Next, we will emulate ransomware which is published on the Mantikor Github repository.  If we go there, clearly we can see it includes two phases.  And for generating these scenarios we used ransomware emulation repository.  One of them is GO base ransomware emulation.  Second one is PowerShell base ransomware emulation.  If we edit our thread group URL.  Then we are running our CLI again.  Firstly, GO base multiplatform ransomware emulation is simulated.  Also, secondly, PowerShell base ransomware emulation is simulated.  For example, if we look at the first scenario, first isk is generated, then encrypted isk is generated via public k, then decrypted isk via generated private k.  Then here we can see encrypted file content and decrypted file content here.  And we can finally see the scenario result here.  If you wonder for example, ransom emulation executable here listed.  It is, as we said before, it is compiled from this repository.  You can easily compile that and you can run in your infrastructure.  Finally, we will add APT29 emulation URL in config file which does not show all scenarios, but few of them we will try to emulate.  For being clear, if we go into APT21 JSON file, there we can see different scenario phases and you can easily go into the it in our GitHub repository.  For example, in one of the example screen capture native api calls were used to collect a screenshot.  It imports to get screenshot ps.phile, then called the function and we will emulate now this one.  We are closing that.  I will check config file again.  Here we can see scenario execution is continuing.  Here we completed partially APT29 emulation.  There is a, as we told before, it is partial.  We have a different kind of scenarios.  You can clearly go down in the GitHub repository.  We are trying to generate, we will try to import all available scenarios into our platform.  Easily people can reach them and they can generate complex scenarios from them.  If we go into the content, our slides.  For the feature work, we are continuing to add all available scenarios to the repository.  We are also working on the feature of running scheduled scenarios throughout the UI.  Another plan is the integrate our threat intelligence framework into this scenario tool to contribute to the scenario generation and attack prevention.  For the public release, we will add reporting feature that will be added.  On the other hand, for achieving purple team, we will add security management software integration into our CLI tool and UI user interface.  So, the red team, blue team can query which scenario is detected or prevented.  In the next, we are waiting for the community support for this tool.  Thanks for listening.  If you have any questions, please ask us live in Discord.  Also, you can reach us if you want from this email address.  Also, we are waiting for your support on our GitHub platform.  Thank you so much again.
DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_0_659.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_660_7943.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_7944_10799.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_10800_11603.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_11604_13811.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_13812_22907.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_22908_27503.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_27504_27563.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_27564_27647.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_27648_27695.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_27696_28679.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_28680_31451.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_31452_33371.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_33372_33587.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_33588_33635.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_33636_33863.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_33864_34871.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_34872_40511.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_40512_40859.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_40860_41255.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_41256_41327.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_41328_41387.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_41388_41447.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_41448_41519.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_41520_41687.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_41688_41795.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_41796_41939.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_41940_42023.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_42024_42083.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_42084_42347.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_42348_42983.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_42984_43043.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_43044_43127.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_43128_44423.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_44424_48107.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_48108_48323.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_48324_48395.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_48396_48527.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_48528_49427.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_49428_50579.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_50580_50687.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_50688_52439.png DEF_CON_Safe_Mode_Red_Team_Village_-_Erdener_Uyan__QouX0zVE434_52440_52976.png