Reconnaissance: Azure Cloud w/ Kevin Klingbile
In this video, Kevin Klingbile from Black Hills Information Security discusses the intricacies of Azure Cloud services and M365, focusing on the differences between unauthenticated and authenticated reconnaissance in penetration testing. He provides a thorough walk-through of various tools and techniques for conducting effective recon, including username enumeration, password spraying, and extracting tokens. Kevin also shares practical insights on setting up developer subscriptions for Azure and emphasizes the importance of maintaining situational awareness to enhance security posture.
- The webinar focused on the differences between M365 and Azure Cloud services, and the specific considerations for penetration testing these environments.
- Various reconnaissance techniques were discussed, including unauthenticated and authenticated recon, with a focus on DNS records, user enumeration, and identifying potential security misconfigurations.
- Several tools and methods for exploiting vulnerabilities within M365 and Azure were covered, including using Cloud Enum, Cred Master, and Graph Runner for detailed recon and potential exploitation.
Highlights
Full Video
Transcript
Kevin Klingbile
All right, I lied a little bit on the topic. I’m going to start out with that. I said Azure Cloud. we’ll get into the reason why I said Azure Cloud. Most people recognize Azure as Microsoft cloud services.
There’s also M365 and Azure Cloud and they’re different. We’ll discuss why. But before we get there, let’s go into the overview. We’ve got the introduction, don’t really worry about that.
We got some concepts we’re going to do unauthenticated recon, and, because it’s a pentesting kind of topic, we had to throw some exploitation in there and then we’re going to look at authenticated recon.
So there’s really two major differences here. We can look at the unauthenticated side and what we can see from there once we get that set of credentials or if you’re a security analyst who wants to actually go in and delve more into it with your tenant or a tenant that you’re authorized to, to check against, we’ve got that authenticated recon piece.
And that’s what we all do as testers here too. So we’ll get there when we do. So, a little bit about me: penetration tester here at Black Hills Information Security analyst, lifetime hacker, been doing it for as long as I can remember.
I remember doing things in middle school that were probably a little sketch too. I am on the CIS critical security controls editor. So the editorial panel for version eight, I worked on the ICS companion guide, version eight and I’ve got 22 years of experience all over the place, a lot of Internet provider, a lot of energy, a little bit of healthcare and pentesting.
Now I always did pentesting style, role, security roles, as long as I can remember. So goals for the day, I’m not going to read these off because we’re going to delve into these.
But if you need to go back, slide four has got the outline of where we’re starting. I started and said I lied to you just a little bit. We have M365 and we have Azure.
A lot of people just combine them to say Azure, which makes sense from the standpoint of it’s one term that you can use to describe Microsoft cloud, but it’s a little bit tricky when you’re thinking of the differences there.
Like do I need to test against M365 or do I need to test against Azure? Do I need both? Really the answer is probably both or M365. Most people are on M365.
Azure is when you start to pull in the actual infrastructure, pieces of it. M365 is going to be the SaaS enter id is essentially under M365 as well.
It’s technically a platform as a service. This little bottom description here I pulled from the Microsoft site. And if you grab the PDF for the slides, I know one of the PDF’s that they’re going to post out has the notes section from the slide deck.
And in the notes section I have links to all sorts of resources. So I have links to essentially where I pulled this from. I have links to some diagrams to other Microsoft resources, to other pentesting resources, to GitHub repos, everything that’s on the slide.
M365 and entry id is where most clients are when they think Azure Cloud. If we go beyond that, we’re starting to do DevOps in Azure, we’re starting to use buckets, we’re starting to do build code repos, we’re hosting applications.
All of that’s going to be the Azure piece. We’ll look at the differences of what can we look at from an M365 perspective for recon. What can we look at from an Azure perspective for recon on both authenticated and unauthenticated recon.
So if we want to break that down a little bit more, just one more Microsoft slide and I think I’m done with Microsoft slides. There’s one more I can think of, but there’s not a lot of Microsoft slides in this except this one too.
I just want to break out some of those services and where they fit into the line. So you can reference this to say where in the Microsoft ecosystem am I working, what am I looking at?
That’s why I included this one here. So just more of a reference. So if we actually jump into the recon portion of what we’re doing, we can start kind of the very beginning DNS records, right?
Anytime you’re looking at recon you’re going to be looking at DNS. So if we start here we can look at the DNS, the text record specifically and there’s going to be two different text records that I can think of that are going to be effective for us.
One of them is going to be as soon as you register a Microsoft tenant and you go and you say I want a custom domain, it’s going to pop up and say you need to authorize your domain.
So with that domain authorization they want you to set an MS equals value as a text record. So here’s one example of a redacted domain where they had a redacted again Microsoft Ms value.
So if you see that a DNS text record, at some point, they went in, they likely said, I want to register this domain as a custom domain within Azure.
And Microsoft gave them that value to add to the text record. The other one we can look at is, are they using M365 services for each. So exchange, online exchange, everything is considered the M365 side of the house, not the Azure side of the house.
And that’s going to be through, for example an SPF record. Maybe we see the SPF record for protection dot outlook.com comma authorizing Microsoft’s Outlook.com does send email for that domain.
So we can look at these from a text record perspective. Then similarly to the SPF record, we’d have the MX record.
So the mail record. so if we hit the mail record, do we see that mail dot protection dot outlook.com now I have a little note here and we’re going to get to this soon.
Beware of false negatives. So just because you look at the MX record and you don’t see mail protection, outlook.com doesn’t mean that mail isn’t working on that tenant.
Whenever you sign up for a tenant and you start adding different resources in there, mail is technically running on that tenant.
So we’ll dig into that shortly here. Actually, shortly, I moved the slide, so direct send when we look at that mx record, in this case on this slide, I have this mail dot protection dot look.com dot.
And Steve wrote, steve a tester here at Bhis wrote a really really really good blog post on direct send. And if you look at the notes on the slide, ive got a link out to the spoofing Microsoft 365, like its 1995 blog post that he wrote.
And specifically he digs into spoofing mail records through direct send, which is one of the Outlook mail connectors. Now the reason I say caution here is whenever I’m doing a Microsoft assessment or an Azure assessment for a client, I will go ahead and attempt direct send.
Whether they have this mail dot protection dot outlook.com or not. I will attempt to manually nslookup do we have the domain dash tld dot Microsoft dot protection dot outlook.com if that exists.
It means that M365 services are running exchange in the background so we can actually still attempt to do a direct send to that, to that client in our case, or to your company, whatever it might be, and see if we can get through.
Now, misconfigurations in the mail rules will sometimes still allow that direct send message to go directly, even though SPF does not allow it.
So I’ve actually seen instances where I’ve spoofed a mail record. It’s gone directly to the internal side. There’s no spam controls at all because they’re not using the built in Microsoft spam controls.
And there was no exchange rule, mail rule, transport rule to actually forward that to a spam system either. I’ve actually seen cases where we could directly attach executables, send them into the company and have users click on them to get shells back.
so it’s almost more dangerous when the company is not aware that this is running in the background. And I see that, I don’t want to say frequently, but more often than we should.
so to send a direct message, I have that text here, it’s also in the slide there and you just send it to whichever domain resolved.
the other thing I’ve seen is some clients set up, essentially like a mail forwarder, from domain a to domain b. So we’ll forward a message in or direct send a message in and it gets picked up by that mail forwarder and it still gets sent through, forwarded essentially to another domain because of internal trust that they have maybe some internal DKIM records or something else that they have set up.
So always, always a good thing to look at and check. Manual discovery looking at the vast items here, the reason why a lot of manual discovery works with Azure is essentially we have these static base URL’s examples here.
if you’re looking at blob storage it’s always going to be some customer name storage account, blob core Windows uh.net dot same with table storage, queue storage and more.
These are just examples. There’s more than I have listed here on the slide. essentially anything that will brute force a subdomain is how you can access different or find rather different storage accounts different.
table storage queue storage Azure files database web, which isn’t listed here in others. I’ve got a tool coming up next slide I think that will show that also we can use google dorks so we can go, I don’t want to say old school, but I remember doing google dorks like 20 years ago.
So we can go through and we can hit that static base URL, for example blob dot core dot Windows.net and search it for some keyword with google as well.
If we go forward, we’ve got cloud enum. Cloud enum is going to programmatically take that last slide and assess keyword, against everything that’s here.
Now, cloud enum will do more than just Azure. It can do aws and it could do GCP. But because we’re talking Azure, I have the flags to disable the AWs and disable GCP.
In this example, if we run cloud enum with a keyword, it’s going to take that keyword that we put in, it’s going to check all of these different base static URL’s with that keyword that we have over here.
I took an example a couple days ago of a blob that I knew existed. I put that in as a keyword. We can see cloud enum went through essentially uses this mutations and brute list here and attempts this keyword with some fuzzing against those static URL’s.
The very first check is Azure storage, accounts. it checked through there. It took 18 seconds, to go through that phase. Then we have this open Azure container, found it.
And it listed out the blob and then it found the static bucket within that actual container. And we’re going to dig into how buckets are set up just slightly with a Microsoft graph to show how those storage accounts versus blob data is.
And here it started listing off the files. And there were a lot of files in this specific bucket. I think these were intended to be public in this specific one. But I redacted it just to protect the.
So if we look at how blob storage is actually set up within Microsoft cloud services, which would be the Azure side, you start off with an account, and this is actually a snippet from a Microsoft site.
I’ve got the reference in the notes slide, portion of the slide. So you start off with an account, we’ll call it Sally. That’s like your storage. Then you set up containers inside of that storage and that’d be like your essentially blob bucket, storage.
And in this case you might have pictures or movies or something else. Then you end up with the actual blob data, the actual files. Now if you don’t want to go off and attempt a bunch of keywords, there is a website greyhatwarfare.com and they actually kind of go out and do a lot of this for you.
and with a free account, unregistered free account, you can go off and you can just click on Azure blob storage for example, and start to look at what different buckets are out there, what the containers names are, backup or pictures or movies or whatever it might be within that bucket.
And then you can actually click on the link to see the files and it’ll list all of the different files that they found in that specific blob storage within that storage account.
another thing we can look at is ad FS active directory federated services. There’s a manual URL you can go, that you can go to within Microsoft it’s the login dot Microsoft online.com getuser realm and this email address, some domain tld here that you would replace with any email.
It just has to match the domain. So you can say no one at whatever domain you’re testing. And you’re going to get two different items that might pop up here. You’re going to get is federated false, which means you’re using the Microsoft 365 entra id essentially.
and that might be joined on prem cloud joined might be dual purpose, something else. But regardless, that they’re using those services. The other option is you might get hey, this auth URL is federated.
So is federated true? It’s going to give you some auth URL, likely to an IDP, wherever their identity provider URL is. This will give you a little bit of information from the standpoint of are they federated with some other third party service like okta or something else.
Then Azure active directory internals. It used to be called Azure active directory. They since changed the name to entra id. but aad internals is still the tool that we use for that.
I just ran this get help, invoke aad int recon as outsider to pull off an example to throw in the slide. if I’m running it against a client, I typically just run this very very quickly to get an idea from a high level perspective of what is on this domain.
The FT is just the same as formattable in Powershell. I’m just shortening it to ft. We get a lot of information, including things like the tenant id. So now we have this tenant id which we will need for other tools.
sometimes when we’re executing certain commands we’ll need to specify the tenant id. So very quick and easy way to get that is right here. This desktop SSO enabled in this example, it’s false.
When we get to password spraying later, I’m going to talk about this specific case, if this were true. more often than not this desktop SSO is enabled in tenants.
from what I see at least, here’s another example. Down here we can see if they’re federated or if they’re managed, same as the previous slide that I just went through. but this will give us the actual auth URL portal and tell us whether they’re federated or managed.
Then additionally with Aad internals is going to give us list of other URL’s, other domains rather that we may not have been aware of that that company is tied to somehow.
so within the Azure active directory enter id format, that specific domain is tied to that tenant somehow.
so we can get lists of additional resources to go back and re recount against too.
Let’s look at username enumeration, probably one of the more fun and interesting valuable things we can get from m, M365 services relatively easily.
Now Microsoft does not find username enumerations of vulnerability. They say no, username enumeration is not, so there was quite a bit of debate about this years, many many years ago.
and they’ve held against that and I mean it I guess makes sense, to some degree, but only if you’re a big company like Google or Microsoft can you get away with saying username enumerations not a vulnerability.
So first we can start off, we could just do straight normal manual enumeration. so if we go with manual enumeration, it’s literally just hit that login dot Microsoft online.com site and we type in a email address.
so let’s just say it’s Kevin test.com dot. If Kevin dot test.com returns me to now requesting password from the same style Microsoft login box, it’s probably just a managed instance at that point looking at M365 services, if it however redirects me and points me to an IDP server, well now we know that it’s a federated instance.
The other instance that we’ll sometimes see is if you type in a URL or sorry, an email address and hit submit, you’ll get a pop up and it’ll say is this your work or school account or is it your personal account?
it’s essentially the difference between being tied to the company tenant or tied to a personal account. and that will actually pop up before the IDP instance because the personal side would be managed through like essentially Microsoft’s internal version of M365, whatever they’re using for that back end authentic.
so it has to come up before the IDP because the IDP is only going to be for work or school configured. So those are the different scenarios that I have personally seen from a manual enumeration phase.
Now a username lists, if you haven’t used, I highly recommend statistically likely usernames. Now this is older, I think this is last updated like seven years ago, I think maybe a little older.
It’s in the GitHub repo. you can check it out, but it was basically taken from census results. I tried finding a newer census list and what this used, I didn’t see any, with some quick searching a couple days ago, but so we’re stuck with this.
Unless you find a better list, let me know. but essentially this John Smith TXT has roughly 250,000 examples. this is that Johnsmith txt file.
Now obviously we have to know the email scheme being used by the company. there are a couple ones here. So we have like John Smith. So first, last, first name, last name for roughly 250,000, I think it’s 246,000 and change, usernames.
and then we’ve got a couple other formats here. some of these formats are smaller. so just be aware of what you’re doing. But regardless you can use some quick python or bash or powershell or anything else to cut this list up to format it to however you want.
what I really really really like about statistically likely usernames is I will commonly find a couple hundred extra usernames in large organizations that did not previously have through other recon results.
We’re essentially brute forcing username lists. it doesn’t perform an authentication with the tool that we’ll be using this against coming up here.
so have at it. Right. it does take a little while to run through, I think. I’m trying to remember how long it took last time I ran it, but it was probably a couple hours, to run through and test the 250,000 against a specific instance.
Now I didn’t cover Azure recount from the standpoint of compromised credentials. Obviously there’s going to be some form of compromised credentials that are out there that you might be able to get access to through various sources.
Obviously use those emails as well and just append those emails to the username list that you’re using, like this one. that way you get coverage from the standpoint of the statistically likely along with the previously breached.
Such a side note there. Now if we look at the statistically likely usernames, this is one place where you could use those. I’ve got, I think three different tools that I’m showing some enum potential enum with.
so the first one would be OneDrive enumeration. So we can actually, OneDrive enum, you can feed it a list of users. It will go through and attempt to access OneDrive, essentially another static URL that Microsoft uses, for those usernames.
In this case, I just had a test tenant set up. I threw in an invalid account with 17 valid ones and we have 18 tested and 17 were valid. It’ll actually write out what those 17 emails were to a list for us to use later.
Now there is a caveat to OneDrive enumeration. That is depending which Microsoft 365 services have been used by the user. In most cases likely used, likely valid, but there are cases where a oneDrive URL might not be made and I haven’t manually went through and tested each of these cases, but this is what they have on their GitHub page for OneDrive enum, specifying which Microsoft 365 services will create the oneDrive URL.
I know in the case of these 17 valid ones here, I had just stood up and created brand new users. They did not have any interaction at all and they were still found as valid tested valid.
so it might just be even the fact that there was a license assigned, it now activated it. I’m not quite sure on that. There’s definitely some more research that should be done there.
Then teams enum. teams enum will go through and attempt to enumerate through Microsoft Teams. Now the advantage to doing teams enum and typically I’ll go through and I’ll do some other enum first and then follow up with teams enum.
Once I have a more standard list of users, authorize known valid list of users. It just takes a little bit longer in my experience.
But you have to give teams enum a valid business account. You have to have a valid like e five license. on, I don’t know, it has to be e five, but you have to have a valid Microsoft license with a teams license on a business account and then specify a prompt for your password and give it a list of users.
Now what you’re doing is you’re actually going from your tenant or whichever tenant you’re giving it a, as this username to the remote tenant, your target.
And what’s happening is you’re using your team subscription to attempt to reach out to their tenant. And the reason you have to do that is a personal team’s license doesn’t work with the enumeration side so it’s not going to work the same.
So you do have to have a valid license essentially at that point whether it be a demo license or a developer license or something else. But the advantage to teams enum is it’ll actually give us user information.
So in this case right here with this redacted.com comma, we can see the user exists but the full user details cannot be fetched. we can alternatively sometimes see user status like they’re away from, they’re online, they’re out of office.
So we can actually get the different teams notification statuses of users remotely. if you actually go into the admin portal and you look at the settings that teams has, for external domains, external communication, these are the four different settings that you’re going to see here.
Changing these settings does not necessarily block teams enum from finding that a user exists. it will however change other settings, that you might get through teams enum.
Now that’s not to say we’re talking teams enumeration here. There’s lots of other ways we can enumerate users. So the fact that you’re blocking full user details is likely enough.
but from just a general standpoint of Microsoft Teams M365 teams, obviously you don’t want any user to be able to reach out to your internal users.
it’s relatively common that we’ll reach out to users over teams and send them a phishing URL or something else. I guess you call it teams phishing, I don’t know.
but we’ll reach out and we’ll talk to users. We’ll stand up on Microsoft that looks similar to your domain. and then try to hit users that way.
by default teams is just allow all external domains. I don’t think I have a screenshot of it, but the teams default is basically as open as could possibly be in a brand new tenant.
you need to go through and lock those down. Then we’re going to look at Cred Master from a username enumeration.
There’s a lot of things we can do with Cred Master. We do user enumeration, we can do password spraying, we can do a few other tasks. I’m going to cover user enumeration first here, and then we’ll jump over the password spraying with it.
But in general, Credmaster uses Fireprox. If you’re not familiar with Fireprox, I don’t have a link out to it, but if you just Google GitHub Fireprox, it’ll pop up.
What Fireprox does is it stands up an AWS API endpoint. It allows every single request made to that API endpoint to redirect through a AWS IP address pool.
Every single time you hit that endpoint, it’s going to cycle the AWS backend ip that’s being used. Essentially what this looks like is if we’re doing username enumeration, every single username lookup is going to come from a different AWS IP address by using Fireprox.
when we get to password spraying, this gets especially interesting. and we’ll talk about that coming up. But we can enumerate with o 365 enum, this specific plugin.
this command here will use Cred master to enumerate o 365 against some domain. We do have to specify again the AWS access key, and AWS access, secret access key here.
Then we can output those to maybe email log or whatever you want. Cred master will append dot or dash Credmaster txt when it creates that log file.
So here we can just see two valid usernames. completed enumeration. I just threw two in as a test to get the screenshot. This does not perform authentication for, for the username enumeration.
then if we move and we look at Cred master for password spraying. So there’s something I want to point out about Cred master password spring. I just specified it’s going to be using fireprox.
Now that does create somewhat of a signature in the log file, in this case a password spring with Credemaster. I’m going to use the plugin MSOl for this example here.
we specify domain. We got the access keys here for fireprox passwords. per delay. If you have a really, really long word list so you’ve got 20 different words that you want to spray, you can actually say, in this case I’m just doing one password per delay.
I’m saying a delay of 67 minutes, a jitter of one. And then I’m specifying the user’s list, whatever that password list is, and then output to some log file again.
Cred master will error if this is a duplicate. So if you just did enumeration with emails log and now you’re repassing the spray, it’s going to error out. Make sure you’re using a unique name there.
But the interesting, kind of fingerprint that’s left in the log file is your users are probably not typically logging in as AWS, from an AWS IP space.
So if you go into your enter id monitoring sign in logs, you can actually look at the sign in logs and see different items occurring there. From the standpoint of AWS, authenticated login, or failure.
If you see failure after failure after failure of login, different users that it’s likely that something like Fireprox is being used to spray users as a fingerprint.
So definitely look at that from a rule standpoint of something you should be, should be exporting these logs and viewing those, reviewing them. Now, I was playing with Cred master kind of getting ready for this, and I decided to try the plugin Ms graphite.
so I threw in the plugin Ms graph, very similar to the password spring that we previously saw. And I got a different error message here. So you can see I’m using Fireprox. I’m going through USD two for these, we got these two different failure codes.
Invalid username or password for admin at this company. And then failure this Aad STs error code Azure active directory sts error code I actually have on the notes for this slide deck, the link out to all of the different various aad error codes.
But in this case we see request body must contain the following parameter client assertion client secret this was a valid login. It’s just cred master didn’t know how to handle this specific error message if you’re spraying and you’re getting different error codes, different results.
And this applies to any tool, not just this, but dig into what that error code specifically means in this case. I could use this for validating credentials, as well, but I’m going to be getting different error codes out of it.
Just a heads up on that part. If we go back and we look at Cred master for password spraying, I previously mentioned using aad int recon as outsider.
if we look at this desktop SSo enabled. If this was true we can use the Azure sso plugin with cred master. it’s another different endpoint that we can password spray against Azure.
Just yet another example. So we got creds, I don’t know if you saw it.
Right back here we’ve got this adele v as some domain with yet another weak password one bang. Let’s go ahead and just do a quick exploitation on that user.
We’re going to look at does that user have multifactor? There’s a lot of things that contribute to multifactor being abled within M365 within Azure. we’re going to dig into a few of those coming up here, but let’s just check the account.
I took the adele user here and I used find me access which I’ve got links to. to say what endpoints can we hit with the adelbe user that do not require multi factor authentication.
Now I had previously configured this user. This user had no multifactor setup. Okay. They just, they didn’t have any. So over here we see true, true, true, true, true, kind of all over the place.
This is a little summary graph for the resources and the number of accessible client ids that you’re going to get. what we tend to see if we find a valid account in the wild is we’ll tend to find a couple of these accessible client ids and it might be something like maybe you can access outlook overdose, one of the different resources, with a mobile user agent string or something.
So we can actually go through and see hey if we’re using a mobile user agent string, we can access that. So then we can go through and exploit it from that standpoint. And that’s because, well, mobile users don’t want to type in multifactor.
I get it. but we need to have that so you can do a quick assessment on your own company from this with permission, with perspective to are there any applications that are allowed through that maybe we need to go through and check in the rule set of why that’s allowed through MFA sweep, another tool, from bhis that bo wrote, mFA sweep does similar.
MFA sweep’s been around for a long time. If you do the standard invoke MFA sweep with the username, whatever it might be, it’ll go through and you’ll do I think roughly ten different checks.
and here you can see the specifications of like M365 with Linux user agent string, Android user agent iPhone, et cetera. It’ll say whether it was allowed or not.
he just updated in the last week, I want to say or two to start brute forcing client ids. I don’t want to take his thunder. I don’t know if he’s talking about this later. I just told him hey, I’m going to bring that up.
And he didn’t object. So there is a, with MFA sweep you can now invoke brute client ids. You can specify a username and a password. It does require specifying password.
It won’t pass through and prompt auth like MFA sweep will currently. So you have to specify it. And we’ll see down here we’re testing a client id and it’ll go through and check whether or not we’re valid.
So the additional thing that I noticed that Bo is doing with this, literally was playing with this, I think last night, was he’ll actually save the token off.
So if we look at it from the perspective of find me access, to my knowledge it’s not saving any of these tokens off. So with MFA sweep in this access tokens, we end up with a list of hey, here’s valid tokens and renew refresh tokens for that authenticated login.
So we can actually go through and steal that token and just move with it right away. Now from a logging standpoint, if we go back and we go to enter id, we look at the monitoring sign in logs.
This is one very, very small snippet of a find me access against that Adele user. So we can see within this is actually less than a two second window because there was some above and some below this.
But we see all of these successful logins for different endpoints that were being tested, success fail. So gives us an idea to some degree, again, another fingerprint that someone was running some sort of a find me access, an MFA spray, some sort of brute force.
Is their MFA enabled within these logs? So we jump in, look at find me access.
I’m going to generate find me access will allow you to generate tokens. I use find me access and I specify give me a token for the Microsoft graph API.
And let’s just do Microsoft Azure Powershell. what this looks like is here we see the resources like graph dot Microsoft.com and we get the ey, the JWT essentially access token.
Now again, this allows us to take the specific resource and client, and pull a token for that resource and that client so you might not get standard permissions.
Like if you just use your normal user account you’re going to get, and you have the multi factor token and you enter it into a tool, you’re going to get a lot more potentially permissions than you would getting specific client ids and endpoints.
but nonetheless we can generate those specific items and work on exfiltrating. So if we look at JWT tokens, these are snippets from JWT IO of this decoded token that we got in the last slide.
So we can see it’s Actually sorry, this is for yeah, this is for, I might have grabbed the wrong screenshot for this, but regardless we can take this specific access token.
And I don’t think it was this access token because this was a graph endpoint. I pulled the next screenshot and showed it in the JWT IO. So this token that I decoded in JWT IO was for outlook dot office.com.
and we can see it had the app display name. So it was a Microsoft teams app id tokenization for that adele user. this slide here, this token example where I generate a token for outlook with the teams id here.
Thats what I was showing on that previous slide. So token setup. If we generate this token and we copy everything between the quotes for the access token. So we get the EY J zero ex JWt token id go through and we save that as tokens text on a Windows host.
When we jump to that Windows host we can use a tool like teamfiltration exe. and we can specify that token and we can exfil all.
I just set up a very sample kind of a demo scenario where I had an admin email, Adele or whatever the name is, Adel and gave the password in an email.
So by running this exfil all of we can see, and team filtration does support Fireprox in this specific screenshot here. I decided not to use it.
I said I was an adult. Yes I am. It’s just a demo. but it does allow using that if you configure it recommended if you’re doing this on an actual test.
here we can see that it parsed the user and it found an exfiltrated emails from Outlook. In this case two emails were found. If we go to that demo folder that we specified in the out path, we can see the user outlook emails open up one of those emails and we say please don’t tell anyone this time.
Here’s your password. So you’d actually get a list of multiple emails here if they had more than just one email. now teams filtration can do a lot of the other stuff that we’ve already talked about.
it can do user enum, it can do password spraying, it can do kind of everything. I want to give you that piecemeal. Here’s other tools that do it.
Here’s another tool that does it. It just depends on the scenario you’re in. team filtration is a windows tool, Cred master and others are Linux tools. So you kind of have to pick the tool for the job.
One note I will say about team filtration, you have to use that proper token. If you’re using a token that doesn’t have permissions to what you’re trying to exfiltrate, it’s just going to show an empty directory.
within that demo directory it’s going to have the local database for team filtration that was generated. But it’s not going to have any data. It doesn’t mean that the data is not there, it just means that that specific token didn’t have access to that data.
So just do be aware, depending on what that token has access to. So MFA checks.
So there’s a lot of different ways, that you need to check your instance, your Azure, your M365 instance for MFA. I pulled out a few examples here from this test, domain test dennet that I was using.
One of the things was authentication requirement, single factor. If we actually go to entra, we go to the sign in logs, manage the sign in logs.
we can create a filter, we can add filter here, we can choose authentication requirement. Then we can click here and we can choose single factor authentication. We can see our users using single factor authentication, actively using it, not that it’s available, just actively being used.
So this is kind of one of those scenarios where management comes to you and says well we can’t disable it because people use it all the time. Well maybe they do, maybe they don’t. you can actually go in and start auditing that, start checking.
Is this actively used? It gives you awareness, situational awareness to the risk that you have, right. And then from there you need to work on how do we weed it out, how do we get rid of it? Was it a mistake?
Maybe you intended to have it also, where are they logging in from? It’s not in this little snippet here, but you’ll have the IP address, user agent string, a bunch of other metadata to this actual authenticated login.
another place you can go is within identity protection. You can actually say require that multi factor authentication. registration on user, setup.
Now I have a little bit of heartburn with this. Yes, it’s a good setting to have. You need to have it set. However, I cannot count the number of times when we as testers find an active account that’s not actively used by a user that we password spray successfully and we set up the multi factor for the user.
I’m not aware of anything in Azure that as an active configuration option. M, M365 I said that M365 is limited in what we can do.
You could programmatically create a Powershell script to go in and audit it. But I really wish M365 had. Like if user has not set up multi factoring x number of days, disable the account.
maybe there’s an option in there. I haven’t seen it. but regardless, it’s a nice thing to consider for you. How long have these accounts been active and do they have MFA yet?
If they don’t have MFA, really the question is why? Right? it’s obviously not used or they never log into Azure. M365, they never log into those services.
Do they need those services? Can you remove them from those services? then, another item that might be caused, with this authentication requirement, one of these other metadata fields is, conditional access policies.
Now this test tenant that I was using was set up with just the Microsoft, security defaults. Microsoft security defaults do not use conditional access. They have these default configuration without conditional access.
Now I thought this was really interesting. I went to the conditional access with an enter id and I knew that this box was here where it says, see all unprotected sign ins.
Now notice this says zero users signed in during the last seven days without any policy coverage. Yes, that’s true. There was no conditional access policy coverage.
but if I had conditional access policy coverage enabled, this number would tell me essentially how many unprotected sign ins there were with single factor authentication. Also, it’s Microsoft’s math number.
I don’t know if that was just a bug that should be fixed or if it’s just the verbiage needs to be changed to zero signed in in the last seven days using conditional access policies.
I don’t know if I actually clicked the c unprotected sign ins. These user logs were also shown as obviously unprotected sign ins.
So just a bit of an oddity there. So I recommend even if it says zero, click the box and check. but one of these reasons for the single factor authentication is again we find conditional access is like its own topic.
We could probably talk about it for an hour someday, right? these rules get very, very complex and sometimes just adding certain applications in not thinking about it or adding certain exceptions to the conditional access policies start to create these holes much like we saw in traditional firewalls or on prem firewalls wherever I, one rule kind of goes further than it should and takes over a bunch of other items.
So we tend to find those as the tricky issues that didn’t require all Microsoft applications for example, or all Microsoft resources to use, sorry to require multi factor authentication.
All right, so time check, we’re a little low but we’ll keep going. We got a little bit of time here. So authenticated reconnaissance, once you have credentials, this could be from the attacker’s perspective or your perspective auditing your own organization or checking, validating your own organization.
there’s some quick wins with credentials. One of the utilities I really like is just 0365 recon. 0365 recon. When you import it it’s going to just prompt you for credentials.
You pop in the credentials and it’s going to quickly give you some CSVs and text files here of overall layout of the land. It’s just a one time shot, very quick, gives you that user list.
Now we could take this users list that we have once we have one authenticated user, now we can take this list and we can go back to that password spraying.
Now that we have all valid users within the company as of the time of pulling that snapshot, I like to go back and cycle back through those credentials again, and potentially hit more with those basic creds, road recon.
so rode recon takes a little bit more time to run but it’s going to go through and you have to authenticate with a device code once you authenticate with that device code again provided you have the multi factor auth or you can somehow gather a different way, then we can run gather and it’ll give us a nice webpage, with users, groups, devices.
Just a really great dump of that. Again data from M365, and Azure, then Azure Hound, we all love bloodhound on prem.
so we have to talk about Azure Hound. So Azure Hound, once we have those credentials again we can run that against the tenant. It’s going to go through and again this was that test tenant that I had.
It only had 18 users. It was not set up for, for really anything here. but it’s going to go through and it’s going to pull a lot of Azure objects out.
there’s some really, really interesting attacks and this is a recon discussion so I’m not going to dig into those attacks because number one time, certainly and number two is it’s a whole different topic, but there’s a lot of really interesting attacks within Azure hound that you can query from a tenant perspective, go through, pull the Azure hound, start to look through what those objects are and potentially how you can elevate in that tenant graph.
runner another bhis tool. So getgraph tokens will pop up and prompt for device code authentication. when you get that graph token, these are the default permissions on the graph token.
Sometimes when you run get graph tokens. the screenshot I have here is just the standard Microsoft M365 default tokens. Sometimes when you run it, if the user is restricted on what they can do with the graph token you’re going to see a lot less permissions here.
I was just talking with another tester a couple of days ago. They had two permissions in here. It was user read, and that was it or something like it had almost no standard permission.
So do double check what permissions are included, within that token. so we can run like get Azure ad users with the tokens, dollar tokens and go through and query again the users from that tenant.
We can save it out to a file. some of my favorite things are kind of go to things with graph runner. is this permission enum it goes through and it executes and it shows you a lot of the M365 settings, a lot of the tenant settings that are set up.
so you can look at things like can users create groups, can users, trying to think of some of them invite guest users, different items like that.
the other thing here is dump caps. Caps are those conditional access policies that we talked about. So we can actually dump the conditional access policies and start to go through and review them and find oh hey, did that there’s an exception in this caps policy?
Maybe for even for something like teams or outlook or something else? maybe we can go and request a specific token for that now if you remember running find me access and MFA spray, they’ve got fingerprints, in the logs of multiple logins.
So if we can, if we’re able to, maybe we just run graph runner first. It’s one login, right? And then we go through and we dump those caps if we’re trying to be sneaky about it.
And now we go through those caps and see is there any way that we can bypass this rather than going through and hitting it with a sledgehammer, with a find me access or something?
obviously getting the users, that’s the screenshot here. get updatable groups. It’s possible that there’s groups that you as a user can add yourself to that you aren’t currently in.
I like to get those groups and actually there’s another command for it, but I like to then add myself to all of those groups to see what other juicy data is out there.
I’ve, I’ve done this on a couple clients and ended up getting some, some really, really nice high fidelity things like, credentials for other accounts. complete domain takeover, get dynamic groups.
dynamic groups are, it’s almost like conditional access policies. It’s a whole nother thing. It’s essentially conditions that are set to add you to a group.
so sometimes you can find certain conditions that you might be able to manipulate that then adds you to a new group. maybe admins contain administrator, and the username or something.
And you can also invite guest users and you can have administrator in the username. You could then invite a guest user with administrator in the username with a username that contains administrator or something.
invite that guest user come in and now get added automatically to that role. so dynamic groups are worth looking at. and then obviously searching Sharepoint in Onedrive for sensitive and valuable data.
scout suite, I wouldn’t run this is another sledgehammer tactic. but Scout suite is great for internal teams who are trying to do essentially an audit or a security check against their own tenant.
Now Scout suite does require subscriptions to run. when we look at something like graph runner, the user doesn’t need a subscription because all you’re touching is Microsoft 365 stuff, really.
Scout suite is heavily focused on really the Azure side of the house. You need those subscription resources, which is Azure. Anytime you’re looking at Azure you’ve got a subscription for it.
it’s looking at those subscriptions and pulling out key data for that. And then running an audit against that, it creates essentially a website, you can come up and you can run JQ against, there’s a couple JSON files that are output by scout suite.
You can just run JQ against them, but it also creates a dynamic website, and you can go through and click through. If you were to click on say network it would take you to the different checks that were run.
There’s maybe some green boxes, some yellow boxes and some red boxes. this network one might be like there’s a network access rule that allows everything outbound.
in fact whenever I’m testing a client I tend to find cloud hosted in Azure AWS domain controllers. For whatever reason you can chalk 445 outbound on those, more frequently than I’d like to admit.
so there’s always that. But scouse, we highly, highly recommend running it from an internal perspective or if you’re, as a tester, you just want to hit the sledgehammer.
I have seen this detected a couple times, very very rarely, which shows us that there’s a huge lack between taking these fingerprints and applying them within companies.
powersure, another great, I like to use this for the operational post op stuff, within Azure, like dumping credentials out, dumping run books and those kinds of things.
There’s one more thing, two more things I wanted to hit and I know we’re close on time. So number one is benchmarks. Look at the CIS benchmarks. Look at the other benchmarks that are out there to learn how to audit and modify your configuration.
M365 has a ton of defaults that are really, really really weak. And if you go through and you hit this, this was a screenshot from actually like 2019. There were 60 different recommendations.
I know there’s more today in those benchmarks. ATT and CK has a whole separate framework, for that as well. And the last piece that I have here is practice.
Right? practice makes perfect. You gotta practice. A lot of us maybe are thinking, I can’t practice this. I don’t have an Azure tenant. So there is a Microsoft developer program.
If you have a visual studio Pro license or an enterprise subscriber, you can get a free developer license. You essentially go to developer Microsoft. Click here, click here, click join now.
And you can actually create a developer program. Takes a phone number. You can add these sample data packs for users. It’ll add like I think 17 default users.
And you can add mail, it gives you full licenses, you can do teams, you can do, outlook. You can do kind of everything that you just saw here in the slide deck today.
So highly, highly recommend doing that. That’s all I got.
Jason Blanchard
Jason’s muted.
Deb Wigley
All right, there we go, Kevin, well done. It was Kevin’s first Black Hills information security webcast. Thank you for coming here today, sharing your knowledge about how to do reconnaissance for Azure.
we do have questions, but we’ll get to them in some post show banter. So we’re running out of official time. So, Kevin, if you could sum up everything today in one final thought, for people to take with them, what would it be?
Kevin Klingbile
Situational awareness. run this against yourself. If you get permission to, see what’s out there, be aware of what others can see about you without knowing it. Like, ad int recount is outsider.
It’s going to show you those other domains attached that you might not, you think are hidden. You don’t know about. MFA. MFA, MFA. And double check that you actually have executed MFA properly within your tenant.
Deb Wigley
So thank you so much for joining us today on this Black Hills information security webcast. We’ll stick around for a couple minutes to do Q and a. but if you joined us today, thank you so much. If you forgot to do hack it inside discord.
So it’s got to be live during webcast in discord. If you engaged at all today, you did get credit for it. If you have, like, a little storm cloud next to your name, you’re good to go. but if you didn’t check in for Hackett and if you don’t know what Hackett is, is that every 10th webcast, 10th and 20th, 30th, 40th, and 50th webcast, we send you a reward in the mail, and you’re like, really something in the mail.
Yes, it does arrive to you. It comes to your mailbox. It’s fantastic. so make sure that you check in for Hackett. And thank you so much for being a part of this community. We hope that you engage between the webcasts.
So stick around inside the discord. Ask whatever questions you have. Ask questions about your career. Ask questions about, red teaming or blue teaming or threat hunting. Like, there’s channels for it.
There’s room for you to ask your questions. And then there are so many people in the community that would like to, share their knowledge with you to help answer those questions. That’s how we all get better. That’s how our security improves, and that’s how the world becomes a better place.
So thank you for participating in that all right, if you do need a red team thread hunt pen test, especially for 2025, now’s the time to reach out.
All right, now let’s move on.
Jason Blanchard
Can you do that again? You added a little bit after confusing.
Kevin Klingbile
If you need a cloud assessment, we do those too. Yeah.
Jason Blanchard
So we might have missed questions, since there were about 1200 of you here today. So if we did not answer your question, go ahead and pop it again in the discord and we will ask.
Kevin Klingbile
I did see one question here. Doesn’t developer subscription only last 30 days? So I just signed up like literally three days ago, four days ago and it gave me 91 days. I heard that this is renewable too, so as long as you continue to use it, it’s going to at some point recycle that, and pop back in.
Deb Wigley
Just so you’re aware, someone said to be a noob. If I understand this correct, if you have an external spam filter, it will not catch the spoof email that he showed earlier in the cast.
Also. Awesome cast and thanks.
Kevin Klingbile
So it really depends on how the mail is set up within the tenant. there’s transport rules and there’s mail flow rules. a transport rule might take all mail that’s received by M365 exchange, and forward it out to that spam filter.
there might be a mail flow rule that’s actually going to intercept and say if it meets certain conditions, send it directly. we used to see that really, really commonly with phishing products.
I don’t want to pick on any one phishing product, but whatever phishing products are out there they used to say because you used to not be able to do these granular rules within, within M365.
Back then it was 0365 or whatever they called it. these granular rules. And they would say if the mail header contains product name, allow it through the mail filter.
so then we can just create spoofed mail with a mail header and it gets forwarded to users that way as well.
Deb Wigley
Yeah.
Kevin Klingbile
So there’s a lot of different configuration.
Deb Wigley
In there, but yeah, I also reshared, the blog post by Steve.
Kevin Klingbile
Yeah.
Deb Wigley
just a reminder, if you are currently with Microsoft and you’re watching today’s webcast, we see we appreciate you and we appreciate the emails that you send afterwards, fact checking and letting us know that this is why you do the things that you do.
we enjoy getting those emails and we appreciate it. Thank you Microsoft.
Kevin Klingbile
Thank you Microsoft.
Deb Wigley
Wouldn’t Microsoft defender catch Ada internals or any of the other tools being run once accessed is achieved.
Kevin Klingbile
So, once access is achieved, it’s a whole different set of rules. So we’re really looking at the risky sign ins and a few other things.
that all depends on configuration. And so when I think about it, I can think of a couple clients, I could probably count them on my two hands, that have actually detected something like a breach once we’ve achieved it from that standpoint, I run all day long like find me access MFA spray that’s only ever been detected once or twice I can think of.
so it’s very very very dependent on how you have configured those rule sets. and there’s a lot of configuration in there that we’d have to dig down to and look at.
I’d almost look at the other metadata on the sign in logs, to see what you can filter out from that aspect. But no defender, like ATP and the others out of the box.
I haven’t seen anything other than that handful of times.
Jason Blanchard
this question was asked a couple of times. how do you verify entre two fa when using something like okta?
Kevin Klingbile
Well, so I’m not sure if there’s anything that is there. We rarely run into, an unmanaged instance where we’re spraying against that.
Every now and then it’ll come up. So I actually haven’t tried to see what happens if we spray against an instance like that. but the sticking through the different ad fs flow here.
So if we can’t directly authenticate to M365 entra, it’s going through okta, then okta would be the provider.
So in that case, if we try to generate a token somewhere else, it should redirect us to okta, would be my guess. I don’t have a demo set up to test it out or try it though.
Jason Blanchard
Sure. Our buddy Jeff McJunkin says, have you used, purplecloud.net work? Any thoughts or impressions of it?
Kevin Klingbile
I have not. Purplecloud.net work. Mhm. I’ll have to take a look.
Deb Wigley
someone asked how they get CPE credit and just want to let everyone know that we switched over to a new company called incredible about four months ago. so if you do a search in your inbox for [email protected] you should find them in your spam folder or check your spam folder to see if you’ve had, need to set up a rule where that comes to your inbox so all of your, and this.
So if you’ve attended like seven or eight of them then you’ve gotten credit for all seven or eight of them until you actually like go and check your credible account. So if you’re using the same email address for each one of your registrations, then there should be a repository of all your certificates for your black hills, same thing for anti siphon, same thing for active count measures.
If you’ve attended those, it’s all in the same repository. So we’ve been keeping track and once we get an intern on board we’re going to go retroactively for like the last three or four years and make sure that you get those too.
So, but it is time intensive, make sure. And we also want to make sure that we’re not like transferring your data in a way that’s insecure. so that’s, that’s what we’re working on.
Jason Blanchard
A couple intern job right there.
Kevin Klingbile
Yeah. M question here. How do you decide what needs a tool and what’s the process for making them?
Deb Wigley
Mhm.
Kevin Klingbile
So I always heard this kind of go out and look for a tool for about 15 minutes. If you can’t find the tool in 15 minutes, it probably hasn’t been written yet. Right.
So if you’re trying to do something very, very specific in there, I mean there’s so many tools I didn’t even cover in this deck, there’s just not enough time, and I feel bad about some of them, but I just didn’t have time for making them.
Wow. I guess so many other people that would be better responding to that. I don’t really develop tools. I develop a lot of scripts so I write some quick python, some quick bash and kick that out.
but for developing a tool I suppose it’s the same. Come up with that minimum viable script or tool that works, put it out on GitHub and ask the community for, for some feedback.
Maybe hit up some people in the discord chat, for that as well. There’s plenty of developers there.
Jason Blanchard
A good follow up question is, do you have a course that one could take to learn more about this? Kevin, have you thought about doing a class?
Kevin Klingbile
I’ve thought about it, yeah. So I’m in the process of developing a class right now. I’m probably right around 70, 60, 70% done with it.
so I use the base of some of that for this slide deck here on just the intro and recon portion. so I’m looking at having a two day class probably in the next couple months.
Here. using Cred master’s MsOl plugin will start triggering Azure smart lockout at around ten failed logins.
Have you found a way around this? Yeah, so great question. I actually meant to bring this up when I was talking on that slide and I forgot to. So the Fireprox is going to use a unique address from AWS when you’re using that.
So if you’re running Cred master without Fireprox, it’s going to very, very quickly and I don’t know if it’s ten, I usually see it around closer to like 40 or 50. You start getting that smart lockout, but by using Fireprox with it, you’re going to avoid that smart lockout to a degree.
I say to a degree, if you run cred master every 67 minutes like I had in the slide, for about a day, you’re going to start getting still smart lockouts in the background.
So there’s some secret saucer that Microsoft has. We don’t know what it is, but after some period of time they’re fingerprinting that to some degree and we’ll start to block it from that standpoint.
But yeah, switch over and start using Cred master or Fireprox with Cred master.
Deb Wigley
Anyone know of any deeper courses on Azure? M365 maybe business email compromise related? I think Derek’s working on a business email. no, Patterson Cake’s working on business email compromise course.
Okay, I think that’s it. Yeah.
Kevin Klingbile
All right.
Deb Wigley
If we didn’t get to your question, we apologize. but what Kevin’s going to do is take those questions, figure out a way to either potentially future blog posts or content for training class or a, future webcast.
So thank you so much for asking those questions and hopefully you got your question either answered by the community or by the others attending. so we appreciate you sticking around.
Q and a. This video will be available on YouTube, so you can definitely check it out there. You can look at all of our past videos. And if you go to poweredby, it’s a new site that we have.
You can take a look at all future webcasts that we’ve already like figured out and planned and prepared. we have webcasts scheduled into 2025 already, not like in that website, but internally we have them.
we’re still figuring out what the content’s going to be and who’s going to teach it and all that other stuff. So thank you so much. We’ll make sure you get credit today. And if you unlocked a special channel for Hackett, then, make sure that you go and get your reward.
If you have no idea what I’m talking about, come, back to other webcast, and we’ll talk about it some more. Deb, anything that you want to say before we get going? Because we have wildlife hack and fest coming up. You’re the director of kindness and generosity.
Anything that you want to say?
Jason Blanchard
No, just, thank you. Yeah, I guess I want to say more kind things like thank you for showing up. Thank you for spending your valuable time with us. We know time is, almost worth more than money.
At least my time is worth more than money. So thank you for sharing an hour with us and, being so positive and helpful. Everyone answering questions is always. It, warms my heart to see you guys jumping in, answering questions.
And thank you, Ryan, for not spotlighting me. I appreciate that.
Deb Wigley
Kevin, great job. First webcast down. We’ll, take a look at when you can do another one in 2025 because you did a great job. Well done, spoke well, very easy to understand.
You broke down complex concepts into small things. We appreciate you. And, with that, Ryan, kill it with fire.
Jason Blanchard
Kill it with fire.
Deb Wigley