There’s a new attack targeting AWS accounts and it involves AI

AWS attack involving AI

Commonly when a threat actor gains access to AWS credentials (often long-term access keys), they will do a few things depending on their objectives…like for example, they’ll:

  • Try to access Amazon SES (Simple Email Service) to try and send spam and phishing campaigns from the organization’s email domains
  • Try to access EC2 to launch crypto mining instances
  • Try to perform privilege escalation or establish persistence through IAM (which we’ve been covering a lot at Cybr)

Commonly also we see them trying to access Amazon S3 and set up backdoors to either find sensitive data like proprietary information all the way to PII or other sensitive customer data, and/or or to ransom the data, and/or to host malware.

Now, however, we’re seeing something brand new that’s having a pretty big impact.

Attackers are trying to access services like Bedrock.

PS: Prefer watching videos over reading? Watch here:

If you’re not already familiar, Amazon Bedrock is their service for interacting with foundational LLMs, like Anthropic’s Claude, Meta’s Llama, and a few others…

Attackers are doing this because they can hijack LLM infrastructure to power their AI chatbot services, including roleplaying services. And you can probably guess where this is going.

By the way, this report is coming straight from a security research firm called Permiso.io. They set up a honeypot environment and they were able to see exactly what attackers did and how they did it. Check out their original article and the report by KrebsonSecurity for more info and full details.

Technical breakdown

OK so here’s what happened and how it happened:

First, the AWS account has to get compromised. While there are quite a few ways that this can happen, a lot of times it’s because people are still using access keys, and they’re leaking those access keys or they’re falling victim to social engineering attacks.

Second, once the account is compromised, the threat actor will perform basic enumeration to figure out what their access looks like through that access key. And a lot of times, this will be automated.

Through enumeration, if they detect access to Bedrock, they typically do a few things:

  1. Check for model availability
  2. They’ll request access to models
  3. Invoke the models via prompting

The most common ways to check for model availability is with:

If a model is not available, the attacker can request access through an application process, which can be done via the AWS Console or programmatically.

Once the attacker has access, they then invoke the prompt models, and while Permiso observed multiple models being used, the one most often used has been Anthropic’s Claude 3 Sonnet.

Why are they doing this?

But why are they doing this?

Attackers are doing this so that they can host AI roleplaying services. They use common jailbreaking techniques to get the models to accept and respond with content that would normally be blocked by the model, because most of the roleplaying is explicit in nature, including really messed up forms of explicit material that I’m not going to mention because I don’t want YouTube to ban me.

I also won’t show you some of the messages for the same reason, but you can check out the original research for screenshots. Even some of those are blurred out, which can give you an idea of how messed up it is.

Users can then chat with these bots on websites hosting them to do all kinds of roleplaying. Fortune even wrote an article about this if you’d like to learn more.

So instead of having to pay out of pocket to run these explicit roleplaying markets, attackers scan the web for leaked access keys to cloud accounts, and then use services like Bedrock to run their business for free…passing on the bill to the compromised account.

So not only are your accounts and resources being used in this, but you could end up with thousands of dollars in bills.

How to defend against this

This is something we are likely to see a lot more of, even if for other types of use cases, but there are things we can do to prevent it:

  1. It starts with preventing compromised credentials. Stop using access keys and other long-term credentials for your AWS environments — there are better alternatives including using roles and identity federation with multi-factor authentication through Identity Center and/or through external identity providers
  2. Keep working towards least privilege — because even if access keys get leaked, you should make it very difficult for an attacker to be able to access other services or actions, but a lot of times we still see admin-level permissions
  3. Lock down unused services – so if you’re not using Bedrock, then you can prevent access to the service using a Service Control Policy, or SCP. Even if you are using it, chances are you’re only using it in specific accounts anyway
  4. Implement threat detection – there are different solutions for this but we can plug in Atomic Indicators and TTPs
  5. Implement better security against LLM jailbreaking — though in this case there’s not much you could do and it’s more on Anthropic’s end

Conclusion

But that’s it for now! This is something you should know about and be on the lookout for so I wanted to inform you.

If you want more tips and tricks on how to secure your AWS environments and avoid making the news for the wrong reasons, then sign up for our training and subscribe to our YouTube channel for more content like this!

Thanks for reading, and see you next time.

Related Articles

Responses

Your email address will not be published. Required fields are marked *