Pierre-Nicolas Allard-Coutu - Cloud Environments - Red Team Perspectives

And then controlling it. Does this is this gonna work or what? No.

Uh yeah. Where's the which one is left? Yeah. So the large button problem. Is this on? Testing. It's on. Okay. Is this Yeah. Okay. All right. Uh thank you, Nathan. Uh next up we have uh Pierre uh presenting on cloud environments uh red team perspectives. All right. Testing, testing. Everyone can hear me well. Yeah, it's good for volume. Okay, cool. Uh, all right. I'm going to put myself a little timer. Sorry. All right. Welcome to uh cloud environment red team perspective. Uh we're going to jump right into it. Uh who am I? My name is uh Pier Nicola Pierre Nicholas. You can call me Pierre. I'm a senior penetration tester at Bell Canada's uh STR team. That is the

security testing and incident response team. I uh do a lot of uh penetration testing. red team uh operations, purple team engagements. Um recently some uh cloud stuff which you'll see in this uh in this here presentation. Uh I also do a little bit of malware development for the red team purposes and uh here are my two cats which I have to uh I have to mention. There we are. So what's on the agenda today? Um not all of these are equal. Just a little preface. Uh we're going to be talking about cloud security 101. uh cloud security challenges uh offensive operations in the cloud uh approaches and methodologies, standards and frameworks, the cloud attack life

cycle as uh we like to define it um leveraging the cloud as a red team operator and finally cloud security best practices. uh these will not we won't be spending as much time on all these topics and uh I've practiced this a number of times and always come out over time so I will be skipping through a little bit of the uh more complex stuff and try to get to the interesting stuff you may not have seen before. So uh cloud security 101 not going to spend too much time here because uh I'm sure most of you are at least somewhat familiar with what the cloud is. But uh cloud in very very simple terms is other

people's computers and infrastructure. Very simple terms. Um the three main providers, there's Amazon's AWS, there's Microsoft Azure, and there's uh Google's GCP. There are others, but they're um pretty niche. So, uh they will be outside of the scope of the talk today. Uh and why do people use cloud? Well, all sorts of reasons. Um scalability, reliability, cost efficiency, uh accessibility, flexibility, all sorts of things. So, again, a little bit of uh speed in these here parts. Uh there are different AAS's as you may have noticed in your perusing of these uh documentations. Uh SAS fast pass I asked what does this mean? Um I'll resume it as I I like to think of it as different

levels of granularity and uh and capacity when it comes to using other people's computers and infrastructure like I said. So you may be interested in simply using the processing power of a cloud you know of a cloud setup and just you know use only the function you're passing it just a piece of code you want it to calculate something give you an answer you're going to use a function as a service you might be interested in having VMs uh actual full machines in which case you're going to be using more of the infrastructure that's provided by the uh the cloud provider um you might be using the identity service as we're going to see a little bit later. So

basically what these break down to is what what parts of the infrastructure do you need access to uh and you're going to subscribe to whatever it is that you need. This is an advantage of cloud because it gives you the flexibility to pick and choose on a cost basis and also on a needs basis what components you're you're going to be actually uh paying for and leveraging. U an important thing to understand is that cloud does not equal not your responsibility. Okay. Uh there's a lot of unfortunately a lot of organizations that tend to assume that security in the cloud is not something that they need to uh consider because it's outsourced. It's someone else's uh

infrastructure and therefore it's not theirs to secure and properly configure. This is very much so not the case. Uh here you've got just a small comparison of different types of uh of services that you might subscribe to from cloud providers versus onrem. Uh so if we're talking about on-prem you know servers that are actually in your organization your internal network things you fully have control of hardware that's in your internal network uh in those cases everything is your responsibility but as we start using different cloud services we start to have a shared responsibility model where security is both the responsibility of the uh provider and yourself although like I said it's never entirely their responsibility uh if you

start using for example Microsoft cloud infrastructure and you have a a plethora of servers. Yeah, those servers might be in a data center somewhere. The physical security of that data center is not your responsibility. If there's a fire, it's not your responsibility. But if you take uh you create a bunch of accounts, configure them in a bad way, and an attacker gets access and starts to do nasty things, that's your fault. And that's something that you need to consider as an implication for your usage of these services. Which leads into u a couple of examples. I'm not going to go over these but just to show you there are uh major incidents that occur with regards to cloud

infrastructure uh that can be extremely damaging to uh to you as the user or to the uh you know parent organization itself. Um going back in 2019 I just want to show that this like this happens it exists. Uh and also it evolves over time. Uh in the past we saw more typical um the types of attacks we were seeing were more typical web application attacks starting a lot with SSRF attacks, serverside request forgery. Um really flaws with the APIs or the infrastructure itself that could be abused by attackers. In 2023, what we're seeing more of is identity based leveraging. Um people you know finding u permission issues between accounts across accounts from different organizations that can influence each

