Insider Lab

The 2018 Cisco WebEx hack serves as a stark reminder of the risks posed by insider threats in today’s digital landscape. With over 39 million users relying on WebEx for virtual conferencing, the sabotage carried out by a disgruntled ex-employee had far-reaching consequences, both financially and operationally.  In 2018, 456 virtual machines hosting WebEx services were deleted, resulting in $2.4 million in damages for Cisco.

A similar event in Singapore has highlighted the vulnerabilities in IT systems. An employee who was fired hacked into the computer system of NCS and deleted 180 virtual servers, causing the company to lose S$918,000.

Delving into the Cisco WebEx service hack, this article aims to offer an easy-to-read guide accompanied by illustrative details. Additionally, we will provide guidelines for detection.

What happened in the Cisco WebEx hack?

In April 2018, Ramesh, an engineer, resigned from Cisco. During Ramesh’s tenure at Cisco, he was given access to Cisco’s AWS account to maintain the virtual machines responsible for the WebEx services.

In September 2018, Ramesh discovered that even after he had left the company, he could still access Cisco’s AWS account with the AWS key that had been provided to him during his employment. Using this key, Ramesh logged into Cisco’s AWS tenant (2). Notably, Ramesh performed the login from his new workplace without any attempt to mask his company’s internet address.

Ramesh, still having high privileges to manage the virtual machines, deleted at least 456 virtual machines from Cisco’s AWS tenant (3).

Mapping the Attack: Tactics, Techniques, and Procedures (TTPs)

The sabotage executed by Ramesh can be mapped to specific Tactics, Techniques, and Procedures (TTPs) in the MITRE ATT&CK framework. Understanding these TTPs is crucial for preventing similar attacks in the future. We will subsequently refer to Ramesh as the “threat actor”.

How to detect and prevent similar insider threats

Effective detection and prevention of insider threats requires a proactive approach. Let’s break down the timeline and explore possible detection strategies.

Stage 1: Detecting Unauthorized Access

When the threat actor accessed Cisco’s cloud resources from his new company’s location, several red flags could have been detected:

1. Detecting logins from unusual IP
2. Detecting logins from an unusual software agent
3. Dormant account detection (Account inactive for over extended period)

The screenshot below is CSX detecting unusual IP and user agents.

Stage 2: Detecting Malicious Activities

When the threat actor deleted a large number of virtual machines, this activity could have been detected by:

1. An unusually high number of virtual machines deleted.
   Since the accounts do not usually delete this much virtual machines, this form of alerting will have very low false positives.

The screenshot below is CSX detecting multiple VM instances being terminated.

There may have been more actions carried out by the threat actor that were not reported. It is typical for the threat actor to perform reconnaissance and enumeration before carrying out the main part of the attack. Some examples include executing a number of privileged activities to verify the privileges of the compromised account. These can be detected by comparing the usual privileged activities an authentic account would perform with those executed by the threat actor.

The following table summarizes the threats demonstrated by the threat actor and the corresponding detection strategies.

Threats	Detection strategies	Stage in illustration
Threat actor login from new office location	Login from unusual IP Login with unusual client agent Suspicious login from inactive account	1
Mass removal of virtual machines	Change in VM access pattern	2

Staying ahead of cyber threats

InsiderSecurity’s advanced solutions for cyber threat detection

Looking for ways to stay ahead of any cyber threats? InsiderSecurity provides advanced cybersecurity behavior analytics products that help your company to uncover cyber threats before there is any serious data loss. We offer a range of solutions, including Automated UEBA for securing on-premise and cloud IT infrastructure, as well as the CSX for ensuring cloud data security.

CSX is designed to detect sophisticated attacks described in this article, making it an essential subscription for any organization serious about its cybersecurity posture. Beyond detecting threats, CSX offers recommendations and a user-friendly avenue for executing remedial actions and implementing mitigation strategies.

CSX provides an easy way to perform mitigation and remediation.

Conclusion

The Cisco WebEx sabotage case underscores the critical importance of robust cybersecurity practices, particularly in managing employee access and detecting insider threats. By learning from this incident and implementing advanced detection strategies, companies can better protect their digital assets and ensure that similar attacks are thwarted before they cause significant damage.

In a stark reminder of the critical importance of cybersecurity in today’s digital age, Securitas, a multinational security services company based in Stockholm, inadvertently exposed over 3TB of sensitive data (more than 1.5 million files). This data, belonging to their airport clients in Colombia and Peru, dates back to 2018 and includes personal information about employees working at these airports.

The Breach: How Misconfigured S3 Buckets Led to Data Exposure

The breach involved an AWS S3 bucket which are a widely-used, reliable, and scalable cloud storage platform designed to store various types of files. The following illustration provides a quick glimpse of the files commonly stored in the S3 bucket.

However, in this case, a simple misconfiguration of the S3 bucket led to a massive data exposure. Delving into the data exposure, this article aims to offer an easy-to-read guide accompanied by illustrative details. Additionally, we will provide guidelines for detection.

What happened?

In 2021, Securitas inadvertently misconfigured an AWS S3 bucket containing employee information for airport workers. This likely occurred due to human error, with no indications that the misconfiguration was caused by a threat actor. SafetyDetective’s cybersecurity team discovered the exposure in October 2021, and Securitas fixed the issue in November 2021.

While there were no reports of breaches or the exposed data appearing on the dark web, the duration of the misconfiguration remains unknown. Given an extended exposure period, a malicious actor could have potentially accessed large amounts of sensitive data.

The Risks of Misconfiguration

Misconfigured cloud storage can lead to unintended data exposure, potentially giving unauthorized users access to sensitive information. In the case of Securitas, the exposed data included highly sensitive personal details of airport employees, which could have been exploited by malicious actors had they discovered the vulnerability.

Detection and Prevention: How to Safeguard Against Misconfigurations

There are opportunities for detection. When the administrator has misconfigured the S3 bucket, we can detect such activities by:

Detecting for ‘bucket allow public access’ event.

Instead of relying on good Samaritans to discover these vulnerabilities, organizations must take active steps to monitor and secure their cloud infrastructure, minimizing the risk of accidental data exposures due to human error.

Staying ahead of cyber threats

Innovative solutions by InsiderSecurity

Looking for ways to stay ahead of any cyber threats? InsiderSecurity provides advanced cybersecurity behavior analytics products that help your company to uncover cyber threats before there is any serious data loss. We offer a range of solutions, including Automated UEBA for securing on-premise and cloud IT infrastructure, as well as the CSX for ensuring cloud data security.

CSX is designed to detect sophisticated attacks described in this article, making it an essential subscription for any organization serious about its cybersecurity posture. Beyond detecting threats, CSX offers recommendations and a user-friendly avenue for executing remedial actions and implementing mitigation strategies.

CSX provides an easy way to perform mitigation and remediation.

Conclusion

The Securitas data exposure incident serves as a sobering reminder of the potential consequences of cloud misconfigurations. As cloud storage becomes increasingly integral to business operations, ensuring the security of these systems is paramount. By implementing robust detection strategies and continuously monitoring cloud configurations, organizations can protect their digital assets and avoid the costly consequences of data breaches.

