DEV Community: Adan Alvarez

Gaining Long-Term AWS Access with CodeBuild and GitHub

Adan Alvarez — Sun, 13 Apr 2025 11:35:08 +0000

As I wrote in other blogs, such as Gaining AWS Persistence by Updating a SAML Identity Provider, when an attacker compromises an AWS account, one of the first tactics they will attempt is to gain persistence. This is because access obtained through temporary credentials may expire quickly, or the attacker may want to ensure continued access even if their initial foothold is discovered and removed.

That’s why I’m interested in exploring how legitimate AWS services can be abused for persistence. While creating IAM users and assigning them admin privileges is still a common and effective tactic (as we continue to observe in data from TrailDiscover), it’s noisy and easier to detect.

In this article, I’ll explore how an attacker could use/abuse AWS CodeBuild for persistence. I haven’t seen this particular approach documented in other research, but let me know if it’s been covered elsewhere.

⚠️ Disclaimer: This is NOT an AWS vulnerability. The technique described assumes the attacker has already compromised the account and has sufficient permissions. The goal is to expose how CodeBuild can be used to establish long-term access.

What is AWS CodeBuild?

CodeBuild is a fully managed continuous integration service that compiles source code, runs tests, and produces software packages for deployment. It supports custom build environments and integrates with popular tools such as GitHub.

In mid-2024, AWS introduced support for running self-hosted GitHub Actions runners using CodeBuild. This functionality allows you to configure a CodeBuild project to act as a runner for GitHub Actions.

This GitHub Actions integration is the option we are going to explore to see how an attacker can abuse it to gain persistence.

How an Attacker Could Abuse CodeBuild

The technique is surprisingly straightforward.

Because CodeBuild now supports self-hosted GitHub Actions runners, an attacker can:

Configure a CodeBuild project to serve as a GitHub Actions runner.
Link that project to a GitHub repository controlled by the attacker.
Modify an IAM role to allow CodeBuild to assume it. Then this role will provide access to the AWS environment.

Let’s see these steps in more detail.

Step 1: Backdoor a Role

The attacker first needs to choose an IAM role to abuse. Ideally, this is an existing role with broad/admin privileges. In most cases, backdooring an existing role is often stealthier than creating a new one.

To “backdoor” the role, the attacker modifies its trust policy to allow the CodeBuild service to assume it:

{
  "Effect": "Allow",
  "Principal": {
    "Service": "codebuild.amazonaws.com"
  },
  "Action": "sts:AssumeRole"
}

This change allows CodeBuild builds to assume the role and inherit its permissions.

Note: Backdooring IAM roles for persistence is a well-known technique. It has been documented in research and observed in real-world incidents.

Step 2: Create a CodeBuild Project and Connect it to GitHub

Once the attacker has selected and backdoored an IAM role, the next step is to go into AWS CodeBuild and create a new build project linked to a GitHub repository they control.

While CodeBuild projects can be created via API or CLI, connecting a GitHub repository often requires going through the AWS Console. Fortunately for the attacker, it’s relatively easy to move from IAM credentials to a web console session, as described here: Create a Console Session from IAM Credentials

Selecting a Project name and type
The first step when creating a project will be to select the name and the type. In this case, the type will be a “Runner project”

Connecting to GitHub
To link a GitHub repository to the build project, AWS provides three options:

GitHub App
OAuth App
Personal Access Token (PAT)

To minimize noise and complexity, the attacker can choose the simplest route: using a GitHub Personal Access Token (PAT). This PAT would grant access to a repository that the attacker controls (it can even be private).

Once the GitHub connection is established, the attacker can select the Repository

Using the Backdoored Role

In the project settings, under the “Environment” section, the attacker can choose to use an existing service role; this is where they select the backdoored IAM role from Step 1.

There is also a checkbox: “Allow AWS CodeBuild to modify this service role so it can be used with this build project.”

If this box is checked, CodeBuild will automatically add extra permissions to the role (for things like writing logs to CloudWatch or interacting with CodeBuild resources). If the role already has admin-level permissions, the attacker won’t need to enable this.

Note: The attacker will likely disable CloudWatch Logs to reduce visibility of their build runs.

Step 3: Set Up the GitHub Action

At this point, the attacker has:

Created a CodeBuild project
Linked it to a GitHub repository they control
Configured it to assume a backdoored IAM role

The final step is to create a GitHub Action workflow that executes commands in the AWS environment using the assumed role.

The workflow can be extremely simple. Here’s an example that will run on every push and call the sts:GetCallerIdentity API:

name: Backdoor AWS Access
on: [push]
jobs:
  persistence-access:
    runs-on:
      - codebuild-MyGitHubRunner-${{ github.run_id }}-${{ github.run_attempt }}
    steps:
      - name: Verify AWS Access
        run: |
          aws sts get-caller-identity

Here’s an example of the execution of this action:

This confirms that the workflow is successfully running in the AWS environment with permission from the backdoored role. From here, the attacker can execute any AWS commands their role allows.

With these three simple steps, the attacker now has persistent access to the AWS environment. Even if their initial credentials are revoked or the original attack path is closed.

Defending Against CodeBuild-Based Persistence

Let’s walk through what defenders can observe (and what they can’t):

CloudTrail Logs
During the setup phase, several key events will appear in CloudTrail, such as:

