WEBVTT 00:01.100 --> 00:02.400 Welcome back. 00:02.520 --> 00:09.440 And thank you, Corey and Matt, for supporting us, supporting the Red Team Village, supporting DEF CON and the community. 00:09.620 --> 00:11.180 And without any further ado, take it away. 00:11.180 --> 00:12.000 You're live. 00:12.220 --> 00:13.060 Thank you. 00:13.060 --> 00:13.940 Thanks, Omar. 00:14.020 --> 00:22.260 So this talk is called Breaking the Attack Chain, Unexpected Wins and Fails from Two Stimulated Adversaries. 00:24.320 --> 00:25.800 So here's the agenda. 00:25.800 --> 00:35.360 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. 00:35.480 --> 00:40.580 And then we'll finish off with some of our just notes, and also we'll open up the floor for questions. 00:41.540 --> 00:42.880 So who we are. 00:42.880 --> 00:44.640 Matt, you want to say who you are? 00:44.640 --> 00:45.240 Sure. 00:45.240 --> 00:47.420 So I'm Matthew Edelberg. 00:47.420 --> 00:50.320 I'm a Principal Security Consultant at Optiv. 00:50.480 --> 00:54.480 I also help lead the Adversary Simulation Team. 00:54.480 --> 01:04.380 That's pretty much our fancy way of calling what we do for our red, purple, and physical-based, real-world scenario-based-driven operations. 01:04.420 --> 01:16.320 Also authored and developed several open-source tools and frameworks, mainly focusing around EDR, evasion, and bypassing security controls and remaining low underneath the radar. 01:16.320 --> 01:18.260 That's really where my passion is. 01:18.360 --> 01:22.660 I did do, for a while in the beginning of my career, focus a lot on wireless. 01:22.660 --> 01:27.160 So kind of that whole spectrum, sort of one area, a different area. 01:27.160 --> 01:33.680 Also, I've spoken at numerous different conventions, you know, DerbyCon, B-Sides Las Vegas, HackFest URCON. 01:33.680 --> 01:41.280 Really just passionate about red teaming operations and the nuances and always improving that concept of sharpening that spear, staying low to the ground. 01:41.620 --> 01:45.200 I'm going to turn it over now to Corey to kind of give a brief introduction as well. 01:45.200 --> 01:54.760 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. 01:54.760 --> 02:06.900 I've participated in some open source tool development, and then my passions really center around data aggregation and building lab environments for the red teams, basically. 02:08.340 --> 02:12.380 So before we begin, I wanted to basically caveat this. 02:12.920 --> 02:17.020 Red teaming is a different thing to different people. 02:17.020 --> 02:23.420 This presentation is based on our experience during our engagements, real-world scenarios. 02:23.420 --> 02:25.440 These are not made-up scenarios. 02:25.440 --> 02:28.560 A lot of them include real screenshots from real engagements. 02:29.860 --> 02:31.640 Everyone does this differently, right? 02:31.640 --> 02:35.560 So some people's definition of a red team is just an app testing team. 02:35.560 --> 02:42.200 Some people's definition of a red team is a full-blown, zero-knowledge assessment every year or every two years or whatever. 02:43.820 --> 02:47.040 So everything in this presentation is also situational. 02:47.040 --> 02:49.380 So we're not going to cover the client's demands. 02:49.380 --> 02:54.740 We're not going to cover that it was raining that day or whatever reason we have for each scenario. 02:54.740 --> 03:00.480 So there might be a little bit of background information that we're going to gloss over, but it should be fun. 03:00.760 --> 03:15.420 This talk is going to kind of be a briefing style, so it's kind of almost like if we're talking to you, it could be if we're a red team or if you're a blue team, it's sort of covering our debrief of a lot of these scenarios that we've encountered on different assessments. 03:17.920 --> 03:23.000 So kicking off the first topic here, we'll be met with some OSINT stuff. 03:23.240 --> 03:23.860 Yep. 03:23.880 --> 03:25.800 So we all know what OSINT is. 03:25.800 --> 03:31.480 It's one of the most, I always believe it's one of the most vital things when you're starting off an engagement. 03:31.820 --> 03:34.520 You know, we're basically just professional Googlers. 03:35.280 --> 03:48.660 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. 03:49.820 --> 03:58.720 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. 03:58.720 --> 04:10.560 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. 04:10.620 --> 04:14.980 And you can be doing that for thousands of pictures and it may yield nothing. 04:15.020 --> 04:23.280 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. 04:23.700 --> 04:28.280 And you can kind of see with this great example, a bit of background. 04:28.540 --> 04:34.320 We like to call this, you know, hashtag Mondays might delete later. 04:34.320 --> 04:35.640 I see no problem. 04:35.780 --> 04:43.400 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. 04:44.000 --> 04:56.460 And we did that typical, started building the profile, looking at who the employees were, trying to get an understanding of what information was out there until we stumbled across the company's Instagram account. 04:56.460 --> 05:04.740 And this picture was originally taken by another employee that the company's Instagram account kind of liked and retweeted. 05:04.740 --> 05:18.120 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, bank transactions, a lot of other very sensitive stuff. 05:18.920 --> 05:21.920 But there was a lot of these types of pictures just sitting on Instagram. 05:21.920 --> 05:31.700 So one of the 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 jewel vital data. 05:31.700 --> 05:33.180 They provide it to us. 05:33.260 --> 05:36.680 And I would say that this is not just that one unique time. 05:36.680 --> 05:38.960 This is something that's constantly out there. 05:39.100 --> 05:50.380 As 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. 05:50.380 --> 06:02.420 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 that those two different things, the awareness there is there are huge gaps. 06:06.540 --> 06:11.560 And that leads us to our next sort of major one that we love to look at are paste sites. 06:12.160 --> 06:15.520 You know, there's many different ones, Pastebin, anything like that. 06:16.340 --> 06:18.760 I mean, scraping these are just... 06:18.760 --> 06:20.820 you can yield a plethora of data. 06:20.820 --> 06:22.020 I mean, it's not a lot of money. 06:22.020 --> 06:29.920 I mean, correct me if I'm wrong, but I believe now for a pro license for Pastebin, you can, for $50, you can scrape to your heart's content. 06:29.920 --> 06:36.040 You put that in, say, like a Caldana instance, like Elk, and it just endless scrapes. 06:36.040 --> 06:40.980 You can kind of just make a search thing like search client name and look at every single thing that references this. 06:41.220 --> 06:50.200 And that's honestly something so simple, so unique and so fast that you can yield things like usernames, credentials, APIs, hell, even credit cards and other sensitive PII. 06:50.200 --> 07:04.060 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, all that information. 07:04.060 --> 07:15.500 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. 07:15.620 --> 07:20.340 Because all their controls were like, what's your bank account number? 07:20.480 --> 07:22.360 What's your security answer for this? 07:22.360 --> 07:23.860 What's your secondary one? 07:24.000 --> 07:25.340 And do you still live at this address? 07:25.340 --> 07:26.600 What's the last four digits of your phone number? 07:26.600 --> 07:31.820 All those typical security controls to prevent fraudulence are all out there. 07:31.820 --> 07:35.160 Great plate hackers constantly are dumping data there. 07:35.600 --> 07:40.020 And in the top example, we actually can still find valid credentials. 07:40.100 --> 07:48.940 We found two-year-old valid credentials to a third-party portal, which led us to have access to a setup site. 07:48.940 --> 07:54.620 And from there, we were able to get enough information that allowed us to establish a foothold into their internal network. 07:54.620 --> 07:59.160 So something like that can sit there for years before it's even discovered by the client. 07:59.160 --> 08:00.860 And that drives the impact so much more. 08:06.490 --> 08:07.790 So what can you do? 08:07.790 --> 08:11.110 And this will be the style of that debrief, is how do you break this chain? 08:11.150 --> 08:13.810 In the sense of all these wins, how do you break this? 08:13.810 --> 08:15.470 How do you prevent this from happening? 08:15.490 --> 08:23.930 And it's really hard, especially when data is out of your control, when you get stuff on those PACE sites, it's next to impossible to take it down. 08:24.370 --> 08:30.690 So there's no surefire of, oh, this is up there, we'll bring this down, we'll cease and desist, and that will be the end of it. 08:31.190 --> 08:35.490 Especially like what I was just describing with PACE sites and being able to scrape and have that local database. 08:35.490 --> 08:39.010 Once it's there, it's hard to get rid of off every individual who's scraping. 08:39.250 --> 08:42.410 So it really comes down to understanding what's out there. 08:43.010 --> 08:48.450 Find those information sources through profiling or intelligence gathering. 08:48.650 --> 08:52.350 We like to call it public information profiling or data intel. 08:52.450 --> 08:57.850 It's performing that on yourself, your company, regularly to understand, oh, there's new data coming out there. 08:57.850 --> 08:59.090 Now I have to adjust. 08:59.090 --> 09:06.930 So it might be, hey, we discovered a couple of clients, there's sensitive data out there, we need to contact them now and get all that stuff scrubbed. 09:06.930 --> 09:08.850 So that way it's not valid anymore. 09:08.850 --> 09:20.050 And 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 training them through impact. 09:20.150 --> 09:24.890 Here's a picture of something, and do you think this is sensitive? 09:24.890 --> 09:28.550 Well, here's what an attacker looks at it as, and this is why it's so impactful. 09:28.550 --> 09:33.910 And just kind of visually explain to them why this is so detrimental to post. 09:34.130 --> 09:39.110 And that can oftentimes help reduce that gap from like this big to like this big. 09:39.110 --> 09:43.310 You're always going to still have a little space, and that's where intelligence sources come into play. 09:45.070 --> 09:48.490 So those were some pretty cool wins you had there, Matt. 09:48.490 --> 09:51.930 But I figured we could cover some failures, right? 09:51.930 --> 09:56.430 So obviously, a lot of successes do happen, but also failures happen. 09:56.430 --> 10:01.270 And I think maybe blue teams and red teams can learn from some of our red team failures. 10:01.270 --> 10:03.710 So this is what I like to call the red herring domain. 10:03.710 --> 10:11.730 So basically, the TLDR is that email alias domains do not make great password guessing or enumeration targets. 10:11.730 --> 10:16.310 So we all remember when Office 365 enum worked perfectly. 10:16.310 --> 10:20.050 Those were the halcyon days of, man, that was a good time. 10:20.050 --> 10:25.930 But basically, the client had clientdomain.com was their email address. 10:25.930 --> 10:27.090 That's what they used publicly. 10:27.090 --> 10:28.970 It was on all over their website and everything. 10:28.970 --> 10:32.670 So we figured this has got to be... this is easy. 10:33.190 --> 10:34.910 That's what their domain is. 10:35.050 --> 10:39.450 We started password guessing, and we're getting all kinds of weird results. 10:39.470 --> 10:43.130 Valid user, invalid user, bunch of 401s and weird... 10:43.130 --> 10:44.870 like some users have two vectors, some don't. 10:44.870 --> 10:48.490 It was very incongruous with what we're used to seeing. 10:49.550 --> 10:51.450 And basically, we were like, hold on. 10:51.450 --> 10:53.250 Is this really their email domain? 10:53.830 --> 10:58.030 So we actually used reverse DNS, or reverse Whois. 10:58.370 --> 11:04.830 Vue DNS has a very cool reverse Whois tool where you can basically type in the contact information of a registrant. 11:04.830 --> 11:08.210 So, you know, info at clientdomain.com or whatever. 11:08.210 --> 11:12.090 And then you can view all the other domains that are registered to that email address. 11:13.210 --> 11:18.530 Obviously, it can get a little hairy if you have, you know, anonymization with the Whois records. 11:18.530 --> 11:20.330 But basically, we used that. 11:20.330 --> 11:24.050 We pulled up a list of all the valid domains that were registered to that client. 11:24.050 --> 11:29.050 And we looked and actually for each one, we went through and checked them against Office 365. 11:29.350 --> 11:33.690 And then eventually, we found the real one, which happened to be myclientdomain.com. 11:33.690 --> 11:43.610 So it was just sort of a weird scenario where we basically burned a few days on an assumption that this was obviously the domain, when in reality, the domain was something else. 11:43.730 --> 11:48.130 So I guess the takeaway is to trust your gut. 11:48.190 --> 11:49.930 Check and then double check, right? 11:49.930 --> 12:00.310 If you're getting incongruous 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. 12:00.310 --> 12:03.190 Figure out what could lead to these different results. 12:03.350 --> 12:17.290 You know, the getUserRealm functionality of Office 365, you can use to sort of manually inspect each individual element and see, okay, is this a valid domain in Office 365, etc. 12:17.290 --> 12:22.510 Those sorts of manual checks can keep you from doing these fails. 12:22.670 --> 12:26.910 So Matt's going to cover another funny one about building. 12:26.950 --> 12:32.290 Yes, we thought it'd be fun if we both share our experiences in the fail realm. 12:32.450 --> 12:35.490 So this is the one I like to call wrong building. 12:35.890 --> 12:39.970 So like I kind of said, that rabbit hole, it can lead to so many great results. 12:39.970 --> 12:42.050 It also can bite you. 12:42.070 --> 12:45.950 So in this kind of bit of background here was the situation. 12:45.950 --> 12:51.090 We were hired to do a physical breach assessment to break in physically into a building. 12:51.570 --> 12:59.590 The building in question was this large commercial high-rise and we're listed as safe arguments in the story, the seventh floor. 12:59.910 --> 13:15.610 So we did a lot of OSINT and we were 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 is the actual person on site, what were the vendors, even forms to fill out. 13:15.610 --> 13:27.850 Say, for instance, if you were one of the tenants there and say, you know, telecom went out or pipe burst, paperwork and all that stuff, you know, who to contact, here's like the, you know, all this other information to know which building and everything like that. 13:27.850 --> 13:28.450 It was great. 13:28.450 --> 13:32.170 We were so happy because right there we could create a perfect scenario. 13:33.050 --> 13:33.910 And we did. 13:33.910 --> 13:41.850 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. 13:42.830 --> 13:44.710 We got even so detailed. 13:44.710 --> 13:47.550 We were able to kind of create a fake work order. 13:47.610 --> 13:55.370 We were able to find out uniforms for that vendor and we addressed, you know, perfectly right down to the level details. 13:55.370 --> 14:00.350 We had called beforehand, knowing when the office manager for the client was out. 14:00.350 --> 14:01.650 So we left the voicemail. 14:01.650 --> 14:04.610 We left lots of different things just pretending to be the property manager. 14:04.610 --> 14:07.550 Say, Hey, we have some guys coming into the building. 14:07.550 --> 14:08.970 They're doing some work with telecom. 14:09.650 --> 14:13.410 I've been getting a lot of calls throughout the day, just people verifying them. 14:13.410 --> 14:17.050 I just wanted to let you know that they should be at your floor in the next 20, 30 minutes. 14:17.050 --> 14:18.510 I'm just stepping up for lunch. 14:18.510 --> 14:27.250 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. 14:27.250 --> 14:35.210 So we really had provided enough information so that way they could go listen to the voicemail and say, okay, there has to be a work where we have to check all those things. 14:35.210 --> 14:37.190 So we were kind of creating that self-validation. 14:37.630 --> 14:40.930 So we get up there, talk to the receptionist. 14:40.930 --> 14:43.970 The receptionist goes, okay, I got to go get the office manager. 14:44.090 --> 14:46.050 Point this at the, you know, like the sitting area. 14:46.050 --> 14:48.850 We're sitting there, just sitting there. 14:49.230 --> 15:00.230 And then maybe we kind of realized it's been a while, but maybe another five, 10 minutes later, the office manager came out with someone else who was the property manager. 15:00.230 --> 15:04.570 And they were like, so who are you guys? 15:05.970 --> 15:07.790 You're not anyone I've ever worked with. 15:07.790 --> 15:09.410 You don't even work at the company I've never worked with. 15:09.410 --> 15:13.130 I'm like, oh, well, you know, so-and-so that's the property manager contact us. 15:13.130 --> 15:14.570 He probably, he left a call. 15:14.570 --> 15:17.010 He was like, yeah, but here's the thing. 15:17.090 --> 15:20.170 He works on the bottom floor in the retail section. 15:20.170 --> 15:23.790 I handle all the commercial high rise and corporate stuff. 15:23.970 --> 15:27.190 So I'm going to ask you again, who are you? 15:28.410 --> 15:29.830 What do you do in that situation? 15:29.830 --> 15:31.270 You kind of have egg on your face. 15:31.270 --> 15:33.870 You know, we had done such great OSIN and everything like that. 15:33.870 --> 15:40.970 But the problem was, we didn't realize that the building was split property managers for retail and the corporate renting. 15:41.650 --> 15:46.870 And in that moment, like your perfect pretext and everything like that, just goes out the window. 15:46.990 --> 15:48.410 So me and my colleague were sitting there. 15:48.410 --> 15:52.890 We literally had this conversation, just staring at each other, not to like sweat and everything like that. 15:53.110 --> 15:55.430 You can't just instantly pull up like to get a jail-free card. 15:55.430 --> 15:57.550 Like, ah, this was a scenario and stuff. 15:57.550 --> 15:59.790 You try to always want to deescalate. 15:59.830 --> 16:00.870 So you do your best. 16:00.870 --> 16:03.390 Like, okay, that seems really weird. 16:03.390 --> 16:04.390 You know what, let's just stop. 16:04.390 --> 16:05.230 Let's take a moment. 16:05.510 --> 16:10.490 I called someone who was obviously a co-worker of mine and pretended like I got the voicemail. 16:10.490 --> 16:11.890 And it's like, hey, there's some issues. 16:11.890 --> 16:13.670 Can I explain the situation on the phone? 16:14.290 --> 16:16.090 We're not going to do any more work. 16:16.310 --> 16:21.670 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. 16:22.150 --> 16:24.750 So it's really taking those steps to deescalate it. 16:24.750 --> 16:26.630 And it ended up, you know, we're like, okay, well, you know what? 16:26.630 --> 16:27.870 Let's give a business card. 16:27.870 --> 16:28.690 Give us the business card. 16:28.690 --> 16:29.350 We're going to call. 16:29.350 --> 16:30.190 Let's maybe get on there. 16:30.190 --> 16:31.630 We can figure this all out. 16:31.630 --> 16:39.770 But I will tell you, that was the most awkward elevator ride down when they came with us in the elevator and were just sitting there like, this elevator is going so slow. 16:40.770 --> 16:42.890 The moment we got to the ground floor, we shook their hands. 16:42.890 --> 16:47.590 I'm pretty sure we had a little bit of sweat on our hands and we're just like bolting right out. 16:49.270 --> 16:54.310 So those are the things where, you know, sometimes OSINT can really, you know, bite you in the butt. 16:55.930 --> 16:56.590 All right. 16:56.590 --> 16:58.470 So taking a left turn here. 16:58.470 --> 17:01.610 So a different category than OSINT, initial access. 17:01.610 --> 17:08.150 So initial access, you know, we can define it as, you know, that initial point of compromise, right? 17:08.150 --> 17:14.530 So nowadays, starting from that perimeter environment, a lot of attack services are heavily limited. 17:14.530 --> 17:17.390 Companies have, you know, nothing but 80 and 443. 17:17.510 --> 17:24.710 It's pretty much SSO everything, redirect everything through their central auth, and everything's multi-factor, right? 17:24.710 --> 17:31.450 So the approach here as an attacker is to prioritize that breadth-first search for that weak point, right? 17:31.450 --> 17:40.130 So, you know, if it's Office 365 and they have basic auth enabled on AWS or something like that, that would be an example of a weak point. 17:40.130 --> 17:42.450 Or, you know, here's some other common techniques. 17:42.450 --> 17:46.490 Obviously, we're not going to cover any of these in depth, but password guessing is really common. 17:46.490 --> 17:53.330 Web app vulnerabilities, if you can get deserialized or some other, you know, similar, you know, roll your own web app issues. 17:53.730 --> 17:54.950 Spear phishing is common. 17:54.950 --> 17:56.310 Phone pretexting is common. 17:56.310 --> 18:00.570 And then lastly, physical access isn't easy, especially as a backup plan. 18:00.570 --> 18:02.190 It works pretty well. 18:02.190 --> 18:06.230 So multi-factor spear phishing. 18:06.270 --> 18:08.970 So phishing is dead, long live phishing, right? 18:09.490 --> 18:20.890 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. 18:21.570 --> 18:25.290 Attachments don't work from the perimeter anymore with an email filter. 18:25.290 --> 18:28.630 Email filters have their own URL filtering now. 18:28.630 --> 18:36.230 Any email that's sent to more than five people, for example, might just get blocked because they're assuming it's a spear phish. 18:36.290 --> 18:37.910 People are good at reporting them. 18:37.910 --> 18:46.710 I mean, I guess it's like over the years, we finally started to get better at training people and developing technical solutions so that it's actually not as successful. 18:46.710 --> 18:50.210 However, it does still work, even with two factors. 18:50.210 --> 18:56.950 So we like to actually focus not necessarily on passwords, but actually on tokens. 18:56.950 --> 19:05.250 So there are MFA-compatible phishing tools like Evilginix or Mudlishka that actually let you gather the tokens. 19:05.250 --> 19:17.330 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. 19:17.330 --> 19:26.590 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. 19:27.330 --> 19:29.290 And why do we like tokens? 19:29.430 --> 19:31.530 Because tokens are harder to track. 19:32.090 --> 19:37.310 Lots of people don't have anomaly alerting or anything like that on token usage, right? 19:37.310 --> 19:43.270 So if I log in from a new device, it says, whoa, this is a new device, you need to authenticate it. 19:43.270 --> 19:52.670 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. 19:52.670 --> 19:56.230 The other reason why we like tokens is because they're hard to reset. 19:56.230 --> 20:02.630 So a lot of the traditional IR procedures, they focus around Active Directory, right? 20:02.630 --> 20:06.270 So you reset your Active Directory password, you lock the Active Directory account. 20:06.270 --> 20:10.450 That doesn't necessarily have any triggers to a third-party SSO site. 20:10.450 --> 20:23.590 So if it's Okta 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. 20:23.590 --> 20:25.870 So here's a scenario. 20:26.770 --> 20:30.050 Basically, here's a screenshot of Evogenics output. 20:30.670 --> 20:43.790 The SID token, this is specific to Okta, but basically, after the user had authenticated to our Evogenics, and then they had pretty much realized, you know, okay, that's not great. 20:43.790 --> 21:04.610 But we were actually able to use that token to access their Okta 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. 21:07.410 --> 21:24.330 So, you know, before I cover breaking and detaching, last thing I want to mention, just if you're a red teamer, next time you get a token, or if you do phish a user with that, you know, Evogenics or another solution, do what you would do with a credential and actually do stuffing. 21:24.330 --> 21:34.970 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. 21:34.970 --> 21:45.210 I mean, with Okta, for example, you literally just put that SID token in your browser, go to the company's Okta site, and at least at the time that this gig was executed, it worked. 21:45.210 --> 21:56.950 There was some JavaScript sub-resource integrity stuff that we had to bypass, but it was, you know, API tokens or Vera tokens, it's definitely a good area to focus. 21:57.550 --> 21:59.650 So, breaking the attack chain, right? 21:59.650 --> 22:01.290 How do you fix this? 22:01.290 --> 22:04.310 Because it's really tricky to monitor. 22:04.330 --> 22:09.190 Like, Okta doesn't have default alerts for geolocation token usage, right? 22:09.190 --> 22:11.710 So, you should generate those alerts, right? 22:11.710 --> 22:18.550 So, figure out how within your SIEM or whatever to alert on token usage, not just password usage, right? 22:18.550 --> 22:29.510 Instead of suspicious login events, maybe look at suspicious token usage or just a session happened to move from this site to this site or whatever, or a different user agent or whatever. 22:30.530 --> 22:36.130 And also, build those connectors so that those tokens are automatically reset if the user does change their password. 22:36.130 --> 22:42.910 Or, if it's not automatic, build it into a playbook so that your incident response says, a user got phished. 22:42.910 --> 22:52.170 Not only do we reset their Active Directory password, but we also reset their Okta tokens or their Office 365 tokens or any kind of tokens. 22:52.170 --> 22:57.750 Typically, there are tools within these web portals to actually manually refresh a user's session. 22:57.810 --> 23:05.630 So, build that into your IR playbook so that you don't have that token that's been outvalid for 24 hours after the password was changed. 23:05.870 --> 23:08.730 And then lastly, here's a little shout-out. 23:09.150 --> 23:10.690 Generate IOCs for known tools. 23:10.690 --> 23:16.230 So, for example, Evogenics actually has a hard-coded IOC built into it. 23:17.670 --> 23:19.530 It's been published on Twitter before. 23:19.530 --> 23:31.310 I won't say exactly where it is in the GitHub, but if you're using Evogenics and you haven't forked it and edited it out and removed the IOC from it, it should be easy to be detected, right? 23:32.690 --> 23:45.910 Attackers sometimes use off-the-shelf tools like Evogenics, 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. 23:47.870 --> 23:52.310 So, after some successes, I'll cover a failure. 23:52.310 --> 23:55.890 So, this is what we call the traveling user problem, right? 23:55.890 --> 24:01.550 So, we have, on breach engagements, set off alerts with bad IP hygiene. 24:01.610 --> 24:05.290 We typically like to use non-attributable IP space, right? 24:05.290 --> 24:09.490 So, Amazon, Azure, VPNs, etc. 24:09.730 --> 24:11.850 But that's a double-edged sword, right? 24:11.850 --> 24:15.890 So, users don't usually use AWS, right? 24:15.890 --> 24:18.370 And also, geographically improbable access. 24:18.490 --> 24:31.810 So, like, 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. 24:32.830 --> 24:35.910 And also, you know, reusing that single cloud... 24:36.750 --> 24:37.730 you know, we're lazy, right? 24:37.810 --> 24:40.330 We're red teamers, we have so much going on. 24:40.590 --> 24:46.490 But sometimes we get lazy, we'll reuse the same IP address that we've obtained for multiple accounts, right? 24:46.490 --> 24:54.170 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? 24:54.370 --> 25:06.350 That's an easy indication that not only is it an AWS IP that's authenticating to our VPN, but also they just authenticated as two valid users and it's not, like, an office location, right? 25:07.930 --> 25:10.990 So, for red teamers, how not to fail? 25:10.990 --> 25:12.650 Know your IP space, right? 25:12.650 --> 25:15.470 Use some of those blue team tools in your red team engagement. 25:15.470 --> 25:17.250 So check your ASNs, right? 25:17.250 --> 25:28.170 So I put some links at the bottom of different services you could use to check the, like, IP reputation or, you know, sort of the footprint of the IP addresses that you're using. 25:28.330 --> 25:30.090 And tell the story as well, right? 25:30.090 --> 25:34.490 That's sort of our 2020 breach team slogan is tell the story. 25:34.490 --> 25:39.270 But basically, one IP is mapped to one valid account forever. 25:39.270 --> 25:51.790 So if we're going to trigger a valid login as a user, if we're going to actually start that pathway of emulating, that's when we'll say, let's go into it. 25:51.790 --> 26:00.450 Let's make this IP address this user's IP address and then keep using that for the rest of the engagement, basically. 26:00.970 --> 26:04.570 So that is very... it's harder. 26:04.570 --> 26:10.310 Obviously, they can still alert on, hey, this is an AWS IP logging in and that shouldn't be the case. 26:10.310 --> 26:17.370 But also, they can say, well, they did log in here and they logged in there and maybe they're just using a VPN or whatever. 26:17.830 --> 26:20.690 So it can be a powerful thing. 26:22.390 --> 26:23.330 Yep. 26:23.330 --> 26:26.510 Now we're going to flip over to foothold. 26:26.550 --> 26:30.670 And before we kind of go there, let's kind of do a little bit of an explanation. 26:30.670 --> 26:42.210 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. 26:42.210 --> 26:50.790 It may have given us a small step in, but we're not at the stage where we can, you know, start using our post exploitation frameworks, whatever that is. 26:50.910 --> 26:52.590 That's what we call the foothold. 26:52.590 --> 26:54.990 We've established the beachhead and we're moving. 26:54.990 --> 26:58.370 We begin that privilege escalation and moving laterally. 26:59.590 --> 27:02.670 So that's the major definition and difference. 27:02.670 --> 27:12.070 So in this example, which we're going to kind of talk about, this is actually a runoff of what Corey was just describing with the Okta and SIDS and Tokens. 27:12.070 --> 27:24.450 So we were inside their portals and we were able to get access to several different applications because we sent out a phish and one user clicked it. 27:25.050 --> 27:32.290 So we had tons of access, but only through their portals, like the tiles and whatever, you know, substant applications that were exposed to the internet. 27:32.290 --> 27:42.570 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 had been triggered. 27:42.570 --> 27:46.390 We're like, okay, that's kind of weird because it was an IT ticket. 27:47.130 --> 27:52.610 And what basically it outlined, as you can kind of see right here, was, hey, something's gone wrong. 27:52.610 --> 27:55.550 And it basically was, I clicked on this. 27:56.250 --> 27:57.710 I know it was something bad. 27:57.710 --> 28:10.610 I've already changed my password twice, which kind of goes back to what Corey said on how valuable resetting those Okta 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, 28:10.610 --> 28:11.910 but we were still in. 28:13.770 --> 28:16.730 They had already, they also attached our email. 28:16.730 --> 28:27.730 So our Spearfish email, as well as the, you know, security alert of sign-on that we had triggered by logging into an application that we weren't aware of had like that notification prompt built into it. 28:27.750 --> 28:34.730 We were just pillaging through the data, trying to get as much information we can to help kind of solidify our next stage of moving into that foothold. 28:35.370 --> 28:40.270 So I helped us ticket with our Spearfish and all this stuff. 28:40.270 --> 28:41.730 Pretty damaging, right? 28:41.730 --> 28:45.350 Hard to kind of back, you know, move around in something. 28:45.350 --> 28:52.510 So going back to my initial thing with the story about the building, you have to always deescalate. 28:52.830 --> 28:54.210 So what did we do? 28:54.210 --> 28:58.890 We removed the attachments and we replied back saying, sorry, my bad. 28:58.890 --> 29:08.130 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. 29:08.530 --> 29:20.590 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. 29:20.590 --> 29:22.710 So she would never see it. 29:22.710 --> 29:28.430 With all of this, we were able to then kind of do a comprehensive internal Spearfish. 29:28.430 --> 29:36.970 Starting on a couple of the employees that reported to this user with a typical great macro document. 29:36.970 --> 29:41.590 It was an Excel timesheet that they actually had been passing around, all the staff passed around. 29:41.830 --> 29:46.930 And we basically just added a few verbiage saying, hey, we're having trouble seeing it, you have to enable macros. 29:46.930 --> 29:49.650 Can someone take a look at this and see if this is right? 29:49.650 --> 29:56.970 And we sent that out, and with maybe half an hour, an hour, we received our good trusty beacon. 29:57.630 --> 29:59.690 We love to see those come in. 29:59.830 --> 30:09.770 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. 30:09.770 --> 30:14.170 And if you know how to handle and deescalate, you can take that ripple and make it invisible. 30:14.370 --> 30:20.090 If you don't, you leave it there too long, or you don't handle it properly, you can definitely make that ripple into a giant wave. 30:20.310 --> 30:24.690 And now instant responders are investigating, and your whole office burned. 30:24.690 --> 30:28.510 So small things can really take time just to deescalate it. 30:28.510 --> 30:32.070 And it's nothing technical, it's just using soft skills and communicativeness. 30:35.070 --> 30:38.450 So how do you stop against this? 30:38.930 --> 30:44.450 One of the biggest things we've seen, and you can kind of take from the story, is that training. 30:44.450 --> 30:51.770 It actually turned out after when we did a debrief with the client, that the client actually had a separate portal for incidences. 30:51.770 --> 30:56.910 So helpdesk handled the day-to-day issues, I can't log in, my password, those types of issues. 30:56.910 --> 31:02.390 But there was a whole separate portal for like, hey, I think I've been spearfished, something's weird, I'm seeing something. 31:02.750 --> 31:08.030 And because they put that ticket in the helpdesk, there was different responses and everything like that. 31:08.110 --> 31:12.190 Helpdesk, they weren't trained or aware that maybe this is something weird. 31:12.190 --> 31:16.830 This user provided a lot of data, and then all of a sudden, deleted, deleted, and saying, my bad. 31:16.890 --> 31:20.630 If you read that thing, it kind of looked like this person was two different people talking. 31:20.790 --> 31:26.830 But their SLAs and everything like that, they were just trained to not spot weird or anomalous behavior. 31:26.830 --> 31:28.030 And that's the key word. 31:28.090 --> 31:32.710 We always talk about indicators of compromise, but there's indicators of anomalous. 31:32.910 --> 31:39.930 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. 31:39.930 --> 31:44.810 So really teaching your users how to properly handle those incidents. 31:44.810 --> 31:45.950 Don't just call the helpdesk. 31:45.950 --> 31:48.270 Helpdesk is not security, so to speak. 31:48.570 --> 31:55.130 And then kind of really focusing on when you get those types of events, like prioritizing a real-time communication. 31:55.130 --> 31:57.550 Don't wait for an automated message, don't do anything. 31:57.550 --> 32:01.850 And that's both on the user's front and on your IT and security team. 32:01.950 --> 32:05.670 In this example, you saw all of them were message-based. 32:07.270 --> 32:13.910 Putting in 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. 32:13.970 --> 32:19.750 You have someone on the phone now, you're talking to someone, or you go in the office, you can find them. 32:19.850 --> 32:24.790 Talking, being in person, it changes the level of severity and forces people to react faster. 32:24.830 --> 32:28.070 A ticket, most of the time, may not come in at the same urgency. 32:28.650 --> 32:33.730 And that really can change the amount of time we have as an attacker to be successful. 32:33.730 --> 32:43.030 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. 32:43.030 --> 32:49.390 We looked at them and saw, oh, all the users are passing this Excel document around, we can put a macro payload in it. 32:49.390 --> 32:54.430 And that just adds to the legitimacy of the attack and the story. 32:56.650 --> 33:00.370 All right, those successes were great, but let's cover some failures. 33:01.670 --> 33:08.510 All Red Teamers should probably know this, but putting all your eggs in one basket is bad. 33:09.370 --> 33:12.210 Sometimes, even the best tools are buggy. 33:12.210 --> 33:14.350 We use Cobalt Strike. 33:14.630 --> 33:18.870 It's a great tool, it's very powerful, but obviously, it's not perfect. 33:18.990 --> 33:35.090 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. 33:36.210 --> 33:47.150 So, you know, the little screenshot's kind of funny, but I'm 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. 33:47.650 --> 34:00.550 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. 34:02.690 --> 34:14.130 So the downside of that is I didn't really think about, you know, the presence of that bug, and also how much I was relying on that single beacon. 34:14.130 --> 34:28.870 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, 34:28.870 --> 34:36.830 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. 34:36.950 --> 34:48.810 So I guess the takeaway here is, if you are, you know, once you finally land that shell or that foothold, don't necessarily go and use it immediately. 34:48.810 --> 34:54.710 Maybe take some time, just exist in the environment, gather some information, listen passively, etc. 34:55.310 --> 35:02.430 And then maybe establish a backup C2 or another foothold before you start executing higher impact actions, right? 35:02.430 --> 35:12.010 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. 35:12.010 --> 35:18.810 Maybe let it persist and just sort of blend in for a little bit before you go all the way. 35:20.990 --> 35:23.130 So now we're going to cover lateral movement. 35:23.130 --> 35:29.710 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? 35:30.250 --> 35:43.390 It's something different to everyone else, but basically lateral movement is establishing more pieces of the attack chain within the internal environment, right? 35:43.390 --> 35:46.770 So, or compromising users, or etc. 35:47.550 --> 35:51.770 Basically, this scenario is what we like to call acts like you belong, right? 35:51.770 --> 35:55.930 So blue teams know publicly available tools, right? 35:55.930 --> 35:58.090 They can go out and they know about GitHub, guys. 35:58.090 --> 36:00.790 Like , it's a public site. 36:00.790 --> 36:04.470 Anyone can go on there and download whatever tools. 36:04.470 --> 36:05.690 You know, they can download ImpactKit. 36:05.690 --> 36:08.490 They can download anything that's on there. 36:08.490 --> 36:11.470 They know about it, and they can use it, right? 36:11.670 --> 36:14.310 Tools can stand out from the baseline, right? 36:14.310 --> 36:22.230 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? 36:22.270 --> 36:26.710 If they don't use PowerShell and you do, then now you're standing out from the baseline. 36:27.950 --> 36:38.210 And typically, you know, this has been, you know, 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? 36:38.210 --> 36:43.750 It's harder to catch someone who's using the same tools as every other user in the environment. 36:44.950 --> 36:51.630 So this is a scenario where, basically, we had a limited foothold, so we had that C2 access. 36:52.030 --> 36:56.150 We had credentials, so we had plain text credentials for this user. 36:56.910 --> 37:00.330 Basically, we, you know, enumerated our access. 37:00.330 --> 37:01.410 This is net user output. 37:01.410 --> 37:03.290 Of course, we didn't actually run net user. 37:03.290 --> 37:04.910 That would be way too loud. 37:04.910 --> 37:06.950 We generated this from LDAP. 37:07.130 --> 37:13.210 But, you know, we looked at our group memberships, and we saw one of those group memberships is Citrix, right? 37:13.210 --> 37:23.310 So instead of, you know, oh, let's move LIDAR, let's run ImpactKit, or let's run CME or Bloodhound or whatever, you know, let's just log in to Citrix and see what's in there, right? 37:23.310 --> 37:30.270 Not only is there potential footholds there if they have access to Citrix desktops, but also, you know, you never know what you might find. 37:30.270 --> 37:34.370 So on the right here is a screenshot of that Citrix portal. 37:34.370 --> 37:52.170 So we logged in, and essentially this, you know, everything's censored because it's 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. 37:52.170 --> 37:55.030 Without, you know, we didn't use any real tools to do this. 37:55.030 --> 37:58.790 All we did was proxy our traffic through our beacon and then just log in. 37:59.310 --> 38:07.970 So that's... and 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? 38:09.830 --> 38:14.130 So now Matt's going to cover a lateral movement fail. 38:14.630 --> 38:15.530 Yes. 38:15.730 --> 38:21.550 So this was an engagement where we were dwelling in the client's network for three weeks. 38:21.550 --> 38:24.070 They had no visibility into what we were doing. 38:24.070 --> 38:28.290 As you can kind of see from our maps, we had a lot of access. 38:28.290 --> 38:32.230 We had basically been able to move through, basically compromise. 38:32.230 --> 38:36.870 In fact, at one point we became the security team, which was a key part of this story. 38:36.870 --> 38:44.870 So as we're moving laterally through the environment, there were lots of TOIs, targets of interest, that the client had set up for us to compromise. 38:45.390 --> 38:53.150 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. 38:53.410 --> 39:08.510 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 sorts of things that can really show like, oh my God, we have been hacked and our data, our business critical stuff has been compromised, 39:08.510 --> 39:09.670 like that integrity. 39:11.370 --> 39:17.650 So how we actually managed to establish our initial foothold was on a box where there was a domain admin. 39:17.650 --> 39:19.370 So yay, we had access. 39:19.370 --> 39:28.990 We hadn't really used this account yet, because for most of the port as we're moving, we were able to simulate using different users, jumping to various jump boxes, or getting to different systems, kind of blending in. 39:28.990 --> 39:40.350 And one of the goals was to get access to shipping manifest and all this type of very powerful information related to SKUs and all that stuff. 39:40.750 --> 39:47.270 So, unfortunately, we couldn't get onto any of the user's machines because they were in a different environment. 39:47.270 --> 39:58.130 They were in like a subdomain, but the domain admin account actually had privileges, and it was actually still an administrative privilege level set, high integrity on those boxes. 39:58.130 --> 40:05.630 So we were able to authenticate as this domain administrator on one of the warehouse's computers. 40:06.090 --> 40:13.550 Well, that was where it was kind of getting weird, because the account was designed as a backup account for TVs and stuff. 40:13.830 --> 40:18.290 And eventually, like I kind of said, we were in the security IT guy's chat room. 40:18.290 --> 40:22.710 That's actually the Malware War Room Council, that's what they called it. 40:22.710 --> 40:25.570 We were seeing like, why is this account logging in here? 40:25.570 --> 40:27.450 And then they were starting to see tidbits. 40:27.450 --> 40:33.790 So as they were going back through and knocking down our beacons, we were kind of going around in a different direction. 40:33.790 --> 40:37.050 But we eventually lost all but one or two hosts. 40:37.190 --> 40:41.590 We still had access in the environment, but we had to start all the way back from square one. 40:41.590 --> 40:53.170 And why this is one we like to talk about, especially when we're kind of going through any type of our debriefs internally and stuff is, you know, DA is cool and stuff, but oftentimes companies and stuff, they're going to look for that. 40:54.550 --> 40:57.030 Are their DA accounts logged into random places? 40:57.030 --> 40:59.470 I know most of the time that's where everyone goes first. 40:59.470 --> 41:03.690 They have a lot of controls around, but you can do a lot with like other types of accounts. 41:03.690 --> 41:10.970 Like I kind of said, IT security guys, admins, they have a lot of the same access that a domain administrator. 41:11.510 --> 41:22.530 And oftentimes when we look at this, like these types of goals and end results, like maybe compromise an application, get access to the database behind it, where like all the credit card or juicy information is. 41:23.090 --> 41:25.030 Domain admin doesn't really play into the fact. 41:25.030 --> 41:27.450 Domain admin just gives you administrative rights on the box. 41:27.450 --> 41:30.330 It doesn't give you, you know, admin rights into an application. 41:30.710 --> 41:32.450 So that's something where you always want to keep in mind. 41:32.450 --> 41:36.470 So we always kind of look at it like, who are you logging with? 41:36.470 --> 41:37.810 Is there value to it? 41:37.810 --> 41:44.170 Like, you know, it might be an easy skeleton key, but are you going to create more waves than it's worth? 41:44.370 --> 41:46.010 And this is a great example of that. 41:46.010 --> 41:53.290 We pretty much, we were in over 50 boxes moving through different environments and we had to go all the way back to square one. 41:55.850 --> 42:02.870 So breaking this chain, it really comes down to baselining and understanding your environment. 42:03.110 --> 42:05.950 There's a great term called least frequency. 42:05.950 --> 42:17.990 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. 42:17.990 --> 42:25.050 Everything's going to be the same until you see some differences, like Internet Explorer user agent stuff. 42:25.050 --> 42:30.730 And those are the least frequent objects or events that now you can drill into, well, why did that happen? 42:30.730 --> 42:44.230 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 focus in on those few unique new events. 42:44.230 --> 42:54.430 May not be malicious right away, but you can start digging and that's how you can make this large cloud of noise, something smaller and easier for your team to handle and manage. 42:55.250 --> 43:03.930 But when it comes down 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. 43:03.950 --> 43:06.850 That's often the easiest pitfall for lateral movement. 43:07.550 --> 43:11.050 To go back to what Corey said about, you know, the Citrix and stuff. 43:11.350 --> 43:17.710 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. 43:18.890 --> 43:20.730 There are other great tools. 43:20.730 --> 43:24.630 I'm really surprised this one is not talked about a lot or used. 43:24.630 --> 43:25.970 It's called Net Cease. 43:25.970 --> 43:28.150 There's a link right down there that we provided. 43:28.650 --> 43:44.050 Essentially, what it does is it prevents the remote call to net session in Noom, 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. 43:44.230 --> 43:46.310 It doesn't disable or hamper it. 43:46.310 --> 43:49.030 What it does is it changes who can call it remotely. 43:49.030 --> 43:50.930 If you're on the box, you can call it. 43:50.930 --> 43:59.810 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. 43:59.810 --> 44:03.370 It kind of changes it to be power users, administrators, or another group. 44:03.630 --> 44:15.890 And with that patch and that little registry change, which 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. 44:16.310 --> 44:19.290 You can't just start hitting every box and looking at any... 44:19.290 --> 44:21.950 using any tools to find that user. 44:21.950 --> 44:23.990 It really changes the game. 44:24.710 --> 44:33.830 Also, making sure, you know, privilege accounts are protected, you know, there are protected user groups or credential delineations and delegations. 44:33.830 --> 44:35.710 Make sure that, you know, you're not... 44:35.710 --> 44:41.130 if someone logs in a service account or something like that, they're not just stale, sitting in memory, or they're not just easily available. 44:41.130 --> 44:45.790 Really kind of protecting the actual sensitive of credentials or hash credentials. 44:48.830 --> 44:51.930 So now we're going to kind of talk about persistence. 44:51.930 --> 44:54.950 It's one of those... it's more of an art form, I like to say. 44:55.530 --> 45:07.070 There's great techniques or something like that, but whenever you hear about a new one 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 vulnerabilities that allow. 45:07.230 --> 45:09.610 So I always like to take the arts form. 45:10.250 --> 45:22.610 And it really comes down to, like, you know, you could go that crazy route that they might have it patched, but if, say, your payload or whatever, you know, binary, DLL, whatever you want to have it, can persist on disk, or it stays on disk. 45:22.610 --> 45:39.270 It could be somewhere in, like, you know, the user app data, temp folder, something like that, and 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, 45:39.270 --> 45:43.130 it's probably not going to get detected if it looks right telling that story again. 45:43.130 --> 45:59.330 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 gpupdate.exe, but our binary, our evil binary was gpupdate.exe, because it was obviously putting app data. 45:59.530 --> 46:08.930 So when you looked at it, strictly from the point, oh, the process, you know, the binary gpupdate started up when the user kind of logged in, and it wasn't as suspicious. 46:08.930 --> 46:15.950 I mean, if you drilled in, you would have seen, well , why is gpupdate not in C system Windows 32? 46:16.010 --> 46:18.770 Why is it in app data? 46:19.050 --> 46:28.570 And one of the great things about that is that if they're looking at things like what this file is, there's something else that's already kind of dragged their attention towards it, so you're already kind of burnt. 46:28.650 --> 46:34.930 But just staying pretty low, making tiny ripples, you hang around that, you know, indicators of anomalous. 46:34.930 --> 46:41.010 If someone looked at it, they probably wouldn't blink twice until they looked at the file path or other attributes of the file. 46:43.070 --> 46:49.450 And now it comes down to, I think this is one of our favorite ones to talk about, is conference rooms. 46:50.750 --> 47:00.970 So we were on an 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 couldn't afford to lose. 47:00.970 --> 47:04.990 We were really coming close to the tight line of the end. 47:04.990 --> 47:07.090 So it's very late at night. 47:07.090 --> 47:08.190 Okay, perfect. 47:08.490 --> 47:12.550 So we decided, okay, we know what their conference room systems are. 47:12.550 --> 47:18.210 So we put a beacon with persistence on it, thinking, you know, no one's going to look at them. 47:18.210 --> 47:19.730 It's pretty late on a Friday. 47:19.730 --> 47:25.030 No one's going to, you know, do anything about this until Monday, if anything. 47:25.290 --> 47:29.010 And let's be honest, no one's going to come in over the weekend and use the conference room machines. 47:29.030 --> 47:30.890 But it was a pretty solid idea. 47:30.890 --> 47:40.470 What actually happened was their SOC was like, why is there traffic coming from the conference rooms at 2 a.m.? 47:40.470 --> 47:41.450 Like, what? 47:41.450 --> 47:43.070 Is someone using these? 47:43.350 --> 47:56.030 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. 47:56.030 --> 48:01.830 And that really was kind of like the problem was we thought we were being really stealthy and quiet. 48:01.830 --> 48:05.710 And for all purposes, like, you know, there was no artifacts left. 48:05.910 --> 48:09.690 There was no, like, alerts from the EDR consoles or dashboards. 48:09.690 --> 48:12.430 It was just someone saying, well, this traffic, it looks weird. 48:12.430 --> 48:15.290 Our traffic baseline is that, you know, 8 a.m. 48:15.290 --> 48:16.350 to 5 p.m. 48:16.350 --> 48:17.010 is a lot. 48:17.010 --> 48:18.570 And then afterwards, it's a little. 48:18.570 --> 48:20.550 And then all of a sudden, there's a big spike. 48:20.650 --> 48:23.330 So it's like, OK, what's going on here? 48:23.350 --> 48:25.470 And then they dug deeper and deeper. 48:25.470 --> 48:29.710 And it's really hard to come back from that because they've done everything right. 48:29.710 --> 48:36.030 Like, that's so low of an indicator that there's nothing you can really mask besides maybe figure out a better story. 48:38.950 --> 48:43.410 So as I was saying before, this whole persistence, it's really an art form. 48:43.410 --> 48:47.790 There's no, like, silver bullet that if you do this, there's no way anyone can persist on your environment. 48:48.510 --> 48:51.930 You know, patching and keeping up to date is always a great thing. 48:51.930 --> 48:56.590 But kind of like the stories we just kind of described, like, it doesn't matter. 48:56.590 --> 48:58.650 It really comes down to how are you monitoring? 48:58.650 --> 49:00.030 Do you have a good baseline? 49:00.030 --> 49:05.290 Do you understand, like, what processes typically should start up for every different department? 49:05.710 --> 49:11.950 Does HR just use Google Chrome and Outlook and all the services related to that? 49:11.950 --> 49:14.910 So, OK, there's your baseline for that department. 49:14.930 --> 49:31.850 And looking around, like, file locations, you know, the ones that hackers love to use, you know, all 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 in temp or app data that's starting up right when a user logs in. 49:32.210 --> 49:36.410 And of course, the one that got us burned is the unusual net communications. 49:36.410 --> 49:48.030 Looking at those things, if 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. 49:49.450 --> 49:52.290 Also, application whitelisting is your friend. 49:52.290 --> 49:53.450 It's not ours. 49:53.670 --> 50:04.830 When we're on a box, whatever way, you know, might be in Excel, Word documents that bypass that, but, like, trying to get persistence, it's next to impossible if you have a strong whitelist application going. 50:04.850 --> 50:08.690 You know, dropping binaries, like we just described, makes it a whole lot harder. 50:08.870 --> 50:20.610 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. 50:21.190 --> 50:24.150 All of those things are not blocked through application whitelisting. 50:24.150 --> 50:25.430 It can just be a nightmare. 50:25.430 --> 50:29.750 By the time we get it all figured out, you know, we've persisted too long, not moving. 50:30.850 --> 50:36.810 So it's definitely a key thing to definitely keep up monitoring and baselining and getting a good understanding for your environment. 50:37.370 --> 50:39.370 So we're now coming to the end. 50:39.370 --> 50:40.230 All right. 50:40.390 --> 50:45.030 Yeah, so conclusions, or, you know, confessions of an attacker. 50:47.370 --> 50:51.030 So here's some of our sort of lifting the curtain a little bit. 50:51.210 --> 50:53.210 Attackers use what they know works, right? 50:53.210 --> 50:56.830 So, you know, we use Cobalt Strike because we know Cobalt Strike works. 50:56.830 --> 50:58.670 We , you know, custom stuff is great. 50:58.670 --> 51:00.410 We experiment with it quite a bit. 51:00.410 --> 51:09.130 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, which C2 do you want to use, right? 51:09.130 --> 51:15.390 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? 51:15.390 --> 51:26.790 So oftentimes that can be easier for blue teams to identify because the tool set is shrinking as you're relying on more well-developed or well-known tools. 51:27.870 --> 51:31.330 Also, one end-to-end attack chain can be easier for us to manage, right? 51:31.330 --> 51:42.890 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. 51:42.890 --> 51:50.930 But the reality is we're, you know, we're red teamers, so we're doing this in a condensed timeframe with restrictions on how long we have. 51:50.930 --> 51:54.790 So oftentimes we end up with just one end-to-end attack chain. 51:54.790 --> 52:04.670 And along the way, all those chain breaks that we described are ways that would just basically send us back to square one where we'd have to start over and say, we did this, this, and this. 52:04.670 --> 52:11.050 However, they had this security control or they caught us or whatever, and now we have to start over. 52:11.050 --> 52:15.910 So it's actually, you know, it's... the chains are more fragile than they might appear. 52:16.710 --> 52:25.250 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? 52:25.250 --> 52:30.370 We can't stop users from emailing their security team and saying, hey, this looks weird. 52:30.930 --> 52:38.590 Obviously, we showed an example of how we can do anti-evasive maneuvers and say, oh, actually, never mind, my mistake. 52:38.590 --> 52:45.910 But if someone's going to pick up the phone and call a user or if the user picks up the phone and calls up security people, we're not a part of that conversation. 52:45.910 --> 52:47.970 We can't really work around that. 52:47.970 --> 52:54.670 So that's where that security awareness training and just relying and trusting on your users is actually really hard to get around. 52:55.690 --> 52:59.350 And then obviously, defense in depth, it really does win in the long run, right? 52:59.350 --> 53:01.790 So this works for real attackers, right? 53:01.790 --> 53:05.370 Because if you're trying not to get hacked, you're running away from a bear. 53:05.370 --> 53:08.650 So as long as you're not the slowest, you probably won't get eaten. 53:08.710 --> 53:11.630 But defense in depth makes it harder. 53:11.690 --> 53:25.150 Every step along the way gets harder when you have, oh, well, we got a foothold, but now they have all these really strong local firewalls, so we can't move laterally as easily because everything's blocked to everything else, right? 53:25.150 --> 53:26.930 That's an example of defense in depth. 53:27.650 --> 53:33.190 That's not protecting you from spear phishing, but that is helping if you do get to that breach status. 53:33.190 --> 53:35.910 It's going to be restricted in the scope of it. 53:36.790 --> 53:43.290 And then Matt has some final conclusions on tools or defensive controls. 53:43.290 --> 53:44.730 Yes, defensive controls. 53:44.730 --> 53:46.890 We kind of talked a lot about this. 53:46.890 --> 53:52.410 We kind of at some point hit small, you know, an inch into this type of topic. 53:53.410 --> 53:57.110 You know, tools are great, you know, as we kind of described before. 53:57.110 --> 54:03.850 We highly recommend, you know, modern tools, proper configurations, but they're kind of useless if you just buy them in an audit mode. 54:04.550 --> 54:12.850 And that's what we kind of see a lot is, is the deployment that they're not, you know, you might have the greatest security stack of 20 different products. 54:12.850 --> 54:20.130 You might have 14 different ADR agents on there, but if they're not properly tuned or configured, there's tons of gaps. 54:20.130 --> 54:23.450 And that's where hackers and attackers love to live is just in those gaps. 54:23.450 --> 54:24.590 It's pretty much where it is. 54:24.590 --> 54:29.050 Hey, look, there's a gap or a blind spot in our, in this client's network. 54:29.050 --> 54:30.670 That's where we are going to start. 54:30.670 --> 54:35.590 We're going to live in this gap and we're going to try to move as much as we can in there because you guys don't have any visibility. 54:35.590 --> 54:36.470 We know that. 54:36.810 --> 54:49.010 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. 54:49.010 --> 54:50.450 We could use macros. 54:50.450 --> 54:52.570 We can use water hole attacks, you know, set up. 54:52.570 --> 54:59.890 In fact, hey guys, you know, your ADR is only set up to detect, you know, process injections or something like that, anything like that. 55:00.410 --> 55:01.970 There's tons of little things like that. 55:01.970 --> 55:08.270 And that's where really tuning and tightening up can really make a huge difference in the success of your defensive controls. 55:08.790 --> 55:11.070 Also that kind of comment I made before about audit. 55:11.070 --> 55:17.770 We often see the latest and greatest, you know, oh, this is going to stop every, you know, threat, cyber threat known to mankind. 55:17.770 --> 55:22.370 We detect, oh, days before they even thought of tools, but you ran in an audit mode. 55:22.370 --> 55:24.030 So someone's not looking at the dashboard. 55:24.030 --> 55:25.690 You don't see a blinking light appear. 55:26.490 --> 55:30.210 And so we continue on our way through the environment. 55:31.010 --> 55:33.710 It's really, it's really hard to do a lot of that stuff. 55:33.710 --> 55:38.750 And that's where like hiring, you know, red team sims or doing those types of engagements. 55:38.750 --> 55:44.830 So that way you can see what's out there, understand what, you know, people are doing and seeing where those gaps are in your product. 55:44.830 --> 55:52.830 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. 55:53.050 --> 55:59.010 Really having it go through those trials and stuff in a live fire engagement is going to help you guys more than anything. 56:01.270 --> 56:06.110 Also, we know this, and this is probably going to be one of the most frequent questions asked. 56:06.110 --> 56:11.150 You know, well, if we do all this stuff, then, you know, it's not usable for my environment. 56:11.150 --> 56:16.110 You know, users can't log in as easy or they can't do things that they used to do as quickly and stuff. 56:16.110 --> 56:20.210 And now they're going to complain that they're affecting or affecting their ability to do their job. 56:20.210 --> 56:22.970 And, you know, it's going to hurt the company's bottom line. 56:22.970 --> 56:31.710 But, you know, it's that type, it's a 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. 56:31.930 --> 56:33.090 It's very hard. 56:33.090 --> 56:39.450 I mean, I don't envy anyone who has to deal with those conversations on a daily basis, but it's necessary to have. 56:40.010 --> 56:50.390 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. 56:50.430 --> 56:54.170 And the last thing, of course, we've mentioned throughout this whole thing is baselining. 56:54.350 --> 56:55.510 Baselining, baselining. 56:55.510 --> 56:57.550 Know your environment inside and out. 56:57.930 --> 57:13.670 If you do, that's the biggest thing 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 normally using, 57:13.670 --> 57:22.290 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. 57:22.290 --> 57:25.870 Baselining is probably the biggest key, and that's why we left it as the largest bullet point. 57:26.890 --> 57:29.010 Really, just least frequency. 57:29.110 --> 57:31.230 Get in tune with your environment. 57:31.230 --> 57:32.390 Get really in tune. 57:32.390 --> 57:33.910 Get very close to it. 57:33.910 --> 57:35.790 Get unnecessarily close to it. 57:35.790 --> 57:39.590 And with that knowledge, you'll definitely be able to spot the anomalous behavior. 57:41.170 --> 57:44.330 All right, so we have a few minutes left. 57:44.330 --> 57:48.370 If you guys have questions, put them in the Discord channel. 57:48.550 --> 57:53.090 If you guys are in Discord, it's the Briefings Main Talks channel. 57:53.310 --> 57:59.890 We're both in there, and we can try to answer some questions in real time before we wrap up. 57:59.890 --> 58:04.650 You can hit us up on Keybase or Twitter if you have any questions or just want to chat. 58:04.650 --> 58:05.350 We're always available. 58:05.350 --> 58:12.770 We love picking other teams or other people's brains in the industry, so definitely hit us up if you ever have a question. 58:13.710 --> 58:20.730 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.