Full-chain DORA TLPT scenario: 7 assume-breach stages mapped to DORA Art. 5-44. Validates detection, response & resilience across any SOC stack. Built for service providers running compliance tests across banking & insurance clients.
🏛️ DORA TLPT — ICT Risk Validation for Financial Services
This scenario simulates a full-chain Threat-Led Penetration Test (TLPT) as mandated by the Digital Operational Resilience Act (DORA) — Regulation (EU) 2022/2554 — targeting financial sector entities (banks, insurers, fintechs) and their critical ICT service providers.
DORA entered into force on January 17, 2025 and requires financial entities to demonstrate operational resilience against advanced cyber threats. Article 26 specifically mandates TLPT exercises at least every 3 years for significant financial entities. This scenario reproduces a realistic assume-breach attack chain — from initial reconnaissance to data exfiltration — designed to validate detection, response and resilience capabilities across any SOC stack. Each inject maps directly to a specific DORA article, producing a compliance coverage matrix that demonstrates to regulators which ICT controls are effective, partial, or absent.
Built for multi-national service providers (consulting firms, MSSPs) running the same scenario across multiple banking and insurance clients with different security stacks — the results provide an objective, comparable maturity assessment per client.
Article 26 — At least every 3 years for significant entities
Testing Standard
TIBER-EU framework (Threat Intelligence-Based Ethical Red Teaming)
Oversight
ESAs (EBA, EIOPA, ESMA) + national competent authorities
Penalties
Administrative fines + remediation orders from competent authorities
DORA Chapters Covered
Chapter
Articles
Focus
Validated by
II — ICT Risk Management
Art. 5-16
Protection, detection, prevention controls
Stages 2, 4, 6
III — ICT Incident Management
Art. 17-23
Incident detection, classification, notification
Stages 3, 7
IV — Resilience Testing
Art. 26-27
TLPT execution and reporting
All stages
V — Third-Party ICT Risk
Art. 28-44
Supply chain and lateral movement risk
Stage 5
🔗 Kill Chain — 7 Injects
Stage 1 — Discovery: System Information Reconnaissance
ATT&CK
T1082 — System Information Discovery
Delay
T+0s (scenario start)
DORA Mapping
Art. 26 — TLPT initial reconnaissance phase
Description
The first phase of any TLPT exercise: profiling the target environment. DORA Art. 26 requires testing to follow the TIBER-EU methodology, which begins with threat intelligence-driven reconnaissance. This stage collects OS version, domain membership, network configuration, running processes, and installed services — mirroring what an advanced persistent threat would gather after initial access.
What it does
Executes native Windows commands (systeminfo, ipconfig /all, Get-Process, Get-Service, whoami /all) to build a comprehensive system profile. Results are written to C:\ProgramData\OpenAEV\artifacts\.
Detection opportunities
Sysmon Event ID 1 (process creation for systeminfo, ipconfig, whoami), Windows Event ID 4688 (process creation with command-line logging), EDR alerts for rapid succession of discovery commands (>3 enumeration commands in <60 seconds from a single endpoint), SIEM correlation rules for reconnaissance patterns.
DORA Art. 9 requires financial entities to implement ICT protection and prevention measures that are resistant to tampering. This stage validates that security controls cannot be trivially disabled by an attacker with local access. If Tamper Protection is properly configured, this inject should fail — which is the desired outcome. A successful disable indicates a critical gap in the ICT risk management framework.
What it does
Attempts to disable Windows Defender Real-Time Protection, Behavior Monitoring, and IOAV Protection via Set-MpPreference. All original settings are backed up and restored during cleanup.
Detection opportunities
Windows Event ID 5001 (Real-time protection disabled), Tamper Protection alerts (if enabled — the inject is blocked and an alert is generated), EDR alerts for Set-MpPreference modification attempts, GPO/Intune compliance drift detection, Microsoft Defender for Endpoint tamper attempt events.
Stage 3 — Credential Access: LSASS Memory Dump via Comsvcs.dll
Credential theft is one of the most critical events in the DORA incident classification framework. Art. 18 defines criteria for major ICT-related incidents — compromise of authentication credentials affecting critical systems qualifies automatically. This stage tests whether the SOC detects the dump, classifies it correctly as a major incident, and triggers the Art. 19 notification process (initial notification to competent authority within 4 hours). Uses comsvcs.dll MiniDump — a Mimikatz-free technique that leverages a legitimate Windows DLL.
What it does
Dumps the LSASS process memory via rundll32.exe comsvcs.dll, MiniDump to C:\ProgramData\OpenAEV\artifacts\lsass_dump.dmp. Full cleanup removes the dump file.
Detection opportunities
Sysmon Event ID 10 (ProcessAccess on lsass.exe with GrantedAccess: 0x1FFFFF), Sysmon Event ID 1 (rundll32.exe with comsvcs.dll, MiniDump arguments), Windows Event ID 4656 (handle requested on LSASS), Credential Guard alerts (if enabled — dump is empty/unusable), ASR Rules "Block credential stealing from LSASS" (Defender — blocks the action), EDR credential dumping detection (high-confidence on all major EDR platforms).
DORA Art. 10 requires financial entities to detect "anomalous activities" including unauthorized changes to ICT systems. Persistence mechanisms — scheduled tasks, services, run keys — represent unauthorized system modifications that must be identified and investigated. This stage validates that the SOC detects new persistence artifacts and correlates them with the broader attack chain. An attacker maintaining persistent access to a financial institution's ICT systems represents an ongoing risk to operational resilience.
What it does
Creates a scheduled task (OpenAEV-DORA-Persistence) configured to execute an encoded PowerShell command every 15 minutes. The task is fully removed during cleanup — no durable attacker capability is left behind.
Detection opportunities
Windows Event ID 4698 (Scheduled task created), Sysmon Event ID 1 (schtasks.exe /create with encoded command arguments), Windows Event ID 4702 (task updated), EDR persistence alerts (scheduled task with encoded command = high-confidence malicious), SIEM rules for new scheduled tasks created outside change management windows, task entries in C:\Windows\System32\Tasks\.
Stage 5 — Lateral Movement: WMI Remote Execution
ATT&CK
T1047 — Windows Management Instrumentation
Delay
T+8min
DORA Mapping
Art. 28-44 — Third-Party ICT Risk Management
Description
Critical for the service provider use case. DORA Chapter V (Art. 28-44) addresses risks from ICT third-party service providers. A compromised service provider endpoint pivoting into a client's network is the nightmare scenario regulators are most concerned about. This stage simulates lateral movement via WMI — a native Windows protocol that is difficult to block entirely — to validate that cross-boundary movement is detected. For a multi-national service provider running this across different banking clients, this stage answers: "If our environment is compromised, would the client's SOC see us moving into their network?"
What it does
Executes Invoke-WmiMethod to simulate process creation on remote machines. Generates WMI connection artifacts, RPC/DCOM network traffic, and remote logon events consistent with real lateral movement.
Detection opportunities
Sysmon Event ID 1 (wmiprvse.exe spawning child processes), Windows Event ID 4648 (logon with explicit credentials), Windows Event ID 4624 Type 3 (network logon on target), Sysmon Event ID 3 (network connection to port 135 — RPC/WMI), EDR lateral movement alerts, NDR/network monitoring for unusual RPC/DCOM traffic between workstations, Microsoft Defender for Identity lateral movement path detection.
Art. 5-16 — ICT Risk Management (access control validation)
Description
Before targeting high-value assets, advanced threat actors map the Active Directory environment to identify trust relationships, privileged accounts, and security policy weaknesses. DORA Art. 9 requires robust access control and authentication mechanisms — this stage validates that enumeration attempts against the identity infrastructure are detected. If an attacker can silently map all Domain Admins, trust relationships, and password policies, the access control framework has a visibility gap.
What it does
Executes AD reconnaissance commands (nltest /domain_trusts, net group "Domain Admins" /domain, Get-ADDefaultDomainPasswordPolicy, Get-ADUser filtering for privileged accounts). Results are written to a controlled artifact directory.
Detection opportunities
Sysmon Event ID 1 (nltest.exe /domain_trusts, net.exe group), Windows Event ID 4661/4662 (handle requested / operation performed on AD objects), LDAP monitoring (bulk LDAP queries from a non-DC endpoint), Microsoft Defender for Identity alerts ("Reconnaissance via LDAP", "Account Enumeration"), honeypot/decoy account triggers (if canary accounts appear in results → immediate high-fidelity alert), SIEM rules for AD enumeration patterns.
🎯 Stage 7 — Exfiltration: Data Staging & Simulated Upload
The culmination of the attack chain. Data exfiltration from a financial institution is automatically classified as a major ICT-related incident under Art. 18 — triggering mandatory notification to the competent authority (Art. 19), communication to affected clients (Art. 20), and post-incident review (Art. 23). This stage validates the entire incident response pipeline: detection of staging activity, alerting on exfiltration attempt, SOC triage and classification, and initiation of the regulatory notification process. The exfiltration targets localhost only (127.0.0.1) — safe-by-design, no data leaves the network.
What it does
Creates simulated sensitive files (marked "SIMULATED — DORA TLPT"), compresses them into a .zip archive, and executes an HTTP POST to http://127.0.0.1:9999 (non-existent endpoint). Generates all the artifacts a real exfiltration would produce: file access, compression, network connection attempt. Full cleanup removes all staged data, archives, and artifacts.
Detection opportunities
Sysmon Event ID 1 (Compress-Archive PowerShell execution), Sysmon Event ID 3 (outbound network connection), DLP alerts (compressed archive containing sensitive file patterns), proxy/CASB alerts (HTTP POST of archive file to non-whitelisted destination), EDR "Data Staging" or "Exfiltration" alerts (compression + network activity correlation), network monitoring for unusual outbound data volume from endpoint, Windows Event ID 4688 (process creation with staging directory paths).
🔒 Security Checklist
Criterion
Status
No C2 / reverse shell / beacon
✅ All traffic stays local (127.0.0.1) or uses native Windows protocols
No real malware / ransomware binaries
✅ Only native Windows tools and PowerShell commands
No actual data exfiltration
✅ HTTP POST targets localhost:9999 (non-existent endpoint)
Cleanup removes all artifacts
✅ Dumps, archives, staged files, reconnaissance output all cleaned
Designed for multi-national service providers running DORA TLPT across diverse client portfolios:
Client Profile
Typical SOC Stack
Key Validation Points
Tier 1 Bank
CrowdStrike + Splunk + Palo Alto
Full kill chain detection + cross-stage correlation
Insurance Group
Microsoft Defender + Sentinel + Intune
Tamper Protection + Credential Guard + ASR rules
Regional Bank
SentinelOne + QRadar + Fortinet
WMI lateral movement detection + exfiltration alerting
Fintech / Neobank
Cortex XDR + XSOAR + Cloudflare
Automated response validation + time-to-contain
Payment Processor
Carbon Black + ArcSight + Zscaler
Persistence detection + data staging visibility
Each inject produces stack-agnostic artifacts (Windows Event IDs, Sysmon events, process creation logs, network activity) — detectable regardless of the EDR/SIEM combination deployed.
🔄 Continuous Compliance vs. One-Shot Pentest
Traditional Pentest
OpenAEV DORA TLPT Scenario
Frequency
Once every 3 years (Art. 26 minimum)
Continuous — replayable on demand
Reproducibility
Depends on the pentester
100% reproducible, identical scenario every run
Multi-client
Tested on 1 environment per engagement
Same scenario across N clients with N different SOC stacks
Measurability
Static PDF report
Real-time metrics: MTTD per stage, detection rate, ATT&CK coverage
Regulatory evidence
Point-in-time report
Continuous test history + results = proof of ongoing diligence
Cost per run
€€€ per engagement
Scenario reusable, marginal cost per execution ≈ 0
Comparability
No standardized baseline
Same scenario = objective cross-client benchmarking
📈 Value Proposition
Regulation-mapped realism — Every stage maps directly to specific DORA articles (Art. 5-16, 17-23, 26-27, 28-44), producing a compliance coverage matrix ready for regulatory review
Detection + Response validation — Goes beyond "detected yes/no" to measure MTTD (Mean Time to Detect), MTTR (Mean Time to Respond), and incident classification accuracy
Multi-stack portability — Stack-agnostic artifacts ensure consistent validation across CrowdStrike, Defender, SentinelOne, Cortex XDR, or any other EDR/SIEM combination
Service provider scale — One scenario, N clients — enables objective cross-client maturity benchmarking for consulting firms and MSSPs
Safe-by-design — Full execution on production-like environments without risk: no C2, no real exfiltration, complete cleanup and rollback
Continuous compliance — Transforms a 3-year regulatory obligation into an operational advantage: ongoing validation that improves security posture between audits
We use cookies to make the XTM Hub work, understand how it's used, and improve your experience. Strictly necessary cookies are always on. With your consent, we also use optional cookies for functionality, performance and analytics, and marketing. You can accept all, reject all, or choose which optional cookies to allow. You can change your preferences at any time via "Cookie settings". See our Cookie Policy for more information.