other. Uh leakage of accounts, stuff like this. So it changes over time. something to consider. Jumping right into the meat of it. Uh Azure versus Azure AD. I just want to get this said, okay, Azure is not equal to Azure AD. Uh they're not the same thing. It's very confusing naming uh which is perhaps why they have moved towards changing the name I believe to intra but uh yeah it's um it's not the same thing. Azure AD is a granular component of Azure cloud services as a whole. It is really the identity service um that uh that is concerned here. And you will see it is not either a direct correlation to uh Windows server active directory which is

a whole plethora of other things that are outside the scope of this uh talk but I just wanted to mention it is not the same onetoone thing and we will talk specifically about Azure AD but also a little bit about Azure as a whole uh so this is just the vocabulary getting it out of the way um yeah is not Azure ID Azure is a Microsoft cloud platform whereas the Azure AD is the enterprise identity service and we'll see what uh what that implies in a little bit. Moving on to GCP and get used to this. There's a lot of jumping around between the different providers. This talk is about the three main providers um and

the similarities and differences between them but also like the title suggests um the red team perspective. So not going to talk too much about what cloud actually is. I'm going to talk about how we look at it from an attack perspective. Uh but just to get this out of the way, GCP has um its own uh IM model and uh essentially the domain that you would be familiar with uh is the company and afterwards uh it's organized into folders which uh have various rights and permissions on projects. The projects actually then allocate whatever resources required. Uh you can have things like VMs, you can have things like functions, uh whatever it is you need. between these three providers

there's um basically different naming schemes but a lot of the same services. So you might see in AWS something is called an S3 bucket you know but uh in in Microsoft it's it's a blob uh or uh in uh for example in GCP you've got your compute engine instances which are really just another word for virtual machines. So just to give you an idea AWS again different organization different hierarchy but similar concepts uh really in this case the uh the tenants that you would be uh familiar with would be the accounts. Uh in some cases it'll be the organization but not everybody does that. Uh more or less frequently we see accounts as being the

uh the root object that is in use and that that's what we end up targeting. uh underneath you'll have your resource groups with again various permissions and uh then at the very end you'll have your uh your actual assets EC2 instances which are VMs or like we just saw in GCP you know cloud compute engines um S3 buckets which are the storage etc. So not going to talk too much about that. But what does this imply? Um for an attacker, cloud infrastructure is a new way to get into your internal directory or internal network rather. It is a new internetf facing attack surface that you that opponents are going to leverage to do damage or potentially extract

information from your organization. Um, typically you'll see an example of a way in to uh an internal network of whatever organization would be just as an example a web application that has vulnerability. Uh, that web application even though it might be vulnerable might be behind a very strong web a web application firewall w right here. Um, so an attacker first has to contend with the web application firewall. Then let's say they managed to get through it. Let's say they managed to exploit that web application. Now they have remote code execution on that server. Great. That server is probably in a DMZ. Uh the DMZ is not directly connected to the internal network. They're going to have

to pass through some firewalls. They might have to pass through hopefully some sort of network segmentation. There might be all sorts of countermeasures in place, CMS, you know, IDS, IPS, all sorts of things that are going to prevent them from leveraging that level of access to then go and do big damage here in the internal network. Um, one thing that attackers appreciate from the cloud is that it often gives direct access to the internal network uh and is not secured in the same way with all of these more mature countermeasures that you would be expecting from a typical internetf facing uh path. So it basically big takeaway it increases your attack surface it introduces new

vulnerabilities. It is complex and organizations have not yet caught up in the understanding of how to properly secure it. uh most of the time um the uh there are some detection and response um tools that function at this level but they're not very widely implemented and they're often not well understood uh but they are starting to get there and uh it also gives access something that isn't often considered but it also gives access from the internal network to the cloud. So, an attacker who has already compromised a workstation, say one of your employees opens a malicious email, downloads a payload, detonates it, and now you have remote code execution on that asset. Uh, well, now there's a new

way to get more, let's say, uh, goods out of that, uh, position that you're in. You might be able to extract information that previously was not available because you can leverage the fact that the internal network is connected to the cloud environment. So, it also adds new paths to uh, to further compromise uh, from the internal perspective as well. not just from the outside. So there's a whole basically a whole bunch of new attack surface that's opened up by this um cloud opportunities present sorry cloud environments present challenges for attackers as well. Of course uh there are new systems involved and we need to understand them in order to hack them. uh there's less opportunities for traditional uh types

of attacks like MITM. Um for example, one of the breadandbut things that we do in internal engagements is um you know man-in-the-middle poisoning type attacks that leverage deprecated uh resolution protocols like LMNR or multiccast DNS or BIOS name resolution and more recently IPv6 poisoning. Uh you can't do any of that sort of stuff from the cloud, right? It's just a different uh different position that you're in. So you have to rethink your tools tactics. uh but um it can still be incredibly useful. Uh there are different AM models between the major providers which can be a whole headache and which I will skip over uh in this presentation because I just do not have time to to explain it

all. But uh you'll see at least from the slides that there is a considerable amount of complexity there and uh you need to stay ahead of the curve as an attacker because a lot of this is not documented uh or poorly documented or only documented by other hackers and uh changing all the time. And since it's not documented, you know, these companies don't necessarily have any reason to tell you when they change an API call the structure of it or or what have you. So, uh basically uh the research is not well defined yet. It is getting there and there is some good resources available online, but it's not yet uh fully mature and this of course

