Hostnames truncated to 15 characters in `--generate-hosts-file` due to NetBIOS/SMB limitation

[skyf0l]

Summary
When using netexec smb --generate-hosts-file hosts, hostnames longer than 15 characters are truncated in the output file (e.g. ACADEMY-AEN-MS01 becomes ACADEMY-AEN-MS0). This is because NetExec relies on the NetBIOS hostname obtained from SMB/NetBIOS, which is limited to 15 characters by the protocol spec.

Details

• The hostname field is retrieved from the SMB server using impacket's getServerName() method.
• Source: nxc/protocols/smb.py#L196

self.hostname = self.conn.getServerName()

• NetBIOS hostnames can only be up to 15 characters long; longer real hostnames (as shown in DNS/Active Directory) are silently truncated by the protocol.
• This can cause confusion or errors for environments where server names exceed 15 chars.

Example output:

172.16.8.50     ACADEMY-AEN-MS0.INLANEFREIGHT.LOCAL ACADEMY-AEN-MS0

But actual name is ACADEMY-AEN-MS01

Suggestion for Improvement

• If hostname is over 15 characters, try to also resolve the FQDN using DNS or LDAP and display/add the real full name to the hosts file.
• Optionally print a warning or note when names are truncated in the file, with an explanation about the NetBIOS limit.
• Consider a config option to prefer DNS names or augment NetBIOS results if available.

Environment

• NetExec version: 0.0.0 - Yippie-Ki-Yay - 182c898 - 1
• OS: EXEGOL
• Installed from: EXEGOL

Why this matters
Longer hostnames are common in some AD environments, and their truncation can lead to confusion, incorrect connectivity, or operational issues when importing the hosts file elsewhere.

Reference

• Microsoft NetBIOS specification: NetBIOS names are limited to 15 usable characters (16th byte is reserved for service type)

This issue was assisted by AI.

Thanks!

[NeffIsBack]

Thanks for the bug report, we will take a look into it!

On first thought we might be able to solve this by simply using self.conn.getServerDNSHostName() because this returns the full dns name of the client (which then can be split up to get the hostname). As far as i can tell this should always exist as per MS-NLMP sec. 2.2.2.1 (it is called MsvAvDnsComputerName in there).

However, maybe there are unintended side effects to this approach because maybe this value is missing in some scenarios => must be tested.

[mpgn]

Interesting problem ^^