also have a blog where I write about stuff I also wrote there about pre-exchange. And of course I have a Twitter account where I share my research. So today we'll be talking about clouds. And in the cloud as you all know, um, everything is magic and secure. You don't

have to patch and everything is automatically arranged for you. You just spend some money and everything is good. Um, our results are fully the reality. At Fox we also have like Internet response department and most things they see is um, the cloud being compromised because people actually didn't secure it properly. And on the conferences I don't see a lot

of talks yet about cloud stuff. There are some focusing on Azure and um, on Azure virtual machines and stuff and AWS. But I didn't really see anything about Azure AD. So that's what we'll be talking about today. And first I'll be giving an introduction into

Azure AD, what it is, how we can talk to it, um, how its architecture is kind of built and about the roles, applications, service principles. Then I'll take a short step and have a look, have a look at some fun with multi-factor authentication. Then we'll talk about linking up the cloud and on-premise. Then talking about Azure resource manager and how

it's connected to Azure AD. And last but not least, I'll talk about integrations and as an example, I'll take Azure DevOps. I have to apologize in advance, uh, if you're still tired or hungover, this is a talk which is pretty fast paced and I've got a lot of content. So,

try to keep up. But first, what is Azure AD? According to Wikipedia, Azure Active Directory is Microsoft's cloud-based identity and access management service. Um, that's a whole mouthful, but basically it does the authentication for Office 365, uh, the Azure

resource manager and anything you want to integrate with it. Um, I always like to compare it kind of with, uh, login with Facebook, uh, because you can integrate that on a third party website and you can just login with your Facebook account and you register it. Only then, um, it has a Microsoft logo and it's called Azure AD. And it's actually, on the,

apart from that, it's actually pretty similar. And it's called Azure Active Directory, but if you compare it to the Windows Server Active Directory or the on-premise Active Directory that we all know, there's actually nothing that's really similar to it. Um, all the protocols are different, uh, the structure is different, there are

different, um, terminology and different setup. So, for this talk, try to forget almost everything you knew about Active Directory and we're really gonna focus on cloud. So, if you want to interact with Azure AD, there are a couple of ways. First, there's the portal, which if you did use Azure AD, you probably used. There are some PowerShell

modules, um, there's also a command line interface and lastly there are some APIs. And that's already quite a bit of waste and there's a few difference between those. Um, for example, the portal, it's very, um, nice and shiny, it's, it works nice, you can click

around and configure stuff. But if you try to understand how Azure AD works and you're looking at the portal, um, it's not gonna work out cause I started with the portal and then I moved to trying to understand how things work with the API and such and I found out that the portal just made it more unclear for me cause, um, Microsoft

tries to make everything user friendly and translates, uh, things from the complex terminology that's actually used in the backend. And, so if you want to understand Azure AD, um, don't use the portal. There's also PowerShell, actually there are a couple of PowerShell modules and I think the oldest one, eh, is the MS online PowerShell module.

This one really focuses on Office 365 and as such it has a few features that you won't find in the other modules. Um, this is a bit old and Microsoft is deprecating this one, so you shouldn't be using this but it still has some specific

features that are not available in the other modules so sometimes you still have to use it. There's also the Azure AD PowerShell module which really focuses on Azure AD but it has a different feature set than MS online PowerShell module. And lastly there's the, uh, command line interface and yet another PowerShell module but this one is focusing more on

Azure resource manager so you can use it to, uh, manage spiritual machines and VLANs and that kind of stuff. And the most interesting ones from my perspective are the APIs. Yet again there are some different ways here. So you have the Azure AD graph which is, as it

said, is really focusing on Azure AD but you also have the Microsoft graph and Microsoft was like okay so we have this graph for Azure AD but why not put all of our products in one single API? And I'm like hmm that doesn't really make it much easier to understand. If you apply an API definition that would take a year reading through and I can't really find anything. So I prefer the Azure AD graph, um, but that one is already, um,

considered legacy. So I, in the future you'll probably have to use the Microsoft graph. Lastly there's the exchange provisioning service which uses XML so I really try to avoid that one but once again that's the back end of the MS online PowerShell module so

there are some features in there which are actually not in the other APIs. Now which one to use? Um, all of them have different features and some of them have unique features but they are, um, deprecated or considered legacy as you can see in the, in the,

in the corner below. They support different authentication methods so some of the PowerShell modules support difficult authentication and some don't. So if you want to actually use all of the features you're stuck with using different APIs and different PowerShell modules all over the place. And to make it even more confusing there's also a

different terminology. Like here I'm using, um, at the top I'm using the Azure AD PowerShell module to list the directory roles and you see I have 5 directory roles. But if I use the MS online PowerShell module I suddenly have a lot of more roles. You also see that the object ID for the role is somehow different between the two modules. It has

a reason but it doesn't really make it, um, much clearer. Also here I'm looking at the company administrator role and if you look at the portal that one is conveniently called global administrator. So once again, uh, different terminology. So to conclude on this there's not really one uniform way to talk to Azure ID, I wish there was. And

you're also kind of limited to what Microsoft considers important. Like in on-premise Active Directory you have LDAP and everything in Active Directory is kind of stored there. But in the, in Azure AD you have different APIs and not all features can actually be called via APIs. And most of this research comes from using both

documented and undocumented APIs in Azure AD. So let's have a look at the architecture. In first you have the users, which often are the physical users that are in your company. And

these users can of course have devices. Uh, a device can be like a Windows 10 laptop that can be joined to Azure AD but it can also be an iPhone or Android that's joined to Azure AD via mobile device management. And lastly you have applications, which we'll

talk about later. And your users, um, can have specific roles and this is also, um, this picture is kind of important. So, usually if you hear about Azure roles, they're talking about role-based access control. Azure RBAC roles on the left. That is what is used for the virtual machines and stuff. And it's not actually used for Office 365. So first

we'll, uh, focus on the roles that Office 365 uses, which are defined in Azure AD. And there are some different admin roles. The first one, or the most, uh, important one is the global administrator, or company administrator if you use the APIs. And this

administrator can do anything. Now of course, you don't want all your administrators to be able to do anything. Um, so there are also limited administrator accounts. You have the application administrator, authentication administrator, exchange administrator, etc. And they all have their, uh, limited part which they can manage. Now, at the time that I

made these slides, um, the roles were fixed. You couldn't change that. Actually in the past week, um, Microsoft started to change that. So, um, you see it's cloud, it's changing all the time. And they're actually looking now into, uh, a way that you can create your own roles. But I haven't played with that yet. So let's assume that, um,

these fixed roles are all there is for the sake of this presentation. And now we're talking about applications. And I think this is the most confusing part of Azure AD. It took me a long time before I finally understood how these work. And it's also because the

documentation is not really clear on this. And once again, there's a, a big terminology difference between the documentation, the APIs that are available, and what you can see in the Azure portal. And these applications have a very complex permission system. So what is an application in Azure? Well, about everything. I mean, the Microsoft Graph,

which is an API, is an application in everyone's Azure AD. The Azure portal is also a registered application in the Azure AD that you're using. In fact, there are about two hundred applications and associated service principles in, um, every Office 365

installation. So that's a lot of stuff that is in there by default. And you can do quite some interesting things with us. So when I say application, there are actually two parts. And, if you're looking at the simplest case, which is an application which is defined in your own Azure AD, then there's the application definition and a service

principle. And the application definition basically defines what the application is about, you give it a name, et cetera. And the service principle is the, uh, actual principle in your directory which gets the rights and has the, uh, rights to perform

actions in your directory. So there are two parts of an application. And in this talk, I'll, if I say application, I usually mean the definition, and if I say service principle, I mean the kind of account that's present in the Azure AD. So, because Cloud is multi-tenant, you can have applications from another directory in your

directory. So this is the simplest case, uh, when you have both the application definition and the service principle in your own directory. With third party applications, then the definition of the application is actually in another directory, and once you start using that application, a service principle is created in your own directory, and that's, is the presence of that application in your directory. For Office

365, Microsoft has some internal, um, tenants, in which all these applications are defined, and in your Office 365 directory, all the service principles are created. So once

again, it's a split between the definition of the application and the service principles. Now applications can have privileges, and there are basically two kinds of privileges. In the portal, they're called, uh, delegated permissions and application permissions. And delegated permissions are only used when a user is actively

signed in in the application. However, application permission is something the application has statically, and it can use it at any time. So these, these privileges actually assigned to the service principle portion of the application. Now the

permission model is as follows, um, every application defines its own permissions, which can then be granted to other applications. And like commonly used, uh, are the Microsoft Graph and the Azure AD Graph, and they define permissions, such as directory dot read, which gives an application or a user permissions to read attributes in a

directory. And these can then be granted to other service principles. So let's look at, uh, how this looks in the portal first. So here we have the application definition, and we see there are a couple app- permissions defined for this