presents a challenge for attackers. So, I said I would skip this part. Um I'm just going to mention it very very briefly. uh AWS, GCP and Azure have different uh IM models. Um there are there are basically users in all of these cases. There are roles and permissions in all of these cases. Um and typically there are service accounts in all these cases. Uh service accounts which are tied to the usage of applications or resources that you're using in these cloud environments and then users which are users as you may have guessed. Um like yeah going to skip through that part. Why does this matter? um without having explained the AM model. Uh this is a cheap copout, but

either way, this is a typical example of something that is not considered by uh a company. So, uh down here you have your pentest account. This is a compromised account. Um in our example company, it has reset password uh reset password permissions on the uh SVC backup account. Uh this is uh something you might see in in real life actually. uh the SVC backup account was used to create an application in Azure. So it is the owner of this application in Azure the data platform application and the data platform application is running as this data platform service account over here. Um this is usually something that will be done because first of all the application needs a service account to

run as and second of all um application creators are going to be attempting to create segmentation at the very least from their account that they've used to create it with the account that the application uses to do its various services. what isn't considered and why AM models are so important is because uh is because of this this relationship that uh allows for takeover um because you can reset the password here and this guy owns this application which is running as that user essentially this user owns that user all the way in the corner. If this user which is intended to be the uh the one that the application runs as has certain permissions that the application needs

in order to function that can be leveraged by the attacker who has compromised the first account. In this case you can list all the details and download items from uh one drive users uh based on these fairly common permissions that you might find an application having. Now you can imagine that as an attacker you get access to an account. Uh now you can download all of the one drive uh information. That's pretty powerful and you might be able to recycle that information, find new credentials secrets processes etc. and leverage it to further your attacks. So, just a little precursor. All right, Cloud Cly. Uh there's many ways to interface with these uh cloud services. Uh Azure by far is the most complex. It

has a whole bunch and this isn't even all of them. Some of them are legacy and deprecated. But uh I just wanted to mention that there are a bunch of ways to uh interact with these uh services from uh command line or uh essentially. So that's all I wanted there. Now uh moving into the crux of the material consider that to be the intro. So cloud offensive operations uh at Belt what we've done is we've split this into three different types of categories. We have uh penetration testing. We have uh cloud offensive operations and cloud purple team exercises. So um penetration testing we split into three tiers. Uh there's a black box, a gray box and a

white box approach. They complement each other and are not uh either or. They are often all required in order to get a good uh coverage of the application. I'll explain why in a bit. Uh red team operations focus on specific goals. And uh typically we're going to use a plethora of uh different uh tactics that might be a little bit more advanced or invasive depending on the scope and rules of engagement that we've agreed upon. Uh that would include social engineering. It would include fishing. Uh and it would include uh perhaps even moving on site if it's required. Um and purple team exercises are going to be sort of like a red team but with more of

an emphasis on collaboration with the blue team or security operations center of the client. uh where we're going to try to help them come up with better uh response and detection methodologies and see where they're lacking when we do certain actions. Uh so different goals uh in these types of events. The methodology like I spoke about um we split the pentesting into three different components. The external, the uh assume breach and the security audit which is the different uh box colors. So the the reason why we do this is uh you might have um a blackbox uh engagement that occurs and we look at your profile on the internet. We do our osent methods. We don't find anything. We

there's no exposed credentials. There's no badly configured services that are visible from the outside. There's nothing we can do to get a foothold. But you might have some server that is very very poorly configured. And the day that there is someone who gets an account, maybe you know some person in your organization clicks on a link or does something bad or changes their password and reuses it somewhere else and some website gets breached whatever there's a reason why we have a way in now. Uh well the day that that happens and you've only done blackbox perspective you might think you're fully secure but you're absolutely not. So what we do is we you know we include this graybox perspective

which will leverage an identity that has been provided that represents a standard employee and we'll see okay if this standard employee gets breached what's the worst that can happen and often companies are surprised to see what is the worst that can happen. They might be expecting uh because they from an external point of view there is no current lowhanging fruit then there might not be anything to find but that's often not the case. Similar uh rationale is applied to the white box perspective. So we uh when we do the white box we demand or we ask for a uh a highprivilege account which has access to everything in the uh cloud environment. Uh and then what we're

going to do is we're going to systematically audit everything to see uh okay we might in in those cases it might give us visibility on certain assets that we just would never even see if we were using the employee account. uh that can be important when you're dealing with uh assets that have say you know random alpha numeric subdomains that's like an MD5 hash or something something you will never find or guess programmatically and uh now you have access to it you have visibility on it oh look at that it's terribly configured it's easy for an attacker to do an incredible amount of damage with it etc so this is a bit the uh the ideology

behind splitting this into three different uh tiers and again they complement each other they aren't uh replacements for each other. So standards and frameworks going to talk just a little bit about this and I'll explain why MITER has some good um some good stuff. They're very good at making matrixes. Um we are not going to talk too much about the the matrix because uh there is when it comes to cloud there in my opinion there is a lot of overlap uh with the different steps and also the steps are not so much uh sequential as you would expect them to be. Sometimes you have a step that skips another one. Sometimes you uh you have one step which

