Recovery Methods

The scope of this article does not allow for comprehensive instructions on how to regain control of compromised services, but the approach you use is decisive for the next steps. Restoring on-premises services after destruction or compromise has a long history. For many applications – including AD – specialist tools let you restore up to a relatively recent point in time without the risk of reactivating the malware introduced by the attacker. If this option is not available, you face a choice in most cases:

• Use a more or less fresh backup and follow up the restore (which must take place on an isolated network) by performing a comprehensive analysis and cleanup.
• Revert to a backup from a little further back, hope that it has not yet been compromised, and remake the changes that have taken place since the backup.
• Completely rebuild the directory service because all of your backups have been affected by the attack.

In all of these cases, you can be relatively sure that you have sufficient control over the rebuilt AD environment as long as it remains isolated from the Internet (i.e., it cannot establish a connection to the outside world).

Far tighter limits apply to disaster recovery of cloud services, because the operator only allows access to specific data, and in some cases this access is read only. What you are looking at in this case is restoring the hybrid identity. For example, assume you have backed up application data such as Exchange mail, SharePoint documents, Azure SQL databases, and so on by some other means and can put them back into the respective application as soon as the identity is working again.

Most disaster recovery scenarios here fall into one of the following categories. In the first scenario, the cloud identities may have been compromised but apparently not destroyed, and you still have access to a Global Administrator (GA) account that is active and still assigned the GA role. In the second case, some cloud identities have been destroyed or at least changed such that users can no longer log in, but you still have administrative access to the client. In the third case, you no longer have access to the cloud tenant at all; initially, you don't even know how serious the damage is, but users are reporting that they can no longer log in to cloud services.

If your usual administrator accounts (including the break glass account) no longer work, you need to check your documentation for applications whose identities may have sufficient permissions to create a new administrator or reset the password of an existing administrator. If you find such an application, it may be your best chance of regaining control over your tenant. At the same time, you have probably also found the way for the attacker to hijack your client. In other words, the need for action is urgent because you need to shut down this attack vector before proceeding to restore functionality.

If all administrative access is lost, the only thing that can help is a top-priority support request to Microsoft. Be prepared to have to prove tenant ownership through documents such as invoices or payment receipts and not just, for example, the ability to generate DNS records in custom domains, although this is sufficient for registration. In other words, you depend on the support of your management or commercial department, whose ability to act is severely restricted by the attack and whose nerves are on edge. It makes sense to include at least some of these documents in hardcopy in your emergency folder.

Regaining Control

Sometimes the attacked organizations are lucky and their cloud identity survives more or less unscathed. If you are facing this kind of situation and perhaps even have an up-to-date clean backup of your local AD, you may have gotten off lightly. Remove the old synchronization account from the Entra ID directory because its password may have been compromised. When you rebuild the Azure AD Connect synchronization, you will at least regain control over enabling your identities and their passwords. If you were originally using PTA, this will also work as soon as you set it up. Restoring ADFS, if this was your previous authentication method, is much more complex.

On the other hand, in a situation in which you urgently need access to the cloud services but restoring the on-premises infrastructure takes time, you need at least to enable your IT team to control cloud identities fully. To do this, though, you first need to break the link to the on-premises services.

The Graph API and PowerShell let you switch off synchronization. Please note that at the time of writing, this is only possible through the Graph beta endpoint. Connect to the Graph API by typing:

Import-Module Microsoft.Graph.Authentication, Microsoft.Graph.Beta.Identity.DirectoryManagement
$OrgID = (Get-MgOrganization).Id

From here, either submit a REST PATCH request to the beta endpoint,

$uri = "https://graph.microsoft.com/beta/organization/$OrgId"
$body = @'
{
   "onPremisesSyncEnabled": null
}
'@
Invoke-MgGraphRequest -uri $uri -Body $body -Method PATCH

or use the Microsoft Graph beta module, which still needs the Graph module to authenticate and open the connection:

$params = @{
          onPremisesSyncEnabled = $null
}
Update-MgBetaOrganization -OrganizationId $OrgID -BodyParameter $params

