Knocking to Microsoft Azure targets
Enterprise usage and adoption of cloud technologies continue to experience tremendous year-over-year increases as the cloud pricing model, implementation flexibility, and ease of adoption are difficult to compete within a world of ever-tightening technology budgets.
According to results of the 2021 Flexera State of the Cloud Report, the Covid-19 pandemic has accelerated cloud adoption in both public and private sectors on a global scale despite cloud adoption challenges centering on ineffective security implementation, governance, and lack of resources needed to securely operate cloud workloads and underlying technology.
This article will briefly focus on some top security challenges within the popular cloud offering from Microsoft Azure, how attackers have or may successfully exploit Azure, enterprise users, and some general recommendations that may increase Azure cloud security.
Table of Contents
According to Azure Solution Architect, Vladimir Stafanovic Multi-Factor Authentication (MFA) bypass and properly managing Azure access credentials is a top security concern and ongoing challenge for organizations leveraging Azure.
Attackers can utilize man-in-the-middle (MITM) and cookie stealing frameworks such as Evilginx2 to develop and execute sophisticated social engineering attacks against Azure users to phish their credentials, bypass MFA via web browser cookie theft and masquerade as enterprise users.
Using features such as "Stay signed In" may allow attackers who compromise credentials via phishing to persist in the account longer than they should (e.g., stolen cookies may persist for up to 60 days!).
So how do attackers know what email address to attack?
- Attackers will perform open-source intelligence (OSINT) gathering activities using various tools such as theHarvester or Hunter.io to discover valid email targets. theHarvester is a command-line tool that ships with penetration testing distributions like Kali Linux, while Hunter.io is an online service used by marketing teams to generate leads. Below is an example of how Hunter.io can quickly discover email addresses for users at the Guardian.
- Azure authentication sites also provide potential attackers some indication as to whether a target domain is a registered Azure tenant simply by manually passing in an email address and inspecting the resulting error messages. The first example shows an example where a fictitious and non-existent domain is supplied with Azure, directly evidencing the domain is not registered.
A second example shows a registered tenant but with an invalid username or password, giving attackers some indication of whether they are pursuing valid targets.
- Once valid email addresses are identified, attacks using tools like Evilginx2 are enabled for success.
Evilginx2 prerequisites require that both a phishing domain is configured by the attacker for victims to visit, capturing their username, password, cookies, etc., along with server resources (AWS EC2, DigitalOcean, etc.) to host and execute Evilginx2 phishing functions.
Sophisticated phishing campaigns can be conducted for less than $20 per month. Evilginx2 provides pre-packaged 'phishlets' which mimic legitimate websites users are accustomed to accessing, such as Office 365, Facebook, etc.
If users enter access credentials on the phishing site, they are captured by Evilginx2 and made visible in clear text to the attackers, who can then impersonate users with full access to their account and resources.
- Using a sample malicious web domain 'evilg-xlctesting.com', Evilginx provides a number of pre-authored 'phishlets' and 'lures' covering several common social media and enterprise technology services users typically interact with like Outlook, Amazon, Okta, Wordpress, etc.
The Office 365 phishing template has been enabled and attached to evilg-xlctesting.com to capture and redirect user credentials back to Evilginx for the attacker to abuse allowing user masquerading, persistence, privilege escalation, and attacks on data.
- A phishing lure is configured for Office 365 along with a redirect URL of office.com that will provide users with a logon website that looks legitimate but is capturing and providing entered credentials to the attacker.
The “sessions [0-10,etc]” command can be used to centrally capture results from all active phishing campaigns and review phished credential results.
- Taking note of the URL, we see our sample malicious website domain listed, but the user is presented with what appears to be a valid Microsoft login prompt. With some imagination and experimentation, attackers can forge legitimate-looking domain names resembling victim organizations and trick users into divulging credentials.
- If victims supply their credentials, Evilginx captures and saves their credentials in table format.
Suppose an MFA token was enabled and also supplied during login. In that case, Evilginx will also capture these values and allow the attacker to re-use MFA tokens for successful authentication, bypassing MFA!
Like Amazon Web Services and its Simple Storage Service (S3), publicly accessible Azure Blob Storage is a primary and ongoing security concern due to unintentional misconfiguration of Blob storage settings.
Using tools like BlobHunter, malicious actors (or security teams!) can quickly scan and enumerate Azure tenants for publicly accessible storage and determine the container permissions and other settings which may allow abuse or data theft to occur.
BlobHunter is a python-based tool that is particularly useful in large enterprise environments that contain large numbers of storage accounts, making a manual inspection of storage settings costly.
BlobHunter scans each tenant, enumerates resource groups, storage accounts, then produces a result file in CSV format detailing each publicly accessible blob storage container along with other details such as the public accessibility levels, URL to access the container, number of files it contains, and even the file formats.
In the above example, BlobHunter was able to successfully locate several public Blob storage containers.
BlobHunter produces a CSV report that details the enumerated Azure subscription, resource groups that house the storage containers, public access levels, and additional information that's useful for planning and focusing future attacks.
Reducing or mitigating publicly accessible Blob storage risks involves multiple controls from the preventive side to detective controls. Within each Azure tenant or subscription where Blob storage is used, setting resource group policies will be effective in preventing or reducing instances where storage containers can be created as a publicly accessible resource.
Once set and this action is attempted, the creation of the resource will be prevented. Detective controls include establishing alerting via Azure Sentinel if intended configurations are altered. Enterprises should also perform routine internal audits using tools such as BlobHunter to identify instances where alerting or resource group management policies are not functioning as expected.
According to security research firm Wiz, an enabled-by-default and misconfigured visualization feature that leverages Jupyter Notebooks was activated by Microsoft in February 2021 that freely allowed privilege escalation from any Jupyter Notebook into other Azure customers Jupyter Notebook allowing extraction of primary keys to Cosmos Databases and blob storage access tokens.
Microsoft disabled the feature in late August 2021, but the customer's database primary keys and other secrets may still be exposed on the public internet. The below graphic demonstrates the attack pattern at a high level.
Attackers leverage the Jupyter notebook public cloud and misconfigurations in the Azure notebook feature to extract and obtain Cosmos Database primary keys and storage secrets. The keys are then used to grant the attacker full, remote administrative rights to Cosmos databases and stored data.)
U.S. Cybersecurity and Infrastructure Security Agency (CISA) recommends that Cosmos DB customers who may have been actively using the notebook service regenerate Cosmos Database keys and other digital secrets used by the database service.
Additionally, it is a recommended security practice to routinely recycle resource authenticators such as database keys, digital certificates, and secrets associated with sensitive systems and data. Enterprises should also adopt Microsoft best practices for securing CosmosDB, which include but are not limited to the implementation of monitoring controls to detect changes to DocumentDB accounts, detect who is accessing database keys and from which locations.
Since Azure threats are not purely technical, but as usually associated with human factors, the following processes are necessary to reduce risks:
- cybersecurity user awareness training,
- Internal phishing campaigns that allow enterprises to measure user responses and increase internal security awareness for tools and techniques such as Evilginx2 are ideal solutions to reduce or mitigate these phishing risks.
Effective cybersecurity awareness training should increase users' ability to identify suspicious web URLs presented in emails, instill behaviors to inspect hyperlinks before they are clicked upon, and question emails requiring urgent action from senders they may not identify with or expect communications from.
Along with that, a business should implement best security practices for whitelistening websites reachable outside of internal proxy and ensure their validation.
This article has covered a very tiny percentage of primary attack targets and an overview of some techniques hackers use to abuse Azure resources and environments.
Appropriate Azure security requires an enhanced level of due diligence in the Cloud adoption era as resource misconfigurations, vendor feature releases, and user susceptibility to social engineering raise the stakes for security risks to levels not seen previously.
Adoption of in-depth and routine security audits of the environments, cybersecurity awareness education, internal phishing campaigns, and internal red teaming exercises against Azure workloads should be strongly considered if not already adopted.