On 17 April, the ANSSI published the first doctrinal documents concerning remediation, which is defined as the project to regain control of a compromised information system. These documents are the fruit of the Agency’s experience in supporting victims of security incidents. 

This corpus consists of three sections: strategic section, an organisational section, and a technical section. Currently, the technical section focuses on the remediation of tier 0 of the Active Directory1, or core of trust. This section will be supplemented with additional documents in the future to enhance its content.  

The approach proposed by ANSSI (E3R) is divided into 3 stages: 

1. Containment of the attacker 
2. Evicting the intruder from the heart of the IS 
3. Eradicating the adversary’s strongholds 

These stages are illustrated by 3 typical remediation scenarios, each with increasing ambition levels based on the urgency of the restart and the costs incurred by the long-term damage resulting from the attack: 

1. Restore vital services as quickly as possible 
2. Regain control of the IS 
3. Seize the opportunity to prepare for long-term control of the IS 

The publication of this corpus is a timely step in the reflections and projects currently being carried out by many public and private players, with a view to strengthening their resilience in the face of a successful cyber-attack that would compromise or even destroy their Information System on a massive scale. 

In practice, the time required to establish a proven remediation system extends over several years for most players, rather than just months. This timeframe may be out of sync with the evolving threat landscape and the regulatory deadlines imposed on certain entities.  

There are several reasons for this, which vary from one player to another. However, there are three key factors which contribute to this variation:  

1. Awareness of cyber risk is growing; however, many decision-makers still lack adequate understanding. Balancing immediate priorities with long- term preparation in the face of potential compromises often leads to difficult decisions regarding the allocation of valuable human and financial resources.  
2. The interruption of an organisation’s activities following an IT disaster has historically been dealt with using Disaster Recovery Plans. Their advantages and limitations in terms of remediation are still poorly understood within organisations: 
   1. Depending on the recovery principles adopted, they may offer advantages in terms of IS recovery sequencing know-how (similar to an electrical shutdown/restart), capabilities for unitary and grouped reconstruction, restored data resynchronisation and reconciliation, among others.
   2. Remediation efforts can leverage this know-how, provided it has not been lost because of the adoption of new solutions (e.g., active/active backup) or when a ‘debt’ in terms of maintaining operational conditions and DRP exercises has built up. 

Nonetheless, these plans also have significant limitations. Their architecture relies on technical interconnections and data replication with backup infrastructures, which can inadvertently propagate compromises. Furthermore, while their relevance is proven in a deterministic context (where a given disaster corresponds to a given solution and plan), their effectiveness becomes much less certain when confronted with the diverse characteristics and possibilities of evolving cyber attacks  

This calls for a hybrid approach involving operational, DRP and cyber resilience players. This can be facilitated or hindered depending on the governance that has been put in place between these populations. 

To accelerate the necessary rise in maturity of players on the subject of IS remediation following a cyber-attack, several approach can be considered. Outlined below are four potential strategies, and the subsequent information will provide a more detailed explanation and elaboration for each approach. 

1. Helping decision-makers to understand the specific nature of cyber risk; 
2. Anchoring “compromise by design” in everyday life; 
3. Have several remedial options at your disposal; 
4. Sharing and capitalising on feedback. 

Helping decision-makers understand the specific nature of cyber risk 

 The vast majority of players do not totally rule out the possibility of being vulnerable to a successful cyber-attack that would paralyse their activities through the logical destruction of their IT assets. 

On the other hand, a significant proportion of players have not yet grasped the fact that their existing IT backup resources are rarely adapted to the specific characteristics of this type of attack. A cyber-attack can jeopardise the availability and non-compromise of operating and administrative resources, right down to the workstations of those involved in IS recovery. The timeframe for remediating an Information System (IS) that has suffered extensive destruction due to a cyber-attack is typically considerably longer compared to the recovery time communicated to the business in the event of a physical disaster. 

A number of players have not yet fully assessed the impact of the cyber threat on their ecosystems, for example: 

• If their first-tier IT service providers (outsourcer, cloud service provider, etc.), or even higher-tier providers, are themselves affected by a successful destructive attack; 
• If a player is the victim of a cyber-attack, whether proven successful or not, its partners who have knowledge of the attack will be able to isolate it unilaterally for protection purposes. 

