[00:01.310 --> 00:08.510]  Today, we're going to be talking a little bit about some RDP attacks and specifically how MFA ties into all this whole shindig.
[00:08.730 --> 00:12.310]  So, of course, the name of this is RDP Spray and Prey.
[00:12.410 --> 00:20.390]  We got some research on modern RDP attacks, MFA compromise, and something that wasn't mentioned in the program, which is AI and machine learning training.
[00:20.630 --> 00:22.470]  No, I didn't just add that in last second.
[00:22.650 --> 00:24.270]  It is actually a very big part of my work.
[00:25.070 --> 00:29.050]  It's just something that I figured would kind of take away from the point.
[00:29.050 --> 00:31.810]  So, please get her done.
[00:33.250 --> 00:35.850]  Once I can figure out where my mouse is.
[00:36.050 --> 00:36.590]  Oh my god.
[00:37.190 --> 00:37.770]  Oh no.
[00:37.990 --> 00:38.310]  There we go.
[00:43.540 --> 00:44.020]  Alright.
[00:44.020 --> 00:45.880]  So, first, who am I?
[00:46.120 --> 00:46.980]  Hi, that's me.
[00:47.980 --> 00:49.160]  I am Tess.
[00:49.320 --> 00:50.260]  It's nice to meet you.
[00:50.680 --> 00:53.500]  I am also known as Killer Bunny on the onlines.
[00:54.620 --> 00:57.920]  I am an amateur radio enthusiast, first and foremost.
[00:57.920 --> 01:00.040]  We're getting the hobbies out of the way because they're more interesting.
[01:01.360 --> 01:02.560]  Yes, I am a general license.
[01:02.720 --> 01:03.500]  Yes, I'm proud of it.
[01:04.500 --> 01:07.620]  In the past, I was a threat hunter and an intel analyst.
[01:07.780 --> 01:08.840]  Yes, that counts as a hobby.
[01:10.140 --> 01:12.440]  I also am a malware analysis enthusiast.
[01:12.560 --> 01:15.460]  That was not a job, but it is something that I do when I get the time.
[01:16.360 --> 01:18.440]  And yes, I am an enjoyer of numbers.
[01:18.440 --> 01:19.920]  I am a writer of reports.
[01:19.920 --> 01:23.780]  You can find a lot of my work, of course, online.
[01:24.800 --> 01:32.040]  Mostly, it was stuff for Red Canary in the past, but I did some of my own blogs and a bunch of other random stuff.
[01:32.280 --> 01:33.620]  So, there's that.
[01:34.160 --> 01:35.420]  And I have some stickers.
[01:35.440 --> 01:36.500]  And I have some bunnies.
[01:36.500 --> 01:38.340]  They're at the front for when the talk's over.
[01:38.800 --> 01:39.340]  Yeah, that's right.
[01:39.760 --> 01:40.320]  That's right.
[01:40.400 --> 01:40.980]  That's what I thought.
[01:42.700 --> 01:51.080]  But, yeah, my official title is, yeah, technically I am an AI security researcher and engineer at Cisco slash Duo.
[01:51.380 --> 01:52.820]  I'm under the Duo branch.
[01:52.820 --> 01:54.160]  It's a little confusing.
[01:54.420 --> 01:55.640]  Cisco has bought everything.
[01:56.360 --> 01:59.120]  But, you know, that's kind of what I do.
[02:02.580 --> 02:04.020]  So, yeah, you're here.
[02:04.280 --> 02:05.740]  But what the hell are we talking about?
[02:06.620 --> 02:13.160]  First thing, we're going to be talking a little bit about RDP because you can't really understand what's going on if you don't understand what RDP is.
[02:13.540 --> 02:14.580]  This will be brief.
[02:14.920 --> 02:19.540]  Yeah, I know you guys are probably far and above this, but we'll go for it anyways.
[02:20.100 --> 02:28.140]  We'll also talk a little bit about exploits on RDP, how that's kind of evolved in the past, how it's changed over time.
[02:29.440 --> 02:34.660]  We'll talk a little bit about what that has to do with MFA because, of course, yeah, what would be the point otherwise?
[02:35.320 --> 02:37.220]  And then what they look like in logging.
[02:37.440 --> 02:44.800]  I'll show you what I see on a daily basis, what some of my team sees when we go to do some threat hunting and when we want to pick out stuff.
[02:46.040 --> 02:52.500]  And then I'm going to talk a little bit about what we do with all of it, how we apply it, and why you should care.
[02:54.440 --> 03:00.820]  My standard rule with every talk I give is there should be a call to action because otherwise, what's the point?
[03:00.980 --> 03:01.600]  Why are you here?
[03:01.940 --> 03:03.360]  So that would be it.
[03:07.080 --> 03:08.360]  Wait, that went a little too far.
[03:08.480 --> 03:08.740]  There we go.
[03:09.680 --> 03:12.420]  So TLDR, I'm going to give you a quick overview of RDP.
[03:13.020 --> 03:18.860]  First thing is it's remote desktop protocol, which kind of gives you a little bit of the idea of what it is.
[03:19.120 --> 03:24.180]  Every time I try and teach somebody an acronym, I go, all right, well, here's exactly what it means.
[03:24.460 --> 03:25.520]  What do you think it does?
[03:25.780 --> 03:32.020]  And they almost always go, well, you remotely access a desktop.
[03:32.240 --> 03:32.800]  And I'm like, there you go.
[03:32.960 --> 03:33.640]  That's how it works.
[03:34.600 --> 03:36.040]  It's exactly what it sounds like.
[03:36.400 --> 03:47.180]  It helps IT teams and your friendly, overworked admin access machines when they're tired of giving verbal instructions to people who do not, in fact, turn it off and back on again like they're told.
[03:47.580 --> 03:48.460]  Thank you.
[03:49.440 --> 03:56.820]  I don't know what it is, but it was a bit of a godsend for obvious reasons when it was first introduced.
[03:57.540 --> 04:02.740]  You get a full view of the machine, you get full control, you can do kind of whatever you want if you have access.
[04:03.560 --> 04:06.100]  But as above, so below does apply.
[04:06.500 --> 04:14.820]  And of course, attackers getting access to these machines gives them access beyond their wildest dreams when they do so via RDP.
[04:16.420 --> 04:18.880]  So, there are a lot of exploits involved in that.
[04:20.400 --> 04:21.080]  Ta-da!
[04:21.420 --> 04:22.500]  I have a timeline.
[04:22.740 --> 04:25.960]  It's going to be a little bit hard to see, I think, but it's good enough.
[04:26.860 --> 04:28.940]  So, first things first, 1998.
[04:29.340 --> 04:30.400]  It was introduced.
[04:30.660 --> 04:31.540]  Security is for chumps.
[04:31.660 --> 04:33.320]  That was the general idea of the time.
[04:33.540 --> 04:34.520]  It was 98.
[04:34.520 --> 04:35.800]  There wasn't much point.
[04:35.960 --> 04:39.140]  Nobody was really super adopting this sort of stuff anyways.
[04:41.160 --> 04:45.440]  But yeah, then came some encryption during the early 2000s.
[04:45.960 --> 04:54.000]  That was more of a heavy adoption phase when people started to realize, hey, you know, this Microsoft stuff kind of works for business sometimes, occasionally.
[04:55.920 --> 05:02.940]  More attention was placed into security, but NTLM and adversary-in-the-middle attacks were still pretty strong concerns at the time.
[05:05.000 --> 05:11.000]  2008 was when things started to get interesting, with RDP 6.0 being introduced.
[05:11.360 --> 05:14.500]  Security was beefed up significantly with some TLS support.
[05:14.760 --> 05:18.800]  Network-level authentication being introduced, which fixes a lot of stuff.
[05:19.080 --> 05:21.140]  Helps improve a ton of things, actually.
[05:21.140 --> 05:26.780]  So, everything started to shift to more credential harvesting and misconfiguration hunting.
[05:27.200 --> 05:28.100]  Makes sense.
[05:28.980 --> 05:39.160]  This was around the time when Internet-wide bot scanning started to get a lot of traction, and RDP was one of the first and the best targets, understandably.
[05:39.160 --> 05:49.280]  Then, 2012 saw a very significant increase in exploit activity, and especially that of the less targeted variety.
[05:49.980 --> 05:56.920]  The Mordo worm was a very big concern around this timeframe, for instance, and that was used to perform RDP brute force attacks.
[05:58.660 --> 06:09.540]  In 2017, as with every other attack vector out there, there was a sudden spike in usage due to the increased popularity of malware or ransomware as a service.
[06:10.480 --> 06:17.320]  And, for those who are not aware, this is when, basically, there's somebody online who you buy your stuff from, all of your malicious bullcrap.
[06:17.540 --> 06:18.940]  So, that's a thing.
[06:21.340 --> 06:26.460]  But, then there was the big one that I think a lot of you are going to remember if you've done anything in IT services.
[06:28.260 --> 06:30.540]  2019, the discovery of Blue Keep.
[06:31.840 --> 06:39.760]  Blue Keep was a vulnerability that allowed for quick exploit and compromise of machines from modern day, all the way back to Windows 2000.
[06:40.280 --> 06:42.460]  So, yeah, it was kind of a big deal.
[06:43.140 --> 06:50.520]  It was wormable, and then a proof of concept came out, and urgent post-end-of-life patches were finally pushed by Microsoft.
[06:50.560 --> 06:54.720]  Which, if you know anything about Microsoft's patching, they do not do end-of-life.
[06:54.720 --> 06:55.760]  That was weird.
[06:57.860 --> 06:59.440]  And then, finally, modern day.
[06:59.840 --> 07:05.920]  We've seen the introduction of MFA into RDP more recently, around the 2023 era or so.
[07:06.400 --> 07:10.540]  Which is where we're going to be putting a lot of interest in this talk, honestly.
[07:11.160 --> 07:19.500]  The primary methods of overtaking RDP now are through session hijacking and token theft, which can bypass MFA.
[07:19.740 --> 07:24.900]  But, we're going to talk about some of the other stuff we've seen that's a little bit more on the funky side.
[07:27.260 --> 07:31.900]  So, let's get into some common attack methods, with or without MFA.
[07:31.900 --> 07:38.140]  First is the ever-classic RDP brute force, which you can do with Hydra.
[07:38.940 --> 07:43.240]  Hydra makes this process ridiculously, insanely, stupidly easy.
[07:43.560 --> 07:45.860]  I dare you, go look it up online.
[07:46.100 --> 07:49.740]  Say, how do I brute force RDP with Hydra?
[07:49.860 --> 07:54.240]  You will find a billion guides from some people who don't even know what they're doing.
[07:54.240 --> 07:55.180]  It's that easy.
[07:56.400 --> 08:01.500]  But yeah, if you're going for it, something without MFA, notably, this is the ticket.
[08:03.120 --> 08:09.020]  Hydra can work against remote services, so you don't need to fuss with all of your hashes, all your files, all your what have you.
[08:09.840 --> 08:15.500]  Of course, as we know, this can be defeated by defenders by forcing good password hygiene, for instance.
[08:15.500 --> 08:24.560]  Using MFA, lockout, rate limiting, proper logging, and general response to ensure that campaigns aren't going to be ongoing.
[08:25.260 --> 08:26.340]  So, there's that.
[08:27.400 --> 08:37.480]  Next is exploits on common vulnerabilities, like Blue Keep for older versions of Windows, or Deja Blue for newer ones.
[08:39.040 --> 08:48.340]  As we were talking about, we have Deja Blue, that's right, has some limitations in that the target machine needs a specific version of RDP to be running.
[08:48.760 --> 08:51.340]  This is usually 8.0, 8.1.
[08:52.820 --> 08:56.340]  That network level authentication prevents, excuse me.
[08:57.120 --> 09:04.040]  And, oh, and that network level authentication prevents an attacker from gaining access unless they already have valid account credentials.
[09:04.040 --> 09:07.740]  So, they need to get some sort of pseudo-valid account.
[09:09.580 --> 09:14.540]  These aren't massive stopping points, though, and attacks in the wild are still fully possible.
[09:14.940 --> 09:17.640]  Blue Keep is for older versions of RDP, however.
[09:18.640 --> 09:24.440]  Original exploits of Blue Keep had attackers using it to install Crypto Miners, which didn't work.
[09:24.700 --> 09:26.040]  The original exploits sucked.
[09:26.300 --> 09:28.260]  They started besotting machines left and right.
[09:29.500 --> 09:31.560]  So, now, it's perfectly valid.
[09:31.780 --> 09:35.580]  It did get fixed after a little while, and it's freely available on Metasploit.
[09:35.700 --> 09:38.360]  So, if you want to try it, don't do that.
[09:39.800 --> 09:43.260]  Another common use for RDP is, of course, lateral movement.
[09:44.060 --> 09:46.820]  I couldn't find a logo for that, so you get Safety Cat.
[09:48.560 --> 10:00.380]  RDP for lateral movement can be much more dangerous since, of course, there's the presence of both the protocol and whatever resources you have on the machine that you've already gained access to.
[10:01.500 --> 10:09.840]  The results of that is you can move very quickly laterally across a network with a lot more permissions gained over time.
[10:09.840 --> 10:15.380]  So, it's super dangerous, really easy to bypass MFA that way.
[10:17.720 --> 10:23.880]  And the other ways that you can from lateral movement is push harassment and simple social engineering.
[10:24.040 --> 10:24.940]  All of those kind of work.
[10:25.220 --> 10:26.940]  We'll talk a little bit more about that later.
[10:28.700 --> 10:35.440]  Finally, there's denial of servicing it to death, something that's significantly less likely to get access with right now.
[10:36.480 --> 10:45.640]  In some cases, configurations of RDP or MFA for RDP can be denial of service or otherwise brought offline.
[10:46.860 --> 10:49.580]  This can allow for something called a fail open condition.
[10:49.580 --> 10:51.140]  Some of you already know what that is.
[10:51.260 --> 10:54.680]  Some of you already know it's something that you should be sucking your teeth out and going...
[10:54.680 --> 10:55.700]  Yeah.
[10:56.860 --> 11:07.000]  Basically, breaks open MFA and some other requirements for RDP, meaning that an attacker has significantly fewer barriers between themselves and access.
[11:07.700 --> 11:15.840]  In other words, breaking it with itself, not unlike using a Brinks laminated padlock to open another Brinks laminated padlock.
[11:16.780 --> 11:24.200]  Fail open conditions exist in a ton of product implementations and especially network product implementations.
[11:24.720 --> 11:31.340]  And as we know, configs are fallible, so taking advantage of this isn't really unheard of.
[11:31.780 --> 11:37.800]  In fact, we've seen it before in some real-world incidents.
[11:39.120 --> 11:40.820]  This is where we're about to get into it.
[11:41.360 --> 11:47.300]  We'll dive a little bit into some of the scenarios and into some of the broader statistics and trends that we've gleaned from RDP and MFA data.
[11:47.500 --> 11:48.640]  So this is about to get fun.
[11:51.180 --> 11:53.720]  I'm going to let that stew for a second because that's a lot.
[11:56.220 --> 11:59.540]  This right here is what I see on a daily basis.
[12:00.340 --> 12:03.760]  I get to go ahead and figure out what's going on based off of this.
[12:05.100 --> 12:09.780]  To start, each one of these little dots is an MFA authentication.
[12:10.420 --> 12:12.460]  The green ones are success.
[12:12.800 --> 12:14.440]  The red ones are failures.
[12:14.780 --> 12:16.260]  The blue ones are marked fraud.
[12:17.780 --> 12:21.620]  You're going to see that there's some stuff that's a little bit more dense.
[12:21.620 --> 12:28.880]  Those are tons and tons of authentications all happening at once and likely in a pattern that's not human, obviously.
[12:30.640 --> 12:32.660]  All of this is from one IP.
[12:33.580 --> 12:33.820]  One.
[12:35.320 --> 12:37.920]  Each individual line is a different user.
[12:39.360 --> 12:40.620]  This is all one organization.
[12:41.980 --> 12:43.900]  So that's a little concerning.
[12:44.280 --> 12:45.860]  Very highly indicative of bot activity.
[12:46.200 --> 12:47.320]  No surprise there.
[12:48.180 --> 12:49.860]  This is what we call a spray.
[12:50.880 --> 12:55.320]  Typically, this initial hit is an attempt to find configuration problems.
[12:56.400 --> 13:03.520]  And it's so that an individual can take all those little successes, say, Oh, yeah, look, that line of users, these ones, these ones were easy.
[13:03.680 --> 13:05.600]  We got successes on those for some reason.
[13:05.820 --> 13:06.880]  Let's go on back.
[13:07.160 --> 13:09.160]  Let's try something against them, right?
[13:10.960 --> 13:15.040]  Now, the successes are likely from user bypasses and approval of unenrolled users.
[13:15.040 --> 13:19.020]  If you look on the right there, there's a lot of numbers.
[13:19.920 --> 13:24.140]  But you can see that there are a lot of bypassed users, 211 of them.
[13:25.320 --> 13:26.460]  That's not really good.
[13:26.460 --> 13:29.340]  You're not supposed to have bypassed users in most cases.
[13:29.680 --> 13:31.840]  So that's already a little bit concerning.
[13:32.500 --> 13:34.700]  You can also see user approved here.
[13:35.080 --> 13:41.140]  You can see lots and lots of frequent attempts, lots of denials, lots of no responses.
[13:41.820 --> 13:44.700]  So, again, gives a lot of indication of bot activity.
[13:45.200 --> 13:49.640]  There's almost nothing where the user actually did something to get in.
[13:50.280 --> 13:53.060]  So, yeah, very unlikely that there was a person behind this.
[13:54.820 --> 13:55.900]  Now, here's the thing.
[13:57.080 --> 14:01.200]  We've noticed that these patterns tend to hit different users in an organization in a cycle.
[14:01.320 --> 14:02.900]  To avoid lockouts, of course.
[14:03.100 --> 14:07.460]  You don't want to keep hitting something until eventually they say, geez, you're hitting this way too much.
[14:07.540 --> 14:08.640]  Let's go ahead and close you out.
[14:08.840 --> 14:10.280]  Then you lose all your opportunities.
[14:10.280 --> 14:14.080]  So, it's not always that we see stuff like this.
[14:14.320 --> 14:17.780]  Sometimes we'll see it with little brief spaces in between.
[14:19.320 --> 14:33.540]  Something I want to note that's kind of weird about this that leads to it possibly being MFA fatigue, which I will get a little bit more into later, is that there's very odd spacing in between each of these horizontal lines.
[14:33.660 --> 14:35.960]  You can see little tiny spaces.
[14:35.960 --> 14:40.880]  These almost perfectly match up with a nine-to-five workday and with weekends.
[14:42.960 --> 14:48.440]  Yeah, it's indicative of bad activity that's specifically targeting people.
[14:49.380 --> 14:55.400]  You're not going to typically see that type of activity unless it's, yeah, specifically towards people.
[14:56.640 --> 14:58.580]  So, there's that.
[14:59.540 --> 15:04.600]  Most of these organizations that are being targeted by this sort of activity are what you would expect.
[15:04.600 --> 15:07.700]  They tend to be at-risk sectors.
[15:07.920 --> 15:12.280]  Healthcare, education, IT services, manufacturing, etc.
[15:13.940 --> 15:15.900]  A little bit more on that part later as well.
[15:17.420 --> 15:28.820]  Now, this one, despite what it looks like and the fact that we talked about this being a ton of users and there's tons of authentications, this is actually a more targeted long-term campaign attack.
[15:28.820 --> 15:33.240]  Even though it's a spray, it's very targeted because it's that single organization.
[15:34.820 --> 15:39.080]  This activity can last for months if it's not stopped.
[15:40.260 --> 15:47.880]  If it's left unblocked and it's usually done in an attempt to trigger MFA fatigue or find an account that is given permission to bypass MFA.
[15:49.860 --> 15:57.740]  So, really quick, let me talk a little bit about MFA fatigue because that's something that, as a term, I think a lot of people don't know.
[15:58.880 --> 16:05.520]  But MFA fatigue is something that is definitely in the common lexicon as far as thought process goes.
[16:05.520 --> 16:14.680]  So, when you want access to something and you really want to force access to something, you can sometimes just spam an account.
[16:14.980 --> 16:16.460]  You spam it over and over again.
[16:16.580 --> 16:23.580]  And the result is that the user is going to receive push notifications on their phone that say, Hey, yeah, are you trying to log in?
[16:23.640 --> 16:24.420]  Are you trying to log in?
[16:25.340 --> 16:29.880]  If configurations aren't set properly, they're going to get every single one of those.
[16:29.880 --> 16:34.900]  And if they're doing this once every couple of minutes, that's awful.
[16:35.380 --> 16:38.540]  And the vast majority of users, they don't really know what this means.
[16:38.720 --> 16:39.640]  They don't know what to do with that.
[16:39.760 --> 16:42.740]  They'll just say, geez, like I keep denying this and it's not going away.
[16:42.860 --> 16:44.060]  What happens if I just press approve?
[16:45.200 --> 16:45.980]  And then they do.
[16:46.500 --> 16:48.080]  And then we know what happens from there.
[16:48.900 --> 16:50.380]  So, that's MFA fatigue.
[16:52.400 --> 16:57.380]  Now, if it sounds mildly familiar and you're not really sure why, it's because Lapsus was using that.
[16:58.220 --> 17:00.420]  Threat actor group mostly made up of children.
[17:01.460 --> 17:04.200]  To get access to some serious accounts.
[17:04.200 --> 17:05.220]  MGM, for instance.
[17:07.720 --> 17:09.900]  Now, that was one type of attack.
[17:10.180 --> 17:12.180]  A very nice targeted spray.
[17:13.340 --> 17:17.500]  But we have something called misconfiguration and targeted single attacks.
[17:18.200 --> 17:21.060]  These are really hard to understand.
[17:21.640 --> 17:26.360]  They're really hard to put together and say, this is what I'm looking for in my data.
[17:26.360 --> 17:33.240]  Because the only thing that's really going to indicate it is singular authentications.
[17:33.500 --> 17:35.460]  That's not a lot of data points to go off of.
[17:37.600 --> 17:39.960]  So, this is a large amount of our incidents.
[17:41.180 --> 17:44.620]  We see quite a few that are going to be targeted towards a single user.
[17:46.480 --> 17:50.600]  In this image, you're going to see that there are only two authentications, which you can't see.
[17:51.160 --> 17:51.800]  Dang it.
[17:52.700 --> 17:56.560]  I just transferred this over from Google, from PowerPoint.
[17:56.760 --> 18:00.640]  PowerPoint doesn't really like giving things that I've done in it.
[18:01.640 --> 18:05.380]  So, I had circled both of these authentications.
[18:05.560 --> 18:07.060]  There's one that's red in the corner here.
[18:07.060 --> 18:07.940]  That was a failure.
[18:07.940 --> 18:10.180]  There was one that was green in the upper right.
[18:10.380 --> 18:11.320]  That was a success.
[18:13.020 --> 18:16.380]  Now, you'd think, well, there was a success on this account.
[18:16.380 --> 18:18.480]  That was probably where the attacker got in.
[18:19.360 --> 18:20.460]  No, actually.
[18:20.560 --> 18:21.660]  It was a failure.
[18:23.640 --> 18:29.760]  The client had left a bypass in place that allowed the user to simply skirt past the multi-factor step.
[18:30.560 --> 18:35.680]  They had done this on a domain controller basis.
[18:35.980 --> 18:37.400]  They hadn't done it on a user basis.
[18:37.560 --> 18:45.620]  So, when they place a user bypass, we can usually see that as the reason for an authentication failing or succeeding or what have you.
[18:47.500 --> 18:48.660]  This wasn't the case.
[18:48.760 --> 18:50.820]  We saw it as no response from user.
[18:51.900 --> 19:01.500]  But when we dug a little bit deeper into logs, got really, really down deep into Kibana, we saw, oh, hey, this was actually passed off to the auth server.
[19:01.700 --> 19:02.760]  And there was a success.
[19:02.760 --> 19:09.480]  It's just, when it came to MFA, it didn't look like there was any response because they didn't need to complete the authentication.
[19:12.360 --> 19:17.900]  So, as you can see, by comparison to targeted sprays and fatigue, this looks boring.
[19:19.380 --> 19:22.680]  But it was likely very low effort on the attackers' part.
[19:22.900 --> 19:29.940]  This was probably something where they just kind of poked gently at individual users in an org and then they found one that was bypassed.
[19:30.040 --> 19:35.060]  Or they found the DC that was bypassed, found a user from there, and they said, oh, all right, easy.
[19:37.100 --> 19:40.300]  That leads to one of my favorite points in security as a whole.
[19:41.000 --> 19:43.620]  Boring is better when attacks are concerned.
[19:44.280 --> 19:46.540]  Anything flashy, you're going to get caught instantly.
[19:46.860 --> 19:48.720]  Anything boring, you're not.
[19:52.460 --> 19:53.940]  So, there's that.
[19:54.100 --> 19:55.080]  And then there's that.
[19:57.500 --> 19:59.600]  There's also a surprising amount of these.
[20:00.700 --> 20:05.580]  This is a perfect example of extremely ridiculously targeted fatigue.
[20:06.500 --> 20:11.200]  Or maybe a single source denial of service attempt, or maybe a brute force.
[20:11.520 --> 20:12.020]  Who knows?
[20:12.220 --> 20:13.740]  But for heaven's sake, that's a lot of ops.
[20:14.760 --> 20:25.580]  This was a two day long attack with over 32,000 authentications from a single fixed line IP with a terrible attack reputation across actually a pretty small amount of reports.
[20:25.580 --> 20:28.380]  But all those reports, RDP.
[20:29.860 --> 20:41.040]  From logging, it appeared that this actor was attempting to probably do some fatigue or brute forcing, but they didn't know that the user they were attacking was a disabled user.
[20:41.260 --> 20:42.820]  So that didn't really do anything.
[20:44.280 --> 20:52.600]  They may have seen that their attack from a month before, not shown here, was successful in hitting a login and assumed that that user was still active.
[20:54.100 --> 20:56.800]  It looked kind of similar to this, a little bit.
[20:57.560 --> 21:00.000]  But yeah, I don't think it was 32,000.
[21:00.100 --> 21:01.460]  I think it was closer to like a couple thousand.
[21:03.040 --> 21:08.220]  Now, these types of attacks, targeted spray or fatigue attacks happen really often.
[21:08.760 --> 21:20.460]  A query I ran recently, about a week ago, I saw several hundred IPs with failed authentication attempts between several hundred and tens of thousands.
[21:21.760 --> 21:23.620]  Against a single user in one day.
[21:23.800 --> 21:26.740]  That was my criteria that I was running my query on.
[21:27.980 --> 21:29.320]  That's really bad.
[21:30.380 --> 21:34.520]  Hundreds of those shouldn't be happening, even across a lot of customer environments.
[21:35.640 --> 21:42.280]  So yeah, very rare to see that many legitimate failed attempts, except in the case of something like a misconfigured service or an API.
[21:42.280 --> 21:48.720]  And even then you can usually tell, based on the IP, based on some past reputation, that it's a misconfigured service or API.
[21:49.040 --> 21:50.100]  This was not that.
[21:50.520 --> 21:51.520]  This is from Congo.
[21:51.740 --> 21:53.240]  This was a really bad reputation.
[21:53.360 --> 21:55.420]  It was spamming against everything.
[21:56.040 --> 21:56.120]  So.
[21:58.120 --> 22:02.560]  And now the final one that I want to talk about is social engineering and account takeover.
[22:03.660 --> 22:06.340]  We see these as the quietest attack.
[22:06.540 --> 22:08.640]  This is even quieter than the misconfig.
[22:10.820 --> 22:17.860]  They characterize themselves usually with only a single successful authentication from a less usual IP or location, when it comes to authentications.
[22:18.760 --> 22:21.560]  But then we'll start to see some device activity.
[22:23.140 --> 22:32.580]  So after this occurs, after they finally gain access, what happens is they'll typically gain access to the user's device change, right?
[22:32.740 --> 22:35.540]  They'll access the self-service portal or what have you.
[22:35.980 --> 22:38.220]  And they might put in their own device.
[22:38.500 --> 22:40.380]  They might delete a device.
[22:40.820 --> 22:45.080]  And that's usually the biggest indicator we have, which really sucks.
[22:47.220 --> 22:51.820]  Now, at the top of this image, you're going to see this is kind of what it looks like for us.
[22:53.280 --> 22:55.180]  It looks a little bit like gobbledygook.
[22:55.260 --> 22:57.200]  There's not really all that much information here.
[22:57.820 --> 23:05.480]  But you can see that there was something triggered by an admin acted upon a user.
[23:05.680 --> 23:07.820]  And that was performed from one location, Alan.
[23:09.200 --> 23:15.740]  On the bottom, there was an action triggered by a user upon a phone, an ERMO.
[23:16.000 --> 23:17.340]  And that action was null.
[23:17.920 --> 23:21.180]  To us, null means, well, that phone was deleted now.
[23:21.400 --> 23:24.460]  So not really all that much information left.
[23:27.380 --> 23:34.160]  Now, I also want to note that the authentication factors can sometimes be a really, really good indicator of what's going on here.
[23:35.620 --> 23:37.360]  You can see some SNS passcodes.
[23:37.920 --> 23:39.460]  You can see some phone call passcodes.
[23:39.560 --> 23:48.520]  Those are going to be a lot weaker than an authenticator app or, for instance, time-based passcodes because they don't require anything else.
[23:48.620 --> 23:50.080]  You just get the passcode.
[23:50.260 --> 23:54.200]  They're usually active for a very long time by comparison.
[23:55.020 --> 23:59.400]  And an attacker can easily just say, hey, can you just toss me that thing that I sent you?
[23:59.700 --> 24:01.340]  I sent that to you, for sure.
[24:03.660 --> 24:09.000]  In the context of RDP, this is definitely one of the most dangerous attacks because it's very hard to find.
[24:09.380 --> 24:14.240]  All the detections in the world are not going to be able to save somebody if they give their passcode to an attacker.
[24:15.020 --> 24:20.920]  But we can catalog these for future use because those things that I mentioned, those are patterns.
[24:21.240 --> 24:25.520]  Those are things that we can use to train a model and find more of them.
[24:27.460 --> 24:33.020]  So, for the statisticians in the audience, I do have stats.
[24:33.780 --> 24:35.480]  Stat nerds rejoice.
[24:36.240 --> 24:38.840]  Some of these might be useful to understanding the problem.
[24:39.400 --> 24:45.520]  First, these attacks tend to have fewer total authentications than MFA sprays seen on other protocols.
[24:46.300 --> 24:49.580]  But we see significantly fewer usernames.
[24:50.400 --> 24:57.680]  A lot of the time when we're seeing spray attacks, we're seeing somebody grabbing a rainbow table and just shoving it up against an entire network.
[24:58.280 --> 25:01.920]  That's really annoying, but it's not really all that effective now, is it?
[25:03.060 --> 25:08.940]  We had one that was 800 authentications that had 19 usernames.
[25:09.680 --> 25:11.460]  Those usernames were crazy targeted.
[25:11.740 --> 25:13.820]  While we had the usual that you'd expect.
[25:14.000 --> 25:15.400]  There were people trying administrator.
[25:15.660 --> 25:16.680]  There were people trying user.
[25:16.680 --> 25:20.500]  There were also some that were people's actual names.
[25:21.440 --> 25:26.720]  There were some that were formatted as you would see on their email.
[25:27.400 --> 25:27.820]  Right?
[25:28.140 --> 25:30.140]  So, those are all pretty concerning.
[25:30.340 --> 25:31.300]  Those are very targeted.
[25:33.940 --> 25:41.300]  The other thing that we saw was that they tend to have more origination in areas associated with targeted attacks or campaigns.
[25:41.300 --> 25:43.040]  And I do mean geographical areas.
[25:43.980 --> 25:47.020]  Areas with low international cybercrime accountability especially.
[25:47.020 --> 25:50.080]  So, we did see a lot with Russia, Malaysia, Switzerland.
[25:50.620 --> 25:52.200]  We did see some with China.
[25:53.320 --> 25:57.460]  We do see some from the U.S., but they tend to be slightly more VPN based.
[25:58.280 --> 26:02.720]  That being said, known VPNs are significantly less common overall.
[26:02.720 --> 26:05.700]  There is a slight caveat to this though.
[26:06.000 --> 26:09.880]  In that VPNs, of course, they move around a lot.
[26:10.200 --> 26:11.440]  They don't stick with one IP.
[26:11.740 --> 26:15.440]  It can be hard to dedicate whether something is a current VPN or not.
[26:17.080 --> 26:19.420]  So, that's not really the most reliable metric.
[26:22.360 --> 26:24.480]  Another thing that was of note was industry.
[26:25.360 --> 26:32.120]  Industries that are highest targeted are manufacturing at about 40% of the auths out of this dataset, which was massive by the way.
[26:33.220 --> 26:35.840]  And IT services at 14%.
[26:36.520 --> 26:37.820]  This makes a ton of sense.
[26:38.300 --> 26:43.080]  Manufacturing, there is a lot of very, very juicy access to be had.
[26:43.260 --> 26:46.160]  And the vast majority of it is going to be accessed through RDP.
[26:47.580 --> 26:49.840]  IT services, you have the keys to the kingdom.
[26:49.840 --> 26:51.880]  You have lots and lots of customer data.
[26:51.880 --> 26:54.100]  It's going to also be very good.
[26:56.120 --> 27:00.340]  There was also a very high percentage of legitimate auth activity and bypass activity.
[27:01.680 --> 27:08.440]  These are likely attributed to social engineering or successful push fatigue attacks and accounts with a bypass left on.
[27:08.700 --> 27:09.560]  No surprise there.
[27:10.700 --> 27:17.600]  And finally, there's tons and tons and tons of spray activity that occurs without the auth ever going through.
[27:18.460 --> 27:28.200]  This is likely activity looking for those bypassed accounts or a little bit of the fatigue and general automated attacks using public password data.
[27:28.200 --> 27:30.920]  So, it's a ton.
[27:31.140 --> 27:32.060]  There's a lot of crap.
[27:32.240 --> 27:33.500]  84% is a lot.
[27:33.800 --> 27:34.900]  It's a lot to sift through.
[27:38.640 --> 27:43.560]  So, we've talked a little bit about how some of RDP works.
[27:43.560 --> 27:46.000]  A little bit of the historical context.
[27:46.440 --> 27:47.660]  Some of the historical attacks.
[27:48.560 --> 27:55.080]  And we've talked a little bit about the most common RDP MFA attacks that we see today and how they look in logs.
[27:55.360 --> 27:56.240]  That's pretty cool.
[27:56.940 --> 28:07.680]  The last bit I would love to talk with you about today is how this data can be used to train models, create detections, and better protect all systems from these sorts of attacks.
[28:10.600 --> 28:17.760]  So, if you're unaware of how a model is created, this is kind of the general process.
[28:18.140 --> 28:25.700]  You take your data, you label it, you apply it to a model, and then you apply that model to whatever use case you have.
[28:27.520 --> 28:30.600]  This is kind of how it works on a general basis.
[28:30.600 --> 28:39.800]  Slightly more specifically, first, we get a pool of authentication traffic that we perform reviews on and we apply some of our existing detections to.
[28:40.980 --> 28:42.940]  This isn't a foolproof process.
[28:43.480 --> 28:47.880]  All, for instance, apply queries, which are significantly more general.
[28:48.080 --> 28:49.940]  They're a less accurate way of finding something out.
[28:49.960 --> 28:59.360]  I'm basically just asking a general question of what does it look like when I'm asking for all of these single users that are getting hit with over this amount of sprays.
[28:59.360 --> 29:05.060]  So, you're not really going to get anything hyper-specific, but it'll lead you in the right direction.
[29:06.060 --> 29:12.820]  On the other hand, there are detections, which are going to be a little bit more strict on the traffic that they pull out.
[29:12.960 --> 29:14.020]  They've usually been tweaked.
[29:14.180 --> 29:17.080]  They've been sort of moved into the right direction.
[29:18.840 --> 29:32.660]  Sometimes we get notice of compromises and attacks from customers directly, which is super helpful because occasionally we can ask them for some logs on the other side, things that we can't see, to be able to get better context on how they work.
[29:35.780 --> 29:45.180]  Next, we find a piece of traffic that could be an attack.
[29:45.180 --> 29:47.540]  We have finally narrowed it down a little bit.
[29:48.480 --> 29:51.260]  And we'll try to gain a little bit more information on it.
[29:51.260 --> 29:59.760]  We'll do historical lookups on the user, the IP, the phone, the ASN, and detections of similar patterns.
[30:00.860 --> 30:07.920]  We'll catalog these accordingly, even the patterns that turn out to be benign, because there's still some use to those.
[30:07.920 --> 30:12.500]  And then we'll review all of them by hand to ensure that our model has some proper integrity.
[30:12.800 --> 30:15.980]  This is something that tends to be a problem with building models.
[30:16.260 --> 30:20.520]  A lot of people will just kind of shove in the detection with a query, and they'll call it a day.
[30:22.680 --> 30:27.080]  Then we gather these labels together to create a model that's trained on a certain traffic type.
[30:27.820 --> 30:38.260]  RDP MFA model that we have, one of the RDP MFA models that we have, is primarily made up of broad spray activity, as it is indeed one of the most common varieties.
[30:39.180 --> 30:44.020]  But it does have some targeted attacks from customer incidents or other alerting.
[30:45.600 --> 30:52.020]  So we take that model, and we'll finally apply it back to the pool, and we'll test it out and see how it works.
[30:52.920 --> 30:54.840]  Models don't work from the get-go.
[30:54.840 --> 30:59.720]  If you've ever worked with anything with model training, you'll know that they screw up on a regular basis.
[31:00.460 --> 31:02.640]  So they need a lot, a lot of testing.
[31:02.860 --> 31:04.220]  They need a lot of human verification.
[31:04.900 --> 31:06.960]  The process of automation is not an easy one.
[31:10.940 --> 31:14.340]  Now, here's where we get to some of the useful stuff for you.
[31:14.780 --> 31:20.780]  How do you prevent attacks on implemented RDP in your environment, MFA-enabled or otherwise?
[31:21.520 --> 31:24.040]  A lot of these responses are the easy ones, of course.
[31:24.040 --> 31:27.180]  First, RDP and MFA are great together, actually.
[31:27.660 --> 31:33.740]  In spite of all of the stuff I just showed you, it's still a really good idea to have MFA.
[31:35.240 --> 31:38.560]  There are inherently some vulnerabilities in MFA, sure.
[31:38.820 --> 31:43.880]  I mean, it's as with literally any other solution that you're going to be placing.
[31:45.280 --> 31:57.380]  But it's still going to be a whole lot better than a trove of password dumps, brute forcing, port scanning, all manner of junk that slams against your servers, and one of them actually succeeding.
[31:58.600 --> 31:59.800]  So, there is that.
[32:00.740 --> 32:03.340]  MFA is one of the best tools you have to keep that away from your environment.
[32:04.880 --> 32:09.040]  The next thing is that, yeah, this is kind of a widespread problem for RDP.
[32:09.280 --> 32:10.420]  It's configs.
[32:11.480 --> 32:13.820]  The usual recommendations do apply.
[32:14.060 --> 32:16.680]  Keep it off the open Internet if you can, please.
[32:18.540 --> 32:20.460]  Thoroughly read through your configurations.
[32:20.740 --> 32:23.840]  Understand exactly what they do before you put them into place.
[32:23.840 --> 32:31.020]  I have had many incidents in the past where somebody's come to me and said, well, how come they were able to get access?
[32:31.200 --> 32:33.080]  And I'm like, well, it's because you left it wide open.
[32:33.620 --> 32:35.080]  I don't know what to tell you.
[32:35.600 --> 32:40.280]  And then I tell them about something that they should have seen right when they were configuring the thing in the first place.
[32:41.340 --> 32:46.700]  It's something that, yeah, sometimes you just got to take a second, take it slow and read it through.
[32:49.300 --> 32:50.740]  Also, regular audits.
[32:50.900 --> 32:52.780]  I can't express this enough.
[32:52.780 --> 33:00.980]  I have done a lot of contract work for organizations in the past where I'll go, hey, what you got for permissions?
[33:01.360 --> 33:02.940]  And they're like, we don't really know.
[33:03.420 --> 33:05.080]  I'm like, that's not good, man.
[33:06.320 --> 33:08.980]  And so first thing I'll do is I'll do an audit.
[33:09.200 --> 33:12.700]  I'll check for permissions on certain accounts.
[33:12.700 --> 33:14.060]  I'll check for bypasses.
[33:14.260 --> 33:16.100]  I'll check for what they have in place.
[33:16.100 --> 33:20.900]  And sometimes I do it black box because it can be easier.
[33:20.900 --> 33:24.500]  Sometimes these orgs don't have any idea of what's going on with their configs.
[33:25.640 --> 33:27.180]  Again, unfortunately, that's normal.
[33:27.360 --> 33:28.880]  It's just the way the red tape works.
[33:29.040 --> 33:33.520]  But that's still a big, big problem when it comes to RDP and MFA.
[33:35.120 --> 33:41.700]  The final thing is that, and I kind of hate having to bring it up, but it is this way right now.
[33:42.860 --> 33:48.500]  Automation helps, but it's really not going to do the trick on its own at all.
[33:50.080 --> 33:54.440]  Humans are completely necessary in identifying threats and training models.
[33:54.780 --> 34:00.340]  There's no way that you can just shove information into a model and see an excellent output right away.
[34:00.340 --> 34:01.700]  It doesn't work like that.
[34:03.740 --> 34:08.920]  So yeah, humans are great with pattern recognition, especially the NeuroSpicy types.
[34:09.620 --> 34:16.780]  We're able to pick out things that a machine won't be able to see unless it is specifically already trained to see them.
[34:17.040 --> 34:18.960]  If it doesn't exist, we can't do it.
[34:20.000 --> 34:25.180]  So no matter what, even with this amazing automation, you need to keep humans in your workflow.
[34:25.180 --> 34:32.780]  They will always be necessary to SOC managers, CISOs, what have you, all other leadership out there.
[34:33.740 --> 34:39.980]  Their value is beyond what I can calculate statistically, and trust me, I can calculate pretty well.
[34:42.020 --> 34:46.440]  So, with that, I would love to take some questions.
[34:55.120 --> 34:55.560]  Anyone?
[34:56.300 --> 34:56.740]  Bueller?
[34:57.180 --> 35:04.640]  I missed part of this, but how did you generate the dot graph that you got earlier?
[35:04.920 --> 35:06.220]  Okay, so this is a good question.
[35:06.220 --> 35:07.880]  How did I generate the dot graphs?
[35:09.460 --> 35:11.380]  So, this was something that...
[35:11.380 --> 35:15.380]  And actually, I mean, I may as well do the thanks first, because one of my coworkers did this.
[35:16.140 --> 35:18.700]  So, Steven Leung, Laurence L.
[35:18.780 --> 35:22.820]  Fletcher, and then Phillip Schaefer, these are my team, and they're wonderful, and I love them.
[35:22.820 --> 35:29.100]  So, we started working with Hex and Snowflake tools years ago.
[35:30.440 --> 35:41.540]  And we found that there were some graphing applications that we could use as part of them that were super crazy easy to configure.
[35:41.540 --> 35:44.460]  This one, in particular, was hex-based.
[35:45.560 --> 35:46.580]  So, yeah.
[35:46.720 --> 35:47.800]  It shows up well.
[35:47.960 --> 35:51.300]  And the coolest thing is that those graphs, they're not static.
[35:51.680 --> 35:53.980]  You can change, like, everything about them.
[35:54.000 --> 35:55.160]  It's really, really nice.
[35:56.020 --> 36:00.460]  So, if I just want to filter down something that I've already obtained, I can.
[36:00.460 --> 36:04.080]  I can go into certain fields, and I can just say, no, I only want these.
[36:04.080 --> 36:04.620]  I want this.
[36:04.720 --> 36:05.120]  I want that.
[36:06.200 --> 36:08.660]  It makes it a lot easier to display things, of course.
[36:09.840 --> 36:20.560]  But more than that, like, if you're actually presenting, like, a dashboard or something like that for a manager, you can narrow it down and make it look less crazy so they can understand it better.
[36:20.560 --> 36:21.580]  It's pretty nice.
[36:22.760 --> 36:34.060]  The data for that graph, maybe you said this, like, was it from packet, like from Wireshark, a packet analysis, or was it from system logs?
[36:34.420 --> 36:35.760]  So, data sourcing.
[36:36.040 --> 36:38.340]  It was from system logs.
[36:39.020 --> 36:41.280]  We didn't do packet captures on these ones.
[36:41.280 --> 36:46.200]  We do some, but they're not really a part of this.
[36:47.180 --> 36:49.840]  Yeah, this is all auth data that's direct from API.
[36:49.840 --> 36:50.580]  So...
[36:53.500 --> 36:54.300]  Oh, yeah.
[36:54.600 --> 36:54.760]  Yeah.
[36:55.980 --> 36:56.520]  So, yeah.
[36:56.620 --> 36:56.900]  Go for it.
[36:57.600 --> 37:04.600]  So, I'm kind of curious, I'm probably already in the answer to this, but did you break out, like, MFA tax via...
[37:04.600 --> 37:11.540]  You know, did you break out a tax via MFA pushout versus other types of MFA, like HOTP, TOTP, that sort of thing?
[37:11.840 --> 37:12.200]  Yeah.
[37:12.320 --> 37:12.440]  Yeah.
[37:12.540 --> 37:18.740]  So, on one of the slides, I was showing some of the different authentication methods.
[37:18.740 --> 37:24.840]  We do have a lot of insight into which individual method is being used.
[37:26.080 --> 37:32.420]  And we'll even get into some of the ones that are, like, insanely esoteric and really out there.
[37:32.420 --> 37:35.540]  So, we do have some stats on that.
[37:35.660 --> 37:36.340]  It's pretty cool.
[37:50.020 --> 37:50.500]  Yeah.
[37:50.500 --> 37:58.360]  So, one of the things that we find most helpful is that we have an entire section that's working on risk-based authentication work, right?
[37:59.140 --> 38:05.380]  And we'll have detectors that'll flag when, you know, yeah, rate limiting or what have you.
[38:05.380 --> 38:12.800]  We also have some that will trigger very quickly, which our engineering team is freaking magical.
[38:13.520 --> 38:19.400]  There have been some really, really amazing ones that have picked up on spray on, like, the first two aughts.
[38:19.480 --> 38:20.160]  It's amazing.
[38:21.960 --> 38:24.600]  So, yeah, it's a bit of a combo.
[38:25.760 --> 38:33.080]  But, in general, I would say that, yeah, the brain.
[38:33.380 --> 38:33.620]  Nope.
[38:33.820 --> 38:34.480]  I just had a brain fart.
[38:34.620 --> 38:35.680]  But, yes, in general, yes.
[38:37.140 --> 38:37.820]  It's...
[38:37.820 --> 38:42.020]  So, initialized brokers, frequently, several already be accessed.
[38:42.240 --> 38:43.400]  That's a lot of times now.
[38:43.740 --> 38:48.660]  They show that they have access to an organization, and et cetera.
[38:49.440 --> 38:56.960]  You mentioned that some of the attacks used the name and email of actual employees.
[38:57.240 --> 39:00.460]  Do you have any idea where that was taken from?
[39:00.620 --> 39:03.400]  Like, how they were able to get that information?
[39:03.400 --> 39:03.960]  Yeah.
[39:04.300 --> 39:08.060]  So, there was one time a few months ago, I got really curious about that.
[39:08.660 --> 39:14.100]  And I started following in their footsteps a little bit and trying to figure out where it was coming from.
[39:14.920 --> 39:16.540]  And a lot of it's just pastebin.
[39:16.740 --> 39:17.960]  A lot of it is pastebin.
[39:18.260 --> 39:19.200]  Because, of course, it is.
[39:19.280 --> 39:19.760]  It's all pastebin.
[39:20.000 --> 39:21.020]  Everything's pastebin nowadays.
[39:22.380 --> 39:27.780]  But there were some where it was like, oh, yeah, this was very clearly from something that was sold.
[39:28.540 --> 39:30.400]  This was, like, way too specific.
[39:30.400 --> 39:34.300]  There's some hashes in here for passwords that are not, you know.
[39:35.020 --> 39:36.300]  So, it's...
[39:36.300 --> 39:36.900]  Yeah.
[39:37.140 --> 39:37.360]  Yeah.
[39:37.640 --> 39:41.120]  It's usually from something like that, from prior breaches.
[39:41.780 --> 39:49.880]  The reason I'm asking is, as we analyze, like, credential, I'm sorry, ransomware leaks and the data that is leaked, like, third-party.
[39:50.080 --> 39:50.440]  I hated this.
[39:50.640 --> 39:52.480]  But, you know, have you ever noticed anything?
[39:52.700 --> 40:02.940]  Because, obviously, that has a lot of information about not just the victim companies and board which already has been, you know, hacked, but their affiliates, their clients, all that kind of stuff.
[40:02.940 --> 40:06.020]  Have you ever seen anything related to that?
[40:06.340 --> 40:06.820]  Kinda.
[40:07.360 --> 40:08.620]  More tangentially.
[40:09.660 --> 40:14.700]  So, for a really cool shout out, we get to work with Talos right now.
[40:14.980 --> 40:16.540]  And it's been awesome.
[40:17.200 --> 40:33.780]  And occasionally, if we get something like that, where we're like, oh, this could probably be a ransomware, it could be originating from a ransomware attack earlier, or what have you, we can go to them and we can say, hey, this IP, this specific data that we saw, do you see any correlation?
[40:35.700 --> 40:37.780]  And we can usually see a little bit.
[40:38.700 --> 40:43.260]  In the past, we had, it was more of a targeted spray.
[40:44.080 --> 40:47.740]  But, yeah, it looked really, really wildly specific in the usernames.
[40:47.740 --> 40:54.600]  And we brought it over to them and they went, oh yeah, no, this, this IP is one of the ones that's associated with this threat actor and it's a pretty big one.
[40:54.800 --> 40:58.060]  So, it was almost direct answers.
[40:58.220 --> 41:03.880]  It's, it's, it's every data nerd's dream to have access to Talos.
[41:04.980 --> 41:06.940]  So, yeah, thank you.
[41:08.040 --> 41:12.700]  You had mentioned earlier that VPNs weren't very commonly seen on these.
[41:12.700 --> 41:24.700]  the, the, the origination of a lot of these, are they coming from like the big three IS, like Azure AWS GCP, or is it like hosting Colos or residential ASNNs or?
[41:25.020 --> 41:25.480]  Yes.
[41:26.080 --> 41:33.240]  So, the question was on like, yeah, with the VPN issue, a lot of it is from a lot of the, the typical cloud providers and such.
[41:34.020 --> 41:35.660]  Um, a little bit, yeah.
[41:36.000 --> 41:38.140]  Uh, there's, there's a pretty good amount, of course.
[41:38.140 --> 41:44.160]  I mean, how much of like all Internet traffic is based off of cloud provider usage nowadays?
[41:44.160 --> 41:44.820]  It's a lot.
[41:45.440 --> 41:47.040]  Um, so yeah, there is a pretty good amount.
[41:47.180 --> 41:51.320]  I would say it's about average with what would be seen generally.
[41:52.120 --> 42:04.700]  Um, haven't looked into it too deeply, but, um, as far as the VPNs go, it's, it's, um, we'll see some stuff that is usually associated with a regular application and it's totally malicious.
[42:04.700 --> 42:05.680]  There's no way it's not.
[42:06.500 --> 42:08.360]  Um, yeah, cloud provider, same deal.
[42:08.600 --> 42:16.800]  Uh, we don't necessarily classify that as VPN, um, but it's kind of in its own sort of, uh, bucket.
[42:17.340 --> 42:26.660]  Um, as far as VPNs go, yeah, that, that issue of like, you're chasing where the VPN providers are grabbing their IPs and it's, it's annoying.
[42:26.880 --> 42:29.460]  It's really, it has to work off of reputation.
[42:29.460 --> 42:32.120]  Um, cause a lot of them are really, really good at hiding it.
[42:32.540 --> 42:35.780]  Uh, of course, not like the primary ones, a lot of the lower level ones.
[42:36.180 --> 42:36.280]  So.
[42:37.420 --> 42:37.820]  Yeah.
[42:38.160 --> 42:38.920]  I hope that answers it.
[42:39.560 --> 42:40.660]  Um, yeah.
[42:41.300 --> 42:44.780]  Um, a client thought of a DOD contractor.
[42:45.280 --> 42:46.380]  I was just behind a conversation.
[42:46.640 --> 42:49.200]  We found about RDD, already deep in force incident.
[42:49.760 --> 42:53.540]  Um, and I found that they have a good policy forcing.
[42:54.280 --> 42:57.700]  public access, but what are you bringing them in all of their machines?
[42:58.680 --> 42:58.740]  Um.
[42:59.120 --> 42:59.260]  Mm-hmm.
[43:00.620 --> 43:02.580]  I'm just curious if you have any, like, choice.
[43:03.300 --> 43:05.460]  What would your approach be to that conversation?
[43:05.780 --> 43:07.300]  Like, do you have any statistics you might cite?
[43:07.980 --> 43:10.260]  I, I've had that conversation before.
[43:10.600 --> 43:18.980]  Um, so, so the question was like, you know, I've had, uh, uh, open, open to Internet, three, three, eight, nine, uh, how do you approach that?
[43:18.980 --> 43:26.660]  Uh, usually it's with a, hey, buddy, you know, these attacks are really, really common.
[43:27.020 --> 43:38.480]  Um, I don't have the number right in front of me, but, uh, out of all of the spray attacks we see, RDP is, it is insanely common, which is why I did this talk instead of on something else, right?
[43:38.700 --> 43:40.440]  Um, it's, it's a really, really big problem.
[43:40.460 --> 43:48.420]  And I would literally just go through the timeline, like, if you can just send him a little link in the timeline that says, hey, it's been vulnerable for a long time.
[43:48.420 --> 43:50.180]  And, hey, it's kind of been targeted forever.
[43:50.920 --> 43:54.120]  Um, RDP is a bit of a problem in that sense.
[43:54.540 --> 43:57.760]  Um, and, uh, it's probably not going to go away.
[43:58.580 --> 43:58.980]  Ever.
[44:00.440 --> 44:03.400]  Um, there's always going to be something to replace it that's similar to.
[44:03.600 --> 44:09.480]  So, yeah, it, in general, my response is just say, yeah, it's always been a problem.
[44:09.740 --> 44:10.960]  There's no way it's going away.
[44:12.040 --> 44:12.580]  So, yeah.
[44:13.780 --> 44:30.460]  As far as more of a, a defense in depth kind of perspective, um, what are your thoughts on, uh, more of the conditional access policies or, like, requiring known enrolled managed devices, uh, to, to be able to have RDP access?
[44:30.460 --> 44:34.360]  Um, so thoughts on conditional access policies and known managed devices?
[44:34.680 --> 44:39.800]  Um, well, yeah, I, I actually think it does help a pretty good amount.
[44:40.080 --> 44:43.660]  Um, we have some, like, I can't get into it.
[44:43.660 --> 44:51.660]  I got like five minutes, but, um, we have some things with, um, phone keys, the way that we track phones that are a little screwy.
[44:51.820 --> 44:52.580]  It's a little annoying.
[44:53.060 --> 44:59.680]  Um, but in general, like if you lock down conditional access, uh, you lock down using conditional access.
[44:59.680 --> 45:18.180]  If you say, Hey, look, um, I'm going to give you this one time code and I'm going to make sure you got it through an out of band method and, and, and, um, and you make sure that like, you know, those, those specific, um, uh, rules that you have for initial registration are really locked the hell down.
[45:18.900 --> 45:19.080]  Yeah.
[45:19.140 --> 45:19.880]  It helps like a ton.
[45:20.400 --> 45:26.280]  Um, that's one of those configuration problems that I'm kind of like very broadly throwing out into the ether.
[45:26.540 --> 45:38.800]  I, you don't, you don't lock down as hard as you can and get to, um, get to a point of, I can't believe I'm saying this, but like least privilege, uh, then yeah, you're, you're going to have some serious issues.
[45:38.800 --> 45:39.680]  It's just going to be open.
[45:41.280 --> 45:42.320]  So yeah.
[45:42.520 --> 45:43.120]  Conditional access.
[45:43.260 --> 45:43.320]  Good.
[45:46.260 --> 45:46.780]  Anybody?
[45:47.260 --> 45:47.540]  Bueller.
[45:48.100 --> 45:48.820]  Over there.
[45:49.480 --> 45:49.580]  Please.
[45:50.120 --> 45:51.660]  Uh, you have some models training.
[45:52.180 --> 45:52.500]  Oh!
[45:53.040 --> 45:59.100]  Uh, if you have some different fat cat organization, I'll be having a lot more organizations.
[46:00.420 --> 46:01.200]  They're trading.
[46:01.200 --> 46:01.960]  Sure.
[46:02.300 --> 46:04.600]  Well, I'm afraid this is kind of the catch 22.
[46:05.180 --> 46:13.180]  Um, so a question was, yeah, if you're doing model training, how do not so huge organizations get access to this data to be able to do it?
[46:13.280 --> 46:18.040]  And the answer is, well, you kind of got to, you kind of got open sourcing as much as you can.
[46:18.300 --> 46:19.140]  That's really all you got.
[46:19.440 --> 46:21.160]  Um, it has been done.
[46:21.360 --> 46:27.520]  Uh, but it requires a pretty large amount of effort and that's why it's kind of inherently a big, big, big thing.
[46:28.340 --> 46:35.180]  Um, it sort of sucks in that sense, but that's why open-source models are very important to support.
[46:35.740 --> 46:45.740]  Um, again, more, more beautiful points for open-source in that, uh, yeah, at least you got a ton of other people who are really, really interested in it who can hopefully help.
[46:45.740 --> 46:54.860]  Um, but yeah, and, uh, you keep the corporate bureaucracy stuff out of it, which can help with your model quality sometimes.
[46:55.760 --> 46:56.320]  Mm-hmm.
[46:56.320 --> 46:57.120]  So, cool.
[46:57.680 --> 46:58.060]  All right.
[46:58.360 --> 46:58.840]  One more.
[46:58.960 --> 47:11.260]  Do you know of any, um, like community efforts for kind of collecting those, those data or like sufficiently like redacted loss to be able to do this, this model?
[47:11.260 --> 47:17.640]  So, question is, uh, do you know of any community efforts to get some sufficiently redacted logs to do this modeling?
[47:17.940 --> 47:19.480]  I don't, actually.
[47:20.080 --> 47:24.280]  Um, I could be completely like, you know, under a rock.
[47:24.660 --> 47:27.100]  Um, I haven't super looked into it.
[47:27.300 --> 47:30.180]  Um, but, uh, I don't, I don't right now.
[47:30.800 --> 47:33.040]  So, all right.
[47:33.600 --> 47:34.360]  Thanks guys.
[47:34.520 --> 47:35.280]  Come get some stickers.
[47:35.420 --> 47:35.440]  Cheers.