Intro

There’s been a rising threat concerning compromised SaaS identities due to phishing, even with multi-factor authentication (MFA) in place.  Has MFA proven ineffective? Not exactly, but we are witnessing a surge in a type of known attack that’s becoming more prevalent that has always been effective against MFA. The attack in question is AitM (Adversary-in-the-middle).

This blog post will explore this old but emerging threat, enabling threat actors to bypass MFA. Furthermore, we’ll offer guidelines for detection.

How are threat actors bypassing MFA?

Similar to any successful phishing attack, the threat actor initially deceives the victim into visiting a website controlled by them (1)(2). The unsuspecting victim would then unknowingly provide their credentials to the threat actor’s website through a form or a login page (3). If MFA has not been enabled for the account, the threat actor could simply reuse the credentials (4)(6) to gain access to the victim’s account.

If MFA is enabled for the account, the threat actor must ensure that the victim completes the authentication process with the correct MFA provided (6)(7). This can be achieved by ensuring that the actual server is able to authenticate the legitimacy of the MFA provided. In this scenario, the stolen credential alone will not be particularly useful for the threat actor. Instead, they will rely on the stolen OAuth2 tokens or session cookies (8) to access the actual service.

The threat actor could easily insert the stolen session cookie into their browser to access the actual web service (9).

However, session cookies have a limited usage period, and the threat actor needs to complete their intended operations with the account as quickly as possible. At this stage, the threat actor could either download all the files and emails before the session expires (11).

Alternatively, the threat actor could attempt to maintain access to the account over a longer period. This can be achieved by registering a new MFA device (10).

Mapping the MFA-bypass attacks to MITRE ATT&CK framework

We can map the attacks to the following Tactics, Techniques, and Procedures (TTPs) in MITRE.

Strategies to detect MFA-bypass attacks

There are several opportunities for detection. Let’s examine the attack sequence and outline potential detection strategies.

During Stage 9 of the attack, when the threat actor reuses the session cookie to access cloud resources, we can depend on the Azure AD log to detect the following anomalies:

1. Identifying logins from unusual locations or instances of rapid location changes.
2. Recognizing logins from VPN IP ranges.
3. Noticing changes in browser agents.
4. Attempt of user privilege escalation

Based on our testing, we have verified that we could access Microsoft 365 resources without encountering any authentication prompts by simply reusing a cookie session captured from our test environment. Additionally, we observed that a new ‘UserLoggedIn’ operation, including the threat actor’s IP address and browser agent, would be recorded in the audit trail accessible within the Audit Management Log. This ‘UserLoggedIn’ operation signifies that a new login event has taken place.

    "ActorIpAddress": "XX.XX.XX.XX",
    "ClientIP": "XX.XX.XX.XX",
    "CreationTime": "2024-04-03T03:12:48",
    "ExtendedProperties": [
      {
        "Name": "ResultStatusDetail",
        "Value": "Success"
      },
      {
        "Name": "UserAgent",
        "Value": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0"
      },
      {
        "Name": "RequestType",
        "Value": "OAuth2:Authorize"
      }
    ],
    "Operation": "UserLoggedIn",
    "UserId": "test_victim@insidersecurity.co",

During Stage 11, when the threat actor accesses an unusually high number of files, we can depend on the Audit Management Log to detect the following anomalies:

• Detection of a spike in file or email access.

Finally, if the threat actor establishes a new MFA device, we can rely on the Audit Management Log to identify the following anomaly:

• Addition of a new MFA device.

Summary of detection strategies

Below is a summary table outlining the threats demonstrated by the threat actor on the cloud and corresponding detection strategies.

Threats	Detection strategies	Stage in illustration
Threat actor logins with stolen account	Login with an unusual browser agentLogin from one country to another within a short span of timeLogin from an unusual country	9
Addition of new MFA device	Suspicious MFA device creation	10
High amount of data downloaded	Suspicious amount of file downloaded	11

Staying ahead of cyber threats

Innovative solutions by InsiderSecurity

Looking for ways to stay ahead of any cyber threats? InsiderSecurity provides advanced cybersecurity behavior analytics products that help your company to uncover cyber threats before there is any serious data loss. We offer a range of solutions, including Automated UEBA for securing on-premise and cloud IT infrastructure, as well as the CSX for ensuring cloud data security.

CSX is designed to detect sophisticated attacks described in this article making it an essential subscription for any organization serious about its cybersecurity posture. Beyond detecting threats, CSX offers recommendations and a user-friendly avenue for executing remedial actions and implementing mitigation strategies.

Intro

This is the third installment in a series that delves into hacks spotlighted in CSA’s renowned paper on the Top Threats to Cloud Computing. Focusing on the threat actors behind the UBER hack, this article aims to provide a user-friendly guide complemented by illustrative details. Furthermore, we will provide detection guidelines.

What happened?

LAPSUS$, alternatively recognized as DEV-0537, represents a threat actor group that has remained active over recent years. They have directed their efforts towards big technology companies including Microsoft, Uber, Nvidia, and Samsung.

Within this article, we will delve into the documented hacks orchestrated by LAPSUS$ targeting Microsoft 365 and Microsoft Azure cloud platforms. Furthermore, we will examine the detection strategies derived from these incidents.

Understanding the Uber hack

The threat actor is notorious for purchasing credentials from disgruntled insiders (1). These credentials are then utilized by the threat actor to infiltrate the corporate network (2), moving laterally internally within the corporate network, and ultimately identify the global administrator account (3) necessary for complete access to the corporation’s cloud resources.

The accompanying screenshot depicts a text found in a Telegram channel where the threat actor actively solicits credentials from potential insiders.

In the past, attackers were known to move laterally from one machine to another within the on-premise network. However, it has become increasingly common for attackers to pivot laterally from the on-premise environment to the organization’s cloud.

These attackers were observed using NordVPN (4) to obfuscate their originating IP addresses.

Once inside the Azure portal, the attackers were observed creating a new global administrator account (5) —a super administrator equivalent in Azure—as a backup, along with a virtual machine (6) to serve as a tooling server to advance their attack.

To hinder the organization’s recovery efforts, the attackers established an organization-wide email transport rule to redirect (7) all emails to another email account under the attackers’ control. They also removed all other global administrator accounts (8) to impede the organization’s recovery from the attack.

Mapping Uber hack techniques: A focus on MITRE’s TTPs

We can map the cloud-related attacks to the following Tactics, Techniques, and Procedures (TTPs) in MITRE.

Detection strategies: Identifying and mitigating threats

There are multiple opportunities to notice if something is wrong. Let’s go through the steps in the timeline and find out how we can catch these problems.

In the fourth stage of the attack, we can find signs of suspicious logins into Azure AD by checking the Azure AD or Audit management log for logins coming from:

• Unusual country, when the user logs in from a country unusual for the account.
• Impossible travel, when the user hops from one country to another within an impossible period.
• Login from a known VPN (i.e. – NordVPN) 

