Detect Trusted Relationship in Splunk
Adversaries may breach or otherwise leverage organizations who have access to intended victims. Access through trusted third-party relationships abuses an existing connection that may not be protected or receives less scrutiny than standard mechanisms of gaining access to a network. Organizations often grant elevated access to second or third-party external providers in order to allow them to manage internal systems as well as cloud-based environments. These relationships include IT services contractors, managed security providers, and infrastructure contractors. In Office 365 and Azure AD environments, organizations may grant Microsoft partners or resellers delegated administrator permissions. By compromising a partner or reseller account, an adversary may be able to leverage existing delegated administrator relationships or send new delegated administrator offers to clients in order to gain administrative control over the victim tenant.
MITRE ATT&CK
- Tactic
- Initial Access
- Technique
- T1199 Trusted Relationship
- Canonical reference
- https://attack.mitre.org/techniques/T1199/
SPL Detection Query
// Detect trusted relationship abuse via Office 365 delegated admin grants and external service account logons
(
sourcetype="o365:management:activity"
(Operation="Add-RoleGroupMember" OR Operation="New-ManagementRoleAssignment" OR
Operation="Add member to role." OR Operation="Consent to application." OR
Operation="Add delegated permission grant." OR Operation="Add app role assignment to service principal.")
| eval EventCategory="DelegatedPermissionGrant"
| eval ActorUPN=coalesce(UserId, Actor{}.ID)
| eval TargetResource=coalesce(ObjectId, ModifiedProperties{}.NewValue)
| eval SourceIP=ClientIP
| table _time, EventCategory, Operation, ActorUPN, SourceIP, TargetResource, ResultStatus, OrganizationId
)
| append
[
search sourcetype="o365:management:activity"
(Operation="UserLoggedIn" OR Operation="UserLoginFailed")
UserType=4
| eval EventCategory="ExternalUserAccess"
| eval ActorUPN=UserId
| eval SourceIP=ClientIP
| eval TargetResource=Workload
| eval IsAdmin=if(match(ActorUPN, "(?i)(admin|svc|msp|partner|vendor|managed)"), 1, 0)
| where IsAdmin=1 OR UserType=4
| table _time, EventCategory, Operation, ActorUPN, SourceIP, TargetResource, ResultStatus, UserType
]
| append
[
search index=wineventlog sourcetype="WinEventLog:Security" EventCode=4624
LogonType=3 NOT (SourceNetworkAddress="10.*" OR SourceNetworkAddress="172.16.*" OR
SourceNetworkAddress="172.17.*" OR SourceNetworkAddress="172.18.*" OR
SourceNetworkAddress="172.19.*" OR SourceNetworkAddress="172.20.*" OR
SourceNetworkAddress="172.21.*" OR SourceNetworkAddress="172.22.*" OR
SourceNetworkAddress="172.23.*" OR SourceNetworkAddress="172.24.*" OR
SourceNetworkAddress="172.25.*" OR SourceNetworkAddress="172.26.*" OR
SourceNetworkAddress="172.27.*" OR SourceNetworkAddress="172.28.*" OR
SourceNetworkAddress="172.29.*" OR SourceNetworkAddress="172.30.*" OR
SourceNetworkAddress="172.31.*" OR SourceNetworkAddress="192.168.*" OR
SourceNetworkAddress="127.*" OR SourceNetworkAddress="::1" OR SourceNetworkAddress="-")
| eval IsSvcAccount=if(match(TargetUserName, "(?i)(svc_|_svc|admin|mgmt|msp|vendor)"), 1, 0)
| where IsSvcAccount=1
| eval EventCategory="ExternalServiceAccountNetworkLogon"
| eval ActorUPN=TargetUserName
| eval SourceIP=SourceNetworkAddress
| eval TargetResource=ComputerName
| table _time, EventCategory, ActorUPN, SourceIP, TargetResource, TargetDomainName, LogonType
]
| eval SuspicionIndicators=0
| eval SuspicionIndicators=SuspicionIndicators + if(EventCategory="DelegatedPermissionGrant", 2, 0)
| eval SuspicionIndicators=SuspicionIndicators + if(EventCategory="ExternalUserAccess", 1, 0)
| eval SuspicionIndicators=SuspicionIndicators + if(EventCategory="ExternalServiceAccountNetworkLogon", 1, 0)
| eval SuspicionIndicators=SuspicionIndicators + if(match(ActorUPN, "(?i)(admin|global.admin|privileged)"), 1, 0)
| eval SuspicionIndicators=SuspicionIndicators + if(ResultStatus="Failed" OR ResultStatus="Failure", 1, 0)
| where SuspicionIndicators > 0
| sort - SuspicionIndicators, - _time
| table _time, EventCategory, Operation, ActorUPN, SourceIP, TargetResource, SuspicionIndicatorsDetects trusted relationship abuse using three data sources: (1) Office 365 Management Activity logs for delegated permission grants, role assignments, and application consent operations that indicate new MSP/partner relationship establishment; (2) O365 external user logon events (UserType=4) for accounts with service/admin/MSP naming patterns accessing cloud workloads; (3) Windows Security EventCode 4624 LogonType=3 (network logon) for service accounts with MSP/vendor naming patterns authenticating from external IP addresses. A suspicion scoring system weights events by category and additional risk indicators. Requires the o365:management:activity add-on and Windows Security log forwarding to Splunk.
Data Sources
Required Sourcetypes
False Positives & Tuning
- Legitimate MSP onboarding creating new delegated admin grants — coordinate with IT management to build an allowlist of expected partner tenant IDs
- Authorized service accounts from managed service providers performing scheduled maintenance over the network from their management IP ranges
- Microsoft partner accounts with existing authorized GDAP or DAP relationships accessing tenant resources as part of contracted support
- MSSP/MDR provider accounts logging into Office 365 security portals as part of a 24/7 monitoring engagement
- Vendor or contractor accounts with B2B guest access accessing SharePoint or Teams for authorized project collaboration
Other platforms for T1199
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1 Simulate Delegated Admin Permission Grant via Azure AD PowerShell
Expected signal: Azure AD AuditLogs: OperationName 'Add delegated permission grant', Result 'success', InitiatedBy.user.userPrincipalName = executing account, TargetResources[0].displayName = 'Microsoft Graph'. Visible in Microsoft 365 compliance portal under Audit search with Activity = 'Add delegated permission grant'.
- Test 2 Assign Privileged Role to External Guest Account Simulating MSP Onboarding
Expected signal: Azure AD AuditLogs: OperationName 'Add member to role', Result 'success', TargetResources[1].displayName = 'Global Reader', TargetResources[0].userPrincipalName contains '#EXT#'. Also generates 'Invite external user' event. Both visible in AuditLogs table within 5-10 minutes.
- Test 3 Simulate MSP Network Logon from External IP Using Service Account
Expected signal: Windows Security Event ID 4624: LogonType=3 (Network), TargetUserName='svc_msp_test', SourceNetworkAddress=127.0.0.1. Security Event ID 4672 if the account has elevated privileges. Visible in Windows Event Viewer under Security log within seconds of execution.
- Test 4 Create New Service Principal and Grant API Permissions Simulating Post-Access Backdoor
Expected signal: Azure AD AuditLogs: OperationName 'Add application', Result 'success', TargetResources[0].displayName = 'df00tech-detection-test-app'. Followed by OperationName 'Update application' with ModifiedProperties showing RequiredResourceAccess including Mail.Read scope. Both events include InitiatedBy.user.userPrincipalName of the executing account.
References (8)
- https://attack.mitre.org/techniques/T1199/
- https://us-cert.cisa.gov/APTs-Targeting-IT-Service-Provider-Customers
- https://support.microsoft.com/en-us/topic/partners-offer-delegated-administration-26530dc0-ebba-415b-86b1-b55bc06b073e
- https://www.microsoft.com/security/blog/2021/10/25/nobelium-targeting-delegated-administrative-privileges-to-facilitate-broader-attacks/
- https://www.secureworks.com/research/revil-sodinokibi-ransomware
- https://learn.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-audit-activities
- https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/security-operations-privileged-accounts
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1199/T1199.md
Response Playbook
Triage
- Identify the account that initiated or used the trusted relationship: check whether the UPN belongs to an internal employee, a known MSP service account, or an external partner tenant. Query AuditLogs: summarize by InitiatorUPN, category, and result to see scope of activity in the past 72 hours.
- Verify the relationship legitimacy: check with IT management and procurement whether this MSP/partner/contractor relationship exists in the official vendor registry. Ask specifically: Was a formal onboarding ticket or change request created? What is the contracted scope of access?
- Review what actions were performed under the trusted relationship: pull AuditLogs filtered by CorrelationId or session, OfficeActivity filtered by UserId, and DeviceLogonEvents filtered by AccountName for the suspicious account. Focus on mailbox access, file downloads, role changes, and new service principal creation.
- Check the geolocation and ASN of the source IP: does it match the MSP's known data center ranges or offices? Use the IP in threat intelligence feeds to determine if it's associated with known malicious infrastructure. A VPN or datacenter exit from an unusual country is a strong indicator of compromise.
- Assess privilege level: what roles or permissions does the third-party account hold? Global Administrator, Exchange Administrator, or Security Administrator access from an MSP account that has been compromised gives adversaries full tenant control. Determine the blast radius immediately.
- Check for delegated admin abuse indicators: in AuditLogs, look for 'Add partner to cross-tenant access setting' or 'Add delegated permission grant' operations immediately preceding the suspicious sign-in. This pattern suggests the adversary established their own access path after compromising the MSP.
- Look for lateral movement from MSP-managed systems: if the MSP has RMM (Remote Monitoring and Management) tools installed on endpoints (e.g., ConnectWise, Kaseya, Datto), check DeviceProcessEvents for unusual processes spawned by RMM agents, and DeviceNetworkEvents for beaconing from those processes.
Containment
- Immediately revoke the compromised third-party account's access tokens and sessions: in Azure AD, navigate to Users > [account] > Revoke sessions. For MSP delegated admin relationships, remove the delegated admin relationship via the Microsoft 365 Admin Center under Settings > Partner relationships.
- Disable or block the source IP range at the firewall and conditional access level: create an Azure AD Named Location for the suspicious IP(s) and add a Conditional Access policy blocking sign-ins from those locations to all cloud apps. For on-premises, block the range at the perimeter firewall.
- If Global Administrator or equivalent privilege was abused: rotate all service principal credentials and OAuth tokens immediately. Audit all Conditional Access policies, federation settings, and external identity configurations for backdoors added during the attack window.
- Isolate any on-premises endpoints that the MSP's RMM tool has agent access to, particularly if the RMM platform (Kaseya, ConnectWise, SolarWinds) was the vector. Use EDR isolation on affected endpoints until RMM agent integrity is verified.
- Notify the MSP/third-party provider of the suspected compromise: they may have other customers affected. Coordinate with them to reset all service account credentials and review their own environment for indicators of compromise.
- Preserve all audit logs before rotating credentials: export AuditLogs, SigninLogs, and OfficeActivity for the attack timeframe to an immutable storage location (e.g., Azure Immutable Blob Storage) to support forensic investigation and potential legal action.
Evidence Collection
- Azure AD AuditLogs for the past 30 days filtered by the compromised account UPN and all accounts in the same partner tenant — captures every privileged action taken under the trusted relationship
- Azure AD SigninLogs for all successful and failed sign-ins by the third-party account — provides geolocation, device fingerprint, and access patterns over time
- Office 365 Unified Audit Log (UAL) — accessed via Microsoft Purview Compliance portal or Exchange PowerShell: Search-UnifiedAuditLog — for mailbox access, file downloads, SharePoint activity, and Teams messages read by the external account
- Microsoft Cloud App Security (Defender for Cloud Apps) activity logs — if deployed, provides richer session context including specific file and data accessed under the third-party account
- Azure Resource Manager Activity Logs — if the MSP had Azure subscription access, review via the Azure Monitor Activity Log blade for resource creation, deletion, policy changes, or role assignments
- RMM agent logs and management console audit trails from the MSP's tooling (ConnectWise Automate, Kaseya VSA, Datto RMM) — shows what scripts were executed on managed endpoints
- Network flow data or firewall logs from the perimeter showing connections from the MSP's IP ranges in the days preceding the incident — establishes a baseline of normal access timing and volume to identify anomalies
- Endpoint memory and disk forensics on any systems the RMM agent touched — collect process memory dump if malicious tools were deployed, and check for persistence mechanisms in startup locations, scheduled tasks, and WMI subscriptions
Escalation Criteria
- !Evidence that the trusted relationship was used to establish a backdoor: new service principal created, new Conditional Access exclusion added, federation trust modified, or emergency access account created by the external account
- !Data exfiltration indicators: large volume SharePoint/OneDrive downloads, bulk mailbox exports, or Azure Storage blob access from the third-party account — especially to IPs outside the MSP's known infrastructure
- !Lateral movement from MSP-managed endpoints to non-MSP-managed systems: DeviceLogonEvents showing the MSP service account authenticating to domain controllers, sensitive file servers, or backup infrastructure
- !Multiple customer environments affected: if this is an MSP compromise, the same malicious patterns may appear across multiple tenants managed by the same partner — coordinate with MSSP/CISA if this is confirmed
- !Privileged identity infrastructure tampered with: changes to Azure AD PIM (Privileged Identity Management) settings, removal of MFA requirements for privileged roles, or new emergency access accounts without MFA
- !Evidence of supply chain extension: the third-party account was used to access your software build systems, code repositories, or deployment pipelines — indicating possible intent to compromise your own customers
Investigation Guide
Related Techniques
Forensic Artifacts
- >
Azure AD AuditLogs: OperationName 'Add delegated permission grant' or 'Add partner to cross-tenant access setting' — records the exact timestamp and actor that established the trusted relationship - >
Azure AD SigninLogs: CrossTenantAccessType field — differentiates B2B collaboration, B2B direct connect, and Microsoft Support access types for external accounts - >
Microsoft 365 Admin Center: Settings > Partner relationships — lists all active DAP (Delegated Admin Privileges) and GDAP (Granular Delegated Admin Privileges) relationships with partner tenant IDs and assigned roles - >
Office 365 Unified Audit Log: WorkloadName=AzureActiveDirectory, Operations related to role assignment and permission grants — provides 90-day retention of privileged operations - >
Azure Activity Log: Authorization/roleAssignments/write events — captures RBAC role assignments made to service principals or external accounts on Azure subscriptions - >
RMM agent installation artifacts on endpoints: registry keys at HKLM\SOFTWARE\[RMM Vendor], installed service entries in services.msc, and scheduled tasks created by the RMM agent - >
Windows Security EventID 4648 (Explicit Credential Use) on domain-joined machines — logged when MSP accounts use explicit credentials to connect to internal systems - >
Azure AD Application Registration audit trail: app registrations and service principals created or modified by external accounts — check for applications with Mail.Read, Files.ReadWrite.All, or Directory.ReadWrite.All permissions
Tuning Guidance
The primary tuning challenge for T1199 is distinguishing legitimate MSP/partner activity from abuse. Build a Named Locations list in Azure AD Conditional Access containing all documented MSP and vendor IP ranges, then add this to the KQL query as an exclusion for the baseline AlertLevel. Maintain a partner registry (ideally in a CMDB or ticketing system) mapping each partner's Azure AD tenant ID to their contracted scope of access and allowed IP ranges — use this to create allowlist conditions in your detection. For the AuditLogs query, filter out operations matching known change ticket windows (correlate with ITSM system via ServiceNow integration or Sentinel Playbook). For the DeviceLogonEvents hunting query, build an exclusion list of documented MSP management IP CIDR ranges extracted from vendor contracts. Time-of-day analysis is valuable here: MSP access outside contracted business hours or outside agreed maintenance windows should have lower threshold for alerting. Consider integrating DMARC/DKIM/SPF data — phishing-based MSP compromise often precedes the trusted relationship abuse, so email threat intelligence can provide early warning.
Hunting Queries
Hunt for all privileged administrative actions performed by external or guest accounts (UserType=4, #EXT# UPN pattern) over the past 30 days. A high action count from an external account that is not part of a documented change window is a strong indicator of MSP account compromise or unauthorized third-party access. The 30-day window captures dwell time common in trusted relationship attacks.
// Hunt for all privileged actions performed by external/guest accounts across the tenant
AuditLogs
| where TimeGenerated > ago(30d)
| extend ActorUPN = tostring(InitiatedBy.user.userPrincipalName)
| extend ActorTenantId = tostring(InitiatedBy.user.tenantId)
| where ActorUPN contains "#EXT#" or ActorTenantId != tostring(parse_json(tostring(AdditionalDetails))["tenantId"])
| where Category in ("RoleManagement", "ApplicationManagement", "Policy", "ProvisioningManagement")
| where Result =~ "success"
| summarize
ActionCount = count(),
UniqueOperations = dcount(OperationName),
Operations = make_set(OperationName, 20),
Earliest = min(TimeGenerated),
Latest = max(TimeGenerated)
by ActorUPN, ActorTenantId, Category
| where ActionCount > 0
| sort by ActionCount descsourcetype="o365:management:activity" UserType=4
(RecordType="AzureActiveDirectory" OR RecordType="AzureActiveDirectoryAccountLogon" OR RecordType="ExchangeAdmin")
| eval ActorUPN=UserId
| eval IsPrivilegedOp=if(match(Operation, "(?i)(role|permission|grant|assign|admin|policy|delete|remove|update)"), 1, 0)
| where IsPrivilegedOp=1
| stats count as ActionCount, dc(Operation) as UniqueOps, values(Operation) as OperationList, earliest(_time) as Earliest, latest(_time) as Latest by ActorUPN, OrganizationId
| sort - ActionCountHunt for privileged administrative actions (new service principals, OAuth consent, delegated permission grants) performed by external accounts within 60 minutes of a successful cross-tenant sign-in. This temporal correlation identifies the 'foothold-then-establish-persistence' pattern typical of MSP account compromise where attackers quickly add backdoor applications or permissions before their access window closes.
// Hunt for new service principals or OAuth app grants created shortly after an MSP cross-tenant sign-in
let ExternalSignins = SigninLogs
| where TimeGenerated > ago(30d)
| where CrossTenantAccessType != "none" and ResultType == 0
| project SigninTime = TimeGenerated, ExternalUser = UserPrincipalName, SourceIP = IPAddress;
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName in ("Add service principal", "Add application", "Consent to application.", "Add delegated permission grant")
| where Result =~ "success"
| extend ActorUPN = tostring(InitiatedBy.user.userPrincipalName)
| extend TargetName = tostring(TargetResources[0].displayName)
| join kind=inner (
ExternalSignins
| extend JoinKey = ExternalUser
) on $left.ActorUPN == $right.ExternalUser
| where abs(datetime_diff('minute', TimeGenerated, SigninTime)) < 60
| project TimeGenerated, OperationName, ActorUPN, TargetName, SourceIP, SigninTime, CorrelationId
| sort by TimeGenerated descsourcetype="o365:management:activity" UserType=4 Operation="UserLoggedIn" ResultStatus="Succeeded"
| eval ExternalUser=UserId
| eval LoginTime=_time
| join type=inner ExternalUser
[search sourcetype="o365:management:activity"
(Operation="Add-RoleGroupMember" OR Operation="New-ManagementRoleAssignment" OR
Operation="Consent to application." OR Operation="Add delegated permission grant.")
| eval ExternalUser=UserId
| eval PrivAction=Operation]
| eval TimeDiff=abs(LoginTime - _time)
| where TimeDiff < 3600
| table _time, ExternalUser, PrivAction, ClientIP, OrganizationId, TimeDiff
| sort TimeDiffHunt for service or contractor accounts matching common MSP/vendor naming patterns (svc_, msp, managed, vendor, contractor) authenticating via network logon from public IP addresses. Legitimate MSP access should originate from known, documented IP ranges. Logins from public IPs not matching documented MSP network ranges may indicate stolen credentials being used by an adversary who has compromised the MSP but is not operating from the MSP's infrastructure.
// Hunt for DeviceLogonEvents where service accounts matching MSP/contractor patterns authenticate from external IP ranges
DeviceLogonEvents
| where Timestamp > ago(14d)
| where LogonType in ("Network", "RemoteInteractive")
| where ActionType == "LogonSuccess"
| where AccountName matches regex @"(?i)(svc_|_svc|msp|managed|vendor|contractor|remote|support|helpdesk|admin)"
| extend IsPublicIP = not(ipv4_is_private(RemoteIP))
| where IsPublicIP == true
| summarize
LogonCount = count(),
UniqueDevices = dcount(DeviceName),
Devices = make_set(DeviceName, 10),
UniqueSourceIPs = dcount(RemoteIP),
SourceIPs = make_set(RemoteIP, 10),
Earliest = min(Timestamp),
Latest = max(Timestamp)
by AccountName, AccountDomain
| where LogonCount > 2
| sort by LogonCount descindex=wineventlog sourcetype="WinEventLog:Security" EventCode=4624 LogonType=3
NOT (SourceNetworkAddress="10.*" OR SourceNetworkAddress="172.16.*" OR SourceNetworkAddress="192.168.*" OR SourceNetworkAddress="127.*" OR SourceNetworkAddress="-" OR SourceNetworkAddress="::1")
| eval IsMSPAccount=if(match(TargetUserName, "(?i)(svc_|_svc|msp|managed|vendor|contractor|remote|support|helpdesk)"), 1, 0)
| where IsMSPAccount=1
| stats count as LogonCount, dc(ComputerName) as UniqueDevices, values(ComputerName) as DeviceList, dc(SourceNetworkAddress) as UniqueSourceIPs, values(SourceNetworkAddress) as SourceIPList, earliest(_time) as Earliest, latest(_time) as Latest by TargetUserName, TargetDomainName
| where LogonCount > 2
| sort - LogonCountAtomic Red Team Tests
Creates a delegated permission grant in Azure AD simulating an MSP or partner being granted delegated access to manage the tenant. This replicates the administrative action an adversary would take after compromising a partner account that already has delegated admin access — establishing new or expanded OAuth permissions. Requires AzureAD or Microsoft.Graph PowerShell module and an account with Privileged Role Administrator rights.
Command
# Install module if needed: Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "Application.ReadWrite.All","DelegatedPermissionGrant.ReadWrite.All"
# List existing service principals to find target
$sp = Get-MgServicePrincipal -Filter "displayName eq 'Microsoft Graph'" | Select-Object -First 1
# Create delegated permission grant for current user (simulates partner access grant)
$params = @{
ClientId = (Get-MgContext).ClientId
ConsentType = "AllPrincipals"
ResourceId = $sp.Id
Scope = "User.Read Directory.Read.All"
}
New-MgOauth2PermissionGrant -BodyParameter $paramsCleanup
# Remove the permission grant
$grant = Get-MgOauth2PermissionGrant -Filter "clientId eq '$(Get-MgContext).ClientId'"
if ($grant) { Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId $grant.Id }
Disconnect-MgGraphExpected Telemetry
Azure AD AuditLogs: OperationName 'Add delegated permission grant', Result 'success', InitiatedBy.user.userPrincipalName = executing account, TargetResources[0].displayName = 'Microsoft Graph'. Visible in Microsoft 365 compliance portal under Audit search with Activity = 'Add delegated permission grant'.
Expected Detection
KQL Part 1 triggers on 'Add delegated permission grant' in AuditLogs. SPL EventCategory='DelegatedPermissionGrant' with Operation match. SuspicionIndicators score increases based on initiator account type.
Invites an external guest user and assigns them a privileged Azure AD role, simulating the onboarding step an adversary would perform after gaining access to a tenant via a compromised MSP account. The Global Reader role is used here as a non-destructive alternative to Global Administrator for testing purposes. Generates the 'Add member to role' and 'Invite external user' audit events used in the detection.
Command
# Requires Microsoft.Graph module and account with User Administrator + Privileged Role Administrator
Connect-MgGraph -Scopes "User.Invite.All","RoleManagement.ReadWrite.Directory"
# Invite a test external account
$inviteParams = @{
InvitedUserEmailAddress = "[email protected]"
InviteRedirectUrl = "https://myapps.microsoft.com"
SendInvitationMessage = $false
}
$invitation = New-MgInvitation -BodyParameter $inviteParams
$guestUserId = $invitation.InvitedUser.Id
# Find the Global Reader role
$role = Get-MgDirectoryRole -Filter "displayName eq 'Global Reader'"
if (-not $role) {
# Activate role if not yet instantiated
$roleTemplate = Get-MgDirectoryRoleTemplate -Filter "displayName eq 'Global Reader'"
$role = New-MgDirectoryRole -RoleTemplateId $roleTemplate.Id
}
# Assign role to guest (simulates MSP account being granted access)
$memberParams = @{ "@odata.id" = "https://graph.microsoft.com/v1.0/users/$guestUserId" }
New-MgDirectoryRoleMemberByRef -DirectoryRoleId $role.Id -BodyParameter $memberParams
Write-Output "Guest $($invitation.InvitedUser.Mail) assigned Global Reader role ID $($role.Id)"Cleanup
# Remove role assignment and delete guest user
$role = Get-MgDirectoryRole -Filter "displayName eq 'Global Reader'"
Remove-MgDirectoryRoleMemberByRef -DirectoryRoleId $role.Id -DirectoryObjectId $guestUserId
Remove-MgUser -UserId $guestUserId
Disconnect-MgGraphExpected Telemetry
Azure AD AuditLogs: OperationName 'Add member to role', Result 'success', TargetResources[1].displayName = 'Global Reader', TargetResources[0].userPrincipalName contains '#EXT#'. Also generates 'Invite external user' event. Both visible in AuditLogs table within 5-10 minutes.
Expected Detection
KQL Part 3 triggers on 'Add member to role' for external account (UPN contains '#EXT#') assigned to a sensitive role. SuspicionIndicators score elevated. SPL EventCategory='DelegatedPermissionGrant' for role assignment operation.
Uses PsExec or net use to perform a network (Type 3) logon to a local machine using a service account with MSP-style naming convention, simulating a remote service provider authenticating from an external network segment. This generates Security EventID 4624 with LogonType=3, which the on-premises portion of the detection monitors. Safe to run in a lab — authenticates only to localhost or a test machine.
Command
# Create a test service account with MSP-style naming
net user svc_msp_test TestPassword123! /add /comment:"Test MSP service account for detection validation"
# Perform a network logon to localhost simulating remote MSP access
# Using net use to force Type 3 logon
net use \\127.0.0.1\IPC$ /user:svc_msp_test TestPassword123!
# Verify the logon
net sessionCleanup
net use \\127.0.0.1\IPC$ /delete
net user svc_msp_test /deleteExpected Telemetry
Windows Security Event ID 4624: LogonType=3 (Network), TargetUserName='svc_msp_test', SourceNetworkAddress=127.0.0.1. Security Event ID 4672 if the account has elevated privileges. Visible in Windows Event Viewer under Security log within seconds of execution.
Expected Detection
SPL ExternalServiceAccountNetworkLogon branch triggers: IsMSPAccount=1 matches 'svc_' prefix, EventCode=4624, LogonType=3. Note: localhost is filtered as private IP in production query — in testing, temporarily remove the 127.* exclusion to validate the detection logic fires correctly.
Registers a new Azure AD application and grants it API permissions, simulating the backdoor persistence technique used by adversaries like HAFNIUM and APT29 after gaining access via a compromised MSP or partner account. Adversaries create application registrations with delegated or application permissions to maintain persistent access independent of the original compromised account. Uses Microsoft Graph PowerShell to generate detectable AuditLogs events.
Command
Connect-MgGraph -Scopes "Application.ReadWrite.All"
# Register a new application simulating backdoor app creation
$appParams = @{
DisplayName = "df00tech-detection-test-app"
SignInAudience = "AzureADMyOrg"
}
$app = New-MgApplication -BodyParameter $appParams
Write-Output "Created app: $($app.DisplayName) with ID $($app.Id) (AppId: $($app.AppId))"
# Get Microsoft Graph resource SP
$graphSP = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"
# Add Mail.Read permission to simulate data access capability
$requiredAccess = @{
ResourceAppId = "00000003-0000-0000-c000-000000000000"
ResourceAccess = @(
@{ Id = "570282fd-fa5c-430d-a7fd-fc8dc98a9dca"; Type = "Scope" } # Mail.Read
)
}
Update-MgApplication -ApplicationId $app.Id -RequiredResourceAccess @($requiredAccess)
Write-Output "Granted Mail.Read permission to test app"Cleanup
Remove-MgApplication -ApplicationId $app.Id
Disconnect-MgGraphExpected Telemetry
Azure AD AuditLogs: OperationName 'Add application', Result 'success', TargetResources[0].displayName = 'df00tech-detection-test-app'. Followed by OperationName 'Update application' with ModifiedProperties showing RequiredResourceAccess including Mail.Read scope. Both events include InitiatedBy.user.userPrincipalName of the executing account.
Expected Detection
KQL Part 1 triggers on 'Add service principal' and 'Add application' OperationNames in AuditLogs. If executed immediately after a cross-tenant sign-in, the temporal correlation hunting query (huntingQueries[1]) also triggers within the 60-minute join window.