start	end	text
780	7780	Hello, my name is Chris Nevin and I work for NCC Group. So this tool is called Carnivore,
7780	14120	so that's a Microsoft external attack tool or assessment tool. So the cryptozoologists
14120	20720	amongst you might know this, so that spells meat, so that's very amusing. And it's basically a tool
20720	26680	to help pen testers find misconfigurations and vulnerabilities in Microsoft on-premises
27220	33480	servers. So also apologies if I talk quickly, but there is quite a lot to get through.
35080	40160	So the basic outline of the presentation. So I'm going to start with a demonstration just
40160	44580	to show what the tool can do and then dive a bit deeper into some of the techniques
45160	52340	and the research behind them after that. So now intro demonstration.
52960	59360	Okay, so first a quick overview just to give you a taste of what the tool can do. So just before
59360	64700	I kick it off, we've selected all services and we're also going to attempt to discover the
64700	71580	internal domain information. You might notice that it's a .nev domain. Obviously that wouldn't
71580	77900	normally be a top-level domain, but this is my training lab. So first of all, it's going to
80100	86260	do DNS lookups for subdomains, which are normally connected with a particular service. So for
86260	91960	example, link discover with Skype, then it verifies there's something there. So it's not just a wild
91960	98780	card resolution. And then it also does some checks to make sure, does it also actually seem to be an
98780	107660	exchange or a Skype server? So I've also built in some kind of bailout options. So for example,
107660	112480	we get back a server header saying that it's Nginx. It's not even Windows. We don't need to
112480	120220	test every possible endpoint just in case one of them is a Skype server. So yes, that's something
120220	127340	that we do. So it also validates the username enumeration and the password spray URL separately.
127720	134940	I'll come on to that in a little bit, but basically there are occasions where an organization might
134940	141320	have hidden most things, but there'll be one password spray URL kind of hidden away. So we try
141320	146860	the most obvious, and then if they don't hit, there are other kind of password spray endpoints
146860	152980	that are possible. So yeah, so hopefully if an organization has something exposed, then we'll be
152980	160980	able to find it to report to them. So we also log everything here, and you've got export options
161640	169860	if you want to kind of manually export things for some reason. I'll cover Office 365 more at the end,
169860	177600	but for this section, if Office 365 is ticked, then it will explicitly check if this has any
177600	183340	kind of cloud presence. Even if it's not ticked, then the response to Skype for Business, for
183340	188940	example, might come back and say, I'm hosted in the cloud, and then we'll still do the standard
189460	195560	checks for, is it federated, and that kind of thing. And then it will add, so say we just did
195560	200280	Skype for Business, it says it's in the cloud, it turns out it's federated, we'll get an Office 365
200280	209780	and an ADFS option here. So okay, so we've also got global verbosity here, so you can kind of
210320	217900	tweak that up and down depending on what you want to see. Okay, so let me kick this off.
219280	225540	Okay, so the other thing with this discover internal domain, then it does the fairly
225540	232680	standard blank type one NTLM message. And you can see it's pulled back the internal domain name.
232680	238360	So at the moment, it does that individually for each of these services. And that's because,
238360	245080	you know, Skype might be hosted in Germany, and ADFS server, the ADFS server might be in Canada
245080	250800	for some reason. And so when you're hitting, when you're spraying that server, then you've
250800	256780	got the internal domain information for the particular server that you're hitting. And
256780	263240	in fact, even on a job just last week, then these were all different. So it does happen quite
263240	269320	frequently, I might add some kind of advanced options. So you can say, just assume they're all
269320	277320	same. But like say, that's maybe, you know, a recipe for potential disaster. So okay, we've also
277320	282360	got the IP addresses here. So you can obviously check those against your scope. And if you want
282360	287740	to, you can kind of run this once, check the IP addresses against your scope, and then do the more
287740	296760	active kind of blank NTLM one message. And so for the other thing to mention is for Skype.
296760	302620	So link discover is the kind of auto discover service. And that actually points to the real
302620	311580	server, which is what we want to hit. So that's why there's two kind of entries for Skype there.
312620	319620	So we've now got Skype exchange, ADFS and RD web. So I'm going to show you a quick run through of
319620	325400	username enumeration and password spraying, just to give you an idea. So smart enumeration, we'll
325400	332120	leave it on the defaults. We're also going for password one, just kind of standard. So you see,
332120	338000	there's quite a lot of usernames to try here. As it's going through, we found one of a particular
338000	344840	format. So it's now continuing to loop through nine different formats. And you'll see that when
344840	351240	we discover the correct format, then this will drop drastically, because then we switch to just
351240	359320	using usernames of that format. So we've now got two of the same format. So first initial surname,
361980	366820	and now we've got three. So you'll see that it's now selected that format of JSmith.
367080	373000	So everything we do, oh sorry, if we left that continuing, it would just be, as you can see here,
373000	379720	it's now less usernames, and it's just doing usernames of that format. So now I'll quickly
379720	388520	show you a password spray as well. So I'll use that same format, JSmith. So for the password
388520	395340	spray, that will now spray that in the kind of modern style username format. So jsmith at
395340	402640	nevtech.nev. And we'll just try summer 2020, just to see if there happens to be a user
402640	406260	who might have been daft enough to use that as a password.
408710	414250	So here we go. So that's going to take a second. I'm sure we're not going to find anyone, because
414250	423730	of course no one ever uses passwords like this. Who would possibly be that foolish? So here we go.
425170	429590	If we give it another couple of seconds, you can see again, this is just doing that one
429590	434830	username list. So obviously that's the same number of users total that it will be spraying as
434830	443240	the smart enumeration was looking at. So it should be around about now. So there you go.
443240	449100	So we've now uncovered one user with that password. We've used the RD web service,
449100	454860	but obviously we could have sprayed that on any of these other services. And at the moment,
454860	460340	looking at the internal domain information, we can probably assume that they're kind of
460340	469320	be the same across all of them. Okay. So let's have a look. Let's just do one with Skype. So
477540	484400	just to show you, you can also password spray enumerated users. So let's use that same.
492180	499560	Okay. Okay. So for that option, then we were spraying the users in the legacy format,
499560	505760	because those are the ones we've already enumerated. And for username enumeration,
505760	510680	that's incredibly slow because for every invalid user, you might have to wait something like 20
510680	516680	or 30 seconds. When we're spraying this list of already enumerated users, then we kind of know
518120	523600	already that they exist. And actually that's still quite fast, even when spraying in legacy format,
523600	530220	because you're not having to wait for every invalid user. So obviously we've now got him as
530220	535800	well. You can see we've got this access token here. So I'll quickly show you the address book.
535840	541500	So we'll choose this user who we've already got the access token for. Again, I'll explain in more
541500	547240	detail some of these other settings. But for now, we're just going to let this go, see what happens.
551640	556660	I'm also going to come back to the meeting snooper later. So this is just to kind of show
558320	571050	the address book functionality. Here we go. And so you can see now all of these other users
571050	578730	popping up. So we get the SIP username, the email address, title, department. We can kind of tick
578730	583710	these on and off. The default settings I've got here are basically the ones we can get relatively
583710	590570	quickly. So if I actually expand that and choose to pull some of this other information, it can
590570	596150	take quite a long time, especially with quite a large domain. So in this instance, we just go for
596150	603550	the default. It's fairly quick. Obviously for my test lab, this is quite a small number of users,
603550	608130	but there you go. You can see the general gist of what's possible with this tool.
608530	616230	Okay, so now for some just general statistics. So first of all, I basically ran a version of this
616230	624110	against the Alexa, well, the top 100,000 of the Alexa top a million. Of those, 11.79%
624110	630970	were attackable at all. And so this shows that of that 11%, about 11%,
631510	637390	so how many had each service. So obviously some could have had more than one service.
637950	644750	This started, Carnivore started initially as a Skype attacking assessment tool. So that's
644750	650210	secretly my favorite, but you can see it's kind of still getting beaten out by Exchange and ADFS,
650210	658550	maybe not by all that much. So one caveat with the cloud element here is that there are some
658550	665050	false positives in there, because for this assessment, I didn't explicitly check whether
665050	672250	they were hosted in Office 365. So this is just listing if when I made a link discover request,
672250	677170	did it come back and say it was hosted in the cloud. So actually that number might even be
677170	682430	higher if we'd have explicitly asked. And for some of them, it kind of seems to suggest that
683250	687310	they're hosted in the cloud, but then maybe everything isn't properly configured and
687310	693990	that service isn't there. It's like I say, the cloud kind of maybe take with a pinch of salt,
693990	698850	but the others, that's what was found and what was kind of verified as existing.
699850	705590	So the first part, subdomain enumeration, we'll go into that in a little bit more detail.
707530	715570	Okay, so as I said before, I split the username enumeration URL and the pass spray or the endpoint
715570	720790	validation. Previously, it bailed if the username enumeration wasn't there,
720790	728590	but then I found multiple times, and in fact on that wider kind of mass assessment I did,
728590	734270	then quite often you would find an organization to have just one or just the other.
734750	743650	So for example, here you can see actually there's 53% had a password spray endpoint over 47%
743650	751710	with a username enumeration. So kind of 6% more had a password spray endpoint than had both.
751710	756250	There were some that just had username enumeration. What's interesting about this is that
756250	762390	it means that for those organizations with just a kind of weird password spray NTLM authentication
762390	768610	endpoint somewhere, then it seems likely that they potentially might not even be aware of that
768610	773890	because they've kind of firewalled off or hidden away all of the well-known,
773890	780190	the username enumeration, the standard login points, but then they have this one password
780190	786270	spray endpoint that kind of seems to have eluded that. So yeah, that's kind of interesting.
788010	795250	So Carnival looks for subdomains in the order shown here. So these statistics are taken from
795250	802290	that 11% of the 100,000. So hopefully it means that we'll do as few requests as possible
802290	808930	because obviously we're looking at the one that's highly likely to exist and then only looking at
808930	814650	the others if it doesn't. So in future I might add an option for a kind of, you know, you can
814650	820210	choose between light or full enumeration. So maybe you could choose to just look at the top
820210	828230	two and then discount it. And yeah, so then again, maybe managing to kind of cut that down even more
828230	835750	as to how many requests you need to send. So now username enumeration in a little bit more detail.
836730	842850	So we're going to start with a demonstration. Okay, so we've got various options here that I'm
842850	848770	going to go through. So firstly, smart enumeration that we saw before. So basically that will take
849410	855090	these nine different formats of username taken from the top statistically likely
855830	864530	usernames lists. And it will basically try the top username in each list and then the top of
864530	869850	the next list, top of the next list. And essentially as you saw before, it's looking for three valid
869850	875930	usernames of the same format. So that's using the timing based difference, which is fairly well
875930	883850	known for Skype and Exchange. I've added it here for ADFS and RDWeb as well. So we've got this
883850	888910	advanced option here as well, that if you want, you can kind of pick a format and where you want
888910	895530	to start in that list, or you can leave it as it is. You can also do an individual username, or you
895530	900930	can provide your own list. Or there's these pre-built ones. So these are kind of standard
900930	907730	and service accounts. And Council Killer was created by my colleague Owen Bellis. So that's
907730	914670	kind of a list of maybe fairly standard user accounts that might be in there. So you can set
914670	920730	the password. So obviously also it works on the timing based difference. And then also if you get
920730	927830	the password right, then great. So again, I would just show you, obviously this is fairly similar to
927830	935630	what we saw before. One interesting additional point to note is additional information you can
935630	941990	get depending on the service. So for Skype, then we can actually determine quite a bit of additional
941990	949590	information. So SIP enabled basically just means... so actually, sorry, some of these will only come up
949590	954910	if you get the password right as well. So SIP enabled would mean you've got the username and
954910	961310	the password right, and that user is basically set up on Skype. So account disabled, whatever
961310	967910	password you give, you would get that if the account is disabled. You should see that in a second.
968990	970630	Now that it's switched over...
972770	978350	in fact, I might have re-enabled that user. But so basically if you get a disabled account,
978350	984350	then essentially we won't do anything else with it because basically whatever you put in, you're
984350	991190	not going to be able to kind of do anything. For Skype, you can also tell if the password's expired
991710	997130	and it's possible that you might actually then be able to take that password. And if you found an
997130	1003190	endpoint, you know, maybe for the VPN, it might be you can even kind of put that password in and it
1003190	1009750	will ask you to reset it. Obviously on a test, that's probably a little bit too crazy of a thing
1009750	1017250	to do, maybe for a red team or with the kind of technical point of contacts, you know, green light.
1017730	1021330	And then for Skype, we can also get this server error. But again, that means you've got the
1021330	1027490	password right. And as I said before, you'll get the access token there if you do. So yeah,
1027490	1034970	username enumeration. OK, so as you've just seen, smart enumeration will take nine lists of
1034970	1040550	statistically likely usernames and it will go through those until it finds three of the same
1040550	1046470	and then automatically select that format and then carry on. Now, one interesting thing is this
1046470	1053470	difference between legacy and modern formats. So legacy is domain slash username. Modern kind of
1053470	1059630	email style is username at domain. So that can match, that they can match, but they don't
1059630	1064970	necessarily have to. And again, the modern format could match the email, but doesn't necessarily
1064970	1071250	have to. Now for username enumeration, we can only use the legacy format and that's to get that
1071250	1078510	timing based difference. So one interesting thing is that that causes a little hiccup when rolling
1078510	1085210	over to password spraying. So previously I used username enumeration to discover the format
1085210	1091130	and then just assumed that it would be the same for the modern format for when we spray. Now,
1091130	1096810	because technically that might not be the case, I don't do that anymore. The problem is it means
1096810	1103590	on password spraying, if you choose to use the discovered username format, then invalid usernames
1103590	1112610	will still take ages to do. So what I would suggest as a way of doing this, because basically,
1113010	1119410	yes, so username enumeration, every invalid user, 30 to 40 seconds. So if you waited for that to
1119410	1124790	finish anyway, that's going to take the rest of the day, a couple of days. So ideally what you
1124790	1131130	want to do anyway is use username enumeration to get the potential, the likely format.
1132070	1138430	That might take five minutes, say. Then pause that, switch over to password spray,
1138990	1145490	and then instead of using the discovered format, which because we've only discovered that in the
1145490	1152650	legacy style, then that will take a long time. So instead, pick the same format and password
1152650	1158350	spray those. Hopefully you should get some credentials or some invalid, sorry, disabled
1158350	1164890	accounts, which give you a pointer that that is the correct format. But if you don't, then it is
1164890	1170290	possible that the formats don't match. And you might need to do a little bit more kind of manual
1170290	1176630	going through different potential formats to discover which it is. So the other thing to say
1176630	1183390	is that, so obviously with username enumeration, we discover a valid username, even if the password
1183390	1190070	is wrong. Whereas password spraying, we only find out anything if we get both correct.
1190790	1198350	So you can, if you want to, stay with username enumeration. You get a nice list and it takes 48
1198350	1204070	hours. However, because you will essentially be hitting the same users with the password that
1204070	1211410	you're trying, then actually in terms of progressing the test, then you're not going to really lose
1211410	1216130	anything by switching over to password spraying. You'd be hitting the same users. So you're going
1216130	1221410	to find the same users that might have password one as their password. Just it would take 10
1221410	1227390	minutes instead of two days. So yeah, so that would be my suggested method. So now I'm going to
1227390	1234130	show where we get the time-based difference and some other things for ADFS and RDWeb, because I
1234130	1240650	don't think there's much publicly written about those, whereas there is for Skype and Exchange.
1240650	1247370	So this is maybe more interesting. So this is where we get the time-based difference for ADFS.
1247910	1253310	Now for ADFS, there's this extra kind of interesting extra bit, which is that it needs
1253310	1261770	an MSIS SAML cookie to be sent in the request. So basically, in order to get that, I first send
1261770	1268630	the request here, sorry, to the same place, but with this single sign out parameter. And basically
1268630	1275650	the response to that will give us the cookie that we need, which we then here include when we make
1275790	1286250	a password guess, as you can see. And then here you'll see the invalid response. So it's just 200
1286250	1293510	OK. And so that's told us nothing, or with the timing difference, maybe it's told us if the
1293510	1302030	user's valid. And this is a valid response. We get the 302 redirect, and it sets this MSIS auth cookie.
1302650	1311090	So for RDWeb, we make a POST request like this. So there's the username and the password to this URL.
1312270	1320290	And if it's invalid, then we get the 200 OK again. And for TSWA auth HTTP only cookie,
1320290	1325590	that either isn't there or it's blank. So again, we can use timing-based difference
1325590	1332750	with the username. Or if it's completely valid, so the username and password are correct,
1332750	1341690	again, it's the 302 redirect, and that TSWA auth HTTP only cookie now has a value as shown there.
1342170	1348550	OK, so now password spraying. So as I said before, there's a little hiccup here with
1348550	1353710	the discovered format. So obviously, that's up to you if you want to stick with that discovered
1353710	1360810	format, or just simply choose it from the list, and we'll spray that in the user at domain style
1360810	1367110	instead. So for password spraying, it basically defaults to using that style if possible,
1367110	1375710	because it's quicker. And also, if you provide a list of usernames, you can, if you want,
1375710	1380430	provide it with domain slash user or user at domain, and it will use what you've given.
1382810	1387270	So let me have a look. Yep, so also, as I said, you can use these pre-built lists
1388030	1394190	if you want to go for that, or you can give it a file of your own. And as I've said, if you want to,
1394190	1400450	you can kind of pre-add whatever you want in there, and it will use that instead.
1400450	1405930	So another thing to say is that if you want to, you can just go straight to password spraying.
1405930	1411250	You don't have to do the username enumeration first. So yeah, basically, if you've done the
1411250	1415830	subdomain enumeration, you've got the internal domain information, you can just go straight here.
1415830	1420490	Maybe you've done some OSINT, and you have an idea what the format might be, you can just go
1420490	1426030	straight here and spray it. Okay, so now a little demonstration of password spraying,
1426030	1432370	so I can show you that in a bit more detail as well. Okay, so as you can see here, the top option
1432910	1438150	is use discovered username format. So if we'd already done the username enumeration,
1438150	1443570	then we'd be able to basically just tip that here. And as I've said, that will spray in the
1443570	1448750	legacy format, so you need to be careful. The other choice you've got is that you can just pick what
1448750	1454510	list you want to spray. Again, you can spray these kind of inbuilt lists, you can give it a file of
1454510	1462290	your own, or you can also spray just enumerated users, which again will use the username
1462890	1467450	that we've already discovered, the format that we've already discovered that user in, because
1467450	1473390	obviously we know that that exists. So again, you can put the password in here, that's obviously
1473390	1479410	distinct to the username enumeration password. And then if I click spray, you'll see that this is
1479410	1486330	much quicker, because this is able to be multi-threaded, you're not waiting to check that
1486330	1495610	the kind of time-based information is accurate, which multi-threading the username enumeration
1495610	1501010	can kind of throw that off, because you're making it do multiple ones at the same time.
1501330	1506230	And as you can see, so it's gone through the list, and as we saw before, it's found this user
1506230	1511650	and access token here, and we've also got one with the disabled account.
1513090	1518970	Okay, so as you saw there, we've got these different columns. So for Office 365 spraying,
1518970	1526930	I'll come on to how we do that at the end. But basically, if we can spray the Microsoft login
1526930	1534550	portal, then we can determine a valid user versus an invalid user, and valid credentials versus
1534550	1540290	invalid credentials, and we can also actually tell if you've got the right username and password,
1540290	1547830	but the organization has MFA enabled. So SIP enabled just means they have Skype access,
1547830	1552690	and then depending on the service, we can tell some additional things. So again, Skype is actually
1552690	1559550	my favorite service to look at, because you can actually tell the most from Skype. So we can tell
1559550	1564890	if the account's disabled, you can tell if they're SIP enabled, and you can tell if even if the
1564890	1570890	password is expired. So you've got password right, but it's expired, and also this server error,
1570890	1577030	we can still tell that that's a valid username and password. For Exchange and RDWeb, then we can
1577030	1584830	also still tell if the password is expired or if it's correct, but not some of the additional
1584830	1594610	information. So username enumeration is timing based, so I only have one location for each of
1594610	1599790	those where that's possible, but for password spraying, there's multiple places we can kind of
1599790	1608550	spray. So again, from the 100,000 that I looked at, that's where these statistics have come from.
1608550	1614370	So this is the order in the subdomain enumeration, and when we're validating if the password
1614370	1620550	spray endpoints there, this is the order that Carnivore will look for those in. Again, hopefully
1620550	1626650	this will reduce how many requests we need to make, and in the future, again, maybe that advanced
1626650	1631930	option to say just look at the top two. Obviously you can see here the top two would actually get
1631930	1638210	the vast majority of, you know, would have found it in the vast majority of cases, and then we've
1638210	1646350	got some where there's literally just one out of that 11% that had slash web ticket was there.
1647410	1654970	So this is a mix of known endpoints, kind of publicly written about, ones taken from IIS,
1654970	1662330	from the server itself, and which allow NTLM authentication. So NTLM authentication, I'm
1662330	1667910	going to go into a bit more detail now. So yeah, so just to mention briefly, when I had a look,
1667910	1674350	there kind of doesn't seem to be that much for NTLM, web-based NTLM authentication spraying.
1674350	1678950	It's possible Hydra or something similar might do it, but there didn't seem to be that many tools
1678950	1686190	for it. So here's a little bit of code, very simple for C-sharp, so we can literally just create the
1686190	1692330	new network credential, give it the username and password, and then in response, if it's 401
1692330	1700250	unauthorized, it's bad, otherwise you're good to go. So yeah, incredibly simple, and Carnivore
1700250	1708690	is able to password spray NTLM auth endpoints. So for those, you can still do the blank type
1708690	1714070	one message, but actually, it's part of the protocol is kind of determining and including
1714070	1720090	the domain name. So here, when we're giving the username and password, we can literally just say
1720090	1728510	cscot password one, and actually, as part of this request, it will add the nevtech element of that.
1728910	1736230	So an interesting thing to note is that, as I said before, when I included some NTLM authentication
1736230	1742730	endpoints with the list of subdomains that I look at, then there were some quite big organizations
1742730	1749970	where everything else seemed to not be accessible, and then you've got one kind of weird NTLM auth
1749970	1756330	endpoint hidden away, meaning that they're still susceptible to password spraying against
1756330	1761370	the internal domain. Essentially, I mean, this could even be used for denial of service,
1761370	1767590	because yes, we hit the normal password lockout policies, but essentially, if you purposefully
1767590	1773010	hit that, and you've locked out everyone in the domain, so that's obviously something that
1773010	1779750	an organization would want to be aware of, because that would be a bad day for them as well.
1779970	1785830	So a quick sidetrack into a note on some of these different services, just in case you haven't seen
1785830	1794830	them before. So ADFS, it's a portal that can be present to allow you to sign into different
1794830	1802010	third-party services. Sometimes these might be assumed to be internal, so on past red teams,
1802010	1808730	then this is given access to full job posting applications, so third-party applications,
1808730	1815290	that were linked to the company's Twitter and LinkedIn, all of their job postings. So obviously,
1815290	1821890	for kind of phishing or ongoing attacks, then having access through ADFS to that company's
1821890	1828730	kind of LinkedIn job postings, or even reputational damage, could have been fairly troubling. So
1828730	1835850	basically, you go to the same URL that I gave earlier, and that would give, or would normally
1835850	1839870	give a kind of drop-down list, where you'll see the different applications that you can
1841810	1849830	authenticate into. So I've also seen internal service desks that you can get into. I was
1849830	1855610	logging all call center queries, so that contained incredibly sensitive customer details and
1855610	1860990	information, because it was everyone on their call center putting in, you know, this customer
1860990	1866390	this bank account number, and this credit card number has this question. And that was basically
1866390	1874930	accessible externally through ADFS, and also things like HR, user admin portals.
1875410	1882230	And so one other thing to note there is that if it's Office 365 and federated equals win,
1882230	1889850	so basically Office 365's password spraying avoidance and defense mechanisms are fairly
1889850	1896830	brutal. But basically, if the organization is federated, it means that you, not just that you
1896830	1904010	can, but that you have to hit the ADFS server. And the response to a request I'll show in a bit
1904610	1911190	will tell you where that ADFS server is. And basically, yeah, so if that exists, it's actually
1911350	1917810	a lot better for us, because it means we can avoid Office 365's robust defense mechanisms,
1917810	1925050	and we're just hitting ADFS the same as we would before. And for RDP, that one's fairly simple.
1925050	1930290	It's literally just remote desktop through the web. Depending on how that's configured, maybe you'll
1930290	1937570	be able to RDP into a workstation in the domain, you know, things like that. And yeah, so hopefully
1937570	1943390	you'll have seen Skype and Outlook before. So now, post-compromise, we're going to look at the
1943390	1949630	address list pulling first with a quick demonstration. Okay, so just as a reminder,
1950010	1957330	so this is used to pull the address book through the UCWA API, just to remind you
1957330	1964530	what that looked like. So we have these options here. So if you untick both of those, that means
1964530	1970070	you're just looking for the compromised user. Personal contacts is the personal contacts of
1970070	1976910	that compromised user, so their favorites. That's an interesting one for, say, ongoing social
1976910	1982750	engineering, because then you know, and from the other information you've got here, then you know,
1982750	1989150	okay, my compromised user has this job. His favorites include these people, and they have
1989150	1997630	these jobs. So in terms of kind of fashioning a good phishing payload, then obviously that would
1997630	2003870	be incredibly useful. We can kind of run this on the personal contacts first, and then add in the
2003870	2011150	full address list, just to make that distinction, or yes, just pick the full address list. The data
2011150	2017790	here, as I said before, so the ones that are chosen by default, those are the ones that are quicker to
2017790	2025110	get. So for some reason, the way that the UCWA API works, then we get different pieces of information
2025110	2031430	depending on where we've queried that person. So if they're you, you get this information.
2031430	2036010	If they're your personal contact, you get this information. If it's through the people search
2036010	2041350	function, you get that information. So this is kind of the stripped down list of what you get
2041350	2048970	in every case. Then if you want to kind of go on and pull everything back, we can, but that can take
2048970	2055670	numerous additional requests per user. So obviously for a domain of say 6,000 people,
2055670	2063050	that could take an incredibly long amount of time. So what we do is if we kick this off,
2063050	2070050	I might have just missed the button, that's a good sign. So you'll see it will pull back the
2072770	2076850	standard information for the users first, and then it will kick off some additional threads
2076850	2083670	to pull that additional information. And then as we go, you'll see that start to fill in.
2084290	2090870	And then I'll go over some of these things later. And the additional settings here,
2090870	2096670	I'll go over in more detail. Okay, so as you just saw, the information that we can get back
2096670	2103010	through Skype for Business is a bit of a social engineer's dream. So you've got the department,
2103010	2109630	you've got the office location they work in, and you've got even whether they're online or
2109630	2118350	offline. Additionally, this does say online mobile, online desktop. So I've never fully
2118350	2126210	seen that work in a useful way, but that option's there. So we also get email address, phone number,
2126210	2133430	and this note here is any status message that they've set. So those quite frequently I've seen
2133430	2137530	people will put on there about annual leave, if they're going to be out of the office.
2137670	2142310	So obviously, again, as far as social engineering goes, you know what office they're in,
2142310	2146790	you know their name, email address, what their job title is, you know they're going to be out
2146790	2152370	of the office. So quite a lot of information for maybe even being able to turn up and say,
2152370	2158210	oh, I'm supposed to be meeting so-and-so or even impersonating someone and you know that
2158210	2163630	they're definitely not going to be in the office. So as I was saying, the problem is some of this
2163630	2171890	extra information does take a large number of additional requests. So yeah, by all means,
2171890	2178650	tick all, but just beware, that might take a very long time. And yeah, those are the options
2178650	2185990	you've got. So Carnivore pulls the internal address book back using people search on the UC
2185990	2192830	with the UCWA API. So this does mean that we're essentially having to search letter by letter,
2192830	2198910	A through Z. However, there's an upper limit of 100 on the amount of responses it returns,
2198910	2205310	and there isn't a next link that we can say, here's the first 100, now go to the next link
2205310	2211550	for the next, you know, however many and so on. So basically, what we have to resort to
2211550	2219010	is searching by digraphs and trigraphs. So essentially, A, B, A, C, A, D, and then even
2219010	2232090	A, B, C, A, B, D, A, B, E. And so basically, we can then take either from the top statistically
2232090	2239790	likely usernames list, we can do all of the likely and unique kind of three letters that are there,
2239790	2246210	or you can do all possible two character combinations. So what's interesting and fun
2246210	2252870	about the UCWA API is that there doesn't seem to be much rhyme or reason as to the way that works
2252870	2259350	in terms of what we get back. So to take an example, if we're looking for every pull in the
2259350	2265370	domain, so we know that there's four, and we search for P, you get back 150 results. So we're just
2265370	2271090	going to get the top 100, there's two pulls in there. So then we search for PA, we get back 20
2271090	2276030	results, but this time there's three pulls. So we've got one extra, but for some reason, even
2276030	2280690	though we haven't hit the upper limit, we've still not actually got back every pull who's in the
2280690	2287130	domain. So then we search for PAU, and now we get this mysterious rogue fourth pull that we've never
2287130	2294630	seen before. So essentially, in the interest of me keeping my sanity, I've stuck with diagraphs
2294630	2301070	and trigraphs. It's possible you might want to go on and do quad graphs and quint graphs and whatever
2301070	2308870	else they're called. However, so when I looked at this with the common trigraphs, and then with
2308870	2314450	every possible three character combination, that actually only added an additional, I think it was
2314450	2324990	maybe even one user, in a domain of 6,000. And the difference is common does 2,249 requests,
2324990	2333250	whereas every possible was about 17,500. So all of that for one additional user that, as I've said,
2333250	2339430	was kind of hiding away, and we weren't able to get otherwise. So essentially, hopefully that
2339430	2347290	explains the kind of options on the address list a little bit more. One additional kind of side
2347290	2353590	note. So it's fairly uncommon, but I've seen it where a misconfigured Microsoft web app proxy
2353590	2359530	basically meant that when you auth to the first server, and it gives you back the token, and then
2359530	2365140	you try and use that against the application's endpoint, then it essentially sends it to the
2365140	2372480	wrong place, or you've been authed to the wrong box, and so it then doesn't like it. That actually
2372480	2380080	also stops the legitimate Skype client from being able to authenticate, you know, to Skype.
2380080	2386680	However, now Carnivore is able to detect that. It re-auths to the correct box and carries on.
2386680	2392740	So basically Carnivore is able to connect and carry on using the API, even when the legitimate
2392740	2400320	client actually couldn't. Okay, so now the final post-compromise function, which is MeetingSnooper.
2400520	2406740	So unfortunately, my lab servers stopped working for this, so we have to make do with screenshots.
2408380	2415760	Okay, so as you can see here, this is the MeetingSnooper tab. So once you've compromised the
2415760	2423180	user, if you've got Skype available, so this uses the UCWA API as well, then you can go here
2423180	2429520	and you have to choose, you have to pick the compromised user that you want to use there.
2430200	2435820	So now we can either choose, basically we can do this for all compromised users or just a
2435820	2442760	selected user. Now one thing to say is that this only picks up currently scheduled meetings,
2443200	2448620	obviously. So basically we can run this throughout the day multiple times or, you know, at the start
2448620	2452900	of the day you could run it, see if any new meetings have been added, and then kind of keep
2452900	2460500	running it to pull back new information. So first of all, it dumps the standard dial-in information
2460500	2466000	to the output log. So if you've ever had an email inviting you to a Skype meeting, this will look
2466000	2470920	fairly familiar to you. So you've got the internal number you can dial and then a number for each
2470920	2479720	country or city within that country. And so now apologies for how utterly rubbish this looks.
2479740	2485760	As I said, my training lab unfortunately kind of packing in at the key moment there. But yeah,
2485760	2490880	so to stress this isn't an exploit or a zero day, it's basically highlighting what's already
2490880	2498220	possible through kind of weaponization of the UCWA API for attackers. Obviously it does depend
2498220	2505320	on compromised credentials, but basically so far this tool has shown how we can go from external
2505320	2511520	over the internet to kind of complete compromise and to this point of being able to dump out
2513080	2518820	scheduled meetings for compromised users. So one thing to say is that when kind of using
2518820	2524960	this tool on jobs, then often you find if you're going to get anyone, you probably are going to get
2524960	2532300	like 50 to 100 users. And obviously in that case, then this becomes more interesting because,
2532300	2537280	you know, one user might have one meeting that week, but if you've got 50 users, then maybe
2537280	2544700	you've got someone who's a little bit more interesting. So you can then see here what
2544700	2549880	happens when you run this tool is that it gives you information for each meeting that compromised
2549880	2557660	user has scheduled. So the conference ID there is the PIN. So basically when you dial in,
2557660	2563460	you dial into the phone number and it asks you for a PIN and that's that conference ID.
2563620	2569400	And basically that conference ID is unique to that user. So when you dial in, you'll be
2569400	2576780	impersonating whoever it is that you've compromised. So for example, you dial in,
2576780	2584920	then you show up as being, say, a Chris Nevin guest. Now, obviously, if the people in the
2584920	2591880	meeting are kind of using the desktop application, then maybe it would look weird to have multiple
2591880	2598020	Chris Nevin guests there. If everyone's using the phone to dial in, I'm not sure that they
2598020	2605000	would notice this at all. And in fact, even if they did see these two Chris Nevin guests,
2605000	2610200	how likely is it that people are going to assume, oh, this is someone impersonating and joining in
2610200	2617040	and listening, as opposed to maybe there's some weird bug that's happening. So the information
2617040	2622940	we get here includes the subject of the meeting and the attendees. So obviously these meetings
2622940	2628980	here I've scheduled just to kind of demonstrate, but obviously this could be a lot more juicy.
2629020	2633100	So for example, you've compromised a user, you know from their address book that they're the
2633100	2639260	head of financial fraud. And this meeting subject shows it's the weekly financial crime investigation
2639260	2645960	update. So obviously you can see why this would be kind of concerning for an organization if this
2645960	2652380	was possible. And because, again, without any exploit, any need for any further phishing or
2652380	2658580	payloads being executed, you've basically gone from being over the internet to being able to
2658580	2664500	listen in on and even record the sensitive meetings, essentially impersonating that user.
2665740	2671340	So on the right, you can see the lobby bypass enabled. That basically means that if you
2671340	2678700	dial in, does it bypass the lobby? If that's enabled, that means you're not even in a
2678700	2685660	waiting room that someone has to let you in. So the join URL, if you go to that, you can join
2685660	2690920	the meeting and you can basically enter a name of your choice. So obviously one thing you could do
2690920	2697840	is, again, you've done the address book, you know, is there a social engineering angle? Maybe you
2697840	2703840	could kind of choose your name based on that. Potentially it might be more likely to get caught,
2703840	2708940	whereas actually just dialing in and there being two of the compromised user is maybe less
2709740	2716940	troubling. So another thing to say is that the API basically only seems to give the meeting
2716940	2723920	expiry. So that's two weeks after the meeting ends. So Carnivore will take off, it will remove the two
2723920	2730480	weeks for you automatically, and then it's kind of maybe you'll need to do some kind of common
2730480	2737280	sense around that. So for example, you see the top meeting there. All we actually have been able to
2737280	2743620	is that the meeting ends at 11.30. Now I've set the subject for that one to be the time while I
2743620	2749800	was troubleshooting. So you can see that actually that meeting starts at 11. As I say, normally you
2749800	2757080	wouldn't get that information because that's the subject. So obviously, yeah, if you apply some
2757080	2762580	common sense to it, then you can see, OK, the meeting ends at 11.30. It probably starts at 11
2763080	2771400	or even 10.30. So yeah, so that's the meeting snooping, what you get back from it basically.
2771520	2777200	So there are a couple of extra points to mention, which are that this only seems to be able to pull
2777200	2783460	back self-scheduled meetings. So again, doesn't fully make sense to me because obviously in
2783460	2787720	Outlook or something, you don't just see meetings you've scheduled. You see every meeting
2788380	2793100	that you're scheduled to be a part of. Unfortunately, we're not able to get that
2793100	2800300	through this tool. And so, yeah, and then also meeting end time only, as I said before.
2800620	2807040	Now, there are some weird edge cases with that. So, for example, I set a recurring meeting.
2807040	2812300	And so the only information we get back is that it ends on the 26th of December 2022,
2813060	2818160	which obviously isn't that useful. Again, maybe you could figure out, OK, that's a Friday. It's
2818160	2824540	at half ten. So maybe it's every Friday. But again, we can't get that back through the API,
2824540	2832680	unfortunately. OK, so Office 365. So I'm not going to demo this. So what I've been showing so far is
2832680	2838520	basically just my lab. And so, yeah, we're not going to demo Office 365, but I'm going to talk
2838520	2845560	you through how Carnivore works. So, for example, or sorry, one thing to say is that username
2845560	2851780	enumeration that doesn't require a password guess has been quite widely covered. So there's things
2851780	2858900	like O365 or O365enum. So I'm just going to quickly kind of get into password spraying
2858900	2866520	and give some key pointers. So, as I said before, federated is a win. So just the usual
2866520	2873120	Active Directory rules will apply to lockouts. But again, that kind of doesn't include the
2874540	2882840	extremely robust Office 365 rules. So, as I've said, there's a link that I'm about to show you
2882840	2888200	where you can find out if an organization is federated or not. If it is, you'll get back the
2888200	2895560	ADFS server location and Carnivore will add that automatically. So if it's not federated, we can
2895560	2903500	still spray, sorry, we have to spray the Office portal, but then we can also determine if a user
2903500	2908940	and password is valid, even if we have MFA on there. I'm sorry, I should have said again,
2908940	2914460	with federated, if it's federated, you have to spray ADFS and you can't spray the Office portal
2914460	2920580	and you won't get back anything interesting, anything useful. So password spray counter
2920580	2927580	measures for Office 365. So they have things like trusted versus untrusted network, have separate
2927580	2933840	bad password counts. So again, if you're from the untrusted side, which presumably you would be
2934700	2941040	from an untrusted network, then, you know, your password spray is adding to account of everyone
2941040	2950240	else in the world. So again, lockout is fairly frequent and quick. But from the Microsoft side,
2950240	2954900	obviously that's designed so that then the genuine user can still sign in while on their
2954900	2961600	corporate VPN or something like that. So obviously good security measures, but difficult from a red
2961600	2968920	team perspective. So first of all, to find out if the organization is federated. So this is an
2968920	2975260	example request here. So the username itself is irrelevant. It's just the appdomain.com that we're
2975260	2981880	looking for. And the response here. So if they were federated, that would say
2982740	2989400	federated instead of managed. And it can also include some kind of boilerplate text. So,
2989400	2995040	for example, is keep me signed in disabled? Obviously, that one might be interesting from
2995220	3001780	a red team perspective, because maybe it hints that they have fairly good security and they've
3001780	3007300	had their configuration looked at because users can't just stay signed in forever.
3007820	3013480	You also get the federation brand name there, and you can get back, you know,
3013480	3020000	logo information and that kind of thing. So also, if they said federated, then we would see the
3020940	3025640	location of the ADFS authentication endpoint there as well.
3026920	3033220	So for password spraying, this is how Carnivore does it. So this is the endpoint that we're
3033220	3040520	hitting. There's the username and the password. So the client ID and the scope, obviously,
3040520	3046200	that could be tweaked to maybe be a little bit more realistic or representative. But this is
3046200	3053620	what Carnivore uses. And so this first one is if there's an invalid password. Now, obviously,
3053620	3059880	the actual response here says invalid username or password. So obviously, that seems like maybe
3059880	3064360	that's going to be a bit tricky for us. Is it the username or is it the password? We're not fully
3064360	3071360	sure. But then if the username is incorrect, then we get this message back. The user account does
3071360	3077480	not exist in that directory. So obviously, from that, we can tell the previous response means the
3077480	3083560	password's wrong, not the username. And just to also mention there where it says email hidden,
3083560	3089980	I've not added that. That's the actual response. So then this is a valid user and password without
3089980	3098400	NFA. So again, this is specific to the request that I make in Carnivore. So because we gave a
3098400	3104260	client ID that doesn't exist, then if the username and password is correct, you'd get this unauthorized
3104260	3111480	client and a message that that application doesn't exist, because obviously, it's not a proper
3111480	3121240	client ID. And again, so if it's valid user and password with MFA, then again, we get this invalid
3121240	3126920	grant. But now it's telling us that it's due to configuration, meaning that you need to supply
3126920	3133200	multi-factor authentication. So again, username and password is correct, but you need MFA.
3134840	3142180	So outro very briefly. Yes, so almost forgot to put it in, but here's a link to the tool itself.
3142360	3147540	So obviously you can go there and download the latest version and any issues or anything that
3147540	3152400	you want to bring up there, I'll be happy to try and help wherever I can. So thank you for
3152400	3156800	listening. Hopefully it's been useful and enjoy carnivoring.