The awareness of an organisation’s decision-makers of the cyber risk, its systemic implications and the impact on its business must be developed. In the financial sector, the DORA regulations, or their equivalents in certain non-European countries, as well as the stress tests announced by the European Central Bank for 2024, should contribute to this. 

For many decision-makers, too many technical words are used to describe the risk of cyber destruction. Unlike compliance issues such as the RGPD, which can be understood by the uninitiated, this risk is perceived as a matter for technical experts. Nevertheless, the subject is increasingly being addressed at executive committee level, for example through the presence of the CISO on the Executive Committee and/or through external speakers with experience in acculturating senior management. 

Anchoring “compromise by design” in everyday life 

By considering the possibility of an IS compromise that could result in its destruction and incorporating this perspective from project design to operational activities, the resilience capabilities of the IS can be significantly bolstered.  

From the earliest stages of a project, the business units can be called upon to identify and evaluate, with the support of the technical teams, cyber-resilient design solutions. These may include: 

• To use suppliers of nominal solutions that are technically independent of the organisation’s IS, so that its activities are not based exclusively on it’s IS; 
• To host and operate backup solutions outside the organisation’s IS; 
• Use cyber-resilient architecture models based on an on-premises catalogue or hosted in the Cloud. They are also designed to allow their resilience to be tested while limiting the impact of tests on production; 
• Designing projects that enable operation in degraded mode via : 
  • Periodic extraction of business data in office format, outsourced and protected in an external file storage service; 
  • The ability for applications (and services such as restoration) to operate without certain cross-functional services such as the AD authentication repositories via local backup accounts, etc;  
• Drawing up downgraded business procedures based on downgraded IS resources such as those defined above. 

In addition, the appropriateness of certain practices, although incompatible with the objectives of standardisation and industrialisation, can be considered at the technical design stage, in particular: 

• Encouraging diversity of technologies to limit the exploitation of a vulnerability. 
• Limiting the dependency of applications on cross-functional information systems, so that they can be rebuilt and made operational more quickly. 

During the acceptance phase, business operations in degraded mode and the ability to rebuild an application can be systematically tested before going into production. This test can be reviewed if necessary for each major change. It should be reiterated periodically through exercises that will enable remediation capabilities to be tested and enhance the skills of the various operational players. 

Moving beyond the project phase, the integration of asset reconstruction practices into Business As Usual (BAU) operations enables better mastery of these practices. This, in turn, benefits a larger number of participants in the event of remediation, for example; 

• Reconstruction, once or twice a year, using non-IS resources (e.g., Cloud services or off-line resources), of workstations used for administrative tasks and/or critical activities; 
• Reconstruction, once a year, of infrastructures essential to the recovery of the IS (e.g., restoration infrastructures, core of trust, virtualisation base, etc.), to be determined on the basis of the threat and risk analysis; 
• Development of CI/CD practices on a daily basis, particularly in Cloud environments, in order to automate the recreation of servers to apply changes to them, such as version upgrades or patches. 

Finally, keeping the IS map (including its interconnections with partners and the Internet) and its interdependencies up to date daily is a key factor in remediation, which must be supported by appropriate processes, tools (cyber-resilience) and controls. 

Having several remediation options at your disposal 

Given the difficulty of predicting the course of a cyber-attack and the evolution of its impact in advance, the preparation of a plan requires a balance to be struck between two excesses: 

• Developing reconstruction solutions tailored to too few attack scenarios, with the inherent risk of deadlock, 
• Or, on the contrary, seek to cover all possible scenarios, at the cost of a significant loss of efficiency. 

An updated risk analysis of possible attack scenarios, based on a threat watch, makes it possible to prioritise those to be covered, such as those with the highest probability of success and the greatest impact in the context of the organisation.  

This analysis makes it easier to identify the assumptions that will be used as inputs to the development of plans. For example ; 

• Just a year ago, planning for the industrialised reconstruction of the virtualisation layer of physical servers did not appear to be a necessity for most players, but it has now been identified as essential. 
• The destruction of Cloud resources through the compromise of access to the tenant (master accounts or API access) or even the compromise of the Cloud provider itself, appears to be a new risk that needs to be considered in the Cloud resilience strategy of several players. 

Once the working hypotheses have been chosen or ruled out (e.g., the types of components and technologies impacted, the residual capacities of the malicious code once its means of interacting with the attacker have been cut off, etc.), it is possible to assess the relevance of the various possible means of reconstruction and to prioritise the work more effectively. The following are possible means of reconstruction.  

