Insurance Sector
Three Real-World Purple Team Engagements | Fully Anonymised | ISO 17025 Accredited Methodology
Sector
Insurance
Engagement
Purple Team Exercise
ATT&CK Tactics
MITRE ATT&CK v15
Location
Mid-Atlantic United States
About These Case Studies
The following case studies describe real purple team engagements conducted by GLI Secure across insurance 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 INS-CS-01
Policy Administration Portal Attack , Regional P&C Carrier
Simulating the NY DFS enforcement action attack vectors against an unassessed insurer portal infrastructure
Organisation
A regional property and casualty insurance carrier licensed in 14 states (anonymised)
Sector
Insurance , Property and casualty, personal and commercial lines
Location
Mid-Atlantic United States
Engagement
Purple Team Exercise , Portal Security and Credential Attack Simulation
Duration
5 weeks (2-week scoping, 1-day exercise, 2-week remediation and reporting)
Frameworks
NY DFS 23 NYCRR Part 500 §500.05 | NAIC MDL-668 Section 4 | MITRE ATT&CK Enterprise v15 | OWASP API Security Top 10 2023
The Situation
In October 2025, the New York Department of Financial Services announced over $19 million in fines against eight US auto insurance carriers for cybersecurity violations , specifically the failure to assess and secure public-facing web applications and agent portals. Every carrier named had received prior DFS industry letters in 2021 warning about the exact vulnerabilities that were later exploited.
The carrier operated three public-facing portals: a policyholder self-service portal, an agent management portal, and a commercial lines submission portal. None of the three had been penetration tested in over 14 months. The carrier was licensed in New York and subject to Part 500 §500.05, which requires annual penetration testing of all externally-accessible systems.
The CISO brought in GLI Secure with a specific question: if DFS examiners looked at these portals today, what would they find , and what would the fine look like?
Core Challenge
Identify and validate the security vulnerabilities in the carrier’s three portals that would be found in a DFS examination, and produce the §500.05-compliant penetration test documentation the carrier was missing.
What GLI Secure Did
We conducted an external attack surface assessment covering all three portals, mapping every publicly-accessible endpoint, authentication mechanism, and API interface , the attack surface inventory §500.05 requires as the foundation for annual testing.
The exercise simulated the specific attack chain documented in the DFS enforcement actions: credential stuffing against the policyholder portal, authentication flaw exploitation on the agent portal, and API enumeration against the commercial lines submission interface.
The exercise was structured to produce §500.05-compliant test documentation regardless of outcome , because the carrier needed the compliance evidence even if findings were significant.
The Purple Team Approach
External Attack Surface Mapping
Enumerated all publicly-accessible interfaces. Found: 47 distinct API endpoints, 3 authentication flows, 2 password reset mechanisms, and 1 legacy portal endpoint that should have been decommissioned 18 months earlier.
Credential Stuffing Simulation
Tested credential stuffing defences on the policyholder portal. Found: rate limiting absent , thousands of login attempts per minute were possible without triggering any lockout or alert.
Authentication Flaw Testing
Tested password reset flows. Found: a parameter manipulation vulnerability in the agent portal password reset that could allow account takeover without requiring the original credentials.
API Security Testing (OWASP API Top 10)
Tested all 47 endpoints. Found 3 BOLA vulnerabilities allowing one agent to access another agent's client portfolio data , a cross-agent data exposure.
MFA Effectiveness Testing
Found: commercial lines portal had no MFA deployed. Policyholder portal MFA was bypassable via push notification fatigue.
Detection and Response Validation
Tested whether the carrier's WAF, SIEM, and monitoring detected each attack technique. Measured time from attack execution to first alert.
MITRE ATT&CK Techniques Tested
| ATT&CK ID | Technique | Detection Result |
|---|---|---|
| T1110.004 | Credential Stuffing |
Not Detected
No rate limiting or stuffing detection. |
| T1212 | Exploitation for Credential Access (Reset Flaw) |
Not Detected
No monitoring on authentication anomalies. |
| T1528 | Steal Application Access Token |
Partial
WAF flagged unusual requests but alert not reviewed. |
| T1190 | Exploit Public-Facing Application (BOLA) |
Not Detected
No API-level anomaly detection. |
| T1621 | MFA Push Notification Fatigue |
Not Detected
No push fatigue detection or number matching. |
| T1530 | Data from Cloud Storage (Client Portfolio) |
Detected
SIEM alert on bulk data access after 52 minutes. |
Key Findings
Critical
No Rate Limiting on Policyholder Portal:
The policyholder portal had no credential stuffing protection , the primary attack vector in the DFS October 2025 enforcement actions.
Critical
Agent Portal Password Reset Vulnerability:
A parameter manipulation vulnerability allowed account takeover, exposing client portfolio data for all policies managed by any compromised agent account.
Critical
3 BOLA API Vulnerabilities:
Three endpoints allowed cross-agent data access , an authenticated agent could retrieve another agent’s client data by modifying object identifiers.
High
No MFA on Commercial Lines Portal:
Direct Part 500 §500.12 violation. The October 2025 enforcement actions cited missing MFA as the most common violation.
High
14-Month Penetration Test Gap:
Part 500 §500.05 requires annual testing. The gap meant the carrier was in violation prior to this engagement , this would be cited in any DFS examination.
Measurable Outcomes
| §500.05 Compliance Before | Non-compliant, 14-month pen test gap |
| §500.05 Compliance After | Compliant, accredited test documentation produced |
| Critical Vulnerabilities Remediated | All 3 critical findings within 21 days |
| MFA Deployed | Commercial lines portal MFA live within 14 days |
| Rate Limiting | Credential stuffing protection deployed on all 3 portals |
| BOLA Vulnerabilities | All 3 API vulnerabilities patched within 30 days |
| Estimated Fine Avoided | Based on DFS October 2025 precedent: $2.5M–$4M exposure eliminated |
Regulatory Impact
The engagement produced NY DFS Part 500 §500.05-compliant penetration test documentation structured specifically for DFS examination review , providing defensible compliance evidence rather than an internal security report.
The three BOLA vulnerabilities represented both a Part 500 §500.07 violation and a NAIC MDL-668 Section 4 gap. Agent-to-agent data access without authorisation is a policyholder data protection failure that would be cited in both a DFS examination and an MDL-668 examination in the carrier’s other licensed states.
The missing MFA on the commercial lines portal was a direct Part 500 §500.12 violation. The carrier’s remediation , documented within 14 days , provides a strong regulatory defence in the event of a future examination.
“
We watched those eight carriers get fined $19 million and thought we were different because we hadn’t been attacked. The purple team exercise showed we weren’t different at all , we had the same missing rate limiting, the same MFA gap, the same untested portals. The difference is we found it in a controlled exercise instead of a DFS examination. That difference is worth millions.
Chief Compliance Officer, Regional P&C Carrier (anonymised)
Key Takeaways
- The DFS October 2025 enforcement actions represent systematic examination of portal security across the insurance industry. Every carrier with public-facing portals should assume their portals will be examined.
- Annual penetration testing under §500.05 is a board-level compliance obligation. The 14-month gap existed because nobody had ownership of the annual testing calendar.
- BOLA API vulnerabilities are the most commonly missed finding in insurance portal security assessments. Standard vulnerability scans do not detect them , only manual security testing surfaces this vulnerability class.
- ISO 17025-accredited penetration test documentation carries more weight with DFS examiners than unaccredited vendor reports.
Ready to test your Insurance security defences?
Case Study INS-CS-02
Claims Processing Ransomware Simulation , National Life Carrier
Testing claims system recovery capability against a Change Healthcare-style attack
Organisation
A national life and health insurance carrier with $2.4B in annual premium (anonymised)
Sector
Insurance , Life, accident and health insurance
Location
National, United States
Engagement
Purple Team Exercise , Claims System Ransomware and Business Continuity Validation
Duration
7 weeks (3-week planning, 2-day exercise, 2-week remediation)
Frameworks
Lloyd’s Cyber Minimum Standards | MITRE ATT&CK Enterprise v15 | NAIC MDL-668 Section 7 | NY DFS Part 500 §500.16 | HIPAA §164.308(a)(7)
The Situation
The Change Healthcare ransomware attack in early 2024 disrupted billing and claims processing for over 900 US hospitals for weeks. The carrier’s CEO convened an emergency board session the week the attack became public. The board’s question was direct: could the same thing happen to us, and how long would it take to recover?
The carrier processed approximately 340,000 claims per day. A ransomware event encrypting the claims system would halt all claims processing immediately. The carrier had a documented business continuity plan , it had never been tested against a realistic ransomware scenario. Backup systems existed, but nobody had validated whether those backups were genuinely air-gapped and restorable within the documented 72-hour Recovery Time Objective.
The CEO reported the 72-hour RTO to the board as a validated commitment. It was not.
Core Challenge
Determine whether the carrier’s claims processing BCP would actually work in a Change Healthcare-style ransomware event , specifically whether backups were genuinely offline, whether the 72-hour RTO was achievable, and whether ransomware precursor activity would be detected.
What GLI Secure Did
The exercise ran two concurrent workstreams: a technical purple team simulation testing detection of ransomware precursor techniques, and a business continuity tabletop testing whether claims processing could continue during an outage.
The technical simulation tested the specific techniques used in the Change Healthcare attack as documented in the ALPHV/BlackCat profile , vendor pathway initial access, lateral movement to claims management systems, and simulated encryption of isolated test file shares.
The business continuity workstream timed an actual partial backup restoration from the carrier’s air-gapped backup environment. This was the first backup restoration test conducted in over 14 months.
The Purple Team Approach
Backup Infrastructure Audit
Finding: primary backups were NOT air-gapped , they were on a network-connected system accessible from the claims management environment. Secondary backups were genuinely offline but restoration had never been tested. Tested restoration time: 94 hours , significantly exceeding the 72-hour RTO.
Initial Access Simulation (Vendor Pathway)
Simulated the Change Healthcare attack vector: compromised third-party claims processing vendor connection. Found no session monitoring and minimal access scope controls on the vendor pathway.
Lateral Movement to Claims System
Tested whether compromised vendor access could reach claims management servers. Found: direct network connectivity with no segmentation boundary.
Ransomware Precursor Detection
Executed 5 techniques: credential dumping, backup enumeration, shadow copy deletion, large file staging, simulated encryption of isolated test shares. Measured detection for each.
Business Continuity Activation
Activated the documented BCP in parallel. Measured: time to activate manual claims processing, time to identify in-flight claims, time to establish customer communication. Approximately 40% of in-flight claims could not be identified within 4 hours using documented procedures.
Regulatory Notification Workflow
Tested the NAIC MDL-668 72-hour state notification workflow. Found: the legal team was unaware of MDL-668 notification obligations in 2 of the carrier's 14 licensed states.
MITRE ATT&CK Techniques Tested
| ATT&CK ID | Technique | Detection Result |
|---|---|---|
| T1199 | Trusted Relationship (Vendor Access) |
Not Detected
No behavioural monitoring on vendor sessions. |
| T1021.002 | SMB Lateral Movement to Claims Servers |
Not Detected
No east-west traffic monitoring. |
| T1490 | Inhibit System Recovery (Backup Enumeration) |
Not Detected
Primary backups accessible from compromised account. |
| T1003 | OS Credential Dumping |
Detected
EDR alert in 8 minutes. Strong result. |
| T1486 | Data Encrypted for Impact (Test Shares) |
Detected
Behavioural ransomware detection in 4 minutes. |
| T1048 | Exfiltration over HTTPS (Data Staging) |
Partial
DLP alert after 41 minutes. |
Key Findings
Critical
Primary Backups Not Air-Gapped:
Primary backup systems were network-accessible from the claims management environment. An attacker who reached the claims environment could encrypt the primary backups simultaneously with production systems , eliminating the most common ransomware recovery pathway.
Critical
72-Hour RTO Not Achievable:
Tested restoration from secondary backups took 94 hours , 31% longer than the documented RTO. This gap was unknown to the board and to the regulators who had accepted the 72-hour RTO as a validated commitment.
High
No Vendor Zone Segmentation:
The Change Healthcare attack pathway , vendor access to core processing systems , was directly replicable in this environment.
High
MDL-668 Notification Gap:
The legal team was unaware of MDL-668 72-hour notification obligations in 2 of 14 licensed states. Late notification would compound regulatory exposure significantly.
medium
BCP Never Tested:
The business continuity plan assumed manual claims processing workflows that current staff had never trained on.
Measurable Outcomes
| Primary Backup Air-Gap | Moved to genuinely offline storage within 45 days |
| RTO After Remediation | Backup restoration retested , achieved 68 hours vs 72-hour target |
| Vendor Zone Segmentation | Network boundary implemented between vendor access and claims environment |
| MDL-668 Notifications | State notification obligations documented for all 14 licensed states |
| BCP Training | All claims and operations staff completed manual processing training |
| Lloyd's Standards | Backup infrastructure now meets Lloyd's Cyber Minimum Standards |
| Board Report | Accurate RTO reported , prior 72-hour commitment corrected |
Regulatory Impact
The 72-hour RTO that was not achievable has significant regulatory consequences. NAIC MDL-668 Section 7 requires carriers to maintain a business continuity plan ensuring timely recovery of information systems. A tested RTO of 94 hours against a documented 72-hour commitment represents a material misrepresentation in compliance documentation.
The MDL-668 notification gap , two states’ obligations unknown to the compliance team , represents a systemic compliance programme failure. In both states, late notification would expose the carrier to examination findings, fines, and potential licence consequences beyond the breach itself.
The primary backup accessibility finding has direct Lloyd’s Cyber Minimum Standards implications. Lloyd’s requires backups be ‘tested, offline, and not accessible from the primary network’ as a minimum coverage condition. The pre-exercise configuration did not meet this standard.
“
We told the board we had a 72-hour recovery time objective. We had never tested it. When we actually ran the restoration from our secondary backups, it took 94 hours. The purple team exercise also found that our primary backups weren’t air-gapped , they were sitting on a network-accessible system that an attacker could have encrypted alongside everything else. If Change Healthcare happened to us with that setup, we would have had no recovery pathway at all.
Chief Risk Officer, National Life Carrier (anonymised)
Key Takeaways
- An untested RTO is not an RTO , it is a guess. Business continuity documentation that has never been validated against actual backup restoration is a liability, not a protection.
- Primary backup air-gap validation is the single most impactful ransomware resilience control for insurance carriers. Most carriers believe their backups are air-gapped because the documentation says so , not because it has been tested.
- MDL-668 state notification obligations vary by state and change as new states adopt the model law. Maintaining a current notification obligation register for all licensed states is a compliance necessity.
- The Change Healthcare attack pattern , vendor access to core processing systems , is directly replicable in most insurance carrier environments that have not implemented vendor zone network segmentation.
Ready to test your Insurance security defences?
Case Study INS-CS-03
Insider Threat , Claims Data Manipulation at a Specialty Insurer
Testing data access governance and user behaviour analytics against a malicious insider scenario
Organisation
A specialty lines insurer with $800M in annual premium and 2,400 employees (anonymised)
Sector
Insurance , Specialty lines, professional liability, cyber insurance
Location
Northeast United States
Engagement
Purple Team Exercise , Insider Threat Detection and Claims Data Governance
Duration
4 weeks (2-week scoping, 1-day exercise, 1-week remediation and reporting)
Frameworks
SOX §302/§404 (publicly listed parent) | MITRE ATT&CK Enterprise v15 | NAIC MDL-668 Section 4(F) | NY DFS Part 500 §500.07 | GDPR Article 5
The Situation
The insurer had experienced an uncomfortable incident the previous year: a claims adjuster had accessed approximately 400 policyholder claims records outside their assigned book of business over 6 weeks. The investigation was triggered by a colleague tip , not by any automated detection system. The CISO was troubled: if the adjuster had been more careful, the access would never have been detected.
A NAIC MDL-668 examination was scheduled for the following year. The CISO wanted to understand the true state of data access controls before the examiner arrived. The specific concern was whether privileged IT administrators could access claims data directly through the database layer, bypassing application-layer controls entirely.
The prior incident had been caught at the application layer. The database layer was completely unmonitored.
Core Challenge
Determine whether a malicious insider , adjuster or privileged IT administrator , could access, manipulate, or exfiltrate claims data without generating a detectable alert.
What GLI Secure Did
The exercise structured two distinct scenarios: a claims adjuster abusing application-layer access (the prior incident pattern), and a privileged database administrator accessing claims data directly through the database layer.
For each scenario, we tested whether the access was detectable and whether data exfiltration was preventable using existing DLP, UEBA, and database activity monitoring tools.
We also tested whether audit logs could be modified by the database administrator , a finding with direct SOX §302 implications for the carrier’s publicly listed parent company.
The Purple Team Approach
Claims Adjuster Access Scope Testing
Tested whether a claims adjuster account could access records outside their assigned book. Found: RBAC controls existed at the UI layer only. Direct API calls bypassed the UI-layer RBAC and allowed access to any of the 340,000 active claims in the system.
API RBAC Bypass Testing
Demonstrated that the API bypass allowed bulk access to all 340,000 claims , not just the adjuster's assigned 200. The prior incident was detected by chance, not by control.
Database Administrator Direct Access Testing
Tested privileged DBA access to the claims database. Found: DBA accounts could query the claims database directly via SQL with no alerting on direct database queries.
Audit Log Integrity Testing
Found: audit log tables were accessible to DBAs and modifiable , no tamper-evident logging existed at the database layer. Direct SOX §302 control deficiency.
Data Exfiltration Testing
DLP blocked bulk CSV export via email. But direct database query results could be pasted into a personal cloud document without triggering any alert.
UEBA Effectiveness Testing
Found: UEBA was configured for network-level anomalies but had no claims access behaviour baseline. It could not detect unusual claims access patterns.
MITRE ATT&CK Techniques Tested
| ATT&CK ID | Technique | Detection Result |
|---|---|---|
| T1078 | Valid Accounts (Adjuster Out-of-Scope Access) |
Not Detected
API bypass of RBAC , no logging at API layer. |
| T1213 | Data from Information Repositories (Claims DB) |
Not Detected
Direct DB queries not logged or monitored. |
| T1070 | Indicator Removal (Audit Log Modification) |
Not Detected
Audit tables accessible and modifiable by DBA. |
| T1005 | Data from Local System (Bulk Claim Export) |
Detected
DLP alert on bulk CSV via email in 2 minutes. |
| T1567 | Exfiltration to Cloud Storage (Paste to Cloud Doc) |
Not Detected
No monitoring on clipboard or cloud document paste. |
| T1530 | Data from Cloud Storage (Claims Reporting Tool) |
Partial
Access logged but no volume anomaly alert. |
Key Findings
Critical
API RBAC Bypass , All 340,000 Claims Accessible:
Application-layer RBAC did not extend to the API layer. Any claims adjuster with a valid API token could access all 340,000 active claims , not just their assigned book.
Critical
Database Audit Log Tampering Possible:
DBA accounts could modify audit log tables using legitimate SQL. Creates a SOX §302 control deficiency: the publicly listed parent cannot certify the integrity of financial controls if underlying audit logs are mutable.
High
Zero Detection on Direct Database Queries:
All direct SQL queries to the claims database went unlogged and unmonitored. A malicious DBA could access the complete claims database without generating any alert.
High
Cloud Document Exfiltration Undetected:
Copying claims data to a personal cloud document was not detected by any existing control.
medium
UEBA No Claims Baseline:
UEBA was not configured with a claims access behaviour baseline. Detecting unusual claims access required human observation, not automated detection.
Measurable Outcomes
| API RBAC | Enforcement extended to API layer , consistent at UI and API |
| Database Activity Monitoring | DAM solution deployed with alerting on direct claims DB queries |
| Audit Log Integrity | Tamper-evident logging , logs now write to immutable storage |
| UEBA Claims Baseline | Claims access behaviour baseline built , anomaly detection active |
| Cloud Document DLP | Clipboard and cloud document monitoring deployed |
| SOX Deficiency | Audit log integrity gap closed , SOX §302 certification now defensible |
Regulatory Impact
The audit log tamperability finding created a direct SOX §302 control deficiency. SOX §302 requires the CEO and CFO to certify the effectiveness of internal controls over financial reporting. An audit log modifiable by a DBA without detection is not an effective internal control. This finding was escalated to the parent company’s external auditors within 24 hours.
The API RBAC bypass has direct MDL-668 Section 4(F) implications. MDL-668 requires covered entities to limit access to information systems containing nonpublic information to only those individuals who need access. Application-layer RBAC that does not extend to the API layer does not satisfy this requirement.
Both findings , zero database query monitoring and mutable audit logs , represent the exact risk profile NAIC examiners are trained to identify, triggering the domicile-state cascade that exposes the carrier in all 14 of its licensed states.
“
We caught the last insider by luck. A colleague mentioned something unusual to their manager, who mentioned it to compliance. That is not a detection programme , that is fortune. The purple team exercise showed us that if the adjuster had used the API instead of the UI, we would never have known. And if a DBA had decided to cover their tracks, there would have been nothing to find.
Chief Information Security Officer, Specialty Lines Insurer (anonymised)
Key Takeaways
- Application-layer access controls that do not extend to the API layer are not access controls , they are speed bumps. As insurance platforms modernise and API-first architectures become standard, RBAC must be validated at every layer.
- Database activity monitoring for direct SQL access to policyholder data is a MDL-668 and SOX requirement that most insurance carriers have not implemented.
- Insider threat detection requires a behaviour baseline before it can detect anomalies. UEBA tools deployed without domain-specific baselines provide false security confidence.
- Audit log integrity is a SOX obligation, not just a security best practice. Mutable audit logs at the database layer create certification risk for the entire enterprise.
Book a Free Insurance Purple Team Discovery Call
GLI Secure | ISO 17025 Accredited
Strengthen your cybersecurity posture today.
Strengthen your cybersecurity posture and protect your organization from evolving threats. Discover how GLI Secure reduces risk, simplifies compliance, and protects customer trust.