Embrace the Red: Enhancing Detection Capabilities with Adversary Simulation

Vielen Dank.

Can you hear me? You ready?

All right. Good morning, B-Sides. How's it going? I'm really excited to be here. This is my second B-Sides Baltimore first time presenting, so really happy. Today I'm gonna be talking about embracing the red and how we as blue teamers can leverage offensive skill set, adversary, offensive knowledge to enhance our detection programs. So that's kind of like the whole goal of the talk. I'm gonna talk about the benefits of blue team led adversary simulations and also gonna be releasing a tool today that hopefully can help you simulate certain attack patterns on your network so you can test your own detection programs. I'm gonna start with a real quick and kind of like to break the ice. How

many red teamers do we have on the audience? Can you raise your hand? Okay, how many blue teamers you're defending companies? Okay, and who are purple teamers? Who considers, ah, there you go, okay. I consider myself a purple teamer as well. All right, so we're gonna go ahead and start. Just real quick, a little bit about me. My name is Mauricio. I'm originally from Peru. Has anyone been to Peru? Couple of hands we have, nice. That's a picture of my home city. We have a big volcano in the background. Although with global warming, it doesn't look like that anymore. I currently lead the threat management team, the blue team at our financial services in New York. I used to be a pen

tester. That's my Twitter account and I always love to come to conferences and connect and so come say hi if you see me around. In the past couple of years, I've been doing some, sharing some of my work around threat hunting and threat detection on a few conferences, so you can find me out there. But let's just go ahead and start with our important piece. So I wanna start first talking about a little bit of how we're leveraging offensive skill set, offensive mindset to enhance our program, security program, right? If you think about it, you know, we've been using things like vulnerability scanning, penetration testing, red teaming. And these are great, right? And the goal of these engagements, assessments, however you want to call them, is to

identify weaknesses, identify attack vectors before attackers do, right? And then you close them and you are preventing attacks. So these type of assessments are helping us prevent attacks, which is great. And we need to continue doing them and, you know, encourage you. In the first few years, well actually four or five years, I think, we've been seeing a new trend on how to use offensive skill sets. And that is in the form of what people are calling adversary simulation or purple teaming, right? And this is kind of what the talk is all about, purple teaming. So what is this? Purple team is a coordinated effort between a blue team and a red team with one common goal and the goal is to identify gaps in visibility and detection

capabilities right so unlike kind of like the first bucket of services that we saw that focus on prevention I feel purple teaming focus a lot on detection and enhancing your detection programs purple teaming adversary simulation it's a highly collaborative exercise where blue and red are sitting down together working together going through techniques simulating them sharing notes sharing knowledge in general right and I feel like this benefits both blue and red because the blue team is able to understand how an attack looks like you know how can you actually simulate it replicate it and then with that knowledge you can go ahead and try to detect it right and but the red team also benefits because now the red team knows what are the capabilities of a

blue team so you can start thinking of ways of bypassing that so it makes us both stronger So back to our experience, you know, we started doing purple team engagements maybe three or four years ago at the company I work for. And, you know, after the first exercise, we learned the benefits right away. It was really good. After the two weeks on site with consultants, we had a good idea of what are the gaps in our visibility in general in the detection program. So we wanted to keep doing it, right? And we have. But I feel there's one challenge with this type of assessment. And the challenge is that we cannot do enough of them. And why is that? It's because we usually need a red team, so

we need to go out and hire consultants to do this. And we can only do this two or three times a year. And I'm sure all the companies only get to do this once, or maybe you don't have the budget for it. And this is kind of the main goal of my talk, which is we as blue teamers, I feel that we need to embrace the red. We need to go out. and learn these techniques so we can simulate them against our environments. And that doesn't mean that we're going to become red teamers or we're going to become pen testers. We don't have to. We don't need to know as much as a real red

teamer or like a professional red teamer, if you want to call it, to simulate some of these techniques. So that's the main takeaway, embrace the red. So having done this for a few years now, we kind of have a methodology that we follow, and I wanna share with you guys so you can do your own purple teaming on your organizations. so first one the first step is to identify the technique of interest right so you need to identify what do you want to simulate right and this could come from different sources probably the best source right now is the attack miter framework right you can go out there navigate and just go through all the techniques and pick the ones that are more relevant for you the ones

