Conference DEFCON 20. Capture in 60 seconds: from guest account to Windows domain administrator. Part 1

Original author: Zach Fazel
  • Transfer
Hi, I'm Zach Fazel, I will speak quickly, if it is too fast, you can slow me down. During the day I am a pentester, at night a DJ and a photographer, I can be found on Twitter on nick @zfazel. People always ask me about diplomas. I am not one of those people who list a bunch of degrees, so it's better to judge me on the basis of this presentation, and not by the number of certificates I have.

Shameless comment: we have a little competition here, right now the guys from Chicago are performing on track 4, we are all from Chicago, quickly raise your hands, who are from Chicago. So, I think I lost the bet. Tonight in the pool I'll be a DJ, so if you're free, welcome to the battle with Kate Myers, after that I return to Chicago for another hacker conference. Last year there were 500 people present, this year we hope that there will be more guests. My guys from team 312 will also perform there, more information about this conference can be found at

So, not to waste time: we will talk about an alternative to the Pass-the-hash attack called NTLM-Relay, a new set of tools for performing inter-protocol transmission of Cross Protocol Relaying for NTLM authentication requests, new methods for automatic authentication of clients and new purposes for which you can use Pass-the-hash.
Let's start with NTLM, for those who do not know what NTLM 101 is, the whole point can be stated in less than 10 minutes. So what is LM / NTLM? It is a password store and network authentication protocol developed by Microsoft for use in Windows. Damn, my slides are not fine! So, LM-hash is a format for storing user passwords with a length of less than 15 characters, the password is divided into 2 parts of 7 bytes and is reduced to upper case. I hope you can see what LM and NTLM hashes look like. I'm not going to waste time telling how bad and weak the LM is, you know all this, and if not, google it.

An NTLM hash is usually case-sensitive, has an unlimited length, does not break into groups of characters, and is slightly stronger than LM, but is also not without problems. Now I will tell about them. The first vulnerability is the ability to attack Pass-the-hash, which allows a hacker to authenticate to a remote server that uses client authentication based on NTLM / LM protocols. Sorry, guys, I mixed up the slides, I made them 5 minutes ago, in short, the LM - this sucks.

So what is NTLM authentication? This is network authentication for remote services. It is needed to prove that you really are what you call yourself. The service usually runs on a separate computer where you want to access resources offered by the service, for example, the file server is the service and the files are the resources. In a minute we will look at what these services are.

We can get confused when we talk about NTLM v1, v2, NTLM 2, signed or unsigned, so let's quickly go over NTLM authentication. The authentication process sends 3 message types.

Type 1 is the client accessing the server to establish a contact, something like “I want to authenticate”. You can see the packet that was disassembled into parts, captured by Wireshark, here there are flags to support authentication, the name of the workstation and the domain name belonging to it.

Message Type 2 is the server's response. If you noticed from the Type 1 message, we still don’t know who this user is, he just asked to connect to the server and wants to know if the request is supported.

You see here the response of the NTML Challenge server as a set of numbers that changes every time. The screenshot shows a static response that can be used to create “rainbow tables”. So, the server responds with a message of the second type: “this is what I support, here is my domain name, here is my server name”. This answer is used to “salt” your password hash, so that every time a unique answer is obtained, you cannot repeat it again and again with the same request.

Message Type 3 - this is the client authentication message.

This is the server's response, which is hashed with the password for the NTML hash, along with the username, the name of the workstation and the name of the domain belonging to it, and the session key if you sign the session.

This is what NTML version 1 is. NTML version 2 is very similar to it, but there are added additional parameters to the response password and calling the client to protect against the use of rainbow tables, that is, the client uses an element of randomness against them.

Another thing we need to talk about is integrated Windows authentication. It is necessary so that you do not have to re-enter the system with a password every time in order to use resources and services. If you are connected to a domain server or an internal web server, Windows does not ask you for a password, it simply requests the API and receives information from it what the system should use for authentication.
In the context of local security, HTTP protects by using trusted security zones, trusted sites, or local sites, checking for only one-word domain name. I will try to quickly refresh your memory. A one-word domain first searches for a DNS name on DNS servers, then checks its host or DNS host name and sends it back. It checks the structure of your full name and then executes the NBNS, which is a broadcast request for that domain name. In fact, he asks the network: “hey, I'm looking for a name , do you know someone with that name?”, Distributing this request over the local network in the MBNS multimedia broadcast mode.

