{"id":921,"date":"2025-01-31T09:30:14","date_gmt":"2025-01-31T08:30:14","guid":{"rendered":"https:\/\/sparrow365.de\/?p=921"},"modified":"2025-02-25T22:17:44","modified_gmt":"2025-02-25T21:17:44","slug":"new-vulnerability-in-entra-id-users-were-able-to-change-their-own-username","status":"publish","type":"post","link":"https:\/\/sparrow365.de\/index.php\/en\/2025\/01\/31\/new-vulnerability-in-entra-id-users-were-able-to-change-their-own-username\/","title":{"rendered":"New Vulnerability in Entra ID: Users were able to change their own Username"},"content":{"rendered":"

New Vulnerability in Entra ID: Users were able to change their own Username<\/h1>\n

Another Microsoft security vulnerability became known over the past week. It was<\/strong> possible for users and, under certain conditions, external users (guests<\/em>) to change their so-called "User Principal Name (UPN)<\/strong>." The UPN is the primary sign-in attribute used in the Microsoft world to determine identity.<\/p>\n

\n

The Bypass of Intune Compliant Device controls<\/a> is also still current<\/em><\/p>\n<\/blockquote>\n


<\/p>\n

\n

\u26a0\ufe0f For hybrid users synchronized from Active Directory, changes were overwritten, but this still opened a window for potential misuse.<\/em> \u26a0\ufe0f<\/p>\n<\/blockquote>\n

In the Admin Center, a user could adjust the prefix (Max.Mustermann<\/em><\/strong>@…) and the domain (…@Firma.de<\/em><\/strong>) in their own profile, thereby also creating additional valid email addresses for themselves. This change could also be done via the API.<\/p>\n

Normally, although the field is shown as editable, you would see an error message when attempting to save:<\/p>\n

\"AttempToSaveUPNChange\"<\/p>\n



\n
<\/p>\n

Since at least<\/strong> January 22, 2025, that error message did not appear. The issue was fixed<\/strong> on January 24, 2025, in the afternoon. To date, Microsoft has not disclosed exactly how long the problem existed (status as of January 29, 2025<\/em>).<\/p>\n


<\/p>\n

\n

When were guest users able to change their sign-in name?<\/h2>\n

Entra ID offers various ways to manage guests. By default, their access is limited. If, however, guests are granted the same rights as regular users (which I explicitly do not recommend!<\/em>), those rights included the ability to change their own UPN.<\/p>\n

\"ProblematicGuestAccess\"<\/p>\n



\n
<\/p>\n

\n

Why is changing the UPN a problem?<\/h2>\n

The following scenarios are immediately apparent to me, but there are certainly more ways to exploit the ability to change a UPN.<\/p>\n

Impersonation<\/h3>\n

Changing the UPN also changes the email and chat address<\/strong>. This could allow users to conceal their identity (e.g. \u201cCEO@…\u201d), as the display name in the Office contact card is often not visible across organizations. Old UPNs remain associated with the mailbox, meaning unused addresses (e.g. "WorksCouncil@…") could be misused to intercept emails. After an UPN-Change, Guests could also appear as internal employees.<\/p>\n

Dynamic Groups<\/h3>\n

Automatic group rules often rely on email addresses. By changing the UPN, attackers could gain unauthorized access to organization-wide Teams<\/strong> or files. Naming conventions used for security mechanisms<\/strong> (such as Conditional Access) could also be circumvented by clever administrators.<\/p>\n

\n

Tip:<\/strong> Administrator controls should use explicit assignments and protected attributes.<\/em><\/p>\n<\/blockquote>\n

Taking over inactive user accounts in connected applications<\/h3>\n

Even though active UPNs in Entra are unique, departed users\u2019 accounts<\/strong> may still exist in third-party applications. Since those accounts are often not deleted, this could allow extensive access to systems such as HR software or financial accounting.<\/p>\n


<\/p>\n

\n

Searching for Misuse<\/h2>\n

We\u2019ve established the importance of taking a look at any changes that occured \u2013 but how can we find problematic UPNs over an unknown time period?<\/p>\n

\n

Microsoft has announced that, in the event of misuse, they will contact the administrators of affected tenants. However, since neither the timing nor the details of this contact are known, it makes sense to proactively look for potential exploitation of this behavior wherever possible.<\/em><\/p>\n<\/blockquote>\n

Before we begin, it\u2019s important to note: without an Entra ID Premium license, Audit Logs are only retained for 7 days<\/a>. If these logs aren\u2019t forwarded to a Log Analytics Workspace or another archive, it\u2019s very unlikely you will be able to independently identify any misuse.<\/p>\n

\n

Adding the storage solutions listed below after the fact will not recover lost data\u2014what\u2019s gone is gone.<\/em><\/p>\n<\/blockquote>\n


<\/p>\n

Parsing the Audit Log from the Portal<\/h3>\n
\n

\u26a0\ufe0f This approach cannot detect the incident discussed in the article, because the corresponding logs have expired from the retention period. However, it can serve as a template for future searches.<\/em> \u26a0\ufe0f<\/p>\n<\/blockquote>\n

The simplest way to access the Audit Logs is via the Entra admin center<\/a>. Global Reader or Report Reader<\/strong> permission is sufficient.<\/p>\n

With Entra Premium licenses, such as those included in Enterprise plans, changes are retained for 30 days<\/strong>.<\/p>\n

\"DownloadLogsFromAdminCenter\"<\/p>\n



\n
<\/p>\n

While you can filter for user changes in the portal (Activity = "Update User"), even medium-sized tenants quickly become hard to manage in this view.<\/p>\n

It\u2019s therefore more practical to export the results and then analyze them with a script. Below is an example script that reads a CSV file of the Audit Logs and filters for suspicious changes:<\/p>\n

param (\n    [parameter(Mandatory = $false)]\n    [string]$auditCSVPath\n)\n\n# If Path not provided or not found, prompt user to select the Audit Log Export\nif (-not $(Test-Path "$auditCSVPath") ) {\n    Add-Type -AssemblyName System.Windows.Forms\n    $FileBrowser = New-Object System.Windows.Forms.OpenFileDialog -Property @{ \n        InitialDirectory = [Environment]::GetFolderPath('Desktop') \n        Filter = 'CSV Export (*.csv)|*.csv'\n    }\n    $null = $FileBrowser.ShowDialog()\n    $auditCSVPath = $FileBrowser.FileName\n}\n\n$auditlogImport = import-csv $auditCSVPath\nif ($auditlogImport.Count -eq 250000) {\n    Write-Warning "Please specify a (more restrictive) filter in the GUI or use the API, you have reached the maximum number of records"\n}\n\n# Filter relevant entries\n$selfEdits = $auditlogImport | Where-Object {$_.Activity -eq "Update user" -and $_.Target1ObjectId -eq $_.ActorObjectId}\n$suspiciousEdits = $selfEdits | Where-Object {$($_ | ConvertTo-Json) -match '"UserPrincipalName",' }\n\nif (-not $suspiciousEdits){ Write-Output "No suspicious changes found"; break }\n\n$Report = [System.Collections.Generic.List[Object]]::new()\nforEach ($item in $suspiciousEdits) {\n    $obj = [PSCustomObject][ordered]@{\n        "Timestamp" = "$(get-date ($item.'Date (UTC)') -Format 'dd-MMM-yyyy HH:mm')"\n        "User GUID" = $item.Target1ObjectId\n        "Old UPN" = $item.ActorUserPrincipalName\n        "New UPN" =  $item.Target1UserPrincipalName\n    }\n    $report.Add($obj)\n}\n$Report | Out-gridview -Title "Please verify, carefully, these UPN changes"<\/code><\/pre>\n

<\/p>\n
Audit Log via the Graph API<\/h3>\n
\n
\u26a0\ufe0f This approach cannot detect the incident discussed in the article, because the corresponding logs have expired from the retention period. However, it can serve as a template for future searches.<\/em> \u26a0\ufe0f<\/p>\n<\/blockquote>\n
If you have elevated privileges, I recommended setting up an Enterprise App and directly using the Graph API<\/strong> to retrieve the Audit Logs. However, for the initial setup, you\u2019ll need the "Privileged Authentication Administrator<\/strong>" right.<\/p>\n
Connect-MgGraph -Scope "AuditLog.Read.All, Directory.Read.All" -NoWelcome\n\n$filter = "activityDateTime le 2025-01-25 and activityDisplayName eq 'Update user'" \n$auditLogs = Invoke-MgGraphRequest GET "https:\/\/graph.microsoft.com\/v1.0\/auditLogs\/directoryaudits?`$filter=$filter" -OutputType PSObject\n\n# Identify UPN Changes initiated by the user himself\n$upnchanges = $auditlogs.value | Where-Object {$_.targetresources.modifiedproperties.displayname -eq "Userprincipalname"}\n$suspiciousEdits = $upnchanges | Where-Object {$_.Initiatedby.user.id -eq $_.targetresources.id}\n\nif (-not $suspiciousEdits){ Write-Output "No suspicious changes found"; break }\n\n# Create and show report\n$Report = [System.Collections.Generic.List[Object]]::new()\nforEach ($item in $suspiciousEdits) {\n\n    $modifiedProperty = $item.targetresources.modifiedproperties | Where-Object {$_.displayname -eq "Userprincipalname"}\n\n    $obj = [PSCustomObject][ordered]@{\n        "Timestamp" = "$(get-date ($item.activityDateTime) -Format 'dd-MMM-yyyy HH:mm')"\n        "User GUID" = $item.Initiatedby.user.id\n        "Old UPN" = $modifiedProperty.oldValue\n        "New UPN" =  $modifiedProperty.newValue\n    }\n    $report.Add($obj)\n}\n$Report | Out-gridview -Title "Please verify, carefully, these UPN changes"<\/code><\/pre>\n

<\/p>\n
KQL in an Azure Log Analytics Workspace<\/h3>\n
If you have set up an export of the Audit Log<\/a> to an Azure Log Analytics Workspace<\/strong>, you benefit from potentially much longer retention periods and more efficient search options.<\/p>\n
Simply open the Log search and use the following KQL to display instances where a user changed their own UPN:<\/p>\n
AuditLogs\n| where TimeGenerated between (datetime(2024-12-20) .. datetime(2025-01-25) ) \n| where OperationName == "Update user"\n\/\/Filter common Service Identities to reduce costly parsing\n| where not(Identity in ("Azure MFA StrongAuthenticationService", "Microsoft Substrate Management", "Azure Credential Configuration Endpoint Service", "Microsoft password reset service", "Microsoft Online Services", "Office 365 SharePoint Online"))\n| extend Target = parse_json(TargetResources)[0]\n\/\/ Check whether the UPN was changed before we expand\n| where Target.modifiedProperties has "UserPrincipalName"\n| mv-expand Target.modifiedProperties\n| where tostring(Target_modifiedProperties.displayName) == "UserPrincipalName"\n\/\/ Add the Initiator to check whether the user changed himself\n| extend Initiatior = parse_json(InitiatedBy)\n| where tostring(Initiatior.user.id) == tostring(Target.id)\n| extend newValue = tostring(Target_modifiedProperties.newValue)\n| extend oldValue = tostring(Target_modifiedProperties.oldValue)\n| where newValue  != oldValue\n| project TimeGenerated, User_GUID = Target.id, newValue, oldValue<\/code><\/pre>\n
\n
For no particular reason I would like to mention Julian Rasmussen<\/a>.<\/em><\/p>\n<\/blockquote>\n

<\/p>\n
Purview Audit Log Search<\/h3>\n
\n
\u26a0\ufe0f This approach can be used for full results with an E3 license until June 18, 2025, and with an E5 license until December 20, 2025<\/em> \u26a0\ufe0f<\/p>\n<\/blockquote>\n
If it turns out the vulnerability has existed for more than 30 days<\/strong> or you only became aware of it late, there is an alternative\u2014even if no Log Analytics Workspace<\/strong> has been set up.<\/p>\n
The Purview Audit Log<\/a> (also called the Exchange Unified Audit Log) stores compliance data for:<\/p>\n