🏛️ DORA TLPT — ICT Risk Validation for Financial Services

Category: Attack Scenario | Severity: 🔴 Critical | Focus: Incident Response

---

📋 Executive Summary

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.

---

🧠 Regulatory Framework Profile

| Attribute | Details | |---|---| | Regulation | DORA — Regulation (EU) 2022/2554 | | Effective Date | January 17, 2025 | | Scope | Banks, insurers, investment firms, crypto-asset providers, critical ICT third-party providers | | TLPT Requirement | 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. |

---

Stage 2 — Defense Evasion: Defender Tampering

| | | |---|---| | ATT&CK | T1562 — Impair Defenses | | Delay | T+2min | | DORA Mapping | Art. 5-16 — ICT Risk Management Framework (control resilience) | | Description | 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

| | | |---|---| | ATT&CK | T1003.001 — OS Credential Dumping: LSASS Memory | | Delay | T+4min | | DORA Mapping | Art. 17-23 — ICT Incident Management (major incident trigger) | | Description | 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). |

---

Stage 4 — Persistence: Scheduled Task Creation

| | | |---|---| | ATT&CK | T1053.005 — Scheduled Task/Job: Scheduled Task | | Delay | T+6min | | DORA Mapping | Art. 5-16 — ICT Risk Management (anomaly detection) | | Description | 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. |

---

Stage 6 — Discovery: Domain Trust & Privileged Account Enumeration

| | | |---|---| | ATT&CK | T1482 — Domain Trust Discovery / T1087 — Account Discovery | | Delay | T+10min | | DORA Mapping | 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

| | | |---|---| | ATT&CK | T1567 — Exfiltration Over Web Service | | Delay | T+12min | | DORA Mapping | Art. 17-23 — ICT Incident Management (major incident — data breach) | | Description | 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 | | Cleanup removes persistence | ✅ Scheduled task fully deleted | | Cleanup restores security settings | ✅ Defender preferences restored to original state | | ATT&CK mapping on every inject | ✅ 8 techniques mapped across 7 tactics | | DORA article mapping on every inject | ✅ Art. 5-16, 17-23, 26-27, 28-44 covered | | Safe for production-like environments | ✅ No destructive actions, complete rollback |

---

📊 DORA Compliance Coverage Matrix

| DORA Requirement | Articles | What the Scenario Validates | Pass Criteria | |---|---|---|---| | ICT protection controls resist tampering | Art. 9 | Stage 2 — Defender tampering is blocked | Tamper Protection prevents disable + alert generated | | Anomalous activities are detected | Art. 10 | Stages 1, 4, 6 — Discovery & persistence detected | SOC alerts on reconnaissance and unauthorized system changes | | Credential protection mechanisms work | Art. 9 | Stage 3 — LSASS dump is prevented or detected | Credential Guard / ASR blocks dump OR EDR alerts within <5min | | Major incidents are classified correctly | Art. 18 | Stages 3, 7 — Credential theft & exfiltration flagged as major | SOC classifies as major incident per Art. 18 criteria | | Notification process is triggered | Art. 19 | Stage 7 — Exfiltration triggers notification workflow | Initial notification to authority within 4 hours | | Third-party lateral movement is visible | Art. 28-44 | Stage 5 — WMI movement detected across boundaries | Network logon + WMI activity generates alert | | TLPT is executed per TIBER-EU | Art. 26-27 | Full scenario — 7 stages, complete kill chain | Scenario executed, results documented, gaps identified |

---

🏦 Multi-Client Deployment (Service Provider Model)

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

1. 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
2. Detection + Response validation — Goes beyond "detected yes/no" to measure MTTD (Mean Time to Detect), MTTR (Mean Time to Respond), and incident classification accuracy
3. Multi-stack portability — Stack-agnostic artifacts ensure consistent validation across CrowdStrike, Defender, SentinelOne, Cortex XDR, or any other EDR/SIEM combination
4. Service provider scale — One scenario, N clients — enables objective cross-client maturity benchmarking for consulting firms and MSSPs
5. Safe-by-design — Full execution on production-like environments without risk: no C2, no real exfiltration, complete cleanup and rollback
6. Continuous compliance — Transforms a 3-year regulatory obligation into an operational advantage: ongoing validation that improves security posture between audits
7. Audit-ready output — Results directly feed DORA Art. 27 reporting requirements (TLPT results, identified gaps, remediation plans)

---

Total execution time: ~12 minutes | 7 injects | 8 ATT&CK techniques | 7 tactics covered | 4 DORA chapters validated