takes three steps in one. And this is often the case. So I just wanted to mention that MITER has some attack frameworks uh for for cloud specifically. Microsoft has their own and uh there are some in the community like Alina Laauo has a good one on GitHub which is available. So there are some uh ways to understand this but I wouldn't use this as a rigid framework to base your understanding on of cloud pentesting on. it's more of something that can complement it. Uh although we will do some callbacks to uh to this framework here. So this this is the uh the cloud matrix framework and it breaks down in its steps. If you don't know

there's the initial access, excuse me, the execution, persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, etc. Um you'll see in my examples later why this isn't so much a good thing to base yourself on rigidly. uh but it is helpful to understand the overall process and it will be referenced in this in this documentation. So let's get into the meat of it. This is the actual reason why I'm here. Uh so cloud attack life cycle we've got uh the first step which is identifying the target always. In the three different cases of these providers, it's going to be either identifying the organization name, the AWS account ID or the tenant ID which is

basically the same thing. It's an identifier which represents your cloud environment that you are leasing from the cloud provider. Uh that's what we base our initial attack on and everything that comes after is based off of this discovery. The first step so again I said I would reference MITER right but um it's you'll see why. So the first step initial access it occurs in one of six ways typically. Uh we either exploit a cloud component which is a VM a function some storage buckets whatever uh exploit an identity which is leaked. It could be an access token or it could be actually credentials. Um spraying which can be uh username brute forcing usernames uh password spraying etc.

Fishing users for credentials or to bypass MFA. Uh exploiting a device. This it happens when we uh already have access to your internal environment, but maybe we aren't a domain admin. We might not have all of the keys to the castle. We might just have a very small foothold in your internal environment. Maybe we just have one user or one workstation that's been compromised. But if that workstation is joined to the cloud and there are ways for us to bounce into the cloud and then back into your internal environment or just into the cloud and get some, you know, uh secrets there, uh this is one way that we would get initial access to the cloud environment.

and abusing trust relationships um specifically uh supply chain attacks or trust relationships that exist between different organizations or tenants in different cloud environments. Um you've got some examples of this here. So DNS enumeration, certificate transparency lists, classic OSIN stuff. Uh that's open source intelligence gathering. I'm going to use that acronym a lot. Uh but uh this is where we would uh essentially grab a list of uh valid targets and things of the source. um direct u search engine indexing. So dorks, uh there are Google dorks, there are Bing dorks, there's uh pretty much any search engine has dorks. These are specific operators that let us search for very specific information that's been unintentionally indexed by these great services. Um this

is actually a functional dork. So if you use this right now, you will find creds on the internet to some organizations that I have no affiliation with. But uh yeah, this this is actually working as of this morning. And it's just to illustrate the point. Um, we would of course refine these and include keywords that relate to the specific target. We're not just looking broadly, but uh you should be aware that attackers are looking broadly and uh will eventually find things that are leaked. So that's a good example. Uh publicly accessible storage. So S3 buckets, cloud storage, Azure blobs. Uh there are aggregation websites and services that exist to find these u like uh grey hat warfare is a

good one. Um here on the on the left, I should say. Uh the uh there is an example of a Python tool which is open source available on GitHub which allows um identifying open S3 buckets. You give it a keyword. In this case the target is devcloud buck which is a target we created for this uh presentation. And uh we uh configured a S3 bucket to be accessible publicly. So you can use this. It'll do some rudimentary brute forcing and permutations on the name uh to find uh open buckets and then it'll list them for you. And then here you've got an example of some goods you would find super secret key. You can imagine

this would be an SSH key. Might be some random documents that uh disclose information about your internal processes. Could be anything. But uh if it's open, attackers will find it if they're targeting you. Um traditional web application vulnerabilities is another way in. Uh usually you'll see this when uh cloud components are implemented into web applications like uh cloud functions for example might be used as a backend for an application or maybe the application itself is hosted on a cloud VM. So if we can exploit that application in a traditional way, we will have execution in the context of the cloud account that is running it. So this is one another way we get initial access. Open services. This is typical

um normal stuff. If you have a cloud VM and it's running certain deprecated or vulnerable services on certain ports or maybe it just has an open port, you know, where you can connect and do some nasty stuff. Uh well, we can find that just as if it was a regular physical server. Same thing. Um there's also uh vulnerable serverless functions. I already went over that. Leaked credentials. There's great tools that allow you to find leak credentials on the internet. We're going to spend a bit more time on these, so I won't talk about them now. Um, password spray. Also going to talk more about these in detail. Uh, system compromise. This is like when you uh when you're in an

internal environment and you have system on an asset, server, workstation, whatever, you can extract a re primary refresh token for example from the computer itself and then use that to uh access the cloud environment as that uh as that computer's uh account. So um you can also do fishing which we'll talk about again in more details in a sec. So let's move on here. You've just got a couple of specific examples of uh for for each one. So AWS, Azure, and GCP. You see here, it's pretty much the same thing. You can exploit public VMs and snapshots. This one's actually kind of cool. Lots of companies will have uh snapshots or volumes of certain uh

