Gaming Technology Vendor
A real-world purple team engagement inside a multi-jurisdiction online casino | Fully anonymised | ISO 17025 accredited methodology
ISO 17025 accredited · MITRE ATT&CK v15 · Conducted under explicit written authorisation.
Sector
Gaming Technology Vendor
Engagement
Purple Team Exercise
ATT&CK Tactics
MITRE ATT&CK v15
Location
United States
Purple Team Case Studies — Gaming & Lottery
ISO 17025 Accredited
MITRE ATT&CK v15
Conducted under explicit written authorisation
Confidentiality Notice: These case studies are anonymised; any resemblance to specific organisations is coincidental.
CASE STUDY GAM-CS-05
Supply Chain Attack Simulation and Operator Client Protection Testing — Gaming Technology Vendor
Testing whether a compromise of the vendor’s build pipeline could propagate malicious updates to operator clients
Organisation
A gaming technology vendor supplying casino management software, EGM control systems, and player tracking solutions to 340 operator clients across 18 jurisdictions (anonymised)
Sector
Gaming — Technology vendor, B2B, gaming systems and software
Location
Multi-jurisdiction — US and European operator client base
Engagement
Purple Team Exercise — Software Supply Chain, Build Pipeline Security, and Operator Update Propagation Testing
Duration
9 weeks (4-week scoping, 3-day exercise, 2-week remediation and reporting)
Frameworks
| GLI-11 | GLI-33 | NIST SP 800-161 Supply Chain Risk Management | CISA Secure Software Development Framework | MITRE ATT&CK Enterprise v15 | SOC 2 Type II
Core Challenge
Following the SolarWinds and 3CX supply chain attacks, several of the vendor’s Tier 1 operator clients had requested independent validation that a compromise of the vendor’s development or update infrastructure could not propagate malicious code to operator casino management systems. The engagement had additional urgency because GLI-33 audit requirements were being updated to include software supply chain security controls.
The engagement needed to test: whether the build pipeline could be compromised from a developer workstation; whether a malicious update could be packaged and signed using the vendor’s legitimate certificate; whether operator update workflows would accept and deploy a tampered package; and whether the vendor’s SOC would detect a supply chain attack in progress before it reached operator clients.
Engagement Phases
Developer Workstation and Source Control Access Testing
Tested access controls from a compromised developer workstation. Found: the CI/CD pipeline was accessible from developer machines with only username/password authentication — no MFA on the build system. Three developers had credentials stored in browser autofill extractable from the workstation profile directory without elevated privileges. From a single compromised developer account, the build pipeline was fully accessible.
Build Pipeline Integrity Testing
From the compromised developer account, tested whether a malicious modification to the codebase could pass through the build pipeline without detection. Found: code review was required for main branch merges but the build pipeline also processed feature branches without review. A feature branch build could be promoted to a release candidate by a single developer without secondary approval. The SAST tool was configured but its output was not mandatory — a failed scan did not block the build.
Code Signing and Package Integrity Testing
Tested the code signing workflow. Found:Â the signing certificate and its passphrase were stored in the same CI/CD secrets vault, accessible to any account with pipeline access. A compromised developer account could access both the malicious build and the signing certificate in a single authenticated session. The signed package was indistinguishable from a legitimate update.
Operator Update Deployment Simulation
With explicit written consent from two Tier 1 operator clients participating in the exercise, tested whether the tampered but legitimately-signed update package would be accepted by the operator's update workflow. Both operators accepted the package without secondary validation. Neither operator had an independent integrity check separate from the vendor's signature. The update deployed to a test environment in both cases within 4 minutes of delivery.
Vendor SOC Detection Testing
Tested whether the vendor's SOC detected the supply chain attack in progress at any point: developer compromise, pipeline access, malicious build, signing, or operator delivery. Found: the SOC detected the feature branch build anomaly (unusual build time at 2:17am) after 47 minutes — after the simulated package had already been delivered to both test environments.
Incident Response and Client Notification Testing
Tested the vendor's incident response plan for a supply chain compromise scenario. Found:Â the IR plan had a notification workflow for data breaches but no specific procedure for supply chain compromise. The plan did not include a process for simultaneously notifying 340 operator clients of a potentially compromised update, nor a mechanism to revoke a distributed signed package.
MITRE ATT&CK Detection Results
| ATT&CK ID | Technique | Detection Result |
|---|---|---|
| T1195.002 | Compromise Software Supply Chain (Build Pipeline Access) |
NOT DETECTED
No MFA on build system. Access from developer credentials not flagged. |
| T1554 | Compromise Client Software Binary (Malicious Build) |
NOT DETECTED
SAST failures non-blocking. Feature branch build not reviewed. |
| T1553.002 | Subvert Trust Controls (Code Signing with Stolen Certificate) |
NOT DETECTED
Signing certificate accessible from compromised account. No separation. |
| T1072 | Software Deployment Tools (Operator Update Delivery) |
NOT DETECTED
Operators accepted signed package without secondary validation. |
| T1204.002 | Malicious File Execution (Operator Test Environment Deployment) |
DETECTED
SOC anomaly alert after 47 minutes — post-delivery. |
| T1562.001 | Impair Defenses (SAST Bypass via Feature Branch) |
NOT DETECTED
Feature branch pipeline not subject to mandatory SAST. |
| T1078 | Valid Accounts (Developer Credential Reuse in Build System) |
NOT DETECTED
No MFA or anomaly detection on build system access. |
Outcomes
| Metric | Before | After |
|---|---|---|
| Build system MFA | Username/password only | MFA enforced on all build system and CI/CD access |
| Code signing separation | Certificate and passphrase in same vault as build access | Certificate moved to HSM — separate authorisation required for signing |
| Feature branch builds | Promoted to release without secondary approval | Two-engineer approval required for any release candidate promotion |
| SAST enforcement | Output advisory only — failed scan did not block build | Failed SAST scan now blocks build pipeline — exception process documented |
| Operator update validation | Vendor signature only — no independent check | Operator clients provided independent hash verification workflow |
| Supply chain IR plan | Data breach plan only — no supply chain procedure | Supply chain compromise IR plan written — 340-client notification workflow tested |
| GLI-33 supply chain audit | Not previously assessed | Supply chain controls documented for GLI-33 audit evidence package |
“
When we saw the signing certificate and its passphrase in the same secrets vault that a compromised developer account could reach, that was the moment the exercise changed. We had been thinking about supply chain risk as something that happened to other people’s software. This showed us we were other people’s software — to 340 operators who trusted our update signature the way their players trust their jackpot display.
Chief Compliance Officer, Regional P&C Carrier (anonymised)
Test your gaming technology supply chain security
Strengthen your cybersecurity posture and protect your organization from evolving threats. Discover how GLI Secure reduces risk, simplifies compliance, and protects customer trust.