Penetration Testing Lab 15 by Pentestit — walkthrough

On March 15, 2021, we launched our fifteenth Test lab, codenamed Who is the n0v1ch0k?

On the 12th day, in non-stop mode, the BadBlackHat participant was the first to compromise all the nodes of the laboratory. For everyone else who tried, is trying and will try to pro-test Test lab 15, we decided to publish its walkthrough.

Test lab emulate an IT infrastructure of real companies and are created for a legal pen testing and improving penetration testing skills. Laboratories are always unique and contain the most recent and known vulnerabilities.

So, it’s time to disassemble all the tasks of Test lab 15 in order to enable those who fail to dive deeper into the world of information security and learn something new for themselves. The content turned out to be quite voluminous, but, we hope, interesting.

The article is for informational purposes only. Do not break the law.

Laboratory connection

To connect to the laboratory, we use the login/password obtained in the personal account. There is also an instruction for setting up an OpenVPN connection for Linux and Windows platforms. At the time of this writing, March 26, over 500 unique VPN connections have been established. At the same time, only 124 participants were able to take at least one token.

After connecting, the gateways and become available, behind which the other nodes of the laboratory are located. We scan host for open ports and find only open port 80:


Through, it is possible to interact only with a web application in the form of a site, but it is not clear what to do with it, since we do not have authorization credentials, and the automatic scanning tools did not give the expected results.

The web application is protected with the Nemesida WAF, which can be evaluated on the example of this site. If you cause an error 404 or 50x, then a custom page will appear, where the e-mail is indicated, which we write to ourselves.

Also on the website page there is an e-mail address info@test.lab. We save this data. Having decided not to waste time brute-force passwords for these users, let’s move on.


We scan host and find open ports 143 and 8100. These are IMAP and HTTP services, where there is a form of authentication for users.


Using the Hydra tool, we begin to brute force passwords for previously found users info@test.lab and support-web@test.lab, but we can only find it for the last account.


We log in through the web form and get into the mail. We find the token, JAR file and configuration file for the VPN, we save everything to ourselves.

We connect with the new VPN configuration and in the connection log we see the addition of new routes on the subnets:

When scanning the subnet, we find only one available host with port 80 open.


We also scan other networks:


Notice the available hosts and



We go to the address and see the standard page of the site, in the code of which we could not find anything interesting. Searching directories with Dirb has been unsuccessful. Since the tasks themselves involve searching for tokens, let’s try to use the word “token” in the request. As a result, the file containing the token is downloaded.


On the host, port 53 is open, which is used by the Bind service, that is, it is a DNS server. Using the site’s domain name, let’s compose a command for AXFR:


where the output contains the IP addresses of other servers on the network and we take the token.


Since we know that is a domain controller, let’s start enum4linux and try to get some information about the domain:


The data of one of the users contains a token.


Now let’s deal with the JAR file that we found in the mail. Open the JAR file as an archive and open Main.class in the IDE:

In the code, we see the data for connecting to SSH to the server, but the password specified in the code does not match.

Modifying the code:

Save the file and compile. By running it again, we will receive the correct data for connecting to the server via SSH:



On server, in the /opt/token directory, we find a token, and in the scripts folder – a script that should create a archive on the same server.

Using htop, we track the execution time of the script, check the contents of the directory and take the archive, which contains another configuration file for the VPN. Having connected with the new configuration, we get access to the servers that were previously closed for us.


Let’s scan the network

We find machines – These are likely the custom machines we found earlier. SSH port 22 is open, so we will brute-force the password using Hydra:


We get passwords from users stepanova and ivanov. We log in with these credentials on each machine and look for some interesting information. On the server, in the home directory of the ivanov user, we find the container file from KeePass.

They are usually password protected, but the standard account password is not suitable. Having examined the server, we also find the installed Mozilla Firefox browser. Users often use the same passwords for different services. Let’s try to find the password there.

The password file is stored in the user’s home directory:

The name of the file containing the passwords can be found by filtering out the path parameter from the profiles.ini file:

You can get the data using the python script FIREFOX_DECRYPT, clone the project from GitHub:

When launched, the script will ask for a master password, but by default it is empty. The result of the script will be saved passwords.

We display the data:

We enter the received password into the container file and unlock it, having received a token in one of its fields.


In the directory of the user leonov on server, we find a dehcip file that can be run, but it will issue an incorrect token and private key.

It is necessary to reverse engineer the file to restore the algorithm of its operation.

First, we dump the file using objdump:

