In November 2023, the ALPHV/BlackCat ransomware operators gained full control over the network of one of Europe’s largest logistics operators in under 72 hours. The entry point: an unused service account with Domain Admin privileges that had not been rotated in more than four years. The end point: 14,000 workstations encrypted and a ransom demand of 12 million dollars. The attack vector that made the entire chain of events possible was classic Kerberoasting — a technique known since 2014, documented in dozens of security reports, and publicly available in every major offensive framework.
Active Directory is one of those systems whose security organizations treat as a given rather than something that requires active work. Yet every AD environment is the product of its own configuration choices and layers of accumulated administrative changes over the years. An account created in 2009, a GPO configured by an administrator who left the company in 2015, NTLM enabled “temporarily” during a migration in 2018 — these are the typical artifacts that attackers discover and exploit without mercy. This article systematically walks through the entire Active Directory hardening process: from the tiering model, through protecting privileged accounts, to a recovery plan for restoring the environment after a full compromise.
Why Is Active Directory the Most Frequently Attacked Component of Infrastructure?
Active Directory serves as the central authorization and authentication system in the vast majority of corporate environments based on Windows. A Domain Controller stores the databases of user accounts, groups, security policies, and resource mappings for the entire domain. Whoever controls the Domain Controller controls the entire organization — every workstation, every server, every application integrated with AD. This is precisely what makes AD such an attractive target for APT groups, ransomware operators, and financial criminals.
The AD architecture is built on protocols designed in the late 1990s — Kerberos defined in RFC 1510 and NTLM originating from Windows NT systems. Both protocols have been extended over the years with additional features and security patches, but their fundamental limitations will never disappear. Kerberos tickets are susceptible to Kerberoasting and AS-REP Roasting. NTLM hashes are susceptible to Pass-the-Hash and Pass-the-Ticket. These protocols are an inseparable part of every Windows environment and cannot simply be “switched off” without a thorough infrastructure rebuild.
The second source of vulnerabilities is accumulated historical complexity. An AD environment that has been running for more than a decade typically contains hundreds or thousands of objects — user accounts, groups, organizational units, GPO policies — that have accumulated over years of migrations, restructurings, and changing business requirements. An Active Directory administrator attempting to maintain full visibility of the entire environment without dedicated analytical tools faces a practically impossible task.
The third issue is the broad scope of compromise. Once an attacker obtains Domain Admin privileges, they do not need to attack each system individually. A single domain controller is sufficient to issue Kerberos tickets for any account, modify GPOs that distribute malicious code to all workstations, or export the NTDS.dit database containing the hashes of all accounts in the domain. The Verizon Data Breach Investigations Report 2024 indicates that in ransomware attacks against organizations with Windows infrastructure, the compromise of Active Directory constituted a critical phase in over 85% of incidents.
What Attack Techniques Do APT Groups Most Commonly Use Against AD — Kerberoasting, Pass-the-Hash, DCSync?
Understanding specific attack techniques is a necessary prerequisite for effective hardening. Attackers use well-documented methods categorized within the MITRE ATT&CK framework — familiarity with these techniques allows designing specific countermeasures rather than generic defenses.
Kerberoasting (T1558.003) is a technique that involves extracting Kerberos Service Tickets for accounts with the Service Principal Name (SPN) attribute and subsequently cracking them offline. Any service account with an SPN can become a target: the attacker requests a TGS ticket from the domain controller, which is a normal operation available to any authenticated domain user, and then cracks the ticket’s encryption outside the organization’s network. If the service account’s password is weak or predictable, the attack succeeds within minutes or hours. APT groups such as APT29 (Cozy Bear) have documented the use of Kerberoasting as a standard privilege escalation step.
Pass-the-Hash (T1550.002) allows authentication as another user without knowing the plaintext password — all that is needed is the NTLM hash. The hash can be extracted from the memory of the LSASS process on a compromised machine using tools such as Mimikatz or its derivatives. The technique is particularly dangerous in environments where administrators use the same local passwords across multiple workstations — compromising one machine immediately grants access to dozens of others sharing the common password. CVE-2021-36934 (HiveNightmare) is an example of a vulnerability that allowed unprivileged users to access copies of the SAM database and export local account hashes.
DCSync (T1003.006) is an attack that simulates the Domain Controller replication mechanism. An account with DS-Replication-Get-Changes and DS-Replication-Get-Changes-All permissions can send a replication request to a domain controller and retrieve NTLM hashes for any accounts — including the KRBTGT account, which enables the creation of Golden Tickets. The attacker does not need physical access to the DC or access to the NTDS.dit file. A single account with excessive replication permissions is sufficient to export the entire domain password database.
Golden Ticket and Silver Ticket are techniques based on forging Kerberos tickets. A Golden Ticket requires knowledge of the KRBTGT account password and enables the creation of valid TGT tickets for any user, including non-existent ones. A Silver Ticket requires only the service account hash and allows forging TGS tickets for specific services. The Golden Ticket is particularly dangerous because it remains valid even after user passwords are changed — it is valid for the entire lifetime of the default ticket configuration (10 hours) or until the KRBTGT account password has been rotated twice.
AS-REP Roasting (T1558.004) targets accounts with the “Do not require Kerberos preauthentication” option disabled. For such accounts, the domain controller responds to an AS-REQ request without verifying the identity of the requester, and the AS-REP response contains data encrypted with the account hash — making it crackable offline. This configuration is sometimes used by legacy applications that do not support pre-authentication and represents a regularly overlooked attack vector.
Key takeaway: All of the techniques listed above are effective primarily because of configuration errors and excessive permissions, not because of zero-day vulnerabilities in the protocol itself. AD hardening consists first and foremost of eliminating these configuration errors.
How to Implement the Tiering Model (Tier 0/1/2) in Active Directory?
The tiering model is the foundation of a secure permission architecture in Active Directory. Its principle is simple: assets and accounts of different criticality levels are isolated from one another in such a way that compromising a lower-tier resource cannot automatically lead to the compromise of a higher-tier resource.
Tier 0 encompasses the most critical assets: domain controllers, directory services servers (AD CS, AD FS, AAD Connect), Domain Admins and Enterprise Admins accounts, and all public key infrastructure management systems. Tier 0 accounts may be used exclusively to log on to Tier 0 resources. No Tier 0 administrator should use their privileged account to log on to workstations, application servers, or mail systems.
Tier 1 encompasses application servers, database servers, backup systems, and other infrastructure servers that do not hold permissions to manage AD. Tier 1 accounts (server administrators) may log on to Tier 1 resources but not to Tier 0. Escalation from Tier 1 to Tier 0 should be impossible — an application server administrator should have no path to seize control of a domain controller.
Tier 2 encompasses end-user workstations, mobile devices, and other end-user class devices. Workstation administrators (Tier 2) have permissions to manage workstations but not to log on to Tier 1 or Tier 0 servers. In practice, this means that IT helpdesk staff operating at the Tier 2 level should not have the ability to log on as an administrator to a production server.
The technical implementation of tiering requires configuring Authentication Policy Silos and Protected Users Security Group, which enforce logon policies at the Kerberos protocol level. GPO groups must block the ability of Tier 0 accounts to log on interactively to workstations (via the “Deny log on locally” and “Deny log on through Remote Desktop Services” settings for administrative groups outside their designated tier). Administrative separation must be reinforced by Privileged Access Workstations (PAW) — dedicated, hardened workstations used exclusively for Tier 0 administrative tasks.
Implementing the tiering model in an environment that has never had it is a multi-month project that requires a thorough inventory of current permissions, mapping of application dependencies, and careful communication with administrators. Errors in tiering configuration can lead to availability issues on production systems. nFlo carries out tiering model implementations as part of AD hardening projects, always preceding them with a complete inventory and dependency analysis.
How to Secure Domain Admin and Service Accounts?
Domain Admin accounts are the crown jewels of an Active Directory environment. Their compromise means an attacker instantly gains full control over the domain. Despite this, in many organizations the management of DA accounts is alarmingly careless — too many accounts, used too broadly, with passwords changed too infrequently or not at all.
The first principle: minimize the number of Domain Admin accounts. In a typical organization of several hundred employees, two Domain Admin accounts are sufficient — one for daily administrative tasks and one “break-glass” account stored in a safe as a backup. There is no business justification for having ten or twenty DA accounts, which is nonetheless the state of affairs commonly found in environments audited by nFlo. Every unnecessary DA account is a potential attack vector.
The second principle: Domain Admin accounts should never be used for everyday work. An administrator should have two separate accounts — a standard user account for browsing email, the web, and daily tasks, and a separate DA account for carrying out administrative tasks. Logging on with a DA account to a workstation used for daily work exposes the DA password hash to extraction from LSASS memory by malware or an attacker with local administrator access.
Service accounts constitute a separate risk category. They are often configured with excessive permissions — either “just in case” or because software documentation requires Domain Admin privileges. Their passwords are changed rarely or never — because changing a service account’s password requires updating the configuration in every service using that account. Microsoft introduced the Group Managed Service Accounts (gMSA) mechanism in Windows Server 2012, which eliminates this problem: the domain controller automatically generates and rotates a 120-character password for the gMSA account, and services retrieve the current password hash without administrator intervention. Migrating service accounts to gMSA is one of the most important hardening actions.
An additional mechanism for protecting privileged accounts is adding them to the Protected Users group. Accounts in this group cannot use Kerberos delegation, cannot be authenticated via NTLM or DES, their TGT expires after 4 hours (instead of the default 10), and Windows never caches their credentials locally on workstations. The Protected Users Security Group is one of the most effective mechanisms for protecting high-risk accounts, available since Windows Server 2012 R2.
Privileged Identity Management (PIM) and Just-in-Time (JIT) access is an approach in which privileged accounts have no special permissions on a day-to-day basis. An administrator requests privilege elevation for a defined period (e.g., 4 hours), receives approval (manual or automated), performs the task, and the permissions are automatically revoked after the time expires. The JIT approach dramatically reduces the exposure window for privileged accounts. Microsoft Entra ID offers built-in PIM for hybrid environments, and for purely on-premises environments, solutions such as CyberArk or BeyondTrust implement this mechanism.
How to Detect Anomalies in AD — BloodHound, PingCastle, Purple Knight?
Without active monitoring and analysis, an Active Directory environment remains a black box. An administrator may not know that a specific service account has a path to Domain Admin through a series of delegations and group memberships — a path that an attacker will discover and exploit within minutes. AD analytical tools are a mandatory element of the arsenal of every secure environment.
BloodHound (available in Community Edition and BloodHound Enterprise) is a graph analysis tool for relationships in Active Directory. The SharpHound collector (or BloodHound Python for remote collection) gathers data about AD objects: accounts, groups, organizational units, GPOs, computer sessions, and permissions. BloodHound processes this data and presents it as a dependency graph, enabling visualization of all attack paths leading to Domain Admin or DC. The query “show me all paths from accounts in the ‘Domain Users’ group to ‘Domain Admins’” immediately reveals transitive memberships and delegations that may not be visible in standard administrative tools. BloodHound Enterprise additionally offers continuous monitoring of environment changes and alerts on the emergence of new attack paths.
PingCastle is an audit tool that generates an AD security report with a score and a detailed list of identified issues. The PingCastle report categorizes risk across four areas: Anomalies (configuration anomalies), PrivilegedAccounts (privileged account issues), StaleObjects (stale AD objects), and Trusts (trust relationships between domains). The overall score (the lower the better — analogous to a risk score) allows benchmarking the AD security posture over time and comparing it across domains. PingCastle is an agentless tool that operates from any domain account — it can be run by both an external auditor and an internal security administrator.
Purple Knight is a tool by Semperis, focused on detecting Indicators of Exposure (IoE) and Indicators of Attack (IoA) in Active Directory. Purple Knight checks more than 100 security indicators, including the presence of accounts with non-standard ACL permissions, AdminSDHolder attributes, Kerberos delegations, or DCSync permissions. The tool is particularly valuable for detecting artifacts indicating a compromise has already occurred — for example, unauthorized changes to AdminSDHolder, the addition of accounts to protected groups, or modifications to GPO objects.
Using these tools in a regular audit schedule — a quarterly PingCastle scan, monthly BloodHound analysis, and a semiannual Purple Knight review — allows detection of security issues before attackers find them. These tools are also a standard element of AD penetration tests carried out by nFlo: BloodHound and PingCastle results form the core of the report, with identification of attack paths and prioritization of remediation actions.
How to Implement LAPS and Manage Local Administrator Passwords?
Local Administrator Password Solution (LAPS) is a mechanism for managing local administrator account passwords on workstations and servers. Without LAPS, organizations often use the same local administrator password across all machines — either as a “default” set during deployment, or as a password changed once and then forgotten. Such a configuration means that compromising one workstation immediately opens access to all other machines sharing the common password.
Windows LAPS (built into systems from Windows Server 2019 and Windows 10 20H2 onwards) and its predecessor Microsoft LAPS (standalone, available for older systems) store randomly generated local administrator passwords directly in the attributes of computer objects in Active Directory. Each machine rotates its own password according to a configured schedule (e.g., every 30 days or after each use), generating a random string of 14 or more characters. Authorized administrators retrieve the current password from the AD attribute or from the LAPS administration center. After use, the password is automatically rotated, eliminating the risk of its reuse.
Implementing LAPS requires several steps: extending the AD schema (for Microsoft LAPS), configuring GPOs that define the scope of managed machines and the password rotation policy, and granting read rights to LAPS attributes only to authorized administrator groups. It is critically important that permissions to read LAPS passwords are granted on a least-privilege basis — a workstation administrator in a branch office should not have access to server passwords.
Windows LAPS (introduced in Windows 2023) extends capabilities with encrypted password storage, management of DSRM (Directory Services Restore Mode) accounts on domain controllers, support for Microsoft Entra ID (for Entra-joined devices), and the ability to store password history. For organizations with devices older than Windows 10 20H2, Microsoft LAPS remains a fully functional solution.
Particular attention should be paid to managing the DSRM (Directory Services Restore Mode) account on domain controllers. The DSRM password is the local administrator password for the DC, used in recovery mode. It is not managed by LAPS in a standard configuration, and its not having been updated for years is a common finding in audits. The latest version of Windows LAPS supports DSRM password rotation, eliminating this gap.
Key action: LAPS eliminates one of the most common lateral movement vectors — shared local administrator passwords. Its implementation should be treated as an absolute priority in every Windows environment.
How to Monitor Critical Events in AD — Event IDs to Watch?
Active Directory generates detailed security event logs, but their default configuration in many organizations is insufficient for effective threat detection. Extended auditing (Advanced Audit Policy) must be explicitly configured, and logs must be forwarded to a central SIEM or SYSLOG system, because local logs on Domain Controllers have limited capacity and can be deleted by an attacker.
Below is a summary of critical Event IDs requiring active monitoring:
Event ID 4768 and 4769 relate to Kerberos TGT requests (4768) and Service Ticket requests (4769). Bulk 4769 requests from the same account requesting tickets for multiple service accounts in a short period of time are a signature of Kerberoasting. Ticket requests using the RC4 algorithm (encryption type 0x17) instead of AES are particularly suspicious, because Kerberoasting tools request RC4 tickets due to the ease of cracking them.
Event ID 4624 and 4625 record logon events (successful and failed). It is worth monitoring logon types 2 (interactive), 3 (network), and 10 (remote). A Domain Admins group account logging on to a workstation (instead of a DC) is an immediate alarm. A series of 4625 events preceding a 4624 event for the same account suggests a dictionary attack or brute-force attempt.
Event ID 4720, 4722, 4723, 4724, 4726 relate to account management: account creation (4720), enabling (4722), password change by user (4723), password reset by administrator (4724), account deletion (4726). Creating new accounts in privileged groups or outside the standard onboarding process should generate an alert.
Event ID 4728, 4732, 4756 record the addition of a user to a security group (global, local, and universal, respectively). Adding an account to the Domain Admins, Enterprise Admins, or Schema Admins groups must immediately generate a high-priority alert.
Event ID 4673 and 4674 relate to privilege use (Sensitive Privilege Use). Event 4673 is generated every time an account uses a privilege from the Sensitive Privileges list, such as SeDebugPrivilege (required by Mimikatz) or SeBackupPrivilege. A large volume of 4673 events for the SeDebugPrivilege privilege generated by an unexpected process is a signature of Mimikatz usage.
Event ID 5136 and 4662 record modifications to AD objects (5136) and access to objects (4662). Changes to critical objects such as Tier 0 GPOs, AdminSDHolder, or domain controller objects must be monitored in real time. Event 4662 with access type DS-Replication-Get-Changes indicates a potential DCSync attack.
Event ID 1102 records the clearing of the security event log. This is an immediate alarm signal — log clearing is a classic technique for covering tracks after an attack.
Effective monitoring of these events requires a central SIEM with correlation rules. Collecting logs without detection rules does not provide detectability. nFlo designs SIEM rules specifically for the AD environments of its clients, taking into account their normal activity patterns to minimize false positives while maintaining high detection effectiveness.
How to Prepare for an AD Compromise Scenario — a Recovery Plan?
An AD environment that does not have a tested recovery plan for a full compromise is an environment that may not survive a serious attack. Rebuilding Active Directory after a ransomware attack or a full takeover by an APT group is one of the most challenging scenarios in IT security — technically complex, operationally stressful, and costly from a business perspective.
The key element of a recovery plan is regular, tested backups of the system state (System State) of domain controllers. Microsoft recommends using the 3-2-1 method: three copies, on two different media, with one copy offline. The offline copy is critical — ransomware attacks regularly target backups integrated with the domain. AD backups must be stored outside the reach of domain accounts, ideally in an isolated offline or air-gapped environment.
The retention period for AD backups is of enormous importance. If an attacker has been “nested” in the environment for 90 days before triggering the ransomware (the ALPHV/BlackCat 2023 scenario), and the organization only stores 30-day backups, restoration from backup may be impossible without simultaneously restoring the attacker’s presence. A tiered backup approach with a distinction between short-term (7 days), medium-term (30 days), and long-term (90+ days) backups is the minimum for high-risk environments.
The AD recovery plan following a full compromise (known as “Forest Recovery”) is a multi-phase process and is not something that can be improvised during an incident. Microsoft publishes a Forest Recovery Guide defining a 16-step recovery process, from network isolation, through restoring the first DC from backup, to verifying domain integrity and gradually restoring other systems. Every organization should conduct a simulation of this process at least once a year in a test environment, measuring the time and identifying critical dependencies.
Special attention must be devoted to the KRBTGT account — a special Kerberos account whose hash is used to sign all TGT tickets in the domain. After a full AD compromise, the KRBTGT hash is compromised (Golden Ticket). The KRBTGT password must be changed twice with a pause between changes (a period equal to the maximum TGT ticket lifetime, 10 hours by default), because the two previous passwords are stored and still accepted by Kerberos.
Furthermore, the recovery plan must account for a “trust boundary reset” — after a full compromise, all trust relationships between domains (trusts) are potentially compromised and require deletion and re-establishment with verification. Delegated accounts, certificates issued by AD CS, AAD Connect synchronization tokens — all of these elements require verification and potential rotation.
nFlo offers a service for developing and validating an AD recovery plan (AD Forest Recovery Playbook) as a separate advisory project. The plan is an operational document: step by step, with assigned roles and responsibilities, ready to use in the stressful conditions of an incident.
What Does an AD Hardening Checklist Look Like?
The table below serves as a strategic map for Active Directory hardening — a compilation of key action areas, implementation priorities, and verification methods. It serves as a tool for self-assessing AD security maturity and planning next steps.
| Area | Hardening Action | Priority | Verification |
|---|---|---|---|
| Privileged accounts | Reduce the number of Domain Admin accounts to an absolute minimum (2-3 accounts) | Critical | BloodHound — query for DA accounts |
| Privileged accounts | Implement Protected Users Security Group for DA and EA accounts | Critical | Get-ADGroupMember “Protected Users” |
| Service accounts | Migrate service accounts to gMSA | High | Get-ADServiceAccount -Filter * |
| Local passwords | Deploy Windows LAPS on all workstations and servers | Critical | LAPS report — machines without LAPS |
| Protocols | Disable NTLMv1, configure SMB Signing (required) | Critical | Check GPO: Network security: LAN Manager |
| Protocols | Disable weak Kerberos encryption types (DES, RC4) where possible | High | Get-ADDefaultDomainPasswordPolicy |
| Tiering | Implement Tier 0 PAW (Privileged Access Workstations) | High | GPO verification: Deny log on locally |
| Tiering | Configure Authentication Policy Silos | High | Get-ADAuthenticationPolicySilo |
| Kerberoasting | Audit accounts with SPN — identify and secure weak passwords | Critical | PingCastle report: SPN accounts |
| AS-REP Roasting | Identify accounts with pre-authentication disabled | High | Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} |
| Delegation | Identify and remove unconstrained Kerberos delegation | High | BloodHound — Unconstrained Delegation |
| Monitoring | Deploy Advanced Audit Policy on all DCs | Critical | Check Local Security Policy → Advanced Audit Policy |
| Monitoring | Configure log forwarding from DC to SIEM | Critical | Verification in SIEM — events from DC |
| Monitoring | Enable monitoring of critical events (4728, 4769, 5136) | Critical | SIEM rule tests |
| AD CS | Audit certificate templates for ESC1-ESC8 vulnerabilities | High | Certipy — scan —vulnerable |
| Stale objects | Disable and remove inactive accounts (>90 days) | High | Search-ADAccount -AccountInactive -TimeSpan 90 |
| Backup | Implement tested System State backup of DC (offline) | Critical | Recovery test in test environment |
| KRBTGT | Schedule KRBTGT password rotation (minimum once a year) | High | Check lastPasswordSet for KRBTGT account |
| Trusts | Audit external trusts — remove unused ones | Medium | Get-ADTrust -Filter * |
| Audit | Run PingCastle and Purple Knight quarterly | High | PingCastle report — score below 30 |
How Does nFlo Conduct Active Directory Audits and Hardening?
nFlo has developed a methodology for Active Directory audit and hardening based on more than 500 completed security projects and experience with 200+ clients from the sectors of public administration, manufacturing, finance, and media. The approach is systematic and evidence-based — every recommendation is linked to a specific identified risk, not a theoretical scenario.
An AD audit conducted by nFlo proceeds in three phases. The first phase is automated data collection: PingCastle for assessing the overall security posture, BloodHound for attack path analysis, Purple Knight for compromise indicators, and custom PowerShell scripts for collecting detailed data on accounts, delegations, and GPO configuration. The data collection phase typically takes one business day and does not require any changes to the environment configuration — all tools operate in read-only mode.
The second phase is analysis and prioritization. nFlo specialists analyze the collected data, identifying critical attack paths (e.g., accounts with access to DA through fewer than 3 delegation or group inheritance steps), configurations that violate the principle of least privilege, and stale objects that pose a risk. Each finding is categorized according to the CVSS methodology and the MITRE ATT&CK standard, enabling precise communication of risk to management and the IT department. Clients regularly note that the nFlo report is the first document that realistically describes their AD security posture instead of a generic catalog of best practices.
The third phase is hardening — implementing recommended changes within an agreed scope and schedule. nFlo can carry out hardening directly or in a “train and assist” model, where nFlo specialists guide the client’s internal IT team through the implementation process. Every configuration change is preceded by testing in a UAT environment or an isolated test environment, and the schedule takes into account service windows that minimize the impact on business operations. nFlo’s response time to queries during a hardening project is under 15 minutes, which allows unforeseen complications to be addressed immediately.
A unique element of the nFlo service is the knowledge retention model: upon completion of the project, the client receives not only a final report but also an “AD Security Runbook” — an operational document describing the security configuration of the environment, the rotation schedule for passwords and key accounts, a checklist of periodic reviews, and response procedures for the most common AD incident scenarios. The Runbook is updated with each subsequent project. nFlo’s 98% client retention rate stems in large part from this approach — clients treat nFlo as a permanent security partner, not a one-time service provider.
Related concepts: Kerberoasting, Pass-the-Hash, DCSync, Golden Ticket, Silver Ticket, LAPS, gMSA, Protected Users Security Group, Authentication Policy Silos, BloodHound, PingCastle, Purple Knight, AD CS (Active Directory Certificate Services), NTDS.dit, KRBTGT, Tier 0/1/2 model, MITRE ATT&CK T1558, T1550, T1003.
Learn more: Active Directory Infrastructure Penetration Tests: Specifics, Techniques and Attack Paths | IT Infrastructure Hardening: How to Seal the Foundations of Your Digital Fortress | Identity and Access Management — From Basics to Zero Trust
Check our services: AD Security Audit and Hardening | Infrastructure Penetration Testing
Frequently Asked Questions
How Long Does an Active Directory Hardening Project Take?
The timeline depends on the size of the environment and the scope of the project. An AD audit for an organization of up to 500 users typically takes 3-5 business days (data collection + analysis + report). A full hardening project — implementing LAPS, migrating service accounts to gMSA, configuring tiering, extended auditing — for an environment of the same size takes between 4 and 8 weeks, including tests in a UAT environment and service windows. Larger environments (2,000+ users, multi-domain environments) require more time and are typically divided into phases prioritized by risk.
Can AD Hardening Disrupt Production Systems?
Poorly planned hardening can cause application availability issues — in particular, changing authentication protocols (disabling NTLMv1, changing Kerberos encryption types) can affect legacy applications that do not support newer standards. This is precisely why every configuration change should be preceded by testing in a non-production environment and carried out within service windows with a prepared rollback plan. nFlo always carries out hardening in iterations with a gradual rollout of changes and monitoring of the impact on the production environment.
Can Kerberoasting Be Completely Eliminated?
Kerberoasting as a technique derives from the properties of the Kerberos protocol — requesting Service Tickets is a normal operation and cannot be blocked. However, the effectiveness of the attack can be dramatically reduced by eliminating its weak points: migrating service accounts to gMSA (automatic rotation of 120-character passwords), regular auditing of accounts with SPN for password strength, disabling RC4 encryption for service accounts (enforcing AES, which makes cracking significantly harder), and monitoring Event ID 4769 for bulk ticket requests. These measures make Kerberoasting impractical even when the attacker has network access.
What Is the Difference Between Windows LAPS and the Original Microsoft LAPS?
The original Microsoft LAPS (available as a separate installation since 2015) stores local administrator passwords in AD attributes in plaintext (although access to the attribute is controlled by ACLs). Windows LAPS (built in from Windows Server 2019/Windows 10 20H2, updated in 2023) introduces encrypted password storage, support for DSRM accounts on domain controllers, password history, integration with Microsoft Entra ID for AAD-joined devices, and extended password policy options. For new deployments, only Windows LAPS should be used. For environments with systems older than Windows 10 20H2, Microsoft LAPS remains a functional solution and can coexist with Windows LAPS.
How Often Should an AD Security Audit Be Conducted?
The minimum is an audit once a year, and for high-risk environments (public administration, finance, critical infrastructure) — every six months or after any significant change to the AD infrastructure. Tools such as PingCastle are lightweight enough to run quarterly as an automatic check for configuration regression. Continuous monitoring using BloodHound Enterprise or similar commercial solutions enables real-time detection of new attack paths. It is worth remembering that the AD environment changes constantly — new accounts, new applications, new delegations — and the security posture from six months ago may not reflect the current reality.
Sources and Further Reading
- Microsoft Security Documentation: Active Directory Security Best Practices
- MITRE ATT&CK: T1558 - Steal or Forge Kerberos Tickets
- MITRE ATT&CK: T1550.002 - Use Alternate Authentication Material: Pass the Hash
- MITRE ATT&CK: T1003.006 - OS Credential Dumping: DCSync
- Microsoft Security: Windows LAPS Overview
- Microsoft Security: Protected Users Security Group
- Semperis: Purple Knight — AD Security Assessment
- SpecterOps: BloodHound Community Edition
- PingCastle: Active Directory Security Assessment Tool
- Microsoft: AD Forest Recovery Guide
