Microsoft Azure

Azure is Microsofts answer to AWS (Amazon). It’s a fully loaded cloud computing service which offers a whole range of services within their platform.

Although the Microsoft cloud may improve your security posture it won’t protect it by default, it’s important to remember that the security responsibility is shared between the two of you. Microsoft will secure their infrastructure and services best they can, however it’s up to you to properly secure anything you test, build or manage within their platform.

Microsoft will work tirelessly to keep attacks at bay however if you build a Windows Server, place it on the network and don’t realise that 3389 is open to the internet, that’s on you.

That’s why it’s really important to have a strategy and design in place before you start utilising the cloud. Cloud computing is a whole new ball game and doesn’t have the same attack surface which your on-premise solution has. Although the cloud may give you new capabilities which you couldn’t implement with your on-premise solution, you need to be aware that those capabilities come with different risks. Each risk needs to be managed accordingly and not treated the same. Let me run through an example to explain…

A users account in AD (on-premise) and a cloud based account (AAD).
Both depend on strong passwords and are susceptible to brute force attacks. That being said, the attack surface is different.

To be able to brute force the on-premise account, an attacker will need an entry point. They will look for exposed internet facing services which authenticate a user. If there isn’t one, they will need to gain access to a device that sits on the companies network (excluding offline attacks for now). This will require a lot of work and may deter certain attackers.

To be able to brute force the cloud account, they may just need to know the user name. This is because the cloud service may be using a generic URL. For example, to brute force O365 or Outlook, you can use the following; Outlook.com, Outlook.office365.com or SMTP.office365.com. These are generic and available on the internet. This means the attackers have to work less and can target multiple companies at once.

As you can see, both are user accounts however will be targeted differently. This is the same for things like Phishing attacks. You wouldn’t (hopefully) expect your users to be fooled by a Microsoft O365 Phish if you only use on-premise Exchange. If you provide OWA externally, you most likely use a custom URL such as [owa.company.com] which would route internally.

There are hundreds of examples we could run through but hopefully you can see that the more your environment shifts, so do the risks.

So what do you do?

Strategize, design, implement, test and constantly review. These stages should be completed before anything is made “live” within your cloud platform. It’s often too late if you build first and then come up with a plan.

Planning to use a whole new platform will obviously take some time so it’s sometimes beneficial just to look at the top threats today. Lets run through some…..

Not Knowing What You Are Responsible For

Although the cloud may bring security benefits a lot of them require your input. The vendor will have strong security controls in place to protect the platform as a whole but what you build/manage is on you. You need to be aware of things like default settings, how services are accessed and what baseline controls you need in place before you can start building. Failure to do this will most defiantly result in a breach. This is proven if you look at all the AWS breaches you are seeing in the news. Companies failing to fully understand how to secure S3 buckets seems to be the common issue. It’s public by default and that access alone is enough for an attacker.

It’s important that you know what you are responsible for and that this is communicated down the ladder so that everyone that works with the platform is aware.

No Identity and Access Control

in my opinion, Identify management has shifted to the top of the priority list. The cloud has shifted our environment and brings new ways to manage our user accounts. We now have the capability to have an IDP authenticate our users from anywhere and implement additional controls such as SSO and MFA.

We no longer tie our users to the network and allow them to authenticate to cloud applications over the internet. Be aware that they may not be the only ones though. If your users can authenticate to your IDP over the internet, so can malicious parties. An example would be the high number of Exchange online (O365) brute force attacks. Attackers know the URL, as it’s generic (outlook.office365.com) and are aware that legacy protocols such as IMAP don’t support MFA. All they really need to know is your email pattern and user base (firstname.lastname@domain.com).

The other side of this is access control. There are a lot of generic access groups which don’t provide granular or least privilege access. Because of this, it’s common for a user to be over privileged. It’s important to fully understand who you are granting access and to what account. If the same account they use day to day is granted global admin rights, it becomes a target waiting to be phished. Even with MFA enabled. There are ways to bypass it so be aware.

Separation should be enforced so that your global admin accounts are used for normal activity (mainly email and internet browsing). The risk isn’t just to your environment now, it’s also too your wallet. Attackers could in theory gain access to your environment and start spinning up premium services. If they start a new subscription and restrict access, it would be hard to regain control. If you use Azure active directory, they could also break the connection. If you don’t have a local disaster recovery account, you could be locked out of your own tenant.

Not Securing Credentials

This is like the above point however should be treated separately. Even if you have all the above controls in place, you still need to remember the basics. Applying password policies and trying to stop your users from using P@ssw0rd123.

Their will always be a way into the network, and you can never be sure if the intended security controls have been applied. You may have a conditional access rule for example and apply it to an AD group which “everyone” is apart of. If they aren’t, the rule won’t apply. You might not even apply MFA at all. This means you are allowing single factor authentication and heavily rely on your users setting strong passwords. Things like Azure Password Protect can always help get rid of those common passwords.

