Azure Apps and Attacks practice questions

The application must be configured with a client secret that matches the user's password.

Why it fails: Client secrets are used for confidential client authentication in the OAuth2 flow and are unrelated to the user's personal password. The on-behalf-of flow relies on the trust relationship between the client application and the resource server, not on shared credentials between the user and the client application.

The resource application must explicitly trust the client application's Application ID.

Why it fails: Trust in Microsoft Entra ID is managed through service principals and scopes, not by hardcoding Application IDs into resource applications. The flow requires the client to have obtained a valid access token for the user, which is then presented to the downstream API to request an impersonation token.

The target API must be configured to use Managed Identities instead of Service Principals.

Why it fails: Managed Identities are a mechanism to eliminate credential management for Azure resources but do not replace the OIDC/OAuth2 flow requirements. The on-behalf-of flow is a standard delegated permission mechanism that functions independently of whether the application running the code is using a Managed Identity or a client secret.

Gaining Global Administrator privileges on the target tenant.

Why it fails: The primary goal of consent phishing is to avoid needing administrative privileges. By leveraging user-level consent, an attacker can gain persistent access to mailboxes, files, or contacts without ever triggering an administrative alert or requiring an admin to approve the application registration within the victim's tenant.

Modifying the tenant's Conditional Access policies to allow guest users.

Why it fails: Modifying Conditional Access policies typically requires high-level administrative access. Consent phishing is designed to work within existing security configurations by exploiting the user's own ability to grant consent. Changing tenant-wide policies would likely be detected and is unnecessary for successful execution of this specific attack vector.

Disabling Multi-Factor Authentication for the target users.

Why it fails: Multi-Factor Authentication does not prevent consent phishing because the user is performing a legitimate authentication step. The user grants consent while logged into their own account, meaning they pass all existing MFA requirements, and the attacker simply inherits the permissions granted by that specific user's interaction.

It allows any user in the tenant to access the application without explicit assignment.

Why it fails: Setting this parameter to true directly contradicts this statement. By requiring app role assignments, the application restricts access to only those users or groups that have been specifically granted permission by an administrator, thereby preventing general tenant users from accessing the application's resources without prior authorization.

It automatically grants the User.Read scope to all users in the tenant.

Why it fails: The configuration shown in the exhibit defines required resource access for the Microsoft Graph API, not for user-level permissions. AppRoleAssignmentRequired is an authorization check for the application itself, not a mechanism for granting specific OAuth scopes to users or groups within the directory.

It disables the need for OAuth2 consent for all users.

Why it fails: OAuth2 consent and AppRoleAssignment are two distinct concepts in Microsoft Entra ID. Even if an application requires role assignment, the user may still be prompted for consent if the application requests permissions that have not been granted by an administrator at the tenant level for all users.

/admin/environment

Why it fails: While this looks like a plausible path, Azure Functions do not provide an environment dump endpoint through the standard HTTP trigger interface. The admin endpoints are typically protected by master keys or require specific administrative permissions which are not exposed to standard, unauthenticated HTTP trigger invocations.

/etc/azure/config

Why it fails: This is a fabricated path that does not exist in the default Azure Function runtime environment. Azure stores configuration and secrets in environment variables that are injected by the platform, rather than in configuration files located in the traditional /etc/ directory structure commonly found in standard Linux distributions.

/api/config/secrets

Why it fails: The Azure Function runtime does not expose secrets through a publicly accessible /api endpoint. Secrets are managed by the platform and are only visible at runtime to the application process, not to external callers. Any attempt to access this path would result in a 404 Not Found error.

By querying the Kudu API with the App Service's 'WEBSITE_AUTH_TOKEN'.

Why it fails: The WEBSITE_AUTH_TOKEN is used for internal Kudu authentication and is not a valid OAuth token for the Azure Resource Manager API. Relying on this would fail to provide the necessary authorization headers required by ARM to process the request, as it lacks the correct audience and claims.

By decrypting the 'appsettings.json' file in the root directory.

Why it fails: Appsettings.json typically contains application-specific configuration but does not store OAuth tokens or the secrets required to generate them. The Managed Identity token is generated dynamically by the platform at runtime, meaning there is no static file an attacker could read to obtain a valid access token.

By brute-forcing the application's client secret from the environment variables.

Why it fails: Managed Identities do not use client secrets; they are managed entirely by Microsoft Entra ID. Brute-forcing is not applicable here because the identity is bound to the platform's infrastructure. Attempting to locate non-existent secrets is a waste of resources and will not yield access to the ARM API.

Hardcoding the Application ID in the source code.

Why it fails: While hardcoding an Application ID is a bad practice for modularity, it is not a direct security vulnerability. The Application ID is a public identifier used to reference the application in the directory and does not grant any access or privileges on its own.

Using a self-signed certificate for the application's manifest.

Why it fails: Self-signed certificates are a valid mechanism for authenticating service principals. While they must be managed securely, they are not a 'misconfiguration' in the context of privilege escalation. They are simply an alternative to client secrets for authenticating the application's identity.

It enables anonymous read access to all blob data.

Why it fails: This policy controls authorization for authenticated users or service principals, not the anonymous access setting. Anonymous access is controlled by the storage account's 'AllowBlobPublicAccess' property, not by an IAM/RBAC policy. This policy only affects entities that have been granted access to the account.

It forces the use of HTTPS for all incoming connections.

Why it fails: RBAC policies define access control and permissions, not transport security. The requirement for HTTPS is a global setting on the storage account level. This policy has no impact on whether the connection is forced to use encrypted channels for data transfer.

It restricts access to a specific VNet range.

Why it fails: Network-based restrictions are managed through VNet Rules or Firewall configurations in the storage account's network settings. This policy is an IAM policy, which governs identity-based authorization. It does not contain any conditions or properties related to network IP ranges or VNet identifiers.

Disabling the user's MFA settings in the Azure Portal.

Why it fails: Modifying MFA settings requires administrative privileges that a standard user account will not possess. Attempting this would trigger an audit log and fail, making it an ineffective strategy for a compromised user account. MFA is typically enforced at the tenant level.

Registering a new MFA device on the user's account.

Why it fails: Registering a new MFA device typically requires an existing MFA challenge to be satisfied or administrative intervention. If the attacker has enough access to register a device, they have effectively already bypassed MFA, but this is less common than session token theft.

Injecting a malicious password hash into the directory.

Why it fails: Microsoft Entra ID stores hashes securely, and an attacker cannot modify them directly. Password hash synchronization is a one-way process. This is a misunderstanding of how the authentication infrastructure works; the attacker is focused on session persistence, not credential modification.

Scanning the 'AppService' source code for hardcoded passwords.

Why it fails: Scanning source code for passwords is a standard security practice, but it does not identify Microsoft Entra ID application permissions. Application permissions are handled by the Microsoft Entra ID service and are not reflected in the application's source code files or configuration files.

Analyzing the Azure Activity Logs for login events.

Why it fails: Azure Activity Logs track user and service logins, not the specific permissions assigned to an application. While these logs can show which apps are used, they do not provide the granular detail needed to evaluate whether the app's permissions are excessive for its function.

Checking the storage account's access keys for the application.

Why it fails: Storage account access keys are unrelated to Microsoft Entra ID application permissions. Checking them is a valid security audit step for storage, but it fails to provide any insight into the permissions or OAuth2 scopes that an application might have been granted within Microsoft Entra ID.

The IMDS endpoint requires a client secret to validate the request.

Why it fails: The IMDS endpoint is designed to provide tokens without requiring a client secret, as it validates the identity based on the caller's residency on the Azure infrastructure. Requiring a secret would defeat the purpose of the Managed Identity, which is to eliminate credential management for Azure resources.

The IMDS endpoint is only reachable from within a VNet.

Why it fails: The IMDS endpoint at 169.254.169.254 is a link-local address available on every Azure VM regardless of VNet configuration. It is an infrastructure-level service that is accessible as long as the VM is running and the code is executing on that VM's local host.

The Microsoft Entra ID tenant disables Managed Identity by default.

Why it fails: Managed Identity is a core feature of Azure and is enabled by default at the platform level. It is not something that can be disabled at the tenant level. The security control here is not the identity itself, but the permissions assigned to that identity by the administrator.

Decrypting the application's Web.config file to retrieve the plaintext password associated with the system-assigned managed identity principal.

Why it fails: System-assigned managed identities have no password stored in Web.config; the platform issues short-lived tokens via the instance metadata endpoint. Credential harvesting from configuration files is tempting from traditional connection-string attacks, and would suit apps using SQL logins rather than managed identity.

Extracting the master certificate from the local machine certificate store to forge administrative Kerberos tickets for the Azure domain.

Why it fails: Managed identities use certificate-based authentication brokered by Microsoft Entra ID, not Kerberos domain tickets, and App Service exposes no such local certificate store to forge them. Certificate theft is tempting from on-premises AD attacks, where forging tickets against a domain controller is viable.

Initiating a brute-force attack against the Azure Resource Manager public API using the public application ID found in the portal overview.

Why it fails: The application ID is a public identifier, not a secret, and brute-forcing Resource Manager cannot authenticate without valid credentials or tokens. Credential brute-forcing is tempting against weak password authentication, and would suit exposed login endpoints, not token-based managed identity flows.

Retrieve the managed identity's client secret from the App Service configuration settings.

Why it fails: This is incorrect because system-assigned managed identities do not use client secrets. They rely on the IMDS or the App Service token endpoint with the IDENTITY_HEADER. There is no client secret stored in configuration settings. Attempting to find one would be futile.

Call the Microsoft Graph API to generate an access token for the managed identity.

Why it fails: This is incorrect because Microsoft Graph is not used to generate tokens for managed identities. The token must be obtained from the local token endpoint (IDENTITY_ENDPOINT) or IMDS. Microsoft Graph is a resource that can be accessed with a token, but it does not issue tokens for managed identities.

Use the Azure CLI command 'az login --identity' to authenticate and retrieve the token.

Why it fails: This is incorrect because 'az login --identity' is a legitimate administrative command that requires the Azure CLI to be installed and may not be available on a compromised App Service. The attacker can directly call the token endpoint via HTTP, which is simpler and does not rely on CLI tools. The CLI method is not a required step.

az keyvault secret show --vault-name <vault-name> --name <secret-name> --subscription <subscription-id>

Why it fails: This command uses the Azure CLI's default authentication context, which typically relies on the signed-in user or service principal, not the managed identity token you obtained. It would fail unless the CLI is authenticated with appropriate credentials. It does not explicitly use the managed identity token, so it is not the correct method in this scenario.

Invoke-RestMethod -Uri "https://<vault-name>.vault.azure.net/secrets/<secret-name>?api-version=7.2" -Headers @{Authorization="Bearer <token>"}

Why it fails: While this PowerShell command could work, it is not the most common or direct method in a penetration testing context where you might be on a Linux-based attack platform. The curl command is more universally available and simpler. However, both could work if the token is valid; but the scenario likely expects the curl approach as it is standard in many Azure exploitation tools.

az login --identity --username <client-id> && az keyvault secret show --vault-name <vault-name> --name <secret-name>

Why it fails: This attempts to log in using the managed identity's client ID, but if you already have a token, this is unnecessary and may fail if the identity is not assigned to the current environment. Moreover, it requires the Azure CLI to be installed and configured, which might not be the case on an attacker's machine. It is not the direct method to use the token.

Extract the storage account key from the App Service's application settings and use it to access the storage account.

Why it fails: Storage account keys are not automatically present in App Service application settings. They would need to be manually configured. The managed identity provides access without keys, so this method is not applicable and would likely fail unless the key was explicitly stored.

Retrieve the storage account's connection string from the Azure Key Vault that the App Service is configured to access.

Why it fails: The scenario does not state that the App Service has access to a Key Vault or that a connection string is stored there. Assuming this is speculative. The managed identity's direct role assignment on the storage account is the intended path, not a Key Vault detour.

Use the Azure CLI command 'az storage blob download' from the App Service's Kudu console, authenticating with the managed identity.

Why it fails: While the Azure CLI can authenticate with a managed identity using 'az login --identity', the Kudu console may not have the Azure CLI installed, and this method is less direct than using IMDS. It also requires the CLI to be available, which is not guaranteed.

Use the managed identity's client ID and client secret to connect to the database.

Why it fails: Managed identities do not have a client secret that can be retrieved. They use certificate-based authentication internally. Attempting to use a client secret will fail because none is available. The correct method is to use the identity's token.

Assign the managed identity to an Microsoft Entra ID group that has access to the database, then use the group's credentials.

Why it fails: While you can assign a managed identity to a group, you cannot use the group's credentials directly. Authentication still requires a token for the managed identity. The group membership grants permissions, but the authentication mechanism remains token-based.

Configure the database firewall to allow the App Service's outbound IP address and use SQL authentication with a username and password.

Why it fails: This method uses SQL authentication, not the managed identity. It requires storing a username and password, which defeats the purpose of using a managed identity. The scenario specifically asks for using the managed identity, so this is incorrect.

Use the Azure CLI command 'az login --identity' from the attacker's workstation to authenticate as the managed identity.

Why it fails: The 'az login --identity' command is used to authenticate using a managed identity, but it must be run from within the Azure resource (e.g., the VM) that has the managed identity assigned. From an external workstation, this command will fail because the identity is not available. The attacker would need to execute commands on the VM itself, which may not be possible with only read access to the identity's properties.

Call the Microsoft Graph API endpoint '/servicePrincipals' to generate an access token for the managed identity.

Why it fails: The Microsoft Graph API '/servicePrincipals' endpoint is used to manage service principal objects, not to generate access tokens. Access tokens are obtained through OAuth 2.0 token endpoints or the IMDS. Using Graph API to generate a token for a managed identity is not a supported operation and would not yield a usable token for Key Vault access.

Retrieve the managed identity's client secret from the Microsoft Entra ID application registration and use it with the OAuth 2.0 client credentials flow.

Why it fails: Managed identities do not have client secrets that can be retrieved. They are a special type of service principal managed by Azure, and their credentials are handled internally by the platform. Attempting to find a client secret will fail because it does not exist. The client credentials flow requires a secret or certificate, which is not applicable here.

http://169.254.169.254/metadata/v1/identity/oauth2/token

Why it fails: The path /metadata/v1/identity/oauth2/token is incorrect. The correct path is /metadata/identity/oauth2/token. Adding 'v1' will result in a 404 error. Precision in the endpoint path is crucial; otherwise, the request will fail. This is a common mistake when trying to exploit IMDS.

http://localhost:8080/msi/token

Why it fails: There is no standard endpoint at localhost:8080/msi/token for managed identity tokens in Azure App Service. The correct endpoint is the IMDS at 169.254.169.254. Using localhost might target the application itself, but not the token service. This endpoint is not recognized by Azure and would not return a token.

http://[::ffff:169.254.169.254]/metadata/identity/oauth2/token

Why it fails: While IPv6-mapped IPv4 addresses like [::ffff:169.254.169.254] may resolve to the same address, the IMDS endpoint typically expects IPv4. Some environments may not support IPv6 for IMDS. The standard and reliable method is to use the IPv4 address directly. Using this format might work in some cases but is not the primary method and could be blocked.

Use the Azure CLI 'az ad sp credential reset' command to reset the service principal's credentials.

Why it fails: The 'az ad sp credential reset' command resets the credentials of a service principal, which would invalidate existing credentials and create new ones. However, this command requires high privileges and is not the same as adding a new credential. It also might disrupt existing services. The attacker would typically use the Graph API to add a new password without resetting, to maintain stealth.

Assign the 'Global Administrator' role to the attacker's user account.

Why it fails: Assigning the Global Administrator role requires high privileges and is not necessary for this attack. The goal is to escalate by using the service principal's existing permissions, not by granting roles to the attacker's account. This step would be detected and is not part of the typical escalation via service principal credential addition.

Modify the service principal's application registration to add a new redirect URI.

Why it fails: Adding a redirect URI is not required to authenticate as the service principal using a client secret. Redirect URIs are used for interactive flows, not for client credentials flow. This step would not help the attacker gain access and could introduce unnecessary changes that might be logged.

Conditional Access policy for guest users.

Why it fails: Conditional Access policies are used to enforce authentication requirements like MFA or device compliance. They are not designed to restrict directory-level object visibility or read operations, which are controlled by the Global Tenant settings for external identities.

The 'Enable Global Reader' role for guests.

Why it fails: The Global Reader role is a powerful administrative role that provides read-only access to all directory information. Assigning this to guests would significantly increase the impact of a compromise rather than remediating it. It is the opposite of the intended security goal.

The 'AppRoleAssignmentRequired' property of the tenant.

Why it fails: This property applies to individual application service principals and does not govern directory-wide visibility for guest users. It is a tool for application-level access control, not a mechanism for managing the broader visibility settings of the Microsoft Entra ID directory itself.

The attacker can use the Client ID to authenticate as the application.

Why it fails: A Client ID is not a secret; it is merely an identifier. Authentication requires a client secret or a certificate, which are never exposed publicly. Knowing the Client ID does not grant the attacker the ability to impersonate the application in a service-to-service flow.

The attacker can use the Client ID to reset the application's password.

Why it fails: Resetting credentials requires administrative access to the Azure tenant. There is no mechanism within the Microsoft Entra ID framework that allows for password or secret resets based solely on the knowledge of the Application ID. This is a common misconception about the level of access a Client ID provides.

The attacker can use the Client ID to bypass MFA for the application.

Why it fails: MFA is tied to the user's account and the tenant's security policy, not to the application identifier. Knowledge of a Client ID does not interact with the authentication stack in a way that would bypass MFA requirements, as authentication is a separate process from application identification.