[00:02.340 --> 00:06.800]  Hello, my name is Pablo González and this is my colleague, Fran Ramírez.
[00:06.800 --> 00:09.640]  We are proud to introduce the ATTPound,
[00:09.640 --> 00:13.480]  Adversarial Emulation and Offensive Technical Collaborative Project.
[00:13.500 --> 00:16.420]  We are proud to be at DEF CON this year.
[00:16.460 --> 00:19.420]  Besides, we like very much the offensive part,
[00:19.420 --> 00:23.600]  and that's why we bring a tool called ATTPound,
[00:23.600 --> 00:27.020]  which helps to perform the emulation of adversaries.
[00:27.560 --> 00:30.840]  Also, we want to tell you about the collaborative
[00:31.300 --> 00:33.500]  side of the project.
[00:33.540 --> 00:37.560]  First of all, let's introduce ourselves.
[00:38.680 --> 00:40.680]  I am Pablo González.
[00:40.680 --> 00:45.340]  I work at Telefónica in Spain in the pre-innovation department,
[00:45.340 --> 00:50.600]  where we are very lucky to play with cybersecurity and artificial intelligence.
[00:50.860 --> 00:55.500]  We develop several open source tools and AGIAR,
[00:55.500 --> 00:58.780]  and try to contribute with crazy ideas.
[00:58.780 --> 01:02.640]  I am MVP of Microsoft since 2017.
[01:03.020 --> 01:07.360]  I have written some books in Spanish about cybersecurity,
[01:07.360 --> 01:12.420]  and I am a teacher at several universities in Spain.
[01:13.000 --> 01:16.940]  My partner, Fran Ramírez, works with me at Telefónica
[01:16.940 --> 01:19.720]  in the same pre-innovation department,
[01:19.720 --> 01:23.400]  focusing on cybersecurity and machine learning projects.
[01:23.400 --> 01:29.240]  He has worked several years in the USA as a system administrator,
[01:29.240 --> 01:34.180]  and has written some books about Docker and machine learning.
[01:34.440 --> 01:40.920]  Before we discuss the tool and show the use cases first-hand,
[01:40.920 --> 01:44.060]  let's have a look at the ATT&CK.
[01:47.480 --> 01:52.600]  The emulation of adversaries has become extremely important in the Red Team world.
[01:52.600 --> 01:57.680]  It's an exercise that provides a glimpse into the potential for a real threat,
[01:57.680 --> 02:02.520]  like many others that both business and society have experienced,
[02:02.520 --> 02:04.720]  to affect an organization.
[02:04.720 --> 02:10.980]  The goal is to be capable of verifying if the organization controls are efficient and effective
[02:10.980 --> 02:17.080]  by detecting the threats or displaying weaponry weakness in response to them.
[02:17.200 --> 02:21.100]  The purpose of a Red Team exercise are the following.
[02:21.100 --> 02:24.520]  Demonstration of the exposure-run risk level.
[02:24.520 --> 02:26.340]  Demonstration of the business impact.
[02:26.340 --> 02:28.920]  Demonstration of the prevention capabilities.
[02:28.920 --> 02:31.280]  Demonstration of the detection capabilities.
[02:31.280 --> 02:35.360]  Demonstration of the capabilities of reacting or addressing incidents.
[02:35.640 --> 02:39.400]  Now, we are going to speak about ATT&CK.
[02:39.940 --> 02:44.560]  Mitre ATT&CK is a database containing the most common techniques,
[02:44.560 --> 02:47.880]  tactics, and methods being used by attackers.
[02:47.880 --> 02:51.660]  Tactics are the high-level vectors of ATT&CK.
[02:52.020 --> 02:55.720]  The techniques represent the implementation of methods of ATT&CK.
[02:55.720 --> 02:58.600]  The organizations can perform an adversarial emulation
[02:58.600 --> 03:02.940]  and keep mapping the security controls that are applied to the techniques.
[03:02.940 --> 03:08.740]  Organizations can also have several security controls related to a given technique.
[03:09.100 --> 03:12.100]  The goal is to verify the performance and efficiency
[03:12.100 --> 03:15.940]  as regards the security control by techniques implemented.
[03:16.720 --> 03:22.960]  The Mitre ATT&CK framework takes on the security bridge.
[03:23.360 --> 03:27.600]  So, the starting point is the original intrusion tactic.
[03:27.600 --> 03:30.420]  Any activity that has been previously carried out
[03:30.760 --> 03:37.040]  will be covered by a framework called Mitre ATT&CK.
[03:39.480 --> 03:44.100]  Now, let's find out more about ATTBOUND.
[03:44.100 --> 03:47.380]  ATTBOUND is a computer security tool designed to emulate
[03:48.330 --> 03:52.780]  the tool aims to bring emulation of a real threat into closer contact with
[03:52.780 --> 03:58.040]  implementation based on the techniques and tactics from the Mitre ATT&CK framework.
[03:58.040 --> 04:02.940]  The goal is to simulate how a threat works in an intrusion scenario
[04:03.880 --> 04:08.080]  where the threat has been successfully deployed.
[04:08.220 --> 04:13.220]  It's focused on Microsoft Windows systems through the use of the PowerShell command line.
[04:13.220 --> 04:18.400]  This enables the different techniques based on Mitre ATT&CK to be applied.
[04:18.480 --> 04:23.360]  ATTBOUND is designed to allow the emulation of adversaries as for a red team exercise
[04:23.360 --> 04:32.020]  and to verify the effectiveness and efficiency of the organization control in the face of a real threat.
[04:32.140 --> 04:35.280]  What is the ATTBOUND core? PowerShell.
[04:36.060 --> 04:41.560]  PowerShell is released along with Microsoft Windows Vista.
[04:42.200 --> 04:49.520]  It's not natively embedded in the operating system which makes it very interesting for both
[04:49.520 --> 04:54.100]  IT administrators and pen testers.
[04:54.100 --> 05:01.300]  Its new version includes a large number of new features and modules that will help
[05:01.300 --> 05:08.160]  to integrate interestingly with the operating system and its many tools.
[05:08.720 --> 05:16.580]  And the first version was released in 2006.
[05:16.860 --> 05:18.740]  The first stable version.
[05:18.740 --> 05:25.960]  Okay, two versions appeared in 2009 with the release of Windows 7.
[05:25.960 --> 05:34.420]  Version 3 appeared in 2012 with the release of Windows 8.
[05:34.950 --> 05:43.650]  Later, the last version, version 7, appeared in the year 2020.
[05:47.400 --> 05:53.120]  The idea underlying ATTBOUND to link the Mitre ATT&CK framework along with the techniques that
[05:53.120 --> 05:57.040]  are implemented via the Microsoft Windows PowerShell command line.
[05:57.040 --> 06:03.580]  The many techniques implemented to using PowerShell support a high percentage of techniques
[06:03.580 --> 06:08.960]  laced in the ATT&CK matrix that can be replicated.
[06:09.280 --> 06:11.900]  The project is also collaborative.
[06:11.900 --> 06:21.540]  It means that the user can have his initial knowledge base based on ATT&CK but can import
[06:21.540 --> 06:28.580]  new implementations of the techniques used in PowerShell and relaunch them using the
[06:28.580 --> 06:30.980]  techniques and tactics in the file.
[06:30.980 --> 06:37.680]  We have used JSON format files to export this new code knowledge and import it in other
[06:37.680 --> 06:41.160]  environments where ATTBOUND has been deployed.
[06:41.160 --> 06:45.480]  In this way, the comparative knowledge has become very significant.
[06:46.200 --> 06:52.880]  This facilitates multiple users to share knowledge between separate environments.
[06:52.880 --> 06:57.800]  The techniques are dynamic elements that are emerging through the evolution of offensive
[06:57.800 --> 06:58.720]  security.
[06:59.800 --> 07:06.760]  Now, my colleague, Fran Ramirez, is going to give you a little insight into ATTBOUND.
[07:07.860 --> 07:09.960]  Okay, thank you, Pablo.
[07:09.960 --> 07:11.600]  And hello, everyone.
[07:11.600 --> 07:16.800]  Now, let's see what the architecture of ATTBOUND looks like.
[07:18.640 --> 07:22.500]  ATTBOUND has three main different components.
[07:22.680 --> 07:25.700]  The first one is the console.
[07:25.700 --> 07:32.900]  That is the PowerShell code that will be running on the Windows machines emulating the treat.
[07:34.580 --> 07:41.320]  After this code is executed on Windows machines, it connects towards a command and control
[07:41.320 --> 07:45.720]  and it waits for the adversary's commands to be emulated.
[07:47.240 --> 07:50.580]  The second one are the functions.
[07:51.240 --> 07:58.260]  These are the technical implementations that are mapped in Mitre, ATT, and CK.
[07:59.140 --> 08:06.960]  This is interesting since any user can create their functions written in PowerShell.
[08:07.460 --> 08:14.160]  This makes ATTBOUND collaborative and a project where any user can contribute with their
[08:14.160 --> 08:18.460]  knowledge in the form of technical implementations.
[08:19.140 --> 08:25.200]  All the functions will be carried out by the console when it is executed through Windows
[08:25.200 --> 08:26.050]  machines.
[08:28.850 --> 08:33.410]  And the last one is the command and control MVC or C2.
[08:34.010 --> 08:37.050]  This is the ATTBOUND control panel.
[08:37.810 --> 08:42.780]  From this panel, you can set up the treat or adversary to be emulated.
[08:45.240 --> 08:51.160]  You can use already pre-setup treats or you can build new treats or tests.
[08:55.500 --> 09:01.080]  The tool's knowledge can be imported and exported from this panel since the user can
[09:01.080 --> 09:06.780]  create its content in the form of an implementation of a technique in PowerShell.
[09:10.070 --> 09:15.670]  In other words, a basic architecture scheme has two main elements from the networking
[09:15.670 --> 09:16.950]  point of view.
[09:18.590 --> 09:21.250]  The first is the agent or warrior.
[09:21.990 --> 09:27.950]  It's the adversarial emulation and its code is in PowerShell.
[09:29.930 --> 09:33.710]  The second one is the root node or command and control.
[09:34.570 --> 09:40.330]  From this web application, it is possible to manage the application of the treat to
[09:40.330 --> 09:43.530]  be simulated by the different deployed warriors.
[09:44.510 --> 09:51.070]  Also, you can manage the results of the emulation and make decisions about the controls.
[09:52.290 --> 09:58.430]  Everything is fully connected with the identifiers of the ATT and CK metrics.
[10:00.770 --> 10:05.550]  Again, from the networking point of view, the deployment of warriors over the network
[10:05.550 --> 10:09.230]  will be accomplished through different options.
[10:09.690 --> 10:14.830]  Remote invocation through the network privilege, invocation of remote machine without privilege,
[10:14.830 --> 10:16.670]  lock and invocation, etc.
[10:20.120 --> 10:26.760]  It is commendable not to include more than 10 or 15 computers in this process, as indicated
[10:26.760 --> 10:28.780]  by the ATT and CK.
[10:33.180 --> 10:40.360]  These exercises are simulation, but you must have a real as possible environment for better
[10:40.360 --> 10:42.020]  results.
[10:45.610 --> 10:49.330]  Okay, and now let's talk about the operational flows.
[10:52.090 --> 10:57.810]  These are the different flows between the console or agent and the ATT bound command
[10:57.810 --> 10:59.090]  and control.
[11:01.130 --> 11:04.250]  The first flow is the connection flow.
[11:04.570 --> 11:09.950]  When a console is running on a Windows machine, it sends a high command.
[11:12.860 --> 11:18.820]  When the console is running, it gathers information from the machine and then passes it on the
[11:18.820 --> 11:21.680]  control panel through this packet.
[11:25.640 --> 11:31.080]  During the warrior generation, the IP address to be connected must be specified.
[11:32.680 --> 11:35.600]  But this is discussed further below.
[11:37.040 --> 11:45.340]  When the warrior needs to register as a compromised computer, it sends a request through the
[11:45.340 --> 11:52.960]  HTTP POST method of the root node, stating the warrior ID and the collected information
[11:52.960 --> 11:54.520]  from the computer.
[11:58.050 --> 12:04.970]  When this information is received by the root node, the data will be stored into the database
[12:04.970 --> 12:08.910]  and will be made available for the user.
[12:09.430 --> 12:15.710]  That is, in order to assign the plan set in a treat and perform its execution.
[12:17.630 --> 12:23.750]  When all this information reaches the command and control, it saves the information into
[12:23.970 --> 12:26.850]  a database and sends an OK signal.
[12:28.590 --> 12:34.710]  The second flow refers to the adversarial planning and execution process.
[12:35.950 --> 12:42.170]  The console or agent will ask for information about the treat plan to be performed.
[12:43.070 --> 12:49.370]  If the user has not created a treat plan for that console, the answer will be no treat
[12:49.370 --> 12:50.310]  plan.
[12:51.210 --> 12:56.930]  When there is already a treat plan created for that console, an OK signal will be sent
[12:58.090 --> 13:04.450]  Later, the console will start asking for the functions that are part of the treat plan.
[13:05.850 --> 13:11.630]  For each function downloaded and executed, the results will be reported to the command
[13:11.630 --> 13:13.090]  and control.
[13:16.030 --> 13:21.610]  In other words, when the warrior connects to HTTPound, it requests a new treat plan
[13:21.610 --> 13:24.350]  through the GETPLAN function.
[13:25.850 --> 13:32.510]  If the user has assigned already any plan to the warrior, it answers OK and the treat
[13:32.510 --> 13:34.470]  plan will be delivered.
[13:35.030 --> 13:40.210]  This plan is generated in a JSON format.
[13:40.990 --> 13:44.910]  More details about this file will be provided later.
[13:45.550 --> 13:52.450]  Once the treat plan is available for the warrior, it will perform the request of each function
[13:52.450 --> 13:54.330]  or task to be accomplished.
[13:55.530 --> 13:59.510]  This is made through the GETTASK function.
[14:00.430 --> 14:07.130]  A GETTASK function will be run for each technique implementation that the warrior requires to
[14:07.130 --> 14:11.570]  be performed in order to fulfill the treat plan.
[14:14.070 --> 14:20.610]  For each prior run, two values will be returned through the PUTRESULT function.
[14:21.570 --> 14:28.590]  The first one, whether or not the ATTCK technique has been executed successfully.
[14:29.770 --> 14:36.130]  In the second case, we get the output from the function that implements the returned
[14:36.130 --> 14:41.190]  technique ready for a technical review that can check the results.
[14:41.850 --> 14:45.670]  OK, and now the third flow is the SIGNOUT flow.
[14:46.470 --> 14:51.930]  After all the techniques have been performed, the communication close and the treat emulation
[14:51.930 --> 14:53.170]  is finished.
[14:53.970 --> 14:57.970]  So the console will send the BYE command.
[15:01.010 --> 15:08.570]  Therefore, the root node will also assume the warrior as dead if it does not report
[15:08.570 --> 15:11.710]  any activity for a long period of time.
[15:11.710 --> 15:18.170]  In the other side, the warrior will show activity if, before a treat plan is associated,
[15:18.170 --> 15:20.630]  the warrior is requesting a plan.
[15:22.900 --> 15:28.160]  Now let's talk about some key elements in the ATPAM to go a little deeper.
[15:28.640 --> 15:35.400]  The console will be created from the web application specifying the IP address from where
[15:35.400 --> 15:38.200]  the console file will be downloaded.
[15:39.000 --> 15:47.140]  There is a file called console template that houses the instructions that will manage the
[15:47.140 --> 15:53.100]  connection, the treat plan, and the connection clause we mentioned in the previous section.
[15:53.660 --> 15:59.220]  When the instruction provided is being executed on a Windows machine, the PowerShell code
[15:59.220 --> 16:05.660]  necessary to carry out the warrior instantiation will be launched.
[16:06.300 --> 16:12.160]  The console has two parts with a large if in the middle.
[16:12.340 --> 16:18.080]  The first part of the basic starting path is the beginning of the thread.
[16:18.120 --> 16:23.800]  As seen in the previous section, a connection request shall be made.
[16:23.800 --> 16:33.420]  First, a unique ID is generated for this instance to be identified in the root node.
[16:33.420 --> 16:39.600]  Also, the information on the operating system where it's running is gathered.
[16:40.060 --> 16:48.200]  The second part is driven by a case that can happen in many thread emulations.
[16:48.560 --> 16:53.560]  The process where a privilege escalation or lateral movement to another machine
[16:53.560 --> 17:00.040]  produces a new privilege process, or one that can be executed in another environment,
[17:00.040 --> 17:02.060]  has been called splitting.
[17:02.060 --> 17:07.040]  In this case, the console will be invoked with an ID.
[17:07.040 --> 17:15.900]  That is, it will not have to generate the warrior ID that identifies the warrior to the root node.
[17:15.920 --> 17:23.380]  In other words, if there is a plan with three tasks, and the second task is a privilege
[17:23.380 --> 17:30.180]  escalation, and this one is successful, then the third task will be executed in another
[17:30.180 --> 17:33.820]  process at an operating system level.
[17:34.000 --> 17:39.160]  But from the 80-pound logical point of view, it's the same warrior.
[17:39.160 --> 17:42.560]  That is, it inherits the same warrior ID.
[17:45.700 --> 17:47.800]  How do we define a thread?
[17:48.080 --> 17:51.660]  Simple, through a JSON file.
[17:51.660 --> 17:56.580]  The thread plan is generated in the root node according to the user's needs.
[17:56.580 --> 18:02.380]  The user can use real threads already created or build their threads and see the output
[18:02.380 --> 18:04.680]  of their monitoring techniques.
[18:04.680 --> 18:08.720]  The document format delivered with the plan is JSON.
[18:11.590 --> 18:18.110]  Let's talk about how to create your ATT-bound functions using the skeleton function.
[18:20.100 --> 18:27.960]  Any user can create or add features to implement techniques from the Mitre ATT and CK.
[18:29.620 --> 18:36.700]  Its implemented function is linked to a technique and one or more tactics in the framework.
[18:38.700 --> 18:47.980]  The main components from the skeleton functions are the technique to be launched or the function
[18:48.500 --> 18:50.640]  and the main program.
[18:51.020 --> 18:56.520]  This main program will be in charge of managing the flow of the technique to be performed.
[18:59.410 --> 19:03.910]  And this main program is in charge of another three tasks.
[19:05.330 --> 19:13.590]  The first one is request the necessary data to the root node for the technique to be executed.
[19:13.890 --> 19:17.990]  This is an execution prerequisite.
[19:19.390 --> 19:26.750]  The second one is check if the execution of the technique has been successful or not.
[19:28.110 --> 19:32.770]  The output will be stored in a true-false variable.
[19:34.690 --> 19:40.290]  And the last one is if there is some data collected such as credentials dump,
[19:40.290 --> 19:46.310]  AP addresses or user enumeration that can be used by another technique because
[19:46.970 --> 19:53.570]  all this information will be dumped to a data store that has the root node.
[19:54.630 --> 20:01.090]  This scheme can be visualized in any of the functions that can be found in ATT-bound.
[20:02.290 --> 20:09.370]  ATT-bound is a collaborative project where the goal is to share knowledge through treat plans.
[20:11.090 --> 20:18.150]  For this reason, the tool allows exporting user-generated treats and importing them into
[20:18.150 --> 20:26.510]  other ATT-bound instances. During the treat plan generation or query,
[20:26.510 --> 20:31.310]  the export plan option can be used as shown in the image.
[20:35.560 --> 20:40.820]  Once the file is stored in JSON format, it can be shared with the community.
[20:42.240 --> 20:48.580]  The JSON file contains all the information needed to recreate the treat plan with all the tasks
[20:48.580 --> 20:56.860]  and implementation of techniques involved, even if these are not available in the new scenario.
[20:58.220 --> 21:04.100]  Now, let's look at some use cases. In ATT-bound, you can execute the
[21:04.420 --> 21:11.200]  default or known threats and threats or adversaries that we create. With our custom
[21:11.200 --> 21:21.000]  threats, we can make our own version of a known threat with HTTP techniques selected by us,
[21:21.000 --> 21:29.780]  create our own version of an attack with HTTP techniques, and perform an execution of a threat
[21:29.780 --> 21:37.220]  now created by us that implements our own functions through the skeleton function.
[21:38.760 --> 21:44.780]  In this section, we will perform different scenarios and explain them.
[21:50.370 --> 21:54.470]  Okay, in this first demo, let's see what a warrior is.
[21:55.300 --> 22:02.270]  To do this, we will create the warrior in this option and copy the code that ATT-bound delivers
[22:02.270 --> 22:16.680]  to us. Then, we go to the computer where we will make the adversary or threat test, paste the code,
[22:16.680 --> 22:23.160]  it will be executed in a new PowerShell, and finally, it connects with ATT-bound downloading
[22:23.220 --> 22:33.810]  a console. If we go to the home section, we will be able to see the computer where the warrior is
[22:33.810 --> 22:43.470]  running. Here, we have the architecture data, the process that it's running, the AP address to which
[22:43.470 --> 22:53.580]  it belongs, and the warriors identified. In the plan section, we have some predetermined threats
[22:53.580 --> 23:01.120]  as we can see here, like WannaCry, NotPetya, Flame, DarkComet, or Dooku.
[23:02.600 --> 23:09.660]  Let's select, for example, WannaCry, and here we can see the techniques and the ATT and CK
[23:09.660 --> 23:25.030]  tactic identified that forms this version of WannaCry. We could use it against a warrior,
[23:25.030 --> 23:31.590]  launch the warrior plan, and finally execute it, step by step, all those techniques that correspond
[23:31.590 --> 23:45.680]  to WannaCry in this case. In this second demo, we are going to gather information to verify that
[23:45.680 --> 23:53.140]  there are different techniques within ATT and CK and ATT-bound to be able to collect that
[23:53.140 --> 24:03.980]  information to recreate the malware threat. Next, we are going to do a privilege escalation technique
[24:03.980 --> 24:12.280]  that will split the ATT-bound console process in two. One without privilege and the new one
[24:12.280 --> 24:30.690]  with privilege. The first step will be to create the warrior, copy the code, go to the PowerShell,
[24:32.830 --> 24:59.100]  run the code, and finally obtain the warrior executed. Okay, now let's go to the plan option,
[25:02.250 --> 25:16.580]  create a new one, select the gathering tactic where we can see here, besides the implemented
[25:16.580 --> 25:24.100]  techniques, we also have the discovery tactic where we can see some ATT and CK techniques generated.
[25:26.180 --> 25:33.620]  In this case, we are simply going to make a selection of the processes that the machine has.
[25:33.980 --> 25:39.140]  We will add this technique, then we'll go to the escalation of privilege,
[25:39.140 --> 25:48.120]  where we are going to use a bypass of USC technique named 1088. We add it,
[25:48.120 --> 26:03.690]  we put a name to the thread, and finally we will create the plan.
[26:04.230 --> 26:08.570]  Once we have the plan created, we can select it here.
[26:12.180 --> 26:18.960]  We see the elements of our plan with which Mitre tactics the mapping is performed.
[26:20.960 --> 26:26.440]  And we can identify the warrior over the warrior we want to launch it, and finally we launch the
[26:26.440 --> 26:36.120]  plan. At this moment, the ATT bound console will start working and it will read the plan, and
[26:37.160 --> 26:39.860]  here we have the pending task.
[26:42.260 --> 26:47.760]  If we go to the result option, we will see how the first technique has already been executed.
[26:51.380 --> 26:57.280]  In bulk process, which is just a collection of processes, we can see success.
[26:59.140 --> 27:03.560]  If we refresh it or we wait for a little while,
[27:07.910 --> 27:20.930]  we will find that USC bypass has also been successful, and we really get a double process.
[27:21.840 --> 27:25.100]  The one on the left is without privilege,
[27:27.130 --> 27:34.690]  but the one on the right is a process in which instructions with privilege are being executed,
[27:34.690 --> 27:39.850]  but we had no more technique after the privilege elevation of execution.
[27:40.010 --> 27:45.660]  In the ATT bound technical part, we can see the technique's output.
[27:48.680 --> 27:57.320]  We can check the processes that the computer has, and here we can also see the UAC bypass result.
[28:02.040 --> 28:16.080]  And here's the second demo. In this third demo, we are going to perform an escalation of privilege,
[28:16.080 --> 28:28.220]  but also a credential stamp. To do this, let's create a warrior pointing to the ATT bound IP
[28:28.220 --> 28:36.220]  panel, copy the code, and run it on the PowerShell console as we saw before.
[28:41.190 --> 28:46.070]  Here we can see the information about the new warrior connected to the panel,
[28:46.070 --> 28:58.270]  and now we are going to create a plan. The plan will have a privilege escalation.
[28:58.880 --> 29:04.560]  We will use again 1088, that is the UAC bypass,
[29:06.190 --> 29:13.590]  and we will execute a credential access tactic using a power dump, but we could also use
[29:13.590 --> 29:32.790]  Mimikatz to perform the credential dump. The interesting part is that once we get the
[29:32.790 --> 29:38.970]  privilege escalation working, we will get a new process with privilege, and this process
[29:38.970 --> 29:48.340]  will be able to perform the credential dump. Okay, so let's create the plan, deploy the treat,
[29:48.340 --> 30:02.860]  select the treat, select the warrior, and finally launch the plan. Okay, and now let's go to the
[30:02.860 --> 30:10.800]  ATT bound output section, and here we'll be able to see the techniques or tasks pending execution.
[30:13.510 --> 30:26.020]  Like the 1088, if we give it a little time, we will see that it has been successful.
[30:26.400 --> 30:32.340]  This new process with privilege has not been created yet. We will see in the next refresh.
[30:34.880 --> 30:38.600]  Here we can see the console without privilege,
[30:43.140 --> 30:48.860]  and this second panel, we will find the credential dump still running.
[30:57.010 --> 31:05.850]  And now we can see that the power dump technique is finished. But where can we see the results?
[31:05.870 --> 31:11.510]  Like in the previous demo, here we can see the output that this technique has.
[31:12.770 --> 31:14.990]  In this case, the UAC bypass.
[31:16.610 --> 31:21.130]  While the second technique executed in this process, the credential dumping,
[31:21.130 --> 31:24.090]  has returned us all this information.
[31:25.430 --> 31:31.870]  This information is very important. As we see here, we have users, user ID,
[31:31.870 --> 31:40.010]  has lm, has ntlm. As I said, this information is very important because we will be able to use it
[31:40.010 --> 31:50.990]  through a datastore. The datastore can be used by techniques that are performed afterward.
[31:51.400 --> 31:58.280]  For example, a lateral movement technique can be used by these hashes and these users because of
[31:58.280 --> 32:05.800]  this datastore. This is a very, very important element within ADDbound.
[32:12.410 --> 32:16.850]  In this fourth demo, we will perform the following scenario.
[32:17.810 --> 32:24.330]  First, an escalation of relays. Second, credential dumping.
[32:25.670 --> 32:31.730]  And finally, we will make a lateral movement from a computer with Windows 7 to a computer with
[32:31.730 --> 32:39.210]  Windows 10. First, we are going to deploy a warrior on the Windows 7 machine.
[32:42.380 --> 32:50.120]  Okay, as we have done in previous demos, we type in the ADDbound IP address and finally create
[32:50.120 --> 33:04.090]  the code. We copy the code from PowerShell and run it on Windows 7. Okay, we copy the code
[33:06.810 --> 33:11.970]  from ADDbound and run it on Windows 7 on PowerShell.
[33:14.350 --> 33:25.370]  Okay, once executed, we go to home and obtain, as before, the new warrior running Windows 7.
[33:29.780 --> 33:43.360]  Okay, well, now let's generate a plan where the first step is to execute this technique.
[33:43.360 --> 33:56.400]  For example, by the counts T1078. Okay, the second technique is an escalation of privileges.
[33:56.400 --> 34:05.200]  And third technique is credential dumping. And the fourth step or fourth technique will be a
[34:05.200 --> 34:27.300]  lateral movement. Okay, now insert plan and select a plan, new plan or new thread.
[34:27.840 --> 34:50.100]  And we assign warrior ID to new plan. Okay, and look at results view and we have a data store.
[34:50.100 --> 35:09.280]  Okay, these are several techniques about the new plan and data store. We add an IP address
[35:09.280 --> 35:30.890]  to the data store. Okay, well, refresh the web page several times until the lateral movement
[35:30.890 --> 35:37.710]  is complete. The technique of lateral movement is complete.
[35:39.190 --> 35:48.130]  Now ADDbound is still executing, execute all process.
[35:51.690 --> 35:58.270]  And now refresh the web page several times until the lateral movement is complete. Okay,
[35:58.270 --> 36:05.170]  observe that we have an ADDbound console running on Windows 10.
[36:10.970 --> 36:21.880]  Yeah. Then now we can conclude this demo 4. Okay, now we are going to
[36:21.880 --> 36:46.810]  do a speech about demo 5. Well, in this 5th demo, we will work on an all-in-one thread concept
[36:47.550 --> 36:55.930]  where we will automate the service discovery and the discovery of machines within a network
[36:55.930 --> 37:04.470]  as a thread or an adversary could do. The data discovery will be stored on the data store by a
[37:04.470 --> 37:11.090]  technique being used. Then we will perform a privilege escalation, obtain a new privilege
[37:11.090 --> 37:19.410]  process on the Windows 7 machine. Then we will make a credential dump thanks to that privilege
[37:19.410 --> 37:28.610]  escalation where we will acquire hashes and users. Then we will make a lateral move where we will
[37:28.610 --> 37:36.230]  use the hashes, users, and the IP addresses from the computers within the network to try to make
[37:37.230 --> 37:45.210]  that lateral move through the metered CKE technique. In this way, the whole process is
[37:45.210 --> 37:52.650]  fully automatic, so we can test the effectiveness or efficiency of security
[37:52.650 --> 37:59.310]  controls within the organization. We will start, as always, by generating a warrior. In this case,
[37:59.310 --> 38:07.310]  we check the IP address again. Copy the code and go to PowerShell to paste the code. Okay?
[38:09.730 --> 38:19.490]  Okay. In the home section, we will see the control connected soon. Here we see the data.
[38:19.490 --> 38:36.930]  Now we go to the plan section. Okay. Waiting for the warrior. And we go to the plan section.
[38:36.930 --> 38:48.950]  We create a new plan beginning with the discovery tactic using the T1046 technique
[38:49.650 --> 38:57.230]  where this port scanning will allow us to discover computers. Okay.
[38:57.530 --> 39:05.590]  We add the technique to the plan indicating an escalation of privilege and then credential dump
[39:05.590 --> 39:15.810]  with power dump or mini cuts. And finally, the last technique, again, a lateral movement.
[39:16.650 --> 39:28.450]  Okay. And thread name, DEF CON GIMU5, and thread description, blah, blah.
[39:31.830 --> 39:37.050]  Okay. We put the name on the one, create a plan, and link it with the warrior.
[39:37.050 --> 39:49.730]  We go now to the results. Okay. Well, first locate plan. And now we go to the results.
[39:51.920 --> 39:55.390]  We see the control begins to work.
[39:58.010 --> 40:05.440]  Now we can see here the task to be done. And the scan begins.
[40:08.510 --> 40:18.310]  One moment here. Yeah. The scan is a technique that can take quite a long time.
[40:18.310 --> 40:26.990]  Can be seconds or minutes. So, we will speed up the demo a little bit so that this part goes as
[40:26.990 --> 40:40.660]  fast as possible. Okay. Once the scan has finished, we will be able to check that it has been successful
[40:40.660 --> 40:52.640]  if we go to the data store. Okay. Now, we go to the data store. We will be able to see the
[40:52.640 --> 41:01.940]  computer IP addresses that are currently alive on the network. Right now, the second technique,
[41:01.940 --> 41:10.160]  that is the escalation of village has also been successful. So, the process has been unfolded.
[41:10.160 --> 41:21.220]  Right now, the process is done. Okay. If we refresh the page, we will see the credential
[41:21.220 --> 41:31.160]  dumping has been successful, too. And if we go to the data store, we see that we have IP addresses,
[41:31.160 --> 41:41.600]  users, and hostess. This hostess can be from here directly. Like any data from the data store
[41:41.600 --> 41:49.980]  and the changes will be saved by clicking on the update code. Okay. For the thread to finish,
[41:49.980 --> 41:54.620]  we will have to check if the result is correct or not in the lateral movement.
[41:54.620 --> 42:02.740]  And we must consider that these techniques are used to test the efficiency and effectiveness
[42:03.360 --> 42:10.380]  of the security controls within the organization. Therefore, certain implementations may be
[42:10.380 --> 42:21.740]  dated and avoid the execution of some codes. Okay. Now, a new process on Windows 10 has
[42:21.740 --> 42:28.280]  been implemented. There are no tasks and we have performed the lateral movement. In other words,
[42:28.280 --> 42:35.620]  the thread has moved from Windows 7 to Windows 10 from one machine to another over the network.
[42:35.900 --> 42:44.340]  We have also done the whole process of thread that is real for us. Detecting computers in the
[42:44.340 --> 42:52.520]  network. Dumping and accessing information such as hashes. And finally, a lateral move
[42:52.520 --> 42:59.880]  with one of the techniques that can be implemented within the lateral movement. Move tactics.
[43:03.290 --> 43:10.970]  In this final demo, we are going to export the thread plan and then import it into
[43:10.970 --> 43:19.450]  HTTP. To make a simple example, we can choose notepad, select the thread,
[43:19.450 --> 43:24.740]  get the techniques to use, and proceed with the plan export.
[43:26.830 --> 43:39.070]  In this button, we export this knowledge. If we want to share knowledge with other users,
[43:39.070 --> 43:47.010]  our thread knowledge that we already have created, or even techniques that we have implemented
[43:47.010 --> 43:56.230]  in PowerShell, we can create a new plan, set a name, create a plan, choose it, and proceed to
[43:56.230 --> 44:18.410]  export it. If we want to share this plan with another user, we will send him the JSON file
[44:18.410 --> 44:33.340]  which we are going to open to see the content. Okay, JSON, opening JSON file in Firefox, okay.
[44:35.880 --> 44:43.680]  Okay, as you can see, even the function definition written in PowerShell,
[44:43.680 --> 44:52.820]  exactly as we have created it, is transferred. So, if we want to share this information with
[44:52.820 --> 44:59.260]  another user, we can export those plans containing the functions that we have
[44:59.260 --> 45:14.050]  created in PowerShell and added to HTTP and send this JSON. Okay. It's a very simple and
[45:14.050 --> 45:19.790]  collaborative way to provide the knowledge to other users with offensive techniques
[45:19.790 --> 45:29.610]  within the HTTP mapping. Well, this is the last demo, and I will pass the word on to my partner, Fran.
[45:30.970 --> 45:37.570]  Okay, so that's all. Feel free to visit the ATTPound GitHub and download the software.
[45:38.550 --> 45:43.930]  This is a new tool we are currently working on, and we are adding new techniques.
[45:45.410 --> 45:49.630]  Also, the project is collaborative, and everyone can help the project grow.
[45:50.890 --> 45:55.990]  And now, we are ready to answer any questions you may have about HTTP.