Shulou(Shulou.com)06/02 Report--

This article will explain in detail how to detect Pass-the-Hash attacks. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have some understanding of the relevant knowledge after reading this article.

Horizontal penetration technology is one of the most common methods used by attackers to infiltrate the target network and obtain credentials and privileged access to data. This is illustrated by the recent discovery of blackmail software such as Samsam and Ryuk.

Recently we studied how to detect pass-the-hash attacks through honeypots, and while studying the most effective ways to detect such attacks, I found several other interesting methods. I think it is very necessary to test them and further study the pass-the-hash behavior.

In this article, I'll show you how to use the native Windows event log to detect pass-the-hash, as well as some practical advice on how to implement it. I won't talk about what pass-the-hash is here. You can read this article and watch its demo video if you like.

Baseline normal event

Pass-the-Hash relies on NTLM authentication. To reliably create NTLM authentication, I use the Sqlcmd utility to connect to the Microsoft server through its IP address. This command generates NTLM authentication for the SQL database:

Sqlcmd-S [IP ADDRESS]

Before we look at how to detect pass-the-hash attacks, let's get the event baseline that is typically generated when performing NTLM login activities. To do this from my PC workstation, I will first start a new command prompt with the actual password of the administrative user:

Now, at the new command prompt, I will use Sqlcmd to connect to the SQL host and run the SELECT SYSTEM_USER command to view my authenticated user:

All right, everything's fine! Now let's look at the generated log.

Workstation log

I saw the following events on my local workstation.

4648 event: attempt to log in with explicit credentials (A logon was attempted usingexplicit credentials)

4624 event: successful login account (An account was successfully logged on)

The 4624 event shows that the login type is 2, which means an interactive login. This fits the way I use runas, where I enter credentials interactively.

4672 event: assigned to a new login privilege

Because the Franklin Bluth account I use is an administrative account, 4672 shows the permissions being assigned. This is a very practical way to track administrative account activity.

Target server log

I see the following events on my SQL server:

4624 event: successful login account (An account was successfully logged on)

Now, on SQL Server, you will see event 4624, which has a login type of 3, that is, network login.

More importantly, it indicates that the authentication package (Authentication Package) used is NTLM. It also confirms that we are using this method to perform NTLM authentication.

We will also see the 4672 event because the user account we are using is a privileged account.

Domain control log

On the domain controller, I will see signs that the user Franklin Bluth is authenticated. In this example, I will see Kerberos and NTLM authentication. Kerberos authentication occurs first, which is the default authentication method for Active Directory. This generates two events:

4768 event: Kerberos Authentication ticket (TGT) request

The above shows our simulated user's TGT request to the domain controller.

4769 event: Kerberos service ticket request

Once we have TGT, we will request TGS for our simulated user's host. With this, our user Franklin can now interact with PC and launch a command prompt.

4776 event: domain control attempted to validate account credentials

The 4776 event is specific to NTLM and will be at the end. This happens when we execute a command using Sqlcmd that forces NTLM authentication.

The following is a summary of the logs we saw when performing NTLM authentication without pass-the-hash. This provides us with a baseline for normal behavior.

Source host destination host domain controller 4648 event: attempt to log in 4624 with explicit credentials-account logged in successfully. The login type is 3century NTLM4768-Kerberos authentication ticket (TGT) request. 4624-account logged in successfully. Login type is 24672-assigned to the new login privilege. 4769-Kerberos service ticket request. 4672-assign new login privileges. 4776-the computer attempted to verify the credentials of the account.

Now, let's take a look at what we saw at Pass-the-Hash.

Pass-the-Hash event

To perform the pass-the-hash test, we will do the same exercise, except this time we will use the mimikatz and pass the hash commands instead of using runas as the user to start the process.

I can easily get the NTLM hash value of the user Franklin from memory using the mimikatz command:

After getting the hash, I will perform a pass-the-hash attack using the following command:

Sekurlsa::logonpasswordsSekurlsa::pth / user:Franklin.Bluth / ntlm: [ntlm] / domain:jefflab.local

This will open a new command window, and if I connect to my SQL Server's IP address using the same Sqlcmd command, you can see that I am now verified as Franklin Bluth:

So, let's see what events will be generated after the pass-the-hash is executed:

Workstation log

On my local workstation, I saw that events 4648, 4624 and 4672 were the same as I was doing legitimate NTLM authentication, but with some key differences.

First, the login type for the 4624 event is 9. This is a NewCredential login type and is a very useful way to identify pass-the-hash. This was determined by security researchers, and I reproduced it in my tests.

Login type 9 is very rare. However, I was able to generate some false positives running applications that use simulations. The key difference is that the login process is always "seclogo" for pass-the-hash (from my test), so you can filter it out to reduce false positives. You can see here that I can get StealthAUDIT to generate Logon Type 9 events, but it uses the Advapi login process.

In addition, I noticed the difference between the 4672 incident. Previously, this confirmed the privileged login of my impersonation account Franklin Bluth. This will register me for users who log in to my workstation.

In addition, the logs on the SQL server are the same. On domain controllers, the key difference is that you won't see Kerberos authentication. However, this is not a reliable way to detect pass-the-hash, such as authentication originating from an untrusted domain.

The following is a summary of what we saw when we executed hash-hash.

Source host destination host domain controller 4648 event: attempt to log in 4624 with explicit credentials-account logged in successfully. The login type is 3century NTLM474776-the computer attempts to verify the credentials of the account. 4624-account logged in successfully. (Logon type = 9 Logon Process = Seclogo) 4672-assign new login privileges. 4672-assign new login privileges. (login user instead of impersonating user)

Sysmon

I used Sysmon to finally detect pass-the-hash, which helps monitor process access events. We used it in honeypot detection, and you can read this article to learn how to set it up.

When pass-the-hash occurs, you will see the event ID 10 showing access to the LSASS process from Mimikatz or the pass-the-hash tool you choose to use.

Construction of Pass-the-Hash detection

Now that we have looked at all the evidence for pass-the-hash attacks, the easiest way to build to detect pass the hash attacks is to find:

4624 events on your workstation

Logon Type = 9

Authentication Package = Negotiate

Logon Process = seclogo

LSASS process accesses associated Sysmon 10 events

By customizing the event log filter, you can easily see pass-the-hash activity on your network when these two things happen at the same time!

The following is a custom event filter that can be used to display specific information.

* [System [(EventID='4624')] and EventData [Data [@ Name='LogonType'] ='9'] and EventData [Data [@ Name='LogonProcessName'] = 'seclogo'] and EventData [Data [@ Name='AuthenticationPackageName'] =' Negotiate']] * [System [(EventID=10)]] and * [EventData [Data [@ Name='GrantedAccess'] and (Data='0x1010' or Data='0x1038')]]

I hope that through the study of this article, you can learn how to detect pass-the-hash attacks through the event log. This requires logging to be enabled on all endpoints. To make it easier to detect pass-the-hash attacks using more advanced technologies, you may need to use third-party threat detection products, such as StealthDEFEND.

On how to detect Pass-the-Hash attacks to share here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.