 Hello, my name is Chris Nevin and I work for NCC Group, so this tool is called Carnivore, so that's a Microsoft external attack tool or assessment tool. So the cryptozoologists amongst you might know this, so that spells meet. So that's very amusing. And it's basically a tool to help pentesters find misconfigurations and vulnerabilities in Microsoft on-premises servers. So also apologies if I talk quickly, but there is quite a lot to get through. So the basic outline of the presentation. 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. So now intro demonstration. Okay, so first a quick overview just to give you a taste of what the tool can do. 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. You might notice that it's a .nev domain, obviously that wouldn't normally be a top level domain, but this is my training lab. So first of all, it's going to look for DNS, sorry, do DNS lookups for subdomains which are normally connected with a particular service. So for example, link discover with Skype, then it verifies there's something there. So it's not just a wildcard resolution. And then it also does some checks to make sure, does it also actually seem to be an exchange or a Skype server? So I've also built in some kind of bailout options. So for example, if we get back a server header saying that it's njinks, it's not even Windows, we don't need to test every possible endpoint just in case one of them is a Skype server. So yes, so that's something that we do. So it also validates the username enumeration and the password spray URL separately. I'll come onto 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. So we try the most obvious and then if they don't hit, there are other kind of password spray endpoints that are possible. So yes, so hopefully if an organization has something exposed, then we'll be able to find it to report to them. So we also log everything here and you've got export options. If you want to kind of manually export things for some reason. 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. 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 kind of checks for is it federated and that kind of thing. 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. 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. Okay, so let me kick this off. Okay, so the other thing with this Discover Internal Domain, then it does the fairly standard blank type one NTLM message and you can see it's called back the internal domain name. So at the moment, it does that individually for each of these services. And that's because Skype might be hosted in Germany and the ADFS server might be in Canada for some reason. 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. And in fact, even on a job just last week, then these were all different. So it does happen quite frequently. I might add some kind of advanced options. So you can say just assume they're all the same. But like I say, that's maybe a recipe for potential disaster. So okay, we've also got the IP addresses here. So you can obviously check those against your scope. 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 until M1 message. So the other thing to mention is for Skype, so link discover is the kind of auto discover service. And that actually points to the real server, which is what we want to hit. So that's why there's two kind of entries for Skype there. So we've now got Skype exchange, ADFS and RD web. So I'm going to show you a quick run through of username enumeration and password spraying just to give you an idea. So smart enumeration, we'll leave it on the defaults. We're also going for password one, just kind of standard. So you see there's quite a lot of usernames to try here as it's going through. We found one of a particular format. So it's now continuing to loop through nine different formats. And you'll see that when we discover the correct format, then this will drop drastically because then we switched to just using usernames of that format. So we've now got two of the same format, so first initial surname. And now we've got three. So you'll see that it's now selected that format of jsmith. 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. So now I'll quickly show you password spray as well. So I'll use that same format, jsmith. So for the password spray, that will now spray that in the kind of modern style username format. So jsmith.nevtech.nev. 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. So here we go. So that's gonna take a second. I'm sure we're not gonna find anyone because of course no one ever uses passwords like this. Who would possibly be that foolish? So here we go. If we give it another couple of seconds, you can see again this is just doing that one username list. So obviously that's the same number of users total that it would be spraying as the smart enumeration was looking at. So it should be around about now. So there you go. So we've now uncovered one user with that password. We've used the RD web service, but obviously we could have sprayed that on any of these other services. And at the moment, looking at the internal domain information, we can probably assume that they're kind of gonna be the same across all of them. Okay, so let's have a look. Let's just do one with Skype. So, here we go. So actually, sorry, I forgot to use Skype. So just to show you, you can also password spray enumerated users. So let's use that same. It was 2019. Okay, so for that option, then we were spraying the users in the legacy format because those are the ones we've already enumerated. And for username enumeration, that's incredibly slow because for every invalid user, you might have to wait something like 20 or 30 seconds. When we're spraying this list of already enumerated users, then we kind of know already that they exist. And actually that's still quite fast even when spraying in legacy format because you're not having to wait for every invalid user. So obviously, we've now got him as well. You can see we've got this access token here. So I'll quickly show you the address book. So we'll choose this user who we've already got the access token for. Again, I'll explain in more detail some of these other settings. But for now, we're just gonna let this go, see what happens. I'm also gonna come back to the meeting snooper later. So this is just to kind of show the address book functionality. Here we go. And so you can see now, all of these other users popping up. So we get the sipusername, the email address, title, department. We can kind of tick these on and off. The default settings that I've got here are basically the ones we can get relatively quickly. 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. So in this instance, we just go for the default. It's fairly quick. Obviously for my test lab, this is quite a small number of users, but there you go. You can see the general gist of what's possible with this tool. Okay, so now for some just general statistics. 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 of those 11.79% were attackable at all. And so this shows that of that 11%, about 11%, so how many had each service? So obviously some could have had more than one service. This started, kind of all started initially as a Skype attacking or assessment tool. 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. So one caveat with the kind of 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. 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? So actually that number might even be higher if we'd have explicitly asked. 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. So I could 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. So the first part, subdomain enumeration, we'll go into that in a little bit more detail. Okay, so as I said before, I split the username enumeration URL and the pass spray or the endpoint validation. 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 that organizations have just one or just the other. So for example, here you can see actually there's 53% had a password spray endpoint over 47% with a username enumeration. So kind of 6% more had a password spray endpoint than had both. There were some that just had username enumeration. And 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, the username enumeration, the standard login points, but then they have this one password spray endpoint that kind of seems to have eluded that. So yeah, that's kind of interesting. So kind of all looks for some domains in the order shown here. So these statistics are taken from that 11% of the 100,000. 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. So in future, I might add an option for a kind of, you know, you can choose between light or full enumeration. So maybe you could choose to just look at the top two and then discount it. And yeah, so then again, maybe managing to kind of cut that down even more as to how many requests you need to send. So now username enumeration in a little bit more detail. So we're gonna start with a demonstration. Okay, so we've got various options here that I'm gonna go through. So firstly, smart enumeration that we saw before. So basically that will take these nine different formats of username taken from the top statistically likely username's lists. And it will basically try the top username in each list and then the top of the next list, top of the next list. And essentially, as you saw before, it's looking for three valid usernames of the same format. So that's using the timing-based difference, which is fairly well known for Skype and Exchange. I've added it here for ADFS and RDWeb as well. So we've got this advanced option here as well that if you want, you can kind of pick a format and where you wanna start in that list. Or you can leave it as it is. You can also do an individual username or you can provide your own list. Or there's these pre-built ones. So these are kind of standard and service accounts. And Counts will killer was created by my colleague, Owen Bellas. So that's kind of a list of maybe fairly standard user accounts that might be in there. So you can set the password. So obviously also it works on the timing-based difference and then also if you get the password right, then great. So again, I would just show you, obviously this is fairly similar to what we saw before. One interesting additional point to note is additional information you can get depending on the service. So for Skype, then we can actually determine quite a bit of additional information. So SIP-enabled basically just means, so actually, sorry, some of these will only come up if you get the password right as well. So SIP-enabled would mean you've got the username and the password right and that user is basically set up on Skype. So account disabled, whatever password you give, you would get that if the account is disabled. You should see that in a second. Now that it's switched over. In fact, I might have re-enabled that user. 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 gonna be able to kind of do anything. 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. And if you found an endpoint, maybe for the VPN, it might be, you can even kind of put that password in and it will ask you to reset it. 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 contact, green light. And then for Skype, we can also get this server error, but again, that means you've got the password right. And as I said before, you'll get the access token there if you do. So yeah, username and numeration. Okay, so as you've just seen, smart and numeration 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. Now, one interesting thing is this difference between legacy and modern format. So legacy is domain slash username. Modern kind of email style is username at domain. So that can match, they can match, but they don't necessarily have to. And again, the modern format could match the email, but doesn't necessarily have to. Now for username and numeration, we can only use the legacy format and that's to get that timing based difference. So one interesting thing is that that causes a little hiccup when rolling over to password spraying. So previously I used username and numeration to discover the format and then just assume that it will be the same for the modern format for when we spray. Now, because technically that might not be the case, I don't do that anymore. 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. So what I would suggest as a way of doing this, because basically, yes, so username and numeration, every invalid user 30 to 40 seconds. So if you waited for that to finish anyway, that's gonna take the rest of the day, a couple of days. So ideally what you wanna do anyway is use username and numeration to get the potential, the likely format. That might take five minutes, say, 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. So instead, pick the same format and password spray those. Hopefully you should get some credentials or some invalid, sorry, disabled accounts, which give you a point of that is the correct format. But if you don't, then it is possible that the formats don't match and you might need to do a little bit more kind of manual going through different potential formats to discover which it is. So the other thing to say is that, so obviously with username and numeration, we discover a valid username, even if the password is wrong, whereas for password spraying, we only find out anything if we get both correct. So you can, if you want to, stay with the username and numeration, you get a nice list and it takes 48 hours. 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 gonna really lose anything by switching over to password spraying, you're gonna be hitting the same users. So you're gonna find the same users that might have password one as their password, just it will take 10 minutes instead of two days. So yeah, so that would be my suggested method. So now I'm gonna show where we get the time-based difference and some other things for ADFS and RD web, because I don't think there's much publicly written about those, whereas there is for Skype and Exchange. So this is maybe more interesting. So this is where we get the time-based difference for ADFS. 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. 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 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. And then here you'll see the invalid response. So it's just 200 okay. And so that's told us nothing, or with the timing difference, maybe it's told us if the user's valid. And this is a valid response, we get the 302 redirect and it sets this MSIS auth cookie. So for RDWeb, we make a post request like this. So there's the username and the password to this URL. And if it's invalid, then we get the 200 okay again. And for TSWA auth HTTP only cookie, then that either isn't there or it's blank. So again, we can use timing-based difference with the username 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. Okay, so now password spraying. So as I said before, there's a little hiccup here with the discovered format. 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 app domain style instead. So for password spraying, it basically defaults to using that style if possible because it's quicker. And also if you provide a list of user names, you can if you want provide it with domain slash user or user domain and it will use what you've given. So let me have a look. 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. 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. So another thing to say is that if you want to, you can just go straight to password spraying. You don't have to do the username and enumeration first. So yeah, basically if you've done the sub-domain enumeration, you've got the internal domain information, you can just go straight here. Maybe you've done some OS and you have an idea what the format might be. You can just go straight here and spray it. Okay, so now a little demonstration of password spraying so I can show you that in a bit more detail as well. Okay, so as you can see here, the top option is use discovered username format. So if we'd already done the username enumeration, then we'd be able to basically just tip that here. And as I've said, that will spray it in the legacy format. So you need to be careful. The other choice you've got is that you can just pick what list you want to spray. Again, you can spray these kind of inbuilt lists. You can give it a file of your own and or you can also spray just enumerated users. Which again, we'll 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. So again, you can put the password in here. That's obviously distinct to the username enumeration password. 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 timing-based information is accurate, which multi-threading the username enumeration can kind of throw that off because you're making it do multiple ones at the same time. 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. Okay, so as you saw there, we've got these different columns. So for Office 365 spraying, I'll come onto how we do that at the end. 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. So SIP enabled just means that they have Skype access. And then depending on the service, we can tell some additional things. So again, Skype is actually my favorite service to look at because you can actually tell the most from Skype. So we can tell if the account's disabled, you can tell if they're SIP enabled, and you can tell even if the password is expired. 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. For Exchange and RD web, then we can also still tell if the password is expired or if it's correct, but not some of the additional information. So username and 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. So again, from the 100,000 that I looked at, that's where the statistics have come from. So this is the order in the sub-domain enumeration and when we're validating if the password spray endpoint's there, this is the order that kind of all the look for those in. 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. 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 somewhere is literally just one out of that 11% that had slash web ticket was there. So this is a mix of known end points kind of publicly written about. One's taken from IAS from the server itself and which allow until I'm authentication. So until I'm authentication, I'm gonna go into a bit more detail now. So yeah, so just to mention briefly, when I had a look, there kind of doesn't seem to be that much for until I'm web-based until I'm authentication spraying. It's possible Hydra or something similar might do it, but they didn't seem to be that many tools for it. 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 the response, if it's 401 unauthorized, it's bad. Otherwise you're good to go. So yeah, incredibly simple and Carnivore is able to password spray until I'm off end points. 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. So here, when we're giving the username and password, we can literally just say C Scott password one. And actually as part of this request, it will add the Nevtech element of that. So an interesting thing to note is that, as I said before, when I included some NTLM authentication endpoints with the list of sub-domains 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 off endpoint hidden away. And that they're still susceptible to password spraying against the internal domain. 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 because that would be a bad day for them as well. So quick sidetrack into a note on some of these different services, just in case you haven't seen them before. So ADFS is a portal that can be present to allow you to sign into different third party services. Sometimes these might be assumed to be internal. So on past red teams, then this has given access to full job posting applications. So third party applications, they were linked to the company's Twitter and LinkedIn, all of their job postings. 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. So basically you go to the same URL that I gave earlier and that would give or would normally give a kind of dropdown list where you'll see the different applications that you can authenticate into. So I've also seen internal service desks that you can get into. It was logging all call center queries. So that contained incredibly sensitive customer details and information because it was everyone in their call center putting in this customer with this bank account number and this credit card number has this question and that was basically accessible externally through ADFS and also things like HR, user admin, poor tools. And so one other thing to note there is if it's Office 365 and federated equals win. So basically Office 365's password spraying avoidance and defense mechanisms are fairly brutal but basically if the organization is federated, not just that you can, but that you have to hit the ADFS server and the response to a request I'll show in a bit will tell you where that ADFS server is 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 and for RDP, that one's fairly simple. It's literally just remote desktop through the web depending on how that's configured. Maybe you'll be able to RDP into a workstation in the domain, things like that. And yeah, so hopefully you'll have seen Skype and Outlook before. So now post compromise, we're gonna look at the address list pulling first with a quick demonstration. Okay, so just as a reminder, so this is used to pull the address book through the UCWA API, so just to remind you what that looked like. So we had these options here. So if you untick both of those, that means you're just looking for the compromised user. Personal contacts is the personal contacts of that compromised user, so their favorites. 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. His favorites include these people and they have these jobs. So in terms of kind of fashioning a good fishing payload, then obviously that would be incredibly useful. 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. The data here, as I said before, so the ones that are chosen by default, those are the ones that are quicker to get. 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. So if they're you, you get this information. If they are personal contacts, you get this information. If it's through the people search function, you get that information. So this is kind of the stripped down list of what you get in every case. Then if you want to kind of go on and pull everything back, we can, but that can take numerous additional requests per user. So obviously for a domain of say 6,000 people, that could take an incredibly long amount of time. So what we do is if we kick this off, and then I've just missed the button, that's a good sign. So you'll see, it will pull back the kind of standard information for the users first and then it will kick off some additional threads to pull that additional information. And then as we go, you'll see that start to fill in. And then I'll go over some of these things later and the additional settings here will go over in more detail. Okay, so as you just saw, the information that we can get back through Skype for Business is a bit of a social engineers dream. So you've got the department, you've got the office location they work in, you've got even whether they're online or offline. Additionally, this does say online mobile, online desktop. So I've never fully seen that work in a useful way, but that option's there. So we also get email address phone number and this note here is any status message that they've set. So those quite frequently I've seen people will put on there about annual leave if they're gonna be out of the office. So obviously again, as far as social engineering goes, you know what office they're in, the name, email address, what their job title is, you know they're gonna be out of the office. So quite a lot of information for maybe even being able to turn up and say, you know, oh, I'm supposed to be meeting so-and-so or even impersonating someone and you know they're definitely not gonna be in the office. So as I was saying, the problem is some of this extra information does take a large number of additional requests. So yeah, by all means tick all, but just beware that might take a very long time. And yeah, those are the options you've got. So Carnivore pulls the internal Dressbook back using people search with the UCWA API. So this does mean that we're essentially having to search letter by letter, A through Z. 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. So basically what we have to resort to is searching by digraphs and try graphs. So essentially A, B, A, C, A, D, and then even A, B, C, A, B, D, A, B, E. 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. 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. 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. So we're just gonna get the top hundred, there's two pulls in there. So then we search for P, A, we get back 20 results, but this time there's three pulls. 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. So then we search for P, A, U, and now we get this mysterious rogue fourth pull that we've never seen before. So essentially in the interest of me keeping my sanity, I've stuck with digraphs and try-graphs. It's possible you might wanna go on and do quad-graphs and quink-graphs and whatever else they're called. However, so when I looked at this with the common try-graphs 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. And the difference is common does 2,249 requests, whereas every possible was about 17 and a half thousand. 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. So essentially, hopefully that explains the kind of options on the address list a little bit more. One additional kind of side note. 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 applications endpoint, then it essentially sends it to the wrong place or you've been off to the wrong box and so it then doesn't like it. That actually also stopped the legitimate Skype client from being able to authenticate to Skype. And however, now Carnival is able to detect that. It re-auths to the correct box and carries on. So basically, Carnival is able to connect and carry on using the API even when the legitimate client actually couldn't. Okay, so now the final post-compromise function which is meeting Snooper. So unfortunately, my lab servers stopped working for this. So we have to make do with screenshots. Okay, so as you can see here, this is the meeting Snooper tab. 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 wanna use there. So now we can either choose, basically we can do this for all compromised users or just the selected user. Now one thing to say is that this only picks up currently scheduled meetings, obviously. So basically we can run this throughout the day multiple times or 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. So first of all, it dumps the standard dial-in information to the output log. So if you've ever had an email inviting you to a Skype meeting, this will look fairly familiar to you. So you've got the internal number you can dial and then a number for each country or city within that country. So now apologies for how utterly rubbish this looks. As I said, my training lab unfortunately kind of packing in at the key moment there. 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. Obviously it does depend on compromise 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 yet scheduled meetings for compromised users. So one thing to say is that when kind of using this tool on jobs, then often you find if you're gonna get anyone, you probably are gonna get like 50 to 100 users. And obviously in that case, then this becomes more interesting because 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. 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. So the conference ID there is the PIN. So basically when you dial in, you dial into the phone number and I asked you for a PIN and that's that conference ID. And basically that conference ID is unique to that user. So when you dial in, you'll be impersonating whoever it is that you've compromised. So for example, this you dial in, you put in the PIN and then you show up as being say Chris Nevin guest. 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. If everyone's using the phone to dial in, I'm not sure that they would notice this at all. And in fact, even if they did see these two Chris Nevin guests, how likely is it that people are gonna assume, oh, this is someone impersonating and joining in and listening as opposed to, maybe there's some weird bug that's happening. So the information we get here includes the subject of the meeting and the attendees. So obviously these meetings here, I've scheduled just to kind of demonstrate, but obviously this could be a lot more juicy. So for example, you've compromised the user, from their address book, they're the head of financial fraud and this meeting subject shows it's the weekly financial crime investigation update. So obviously you can see why this would be kind of concerning for an organization if this was possible, 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. So on the right, you can see the lobby bypass enabled. That basically means that if you dial in, does it bypass the lobby? If that's enabled, that means you're not even in a waiting room that someone has to let you in. So the join URL, if you go to that, you can join the meeting and you can basically enter a name of your choice. So obviously one thing you could do is, again, you've dumped the address book, is there a social engineering angle? Maybe you could kind of choose your name based on that. 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 trouble in. So another thing to say is that the API basically only seems to give the meeting expiry. So that's two weeks after the meeting ends. 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. So for example, you see the top meeting there, all we actually have been able to pull is that the meeting ends at 11.30. Now I've set the subject for that one to be the time while I was troubleshooting. So you can see that actually that meeting starts at 11. As I say, normally you wouldn't get that information because that's the subject. So obviously, yeah, if you apply some common sense to it then you can see, okay, the meeting ends at 11.30, it probably starts at 11 or even 10.30. So yeah, so that's the meeting snooping, what you get back from it basically. 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. So again, it doesn't fully make sense to me because obviously in Outlook or something you don't just see meetings you've scheduled, you see every meeting that you're scheduled to be a part of. Unfortunately, we're not able to get that through this tool. So yeah, and then also meeting end time only as I said before. Now there are some weird edge cases with that. So for example, I set a recurring meeting and so the only information we get back is that it ends on the 26th of December, 2022, which obviously isn't that useful. Again, maybe you could figure out, okay, that's a Friday, it's a half 10, so maybe it's every Friday. But again, we can't get that back through the API unfortunately. Okay, so Office 365, so I'm not gonna demo this. So what I've been showing so far is basically just my lab. And so yeah, we're not gonna demo Office 365, but I'm gonna talk you through how Carnival works. So for example, sorry, one thing to say is that username enumeration that doesn't require a password guest has been quite widely covered. So there's things like 0365 or 0365 enum. So I'm just gonna quickly kind of get into password spraying and give some key pointers. So as I've said before, federated is a win. So just the usual Active Directory rules will apply to lockouts. But again, that kind of doesn't include the extremely robust Office 365 rules. 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. If it is, you'll get back the ADFS server location and Carnival will add that automatically. 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. 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. You won't get back anything interesting, anything useful. So password spray counter measures for Office 365, so they have things like trusted versus untrusted network have separate bad password counts. So again, if you're from the untrusted side, which presumably you would be from an untrusted network, then your password spray is adding to account of everyone else in the world. So again, lockout is fairly frequent and quick, but from 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. So obviously good security measures, but difficult from a red team perspective. So first of all, to find out if the organization is federated, so this is an example request here. So the username itself is irrelevant. It's just the appdomain.com that we're looking for. And the response here, so if they were federated, that would say federated instead of managed. And it can also include some kind of boilerplate text. So for example, is keep me signed in disabled? 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 the configuration looked at because users can't just stay signed in forever. You also get the Federation brand name there and you can get back logo information and that kind of thing. So also if this said federated, then we would see the location of the ADFS authentication endpoint there as well. So for password spraying, this is how Carnivore does it. So this is the endpoint that we're hitting. There's the username and the password. So the client ID and the scope, obviously that could be tweaked to maybe be a little bit more realistic or representative, but this is what Carnivore uses. So this first one is if there's an invalid password. Now obviously the actual response here says invalid username or password. So obviously that seems like maybe that's gonna be a bit tricky for us. Is it the username or is it the password? We're not fully sure, but then if the username's incorrect, then we get this message back. The user account does not exist in that directory. So obviously from that, we can tell that the previous response means the password's wrong, not the username. And just to also mention there where it says email hidden, I've not added that, that's the actual response. So then this is a valid user and password without NFA. So again, this is specific to the request that I make in Carnivore. 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. And again, so if it's valid user and password with NFA, then again, we get this invalid grant, but now it's telling us that it's due to configuration, meaning that you need to supply multi-factor authentication. So again, username and password is correct, but you need NFA. So, outro very briefly. Yes, so almost forgot to put it in, but here's a link to the tool itself. So obviously you can go there and download the latest version and any issues or anything that you wanna bring up there. I'll be happy to try and help wherever I can. So thank you for listening. Hopefully it's been useful and they enjoy Carnivore.