fortra/impacket

Client RST TCP Connection instead of switching to NTLM

HAVP opened this issue · 2 comments

HAVP commented

ntlm-problem.zip

Configuration

impacket version: v0.11.0
Python version: Python 3.11.6 (main, Oct 8 2023, 05:06:43) [GCC 13.2.0] on linux
Target OS: 2023.3 Linux kali 6.5.0-kali3-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.6-1kali1 (2023-10-09) x86_64 GNU/Linux

Problem

IP Kali: 192.168.77.24
root@kali:~/responder/igandx-Responder# impacket-ntlmrelayx -t 192.168.77.3 -smb2support
Impacket v0.11.0 - Copyright 2023 Fortra

[] Protocol Client HTTPS loaded..
[] Protocol Client HTTP loaded..
[] Protocol Client RPC loaded..
[] Protocol Client SMTP loaded..
[] Protocol Client DCSYNC loaded..
[] Protocol Client MSSQL loaded..
[] Protocol Client LDAP loaded..
[] Protocol Client LDAPS loaded..
[] Protocol Client IMAPS loaded..
[] Protocol Client IMAP loaded..
[] Protocol Client SMB loaded..
[] Running in relay mode to single host
[] Setting up SMB Server
[] Setting up HTTP Server on port 80
[] Setting up WCF Server
[] Setting up RAW Server on port 6666

[] Servers started, waiting for connections
[] SMBD-Thread-5 (process_request_thread): Received connection from 192.168.77.23, attacking target smb://192.168.77.3

The client (Windows 22H2 19045.3693) does a RST of the connection. It looks like the client sends "SMB2: Session Setup Request, INITATOR_NEGO, INITIATOR_META_DATA". After that server send a respond, the client resets the connection. I attached a pcap.

If I start "impacket-smbserver test /tmp/ -username user1 -password 'xxx' -smb2support", the same client can connect to the server without a problem.

I also tried Responder. I can also see "SMB2: Session Setup Request, INITATOR_NEGO, INITIATOR_META_DATA". Responder sends "SMB: Session Setup Response, Error: STATUS_MORE_PROCESSING_REQUIRED, NTLMSSP_CHALLENGE". After that the Windows Client sends a RST.

Everything works for a Windows 10 22H2 (19045.3570).

It looks like the client sticks with kerberos authentication and did not switch to NTLMSSP_NEGOTIATE.

I tried different Python and impacket versions. The impacket-smbserver send NTLMSSP in the GSS-API. impacket-ntlmrelayx send in addition the kerberos MechType e.g. KRB5.

Is there a bug in the python library?
Could it be some kind of configuration on the windows client? But I don't think so.

Thank you

HAVP commented

I updated the other Windows to also 22H2 19045.3693 and it is still working.

The problem only appears for active directory domain users. Local accounts work find. This sounds reasonable to me, because local accounts are not capable of kerberos authentication.

HAVP commented

I changed the following lines in smbrelayserver.py and now it is working.

Line 209:
blob = SPNEGO_NegTokenInit()
blob['MechTypes'] = [TypesMech['NEGOEX - SPNEGO Extended Negotiation Security Mechanism'],
TypesMech['NTLMSSP - Microsoft NTLM Security Support Provider']]

To:
blob = SPNEGO_NegTokenInit()
blob['MechTypes'] = [TypesMech['NTLMSSP - Microsoft NTLM Security Support Provider']]