[ntlmrelayx.py] fails to pick up requests over HTTP

[Sockmower]

I'm trying to capture and relay authentication using ntlmrelayx.py; a Responder session in the same terminal window picks up the HTTP requests fine, but ntlmrelayx fails to produce any output even when debug mode is on. The client at 172.0.0.1 is repeatedly making HTTP requests to a resource on the attacker machine. The responder output is included below for reference:

mower@mowerbox:~$ sudo Responder.py -I ens3 -v

[omitted for brevity]
 
[+] Generic Options:
    Responder NIC              [ens3]
    Responder IP               [10.1.1.1]
    Challenge set              [random]
    Don't Respond To Names     ['ISATAP', 'ISATAP.LOCAL']
 
[+] Current Session Variables:
    Responder Machine Name     [WIN-1H2DNOLTFNE]
    Responder Domain Name      [XOAS.LOCAL]
    Responder DCE-RPC Port     [49079]
 
[+] Listening for events...
 
[!] Error starting SSL server on port 5986, check permissions or other servers running.
[!] Error starting SSL server on port 443, check permissions or other servers running.
[HTTP] Sending NTLM authentication request to 172.0.0.1 
[HTTP] GET request from: ::ffff:172.0.0.1 URL: /test.jpeg 
[HTTP] NTLMv2 Client   : 172.0.0.1 
[HTTP] NTLMv2 Username : APERTURE\cjohnson
[HTTP] NTLMv2 Hash     : cjohnson::APERTURE:ommitted_for_brevity

Running ntlmrelayx in the same terminal, while the HTTP requests are still being made:

mower@mowerbox:~$ sudo ntlmrelayx.py -tf targets.txt -smb2support -debug -ip 10.1.1.1
Impacket v0.11.0 - Copyright 2023 Fortra
 
[+] Impacket Library Installation Path: /usr/local/lib/python3.8/dist-packages/impacket
[*] Protocol Client SMB loaded..
[*] Protocol Client LDAP loaded..
[*] Protocol Client LDAPS loaded..
[*] Protocol Client MSSQL loaded..
[*] Protocol Client SMTP loaded..
[*] Protocol Client RPC loaded..
[*] Protocol Client DCSYNC loaded..
[*] Protocol Client HTTPS loaded..
[*] Protocol Client HTTP loaded..
[*] Protocol Client IMAP loaded..
[*] Protocol Client IMAPS loaded..
[+] Protocol Attack LDAP loaded..
[+] Protocol Attack LDAPS loaded..
[+] Protocol Attack HTTP loaded..
[+] Protocol Attack HTTPS loaded..
[+] Protocol Attack IMAP loaded..
[+] Protocol Attack IMAPS loaded..
[+] Protocol Attack SMB loaded..
[+] Protocol Attack DCSYNC loaded..
[+] Protocol Attack RPC loaded..
[+] Protocol Attack MSSQL loaded..
[*] Running in relay mode to hosts in targetfile
[*] 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

[no further output here]

Why is it that Responder picks up these requests just fine but ntlmrelayx fails to do so?

[Zamanry]

My team is having a similar issue. Auth PetitPotam SMB v1-3 > PC$ is not getting caught. Responder does. Pcredz does not. Someone else recommended you need to declare your network interface with ntlmrelayx.

[Sockmower]

@Zamanry: Thanks; do you know the argument to do so so I can test that?

[Zamanry]

@Zamanry: Thanks; do you know the argument to do so so I can test that?

-ip #.#.#.# where #.#.#.# is your interface IP. We’ll test PetitPotam with that parameter this afternoon

[Sockmower]

Ah! I am already specifying -ip. Thanks though

[p0dalirius]

Same issue here, any advice?

[Zamanry]

I tried the -ip flag, never fixed it. I’ve encountered this issue at multiple clients now.

[gabrielg5]

Hi, been doing some tests and wasn't able to replay the same behavior you are having.

There a couple parameters in ntlmrelayx to indicate in which interface (-ip) and port (--http-port in this scenario) to listen for connections

Just thinking out loud, and trying to better understand the scenario to analyze where could the issue be:
Those HTTP requests are being done to the interface you configured there right?
can you try configuring HTTP server in another port?

[p0dalirius]

Hi,

We've been doing some tests with multiple impacket versions.
It seems the issue was introduced between versions 0.9.24 and 0.10.0

Here are our results:

Impacket 0.9.24 (receiving authentications)

