 Hello, my name is Stefan von Pui and welcome to my first and hopefully not last DEF CON talk. Today, I will be presenting my autonomous lateral movement technique that I have developed at my time as an intern at Prelude Research Incorporated. So before we get into it, I'd like to discuss a little bit about myself. So currently I am a rising senior mechanical engineering student at Virginia Tech. Hopefully there are some fellow Hokies watching. And I know what you might be thinking mechanical engineering. How does that relate with cybersecurity? Well, that's where my time at Prelude Research Incorporated has come in. So keep in mind I'm an intern. I've only been doing this for two months. I'm not super familiar with the field yet. So if I make any mistakes, please bear with me. Let's hop in. So the tools that I'll be using, I'll be using Prelude's operator, which is a command and control center. I will be using two Linux virtual machines, which will be labeled as workstations A and B, in which we will discuss in the next slide. And I'll be using agents and adversaries. Agents are remote access Trojans, in which this case I will want to upload and have it connect back to me. And adversaries are a culmination of TTPs, which I will use in my attack. Finally, we have AWS, which will be used as a redirector, which will allow me to have connections to workstations A and B and proxy back to my local laptop, which we'll talk about in one moment. So what is the goal? The goal of this attack is to gain control of workstation B through the use of agents and have full control using Prelude operators command and control center, which will allow me to distribute and execute TTPs to that set agent, allowing me to navigate and use the laptop. Or a network server. What is the plan? So as we can see here, that little circle me is that local computer that I am currently recording this talk on right now. I have connection to an AWS redirector, which allows me to connect to workstation A. In this scenario, workstation A is a remote workers laptop. So I drew inspiration from this attack, or I drew inspiration for this from the not patch attack, where they got access from a workers laptop and from there, laterally moved on to the IT network. That's what I'm going to be recreating here. So workstation A, for the sake of simplicity, we are already going to say I have access to. So that is a workers remote laptop. Remote work laptop. Workstation B is the IT network. So we know that workstation A and B have a connection because that worker has connection to the IT network and the real world that could be through a VPN, which allows the worker to have access to any company securities or protocols. So what we're missing is that purple dashed line, that arrow. So what we want is we want to establish a connection between workstation B and that AWS redirector, which will proxy back to my local laptop. That is our goal in this plan. So there are really only three steps, and I'm going to be describing in this first half of the talk my on paper details of the attack. So the three steps are the first one is to identify any known hosts on workstation A. Secondly, we will use those known hosts that we find to secure copy an agent, in this case, the new agent that prelude supports the new agent over an SSH connection to laptop B or workstation B. And thirdly, we will remote activate that agent over an SSH connection and have it connect back to our AWS redirector. And I know there are plenty of ways to do this. And as I mentioned, I'm still a beginner in this field. And through my research, I found secure shell connections to not only be versatile in their use, but also on the simpler side for me to understand. So this is the first step of code. We're going to cat, which will allow us to read the contents of a file. And in this case, we're going to do that in the hidden SSH directory and the known host file or list. So we want to cat that and read that. And these are the outputs of that. The outputs, as you can see, are the known hosts there. So the IP address and also on the right, you can see parse results, which we will get into later when we make it autonomous. So now you can see that we have parsed an IP address or the known host. And now secondly, we're going to move to secure copying it. So the way SSH works, if anyone's not familiar, we want to secure copy the file that we want for the contents, the host at IP address, and then the location of where we want to copy it to on that remote user. So since AWS supports Linux OS, and in this case we're using the default host name for that is ec2.user, which is why I took a stab and just guessed for that. That's why you can see that it's the host name I'm using. And in this case, the location that I'm distributing that new agent is in the hidden directory SSH, because at the time of failure, you want to place it in somewhere that's more obscure, obviously, so no one can find it. You'd be a little bit more discreet. The outputs of writing this command over operator are or follows with a green dot, which means that it was successful. A red dot would mean is a failure. Step three is to remote activate it over SSH. So again, SSH host name at IP address or the known user that we grabbed. The new agent right here, this is the properties, we're going to run it in a detached terminal, have it beacon back to my AWS address right here, and send any outputs or errors to know. Once again, just to be a little bit more obscure and discreet. And these are the outputs of that. You see green, so successful. So through those three steps, we found local, we found known hosts, we secure copied our agent and we activate our agent and the results of that are we went from workstation A to workstation B. So we're done. Nope, not yet. We're going to have a little bit more fun with it and make it even better. We're going to make it autonomous. Or automated. So now let's hop back into prelude. So that was the first step that was basically like our on plan on paper plan. So now let's go into here and I want to describe one feature to you. All right, so now we're an operator. I want to talk about their use of custom facts. Custom facts are variables that are saved to an agent as a fact. As you can see here, operator supports very many default ones. So now going into our editor, we can see the manual adversary, the boring way. So we can see that in the known, the parse hosts, there's an expected output, a domain, a file and an IP. These are all facts. So these are all variables saved to the agent as a fact, which can be called on and later used to create a chain, which will make things a lot simpler in this attack. So now let's get into the automated way. Tweaking the code a little bit in action and adding an extra line allows us to deploy this adversary and have it connect to any IPs or any hosts available to it that we have connection to. Just with one click of the button. So once again, we'll start with parse known hosts. Again, we will search and find and document any hosts. But what we are really looking for is this expected output. We want this IP dot T 10 18. We're going to use that again. So next step would be to secure copy. We're going to secure copy. And I can see that the codes a little bit different than it was before. This is a fact agent location is a default fact and operator that takes the agents location, the property location. So in this case, it's somewhere in the home user's address. I'll show I'll show it later on. But it knows it knows where to find it. So we're going to secure copy that agent location on workstation a which contains all the new properties. To the username, which I'll go back to at the IP address that we grabbed from parsing the known hosts. And we're going to upload it to this location a temporary temporary directory, new met Linux. So now going back to this username, this is the only manual part that I put into this attack. Since I knew that the default user for a OS Linux on AWS was easy to dot user dash user. I added that as a custom fact and I could add anything I could do adversary dot village and say us. Not sure how that would fit into this code, but if you have any suggestions, let me know. So now you can see that I previously added the user dot name easy to dot user. That's the only manual thing that I did in this. So now going back to the automated way, we're going to secure copy that new location on workstation a to the username at IP address from the parsing known hosts. Next, next, we're going to look at how to remote activate it to SSH remote activated. So we have the username and IP address run into attached terminal. And what we want is our new executable right here, our agent executable. To make it automated, I included a fact, but to be able to grab this fact, I added one more line of code. What we're going to do is over an SSH command, we're going to list the contents of that temporary directory that we uploaded our new Linux agent to. As you can see, the expected output is file T 10 21 dot 004. That is what we're looking for. And we're going to put that right in here so that it knows that this is where the agent location is on workstation B. We're going to name it workstation underscore B and have it address back to operator dot TCP. That is the AWS TCP port address. And then once again, we're going to send the outputs and errors to null. So now we have four steps all automated. And now let's test it out. So here we have workstation A. And we're going to scroll down to our adversaries and find our automated the fun way. And we're going to deploy it. And just like that, we have now connected to workstation B autonomously. Now the difference is in the manual way each step relies on each other. So two requires one, three requires two and one. So if I wanted to secure copy or do any SSH command, I needed to first know what the known hosts were and then manually go back into my code and change that. In this way, operator knows how to intuitively pick up the facts that it's learned and incorporate them into the next step, which creates a chain of attacks. Now, if we look into what actually happened, we can see that it occurred twice. So we found hosts and it actually picked up two different IP addresses. If it uploaded the numit to different two different IP addresses, it once again remote listed both of them to create that fact that we wanted and then remote activated each. The problem is, is I don't have credential access to one of the IP addresses, but I have it to I only have it credential access to one. So if this were a real world scenario and you were deploying this attack on a network that had several connections and credential accesses to you. It would result in a lot more agents connecting back and even more expansive network of agents that you control now. Alright, so now if we look in here, we can see the known hosts so we can see the IP address of the network that we connected to the IT network and the results of doing that and the activation, which resulted in our workstation B. Alright, and that was it for my presentation on my lateral movement technique on preludes operator. Once again, my name is Stephen Fompuy. As you can see, my contacts are empty knowing you guys are all professionals in the cybersecurity field. I'm sure if you want to contact me, you will find a way. Follow along on the blog, the prelude blog, because this was phase one of out of my four phase attack and come back in when I conclude my attack fully. Thank you so much for your time and I hope to be at the next dev con. Have a great day. Bye.