application. So first is the directory access as users, access as user, which is a delegated permission. So once a user is signed in into this application, this application has the right to access the directory as if it was the signed in user. There's also, uh, an

application permission here, which is, um, directory read write all, which gives the application permissions to read and write to the directory. If we look at the service principle, we see these privileges again. So the, um, the application has permissions to

read and write directory data in this case. And also, uh, an admin sometimes has to grant these privileges, because by default any user can create new applications, but of every user can give these application permissions. And sometimes the high value or high impact permissions have to be approved by an application before they can be used. Now I

created a small table to, um, see how permissions actually work versus how, um, the Microsoft portal or the Azure portal tells you how they work. So on the right is the portal terminology, and on the left is how, um, they are used in the APIs, which for me

is, um, canonical. So every application defines OAuth 2 permissions and application roles. And these get translated to, um, delegated permissions and application permissions in the portal. And an application definition then requires, uh, access to certain permissions, such as OAuth permissions or application roles, and when an

administrator approves those permissions, these are granted to the service principle. So you would imagine that, um, we have the Microsoft Graph application which defines permissions, uh, we have created our own application which needs to access the

Microsoft Graph, so we set some, uh, definitions of which API calls, or which API permission it requires, and these are then granted to the service principle associated with our application. Oh, this is clear a bit. And, and as I said, um, I should

previously, an admin has to approve these applications, so, uh, that's how it works in the portal, but it's not necessarily how it's required to work. So normally you add permissions in the application definition, and an admin then approves the permissions. However, if you use the APIs, you can directly, um, assign a role for, to an

application on the Microsoft Graph or the Azure AD Graph. There are some API calls for that. And then when an admin looks in the application's overview in the portal, it says, oh, there are no permissions required for this application, which looks great. If you

now move to the service principle, suddenly there are some permissions that the service principle has, so even though the application definition doesn't say it has these permissions, the service principle still has them. And also you can see that these privileges were granted, uh, by an admin, but it doesn't say which admin, it just says granted by an administrator. So there's not really a way to see, hey, who was this

administrator that assigned these permissions without actually putting them in the definition. It gets even more confusing when you look at Microsoft applications, because all the Office 365 applications are considered, uh, first party applications in

OAuth terms, and as you see in the portal, they don't actually have any permissions that you can see. So you, we are looking at the Microsoft Teams web client here, and it says, oh, there are no permissions for this, um, service principle. Okay, that's great, so it

doesn't have any privileges, you'd think. But when I sign into Microsoft Teams, I get a JSON web token, which, uh, if you decode it, contains the privileges that were granted to this application, and you suddenly see that this application does in fact have permissions. So in the scope variable of the JSON web token, um, you see this application

can actually send emails, it, uh, can read my information, and it can write to my calendar. And it has these privileges on the, the outlook API. And as you see, this is actually the same application that we were just looking at, the Microsoft Teams web client. So why does this all matter? There are some admin roles, uh, which allow an

admin to manage all the applications in the directory, such as the global administrator, of course they can do that because they can manage anything, or the, um, application administrator or cloud application administrator. So these administrators can assign

credentials to applications, or rather to the service principle of the applications, and then they can log in as that service principle using those credentials. So if we compromise an admin account in Azure AD, we can, um, assign credentials to an application, um, and then we can log in as that application. And of course, since

applications are, um, not humans, there are no multi-factor options for service principles. Also, if there is an application that actually has more rights than the application administrator, actually in previously there used to be some default Office 365

applications, which had roles assigned, so it had more permissions than the application administrator had. So the application administrator could just assign credentials to the application, and then perform actions that he previously couldn't do. This has been fixed by Microsoft, by the way. So just to give an example how

this works, um, you can use PowerShell to create a new certificate, and then assign certificate credentials to a service principle. Then you can log in as a service principle. In this case, I'm using the Azure AD PowerShell module, and you see I'm signed in with a certificate on the directory. Now if I perform any actions such as

adding a user to a group, then the logging will show that this was performed by the application, rather than, um, the admin that assigned the credentials to the, to the application. So if I assign credentials to an application, and then I wait X amount of

time, that the logging kind of rolls over, and there are no more logs that I actually modified the application, there's no way to see which user assigned these credentials, and this actually performed these actions. Furthermore, a bit of a twist, um, so

application admins by default can't assign roles to the application that allow it to interact with the Microsoft Graph or the Azure AD Graph. If they could, they could just assign the permissions to the application which they don't have themselves, which would be previous escalation again, but this is not possible. But what they can do is assign

