Every Kerberoastable account, AS-REP target and DCSync path in your domain, found and proven.
ADscan identifies the credential attack surface in your Active Directory, executes each supported technique, and delivers verified exposure instead of a list of potential vulnerabilities. Kerberoasting, AS-REP roasting, password spraying and DCSync, validated and mapped to DORA.
Credential exposure in Active Directory is the set of conditions that lets an attacker request, crack or abuse Kerberos tickets and service credentials without needing to elevate first. ADscan maps and executes the four main families: Kerberoasting, AS-REP roasting, password spraying and DCSync, recording each as proven when it succeeds or theoretical when it is detected but not reached.
82%
Kerberoastable service accounts exist in virtually every Active Directory. Most were created years ago, before the risk was understood, and rotate their passwords rarely if ever. An attacker with any valid domain account can request a Kerberos service ticket for each one and take it offline for cracking. A weak or shared password means Domain Admin within minutes. The same problem repeats with AS-REP: accounts with Kerberos pre-authentication disabled hand their hash to anyone who asks. No exploit, no special tool, no elevated access required.
CISA advisory AA23-352A, 2023 — service accounts with SPNs set across surveyed domains
- 01
Enumerate the credential surface
Collect all accounts with SPNs (Kerberoasting targets), all accounts without Kerberos pre-auth (AS-REP targets), and all accounts with DCSync-equivalent rights on the domain object.
- 02
Request and recover tickets
Request service tickets for Kerberoastable accounts and AS-REP hashes for pre-auth-disabled accounts, exactly as an attacker would from any domain-joined position.
- 03
Attempt offline cracking
Run the recovered hashes against a common password list. Results are honest: cracked passwords are proven exposure; hashes that did not crack in the test window are flagged as exposure-present but not cracked.
- 04
Validate DCSync paths
Identify accounts with Replicating Directory Changes / Replicating Directory Changes All on the domain object and validate whether DCSync is executable from the current test context.
- 05
Attempt password spraying
Test the domain against a low-volume common-password spray (policy-aware, lockout-safe) to identify accounts with guessable or default credentials.
- 06
Map and report
Each proven credential finding is tied to the path it enables (e.g. Kerberoasted SPN leads to lateral movement toward Domain Admin) and mapped to DORA, NIS2 and ENS Alto controls.
Kerberoasting and AS-REP roasting, executed
ADscan requests service tickets and AS-REP hashes natively, attempts offline cracking, and reports which accounts are proven compromisable versus detected-only. Not a misconfiguration scan: a live credential attack.
DCSync path validation
ADscan identifies every account or group with replication rights on the domain object and validates whether the DCSync attack is executable from the current context, producing the hash dump as proof when it succeeds.
Password spraying with lockout safety
Low-volume, policy-aware spraying that reads the domain lockout policy before making any attempt. Identifies accounts with guessable passwords without triggering account lockouts in production.
Chain into the attack path
A cracked service-account credential or a DCSync hash is not a standalone finding: ADscan continues the chain and shows which path to Domain Admin that credential unlocks, connecting credential exposure to Tier 0 impact.
Golden Ticket readiness via DCSync
When DCSync succeeds and the krbtgt hash is recovered, ADscan flags Golden Ticket readiness, the condition under which an attacker can forge any Kerberos ticket in the domain for an unlimited period.
Compliance-mapped credential findings
Every proven credential finding is mapped to the specific DORA Article 9.4 protection requirement, NIS2 Article 21 access-control measure, and ENS Alto identity control, with legal citations attached.
Mapped to the control your supervisor asks about.
Kerberoasting and DCSync are among the most-cited techniques in DORA Article 9.4 technical implementation guidance (EU 2024/1774), which requires entities to protect privileged accounts and service credentials. NIS2 Article 21(2)(i) mandates authentication and access-control measures that directly cover pre-auth and replication rights. ENS Alto requires continuous validation of identity and access controls. ADscan ties each proven credential finding to the specific control with its legal citation, so the report is compliance evidence, not just a technical log.
The open-source ADscan CLI enumerates Kerberoastable accounts, AS-REP targets and DCSync rights, requests tickets and hashes, and attempts cracking. All techniques are available in the free engine, no license required.
Adds the executive-level PDF report with the credential-exposure narrative, per-account remediation ordering, and DORA, NIS2 and ENS compliance mapping with legal citations. Free in beta for consultancies and MSSPs. The Enterprise platform adds scheduled re-validation and alerts when new Kerberoastable accounts appear.
Explore the rest of the platform.
In every regulated environment where we have run ADscan, at least one Kerberoastable service account existed with a password weak enough to crack in the test window.
Questions, answered.
What is Kerberoasting?
Kerberoasting is an Active Directory attack in which any authenticated domain user requests a Kerberos service ticket for any account with a Service Principal Name (SPN) set. The ticket is encrypted with the service account's password hash and can be taken offline for cracking. If the password is weak, the attacker recovers a plaintext credential for that account. The attack requires no elevated rights and no special tool, only a valid domain account.
What is AS-REP roasting and how is it different from Kerberoasting?
AS-REP roasting targets accounts with Kerberos pre-authentication disabled (the "Do not require Kerberos pre-authentication" flag in Active Directory). With pre-auth disabled, the domain controller responds to an authentication request with an AS-REP message encrypted with the account's password hash, without verifying the requester's identity first. The difference from Kerberoasting: Kerberoasting requires a valid domain account to request a service ticket; AS-REP roasting can be attempted without any credentials at all, just a list of usernames.
What is DCSync and why is it dangerous?
DCSync is an attack technique that abuses the Active Directory replication protocol. Any account granted the "Replicating Directory Changes All" right on the domain object can pretend to be a domain controller and request a copy of any account's password hash, including the krbtgt account. Recovering the krbtgt hash means an attacker can forge any Kerberos ticket in the domain indefinitely (a Golden Ticket). DCSync is silent in most environments: there is no lockout, no failed logon, and the default audit configuration does not log replication requests from non-DC machines.
How does ADscan detect credential exposure?
ADscan collects the domain's account attributes natively, without an agent, identifies accounts with SPNs, accounts without pre-authentication, and accounts with replication rights. It then executes each technique: requesting tickets and hashes, attempting offline cracking with a common password list, and validating DCSync from the test context. Results are explicit: proven means ADscan cracked the hash or executed the DCSync; theoretical means the misconfiguration exists but was not exploited in the test window.
What is a Golden Ticket attack?
A Golden Ticket is a forged Kerberos Ticket Granting Ticket (TGT) signed with the krbtgt account's hash. Because every Kerberos ticket in the domain is ultimately validated against the krbtgt key, an attacker who holds that hash can issue a TGT for any user, any group membership, and any validity period, including ones that do not exist. Golden Tickets survive password resets on other accounts, and the only real remediation is rotating the krbtgt password twice. ADscan flags Golden Ticket readiness when DCSync succeeds and the krbtgt hash is recovered.
Does ADscan test for credential exposure in compliance with DORA?
Yes. DORA Article 9.4 (as elaborated in EU Regulatory Technical Standards 2024/1774) requires ICT entities to protect privileged accounts and service credentials. ADscan maps each proven Kerberoasting, AS-REP and DCSync finding to the specific Article 9.4 requirement, with the legal citation and the concrete remediation, so the output is compliance evidence rather than a standalone technical report.
Find out which path to Domain Admin you have today.
Request a proof of value and we will run ADscan against your Active Directory, then deliver the compliance-mapped report.