 Welcome back and thank you Corey and Matt for supporting us, supporting the Red Team Village, supporting DEF CON and the community and without any further ado take it away, your life. Thank you. Thanks Omar. So this talk is called Breaking the Attack Chain, Unexpected Wins and Fails from Two Stimulated Adversaries. So here's the agenda. We'll start with who we are and then we're going to cover some wins and some fails across a broad variety of different categories of Red Team topics and I'll finish off with some of our just notes and also open up the floor for questions. So who we are Matt, you want to say who you are. Sure. So, Matthew Adelberg, I'm a principal security consultant at Optiv. I also help lead the adversary simulation team. That's pretty much our fancy way of calling or what we do for our red, purple and physical based real world scenario based driven operations. Also authored and developed several open source tools and frameworks, mainly focusing around like EDR, evasion and bypassing security controls and remaining low underneath the radar. That's really where my passion is. I did do for a while in the beginning of my career focus a lot of wireless. So kind of that all spectrum sort of one area, a different area. So looking at numerous different conventions, you know, Derby Khan, besides Las Vegas, Hackfasker Khan, really just passionate about red teaming operations and like the nuances and always improving that concept of sharpening that spear staying low to the ground. I'm going to turn it over now to Corey to kind of give a brief introduction as well. So I'm also a principal security consultant at Optiv specializing in adversary SIM or red teaming or whatever you want to call it, depending on the buzzwords of the day. I've participated in some open source tool development and then my passions really center around like data aggregation and building lab environments for the for the red teams basically. So before we begin, I wanted to basically caveat this red teaming is a different thing to different people. This presentation is based on our experience during our engagements real world scenarios. These are not, you know, made up. These a lot of them include real screenshots from real engagements. Everyone does this differently right so some people's definition of definition of a red team is just an app testing team. Some people's definition of red team is a full blown zero knowledge assessment every year every two years or whatever. So everything in this presentation is also situational. So we're not going to cover the clients demands. We're not going to cover the, you know, that it was raining that day or whatever reason we have for each scenario. So there might be a little bit of background information that we're going to cross over, but it should be fun. This talk is it's kind of kind of be a briefing style. So it's kind of almost like if we're talking to you could be for a red team or if you're a blue team and sort of covering our debrief of a lot of these scenarios that we've encountered on different assessments. So kicking off the first topic here will be Matt with some OSIN stuff. Yep. So we all know what OSIN is. It's one of the most I always believe it's one of the most vital things when you're starting off an engagement. You know, we're basically just professional Googlers. Well, one of the things that differentiates, you know, just quickly Googling, seeing what you can get and like a deep methodical approach is honestly the level of detail, whether you have proper API keys, you're scraping the right data. And as I kind of say this, all those different things we know they can be sometimes an endless rabbit hole where you go down and you never know if it's going to yield you stuff. You could be starting to pull down, you know, employees, Instagram posts, Facebook, you know, all those types of social media things pulling out trying to see if there's maybe a picture or something or some kind of metadata that you can scrape. And you can be doing that for thousands on pictures and it may yield nothing, but oftentimes it's still a very vital role and can lead to a lot of unexpected wins and successes which we're going to talk about. And you can kind of see with this great example, a bit of background. We like to call this, you know, hashtag Mondays might delete later. I see no problem. A bit of the background on this is we were looking at a client we were doing a remote breach simulation, which is our terminology for red team ops. And we did that typical started building the profile looking at who the employees were trying to getting an understanding of what information was out there until we stumbled across the company's Instagram account. And this picture was originally taken by another employee that the company's Instagram account kind of liked and retweeted. It was basically just, which we have blurred out a bunch of PII information, which included, you know, date of birth, home address, credit card and transactions, a lot of other very sensitive stuff. But there was a lot of these types of pictures just sitting on Instagram. So one of these things we always like to drive is sometimes we don't even need to get inside the network, get domain admin, do all those cool lead hacks to get that crown jewels vital data. They provide it to us. And I would say that this is not just a one unique time. This is something that's constantly out there. There's a lot of companies, they train their users, they don't click on phishing links, don't click on this, but they don't teach them, don't post this or this is bad. This is something sensitive, especially when it comes down to certain departments, when you look at a marketing team, they're not given the same level of training that maybe someone that actually handles sensitive like, you know, credit card data in the sense of those two different things. The awareness there is, there are huge gaps. And that leads us to our next sort of major one that we love to look at our pay sites. You know, there's many different ones, Pay Spin, anything like that. I mean, scraping these are just, you can yield a plethora of data. I mean, it's not a lot of money. I mean, I believe now for a pro license for Pay Spin, you can, for $50, you can scrape to your heart's content. You put that in say like a Kalbana instance, like Elk, and it just enli scrapes. You can kind of just make a search thing like search client name and look at every single thing that references this. And that's honestly something so simple, so unique and so fast that you can yield things like usernames, credentials, APIs, how to even credit card and other sensitive PII. As you can kind of see, we've been able to pull out actual credit card information going right down to the user's security questions, where they live, their phone number, like, you know, all that information with all that information, we were able to actually, because the client was a bank, provide an impact scenario where we could actually bypass all the security controls and start doing some financial banking on behalf of this individual. Because all their controls were like, you know, give me your, you know, what's your, you know, bank account number? What's your security answer for this? What's your secondary one? And do you still live at this address? What's the last word digits of your phone? All those typical, you know, security controls to prevent, you know, fraudulent are all out there. It's a great plate hackers constantly dumping data there. And in the top example, we actually can still find valid credentials. We found two year old valid credentials to a third party portal, which led us to have access to a setup site. And from there, we are able to get enough information that allowed us to establish a foothold into their internal network. So something like that can sit there for years before it's even discovered by the client. And that drives the impact so much more. So what can you do? And kind of this will be the style of that debrief is how do you break this chain, like, in the sense of all these wins? How do you break this? How do you prevent this from happening? And, you know, it's really hard, especially when data is out of your control when you get stuff on those pay sites, it's next to impossible to take it down. So there's no surefire of, oh, this is up there, we'll bring this down, we'll, you know, cease and assist. And that will be the end of it. Especially like when I was just describing with pay sites and being able to scrape and have that local database, once it's there, it's hard to get rid of off every individual who's scraping. So it really comes down to understanding what's out there. Find those information sources through profiling or intelligence gathering. We like to call it like public information profiling or data intel. Just performing that on yourself, your company regularly to understand, oh, there's new data coming out there. Now I have to adjust. So it might be, hey, you know, we discovered a couple clients, sensitive data out there. We need to contact them now and get all that stuff scrubbed. So that way it's not valid anymore. And even things like that, as well as awareness training, not just looking at, hey, users, don't click on links or if you get a phone call from someone suspicious, don't follow the instructions. But it's training them through like impact, you know, here's a picture of something. And do you think this is sensitive? Well, here's what an attacker looks at it as, and this is why it's so impactful. And just kind of visually explain to them why this is so detrimental to post. And that can oftentimes help reduce that gap from like this big to like this big. You're always going to have a little space and that's where the intelligence sources come into play. So those were some pretty cool wins you had there, Matt. But I figured we could cover some failures, right? So obviously, a lot of successes do happen, but also failures happen. And I think, you know, maybe blue teams and red teams can learn from some of our red team failures. So this is what I like to call the red herring domain. So basically, the TLDR is that email alias domains do not make great password guessing or enumeration targets. So we all remember when Office 365 Enum worked perfectly, you know, those were the Halcyon days of, man, that was a good time. But basically, the client had, you know, client domain.com was their their email address as what they use publicly was on all over their website and everything. So we figured this is this has got to be, you know, this is easy. It's just that's what their domain is. We started password guessing. And we're getting all kinds of weird results, you know, valid user invalid user, bunch of 401s and weird, like some users have two vectors, some don't. It was very incongruous of what we're used to seeing. And basically, we were like, hold on, is this really their email domain. So we actually used reverse DNS or reverse who is view DNS has a very cool reverse who is told where you can basically type in the contact information of a registrant. So, you know, info at client domain.com or whatever. And then you can be all the other domains that are registered to that email address. Obviously, you can get a little hairy if you have, you know, anonymization with who is records. But basically, we use that we pulled up a list of all the valid domains that were registered to that client. And we looked at actually for each one we went through and checked them against Office 365. And then eventually we found the real one, which happened to be my client domain.com. So it was just sort of a weird scenario where we basically burned a few days with on an assumption that this was obviously the domain. When in reality, the domain was something else. So I guess the takeaway is to trust your gut, check and then double check, right, if you're you're getting on in Congress results or something that doesn't match up with what you're expecting when you're executing a tool or whether you're doing it manually, dig into it, figure out what could lead to these different results. You know, the get user realm functionality of Office 365 you can use to sort of manually inspect each individual element and see, OK, is this a valid domain in Office 365, etc. Those sorts of manual checks can keep you from doing these, these fails. So that's going to cover another funny one about building. Yes, we thought, you know, it'd be fun if we both share our experiences in the fail realm. So this is the one we I like to call wrong building. So, like I kind of said that rabbit hole it can lead to so many great results that also can fight. Yeah. So in this kind of bit of background here was the situation we were hired to do a physical breach the session to break in physically into a building. The building in question was this large commercial high rise and we're let's just say arguments in the story, the seventh floor. So we did a lot of OSINT and we are able to find some information including a page for the building that basically listed out, you know, who is the property managing company like who was the actual person on site. What was the vendors even forms the fella say, for instance, if you were one of the tenants there and say, you know, telecom went out or pipe first paperwork and all that stuff, you know, who to contact. Here's like, you know, all this other information to the know which building and everything like that. It was great. We were so happy because right there we could create a perfect scenario. And we did we kind of decided to come up with a scenario that we were, you know, coming into the building going to be doing some telecom fixing on some of the floors. We got even so detailed, we were able to kind of create a fake work order. We were able to find out uniforms for that vendor. And we dressed, you know, perfectly right down to the level details we had called beforehand knowing when the office manager for the client was out. We left the voicemail. We left lots of different things just pretending to be the property manager say, Hey, we have some guys coming into the building. They're doing some work with telecom. I've been getting a lot of calls throughout the day just people verifying them. I just wanted to let you know that they should be at your floor in the next 20, 30 minutes. I'm just stepping up for lunch. So I may not be able to be reachable by phone. But if they do have them show the work order and make sure everything like that their names are blah and blah and everything like that. We really had provided enough information so that way they could go listen to the voicemail and say, Okay, there has to be work or we have to check all those things. We were kind of creating that self validation. So we get up there, talk to receptionist receptionist goes, Okay, I got to go get the office manager points us up to, you know, like the sitting area. We're sitting there. We're sitting there. And then maybe we kind of realized it's been a while. Five, 10 minutes later, the office manager came out with someone else who was the property manager. And they were like, So who are you guys? Because you're not anyone I've ever worked with. You don't even work at the company I've never worked with. I'm like, Oh, well, you know, so and so that's the property manager contact us. He probably he left the call. He's like, Yeah, but here's the thing. He works on the bottom floor in the retail section. I handle all the commercial high rise and corporate stuff. So I'm going to ask you again, who are you? Are you doing that situation? You kind of have egg on your face. You know, we had done such great OSINT and everything like that. But the problem was we didn't realize that the building was split property managers for retail and the corporate renting. And in that moment, like your perfect free tax and everything like that just goes out the window. So me and my colleague were saying that we literally had this conversation just starting to try not to like sweat and everything like that. You can't just instantly pull up like to get a jail free card, but yeah, this was a scenario and stuff. You try always want to de-escalate. So you do your best like, OK, that seems really weird. You know what, let's just stop. Let's take a moment. I called someone who was obviously a coworker of mine and pretended like I got the voicemail. And it's like, Hey, there's some issues going to explain the situation on the phone. We're not going to do any more work, all this stuff. Just trying to really paint it off that we don't want to do anything because obviously they're very tense and upset. So it's really taking those steps to de-escalate it. And then up, you know, we're like, OK, well, you know what, let's give a business card to give us the business card. We're going to call. Let's maybe get everyone there. We can figure this all out. But I will tell you that was the most awkward elevator ride down when they came with us in the elevator. We just sit in there like this elevator is going so slow. The moment we got to the ground floor, we shook their hands. I'm pretty sure we had a little bit of sweat on our hands and we're just like bolting right out. So those are the things where, you know, sometimes OSINT can really, you know, bite you in the butt. All right. So taking a left turn here, so a different category than OSINT, initial access. So initial access, you know, we can define it as, you know, that initial point of compromise, right? So nowadays, starting from that perimeter environment, a lot of attack services are heavily limited. Companies have, you know, nothing but 80 and 443. It's pretty much SSO everything, redirect everything through their central auth and everything's multi-factor, right? So the approach here as an attacker is to prioritize that breadth-first search for that weak point, right? So, you know, if it's Office 365 and they have basic auth enabled on EWS or something like that, that would be an example of a weak point. Or, you know, here's some other common techniques. Obviously, we're not going to cover any of these in depth, but, you know, password guessing is really common. Web app vulnerabilities, if you can get DC realized or some other, you know, similar, you know, roll your own web app issues. Spearfishing is common. Phone pretexting is common. And then lastly, physical access isn't easy, especially as a backup plan. It works pretty well. So multi-factor spear phishing. So phishing is dead along with phishing, right? We have seen, especially in the past couple of years, that phishing is really getting a lot of eyeballs as far as tooling solutions and just general alerting and controls. Attachments don't work from the perimeter anymore with an email filter. Email filters have their own URL filtering now. Any email that's sent to more than five people, for example, might just get blocked because they're assuming it's spear phishing. People are good at reporting them. I mean, I guess it's like over the years, we've finally started to get better at training people and developing technical solutions so that it's actually not as successful. However, it does still work, even with two factors. So we like to actually focus not necessarily on passwords, but actually on tokens. So, you know, there are MFA-compatible phishing tools like Emulgenix or Mudlishka that actually lets you gather the tokens. So you're actually, with these tools, you're essentially sending a message with the URL in it. The user is browsing to that URL and then they are basically using you as a proxy to interact with the real site. So if they're using your site as a proxy, you can capture all the authentication tokens, API tokens, whatever it is that that user is sending. And why do we like tokens? Because tokens are harder to track. Lots of people don't have anomaly, you know, alerting or anything like that on token usage, right? So, you know, if I log in from a new device, it says, whoa, this is a new device, you need to authenticate it. But if I just take the already valid token and replay it onto another device, oftentimes it just works without any sort of double checks or anything like that. The other reason why we like tokens is because they're harder to reset. So a lot of the traditional IR procedures, they focus around active directory, right? So you reset your active directory password, you lock the active directory account. That doesn't necessarily have any triggers to a third-party SSO site. So if it's, you know, octa or another provider, there's no link to active directory that necessitates a token refresh or a deletion of all the tokens when a user has an incident and the password is reset. So here's a scenario. Basically, here's a screenshot of Evil Genics output. The SID token, this is specific to octa, but basically after we authenticated, the user had authenticated to our Evil Genics and then they have pretty much realized, you know, okay, that's not great. But we were actually able to use that token to access their octa portal, basically, which had access to, you know, not only all their other third-party apps, but also VPN or other similar, you know, higher security context things which potentially could yield to a foothold. So before, you know, before I start breaking into action, Leslie, you want to mention just if you're a red teamer, next time you get a token or if you do fish a user with that, you know, Evil Genics or another solution, do what you would do with a credential and actually do stuffing. You know, try to use that API token across as many different applications as you can and you might be surprised at how easy it is to just put the token in and then go. I mean, it's with octa, for example, you literally just put that SID token in your browser, go to the company's octa site and at least at the time that this gig was executed, it worked. There was some JavaScript, some resource integrity stuff that we had to bypass, but it was, you know, API tokens or bearer tokens, it's definitely a good area to focus. So breaking the attack chain, right? How do you fix this? Because it's really tricky to monitor like octa doesn't have default alerts for geolocation token usage, right? So you should generate those alerts, right? So figure out how within your sim or whatever to alert on token usage, not just password usage, right? Instead of suspicious login events, maybe look at suspicious token usage or just session, you know, a session happened to move from this site to this site or whatever or a different user agent or whatever. And also build those connectors so that those tokens are automatically reset if the user does change their password. Or if it's not automatic, build it into a playbook so that your incident response says a user got phished. Not only do we reset their active directory password, but we also reset their octa tokens just or their, you know, Office 365 tokens or any kind of tokens. Typically, there are tools within these web portals to actually manually refresh a user session. So build that into your IR playbook so that you don't have, you know, that token that's been out valid for 24 hours after the password was changed. And then lastly, here's a little shout out. Generate IOC is for known tools. So for example, Evil Genics actually has a hard coded IOC built into it. I won't say it's been published on Twitter before. I won't say exactly where it is in the GitHub, but if you're using Evil Genics and you haven't forked it and edited it out and removed the IOC from it, it should be easy to be detected, right? Attackers sometimes use off-the-shelf tools like Evil Genics, and that's relatively easy as a blue team to download those tools, run them, execute them, and see what that looks like and then generate IOCs based on that. So after some successes, I'll cover a failure. So this is what we call the traveling user problem, right? So we have, for each engagement, set off alerts with bad IP hygiene. We typically like to use non-distributable IP space, right? So Amazon, Azure, VPNs, et cetera. But that's a double-edged sword, right? So users don't usually use AWS, right? And also geographically improbable access. So if a user is based out on the East Coast and you're using a US West Amazon instance, that could trigger an alert if you sign in as that user and it says, oh, this user just signed in from here and then they signed in from there. And also reusing that single cloud, we're lazy, right? We're red teamers. We have so much going on. But sometimes you get lazy. We'll reuse the same IP address that we've obtained for multiple accounts, right? So, you know, maybe we log in on that one instance and then we log in as another user just to test those credentials, right? That's an easy indication that not only is it an AWS IP that's authenticating to our VPN, but also they just authenticate it as two valid users and it's not like an office location, right? So for red teamers, how not to fail, know your IP space, right? Use some of those blue team tools in your red team engagement. So check your ASNs, right? So I put some links at the bottom of different services you could use to check the IP reputation or sort of the footprint of the IP addresses that you're using and tell the story as well, right? That's sort of our 2020 breach team slogan is tell the story. But basically, one IP is mapped to one valid account per effort. So if we're going to trigger a valid login as a user, we're going to actually start that pathway of emulating. That's when we'll say, let's go into it. Let's make this IP address, this user's IP address, and then keep using that for the rest of the engagement basically. So that is very, it's harder. Obviously, they can still alert on, hey, this is an AWS IP logging in and that shouldn't be the case. But also they can say, well, they did log in here and it logged in there that maybe they're just using a VPN or whatever. So it can be a powerful thing. Yeah. All right. Now we're going to flip over to foothold. And before we kind of go there, let's kind of do a little bit of an explanation. When we talk about like initial access versus foothold, we're really kind of differentiating the two kind of concepts of, hey, we were able to get some access through password guessing. It may have given us a small step in, but we're not at the stage where we can start using our post-exploitation frameworks, whatever that is. That's where we call the foothold. We've established the beachhead and we're moving, we begin that pre-legislation and moving laterally. So that's the major definition and difference. So in this example, which we're going to try to talk about, this is actually a runoff of what Corey was just describing with the octa and SIDS and tokens. So we were inside their portals and we were able to get access to several different applications because we sent out a fish and one user clicked it. So we had tons of access, but only through their portals, like the tiles and whatever, you know, the subsequent applications that were exposed to the internet. So as we're going through all these different sites and third-party applications, because we had access to the email account, we saw an email have been triggered. We're like, okay, it was kind of weird because it was an IT ticket. And basically it outlined, as you can kind of see right here, was, hey, something done wrong. And it basically was, I clicked on this. I know something bad. I've already changed my password twice, which kind of goes back to what Corey said to people in resetting those octa or, you know, those tokens and SIDS are, because at the end of the day, we didn't need, like, the user had changed her password so many times, but we were still in. They had already, they also attached our email, so our spearfish email, as well as the, you know, Secure Alert of Sinon that we had triggered by logging into an application that we weren't aware of had like that notification prompt built into it. We were just pillaging through the data, as much information we can to help kind of solidify our next stage of moving into that foothold. So, I mean, I helped us take it with our spearfish and all this stuff, pretty damaging, right? Hard to kind of back, you know, move around and something. So going back to my initial thing with the story about the building, you have to always de-escalate. So what did we do? We removed the attachments and we replied back saying, sorry, my bad. And within a few seconds, because good old help desk, they closed the ticket instantly with a nice little message saying, hey, don't worry about it, I'm glad you were able to be assisted, if you have any other questions. And we also took an additional step by actually adding a mail rule that any type of emails that were related to this help desk ticket would be put into the user's junk bin. So you never see it. With all of this, we were able to then kind of do a comprehensive internal spearfish, targeting a couple of the employees that reported to this user with a typical great macro document. It was an Excel time sheet that they actually had been passing around, all the staff passed around. And we basically just added a few verbiage saying, hey, we're having trouble seeing it. You have to enable macros. Can someone take a look at this and see if this is right? And we sent that out, and with maybe half an hour an hour, we received our good trustee beacon. Yeah. We love to see those come in. So that was a great example of how, just because something happens, a ripple in the whole environment is kind of created, they can't always be a wave. And if you know how to handle a DS plate, you can take that ripple and make it invisible. If you leave it there too long or you don't handle it properly, you can definitely make that ripple into a giant wave. And now incident responders are investigating and your whole office burnt. So small things can really take time just to de-escalate it. And it's something technical. It's just using soft skills and communicativeness. So how do you really break? How do you stop against this? One of the biggest things we've seen, and you can kind of take from this story, is that training. It actually turned out after, when we did a debrief with the client, that the client actually had a separate portal for incidences. The help desk handled the day-to-day issues, I can't log in, my passwords, those types of issues. But there was a whole separate portal for like, hey, I think I've been spearfished, something's weird, I'm seeing something. And because they put that stick in the help desk, there was different responses and everything like that. Help desk, they weren't trained or aware that maybe this is something weird. This user provided a lot of data and I was deleted and saying my bad. If you read that thing, it kind of looked like this person but their SLIs and everything like that, they were just trained to not spot weird or anomalous behavior and that's the key word. We always talk about indicators of compromise, but there's indicators of anomalous. And if you can stay and live in those indicators of anomalous, you're going to have a higher chance of success as kind of described. So really teaching your users how to properly handle those incidents and don't just call the help desk. Help desk is not just security, so to speak. And then kind of really focusing on when you get those types of events, like prioritizing a real-time communication. Don't wait for an automated message, don't do anything. And that's both on the user's front and on your IT and security team. In this example, you saw all of them were message-based. Really like putting a ticket is great. You have all the evidence there, but following up with a phone call saying, hey, I'm really worried something happened. You have someone on the phone now, so if they're in the office, you can find them. Talking and being in person, it changes the level of severity and forces people to react faster. I take it most of the time, may not come into the same urgency. And that really can change the amount of time we have as an attacker to be successful. And just by de-escalating, we had enough time to figure out a good convincing internal spearfish, which we love to do because you're bypassing all those mail filter controls. We looked at them and saw, all the users are passing this Excel document around. We can put a macro payload in it. And that just adds to the legitimacy of the attack and the story. All right. Those successes were great, but let's cover some failures. So all red teamers should probably know this, but putting all your eggs in one beacon, sorry, basket is bad. Sometimes even the best tools are buggy. So we use cobalt strike. It's a great tool. It's very powerful. But obviously it's not perfect. This was at a time when basically this was right before the cobalt strike 4.0 release. And there was a bug in execute assembly at one point where if you executed anything in execute assembly, it would crash the beacon. So, you know, the little screen chat is kind of funny, but I'm just sitting there and I run, you know, I had worked really hard and I had done all my red team things and I finally got this beacon. And I was like, all right, I've been working really hard. I should use this. I should take this opportunity, seize the moment and really go and do all my, you know, do my reconnaissance, do my situational awareness and try to move laterally, etc. So the downside of that is I didn't really think about, you know, the presence of that bug so the, how much I was relying on that single beacon. So, luckily I did set up persistence before I executed that, so it came back the next day when that user logged in. But it was a long 24-hour period of basically waiting and saying, I shouldn't have done that. I shouldn't have executed that. You know, it was kind of a kick yourself moment when you just potentially burned a couple weeks of work just because you got excited when that beacon came in. So I guess the takeaway here is if you are, you know, once you get that, once you finally land that shell or that foothold, don't necessarily go and use it immediately. Maybe take some time, just exist in the environment, gather some information listen passively, etc. And then maybe establish a backup C2 or another foothold before you start executing higher impact actions, right. So start out as low and slow as you possibly can and then ramp it up as time goes on instead of having your automation and everything ready to go for that initial beacon to go. Maybe let it let it persist and just sort of blend in for a little bit before you go all the way. So now we're going to cover lateral movement. So we didn't put a lateral movement overview slide because, you know, it would have been like 20 slides of what lateral movement is, right. It's something different to someone, to everyone else. But basically lateral movement is establishing more pieces of the attack chain within the internal environment, right. So or compromising users or etc. Basically this scenario is, we like to call it acts like you belong, right. So blue teams know publicly available tools, right. They can go out they know about GitHub guys like it's a public site anyone can go on there and download whatever tools you know they can download impact it they can download any anything that's on there they can they know about it and they can use it right tools can stand out from the baseline right so you know user agents for example if you are using PowerShell and the environment doesn't use any PowerShell it's a classic example right if they don't use PowerShell and you do then now you're standing out from the baseline and typically you know this has been there's wall bins and etc but living off the land or blending in is probably the best way to go if you're red teaming right. It's hard to catch someone who's using the same tools as every other user in the environment. So this is a scenario where basically we had a limited foothold so we had that C2 access. We had credentials so we had plain text credentials for this user basically we enumerated our access. This is that user output. Of course we didn't actually run that user. That would be way too loud. We generated this from LDAP but we looked at our group memberships and we saw one of those group memberships is Citrix right so instead of you know oh let's move later let's run impact it or let's run CME or Bloodhound or whatever. Let's just log into Citrix and see what's in there right. Not only is there potential footholds there if they have access to desktops but also you never know what you might find so on the right here is a screenshot of that Citrix portal. So we logged in and essentially this everything censored because client stuff but basically this was a SCADA environment that we basically had direct access to monitor a lot of their high sensitivity SCADA applications and devices within the environment without we didn't use any real tools to do this all we did was proxy our traffic through our beacon and then just log in so that's they didn't detect it because that's very difficult to detect a normal user logging into their normal thing that they normally do right so now Matt's going to cover a lateral movement fail. Yes so this was an engagement where we were dwelling in the client's network for three weeks they had no visibility into what we were doing and as you can kind of see from our maps we had a lot of access we had basically been able to move through basically compromise in fact we at one point we became the security team which was a key part of this story so as we're moving laterally through the environment there were lots of TOIs started of interest the client had set up for us to compromise kind of hey once you're in it's not just hey get domain admin that's like the easy cool thing but show that impact that value that'd be like you know decrypt credit cards access our secret sauce that's stored on this network you know access data all the stuff that can really show like oh my god we have been hacked in our data our business critical stuff has been compromised like that integrity so how we actually managed to establish our initial foothold was on a box where there was a domain admin so yay we had access we hadn't really used this account yet because for most of our as we're moving we were able to simulate using different users jumping to various jump boxes are getting to different systems kind of blending in and one of the goals was to get access to shipping manifest and all this type of very powerful information related to skews and all that stuff so fortunately we couldn't get on to any of the users machines because they were in a different environment they were in like a sub domain but the domain admin account actually had privileges and it was actually still an administrative privilege level set high integrity on those boxes so we were able to authenticate as this has this domain administrator on one of the work of the warehouses computers well that was where it was kind of getting weird because the account was designed as a back up account for TV's and stuff and eventually like I said we were in the security IT guys chat room there's actually the malware war room council what they called it we were seeing like why is this account login here and then they were starting to see tidbits so as they were going back through and knocking down our beacons we were kind of going around in a different direction but we eventually lost all but one or two hosts we still had access to the environment but we had to start all the way back from square one and why this is like the talk about especially when we're kind of going through any type of our debriefs internally and stuff is DA is cool and stuff but often times companies and stuff they're going to look for that are their DA accounts login to random places I know most of the time that's where everyone goes first they have a lot of controls around but you can do a lot with like other types of accounts like I kind of said IT security guys admins they have a lot of the same access that domain administrator and often times when we look at this like these types of goals and end results maybe compromise an application get access to the database behind it where like all the credit card or juicy information is domain admin doesn't really play into the fact domain admin just gives you administrative rights on the box it doesn't give you admin rights into an application so that's something where you always want to keep the mind so we always kind of look at it like who are you logging with is there value to it like you know it might be an easy skeleton key but are you going to create more waves than it's worth and this is a great example of that we pretty much we are in over 50 boxes moving through different environments and we have to go all the way back to square one so breaking this chain it really comes down to baselining and understanding your environment there's a great term called lease frequency if you're not familiar with it the concept is that if you're baselining to the point where you know your environment you know like what user agents everyone uses you know your google chrome or a firefox shop all those types of things that's your baseline everything's going to be the same until you see some differences like internet explorer user agent stuff and those are the least frequent objects or events that now you can drill into well why did that happen if everything else is standard operating procedure you've seen this for day in day out for like three or four years and then you see this one event for the first time you kind of can shuffle all that stuff off to the side and focusing on those few unique new events may not be malicious right away but you can start digging that's how you can make this large cloud of noise something smaller and easier for your team to handle and manage but when it comes to lateral movement the great tips we often recommend are you know auditing your ACLs making sure that you know users don't have unnecessary privileges that's often the easiest pitfall for lateral movement to go back to what Corey said about you know the Citrix and stuff one of the issues was there were so many unnecessary privileges that gave us hops, skips and jumps in the environment that just made us so much more successful there are other great tools I'm really surprised this one is not talked about a lot or used it's called net cease so there's a link right down there that we provided essentially what it does is it prevents the remote call it's a net session in noon which if anyone's familiar with that's how most great tools that are out there on github or in the hacker space get all that you know who's currently logged in it doesn't disable or hamper it what it does is it changes who can call it remotely if you're on the box you can call it it doesn't matter your privileges but if you're remote to a box it can only be certain ones rather than what's default which is anyone that's in the domain user group to be power users administrators or another group and with that patch and that little registry change it can be what you can be pushed out through group policy it really does hamper your ability to see oh I need to be user X and I'm user Y and I need to figure out now where user X is you can't just start hitting every box and looking at any using any tools to find that user it really changes the game also making sure you know privilege accounts are protected you know there are protected user groups or potential delineations and all the delegations make sure that you know you're not if someone logs in a service account or something like that they're not just still sitting in memory or they're not just easily available really kind of protecting the actual sensitive of credentials or hash credentials so now we're going to kind of talk about persistence it's one of those it's more of an art form I like to say there's great techniques or something like that but whenever you hear about a new file on Twitter or there's an article most of the time people pay attention because they really get scared and that's like the focus of patching so when you find vulnerability to allow so I always like to take the art form and it really comes down to like you know you could go with that crazy route but they might have it patched but if say you're payload or whatever you know binary DLL whatever you want to have it can persist on disk where it stays on disk it could be somewhere in like you know the user app data temp or something like that and your whatever security appliance is just not alerting on it if you have say you know a bat file or something where it drops into a start follow of a user and calls it it's probably not going to get detected if it looks right telling that story again so in one of the scenarios we did we were persisting on multiple different machines and what we ended up doing was just dropping a bat file that would call gpuptate.exe or binary or evil binary was gpuptate.exe because it was obviously put in app data so when you looked at it strictly from the point oh the process you know the binary gpuptate started up when the user kind of logged in and it wasn't as suspicious I mean if you drilled in you would have seen well why is gpuptate not in C system Windows 32 why is it in app data and one of the great things about that is is that if they're looking at like things like well what this file is there's something else is already kind of dragged their attention towards it so you're already kind of burnt but just staying pretty low making tiny ripples you hang around that you know indicators of anomalies if someone looked at it they probably wouldn't blink twice until they looked at the file path or other attributes of the file and now it comes down to I think this is one of our favorite ones to talk about is conference rooms so and we were on engagement that was getting close to the end and it was very late when we had managed to finally get through and we really wanted to establish persistence because we didn't want we couldn't afford to lose we were really coming close to the tight line of the end so it's very late at night okay perfect so we decided okay we know what their conference room systems are so we put a beacon with persistence on it thinking you know no one's going to look at them it's pretty late on a Friday no one's going to do anything about this until Monday if anything and let's be honest no one's going to come in over the weekend and use the conference rooms machine but that was a pretty solid idea what actually happened was their sock was like why is there traffic coming from the conference rooms at 2am like what is someone using these and that in itself was actually louder than anything we had done previously to get in because it didn't make sense why these conference rooms every so often would call out to the internet and stuff like that and that really was kind of like the problem was we thought we were being really stealthy and quiet and for all purposes like you know there was no artifacts left there was no like alerts from the EDR consoles or dashboards it was just someone saying well this traffic it looks weird traffic baseline is that you know 8am to 5pm is a lot and then afterwards it's a little and then all of a sudden there's a big spike so it's like okay what's going on here and then they dug deeper and deeper and it's really hard to come back from that because they've done everything like that's so low of an indicator that there's nothing you can really mask besides maybe figure out a better story so as I was saying before this whole persistence it's really an art form there's no like silver bullet that if you do this there's no way anyone can persist on your environment you know patching and keeping up the date is always a great thing but kind of like the stories we just kind of described like it doesn't matter it really comes down to how are you monitoring do you have a good baseline do you understand like what processes typically should start up for every different department you know does HR just use Google Chrome and Outlook all the services related to that so okay there's your baseline for that department and looking around like file locations you know the ones that hackers love to use you know all of those looking for things that are spawning from there or starting up there that will give you a huge indication like nine times out of ten there should never be a DLL and temp or app data that's starting up right when a user logs in and of course the one that got us burned is the unusual net communications looking at those things you can drill down that precise you have a very mature environment and a very mature way of handling instances that's going to make any like challenge red teamers job a lot harder also application whitelisting is your friend it's not ours when we're on a box whatever way you know might be in Excel we're document that bypass that but like trying to get persistence it's next one possible if you have a strong whitelist application going you know dropping binaries you just describe it makes it a whole lot harder and then making sure whatever we're trying to slingshot through that's not you know being caught in any of those chains to get to the nasty that we call our backup payload making sure none of that all of those things are not blocked through application whitelisting can just be a nightmare and by the time we get it all figured out you know we persisted too long not moving it's definitely a key thing to definitely keep up monitoring baseline and getting a good understanding for environment we're now coming to the end yeah so conclusions or you know confessions of an attacker so here's some of our sort of lifting the curtain a little bit attackers use what they know works right so we use cobalt strike because we know cobalt strike works we you know custom stuff is great we experiment with it quite a bit but if it comes down to we have one shot we have one you know dll or one exe that we're going to do um which c2 do you want to use right it's we're going to we're going to if it comes down to a choice like that we're going to make the choice of the most reliable tool right so oftentimes that can be easier for blue teams to identify because the tool set is shrinking as you're you know relying on more well developed or well known tools um also one into an attack chain can be easier for us to manage right so as you know as cool as it is to have four or five different footholds that are totally unrelated different c2 different initial compromise different physical locations that's great but the reality is we're you know we're rent teamers so we're doing this in a condensed time frame with with restrictions on how long we have so oftentimes we end up with just one end to end attack chain and along the way all those chain breaks that we described are ways to just basically send us back to square one where we have to start over and say we did this this and this however they had this security control or they caught us or whatever and now we have to start over so it's actually you know it's the chains are more fragile than they might appear um users who report incidents are honestly one of the things that comes up more than we'd like it to because there's really nothing we can do to stop it right we can't stop users from emailing their security team and saying hey this looks weird um we you know obviously we showed an example of how we can do anti you know evasive maneuvers and say oh actually never mind my mistake but if someone's going to pick up the phone and call a user or if the user picks up the phone and calls out security people we're not a part of that conversation we can't really work around that so that's where that security we're in this training and just relying and trusting on your users is actually really hard to get around um and then obviously defense in depth it really does win in the long run right so this works for real attackers right because you know if you're trying not to get hacked or running away from a bear so as long as you're not the slowest you probably won't get eaten but um defense in depth makes it harder every step along the way gets harder when you have you know oh well they you know we got a foothold but now they have all these really strong local firewalls so we can't actually you know we can't move laterally as easily because everything's blocked everything else right that's an example of defense in depth it's not that's not protecting you from spear phishing but that is helping if you do get to that breach status it's going to be restricted in the scope of it um and then Matt has some final conclusions on tools or control or defensive controls yes that defensive controls and we kind of talked a lot about this um kind of at some point hit small little uh you know an inch into this type of topic but uh you know tools are great you know as we kind of described before the we highly recommend you know monitoring tools proper configurations but they're kind of useless if you just buy them put them in audit mode um and and that's what we kind of see a lot is is this deployment that they're not you know you might have the greatest security stack of 20 different products if you might have 14 different AV ADR agents on there but if they're not properly tuned or there's tons of gaps and that's where hackers and attackers love to live is just in those gaps it's pretty much where it is is hey look there's a gap or a blind spot in our in this uh client's network that's where we are going to start we're going to live in this gap and we're going to try to move as much as we can't in there because you guys don't have any visibility and we know that so if we know that you know hey you guys are monitoring PowerShell but you know we can use C sharp or hey we can you know you guys have great lockdown for a lot of stuff but macros are really easy we could use macros we can use water hole attacks you know setup effects hey guys you know your EDR is only set up to detect you know process injections or something like that is anything like that I can go on there's tons of little things like that and that's where really tuning tightening up it can really make a huge difference in the success of your defensive controls uh also that kind of comment I made before about audit we often see the latest and greatest you know this is going to stop every you know cyber threat known to mankind we've detected old days before they even thought of tools but you ran it in audit mode so someone's not looking at the dashboard you don't see a blinking light appear um and so we continue on our way through the environment um it's really it's really hard to do a lot of that stuff and that's where like hiring you know red team Sims and we're doing those types of engagements so that way you can see what's out there you understand what you know people are doing and seeing where those gaps are in your product that's highly valuable than just hey I'm going to buy a product and just you know plug a few buttons on it and hope that I got everything right really having it go through that trying those trials and stuff in a live fire engagement is going to help you guys more than anything um also we know this and this is probably going to be one of the most frequent questions asked you know well if we do all this stuff then you know it's not usable for my environment you know users can't log in as easy or they can't do things that they used to do as quickly and stuff and now they're going to complain that they're infecting or affecting their ability to do their job and you know it's going to hurt the company's bottom line but you know it's that type that's that hard conversation you have to have with the business about you know you have to change the way you guys have been using stuff to make it more secure it's very hard I mean I don't envy anyone who has to deal with those conversations on a daily basis but it's necessary to have and I think if you approach it properly and with a lot of you know information and guidance and recommendations even from third parties you can definitely get a lot of value out of that and the last thing of course we mentioned throughout this whole thing is baselining baselining baselining know your environment inside and out if you do that's the biggest thing as from our red teaming experience that has killed us or stopped us dead in the water is if you can baseline and discern us from the rest of your normal traffic even if we're logging in through RDP and we're using all the same stuff you're your own user if you can find out that we're not who we're pretending to be you're going to have a lot better success right then if you do anything that I just described baselining is probably the biggest key and that's what we left it as the largest bullet point really just least frequency get get in tune with your environment get really in tune get very close to it unnecessarily close to it and with that knowledge you'll definitely be able to spot the anomalous behavior all right so we have a few minutes left if you guys have questions put them in the discord channel it's the uh if you guys are in discord it's the briefings main talks channel we're both in there and we're we can answer or try to answer some questions in real time before we wrap up you can hit us up on key base or twitter if you have any questions or just want to chat we're always available we love picking you know other teams or other people's brains in the industry definitely you know hit us up if you ever have a question um other than that I just want to say thank you to the red team village for letting us speak today and thank you guys for showing up for our talk