We open the resulting file dechip.txt, we see the following there:

Remove the unnecessary from Dechip.txt and leave the readable C code so that the algorithm is more clearly visible. We get the following:

From the analysis of the code, we can conclude that we used our own implementation of sorting the “bubble” of an array of structures of 15 elements of the type {key, value}. After that, the bitwise exclusive “or” (xor) operation was applied to some array. Based on the received data, we will correct the binary file.

Analyzing the implementation of the bubble sorting algorithm, we find an error:

That is, the loop does not reach the end of the array. Create a helper program (in our case, call it blanker.c) and save it to a file:

Compile the source:

And also create and compile the file with the corrected version of the sorting:

Create a dump of both received executable files:

It turns out that in order to correct the wrong cycle, you need to correct the mov command, remove the sub command (for example, overlap with the nop command), the cmp command, and the jb conditional branch.

We look at the similar code in the dechip program:

This hex code must be converted to the following form:

To do this, open the dechip source file in a hex editor and look for the start sequence 48 83 45 e8 08 in it:

We fix:

We save the changes to the file and run. The result of the work will be the output of the correct token and private key.


By analogy with the vpn-2 task, go to and download the file with the token.


Servers, and can only be accessed from certain machines. Through trial and error, we find out that they can only be accessed through user machines – Forwarding the tunnel using sshuttle:

Log in to the system with the ivanov user account with a password for KeePass and a news feed opens.

We check the web application for SQL injection, but we don’t get any visible response to payloads. Then let’s try to exploit Blind SQL injection.

Checking simple conditionals:

Conditional statements are executed and there is a delay of 10 seconds. This means that we can talk about the presence of a vulnerability. Now all that remains is to find the correct payload to search for the token in the database.

Unfortunately, it will either not work to automate the injection operation process, or it will be very problematic. with each request, the name of the fields for user input changes.

The final payload for checking the presence of this or that symbol will look like this:


By changing the position of the checked character and letter, we can check all the options and compose a token.

On server, we find another web application.

We look at which cookies are transmitted in requests. There is PHPSESSID and logged — for now, just remember this information.

We check the search string for the use of template engines, based on the method of their definition:

Having entered at the last stage {{7 * '7'}} and having received the result 49, we conclude that Jinga2 or Twig is used. We read the documentation for the Twig template engine and enter the command in the search bar to get the current user id:


We get the user id, but so far it does not give anything. Based on the tickets, we find out that the salt is used for logins in the system. Search index.php for the word “salt” with the command:


In addition to salt, double MD5 hashing is applied to logins. Search for msalt in index.php. There is no line and the variable may be defined in another file.

We search with the commands:



The result is negative. Let’s try to sequentially search for included files:


The last command gives a result, which means the file is present. We search for $msalt in the config.php file:


Glue the resulting TL2020 salt with the bug.admin administrator login and apply MD5 hashing twice:

We substitute the resulting result in the cookie in the logged parameter and update the page. We see that we are logged in as an administrator, and the token is in the name.


We go to the site under the user stepanova and go to the page with records and fields for filtering them. Not finding any vulnerabilities on the page, we look at the source code and notice the scripts to be connected:

After examining each of them, we stop at /inc/script.js, where at the very end there is a self-written script that generates an AJAX request and the page /load_news.php is specified:

Going to the page, we find that there are several records on it:

Using the search parameter, compose a query for SQLmap:


Dump the contents of the tables:


And we get the token.


On the host, UDP port 161 is open, intended for the SNMP protocol. Searching community strings for SNMP versions 1 and 2 did not give any results, so we will work with v3. The peculiarity of this mode is the increased security level and 3 authentication modes:

  • username;
  • username and password;
  • username, password and encryption password.

To get the username, run Patator. To the article, the username can be obtained regardless of the security mode used:


We get the username Rafael.

Now we launch the SNMPWN tool, which will simultaneously iterate over the password and encryption password for the specified user:


By the way, this tool can also pick up a username if you specify multiple logins in users.txt. Having chosen the password and encryption password, we use SNMPwalk to obtain information about the configuration of the router and the token:


Previously, the site was available for us, but was protected by the WAF. Now, when we have made our way to the same network to it, we can try to search for and exploit vulnerabilities. Let’s scan the site using whatweb, not forgetting to register in /etc/hosts to access the site bypassing WAF:


Found out that the web server is Nginx 1.18 and CMS WordPress 5.6.1. Launch WPScan to find more detailed information:


