Full Report
City Relay says intruders accessed its Metabase Cloud instance twice and extracted customer data
Analysis Summary
# Incident Report: City Relay Metabase Cloud Compromise
## Executive Summary
London-based property management firm City Relay experienced a data breach involving two unauthorized intrusions into its Metabase Cloud instance. The attackers exploited an undisclosed vulnerability in the platform to extract sensitive customer data, including financial details and physical property access codes. While the company has updated security codes and found no evidence of property intrusions, the breach poses significant identity theft and physical security risks to landlords.
## Incident Details
- **Discovery Date:** September 8, 2026
- **Incident Date:** Occurred twice prior to discovery (Exact dates not disclosed; possibly linked to August 2024 activity)
- **Affected Organization:** City Relay
- **Sector:** Real Estate / Property Management
- **Geography:** London, UK; Paris, France
## Timeline of Events
### Initial Access
- **Date/Time:** Undisclosed (Two distinct instances of access)
- **Vector:** Exploitation of a vulnerability in the Metabase Cloud platform.
- **Details:** Intruders leveraged a platform-side vulnerability (potentially a SQL injection zero-day) to gain access to City Relay’s specific cloud instance.
### Lateral Movement
- **Details:** Attackers moved from the Metabase reporting interface to the underlying databases connected to the platform, which contained core transactional and customer records.
### Data Exfiltration/Impact
- **Details:** Extraction of personal and financial data, including:
- Names, email addresses, and phone numbers.
- Bank details (Account numbers, Sort codes, IBAN, SWIFT, account names).
- Account passwords.
- **Physical Security Data:** Property access instructions, key storage locations, and lockbox codes.
### Detection & Response
- **Discovery:** City Relay identified the intrusion on September 8, 2026.
- **Response Actions:** Notified affected landlords on September 14; initiated a mass reset of all physical lockbox codes and access credentials.
## Attack Methodology
- **Initial Access:** Exploitation of a vulnerability in a third-party SaaS provider (Metabase).
- **Persistence:** Not disclosed; likely session-based or via exploited platform credentials.
- **Privilege Escalation:** Not disclosed, but involved accessing high-privilege databases via the Metabase connection.
- **Defense Evasion:** Not disclosed.
- **Credential Access:** Extraction of stored account passwords from the connected database.
- **Discovery:** Mapping of database schemas to identify tables containing financial and property access info.
- **Collection:** Bulk extraction of customer PII and property metadata.
- **Exfiltration:** Data pulled via the compromised Metabase cloud instance.
- **Impact:** Potential for financial fraud and unauthorized physical entry into managed properties.
## Impact Assessment
- **Financial:** Risk of fraudulent transactions due to exposed IBAN/SWIFT and bank details.
- **Data Breach:** High-sensitivity PII and credentials for thousands of London and Paris properties.
- **Operational:** Significant labor required to manually update physical lockbox codes across hundreds/thousands of properties.
- **Reputational:** Damage to their brand as "London's most trusted property management company."
## Indicators of Compromise
- **Network indicators:** None disclosed (Third-party cloud breach).
- **File indicators:** None disclosed.
- **Behavioral indicators:** Unusual query patterns or data export volumes originating from the Metabase Cloud environment.
## Response Actions
- **Containment:** Secured the Metabase instance and addressed the platform vulnerability.
- **Eradication:** Updated all relevant physical access and key-storage codes to invalidate stolen data.
- **Recovery:** Notified customers, engaged cybersecurity specialists, and reported to relevant authorities (ICO/Police).
## Lessons Learned
- **Database Segregation:** Connecting a reporting tool (Metabase) directly to a core transactional database containing sensitive PII creates a single point of failure.
- **Data Encryption:** Storing financial details and passwords in a readable (plaintext) format significantly increased the severity of the breach.
- **Third-Party Risk:** Vulnerabilities in SaaS providers can lead to full compromise of locally managed physical assets.
## Recommendations
- **Least Privilege:** Connect business intelligence tools to read-only "follower" databases that have sensitive columns (like passwords or bank codes) masked or removed.
- **Encryption at Rest:** Ensure sensitive financial fields are encrypted or tokenized so that even if the database is queried, the data remains unusable.
- **Multi-Factor Authentication:** Enforce strict MFA for all cloud-based reporting and analytics platforms.
- **Physical Security Redundancy:** Avoid storing master lockbox codes in digital databases that are accessible via web-facing reporting tools.