As I have already said, since we use the SMB protocol everywhere, there are no limitations here, we just have automatic authentication using SMB. This causes some problems.

Consider the Pass-the-hash method. The protocols show that NTML does not use the original password for authentication, so all we need is the NTML hash itself. We can access the NTML hash using various Windows tools, that is, pull this hash out of local storage or from memory. All this has been described in other speeches, I just quickly remind you of the gist of the matter to show the differences between the two methods.
The fact is that usually this Pass-the-hash requires access at the local system administrator level, because with a guest account you will not get access to local storage or local memory.

So what is NTLM Relaying and how does it differ from the Pass-the-hash method? People constantly say to me: “oh, you're telling you about Pass-the-hash!”, And I answer: “No, I'm talking about NTLM Relaying!”. The difference is that NTLM Relaying does not require administrator authority to access the network or the system. In fact, you are connecting to the network from the inside or outside and start working as a guest. There are no credentials, no access to the system, only the request is authenticated, if you return to the above types of messages 1,2,3. There is no verification when the host responds to your request and makes sure that you are you.
What we do is create a fraudulent server to receive authentication requests and then relay them to the target server.

Let's listen to the story so that you understand the essence of the question. Back in 1996, when Dominic Brezinsky discovered the vulnerability of the authentication process using the access protocol CIFS, the first version of the SMB protocol. After that, the first time they started talking about the possibility of using NTLM Relaying. In 2001, NTLM managed to find a hole in SMB. First, Veracode employee Christian Ryu (aka Dildog) told about this at a DefCon conference, and then hacker Josh Bushbinder (aka Sir Dystic) published an exploit code that works with this vulnerability. At the same time, Telnet protocol and IE browser vulnerability were used, where you could simply type telnet: // ip and automatically authenticate.

After that, the NTLM Relaying method was used to redirect SMB requests to other hosts or to its own host. This continued until November 2008, when Microsoft Windows patched up holes where they could, preventing the possibility of a reverse return of the NTLM authentication request patch MS08-068.

Thus, we lost the opportunity to return the authentication request to our host and could only redirect it to other hosts due to the design features of the protocol. In 2008, the guy under the nickname Grutz spoke at DefCon with a statement about the death of NTLM. I think it was one of the best performances in recent years, because it had a huge impact on the corporate environment.

He called his instrument the Pokémon name "Squirtl" and the technology - "monkey in the middle" by analogy with "man in the middle". This tool allowed NTLM Relaying to be performed via HTTP and also worked well with SMB, receiving authentication requests.

This screenshot was taken two days ago, and the development of its Squirtle application is still ongoing. I decided that you are all familiar with these vulnerabilities, the problems of which we speak again and again, because they are not corrected in any way and show themselves everywhere. I belong to the corporate environment, so I know very well about the problem that I constantly complain about - this is the fact that websites do not do SSL encryption of authentication requests, just as they do not encrypt their cookies. In 2010, a Firefox browser extension called Firesheep was released.

You are probably familiar with this tool for intercepting unencrypted HTTP cookies of popular websites and other people's sessions of working with websites via Wi-Fi or sniffing networks, posing as other users.

I asked myself the question of where people have a craving for creating such tools. It turns out that it's all about ease of use. It is easy enough to create an application that allows you to impersonate someone else. So I decided to start with the same and make an application that would allow using the NTLM Relaying method to show people that this is as simple as Firesheep.

I started working on NTLM Relaying to see how much it can be supported by multiple protocols. Many people talked about the theoretical possibility of such support, but no one has realized this in practice. So my goal was to create a Firesheep for NTLM.
I decided to start learning Ruby, because I was originally going to integrate my exploit into Metasploit. In 2012, I wanted to address this topic at Black Hat and DefCon conferences, but my report was rejected. Not only were my speeches rejected, I received a false e-mail message saying that DefCon had accepted my report. A friend thought it would be very funny to punch me, he was such a jerk. He had a friend here, whose performance was approved, and my friend took and sent me the contents of his email. I did not pay attention to the headline, where it was “From Nikita” and panicked, realizing that I had to speak at DefCon in an hour and a half, but then I received a real letter of refusal.

Do you think this story ends? No, three weeks later, Nikita said to me: "Hey, we have an opening on Sunday, someone refused to participate, would you like to take the place of him?" I thought it was great, but then I realized that I had very little time before the performance, and started coding like crazy, trying to finish everything in time.