OAuth permissions, or delegated permissions if you use the portal, but these are only valid when a user is using the application. But of course you can exploit this, um, if you add the user impersonation permissions to the application, and then phish a global

administrator to actually sign into that application, you can perform any actions that the global administrator could do. And here's a small demo, hope it works. So we sent an email to the global admin here, and here's a link, he clicks on it, and then we

captured his access token. So this is an access token for the, um, Microsoft Graph, and with this access token, I could perform all kinds of actions. And you can see here there's this action, this token has privileges to access directory as if it was that user. So that with this token, um, I can perform all kinds of actions and I can, uh, modify my

own role, I can give myself permissions, I can ask users to group and all that kind of stuff. And, um, as you saw, this, uh, didn't require any consent from the admin, that's because the application admin already approved the privileges for the application. You

can make this even more fun, um, so, because there are like 200 built-in Office 365 applications that the application admin can also modify. And if you assign a re- a whitelisted URL that this application can use to sign users in, and you then assign

your own URL, you can use the built-in permissions for the application to actually, uh, face the admin again. And if you look at the logs, um, this actually doesn't show anything suspicious, because if, if an admin is using Office 365, um, these

kind of sign-ins appear all the time, and the logging doesn't specify which URL the admin was redirected to. So you can just add your own redirect URL, uh, get a token, and in the logging it won't actually say anything, apart of course that you modified the application, but the sign-in log is kind of useless here. So this was a bit about Azure

applications, I'm gonna take a little side step and have a look at notifactor authentication. So of course, um, notifactor authentication is good, and everyone should do it, um, and there are multiple options for this, so the authenticator app is one of the

options, um, it's kind of similar to Google authenticator when you have like a code that you dis-display and you use that as the second factor. You can also have a notification that comes, pops up on your phone that you, you can prove the sign-in. And there's of course the good old, uh, text message that I think has been reiterated, uh, a

million times already that these can be intercepted and are insecure and stuff. So I didn't look at that, but there's also the option to authenticate with a voice call. And this works as follows, um, you have your phone number registered in Azure AD and then, um, Microsoft calls you and in order to approve the sign-in, you have to

press the, the hash sign or the pound sign. Now I thought, okay, what about I break into someone's voicemail and I change his welcome message to the tone of a pound sign, because these signs are just specific sound frequencies. So if you can record it in

your voicemail message, then, um, potentially Azure would call you and hear that same tone. Then you make sure that the phone is occupied, so when you're performing your sign-in, you call the, the victim and make sure the phone can't answer it and the talk will go,

and it will go to voicemail. Um, you sign in using the password that you phished previously or you found it in a leak somewhere. Azure AD will get redirected to voicemail and it will authenticate you. And if you think, um, can I actually break into

someone's voicemail and how hard is that, uh, you should see this talk from last year, um, this guy made like a python script to brute force all the pin codes on voicemails, which is really cool. So here's a small demo. So I changed my voicemail message, I hope you can hear this. So this is the, the sound of the

sound sign. Now I put my phone in airplane mode. And I enter the password for the user that I somehow obtained. And it will say, okay, I sent you a text message. You can also

choose to call the phone. And now Azure is calling the phone and hopefully getting redirected to voicemail. And we have to wait for a little bit. And there it goes.

So if you do compromise someone's voicemail and you change the message, you can potentially bypass his, uh, multi-factor authentication. I reported this to Microsoft and they're saying, okay, yeah, um, we see the issue here, but you still need to compromise someone's voicemail first and it's kind of a post-exploitation technique. So

we will be fixing this at some point, but not right now. So I haven't tested this recently, but I assume this still works. So if you do allow voice messages for authentication in your tenant, you may think, you may want to think about disabling that. Okay. Up next, um, linking up the cloud and on-premise. Cause, um, of course you

don't have all your infrastructure in the cloud yet. You also have parts on-prem and you would like to combine the two. And previously we talked about the application

administrator and how he can backdoor stuff, escalate privileges and stuff. But let's assume that this account is protected with MFA and we can't hack into his voicemail. So what about the on-premise infrastructure? If you want to synchronize Azure AD and on-premise AD, um, that's usually done through a utility called Azure AD Connect and

you install that on-premise and you s- that synchronizes Active Directory data to Azure AD. And depending on which methods, uh, you use to authenticate your on-premise use in Azure AD. You can, for example, use password hash synchronization so that they can sign in with the same password on-premise in Azure AD. Or you can use, um,

