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 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 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?