This webcast was originally published June 2, 2021
In this video, Beau Bullock from Black Hills Information Security discusses penetration testing in Azure cloud environments. He provides insights into the methodology of attacking cloud environments, focusing on Azure but also touching on AWS and GCP. Throughout the presentation, Beau aims to equip viewers with the knowledge and tools needed to successfully conduct penetration tests on Azure, enhancing their understanding of common terms and potential attack surfaces.
- Beau Bullock, a seasoned pen tester at Black Hills Information Security, shares insights on Azure pentesting, emphasizing the importance of understanding the cloud environment’s attack surface and potential security configurations.
- The webinar highlights the evolving nature of cloud security and the challenges of keeping up with configuration changes, underscoring the need for continuous learning and adaptation in cloud security practices.
- Tools and techniques for attacking Azure are discussed, including external attacks, internal resource-level penetration tests, and API access level attacks, demonstrating the multi-faceted approach required for effective cloud security assessments.
Highlights
Full Video
Transcript
Jason Blanchard
Alright, everybody, welcome to today’s Black Hills information security webcast. If this is your first time ever joining us for a webcast, thanks for being here. 2nd, 3rd, 4th, 5th, 100th time for being here. Thanks for coming back, we appreciate it.
we enjoy sharing our knowledge with community. That is what we do. We have a community of 20,000 members on Discord where we get together. And so if you want to join that, the link will be here in good webinar or on YouTube, wherever you choose to watch.
the community is going to help answer your questions. So if you ask a question inside discord, if it doesn’t get answered, we’ll see if Beau can answer it at the end. But we’re not going to stop Beau while he presents today unless something bad happens, like to the equipment or anything else.
So we have today with us Beau Bullock. He is a pen tester here at Black Hills information security. And Beau, you’ve been around for a long time. You create tools like domain password spray and.
Beau Bullock
Seven years, yeah, huh? Yeah.
Jason Blanchard
One of the first hires of black Hills. And I’ve known you for years. I met you at SANS back when I worked there and I watched you play net wars. You were one of the people I called when I said, should I come, work at Black Hills because I wanted to.
Beau Bullock
Yeah. Yes, please do.
Jason Blanchard
And so thank you so much for joining us today. If you ever need a pen test thread, hunt our red team or any of those things, where to find us. But that’s not why we’re here today. We’re here for this webcast with both. So I’m going to turn it over to you.
It’s all yours, Beau.
Beau Bullock
Awesome. Thanks, Jason. Thank you all so much for being here today. Today’s talk getting started in pentesting the cloud azure. This talk is really meant to be a primer for azure pen testing.
So I teach a four day class where I basically walk through the entire methodology of attacking cloud environments, not just Azure, AWS and GCP as well. But in that class I cover a lot of azure stuff. What I wanted to do is basically treat this talk as a primer to go over.
Here’s all the things that I think if you want to get started attacking different cloud environments, specifically Azure today, you should be able to take this presentation and go off and have a decent level of success knowing at least the various terms and what you’re up against.
Hopefully throughout today, this is going to help make you aware of some of the common terms associated with azure assessments. As well as some of the potential attack surface.
My name is Beau Bullock and I am a, pen tester, red teamer at Black Hills Information security. Like I said, I wrote a course called breaching the cloud.
Got a few certs. I primarily run red team engagements and cloud assessments. Recently. Historically, like I said just a few minutes ago, I’ve been here for seven years, at Black Hills, and kind of covered the gamut of different types of testing, web apps, wireless, all the things.
But over the last couple of years, I’ve really focused heavily on just doing red teaming and cloud assessments. So throughout that experience, I’ve been able to spend a lot of time focusing hard on the methodology of how to attack cloud environments.
I also written a number of tools. A lot of them are out on GitHub, which we’ll actually talk about a few of them today. And then I’ve also, I’m also produced some synthwave metal music, for a project called no bandwidth.
All right, so, roadmap, first things up. What we’re going to look at right off the bat is looking at identifying ATt and CK surface. And the reason is because this is, in my opinion, one of the most important areas right up front of any sort of cloud based assessment.
We’re going to talk about a lot of the different angles you can approach Azure from, because a lot of them are not clear immediately. And some of them take a little bit of knowing that they actually exist and identifying those methods before you even engage in, a cloud based assessment.
The second thing we’re talking about, we’re gonna go right into recon and external attacks. So we’re gonna look at things like how can we identify what authentication mechanisms that a cloud service uses? What kind of external attacks can we carry out?
Are we able to hit public resources that are, that are hosted in Azure? Then we’re gonna look at authentication. Authentication is actually a fairly large section of this presentation due to me basically thinking that this is one of the most important things when it comes to authentication.
There’s a lot of configuration issues that can, can arise from not configuring things correctly. A lot of the time those configurations are, they can tend to be pretty easy to misconfigure.
Then we’re going to go into post compromise right after getting access to a credential. We’ll look at what can we do with those credentials, and we’ll explore a little bit of what are some things that we could potentially attack, what, are some escalation paths what are tools that we can use to perform additional attacks?
Following that and directly related to post compromise is going to come the Azure subscription hierarchy. because knowing what subscriptions are, what resources are, knowing how the different roles and different permissioning is set up within Azure is going to help us understand better what we can get to and then we’re going to look at resource specific issues.
So in that section it’s going to be kind of a rapid fire. Here’s just a few slides of some things that I think are some of the top most interesting things to just go after immediately and some things to be aware of.
And then we’re going to look at leveraging scanning tools because a lot of the times and we’ll discuss this once we get to the identifying attached service section. We can make our lives easier by leveraging scanning tools to find various low hanging fruits in terms of vulnerabilities and help make our lives easier.
Why Azure? Azure is one of the most popular pieces of software that I see utilized by a lot of the organizations that we test.
So it’s really, really popular due to a few reasons. Got organizations that historically have been Microsoft, active directory shops like Internal, Microsoft Active Directory and now they’re thinking okay, well how can we make our employee force more productive remotely and pushing a lot of those resources to the cloud.
Since Azure has that functionality of integrating internal on prem ad with cloud based Azure Active directory, it makes it really easy for companies to move and have that access and have those capabilities to have employee workforce utilize things like Office 365, SharePoint, that kind of stuff.
Us as attackers. And honestly, like through a lot of the pen tests that we do, we tend to at least see some 0365, some Azure usage throughout a lot of our engagements.
One of the things to note here is that hybrid environments can potentially enable these cloud to on prem pivoting potential paths us as attackers. If we’re doing red teams, we’re doing external assessments, or if we’re doing even cloud specific assessments, a lot of times what we’re looking for now are how can we leverage credentials that we get during the engagement to attack Azure resources?
Can we use that access to pivot? And it really ties heavily into the process. From like the red teaming angle, we can go through an engagement where, let’s say we password spray credential and now we have that credential within Azure.
What can we do within the context of Azure? Instead of having that traditional firewall approach where old school where you just have the on prem resources, now you got a VPNN to get to anything useful. A lot of times what we’re finding is that due to all these resources being publicly available, things like SharePoint, things like email, it makes it much more likely that we’ll find things like sensitive data that’s just readily available.
In those cases, it’s like, is it even worth pivoting internally if we have everything we need to prove risk and show that there’s potential for sensitive data just out in sharepoint?
One thing to note, throughout today, a lot of the Azure pen testing techniques that I’m going to talk about, will apply to different types of engagements. I’m not going to be specifically talking about just Azure cloud assessments, but what you’ll see is that learning about what you could do within the Azure cloud context will directly apply to things like red teaming engagements, external engagements, web apps assume compromise, that kind of stuff.
All right? So identifying attack surface. So depending on the assessment type, your attack surface might change. And like I mentioned on the previous slide, things like red team engagements, external engagements, cloud specific engagements, a lot of times what the assessment type is, is going to change what you’re attacking and knowing what to look for in these different scenarios is going to be really key.
Throughout the section, I’m going to try to clear up some of the common confusing points that I see a lot of people have issues with. In my opinion, there are realistically three different ways that we can approach looking at attacking Azure resources.
We’ve got external, which in most cases this is looking at Azure resources from a traditional external network pen testing context. We’re looking completely unauthenticated, attacking public resources, looking at what hosts are available, what virtual machines are available to attack externally, what public buckets are out there, storage, storage, that kind of stuff.
One thing that I’ll note throughout today’s talk is that a lot of these things can overlap and sometimes it’s not super clear unless you discuss with the customer what they actually want tested.
So I’ve had rules of engagement calls where it’s like we’ve scoped a cloud assessment, but realistically they’re looking for something like an internal network assessment. So that’s where this second bullet point comes from, an internal resource access level pen test.
Think of this kind of like a traditional pen test, internal to cloud environment. So think of like having access to a virtual machine in a cloud environment where you’re now assessing other cloud resources from that virtual machine.
And a lot of times the reason you would want to do something like this is due to cloud based systems not being under the same asset management, they might not have the same inventory, they might not be under the same patch cycles.
Because if you think about it, if you deploy software like let’s say that you installed something like a Solarwinds, Orion portal or something like that on a cloud based virtual machine, a lot of times those specific pieces of software might not be under the same update cycles.
So we still need to assess internal cloud resources as well. Then the third option, and this is one of the more likely scenarios, is where we’re actually provided API access, we’re actually authenticating to the cloud service where we have either a set of user credentials that have access to a subscription and we can read resources from the account.
Or in some cases we might even look at this as somewhat of an assumed compromise where we say all right, who are your users of your Azure environment? Do you have developers, do you have other people that are pushing different services and resources out to Azure?
In those cases we might say ok, well what would happen if this developer got compromised? What could they then do within the Azure context? Could they pivot, could they escalate privileges and whatnot?
I tend to try to look at Azure attacks from these three angles. So external unauthenticated attacks, internal resource to resource attacks, and then internal API access level attacks.
The other thing that I see a lot of confusion from is the difference between Azure Resources and Microsoft 365. This is something where you hear the term Microsoft 365 and a lot of people use that interchangeably with the term azure.
One of the things that I see that’s really confusing is I see people that are like okay, I got a user credential and how do I now see all the virtual machines or how do I see all the databases? Well the problem is that even though you have a credential, that does not necessarily mean that that account has had a role assigned to it within a subscription context.
And we’ll talk about subscriptions later on today more in more depth. But in general, Azure resource manager really relies on subscription access to hit any of these resources.
So if we’re looking at things like virtual machines, databases, storage, serverless technologies, that kind of stuff, those items are resources that have to be a part of a subscription.
And in order to access any of that stuff at any level, even reader level access, you have to have that role applied to your Azure active directory user account. So the confusing thing here is that Microsoft 365 accounts, anytime you spin up a new Microsoft 365 account, new tenant, and you start provisioning email and accounts for users within your environment, they get Azure active directory accounts.
You can authenticate to Azure active directory to Microsoft online and read data from the Microsoft online side, but not necessarily the Azure resource manager side unless you have a subscription.
That’s something that I see pretty often confused. A lot of times people are like, okay, well why aren’t any of these Azure modules that are part of PowerShell working? And it’s likely because that user is not a member of subscription recon and external attacks.
In this section I’m going to run through some of the key items that I just look for right off the bat. If you said, all right, Beau, you are on a red team against an environment or you are on a cloud pen test against this customer.
One of the first things that I do is I try to identify Microsoft 365 usage and one easy way you can do that is via this first URL here. So the first URL is this Microsoft online.com getuserrealm srf this URL, if you change that login username at the domain name of the company you’re testing.com comma, what you’ll get back is a page that looks similar to this, the screenshot here.
So the screenshot shows a lot of information regarding that tenant. Okay, so if that tenant exists, you will get information back whether or not they are using active directory federation services, if they’re just using managed environment, within Azure itself where they’re not using ad fs.
But if they are using ad fs, here is a place that you’ll actually get back the ad fs link that you would end up getting redirected to for authentication. In my opinion, this is a super useful, just right off the bat thing to do to identify Microsoft 365 usage.
The second link here is actually something that is really useful for identifying the tenant id. The second URL, if you add the target domain within that URL to that openid configuration URL, you’ll get back the openid endpoints and within those endpoints actually has the tenant id, which the tenant id can actually be useful later on if you got something like a service principal credential to authenticate.
The other thing we got to look at is user enumeration because we’re going to talk about password attacks in a moment. But in general, one of the first things that we like to do is identify valid users. We’ll go through our recon process, build out a list of users that we think are valid.
We might scrape LinkedIn or whatever service to build out a good employee list. Then mangle that into some email addresses and then now try to identify which ones of those are actually legit because we want the most, I guess precise user lists when we go into password spraying.
So there’s a couple of ways we can do this. The first URL I have here is a link to a tool that I wrote called MSL spray, which we’re also going to use for password spraying later on. This tool will tell you if users are invalid or not.
Hitting the Microsoft Oauth endpoint is actually really verbose. The screenshot we have here at the bottom gives you an example of some of the information you might get back. In this case we’ll see the user account does not exist in the directory.
That’s user enumeration that tells us that that email that we tried to password spray with doesn’t exist. One of the problems here is we are creating a failed login. That’s a potential opportunity for detection.
Another way is the second URL I have here is a tool that does username enumeration via OneDrive. OneDrive has custom URL’s as well that utilize the email address, and you can use that to identify in some cases.
Another thing that I like to look for right off the bat are data that’s in public azure blobs. One of the things that you see, I would say the most news, according to or the most news articles associated with cloud environments is typically some sort of public bucket exposure.
Think like Amazon s three buckets that somebody put a bunch of data and they just left it out on the Internet publicly available. So this is something we can look for in Azure as well. So Azure has storage and m they use this term called blob storage for Azure blobs.
So think folders here because when you create a storage account in Azure, it actually uses the name that the customer provides it. And in a lot of cases that might just be something as easy as customer name the company name.
The cool thing about Azure is that a lot of the services end up creating DNS entries for a lot of the different resources which you’ll actually see throughout a couple of the slides today.
Some of the services that do it as well, the storage accounts get in a DNS entry at storage account name Blob dot core dot Windows.net dot. If they created a storage account for blob storage at that URL, if they create containers, those containers are essentially folders and you can create permissions based off of the container level or the Blob level or you can just make it private altogether.
If you create a blob, create a blob storage where blob access policy. If you apply that blob access policy, that means basically that anyone who has a link directly to those blobs can access them.
There’s anonymous access to those specific blobs. So think, if you go to share a file from G drive, you have to have that direct link. It’s not directly something you would typically enumerate publicly or be able to list out by just knowing the container.
However, if the container itself allows for read access, then the container can be identified via brute forcing. Then the contents within that container, including the blobs, can be displayed as well.
One tool to quickly go about doing this is a tool called Cloud Enum from Chris Moberly. This is one of my favorite tools for doing this across all three services, because this hits Azure, AWS and GCP.
The cool thing about cloud Enum, is it doesn’t just hit Azure resources, it hits, or I’m sorry, it doesn’t, it doesn’t just hit storage buckets. It hits things like databases, virtual machines, web apps.
And this is using that method that I mentioned earlier, that we’re just literally brute forcing DNS addresses. Take what you get back from these tools with a grain of salt, because, anyone can go spin up resources with certain names if they are not taken already.
Google storage Blob wasn’t taken. You could go potentially take that storage blob and have it as, as your own within your own account if it wasn’t taken. If you’re identifying buckets that are associated with a company’s name, they’re not necessarily 100% associated with them.
So just keep that in mind. So after finding an open storage blob, one thing you could do is use, Azure storage Explorer, which is another tool that you could use to actually connect to that storage blob and start analyzing the data there.
I’ve actually had a couple assessments where I found public storage blobs, and within the contents of the files that were stored out there were things like credentials for other blobs, like protected buckets.
One thing that’s a, theme that we should keep in mind too, is later on an engagement. If you get API access, if you actually are authenticating to the account where the storage buckets are located, you can actually read the names of these different storage buckets.
You could determine based off of API level access, which ones are public as well. This is something, if you’re doing just a straight up cloud audit. Something you should be doing, you should be identifying via, command line, via the API.
What resources are being publicly exposed? One of the most common ways that we end up getting access, though, is through password spraying. If you’re not familiar with the term password spraying, password spraying is essentially the opposite of most brute forcing or traditional brute forcing attacks, where traditional brute forcing.
We’re taking a list of passwords, like maybe, 1000, 10,000, 10,0000 passwords, trying those against one account. The problem with that is that’s going to lock out accounts pretty quickly in most cases, right?
Because a lot of, a lot of account lockout policies are somewhere between like the five and ten attempt, threshold for locking out. So password spraying takes a different approach, where instead of trying all those passwords against one account, we’re going to try one password against all of the accounts.
So we’ll say, all right, here’s the entire user list that I have available through recon that I enumerated that I know are valid, and I’m going to try the password season, year, something like winter 2021.
This is something we have really, really high success with. The cool thing about the different ways to authenticate to Azure is we can do this via command line. Another tool that I put together is one called MSOL spray, which I mentioned for the enumeration part earlier, but it can also do password spring.
That’s the primary purpose of it. But the cool thing is that because of how verbose the endpoint is, we get back information about the account in detail. So things like is MFA enabled on the account?
The reason that’s interesting is because this particular mechanism of validating a credential won’t actually trigger things like push notifications, so it won’t automatically start the process for doing the SMS message or phone call based MFA, but it will tell you that MFA is there.
And then later on in this presentation, I’ll show you how you can take that cred and go find where maybe MFA is not enabled. If you’re spraying with it and you find that the tenant doesn’t exist, then maybe you have the wrong domain.
If the user doesn’t exist, we’ve already talked about user identification. We just take them out of the list. If the account is locked, disabled, there’s actually 200 or so different error codes that you can hit here or get back, and a lot of them come back with various, configuration around conditional access policies, which can be very, very useful for figuring out where to go.
One of the things that we end up coming up against. And I get a lot of questions about with regards to Ms OSB is this thing called Azure smart lockout. There’s actually a couple different protection mechanisms within azure for preventing password attacks.
The first one is Azure password protection. This is effectively like a password filter of sorts where you can say, I don’t want any of my employees to pick any seasons or the company name for their passwords, so that will eliminate a lot of the common password spraying candidates.
The other thing, Azure smart lockout is something that from the outside actually looks kind of terrifying because you start spraying these accounts and then all of a sudden you’re seeing where now everything’s locked out.
The problem is with how they display that information because in fact you’re not actually locking out any of those accounts. What’s happening is Azure smart lockout is locking your ip address out. It’s effectively doing something similar to like a fail to ban of sorts where it’s just blocking your IP address.
So how do we get around that? We have to rotate ips. And I see Mike Felch is here. So his tool fireprox is great with MSL spray. It works awesome. So Fireprox uses API gateway to spin up an endpoint that you can point MSL spray at.
Each of the authentication attempts that’s going through MSOL spray or I’m sorry, that’s going through Fireprox, will be rotated through different IP addresses. So every single authentication attempt will come from a different IP address and that in most cases will get around smart lockout.
The next thing I want to talk about is authentication mechanisms. This is really important to understand when it comes to anything cloud related. This is going to cover different ways to configure things like how users authenticate to Azure and how on the backend that authentication actually functions.
Then we’re going to talk pretty deeply about conditional access policies here and potential ways to bypass them. With Azure authentication, we’ve got more ways to authenticate than just username, m and password.
We talked about spring just now. There are actually other ways you can hit different endpoints within Azure using things like certificates. There’s different APIs to hit.
There’s a few different multi factor settings we need to consider that will differ for things like service counts and those that authenticate with certs. One thing that I would say that we should be looking for as well are the potential for public keys getting, or I’m sorry, private keys getting posted to public forums.
Things like GitHub, repositories GitHub has a lot of things to deal with that now to prevent that from happening, but we still see it every once in a while. Realistically, finding and understanding these authentication points is going to be really key to, us understanding how we’re going to go through the flow of attacking an environment on the cloud.
Authentication side there’s a couple of things to consider. This list is what I’ve collected together as what I think is some of the more important things to consider when it comes to authentication.
We’ll walk through each one of these. The first three items here, password hash sync passthrough authentication ad fs. These are ways that we can configure how users are authenticating and how on the backend are being authentic authenticated to our own environment.
Certificate based off we’ll talk about conditional access policies, like I said, long term access tokens for users that are authenticating via the APIs and then legacy authentication portals. That’s like the bane of most companies that we end up testing.
Where we end up getting in tends to be legacy auth portals. Let’s talk about the ways in which we can configure Azure. You have password hash synchronization. This is effectively a full clone of the user’s credentials from your on prem active directory environment into Azure active directory.
Now, anybody who’s authenticating to Azure or services like O 365, they’re actually using their internal domain credential via email address directly against Azure active directory. All of that authentication happens within Azure.
One of the main differences between that and pass through authentication is instead of the credentials being validated in the cloud, they’re actually being validated on Prem. So pass through authentication credentials are just not stored in the cloud at this point.
What happens is you have a service that runs on a server on prem that anytime somebody tries to authenticate to Azure or Microsoft 365, that service says, hey, what is that credential they just typed in?
Let me validate it locally. That’s correct. Let them into Azure. That’s the main difference there. The third, setup and one of the more common setups that we end up seeing is called active directory Federation services.
The thing with ADFs is all the credentials, they stay on prem, first of all, and users end up getting redirected from the Microsoft online portal to your ad FS server, which tends to be an on prem server as well to perform that authentication.
Now the reason that this is important is because this setup tends to visually look different than the previous two. The previous two setups if you go to the Microsoft online portal you can authenticate directly there and depending on which one that credit will be validated.
But with this setup you cannot authenticate directly to the Microsoft online portal. You will be redirected to an on prem portal. So things like password spraying is going to be different because you’re going to have to pivot your sprays accordingly.
You’re going to have to actually attack on prem systems at this point, which in general I typically just intercept the request with Burp like Burp suite and then just replay that request with different users.
Conditional access policies during any sort of offensive engagement that we do, we’re commonly doing things like password attacks or phishing where we’re trying to get credentials. There’s a lot of times where we’ll compromise a credential and the MFA that’s in place can sometimes stop that activity.
But there’s definitely ways to phish and get sessions. But in a lot of cases we find where there’s a lot of different protections that get put in place to prevent us from using those credentials. Microsoft 365 and Azure both have built in MFA options by default.
Generally these are things like using the authenticator app or OAuth, like OAuth hardware token or SMS voice call. These are free features in most cases. In addition to those, a brand new Microsoft account gets what’s called security defaults enabled by default.
And this setting is actually really good. So if you spin up a brand new Microsoft 365 tenant and you create some users, they will get the security defaults policy applied to them.
Why this is cool is because it does things like it requires users to register for MFA. It blocks legacy auth protocols. So things like exchange web services, IMAP, the things that we end up as pen testers getting in with the most will be blocked by default.
So these are already off for new customers. It requires MFA during authentication when necessary. So if I’m authenticating from a new location instead of it just allowing me in, I have to use MFA again and then protect, and it protects privileges or protects privileged activities like getting access to the Azure portal.
So it will block that by default. These are really awesome settings, right? Like these are things that you want enabled. However, a lot of companies tend to need more granular settings.
So let’s say that a company needs like let’s say they have like a C suite of people, CEO’s, CFO’s, ctos that don’t like MFA. Sad, but it’s reality, right? Like we have a lot of, a lot of companies that just, they want to make it easier on certain, certain employees, so they disable MFA for them to do that, to create specific policies where you are providing that level of access to employees, you actually have to disable security defaults.
The problem here is that when you start disabling security defaults, now it’s on whoever is configuring conditional access policies to start re implementing these other things that were already protecting the account.
That’s where, in my opinion, that’s where I see a lot of the configuration issues come to light. It’s when they take the defaults that are actually pretty decent, already disable them, and then have to rebuild them themselves.
So what are conditional access policies? Well, they’re fine grained controls for creating different levels of access for when a user can get in with or without MFA.
Things like the username, the location they’re coming from, the devices, the actual device they’re using, the application they’re authenticating with. And there’s also this thing called real time risk, which can kind of provide an additional level of when are we going to validate MFA?
To give you another example, I’ve tested organizations where they’ve used conditional access policies to do things like allow single factor access to Microsoft 365 from their own IP space. So like their own on prem network, but required MFA everywhere else.
These are the types of scenarios that we end up seeing things like that. Like I said, the bane of like most of the companies that we end up testing tends to be legacy authentication portals. And the reason is because a lot of these legacy auth portals don’t actually support MFA directly.
So things like exchange Web services, this is a service where you can authenticate and read or send email. And it’s something like, I wrote a tool called Mail Sniper to read email from exchange web services.
And whenever you enable MFA on an account, you either have to go disable exchange with services altogether for the user, or you have to have them create an app, specific password for the things they need.
So historically, why we have seen it enabled tends to be due to specific applications that employees need. So things like Outlook for Mac, you used to only support exchange web services.
They would create a rule that just says, all right, everyone who uses a Mac can hit exchange web services. These different legacy portals can be completely blocked with conditional access policies. The thing that I think is kind of funny here is that if you look at the checkboxes on the right for under legacy auth clients, we’ve got exchange active sync clients, and then you have other clients.
So you have the ability to just allow Activesync for some reason. Then all of the other legacy Auth gets grouped together. I don’t understand completely why they left active sync out of this single bullet point.
But what I’ve ended up seeing, what I’ve ended up finding out is that a lot of people don’t click that exchange act to sync clients and allow that, but they block everything else. So we’ll talk about again in a few slides here, I’ll show you how you figure out which portals are accessible.
One thing that is kind of interesting is that legacy Auth was supposed to be end of life last year, but due to Covid, it actually got pushed back to the second half of 2021. Another thing and, that you can, you can, you can configure with conditional access policies are device platforms.
Device platforms are basically the operating system in which these are authenticating. The things that’s crazy about device platforms is it literally is just using the user agent string to validate a user coming from an Android device.
It literally is just saying, oh, you used an Android user agent. What that looks like is this where you’ve got on the left authentication without a mobile user agent. So I’m, basically logging into my account just with a web browser, and I get my MFA prompt, same exact account on the right, logging in.
But I manipulated the user agent to be an Android mobile user agent, and MFA was not applied. I’ve seen this on assessments where companies say, all right, if they’re coming from a mobile device, no MFA m things like that are things that we want to be looking for to help with finding this kind of stuff.
I wrote another tool called MFA M suite. The whole point of it is to help us find these inconsistencies where the organization is trying to do a really good job by deploying MFA, but due to different conditional access policy configurations, they may have left one of these single factor.
Basically what the tool does is it says, all right, give me a set of credentials and I’m going to just try it against all these different endpoints. I’ve collected together a list here of what I think are some of the top endpoints to at least attempt to authenticate to.
So we’ve got the graph API, we’ve got the azure service management API. We talked about exchange web services. That’s another super common one that we see exposed single factor. The actual web portal, we try to authenticate to the web portal using a mobile agent.
We try to authenticate to, we try to hit active sync. And like I said, because that is a separate checkbox, sometimes you’ll find that everything else is two factor, but active sync is allowed.
Then finally, it also has the ability to hit ad fs to run this. If you want to try this, just be careful because it is trying to authenticate to that specific account six times seven if you use adfs.
Basically it’s a Powershell script you just import into a powershell session. And then you would run invoke Dash MFA sweep and give it a username m and a password and it will try to go authenticate single factor each one of those and let which ones are single factor.
You can also check ad Fs, and what it does is we’ll try to check that initial URL that I showed you on the recon slides where it will point us to that ad Fs endpoint and attempt to authenticate to that ad Fs endpoint using single factor.
And if it does end up getting redirected to the multi factor pages, it will tell you that it’s an indication of MFA being in place for that user. All right, post compromise after we get credentials, what are we going to do next?
So this section is really going to have some go to actions for basically following successful compromise of credentials. And I teach four day class on this, so this is by no means like everything that you would do, but I’m going to try to just give you some of the, the high level approach to how I would go through post, compromise here.
So first off, who do we have access? As we just got a credential, we need to figure out who that user is. Is that user just an Azure active directory user, or do they also have roles applied within a subscription?
These are things that we typically might want to figure out is MFA enabled. What can we access if we do have access to a subscription, can we get to access to, or can we read data from things like web application storage?
Who the administrator? How are we going to escalate privileges then? Additionally, if you have access to the various Microsoft graph API endpoints, you can actually enumerate some security protections, things like ATP licenses.
After getting a cred, one of the first things I typically like to do is just see if we can get to the Azure portal directly. One thing that’s cool is that the Azure portal actually relies on the same Microsoft online authentication.
If you fish a credential with something like Evil Gen X two and you have a session to, let’s say, just office 365, you’re in their outlook account like email.
That same session can be utilized to attempt to authenticate to the Azure portal. If they have not disabled access directly to the Azure portal, you may be able to just go to portal dot azure.com and you can be presented with the actual Azure portal itself.
Why is that useful? Well, when we started doing recon, we built out an employee list for password spraying. We use that list to attempt to compromise accounts. Well, let’s say that we did compromise an account.
Now let’s go get the full user list which you can get from either the global address list or if you have access to the Azure portal you can get it from the Azure active directory users page as well.
Here’s the thing. Even if the portal is locked down, a lot of times the Powershell Cmdlets, the Azcli tools will still work because locking that down is actually a little bit more difficult.
It’s not just a checkbox. There’s a command that you have to run as a, as a global admin to disable access to the command line for all users. I actually like, I’ve had customers where they blocked access to the Azure portal via different conditional access policies.
Maybe, maybe it’s MFA, but I was able to hit that same API via command line single vector. So things to consider when it comes to command line access, this is in most cases going to be where we want to operate.
When it comes to the different Powershell modules that are available to us. I want to explain some of the key differences. Here we have the AZ Powershell module. The AZ Powershell module is realistically how we’re going to enumerate and identify things from subscriptions, things like resources within subscriptions, virtual machines, databases, storage accounts, that stuff.
The Azure Ad and Ms online modules are heavily focused on just the Azure ad side of the house. Those modules will allow us to do things like enumerate groups, user counts, service principles, that stuff.
There’s also Azure CLI tools, which is another cross platform tool. If you don’t like Powershell, that will work as well. We only have 15 minutes left of class. I don’t have a whole lot of time to just throw a bunch of commands at you.
But what I did is I put together this list of cloud pen test cheat sheets and it’s not just Azure specific. So I’ve got AWs, GCP and Azure in there. But in those cloud pen test cheat sheets there’s plenty of commands to get you started with all three of these different, different tools.
All right, let’s talk about the Azure subscription hierarchy. So after we’ve been able to get into an account, we now have CLI access potentially, or even portal access. Let’s say that we did get access to a subscription.
What does that even mean? Organizations at the top level, you have the tenant. The tenant contains the ability to create different licenses for different services, different products.
But when we talk about subscriptions, subscriptions are effectively where we’re going to create different resources like virtual machines, databases, that kind of stuff.
One of the things that I think is often confusing is software licenses like Microsoft 365. They can be purchased and those licenses can be applied to users, but that is not a subscription.
Okay, that’s one of the things that again, like I think that that can be a little bit confusing for some people because just because it’s all in Azure doesn’t necessarily mean that it is Azure subscriptions.
I want to make that clear, because when we talk about subscriptions, we’re not specifically talking about Microsoft 365 licenses. Azure ad has multiple tiers that can be purchased. And under those tiers, well, I guess in general, like subscriptions tend to be grouped for billing purposes.
The reasoning behind why a user might create multiple subscriptions is completely dependent on them. Technically you could have a tenant that has 100 subscriptions or even 1000 subscriptions.
It all depends on what their use cases are. But in general they might divide it up, billing purpose wise. They might want to know how much their development shop is spending versus their production environment versus lab, that stuff.
One of the other key things to understand with subscriptions is just because you authenticate and you see that you have access to a subscription doesn’t mean you have access to all of the subscriptions.
So sometimes you might find that authenticating, you see this subscription there, but the resources within that subscription are the only things that you have access to. However, unless you’ve been provided roles within each of the other subscriptions, within that account, you wouldn’t see them.
Under subscriptions. We have resources and resource groups. In my opinion, one of the best, first things that we need to do is identify what is the purpose of the subscription that we’re operating in.
A lot of times you’ll see naming conventions that can help us identify what the purpose is. You might see the name prod or dev that can help you at least understand a little bit about the subscription.
But each subscription can have resource groups under it. Things like we might group web application with a database that they have some sort of interaction within a resource group.
But at the end of the day, those are realistically just folders that can help us organize things. But the resources are realistically where we want to look and why the different levels are important is because each resource, each resource group, each subscription can have policies and permissions applied to each level.
The roles that get applied to subscriptions at different levels are hierarchical. They actually get inherited down. So if you apply, let’s say, owner level access to the subscription, that means every single resource, every single resource group under it, that user is an owner of.
There are some default roles within Azure to know about. First off, subscriptions can have, well, in general, any resource, including subscriptions can have owner level access, which is generally like the full control access.
Contributors have all the same rights, except they can’t change permissions. Reader level access can only read attributes. If we’re doing a cloud based pen test, generally, what I asked for is just reader level access where we’re authenticating to the account and able to read all the resources.
Then another common one is user access administrator. We’ve gone over a little bit of post compromise, a little bit of what to do. What are the things to know about.
These next few slides are really just rapid fire high level things that I wanted to cover as things to look for immediately. So each of these topics can be dug into much deeper, but having a general awareness of them I think will be a good place to start.
First up, serverless environment variables. This is something that I have had great luck in finding. Clear text credentials just applied to, things like azure functions, serverless technology in general.
If you looked at AWS, they have lambda functions, Azure has Azure functions. The whole idea of these are to create some sort of action that gets triggered based off of some other thing. With Azure you can set up things like hey, if a user uploads a file to this onedrive share trigger this flow to go run this thing on that file, that could be a function.
But what we end up seeing a lot of times is where organizations include secrets in those azure functions directly. And if you have reader level permission to those functions, you can actually call out and see those plaintext values as well.
What they should be doing is pulling those secrets from key vaults. I’ve had multiple assessments now where I’m doing cloud based pen tests where we’re provided a reader level credential to an account.
We read the different functions and see credentials within those functions and then are able to use those to escalate and get additional access. This is kind of a rapid fire, just high level, high level overview of a few things.
Another thing is instance metadata service. So this is something that across the cloud services I think that a lot of people might not understand is actually something that exists. And it honestly, when I first learned about it, I was like, wow, really?
Whenever you spin up a virtual machine within a cloud environment, whether it be AWS, GCP Azure, an actual web application gets spun up on an endpoint at the non routable IP address of one 6925-416-9254 and the whole point of this is to be a way for that server to help orient itself because of how dynamic cloud services are.
So this metadata endpoint can have all kinds of stuff like it could have data about the account, data about the subscription, data about resources, that kind of thing. You can also apply managed identities to two different resources.
So things like a virtual machine may have a managed identity applied to it where it can assume a set of credentials for accessing other resources. In the case of having access to that metadata endpoint, you can actually call the endpoint and get a set of temporary credentials.
If you look at some of the bigger AWS compromises, they hit the metadata service via web attacks, things like server side request forgery. Because the whole point of this is that it’s supposed to not be accessible externally.
It’s supposed to only be reachable by the local host. However, through vulnerabilities like server side request forgery, we can cause an application to send a request on behalf of the server itself to its local host, that is the metadata service.
Sometimes via web application vulnerabilities you might be able to actually hit the metadata service and get more credentials. Another thing we talked about having access via the MS online Powershell module to Azure Ad.
Anytime you have a user credential that has access to something like Microsoft 365, those user credentials can typically read data from Azure active directory. You could use the MS online module to do that.
One of the things that we look for on pretty much every pen test are when credentials end up getting stored in actual active directory user attributes.
What I mean by that is occasionally you’ll find where maybe a help desk engineer has created a new user and for some reason they put the user’s password as an attribute, whether it be in the description field or wherever.
This is something historically we’ve done a lot of and we found a lot of credentials internally on traditional, on prem environments. But if you want to look for the same thing in the cloud, you can use the MS online module. And then I wrote a quick one liner here to go look for the term password and you can change that too because like sometimes it might be cred or it might be, I don’t know, like login, that kind of thing.
Service principle hijacking. This is, this is a topic that I literally have like I don’t know, ten slides on. I’m in my class, so I’ll try to describe this as quickly as I can. Here’s the thing with this particular issue that I think is fascinating.
Anytime you create a Microsoft 365 account, by default that account will spin up 200 service principals within your tenant.
None of them are actually listed in the Azure Gui portal under the users section. You have to go to the super service principles to actually see them. The thing is, they all have varying levels of permissions on Microsoft graph.
This can present an interesting privilege escalation opportunity because let’s say that you compromised an account for somebody that is an application administrator.
The application administrator role allows users or allows the application administrator to change passwords or certificates for service principles. So even these default ones that get spun up, one thing you could potentially do is identify an account that has a higher level privilege than your application administrator.
Now one thing that application administrators typically can do are things like create new users or modify the directory. They can only do things against applications. So things like service principles.
Now if you change the password or add a new password or add a certificate for a service principal that has that permission, you have now escalated privileges.
So that’s potential privilege escalation opportunity. Key vaults are another thing that is pretty interesting to look at when it comes to azure based pen testing. key vault is what it sounds like.
It’s a vault for storing your passwords and other secrets. Other cloud apps and services can typically use these. That is, azure functions should be. It’s easy to store things like Ssl, TL’s, certs.
Many times the data you want access to might require additional credentials. And to get them, it might be as easy as just getting access to the key vault. Now one thing that is interesting about key vaults is that by default, only the owner of a key vault can actually access those keys.
However, contributors have the ability to actually modify certain permissions on key vaults. So as a contributor to a key vault, let’s say that you got access to a contributor count for a key vault and attempted to read keys from that vault, you’ll get access denied.
But the thing that’s crazy is that contributors can actually modify their own permissions to give them the read permissions they need to actually read data from those key vaults, something to definitely keep an eye out for.
Last thing on these key things to look at is getting data. One of the key things that we want to do as pen testers at red teamers is what data can we get to? And one of the more interesting approaches to this is just doing what’s called a compliance search in Microsoft 365.
So if you get global admin, or even if you compromise a member of the ediscovery manager role, you can actually search and report across all of the Microsoft 365 services.
So you can actually report across things like, you can search for things like passwords, secrets, all that stuff in the entire organization’s email, all the Skype messages, all the teams messages, all the sharepoint sites, all the onedrive accounts, and find where the sensitive data actually is.
Historically we’ve on prem, I wrote mail Sniper to search through email for that specific purpose. But now this is like that on steroid. So we did this in an.org where compromise after compromising global admin, this helped us identify potentially sensitive data that was in email and chat and stuff.
To wrap things up here, I’m going to talk about scanning tools real quick because this is something that is very, very important to how we’re going to approach assessing a cloud infrastructure from an automated perspective.
Like I said, there’s multiple angles that we got to look at. Looking at Azure from, first one being external, second one being internal access via via like a virtual machine to other resources within that account.
And then the third thing would be API level access. So having the ability to run scans can help us quickly identify certain vulnerabilities, things like low hanging fruit. But this might not be something you run on like a red team because this can be a bit noisy, right?
And generally all we need is an account to read permissions from, from the different resources. One of my favorite tools for this is Scout suite by NCC Group. The cool thing about Scoutsuite is it’s multi cloud.
It supports AWS, Azure, GCP. But this is one of the first things that I typically end up running on an assessment because I like to get data back quickly about the account so I understand what’s there.
In some cases we might be testing 100,000 resources and in order to do a good job of getting through that data quickly, we need to automate some of that.
Scout suite is a good tool for that. Another slide here with a few different tools to look at if we want to look at doing a full on download of the entire Azure active directory data, road tools is the way to go.
Road tools is an amazing tool. It’s one of my favorites after getting access to a user credential. So road tools and road recon will go and actually copy off all the users, all the MFA information, service principal information.
That stuff groups so you can actually like look through that data offline as opposed to just running a bunch of queries directly while you’re testing. Then powersure and microburst are two amazing Powershell tools for, for doing all kinds of this stuff that we were talking about earlier for, doing post, post compromise recon, dumping keyboards, that kind of stuff.
Amazing tools. If you want to help, if you want help with automating some of that approach. Storm spotter and Azure Hound, great post compromise tools for doing things like finding paths of escalation. If you’re familiar with bloodhound, Azure Hound is the azure equivalent of that, where we’re now using the ability to identify resource permissions and potential privilege escalation opportunities there.
Key, takeaways for today, Recon is absolutely the key for us to understanding cloud asset usage. Being able to identify publicly available resources, anything like that can help drive how we’re going to attack that company.
Cloud attack service is going to enable us multiple ways to gain access. So we talked about API level access, looking at different ways to get around conditional access policies, that kind of thing.
Configuration of cloud resources is still a wild west. It really is, and is changing daily. A lot of the conditional access policies you put in place today might not be efficient tomorrow because there’s new services that get spun up, that kind of stuff.
Key methods for gaining a foothold are going to include things like I mentioned, key disclosure, public repositories that have keys in them, performing password attacks, phishing for access, ultimately potential remote code execution.
If we can get some sort of web app vulnerability or even command injection, that kind of thing, we might be able to read data from that metadata service. And then situational awareness after we get access is going to help drive our decision post compromise.
Like I said, today’s, today’s talk was a lot of just, hey, here’s how you can, you can use some of this information to get started. But I do teach a four day class on this and yeah, I hope you guys enjoyed it.
And I will be hanging out for a little bit to answer any questions because I know we didn’t, we didn’t stop at all in for questions, so if you guys got questions, feel free to throw them at me.
Jason Blanchard
Oh, they got questions though. They got questions. First of all, hey everyone, thanks so much for joining us for this Black Hills information security webcast. You ever need a pen test or threat hunter bread team, where to find us. We’re going to go into overtime right now.
So this is what we call post show banter. So if you need to leave, totally understand, but we’re going to stick around and answer it rapid fire questions as best we can. And so we’re going to give Beau about ten to 15 minutes unless we run out of questions first question.
Beau, let me go ahead and take a look. it’s only like 72 or no, there’s not that many. Are Microsoft Azure admins prevented from seeing blobs or data without a policy?
And with a policy, are Microsoft admins still able to access a particular data store across any cluster? I think that’s two questions.
Beau Bullock
So they would need certain permissions to those blobs. They would need either viewer or reader level permissions in most cases. But if they’re an admin, if it’s like a global admin, then they can give themselves access.
Fun fact, there’s actually a checkbox in Azure. If you’re a global admin, you can actually give yourself user access administrator across all of the subscriptions within that tenant.
It literally the checkbox. If you have global admin access, you just go click that checkbox and now your user access administrator to everything. And if you’re an admin, yes, you have access to all of the subscriptions and previous engagements.
Jason Blanchard
Have you encountered smart lockout and how has that limited your access attempts?
Beau Bullock
Yep. Yeah, so that’s, I talked about that a little bit on, on the password spring section. Definitely have come up against it. But these days I pretty much just, you combine Mike’s tool, Fireprox with msol spray to rotate ip addresses to get around that.
Jason Blanchard
Yeah, whenever I play backwards or breaches with people, I always tell them about Fireprox. And the reason why I want them to know that it exists is because all of your way of doing defensive is not going to work anymore.
Now that fireprox, like, well that does change things, doesn’t it? Like, yeah, look at these tools. Is there a portion, speaking of Fireprox, is there port scanning equivalent for Fireprox?
Beau Bullock
So that’s definitely a question for Mike, but I think that it’s mainly URL based and so you pointed out a specific URL. So if you wanted to do something like a port scan where you’re rotating ips.
I think proxy cannon might be a better option for that.
Jason Blanchard
This question seems really important. Do you need approval before running these tests?
Beau Bullock
You need approval with the company you’re testing, but not azure. Historically, if you went back five years or so, you used to have to fill out an authorization form where you used to have to say, all right, this is the company I’m testing.
This is the bandwidth I’m going to end up using during the test and all that stuff, Azure, AWS, GCP, they’ve all been like, we don’t need that information anymore. Just as long as you got authorization from the customer, we’re good.
Generally, they just don’t want you attacking their own infrastructure or their employees. They don’t want you phishing Microsoft employees to get access to the customer you’re pen testing.
That’d be bad.
Jason Blanchard
I think this is a really important question too, for a lot of the people here who are blue team, and we do get a lot of blue teamers that come and they want to see how the attacks work, see what they can fix and make adjustments to.
So what kind of alerts are being generated on the customer side? How stealthy are these or how hard are they to hunt for?
Beau Bullock
Well, it depends across, it depends on which attacks we’re talking about. Right. something like password spraying. I mean, it shows up there are, there, there are rules that you can put in place. Actually, I saw a blog post a couple days ago talking about how to identify it, I think with Sentinel, if you look through my Twitter history, I think it was maybe yesterday, the day before I retweeted somebody who posted a blog for detecting password spraying specifically in azure.
there’s definitely logs.
Jason Blanchard
And that’s daft hat hack. Daft hack on Twitter, if you want to find his Twitter account. Daft. Daft.
If you only access with read only, is that less likely to be noticed?
Beau Bullock
I m mean, generally if you are given an account, I mean, they know about it, right? They know about that access. And I guess it kind of comes down to what alerting they have up, in play as well.
But looking at just specific access to resources is something that could be potentially alerted on. So reading from key vaults, reading from storage buckets, that kind of stuff can be definitely alerted on.
But I, I would, I would say that, a lot of the maturity that we’ve seen across organizations haven’t been at that level.
Jason Blanchard
how effective has azure identity, old Azure ATP when domain controllers been at detecting your azure activities while pentesting.
Beau Bullock
I would say we haven’t had a whole lot of customers where they have either been using that or brought up alerting based off of ATP.
I don’t really have a whole lot of insight into that specific alert mechanism.
Jason Blanchard
I wonder if there’s some azure people here, they’re like, yes, question, better class, does reaching the cloud training include labs?
Beau Bullock
Oh yeah, yeah. we have, it’s somewhere between four and five a day, usually four or five labs a day. And they range from, things like password spraying to privilege escalation to creating backdoors, service principle backdoors, that kind of stuff.
We set up an entire c two infrastructure with domain fronting. Fun stuff.
Jason Blanchard
Did you ever get caught through O 365 impossible travel alerts? Is it worth monitoring it?
Beau Bullock
So yes, yes, definitely to both questions. Definitely worth monitoring for it definitely worth keeping an eye out for it. however, I will say that I have had the craziest luck sometimes when it comes to where we can actually authenticate from.
I think ideally if you’re fishing for credentials with something evil Gen X, you want that authenticated session to be coming from the same IP address.
If they’re authenticating through you, that IP address that’s authenticating should be the same IP address that you end up using that session from. In most cases you want to actually point your browser that you want to use for using that authenticated session through your Evogenex server as well.
It looks like all of that access is coming from the same location. I will say that I have had occasions where I didn’t do that, fished a credential and then attempted to use that session on another browser from another IP address and that did not work.
But I have had luck where we see things like MFA in place and maybe we password sprayed. I don’t see any single factor access. I want to access outlook.
So I go to login to see if there’s MFA. I’ve had occasions where I go to login and it’s like automatically calling or automatically doing the push notification to the user.
So I’ve had occasions where it’s like you go to check and it’s oh, it’s calling them right now. And in those cases I’ve actually had occurrences where the user is just like oh yeah, Microsoft, that’s normal.
Hit the panel key and let them in and give us access to the account. So yeah, it ranges.
Jason Blanchard
Is there anything in common between Ad or azure? Ad or. There is no reusable knowledge.
Beau Bullock
Yeah, I mean, so setting up accounts is pretty similar. how you authenticate is very different.
Jason Blanchard
Right?
Beau Bullock
Like, there’s no Kerberos, authentication to azure ad. A lot of it’s just oauth based authentication, but there’s a lot of similarities. There’s, you don’t have a lot of the same things like gpos that you can deploy to Azure, things like that.
But I would say that at least some of the knowledge is similar.
Jason Blanchard
Have you experienced a time where Microsoft seems to detect Fireprox and throw false information at you?
Beau Bullock
I, haven’t yet, no. I’ve had occasions where I have seen certain regions start to get locked out, which is honestly, I’m not entirely sure what’s happening there, but I’ve seen where, like, I started using Fireprox in us east one, right?
And it’s rotating ips, and then I start getting lockout alerts. And then, I’m like, well, it’s rotating. Why is that happening? Switch over to, like, us east two. And now no more lockout alerts.
So not sure if that’s just them, like maybe doing some identification of the region specifically or what, but, yeah, that’s the closest I’ve gotten to it.
Jason Blanchard
Does Microsoft Security center provide any detection related to this type of testing?
Beau Bullock
Yeah, I think they do. I mean, again, like red Teamer, so I believe they do. I’ve seen, definitely seen a few alerts come from customers on, Microsoft Security center.
so, yeah, I think one of.
Jason Blanchard
The last questions we’ll ask is how much of the breach in the cloud content has changed since it was offered last year.
Beau Bullock
That’s a good question. So the first time I saw it was April of 2020. I think it’s either April or May. Is May.
Yeah. So May 2020. And every single course, every or every single version that I’ve taught since then, which I think I’ve taught it about five or six times since then, has had at least something changed.
It’s usually small stuff, though. It’s usually nothing like major, major, Major. Usually it’s things that I’ve like new, like breakthrough things that I’ve added. But I would say like somewhere between, like the 40 to 50 slide mark.
Actually, some labs have completely changed due to some of the labs have completely changed due to just like things breaking or different ways that Azure has actually changed.
Things like, for example, authenticating with the, az Powershell module that used to create a session token in one place, but now it uses a completely different set of, credential storage on disk, things like that, like have changed, but it’s not like crazy.
Jason Blanchard
Last question I think will be, it’s kind of long, so just stick with me.
Beau Bullock
Okay?
Jason Blanchard
What is your take on Azure enterprise app registration for persistence? Software vendors are always asking for all kinds of excessive permissions when configuring SSO.
So another directory readwrite, all would likely, most likely go unnoticed.
Beau Bullock
Yep. Yeah, so I actually have a lab and the class for that specific thing. So, creating an Oauth application or an application within the azure tenant is something that is super honestly really popular.
right now, even the last couple of years, where they have the ability to create applications within Azure and then provide certain permissions to those applications.
To give an example here, you might create an application, like you said, with directory read write all, where that application has that permission to read access or write access to the directory.
The other thing that we look at is phishing and doing remote compromise against users via OAuth attacks. If you can actually convince a user to click consent on the application prompt, then that application can potentially have permissions within their own account.
That’s something that we see in the news, more and more often where users are consenting to permissions. And honestly, if you think about it from an application, let’s say you have your mobile phone and you go to install a new app, and it says, all right, this application wants access to your contacts, it wants access to email.
You’re saying, yeah, sure, whatever, it’s the app I want. That’s essentially the equivalent of Azure Oauth application consent phishing, where we create an application with an attendant fish.
With that application, they just get a page that says, hey, this application wants permission to these things. Okay, sure, I’m going to click consent.
Now that application can read that data. So yeah, I think it’s definitely something to be aware of, something that I teach in the class too.
Jason Blanchard
All right. my last shameless plug for myself is 1 June 10. I’m doing a live blackout webcast on how to give a presentation.
And so it’s a presentation. On giving presentations wrapped within a presentation, it’s the inception presentation. And so if you’re interested in sharing your knowledge, if you have ever been asked or wanted to submit to a call for papers, and you were shy or embarrassed or you weren’t quite sure what to do, or whatever the case is, but you wanted to start sharing your knowledge with others, then come to June 10 and I’m going to give a presentation, presentation on presentations that is going to be so meta using science and stuff, where you’re like, wait, you’re in my brain right now?
Yes, I am, because I know exactly what you’re thinking. All right, so with that, Beau, any final words?
Beau Bullock
Yeah, if you’re looking for a job, go to his, go to Jason’s, live streams that he does. He’s like the man at getting people hired, so.
Jason Blanchard
Thanks, Beau. Yeah, we’re at 93 right now. We’re almost our 100th viewer getting a new job.
Beau Bullock
That is so awesome. Yeah. All right. Hey, thanks, everyone. I appreciate you guys coming so much. yeah, definitely. Let me know, if you have any questions or anything later on.
Jason Blanchard
Thanks, Beau. Thanks, everybody. We’ll see you next time. Thanks for being here on today’s Black Hills information security webcast. If you ever need us, where to find us. Talk to you later. Bye. And ending the webinar,