that you care about But this could also come maybe in a tweet. Maybe a researcher finds a new way of doing lateral movement, so you may want to try it, right? Or a report from a threat actor that is doing something interesting. Once you identify a technique, you're gonna go ahead and simulate the scenario. And I think this is the most important piece of a probability exercise. The scenario means you're going to research the technique, you're going to identify how are you going to simulate it, like maybe there are tools that are out there that you can use to simulate it, maybe you have to write your own, right? And this is kind of essentially how you're going to simulate it. Are you going to simulate it from

a rogue device on your network? Are you going to simulate it from an actual domain computer? You know, how are you going to do that, right? So you define all that, then you go ahead and execute the test, right? So here's the next thing, the interesting thing. In an ideal world, when you execute this test, certain logs are gonna get generated and ideally they're gonna be centralized in a central location like a sim, right? If you don't have these logs in a central location, you cannot detect it, right? You may be able to investigate it from an in-transponse perspective, but you're not gonna do real-time monitoring on this. So that's kind of where it takes

us on this on the next step of the workflow, do I have centralized telemetry for this technique? Because if I don't, I need to go back and fix that. And this could come in many ways. For example, you may not be logging certain event log and you need to turn that on. Or maybe you're logging it, but your event pipeline is broken and the event is not getting sent to your central location. So you may have to fix that. So once you fix that, once you have that log in a central location, you go back and execute the test once again. so we execute the test once again now that we have the logs and

now we go through this branch now we have the logs in our central location the next question is did a detection trigger? right? and if you're doing this for the first time you may not have a detection for it right? so this is when you go ahead and develop the detection the simulation sorry the detection so you may you have a log that is bad and then you have logs that are legitimate you know like a baseline from your users and you try to create a rule that is going to detect it with a minimum number of false positives, right? So now you have a detection. You go back and here's what it gets interesting.

You may say, okay, I already have a detection for this technique. I'm gonna go to the right side and say, finish, I'm done. I don't recommend you to do that, actually. I think you should go back and execute the same technique in a different way. Because that way you're gonna test the resilience of your detection. And this is really important. I feel that if we simulate the same TTP under different scenarios, we're gonna test the resiliency, because the different scenarios will create different logs, and your detection logic may not work for all of them. A quick example is a Kerberosting attack, right? I'm not gonna go deep in what a Kerberosting attack is, but essentially, it allows an attacker to escalate privileges on an active directory network by getting

the hash of a service account, potentially cracking it, right? So if you want to purple team this technique, you'll go out, research it, and find out there's a few ways you can replicate it. So let's say you find these first two tools that I mentioned here, invoke Kerberos and get users SPNs from Impacket. The first one is for PowerSplot, second one for Impacket. So you execute this in your environment. And this looks really interesting, because the way these tools work is that they're going to basically get a service ticket for all the service accounts that have an SPN related to them, service principal name. And this looks really anomalous in the logs because all of

a sudden you're going to see one user requesting for 300 service tickets or however many accounts that you have with an SPN associated. So this is really easy to catch. All you have to do is create a rule that looks for event 4769, service ticket requested, and look for a threshold, right? And that's it. So you're done. So you may say at this point, OK, I have a detection for Kerber hosting. I'm done. Hold on a minute. What if an attacker is you know, a little bit more stealthy. What if instead of just trying to get a service ticket for all those accounts, they do some enumeration, use something like PowerView or SharpView to figure out what are all the accounts with SPNs, and not try

to grab a ticket for all of them, but maybe just pick one. And you can use the tool Rubyus to grab a server, a carrier ticket for just one of them. Your detection is not going to detect this, right? So that's kind of the whole point. If you are not simulating the same technique under different scenarios, your detection is mediocre, basically. So now I want to get to the main piece of the talk. So I'm going to do an exercise of simulating password spraying. So password spraying is a really effective technique that allows you to iterate a bunch of users with one password. I have a lot of red team friends, and they love this technique. It always gets them

in. So we're going to do a simulation for this. for this type of attack. So we're gonna go for our first exercise. We're gonna say, all right, the scenario is that an adversary has obtained physical access to your network, so they are now connected to your network with a rogue device, all right? So we're gonna validate one password across all your domain users against a domain controller using NTLM authentication. So the tool that we're gonna use is LDAP search to help us perform LDAP queries, and then Medusa, which is like a, you know, I don't know how many years, year old tool this is, but it's been around. So first thing you do is you're

