The short version. A credentialed, read-only look at your domain: which accounts are roastable, which ACLs and delegations create escalation paths, where certificate services are misconfigured. It requests nothing it would need to crack, and writes nothing to the directory.
What this engine does
Most domains do not fail because of a missing patch. They fail because of an accumulated permission nobody remembers granting. That accumulation is what this engine maps.
- Kerberoastable accounts — service accounts whose configuration makes them targets, identified by enumeration.
- AS-REP roastable accounts — accounts with pre-authentication disabled.
- ACL and delegation analysis — BloodHound-style path finding across object permissions, unconstrained and constrained delegation.
- ADCS misconfiguration — certificate templates that permit escalation (the ESC family).
- Domain-controller reconnaissance — policy, trust and account posture read over an authenticated LDAP bind.
What it deliberately does not do
This is the engine where restraint is the product. Everything below is excluded in code, not in policy:
- No ticket cracking. Roastable accounts are identified by configuration; no hash is requested for offline cracking.
- No writes to the directory. No object created, modified or deleted; no group membership changed; no password reset.
- No exploitation of the paths found. An escalation route is documented, not traversed.
- No credential harvesting. No secretsdump, no ticket theft, no memory access on any host.
- No lateral movement. The assessment stays at the directory layer.
How we prove you are allowed to run it
Authorisation is a hard gate, not a checkbox in our terms. A scan starts only if the asset is verified by Domain Control Verification — you place a DNS TXT record or a file we specify — or you supply an explicit legal-authority attestation stating you own the target or are authorised to test it. A request carrying neither is refused with HTTP 403, at every tier, with no override. This engine requires credentialed access to a domain controller, so it runs only on an explicit legal-authority attestation. There is no DCV equivalent for a private directory — the attestation is the record, and we keep it.
Where your data goes, and when it is deleted
Everything runs on EU infrastructure: edge functions in EU regions, scan compute in Frankfurt, object storage under EU jurisdiction, model inference through an EU endpoint. Nothing is used to train any model — ours or a third party's — and that is a contractual term in the DPA, which every plan gets.
- The report — kept two years, so you can hand it to an auditor next year.
- Raw uploaded material — third-party scanner files 30 days, application binaries 60 days, then deleted automatically.
- The anonymous homepage preview — content erased after 24 hours.
- The authorisation record — kept, because it is the evidence that the scan was permitted.
The full schedule is in our Privacy Policy, and the sub-processor list is on the Trust Center.
How a run actually works
You supply a low-privilege domain account. The engine binds over LDAP and reads: accounts, groups, ACLs, delegation settings, certificate templates and policy. Analysis is graph-shaped — the interesting output is not a list of misconfigurations but the shortest route from an ordinary account to domain dominance, if one exists.
Because the account you provide is a real credential, it is handled like one: never written to our database, scrubbed from logs, removed from the workspace at teardown.
What you get at the end
The paths, ranked by how short they are and how ordinary the starting account is, with the specific object and permission at each hop. Remediation is expressed as the concrete change — this delegation removed, this template restricted, this account given a stronger service password — rather than as generic advice.
What this engine cannot find
A read-only directory assessment cannot tell you:
- Whether a path is actually exploitable end to end in your environment, because it is never walked.
- Anything outside the directory: host-level misconfiguration, endpoint protection gaps, service vulnerabilities.
- What lives in trusted domains you did not include in the assessment.
- Whether your detection stack would notice the attack — that is a purple-team exercise, not this.
- Objects the supplied account cannot read.
We publish this list for the same reason we publish our own assessment report, limitations section included: a vendor that cannot tell you what its tool misses is asking you to take the rest on faith.
Frequently Asked Questions
Do you crack Kerberos tickets?
No. Roastable accounts are identified from their configuration. Requesting a ticket in order to crack it offline is exactly the destructive-adjacent step this engine excludes.
What privileges does the account you need have?
A standard, low-privilege domain user is enough. The value of the assessment comes from showing what an ordinary account can reach.
Will anything in our directory change?
No. There are no writes: no objects created or modified, no memberships changed, no passwords reset.
Why does this need an attestation rather than domain verification?
A private directory cannot be verified the way a public domain can. The attestation is your on-record statement that you are authorised, and we retain it as evidence the assessment was permitted.
Is this the same as a red-team exercise?
No. A red team walks the path and tests your detection. This maps the paths so you can close them, without touching production identities.