01 / OBJECTIVE AND BOUNDARIES
Start with a question the evidence can answer.
I used a Kali Linux VM to examine a Windows 11 target from another host on the same private LAN. The goal was to compare network-visible exposure with host-side listeners, deliberately expose TCP 445 long enough to observe firewall behavior, and verify several SMB security settings.
The work was deliberately narrow. It was a controlled configuration lab, not an external penetration test or complete vulnerability assessment.
02 / ESTABLISHING THE TARGET
Confirm the starting point.
Before testing services, I confirmed that the selected address was responding from the Kali peer. Keeping the check focused on one target avoided publishing unrelated devices from the private network.
Four ICMP echo replies from 192.168.68.71 with 0% packet loss established that the Windows target was reachable from the Kali host at the start of the lab.
03 / REMOTE EXPOSURE VS. LOCAL LISTENERS
One host, two different views.
A remote scan and a local listener check answer different questions. I compared both views instead of treating either one as the entire picture.
A targeted TCP connect scan reported every selected port as filtered from the Kali peer’s vantage point. In Nmap, filtered means the scanner could not determine whether the ports were open or closed because a filter obstructed the probes.
Windows netstat -ano showed local TCP listeners on 135, 445, 5040, 7680, and high-numbered ports, together with their owning PIDs. Local listening state does not establish network reachability.
Core insightThe scanner saw the selected ports as filtered even though Windows showed services listening locally. A local listener and a network-reachable service are different facts, so both perspectives were needed.
Nmap defines filtered as a state where packet filtering prevents it from determining whether a port is open or closed. The retained evidence does not isolate every possible filtering layer, so this result is not attributed solely to Windows Firewall. See the Nmap port-state definitions (opens in a new tab).
04 / CONTROLLED TCP 445 FIREWALL EXPERIMENT
Change one condition, then observe the result.
To test reachability without leaving TCP 445 exposed, I created a time-bounded temporary inbound allow rule for that port, repeated the scan from the same peer, and deleted the named rule after the observation.
- 01Filtered
Selected ports were not classifiable from Kali.
- 02Allow rule
A temporary inbound rule was created for TCP 445.
- 03Open
The same-LAN scan reached TCP 445.
- 04Removed
Windows deleted the named temporary rule.
Windows accepted creation of the temporary inbound TCP 445 rule named Allow SMB Test.
After the temporary rule was created, a targeted scan from the same-LAN Kali host reported TCP 445 open. The microsoft-ds text is Nmap’s service label, not a version identification.
Windows reported deletion of one rule named Allow SMB Test after the controlled check.
05 / CORRELATING PORTS WITH PROCESSES
Connect the network result to the host—carefully.
I followed the network view with host-side PID mapping. This added context without overstating what a tentative service label or shared process name could prove.
A subsequent service/version scan reported 135, 139, 445, and 5040 filtered, with TCP 7680 open. The pando-pub? label is tentative and does not identify the underlying Windows service.
Get-Process resolved the PIDs captured by netstat to System, svchost, services, and prl_tools_service. This maps process owners, not the specific Windows services hosted inside each svchost process.
The comparison connected remote observations to process owners while preserving an important limit: a process name alone was not enough to identify every Windows service behind a shared host process. TCP 7680 is therefore not assigned to a specific Windows feature from these captures alone.
06 / APPLYING AND VERIFYING SMB CONTROLS
Separate the baseline, the change, and the final state.
The retained captures support three distinct findings. Keeping them separate prevents an existing baseline from being presented as a new remediation and keeps firewall behavior distinct from SMB protocol configuration.
CONTROL 01
SMBv1 was already disabled.
Before any disable action, Windows reported both SMBv1 optional features as disabled. This is a verified starting state, not a claim that the lab newly disabled the protocol.
Before any disable action, Windows reported SMB1Protocol and SMB1Protocol-Server as disabled. This verifies the existing baseline; it is not evidence that the lab newly remediated SMBv1.
CONTROL 02
SMB signing was explicitly required and verified.
PowerShell required signatures for the server and client configurations. Final queries show RequireSecuritySignature set to True for both. Because no retained baseline shows the previous values, the evidence supports the configured final state—not a claim that both values changed from false.
SMB signing provides message integrity and helps protect against tampering and relay attacks; it does not encrypt SMB traffic. See Microsoft’s SMB signing overview (opens in a new tab).
PowerShell explicitly required SMB signatures for the client configuration. The retained capture shows the command being accepted; the resulting value is verified separately.
Post-change queries show RequireSecuritySignature: True for both the server and client configurations and EnableSMB1Protocol: False on the server.
CONTROL 03
An inbound TCP 445 block rule was created.
The creation command and returned rule object show an enabled, inbound, persistent block rule intended for TCP 445 across all profiles. The claim is limited to TCP 445; the rule does not cover every SMB path, including TCP 139.
PowerShell created an enabled inbound block rule intended for TCP 445 across all profiles and placed it in the persistent policy store.
07 / VALIDATION, LIMITATIONS, AND LESSONS
End with what is known—and what still needs testing.
VERIFIED HOST-SIDE OUTCOMES
- SMBv1 optional features were disabled before hardening.
- The final server and client configurations required SMB signing.
- The persistent inbound block rule was created and returned as enabled with a Block action.
EVIDENCE LIMITATIONS
- The broad NSE run returned no target-specific finding while its selected ports were closed. That is not a clean bill of health.
- The final “host down” capture came from failed ARP discovery; it is not evidence of successful firewall hardening.
- No valid network-side post-hardening capture was retained.
- Results describe one target, one peer, one private network, and one point in time.
- The Windows version and edition were not captured clearly enough to infer whether signing values differed from system defaults.
The most important lesson was not that one scan made the host “secure.” It was that security conclusions must match the evidence: listener state, firewall configuration, and network reachability each answer a different question.
NEXT ITERATION
Close the remaining evidence gaps.
- Capture the exact Windows product, edition, version, and build.
- Query the effective firewall rule and its associated protocol and port filter.
- Record immediate scans before the rule, during the temporary allow, after deletion, and after the final block under unchanged conditions.
- Resolve shared svchost PIDs to the specific hosted Windows services.