In both cases, according to Microsoft, it can take up to 72 hours for the synchronization status to be completely reset to Cloud Only . In practice, this change usually takes place within 12 hours but is by no means even close to real time. That said, you can see on the portal that the command has taken effect after just a few minutes; the status of Azure AD Connect or Cloud Sync very quickly reports that the Sync has never run. If PHS was enabled, all user accounts retain their last passwords, even after synchronization has been deactivated, so that the users – but unfortunately also the attacker – can still log in.

One thing to consider is that the various portals and endpoints will take varying amounts of time to change the displayed status of users and groups from Synchronized to Cloud Managed (Figure 2). If your disaster recovery plan allows it, you might want to delay further actions until the status is displayed uniformly everywhere.

Figure 2: Breaking down the hybrid identity takes different amounts of time in different parts of the Microsoft cloud.

If you are working with ADFS, you need to change the authentication type of all federated domains from Federated to Managed (Figure 3),

Connect-MGGraph -Scopes Domain.ReadWrite.All,Directory.Access-AsUser.All
Get-MGDomain

and proceed as follows,

Update-MGDomain -DomainId <Domain> -AuthenticationType Managed

for each domain that has an AuthenticationType of Federated.

Figure 3: All domains have been switched to managed authentication.

Reconnecting Entra ID with the Local AD

From now on, you can and must manage your Entra ID client independently of the local infrastructure. Once the AD has been restored, you need to reconnect the two directories. The procedure depends on whether you have restored the AD from a backup of the attacked AD or rebuilt it with the known account data. Before you continue, make sure that you disable the Block Hard Match Takeover security feature:

$uri = "https://graph.microsoft. com/beta/directory/onPremisesSynchronization" (Invoke-MgGraphRequest -Method GET -Uri $uri).Value.Features

Also watch out for BlockCloudObjectTakeoverThroughHardMatchEnabled. If the value is set to true, you must disable it with a corresponding PATCH request against the same endpoint to allow matching.

To ensure that everything works optimally, you have to know which attribute the matching was originally configured to use – lucky you if you documented your Azure AD Connect configuration. If this is not the case, you can read out the OnPremisesImmutableID attribute of your cloud user and try to convert it into a GUID or a string in a script:

$imid = (Get-MgUser -UserId -Property OnPremises-ImmutableID).OnPremisesImmutableID
$chars = [System.Convert]::FromBase64String($imid)
[System.Text.Encoding]::UTF8.GetString($chars)
if ($chars.Count -eq 16) {
          [guid]::new($chars).Guid
}

If the output string can be clearly read and evaluated, you can try to guess the attribute for which it is a valid value – often user principle names (UPNs) or email addresses, but they can also be other unique attributes. If the string is unreadable, you will probably find a GUID in the second line, the objectGUID of the corresponding AD object. Sander Berkouwer describes matching in detail in his blog [3], and in another blog post [4] he also discusses how matching can be established in a new forest – in case you have completely lost your AD and must rebuild it.

Entra ID saves some important attributes of the synchronized AD user, which subsequently makes it possible to assign the ID, and the on-premises directory can also be rebuilt true to the original. The properties all have the OnPremises prefix and include the security identifier (SID), the distinguished name (from which the organizational unit, OU) structure can also be derived), the sAMAccountName, the UPN, and even the complex attribute OnPremisesExtensionAttributes, which contains ExtensionAttribute<x> ranging from x =1 to 15 . On the other hand, you will see fewer local attributes for groups; the distinguished name and ExtensionAttribute<x> are missing here. That said, in a situation where the local directory is irretrievably lost but the Entra ID client has survived undamaged, the cloud identity is very useful for rebuilding AD.

Finally, an important note: As soon as you set up the synchronization again and Azure AD Connect, or once Cloud Sync has completed the matching process, the local AD is once again authoritative for the passwords, activation statuses, and group memberships of your users. Let your users know this early enough so that they can change their local passwords before synchronization is activated.