Banking & fintech

Regulators want proof you can take a real attack. Cracken runs the attack and hands you the evidence.

The tradecraft behind real bank intrusions, run against your own estate.

The run works your Active Directory, internal network, cloud and web estate under per-action approval, proves how far a foothold carries toward payments, and produces regulator-ready evidence you can re-run, not once a year. It stops at the boundary: the run proves reach, it moves no money.

Book a demo
See the platform
Definition

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

DORA threat-led penetration testing (TLPT) is the adversarial test EU financial entities must run at least every three years, on live production systems, under Article 26 of Regulation (EU) 2022/2554. The obligation is DORA's. TIBER-EU is the European Central Bank's framework for conducting one, and adopting it is a supervisory choice, not a requirement the regulation imposes. — DORA Article 26(1)-(2) (CELEX 32022R2554 — applicable from 2025-01-17, Official Journal of the European Union, 2022-12-27)

Run the tradecraft, tagged to ATT&CK

The AD, network, cloud and web playbooks execute the post-entry tradecraft a bank intrusion uses, with every step recorded against ATT&CK v19.0.

Measure the reach toward payments

Tests which routes carry a foothold to the segment fronting the payment switch, and in how many hops. The switch stays a reachability question, never a target.

Evidence a DORA or TIBER-EU assessment expects

Every command, its output and its artifacts land in the operation ledger, so any finding traces back to what produced it.

The cloud and the APIs you expose

Cloud Pentest and Web App Pentest work your control plane and the open-banking interfaces you publish, from the outside in.

Lazarus / APT38 (North Korea RGB), tracked as G0082 in MITRE ATT&CK — phished into banks, moved to the payment switch and issued fraudulent SWIFT transfers, including the Bangladesh Bank heist.

How far Cracken follows APT38, and where it stops

The crew did not crack the vault. It phished in and let SWIFT do the rest. Cracken picks the chain up after entry and stops before the money.

  1. 1Initial access
    Attacker

    Spear-phish or watering hole.

    With Cracken

    The run starts from the exposure Domain Recon finds, an app Web App Pentest exploits, or an account you issue it.

  2. 2Credential access
    Attacker

    Harvests credentials and Kerberos tickets on the way in.

    With Cracken

    AD Pentest kerberoasts the SPNs, hunts constrained delegation, and finds the misconfigured certificate template.

  3. 3Privilege escalation
    Attacker

    Escalates to domain rights.

    With Cracken

    Requests a certificate as a Domain Admin, authenticates over PKINIT, and DCSyncs krbtgt — proven, with the command and its output attached to the finding.

  4. 4Lateral movement
    Attacker

    Pass-the-hash toward payments.

    With Cracken

    Walks every route those credentials open, host by host, and writes the paths to the Cybergraph.

  5. 5Access to payments
    Attacker

    Reaches the SWIFT interface or the switch.

    With Cracken

    Tests which deny rules hold on the path to the segment fronting the switch, and records source, destination, port and outcome.

  6. 6Fraudulent transfer
    Attacker

    Sends instructions, wipes traces.

    With Cracken

    The run stops at proving reach. No payment instruction is issued, no money moves and no log is touched.

One run

One standard domain account to domain dominance, and the reach toward the payment switch.

A bank's internal estate: one Windows forest holding the corporate domain, a start from one standard domain account, and the segment fronting the payment switch named in the rules of engagement as a reachability question, not a target. Domain, host and account names are illustrative.

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 AD Pentest discovery sub-operation enumerated the corporate domain over Kerberos with nxc and bloodhound-ce-python, then ran certipy-ad find against the CA.

    T1558.003 Kerberoasting
    What it established

    The DC, the domain's users and computer accounts, and candidate edges in the Cybergraph: Kerberoastable SPNs, constrained-delegation accounts, and one certificate template flagged ESC1.

  2. 02
    What ran

    An exploit sub-operation requested a certificate from the ESC1 template with certipy-ad using a Domain Admin's UPN, authenticated over PKINIT and unPAC'd the NT hash, then a verify sub-operation ran impacket-secretsdump against the DC for krbtgt.

    T1649 Steal or Forge Authentication Certificates; T1003.006 DCSync
    What it established

    krbtgt replicated. PROVEN — one standard domain account to domain dominance, recorded with the command and captured output attached to the finding. No AD object was changed; the template was already misconfigured.

  3. 03
    What ran

    A Network Pentest reachability sub-operation read the ACLs and firewall rules on the path from a domain-joined host, then tested reachability toward the segment fronting the payment switch with nmap against the ports the policy declares denied.

    T1046 Network Service Discovery
    What it established

    Which deny rules held under traffic and which did not, recorded as source, destination, port and observed outcome. Reach was proven to the segment boundary; the switch itself stayed out of scope as a target.

  4. 04
    What ran

    Every command, its output and the artifacts land in the operation ledger; hosts, accounts and the paths between them are written to the Cybergraph.

    What it established

    A trail that runs from any finding back to the command that produced it — the report contents a DORA or TIBER-EU assessment is written to expect.

