Ransomware Recovery Tales: Protect the Kingdom

For every ransomware incident MOXFIVE has assisted with, the primary concern during recovery has been the health of the core infrastructure. Before recovering any environment, the first thing to confirm, outside of the viability of backups, is whether there is a working and operational domain controller (DC) with functioning Active Directory (AD) services. A domain controller is a server that runs Active Directory, the Windows service that manages all users and computers in a Windows environment. Simply put, AD holds the keys to the Windows “kingdom” and is required for proper functionality of systems connected to the Windows domain. For that reason, it is imperative to have a functioning AD before you can begin restoring your other critical servers.

MOXFIVE has witnessed instances where ransomware significantly impacted the DCs, yet there were no available backups. This can make it difficult to recover an environment, but not impossible. When organizations find themselves in this situation, there are two potential scenarios to consider:

1. Active Directory is functioning but potentially unstable

• MOXFIVE recommends building new DCs, enabling AD services, promoting the DCs using DCPromo, and transferring all the flexible single master operation (FSMO) roles to the new primary DC.

2. Active Directory is not functioning and there are no backups

• Organizations are forced to rebuild the domain from scratch.
• This is the worst-case scenario that we prefer to avoid, as it commonly results in the recovery costs greatly expanding.

Based on the above scenarios, clearly the overall goal is to avoid scenario two. But how do you go about this? There are many ways of answering this question, for the purposes of this blog post we will focus primarily on two ways to avoid scenario two and ensure AD is functioning: viable backups and Azure AD.

Backups

Arguably one of the most tried and true methods, a well implemented backup solution can prevent you from having to rebuild an entire Windows domain. That said, there are many ways of backing up your servers, but MOXFIVE recommends following the 3–2–1 backup rule.

Ransomware threat actors often target local backup servers and delete backups to ensure that they have a higher chance of getting their ransom paid. This is especially true for backup servers that are joined to the Windows domain. Therefore, we recommend implementing the following best practices as it relates to your local backups:

• Do not join the local backup server to the Windows domain. Doing so will allow a threat actor to use privileged accounts to authenticate to the local backup server and potentially delete your local backups.
• Ensure the username and password used for authentication to the local backup server is complex, unique from anything within the environment, and protected. Threat actors will re-use and test credentials they have seen elsewhere in the network.
• Encrypt your local backup copies using utilities such IBM Security Guardium or Hashicorp Vault. Doing so will ensure that your backups have an extra layer of protection if a threat actor attempts to tamper with them.

While your local backups can be configured to be as secure as possible, organizations should still implement a backup solution that allows you to store cloud backups as well. Local backups allow for quick restores, but having a copy in the cloud as your contingency plan is recommended if your local backups are not available.

Azure AD

MOXFIVE has seen an increase in companies that leverage Azure AD within their domain. Azure AD is Microsoft’s cloud-based identity access management service that provides similar functionality to an on-premise AD solution. While shifting completely towards the cloud may sound like a great idea, it’s important to note that Azure AD will store user information but it will not contain any of the other elements that your on-premise DC would otherwise have (e.g. Group Policy Objects (GPOs), Organizational Units (OU), etc.). For that reason, MOXFIVE recommends having an on-premise DC to supplement your environment. In the event of an incident where your local DCs are down, Azure AD can be used as a temporary replacement and allow you to have a semi-functional domain. While you may need to restructure your network architecture, it is better than not having any functional DCs with AD services at all. Leveraging Azure AD will ensure that at least all the user information from your environment is still available if your DCs are completely inoperable and allow for authentication of users to systems in the environment.

Using Azure AD Connect sync to sync your on-premise DC (with AD services) with Azure AD enables your environment to be prepared for any situation that may involve a non-working DC with damaged AD. It is important to make sure that it is frequently synced, so that if you need to “recreate” your domain on premise, Azure AD has the most current information from your users. You can use Scheduled Tasks, the PowerShell module, and “Get-ADSyncScheduler”, to do the Azure AD sync for you. Note that by default, the shortest time allowed is 30 minutes. The more frequent you set the synchronization within your environment, the more network utilization you will experience.

Conclusion

The most important theme to take away from this blog post is to always “protect the kingdom”. If you are in a situation where you have been impacted by ransomware, AD often is the first step in restoring operations to the environment. For that reason, it is imperative to have a disaster recovery plan that includes your DCs in addition to your critical data. During recovery operations, you do not want the rest of your recovery efforts to be bottlenecked by a non-functional AD environment.