assets that are accessible on the internet um that belong to assets that are either in the cloud or that are not in the cloud that are in their internal environment. We've actually seen this in practice where um an organization will have for example a snapshot you know backup of their domain controller VM and then that is uh hosted publicly in the cloud but the the domain controller is not connected you know to the internet um well if we can get that snapshot which is publicly available we can set up our own computer in our own cloud instance and then just mount that and we have full control of our own computer and we just pone your domain controller

you know so this is uh this is something we see often also So when you get access to um to a particular server um you might be able to find uh certain tokens, right? These are just paths that you would look for in different cases, but it's as you can see the same the same thing. It's just a different path. Uh you'll find tokens there. Tokens are cool because they often allow you to bypass MFA uh because there's kind of an assumption that you've already passed through the MFA uh transaction in order to uh acquire them. So there's limitations on how they're used, but they can be pretty much equivalent or better than credentials in some

cases. Uh okay, so more on access tokens. Um we can search for these also on the internet because they follow certain patterns. Um in AWS case, you they all start with AKIA. This is a pattern that we can leverage to programmatically look for them. There are services that exist uh to leverage that. And uh we can also find uh for example in the case of uh GCP like JSON files which um are service count JSON files which are essentially equivalent to accessing that service account. In the uh picture you have here the example is uh us using the legitimate Google cloud uh CLI to uh upload or to actually use a uh the AP-SA JSON file that we

have recovered off of the internet. Uh so it was publicly accessible. we found it by uh searching for it using OSENT again. Um well, we can activate that account and now we have uh access to the projects that that account has access to. So these are just some of the ways that you can leverage these things and there's a couple of tools here at the bottom. I encourage you to check them out. Some of them are very good like truffle hog for example, very good tool um to do this. Other ways that we get initial access and it's going to be like this guys. I'm going to go through them fast. I'm trying to give you red team

perspectives, not teach you everything about it. So um initial access another way we can do it is through uh user enumeration uh particularly in the case of Azure because Azure doesn't consider this to be a vulnerability rather Microsoft doesn't consider it to be a vulnerability so they allow uh username enumeration to continue to exist it's kind of a by design thing so um yeah we're in this case we're using cred master which is all these tools by the way all available on GitHub all free all open source etc. Um, in this case, what we're doing is we're uh creating a uh list of potential users. We're going to do that through again OSENT. We're going

to look at your company's LinkedIn. We're going to look at your company's website. We're going to grab all of the employees names, everyone that we who has anything to do with your company. We're going to derive the structure of email addresses that your company is using. So, typically it's like first name.ast name or you know the first letter of the last name and then the first name whatever. These are predictable patterns. We'll create lists of users that uh of usernames based on these patterns and we will feed it to uh to these types of tools. These tools in this case are this case this tool is leveraging AWS infrastructure in order to do this. Uh so we're using AWS and a

technique or tool called Firerox which basically we create an API gateway and we rotate the IP every time that we make a request. So there's we can avoid lockout policies this way. Um, as we move forward in time, these companies are getting or these providers are getting better at detecting this sort of thing. So, uh, we also have to add certain randomization like user agent randomization to make it look like it's coming from a different device by adding different HTTP headers. Uh, we also have to add jitter to the time intervals. Machine learning is getting better at predict at at seeing attacks. So, we have to add a little bit more randomness to the attacks, but it's still entirely

possible. Uh so in this case we're using a specific region which looks legitimate. Uh and we are trying all of these usernames until we find some valid ones. Everything's blacked out but the idea is we take a list that we've created and we find valid usernames. Then we do the same thing with passwords um until we get a hit. And uh in this case we're doing again the same thing. You see we've added a delay um to the uh to the command. But again this is just an arbitrary tool. You can use the any tool to do this. you can make your own tool. Um, we're using a specific region and we're rotating the IP again every

time that we do these requests. So, here you see we have some valid ones. Okay, cool. So, we've done some password spraying. We've found some users. Now, what what if there is MFA? Um, MFA is uh in this case or and typically based on conditional access policies. Um, in this case, conditional access is an if is an if then statement. So it says if you want to access a resource then you have to complete a certain action um in this is typically how uh multiffactor authentication is uh implemented. So there are a number of ways to get around it usually has to do with misconfiguration. Uh we are using a tool called MFA sweep again free uh open

source GitHub uh which can be used to test what are the um factors that uh force the use of MFA. There are sometimes exceptions and we will leverage those exceptions as an attacker. So these are the typical exceptions. You've got legacy authentication. Uh that means old protocols that just don't work with MFA. They break. So we create exceptions for them. Um you've got geoloccation based. I skipped one. I'll get back to it. You've got geoloccation based. Uh so anything from China, deny it. We are in the US. We're not going to let that happen. Um device type, right? That one is something that MFA sweep will be able to detect. Um perhaps all of the sea