• Restore systems and/or business data from backups, if necessary, in an isolated environment (e.g., from snapshots, offline or “immutable” backups); 
• Cleaning up restored environments that may have already been compromised when they were backed up (e.g., Using antivirus software for office files and systems that may have been compromised, using an EDR on systems that have been restarted in an isolated environment, or using solutions that can clean up the backed-up image of a virtual server directly); 
• Reinstallation of compromised technical layers (e.g., OS, middleware, etc.); 
• Replenishment of virtual infrastructures (e.g., Terraform, etc.); 
• Strategies and solutions that can cover both the risk of a conventional disaster and a cyber disaster (e.g., a backup IS that is independent of the nominal IS, with business data refreshed by a device that maintains technical watertightness). 

This assessment should lead to the development of a “catalogue” of remediation methods, the application of which should be contextualised at the time of the attack. As a complement to each reconstruction solution in the catalogue, the identification of an alternative – perhaps less industrialised – solution will enable us to deal more effectively with the vagaries of the attack context. 

Sharing and capitalising on feedback 

To gain maturity and efficiency in remediation more quickly, market players benefit from capitalising on the experience of others. 

This may involve capitalising on: 

• Studies, such as the body of doctrine published by ANSSI; 
• Direct exchanges with peers or via third parties; 
• Working groups in which its ecosystem of partners will be represented if possible. 

The feedback to be sought can relate to the specificity of the cyber context in remediation but also to more traditional aspects linked to the reconstruction of an IS such as: 

• The methods and approaches used; 
• Proven market solutions (beyond promises);  
• Performance achieved (reconstruction times)  
• Costs;  
• Logistical and HR aspects (similar to crisis management);  
• More functional aspects such as data reconciliation, following different restoration points and lost flows with third parties. 

Other articles on the subject of remediation :

Surviving an Active Directory compromise: key lessons for improving the rebuilding process

Cyber-attacks: what are the risks for backups and how can you protect yourself?

Active Directory rebuild: approaches to quick Active Directory recovery

Next on https://www.riskinsight-wavestone.com/ : workstation remediation

Cet article  « Compromise by design » or how to anticipate a destructive cyber attack est apparu en premier sur RiskInsight.

Your company is currently dealing with a major ransomware crisis. Given its central role in managing access, authentication, and network resources within any organisation, cybercriminals have compromised the Active Directory in 100% of these crises.  

Your systems are now encrypted if the attackers have activated the malicious payload. They might otherwise be isolated and unavailable. In either case, your company no longer has the necessary resources to function properly, and your activity has either ceased or has been significantly slowed! 

In this case, trust in your information system has been broken. Your teams begin to feel business pressure, and one question persists: when will we be able to reopen our services? Your goal then becomes clear: you must restore Active Directory with a high enough level of trust to reopen services as soon as possible. 

Rebuilding an Active Directory is a difficult step in crisis management. If poorly executed, your organisation exposes itself to two major risks: exacerbating the operational impacts for the business or introducing a new threat to your environment.

The ANSSI has recently published three very comprehensive guides on this subject [1], which we recommend you read. 

In this article, we will go over some of the items that stood out to us during crisis management. Our teams were able to overcome numerous obstacles during their interventions. What are the main issues that have arisen? How can they be fixed?

From compromise to reopening: advice to overcome obstacles

Start remediation efficiently with a proven organization

Time lost due to poor crisis organisation can exacerbate the consequences of an Active Directory compromise. Teams are frequently unsure of what to do, who to involve, and what goals to pursue. A delayed response will increase remediation costs, revenue losses, and have an impact on the company’s reputation.

Before the crisis…
It is necessary to identify all the key players to involve in the reconstruction of the Active Directory:

The executive committee will resolve fundamental issues. For example, do we prioritise reopening critical services quickly for business reasons or slowly and securely? There are several possible postures, each with advantages and disadvantages [1 – Strategic Dimension]. The entire remediation plan is based on this decision, so the executive committee must make a decision to begin work immediately.  

Business teams will identify and prioritise the most critical services for restoration. The Active Directory compromise affects the majority of the company’s services, and your teams will be unable to handle all requests at once. 

