Insurance

You price everyone else's cyber risk. Prove you have a handle on your own.

The attack starts at the help desk. Cracken picks it up at the account.

The run starts from one assumed standard domain account, the thing an MFA reset hands over, and walks your directory to the claims file share: Kerberoasting, a misconfigured certificate template, Domain Admin, DCSync. Against production, under scoped authorization, with the command and the captured output attached to every proven finding.

Definition

What is dora threat-led penetration testing (tlpt) for insurers?

DORA's threat-led penetration test lands on an insurer exactly as it lands on a bank. Article 2 puts insurance and reinsurance undertakings and their intermediaries in scope, so Article 26 applies: a test at least every three years, run on live production systems — the policy and claims estate where policyholder data sits, not a staging copy. In force since 17 January 2025.Regulation (EU) 2022/2554 (DORA), Articles 2 and 26 (CELEX 32022R2554, Official Journal of the European Union, 2022-12-27)

Start where the crew lands

The Active Directory playbook takes one assumed standard account and walks the graph: Kerberoastable SPNs, delegation, certificate templates, DCSync.

Legacy and cloud trust the same identities

Policy systems and newer claims apps end up federated to one directory. Network and Cloud Pentest work the seam between them.

The broker-facing portal you own

Web Application Pentest works your own portal the way someone holding a broker's credentials would.

Evidence an auditor can re-run

Every proven finding carries the exact command, the captured output, and its ATT&CK technique.

Scattered Spider (UNC3944) — talks past the help desk with breach-sourced PII, resets MFA, hijacks the identity provider, then steals data and extorts. On 16 June 2025 Google Threat Intelligence reported multiple US intrusions bearing the group's hallmarks and told the insurance industry to be on high alert. That same month Erie Indemnity disclosed an information security event in an SEC Form 8-K, without naming an actor.

Scattered Spider's route, and where Cracken picks it up

No firewall gets broken. A phone call buys the crew one account; everything after that happens inside your directory. That account is where Cracken starts.

  1. 1Recon
    Attacker

    Profiles an employee and pulls their PII out of a breach dump.

    With Cracken

    Domain Recon maps the same external footprint: people, hosts, exposed services.

  2. 2Help-desk pretext
    Attacker

    Talks the desk into resetting MFA on that employee's account.

    With Cracken

    The run starts from the account this step produces: one assumed standard domain account.

  3. 3Account takeover
    Attacker

    Enrolls its own device and walks in as a normal user.

    With Cracken

    Assumes one standard domain account and enumerates from it: SPNs, delegation, certificate templates.

  4. 4Identity provider abuse
    Attacker

    Registers a rogue federation trust and impersonates anyone it likes.

    With Cracken

    On-prem, escalates through a misconfigured ADCS template to Domain Admin and settles it with DCSync. In the cloud tenant, tests whether that admin can register the trust.

  5. 5Theft and extortion
    Attacker

    Policyholder data leaves and the clock on your filing starts.

    With Cracken

    Authenticates to the claims share and lists it. Reach proven by directory listing — no records are downloaded.

One run

One assumed domain account to the claims file share, proven by DCSync

The run starts from one assumed standard domain account. Getting that account is help-desk pretext work, and in this run the account is handed over rather than taken.

Written from the execution plan of the playbooks that run today — Domain Recon, Web App Pentest, Network Pentest, Cloud Pentest, AD Pentest. A run covers the target you authorise, under the policy you set.

  1. 01
    What ran

    The discovery sub-operation enumerated the domain over Kerberos with nxc and bloodhound-ce-python, then ran certipy-ad find against the certificate authority.

    What it established

    The domain controller, the accounts, and the file shares — including the claims share holding policyholder PII — plus candidate edges in the graph: Kerberoastable SPNs, a constrained-delegation account, and one certificate template flagged ESC1.

  2. 02
    What ran

    An exploit sub-operation loaded adcs-template-abuse and requested a certificate from the flagged template with certipy-ad, supplying a Domain Admin's UPN as the subject alternative name.

    T1649 Steal or Forge Authentication Certificates
    What it established

    A certificate issued in the Domain Admin's name. The template was already misconfigured, so no AD object was changed and there was nothing to roll back. Still a candidate, not a finding.

  3. 03
    What ran

    The same sub-operation authenticated with that certificate over PKINIT and unPAC'd the NT hash from the returned ticket.

    What it established

    A ticket-granting ticket and an NT hash for the Domain Admin, held in the operation's sandbox as a candidate to be reproduced.

  4. 04
    What ran

    A verify sub-operation, pinned to the same tentacle, ran impacket-secretsdump against the domain controller for krbtgt.

    T1003.006 DCSync
    What it established

    krbtgt replicated. PROVEN — full domain compromise, recorded with the command and the captured output attached to the finding.

  5. 05
    What ran

    With the Domain Admin credential, the operation authenticated to the claims file share found in step 01 and listed its contents.

    T1039 Data from Network Shared Drive
    What it established

    The path from one standard account to the policyholder data store, confirmed by a directory listing. Listing only; no records were downloaded. The control that should have stopped a lateral read is now identified, not assumed.