Not Securing Applications and Data

The cloud breaks your boundaries and allows you to provide application access over the internet. This often allows you to give you a better solution to your users. This comes at a cost though. There needs to be a balance between security and usability because exposing SaaS to the internet could be your undoing. It gets worse when you are using more traditional model of application servers. If you don’t use 3 or 2 tier models, you could be exposing more than you bargained for. Network security and permissions need to be fully reviewed on a per service basis. This includes all parts and resource group.

On the data side, encryption and access control are key. You may be using brand new services such as S3 buckets and blob storage but you have to be aware of new threats. For example; Blob storage reduces the risk of malware running on file servers as in blob there is no OS layer. This means the risk shifts to the access layer. The focus is then on securing ACLs and the Access keys.

Say you deploy a logon script that maps a network drive with the access key. It’s a great experience for your users and no one needed to do anything. The problem here is that the script contains the access keys. Because of this, it can be stolen. This has already been the downfall for certain companies due to their developers embedding them in clear text. Things like this can be found and there are tools out there that can easily find them.

Encryption should be a default. When possible encrypt the data both at Rest and in Transit. If you do one and not the other, you have to accept the risk. Encryption isn’t applied by default so it’s always best to check what you have enabled.

Not Keeping Good Security Hygiene

The more you utilize the cloud, the more you move away from the original design. Because the cloud isn’t static, you need to be constantly reviewing it. Having strong auditing and compliance tools in place will help with this but it’s always best to review the bigger picture yourself. It’s easy to go off track as new features are being released monthly.

No True Visibility

Auditing isn’t always enabled by default and it’s important to be aware of this. You may have full visibility of your on-premise solution but there are new technologies in play. They may or may not support your current model so it’s best to review this. There are also a lot of tools available that will help you shine a light on those missed places, but they often come with a price tag. Logging and auditing is often forgot and needs to be included in the budget.

No Education Or Lack Of Awareness

Cloud models seem to be forever changing. Your workforce need to be kept up to date and educated. You can’t apply traditional models to the cloud as they simply don’t fit.

It will always be worth training your staff before you utilise the cloud as they will be the ones building and maintaining it. You also want to remove the “false confidence” which may exist. Your team may be experts on-premise, but the cloud is totally different. Everyone will need to go through similar training to remove this risk. The platform and concepts are forever changing so you will need different teams to focus on different areas. It would be impossible for a single team to be aware of the whole platform.

This knowledge will also be required at the top as you will want to avoid ill-informed decisions.

The cloud will be a big part of any organisation nowadays and it’s important that the strategy fits it. Clear guidelines and focus need to be applied else it may end up costing you more in the long run.  

Not Empowering And Educating The Users

IT staff may be the ones configurating your cloud infrastructure and services, but the users are the ones using it. You may be thinking they are accessing it the way you intended but there will be cases where the user finds a new nifty tool. Things like Azure storage explorer or using APIs. It will only take one bad day for them to google alternative ways of doing their job.  If you haven’t got controls in place, they may go unnoticed. It’s best to involve them in the process so that they become aware of the risks.

Password resets are another example. Providing an easy to use tool which allows them to reset their password may reduce risk and calls to your service desk. If the whole process is a nightmare, they will find other means. They may also choose to use easy to remember password which may be less secure. They may do this to avoid having to go through a long winded, bad process.

Offering service like this will benefit both parties in the long run. You can set standard and policies whilst the user gets an easy way to reset their password, should they forget.  

Sticking With The Defaults

This is the scary one as is another main cause of breaches. Remember that the defaults are often focused around usability rather than security.

For example, for storage accounts, the endpoint firewall policies in Azure are “allow all networks” and “allow RDP [Any:Any]” is the default for virtual machines. If someone lifts this on the internet, there is a very high risk that you will be attacked.

This goes the same for all areas such as encryption, network access, IAM and ACLs. The defaults will allow you to spinup a service quickly and use it straight of the bat. If vendors thought of security first, they would have users spin-up a server which they couldn’t then RDP too. Although this would help secure the VM, non-IT people may struggle. This is why I think providers like Microsoft set these risky rules as defaults.

Now that we’ve gone through the basics, we can start to build our foundations. Below covers the different aspects of Azure.

Creating Security Baselines

Securing Storage Accounts

Revoking Third Party Application Access

Blog Posts:

Enumerating O365 Email Address: https://securethelogs.com/2019/12/04/uhoh365-o365-enumeration/

Enumerating Azure Resources:
https://securethelogs.com/zorkazure-enumerating-azure-resources/

Azure goes passwordless:
https://securethelogs.com/azure-goes-passwordless/

More to come…….