Intervention teams (technical and security) will be formed to define and implement the remediation strategy. Because of the expertise and human efforts required to rebuild an Active Directory, temporary reinforcement of your teams is required to handle the remediation: mastering configuration review tools (PingCastle, Purple Knight, etc.), prioritising detected vulnerabilities, deployment and control of measures, and so on. 

It is critical to define processes and reflex cards in order to optimise each actor’s reaction time. Simulations and regular exercises should be organised in addition to their writing to train your teams to react effectively. 

During the crisis… 

Rapidly implement a project monitoring system that includes regular reports, action tracking, and coordination among the various teams involved. Too often, a lack of communication and information leads to a slowdown in remediation. It is not uncommon for administrators to take initiatives without taking the time to communicate them, such as opening more network ports than necessary, parallelizing two tasks from the remediation plan, and so on. These well-intended initiatives can have a significant impact on remediation, ranging from complicating the work to a distorted view of the true security level following the security work, and thus an increased risk of new lightning compromise. 

Ensure the resilience of backups by defining a robust strategy   

When dealing with an Active Directory compromise, the unavailability of backups (corrupted or compromised) is a major challenge. Attackers frequently target and disable backups or disrupt backup servers. This complicates and lengthens Active Directory restoration and recovery. 

Before the crisis…

Create a resilient backup strategy that takes best practices and recommendations into account (backup on disconnected media, immutable or in the cloud) [2]. There is currently a significant gap between state-of-the-art and implemented backup strategies (for example, Active Directory authentication of backup infrastructures, unsecured domain controller backups, and so on). 

During the crisis… 

Consider performing Active Directory remediation from a compromised domain controller. This “double bascule” method can assist in recovering and securing critical data in order to restore the Active Directory service without the use of a backup. When backups are unavailable and the strategy does not include rebuilding Active Directory from scratch, this scenario is selected. 

Anticipate technical problems such as DNS Active Directory configuration by maintaining your environment 

The vast majority of Active Directory environments have accumulated technical debt over time (complex network architecture, roles such as DHCP carried out by domain controllers rather than dedicated servers, and so on). Furthermore, Active Directory environments are now synchronised with Azure Active Directory, establishing new technological dependencies that may complicate remediation in the event of an Active Directory compromise (Active Directory/Azure Active Directory synchronisation). These two elements can cause an array of technical issues on the day of the crisis (loss of synchronisation with Azure Active Directory, unavailability of the DHCP service carried by a domain controller that must be turned off, and so on).

Before the crisis… 

Maintain Active Directory technical documentation and inventories (infrastructure, Azure Active Directory synchronisation, etc.). It often proves too difficult to obtain a clear view of the environment and the perimeter to be remediated. Up-to-date inventories will significantly improve remediation work and ensure the establishment of a consistent remediation plan. Additionally, this will allow you to identify and correct bad practises that could cause major issues on the day of the crisis (DNS service configuration, DHCP, and so on). 

During the crisis… 

After 30 days of desynchronization with the Active Directory, Azure Active Directory services may become unavailable, resulting in a ticking time bomb. Make sure to assess the consequences of losing Azure Active Directory services and avoid relying on them to handle critical tasks (email communication, for example).  

The crisis will highlight numerous technical flaws (Active Directory configuration report via audit tools, network issues, and so on). Make sure to only deal with problems that are related to the remediation plan’s objectives (see Advice No. 5 – Set a course and stick to it during remediation!). 

Optimize the reinitialization of secrets through processes adapted to your context 

Active Directory compromise results in a loss of trust in all of its secrets. As such, a reset of these is required to achieve the level of security required to reopen services while avoiding another quick compromise. Resetting a large number of user passwords and service accounts can have significant operational consequences in large environments with several thousand users and more than a hundred applications. To provide the new password for service accounts, you must first understand how the application uses the account. For users, you must devise a secure method of distributing new passwords on a large scale. 

Before the crisis… 

It is critical to have a clear understanding of the process of assigning new passwords to users. Several methods are available, depending on the environment studied, such as summoning users with the presentation of an identity card, transmitting the new username/password via physical mail, email, SMS, and so on. Regardless of the method chosen, the user must be required to reset his password on the next connection. Users may also be able to reset their own passwords using solutions that rely on two-factor authentication, for example. 