In the next stage of the attack, the attacker created a new global administrator account (5) and VM (6). We can detect these actions by monitoring the Audit Log or User Activity Log for such privileged activities.

In the final phase of the attack, the attacker created an organization-wide email transport rule (7) and removed the global administrator accounts (8). We can also detect these actions by monitoring the Audit Management Log for such privileged activities.

Below is a summary table outlining the threats demonstrated by the threat actor on the cloud and corresponding detection strategies:

Threats	Detection strategies	Stage in illustration
Threat actor logins with stolen account	Login from known VPNLogin from one country to another within short span of timeLogin from an unusual country	4
Creation for VM	VM creation from an unusual accountVM creation in an uncommon zone	5
Creation of a global administrator account	Suspicious account creationAssignation of privileged role	6
Forwarding all emails to an external email address	Suspicious creation of email transport rule	7
Removal of administrator accounts	Suspicious account removal	8

Staying ahead of cyber threats

Innovative solutions by InsiderSecurity

Looking for ways to stay ahead of any cyber threats? InsiderSecurity provides advanced cybersecurity behavior analytics products that help your company uncover cyber threats before there is any serious data loss. We offer a range of solutions, including Automated UEBA for securing on-premise and cloud IT infrastructure, as well as the CSX for ensuring cloud data security.

CSX is designed to detect sophisticated attacks described in this article, making it an essential subscription for any organization serious about its cybersecurity posture. Beyond detecting threats, CSX offers recommendations and a user-friendly avenue for executing remedial actions and implementing mitigation strategies.

Welcome to the second installment of our series, in which we highlight notable cyber attacks featured in the CSA’s report, “Top Threats to Cloud Computing.”

In this article, we turn our focus to APT29—a sophisticated threat actor behind the breaches at the Portuguese and Brazilian Embassies. Our goal is to present this information in a clear, reader-friendly format, enriched with detailed examples. We also aim to provide actionable detection strategies for these kinds of cyber threats.

Understanding APT29: A new era of cyber espionage

APT29, also known as Nobelium or Midnight Blizzard, is a prominent cyber espionage group that has made multiple headlines over the past several years. This group has executed sophisticated cyber attacks targeting an array of entities — from governmental bodies such as the Portuguese and Brazilian Embassies, to corporate giants like Microsoft.

In a joint advisory, the Five Eyes agencies cautioned that APT29 is adapting to modern IT environments, particularly the widespread adoption of cloud-based infrastructure. Shifting from traditional exploitation of on-premises network vulnerabilities, APT29 now specifically targets cloud services. Notably, the group has been actively targeting Azure and Microsoft 365 environments.

In the following analysis, we will thoroughly examine the documented attacks by APT29 on Microsoft’s cloud infrastructure and discuss the strategies for detection that can be developed based on these incidents. This exploration aims to provide insights into the operational methods of APT29 and offer guidance on enhancing cybersecurity preparedness against such sophisticated threats.

APT29’s methodology in cloud-based attacks

The attacker executed a password guessing attack (1) against Microsoft’s own internal cloud tenant, which hosts the Microsoft 365 services. These attackers were observed using residential proxies (2) to conceal their origin IP addresses.

By sheer luck, the attacker successfully discovered a test account (3) that was not protected with MFA.

After successfully logging in, the attacker found a legacy OAuth Application (4) accessible by the breached account, which held a high level of privileges. This OAuth Application is also known as an ‘Enterprise App’ in Azure AD. It was likely discovered through the enumeration of all Azure Applications to identify accessible services and resources with the breached account.

The attacker proceeded to create a new Azure AD account (5) and a new malicious OAuth Application (6) through the legacy OAuth Application with high privileges (4).

Subsequently, the attacker disabled auditing for ‘Purview’ (7) and used the new malicious OAuth Application to read the emails of all users in that tenant. Due toPurview being disabled, there was no audit trail of the OAuth Application reading the email.

Mapping APT29’s Techniques: A Focus on MITRE’s TTPs

By aligning APT29’s actions with the MITRE ATT&CK framework, we can categorize and understand their tactics, techniques, and procedures (TTPs) more effectively. This alignment helps in developing targeted defenses against their known strategies.

Detection strategies: Identifying and mitigating threats

There are multiple opportunities to notice if something is amiss. Let’s go through the steps in the timeline and find out how we can detect these problems.

In the first part of the attack, we can find signs of a password guessing attack by checking the Azure AD or Audit management log. We can look for successful logins that come after failed ones (A). 

In the same login actitivties, we can also find suspicious logins from places that aren’t normal for the organization or account, such as logins from a VPN IP range (B) that the attacker used in the second part of the attack.

In the fifth part of the attack, the attacker created a new account in Azure AD. We can detect this by keeping an eye on the Audit management log for such privileged action (C).

In the sixth part of the attack, the attacker made a new privileged application in Azure AD. Similarly, we can detect this by looking through the Audit management log for such privileged actions (D).

In the last stage of the attack, the attacker disabled the Purview auditing.

The following table outlines the threats demonstrated by the threat actor and the corresponding detection strategies.

Threats	Detection strategies	Stage in illustration
Password guessing attack	Successful login with multiple failed attempts	A
Suspicious login from residential proxy	Login from one country to another within short span of timeLogin from unusual country	B
Creation of global administrator account	Suspicious account creationPrivileged role(s) assigned	C
Creation of malicious enterprise application	Suspicious enterprise applications created	D
Disabling of Purview audit logs	Audit logging disabled	E

Staying ahead of cyber threats

Innovative solutions by InsiderSecurity

Looking for ways to stay ahead of any cyber threats? InsiderSecurity provides advanced cybersecurity behavior analytics products that help your company to uncover cyber threats before there is any serious data loss. We offer a range of solutions, including Automated UEBA for securing on-premise and cloud IT infrastructure, as well as the CSX for ensuring cloud data security.

CSX is designed to detect sophisticated attacks described in this article making it an essential subscription for any organization serious about its cybersecurity posture. Beyond detecting threats, CSX offers recommendations and a user-friendly avenue for executing remedial actions and implementing mitigation strategies.

Understanding the LastPass hack

This marks the initiation of a series exploring hacks spotlighted in CSA’s renowned paper on the Top Threats to Cloud Computing. Delving into the LastPass hack, this article aims to offer an easy-to-read, illustrated guide. Additionally, we will provide guidelines for detection.

LastPass, a Software as a Service (SaaS) provider, offers a password vault service. These services are typically used for the secure storage of secrets and are popular with security-conscious individuals, as they facilitate the secure and easy storage of complex passwords.

LastPass assures customers that they do not have knowledge of the actual secret stored in their system because of LastPass’s zero-knowledge architecture, which includes the following:

1. Data is stored encrypted in LastPass’s database.
2. The encrypted data can only be decrypted with the master password provided by the customer just-in-time.
3. The master password provided by the customer is never stored in any persistent storage in LastPass’s system.

The following diagrams help illustrate how such a password vault works.

