“Let’s say someone is using those providers and they happen to have a common identity platform, maybe SailPoint. If SailPoint is passing a data stream to AWS and Microsoft and maybe others, it could permit access to all that client’s information in one of those hyperscaler environments. It might allow limited data access in the cloud. Now let’s say somehow an attacker is targeting that AWS API. If that client was using the same credentials across those cloud platforms,” it could provide extensive access, he says.

IMDSv2: What you don’t know could kill your cloud 

In March 2024, Amazon quietly rolled out an update to a critical piece of the AWS platform: the Instance Metadata Service (IMDS). Some SOCs “might not even realize that they are using [IMDS]” and therefore they are exposing their operation to a serious “security threat related to metadata exposure,” says Pluralsight’s Firment.

“AWS uses IMDS to store security credentials used by other applications and services, and makes that information available using a REST API. Attackers can use a Server-Side Request Forgery [SSRF] to steal credentials from IMDS, which allows them to authenticate as the instance role for lateral movement or data theft,” Firment explains. “AWS introduced a newer version of IMDS, version 2, to improve the security of unauthorized metadata, although many organizations are still using the original IMDSv1 as the default. To help CISOs close this potential security hole, AWS recently announced the ability to set all newly launched Amazon EC2 instances to the more secure IMDSv2 by default.”

IMDSv2 “was launched by AWS in November 2019 but the ability to set the default to the new version was not introduced until March 2024. As a result, many organizations continued to use the original vulnerable IMDSv1. Interesting to note that the default only applies to new instances launched, so existing instances with IMDSv1 still need to be reconfigured,” Firment says.