gonna do a few old app searches to get a list of domain controllers, and then randomly pick one, make sure it's alive, then run another old app search to get a list of users. Once you have those, then you're gonna run Medusa with just these parameters, and that's gonna generate a spray attack. Once we go to the next step of the Probable Team exercise, we go to the assessment and we find out that, yeah, our domain controllers are logging, failed account log on events, 4625, and we actually have a detection for this attack, which is kind of, the rule looks like this. It's basically looking for 4625 event, log on type three, which means a network connection, so remote connection, and you're grouping by the IP address, the client

address, and then you just put a threshold. You could put three or five or 10, however you want, right? So that's good. First exercise, we learned that we have some detections for password strain. That's awesome. Let's move on to a different iteration of the same attack. In this case, we're going to simulate an adversary that controls a compromised source on our network. So no longer a rogue device in our network, but an actual domain computer which has been infected by a fish. So we're going to validate, slightly different, we're going to validate 50 domain users against one domain computer, no longer a domain controller, using Kerberos this time, not NTLM. So in the tool that we're going to use is just leaving off the LAN,

command line and PowerShell. So the first command, net user, is going to give us the list of users. Second command, net group, is going to give us the list of computers. Then we manually have to go into this list, pick 50 users, go into the list of computers, pick one computer, make sure it's alive. And then you run a tool like there's a lot of them out there, PowerShell, that can do password spraying. I wrote one called Invoke SMB Logging, really simple. that and you can spray it. Alright we go to the next step simulation is done let's go to the assessment. We find out that our domain controllers are not logging Kerberos events so you cannot see this attack basically if you had domain controller Kerberos events

logging you would see the 4771 Kerberos ticket requested failed. So

Now I find, now we learn that we need to enable Kerberos logging. So one first achievement, we know that we have a visibility in our monitoring. So the next iteration, it becomes even more interesting. What if, once again, just like the one before, an adversary controls a compromised host in the network, but this time we're gonna validate one password on 20 domain users. against 20 domain computers. So we're going to do kind of like a distributed spray where you're sending one authentication attempt per computer instead of all of them against one, right, to make it more stealthy. On top of that, we're actually going to add like a sleep time, five seconds between each of

them, right? So this is definitely the same technique, but more sophisticated, more stealthy. So the assessment is we find out that our member endpoints in the domain are not, the events are not being centralized. So you do have logging enabled, you have your right GPOs enabling logs, but all the logs are scattered in each computer and they're not central. So you have a gap in visibility. Another thing that you find is that your existing detection analytics, the one we saw on the first exercise, does not contemplate a sleep time so even if you had the logs you wouldn't be able to detect this because the sleep time just breaks it so now you find two other things about your detection program right so what if you keep doing this

right and keep changing things like instead of using domain accounts you use local accounts because that looks different on the logs instead of using coveralls you use ntlm so all these variations right so after doing this two or three times with with third party consultants and us internally, we quickly learned that there were a lot of manual steps of grabbing a list, copying, making sure a host is alive. So I wanted to, I said to myself, I can probably automate some of this. And a few months ago, I started writing something that I want to release today. And I call it Purple Spray. Purple team in password spraying, Purple Spray. So all right, I'm gonna explain what Purple Spray is. Purple Spray is an adversary simulation tool that will

help you execute password spray behavior within different scenarios. Like basically all the ones that I discussed, Purple Spray supports. Focus on Windows Enterprise environments. It's going to help you in three things. Identify gaps in visibility, test your detection resiliency, and maybe helping you create new detection analytics that you didn't have before. Right now it has two modules and they both target SMB as a protocol for the spray. So just real quick, I already talked about this, but what are the supported scenarios for Purple Spray? First thing is that we can simulate a rogue device in our network or a compromised host. And this is kind of like what the two modules that a rogue give me. And I'll explain a little bit of that

in a little bit. But again, that looks different in the logs. If you have someone connected like a Linux computer in your environment, non-domain joined, it's going to look different from your domain computer generating the attack. It can target random users. So I do LWD queries and bring down random users and target them. And to minimize the risk of locking any user out, I use this cool attribute called bad password count that basically defines how close you are to a lockout. So I just query based on that and now I'm never gonna look at a user, so it's safe. I can target different roles and random hosts in the environment. So for example, I can target a randomly picked domain computer