What this did not prove: The run moves no money. It started from one standard domain account, so it proves nothing about the entry step that opens a real APT38 chain. Reaching the system that issues payments and issuing one are different results, and only the first is on the table.

MITRE ATT&CK v19.0, April 2026

Prove the route to payments before someone else walks it.

A general-purpose assistant will discuss the attack. Cracken's model runs it — against your named domain, under per-action approval, with every command and its output kept. That is what turns the once-a-year red team into a run you repeat.

?

Exploit the path, don't describe it

Cracken requests the certificate, authenticates as the admin and pulls krbtgt in your domain, then reproduces the step before it records it.

?

Commission the playbook your estate needs

Write the operation for your identity, network, cloud and web estate, and re-run it whenever the estate changes.

It stops where you say it stops

An intrusiveness ceiling and per-action approval bound the run: it proves reach toward payments, moves no money, and tampers with no log.

Turn the once-a-year red team into a run you repeat. Walk into your next exam with the evidence.
Questions

What a bank CISO asks before scoping a run

Does DORA make TIBER-EU mandatory?

No. DORA is binding law; TIBER-EU is a method, not a mandate. Article 26 of Regulation (EU) 2022/2554 requires designated financial entities to carry out threat-led penetration testing at least every three years, on live production systems. TIBER-EU is the European Central Bank's framework that authorities have adopted for conducting that TLPT — but the obligation is DORA's. Article 26(11) requires the technical standards to be developed in accordance with TIBER-EU, but the regulation does not oblige an entity to adopt the framework itself — a vendor who calls TIBER-EU compulsory is overstating it. — DORA Article 26(1)-(2) (CELEX 32022R2554 — applicable from 2025-01-17, Official Journal of the European Union, 2022-12-27)

Can Cracken test our live production systems, the way DORA's TLPT requires?

DORA Article 26 requires the advanced test to be 'performed on live production systems supporting such functions.' A scanner reads versions; it does not exercise a live path. Cracken runs the tradecraft against the scoped estate under per-action approval and an intrusiveness ceiling, stopping short of anything that moves money or tampers with logs — proving the path held on the day it ran, on the systems the regulation names. — DORA Article 26(1)-(2) (CELEX 32022R2554 — applicable from 2025-01-17, Official Journal of the European Union, 2022-12-27)

Our vulnerability scanners already give us the findings. Why add this?

FS-ISAC's April 2026 sector risk advisory put it plainly: 'Traditional assumptions and approaches for vulnerability management no longer hold,' according to the advisory reported by the ABA Banking Journal. A scanner ranks findings by score; it cannot tell you which of them an attacker chains to reach your payment systems. Cracken validates the exploitable path and reports what held, not what merely scored high. — FS-ISAC sector risk advisory, reported by ABA Banking Journal (American Bankers Association (ABA Banking Journal), 2026-04-20)

What actually hits banks — is this a real threat or a compliance exercise?

Both. ENISA's Threat Landscape 2025 records the finance sector at 4.7% of all collected EU incidents, concentrated in the banking subsector at 21.6% of finance cases. Within the cybercrime incidents ENISA collected for the sector, data breaches accounted for 64% and ransomware 36%, with Akira (20%), Datacarry (12%) and BlackLock (4%) the strains reportedly deployed against EU financial institutions. — ENISA Threat Landscape 2025, section 5.4 Finance (v1.2 (revised 2026-01-09), European Union Agency for Cybersecurity (ENISA), 2025-10)

Will you phish our staff, or write malware against our core banking stack?

Only what you scope. Domain Recon, Web App Pentest, Network Pentest, Cloud Pentest and AD Pentest run against the estate you name, and a run starts from the exposure you publish or an account you issue it, working the identity, network, cloud and web estate from there. It writes no malware against your core banking stack and emulates no payment fraud: an intrusiveness ceiling and per-action approval bound every step.

You've named no bank customer. Have you run this against a real bank?

No. Cracken has no signed bank customer, and nothing on this page implies one. What you see here is the shape of an authorized run written from the playbooks Cracken runs — Domain Recon, Web App Pentest, Network Pentest, Cloud Pentest and AD Pentest — not a customer engagement. The only way to know what it finds in your environment is to scope a run against it.

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. Banking & fintech 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.

Use cases

Playbooks for Banking & fintech

See all use cases

Turn your next DORA assessment into a run you can repeat.

Scope a threat-led run against your estate and see what the evidence looks like.

Book a demo