federation with ADFS. Both require this Azure AD Connect tool. And the account for this tool in Azure AD has quite some privileges, which is all very nicely documented by the way. So, if you look at the documentation, you see the direction synchronization accounts. And we can see that it has permissions to update service

principles and to assign credentials to service principles. And these were just the applications that we abused with the application administrator account. So, um, brief some interesting things about the sync account. If you use password hash

synchronization, then the sync account will have access to all the password hashes on premise. So, that basically makes it domain admin, cause you can just synchronize the- or synchronize the password hash of the KBTT account and then you can compromise on premise. And of course, in the cloud, it also has high privileges, as we just saw from

documentation. And the assets in the cloud may not just be limited to the single AD domain that you're synchronizing. So, there's some potential for privilege escalation here. Um, I wrote a tool to extract the Azure AD connect passwords from the

on-premise server. Uh, there are some several protections for this password, uh, about which I presented at, uh, Troopers earlier this year. So, if you're interested in the technical stuff, uh, check out the link below. But basically, I wrote three different tools that, depending on your scenario, can be used to dump the credentials of this

account. And some work over the network, while some others, uh, can be used, in example, for cobalt strike through, um, assembly loading. And these tools get your- get the- both the on-premise password and the cloud password from the server where AD connect is installed. So, once we have these credentials, there's some fun stuff we

can do. We can dump all the on-premise password hashes if the organization is using password hash synchronization. We can also use this account to log in into the Azure portal. Don't ask me why, but this works. It's a user account, so you can just log in. Um,

we can bypass conditional access policies since there are some conditional access policies to require multi-factor authentication for all admin accounts. But, uh, the sync account is, of course, excluded from this since it's not a human account and this can't do multi-factor. Just like the application administrator, we can add

credentials to service principles, um, backdoor stuff, and do all kinds of fun things. And we can also modify service principle properties. So, we can change the authentication URL of a Microsoft application, vision admin, and escalate to global admin privileges. And

there are some more things where service principles are used. And that's where the connection between Azure Resource Manager and Azure AD comes in. So, once again, returning to this picture, um, Azure AD is the authentication and, and identification,

access management for both Office 365 and for the Azure role-based access controls in Azure Resource Manager. So, that means that if you're a global administrator, you can, um, by design, also access all the, um, virtual machines and network infrastructure that is stored in Azure Resource Manager. And, you can also assign privileges to manage Azure

resources to service principles, which can be managed by application administrators or by the on-premise sync account. And if you have an application such as Terraform, which is used to automatically provision cloud resources, then it obviously needs high

privileges in order to create and modify and delete resources. And this is, this can be service principles. So, if you have control over the on-premise sync account, you can assign credentials to service principles which have rights in Azure Resource Manager, and you can also control all the cloud resources. An example which actually uses this is

Azure DevOps. And what is Azure DevOps? Azure DevOps is, uh, DevOps tooling, um, it's in source code management, you can collaborate on projects, um, you can have automatic build

pipelines and automatic deployment. It's a whole DevOps, um, toolkit. And I had a look at Azure DevOps pipelines, um, this is kind of cool because Microsoft makes this feature available for free to, for example, open source projects, and you can automatically build

your codes through, for example, GitHub integration, and when you push your, a new version, it will be automatically built on hosted resources in Azure. An example of this is my own Azure AD Connect tool. I've connected that to Azure Pipelines, so as soon as I create a new, put a new comment in there, um, the .net binaries will get automatically

built on Azure, and you can download those. So, there are multiple ways to change the definition of a build pipeline. Previously, um, when I looked at this, only the, uh,

a GUI could be used to change the, the build definition, but, um, I think earlier this year, or, uh, at the end of last year, a new feature was added which allowed pipelines as codes in YAML files. So then the pipeline definition is part of the repository where the code is in. And it kind of looks like this. So this is a YAML file with the, um, build

definition. It says, okay, when I push a new, uh, comment to master, um, you build it using the hosted Visual Studio 2017 profile. You can provide, you can set up all build steps in order to, um, do stuff with this. So let's talk about a hypothetical scenario. Um, we

have a DevOps team, and a team, member of the team wants to automatically publish the build artifacts, so, for example, executables, uh, to Azure using blob storage. Um, blob

storage, all kind of stuff in there. So he, he links up Azure resource manager with Azure DevOps. And there's this nice button there which, uh, you can select your subscription, and then you click authorize. And then suddenly the two are connected. Now,

