AWS access keys leak via public code repository is a quite known security problem. So common, that popular version control systems offer for free a dedicated service, which looks for hardcoded secrets. Specifically, I refer here to GitHub secret scanning service.

Without a doubt, it’s awesome that such a service was released, however, in this blog post I want to answer the following questions:

• how quickly attackers will detect the key leak?
• how many unique attempts to use the disclosed keys will occur?
• and finally… will Amazon automatically disable my leaked keys?

The experiment

I’ve created an IAM user with programmatic access named github_deployer and attached to it a very limited…

TL;DR

• Most of vulnerabilities existing in traditional applications can also appear in serverless applications. The most common ones are described in OWASP Serverless Top 10.
• There are also threats which are specific to serverless, like event injection or overwriting the code stored in S3 bucket.
• It’s quite common, that Lambda’s execution role has more permissions than it’s required.
• The malicious code can be also smuggled to your serverless application via used dependencies.

What is AWS Lambda?

FaaS (Function as a Service) model allows to build applications and services without the need to manage physical or virtual servers. It is the provider who is responsible for the security of networks, servers, operating systems, their configuration, and update. On the other hand, the developer’s responsibility is to keep the code, logic and application configuration secure. …

Recently I’ve passed the “AWS Certified Security — Speciality” exam, so I think that’s the best proof that my preparation process was good enough.

In this post I want to share my path to pass the “AWS Certified Security — Speciality” exam, including sharing all my notes which I made during the preparation. The scope of the exam is quite general and sometimes you don’t know how deep you should go into some topic. Well, at least it was a dilemma for me regarding the services, which I don’t use on my daily basis. …

In this blog post I’m going to show you several ways in which sensitive data from an isolated AWS EC2 instance can be exfiltrated by an attacker who compromised access keys, or by an excessively “curious” teammate😉 Among the attack vectors you’ll find out how to explore the instance’s content via snapshots or AMIs, and get a shell via User Data or SSM service. Last but not least, you will learn how to silently exfiltrate data outside your VPC via DNS traffic or other AWS services using VPC endpoints. …

This is the final part of the “Playing with CloudGoat” series. In this post I’m going to introduce you the AWS exploitation framework — Pacu. Through parts 1, 2, 3 and 4 I was hacking CloudGoat using AWS CLI and some external tools. Today I’ll go through some of the CloudGoat scenarios, but this time using Pacu. I’ll show you how hacking AWS services can be done quicker and easier.

Few words about the Pacu

In the Pacu repository you can find the following description of the framework:

“Pacu is an open source AWS exploitation framework, designed for offensive security testing against cloud environments. Created and maintained by Rhino Security Labs, Pacu allows penetration testers to exploit configuration flaws within an AWS account, using modules to easily expand its functionality. Current modules enable a range of attacks, including user privilege escalation, backdooring of IAM users, attacking vulnerable Lambda functions, and much more.” …

It is true that migrating your business to the cloud indeed mitigates a lot of risks while comparing to a monolithic architecture. Thanks to the shared responsibility model, you don’t have to worry about patching your OS or a physical security of a hosting server, because it’s handled by the cloud service provider. However, you have to remember that when you decide to use cloud services, it is your responsibility to take care of the security IN the cloud, which means you’re responsible for who and how can access your cloud services and data.

Configuring your cloud in a secure way isn’t a trivial task. Recent data breaches like exposing personal data of FedEx customers or compromising Tesla cloud resources for mining cryptocurrencies are perfect examples of little misconfigurations that can make your nights sleepless. There are more and more such stories including both little startups as well as big companies. According to a Gartner…

Today, it’s time to go through the last attractions prepared by guys from Rhino Security Labs: AWS Glue, CodeBuild, S3 as well as unused groups and roles. But, no worries — that won’t be the last episode 😉 If you don’t know what the CloudGoat is I recommend you to go through whole series starting from part 1.

The starting point of today post is the scenario when an attacker gets the SSH access to a Glue Development Endpoint. I’ve modified a little bit the default configuration of CloudGoat to be able to sequence the presented attacks. …

In this blog post, I’ll go through a scenario when an attacker finds Joe’s and Bob’s access keys but the EC2 instance is terminated. If you’re new to this series and you haven’t faintest idea what is CloudGoat and who the hell is Joe and Bob, then I recommend you to read the first part of the series.

Having access keys, the first step an attacker would do is verifying what the owner is allowed to do. Unfortunately, Joe is missing iam:ListAttachedUserPolicies and iam:GetUserPolicy permissions but fortunately we can use Bob’s permissions.

Oooh so Joe’s permissions are regulated by the AWS managed policy named DatabaseAdministrator. Being able to create a Lambda function would open a new door in this scenario by giving me new possibilities, but firstly I have to know what role should be assigned to it (without a role a new Lambda wouldn’t be able to perform any action — makes sense, doesn’t it?). Let’s see then what roles are available to assign, using the following…