Financial Services Sector
Three Real-World Purple Team Engagements | Fully Anonymised | ISO 17025 Accredited Methodology
ISO 17025 Accredited · MITRE ATT&CK v15 · All engagements conducted under explicit written authorisation
Sector
Financial Services
Engagement
Purple Team Exercise
ATT&CK Tactics
MITRE ATT&CK v15
Location
United States
About These Case Studies
The following case studies describe real purple team engagements conducted by GLI Secure across financial services sector organisations. All identifying details, organisation names, locations, system names, and personnel, have been fully anonymised. Statistical outcomes, detection improvements, and regulatory findings are accurate as documented during and after each engagement.
All purple team exercises described in this document were conducted under explicit written authorisation from the client organisation, using GLI Secure’s ISO 17025-accredited testing methodology. MITRE ATT&CK technique IDs are referenced as documented in ATT&CK Enterprise Framework v15.
Confidentiality Notice: These case studies anonymised; any resemblance to specific organisations is coincidental.
Case Study FIN-CS-01
DORA TLPT Preparation, EU Asset Management Firm
Purple team readiness exercise ahead of mandatory DORA Threat-Led Penetration Test
Organisation
An EU-headquartered asset management firm with €180B AUM, significant in scope under DORA (anonymised)
Sector
Financial Services, Asset management, institutional investment
Location
Luxembourg and Germany
Engagement
Purple Team Exercise, DORA TLPT Readiness and ICT Risk Management Validation
Duration
9 weeks (4-week scoping, 3-day exercise, 2-week TLPT readiness report)
Frameworks
DORA Regulation (EU) 2022/2554 Articles 5–16, 26 | TIBER-EU Framework | MITRE ATT&CK Enterprise v15 ECB CROE
The Situation
DORA came into full effect in January 2025. As a significant financial entity, the firm was subject to Article 26’s mandatory TLPT requirement, conducted by an independent external tester using real threat intelligence, with results submitted to BaFin and CSSF. The firm had never undergone a TLPT. Its closest prior experience was an annual penetration test conducted by a German IT security firm.
The management body had received a DORA briefing from external counsel that left them with a clear understanding: under DORA, the management body was personally accountable for ICT risk management failures. A failed TLPT or a significant ICT incident revealing inadequate controls could expose individual management body members, not just the institution.
The firm engaged GLI Secure to conduct a purple team readiness exercise ahead of the formal TLPT, to identify and close gaps before an accredited TLPT tester examined the environment.
Core Challenge
Identify the detection and response gaps that would be exposed in a formal DORA TLPT, and produce the ICT risk management documentation improvements required to satisfy BaFin and CSSF examination standards.
What GLI Secure Did
We constructed a threat intelligence profile for the firm based on the GTI component of the TIBER-EU framework. This identified Lazarus Group, APT41, and financially motivated Eastern European groups as the highest-relevance threat profiles for an asset manager with €180B AUM.
The exercise simulated four attack scenarios from the threat intelligence profile: spear-phishing targeting senior investment professionals, API attack on the client portal, supply chain compromise via a prime broker connection, and privileged access abuse by a rogue IT administrator.
All findings were mapped to DORA ICT risk management requirements (Articles 5–16) and structured in the format expected by BaFin and CSSF examiners.
The Purple Team Approach
Threat Intelligence Profile (GTI Approach)
Developed firm-specific threat intelligence profile using OSINT and sector-specific threat data. Identified Lazarus Group SWIFT-targeting TTPs and APT41 investment data exfiltration techniques as highest-relevance threat profiles.
Spear-Phishing Simulation (Investment Professionals)
Sent targeted spear-phishing to 12 senior investment professionals using market intelligence lures. 4 of 12 clicked (33%). Two provided simulated credentials on the harvesting page.
Client Portal API Attack
Tested the client reporting portal for BOLA vulnerabilities. Found 2 API endpoints allowing one client to access another client's portfolio data.
Prime Broker Connection Lateral Movement
Found the prime broker integration had broader network access than its contractual scope required, a DORA Article 28 third-party ICT risk management gap.
Privileged Access Abuse
Simulated a rogue IT administrator accessing investment system databases directly. Found: no Database Activity Monitoring, no PAM controls on DBA accounts, and audit logs modifiable with DBA-level access.
DORA ICT Risk Management Gap Assessment
Mapped all exercise findings to DORA Articles 9, 10, 13, and 16. Identified 12 specific gap areas requiring remediation before formal TLPT.
MITRE ATT&CK Techniques Tested
| ATT&CK ID | Technique | Detection Result |
|---|---|---|
| T1566.002 | Spear Phishing (Investment Targeting) |
PARTIAL
Email security blocked 8 of 12 (67%). 4 delivered. |
| T1528 | Steal Application Access Token (Portal) |
NOT DETECTED
No API-level monitoring on client portal. |
| T1199 | Trusted Relationship (Prime Broker Connection) |
NOT DETECTED
No behavioural monitoring on prime broker API sessions. |
| T1213 | Data from Information Repositories (Investment) |
NOT DETECTED
No DAM on investment databases. |
| T1070 | Indicator Removal (Audit Log Manipulation) |
NOT DETECTED
Audit logs accessible and mutable by DBA. |
| T1021.001 | Remote Desktop Protocol (Lateral Movement) |
DETECTED
SIEM alert in 11 minutes. Within target. |
Key Findings
Critical
2 Client Portal BOLA Vulnerabilities:
Two API endpoints allowed cross-client portfolio data access. In a regulated asset management context, this represents both a DORA security failure and a potential market abuse risk under MAR.
Critical
Audit Log Mutable by DBA:
DORA Article 8 requires tamper-evident audit trails. Mutable audit logs fail this requirement and create personal management body liability.
HIGH
Prime Broker Integration Overscoped:
DORA Article 28 third-party ICT risk management failure, third-party access must be limited to what is strictly necessary.
High
33% Investment Professional Spear-Phishing Success:
One-third of targeted investment professionals clicked on simulated phishing, a significant DORA Article 13 security awareness gap.
medium
No API Security Monitoring:
DORA requires continuous monitoring of ICT systems. API-level monitoring of client-facing financial services portals is specifically required.
Measurable Outcomes
| BOLA Vulnerabilities | Both patched within 14 days |
| Audit Log Integrity | Immutable audit log infrastructure implemented within 45 days |
| Prime Broker Scope | Integration rescoped to minimum necessary access within 30 days |
| API Monitoring | API security monitoring deployed on client portal |
| DORA TLPT Readiness | 12 gap areas reduced to 2, TLPT readiness assessment: READY |
| Management Body Briefing | Quarterly ICT risk reporting format implemented per DORA requirements |
Regulatory Impact
The exercise produced direct evidence for DORA Article 26 TLPT readiness. GLI Secure’s ISO 17020 field inspection accreditation is the qualifying standard for DORA TLPT independent testers, meaning the readiness exercise was conducted by an organisation already positioned to conduct the formal TLPT itself.
The mutable audit log finding created direct DORA Article 8 exposure. Audit logs that can be modified by privileged users do not satisfy the DORA requirement, and critically create personal management body liability under DORA’s accountability framework.
The cross-client BOLA vulnerabilities have implications beyond cybersecurity. In asset management, access to another client’s portfolio data could constitute market abuse under MAR. The compliance team was briefed on the MAR implications within 24 hours, resulting in an accelerated remediation timeline.
“
DORA gave our management body a new problem: personal accountability for ICT risk management failures. The purple team exercise gave us something to do about it, a structured, independently-assessed view of where our ICT controls actually stood versus where our documentation said they stood. The cross-client API vulnerability alone would have been a regulatory disaster in a formal TLPT.
— Chief Risk Officer, Asset Management Firm (anonymised)
Key Takeaways
- DORA personal management body accountability has transformed ICT risk management from an IT concern to a board-level liability. Purple team exercises produce the independently-validated evidence that management bodies need to discharge their personal obligations.
- BOLA API vulnerabilities in financial services have dual regulatory implications, cybersecurity and market integrity. API security testing must be on the agenda of every financial services organisation with client-facing digital infrastructure.
- ISO 17020 accreditation positions GLI Secure as a DORA TLPT qualifying tester, enabling a seamless pathway from purple team readiness exercise to formal TLPT submission.
- TIBER-EU's threat intelligence-led approach produces more relevant findings than generic penetration testing. The GTI/TTI framework ensures the exercise tests the actual adversary profile.
Ready to test your Financial Services security defences?
Case Study FIN-CS-02
Open Banking API Security, UK Digital Bank
Organisation
A UK-licensed digital bank with 820,000 active current account customers (anonymised)
Sector
Financial Services, Digital banking, FCA-regulatedEducation — K-12 public school district
Location
United Kingdom
Engagement
Purple Team Exercise, Open Banking API Security and PSD2 SCA Compliance
Duration
6 weeks (2-week scoping, 2-day exercise, 2-week remediation and FCA evidence package)
Frameworks
PSD2 RTS on SCA (Delegated Regulation EU 2018/389) | FCA OBIE Standards | OWASP API Security Top 10 2023 UK GDPR | MITRE ATT&CK Enterprise v15
The Situation
Open Banking had enabled 47 third-party integrations central to the digital bank’s growth strategy. The bank’s security team had identified API security as their highest-priority concern following FCA industry letters in 2024 warning about credential stuffing, BOLA vulnerabilities, and SCA bypass attacks against Open Banking infrastructure.
The bank had never conducted a dedicated Open Banking security exercise. Its annual penetration test covered the mobile application and web banking interface but did not address the Open Banking APIs or the PSD2 SCA implementation. The security team suspected SCA gaps, but had no independent evidence before an FCA supervisory visit scheduled for the following quarter.
The goal: exercise findings and remediation evidence in hand before the FCA visit.
Core Challenge
Identify exploitable vulnerabilities in the bank’s Open Banking API infrastructure and SCA implementation that would be found in an FCA supervisory examination, and produce the PSD2 RTS compliance evidence package.
What GLI Secure Did
We conducted a comprehensive Open Banking API security assessment covering all 47 TPP integrations, AIS and PIS endpoints, and the bank’s SCA implementation across all three authentication flows.
The exercise tested the most impactful attack techniques: credential stuffing against the OAuth endpoint, BOLA testing across all API endpoints, SCA bypass via push notification fatigue and redirect manipulation, and token theft via mobile application reverse engineering.
All findings were mapped to PSD2 RTS requirements and structured as an FCA supervisory examination-ready evidence package.
The Purple Team Approach
Open Banking API Enumeration
Mapped all 47 TPP integrations, 23 AIS endpoints, and 8 PIS endpoints. Identified 3 legacy endpoints from a previous API version that were still active and unauthenticated.
OAuth Security Assessment
Found: token expiry set to 24 hours rather than the PSD2 RTS-required 90-day maximum with explicit consent refresh, creating both over-permission and a compliance gap.
BOLA Testing (All 47 TPP Integrations)
Found 4 BOLA vulnerabilities across 3 TPP integration endpoints, allowing one TPP to access another customer's account data.
SCA Bypass Testing
The mobile SCA push notification flow was vulnerable to push fatigue. Number matching was not implemented. An attacker with customer credentials could approve a fraudulent transaction by sending repeated push notifications.
Unauthenticated Legacy API Endpoints
2 of the 3 decommissioned but still-active legacy endpoints returned account balance information without authentication, a direct PSD2 strong authentication requirement violation.
FCA Evidence Package Assembly
Structured all findings, remediation evidence, and compliance mapping in FCA supervisory format, including specific PSD2 RTS article references for each finding.
MITRE ATT&CK Techniques Tested
| ATT&CK ID | TECHNIQUE | DETECTION RESULT |
|---|---|---|
| T1110.004 | Credential Stuffing (OAuth Endpoint) |
PARTIAL
Rate limiting present but insufficient. 100 req/min allowed before lockout. |
| T1528 | Steal Application Access Token |
NOT DETECTED
Token theft via mobile reverse engineering, no detection. |
| T1190 | Exploit Public-Facing Application (BOLA) |
NOT DETECTED
No API anomaly detection on object-level access. |
| T1621 | MFA Push Notification Fatigue (SCA Bypass) |
NOT DETECTED
No push fatigue detection or number matching. |
| T1550 | Alternate Authentication Material (Legacy Endpoints) |
NOT DETECTED
Legacy endpoints unauthenticated and unmonitored. |
Key Findings
Critical
2 Unauthenticated Legacy Endpoints Returning Account Data:
Direct violation of PSD2 Articles 66/67 strong authentication requirement. Would be an immediate enforcement finding in an FCA examination.
Critical
SCA Push Notification Fatigue Vulnerability:
No push fatigue detection and no number matching, a social engineering technique documented in FCA fraud pattern reports that can approve fraudulent high-value transactions.
CRITICAL
4 BOLA Vulnerabilities in TPP Integrations:
Cross-customer data access via three TPP integration endpoints, potentially exposing customer financial data at scale.
High
OAuth Token Expiry Non-Compliant:
The bank’s consent management implementation did not link token expiry to explicit consent refresh, a PSD2 RTS Article 10 compliance gap.
Medium
Insufficient OAuth Rate Limiting:
100 requests per minute before lockout, sufficient for a distributed credential stuffing botnet.
Measurable Outcomes
| Legacy Endpoints | Both unauthenticated endpoints decommissioned within 24 hours |
| SCA Push Fatigue | Number matching implemented within 21 days |
| BOLA Vulnerabilities | All 4 patched within 30 days |
| FCA Evidence Package | PSD2 RTS compliance evidence delivered before FCA visit |
| FCA Supervisory Visit | No enforcement findings raised, compliance evidence accepted |
Regulatory Impact
The two unauthenticated legacy endpoints represented an active PSD2 RTS violation. The FCA has taken enforcement action against firms for precisely this type of oversight in its Open Banking examination programme.
The SCA push fatigue vulnerability represented a PSD2 RTS Article 4 compliance gap. The RTS requires that SCA measures prevent the compromise of authentication codes, a push notification flow without fatigue detection does not satisfy this requirement.The SIS backup failure has direct FERPA implications. A three-month data loss scenario following a ransomware event would compromise the district’s ability to certify the accuracy of student records for federal funding purposes.
Producing a PSD2 RTS compliance evidence package before the FCA visit, covering all seven RTS chapter areas, enabled the bank to demonstrate active compliance management. This posture is materially important in FCA examinations.
“
We had 47 TPP integrations and an FCA visit coming up. We suspected there were gaps in our SCA implementation but had no independent evidence. The purple team exercise found two unauthenticated legacy endpoints that would have been an immediate enforcement finding, and they had been live for over six months. We decommissioned them within 24 hours. Going into the FCA visit with a comprehensive remediation package rather than two open critical vulnerabilities was the difference between a productive supervisory engagement and an enforcement action.
— Head of Technology Risk, Digital Bank (anonymised)
Key Takeaways
- Decommissioned API endpoints that remain live are one of the most common and highest-risk findings in Open Banking security assessments. Legacy endpoint lifecycle management must be as rigorous as new endpoint security.
- PSD2 SCA push notification fatigue is a documented fraud technique that regulators specifically examine. Number matching is the minimum control for mobile SCA push flows.
- BOLA vulnerabilities in Open Banking APIs require manual testing of each TPP integration endpoint, they cannot be found with automated scanning. Open Banking API security requires dedicated expert assessment.
- FCA supervisory examination preparation is most effective when findings and remediation evidence are produced together, structured as an FCA-ready compliance package.
Ready to test your Financial Services security defences?
Case Study FIN-CS-03
SWIFT Infrastructure Attack, International Trade Finance Bank
Testing SWIFT CSP controls against a Lazarus Group attack profile targeting correspondent banking infrastructure
Organisation
A mid-tier international bank with SWIFT connectivity processing approximately $4.2B in daily transactions (anonymised)
Sector
Financial Services, Commercial banking, trade finance, international payments
Location
Singapore (APRA-regulated subsidiary; MAS TRM Guidelines applicable)
Engagement
Purple Team Exercise, SWIFT CSP Control Validation and Correspondent Banking Security
Duration
8 weeks (3-week scoping, 2-day exercise, 3-week MAS TRM remediation report)
Frameworks
SWIFT Customer Security Programme (CSP) Mandatory Controls | MAS TRM Guidelines 2021 | APRA CPS 234 | MITRE ATT&CK Enterprise v15
The Situation
The Lazarus Group’s theft of $80 million from Bangladesh Bank through SWIFT manipulation remains the defining case study in international banking cybersecurity. In 2024 and 2025, CISA and FBI jointly attributed additional SWIFT-targeting activity to Lazarus Group subsidiaries, indicating the threat remained active against mid-tier correspondent banks.
The bank processed approximately $4.2 billion in daily SWIFT transactions. Its SWIFT CSP self-assessment had been submitted annually but never independently validated. The bank’s MAS TRM Review was scheduled for the following year, and TRM Principle 9 (cyber resilience) specifically addressed the adequacy of SWIFT security controls.
The bank engaged GLI Secure to validate the operational effectiveness of SWIFT CSP mandatory controls, not just whether the self-attestation was accurate, but whether controls would actually prevent a Lazarus Group-style attack.
Core Challenge
Validate the operational effectiveness of SWIFT CSP mandatory controls against a Lazarus Group-profile attack, and identify gaps between self-attested compliance and actual control effectiveness that a MAS TRM review would surface.
What GLI Secure Did
We constructed a Lazarus Group attack profile based on documented TTPs from the Bangladesh Bank attack, the 2023 Lazarus cryptocurrency exchange attacks, and CISA/FBI joint advisories.
The exercise tested the SWIFT CSP mandatory controls directly: secure zones and network protection, privileged account management on SWIFT-connected systems, interactive session integrity, and back office transaction data protection.
We also tested whether the bank’s monitoring would detect a Lazarus-pattern attack in progress, specifically the 3-hour window between initial SWIFT system access and fraudulent payment instruction transmission that characterised the Bangladesh Bank attack.
The Purple Team Approach
SWIFT Environment Mapping
Mapped all SWIFT-connected systems including Alliance Gateway, SAA, and local SWIFT interfaces. Identified 12 systems with SWIFT environment connectivity not in the bank's documented SWIFT secure zone.
SWIFT Secure Zone Boundary Testing
Found: 3 firewall rules permitted communication from the corporate network to SWIFT-adjacent systems outside the documented secure zone definition.
Research Network Lateral Movement
From a simulated compromised faculty workstation, tested lateral movement to CUI repositories. Found: research network inadequately segmented from the general campus network.
Privileged SWIFT Account Testing
Found: SWIFT admin accounts had no session recording, no just-in-time access provisioning, and were accessible without MFA from within the corporate network.
Transaction Monitoring Testing
Tested whether SWIFT transaction monitoring would detect anomalous payment instructions consistent with the Bangladesh Bank fraud pattern. Found: rules-based monitoring could be evaded by keeping transactions within documented thresholds.
MAS TRM Principle 9 Gap Assessment
Mapped all findings to MAS TRM Principle 9 and SWIFT CSP mandatory controls, producing the gap assessment and evidence package for the MAS TRM review.
MITRE ATT&CK Techniques Tested
| ATT&CK ID | TECHNIQUE | DETECTION RESULT |
|---|---|---|
| T1566.001 | Spear Phishing (SWIFT Operations Staff) |
SUCCESS
37.5% click rate. Consistent with Bangladesh Bank initial access. |
| T1078 | Valid Accounts (SWIFT Admin Credentials) |
NOT DETECTED
No MFA, no session monitoring on SWIFT admin accounts. |
| T1021.001 | Remote Desktop to SWIFT-Adjacent Systems |
PARTIAL
Firewall logs captured but no alert on unusual RDP to SWIFT zone. |
| T1565 | Data Manipulation (SWIFT Message Modification) |
NOT DETECTED
No real-time SWIFT message content monitoring. |
| T1078.002 | Domain Accounts (Privileged SWIFT Access) |
NOT DETECTED
No PAM session recording on SWIFT administrator sessions. |
Key Findings
Critical
SWIFT Admin Accounts Without MFA or Session Recording:
SWIFT administrator accounts were accessible without MFA and had no PAM session recording. This is the exact access control failure that enabled the Bangladesh Bank attack.
Critical
12 Systems in SWIFT Environment Not in Documented Secure Zone:
SWIFT CSP Mandatory Control 1.1 requires all systems in the SWIFT local environment to be explicitly scoped. The 12 undocumented systems were out of compliance.
High
Rules-Based Transaction Monitoring Evadable:
Static thresholds could be evaded by keeping individual transactions below alert levels, the approach used in the Bangladesh Bank fraud.
High
3 Firewall Misconfigurations to SWIFT-Adjacent Systems:
Three firewall rules permitted communication from the corporate network to SWIFT-adjacent systems without traversing the documented SWIFT secure zone boundary.
medium
37.5% SWIFT Operations Staff Spear-Phishing Rate:
More than one-third of SWIFT operations staff clicked on a simulated SWIFT service bulletin phishing email.
Measurable Outcomes
| SWIFT Admin MFA | MFA enforced on all SWIFT admin accounts within 7 days |
| PAM Session Recording | Session recording deployed on all SWIFT administrator sessions |
| Secure Zone Documentation | 12 systems added to SWIFT secure zone scope |
| Firewall Rules | 3 misconfigurations remediated within 14 days |
| Transaction Monitoring | Behavioural analytics layer added |
| MAS TRM Review | MAS examination completed, no material Principle 9 findings |
Regulatory Impact
The SWIFT CSP mandatory control gaps represented active CSP violations at the time of the exercise. An independent assessment finding these controls absent would trigger SWIFT’s mandatory reporting process to the bank’s supervisory authority.
MAS Notice 655 (Cyber Hygiene) specifically requires MFA for all critical system administrator accounts. The absence of MFA on SWIFT admin accounts was a direct Notice 655 violation.
The bank’s APRA-regulated Australian subsidiary had relied on the Singaporean parent’s CSP self-attestation as its CPS 234 testing evidence, which this exercise demonstrated was inadequate.
“
The Bangladesh Bank attack happened because someone clicked a phishing email, and then the attackers had unrestricted access to SWIFT because there was no MFA, no session monitoring, and nobody watching for unusual transaction patterns. Our exercise showed we had all three of those same gaps. We had been self-attesting CSP compliance for three years. The first time someone looked at whether those controls actually worked, they didn’t.
— Chief Information Security Officer, International Trade Finance Bank (anonymised)
Key Takeaways
- SWIFT CSP self-attestation and operational control effectiveness are not the same thing. Annual self-attestation exercises consistently produce higher compliance scores than independent operational testing.
- SWIFT operations staff are among the highest-value targets for nation-state spear-phishing. Staff who process international payment instructions need targeted, role-specific security training.
- Undocumented systems in SWIFT-connected environments are the most common CSP Mandatory Control 1.1 gap. SWIFT secure zone documentation must reflect the operational environment, not the intended architecture.
- MFA on SWIFT administrator accounts is the single most impactful control gap in correspondent banking security. It was absent in the Bangladesh Bank attack. It remains absent in many mid-tier correspondent banks today.
Book a Free Financial Services Purple Team Discovery Call
GLI Secure | ISO 17025 Accredited
All case studies are fully anonymised. ISO 17025-accredited methodology. MITRE ATT&CK is a trademark of The MITRE Corporation.
Purple team use cases for your industry
Every engagement is threat-intelligence-led, built around the adversaries, attack vectors, and regulatory frameworks that define your sector. Select your industry to see the scenarios we run.
Healthcare Purple Team Use Cases
Protecting Patient Data, Clinical Systems, and Operational Continuity
Ransomware Attack on Electronic Health Record (EHR) System
Simulating a Conti/BlackCat-style ransomware campaign targeting Epic or Cerner infrastructure
Medical Device Network Lateral Movement and IoMT Compromise
Simulating adversary pivot from IT network to Internet of Medical Things (IoMT) devices
Third-Party Healthcare Supplier Supply Chain Attack
Simulating a supply chain compromise via a trusted NHS or health system IT vendor
Insurance Purple Team Use Cases
Defending Policy Administration Systems, Customer Data, and Regulatory Standing
Policy Administration System (PAS) Web Portal Compromise
Simulating the attack vectors behind the October 2025 NY DFS $19M multi-carrier enforcement action
Ransomware Attack on Claims Processing Infrastructure
Simulating a financially motivated attack timed to maximise operational disruption during peak claims periods
Insider Threat, Fraudulent Claims Data Manipulation
Simulating a malicious insider accessing and manipulating claims and policyholder data
Education Purple Team Use Cases
Securing Student Records, EdTech Platforms, and Research Networks
EdTech Vendor Supply Chain Attack, Student Record Exfiltration
Simulating the PowerSchool attack pattern: compromise via trusted EdTech vendor access
Ransomware Attack on K-12 District, Full Network Encryption
Simulating the attack profile responsible for 130 US school ransomware attacks in 2025
Research University, CMMC 2.0 Controlled Unclassified Information (CUI) Compromise
Testing DoD supply chain cybersecurity requirements at universities handling defence research data
Financial Services Purple Team Use Cases
Protecting SWIFT, DORA Compliance, and Financial System Integrity
DORA TLPT, Threat-Led Penetration Test (Financial Market Infrastructure)
Executing a DORA Article 26-compliant Threat-Led Penetration Test for significant EU financial entities
API Security Attack on Open Banking / Fintech Platform
Testing Open Banking API security against OWASP API Top 10 and PSD2 compliance requirements
Insider Threat, Rogue Trader / Market Manipulation via System Access
Testing controls against a privileged insider manipulating trading systems or data
State & Local Government Purple Team Use Cases
Protecting Critical Infrastructure, Citizen Data, and Public Service Continuity
Ransomware Attack on Municipal Critical Infrastructure
Simulating a ransomware attack on city government systems including utilities, 911 dispatch, and citizen services
OT/ICS Attack on Water Treatment Infrastructure
Simulating a cyberattack on water treatment SCADA systems, Salt Typhoon pre-positioning scenario
Election Systems and Voter Registration Infrastructure Attack
Testing the security of voter registration databases and election management systems
Manufacturing Purple Team Use Cases
Securing OT/ICS Networks, Defence Supply Chain, and Production Continuity
IT/OT Convergence Attack, Production Line Shutdown
Simulating a cross-network attack from enterprise IT to operational technology environments
CMMC 2.0 Adversarial Assessment, Defence Supply Chain CUI
Full adversarial simulation of a nation-state attack on a DoD contractor’s CUI environment
Automotive Supply Chain, VDA TISAX and ISMS Compromise Simulation
Purple team exercise aligned to Trusted Information Security Assessment Exchange (TISAX) requirements
Gaming & Lottery Purple Team Use Cases
Securing OT/ICS Networks, Defence Supply Chain, and Production Continuity
Commercial Casinos
Social engineering defence validation (Scattered Spider methodology); casino management system lateral movement; help desk vishing simulation; MDR detection rate verification
Tribal Casino-Resorts
NIGC MICS electronic gaming system integrity verification; tribal sovereignty network boundary testing; loyalty programme data exfiltration detectionSimulating adversary pivot from IT network to Internet of Medical Things (IoMT) devices
iGaming Platforms
Account takeover (ATO) detection validation; API security testing with blue team observation; payment fraud detection logic; geolocation bypass detection
Sports Betting Operators
Odds feed integrity attack simulation; trading platform manipulation detection; geolocation system bypass; DDoS simulation for major event readiness
Gaming Technology Vendors
Supply chain attack simulation; source code repository access detection; privileged vendor access abuse; client operator network infiltration via vendor connection
Lotteries
Draw system integrity attack simulation; lottery terminal network compromise detection; player data exfiltration detection; PCI DSS cardholder data environment testing
Strengthen your cybersecurity posture and protect your organization from evolving threats. Discover how GLI Secure reduces risk, simplifies compliance, and protects customer trust.