there is a new user, or a new team member at the company, and this team member needs minimal privileges to, uh, contribute his codes to the repository. Because he is a junior member, there, we don't give him any special privileges to, for example, alter the build definitions. Um, now the new user isn't exactly, um, isn't exactly a nice person,

because the first thing he does is actually editing that build definition in the codes, and then pushing that change to, to the, uh, repository. So even though he didn't have privileges to edit the pipelines, because the pipeline is part of the codes, this

user can still edit it. And meanwhile, in, um, a completely unrelated Azure VM, which is not related to the source code at all, the following happens. The video plays. Yes. Ooh,

it's a notepad. How did notepad get there? I thought we were editing source codes. So what happens here? Um, remember that I said that we added, um, a copy of the Azure Blob Storage for the artifacts? Well, there's, uh, a task for that, which is called Azure File Copy. And I've edited this build pipeline a little. So what it does, it's, it

gets the Azure File Copy script, and it backdoors that to dump some of the authentication data that is used to link Azure Resource Manager to Azure DevOps. And it will then put the backdoor codes back in the original PowerShell script that's used to

copy the file. So when the file gets copied, uh, instead my code gets run, and we can gain access to some of the credentials. So if we look at the logs, um, we see it dumped the tenant ID, service principle ID, but they're all, um, they're all masked in asterisks,

because Azure DevOps doesn't let you log sensitive stuff, of course, to the logs. But if you base 64 and code that, um, then it's all fine. So at the bottom you see that I dumped the authentication data and the password for the account using basic, basic 64. And we can decode that, and then we see, you get the tenant ID that, uh, is used for

Azure subscription, the service ID of the service principle that was created, and you get the service principle key, which is the password for that service principle. Now, I

remembered clicking the authorize button, and I didn't really get a warning that the service principle would basically get, contribute your rights on my whole Azure subscription. So, when I clicked that little button, a new service principle was created, and he got full privileges on the whole Azure resource manager subscription. So

it means that he can edit any virtual machines, disks, access files, and all that kind of stuff. And with these credentials that we just obtained, we can log in using the Azure, uh, CLI module. And the password you saw before, even though it looks, uh, like

basic 64 encoded, is just a very long string. So here I use the credentials that I dumped from Azure DevOps to actually log in on Azure resource manager. Now, how about the notepad? Um, I added a little extra, so it's just the inline script, which adds a

new custom extension to, uh, virtual machine in Azure. And this runs a PowerShell script, which then, uh, spawns notepad. So that's just to prove that you can actually access those virtual machines as the highest user there is. So, can anyone edit pipelines? Um,

normally no. Um, the pipeline definition, uh, there's a specific role required to edit the build steps in the pipeline. But since the pipelines move to be part of the code, anyone who could edit the code could actually edit the pipeline. I reported that to Microsoft, and that is fixed in the latest version of Azure DevOps. So, I didn't

retest this yet, but, uh, this shouldn't be possible anymore. And hopefully now the edit pipeline role is actually enforced also on the source code in the repository. A few conclusions about this, um, be careful with integrations. Have a look at which

privileges to actually get on your subscription and, um, how they're used, because anyone that can edit your build pipelines can access the secrets that are exposed to the build pipeline. And if you enable secrets for public repositories and you allow, um, you allow builds on pull requests, then anyone who creates a pull request can actually extract

your secrets of any service that you integrate with Azure DevOps. Um, so this is disabled by default and this is documented, uh, pretty well I think. At the link at the bottom it actually says, warning, anyone who can edit your build pipeline can access your secrets if you enable this, if you don't want this. Some general conclusions, um, I

think cloud can be beautiful, it definitely allows us to do a lot of things that we couldn't do before. But all your stuff is on the internet and you will have to, uh, secure it yourself because not everything is secure by design. And especially enable MFA for

all your sensitive users because, uh, 99% of the cloud compromises are users that didn't have MFA enabled. And if you have software as a service, um, it does take away your need to patch manually, you always have the latest patches, you always have the

latest features, but you also have the latest vulnerabilities that got introduced by those fancy new features. Such as in Azure DevOps case, if you really lock down your permissions and then suddenly there's a new feature which, uh, changes that, then you have to be, uh, aware and redo your, um, risk calculation. And sometimes there may be a vulnerability that makes your security some, uh, suddenly a bit more insecure. And of

course there is, uh, a full trust implied in the vendor from who you are renting your cloud services. So, um, you do have to trust that they are actually doing everything correctly and following best practices. So this was I'm In Your Cloud and thank you for

attending.