or randomly picked domain controller or several randomly picked domain computers. And why do I do this? This is interesting. When you're doing a purple team assessment, you're probably hitting your main domain controller, and you're checking, all right, I have detection. But what if an attacker is actually pointing to that server you have in a cabinet in Asia where you have a read-only domain controller, and that domain controller is not logging events because GPO broke or there's a firewall rule blocking the events? so by randomly picking host again for your sprays you're making sure that your system your security monitoring program is actually effective right so that's why I do that and purple spray does it automatically for you you can spray domain

accounts or local accounts because that looks different on the logs if you authenticate with a local account it's gonna leave a new type of event 4776 credential by the credentials I forgot the name And why is this interesting? Because red teamers love when you have a local administrator account password across all your computers, right? So if you're looking for a local account authentication, you may find an attacker trying to do that. It can support Kerberos or NTLM. That looks different in the logs also. It can also sleep between each authentication event, kind of like what we went over on exercise three, right? So all these possible scenarios, the tool supports natively, and you don't have

to just pick and choose and grab notepads and copy and paste the way we used to do purple spray, sorry, purple teaming on password spraying. So if you think of any other scenarios, let me know, because I want to implement them. And now we go to the demo. So we have 10 minutes for the demo. OK, that's good. All right, so the first module is in-packet spray. And I call it in-packet spray because it uses the in-packet library, an amazing library that implements Microsoft protocols to do authentication events. This will simulate an adversary leveraging a rogue device. So this would simulate an attacker breaking into your network, connecting a computer, or maybe getting access to a VPN through a bad username and password

and now they have access to your network through a VPN. So we're going to go ahead and show you the demo. I have a video because I don't want to challenge the demo gods. And there you go. Here's Pulper Spray. So I have a domain environment with 10 VMs just to simulate a real environment. as you can see here, and I'm gonna run purple spray which is kind of, if you've used Metaspload or Empire, it's just identical, it has like a CLI menu. It has two modules right now, I'm gonna use the module, and I'm gonna show options. Alright, what are the options that I need? First, it needs information to be able to query LDAP, right? So username, password, domain controller, domain, right? then it's going to

have a has a field called domain users and you can say true or false this variable is going to define if purple is going to go and query LDAP for actually getting legitimate domain users or if not it's going to generate fake accounts like just random local accounts so random strings that are going to be treated as local accounts on the host it has the the actual password spray that you're going to use. And here's the interesting piece. It has this variable called type. And I support three types right now. Type 0 is you're going to randomly pick a domain controller and spray it. Type 1 is I'm going to randomly pick a domain computer

and spray it. And type 2 is I'm going to randomly pick more than several domain computers and spray them in a distributed way, one authentication attempt per computer. So that's kind of what the options are. So I'm just going to quickly run it. Let me see, is this running? Yeah. OK, so if the video helps me here, I'm just going to set some variables to authenticate to LDAP, set username, set domain, set IP, the domain control IP address. And I'm just going to hit run. So you just quickly show options.

We run it and here's what it does, right? It goes against LDAP, gets a list of domain controllers, picks one randomly, goes against LDAP, get a list of users, and then once again, picks them randomly and sprays them against that domain controller, right? And you can get like the, you know, whether it was an invalid authentication event or not, successful. And then I can go to the logs of my domain controller, refresh, and I'm gonna see the 4625s there, right? There you go, you can see them, right? Now, what I used to do before, it was like a new simulation. I would have to use different tools, go to the notepad, and copy paste things. If I want to run a different simulation, all I have to do now

is just set a different type. And so now I do set type 1, which is going to pick a randomly big domain computer. I'm going to set the users to 5, because I only want to spray 5 users. I'm going to set domain users to false, because I want to generate, like randomly generate accounts. And I'm gonna hit run. And you'll see it, this time it targeted my Windows 2008-1 with these accounts that are random. If I run it again, you'll see it again hitting the Windows 10-2, right? So it's randomly picking different hosts to spray, right? And if I go to the logs, here's the interesting piece, right? You see on the logs of this Windows 10 computer that It generated failed authentication

events, 46.25, but also generated 47.76, which defines when someone is trying to use a local account. So again, this is the value of other simulation. You're learning how attacks look like in your logs, and you can create correlation rules for them. And you're enhancing your detection, once again. Alright, and the last one, the most sophisticated one, we're gonna use set type 2. In this case, remember, I'm gonna randomly pick more than one computer and spray for one user per computer, so we're distributing the attack across several computers. And this is gonna look really interesting on the logs and probably defeat some of the texture. So I run it, same LDAP queries, and as you can see now, I hit it, Windows 10-1, 2, Windows 7, So, spread it.

