Pages

Sunday, February 28, 2016

A recent penetration test was one of the rare ones where it was not possible to locate a domain admin credential (password/hash/ticket) using the usual methods. I already had Administrator access to one of the server thanks to a file upload feature in an in-house log management dashboard running over WAMP (WAMP runs with SYSTEM privileges). I got access to few more servers by using hashes of a domain user who was local admin on couple more servers and some more similar stuff, but still no luck.

Anyway, after looking around for Active Directory and Kerberos related attacks for a while, it was time for reconsidering the attack approach. Recall the first thing which comes to mind when we fail at server side attacks? Absolutely! Client side attacks. I could drop some emails with attachments and links and hope for hitting a user machine which leads me to a server which has a Domain Admin token. The client, for his own reasons, wanted me to keep all the connect back shells/requests from phishing within the internal network and there was absolutely no outgoing traffic allowed towards my VPN machine.(Diagram build with draw.io)

So, either I needed to setup multiple listeners on one of the compromised servers which can handle multiple connect back shells or some way to use an existing service as a listener for my phishing attacks. Since I am lazy :) I decided to go with the second option, that is, using an existing service. While enumerating the domain after initial foothold, I saw that a web server had Kerberos Unconstrained Delegation enabled.

Once I realized Kerberos Unconstrained Delegation was enabled, I could attempt to exploit this scenario using a technique Sean Metcalf (@PyroTek3) spoke about last year and published on ADSecurity.org (https://adsecurity.org/?p=1667). Sean covers how exploiting a server with Kerberos Unconstrained Delegation can lead to credential theft of DA credentials resulting in Active Directory compromise by tricking a Domain Admin into connecting to any Kerberos service on the server.

So, all that needed to be done was creating phishing emails and use them to connect back to the server where I had admin access and wait for a domain admin to fall for an email.

Here is how I did it (replicated in my lab).

1. pfptlab-build is the server where we have admin access with RDP, PowerShell Remoting etc.
2. pfptlab-web is the server where we can execute commands as admin but it is not directly accessible.

Searching for computers with Unconstrained Delegation

By using the built-in Active Directory PowerShell Module. This module is available by default on Windows Server 2012. From an elevated shell on the server with admin access (pfptlab-build) use the below commands:

Another way of searching for computers with Unconstrained Delegation is using Powerview:

Setting up the "Listener"

On the server where unconstrained delegation is enabled (pfptlab-web in the lab), we can enumerate existing tickets using Invoke-Mimikatz. Keep in mind that we have admin access to the server with the help of hash of a domain user who is local admin on that server. Please note that we can pass the ticket as well but the expiry time of the ticket will play a spoilsport here as we need to wait till a domain admin connects to the machine.

We can use the hash of domain user webadmin which is a local admin on the pfptlab-web, the server with unconstrained delegation:

This is how the output of these commands look like:

Now, let's list tickets on pfptlab-web, the server with Unconstrained Delegation. Since, we have direct access to the pfptlab-build machine, let's *drop the script on disk* there and use below commands to use it in a stateful session on pfptlab-web without touching disk. Remember that below commands need to be run in the PowerShell console opened by over-passing the hash of the webadmin user:

An alternate way with a catch!
A quick thing to note here. If we try to use below command (to execute Invoke-Mimikatz on pfptlab-web without dropping the script to disk on pftplab-build) there will be an error.

Because, we cannot pass named parameters in the -ArgumentList parameter. It is not possible to pass "-Command '"sekurlsa::tickets"'" in the above case. We can pass only the positional parameters. To overcome this I changed the positions of the parameters. I assigned position 0 to the "Command" parameter of Invoke-Mimikatz and the above command worked successfully. Now the catch! If I add "/export" to the ArgumentList parameter in the above command, it fails as PowerShell passes it to the Invoke-Mimikatz as second parameter. If anyone is able to do that successfully, please share!

So, assuming that we have enumerated the Domain Administrator accounts already and one of them is the "Administrator", to know if a domain admin has connected we can use the following ugly method:

May be someone will automate this in a much cleaner way. If a ticket of the Domain Administrator, Administrator, is saved by Mimikatz, the second command above should list it. But, no Domain Admin ticket on pfptlab-web, yet.

Preparing email

Fortunately, the client's internal mail server allowed email relaying so sending phishing emails was not a problem. I was able to get access to email ids with a combination of AD usernames and couple of email excel files I got my hands on. After sharing the emails with the client, he removed emails of some guys from the management. One of the multiple email templates used was:

While I am no expert in crafting phishing emails, I would like you to note some points in the above email:
- No intimidation but a balanced tone of Authority.
- Use of jargon but not too obscure words, as if I was really trying to explain complex things in simple terms to the user.
- Requirment of urgent action by the target user.
- Command which displays a lot of output.
- Providing an alternate way to the user if they can't access the share which makes me look more helpful.
Though I tried to pick the "email culture" of the client from the emails I exchanged, surely, this email could be written in a lot better way.

Using the below command, email was sent to users.

This is how the email looked in like in mailbox of one of the targets.

Execution

After sending email, I started checking the tickets for Domain Administrator by running Invoke-Mimikatz repeatedly and soon there were more than one domain administrators who complied to whatever they were asked to do :D

Now, in my opinion, the best way to use the tickets is to copy them to the pfptlab-build server as we have direct connectivity to it. Using the below command we can copy all the tokens from the pfptlab-web to pfptlab-build machine.

Now, we can use one of the Administrators tickets copied locally to elevate our privileges to Domain Administrator:

Thursday, February 11, 2016

Kautilya has the ability to do interesting and useful stuff using a Human Interface Device. But sometimes, nothing beats a simple reverse shell. Recently, I added some new payloads to Kautilya which are useful for getting reverse shells using different protocols.

This post describes the payloads which give us the capability of having reverse connect PowerShell shells from Windows targets. With these payloads, Kautilya now has improved capability to provide us with a foothold machine in penetration testing engagements where use of Social Engineering techniques is allowed. Those who follow my other tool Nishang, I did a five part blog series on that.

Lets see the payloads in action.

Reverse TCP and Reverse UDP

Both of the payloads can be used with a standard netcat listener both on Windows and Linux. On Windows, Powercat can also be used. We just need to provide the IP to which the target connects back and the port to use. Upload it to a HID and send it to a target.

When a target connects the device, this is how it looks like at the listener.

Neat! An intercative reverse PowerShell shell.

Reverse ICMP

My favorite one for bypassing network restrictions, a reverse shell completely over ICMP. This payload needs a listener, icmpsh_m.py, from the icmpsh suite. Run the command "sysctl -w net.ipv4.icmp_echo_ignore_all=1" and start the listener. This is how it looks like on a successful connection:

This one has been useful in so many penetration tests.

Reverse HTTPS and Reverse HTTP

Reverse HTTPS is proxy aware and uses valid HTTPS traffic for reverse PowerShell shell. Its target part (typing done on the target machine) is very small and this makes it very useful. Currently, a listener on Windows is required. Run Invoorke-PoshRatHttps.ps1 in the extras directory of Kautilya from an elevated shell. The listener script adds exception to the Windows Firewall for incoming requests on the specified port.

Awesome, isn;t it?

Hope you liked the post! As always I look forward for feedback and comments.

Learn penetration testing of a highly secure live Windows network with me in PowerShell for Penetration Testers Training at: