App Service Exploitation and Credentials Extraction

Extracting credentials from App Service

Cited from: Penetration Testing Azure for Ethical Hackers Book by David Okeyode and Karl Fosaaen

Steps:

1) Authenticate to Contributor user/role account

Connect-AzAccount 

2) Collect credentials from publish profile

Get-AzWebAppPublishingProfile 

3) Dump credentials for App Service

Get-AzPasswords -AutomationAccounts N -StorageAccounts N -Keys N -ACR N -CosmosDB N -Verbose | Out-GridView 

• When prompted to select an Azure subscription, select your test Azure subscription and click OK

• In the resulting output, you should see credentials that were dumped from the App Service configurations

Now that we have access to the app service publish profile, we will see how these credentials can be used with the application.

Lateral Movement, escalation and persistence in App Service

After gathering credentials from an App Service publish profile, we have a few options for persisting, moving laterally, and/or escalating privileges. First things first, we will want to review the application files for any credentials that may be stored in existing configuration files or application code from previous deployments. The easiest way to do this is by connecting to the FTP server associated with the application. You can obtain the FTP server endpoint in the Azure portal (App Service  Deployment Center  FTP Credentials). You can also obtain the endpoint using the Azure CLI by running the following command:

az webapp deployment list-publishing-profiles --name APP_NAME --resource-group GROUP_NAME --query "[? ends_with(profileName, 'FTP')].{profileName: profileName, publishUrl: publishUrl}"

You can then connect using an FTP client. If you don't have a preferred FTP client, you can always use the Windows explorer with an FTP:// path.

At this point, we can also upload a web shell that would allow persistent access to the application server, and it would allow us to run commands to generate tokens for any attached managed identities. If you go this route, make sure that you use a web shell that you trust and password-protect the web shell to prevent other attackers from getting access to your shell.

As an alternative to web shells, it is possible to run commands on the App Service server from the portal, in the Console section.

This interface is convenient, but it does require you to be authenticated to Azure AD as a Contributor.

Finally, there is an alternative management interface that can be used for managing the application. This interface can be found under the $APP_NAME.scm. azurewebsites.net subdomain, instead of the main App Service URL ($APP_NAME.azurewebsites.net).

This interface is the Kudu (https://github.com/projectkudu/kudu) service, which can allow for a number of different attack options. This interface has CMD and PowerShell consoles, a file browser, and exports of all the environmental settings and variables.

Additionally, this interface is available without authenticating to Azure AD. By accessing the affected site on the https://$APP_NAME.scm.azurewebsites.net/basicauth page, you can just enter the credentials from the publish profile. This is really handy if you need to regain access to a subscription.