WEBVTT 00:00.780 --> 00:05.560 Hello, my name is Chris Nevin and I work for NCC Group. 00:05.580 --> 00:12.800 So this tool is called Carnivore, so that's a Microsoft external attack tool or assessment tool. 00:12.800 --> 00:19.120 So the cryptozoologists amongst you might know this, so that spells meat, so that's very amusing. 00:19.180 --> 00:28.260 And it's basically a tool to help pen testers find misconfigurations and vulnerabilities in Microsoft on-premises servers. 00:28.440 --> 00:33.480 So also apologies if I talk quickly, but there is quite a lot to get through. 00:35.080 --> 00:37.900 So the basic outline of the presentation. 00:37.900 --> 00:48.920 So I'm going to start with a demonstration just to show what the tool can do and then dive a bit deeper into some of the techniques and the research behind them after that. 00:49.820 --> 00:52.340 So now intro demonstration. 00:52.960 --> 00:58.520 Okay, so first a quick overview just to give you a taste of what the tool can do. 00:58.520 --> 01:06.600 So just before I kick it off, we've selected all services and we're also going to attempt to discover the internal domain information. 01:07.000 --> 01:10.460 You might notice that it's a .nev domain. 01:10.620 --> 01:15.560 Obviously that wouldn't normally be a top-level domain, but this is my training lab. 01:16.160 --> 01:25.920 So first of all, it's going to do DNS lookups for subdomains, which are normally connected with a particular service. 01:25.920 --> 01:30.880 So for example, link discover with Skype, then it verifies there's something there. 01:30.880 --> 01:34.200 So it's not just a wild card resolution. 01:34.260 --> 01:41.060 And then it also does some checks to make sure, does it also actually seem to be an exchange or a Skype server? 01:41.520 --> 01:46.840 So I've also built in some kind of bailout options. 01:46.840 --> 01:50.740 So for example, we get back a server header saying that it's Nginx. 01:50.740 --> 01:52.000 It's not even Windows. 01:52.000 --> 01:57.560 We don't need to test every possible endpoint just in case one of them is a Skype server. 01:58.780 --> 02:01.260 So yes, that's something that we do. 02:01.500 --> 02:07.340 So it also validates the username enumeration and the password spray URL separately. 02:07.720 --> 02:20.080 I'll come on to that in a little bit, but basically there are occasions where an organization might have hidden most things, but there'll be one password spray URL kind of hidden away. 02:20.180 --> 02:28.080 So we try the most obvious, and then if they don't hit, there are other kind of password spray endpoints that are possible. 02:28.820 --> 02:35.420 So yeah, so hopefully if an organization has something exposed, then we'll be able to find it to report to them. 02:35.880 --> 02:45.860 So we also log everything here, and you've got export options if you want to kind of manually export things for some reason. 02:46.300 --> 02:59.300 I'll cover Office 365 more at the end, but for this section, if Office 365 is ticked, then it will explicitly check if this has any kind of cloud presence. 02:59.300 --> 03:13.160 Even if it's not ticked, then the response to Skype for Business, for example, might come back and say, I'm hosted in the cloud, and then we'll still do the standard checks for, is it federated, and that kind of thing. 03:13.160 --> 03:23.600 And then it will add, so say we just did Skype for Business, it says it's in the cloud, it turns out it's federated, we'll get an Office 365 and an ADFS option here. 03:24.840 --> 03:34.080 So okay, so we've also got global verbosity here, so you can kind of tweak that up and down depending on what you want to see. 03:34.740 --> 03:37.900 Okay, so let me kick this off. 03:39.280 --> 03:48.820 Okay, so the other thing with this discover internal domain, then it does the fairly standard blank type one NTLM message. 03:48.820 --> 03:52.680 And you can see it's pulled back the internal domain name. 03:52.680 --> 03:57.160 So at the moment, it does that individually for each of these services. 03:57.160 --> 04:06.360 And that's because, you know, Skype might be hosted in Germany, and ADFS server, the ADFS server might be in Canada for some reason. 04:06.820 --> 04:15.960 And so when you're hitting, when you're spraying that server, then you've got the internal domain information for the particular server that you're hitting. 04:16.320 --> 04:21.100 And in fact, even on a job just last week, then these were all different. 04:21.960 --> 04:26.960 So it does happen quite frequently, I might add some kind of advanced options. 04:27.360 --> 04:30.080 So you can say, just assume they're all same. 04:30.240 --> 04:36.040 But like say, that's maybe, you know, a recipe for potential disaster. 04:36.040 --> 04:38.980 So okay, we've also got the IP addresses here. 04:38.980 --> 04:41.560 So you can obviously check those against your scope. 04:41.560 --> 04:51.060 And if you want to, you can kind of run this once, check the IP addresses against your scope, and then do the more active kind of blank NTLM one message. 04:52.240 --> 04:56.760 And so for the other thing to mention is for Skype. 04:56.760 --> 05:00.540 So link discover is the kind of auto discover service. 05:00.540 --> 05:05.620 And that actually points to the real server, which is what we want to hit. 05:05.620 --> 05:11.580 So that's why there's two kind of entries for Skype there. 05:12.620 --> 05:17.040 So we've now got Skype exchange, ADFS and RD web. 05:17.040 --> 05:23.820 So I'm going to show you a quick run through of username enumeration and password spraying, just to give you an idea. 05:23.820 --> 05:27.040 So smart enumeration, we'll leave it on the defaults. 05:27.040 --> 05:30.400 We're also going for password one, just kind of standard. 05:31.420 --> 05:34.800 So you see, there's quite a lot of usernames to try here. 05:34.800 --> 05:38.780 As it's going through, we found one of a particular format. 05:38.780 --> 05:42.800 So it's now continuing to loop through nine different formats. 05:43.480 --> 05:53.580 And you'll see that when we discover the correct format, then this will drop drastically, because then we switch to just using usernames of that format. 05:55.360 --> 05:57.780 So we've now got two of the same format. 05:57.780 --> 06:03.540 So first initial surname, and now we've got three. 06:03.540 --> 06:06.820 So you'll see that it's now selected that format of JSmith. 06:07.080 --> 06:17.560 So everything we do, oh sorry, if we left that continuing, it would just be, as you can see here, it's now less usernames, and it's just doing usernames of that format. 06:18.440 --> 06:22.660 So now I'll quickly show you a password spray as well. 06:23.020 --> 06:26.600 So I'll use that same format, JSmith. 06:27.460 --> 06:34.160 So for the password spray, that will now spray that in the kind of modern style username format. 06:34.160 --> 06:36.800 So jsmith at nevtech.nev. 06:36.820 --> 06:46.260 And we'll just try summer 2020, just to see if there happens to be a user who might have been daft enough to use that as a password. 06:48.710 --> 06:50.030 So here we go. 06:50.030 --> 06:51.870 So that's going to take a second. 06:52.050 --> 06:58.050 I'm sure we're not going to find anyone, because of course no one ever uses passwords like this. 06:58.210 --> 07:01.090 Who would possibly be that foolish? 07:01.910 --> 07:03.730 So here we go. 07:05.170 --> 07:10.830 If we give it another couple of seconds, you can see again, this is just doing that one username list. 07:10.830 --> 07:18.510 So obviously that's the same number of users total that it will be spraying as the smart enumeration was looking at. 07:20.920 --> 07:22.620 So it should be around about now. 07:22.620 --> 07:23.240 So there you go. 07:23.240 --> 07:26.740 So we've now uncovered one user with that password. 07:26.760 --> 07:33.340 We've used the RD web service, but obviously we could have sprayed that on any of these other services. 07:33.340 --> 07:42.560 And at the moment, looking at the internal domain information, we can probably assume that they're kind of be the same across all of them. 07:43.620 --> 07:44.300 Okay. 07:44.300 --> 07:46.180 So let's have a look. 07:46.180 --> 07:49.020 Let's just do one with Skype. 07:49.040 --> 07:49.320 So 07:57.540 --> 08:01.640 just to show you, you can also password spray enumerated users. 08:02.180 --> 08:04.400 So let's use that same. 08:12.180 --> 08:13.020 Okay. 08:13.160 --> 08:14.280 Okay. 08:14.660 --> 08:22.320 So for that option, then we were spraying the users in the legacy format, because those are the ones we've already enumerated. 08:22.820 --> 08:32.020 And for username enumeration, that's incredibly slow because for every invalid user, you might have to wait something like 20 or 30 seconds. 08:32.120 --> 08:39.940 When we're spraying this list of already enumerated users, then we kind of know already that they exist. 08:39.940 --> 08:46.660 And actually that's still quite fast, even when spraying in legacy format, because you're not having to wait for every invalid user. 08:47.220 --> 08:50.460 So obviously we've now got him as well. 08:50.460 --> 08:52.920 You can see we've got this access token here. 08:52.920 --> 08:55.800 So I'll quickly show you the address book. 08:55.840 --> 09:00.100 So we'll choose this user who we've already got the access token for. 09:00.100 --> 09:03.440 Again, I'll explain in more detail some of these other settings. 09:03.600 --> 09:07.240 But for now, we're just going to let this go, see what happens. 09:11.640 --> 09:15.100 I'm also going to come back to the meeting snooper later. 09:15.280 --> 09:20.660 So this is just to kind of show the address book functionality. 09:20.660 --> 09:21.840 Here we go. 09:28.170 --> 09:31.810 And so you can see now all of these other users popping up. 09:31.810 --> 09:36.890 So we get the SIP username, the email address, title, department. 09:37.430 --> 09:39.570 We can kind of tick these on and off. 09:39.590 --> 09:44.590 The default settings I've got here are basically the ones we can get relatively quickly. 09:45.750 --> 09:53.910 So if I actually expand that and choose to pull some of this other information, it can take quite a long time, especially with quite a large domain. 09:54.070 --> 09:56.730 So in this instance, we just go for the default. 09:56.730 --> 09:57.950 It's fairly quick. 09:58.810 --> 10:04.610 Obviously for my test lab, this is quite a small number of users, but there you go. 10:04.610 --> 10:08.130 You can see the general gist of what's possible with this tool. 10:08.530 --> 10:12.170 Okay, so now for some just general statistics. 10:12.170 --> 10:21.370 So first of all, I basically ran a version of this against the Alexa, well, the top 100,000 of the Alexa top a million. 10:21.370 --> 10:26.610 Of those, 11.79% were attackable at all. 10:27.790 --> 10:33.830 And so this shows that of that 11%, about 11%, so how many had each service. 10:33.830 --> 10:37.390 So obviously some could have had more than one service. 10:37.950 --> 10:43.970 This started, Carnivore started initially as a Skype attacking assessment tool. 10:43.970 --> 10:52.530 So that's secretly my favorite, but you can see it's kind of still getting beaten out by Exchange and ADFS, maybe not by all that much. 10:52.890 --> 11:07.510 So one caveat with the cloud element here is that there are some false positives in there, because for this assessment, I didn't explicitly check whether they were hosted in Office 365. 11:07.510 --> 11:15.010 So this is just listing if when I made a link discover request, did it come back and say it was hosted in the cloud. 11:15.430 --> 11:19.450 So actually that number might even be higher if we'd have explicitly asked. 11:19.730 --> 11:29.390 And for some of them, it kind of seems to suggest that they're hosted in the cloud, but then maybe everything isn't properly configured and that service isn't there. 11:29.810 --> 11:38.850 It's like I say, the cloud kind of maybe take with a pinch of salt, but the others, that's what was found and what was kind of verified as existing. 11:39.850 --> 11:45.590 So the first part, subdomain enumeration, we'll go into that in a little bit more detail. 11:47.530 --> 11:57.230 Okay, so as I said before, I split the username enumeration URL and the pass spray or the endpoint validation. 11:57.330 --> 12:14.270 Previously, it bailed if the username enumeration wasn't there, but then I found multiple times, and in fact on that wider kind of mass assessment I did, then quite often you would find an organization to have just one or just the other. 12:14.750 --> 12:25.950 So for example, here you can see actually there's 53% had a password spray endpoint over 47% with a username enumeration. 12:26.010 --> 12:31.710 So kind of 6% more had a password spray endpoint than had both. 12:31.710 --> 12:34.650 There were some that just had username enumeration. 12:34.770 --> 12:53.890 What's interesting about this is that it means that for those organizations with just a kind of weird password spray NTLM authentication endpoint somewhere, then it seems likely that they potentially might not even be aware of that because they've kind of firewalled off or hidden away all of the well-known, 12:53.890 --> 13:04.510 the username enumeration, the standard login points, but then they have this one password spray endpoint that kind of seems to have eluded that. 13:04.510 --> 13:06.270 So yeah, that's kind of interesting. 13:08.010 --> 13:12.350 So Carnival looks for subdomains in the order shown here. 13:12.350 --> 13:18.650 So these statistics are taken from that 11% of the 100,000. 13:18.930 --> 13:30.510 So hopefully it means that we'll do as few requests as possible because obviously we're looking at the one that's highly likely to exist and then only looking at the others if it doesn't. 13:30.830 --> 13:37.310 So in future I might add an option for a kind of, you know, you can choose between light or full enumeration. 13:37.330 --> 13:42.390 So maybe you could choose to just look at the top two and then discount it. 13:43.230 --> 13:50.510 And yeah, so then again, maybe managing to kind of cut that down even more as to how many requests you need to send. 13:51.190 --> 13:55.750 So now username enumeration in a little bit more detail. 13:56.730 --> 13:58.870 So we're going to start with a demonstration. 13:59.850 --> 14:04.010 Okay, so we've got various options here that I'm going to go through. 14:04.010 --> 14:07.450 So firstly, smart enumeration that we saw before. 14:07.450 --> 14:17.550 So basically that will take these nine different formats of username taken from the top statistically likely usernames lists. 14:17.990 --> 14:26.270 And it will basically try the top username in each list and then the top of the next list, top of the next list. 14:26.270 --> 14:31.850 And essentially as you saw before, it's looking for three valid usernames of the same format. 14:31.850 --> 14:38.190 So that's using the timing based difference, which is fairly well known for Skype and Exchange. 14:38.190 --> 14:42.130 I've added it here for ADFS and RDWeb as well. 14:42.910 --> 14:52.890 So we've got this advanced option here as well, that if you want, you can kind of pick a format and where you want to start in that list, or you can leave it as it is. 14:52.890 --> 14:57.470 You can also do an individual username, or you can provide your own list. 14:57.650 --> 14:59.890 Or there's these pre-built ones. 14:59.890 --> 15:02.610 So these are kind of standard and service accounts. 15:02.770 --> 15:07.010 And Council Killer was created by my colleague Owen Bellis. 15:07.070 --> 15:13.210 So that's kind of a list of maybe fairly standard user accounts that might be in there. 15:13.530 --> 15:15.710 So you can set the password. 15:15.710 --> 15:19.250 So obviously also it works on the timing based difference. 15:19.250 --> 15:22.810 And then also if you get the password right, then great. 15:23.290 --> 15:29.330 So again, I would just show you, obviously this is fairly similar to what we saw before. 15:29.590 --> 15:37.550 One interesting additional point to note is additional information you can get depending on the service. 15:37.550 --> 15:43.250 So for Skype, then we can actually determine quite a bit of additional information. 15:43.430 --> 15:51.990 So SIP enabled basically just means... so actually, sorry, some of these will only come up if you get the password right as well. 15:51.990 --> 15:59.470 So SIP enabled would mean you've got the username and the password right, and that user is basically set up on Skype. 15:59.650 --> 16:05.630 So account disabled, whatever password you give, you would get that if the account is disabled. 16:05.990 --> 16:07.910 You should see that in a second. 16:08.990 --> 16:10.630 Now that it's switched over... 16:12.770 --> 16:15.630 in fact, I might have re-enabled that user. 16:15.630 --> 16:27.110 But so basically if you get a disabled account, then essentially we won't do anything else with it because basically whatever you put in, you're not going to be able to kind of do anything. 16:28.190 --> 16:36.270 For Skype, you can also tell if the password's expired and it's possible that you might actually then be able to take that password. 16:36.430 --> 16:45.310 And if you found an endpoint, you know, maybe for the VPN, it might be you can even kind of put that password in and it will ask you to reset it. 16:45.390 --> 16:57.250 Obviously on a test, that's probably a little bit too crazy of a thing to do, maybe for a red team or with the kind of technical point of contacts, you know, green light. 16:57.730 --> 17:00.330 And then for Skype, we can also get this server error. 17:00.330 --> 17:02.570 But again, that means you've got the password right. 17:02.710 --> 17:06.250 And as I said before, you'll get the access token there if you do. 17:06.610 --> 17:09.150 So yeah, username enumeration. 17:09.330 --> 17:24.750 OK, so as you've just seen, smart enumeration will take nine lists of statistically likely usernames and it will go through those until it finds three of the same and then automatically select that format and then carry on. 17:24.750 --> 17:29.870 Now, one interesting thing is this difference between legacy and modern formats. 17:29.870 --> 17:32.610 So legacy is domain slash username. 17:32.610 --> 17:36.630 Modern kind of email style is username at domain. 17:36.790 --> 17:41.230 So that can match, that they can match, but they don't necessarily have to. 17:41.230 --> 17:46.150 And again, the modern format could match the email, but doesn't necessarily have to. 17:46.150 --> 17:53.030 Now for username enumeration, we can only use the legacy format and that's to get that timing based difference. 17:53.330 --> 18:00.470 So one interesting thing is that that causes a little hiccup when rolling over to password spraying. 18:00.770 --> 18:10.670 So previously I used username enumeration to discover the format and then just assumed that it would be the same for the modern format for when we spray. 18:10.810 --> 18:15.610 Now, because technically that might not be the case, I don't do that anymore. 18:15.610 --> 18:26.670 The problem is it means on password spraying, if you choose to use the discovered username format, then invalid usernames will still take ages to do. 18:26.670 --> 18:37.910 So what I would suggest as a way of doing this, because basically, yes, so username enumeration, every invalid user, 30 to 40 seconds. 18:37.910 --> 18:43.990 So if you waited for that to finish anyway, that's going to take the rest of the day, a couple of days. 18:44.050 --> 18:51.130 So ideally what you want to do anyway is use username enumeration to get the potential, the likely format. 18:52.070 --> 18:55.110 That might take five minutes, say. 18:55.110 --> 19:09.510 Then pause that, switch over to password spray, and then instead of using the discovered format, which because we've only discovered that in the legacy style, then that will take a long time. 19:09.510 --> 19:13.930 So instead, pick the same format and password spray those. 19:13.930 --> 19:22.290 Hopefully you should get some credentials or some invalid, sorry, disabled accounts, which give you a pointer that that is the correct format. 19:22.910 --> 19:27.450 But if you don't, then it is possible that the formats don't match. 19:27.570 --> 19:35.390 And you might need to do a little bit more kind of manual going through different potential formats to discover which it is. 19:35.490 --> 19:44.670 So the other thing to say is that, so obviously with username enumeration, we discover a valid username, even if the password is wrong. 19:44.870 --> 19:50.070 Whereas password spraying, we only find out anything if we get both correct. 19:50.790 --> 19:55.530 So you can, if you want to, stay with username enumeration. 19:55.530 --> 19:59.190 You get a nice list and it takes 48 hours. 19:59.190 --> 20:13.830 However, because you will essentially be hitting the same users with the password that you're trying, then actually in terms of progressing the test, then you're not going to really lose anything by switching over to password spraying. 20:13.830 --> 20:15.670 You'd be hitting the same users. 20:15.730 --> 20:20.090 So you're going to find the same users that might have password one as their password. 20:20.330 --> 20:23.350 Just it would take 10 minutes instead of two days. 20:23.550 --> 20:26.230 So yeah, so that would be my suggested method. 20:26.230 --> 20:40.650 So now I'm going to show where we get the time-based difference and some other things for ADFS and RDWeb, because I don't think there's much publicly written about those, whereas there is for Skype and Exchange. 20:40.650 --> 20:42.830 So this is maybe more interesting. 20:43.130 --> 20:47.370 So this is where we get the time-based difference for ADFS. 20:47.910 --> 20:58.410 Now for ADFS, there's this extra kind of interesting extra bit, which is that it needs an MSIS SAML cookie to be sent in the request. 20:58.410 --> 21:08.110 So basically, in order to get that, I first send the request here, sorry, to the same place, but with this single sign out parameter. 21:08.210 --> 21:19.350 And basically the response to that will give us the cookie that we need, which we then here include when we make a password guess, as you can see. 21:20.410 --> 21:25.070 And then here you'll see the invalid response. 21:25.190 --> 21:27.110 So it's just 200 OK. 21:28.430 --> 21:34.810 And so that's told us nothing, or with the timing difference, maybe it's told us if the user's valid. 21:35.570 --> 21:37.190 And this is a valid response. 21:37.190 --> 21:42.030 We get the 302 redirect, and it sets this MSIS auth cookie. 21:42.650 --> 21:46.690 So for RDWeb, we make a POST request like this. 21:46.690 --> 21:51.090 So there's the username and the password to this URL. 21:52.270 --> 21:55.990 And if it's invalid, then we get the 200 OK again. 21:55.990 --> 22:03.330 And for TSWA auth HTTP only cookie, that either isn't there or it's blank. 22:03.330 --> 22:07.570 So again, we can use timing-based difference with the username. 22:08.150 --> 22:21.690 Or if it's completely valid, so the username and password are correct, again, it's the 302 redirect, and that TSWA auth HTTP only cookie now has a value as shown there. 22:22.170 --> 22:24.130 OK, so now password spraying. 22:25.110 --> 22:30.310 So as I said before, there's a little hiccup here with the discovered format. 22:30.490 --> 22:41.910 So obviously, that's up to you if you want to stick with that discovered format, or just simply choose it from the list, and we'll spray that in the user at domain style instead. 22:42.430 --> 22:48.570 So for password spraying, it basically defaults to using that style if possible, because it's quicker. 22:49.230 --> 23:00.430 And also, if you provide a list of usernames, you can, if you want, provide it with domain slash user or user at domain, and it will use what you've given. 23:02.810 --> 23:04.390 So let me have a look. 23:04.390 --> 23:12.230 Yep, so also, as I said, you can use these pre-built lists if you want to go for that, or you can give it a file of your own. 23:12.430 --> 23:20.450 And as I've said, if you want to, you can kind of pre-add whatever you want in there, and it will use that instead. 23:20.450 --> 23:25.930 So another thing to say is that if you want to, you can just go straight to password spraying. 23:25.930 --> 23:29.010 You don't have to do the username enumeration first. 23:29.550 --> 23:35.830 So yeah, basically, if you've done the subdomain enumeration, you've got the internal domain information, you can just go straight here. 23:35.830 --> 23:42.310 Maybe you've done some OSINT, and you have an idea what the format might be, you can just go straight here and spray it. 23:42.870 --> 23:49.310 Okay, so now a little demonstration of password spraying, so I can show you that in a bit more detail as well. 23:49.430 --> 23:55.590 Okay, so as you can see here, the top option is use discovered username format. 23:55.590 --> 24:01.430 So if we'd already done the username enumeration, then we'd be able to basically just tip that here. 24:01.430 --> 24:05.850 And as I've said, that will spray in the legacy format, so you need to be careful. 24:06.130 --> 24:10.170 The other choice you've got is that you can just pick what list you want to spray. 24:10.470 --> 24:29.570 Again, you can spray these kind of inbuilt lists, you can give it a file of your own, or you can also spray just enumerated users, which again will use the username that we've already discovered, the format that we've already discovered that user in, because obviously we know that that exists. 24:29.750 --> 24:36.870 So again, you can put the password in here, that's obviously distinct to the username enumeration password. 24:37.170 --> 24:56.890 And then if I click spray, you'll see that this is much quicker, because this is able to be multi-threaded, you're not waiting to check that the kind of time-based information is accurate, which multi-threading the username enumeration can kind of throw that off, 24:56.890 --> 25:01.010 because you're making it do multiple ones at the same time. 25:01.330 --> 25:11.650 And as you can see, so it's gone through the list, and as we saw before, it's found this user and access token here, and we've also got one with the disabled account. 25:13.090 --> 25:16.790 Okay, so as you saw there, we've got these different columns. 25:16.850 --> 25:22.470 So for Office 365 spraying, I'll come on to how we do that at the end. 25:22.470 --> 25:43.290 But basically, if we can spray the Microsoft login portal, then we can determine a valid user versus an invalid user, and valid credentials versus invalid credentials, and we can also actually tell if you've got the right username and password, but the organization has MFA enabled. 25:44.510 --> 25:51.310 So SIP enabled just means they have Skype access, and then depending on the service, we can tell some additional things. 25:51.310 --> 25:58.750 So again, Skype is actually my favorite service to look at, because you can actually tell the most from Skype. 25:58.750 --> 26:06.210 So we can tell if the account's disabled, you can tell if they're SIP enabled, and you can tell if even if the password is expired. 26:06.210 --> 26:14.290 So you've got password right, but it's expired, and also this server error, we can still tell that that's a valid username and password. 26:14.610 --> 26:26.110 For Exchange and RDWeb, then we can also still tell if the password is expired or if it's correct, but not some of the additional information. 26:27.930 --> 26:40.630 So username enumeration is timing based, so I only have one location for each of those where that's possible, but for password spraying, there's multiple places we can kind of spray. 26:40.630 --> 26:48.550 So again, from the 100,000 that I looked at, that's where these statistics have come from. 26:48.550 --> 26:59.550 So this is the order in the subdomain enumeration, and when we're validating if the password spray endpoints there, this is the order that Carnivore will look for those in. 26:59.690 --> 27:08.950 Again, hopefully this will reduce how many requests we need to make, and in the future, again, maybe that advanced option to say just look at the top two. 27:08.950 --> 27:26.350 Obviously you can see here the top two would actually get the vast majority of, you know, would have found it in the vast majority of cases, and then we've got some where there's literally just one out of that 11% that had slash web ticket was there. 27:27.410 --> 27:40.130 So this is a mix of known endpoints, kind of publicly written about, ones taken from IIS, from the server itself, and which allow NTLM authentication. 27:40.130 --> 27:44.510 So NTLM authentication, I'm going to go into a bit more detail now. 27:44.630 --> 27:54.350 So yeah, so just to mention briefly, when I had a look, there kind of doesn't seem to be that much for NTLM, web-based NTLM authentication spraying. 27:54.350 --> 27:59.810 It's possible Hydra or something similar might do it, but there didn't seem to be that many tools for it. 27:59.810 --> 28:16.310 So here's a little bit of code, very simple for C-sharp, so we can literally just create the new network credential, give it the username and password, and then in response, if it's 401 unauthorized, it's bad, otherwise you're good to go. 28:17.590 --> 28:24.230 So yeah, incredibly simple, and Carnivore is able to password spray NTLM auth endpoints. 28:24.550 --> 28:35.450 So for those, you can still do the blank type one message, but actually, it's part of the protocol is kind of determining and including the domain name. 28:35.450 --> 28:48.510 So here, when we're giving the username and password, we can literally just say cscot password one, and actually, as part of this request, it will add the nevtech element of that. 28:48.910 --> 29:12.470 So an interesting thing to note is that, as I said before, when I included some NTLM authentication endpoints with the list of subdomains that I look at, then there were some quite big organizations where everything else seemed to not be accessible, and then you've got one kind of weird NTLM auth endpoint hidden away, 29:12.470 --> 29:17.930 meaning that they're still susceptible to password spraying against the internal domain. 29:18.130 --> 29:35.970 Essentially, I mean, this could even be used for denial of service, because yes, we hit the normal password lockout policies, but essentially, if you purposefully hit that, and you've locked out everyone in the domain, so that's obviously something that an organization would want to be aware of, 29:35.970 --> 29:39.750 because that would be a bad day for them as well. 29:39.970 --> 29:47.050 So a quick sidetrack into a note on some of these different services, just in case you haven't seen them before. 29:47.230 --> 29:56.710 So ADFS, it's a portal that can be present to allow you to sign into different third-party services. 29:56.890 --> 30:14.370 Sometimes these might be assumed to be internal, so on past red teams, then this is given access to full job posting applications, so third-party applications, that were linked to the company's Twitter and LinkedIn, all of their job postings. 30:14.410 --> 30:28.610 So obviously, for kind of phishing or ongoing attacks, then having access through ADFS to that company's kind of LinkedIn job postings, or even reputational damage, could have been fairly troubling. 30:28.610 --> 30:43.370 So basically, you go to the same URL that I gave earlier, and that would give, or would normally give a kind of drop-down list, where you'll see the different applications that you can authenticate into. 30:43.930 --> 30:49.510 So I've also seen internal service desks that you can get into. 30:49.510 --> 31:05.350 I was logging all call center queries, so that contained incredibly sensitive customer details and information, because it was everyone on their call center putting in, you know, this customer this bank account number, and this credit card number has this question. 31:05.350 --> 31:14.930 And that was basically accessible externally through ADFS, and also things like HR, user admin portals. 31:15.410 --> 31:30.810 And so one other thing to note there is that if it's Office 365 and federated equals win, so basically Office 365's password spraying avoidance and defense mechanisms are fairly brutal. 31:31.210 --> 31:40.770 But basically, if the organization is federated, it means that you, not just that you can, but that you have to hit the ADFS server. 31:40.990 --> 31:47.510 And the response to a request I'll show in a bit will tell you where that ADFS server is. 31:47.550 --> 32:01.630 And basically, yeah, so if that exists, it's actually a lot better for us, because it means we can avoid Office 365's robust defense mechanisms, and we're just hitting ADFS the same as we would before. 32:02.170 --> 32:05.050 And for RDP, that one's fairly simple. 32:05.050 --> 32:07.770 It's literally just remote desktop through the web. 32:07.850 --> 32:16.670 Depending on how that's configured, maybe you'll be able to RDP into a workstation in the domain, you know, things like that. 32:16.670 --> 32:19.990 And yeah, so hopefully you'll have seen Skype and Outlook before. 32:20.610 --> 32:27.270 So now, post-compromise, we're going to look at the address list pulling first with a quick demonstration. 32:27.810 --> 32:38.570 Okay, so just as a reminder, so this is used to pull the address book through the UCWA API, just to remind you what that looked like. 32:38.570 --> 32:40.730 So we have these options here. 32:40.730 --> 32:47.450 So if you untick both of those, that means you're just looking for the compromised user. 32:47.610 --> 32:53.570 Personal contacts is the personal contacts of that compromised user, so their favorites. 32:53.590 --> 33:05.510 That's an interesting one for, say, ongoing social engineering, because then you know, and from the other information you've got here, then you know, okay, my compromised user has this job. 33:05.510 --> 33:10.130 His favorites include these people, and they have these jobs. 33:10.130 --> 33:19.130 So in terms of kind of fashioning a good phishing payload, then obviously that would be incredibly useful. 33:19.230 --> 33:30.070 We can kind of run this on the personal contacts first, and then add in the full address list, just to make that distinction, or yes, just pick the full address list. 33:30.270 --> 33:38.550 The data here, as I said before, so the ones that are chosen by default, those are the ones that are quicker to get. 33:38.830 --> 33:48.430 So for some reason, the way that the UCWA API works, then we get different pieces of information depending on where we've queried that person. 33:48.470 --> 33:51.430 So if they're you, you get this information. 33:51.430 --> 33:54.110 If they're your personal contact, you get this information. 33:54.170 --> 33:57.830 If it's through the people search function, you get that information. 33:57.970 --> 34:02.630 So this is kind of the stripped down list of what you get in every case. 34:03.550 --> 34:11.610 Then if you want to kind of go on and pull everything back, we can, but that can take numerous additional requests per user. 34:12.550 --> 34:19.550 So obviously for a domain of say 6,000 people, that could take an incredibly long amount of time. 34:19.550 --> 34:26.890 So what we do is if we kick this off, I might have just missed the button, that's a good sign. 34:27.250 --> 34:39.790 So you'll see it will pull back the standard information for the users first, and then it will kick off some additional threads to pull that additional information. 34:40.270 --> 34:43.670 And then as we go, you'll see that start to fill in. 34:44.290 --> 34:47.410 And then I'll go over some of these things later. 34:47.410 --> 34:52.730 And the additional settings here, I'll go over in more detail. 34:53.250 --> 35:01.090 Okay, so as you just saw, the information that we can get back through Skype for Business is a bit of a social engineer's dream. 35:01.090 --> 35:10.930 So you've got the department, you've got the office location they work in, and you've got even whether they're online or offline. 35:11.210 --> 35:16.470 Additionally, this does say online mobile, online desktop. 35:16.490 --> 35:23.230 So I've never fully seen that work in a useful way, but that option's there. 35:23.550 --> 35:30.250 So we also get email address, phone number, and this note here is any status message that they've set. 35:30.570 --> 35:37.530 So those quite frequently I've seen people will put on there about annual leave, if they're going to be out of the office. 35:37.670 --> 35:47.910 So obviously, again, as far as social engineering goes, you know what office they're in, you know their name, email address, what their job title is, you know they're going to be out of the office. 35:48.090 --> 36:00.290 So quite a lot of information for maybe even being able to turn up and say, oh, I'm supposed to be meeting so-and-so or even impersonating someone and you know that they're definitely not going to be in the office. 36:01.790 --> 36:08.030 So as I was saying, the problem is some of this extra information does take a large number of additional requests. 36:09.130 --> 36:15.790 So yeah, by all means, tick all, but just beware, that might take a very long time. 36:16.810 --> 36:19.730 And yeah, those are the options you've got. 36:20.210 --> 36:28.550 So Carnivore pulls the internal address book back using people search on the UC with the UCWA API. 36:28.550 --> 36:33.970 So this does mean that we're essentially having to search letter by letter, A through Z. 36:34.370 --> 36:48.250 However, there's an upper limit of 100 on the amount of responses it returns, and there isn't a next link that we can say, here's the first 100, now go to the next link for the next, you know, however many and so on. 36:48.610 --> 36:55.390 So basically, what we have to resort to is searching by digraphs and trigraphs. 36:55.390 --> 37:02.210 So essentially, A, B, A, C, A, D, and then even A, B, C, A, B, D, A, B, E. 37:03.070 --> 37:23.690 And so basically, we can then take either from the top statistically likely usernames list, we can do all of the likely and unique kind of three letters that are there, or you can do all possible two character combinations. 37:24.110 --> 37:34.730 So what's interesting and fun about the UCWA API is that there doesn't seem to be much rhyme or reason as to the way that works in terms of what we get back. 37:35.050 --> 37:44.910 So to take an example, if we're looking for every pull in the domain, so we know that there's four, and we search for P, you get back 150 results. 37:44.910 --> 37:48.110 So we're just going to get the top 100, there's two pulls in there. 37:48.110 --> 37:53.570 So then we search for PA, we get back 20 results, but this time there's three pulls. 37:53.570 --> 38:01.370 So we've got one extra, but for some reason, even though we haven't hit the upper limit, we've still not actually got back every pull who's in the domain. 38:01.370 --> 38:08.350 So then we search for PAU, and now we get this mysterious rogue fourth pull that we've never seen before. 38:08.490 --> 38:15.930 So essentially, in the interest of me keeping my sanity, I've stuck with diagraphs and trigraphs. 38:15.930 --> 38:22.530 It's possible you might want to go on and do quad graphs and quint graphs and whatever else they're called. 38:22.530 --> 38:38.430 However, so when I looked at this with the common trigraphs, and then with every possible three character combination, that actually only added an additional, I think it was maybe even one user, in a domain of 6,000. 38:38.610 --> 38:48.870 And the difference is common does 2,249 requests, whereas every possible was about 17,500. 38:48.890 --> 38:57.750 So all of that for one additional user that, as I've said, was kind of hiding away, and we weren't able to get otherwise. 38:57.750 --> 39:03.410 So essentially, hopefully that explains the kind of options on the address list a little bit more. 39:05.010 --> 39:07.790 One additional kind of side note. 39:07.790 --> 39:26.000 So it's fairly uncommon, but I've seen it where a misconfigured Microsoft web app proxy basically meant that when you auth to the first server, and it gives you back the token, and then you try and use that against the application's endpoint, then it essentially sends it to the wrong place, 39:26.000 --> 39:31.740 or you've been authed to the wrong box, and so it then doesn't like it. 39:31.740 --> 39:40.080 That actually also stops the legitimate Skype client from being able to authenticate, you know, to Skype. 39:40.080 --> 39:43.640 However, now Carnivore is able to detect that. 39:43.640 --> 39:46.680 It re-auths to the correct box and carries on. 39:46.680 --> 39:54.940 So basically Carnivore is able to connect and carry on using the API, even when the legitimate client actually couldn't. 39:55.560 --> 40:00.320 Okay, so now the final post-compromise function, which is MeetingSnooper. 40:00.520 --> 40:06.740 So unfortunately, my lab servers stopped working for this, so we have to make do with screenshots. 40:08.380 --> 40:13.820 Okay, so as you can see here, this is the MeetingSnooper tab. 40:13.820 --> 40:29.520 So once you've compromised the user, if you've got Skype available, so this uses the UCWA API as well, then you can go here and you have to choose, you have to pick the compromised user that you want to use there. 40:30.200 --> 40:36.820 So now we can either choose, basically we can do this for all compromised users or just a selected user. 40:37.440 --> 40:44.000 Now one thing to say is that this only picks up currently scheduled meetings, obviously. 40:44.020 --> 40:55.840 So basically we can run this throughout the day multiple times or, you know, at the start of the day you could run it, see if any new meetings have been added, and then kind of keep running it to pull back new information. 40:57.300 --> 41:01.840 So first of all, it dumps the standard dial-in information to the output log. 41:01.840 --> 41:07.480 So if you've ever had an email inviting you to a Skype meeting, this will look fairly familiar to you. 41:07.480 --> 41:13.780 So you've got the internal number you can dial and then a number for each country or city within that country. 41:15.760 --> 41:19.720 And so now apologies for how utterly rubbish this looks. 41:19.740 --> 41:24.740 As I said, my training lab unfortunately kind of packing in at the key moment there. 41:25.080 --> 41:37.340 But yeah, so to stress this isn't an exploit or a zero day, it's basically highlighting what's already possible through kind of weaponization of the UCWA API for attackers. 41:37.340 --> 41:55.860 Obviously it does depend on compromised credentials, but basically so far this tool has shown how we can go from external over the internet to kind of complete compromise and to this point of being able to dump out scheduled meetings for compromised users. 41:55.860 --> 42:07.120 So one thing to say is that when kind of using this tool on jobs, then often you find if you're going to get anyone, you probably are going to get like 50 to 100 users. 42:07.360 --> 42:21.140 And obviously in that case, then this becomes more interesting because, you know, one user might have one meeting that week, but if you've got 50 users, then maybe you've got someone who's a little bit more interesting. 42:21.720 --> 42:32.220 So you can then see here what happens when you run this tool is that it gives you information for each meeting that compromised user has scheduled. 42:32.240 --> 42:35.320 So the conference ID there is the PIN. 42:35.320 --> 42:43.460 So basically when you dial in, you dial into the phone number and it asks you for a PIN and that's that conference ID. 42:43.620 --> 42:46.760 And basically that conference ID is unique to that user. 42:46.760 --> 42:53.500 So when you dial in, you'll be impersonating whoever it is that you've compromised. 42:53.980 --> 43:01.880 So for example, you dial in, then you show up as being, say, a Chris Nevin guest. 43:02.100 --> 43:13.840 Now, obviously, if the people in the meeting are kind of using the desktop application, then maybe it would look weird to have multiple Chris Nevin guests there. 43:14.020 --> 43:19.700 If everyone's using the phone to dial in, I'm not sure that they would notice this at all. 43:20.400 --> 43:35.540 And in fact, even if they did see these two Chris Nevin guests, how likely is it that people are going to assume, oh, this is someone impersonating and joining in and listening, as opposed to maybe there's some weird bug that's happening. 43:36.320 --> 43:41.520 So the information we get here includes the subject of the meeting and the attendees. 43:41.680 --> 43:48.980 So obviously these meetings here I've scheduled just to kind of demonstrate, but obviously this could be a lot more juicy. 43:49.020 --> 43:54.700 So for example, you've compromised a user, you know from their address book that they're the head of financial fraud. 43:54.700 --> 44:00.600 And this meeting subject shows it's the weekly financial crime investigation update. 44:00.700 --> 44:06.740 So obviously you can see why this would be kind of concerning for an organization if this was possible. 44:06.740 --> 44:24.500 And because, again, without any exploit, any need for any further phishing or payloads being executed, you've basically gone from being over the internet to being able to listen in on and even record the sensitive meetings, essentially impersonating that user. 44:25.740 --> 44:29.800 So on the right, you can see the lobby bypass enabled. 44:29.800 --> 44:34.460 That basically means that if you dial in, does it bypass the lobby? 44:34.460 --> 44:40.740 If that's enabled, that means you're not even in a waiting room that someone has to let you in. 44:41.580 --> 44:49.100 So the join URL, if you go to that, you can join the meeting and you can basically enter a name of your choice. 44:49.180 --> 44:57.420 So obviously one thing you could do is, again, you've done the address book, you know, is there a social engineering angle? 44:57.420 --> 45:00.900 Maybe you could kind of choose your name based on that. 45:01.120 --> 45:10.860 Potentially it might be more likely to get caught, whereas actually just dialing in and there being two of the compromised user is maybe less troubling. 45:11.640 --> 45:18.080 So another thing to say is that the API basically only seems to give the meeting expiry. 45:18.080 --> 45:21.060 So that's two weeks after the meeting ends. 45:21.060 --> 45:31.560 So Carnivore will take off, it will remove the two weeks for you automatically, and then it's kind of maybe you'll need to do some kind of common sense around that. 45:31.560 --> 45:35.080 So for example, you see the top meeting there. 45:35.400 --> 45:39.700 All we actually have been able to is that the meeting ends at 11.30. 45:39.700 --> 45:44.620 Now I've set the subject for that one to be the time while I was troubleshooting. 45:44.800 --> 45:48.020 So you can see that actually that meeting starts at 11. 45:48.600 --> 45:53.260 As I say, normally you wouldn't get that information because that's the subject. 45:53.440 --> 46:01.120 So obviously, yeah, if you apply some common sense to it, then you can see, OK, the meeting ends at 11.30. 46:01.120 --> 46:04.820 It probably starts at 11 or even 10.30. 46:05.920 --> 46:11.400 So yeah, so that's the meeting snooping, what you get back from it basically. 46:11.520 --> 46:19.380 So there are a couple of extra points to mention, which are that this only seems to be able to pull back self-scheduled meetings. 46:19.680 --> 46:26.680 So again, doesn't fully make sense to me because obviously in Outlook or something, you don't just see meetings you've scheduled. 46:26.680 --> 46:31.120 You see every meeting that you're scheduled to be a part of. 46:31.380 --> 46:34.400 Unfortunately, we're not able to get that through this tool. 46:35.140 --> 46:40.300 And so, yeah, and then also meeting end time only, as I said before. 46:40.620 --> 46:43.240 Now, there are some weird edge cases with that. 46:43.240 --> 46:47.040 So, for example, I set a recurring meeting. 46:47.040 --> 46:55.260 And so the only information we get back is that it ends on the 26th of December 2022, which obviously isn't that useful. 46:55.340 --> 46:58.100 Again, maybe you could figure out, OK, that's a Friday. 46:58.100 --> 46:59.400 It's at half ten. 46:59.400 --> 47:01.280 So maybe it's every Friday. 47:01.480 --> 47:05.440 But again, we can't get that back through the API, unfortunately. 47:06.360 --> 47:08.260 OK, so Office 365. 47:08.740 --> 47:10.820 So I'm not going to demo this. 47:10.820 --> 47:14.460 So what I've been showing so far is basically just my lab. 47:14.960 --> 47:21.300 And so, yeah, we're not going to demo Office 365, but I'm going to talk you through how Carnivore works. 47:21.560 --> 47:30.820 So, for example, or sorry, one thing to say is that username enumeration that doesn't require a password guess has been quite widely covered. 47:30.820 --> 47:35.520 So there's things like O365 or O365enum. 47:35.520 --> 47:40.980 So I'm just going to quickly kind of get into password spraying and give some key pointers. 47:42.040 --> 47:45.180 So, as I said before, federated is a win. 47:45.180 --> 47:50.460 So just the usual Active Directory rules will apply to lockouts. 47:50.520 --> 47:57.820 But again, that kind of doesn't include the extremely robust Office 365 rules. 47:58.020 --> 48:06.680 So, as I've said, there's a link that I'm about to show you where you can find out if an organization is federated or not. 48:06.680 --> 48:12.600 If it is, you'll get back the ADFS server location and Carnivore will add that automatically. 48:13.120 --> 48:27.640 So if it's not federated, we can still spray, sorry, we have to spray the Office portal, but then we can also determine if a user and password is valid, even if we have MFA on there. 48:27.680 --> 48:38.620 I'm sorry, I should have said again, with federated, if it's federated, you have to spray ADFS and you can't spray the Office portal and you won't get back anything interesting, anything useful. 48:38.960 --> 48:42.500 So password spray counter measures for Office 365. 48:42.920 --> 48:49.360 So they have things like trusted versus untrusted network, have separate bad password counts. 48:49.420 --> 49:02.260 So again, if you're from the untrusted side, which presumably you would be from an untrusted network, then, you know, your password spray is adding to account of everyone else in the world. 49:02.260 --> 49:07.580 So again, lockout is fairly frequent and quick. 49:08.160 --> 49:17.360 But from the Microsoft side, obviously that's designed so that then the genuine user can still sign in while on their corporate VPN or something like that. 49:17.460 --> 49:22.900 So obviously good security measures, but difficult from a red team perspective. 49:23.900 --> 49:28.220 So first of all, to find out if the organization is federated. 49:28.260 --> 49:30.260 So this is an example request here. 49:30.260 --> 49:32.800 So the username itself is irrelevant. 49:32.800 --> 49:36.440 It's just the appdomain.com that we're looking for. 49:38.320 --> 49:40.000 And the response here. 49:40.020 --> 49:44.880 So if they were federated, that would say federated instead of managed. 49:45.000 --> 49:49.140 And it can also include some kind of boilerplate text. 49:49.220 --> 49:52.800 So, for example, is keep me signed in disabled? 49:52.980 --> 50:07.300 Obviously, that one might be interesting from a red team perspective, because maybe it hints that they have fairly good security and they've had their configuration looked at because users can't just stay signed in forever. 50:07.820 --> 50:15.940 You also get the federation brand name there, and you can get back, you know, logo information and that kind of thing. 50:16.220 --> 50:25.640 So also, if they said federated, then we would see the location of the ADFS authentication endpoint there as well. 50:26.920 --> 50:31.340 So for password spraying, this is how Carnivore does it. 50:31.340 --> 50:34.080 So this is the endpoint that we're hitting. 50:34.360 --> 50:37.060 There's the username and the password. 50:37.280 --> 50:45.280 So the client ID and the scope, obviously, that could be tweaked to maybe be a little bit more realistic or representative. 50:45.280 --> 50:47.920 But this is what Carnivore uses. 50:49.320 --> 50:52.920 And so this first one is if there's an invalid password. 50:52.920 --> 50:57.900 Now, obviously, the actual response here says invalid username or password. 50:57.900 --> 51:01.820 So obviously, that seems like maybe that's going to be a bit tricky for us. 51:01.820 --> 51:03.820 Is it the username or is it the password? 51:03.820 --> 51:05.280 We're not fully sure. 51:05.960 --> 51:09.780 But then if the username is incorrect, then we get this message back. 51:09.780 --> 51:13.820 The user account does not exist in that directory. 51:13.980 --> 51:19.540 So obviously, from that, we can tell the previous response means the password's wrong, not the username. 51:19.900 --> 51:24.780 And just to also mention there where it says email hidden, I've not added that. 51:24.780 --> 51:26.540 That's the actual response. 51:27.020 --> 51:31.140 So then this is a valid user and password without NFA. 51:31.340 --> 51:36.180 So again, this is specific to the request that I make in Carnivore. 51:36.280 --> 51:53.160 So because we gave a client ID that doesn't exist, then if the username and password is correct, you'd get this unauthorized client and a message that that application doesn't exist, because obviously, it's not a proper client ID. 51:55.060 --> 52:02.280 And again, so if it's valid user and password with MFA, then again, we get this invalid grant. 52:02.280 --> 52:08.880 But now it's telling us that it's due to configuration, meaning that you need to supply multi-factor authentication. 52:09.100 --> 52:13.200 So again, username and password is correct, but you need MFA. 52:14.840 --> 52:17.440 So outro very briefly. 52:17.880 --> 52:22.180 Yes, so almost forgot to put it in, but here's a link to the tool itself. 52:22.360 --> 52:31.600 So obviously you can go there and download the latest version and any issues or anything that you want to bring up there, I'll be happy to try and help wherever I can. 52:31.720 --> 52:32.900 So thank you for listening. 52:32.900 --> 52:36.800 Hopefully it's been useful and enjoy carnivoring.