To carry out service account work, it is essential to create an inventory by identifying the associated applications and password reset methods for each of them. Obtaining this inventory by remediation teams is frequently complicated (unavailable, not maintained, etc.) and thus necessitates devoting significant time to tasks that can be completed outside of the crisis. Aside from remediation work, this exercise will help you manage your service accounts on a daily basis. One of the best practices is to change the passwords on these accounts on a regular basis. 

During the crisis… 

Once the passwords have been reset, it is necessary to ensure that the security measure has been implemented throughout the environment. This is easily accomplished with a PowerShell script, and it ensures that the attacker no longer has a valid account to exploit. 

Set a course and stick to it during the remediation! 

During an Active Directory reconstruction, it is frequently difficult to strike the right balance between exposing oneself to risks by reopening too quickly and incurring significant financial losses by reopening too slowly. Take care not to fall into the common pitfalls of managing a ransomware crisis.[3] 

Before the crisis… 

It is necessary to consider the various remediation postures: quickly restoring vital services, regaining control of the information system, or seizing the opportunity to prepare for long-term control of the information system. [1] 

Beyond defining the posture, ensure that you understand your Active Directory trust core, which is made up of the most critical assets (Tier 0). The remediation actions begin with these components (domain controllers, for example) in order to restore Active Directory’s vital services and to ensure a level of security that does not allow the attacker to compromise the entire environment again. 

During the crisis… 
Make sure that your teams stay on track. As the remediation plan is carried out, new issues will emerge (unavailability of the domain controller carrying one of the required FSMO roles for remediation, network problems, and so on). It will be necessary to question the short-term relevance of its remediation in relation to the set objectives (the answer being dependent on the executive committee’s posture: quick reopening or slower and more secure).  

Consider the opportunities presented by the crisis. For example, if the DHCP service was managed by a domain controller, take advantage of the opportunity to set up a dedicated DHCP server, thereby decoupling the service from the domain controller. 

Our lessons  

The improvement of the reconstruction process before the compromise of Active Directory ultimately rests on three main axes: 

1. The drafting of functional processes and reflex cards to be able to: 
   1. Mobilize the right people in a timely manner. 
   2. Focus on the main objectives. 
   3. The maintenance of the Active Directory environment, which requires: 
2. Defining and maintaining an architecture in accordance with best practices. 
   1. Having up-to-date inventories. 
   2. Ensuring the resilience of backups. 
3. The performance of tests to: 
   1. Validate the applicability of theoretical processes in real conditions. 
   2. Improve the reactivity and efficiency of your teams in a crisis situation.

[1] https://www.ssi.gouv.fr/actualite/lanssi-publie-pour-appel-a-commentaires-un-corpus-documentaire-sur-la-remediation/

[2] https://www.riskinsight-wavestone.com/en/2023/02/approaches-to-quick-active-directory-recovery/

[3] https://www.riskinsight-wavestone.com/en/2023/01/successful-ransomware-crisis-management-top-10-pitfalls-to-avoid/

Cet article Surviving an Active Directory compromise: Key lessons to improve the reconstruction Process  est apparu en premier sur RiskInsight.

Thinking about the right way to deal with this topic in organisations is at the crossroads of AD security enhancement and cyber resilience projects.

Infrastructure and backup agents: weak points

Our various assessments over the last few months have shown that backup strategies have not always evolved towards the state of the art.

First problem: backup infrastructures are not resilient to cyber risk by default. For example, authentication on these backup infrastructures is very often linked to the Active Directory itself. Subsequently, the backup system could be compromised by the attacker, leading to a potential destruction of the backups… including those of the Active Directory!

And backups are a prime target for attackers. In more than 20% of the incidents managed by the Wavestone CERT in 2021, backups were impacted. It is therefore important to consider the cyber scenario – and especially the ransomware scenario – when thinking about the resilience of backups.

The second problem is that Domain Controllers (DC) backups are hosted in the backup tool, which often has a lower level of security than Active Directory. Indeed, an organisation that has already done some work to secure AD will have potentially greatly strengthened its tier 0 (always back to the tiering model!): setting up dedicated workstations for administration, multi-factor authentication, network filtering, dedicated hardware, limiting the number of privileged accounts, etc. Unfortunately, this will not necessarily be the case for the backup infrastructure. As these backups are not necessarily encrypted, an attacker could recover and exfiltrate them from a DC via the backup infrastructure, which is easier to compromise. Once the backup has been depleted, the attacker will be able to extend the scope of his compromise via a ‘pass the hash’ attack, after recovering the hashes, or a brute force attack, after extracting the secrets from the ntds.dit database to recover passwords in clear text, to be replayed on services whose authentication is not based on Active Directory.

