Background

On April 11, 2024, the Cybersecurity and Infrastructure Security Agency (CISA) announced its collaboration with private industry partners to address a significant security breach affecting Sisense, a prominent provider of data analytics services. This compromise, unearthed by independent security researchers, raised alarms within the cybersecurity community, prompting swift action from both government agencies and affected organizations.

In response to the breach, CISA issued urgent recommendations to Sisense customers, advising them to reset any credentials or secrets that may have been compromised or utilized to access Sisense services. Additionally, customers were urged to thoroughly investigate any suspicious activity related to these credentials and promptly report their findings to CISA for further analysis and mitigation.

Prior to CISA's official statement, Sisense's Chief Information Security Officer, Sangram Dash, took proactive measures by directly informing customers about the breach and its potential implications. Dash emphasized the critical nature of the situation, urging affected customers to take immediate action by resetting keys, tokens, and other credentials associated with the Sisense application to safeguard their systems and data from further exploitation.

What is Sisense?

Sisense is a business intelligence (BI) and data analytics platform that enables organizations to gather, analyze, and visualize data from various sources. Sisense is used by a wide range of industries and organizations to analyze data, gain insights, and drive data-driven decision-making.

Sisense offers versatile integration capabilities with various industry-standard systems and services, including cloud-based platforms like Amazon Athena, Azure Synapse, and Google BigQuery, along with traditional database management systems such as MySQL, PostgreSQL, and SQL Server. Additionally, Sisense seamlessly connects to leading cloud data warehouses like Redshift, Snowflake, and SingleStore.

What Exactly Occurred?

Based on a report by KrebsOnSecurity, attackers successfully infiltrated the company's Gitlab code repository. Within this repository, they discovered a token or credential granting them access to Sisense's Amazon S3 buckets stored in the cloud. Exploiting this access, the attackers proceeded to copy and extract several terabytes of Sisense customer data. This data breach compromised millions of access tokens, email account passwords, and even SSL certificates. As a result, Sisense customers are now left to figure out whether and when they should update passwords for the third-party services, they had previously entrusted to Sisense.

Why This Is Cause for Concern

The breach poses a significant concern for Sisense customers as they now face the daunting task of remapping all their data connections associated with the Sisense product. This entails revoking the compromised credentials and conducting a thorough threat hunt across multiple systems to trace the identities linked to these credentials. The aim is to ensure that these credentials haven't been exploited by attackers.

In the upcoming sections, we'll outline actionable steps for Sisense customers to address the breach's aftermath within AWS, and GCP environments.

Discovering Systems that Integrate with Sisense

To ensure clarity, you can use asset management tools to identify the software in use, including Sisense, and understand its integration. Alternatively, consult with your company's BI department or IT personnel for insights. If these options are unavailable and you prefer to conduct your own investigation, we will outline actionable steps for detecting Cloud resources which may intergrade with Sisense.

Sisense and AWS

Sisense has data connectors that integrate with AWS resources like S3 and Athena.

To connect to these resources, users need to create an IAM user with specific permissions and provide the Access Key ID and Secret Access Key to the Sisense product. As documented here: https://dtdocs.sisense.com/article/connecting-athena.

To integrate with resources like Redshift, you must configure inbound rules to allow traffic from both Sisense Cloud and your Sisense deployment via the Redshift port (default 5439). The Sisense Cloud IP addresses are 54.186.74.45 and 54.187.196.247, while your Sisense deployment address will be the IP Address of your Sisense URL. Afterward, provide the connection details back to the Sisense product: https://docs.sisense.com/main/SisenseLinux/connecting-to-amazon-redshift.htm

Discovering AWS Resources that Integrate with Sisense

To identify AWS resources integrated with Sisense, start by examining IAM users within your AWS accounts. Specifically, look for IAM users that contain keywords like "periscope" or "sisense," especially if your company followed tutorials such as https://dtdocs.sisense.com/article/connecting-athena. If you find IAM users fitting this description, there's a strong possibility that their access keys are being utilized by Sisense for integration purposes. For resources like Redshift, inspect the security groups to determine if there are any ingress rules permitting access from Sisense's known IP addresses, as mentioned previously.

Revoking Credentials

When dealing with an IAM user, the critical step is to deactivate the associated access keys. For an extra layer of caution, consider restricting certain actions for the Sisense IAM user by attaching the "AWSCompromisedKeyQuarantineV2" policy to the IAM user. This policy helps prevent unauthorized access to sensitive resources. Once you've verified that the IAM user wasn't compromised, detach this policy, delete the access keys associated with the user, and generate new ones to maintain security.

Threat Hunting: Proactive Security Measures

To proactively identify potential threats, leverage CloudTrail logs to monitor all actions performed by the Sisense IAM user and its access key. Here is an example of “userIdentity” field of action done by periscope IAM user.

Ensure CloudTrail is configured to capture both management and data events, such as S3 and DynamoDB read actions to detect abnormal data actions too.

Look out for anomalies like unusual user agents, unexpected IP addresses, spikes in failure rates indicating unauthorized access attempts, abnormal increases in data downloads from S3 buckets, and any other suspicious activities that could signal a security breach. An example of such suspicious activity includes IAM actions like creating new IAM users and updating IAM policies, actions that users associated with Sisense integration would typically not perform.

For database resources like RDS integrated with Sisense, examine VPC flow logs which covers network connections to those instances. Specifically, look for any successful connections to the RDS instances originating from abnormal IP addresses.

Additionally, if GuardDuty is enabled in your AWS account, cross-reference any alerts generated to see if there are any indicators relating to the Sisense related resources, further enhancing your threat hunting efforts.

Sisense and GCP