We coerce an authentication through EfsRpcEncryptFileSrv with PetitPotam.py to a WebDaV server hosted on our machine on port 8080:

We do receive HTTP authentications in ntlmrelay:

And we do receive the expected PROPFIND handshake of WebDaV:

Impacket 0.10.0 (not receiving authentications)

We coerce an authentication through EfsRpcEncryptFileSrv with PetitPotam.py to a WebDaV server hosted on our machine on port 8080:

In this case (ntlmrelay in impacket 0.10.0), we do not receive any HTTP authentication on ntlmrelay:

But we do receive the expected PROPFIND handshake of WebDaV:

Therefore, we need to find in which commit the issue was introduced between:

• impacket release 0.9.24 commit 265ce178fc1afcf942e2e1fabd7c8fab64e94893 (working)
  and
• impacket release 0.10.0 commit 7a18ef5c8b06aac5e36334927789429777382928 (broken)

Best regards,
Podalirius

[anadrianmanrique]

@p0dalirius this issue is related to ldap parameters handling in ldapattack.py. The webdav connection it's being handled ( as it's being shown in wireshark ). Can you please try with the master branch version? it seems this was fixed in 337d50d

[anadrianmanrique]

@Sockmower sorry for the late response, can you provide the content of the target list file?
can you also try with the master branch version, as many things has changed in ntlmrelayx since you reported this issue?
Thanks!

[gabrielg5]

Hey,

yesterday was doing some tests with different Impacket versions and finally found the commit that removed the log message (c237962) related with the multirelay feature addition at #1297

It only affects WebDav requests.
That is what was happening in your tests @p0dalirius.
Were you doing webdav requests or HTTP GETs in yours, @Sockmower??

When processing an HTTP GET a message is always logged (unless in REDIRECT mode, but it wasn't the case in your tests)

impacket/impacket/examples/ntlmrelayx/servers/httprelayserver.py

Lines 245 to 250 in 829239e

	def do_GET(self):
	if self.server.config.mode == 'REDIRECT':
	self.do_SMBREDIRECT()
	return
	LOG.info('HTTPD(%s): Client requested path: %s' % (self.server.server_address[1], self.path.lower()))

But when processing WebDav, the PROPFIND method is not logging anything - at least until the connection is properly relayed -

impacket/impacket/examples/ntlmrelayx/servers/httprelayserver.py

Lines 182 to 189 in 829239e

	def do_PROPFIND(self):
	proxy = False
	if (".jpg" in self.path) or (".JPG" in self.path):
	content = b"""<?xml version="1.0"?><D:multistatus xmlns:D="DAV:"><D:response><D:href>http://webdavrelay/file/image.JPG/</D:href><D:propstat><D:prop><D:creationdate>2016-11-12T22:00:22Z</D:creationdate><D:displayname>image.JPG</D:displayname><D:getcontentlength>4456</D:getcontentlength><D:getcontenttype>image/jpeg</D:getcontenttype><D:getetag>4ebabfcee4364434dacb043986abfffe</D:getetag><D:getlastmodified>Mon, 20 Mar 2017 00:00:22 GMT</D:getlastmodified><D:resourcetype></D:resourcetype><D:supportedlock></D:supportedlock><D:ishidden>0</D:ishidden></D:prop><D:status>HTTP/1.1 200 OK</D:status></D:propstat></D:response></D:multistatus>"""
	else:
	content = b"""<?xml version="1.0"?><D:multistatus xmlns:D="DAV:"><D:response><D:href>http://webdavrelay/file/</D:href><D:propstat><D:prop><D:creationdate>2016-11-12T22:00:22Z</D:creationdate><D:displayname>a</D:displayname><D:getcontentlength></D:getcontentlength><D:getcontenttype></D:getcontenttype><D:getetag></D:getetag><D:getlastmodified>Mon, 20 Mar 2017 00:00:22 GMT</D:getlastmodified><D:resourcetype><D:collection></D:collection></D:resourcetype><D:supportedlock></D:supportedlock><D:ishidden>0</D:ishidden></D:prop><D:status>HTTP/1.1 200 OK</D:status></D:propstat></D:response></D:multistatus>"""
	token, messageType = self.strip_blob(proxy)

A similar scenario, but for SMB relay, was solved in #1602. Will be submitting a new PR to handle these scenarios in all different relay servers; to give visibility on the received connections.

thank you!

[Zamanry]

I can jump in again! I was facing this issue with WebDAV coerced using PetitPotam code. Appreciate the help!