What this did not prove: No policyholder records were exfiltrated. The reach was proven by a directory listing: the account could open the share, and nobody read a record out of it. Erie Indemnity and Scattered Spider come from a public filing and public reporting; Cracken has run nothing for an insurer.

MITRE ATT&CK v19.0, April 2026

A general-purpose model quits at the first real offensive command

Ask a commercial assistant to forge a Kerberos certificate against your own domain and it declines. Cracken's model runs it, inside your authorized scope, and hands back the output.

?

Forge the certificate

Request a Domain Admin certificate from a misconfigured ADCS template and authenticate as them over PKINIT.

?

Replicate krbtgt

Run DCSync against your domain controller and settle whether one standard account reaches full domain compromise.

?

Follow the data

Walk that credential to the claims file share and confirm by listing whether the control actually holds.

You price everyone else's cyber risk. Run the attack pattern reported against your peers and prove you have priced your own.
Questions

What an insurance security team asks before a run

Does a Cracken run satisfy DORA's threat-led penetration testing obligation?

Not on its own. Article 26 makes TLPT a formal, competent-authority-overseen exercise carried out "at least every 3 years" on live production systems, and the threat-intelligence framing and sign-off sit with accredited testers. Cracken is the offensive execution engine inside that exercise: it runs the attack against the real environment and produces the reproducible proof the report is built on.Regulation (EU) 2022/2554 (DORA), Article 26(1)-(2) (CELEX 32022R2554, Official Journal of the European Union, 2022-12-27)

Are insurers actually a target, or is this compliance theater?

On 16 June 2025, after multiple US intrusions bearing Scattered Spider's hallmarks, Google Threat Intelligence's chief analyst said: "Given this actor's history of focusing on a sector at a time, the insurance industry should be on high alert, especially for social engineering schemes, which target their help desks and call centers." A named analyst naming your sector and naming the entry point — not a vendor statistic.John Hultquist, Google Threat Intelligence Group, on the insurance sector (The Register, 2025-06-16)

Has this reached a named insurer, on the record?

Erie Indemnity, a Fortune 500 insurer, told the SEC: "On June 7, 2025, Erie Indemnity Company (the "Company") identified unusual network activity, which the Company determined to be the result of an information security event." The filing names no actor, and we will not attach one to it. A named insurer and a filed document is the whole claim.Erie Indemnity Company, Form 8-K, Item 8.01 (U.S. Securities and Exchange Commission (EDGAR), 2025-06-11)

How does Cracken reach policyholder data from a single standard account?

The run starts from one assumed standard domain account — exactly what an MFA reset hands over. From that single account, the Active Directory playbook walks the identity graph: Kerberoasting, an ESC1 certificate template, PKINIT to a Domain Admin hash, DCSync, then the claims file share.

Do you test production, or a staging copy?

Production, under scoped authorization. Article 26 requires TLPT "performed on live production systems supporting such functions," which is where the exposure actually is. Cracken runs against the real target with per-action approval, a full ledger, and rollback on anything it writes. A staging clone answers a different question than the one your regulator is asking.Regulation (EU) 2022/2554 (DORA), Article 26(2) (CELEX 32022R2554, Official Journal of the European Union, 2022-12-27)

Which playbooks does an insurance run use?

Five: Domain Recon, Web Application Pentest, Network Pentest, Cloud Pentest, and Active Directory Pentest. The identity-takeover path an insurer worries about runs on the Active Directory and Cloud playbooks.

If you run the operation

See the engine underneath this.

Tentacles, the Cybergraph, the approval gate every action passes through, and the operation ledger that records what ran. Insurance is one playbook on top of that engine.

If you own the risk

Start from the exposure, not the technique.

One playbook answers one question. The case for validating exposure at all — why a scanner score is not a finding, and what changes when something proves the path instead of ranking it — is the argument this page assumes.

Follow your identity graph to the claims file share.

Scope a run against a policy or claims environment.