Intraverse.io Leaks 16.9M Records
Web3 Casino Intraverse.io Leaks 16.9M Records
Impact Scope
People Affected
16.9 million records
Industries Affected
Related Entities
Products & Tech
Other
MITRE ATT&CK Techniques
Full Report
Executive Summary
The Web3 online gambling platform, Intraverse.io, has suffered a major data breach due to a misconfigured production Firebase Realtime Database. On August 17, 2026, a threat actor published the database on a hacking forum, revealing that it was publicly accessible without any password or authentication. The breach exposed approximately 16.9 million records, including player data and, more significantly, the internal configuration of the platform's own automated gambling bots, funding wallets, and a live RPC provider key. While no private keys were reportedly exposed, the leak provides a deep view into the platform's internal operations and poses a significant security risk.
Threat Overview
The breach was not the result of a sophisticated attack but rather a simple, yet critical, security oversight. The threat actor, known as 'exfilar', reportedly discovered the open database during a bulk scan of Firebase project identifiers, a common technique for finding misconfigured cloud resources. The database required no authentication, allowing anyone who found it to read its entire contents.
The leaked data, totaling around 518MB in JSON format, contains 16,898,017 database 'leaves' (records). The contents are a mix of player information and highly sensitive internal platform data. The exposure of the house's own gambling bot stack configuration is particularly damaging, as it could allow competitors or malicious actors to understand and potentially exploit the platform's betting strategies.
Technical Analysis
The root cause of this incident is a classic cloud misconfiguration, a common but highly impactful security failure.
- Root Cause: The Firebase Realtime Database had its security rules set to be publicly readable. The default Firebase security rule is often permissive (
{".read": "true", ".write": "true"}) for development purposes, and it appears this was never changed for the production environment. - Discovery (T1596): The attacker used automated scanning tools to iterate through potential Firebase project URLs (e.g.,
[project-id].firebaseio.com/.json) to find open instances. - Data Exfiltration (T1530): Once the open database was found, the attacker simply made an HTTP GET request to the root of the database URL with
.jsonappended, which returns the entire database contents.
Impact Assessment
While the threat actor noted that no user private keys or seed phrases were found, meaning user funds were not directly at risk of being drained, the impact is still severe:
- Operational Security: The leak of the house bot configuration, funding wallets, and RPC key gives competitors and attackers a blueprint of Intraverse's operations. This could be used to financially harm the platform by predicting or countering its automated strategies.
- User Privacy: The exposure of player records, even if pseudonymous, is a significant privacy violation in the Web3 space.
- Reputational Damage: For a platform in the trust-based world of cryptocurrency and Web3, a basic security failure like an open database is catastrophic for user confidence and the platform's reputation.
- Follow-on Attacks: The leaked RPC provider key could be abused, potentially incurring significant costs for Intraverse or being used to interact with the blockchain on their behalf.
IOCs — Directly from Articles
No specific Indicators of Compromise were provided in the source articles.
Cyber Observables — Hunting Hints
To find similar misconfigurations in your own environment:
https://*.firebaseio.com/.jsonfirebase.rules.json".read": "true".Detection & Response
- Cloud Security Posture Management (CSPM): The best detection is proactive. Use a CSPM tool to continuously scan your cloud environment for misconfigurations, including public Firebase databases, and alert on any violations of your security policy.
- Regular Audits: Manually audit the security rules of all Firebase and other NoSQL databases on a regular basis.
- Incident Response: Upon discovering such a leak, the immediate response should be to change the security rules to private, revoke any exposed keys (like the RPC provider key), and begin a forensic analysis to understand what data was accessed.
Mitigation
- Secure by Default: The most critical mitigation is to adopt a 'secure by default' mindset. All databases and storage resources should be private by default. Access should be explicitly granted, not implicitly open. D3FEND's Application Configuration Hardening is the core principle.
- Implement Proper Security Rules: For Firebase, implement granular security rules that only allow authenticated users to read and write their own data. Never use
".read": "true"in a production environment. - Secrets Management: Do not store secrets like API keys (e.g., the RPC provider key) or wallet information in a realtime database. Use a dedicated secrets management solution like AWS Secrets Manager or HashiCorp Vault.
- Automated Security Scanning: Integrate automated security scanning tools into your CI/CD pipeline to check for misconfigurations before they are deployed to production.
Timeline of Events
MITRE ATT&CK Mitigations
The most critical mitigation is to properly configure security rules for cloud databases like Firebase, ensuring they are not publicly readable.
Mapped D3FEND Techniques:
Regularly audit cloud configurations, either manually or with automated tools (CSPM), to detect and remediate misconfigurations.
While not a direct fix, filtering and monitoring network traffic can help in understanding what data is being accessed and by whom.
D3FEND Defensive Countermeasures
The Intraverse.io breach was entirely preventable and stems from a failure in basic application configuration hardening. The primary countermeasure is to enforce a 'private-by-default' security posture for all cloud resources, especially NoSQL databases like Firebase. Developers must never use permissive rules like {".read": "true"} in production. Instead, granular, attribute-based access control rules should be implemented. For Firebase, this means writing security rules that, for example, only allow an authenticated user (auth != null) to read their own data ($uid === auth.uid). For internal configurations like the bot stack, this data should not be in the same database or should be protected by rules that only grant access to specific service accounts. This hardening should be automated and enforced through a Cloud Security Posture Management (CSPM) tool that scans for and alerts on insecure configurations before they lead to a breach.
To proactively detect when sensitive keys are leaked, platforms like Intraverse.io should use decoy objects, specifically 'canary tokens'. A canary token is a fake secret (like a fake RPC provider key) that is placed within a configuration file or database. This token is designed so that any use of it will trigger a high-priority alert. For example, Intraverse could have placed a fake, but validly formatted, RPC key in their Firebase database. The moment the attacker who downloaded the database tried to use this key, it would have sent an immediate alert to the Intraverse security team, notifying them of the breach long before the data was posted on a public forum. This technique provides an early warning system for data breaches by turning the stolen data itself into a detection mechanism.
Timeline of Events
A threat actor publishes the unsecured Intraverse.io database on a public forum.
Sources & References
Article Author
Jason Gomes
• Cybersecurity PractitionerCybersecurity professional with over 10 years of specialized experience in security operations, threat intelligence, incident response, and security automation. Expertise spans SOAR/XSOAR orchestration, threat intelligence platforms, SIEM/UEBA analytics, and building cyber fusion centers. Background includes technical enablement, solution architecture for enterprise and government clients, and implementing security automation workflows across IR, TIP, and SOC use cases.
Editorial Standards & Analyst Review
CyberNetSec.io uses automation to assist source monitoring, deduplication, observable extraction, and structured intelligence generation. Published analysis follows human-defined editorial standards and adds defensive context including MITRE ATT&CK, D3FEND, STIX, and Sigma where applicable. Read our editorial policy.
Tags
📢 Share This Article
Help others stay informed about cybersecurity threats
🎯 MITRE ATT&CK Mapped
Every tactic, technique, and sub-technique used in this threat has been identified and mapped to the MITRE ATT&CK framework for consistent, actionable threat language.
🧠 Enriched & Analyzed
Observables and indicators of compromise (IOCs) have been extracted and cataloged. Risk has been assessed and correlated with known threat actors and historical campaigns.
🛡️ Actionable Guidance
Detection rules, incident response steps, and D3FEND-aligned mitigation strategies are included so your team can act on this intelligence immediately.
🔗 STIX Visualizer
Structured threat data is packaged as a STIX 2.1 bundle and can be visualized as an interactive graph — relationships between actors, malware, techniques, and indicators.
⚡ Sigma Generator
Sigma detection rules are derived from the threat techniques in this article and can be converted for deployment across any major SIEM or EDR platform.