Full Report
An unknown threat actor gained access to a self-hosted Gitlab instance used by Sisense, which stored credentials for an S3 bucket containing customer access tokens, passwords and SSL certificates.
Analysis Summary
# Incident Report: Sisense Self-Hosted GitLab Compromise
## Executive Summary
An unknown threat actor successfully compromised Sisense’s self-hosted GitLab instance. This access allowed the actor to harvest credentials stored within the repository, which subsequently granted access to an S3 bucket. The compromised S3 bucket contained sensitive customer data, including access tokens, passwords, and SSL certificates. The incident was publicly acknowledged and finalized around April 11, 2024.
## Incident Details
- **Discovery Date:** Around April 11, 2024 (Public Disclosure Date)
- **Incident Date:** Unknown (Date of initial compromise unknown)
- **Affected Organization:** Sisense
- **Sector:** Business Intelligence / Data Analytics Software
- **Geography:** Not specified (Global operations implied)
## Timeline of Events
### Initial Access
- **Date/Time:** Unknown
- **Vector:** Compromise of the self-hosted GitLab instance.
- **Details:** The unknown actor successfully utilized a vulnerability or method to gain unauthorized entry into the self-hosted version of Sisense's GitLab platform.
### Lateral Movement
- **Date/Time:** Post-Initial Access
- **Vector:** Credential Harvesting from Code Repository.
- **Details:** The attacker harvested secrets (credentials) committed or stored within the GitLab repository configuration or source code. These credentials provided a pathway to other infrastructure.
### Data Exfiltration/Impact
- **Date/Time:** Post-Lateral Movement
- **Impact:** Unauthorized access and exfiltration of data stored in an S3 bucket linked via the harvested credentials.
- **Data Compromised:** Customer access tokens, customer passwords, and SSL certificates.
### Detection & Response
- **Date/Time:** Detection date is not specified, but the incident status is 'Finalized' as of June 2, 2024. Public disclosure occurred April 11, 2024.
- **Response actions taken:** While specific actions are not detailed in the input, standard response would include credential rotation, isolation of the compromised S3 resources, and patching the exploited vector on the GitLab instance.
## Attack Methodology
- **Initial Access:** Compromise of self-hosted GitLab instance (specific vector unknown).
- **Persistence:** Not explicitly detailed, but likely maintained via continuously valid harvested credentials.
- **Privilege Escalation:** Not explicitly detailed, but the harvested credentials for the S3 bucket acted as an effective privilege escalation mechanism to a highly sensitive data store.
- **Defense Evasion:** Unknown.
- **Credential Access:** Credential harvesting directly from the code repository (searching for keys, tokens, or plain-text passwords within source code or configurations).
- **Discovery:** Unknown, but likely initial scanning or configuration review of the GitLab instance.
- **Lateral Movement:** Movement from the GitLab environment to the associated AWS S3 environment using stolen credentials.
- **Collection:** Gathering customer access tokens, passwords, and SSL certificates from the S3 bucket.
- **Exfiltration:** Exfiltration of the collected sensitive data (method unknown).
- **Impact:** Unauthorized access to sensitive customer data and infrastructure components (SSL certificates).
## Impact Assessment
- **Financial:** Not available.
- **Data Breach:** High severity. Exposure of Customer Access Tokens, Customer Passwords, and SSL Certificates.
- **Operational:** Potential disruption caused by compromised SSL certificates or the need to force mass credential/token rotation for customers.
- **Reputational:** Notification was issued, impacting trust in Sisense's security posture.
## Indicators of Compromise
*(Note: Lacking specific IoCs from the source text, these are generalized based on the attack type.)*
- **Network indicators:** Undetermined unauthorized API calls originating from unrecognized IP addresses accessing the S3 bucket.
- **File indicators:** None provided.
- **Behavioral indicators:** Anomalous Gitlab administrator activity or large data transfers/downloads initiated from the compromised environment.
## Response Actions
- **Containment:** Rotating all credentials found within the compromised GitLab instance and the targeted S3 bucket. Isolating the affected S3 bucket access policies.
- **Eradication:** Patching or reconfiguring the security flaw that allowed the initial compromise of the self-hosted GitLab instance.
- **Recovery:** Restoring service functions and potentially notifying affected customers to rotate their associated credentials/tokens.
## Lessons Learned
1. **Secrets Management Failure:** Sensitive production credentials (S3 bucket keys, customer secrets) must never be stored directly in source code repositories, even self-hosted ones, without robust secrets management practices (e.g., using vault systems or environment variables referenced securely).
2. **Self-Hosted Security:** Self-hosted environments require diligent patching and hardening equivalent to or exceeding managed services, as vulnerabilities directly expose integrated assets.
## Recommendations
- Implement mandatory secrets scanning on all code repositories (GitLab, internal or external) to automatically flag and remediate committed credentials.
- Immediately migrate sensitive infrastructure credentials from code repositories to a central secrets management solution (e.g., HashiCorp Vault, AWS Secrets Manager).
- Enable and rigorously review multi-factor authentication (MFA) for all users and service accounts accessing the self-hosted GitLab instance.
- Review S3 bucket policies to ensure the principle of least privilege (PoLP) is strictly enforced, limiting access only to necessary services.