UpdateAssumeRolePolicy: This event happens when the role is backdoored. We’ll see in the parameters the policyDocument containing codebuild.amazonaws.com
ImportSourceCredentials: This event happens when the connection with GitHub is established, but it will depend on the configuration. In the case of a PAT in codebuild we’ll see a requesParameters that will look like:

CreateProject: This event happens when the project is created.
CreateWebhook: This event happens when the project is created and is meant to create the webhook that will trigger the build from GitHub.
ProcessWebhook: This event happens when CodeBuild processes an event from GitHub

IAM Role Abuse Visibility
Once the GitHub Action runs, all actions will be performed under the backdoored IAM role.

AssumeRole will happen every time the CodeBuild assumes the backdoored role.
Source IP will appear as AWS infrastructure, or even an IP from your own VPC if the attacker configures CodeBuild to run in VPC mode.
PrincipalID and arn will contain AWSCodeBuild

Access Analyzer Blind Spot

One crucial point: AWS Access Analyzer does not detect the GitHub connection as external access.

This is a major blind spot. Many security teams rely on Access Analyzer to detect unexpected trust relationships, but in this case, no alerts are triggered, even though the GitHub repo is controlling a role externally.

I confirmed this with the AWS security team, and “it is expected behavior”. But it certainly complicates detection.

Conclusion

This is just another example of how attackers can abuse legitimate AWS services for persistence. With over 200 AWS services available, attackers with highly privileged access have plenty of options to carry out their attacks. As defenders, we should be prepared for the day an attacker gains access to our environment, because a compromised account shouldn’t be game over.

For this reason, it is essential to understand diverse abuse paths, monitor CloudTrail logs, audit IAM trust relationships, and stay aware of service limitations (like the one described here with Access Analyzer). These are key actions that will allow us to detect and stop an attack before it’s too late.

DIY — Building a Cost-Effective Questionnaire Automation with Bedrock

Adan Alvarez — Sun, 23 Mar 2025 12:56:34 +0000

Security questionnaires are very common today. When customers consider your product, especially if you’re a startup, they often ask for proof that using your service is safe. This can become a huge time-sink: you may spend hours answering questions that don’t always apply to you.

I won’t cover other strategies, like having a dedicated security page, getting a SOC 2 report, or using a standard security questionnaire. For that, I recommend reading Rami McCarthy’s post.

Instead, this post focuses on how to quickly answer security questionnaires using Amazon Bedrock, Aurora PostgreSQL with pgvector, AWS Lambda, and Amazon S3. With these services, you can create a serverless knowledge base that stores your security documentation and old questionnaire answers. You can query it to generate relevant answers with minimal cost (you only pay when you actually use it).

Searching for a solution

When I started looking for ways to build a security knowledge base in AWS, somewhere I could keep all my security documentation in one place and let others query it easily, I noticed most blogs recommended using Bedrock with Amazon OpenSearch Service’s vector database. However, many of them ended with a warning: “After testing, you should delete your OpenSearch domain, or else you’ll end up with a big bill.” Indeed, OpenSearch can become quite expensive.

I discovered Aurora PostgreSQL as another option for storing documents. After testing, Aurora’s cost was lower than OpenSearch, but it was still around $1 per day, so over $30/month. For something used only occasionally (like security questionnaires), I wanted an almost cost-free solution when not used.

Then I found that if I upgraded Aurora PostgreSQL to version 8.5, I could configure the minimum capacity to 0. This makes the cost $0 when not in use. If you try to use the recommended quick create way, you’ll end up with a PostgreSQL that does not scale to 0, so I built Terraform code to create the infrastructure for me.

Additionally, because my main goal was to handle security questionnaires, I wrote two Lambda functions:

Sync Function: Whenever I upload new security documents to an S3 bucket, it ingests them into my Aurora-based knowledge base.
Q&A Function: I can upload a text file of questions to another S3 bucket; the Lambda queries the knowledge base via Bedrock and then saves the answers as a CSV in that same bucket.

In my setup, I’ve been using Anthropic Claude to generate the responses. However, the Terraform variables in my repository allow you to customize which model ARN you want to use. Of course, these answers need a review, but having a first pass speeds things up. The more questionnaires you fill out and upload to your knowledge base, the better your system becomes over time.

How the Infrastructure Works

Aurora PostgreSQL v8.5

Stores your documentation and security policies in a table that supports vector similarity search (pgvector).
Uses a min capacity of 0, so you pay nothing when it’s idle.

Amazon Bedrock

Handles both retrieving the right documents and generating text (a Retrieval-Augmented Generation approach).
Links to your Aurora database via a “knowledge base” configuration.
In the Terraform code, you can specify which LLM model ARN to use (Anthropic Claude, Amazon Titan, etc.).

AWS Lambda and S3

Data Ingestion: One Lambda function watches for new files in an S3 bucket and loads them into Aurora.
Q&A: Another Lambda function reads a file of questions from a different S3 bucket, calls Bedrock for answers, and saves the results as a CSV.

Try It Out

The complete Terraform code is here: adanalvarez/bedrock-secure-questionnaire-automation

In that repo, you’ll find all the terraform modules to set up Aurora Serverless, S3 buckets, Lambda functions, and the Bedrock knowledge base.

Wrap-Up

When security questionnaires can’t be avoided, automation with an LLM can save time. By storing key documents and previous answers in a secure, queryable knowledge base, you can quickly generate responses and cut down on repetitive work. This approach helps you keep costs near zero when you’re not actively using it, which is ideal for a task that hopefully doesn’t happen every day!