Another example for integration between Sisense to other cloud vendors includes GCP BigQuery integration. The GCP BigQuery connector from Sisense empowers you to selectively fetch data from BigQuery, tailored to your needs.

When connecting to Google BigQuery, you can choose the preferred authentication mechanism: OAuth or Service Account. A service account is a Google account associated with your GCP project.

If the preferred authentication method for your Sisense to BigQuery integration is Service Account, the integration mechanism involves:

1. Create a Service account (or use an existing one)
2. Give it permissions for BigQuery
3. Activate the service account using

gcloud auth activate-service-account

Steps 1, 2, 3, 4 and 6, generate logs in GCP and can be hunted. We'll dive into that later.

To read more about BigQuery integration with Sisense and BigQuery permissions:

• https://docs.sisense.com/main/SisenseLinux/connecting-to-google-bigquery.htm
• https://cloud.google.com/bigquery/docs/access-control#bq-permissions

Discover service accounts related to Sisense integration

A service account is identified by its exclusive email address. When an application authenticates as a service account, it gains access to all resources permitted for that service account. To authenticate as a service account, you must generate a service account key and use it across environments to acquire OAuth 2.0 access tokens.

To identify a service account associated with Sisense, begin by searching for service accounts having keywords such as "periscope" or "Sisense." Additionally, analyze your logs for actions indicative of service account creation, such as the sequence:

1. CreateServiceAccount
2. SetIAMPolicy
3. CreateServiceAccountKey

This sequence is typical for creating service accounts generally, but when combined with specific details like account description, name, or dates, related to Sisense integration, it becomes more insightful.

Additionally, focus on service accounts which seen related to SetIAMPolicy operation contained the necessary BigQuery premissions required by Sisense ('bigquery.tables.read' for tables under 128MB and 'bigquery.tables.editor' otherwise).

Revoking Credentials

To get the permissions that you need to disable service account keys, ask your administrator to grant you the following IAM roles on the project:

• Delete Service Accounts (roles/iam.serviceAccountDeleter)

And after you have the proper permission, you can use gcloud command to finish the disable the service account:

gcloud iam service-accounts disable SA_NAME@PROJECT_ID.iam.gserviceaccount.com

Important: Disabling a service account key does not revoke short-lived credentials that were issued based on the key. To revoke a compromised short-lived credential, you must disable or delete the service account that the credential stands for. If you do so, any workload that uses the service account will immediately lose access to your resources.

Threat Hunting: Proactive Security Measures

To proactively identify potential threats associated with the Sisense breach on Google Cloud Platform (GCP), leverage Admin Activity logs and Data Access audit logs to monitor all actions linked to the Sisense service account and its associated access keys.

First, ensure the logs are configured to capture a comprehensive range of events, including administrative actions and data access events such as reads from BigQuery and Service Account related actions. Once you understand which service account related to Sisense integration we recommend focusing on the "authenticationInfo.principalEmail" field in the logs to identify actions performed by the Sisense service account.

Secondly, we suggest creating detections that focus on this Service Account activity. Begin by examining its assigned IAM permissions. If you discover that it has more IAM permissions than necessary for BigQuery integration, it is either suspicious or indicative of bad practice. In a scenario where an attacker exposes the credentials of this service account, you want to minimize the impact of the attack and ensure that only the necessary permissions for data processing are granted.

Finally, in your threat detection strategy, ensure to conduct regular searches for Sisense integrations and users conducting activities from IPs outside of approved ranges like 107.23.195.228 and 54.236.224.46 across integrated data sources and services.

Keep an eye out for any anomalies such as:

• unusual user creations or resources attributed to Sisense integration
• unusual user agent identifiers
• unexpected IP address geolocations
• surges in access failures suggesting illicit access attempts.
• unusual data retrieval behaviors from services like BigQuery

Also, thoroughly analyze actions executed by integration access keys utilized for Sisense data integration to spot any irregularities or potential security breaches.

Mitiga's Solutions in Action

Mitiga’s Investigation Workbench, a cyber solution that provides instant clarity on all multi-cloud and Software-as-a-Service (SaaS) activities through a single pane of glass. Allows our customers to investigate the actions performed by different entities, including AWS Access keys, Azure service principals and GCP service accounts.

The Investigation Workbench provides the capability to have fast and easy context-informed threat analysis by retrieving the actions and events related to the access key for the chosen timeframe and selected platforms – allowing the investigators the ability to get a trusted and fast verdict for each action to determine if it was a routine and benign action, or if was a malicious action done by a compromised identity.

This allows security teams to identify activities performed by specific identities across their cloud and SaaS platforms in a noticeably short time frame and will assist in determining if a platform has been breached and if and access key was already compromised by threat actors.

In addition to Workbench. Mitiga also offers a comprehensive Incident Response Service designed to assist organizations in effectively managing and mitigating security incidents. Leveraging Mitiga's expertise and advanced methodologies, this service provides a rapid and coordinated response to security breaches, minimizing the impact on operations and data integrity.

Summary

The Sisense breach, disclosed in April 2024, exposed vulnerabilities in data security practices and underscored the critical importance of proactive threat hunting. This guide provides a comprehensive overview of the breach's implications for potential Sisense customers, detailing the proactive measures taken by Sisense and offering actionable steps for threat detection and mitigation. While examples of AWS and GCP searches were provided, it's imperative for Sisense customers to extend their verification efforts to every platform integrated with Sisense, including other cloud providers such as Azure and SaaS like Google Workspace. By understanding the nature of the breach and implementing recommended security protocols across all integrated platforms, organizations can fortify their defenses and mitigate risks associated with third-party integrations.

‍