level at your organization uses iPhones and they can't be bothered with MFA because it reduces their productivity. Uh I've seen that. So uh they make it so that all iPhones don't have to use MFA. Um or maybe Linux devices because it breaks whatever. Um there's also userbased conditions. So there might be groups within the cloud environment that are specifically allowing this again like execs IT uh break glass accounts. So accounts that you'll use if you're locked out of your cloud environment. you might not want MFA on that one account and it's actually kind of common to have that. Uh and also cookie or access token hijacking. Uh usually these uh will bypass MFA altogether because

like I said earlier there's an assumption that you've already passed through the appropriate channels. In this case here we're using MFA sweep to detect which cases are required or not the use of multiffactor authentication. We see that Linux, Android and iPhone do not need it. So we would then emulate those user agents or those devices and use them to access this account that we previously found without passing through multiffactor authentication. Uh one thing that I didn't mention and that I'm going back to it the wireless guest network thing here. Uh so another way that conditional access policies are applied for MFA is u through IP ranges. Uh typically an organization might say okay all the exit IPs of our internal

network we are going to make it so that they don't have to use multiffactor authentication because we trust that the people are are sitting at their desk you know we know who they are we already have cameras and security guards and all this so it's fine they don't have to use 2FA um well in that case something that we've actually seen in practice and that occurs is they'll include accidentally or through neglect uh the uh the the exit IP of their guest network which happens to perhaps overlap in range with what they're you know usually using using for their internal network. So what we can do then in those cases is we can drive up to the company uh go in the

lobby sign into the guest network with no creds and then use these accounts that we've derived um you know creds for and bypass MFA because they've allowed the guest network to do so. So this is a good example of uh things not to do. um other perspectives, right? Switching up a lot, but for initial access, something that we will do often is leverage communication apps, things that are built into the cloud environment themselves. Uh things like teams uh or Google Google chat. Um they by default, Google chat will allow communication from an outside uh organization. Uh same thing with teams. In a lot of cases, we can create a very realistic outside organization which mimics or looks

identical to something that the user is expecting to see. perhaps a subsidiary, perhaps the same organization itself, but with a small change in the letters, whatever. Um, and then we will send them basically spear fishing. Uh, what's cool about this as opposed to traditional email fishing is it often bypasses all of those traditional countermeasures. Remember the graph at the beginning where there's all those countermeasures that are in place, but not from the cloud environment. So, a lot of people are not protecting against this sort of thing. Although they might have a very good anti-PAM filter, they might have, you know, deep packet inspection and and they might have a firewall which is stopping resolution of malicious host

names and all this. But if we use these which are legitimate tools that are not watched, uh we can get past those things, send a malicious link and then you know do our thing that way. So this is something we might leverage. Uh AWS assume role abuse. This is more specific but also pretty cool. Um AWS in particular, now we've moved on to a different one. um has uh policies which allow for assume ro which is basically an impersonation. Um the assume ro action allows you to uh take that uh to take that role that you've uh that you're asking for through the API. Um because of a discrepancy between the response when you ask for a role that

doesn't exist or that does exist, we can brute force programmatically a bunch of roles like write access, full admin, global admin, just stuff that might common sense be in use. uh and we will determine which roles actually do exist at that organization. If any of them are configured as follows like with principle and then a star meaning anybody uh we can after that take our attacker organization which also exists in AWS create an account and then assume that role since we know the name of the role we've brute forced it and we and it's misconfigured we can give that role to our attacker account this can be very dangerous and uh it occurs in practice

as well. So there's tools to uh help with the brute forcing components of this although you could just do it yourself. Just a little example of another initial access technique. Now moving on to Azure. Um again we're spending a lot of time in initial access because red team perspectives. We just want to give you guys a little bit of the eye opener. So um elicit consent grant. This is a really cool one. We basically create a a new tenant in Azure and we create a new application um that is attacker controlled. the application we ask we we are going to abuse delegation between the victim and that application and we're basically going to generate a link

which is going to ask the victim to delegate their permissions in their Azure organization to ours uh to the application specifically and it would look something like this. So this is the uh crafted email looks very legitimate. um when they click on it, they get this legitimate like not crafted. This is a real Microsoft popup asking for consent. Uh you can see the company like the attacker company that we've created is MSFT security services up there. Looks very realistic. We're using the Microsoft logo. The only indicator that this is malicious is that it says unverified. That's it. Um if they accept, they are going to be essentially sending us u their access token and refresh token. The access token has a

short lifespan. we can use the refresh token for up to 90 days to reoptain the access token and we would get uh whatever um permissions that they have accorded to the uh application. So that user if they have certain permissions on certain things within their cloud organization now we have access to that as well. Uh so this is pretty powerful. It's been partially patched since 2020. Uh there are new countermeasures in place um like uh the warnings changed basically but it's still remains exploitable and pretty much the same. Um, another type of uh leveraging of legitimate Microsoft infrastructure in order to do fishing is device code fishing. So this link here, Microsoft device login exists for devices that are

