[00:01.100 --> 00:05.860]  Welcome back. And thank you, Corey and Matt, for supporting us,
[00:05.860 --> 00:09.440]  supporting the Red Team Village, supporting DEF CON and the community.
[00:09.620 --> 00:12.000]  And without any further ado, take it away. You're live.
[00:12.220 --> 00:13.060]  Thank you.
[00:13.060 --> 00:18.660]  Thanks, Omar. So this talk is called Breaking the Attack Chain,
[00:18.660 --> 00:22.260]  Unexpected Wins and Fails from Two Stimulated Adversaries.
[00:24.320 --> 00:27.560]  So here's the agenda. We'll start with who we are,
[00:27.560 --> 00:29.860]  and then we're going to cover some wins and some fails
[00:30.440 --> 00:35.360]  across a broad variety of different categories of Red Team topics.
[00:35.480 --> 00:38.080]  And then we'll finish off with some of our just notes,
[00:38.080 --> 00:40.580]  and also we'll open up the floor for questions.
[00:41.540 --> 00:44.640]  So who we are. Matt, you want to say who you are?
[00:44.640 --> 00:47.420]  Sure. 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 --> 00:57.280]  That's pretty much our fancy way of calling what we do
[00:57.280 --> 01:01.020]  for our red, purple, and physical-based,
[01:01.020 --> 01:04.380]  real-world scenario-based-driven operations.
[01:04.420 --> 01:09.300]  Also authored and developed several open-source tools and frameworks,
[01:09.300 --> 01:14.660]  mainly focusing around EDR, evasion, and bypassing security controls
[01:14.660 --> 01:16.320]  and remaining low underneath the radar.
[01:16.320 --> 01:18.260]  That's really where my passion is.
[01:18.360 --> 01:20.900]  I did do, for a while in the beginning of my career,
[01:20.900 --> 01:22.660]  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:29.960]  Also, I've spoken at numerous different conventions,
[01:29.960 --> 01:33.680]  you know, DerbyCon, B-Sides Las Vegas, HackFest URCON.
[01:33.680 --> 01:36.020]  Really just passionate about red teaming operations
[01:36.020 --> 01:38.820]  and the nuances and always improving that concept of
[01:38.820 --> 01:41.280]  sharpening that spear, staying low to the ground.
[01:41.620 --> 01:42.780]  I'm going to turn it over now to Corey
[01:42.780 --> 01:45.200]  to kind of give a brief introduction as well.
[01:45.200 --> 01:48.960]  So I'm also a Principal Security Consultant at Optiv,
[01:48.960 --> 01:51.480]  specializing in Adversary Sim, or red teaming,
[01:51.480 --> 01:54.760]  or whatever you want to call it, depending on the buzzwords of the day.
[01:54.760 --> 01:57.320]  I've participated in some open source tool development,
[01:57.320 --> 02:00.640]  and then my passions really center around data aggregation
[02:00.640 --> 02:06.900]  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:19.640]  This presentation is based on our experience
[02:19.640 --> 02:23.420]  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:38.660]  Some people's definition of a red team is a full-blown,
[02:38.660 --> 02:42.200]  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:52.500]  We're not going to cover that it was raining that day
[02:52.500 --> 02:54.740]  or whatever reason we have for each scenario.
[02:54.740 --> 02:56.440]  So there might be a little bit of background information
[02:56.440 --> 03:00.480]  that we're going to gloss over, but it should be fun.
[03:00.760 --> 03:04.300]  This talk is going to kind of be a briefing style,
[03:04.300 --> 03:06.980]  so it's kind of almost like if we're talking to you,
[03:06.980 --> 03:10.020]  it could be if we're a red team or if you're a blue team,
[03:10.020 --> 03:13.460]  it's sort of covering our debrief of a lot of these scenarios
[03:13.460 --> 03:15.420]  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:25.800]  Yep. So we all know what OSINT is.
[03:25.800 --> 03:29.220]  It's one of the most, I always believe it's one of the most vital things
[03:29.220 --> 03:31.480]  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:37.760]  Well, one of the things that differentiates, you know,
[03:37.760 --> 03:39.760]  just quickly Googling, seeing what you can get
[03:39.760 --> 03:45.340]  and like a deep methodical approach is honestly the level of detail,
[03:45.340 --> 03:48.660]  whether you have proper API keys, you're scraping the right data.
[03:49.820 --> 03:52.780]  And as I kind of say this, all those different things we know,
[03:52.780 --> 03:55.500]  they can be sometimes an endless rabbit hole where you go down
[03:56.080 --> 03:58.720]  and you never know if it's going to yield you stuff.
[03:58.720 --> 04:01.540]  You could be starting to pull down, you know, employees,
[04:01.540 --> 04:05.800]  Instagram posts, Facebook, you know, all those types of social media things,
[04:05.800 --> 04:08.320]  pulling out, trying to see if there's maybe a picture or something
[04:08.320 --> 04:10.560]  or some kind of metadata that you can scrape.
[04:10.620 --> 04:13.180]  And you can be doing that for thousands of pictures
[04:13.180 --> 04:14.980]  and it may yield nothing.
[04:15.020 --> 04:18.260]  But oftentimes, it's still a very vital role
[04:18.260 --> 04:21.820]  and can lead to a lot of unexpected wins and successes,
[04:21.820 --> 04:23.280]  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:38.560]  A bit of the background on this is we were looking at a client,
[04:38.560 --> 04:40.600]  we were doing a remote breach simulation,
[04:40.600 --> 04:43.400]  which is our terminology for Red Team Ops.
[04:44.000 --> 04:47.380]  And we did that typical, started building the profile,
[04:47.380 --> 04:49.060]  looking at who the employees were,
[04:49.060 --> 04:51.480]  trying to get an understanding of what information was out there
[04:51.480 --> 04:56.460]  until we stumbled across the company's Instagram account.
[04:56.460 --> 04:59.640]  And this picture was originally taken by another employee
[04:59.640 --> 05:04.740]  that the company's Instagram account kind of liked and retweeted.
[05:04.740 --> 05:08.740]  It was basically just, which we have blurred out,
[05:08.920 --> 05:12.200]  a bunch of PII information, which included, you know,
[05:12.200 --> 05:16.000]  date of birth, home address, credit card, bank transactions,
[05:16.140 --> 05:18.120]  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:24.600]  So one of the things we always like to drive is sometimes
[05:24.600 --> 05:27.800]  we don't even need to get inside the network, get domain admin,
[05:27.800 --> 05:31.700]  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:41.360]  As a lot of companies, they train their users,
[05:41.360 --> 05:43.560]  they don't click on phishing links, don't click on this,
[05:43.560 --> 05:46.840]  but they don't teach them, don't post this or this is bad,
[05:46.840 --> 05:48.440]  this is something sensitive,
[05:48.440 --> 05:50.380]  especially when it comes down to certain departments.
[05:50.380 --> 05:51.780]  When you look at a marketing team,
[05:51.780 --> 05:54.620]  they're not given the same level of training that maybe someone
[05:54.620 --> 05:57.380]  that actually handles sensitive, like, you know, credit card data
[05:57.380 --> 05:59.300]  in the sense that those two different things,
[05:59.300 --> 06:02.420]  the awareness there is there are huge gaps.
[06:06.540 --> 06:10.480]  And that leads us to our next sort of major one that we love to look at
[06:10.480 --> 06:11.560]  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:23.320]  I mean, correct me if I'm wrong,
[06:23.320 --> 06:26.740]  but I believe now for a pro license for Pastebin,
[06:26.740 --> 06:29.920]  you can, for $50, you can scrape to your heart's content.
[06:29.920 --> 06:34.540]  You put that in, say, like a Caldana instance, like Elk,
[06:34.540 --> 06:36.040]  and it just endless scrapes.
[06:36.040 --> 06:38.180]  You can kind of just make a search thing like search client name
[06:38.180 --> 06:40.980]  and look at every single thing that references this.
[06:41.220 --> 06:44.640]  And that's honestly something so simple, so unique and so fast
[06:44.640 --> 06:47.920]  that you can yield things like usernames, credentials, APIs,
[06:47.920 --> 06:50.200]  hell, even credit cards and other sensitive PII.
[06:50.200 --> 06:51.660]  As you can kind of see,
[06:51.660 --> 06:54.920]  we've been able to pull out actual credit card information
[06:55.440 --> 07:00.320]  going right down to the user's security questions,
[07:00.320 --> 07:02.740]  where they live, their phone number,
[07:02.740 --> 07:04.060]  all that information.
[07:04.060 --> 07:06.360]  With all that information, we were able to actually,
[07:06.360 --> 07:09.340]  because the client was a bank, provide an impact scenario
[07:09.340 --> 07:11.800]  where we could actually bypass all the security controls
[07:11.800 --> 07:15.500]  and start doing some financial banking on behalf of this individual.
[07:15.620 --> 07:17.240]  Because all their controls were like,
[07:17.240 --> 07:20.340]  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:44.520]  We found two-year-old valid credentials to a third-party portal,
[07:44.520 --> 07:48.940]  which led us to have access to a setup site.
[07:48.940 --> 07:50.740]  And from there, we were able to get enough information
[07:50.740 --> 07:54.620]  that allowed us to establish a foothold into their internal network.
[07:54.620 --> 07:57.080]  So something like that can sit there for years
[07:57.080 --> 07:59.160]  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:09.590]  And this will be the style of that debrief,
[08:09.590 --> 08:11.110]  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:19.850]  And it's really hard, especially when data is out of your control,
[08:19.850 --> 08:22.070]  when you get stuff on those PACE sites,
[08:22.070 --> 08:23.930]  it's next to impossible to take it down.
[08:24.370 --> 08:26.550]  So there's no surefire of, oh, this is up there,
[08:26.550 --> 08:29.030]  we'll bring this down, we'll cease and desist,
[08:29.030 --> 08:30.690]  and that will be the end of it.
[08:31.190 --> 08:33.210]  Especially like what I was just describing with PACE sites
[08:33.210 --> 08:35.490]  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:54.590]  It's performing that on yourself, your company,
[08:55.310 --> 08:57.850]  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:01.770]  So it might be, hey, we discovered a couple of clients,
[09:01.770 --> 09:03.830]  there's sensitive data out there, we need to contact them now
[09:03.830 --> 09:06.930]  and get all that stuff scrubbed.
[09:06.930 --> 09:08.850]  So that way it's not valid anymore.
[09:08.850 --> 09:11.990]  And things like that, as well as awareness training,
[09:11.990 --> 09:14.570]  not just looking at, hey, users, don't click on links,
[09:14.570 --> 09:16.470]  or if you get a phone call from someone suspicious,
[09:16.470 --> 09:20.050]  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:26.990]  Well, here's what an attacker looks at it as,
[09:26.990 --> 09:28.550]  and this is why it's so impactful.
[09:28.550 --> 09:30.870]  And just kind of visually explain to them
[09:30.870 --> 09:33.910]  why this is so detrimental to post.
[09:34.130 --> 09:36.970]  And that can oftentimes help reduce that gap
[09:36.970 --> 09:39.110]  from like this big to like this big.
[09:39.110 --> 09:40.470]  You're always going to still have a little space,
[09:40.470 --> 09:43.310]  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:55.010]  So obviously, a lot of successes do happen,
[09:55.010 --> 09:56.430]  but also failures happen.
[09:56.430 --> 09:59.170]  And I think maybe blue teams and red teams can learn
[09:59.170 --> 10:01.270]  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:07.870]  So basically, the TLDR is that email alias domains
[10:07.870 --> 10:11.730]  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:24.250]  But basically, the client had clientdomain.com
[10:24.250 --> 10:27.090]  was their email address. 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:36.730]  We started password guessing,
[10:37.250 --> 10:39.450]  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:01.590]  Vue DNS has a very cool reverse Whois tool
[11:01.590 --> 11:04.830]  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:16.230]  Obviously, it can get a little hairy if you have, you know,
[11:16.230 --> 11:18.530]  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:37.690]  So it was just sort of a weird scenario where we basically burned a few days
[11:37.690 --> 11:41.130]  on an assumption that this was obviously the domain,
[11:41.130 --> 11:43.610]  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 --> 11:53.810]  If you're getting incongruous results or something that doesn't match up
[11:53.810 --> 11:56.930]  with what you're expecting when you're executing a tool
[11:56.930 --> 12:00.310]  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:06.830]  You know, the getUserRealm functionality of Office 365,
[12:06.830 --> 12:11.810]  you can use to sort of manually inspect each individual element
[12:11.810 --> 12:17.290]  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:49.070]  We were hired to do a physical breach assessment
[12:49.070 --> 12:51.090]  to break in physically into a building.
[12:51.570 --> 12:55.170]  The building in question was this large commercial high-rise
[12:55.170 --> 12:59.590]  and we're listed as safe arguments in the story, the seventh floor.
[12:59.910 --> 13:03.930]  So we did a lot of OSINT and we were able to find some information,
[13:03.930 --> 13:08.450]  including a page for the building that basically listed out,
[13:08.450 --> 13:10.570]  you know, who is the property managing company,
[13:10.570 --> 13:14.390]  like who is the actual person on site, what were the vendors,
[13:14.390 --> 13:15.610]  even forms to fill out.
[13:15.610 --> 13:18.670]  Say, for instance, if you were one of the tenants there and say,
[13:18.670 --> 13:22.410]  you know, telecom went out or pipe burst, paperwork and all that stuff,
[13:22.410 --> 13:24.430]  you know, who to contact, here's like the, you know,
[13:24.430 --> 13:27.850]  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:37.010]  We kind of decided to come up with a scenario that we were, you know,
[13:37.010 --> 13:38.010]  coming into the building,
[13:38.010 --> 13:41.850]  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:52.850]  We were able to find out uniforms for that vendor and we addressed,
[13:52.850 --> 13:55.370]  you know, perfectly right down to the level details.
[13:55.370 --> 13:56.510]  We had called beforehand,
[13:56.510 --> 14:00.350]  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:12.130]  I've been getting a lot of calls throughout the day,
[14:12.130 --> 14:13.410]  just people verifying them.
[14:13.410 --> 14:16.170]  I just wanted to let you know that they should be at your floor in the next
[14:16.170 --> 14:17.050]  20, 30 minutes.
[14:17.050 --> 14:18.510]  I'm just stepping up for lunch.
[14:18.510 --> 14:21.650]  So I may not be able to be reachable by phone, but if they do,
[14:21.650 --> 14:24.110]  have them show the work order and make sure everything like that,
[14:24.110 --> 14:27.250]  their names are blah and blah and everything like that.
[14:27.250 --> 14:30.630]  So we really had provided enough information so that way they could go
[14:30.630 --> 14:33.190]  listen to the voicemail and say, okay,
[14:33.190 --> 14:35.210]  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 --> 14:52.370]  And then maybe we kind of realized it's been a while,
[14:52.370 --> 14:54.630]  but maybe another five, 10 minutes later,
[14:54.630 --> 15:00.230]  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:17.010]  He probably, he left a call. 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:31.270]  What do you do in that situation? 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:35.110]  But the problem was,
[15:35.110 --> 15:38.870]  we didn't realize that the building was split property managers for retail
[15:38.870 --> 15:40.970]  and the corporate renting.
[15:41.650 --> 15:45.350]  And in that moment, like your perfect pretext and everything like that,
[15:45.350 --> 15:46.870]  just goes out the window.
[15:46.990 --> 15:48.410]  So me and my colleague were sitting there.
[15:48.410 --> 15:50.310]  We literally had this conversation, just staring at each other,
[15:50.310 --> 15:52.890]  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:08.770]  I called someone who was obviously a co-worker of mine
[16:08.770 --> 16:10.490]  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:18.370]  All this stuff, just trying to really paint it off
[16:18.370 --> 16:19.330]  that we don't want to do anything
[16:19.330 --> 16:21.670]  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:32.810]  But I will tell you,
[16:32.810 --> 16:34.790]  that was the most awkward elevator ride down
[16:34.790 --> 16:36.090]  when they came with us in the elevator
[16:36.090 --> 16:37.170]  and were just sitting there like,
[16:37.170 --> 16:39.770]  this elevator is going so slow.
[16:40.770 --> 16:41.890]  The moment we got to the ground floor,
[16:41.890 --> 16:42.890]  we shook their hands.
[16:42.890 --> 16:45.010]  I'm pretty sure we had a little bit of sweat on our hands
[16:45.010 --> 16:47.590]  and we're just like bolting right out.
[16:49.270 --> 16:51.130]  So those are the things where, you know,
[16:51.130 --> 16:54.310]  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:04.010]  So initial access, you know,
[17:04.010 --> 17:05.370]  we can define it as, you know,
[17:05.370 --> 17:08.150]  that initial point of compromise, right?
[17:08.150 --> 17:12.470]  So nowadays, starting from that perimeter environment,
[17:12.570 --> 17:14.530]  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:20.350]  It's pretty much SSO everything,
[17:20.350 --> 17:22.950]  redirect everything through their central auth,
[17:22.950 --> 17:24.710]  and everything's multi-factor, right?
[17:24.710 --> 17:28.830]  So the approach here as an attacker is to prioritize
[17:28.830 --> 17:31.450]  that breadth-first search for that weak point, right?
[17:31.450 --> 17:33.710]  So, you know, if it's Office 365
[17:33.710 --> 17:36.210]  and they have basic auth enabled on AWS
[17:36.210 --> 17:37.890]  or something like that,
[17:37.890 --> 17:40.130]  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:44.550]  Obviously, we're not going to cover any of these in depth,
[17:44.550 --> 17:46.490]  but password guessing is really common.
[17:46.490 --> 17:48.930]  Web app vulnerabilities, if you can get deserialized
[17:48.930 --> 17:51.550]  or some other, you know, similar, you know,
[17:51.550 --> 17:53.330]  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 --> 17:58.770]  And then lastly, physical access isn't easy,
[17:58.770 --> 18:00.570]  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:13.250]  We have seen, especially in the past couple of years,
[18:13.250 --> 18:15.710]  that phishing is really getting a lot of eyeballs
[18:15.710 --> 18:17.850]  as far as tooling solutions
[18:17.850 --> 18:20.890]  and just general alerting and controls.
[18:21.570 --> 18:23.570]  Attachments don't work from the perimeter anymore
[18:23.570 --> 18:25.290]  with an email filter.
[18:25.290 --> 18:28.630]  Email filters have their own URL filtering now.
[18:28.630 --> 18:32.230]  Any email that's sent to more than five people,
[18:32.230 --> 18:33.690]  for example, might just get blocked
[18:33.690 --> 18:36.230]  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:40.170]  I mean, I guess it's like over the years,
[18:40.170 --> 18:42.490]  we finally started to get better at training people
[18:42.490 --> 18:44.410]  and developing technical solutions
[18:44.410 --> 18:46.710]  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:55.270]  So we like to actually focus not necessarily on passwords,
[18:55.270 --> 18:56.950]  but actually on tokens.
[18:56.950 --> 19:00.930]  So there are MFA-compatible phishing tools
[19:00.930 --> 19:02.610]  like Evilginix or Mudlishka
[19:02.610 --> 19:05.250]  that actually let you gather the tokens.
[19:05.250 --> 19:07.290]  So you're actually, with these tools,
[19:07.290 --> 19:09.990]  you're essentially sending a message with the URL in it,
[19:09.990 --> 19:11.930]  the user is browsing to that URL,
[19:11.930 --> 19:15.430]  and then they are basically using you as a proxy
[19:15.430 --> 19:17.330]  to interact with the real site.
[19:17.330 --> 19:20.230]  So if they're using your site as a proxy,
[19:20.230 --> 19:22.550]  you can capture all the authentication tokens,
[19:22.550 --> 19:26.590]  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:35.330]  Lots of people don't have anomaly alerting
[19:35.330 --> 19:37.310]  or anything like that on token usage, right?
[19:37.310 --> 19:40.430]  So if I log in from a new device,
[19:40.430 --> 19:42.150]  it says, whoa, this is a new device,
[19:42.150 --> 19:43.270]  you need to authenticate it.
[19:43.270 --> 19:45.590]  But if I just take the already valid token
[19:45.590 --> 19:47.510]  and replay it onto another device,
[19:47.510 --> 19:51.590]  oftentimes it just works without any sort of double checks
[19:51.590 --> 19:52.670]  or anything like that.
[19:52.670 --> 19:54.490]  The other reason why we like tokens
[19:54.490 --> 19:56.230]  is because they're hard to reset.
[19:56.230 --> 19:59.670]  So a lot of the traditional IR procedures,
[19:59.670 --> 20:02.630]  they focus around Active Directory, right?
[20:02.630 --> 20:04.550]  So you reset your Active Directory password,
[20:04.550 --> 20:06.270]  you lock the Active Directory account.
[20:06.270 --> 20:08.490]  That doesn't necessarily have any triggers
[20:08.490 --> 20:10.450]  to a third-party SSO site.
[20:10.450 --> 20:13.990]  So if it's Okta or another provider,
[20:13.990 --> 20:15.510]  there's no link to Active Directory
[20:15.510 --> 20:17.590]  that necessitates a token refresh
[20:17.590 --> 20:19.030]  or a deletion of all the tokens
[20:19.030 --> 20:23.590]  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:33.450]  The SID token, this is specific to Okta,
[20:33.450 --> 20:37.470]  but basically, after the user had authenticated
[20:37.470 --> 20:39.730]  to our Evogenics,
[20:39.730 --> 20:42.290]  and then they had pretty much realized,
[20:42.290 --> 20:43.790]  you know, okay, that's not great.
[20:43.790 --> 20:47.330]  But we were actually able to use that token
[20:47.330 --> 20:50.870]  to access their Okta portal, basically,
[20:50.870 --> 20:52.750]  which had access to, you know,
[20:52.750 --> 20:55.070]  not only all their other third-party apps,
[20:55.070 --> 20:57.890]  but also VPN or other similar,
[20:58.850 --> 21:01.970]  you know, higher security context things,
[21:01.970 --> 21:04.610]  which potentially could yield to a foothold.
[21:07.410 --> 21:10.190]  So, you know, before I cover breaking and detaching,
[21:10.190 --> 21:11.010]  last thing I want to mention,
[21:11.010 --> 21:12.370]  just if you're a red teamer,
[21:12.370 --> 21:13.730]  next time you get a token,
[21:13.730 --> 21:16.670]  or if you do phish a user with that,
[21:16.670 --> 21:19.610]  you know, Evogenics or another solution,
[21:19.610 --> 21:21.230]  do what you would do with a credential
[21:21.230 --> 21:24.330]  and actually do stuffing.
[21:24.330 --> 21:26.490]  You know, try to use that API token
[21:26.490 --> 21:29.550]  across as many different applications as you can,
[21:29.550 --> 21:31.310]  and you might be surprised at how easy it is
[21:31.310 --> 21:34.970]  to just put the token in and then go.
[21:34.970 --> 21:36.670]  I mean, with Okta, for example,
[21:36.670 --> 21:39.470]  you literally just put that SID token in your browser,
[21:39.470 --> 21:41.470]  go to the company's Okta site,
[21:41.470 --> 21:44.390]  and at least at the time that this gig was executed,
[21:44.390 --> 21:45.210]  it worked.
[21:45.210 --> 21:48.710]  There was some JavaScript sub-resource integrity stuff
[21:48.710 --> 21:49.690]  that we had to bypass,
[21:49.690 --> 21:52.490]  but it was, you know,
[21:52.490 --> 21:54.230]  API tokens or Vera tokens,
[21:54.230 --> 21:56.950]  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:06.670]  Like, Okta doesn't have default alerts
[22:06.670 --> 22:09.190]  for geolocation token usage, right?
[22:09.190 --> 22:11.710]  So, you should generate those alerts, right?
[22:11.710 --> 22:14.830]  So, figure out how within your SIEM or whatever
[22:14.830 --> 22:16.790]  to alert on token usage,
[22:16.790 --> 22:18.550]  not just password usage, right?
[22:18.550 --> 22:20.290]  Instead of suspicious login events,
[22:20.290 --> 22:22.010]  maybe look at suspicious token usage
[22:22.010 --> 22:25.170]  or just a session happened to move
[22:25.170 --> 22:27.510]  from this site to this site or whatever,
[22:27.510 --> 22:29.510]  or a different user agent or whatever.
[22:30.530 --> 22:32.110]  And also, build those connectors
[22:32.110 --> 22:33.990]  so that those tokens are automatically reset
[22:33.990 --> 22:36.130]  if the user does change their password.
[22:36.130 --> 22:38.450]  Or, if it's not automatic,
[22:38.450 --> 22:39.630]  build it into a playbook
[22:39.630 --> 22:41.970]  so that your incident response says,
[22:42.090 --> 22:42.910]  a user got phished.
[22:42.910 --> 22:45.130]  Not only do we reset their Active Directory password,
[22:45.130 --> 22:47.850]  but we also reset their Okta tokens
[22:47.850 --> 22:50.650]  or their Office 365 tokens
[22:50.650 --> 22:52.170]  or any kind of tokens.
[22:52.170 --> 22:54.330]  Typically, there are tools within these web portals
[22:54.330 --> 22:57.750]  to actually manually refresh a user's session.
[22:57.810 --> 22:59.430]  So, build that into your IR playbook
[22:59.430 --> 23:01.950]  so that you don't have that token
[23:01.950 --> 23:03.630]  that's been outvalid for 24 hours
[23:03.630 --> 23:05.630]  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:12.950]  So, for example, Evogenics actually has
[23:13.130 --> 23:16.230]  a hard-coded IOC built into it.
[23:17.670 --> 23:19.530]  It's been published on Twitter before.
[23:19.530 --> 23:21.630]  I won't say exactly where it is in the GitHub,
[23:21.630 --> 23:23.310]  but if you're using Evogenics
[23:23.310 --> 23:25.290]  and you haven't forked it and edited it out
[23:25.290 --> 23:27.510]  and removed the IOC from it,
[23:27.510 --> 23:31.310]  it should be easy to be detected, right?
[23:32.690 --> 23:34.810]  Attackers sometimes use off-the-shelf tools
[23:34.810 --> 23:38.130]  like Evogenics, and that's relatively easy
[23:38.130 --> 23:40.950]  as a blue team to download those tools,
[23:40.950 --> 23:43.810]  run them, execute them, and see what that looks like
[23:43.810 --> 23:45.910]  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 --> 23:58.750]  So, we have, on breach engagements,
[23:58.750 --> 24:01.550]  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:21.350]  So, like, if a user is based out on the East Coast
[24:21.350 --> 24:24.590]  and you're using a US West Amazon instance,
[24:24.590 --> 24:27.850]  that could trigger an alert if you sign in as that user
[24:27.850 --> 24:30.270]  and it says, oh, this user just signed in from here
[24:30.270 --> 24:31.810]  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:44.090]  But sometimes we get lazy, we'll reuse the same IP address
[24:44.090 --> 24:46.490]  that we've obtained for multiple accounts, right?
[24:46.490 --> 24:50.290]  So, you know, maybe we log in on that one instance
[24:50.290 --> 24:54.170]  and then we log in as another user just to test those credentials, right?
[24:54.370 --> 24:58.410]  That's an easy indication that not only is it an AWS IP
[24:58.410 --> 25:00.930]  that's authenticating to our VPN,
[25:00.930 --> 25:03.370]  but also they just authenticated as two valid users
[25:03.370 --> 25:06.350]  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:19.730]  So I put some links at the bottom of different services
[25:19.730 --> 25:22.790]  you could use to check the, like, IP reputation
[25:22.790 --> 25:26.950]  or, you know, sort of the footprint of the IP addresses
[25:26.950 --> 25:28.170]  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:43.390]  So if we're going to trigger a valid login as a user,
[25:43.390 --> 25:46.650]  if we're going to actually start that pathway of emulating,
[25:47.270 --> 25:51.790]  that's when we'll say, let's go into it.
[25:51.790 --> 25:55.830]  Let's make this IP address this user's IP address
[25:55.830 --> 26:00.450]  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:08.330]  Obviously, they can still alert on, hey, this is an AWS IP logging in
[26:08.330 --> 26:10.310]  and that shouldn't be the case.
[26:10.310 --> 26:14.230]  But also, they can say, well, they did log in here
[26:14.230 --> 26:17.370]  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:26.510]  Yep. Now we're going to flip over to foothold.
[26:26.550 --> 26:28.330]  And before we kind of go there,
[26:28.330 --> 26:30.670]  let's kind of do a little bit of an explanation.
[26:30.670 --> 26:33.990]  When we talk about, like, initial access versus foothold,
[26:33.990 --> 26:37.530]  we're really kind of differentiating the two kind of concepts
[26:37.530 --> 26:42.210]  of, hey, we were able to get some access through password guessing.
[26:42.210 --> 26:44.530]  It may have given us a small step in,
[26:44.530 --> 26:47.470]  but we're not at the stage where we can, you know,
[26:47.470 --> 26:50.790]  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:05.730]  So in this example, which we're going to kind of talk about,
[27:05.730 --> 27:08.470]  this is actually a runoff of what Corey was just describing
[27:08.470 --> 27:12.070]  with the Okta and SIDS and Tokens.
[27:12.070 --> 27:15.770]  So we were inside their portals
[27:15.770 --> 27:18.270]  and we were able to get access to several different applications
[27:19.150 --> 27:24.450]  because we sent out a phish and one user clicked it.
[27:25.050 --> 27:27.910]  So we had tons of access, but only through their portals,
[27:27.910 --> 27:29.890]  like the tiles and whatever, you know,
[27:29.890 --> 27:32.290]  substant applications that were exposed to the internet.
[27:32.290 --> 27:34.070]  So as we're going through all these different sites
[27:34.070 --> 27:36.250]  and third-party applications,
[27:36.730 --> 27:40.290]  because we had access to the email account,
[27:40.290 --> 27:42.570]  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:50.030]  And what basically it outlined, as you can kind of see right here,
[27:50.030 --> 27:52.610]  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 --> 27:59.030]  I've already changed my password twice,
[27:59.030 --> 28:01.070]  which kind of goes back to what Corey said on how valuable
[28:02.170 --> 28:05.230]  resetting those Okta or, you know, those tokens and SIDs are,
[28:05.230 --> 28:07.690]  because at the end of the day, we didn't need,
[28:07.690 --> 28:10.610]  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:19.850]  So our Spearfish email, as well as the, you know,
[28:19.850 --> 28:23.810]  security alert of sign-on that we had triggered by logging into an application
[28:23.810 --> 28:27.730]  that we weren't aware of had like that notification prompt built into it.
[28:27.750 --> 28:29.770]  We were just pillaging through the data,
[28:29.770 --> 28:33.230]  trying to get as much information we can to help kind of solidify our next stage
[28:33.230 --> 28:34.730]  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:51.070]  So going back to my initial thing with the story about the building,
[28:51.070 --> 28:52.510]  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:01.890]  And within a few seconds, because good old help desk,
[29:01.890 --> 29:04.550]  they closed the ticket instantly with a nice little message saying, hey,
[29:04.550 --> 29:06.770]  don't worry about it, I'm glad you were able to be assisted,
[29:06.770 --> 29:08.130]  if you have any other questions.
[29:08.530 --> 29:12.390]  And we also took an additional step by actually adding a mail rule
[29:12.390 --> 29:17.130]  that any type of emails that were related to this help desk ticket
[29:17.130 --> 29:20.590]  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:26.790]  With all of this, we were able to then kind of do a comprehensive
[29:26.790 --> 29:28.430]  internal Spearfish.
[29:28.430 --> 29:32.450]  Starting on a couple of the employees that reported to this user
[29:33.610 --> 29:36.970]  with a typical great macro document.
[29:36.970 --> 29:39.910]  It was an Excel timesheet that they actually had been passing around,
[29:39.910 --> 29:41.590]  all the staff passed around.
[29:41.830 --> 29:44.270]  And we basically just added a few verbiage saying, hey,
[29:44.270 --> 29:46.930]  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:53.850]  And we sent that out, and with maybe half an hour, an hour,
[29:53.850 --> 29:56.970]  we received our good trusty beacon.
[29:57.630 --> 29:59.690]  We love to see those come in.
[29:59.830 --> 30:03.450]  So that was a great example of how just because something happens,
[30:03.610 --> 30:08.050]  a ripple in the whole environment is kind of created,
[30:08.050 --> 30:09.770]  they can't always be a wave.
[30:09.770 --> 30:11.790]  And if you know how to handle and deescalate,
[30:11.790 --> 30:14.170]  you can take that ripple and make it invisible.
[30:14.370 --> 30:16.070]  If you don't, you leave it there too long,
[30:16.070 --> 30:17.350]  or you don't handle it properly,
[30:17.350 --> 30:20.090]  you can definitely make that ripple into a giant wave.
[30:20.310 --> 30:23.330]  And now instant responders are investigating,
[30:23.330 --> 30:24.690]  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:42.290]  One of the biggest things we've seen, and you can kind of take from the story,
[30:42.290 --> 30:44.450]  is that training.
[30:44.450 --> 30:47.830]  It actually turned out after when we did a debrief with the client,
[30:47.830 --> 30:51.770]  that the client actually had a separate portal for incidences.
[30:51.770 --> 30:53.750]  So helpdesk handled the day-to-day issues,
[30:53.750 --> 30:56.910]  I can't log in, my password, those types of issues.
[30:56.910 --> 30:58.990]  But there was a whole separate portal for like,
[30:58.990 --> 31:02.390]  hey, I think I've been spearfished, something's weird, I'm seeing something.
[31:02.750 --> 31:05.930]  And because they put that ticket in the helpdesk,
[31:05.930 --> 31:08.030]  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:15.670]  This user provided a lot of data, and then all of a sudden, deleted, deleted,
[31:15.670 --> 31:16.830]  and saying, my bad.
[31:16.890 --> 31:18.950]  If you read that thing, it kind of looked like this person
[31:18.950 --> 31:20.630]  was two different people talking.
[31:20.790 --> 31:22.910]  But their SLAs and everything like that,
[31:22.910 --> 31:26.830]  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:30.750]  We always talk about indicators of compromise,
[31:30.750 --> 31:32.710]  but there's indicators of anomalous.
[31:32.910 --> 31:36.510]  And if you can stay and live in those indicators of anomalous,
[31:36.510 --> 31:39.930]  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:48.270]  Don't just call the helpdesk. Helpdesk is not security, so to speak.
[31:48.570 --> 31:52.290]  And then kind of really focusing on when you get those types of events,
[31:52.290 --> 31:55.130]  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:10.030]  Putting in a ticket is great, you have all the evidence there,
[32:10.030 --> 32:11.350]  but following up with a phone call saying,
[32:11.350 --> 32:13.910]  hey, I'm really worried something happened.
[32:13.970 --> 32:16.310]  You have someone on the phone now, you're talking to someone,
[32:16.310 --> 32:19.750]  or you go in the office, you can find them.
[32:19.850 --> 32:22.570]  Talking, being in person, it changes the level of severity
[32:22.570 --> 32:24.790]  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:32.130]  And that really can change the amount of time we have as an attacker
[32:32.130 --> 32:33.730]  to be successful.
[32:33.730 --> 32:36.290]  And just by de-escalating, we had enough time to figure out
[32:36.410 --> 32:39.810]  a good, convincing internal spearfish, which we love to do,
[32:39.810 --> 32:43.030]  because you're bypassing all those mail filter controls.
[32:43.030 --> 32:46.190]  We looked at them and saw, oh, all the users are passing
[32:46.190 --> 32:49.390]  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:05.130]  All Red Teamers should probably know this, but putting all your eggs
[33:05.130 --> 33:08.510]  in one basket is bad.
[33:09.370 --> 33:12.210]  Sometimes, even the best tools are buggy.
[33:12.210 --> 33:16.730]  We use Cobalt Strike. It's a great tool, it's very powerful,
[33:16.730 --> 33:18.870]  but obviously, it's not perfect.
[33:18.990 --> 33:23.130]  This was at a time when, basically, this was right before
[33:23.130 --> 33:28.330]  the Cobalt Strike 4.0 release, and there was a bug in execute assembly
[33:28.330 --> 33:33.650]  at one point, where if you executed anything in execute assembly,
[33:33.650 --> 33:35.090]  it would crash the beacon.
[33:36.210 --> 33:39.270]  So, you know, the little screenshot's kind of funny,
[33:39.270 --> 33:43.110]  but I'm sitting there, and I run, you know, I had worked really hard,
[33:43.110 --> 33:47.150]  and I had done all my Red Team things, and I finally got this beacon.
[33:47.650 --> 33:50.230]  And I was like, all right, I've been working really hard,
[33:50.230 --> 33:53.810]  I should use this, I should take this opportunity, seize the moment,
[33:53.810 --> 33:57.130]  and really go and do all my, you know, do my reconnaissance,
[33:57.130 --> 34:00.550]  do my situational awareness, and try to move laterally, etc.
[34:02.690 --> 34:08.870]  So the downside of that is I didn't really think about, you know,
[34:08.870 --> 34:12.890]  the presence of that bug, and also how much I was relying
[34:12.890 --> 34:15.990]  on that single beacon. So luckily, I did set up persistence
[34:15.990 --> 34:19.270]  before I executed that, so it came back the next day
[34:19.270 --> 34:23.430]  when that user logged in, but it was a long 24-hour period
[34:23.430 --> 34:26.870]  of basically waiting and saying, I shouldn't have done that,
[34:26.870 --> 34:29.930]  I shouldn't have executed that, you know, it was kind of a kick yourself
[34:29.930 --> 34:32.990]  moment when you just potentially burned a couple weeks of work
[34:32.990 --> 34:36.830]  just because you got excited when that beacon came in.
[34:36.950 --> 34:41.330]  So I guess the takeaway here is, if you are, you know,
[34:41.330 --> 34:45.610]  once you finally land that shell or that foothold,
[34:45.610 --> 34:48.810]  don't necessarily go and use it immediately.
[34:48.810 --> 34:51.750]  Maybe take some time, just exist in the environment,
[34:51.750 --> 34:54.710]  gather some information, listen passively, etc.
[34:55.310 --> 34:59.250]  And then maybe establish a backup C2 or another foothold
[34:59.250 --> 35:02.430]  before you start executing higher impact actions, right?
[35:02.430 --> 35:05.370]  So start out as low and slow as you possibly can, and then
[35:05.370 --> 35:08.710]  ramp it up as time goes on instead of having your automation
[35:08.710 --> 35:12.010]  and everything ready to go for that initial beacon to go.
[35:12.010 --> 35:16.470]  Maybe let it persist and just sort of blend in
[35:16.470 --> 35:18.810]  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:25.250]  So we didn't put a lateral movement overview slide
[35:25.250 --> 35:27.650]  because, you know, it would have been like 20 slides
[35:27.650 --> 35:29.710]  of what lateral movement is, right?
[35:30.250 --> 35:33.010]  It's something different to everyone else,
[35:33.010 --> 35:39.810]  but basically lateral movement is establishing more pieces
[35:40.330 --> 35:43.390]  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:50.370]  Basically, this scenario is what we like to call
[35:50.370 --> 35:51.770]  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:16.830]  So, you know, user agents, for example,
[36:16.830 --> 36:19.250]  if you are using PowerShell and the environment
[36:19.250 --> 36:22.230]  doesn't use any PowerShell, it's a classic example, right?
[36:22.270 --> 36:24.630]  If they don't use PowerShell and you do,
[36:24.630 --> 36:26.710]  then now you're standing out from the baseline.
[36:27.950 --> 36:31.010]  And typically, you know, this has been, you know,
[36:31.010 --> 36:33.810]  there's wall bins and etc., but living off the land
[36:33.810 --> 36:36.850]  or blending in is probably the best way to go
[36:36.850 --> 36:38.210]  if you're red teaming, right?
[36:38.210 --> 36:41.490]  It's harder to catch someone who's using the same tools
[36:41.490 --> 36:43.750]  as every other user in the environment.
[36:44.950 --> 36:47.530]  So this is a scenario where, basically,
[36:47.530 --> 36:51.630]  we had a limited foothold, so we had that C2 access.
[36:52.030 --> 36:55.010]  We had credentials, so we had plain text credentials
[36:55.010 --> 36:56.150]  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:09.810]  But, you know, we looked at our group memberships,
[37:09.810 --> 37:13.210]  and we saw one of those group memberships is Citrix, right?
[37:13.210 --> 37:15.950]  So instead of, you know, oh, let's move LIDAR,
[37:15.950 --> 37:18.670]  let's run ImpactKit, or let's run CME or Bloodhound
[37:18.670 --> 37:22.150]  or whatever, you know, let's just log in to Citrix
[37:22.150 --> 37:23.310]  and see what's in there, right?
[37:23.310 --> 37:25.870]  Not only is there potential footholds there if they have access
[37:25.870 --> 37:29.030]  to Citrix desktops, but also, you know,
[37:29.030 --> 37:30.270]  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:38.350]  So we logged in, and essentially this, you know,
[37:38.350 --> 37:40.930]  everything's censored because it's client stuff,
[37:40.930 --> 37:43.010]  but basically this was a SCADA environment
[37:43.010 --> 37:46.290]  that we basically had direct access to monitor
[37:47.010 --> 37:49.650]  a lot of their high-sensitivity SCADA applications
[37:49.650 --> 37:52.170]  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:57.170]  All we did was proxy our traffic through our beacon
[37:57.170 --> 37:58.790]  and then just log in.
[37:59.310 --> 38:02.050]  So that's... and that's... they didn't detect it
[38:02.050 --> 38:04.690]  because that's very difficult to detect a normal user
[38:04.690 --> 38:07.970]  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:18.830]  Yes. So this was an engagement where we were dwelling
[38:18.830 --> 38:21.550]  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:26.590]  As you can kind of see from our maps,
[38:26.590 --> 38:28.290]  we had a lot of access.
[38:28.290 --> 38:30.710]  We had basically been able to move through,
[38:30.710 --> 38:32.230]  basically compromise.
[38:32.230 --> 38:34.430]  In fact, at one point we became the security team,
[38:34.430 --> 38:36.870]  which was a key part of this story.
[38:36.870 --> 38:39.730]  So as we're moving laterally through the environment,
[38:39.730 --> 38:42.330]  there were lots of TOIs, targets of interest,
[38:42.330 --> 38:44.870]  that the client had set up for us to compromise.
[38:45.390 --> 38:48.470]  Kind of, hey, once you're in, it's not just,
[38:48.470 --> 38:50.950]  hey, get domain admin, that's like the easy, cool thing,
[38:50.950 --> 38:53.150]  but show that impact, that value.
[38:53.410 --> 38:55.890]  That'd be like, you know, decrypt credit cards,
[38:55.890 --> 38:59.130]  access our secret sauce that's stored on this network,
[38:59.130 --> 39:01.790]  you know, access data, all the sorts of things
[39:01.790 --> 39:04.490]  that can really show like, oh my God, we have been hacked
[39:04.490 --> 39:06.830]  and our data, our business critical stuff
[39:07.370 --> 39:09.670]  has been compromised, like that integrity.
[39:11.370 --> 39:13.610]  So how we actually managed to establish
[39:14.190 --> 39:17.650]  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:20.710]  We hadn't really used this account yet,
[39:20.710 --> 39:22.190]  because for most of the port as we're moving,
[39:22.190 --> 39:24.510]  we were able to simulate using different users,
[39:24.510 --> 39:26.330]  jumping to various jump boxes,
[39:26.330 --> 39:28.990]  or getting to different systems, kind of blending in.
[39:28.990 --> 39:34.430]  And one of the goals was to get access to shipping manifest
[39:34.430 --> 39:37.790]  and all this type of very powerful information
[39:37.790 --> 39:40.350]  related to SKUs and all that stuff.
[39:40.750 --> 39:45.590]  So, unfortunately, we couldn't get onto any of the user's machines
[39:45.590 --> 39:47.270]  because they were in a different environment.
[39:47.270 --> 39:48.630]  They were in like a subdomain,
[39:48.630 --> 39:52.310]  but the domain admin account actually had privileges,
[39:52.310 --> 39:55.690]  and it was actually still an administrative privilege level set,
[39:55.690 --> 39:58.130]  high integrity on those boxes.
[39:58.130 --> 40:02.090]  So we were able to authenticate as this domain administrator
[40:02.090 --> 40:05.630]  on one of the warehouse's computers.
[40:06.090 --> 40:08.130]  Well, that was where it was kind of getting weird,
[40:08.130 --> 40:13.550]  because the account was designed as a backup account for TVs and stuff.
[40:13.830 --> 40:15.310]  And eventually, like I kind of said,
[40:15.310 --> 40:18.290]  we were in the security IT guy's chat room.
[40:18.290 --> 40:21.570]  That's actually the Malware War Room Council,
[40:21.570 --> 40:22.710]  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:30.950]  So as they were going back through and knocking down our beacons,
[40:30.950 --> 40:33.790]  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:39.150]  We still had access in the environment,
[40:39.150 --> 40:41.590]  but we had to start all the way back from square one.
[40:41.590 --> 40:43.710]  And why this is one we like to talk about,
[40:43.710 --> 40:47.110]  especially when we're kind of going through any type of our debriefs
[40:47.110 --> 40:50.050]  internally and stuff is, you know, DA is cool and stuff,
[40:50.050 --> 40:53.170]  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:00.810]  They have a lot of controls around,
[41:00.810 --> 41:03.690]  but you can do a lot with like other types of accounts.
[41:03.690 --> 41:07.210]  Like I kind of said, IT security guys, admins,
[41:07.210 --> 41:10.970]  they have a lot of the same access that a domain administrator.
[41:11.510 --> 41:13.670]  And oftentimes when we look at this,
[41:13.670 --> 41:15.670]  like these types of goals and end results,
[41:15.670 --> 41:18.010]  like maybe compromise an application,
[41:18.010 --> 41:19.970]  get access to the database behind it,
[41:19.970 --> 41:22.530]  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:40.170]  Is there value to it? Like, you know, it might be an easy skeleton key,
[41:40.170 --> 41:44.170]  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:48.910]  We pretty much, we were in over 50 boxes
[41:48.910 --> 41:50.550]  moving through different environments
[41:50.930 --> 41:53.290]  and we had to go all the way back to square one.
[41:55.850 --> 42:00.290]  So breaking this chain, it really comes down to baselining
[42:00.290 --> 42:02.870]  and understanding your environment.
[42:03.110 --> 42:05.950]  There's a great term called least frequency.
[42:05.950 --> 42:08.210]  If you're not familiar with it, the concept is that
[42:08.710 --> 42:11.030]  if you're baselining to the point where you know your environment,
[42:11.030 --> 42:13.370]  you know, like what user agents everyone uses,
[42:13.370 --> 42:15.810]  you know, your Google Chrome or a Firefox shop,
[42:15.810 --> 42:17.990]  all those types of things, that's your baseline.
[42:17.990 --> 42:21.610]  Everything's going to be the same until you see some differences,
[42:21.610 --> 42:25.050]  like Internet Explorer user agent stuff.
[42:25.050 --> 42:28.150]  And those are the least frequent objects or events
[42:28.150 --> 42:30.730]  that now you can drill into, well, why did that happen?
[42:30.730 --> 42:33.650]  If everything else is standard operating procedure,
[42:33.650 --> 42:36.490]  you've seen this for day in, day out for like three or four years,
[42:36.490 --> 42:38.630]  and then you see this one event for the first time,
[42:38.630 --> 42:41.230]  you kind of can shuffle all that stuff off to the side
[42:41.230 --> 42:44.230]  and focus in on those few unique new events.
[42:44.230 --> 42:47.650]  May not be malicious right away, but you can start digging
[42:47.650 --> 42:50.830]  and that's how you can make this large cloud of noise,
[42:50.830 --> 42:54.430]  something smaller and easier for your team to handle and manage.
[42:55.250 --> 42:56.810]  But when it comes down to lateral movement,
[42:56.810 --> 43:00.790]  the great tips we often recommend are, you know, auditing your ACLs,
[43:00.790 --> 43:03.930]  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:13.690]  One of the issues was there were so many unnecessary privileges
[43:13.690 --> 43:15.930]  that gave us hops, skips, and jumps in the environment
[43:15.930 --> 43:17.710]  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:34.270]  Essentially, what it does is it prevents the remote call to net session in Noom,
[43:34.270 --> 43:37.190]  which if anyone's familiar with, that's how most great tools
[43:37.190 --> 43:42.250]  that are out there on GitHub or in the hacker space get all that,
[43:42.250 --> 43:44.050]  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:54.730]  It doesn't matter your privileges, but if you're remote to a box,
[43:54.730 --> 43:57.650]  it can only be certain ones rather than what's default,
[43:57.650 --> 43:59.810]  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:07.430]  And with that patch and that little registry change,
[44:07.430 --> 44:09.230]  which can be pushed out through group policy,
[44:09.230 --> 44:11.610]  it really does hamper your ability to see,
[44:11.610 --> 44:13.990]  oh, I need to be user X and I'm user Y,
[44:13.990 --> 44:15.890]  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:28.490]  Also, making sure, you know, privilege accounts are protected,
[44:28.490 --> 44:30.110]  you know, there are protected user groups
[44:30.110 --> 44:33.830]  or credential delineations and delegations.
[44:33.830 --> 44:35.710]  Make sure that, you know, you're not...
[44:35.710 --> 44:38.030]  if someone logs in a service account or something like that,
[44:38.030 --> 44:39.690]  they're not just stale, sitting in memory,
[44:39.690 --> 44:41.130]  or they're not just easily available.
[44:41.130 --> 44:43.590]  Really kind of protecting the actual sensitive
[44:43.590 --> 44:45.790]  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 --> 44:57.190]  There's great techniques or something like that,
[44:57.190 --> 44:59.490]  but whenever you hear about a new one on Twitter
[44:59.490 --> 45:01.350]  or there's an article, most of the time,
[45:01.350 --> 45:03.230]  people pay attention because they really get scared,
[45:03.230 --> 45:05.410]  and that's, like, the focus of patching,
[45:05.410 --> 45:07.070]  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:11.890]  And it really comes down to, like, you know,
[45:11.890 --> 45:14.950]  you could go that crazy route that they might have it patched,
[45:14.950 --> 45:18.950]  but if, say, your payload or whatever, you know, binary, DLL,
[45:18.950 --> 45:21.570]  whatever you want to have it, can persist on disk,
[45:21.570 --> 45:22.610]  or it stays on disk.
[45:22.610 --> 45:26.330]  It could be somewhere in, like, you know, the user app data,
[45:26.330 --> 45:27.370]  temp folder, something like that,
[45:27.370 --> 45:31.150]  and whatever security appliance is just not alerting on it,
[45:31.150 --> 45:34.150]  if you have, say, you know, a bat file or something
[45:34.150 --> 45:39.270]  where it drops into a start follow of a user and calls it,
[45:39.270 --> 45:40.730]  it's probably not going to get detected
[45:40.730 --> 45:43.130]  if it looks right telling that story again.
[45:43.130 --> 45:46.530]  So in one of the scenarios we did,
[45:46.530 --> 45:48.310]  we were persisting on multiple different machines,
[45:48.310 --> 45:51.570]  and what we ended up doing was just dropping a bat file
[45:51.570 --> 45:55.610]  that would call gpupdate.exe, but our binary,
[45:55.610 --> 45:57.770]  our evil binary was gpupdate.exe,
[45:57.770 --> 45:59.330]  because it was obviously putting app data.
[45:59.530 --> 46:02.270]  So when you looked at it, strictly from the point,
[46:02.270 --> 46:05.690]  oh, the process, you know, the binary gpupdate started up
[46:05.690 --> 46:08.930]  when the user kind of logged in, and it wasn't as suspicious.
[46:08.930 --> 46:11.330]  I mean, if you drilled in, you would have seen,
[46:11.330 --> 46:15.950]  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:20.950]  And one of the great things about that is that
[46:20.950 --> 46:23.850]  if they're looking at things like what this file is,
[46:23.850 --> 46:25.630]  there's something else that's already kind of dragged
[46:25.630 --> 46:28.570]  their attention towards it, so you're already kind of burnt.
[46:28.650 --> 46:32.390]  But just staying pretty low, making tiny ripples,
[46:32.390 --> 46:34.930]  you hang around that, you know, indicators of anomalous.
[46:34.930 --> 46:37.070]  If someone looked at it, they probably wouldn't blink twice
[46:37.070 --> 46:41.010]  until they looked at the file path or other attributes of the file.
[46:43.070 --> 46:46.590]  And now it comes down to, I think this is one of our favorite ones
[46:46.590 --> 46:49.450]  to talk about, is conference rooms.
[46:50.750 --> 46:54.490]  So we were on an engagement that was getting close to the end,
[46:54.990 --> 46:57.630]  and it was very late when we had managed to finally get through,
[46:57.630 --> 46:58.890]  and we really wanted to establish persistence
[46:58.890 --> 47:00.970]  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:08.190]  So it's very late at night. Okay, perfect.
[47:08.490 --> 47:12.550]  So we decided, okay, we know what their conference room systems are.
[47:12.550 --> 47:16.890]  So we put a beacon with persistence on it, thinking, you know,
[47:16.890 --> 47:19.730]  no one's going to look at them. 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:26.930]  And let's be honest, no one's going to come in over the weekend
[47:26.930 --> 47:29.010]  and use the conference room machines.
[47:29.030 --> 47:30.890]  But it was a pretty solid idea.
[47:30.890 --> 47:36.110]  What actually happened was their SOC was like,
[47:36.610 --> 47:40.470]  why is there traffic coming from the conference rooms at 2 a.m.?
[47:40.470 --> 47:43.070]  Like, what? Is someone using these?
[47:43.350 --> 47:48.330]  And that in itself was actually louder than anything we had done previously
[47:48.330 --> 47:52.370]  to get in because it didn't make sense why these conference rooms
[47:52.370 --> 47:56.030]  every so often would call out to the internet and stuff like that.
[47:56.030 --> 47:58.530]  And that really was kind of like the problem was
[47:58.970 --> 48:01.830]  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:17.010]  Our traffic baseline is that, you know, 8 a.m. to 5 p.m. is a lot.
[48:17.010 --> 48:20.550]  And then afterwards, it's a little. 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:33.730]  Like, that's so low of an indicator that there's nothing you can really mask
[48:33.730 --> 48:36.030]  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:45.650]  There's no, like, silver bullet that if you do this,
[48:45.650 --> 48:47.790]  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 --> 49:00.030]  It really comes down to how are you monitoring? 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:18.690]  And looking around, like, file locations, you know, the ones that hackers love to use,
[49:18.690 --> 49:23.270]  you know, all those, looking for things that are spawning from there or starting up there,
[49:23.270 --> 49:26.610]  that will give you a huge indication, like, nine times out of ten,
[49:26.610 --> 49:31.850]  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:40.190]  Looking at those things, if you can drill down that precise,
[49:40.190 --> 49:43.870]  you have a very mature environment and a very mature way of handling instances
[49:43.870 --> 49:48.030]  that's going to make any, like, challenge, red teamers job a lot harder.
[49:49.450 --> 49:53.450]  Also, application whitelisting is your friend. It's not ours.
[49:53.670 --> 49:57.190]  When we're on a box, whatever way, you know, might be in Excel,
[49:57.550 --> 50:00.690]  Word documents that bypass that, but, like, trying to get persistence,
[50:00.690 --> 50:04.830]  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:12.790]  And then making sure whatever we're trying to slingshot through,
[50:13.270 --> 50:16.830]  that's not, you know, being caught in any of those chains to get to the nasty
[50:16.830 --> 50:20.610]  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:27.090]  It can just be a nightmare. By the time we get it all figured out,
[50:27.090 --> 50:29.750]  you know, we've persisted too long, not moving.
[50:30.850 --> 50:33.710]  So it's definitely a key thing to definitely keep up monitoring
[50:33.710 --> 50:36.810]  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:45.030]  All right. 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 --> 51:00.410]  We, you know, custom stuff is great. We experiment with it quite a bit.
[51:00.410 --> 51:05.270]  But if it comes down to we have one shot, we have one, you know, DLL or one EXE
[51:05.270 --> 51:09.130]  that we're going to do, which C2 do you want to use, right?
[51:09.130 --> 51:12.930]  We're going to, if it comes down to a choice like that,
[51:12.930 --> 51:15.390]  we're going to make the choice of the most reliable tool, right?
[51:15.390 --> 51:19.790]  So oftentimes that can be easier for blue teams to identify
[51:19.790 --> 51:25.310]  because the tool set is shrinking as you're relying on more well-developed
[51:25.310 --> 51:26.790]  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:35.890]  So as, you know, as cool as it is to have four or five different footholds
[51:35.890 --> 51:40.210]  that are totally unrelated, different C2, different initial compromise,
[51:40.210 --> 51:42.890]  different physical locations, that's great.
[51:42.890 --> 51:45.190]  But the reality is we're, you know, we're red teamers,
[51:45.190 --> 51:49.130]  so we're doing this in a condensed timeframe with restrictions
[51:49.130 --> 51:50.930]  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 --> 51:57.290]  And along the way, all those chain breaks that we described
[51:57.290 --> 52:00.750]  are ways that would just basically send us back to square one
[52:00.750 --> 52:04.670]  where we'd have to start over and say, we did this, this, and this.
[52:04.670 --> 52:09.330]  However, they had this security control or they caught us or whatever,
[52:09.330 --> 52:11.050]  and now we have to start over.
[52:11.050 --> 52:14.550]  So it's actually, you know, it's... the chains are more fragile
[52:14.550 --> 52:15.910]  than they might appear.
[52:16.710 --> 52:20.150]  Users who report incidents are honestly one of the things that comes up
[52:20.150 --> 52:24.090]  more than we'd like it to because there's really nothing we can do
[52:24.090 --> 52:25.250]  to stop it, right?
[52:25.250 --> 52:29.150]  We can't stop users from emailing their security team and saying,
[52:29.150 --> 52:30.370]  hey, this looks weird.
[52:30.930 --> 52:35.530]  Obviously, we showed an example of how we can do anti-evasive maneuvers
[52:35.530 --> 52:38.590]  and say, oh, actually, never mind, my mistake.
[52:38.590 --> 52:40.570]  But if someone's going to pick up the phone and call a user
[52:40.570 --> 52:44.150]  or if the user picks up the phone and calls up security people,
[52:44.150 --> 52:45.910]  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:50.950]  So that's where that security awareness training and just relying
[52:50.950 --> 52:54.670]  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:16.650]  Every step along the way gets harder when you have, oh, well, we got a foothold,
[53:16.650 --> 53:18.970]  but now they have all these really strong local firewalls,
[53:18.970 --> 53:24.150]  so we can't move laterally as easily because everything's blocked
[53:24.150 --> 53:25.150]  to everything else, right?
[53:25.150 --> 53:26.930]  That's an example of defense in depth.
[53:27.650 --> 53:29.590]  That's not protecting you from spear phishing,
[53:29.590 --> 53:33.190]  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:00.550]  We highly recommend, you know, modern tools, proper configurations,
[54:00.550 --> 54:03.850]  but they're kind of useless if you just buy them in an audit mode.
[54:04.550 --> 54:08.950]  And that's what we kind of see a lot is, is the deployment that they're not,
[54:08.950 --> 54:12.850]  you know, you might have the greatest security stack of 20 different products.
[54:12.850 --> 54:16.350]  You might have 14 different ADR agents on there,
[54:16.350 --> 54:20.130]  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:34.190]  We're going to live in this gap and we're going to try to move as much as we can in there
[54:34.190 --> 54:36.470]  because you guys don't have any visibility. We know that.
[54:36.810 --> 54:41.170]  So if we know that, you know, hey, you guys are monitoring PowerShell,
[54:41.170 --> 54:46.030]  but you know, we can use C sharp or hey, we can, you know,
[54:46.030 --> 54:49.010]  you guys have great lockdown for a lot of stuff, but macros are really easy.
[54:49.010 --> 54:52.570]  We could use macros. We can use water hole attacks, you know, set up.
[54:52.570 --> 54:56.670]  In fact, hey guys, you know, your ADR is only set up to detect, you know,
[54:56.670 --> 54:59.890]  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:06.090]  And that's where really tuning and tightening up can really make a huge difference
[55:06.090 --> 55:08.270]  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:14.010]  We often see the latest and greatest, you know,
[55:14.010 --> 55:17.770]  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:25.690]  So someone's not looking at the dashboard. 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:36.710]  And that's where like hiring, you know, red team sims
[55:36.710 --> 55:38.750]  or doing those types of engagements.
[55:38.750 --> 55:42.390]  So that way you can see what's out there, understand what, you know,
[55:42.390 --> 55:44.830]  people are doing and seeing where those gaps are in your product.
[55:44.830 --> 55:48.510]  That's highly valuable than just, hey, I'm going to buy a product
[55:48.510 --> 55:50.970]  and just, you know, plug a few buttons on it
[55:50.970 --> 55:52.830]  and hope that I got everything right.
[55:53.050 --> 55:55.950]  Really having it go through those trials and stuff
[55:55.950 --> 55:59.010]  in a live fire engagement is going to help you guys more than anything.
[56:01.270 --> 56:03.910]  Also, we know this, and this is probably going to be
[56:03.910 --> 56:06.110]  one of the most frequent questions asked.
[56:06.110 --> 56:09.290]  You know, well, if we do all this stuff, then, you know,
[56:09.290 --> 56:11.150]  it's not usable for my environment.
[56:11.150 --> 56:13.910]  You know, users can't log in as easy or they can't do things
[56:13.910 --> 56:16.110]  that they used to do as quickly and stuff.
[56:16.110 --> 56:17.690]  And now they're going to complain that they're affecting
[56:17.690 --> 56:20.210]  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:25.450]  But, you know, it's that type, it's a hard conversation
[56:25.450 --> 56:27.590]  you have to have with the business about, you know,
[56:27.590 --> 56:30.170]  you have to change the way you guys have been using stuff
[56:30.170 --> 56:31.710]  to make it more secure.
[56:31.930 --> 56:33.090]  It's very hard.
[56:33.090 --> 56:36.210]  I mean, I don't envy anyone who has to deal with those conversations
[56:36.210 --> 56:39.450]  on a daily basis, but it's necessary to have.
[56:40.010 --> 56:42.650]  And I think if you approach it properly,
[56:42.650 --> 56:45.150]  and with a lot of, you know, information and guidance
[56:45.150 --> 56:47.930]  and recommendations, even from third parties,
[56:47.930 --> 56:50.390]  you can definitely get a lot of value out of that.
[56:50.430 --> 56:52.330]  And the last thing, of course, we've mentioned
[56:52.330 --> 56:54.170]  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:01.970]  If you do, that's the biggest thing from our red teaming experience
[57:01.970 --> 57:04.770]  that has killed us or stopped us dead in the water
[57:04.770 --> 57:09.070]  is if you can baseline and discern us from the rest
[57:09.070 --> 57:11.670]  of your normal traffic, even if we're logging in through RDP
[57:11.670 --> 57:13.670]  and we're using all the same stuff you're normally using,
[57:13.670 --> 57:17.510]  if you can find out that we're not who we're pretending to be,
[57:17.510 --> 57:19.850]  you're going to have a lot better success right then
[57:19.850 --> 57:22.290]  if you do anything that I just described.
[57:22.290 --> 57:23.670]  Baselining is probably the biggest key,
[57:23.670 --> 57:25.870]  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:33.910]  Get really in tune. Get very close to it.
[57:33.910 --> 57:35.790]  Get unnecessarily close to it.
[57:35.790 --> 57:37.730]  And with that knowledge, you'll definitely be able
[57:37.730 --> 57:39.590]  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:56.950]  We're both in there, and we can try to answer some questions
[57:56.950 --> 57:59.890]  in real time before we wrap up.
[57:59.890 --> 58:03.770]  You can hit us up on Keybase or Twitter if you have any questions
[58:03.770 --> 58:05.350]  or just want to chat. We're always available.
[58:05.350 --> 58:08.510]  We love picking other teams or other people's brains
[58:08.510 --> 58:12.770]  in the industry, so definitely hit us up if you ever have a question.
[58:13.710 --> 58:15.870]  Other than that, I just want to say thank you
[58:15.870 --> 58:18.710]  to the Red Team Village for letting us speak today,
[58:18.710 --> 58:20.730]  and thank you guys for showing up for our talk.