Step 1: The customer launches the password vault software and provides the master password. The master password might be salted or hashed further to ensure secrecy in transit before it is sent to the password vault’s server for authentication. Upon successful authentication, the password vault server sends the encrypted secrets to the customer.

Step 2: The customer can now decrypt the encrypted secrets with the master password. These secrets can typically be copied into the clipboard for Just-in-time usage. In the illustration, the customer has decrypted and copied the ‘Secret A’ into the Clipboard. The customer can now login to another software or web portal which requires Secret A to access.

In the incident of LastPass hack, the customer’s encrypted password (X), as shown in the illustration, was stolen. Additionally, customer information, such as the company name and the URL where the decrypted password could be used, was also compromised.

One can imagine the impact this could have had on the industry if the attacker had been able to decrypt any password they had stolen. This would mean the attacker could access any password-protected systems easily accessible from the internet. Of course, this is only applicable if 2FA is not present in those accounts!

The LastPass hack unveiled

How possible is it to decrypt the secrets stolen from LastPass?

Since the secrets are stored encrypted, what are the possibilities that the attacker could recover the secrets? There are multiple ways these encrypted passwords can be decrypted, and we will be discussing two possible methods:

• Password guessing:

As the secrets are stored encrypted with the customer’s master password, if a weak master password has been used, the attacker can easily guess the customer’s master password to access the data and reveal all the passwords stored by the customer.

• Tampering with the backend code:

If the attacker compromises the backend server responsible for decrypting the encrypted data and plants malicious code, they could potentially log the customer’s master password and use it to decrypt the stolen data.

How the Attack Happened

In early August 2022, attackers successfully accessed LastPass’s S3 bucket in a development environment and exfiltrated source code together with technical documents (4). A developer’s valid credentials, stolen from the developer’s compromised machine (1), were used to access the S3 bucket (3). It is interesting to note that the developer does not usually access those resources on S3; however, the access given to the developer has been overly permissive. It is also noted that the attackers obfuscated their original location by accessing the cloud resource over VPN (2).

In mid-August 2022, the LastPass security team discovered the hack and decommissioned the development environment, under the assumption that the attacker’s activity had been contained.

In October 2022, a LastPass Senior DevOps engineer’s machine was compromised (5) and used to access the DevOps engineer’s LastPass corporate vault. This allowed the attacker to access the corporate vault in the S3 bucket (6), which contains backups of LastPass customer data and encrypted vault data. Fortunately, the customers’ secrets remain safe as they are encrypted in the customer’s master key due to the zero-knowledge architecture.

LastPass discovered the hacks after the attackers triggered an ‘IAM unauthorized activity’ alert generated by AWS GuardDuty, likely be caused by running reconnaissance and enumeration operations (4).

We can map the attacks to the following Tactics, Techniques, and Procedures (TTPs) in MITRE.

Detection and prevention strategies

There are multiple opportunities for detection. Let’s walk through the timeline and determine possible detection strategies.

In (2) and (3), when the attacker was accessing the cloud resource over VPN, we can detect such activities by:

1. Detecting logins from unusual locations or fast-flux location changes.
2. Detecting logins from VPN IP ranges.

Storage locations with sensitive data should be tagged, and accessing such data should be monitored. In (4) and (7), when the attacker was accessing sensitive data, we could trigger an alarm.

In (6), when the attacker exfiltrated a hoard of data from the S3 buckets, we can detect this by monitoring for an unusually high intensity in data access. Since the accounts do not usually access that data, this form of alerting will have very low false positives.

Finally, when the attackers are performing reconnaissance and enumeration, they tend to execute a number of privileged activities to verify the privileges of the compromised account. These can be detected by comparing the usual privileged activities the authentic account would perform with those executed by the attacker.

Staying ahead of cyber threats

Innovative solutions by InsiderSecurity

Looking for ways to stay ahead of any cyber threats? InsiderSecurity provides advanced cybersecurity behavior analytics products that help your company to uncover cyber threats before there is any serious data loss. We offer a range of solutions, including Automated UEBA for securing on-premise and cloud IT infrastructure, as well as the CSX for ensuring cloud data security. 

CSX is designed to detect sophisticated attacks described in this article making it an essential subscription for any organization serious about its cybersecurity posture. Beyond detecting threats, CSX offers recommendations and a user-friendly avenue for executing remedial actions and implementing mitigation strategies.

CircleCI, a well-known CI/CI (continuous integration and continuous delivery) platform provider, fell victim to an advanced Cyber Attack and was alerted to a suspicious GitHub OAuth activity by one of CircleCI’s customers on December 29, 2022. The attacker planted malware in the laptop belonging to a CircleCI’s employee and gained unauthorized access to its production systems to extract sensitive data. Although the data was encrypted, the attacker managed to obtain the encryption keys, which could potentially grant them access to the decrypted data. The CircleCI’s breach was significant as CircleCI was serving prominent companies such as Meta, Okta, Salesforce, and Airbnb. In this article, we analyze the details of the incident, how it happened, and what measures can be put in place to protect against similar attacks. 

What happened in the CircleCI’s breach?

The attack started with a compromise of a CircleCI employee’s laptop through malware. The attacker could access the employee’s laptop and stay undetected, which allowed them to gain access to the company’s network. The attacker reused the existing login session found in the employee’s laptop to impersonate the employee and gain further access, effectively allowing the attacker to by-pass two-factor authentication. This allowed them to move further laterally within the network to gain access to production level systems and data.

The key sequence of steps in the attack was:

• The employee laptop was compromised on December 16, 2022
• Attacker performed reconnaissance on December 19, 2022
• Attacker gained access and collected data on December 22, 2022

How the CircleCI’s attack succeeded

The attack succeeded due to a failure of several essential controls:

• Firstly, the attacker compromised a laptop belonging to CircleCI’s engineer and planted a backdoor. CircleCIs’ anti-malware solution did not detect the malware, which allowed the attacker to further continue their activities and remain undetected for an extended period (step 1). 
• Secondly, the attacker reused the web session cookie stored on the laptop (step 1).
• Thirdly, this attacker impersonated a CircleCI employee who has been authorized via multi-factor authentication and gained access to production systems (step 1).
• Fourth, the attacker further escalated their breach by successfully downloading an array of highly sensitive data including SSH keys, API tokens, OAuth tokens, and an AWS IAM access key (step 1).
• Fifth, armed with the SSH keys and tokens, the attacker could seamlessly reuse these credentials to infiltrate not only CircleCI’s internal systems but also gain illicit access to invaluable resources such as the customer’s repo and AWS resources (step 2).
• Finally, the attacker extracted encryption keys from CircleCI’s customer code repository. Despite the company following best practices by encrypting sensitive information such as AWS keys and GitHub tokens, the attacker gained access to the keys needed for decryption (step 2).

As is obvious the attack was multifaceted, with attacker abusing the trust present in the employee’s laptop to impersonate authorized requests. Their careful network reconnaissance allowed them to plan further attacks, increasing their chances of success. This allowed the second phase of the attack, i.e., the data exfiltration attempt to succeed, allowing them to compromise highly sensitive data.