not smart devices that don't have a web browser and that you want to enroll in your Azure services. Uh, so we can use those to uh create this here code and then we can send that code to the the the victim in a uh in a in a email that looks like this. If they click on the link, it sends them to the legitimate device code enrollment endpoint from Microsoft. They enter the code that we've provided and then it again gives us an access token and a refresh token um to uh to their instance. The only difference here is we can't control which permissions we want. Uh we we are going to get just basic permissions but

they are enough to for example list all the users of the Azure environment. Uh with all those users we can then rego back into the first stages and start attacking those users for password sprays or other types of things. So it would feed into the attack life cycle. Moving to persistence. So this is uh changing up the MITER framework a little bit. Um there are many ways that we can get persistence. And a reason why I mentioned I don't like the MITER framework to describe this fully is because often times you won't be able to get persistence after your initial access. You have very low privileges. You don't have the ability to modify some of these things that would allow

you to get persistence. Doesn't always make sense to have it as a second step. you might have to do privilege escalation before you get to persistence or perhaps you're going to do an action which allows you to get persistence and privilege escalation in the same go and and thus it's not necessarily the best way to split it up and look at it that way. Uh in this case however we're going back to what we saw earlier. So the uh assume ro thing well we can instead of creating a new service principle or a new account in your compromised environment we can actually just modify this uh this trust policy and and and create that vulnerability that we spoke

about earlier. Instead of putting a star this time we're putting literally a uh we're designating our attacker account from our external organization and we're pretty much backdooring this in the sense that we can assume this role now at any time with that attacker account which belongs to our external organization. This is something that might not be as visible to uh CIS admins or anybody who's managing the cloud infrastructure. So uh that's that's what we've got here. Assume roll policy backd dooror but there's other things that we can do. Running out of time so I'm not going to talk about all of them but we can modify the conditional access policies. We can hook Azure AD connect.

That's pretty cool but way outside the scope of this uh talk but we can basically uh mess with the DLS that are causing the synchronization from the uh from the internal environment to the cloud for the password hashes. Um we can uh assign virtual machine contributor role to a not to a compromised user. Uh which means basically these contributor roles are very very powerful and we can do uh a lot of things with them. I'll leave it at that. Uh attach policies to a compromised user backdoor lambda functions. Those are cool too. We can add our own code to an existing function that's being used um in the uh in the that's being provided by the uh cloud

environment. We could also in GCP for instance add our SSH keys to the project metadata. then any resource that's created with that project will automatically incorporate R SSH keys and we can log into it uh with those a bunch of ways to do persistence privilege escalation I'm going to touch on this very briefly um there are a number of ways we can do privilege escalation as well in a cloud environment and AM and and roles and permissions are really the most important thing to uh consider when you're doing your configuration because if we have almost no permissions uh when we or we have no permissions when we get our account we can't do anything with

it. Um most that it it really comes down to that. Um if for example here um we're giving an example of uh implicit delegation which is a GCP thing but uh this this is reminiscent of what was uh previously in the beginning of the uh of the talk. Uh if you have service account A which has implicit delegation on service account B and service count B has get access token or whatever privilege over service count C then A also has that privilege over C. And this is something that is not always taken into consideration. So there may be segmentation in place with the intention of making this impossible. But because there's implicit delegation between A

and B, A controls everything C controls. You could this is a reductionist view. But if you took this and made it more complex, you might have 10, 11, 12, 20 different accounts, you know, in this chain. Uh but implicit delegation or any type of delegation for that matter uh can lead to this sort of uh this sort of escalation potential. Um there's also uh that well there's also acting as service account. I'm not going to explain too much about this. Just wanted to briefly mention privilege escalation credential access. Moving further down the MITER framework um we might uh red team perspective. So again not too much overall information just trying to open open your eyes a little bit. Um to get

credential access let's say we've compromised a uh virtual machine which belongs to a cloud environment. Um there's a web app running and uh it's running on a cloud VM. We uh get rce on the VM through the web app. U now we have uh rce as a user that was running the web app or perhaps as a normal user on that VM. We can perform SSRF attacks to get uh credentialed access as the VM itself. In the case of Azure and GCP, they're just they're very similar. You can see basically here what we're doing is we're using PowerShell to make a request to this non-outable IP. You could consider that IP as like sort of

your 127001 in a traditional uh or local host you know in your traditional SSRF attacks. So we will make a request and obtain a token as the actual instance itself and then that token becomes our credentialed access for the VM. So we don't necessarily have to have initial credentials in order to persist in that case. And there I I used the word persist but you see credentialed access would lead to a persistence uh or in the previous case you know the the privilege escalation could lead to a persistence. And that's again why I didn't spend too much time on the MITER framework um or any framework for that matter and you can do the same thing in both cases. Um

there are a number of ways to get credential access through abuse of intoune. This is Azure again uh in tune or if you are a global admin device configurer um there's a lot of different ways you can do that. I'll give an example here. Uh if you're in tune manager uh or sorry in tune administrator or global administrator you can execute PowerShell on the uh joined uh assets. So in this case we could execute something that would give us access to cred to secrets that are stored on the box. We could create users on the box. Um this would give us a persistence mechanism. it would give us credentialed access and it would give us