Now, even more interesting, I'm going to set a sleep time, and I'm going to sleep three seconds with each authentication attempt. I run it again, and now, once again, distributed spray waiting three seconds per authentication event. So this looks different on the logs. Once again, you're going to confirm if your detection is working for this type of scenario, right? So that's demo number one, and I have five minutes, so it's good. Demo number two. I have another module called Empire Spray. This simulates an adversary with control of a compromised domain host. And the way this works is I wanted to simulate a hacked computer performing sprain attacks, but I didn't want to write my own command and control you know, payload

or server, so I use PowerShell Empire, which has a great API, and I can just use it. So what this does is basically you infect a computer with PowerShell Empire, and PurpleSpray talks to the PowerShell Empire API and just instructs this agent to perform simulation. So you can simulate, actually simulate, one infected computer on your network doing spray attacks, right? Okay, so we're gonna go to demo number two. And I don't know, okay, there you go. OK, so I'm going to, first of all, this module has one difference on the main options, which is it has a use Kerberos field, because with PowerShell Empire, I can choose to use Kerberos or NTLM just by using hostname or IP address, right? Really simple, but

they do generate different logs. so that's one difference. The other difference of course is that I need to set other type of options to define where my empire server is, the username, the password, the port, so you have these on the advanced options. Now my tool also allows you to automatically infect a computer with a PowerShell Empire module using WMI execution, remotely WMI execution. In this case I'm gonna use a different way of getting one agent. So I'm going to stand up our empire server on my other tab. There you go. I'll just stand it up, empire dash dash rest with the password. Empire is going to instantiate. It's going to listen on that port. And now I'm ready. So what I need to do is, on

Purple Spray, I need to configure the information of the PowerShell Empire server. And I'm just going to hit initialize. And it's going to connect to it. check if there's any listeners. If there's not, it's going to start one. And then it's going to check if there's any existing agents, like any existing compromise source checking in. If one exists, it's just going to use that for the sprays. But if it doesn't exist, it's going to complain, say, hey, I need an agent. So there's a few ways that you can get an agent. But I also added this simple feature that allows you to get a few stagers. So all I have to do is execute the

command stagers. It's going to go out against PowerShell Empire to get the standard like, you know, BBS, HTA stagers. It's going to write them to a folder. And if I do an LS, I have them here. So now all I have to do is serve them in a web server, have a victim go. We're simulating. We're going to assume that a victim is going to click on a link and get compromised. We have to assume compromise. So in this case, I'm going to replicate that initial compromise. And I get an empire shell. Let me just fast forward. I get an empire shell. And so empire now has an active agent. So I'm going to go back to PurpleSpray and to my tool. and run initialize once again. And if

I hit initialize, now it's going to find that agent checking in, and it's going to use it for the spray. So now we're at a point where we have an active agent checking in to PowerShell Empire, and I'm going to use that agent to spray. So once again, it's just similar like we did before in the first demo. I'm just going to play around with the options here. I'm going to set CurverRows to false, so I use NTLM. I'm going to run. This time, instead of my Cal Linux performing the authentication events, it's just going to instruct, hey, agent, run this PowerShell module. And it's the same part. When I wrote this, I didn't find

a PowerShell Empire module that was doing what I wanted to do. So that's why I wrote SMB login. And then I wrote a PowerShell Empire module for it, which is really simple. But anyway, it's working. So you can see on the PowerShell Empire screen, you would see this. But you don't have to because everything's from Purple Spray. So you can play around with the options, once again. But you can do the same scenarios I was doing before. But in this case, the attacks are all going to come from what domain joined compromised computer. So I only have a few more minutes. I'm just going to fast forward. All these videos are going to be out.

on YouTube also as part of the GitHub page. But just to sum up, there's a few things that I want to do next. I want to support other protocols, like Exchange Web Services, HTTP, NTLM over HTTP, to be able to target things like ADFS or LingQ or Skype. I want to add some reporting. But if you have any ideas, like if this, If you have any ideas for any other type of scenarios, let me know, because I'm looking for them. And I just want to say a few acknowledgments. This tool, this project, wouldn't be possible without these awesome projects. So thank you, community, for releasing these things and helping me build this. And I just want

to finally say happy purple teaming. and I'm going to be making this repo public in the next five minutes so you can download it and play with it. And that is it for me. I don't know if we have time for questions. Thank you for coming.