What does CircleCI do?

CircleCI took several steps to contain the breach once it was detected to limit the blast radius of the attack. The level of exposure post-attack was challenging to determine as the compromised staff had production access and access to customer tokens and keys. The attacker might have exfiltrated further data without leaving any traceable evidence. CircleCI took a transparent approach to the incident and informed its customers of how the attack had taken place. It issued regular updates to customers and advised them to rotate all of their credentials, such as SSH keys, OAuth tokens, etc., to mitigate the risk of further misuse by the attacker. It also revoked Project API tokens and personal API tokens to limit the potential entry points the attacker could exploit following the attack.

Secondly, it recognized the security failings that allowed the attack to succeed and initiated a comprehensive review of its environment. It strengthened production access controls, introducing additional controls for employees needing access to systems. This was intended to mitigate the risk of session compromise in the future via stolen session cookies.

Lastly, it enhanced its capabilities to detect specific behaviors indicative of attacks such as the one that occurred. Attacks such as lateral movement and malware activity were focused on to ensure no similar attacks occurred.

CircleCI also assured its customers of regular security reviews and risk assessments to identify weak areas and areas of improvement. There have been reports of customers who have reported attacker misusing the stolen credentials, so it is possible that the impact of the breach is yet to be determined.

Key lessons to learn from the CircleCI’s breach

The CircleCI data breach is a prime example of how sophisticated attacks can undermine even the most reliable security controls such as encryption and multi-factor authentication. Advanced threats are aware of these controls and adopt techniques to evade or bypass them. To remain updated, continually evaluating your security posture against the latest threats is essential.

Some of the key lessons from this breach are:

• Traditional security controls may no longer be enough. Companies need to adopt techniques like biometrics and machine-learning-based anomaly detection that can detect subtle variations in behavior that human security analysts might miss.
• Devices like laptops and smartphones remain a vulnerable entry point into a network as it was one compromised endpoint that allowed the attacker the access they needed to carry out further attacks. Companies need to look into re-architecting their networks based on Zero Trust principles. This architecture assumes that every request is potentially malicious and no implicit trust is assumed regardless of location or device.
• Key Management best practices remain as critical as ever. Even though CircleCI had implemented encryption, the attacker could retrieve the encryption keys from a running process on the machine. Protecting encryption keys is crucial to key management, as a compromised key can undermine the entire security strategy.

On a positive note, it should be mentioned that CircleCI displayed proper transparency regarding the attack and took immediate remedial action once they detected it. Despite the security weaknesses that allowed the attack to occur, companies should note how they informed customers and released notifications regarding the scope of the incident.

Conclusion on the CircleCI’s breach

Like SolarWinds, the CircleCI attack is a wake-up call for companies to not be over-reliant on controls like multi-factor authentication and encryption. Instead, a company’s cybersecurity posture must be evaluated continuously to assess its resilience against advanced cyber-attacks. By adopting controls like zero-trust architecture, machine learning based detection, and a proactive stance towards cybersecurity; companies can significantly mitigate the risk of falling victim to such attacks like CircleCI.

How InsiderSecurity can help

InsiderSecurity provides robust solutions to detect and thwart attacker tactics and techniques used in the CircleCI breach. With InsiderSecurity’s solutions, organizations can detect potential attacks early, significantly reducing or even preventing data loss.

For example, InsiderSecurity’s Automated UEBA (User and Entity Behavior Analytics) solution effectively counters the risk of compromised servers. It identifies the unauthorized use of stolen SSH keys, which is a tactic used by the CircleCI attackers. Additionally, InsiderSecurity’s CSX cloud security solution secures cloud environments against unauthorised access. It expertly identifies suspicious activities, such as the misuse of stolen session cookies or the unauthorized use of cloud credentials for platforms like AWS and other SaaS services — tactics similar to those employed by the CircleCI attackers. These comprehensive measures ensure that your digital assets remain secure against evolving cyber threats.

Introduction

In today’s digital age, cybersecurity is of paramount importance, with organizations facing an ever-evolving landscape of cyber threats and attacks. InsiderLab (our team of cybersecurity experts) conducts in-depth research and analysis of historical and emergent cyber threats, empowering organizations with the foresight needed to proactively safeguard their digital landscapes.

Amid recent events, the InsiderLab team has scrutinized the tactics and exploitation methods employed by high-profile threat actors. Through tireless investigations, InsiderLab has uncovered critical insights that shed light on the world of cyber threats. These findings not only raise awareness but also provide a comprehensive understanding of the evolving threats that organizations face today.

In this report, we focused on high-profile attacks, particularly those involving compromised Microsoft 365 accounts and studied the tactics used by these attackers. Each case study provides a unique window into the world of cyber threats, offering insights into the cunning methods employed by cyber adversaries and the vulnerabilities they exploit. Furthermore, InsiderLab released a free tool to aid in identifying similar classes of attacks.

Case study 1: Microsoft Storm-0558 SaaS breach

Uncovered in 2023, the threat actor behind the STORM-0558 attacks successfully accessed their victim’s Microsoft Exchange Online and Outlook accounts, completely bypassing 2FA (two-factor authentication). Notably, various U.S. government entities endured the brunt of the STORM-0558 onslaught.

These attackers were known to conduct their activity behind the SoftEther proxy VPN service, thereby masking their true IP addresses.

This was uncovered eventually discovered when the victims’ Microsoft 365 audit logs revealed that an unusual application was used to access the emails. In the blog provided by CISA (Cybersecurity and Infrastructure Security Agency), it was reported that the log entry for the ‘MailItemsAccessed‘ operations contained an unusual AppID. While it is difficult to define what is unusual, keeping track of what is typical would be useful in detecting these deviations.

For example, if the user typically uses the Outlook Express email client or Outlook.com to access their emails, a log entry with an unusual AppID (application identities) would attribute the access to a different application type, indicating a deviation in email access behavior.

The following illustration shows the difference between a threat actor and a legitimate user in accessing Exchange Online. The threat actor uses additional services such as a VPN and the Microsoft Graph API as shown in steps 1 to 3, while the legitimate user typically only uses a web browser as shown in step 4. This approach taken by the threat actor leaves an unusual AppID and client IP address in the audit trail.

Case study 2: SolarWinds SUNBURST attack

Moving on to another case study, we will discuss the SolarWinds SUNBURST Attack. Uncovered in 2020, the threat actor behind the SUNBURST attacks leveraged the Microsoft Graph API to perform data exfiltration. This SUNBURST attack impacted various government entities and major players within the technology sector.

The attackers searched for existing cloud applications with email access privileges, or alternatively, escalated the permissions of pre-existing applications. This cunning maneuver is meticulously documented in this research article , spotlighting the attacker’s utilization of the ‘Mail.ReadWrite’ permission within an existing cloud application to gain access to victim email content via said application.

Furthermore, an alternate strategy observed in a separate attack involved the dispatch of phishing emails by attackers. These deceitful communications were tailored to dupe victims into unwittingly granting consent to install malicious cloud applications. If the victim falls for this trick, attackers would be able to access the victim’s email and files via the malicious cloud application.

The following illustration describes the additional services such as the Graph API and the tainted enterprise application. The attacker would access victims’ emails as shown in step 1 to step 3, whereas the legitimate user would simply access the email directly via a web browser as shown in step 4. The attacker’s approach leaves an unusual AppID in the audit trail.

Case study 3: LAPSUS$ attacks

Now we turn to the LAPSUS$ Attacks, discovered in 2022. The attacker behind this mysterious name targeted many victims, including major tech companies. The attacker is known to access cloud resources via a VPN. A comprehensive account of this method is described in this Microsoft report, where the threat actor employs NordVPN as their conduit to hide their true IP addresses.

The attacker also added an email transport rule to forward emails from their victims to their own account.

The following illustration describes additional services such as the VPN service the attacker would use to access victims’ emails as shown in step 1 to step 2. The attacker’s approach leaves an unusual client IP in the audit trail.

Threat detection with CASUAL tool for compromised accounts

Given the ongoing high-profile breaches in Microsoft 365, our team is proud to introduce CASUAL (CloudAuditSearchUAL) —a user-friendly tool designed to uncover hidden cyber anomalies in the audit trail. Download CASUAL here.

CASUAL analyzes log entries in the Microsoft 365 Unified Audit Log (UAL) and produces a JSON file that contains the following information about accesses to Microsoft 365:

• Unique geolocations
• Unique application identities (AppID)

With this invaluable information in hand, the security team gains the upper hand, conveniently identifying:

• Identities accessing the cloud service from an extensive array of unique geolocations
• Identities engaging with the cloud service through a wide range of distinct applications
  
  

Now, let us move from theory to practice.

To generate a list of identities that have accessed Azure AD and their unique geo-location within the past 90 days, execute the following command:

./ual_tool.ps1 -ops ADLogin -analyze IP -days 90

The following output shows an actual result with an identity that has accessed Azure AD from over 3 unique geo-locations.

"ACCOUT_1":  {
    "Unique IP Count":  3,
    "Unique Countries Count":  3, 
    "IP Properties":  {
        "IP RETRACTED":  {
            "Count":  3,
            "Country":  "SINGAPORE"
        },
        "IP RETRACTED":  {
            "Count":  29,
            "Country":  "MALAYSIA"
        },
        "IP RETRACTED":  {
            "Count":  29,
            "Country":  "INDONESIA"
        }
    }
}

To generate a list of identities that have accessed Azure AD and their unique application accessed within the last 90 days, execute the following command:

./ual_tool.ps1 -ops ADLogin -analyze AppID -days 90

And the following output shows an actual result with an identity that has accessed Azure AD from over 7 unique application types.

"ACCOUNT_2":  {
    "Unique Count":  7,
    "AppID Properties":  {
        "4765445b-32c6-49b0-83e6-1d93765276ca":  {
                "Name":  "OfficeHome",
                "Count":  3
            },
        "89bee1f7-5e6e-4d8a-9f3d-ecd601259da7":  {
                "Name":  "Office365 Shell WCSS-Client",
                "Count":  18
            },
        "7eadcef8-456d-4611-9480-4fff72b8b9e2":  {
                "Count":  1,
                "Name":  "Unknown"
            },
        "c9a559d2-7aab-4f13-a6ed-e7e9c52aec87":  {
                "Name":  "Microsoft Forms",
                "Count":  2
            },
        "fb78d390-0c51-40cd-8e17-fdbfab77341b":  {
                "Name":  "Microsoft Exchange REST API Based PowerShell",
                "Count":  4
            },
        "243c63a3-247d-41c5-9d83-7788c43f1c43":  {
                "Name":  "Office Online Core SSO",
                "Count":  2
            },
        "00000003-0000-0ff1-ce00-000000000000":  {
                "Name":  "SharePoint Online",
                "Count":  2
            }
    }
}

The results can be sorted further based on the value of ‘Unique Count’. This will help analysts in identifying the identity with the most unusual access pattern.

The table below lays out an array of ‘ops‘ parameters, serving as a guide for analysts seeking to uncover anomalies across numerous services:

Parameter options	Services
ADLogin	Azure AD
OD_Access	OneDrive
SP_Access	SharePoint
EXO_Access	Exchange

In the CASUAL PowerShell script, you can find the mapping of operations to the parameters. And since Microsoft has pledged to expose more audit log types which are previously available only to organizations with the E5 licenses, the tool will be able to provide more visibility soon.

As you navigate through the intricacies of digital security, CASUAL can be an invaluable tool, streamlining your quest to find compromised identities. We hope that this tool empowers you and facilitates a smoother and more effective pursuit of cybersecurity excellence.

Limitations of CASUAL

1. Unusual Application types are not automatically identified
   CASUAL simply generates a list of identities discovered in the UAL and the AppIDs used by those identities. An AppID that may be considered unusual for one identity may be normal for another. For example, an account belonging to a security team member might be expected to use PowerShell to access the cloud services, but this could be unusual for someone in the finance team. It is important to apply proper context when analyzing the results. One way is to start building a baseline with the data generated by the tool.
   
2. Geo-location information may be inaccurate
   The geo-location could be misreported by the IP lookup service, or unresolvable due to the lookup cap enforced. If the tool reports an identity accessing the cloud service from an unexpected geolocation, verify the location by checking the IP with a reputation lookup service.

CSX – Simplifies cloud security

Unlike CASUAL, CSX (Cloud Security X) is designed to overcome the limitations mentioned above, making it an essential subscription for any organization serious about its cybersecurity posture.

CSX is an innovative solution that makes comprehensive and easy-to-use cloud security available. Leveraging innovative analytics and AI, CSX enables strong security across all layers of the cloud, covering IaaS, PaaS, and SaaS. CSX was also a project awarded by the Cyber Security Agency (CSA) of Singapore on CSA’s Cybersecurity Innovation Day 2022.

CSX reduces the personnel burden in cybersecurity. It saves costs for businesses while providing strong cloud security.

By subscribing to CSX, you are equipping your organization with cutting-edge technology that leverages AI, advanced analytics, and contextual awareness to provide a higher level of security intelligence. Embrace the limitless potential of CSX to safeguard your cloud assets and maintain a strong defense against ever-evolving cyber threats.

Mark your calendar: CSX will be launched in December, bringing in a new era of simplified yet comprehensive cloud security. Are you ready to embrace the future of cloud security?

InsiderSecurity conducts in-depth research and analysis on emerging cyber threats, so as to equip organizations with the knowledge to proactively protect themselves. In light of recent events, our Insider Lab team has thoroughly examined the methods and exploitation techniques employed by the notorious Volt Typhoon Attacks. Furthermore, we delved into the early detection strategies and practical measures to counter these threats. Here are the key findings from our investigation: 

Volt Typhoon attacks  

On May 24, 2023, Microsoft and the “Five Eyes Alliance” cybersecurity information sharing organization released a joint cybersecurity advisory, which detailed a series of activities related to the Volt Typhoon. According to Microsoft’s blog post, these malicious activities have been ongoing since mid-2021 and have targeted critical infrastructure sectors in Guam and the United States. The sectors affected include communication, manufacturing, utilities, transportation, construction, maritime, government, IT, and education. 

What sets these attackers apart is their extensive utilization of Living-off-the-land techniques (LOLT), which prioritize stealth and obfuscation. Remarkably, the attackers refrained from introducing any discernible malware, custom code, or binaries into the compromised systems. By doing so, they successfully evaded antivirus and endpoint detection and response (EDR) solutions, enabling them to freely navigate the networks and systems. 

In this article, Insider Lab provides valuable insights into detecting such stealthy attackers throughout the various stages of an attack. We focus on the utilization of User and Entity Behavior Analytics (UEBA), a behavioural-based security solution designed specifically to identify threats posed by these lurking attackers within the network. 

Stage 1: Entry and credential access 

During the initial phase of the attack, the intruder managed to gain entry into the enterprise’s intranet by initially infiltrating the router’s management interface (step 1).  

Note: While it is uncommon for the management interface to be exposed directly to the internet, this may be necessary if the device is managed by a third party.

Subsequently, they discovered credentials stored within the router, allowing them to access the network’s assets (step 2). 

To illustrate this stage, let’s consider a scenario where the attacker stumbled on the credential ‘RouterAdmin1’ stored within the router and utilized it to gain access to the domain servers present within the enterprise’s network. 

Note: The rationale to store access credentials (to other network assets) within the router is unclear. However, this might be necessary if specific capabilities of the router have been activated. One such example is when the router needs to retrieve specific records from the identity management server, which is typically the Domain controller.

To detect steps (1) and (2) effectively, behavioural-based algorithms can be leveraged. By monitoring deviations in login behaviour, the following three use cases can trigger alerts when the ‘RouterAdmin1’ account is misused: 

1. Odd Server Usage 
2. Unusual Login Time  
3. First-Time Server Login 

In the ‘Odd server usage’ use case, advanced behavioural analysis can detect anomalies in the usage patterns of the ‘RouterAdmin1’ account. In the event of lateral movement, if the ‘RouterAdmin1’ account is being used to access servers in a way that deviates significantly from a user’s previous patterns, an anomaly alert will be generated. For example, if an attacker gains access to the ‘File server’ and ‘Mail server’ by utilizing the ‘RouterAdmin1’ account instead of the authorized user’s account, this would trigger an alert. 

In the ‘First-time login into server’ use case, an anomaly alert will be promptly triggered when the account logs into the server for the first time. 

In the ‘Unusual login time’ use case, an anomaly alert will be generated when the account logs into the server at a time that significantly deviates from its established login timing. 

The convergence of these anomalies will increase the risk score associated with the ‘RouterAdmin1’ entity, strongly indicating malicious activities. 

Stage 2:  Command & Control 

During stage 2 of the attack, the attacker utilizes the PSEXEC to execute commands on a remote server. PSEXEC.EXE, a Microsoft tool, enables privileged users to launch processes on a remote server. Based on the NSA’s document the attacker launches the NETSH.EXE command on the File server using PSEXEC.EXE in the Domain controller (step 3). 

C:\pstools\psexec.exe” \\{REDACTED} -s cmd /c “cmd.exe /c “netsh interface portproxy delete v4tov4 listenaddress=0.0.0.0 listenport=9999”

The attacker was also observed executing the following command to establish a network connection tunnel. 

netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=9999 connectaddress={REDACTED} connectport=8443 protocol=tcp

To effectively detect steps 3 and 4, which involve the execution of privileged actions, the following use cases can be leveraged: 

1. Privileged Network Drive Access 
2. Creation of New Service 
3. New Network Service 

In the use case of privileged network drive access, an anomaly alert will be triggered when the account accesses a privileged drive such as \\SERVER\ADMIN$. This hidden drive exists in Windows servers and enables privileged users to access the \Windows\ folder of the server. The \SERVER\ADMIN$ drive is commonly utilized by tools like PSEXEC to upload binaries into the server. 

In the use case of creating a new service, an anomaly alert will be promptly generated when a new system service is created. A specific example of concern is the PSEXEC tool, which creates and launches PSEXESVC.EXE as a new system service after successfully uploading the binary. 

In the use case of a new network service, an anomaly alert will be triggered upon the detection of new network connectivity or services. Specifically, this includes instances where NETSH.EXE is utilized to establish a network proxy that listens on TCP port 9999. Moreover, the network proxy is configured to forward incoming data to TCP port 8443 at the IP address 192.168.100.100. 

The presence of the new network service listening on TCP port 9999, as well as the outgoing connection to 192.168.100.100 on TCP port 8443 can be identified by the network anomaly algorithm. 

Stage 3: Reconnaissance and defense evasion

In stage 3 of the attack, the attacker executed a sequence of natively available commands to gather additional information (Step 5). These commands provide various information, including network settings, account details, running processes, and more. Finally, they attempted to clear the security log in order to conceal their tracks (Step 6). 

To detect steps 5 and 6 effectively, the following use cases can be leveraged: 

1. Suspicious LOLBIN activity 
2. Security Log Cleared 

In the use case of suspicious LOLBin (Living-off-the-Land Binary) activity, an anomaly alert will be generated when a series of native commands are executed in a pattern that closely resembles the activities typically carried out by an attacker during reconnaissance and maintaining access. 

These are the specific LOLBin commands outlined in the advisory released by the NSA pertaining to the campaign:

In the use case of security log clearance, an anomaly alert will be triggered when the account attempts to clear the security event log. This deliberate action poses a significant concern as it obstructs forensic analysis and investigation, especially when the victim lacks access to the audit trail. 

This underscores the importance of forwarding the audit log to a secure and resilient log storage facility to preserve crucial evidence for future analysis. 

Auto triage of security alerts 

In the previous sections, we discussed the use cases for detecting stealthy attackers in a network. While one can try to use a SIEM (Security Information and Event Management) solution to implement some of these use cases, there are significant limitations to consider when using a SIEM solution for such use cases. 

For example, monitoring Event ID 1102 can help detect the clearing of security logs, while Event ID 5145 can identify privileged network drive access. However, enabling these alerts in a SIEM may overwhelm the security team with numerous alerts, including many that are benign or unrelated to malicious activity. 

To address this challenge, UEBA (User and Entity Behavior Analytics) will be an effective approach. UEBA continuously triages and compares activity against the historical behavioural of entities. The security team is only notified when behavioural changes linked to relevant use cases are detected, minimizing alert fatigue. 

By leveraging UEBA, security alerts are analyzed in the context of an entity’s overall behaviour, allowing for a more accurate and targeted detection of suspicious activities. This approach significantly reduces the number of false positives and focuses attention on the most relevant alerts, improving the efficiency and effectiveness of the security team’s response to potential threats.  

 

Summary and recommendations 

The attacker’s patient execution of the campaign, relying on the operating system’s limited tools and living-off-the-land (LOL) techniques, emphasizes the need for proactive security measures. To safeguard your organization against such threats, we recommend implementing the following measures: 

• Restrict direct internet access to the router’s management interface 
• Maintain credentials stored in the router at lower privilege levels 
• Implement comprehensive authentication and authorization measures for both intranet and internet-facing assets 
• Establish a secure and centralized location for forwarding and storing audit logs 
• Take a proactive approach by continuously monitoring audit logs for any abnormalities related to identity, network, and assets. Detecting anomalies early can help mitigate potential threats before they escalate 

How can InsiderSecurity help? 

InsiderSecurity’s Automated UEBA (User and Entity Behavior Analytics) powered by AI and advanced user behaviour analytics provides early detection of various security risks, including hijacked accounts, insider threats, and compromised servers. By leveraging our Automated UEBA, organizations can effectively detect all the above-mentioned attack pathways. 

Through continuous monitoring and analysis of user behaviour, InsiderSecurity identifies suspicious activities, anomalous patterns, and deviations from normal behaviour. This allows for the proactive identification of potential security incidents and timely response to mitigate risks. 

InsiderSecurity’s Automated UEBA goes beyond traditional rule-based approaches, utilizing advanced machine learning algorithms to detect complex and evolving attack techniques. By analyzing user behaviour, account activity, network traffic, and other relevant data sources, our solution provides enhanced visibility into potential threats and helps organizations stay one step ahead of adversaries. 

Elevate your security posture and protect your organization from sophisticated threats. Contact us now to schedule a consultation and discover how our advanced security solutions can help you stay ahead of evolving cyber risks. Don’t wait until it’s too late – act now to secure your future. 

Cloud Security is an evolving area in which many companies are still finding their footing. Navigating a cloud environment can be challenging for cybersecurity teams who are unfamiliar with how security changes in a cloud environment. Examples of this can be increased automation, a shared security responsibility model, faster change management, and so on.

Cybersecurity teams can learn which areas to focus on by upskilling their cloud knowledge via certifications, adopting cloud-native best practices, and by studying cloud data breaches within the industry. By analyzing these incidents and understanding what vulnerabilities led to these control failures, companies can ensure they are not exposed in a similar way.

Let us look at a few of the most notable cloud data breaches of recent years and what lessons we can learn from them.

Accenture

Accenture, a well-known name in the IT consulting industry, revealed that a popular ransomware group had compromised them in 2017. As a consequence of a cloud misconfiguration, Accenture inadvertently left four of its AWS S3 buckets to be publicly accessible. As a result, hundreds of gigabytes of sensitive client and company data were exposed. This data included more than 40,000 plaintext passwords, sensitive API data, decryption keys, authentication credentials, user data, and customer information. Hackers released some of this data on the dark web. 

In August of 2021, Accenture again fell prey to an attack via the LockBit ransomware.  Attackers exfiltrated over six terabytes of data and demanded that a $50 million ransom payout be made. The compromise also affected Accenture customers.  

Accenture admitted in its financial report that  
“In addition, our clients have experienced, and may in the future experience, breaches of systems and cloud-based services enabled by or provided by us.” 

A few of the key lessons that can be taken from this incident are:  

• Deploy cloud security tools to detect misconfigurations in the cloud environment. These misconfigurations are usually how attackers gain a foothold in an environment.  
• All major cloud providers like Microsoft Azure, Google, and AWS have guidance on how to protect against ransomware. These should be studied and adopted.  
• Insider threats are a genuine cause for concern. Employees with access can be targeted and potentially bribed by attackers with million dollar budgets. 
• Partners and customers of Accenture were compromised as part of this attack, and hence it is essential to assess the risk of third-party access in a cloud environment.  

Cognyte 

Cognyte, a cybersecurity analytics firm, faced industry scrutiny after a misconfiguration led to over 5 billion user records being exposed over the internet. Even worse was that this database contained data about previous security incidents as part of Cognyte’s intelligence service. A misconfiguration of this database led to it being exposed over the internet without any authentication in place. Thankfully this was discovered by a security firm and informed to them proactively. 

A few of the critical lessons that can be taken from this incident are:  

• Misconfigurations remain one of the biggest threats to cloud security. Without controls to detect and remediate such mistakes, a company can face a similar situation to Cognyte.  
• It is difficult to secure that on which you have no visibility. Make use of cloud security tools to identify all cloud resources and their security posture.  
• Passwords are simply not enough to secure a cloud environment. Implementing multi-factor authentication would have mitigated the impact of this exposure and is something all companies should implement.  

Kaseya

Kaseya, a popular IT management software provider based in the U.S., was compromised in July 2021 by a Russian Hacking group. The attack was similar to the supply chain compromise of SolarWinds in which a popular software is compromised and used as a jumping point to access more environments. While the company shut down its SaaS servers and notified customers, it was not enough to contain the blast radius of the attack as customers found themselves receiving ransomware instead of Kaseya’s regular software updates. The situation was severe enough for the FBI and cybersecurity firms like Mandiant to get involved.  

A few of the critical lessons that can be taken from this incident are:  

• Supply chain attacks can be highly devastating as many other parties are compromised along with the initial victim. Attackers are smart enough to realize that compromising the software supply chain can be easier and result in higher payoffs than attacking companies head-on.  
• Patching remains as essential as ever, as the Russian Group was able to compromise Kaseya by exploiting unpatched vulnerabilities.  

Raychat

Raychat, a famous Iranian chatting application, was compromised in February of 2021 due to a misconfigured database similar to Cognyte. Over 267 million personal details of its customers were accessed and then deleted by a bot. The misconfiguration meant that no advanced technical skills were needed, and the attacker could simply access the database and destroy it without any controls detecting or stopping the malicious activities.  

A few of the critical lessons that can be taken from this incident are:  

• The common theme of misconfigurations once again shows up in this case. If Raychat had implemented controls to detect and remediate this weakness in time, the entire data breach could have been avoided.  
• Continuous monitoring of a cloud environment is essential. An attacker accessing a cloud database should be detected due to its suspicious nature. However, the lack of such controls meant Raychat was not aware while the attack was taking place.  

Lessons learned

By analyzing these incidents, we can pick up some common themes in nearly all of these incidents. These are lessons to ensure that our cloud environments do not contain the same weaknesses:  

• Misconfigurations are a crucial risk, and it is essential to have controls in place that can detect and mitigate these weaknesses. 
• Visibility into cloud resources is critical, as cloud environments change rapidly.  
• Continuous monitoring of cloud resources is needed. Suspicious activities like logins from suspicious locations and data exfiltration should be detected. Cloud Security Monitor provides such automated, continous monitoring.  
• Multi-factor authentication is a best practice that should be implemented in both the cloud and on-premise. 
• Supply chain risk can be a blind spot in cloud environments. It is useful to do a risk assessment of the software supply chain and implement controls to protect against its compromise.