uh the ability to prov. So again 3 in one not so not so strictly onetoone these uh miter steps uh xfiltration going a bit further down the line uh there's a number of ways we can do xfiltration we can create u images volumes snapshots um we can host things in buckets we can synchronize buckets there's all sorts of u legitimate functionalities that we can abuse that exist inside the cloud infrastructure that would allow us to do this um in this case we're creating an image and then after we will host that image uh publicly and then take it and we can mount it into our own VM or our own uh instance in our attacker controlled

organization and then we can recover that uh information that way. And finally uh impact. So uh here's some things that are not typically considered and we've actually seen these in in real life. Um so if you can edit the key policy to in AWS uh account, you might be able to create your own AWS account. go into your KMS, create a key, and then change the policy of your victim so that you can import your own key into their organization. And now you can encrypt all of their S3 buckets with your key. Uh if you do this, this is really bad for the uh victim. Uh essentially, this using the legitimate AWS infrastructure as ransomware. Um and there's nothing

they can do. If they were to contact Amazon and say, "Hey, uh I can't access my S3 bucket." They'll say, "Yeah, well, you know, all the data is encrypted with this key. Does it belong to you?" No. No. Uh oh, okay. belongs to this external organization. Nothing they can do there. They don't have a back door into this hopefully. Uh so there's no way for them to then get access to that information and you'll be in a whole lot of trouble. So uh this is something to consider as well. Uh and one of the potential impacts that could occur if you uh are attacked on from if your infrastructure on the cloud side is attacked and attackers uh succeed. So uh

I'm going to talk quickly about leveraging the cloud as a red team operator. These are uh more features that we might use uh in in red teams. I talked about fires and how we can use AWS API gateway to rotate IPs to do all sorts of interesting things and avoid countermeasures. I'll also talk about um quickly uh cloud-based fishing. So we saw two types of that elicit grant attacks and uh consent grant attacks rather and device code fishing. There are more. I just mentioned two briefly. Uh so these are things that go into the TTPs of uh attackers, modernday attackers. Um also uh using uh cloud for uh making your C2 infrastructure better. Uh as an attacker, we often need to

obuscate our command and control uh servers uh because they're they're giving off a whole lot of signatures that companies and defensive products are used to detecting. So one thing that we'll do is we'll leverage legitimate Azure infrastructure. will configure some redirectionctors uh so that our uh our implant um let's say cobalt strike beacon or in in the case of less mature uh engagements maybe like a interpreter might be something that people are familiar with uh but whatever your implant uh you know that detonated is it needs to talk back to your command and control server if we do it this way which is a technique called cloud fronting um we're basically going to make it talk to Azure instead of

directly to us and then Azure will redirect everything to us this means that from an internal perspective if you're monitor ing logs. If you're a CM, if you're a firewall, all you see is communication with Microsoft with with legitimate Azure endpoints. Um, and that's if you've spent any time in internal networks looking at traffic, you it's impossible to uh separate some communication with Microsoft from other communication with Microsoft and uh if it's properly done, it can be able to bypass even next generation uh countermeasures. So, this is something that is being done in practice. It's very common and it is quite effective. So uh we can also host malicious code on Azure and S3 instances which can help

when we want to recover if we're doing a staged payload and we need to take different pieces from it. Uh if we put it in S3 and you guys are flagging any malicious domains well it's talking to Amazon it's not talking to a malicious domain. So uh these are ways that we can leverage the cloud as a red team. And finally this slide because I had to include this because uh you guys need something positive. So there are ways to uh to stop this right. Um there you need to understand the shared responsibility model first and foremost. You need to uh you need to start with the configuration and really you know pentesting services can help with uncovering these types of

flaws and uh they can be rather esoteric at times. So it's it's good to uh to make use of those services. Not enough companies do uh so frequently. Um it's cool to also deploy MFA even though I talked about ways to uh to bypass it. It's absolutely very very useful and a very large uh stop gap, you know, that can that can help you um secure your infrastructure more. In fact, all the things that we talked about earlier are specific instances where MFA is bypassable because it's not properly implemented. So, when it is properly implemented, it can be very useful. Um, regularly review access token usage. This is something that not enough people do. Um, there might be two or three or

four access tokens that are associated with an admin account. We ask the CIS admin, hey, what's up with those? Oh, you can delete those. Haven't used them for a year or two. Why do they exist? If they're being used, you wouldn't necessarily be aware of it. Uh, so review that. Uh, inventory your apps. Monitor privileged accounts. Review and audit service principles and the permissions that they have in things like MS graph API. Uh, fine grain identity and access management. Essentially, there are ways to make this better. Uh, it's not all bad. And uh one cool thing can be deploying honey honey tokens and honeypot accounts. Um so that indexing services that we're relying on when we do our osent uh they might be uh

they might be finding those and then if an attacker uses it uh you're aware that someone is targeting you. So uh it can be cool to intentionally leak some of these things as long as that's properly done and they don't actually give access to anything uh to alert you that uh you're being uh targeted um and and in what ways you can uh you can improve. So uh yeah that's uh pretty much it. If uh anyone has any questions I am available for minus five minutes. Stop.