We find a list of plugins, among which there is a vulnerable backup-by-supsystic.

We find information about its vulnerability on exploit-db and use the exploit from the description for exploiting LFI. As a result, the file /etc/passwd is downloaded, where the token is located:



As with the News, Bugtrack and ITnews tasks, access to the server is only possible from a specific machine – To connect, we use the private key found in the Reverse task:

Server connection:


Find the token in the user’s home directory. Also, on the server, we find a certain dump in the /opt directory and copy it to ourselves for analysis. Analyzing the dump:

Load data to tcpdump:

And we find the mention of Asterisk IP telephony. Now let’s open this dump using Wireshark and go to the telephony section, where we can listen to the telephone conversation and get a token.


Having got to the server, several more hosts became available to us. In particular Using nc, we scanned the open ports of the server with the command:

As a result, they found 2 open ports – 80 and 6001.

Let’s forward to the remote machine with the following commands:

where /root/ghost is the certificate obtained in the Reverse job. Let’s turn to the site and see that the site is undergoing maintenance:

Attempting to fuzz directories through Dirb fails. It looks like there is nothing interesting on this site. Let’s forward port 6001 and see what’s there:

Php file was found while crawling the site with Dirb. This means that the site is working in the Nginx + PHP-FPM bundle. Therefore, we can assume that port 6001 is served by the PHP-fpm service, although it is not standard for it. In this case, you can check the vulnerability CVE-2019–11043 by running the script:


Having received a positive result, you can try to search for a token:

The token is presented in the form of a picture, which is clearly not without reason. Save the picture for further study. Additionally, the testlab.cap dump can be found on the server.


Let’s open testlab.cap with Aircrack-ng:


We select the Testlab network and wait for the tool to finish working


Examining the picture that we downloaded while completing the FPM task. She has no additional information besides the size, so let’s assume that steganography was used here. Download the package from Github for examining steganographic inscriptions and apply to our picture:


In the output, we get a token.


When examining the Admin server ( in .bash_history, we see a suspicious curl request to the host We forward this port to the local machine:

Tunnel creation:

And we turn to the Elastic service in the browser, but first you need to authenticate. Apparently basic auth is used. We know the username bj_smith, and it won’t be a problem to find the password:


we get a list of indices:

We see 2 indices of documents and documents2. Requesting content:


We get the first 10 records. We assume that the token is in the text field, but contains not only letters but also numbers. Let’s compose a curl-request with which we will search for matches in numbers for the “text” field. At number 3, we got the desired result in the form of a token:



On server, accessible through server (Admin), port 80 is available. Let’s forward to the local machine and examine the web application:

Tunnel creation:

Let’s try to scan a web application using Dirb:


We didn’t find anything, but if we add the -w switch, we will ignore the warnings:


This helped to find an auth page that no longer responds with a 403 code. It turns out that the authentication page was found. Requests are sent using the GET method, so let’s try to pick up a parameter for authentication through the GET parameter:

Something has been found, but it has not yet yielded anything significant. Let’s try to check the username parameter for sql injection. Now we dump the tables and look for the token:


After base64 decoding of the token, we get the answer YYaaYYaaFF.

Server also has access to the last 2 tasks – GIT and Cabinet, let’s start with the first. Let’s forward to the local machine with the following commands:

The main page opens, where we log in under the stepanova user account and examine the repository:

In the repository, we find the source code of the JAVA application for the JAVA job:


But in one of the commits, we find a token, which is the changed SSH password.

From server we scan our host and find open ports 22 and 80. Let’s forward to the local machine with the following commands:

Log in to the system under the ivanov user account and get to the page with the table:

Scanning a web application with Dirb gives no results:

Nothing more interesting was found on the site. Let’s try to connect to the server via SSH with one of the users. It is possible to do this under the leonov account.

Look at open ports and find a service with an open port 11211:

We find out that the port is used by the memcached service. Port 11211 is addressed only from the address Let’s go through telnet and execute the stats items command to display statistics:


Now let’s request a cache dump:

Command result:

Let’s see that one of the values is assigned for the current user in the session parameter in the cookie. This is probably the session ID. We check them in the browser, substituting each of them in turn in the session parameter:

We refresh the page and with one of them we see a token on the page:


This completes the passage of Test lab 15, thanks for reading to the end. To protect web applications, use Nemesida WAF – a comprehensive protection of sites, personal accounts, online stores, marketplaces and APIs from hacker attacks based on machine learning. See you in the new Test lab!

From Information Security With Love

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store