Third problem: traditional backup methods rely on agents installed on Domain Controllers, whose high privileges sometimes increase the risk of systems becoming compromised. Backup agents almost always require administrative rights to the asset being backed up, which mechanically exposes the Domain Controllers and therefore the Active Directory domains. This leads to the paradoxical situation where the measure to reduce the risk of unavailability (installation of a backup agent on a DC) becomes the vulnerability itself that causes a risk that can become critical (unavailability of the entire information system).

Backup on disconnected media, on immutable infrastructure, or in the cloud: multiple strategies for multiple scenarios

To solve these two problems, multiple solutions exist, and their combination facilitates the construction of a robust strategy. This strategy must consider the context of the organisation as well as its cybersecurity maturity.

To address the first problem induced by the vulnerable agent, two approaches exist, both viable:

1. Reduce the probability of exploitation of the vulnerability induced by the backup agent. In addition to the classic security maintenance issues (regular updates, rapid correction of agent vulnerabilities, etc.), this involves integrating a dedicated backup tool into tier 0, whose security level will have been reinforced.
2. Get rid of the backup agent. How can this be done? By using the native Windows Backup feature, which allows a backup to be made and exported, which can be encrypted and taken out of the tier 0 asset, to a tier 1 asset, which itself can be backed up by the company’s standard backup solution.

To increase the resilience of Active Directory backups, a combination of measures should be taken wherever possible:

1. Externalize the backup on media (offline version). The first variant can be set up quickly and at low cost: it involves setting up an external hard disk which will be disconnected once the backup has been made. Then, it is simply a matter of setting up the associated organisational processes so that the necessary actions can be carried out without the relevant agents forgetting. The second option, for the rare organisations that still have them, is to rely on tapes. This option is also dependent on a key process: the regular backup and outsourcing of the backup catalogue, so as not to lose time in the event of restoration, should it also disappear (a story inspired by real events encountered by our incident response teams). A word of caution: tape backups should be seen as a last resort to ensure that a copy of the data is retained in the event of a disaster scenario. In fact, this backup format does not lend itself to rapid reconstruction, due to the considerable time required before restoration to the production IS can begin: time required to repatriate the tapes and time required to read their content.
2. Outsource the backup outside the (online) information system. Whether this is done using in-house scripts or market solutions (see our radar), after robust encryption, a backup can be outsourced. The advantage of market solutions is that they directly integrate the rapid reconstruction element (see next section) of a DC.
3. Rely on a complementary but independent backup. To increase the availability of the backup infrastructure, it is sufficient to (redundantly) ensure that there is no risk of simultaneous compromise. To this end, taking advantage of their transition to the cloud, many organisations have recently chosen to add an additional DC, but hosted in the cloud (the others being traditionally still on-premises), thus naturally benefiting from its own backup mechanisms. Due to the internal replication mechanisms of AD, the DC hosted in the cloud will be compromised (compromise of some accounts or AD configurations) in the same time scale as the on-premises ones, but due to the closeness between the backed-up assets and the backup system, one will have a greater chance of having a backup of a DC still available.
4. Make your backup infrastructure immutable by relying as much as possible on the solutions offered by backup software publishers. Indeed, most publishers now offer immutability mechanisms, which sometimes do not require the purchase of additional storage bays. By making backups immutable within their primary storage, you can be sure of an optimal reconstruction time since it will not be necessary to repatriate backups from offline storage (1.) or online storage (2.) before being able to start restoring. N.B.: 2. can and should benefit from this concept (Amazon S3, Azure blob, etc.).

Finally, one last point of detail, knowing which DCs to back up and use for restoration when necessary is essential (DC Global Catalog, most recent OS version, etc.), as is knowledge of the frequency (ideally daily) and the retention period (a much more subjective subject).

Fast rebuilding : often incompletely tested capabilities

Rebuilding tests are as old as the concept of DRP. But again, one can’t just rely on these annual tests to consider oneself prepared, given the state of the threat. Indeed, these tests are very often based on assumptions that will not be verified in the event of a major cyber-attack: available backups, confidence in the state of the information system, functional collaborative tools (workstations, messaging, ticketing tools, etc.), ready and available target hosting infrastructure, etc.

From what we observe in organisations, the times displayed and communicated on the reconstruction times of an AD domain are often underestimated a priori. The start and stop times of the stopwatch are often questionable: it starts when the backup recovery start button is pressed and stops when a DC is restored and operational (AD forest recovery procedure executed [2]). However, some points are often overlooked when comparing this time to the RTO time:

• unsatisfied dependency on another indispensable domain (domain with one or more approval relationships with other domains),
• ability to handle the authentication load that a service reopening will represent,
• execution time for “grooming” operations (mass password change, deactivation of certain services or accounts, clean-up in objects and groups, etc.),
• etc.

When the AD infrastructure is paralysed by a major cyber-attack, rebuilding it will quickly become the crisis unit’s priority, because of the dependence of applications and users on it. It is also the service with the lowest RTO. In the case where backups are available, certain questions quickly arise that must be addressed in the cyber defense strategy that is being defined (see our article on Successful Ransomware Crisis Management: Top 10 pitfalls to avoid):

• Is there a need for an area to accommodate sensible future infrastructure?
• Does creating users in Azure AD during the crisis allow the service to be reopened more quickly?
• If there are many AD domains (as is the case with very large organisations), in what order should they be created?

On the infrastructure side, firstly, in most cases, having an isolated and secure rebuild area saves time. This must be available, ready to host the number of VMs required to achieve the level of service considered acceptable in such a situation and under the control (accounts with sufficient rights, accessibility, etc.) of the team responsible for the Active Directory service only. This is to reduce the risk of compromise but also to avoid creating obstacles (requests to be made to another team) the day the need arises.

This zone can be on-premises or in a cloud service, depending on the costs and the organisation’s cybersecurity posture with regard to hosting DC on a cloud (if it is public). This dormant zone can also be used to host regular Active Directory recovery tests, to get as close as possible to a real situation. Finally, this infrastructure must obviously be in tier 0, if the organisation relies on this framework.

Then, on the process side, it is advisable to prepare several pieces of information in advance that will be essential when the need to rebuild the service arises:

• determine the minimum number of DCs and their location (rebuilding area in the cloud / on-premises, but also geographically in case of presence in multiple locations),
• determine the replication method (standard replication or use of IFM [3]) of the DCs to minimise the time between the availability of the first and last DC required to reopen the service,
• determine ready and deactivated filtering rules, which only need to be activated before the service is opened,
• establish the acceptable level of risk for the rebuild (simple rebuild and object grooming or pivot method),
• (in organisations with multiple domains serving multiple businesses) establish a rebuild sequence, which should have been determined in advance with the business managers, to reopen the service with the right priorities.

Here again, specialised AD backup and recovery tools provide value: they allow the recovery process of an AD forest to be carried out in a few clicks and in an automated manner. Parallelization of these operations is also made possible, making these tools an undeniable accelerator to consider for organizations with many forests!

Finally, on the resources side, it is important to have an organisation that can respond to this occasional but very important work overload. For this, the automation of reconstruction activities that can be automated, but also the existence of teams that have already practised the exercise many times, is often decisive.

Some organisations take advantage of Disaster Recovery testing to simulate the worst possible situation for the Active Directory service, rather than just simulating a partial recovery. This is undoubtedly good practice.

Ultimately, asking the question of the resilience of one’s Active Directory infrastructure draws on the more global subject of information system resilience, but also concepts around tiering, and considerations regarding regularly scheduled full-scale exercises. We could even make a bridge with DevOps: wouldn’t we dream of being able to redeploy an AD infrastructure almost automatically, in the image of what DevOps manages to do thanks to the ‘Infrastructure as Code’ concept? In the meantime, regular training remains the only way to develop confidence about one’s ability to quickly reopen a minimal AD service if it were to be completely destroyed.

[1] https://www.wavestone.com/en/insight/cert-w-2022-cybersecurite-trends-analysis/

[2] https://learn.microsoft.com/fr-fr/windows-server/identity/ad-ds/manage/ad-forest-recovery-guide

[3] Install From Media : https://social.technet.microsoft.com/wiki/contents/articles/8630.active-directory-step-by-step-guide-to-install-an-additional-domain-controller-using-ifm.aspx

Cet article ACTIVE DIRECTORY RECOVERY: HOW TO BE READY ? est apparu en premier sur RiskInsight.