So what were my problems? First of all, other people's tools could not do the work of the pentester I needed, they sorely lacked various protocols that could return the authentication requests. Most of the protocols related to the use of SMB and HTTP and none of them supported LDAP for MySQL authentication or at least remote desktop testing, VPNs, and the like.

Another problem was that they all forwarded each request to the same destination. That is, we obtained user data, computer accounts and sent all authentication to the same target, so we could not identify users before authentication, that is, before receiving the message “Type 3”. If you remember these messages like 1,2,3, then the message Type 2 is the response of the server. It is unique for each session, and I do not know who these users are until they send the last Type 3 message, and I do not know which answer and which server belongs to the user. I was interested in why there are no tools that would do this, so I took a closer look at protocols like SMB and HTTP, later we will talk about this in more detail.

Windows 8 and Windows 2012 still support NTLM by default. This is scary because we know about the vulnerability of these protocols, but NTLM has not gone away. Therefore, we, as pentesters, inform organizations that they must protect themselves against such attacks.
So, I wanted to solve this problem and created a tool called ZackAttack. I know that it looks ugly, but we went through a whole bunch of names, I personally liked the last one most of all - “NTLMv2? Bitch Please ... ".

What is contained in this tool? I will quickly run through these slides, as I believe that I have already entertained you enough. ZackAttack consists of several different components, we will talk about each of them and how they are related to each other.

First of all, there is an HTTP SMB server here - this is a fraudulent server that accepts authentication requests. So clients target this server, perform authentication, and the server keeps them authenticated. Next we have a set of rules for automatic operation.

We have clients for such automatic exploits, as well as APIs that we can associate with any third-party application that performs the transfer of NTLM Relaying requests.

Finally, we have a generation of payloads that force clients to automatically authenticate to us.

What are fraudulent servers? First, they authenticate users and save it for us, later I will tell you how we use it.

We need all these people to retain their authentication status. There are many tools that disable users after the first successful authentication, but our ZackAttack tool keeps users authenticated as long as possible. In Windows, the SMB LAN is about 30 times before the connection is terminated. So, we need to find out who this user is, while we keep him authenticated.

The first authentication request is a static call of type 112233. Those of you who are engaged in pinging know that this is a kind of task for rainbow tables. As I said, we have to figure out who this user is, but we don’t know this until we reach the Type 3 message, so we send a bunch of calls. I call this the “Alzheimer's element” when the system forgets who the user is and asks him to authenticate each time to connect without closing the session.

The reason why we do this is that HTTP, WPAD and other requests do not always support cookies, in addition, SMB authentication via IP or Source Port source Port does not work if you try to remotely access it via the Internet.

Therefore, for the HTTP server, we use a 302 redirect with the Keep-Alive parameter, which allows us to keep the session open while the socket is closed, and after we authenticate, we know who they are, and we know it until the end of this session.

With SMB it was harder, I had to write a custom SMB server, it’s a bit buggy, but it still works. I'm not going to delve into the authentication mechanism of the SMB protocol, because it will take a couple of hours, so I will explain briefly. After the server receives an authentication request, it forgets about who this user is and says: “Oh, hello, nice to meet you!” - “cool, I want to connect!” - “wait, and who are you?” and again requires an authentication request.

So, we need to get authentication requests that go to HTTP and SMB servers. Many people ask how we carry out the man-in-the-middle attack. There are several different ways to get people to authenticate on our server, and then send them to do other things. Therefore, consider what constitutes the payload in our tool.

First of all, it is WPAD - the proxy automatic configuration protocol, which allows you to determine the location of the configuration file. In Windows, when you try to connect, as you know, a window appears with a small tick "automatically find my connection settings", which activates WPAD. This protocol sends requests for DNS verification and webcasting, so you can fake these requests and respond to them.

By default, on Windows, the computer will automatically authenticate the WPAD server over HTTP with the current user credentials.

18:00 min.

Conference DEFCON 20. Capture in 60 seconds: from guest account to Windows domain administrator. Part 2

Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending to friends, 30% discount for Habr's users on a unique analogue of the entry-level servers that we invented for you: The whole truth about VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps from $ 20 or how to share the server? (Options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps until spring for free if you pay for a period of six months, you can order here .

Dell R730xd 2 times cheaper? Only we have 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV from $ 249in the Netherlands and the USA! Read about How to build an infrastructure building. class c using servers Dell R730xd E5-2650 v4 worth 9000 euros for a penny?

Also popular now: