Cybersecurity experts have been quick to respond to the details of the LastPass breach in recent months. Opinion pieces have been published both addressing the critical remediation steps for customers and doling out deserved criticism of incident communication. Absent from the public discourse has been a discussion of the indicators that can be gleamed from the various LastPass communications. In this blog I look to outline the intel in the LastPass communiques and enumerate the attacker indicators while framing the discussion around the Pyramid of Pain.
This piece is intended to follow closely the advice given by author of the Pyramid of Pain, David Bianco’s “Whenever you receive new intel on an adversary (whether it be APT1/Comment Crew or any other threat actor), review it carefully against the Pyramid of Pain. For every paragraph, ask yourself ‘Is there anything here I can use to detect the adversary's activity, and where does this fall on the pyramid?’”
The Pyramid of Pain for Cloud Indicators
The Pyramid of Pain is a conceptual model for classifying the effectiveness of detective controls. First described by David Bianco in 2013, the ‘Pain’ refers to the pain a detective control will inflict on the adversary. The further you move up the pyramid, the more pain an attacker will feel adapting and necessarily evading the defender’s detective capabilities. The pyramid of pain recognizes that not all indicators of compromise (and therefore detective capabilities) are created equal. Some indicators are trivial for an attacker to modify and evade while other behaviors are core to their stated goal and cannot be altered so easily.
At the bottom of the pyramid are simple indicators such as IP addresses and hash values. This includes cloud detections based on source IP address or attack tool signature. Defenders might find some creature comfort in deploying detections targeting indicators low on the pyramid of pain, however they should be aware of the simplicity of evasion.
Crowning the top of the Pyramid of Pain are indicators which are fundamental to how an attacker goes about achieving their goals. These are the tactics, techniques, and procedures (TTPs) which are either tough or impossible for the threat actor to modify. Imagine a detection suite which fingerprints the API calls involved in the transfer of data out of a trusted cloud environment. This indicator would be impossible for an attacker to modify unless they were able to leverage unknown and undocumented mechanisms from the cloud provider to transfer data.
Sandwiched in the middle are indicators which an adversary could modify or avoid exhibiting with some difficulty. When analyzing the cloud, this tier includes event patterns indicating initial compromise. Discovery and enumeration of a cloud environment is most simply performed by directly querying cloud APIs and leaving a trail of indicators on the cloud control-plane. However, these indicators can be avoided and instead the same information can be gleaned through open-source intelligence or harvesting information from internal documentation.
LastPass Communications Intel
Let’s tease out the pieces of intel from the public LastPass communications — paying particular attention to the attacker indicators as they targeted cloud hosted data. While there are numerous interesting tidbits in these communications regarding LastPass protective and defensive posture, this post is focused on bringing to light the possible behaviors the attacker exhibited.
1st incident: Resulted in stolen source repositories, and technical documentation.
"The threat actor used third-party VPN services to obfuscate the origin of their activity when accessing the cloud-based development environment and used its access to impersonate the software engineer. Using this approach, they were able to “tailgate” into the on-demand development environment via our corporate VPN, as well as a dedicated connection to the cloud-based development environment. They did so by relying upon the software engineer’s successful authentication with domain credentials and MFA. No privilege escalation was identified or required.”
- This indicates the cloud-based development environment had hybrid connectivity and was available to domain authenticated users within the corporate IP space.
- Any detective controls geared towards unusual or known-bad IP addresses would have likely missed the threat actor using the corporate VPN when originating from the software engineer’s endpoint, however if the connection was not established outside of the workstation, controls could have been in place to prevent or detect an unusual VPN connection.
2nd incident: Resulted in the theft of customer vault backups containing encrypted and unencrypted data, one-time password seeds, and API secrets used in third-party integrations.
“Due to the security controls protecting and securing the on-premises data center installations of LastPass production, the threat actor targeted one of the four DevOps engineers who had access to the decryption keys needed to access the cloud storage service.”
- The report authors seem to indicate the threat actor chose to target data stored in the cloud as opposed to the on-premises data because of less robust security controls.
“Specifically, the threat actor was able to leverage valid credentials stolen from a senior DevOps engineer to access a shared cloud-storage environment, which initially made it difficult for investigators to differentiate between threat actor activity and ongoing legitimate activity.”
“To access the cloud-based storage resources – notably S3 bucket…..The encrypted cloud-based storage services house backups of LastPass customer and encrypted vault data.”
- Putting these sentences together, we can deduce that AWS S3 objects were accessed by the attacker using valid, stolen credentials.
“To access the cloud-based storage resources – notably S3 buckets which are protected with either AWS S3-SSE encryption, AWS S3-KMS encryption, or AWS S3-SSE-C encryption – the threat actor needed to obtain AWS Access Keys and the LastPass-generated decryption keys.”
- If an AWS Access Key was needed to access cloud-based storage resources and that access was ultimately successful, we can conclude that an IAM User was compromised and leveraged to access the objects stored in S3 as they are the only IAM Principal which can be assigned Access Keys.
- Given the data accessed was cloud – backups, we might presume the compromised identity was intended to be leveraged during disaster recovery scenarios.
“…..the threat actor exploited a vulnerability in third-party software, bypassed existing controls, and eventually accessed non-production development and backup storage environments.4”
- LastPass confirms the threat actor accessed backup data reported in previous communications as being stored in AWS S3. We can use this information to discuss possible indicators of compromise an attacker might leave behind.
LastPass Breach: Cloud Detection & Response Opportunities
Given what we know about the value of different indicators, how can we map the possible indicators of the LastPass breach onto the Pyramid of Pain?
Relatively ‘Painless’ Indicators
These indicators are easy for an adversary to avoid, tend to result in high confidence true positive detections, but are not likely to receive timely action from a security operations team as they tend not to illustrate impact to cloud resources.
- Cloud API Access from uncommon locations resulting in the detection of improbable travel.
→ It is unlikely that the first incident would have been detected if looking for this indicator but it’s possible the second incident may have produced some signals.
Mid-Pyramid Indicators
An adversary would be able to avoid using these indicators with some difficulty but still aren't likely to receive timely action from a security operations team as they tend not to illustrate impact to cloud resources.
- Reconnaissance activity
→ Upon gaining access to valid credentials, the attacker may have leveraged the cloud APIs to both enumerate their permissions and/or list and describe the S3 objects. However, a large volume of technical documentation was stolen during the first incident. It is quite possible all required information was included in this documentation, and the attacker did not need to perform any further reconnaissance activity on the cloud.
Top Pyramid Indicators
The threat actor would not be able to avoid leaving these indicators and still achieve their goals such as data exfiltration. Modifying these indicators to avoid detection would necessitate leveraging an unknown API or technique. Detections built around these indicators are likely to garner swift attention from a security operations team.
- Movement of S3 Objects to Suspicious Destination
→ Data was moved from authorized cloud-hosted data repositories to attacker-controlled locations. This transfer is an opportunity to craft detections around the movement of data to unknown, untrusted, or external locations.
- Accessing of Large Volume of S3 Objects
→ We can assume from the LastPass communications, large volumes of data were transferred leveraging the speed and scale of the AWS Cloud APIs. Accessing a large volume of data is an indicator which lives at the top of the Pyramid of Pain and is a signal to detect suspicious data retrieval.
There are several indicators of compromise which can be gleamed from the LastPass breach and mapped to all levels of the Pyramid of Pain. Though there is value in providing detection coverage at all levels, it is important to recognize that your mileage may vary. The detection of cloud access from an unknown or untrusted source IP addresses will be trivial for an attacker to avoid, while detecting the TTPs of suspicious data movement and data access is likely to be a tried-and-true detection methodology.