We've covered a lot of material involving attacking Lambda functions, but in this section, we will discuss pivoting from access to a Lambda function to access to the internal network of a virtual private cloud (VPC). This is made possible because Lambda functions can be launched into VPCs for a variety of reasons. This provides us attackers with Lambda access with the ability to interact with internal hosts and services that we may not otherwise be able to gain access to.

Again, we can approach this from two different angles. If we have the required privileges, we can launch a new Lambda function into a VPC of our choice, or we can modify the code of a Lambda function that has already been launched into a VPC. We're going to run through a demo wherein we will be editing a function that has already been launched into a VPC.

For this demo, if we look at the Network tab in the Lambda web UI, we can see that this function has been launched into the default VPC, it is in two subnets, and it is in the security group sg-0e9c3b71. We can also see that the security group allows inbound access to port 80 from some IP address, and it allows access to all ports from servers within the same security group:

We will then run an EC2 DescribeInstances API call to find out what other servers exist in this VPC. We can do this with the following AWS CLI command:

aws ec2 describe-instances

Or, we can use the "ec2__enum" Pacu module. The results show us that there is one EC2 instance, and it is in the same security group as our Lambda function:

Based on what we saw in this security group's inbound rules, we know that our Lambda function has access to every port on that EC2 instance. We also know that something is likely being hosted on port 80, because the same security group whitelists access to port 80 to a different IP address. As an attacker with a small amount of EC2 permissions, it would generally be difficult to gain access to the inside of a VPC, but Lambda lets us get around that. We just need to modify the code in the Lambda function to do what we want within the VPC's network.

We're going to ignore whatever code is in our target Lambda function and just focus on our payloads to access the internal network. We know that we want to contact port 80 on that internal host, which likely means there is an HTTP server running, so we can use the requests library again to make a request to it. We still don't want to disrupt any production code, so everything will be wrapped in a try/except block, like before. The EC2 DescribeInstances call from a minute ago gave us the internal IP address of the target EC2 instance, which is 172.31.32.192. Our payload will look something like this:

try:
    from botocore.vendored import requests
    req = requests.get('http://172.31.32.192/')
    print(req.text)
except:
    pass

To keep it simple, we'll just be printing the output to the console and viewing it there, but this is another situation where some sort of exfiltration may be necessary. Ensure that your Lambda function has internet access, though, as they lose default internet access when launched into a VPC and rely on the VPC to provide that access.

After running the payload to try to make an HTTP request to that internal IP, we are shown the following in the Lambda console:

Just like that, we can see that we gained access to the internal network to bypass network restrictions and accessed some sort of internal human resources portal for the company we are targeting. At the bottom, we can even see a table with some private employee information, such as their salary.

It's that easy to gain access to the internal side of a network in AWS. This method can be used for a variety of different attacks, such as accessing an RDS database that is not publicly accessible, because we can just launch a Lambda function into the VPC/subnet that it resides in and make a connection to it. All kinds of AWS services have the option to launch a resource into a private VPC to disable public access to it, and this method of getting into the internal side of a VPC allows us to access all these different services; a few other examples include ElastiCache databases, EKS clusters, and more.