Enumerate reachable endpoints from a Windows source

Needs: A permitted Windows shell, explicit target list and built-in networking support

Test one TCP port from the Windows source host

# Test one TCP port from the Windows source host
Test-NetConnection -ComputerName TARGET -Port PORTS

# Scan a low-port range
1..1024 | % {echo ((New-Object Net.Sockets.TcpClient).Connect("DC_IP", $_)) "TCP port $_ is open"} 2>$null

# Check a selected port list
22,80,443,445,3389 | % {echo ((New-Object Net.Sockets.TcpClient).Connect("TARGET", $_)) "TCP port $_ is open"} 2>$null

Read: TcpTestSucceeded, source and destination addresses. Use one number for PORTS. Failure does not distinguish a closed port, filtering or a path problem.

Verify → Associate each result with the actual Windows source and selected port; do not claim UDP or full-port coverage.

If it fails → A false result may be routing, filtering or service absence; use route and listener evidence before deciding the service is down. More detail ↓

If → then

A foothold exposes an interface/subnet or a loopback-only service → Discover pivot interfaces, routes and internal service context
Needs: A usable pivot process/identity and explicit scope; both forward and return directions must be understood
A WinRM listener and a candidate endpoint-authorized account → Use WinRM, WinRS or PowerShell remoting
Needs: Reachable HTTP(S) listener, accepted authentication and endpoint/session configuration permissions; hash/ticket support depends on client/context
Scanners disagree, a result is ambiguous, or a new identity changes accessible behavior → Validate uncertain results and rebuild the service queue
Needs: A selected endpoint and a test that can resolve the decision-changing uncertainty

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Enumerate reachable endpoints from a Windows source

USE WHEN: The useful vantage point is a Windows host without Nmap
STARTING ACCESS: An explicitly assigned address or host list and a known source position
RESULT: Selected TCP reachability from the Windows network position

Recognize the clue

From the Windows foothold inspect interfaces/routes, then check an assigned internal host's selected service ports.

Get-NetIPConfiguration
Get-NetRoute -AddressFamily IPv4
Test-NetConnection TARGET -Port 445

SYNTHETIC EXAMPLE OUTPUT

InterfaceAlias   : ADAPTER
SourceAddress    : SOURCE_IP
RemotePort       : 445
TcpTestSucceeded : True

Means: The service is reachable from this Windows source; this can reveal a useful vantage point unavailable from Kali.

Confirm: Confirm application/authentication and whether a forward or a native client can use that route.

After validation: A protocol request works from this source: choose an authorized service client or suitable tunnel.
Ruled out in this context: The selected service is conclusively closed from this source: choose another observed endpoint.
Still inconclusive: TcpTestSucceeded False with uncertain routing/firewall does not prove the host is down.

Troubleshooting: A false result may be routing, filtering or service absence; use route and listener evidence before deciding the service is down.

Additional prerequisite checks

Get-NetIPConfiguration
Get-NetRoute -AddressFamily IPv4
Test-NetConnection TARGET -Port PORT

Purpose: Test TCP reachability from a Windows host when source position or available tooling matters.

Test one TCP port from the Windows source host:

Read: TcpTestSucceeded, source and destination addresses. Use one number for PORTS. Failure does not distinguish a closed port, filtering or a path problem.

Variants — scan ports 1-1024 or a selected port list

Scan a low-port range

Check a selected port list

The example list can be changed to the endpoints of interest.

$_ is the current port; errors are hidden. No printed result does not prove every port is closed. Results reflect the Windows host's access and the stated port selection.

Why it works

A local TcpClient or Test-NetConnection uses the host's route and firewall context. Results from Kali do not substitute for reachability from this source.

Worked example · hypothetical

Observation: Kali cannot reach an internal WinRM endpoint. Test: check TCP/5985 from the Windows foothold. Illustrative output: TcpTestSucceeded is True. Interpretation: a new route/source exists; choose a forward or run an authorized native client there.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