I've been playing with trying to determine if there is a way to take
advantage of the many NBNS Name Query requests that are sent to the
broadcast address.  Specifically, I want to be able respond and redirect
these hosts to the attacker's box to perform attacks similar to smb_relay.
See this scenario:

Victor attempts to mount a share on \\notreal.  In an AD environment,
1) issues DNS requests for notreal.sub.domain.tld; DNS server responds it
doesn't exist
2) issues DNS requests for notreal.domain.tld; DNS server responds it
doesn't exist
3) issues NBNS request to the the NB name server; NBNS gives response that
it doesn't exist
4) issues a request to broadcast (n.n.n.255), which would go unanswered in a
normal environment

Question 4 is what I'm trying to answer and elicit an SMB request to
metasploit.  When you spoof a response and Victor is looking to make an HTTP
connection, it immediately issues a GET to the IP address from the spoofed
response, as I expected.

However, when Victor wants to make an SMB connection, his PC issues an
NBSTAT request to the IP:137, which metasploit/linux has no idea what to do
with, and responds with an ICMP Type 3 Port Unreachable message.

1) What causes Victor to issue an NBSTAT request?  Is it something wrong in
my spoofed response packet, perhaps?  (When Victor opens an SMB connection
to \\ip.add.res, it immediately performs an SMB connect to :139; no NBSTAT
to 137 is performed.)  I've examined my spoofed response and can't see
anything that would be kicking off an NBSTAT request, but I may be missing
2) Anyone know if it's possible to answer 4) in such a way that Victor will
skip the NBSTAT request?
3) Is it possible to answer 4) with an NBSTAT response that will elicit a
Negotiate Protocol Request to :139 or :445?

Thanks very much for any help you can provide!  I'm sure there's good
documentation out there on this, but it's apparently hidden in the mounds
and mounds of trash from 20 years of SMB protocol development.
Framework-Hackers mailing list

Reply via email to