 Hey, how's everyone doing? Awesome. Hey, I know this is a great big conference with a lot of really awesome things to do, so thank you so much for opting to spend the next 45 minutes or so with me. Today I'm going to talk about Moe's, which will allow you to easily take advantage of configuration management tools in order to do evil things. And okay, good. You can see my laptop, right? No. There we go. Anyway, as I was saying, uh, this is a slide that the power is to be put on here. Uh, essentially I'm not speaking on behalf of my employer or any of my previous employers nor am I here representing my current employer or any previous employers and finally my opinions do not reflect those of my current employer or any previous ones. Alright, now that we're past that, this is me in my more natural state presenting in front of a group of people. The content and delivery is a bit different, but I'll figure it out. I'm a death metal vocalist in a band called Carion Kind with that guy right there. And uh, I've been playing metal for around 19 years now. I used to tour around the U.S. with another band with that guy right there. Uh, a lot of great metal dudes in the audience today. But I've since settled for playing local shows every so often. Once upon a time I was a sysadmin and a devops engineer. And currently I am a penetration tester on the product security team at Splunk. My role consists of reviewing the various products that we have for potential issues. Uh, shameless plug we're hiring. And before that I built and ran the corporate red team at Sandia National Labs. And I also really enjoy automating things that break stuff which help to motivate this talk. Okay, on the agenda for today we're gonna begin by talking about what our configuration management tools. After that we will discuss how we can use them for less than savory purposes. Following that I'll talk about what Moe's is and why it exists. After addressing those I will show you how to use it. I will also be discussing existing tools in the space. And there will be some prerecorded demos because the demo gods are cruel. And finally I'm gonna talk about my plans for Moe's future when it goes off to one day. Quick pull before we go any further. Who here enjoys post exploitation? Raise your hands please. Awesome. Keep them up for a second. Who here enjoys post exploitation? Feels like you have enough time to do it on a regular basis. I'm seeing a lot less hands. That is what I expected. So for me, post exploitation is my favorite part of a pen test. And no matter where I work I've never felt like I've had enough time to do it properly. So my goal has been to automate as much of it as I can. And that's the motivation for a lot of the tools that I end up writing. And I found it to be a really effective way to maximize what I can do in the most efficient way possible. I've got a couple of stories around post exploitation specifically with configuration management tools to kind of highlight some of the things that we could start thinking about doing. On the first one I was just beginning recon on an engagement doing some port scanning and service discovery when I came across a system with port 2375 exposed. This is the socket for the Docker daemon as some of you may know. And essentially this meant that I could Docker exec into any of the containers running on that system. One of them happened to be a puppet master for a dev enclave. Subsequently I was able to compromise around 50 or so machines. But this in turn led to a ton of lateral movement both inside and outside of that enclave. So that was pretty fun. On another one I compromised a Jenkins box and once I had the Jenkins SSH key I was able to get into around 15 or so systems. But one of them was a puppet master. From this system I was able to compromise hundreds of servers, countless databases. I got into the devs hip chat which is always really entertaining. And I got admin on their Git lab. It was awesome. So most of the systems is a tool to help you enjoy these sorts of successes in your own engagements. All right. Let's talk about what CM tools are exactly. They are first and foremost used for provisioning systems. So if you have a brand new system that needs to be part of a cluster or it needs to run certain software you provision it to do so. They can also be used to manage the state of the systems in your environment. So if you want to make sure that a service is always running or you want to make sure that machines in that environment are being updated automatically on a regular basis these are some good use cases for configuration management tools. These tools have a lot of things in common. To start they have this concept of idempitency which essentially means that you run the code as many times as you want and can expect to produce the same result. You can also scale infrastructure while guaranteeing consistency. And you have the ability to provision a bunch of machines that are running on a variety of operating systems. So for example you could have a puppet module that works for Debian, Suse, Red Hat, Ubuntu, Windows, etc. And they all have a form of secrets management which we'll discuss a little bit later. It is worth noting that puppet doesn't truly have a native secrets management solution per se but higher EML has more taken control. And lastly it's worth noting that you can run these tools in your list and client server formats. For this talk we're going to focus primarily on client server formats since that's what you can expect to see in most enterprise environments. As you can see these tools are used in a lot of different organizations. This is by no means exhaustive. Pardon me. And some of these organizations use multiple of these tools so you could have an organization that's using Ansible and for example. But the point here is if you haven't come across these at some point you're going to because they are quite prevalent. These are some of the more popular options. So essentially we have puppet, chef, salt and Ansible. There are some differences that exist amongst these tools. For this talk I'm going to be focusing on puppet and shit since these are the two that Moe's currently supports. But go ahead and take a look at that. And if, I'm going to show you an example of how to provision a system with one of these tools in a moment. But if you're still processing why you'd use this technology consider this example of an 1100 line bash script which has zero functions and is completely void of hope. So it's nice to have code that runs your infrastructure but not when it's a giant script that gets passed down from generation to generation and becomes a rite of passage to maintain. Alright so for this example I'm going to show you how to provision a couple of puppet agents with a puppet master. Real quick we're going to take a look at the master manifest for the production environment. And I want you to focus specifically on the web prod.demo.com node here. Essentially we're going to install a couple of packages and then essentially we are going to stand up a web server which will run a web page on top of it. As you can see there's nothing currently running for that system. We're going to go ahead and pop into that particular puppet agent. And as you can see HDVD is not running. But when we run the puppet agent the agent goes to the puppet master says hey I'm lost in this world what am I supposed to be doing with my life. The puppet master says if you're not you are supposed to be a web server running a web page. Do that. And obviously that was not 18 seconds but magically we now have a web page that is running on top of a web server. For the next example we're going to take a look at the dev main manifest. And here I want you to focus on node default. Um we're going to install a couple of packages but it's important to note for puppet that node default means that that case will match any puppet agents that are not explicitly defined with a node definition. So the only definition that was defined was the web dev.demo.com in that case. As you can see the packages are not installed. Puppet agent for the development environment. Same thing goes to the puppet master says hey what am I supposed to be doing. Puppet master says install these packages. And subsequently we now have GCC, make and Node.js installed. So hopefully this is a nice little basic example to get you into the mindset of what we're looking at here. Okay. Some of you are thinking you could do that with containers. Hell you even just use them for your example. Why would an organization still be using this technology? And to that I would say a couple of things. First not everything can be a cloud native ephemeral workload that runs in a container. Secondly it's typically not a trivial effort to migrate older monoliths to container based appointments. And furthermore you still have to install, configure, and manage your Kubernetes environment. So I do not believe that this technology is going to be going anywhere anytime soon. Now that we've talked a bit about these CM tools I would imagine some of the more offensive minded folks in the audience are starting to get some ideas about what we could do with this technology. If not let me give you a couple of ideas. It's important to keep in mind that successfully compromising a CM server can attack the ability to run any command on every connected system. This can lead to introducing back doors, adding or deleting files, modifying database data, getting a whole bunch of shells. Really the sky is the limit. And pardon me. So long as your implanted code isn't modified you have a guarantee that it will run on a regular basis. So persistence is effectively built in for you which is pretty nice, right? And because these tools all provide secrets management solutions we can look at stealing the secrets. Now obviously secrets are something we should keep an eye out for regardless of whether or not we're on a CM server but it can be especially interesting if we land on a CM server and start looking for secrets because some of these secrets were created to run on a whole bunch of different systems. And as such they can provide us with ample lateral and vertical escalation paths and opportunities. So for virtually all these solutions it comes down to getting on the right system and running the decrypt command. Alright let's talk a bit about Moe's. Moe's is a translator between the user and a variety of CM tools. What we want to do and what commands we want to run but we don't necessarily know how to do them for a particular CM tool. Moe's takes the commands we want to execute and translates them into a format that a given CM tool can understand. This is a project that I started working on back in December of last year and since then a lot of nights and weekends have gone into it. When I was coming up with the original idea I decided that I wanted to be in Golang because well I drink black coffee and IPAs and I have this beard so I figured I would complete the ensemble. I decided to make it in Golang so that we can trivially target a variety of operating systems and architectures, leverage, native concurrency and generate a binary that we can run on a target system without having to worry about dependencies. I decided to source it through my previous employer, Sandia National Labs for PR and hiring purposes. Sandia is an awesome place to work and they're super down with open source security tools and contributing to the security community so I wanted to recognize them for that. Before continuing on I wanted to address another potential question that may be on some of your minds. Why do I need a tool to go in between myself and these CM tools? Can I just use the tools myself? And the real answer is you can if you have the time to spare. For anyone that's used these tools let's face it, there's a learning curve. And since you will likely encounter several different CM tools while on engagements you have to deal with that learning curve multiple times over. You can't choose which tools your target uses so you want to be able to weaponize them all and not have to worry about the syntactic differences. It's also really important to keep in mind that you can seriously muck things up if you're not careful. Imagine running one command and taking down 500 production servers all at once. If that's not in scope for you, you are in trouble. That being said, if you tell Mose that you want to run rmrf slash on all puppet agents bad things are going to happen. Don't do that. To give you some perspective these are some of the links that comprise the documentation for puppet. This is what I'm talking about with respect to the learning curve. The documentation for most of this technology is extensive and it takes time to ingest and understand. Two things typically come to mind for me when I hear about a new tool. The first being surely someone has released something already that enables you to do this. And the second being there are so many tools in this space. Do we really need another one? And when I looked at the existing solutions for this particular problem there weren't really too many out there. Right now we've got Pone Pit and Pone Sable. Both are created by a security researcher that goes by the handle Naughty. Pone Sable is a bash script that creates an MSF Venom generated payload and tells you how to run it with Ansible. Pone Pit is a bash script that creates a new manifest and module to run an MSF Venom generated payload. On a somewhat unrelated note there's also a great article from Ryan Wendell which talks about compromising chef via the Chef server web UI called cooking up shells with a compromised chef server. I've included in the read me for mo's when I get that up shortly. So that's worth your time to check out. Okay back to Pone Pit and Pone Sable. They're a great place to start but there's a couple of issues with them. They're decent little bash scripts that work well to demonstrate the problem that's associated with having your CM servers compromised. But they weren't built to scale or give you the ability to translate your thoughts and ideas into code. They only support generating payloads with MSF Venom. So if we didn't want to use MSF Venom we have to make modifications. Additionally both require manual work. For Pone Sable, hello. For Pone Sable. Outside of creating the payload basically everything is manual. And for Pone Pit the user needs to physically modify the main manifest on the server by copy pasting from the generated payload. And you also have to get the associated module and file into place. Plus they don't attempt to get us the juicy secrets that we all really want. So rather than having to manually place files, run commands, modify files on the remote server, Moe's automates all that for you. And there are a lot of really great post-ex tools out there that it would be really ideal to be able to leverage in new kind of workspaces. So Moe's gives you the ability to upload scripts or binaries and execute them on a ton of systems all at once. You can also pick and choose the nodes that you want to target for specific tasks strategically. So this could be something like uploading a web shell for all the web servers or you could pop reverse shells on all the managed laptops when they come online or you could have a specific PowerShell payload that specifically for the Windows servers. And because Moe's allows the user to clearly go from thought to command without having to go deep in the weeds of tool specific details, it helps to prevent someone less experienced with these technologies from accidentally running the wrong commands and decimating a whole bunch of servers all at once. So the user doesn't need to know tool specific implementation details to run Moe's. Essentially you input your command that you want to run the same way whether you're looking at Chef or Puppet. Although you do need to specify the name of the tool that you want to target, it's really simple. You just do dash t Puppet or dash t Chef. However, for users that do have CM experience, you can use Moe's as well to customize your attacks further. A lot of the functionality that exists in Moe's is template based. And so more advanced users can modify these templates to extend on the functionality that Moe's provides out of the box. Also for you more advanced users and potential future collaborators, this is the code that Moe's uses for payload generation. You'll notice that for both Puppet and Chef, these have the same core pieces. And this makes it clear and straightforward to develop and modify as is needed. Alright, let's talk about the workflow for using Moe's. To start, Moe's does come with a make file so to begin you would run make build which will get all the go dependencies in place for you and compile your binary. After you've done that, you'll be at this point. So you specify the command that you want to run. In this case we're going to run LS, it's not very exciting but it's just to demonstrate the point of what we're doing. And then you specify the target as whatever CM tool you want to specifically target. So in this case Puppet. There's also a JSON config file to specify more advanced options that you're not going to need as regularly. So this includes things like pass to SSL certs, where you want to store X filled, Chef files and a number of other things. So once you've got everything in place for how you want it with a JSON and you have the command that you want to run, you just, you run Moe's. It generates the payload as a binary. And by default it will stand up a web server for you and host the payload. If you don't want to go that route you can just specify a different parameter and it'll spit out the payload for you and you can transfer it up via SCP or however you want to get it up there. Once it's up you run the payload on the target CM server. You answer a question or two and that's it. You'll notice that this is one slide of documentation and we can go from nothing to fully compromising a bunch of systems. So alright, let's take a look at Moe's and Puppet. And just for, just to give you a kind of visual representation of what we're looking at here. Puppet environments can get a lot more complex than this but this is a good abstraction of what you can expect to see. So essentially you have a Puppet master that has some modules that are probably in a code repo and this Puppet master is connected to a bunch of Puppet agents. So we go ahead and specify the command we want to run. In this case we're going to create a hello dot text file in the temp directory and just throw the string in there. The target is Puppet and we have this SSL option which allows us to use TLS for the web server that we're going to use to host the payload and we're opting to use port 8090 for the web server. Alright so we ran it in the previous slide. Now at this point we're on the target. We go ahead and grab it. As you can see here we provide a self-signed cert with Moe's which I highly encourage none of you to use. But if you do use it this is what it looks like and as you can see it's very conspicuous. Alright so at this point we run the payload. It asks us if we want to make a backup of the existing manifests. I encourage you to do this unless you don't really want to worry about cleaning up later. So if you do make a backup you can run the Puppet Linux binary again with a dash C param and it will undo all the stuff that you did with Moe's. But if you're trying to be a little stealthier okay I get why you wouldn't want to have a dot back dot Moe's file on the system but I'll leave that up to you. It will then identify all Puppet agents that are known to the Puppet Master. It will also identify modules that are known to the Puppet Master. From there it generates the rogue module based on the command that we specified and then puts it into place. You also notice at the bottom here it found a secret for us so we'll hold on to that for later. At this point Puppet agents by default check in with the Puppet Master every 30 minutes but we wanted to get a nice visual representation of what's going on here so I've gone ahead and kicked it off manually. As you can see the agent checks in with the Master. The Master tells it that it needs to run the rogue payload that we specified and subsequently we have this string in the hello dot text file. Alright. Next let's take a look at Moe's and Chef. Again this is uh this is kind of what you can expect to see here as far as the Chef environment goes basically you have a Chef workstation which allows you to upload recipes and cookbooks to the Chef server. The Chef server interfaces with Chef nodes so there's a added level of complexity with Chef. Um Chef workstation is usually run from a developer's laptop. Uh dev group server, Jenkins, etc. And then Chef server is just there. As far as Chef nomenclature goes um basically Chef nodes run a client which is known as the agent so I'll probably be using agent and client interchangeably. Uh try not to get too hung up on it. Alright so we're going to start with compromising a Chef workstation since this is a lot more straightforward. As you can see we're basically running the exact command that we ran for the Puppet Master with the exception of changing the string from Puppet to Chef and we are also specifying the target as Chef as opposed to Puppet. We go ahead and run the command. It generates the binary for us. We download the payload onto the target Chef workstation and then we run it. And when we do run it it will identify all nodes that are known to the Chef server. It also identifies cookbooks that are known to the Chef server. Um it then allows us to target specific Chef agents. This is functionality I'm hoping to add to Puppet but I just didn't get time this uh for this particular release sorry about that. Um so you can input the systems that you want to target specifically or you can just opt to target all of them. Once you've done that it will generate the rogue cookbook for you. It will upload it to the Chef server and then it will add it to the run list for the target systems that you specified. In this case Chef Agent 1. Uh if you're using the Chef client cookbook which is considered an industry best practice the Chef clients will check in with the Chef server every 30 minutes. In this case again I'm just uh running it manually so you can get a visual understanding of what's going on here. Basically it checks in with the Chef server, sees that there's the new cookbook to run, runs it, generates the file with the string in it and all is well in the world. That wasn't too bad right? I mean it's basically the same thing that we did for the Puppet master. Chef server is a little more complicated. So again just uh for your uh visual perspective uh we are on the Chef server which communicates with the Chef nodes. Okay so we can spawn a cookbook with Moes but the Chef server has no way to provision Chef clients with it because as an industry best practice and typically in most environments it's not going to have the knife utility. So we need a Chef work station for that. What we can get are the certificates that are associated with organizations in the Chef environment which we can use in conjunction with a Chef work station to achieve our desired result of running the rogue cookbooks on the Chef server. Now we don't necessarily want to install work station on the Chef server because we could clobber some dependencies or break something and or get made if we're trying to be more stealthy. It's not ideal. And we don't really want to install it on our own systems either because the same issues and it just you know might be painful and time consuming whatever else. And in the spirit of Moes we want it to be automated for us. So the solution I ended up coming up with uh revolved around Docker and some templating. The idea is we expel all the data that we need and we use it to automatically build our own Chef work station. So just to visually sum up what the plan of attack is here. Essentially we land on the Chef server. We expel the keys and the org names to our own system and then we use those to stand up our own Chef work station. Once we do that we can run Moes on the containerized work station and go to town on the agents. Alright so let's uh walk through the first couple of steps here. Again to begin we run Moes pretty much just like we did for the previous two targets. The two differences you'll see here are the dash L parameter which specifies our local IP address for XFIL purposes and we specify the dash EP param which allows us to specify the XFIL port that we're going to use. After that we run it. Moes generates the payload for us. We get it onto the target system and when we run it it will detect that we are on a Chef server. So back on the attacker system as soon as we download that payload it will immediately ask us these questions. Are you on a work station? No I am not. I am on a Chef server. Once you say that you are on a Chef server it will start the listener up for you so now you can expel the data that you need to. Okay so at this point we're on step five here. It's pretty simple really. Moes finds everything that we need and steals it. Um it posts it to the endpoint that we stood up and it's really all we need to do. Alright so at this point we have the information that we need and so now we can stand up a work station of our own and use it to run whatever command binary or script that we want to run initially. On some or all the nodes. Moes automatically stands up a container for us with all the dependencies that we need. It then drops us into it. So at this point we are running within the context of the work station container that we created. From there you follow the exact same steps as you did as you would as if you were on Chef work station and that's it. Alright so for this demo we're going to return to the environment that we were working in initially where we provisioned a web server to run a web page for us and we had the dev laptop. This is the payload we're going to use. Um we're just going to get an html file from Google Drive and just put it into place. This endpoint is no longer up for any of you out there. Um so we run Moes with the payload. We get onto the target system. Download the payload that we generated. We run it. Create a backup. Um as you can see uh it detected all the modules. Puppet agents found a secret for us so we'll hold onto that for later. Let's go ahead and take a look at the master manifest. There is the payload that we introduced and we'll go ahead and take a look at the payload logic as well. Pretty simple. It puts a file into place that runs uh that has our script that we specified and then it runs it as root. So if we go ahead and look at the web uh site from earlier nothing has really changed which is you know expected. But within a whatever 30 minute window or if we run puppet agent dash t ourselves like we're going to do right now. Agent checks in with the master. The master tells it something has changed in your logic. Please do it. The agent complies. And now when we reload the page some shenanigans have occurred. And beyond that we have that secret that we found earlier the MySQL root password. So there is a MySQL system that is known to this particular box. Let's go ahead and pop into it with that secret and see if it works. Specify the host. Specify the user as root. And haza. Looks like it worked great. So this is a prime example of us being able to target a specific uh agent or set of agents and be able to then live off of the land. Use some of the secrets that we have to get into additional systems. This next demo is pretty simple but I think it highlights some of the things that some of us or maybe all of us want to do with this sort of thing. This is a different uh puppet environment. So I'm just going to show you what's going on here. Pretty simple. Um so basically we've got the production environment. And we're going to take a look at the existing modules. There is this Hello World module. I can assure you it's not very exciting so I didn't bother showing you what's up. And notice there's a node default and that's the only node. So basically that means that any puppet agents in this environment are going to be using whatever is in that node definition. Here we're going to start a tool up. It's called platypus. It's a neat little go-lang tool that essentially allows us to just get a bunch of reverse shells in. It's uh kind of like a lightweight alternative to Meturpreter if you will. Okay from here we're just going to run a you know pretty uh classic uh reverse shell payload. Don't worry I'll show it to you again shortly. We go ahead and get the payload onto the target puppet master. And it goes ahead and doesn't does its thing. There aren't any secrets but that's alright. It dropped our rogue module into place. As you can see here we found around 19 puppet agents, exactly 19 puppet agents. Um and uh there's that Hello World module that was there previously. So if we go ahead and take a look at the main manifest. We now have the rogue payload that we've introduced which is in place. We can go ahead and take a look at the module that we generated as well. And again pretty classic as far as reverse shells go. Can run as root. And so at this point we could wait for 30 minutes but I don't have that much time. So uh I'm going to speed things up by running this bash script here which will run puppet agent for all of the targets. So we'll just pretend that we've been hanging out for a little bit hoping that something good happens after we injected our rogue payload. All of a sudden a connection comes in and we say oh cool. Hopefully this is what we expected to be. Let's take a look. So we'll grab it. Jump into that session. And we are running as agent 2. Looks like there's a couple more connections coming in so why don't we check those out as well. Let's pick one. So we will interact with this and check it out. Looks like we're running as root on agent 6. And at this point it's basically just raining shells down on us so uh looks like things are working properly. And we'll just pick one more just to be sure. Go ahead and jump into it. And as you can see we are running as root on agent 13. So at this point I would say that our work we have owned. Cool. So if you are a responsible penetration tester or red teamer which I hope some are all of you. And you want to try some of this on your own without unleashing it on one of your clients. And you want to have a test environment but you don't necessarily need want to figure out how to do it yourself. If you're not I've created some for you. Uh you'll be able to find them here in a bit. They use Docker and vagrant. So um that's really in terms of dependencies. Don't worry these links will show up again shortly. On a side note I think that the test labs and mo's for that matter could be really interesting for blue teams to use as well. Uh for fire drilling or building uh detection mechanisms, uh automated zig-gen. If there's anyone here that's doing blue teaming and having sort of uh automated pipeline to do that sort of stuff I'd love to talk to you about what you're doing so come say what's up. Looking to the future uh I would like to of course be able to support Ansible and Chef. Um Jenkins obviously isn't a C.M. tool per se. But I think of mo's as STEX tool first and foremost. And Jenkins has a lot of interesting things you can do. I mean realistically it's uh it's basically the world's worst enterprise grade password manager. And um I don't know maybe do something like spawn rogue jobs or something. I haven't looked into it too much so if anyone's done any research there hit me up I'd love to hear from you. Um I think it would be nice to be able to interface with tools like Metasploit uh via containers uh you know generate pay listeners. Um so you don't necessarily have to run this in Kali or deal with setting up Metasploit. I I think it would be interesting to be able to back door existing recipes, modules, play books, states etc. Um right now as as you can recall we're generating a module and so modifying the main manifest. It would be nice if we could just piggyback off of something that's already there. Um so you specify the command you want to run whatever systems you want to run it on and then it back doors the existing code. And it would be nice to turn some of this functionality into some Metasploit modules potentially. Um I could see something like the higher EML secrets gathering is like a post module for example. Uh maybe you guys have some ideas about what we could do there. Hit me up. Uh and then lastly this is an open source project and uh I there's a lot of very smart people in this room and I would love to hear what great ideas you have. Um so please consider contributing. Real quick I wanted to thank a couple of people in the room. We got my wonderful wife Amanda who uh put up with me being super grouchy and working nights and weekends for the past month and a half so thank you very much. I wouldn't be able to do it without you. Um also I want to thank my buddy Al who's somewhere. Hey there he is. Uh he's the first contributor to Moe's and uh without him I wouldn't be able to get in nearly as many awesome features as Moe's has today. So thank you very much. Um couple of people helped me to go through this talk and make sure it didn't sound like dog shit and also gave me some tips on my code. So thank you to those people. And finally uh this is like a pretty crazy event and uh uh I've gotten a little bit of a better sense how the sausage is made so to speak. So could we please give it up for the DEF CON staff for doing such an awesome job year after year? And so if you're interested uh we myself and this wonderful man Al here are going to be talking about a great recon tool tomorrow uh from 12 to 150 in Planet Hollywood. Um if you're interested uh come on by say what's up. If you want to talk about Moe's that's totally cool too. Uh if you want to drink beers we can definitely do that as well. So again this is an open source project. I would love to see what ideas you guys have. Um send me some pull requests, send me some issues. Um let's make this a really awesome tool that we can enjoy and see some successes with in our various engagements. Um this is where you'll be able to find Moe's uh in a bit after the talk and the test labs as well. Um this is my contact info and uh at this point uh we have some amount of time that exists like five minutes for questions. If anyone has any questions now's the time. Thank you.