Lab 08 SMB & Windows Network Service Assessment

Mission Overview

Welcome to Lab 08 — SMB & Windows Network Service Assessment.

In the previous labs, you discovered the Windows target, identified its exposed network services, enumerated authentication requirements, and assessed remote-access controls.

Now you will focus specifically on the Windows network service attack surface, with particular attention to SMB.

SMB is fundamental to many enterprise Windows environments. It can support:

• file sharing

• printer sharing

• administrative access

• domain operations

• application workflows

• remote management

• inter-server communication

Because SMB often exposes valuable organizational resources, a professional network pentester must understand more than whether:

445/tcp

is open.

You need to determine:

• whether SMB should be reachable from your assessment segment

• which SMB protocol behavior is exposed

• whether authentication is required

• whether guest or anonymous access exists

• which shares are visible

• what permissions approved users have

• whether administrative shares are exposed appropriately

• whether SMB signing is configured

• whether legacy protocols appear to be enabled

• whether share permissions align with least privilege

• whether the exposure creates a genuine security finding

Mission Goal: Assess an authorized Windows host’s SMB and related network services, validate authentication and share permissions using supplied lab accounts, document SMB protocol security controls, and produce evidence-based Windows network security findings.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Skill	SMB Security Assessment
Secondary Skill	Windows Network Service Analysis
Environment	GoHackersCloud Network Pentesting Lab
Primary Target	Authorized Windows training host
Typical SMB Port	445/tcp
Credentials	Supplied training accounts only
Primary Outcome	Windows SMB Security Register
Safety Level	Authorized Lab Systems Only

Learning Objectives

By completing this lab, you will be able to:

• identify Windows SMB exposure

• understand SMB’s role in enterprise Windows networks

• distinguish SMB from NetBIOS

• identify Windows host and service information

• assess SMB authentication requirements

• enumerate shares where authorized

• assess guest and anonymous access

• use supplied test credentials safely

• evaluate share permissions

• understand administrative shares

• assess SMB signing

• recognize legacy SMB protocol exposure

• distinguish share visibility from share access

• distinguish read access from write access

• evaluate least-privilege controls

• identify unnecessary Windows network exposure

• create evidence-based Windows service findings

• define remediation and retest criteria

SMB Assessment Methodology

Use:

Windows Host → SMB Exposure → Protocol → Authentication → Shares → Permissions → Signing → Network Context → Evidence → Finding

Conceptually:

Windows Host
     │
     ▼
SMB Reachable?
     │
     ▼
Protocol Information
     │
     ▼
Authentication
     │
     ├── Required
     ├── Guest
     └── Anonymous
     │
     ▼
Share Visibility
     │
     ▼
Share Permissions
     │
     ├── No Access
     ├── Read
     └── Write
     │
     ▼
SMB Security Controls
     │
     ├── Signing
     ├── Protocol Version
     └── Network Restriction
     │
     ▼
Evidence
     │
     ▼
Finding

The central principle is:

An SMB share is not automatically a vulnerability. The security question is who can access it, from where, and with what permissions.

Part 1 — Revalidate Scope

Confirm your Windows training target.

Example:

Authorized Network:
192.168.56.0/24

Windows Target:
192.168.56.30

Expected Services:
135/tcp
445/tcp
3389/tcp
137/udp
138/udp

Record:

Target:

Hostname:

Authorized IP:

SMB Testing Authorized:
Yes / No

Share Enumeration Authorized:
Yes / No

Supplied Credentials Available:
Yes / No

Guest Access Testing:
Only if specifically configured in lab

Write Testing:
Only against designated training share

Assessment Date:

Investigator:

Part 2 — Create the Workspace

Create:

Network-Pentesting-Labs/
└── Lab-08/
    ├── Scope/
    ├── Notes/
    ├── SMB/
    │   ├── Discovery/
    │   ├── Protocol/
    │   ├── Authentication/
    │   ├── Shares/
    │   ├── Permissions/
    │   └── Signing/
    ├── Windows-Services/
    ├── Evidence/
    ├── Screenshots/
    ├── Findings/
    └── Report/

Create:

Lab-08-SMB-Windows-Network-Assessment.md

Suggested structure:

# Lab 08 — SMB & Windows Network Service Assessment

## Mission Objective

## Authorization

## Windows Target Profile

## SMB Reachability

## Protocol Information

## Authentication

## Share Enumeration

## Share Permissions

## Guest / Anonymous Access

## Administrative Shares

## SMB Signing

## Legacy Protocol Assessment

## Windows Network Services

## Network Exposure

## Findings

## Recommendations

## Retest Criteria

## Limitations

## Conclusion

Part 3 — Review the Windows Service Baseline

Bring forward the findings from Labs 03–07.

Example:

Port	Service	State	Previous Assessment
135/tcp	RPC	Open	Windows service
139/tcp	NetBIOS/SMB	Open/Closed	Review
445/tcp	SMB	Open	High priority
3389/tcp	RDP	Open	Remote administration
137/udp	NetBIOS Name	Open/Unknown	Review
138/udp	NetBIOS Datagram	Open/Unknown	Review

This becomes your Windows network baseline.

Part 4 — Understand SMB

SMB stands for:

Server Message Block

SMB enables Windows systems to communicate with shared resources.

Examples:

Client
   │
   │ SMB
   ▼
Windows Server
   │
   ├── Shared Folder
   ├── Printer
   ├── Application Data
   └── Administrative Resource

SMB is normal in enterprise networks.

The security problem is not:

SMB exists

The real questions are:

Who can reach it?

Who can authenticate?

What can they enumerate?

What can they read?

What can they modify?

Should they have that access?

Part 5 — Understand SMB Ports

Modern SMB commonly uses:

445/tcp

Older Windows networking may also involve:

137/udp
138/udp
139/tcp

These ports are associated with NetBIOS-based communication.

A modern network may use SMB directly over TCP 445 without relying heavily on NetBIOS.

Part 6 — Verify SMB Reachability

Begin with the existing port evidence.

You may confirm:

nmap -p 445 192.168.56.30

Save:

nmap -p 445 192.168.56.30 \
-oN SMB/Discovery/smb-reachability.txt

Record:

Target:

Port:
445/tcp

State:

Reachable From:

Expected:
Yes / No

Evidence:

Part 7 — Identify the Service

Use service identification:

nmap -sV -p 445 192.168.56.30

Record:

Host:

Port:

Service:

Product Information:

Hostname Information:

Domain/Workgroup Information:

Confidence:

Do not assume the scanner identifies every detail correctly.

Part 8 — Understand SMB Protocol Generations

Broadly, you may encounter:

SMBv1

SMBv2

SMBv3

SMBv1 is a legacy protocol and has significantly weaker security characteristics than modern SMB versions.

Modern Windows environments should generally prefer supported SMBv2/SMBv3 implementations.

Part 9 — Assess SMB Protocol Support

Your approved assessment tooling may identify supported SMB dialects.

Record:

Protocol	Supported	Security Status
SMBv1		Review
SMBv2
SMBv3

If SMBv1 appears enabled:

Do not immediately attempt exploitation.

First establish that legacy protocol support actually exists.

Part 10 — Understand Why SMBv1 Matters

Legacy SMBv1 lacks a number of security improvements found in later protocol generations.

Its presence may:

• increase legacy attack surface

• weaken protocol security

• violate organizational baselines

• create compatibility-driven security debt

The finding is:

Legacy SMBv1 protocol support is enabled.

Not:

“The host can definitely be compromised.”

Part 11 — Build the SMB Protocol Profile

SMB PROTOCOL PROFILE

Host:

IP:

445/tcp:
Open / Closed / Filtered

139/tcp:

SMBv1:

SMBv2:

SMBv3:

Preferred Dialect:

Legacy Protocol Present:

Assessment:

Evidence:

Part 12 — Understand SMB Authentication

SMB access may involve:

Authenticated User

Guest User

Anonymous / Null Session

Machine Account

Administrative Account

For this lab, use only:

supplied lab identities

unless guest/anonymous behavior is explicitly part of the training scenario.

Part 13 — Create the Test Account Register

Example:

Account	Intended Role	Expected Access
lab-user	Standard User	Department share
lab-admin	Administrator	Administrative resources
Guest	Lab scenario only	Limited/none

Do not record passwords.

Part 14 — Attempt Share Listing with a Supplied Account

Where a supplied account is provided, an SMB client may be used.

Example:

smbclient -L //192.168.56.30 -U lab-user

The client prompts for the supplied training password.

Record:

Account:

Authentication Successful:

Shares Visible:

Access Level:
Unknown until tested

Evidence:

Part 15 — Understand Share Enumeration

Share enumeration answers:

Which SMB resources are advertised to this identity?

It does not prove:

the user can read everything

or:

the user can modify everything

These are separate permission questions.

Part 16 — Build the Share Inventory

Use:

Share	Type	Visible to User	Expected
Public	Disk	Yes	Yes
Finance	Disk	Yes/No	Role dependent
IPC$	IPC	Yes	Normal
ADMIN$	Admin		Restricted
C$	Admin		Restricted

Actual lab shares will vary.

Part 17 — Understand Administrative Shares

Windows commonly creates administrative shares such as:

ADMIN$

C$

IPC$

Their existence alone is not necessarily a security finding.

The important questions are:

Can an unprivileged user access them?

Are they reachable from inappropriate network segments?

Is authentication required?

Are permissions enforced correctly?

Part 18 — Assess Standard User Share Access

For a designated training share:

smbclient //192.168.56.30/Public -U lab-user

Use only the supplied training account.

Inside the approved share, perform read-only enumeration first.

For example, list directory contents.

Your objective is to determine:

Can the user access the share?

Which folders are visible?

Is read access expected?

Do not explore unrelated or sensitive data.

Part 19 — Build the Share Permission Matrix

Create:

Share	Identity	Enumerate	Read	Write	Expected
Public	lab-user	Yes	Yes	No	Yes
Finance	lab-user	No	No	No	Yes
Admin	lab-user	No	No	No	Yes

Part 20 — Distinguish Share Permissions

No Access

User cannot access the resource.

Enumerate

User can see the share exists.

Read

User can view approved contents.

Write

User can create or modify content.

Full Control

User has extensive control over the resource.

These permission levels carry very different security implications.

Part 21 — Test Write Permission Only on the Designated Training Share

If the lab explicitly provides a writable test directory, you may validate write access using a harmless test file.

For example, create locally:

ghc-lab-write-test.txt

containing:

GoHackersCloud authorized SMB write test.

Upload it only to the designated lab share.

Then remove the test file after validation if the exercise requires cleanup.

Document:

Share:

Authorized Write Test:
Yes

Test File:

Upload:
Successful / Failed

Cleanup:
Completed / Not Required

Do not upload executables, scripts, payloads, or sensitive data.

Part 22 — Understand Why Write Access Matters

Write access can be significantly more security-sensitive than read access because it may permit:

• data modification

• file replacement

• business process interference

• unauthorized content introduction

But context still matters.

Write access to:

a designated collaboration share

may be entirely legitimate.

Part 23 — Assess Least Privilege

For each share ask:

Does this identity need this level of access?

Example:

Marketing User
      ↓
Marketing Share
      ↓
Read/Write

may be expected.

But:

Marketing User
      ↓
Finance Share
      ↓
Read

may indicate excessive access.

Part 24 — Build the Least-Privilege Matrix

Identity	Share	Expected Permission	Observed Permission	Status
lab-user	Public	Read	Read	Pass
lab-user	Finance	None	Read	Review
lab-admin	Admin	Admin	Admin	Pass

Part 25 — Assess Guest Access

Only if intentionally configured in the lab, determine whether SMB permits guest access.

Document:

Guest Access Available:
Yes / No

Authentication Required:

Shares Visible:

Resources Accessible:

Permission:
None / Read / Write

Expected:
Yes / No

Do not probe beyond the designated training share.

Part 26 — Assess Anonymous Access Carefully

Anonymous SMB access is different from authenticated guest access.

If the lab explicitly includes anonymous enumeration, determine only the approved scope of visibility.

Do not use anonymous access to explore unrelated resources.

Part 27 — Build the Anonymous/Guest Register

Access Type	Shares Visible	Read	Write	Expected
Anonymous
Guest
Authenticated User

Part 28 — Understand Null Sessions Conceptually

Historically, some Windows/SMB environments permitted limited unauthenticated connections sometimes referred to as:

null sessions

These could expose information without authenticated identity.

In this lab, focus on whether unauthorized information access exists.

Do not perform broad account, group, or domain harvesting.

Part 29 — Assess SMB Signing

SMB signing helps provide integrity protection for SMB messages.

Conceptually:

SMB Message
     +
Integrity Protection
     ↓
Signed SMB Communication

Signing may be:

Required

Supported but Not Required

Unavailable / Legacy

Unknown

Part 30 — Why SMB Signing Matters

If signing is required, the service demands integrity-protected SMB communication.

If signing is merely supported but optional, security may depend on client/server negotiation and environmental controls.

Record:

SMB Signing:

Required:
Yes / No / Unknown

Supported:
Yes / No / Unknown

Assessment:

Evidence:

Part 31 — Do Not Convert Signing Results Directly into Exploitation

The finding should describe the control.

Example:

SMB signing is supported but not required on the assessed host.

Then evaluate:

• network trust

• segmentation

• organizational policy

• endpoint protections

• applicable threat model

Do not perform relay-style activity in this lab.

Part 32 — Build the SMB Signing Register

Host	Signing Supported	Signing Required	Expected	Status
Windows Target

Part 33 — Identify Host Information Disclosure

SMB and related Windows services may reveal:

• hostname

• workgroup/domain

• operating system hints

• share names

• server role

• service configuration

Build:

Information	Source	Auth Required	Security Relevance
Hostname	SMB
Domain	SMB
Share names	SMB

Part 34 — Separate Host Information from Sensitive Data

A hostname such as:

FILESERVER01

is not equivalent to exposing:

financial records

Severity depends on sensitivity and usefulness.

Part 35 — Assess Share Naming

Share names may reveal business structure.

Examples:

Finance

HR

Backups

Engineering

Software

Projects

An attacker could use such names to prioritize further activity.

But the impact depends on:

visibility
+
access
+
data sensitivity

Part 36 — Assess Sensitive Share Exposure

If a share with a sensitive-looking name is visible to the supplied test user, do not automatically access its contents.

First ask:

Should this user even see or access this share?

Where permission validation is required, use only the minimum access necessary.

Part 37 — Build the Sensitive Share Register

Share	Visible	Access	Expected	Classification
Finance	Yes	None	Hidden/Restricted	Observation
Backups	Yes	Read	No	Potential Finding

Part 38 — Assess Share Read Permissions

If an authorized test share allows reading, verify using a harmless designated file whenever possible.

Record:

Share:

File:
Training File

Read:
Allowed / Denied

Expected:
Allowed / Denied

Assessment:

Avoid downloading bulk content.

Part 39 — Assess Share Write Permissions

Write access should receive separate attention.

Ask:

Is write permission required?

Which identities have it?

Which directories are writable?

Could sensitive workflows depend on those files?

Do not test file execution or payload delivery.

Part 40 — Understand NTFS and Share Permissions

Windows access may be influenced by both:

Share Permissions
        +
NTFS Permissions
        ↓
Effective Access

The effective permission experienced by a user may therefore differ from one permission layer viewed in isolation.

Part 41 — Build the Effective Access Register

Identity	Share	Share Permission	NTFS Context	Effective Access
lab-user	Public	Read	Read	Read
lab-user	Projects	Change	Read	Read

Where direct configuration evidence is unavailable, record only observed effective access.

Part 42 — Avoid Assuming Why Access Was Denied

If a user receives:

Access Denied

possible causes include:

• share permissions

• NTFS permissions

• authentication

• policy

• account restrictions

Report:

Access was denied to the supplied test identity.

Do not claim which exact control caused it unless verified.

Part 43 — Assess Administrative Share Access

With a standard lab user, verify that administrative shares remain restricted.

Do not attempt privilege escalation.

Expected:

Standard User
     ↓
C$
     ↓
Access Denied

That is a positive control.

Part 44 — Assess Administrative Account Access Only Where Required

If a supplied administrative training identity exists, you may confirm expected access according to the lab scenario.

Do not use administrative access to modify the host unnecessarily.

Record:

Account Role:

Administrative Share:

Expected Access:

Observed Access:

Status:

Part 45 — Assess Windows RPC Exposure

Windows often exposes RPC functionality through port:

135/tcp

For this lab, identify:

• whether it is reachable

• whether exposure is expected

• whether it should be restricted to internal/management networks

Avoid broad RPC enumeration beyond the course objective.

Part 46 — Build the Windows Service Matrix

Port	Service	Reachable	Expected	Security Context
135	RPC			Windows service
139	NetBIOS			Legacy context
445	SMB			File/network service
3389	RDP			Remote administration

Part 47 — Evaluate Network Exposure

Ask:

Should ordinary workstations reach SMB?

Should guest networks reach SMB?

Should management systems reach SMB?

Should external networks reach SMB?

The answer depends on architecture.

Part 48 — Build the SMB Exposure Matrix

Source Segment	SMB Reachable	Expected
User Network
Server Network
Management
Guest
External

Your isolated lab may simulate only a subset.

Part 49 — Identify Broad SMB Exposure

Suppose file servers should only serve internal corporate endpoints, but SMB is reachable from a simulated guest segment.

That can become a segmentation finding.

You do not need to compromise SMB to prove:

The guest segment has network access to the SMB authentication surface.

Part 50 — Assess Firewall Controls

Possible protections include:

Windows Defender Firewall

Network Firewall

ACL

VLAN Segmentation

Host-Based Policy

Record:

Control	Present	Effect
Windows Firewall
Network ACL
Segment restriction

Part 51 — Identify Positive Controls

Examples:

SMB requires authentication.

Guest access is disabled.

Standard users cannot access administrative shares.

Sensitive shares are role restricted.

SMB signing is required.

SMBv1 is disabled.

SMB is reachable only from approved internal networks.

Document successful controls.

Part 52 — Build the SMB Security Control Matrix

Control	Status	Evidence
Authentication required
Guest restricted
Anonymous restricted
Least privilege
Administrative shares restricted
SMB signing
SMBv1 disabled
Network restriction
Logging

Part 53 — Assess SMB Logging

If the lab gives you access to defensive logs, determine whether SMB authentication and share access generate useful records.

Look conceptually for:

Identity

Source Address

Timestamp

Authentication Result

Resource Access

Do not generate unnecessary failures simply for log volume.

Part 54 — Build the Logging Register

Event	Logged	Identity	Source	Timestamp
Successful SMB login
Share access
Access denied

Part 55 — Classify SMB Findings

Use:

Positive Control

Security behaves as intended.

Observation

Security-relevant information is exposed.

Potential Weakness

Condition appears concerning but needs context.

Validated Finding

Evidence confirms a meaningful security weakness.

Inconclusive

Insufficient evidence.

Part 56 — Example Finding — Excessive Share Permission

Finding ID:
SMB-01

Title:
Standard User Has Unnecessary Read Access to Restricted Share

Asset:
192.168.56.30

Share:
Finance

Identity:
lab-user

Expected Permission:
No Access

Observed Permission:
Read

Severity:
Medium

Confidence:
High

Description:
The supplied standard-user account was able to access the
designated Finance training share despite the role definition
indicating that the account should not have Finance access.

Impact:
Users outside the intended business role may be able to access
information stored within the restricted share.

Recommendation:
Review SMB and NTFS permissions and restrict the share to approved
Finance identities or security groups.

Retest:
Authenticate using the same standard test account and confirm that
access to the Finance share is denied.

Part 57 — Example Finding — Anonymous Share Access

Only where intentionally configured:

Finding ID:
SMB-02

Title:
SMB Share Accessible Without Authenticated Identity

Asset:
192.168.56.30

Share:
Public-Lab

Evidence:
The designated training share could be enumerated and accessed
without supplying an authenticated user identity.

Impact:
Network users who can reach the SMB service may access information
within the share without individual accountability.

Recommendation:
Require authenticated access unless anonymous sharing is a
documented business requirement.

Retest:
Confirm anonymous clients can no longer access the share.

Part 58 — Example Finding — SMBv1 Enabled

Finding ID:
SMB-03

Title:
Legacy SMBv1 Protocol Enabled

Asset:
192.168.56.30

Confidence:
High

Description:
Protocol assessment confirmed that the Windows SMB service
supports the legacy SMBv1 protocol.

Impact:
Legacy SMB protocols increase the system's network attack surface
and lack security improvements available in supported SMBv2/SMBv3
implementations.

Recommendation:
Disable SMBv1 where no documented application dependency exists
and migrate legacy workloads to supported SMB versions.

Retest:
Confirm the host no longer negotiates SMBv1 while required SMBv2
or SMBv3 functionality remains operational.

Part 59 — Example Finding — SMB Signing

Where applicable:

Finding ID:
SMB-04

Title:
SMB Signing Not Required

Asset:
192.168.56.30

Description:
The SMB service supports signing but does not require clients to
use signed SMB communications.

Security Context:
Whether this represents a significant weakness depends on network
trust boundaries, organizational policy, and compensating controls.

Recommendation:
Evaluate requiring SMB signing on systems where integrity
protection is required by the organization's Windows security
baseline.

Part 60 — Example Positive Control

Control:
Administrative Share Restrictions

Observation:
The supplied standard user could authenticate to SMB but was
denied access to administrative shares.

Assessment:
Least-privilege control operating as expected.

Part 61 — Build the Findings Register

ID	Asset	Condition	Severity	Confidence
SMB-01	Windows	Excessive share permission	Medium	High
SMB-02	Windows	Anonymous access	Medium	High
SMB-03	Windows	SMBv1 enabled	Medium/Policy-based	High
SMB-04	Windows	Signing not required	Context-based	High

Populate only findings actually validated in your lab.

Part 62 — Build the Windows Attack-Surface Profile

WINDOWS NETWORK PROFILE

Host:

IP:

Hostname:

Domain/Workgroup:

135/tcp RPC:

139/tcp NetBIOS:

445/tcp SMB:

3389/tcp RDP:

SMB Protocols:

Authentication Required:

Guest Access:

Anonymous Access:

Visible Shares:

Administrative Shares:

SMB Signing:

Standard User Access:

Administrative Access:

Network Restrictions:

Logging:

Highest-Priority Observation:

Part 63 — Build the Evidence Chain

A strong SMB finding should follow:

SMB Reachability
      ↓
Protocol Identified
      ↓
Authentication Context
      ↓
Share / Control Identified
      ↓
Approved Permission Test
      ↓
Expected vs Observed
      ↓
Evidence
      ↓
Finding

Avoid:

445 Open
   ↓
Windows Vulnerable

Part 64 — Mission Challenge

Complete:

LAB INFORMATION

Lab:
SMB & Windows Network Service Assessment

Authorized Network:

Windows Host:

IP:

Assessment Date:

Investigator:


WINDOWS NETWORK SERVICES

135/tcp:

139/tcp:

445/tcp:

3389/tcp:

137/udp:

138/udp:


SMB PROTOCOL

SMB Reachable:
Yes / No

SMBv1:
Enabled / Disabled / Unknown

SMBv2:
Enabled / Disabled / Unknown

SMBv3:
Enabled / Disabled / Unknown

Legacy Protocol Present:
Yes / No / Unknown


SMB AUTHENTICATION

Authentication Required:
Yes / No

Supplied Account Used:
Yes / No

Authentication Successful:
Yes / No

Guest Access:
Yes / No / Not Tested

Anonymous Access:
Yes / No / Not Tested


SHARES

Visible Shares:

Expected Shares:

Unexpected Shares:

Administrative Shares Visible:

Administrative Shares Accessible by Standard User:
Yes / No


STANDARD USER

Account:

Expected Role:

Public Share:

Restricted Share:

Read Access:

Write Access:

Administrative Share Access:


LEAST PRIVILEGE

Expected Permissions:

Observed Permissions:

Excess Access:
Yes / No

Finding Required:
Yes / No


SMB SIGNING

Supported:
Yes / No / Unknown

Required:
Yes / No / Unknown

Policy Expectation:

Assessment:


WINDOWS NETWORK EXPOSURE

SMB Reachable from Expected Segment:
Yes / No

SMB Reachable from Unexpected Segment:
Yes / No

Firewall Restrictions:

Segmentation Controls:


LOGGING

Successful SMB Login Logged:

Share Access Logged:

Denied Access Logged:

Source IP Recorded:


FINAL ANALYSIS

Highest-Risk Share:

Most Significant Permission Issue:

Anonymous Access Present:

Legacy SMB Present:

SMB Signing Concern:

Administrative Shares Properly Restricted:

Network Exposure Appropriate:

Positive Controls:

Validated Findings:

Inconclusive Items:

Ready for Linux Network Service Assessment:
Yes / No

Part 65 — What Not to Do

Do not:

Scan Windows systems outside scope

Guess SMB passwords

Password spray accounts

Brute-force credentials

Perform credential stuffing

Use leaked credentials

Harvest unrelated usernames

Perform broad domain enumeration

Attempt authentication relay

Capture authentication material

Attempt credential cracking

Exploit SMB vulnerabilities

Execute remote commands

Use administrative shares for code execution

Upload executables

Upload payloads

Create persistence

Modify production-like data

Delete user files

Download bulk sensitive data

Access unrelated shares

Disable SMB signing

Enable legacy protocols

Change Windows firewall settings

Expose SMB to the Internet

The professional rule is:

Assess the access control around SMB without turning a permission review into an unnecessary compromise attempt.

Troubleshooting

Port 445 Is Open but Share Listing Fails

Possible reasons include:

• authentication required

• incorrect supplied account

• SMB client compatibility

• network policy

• account restriction

Record the result rather than guessing additional credentials.

User Authenticates but Cannot Access a Share

This may be correct least-privilege behavior.

Document:

Authentication:
Successful

Share Access:
Denied

Assessment:
Access control operating as expected / Requires policy comparison

Share Is Visible but Cannot Be Opened

Visibility and access are separate permissions.

Record both.

Write Attempt Fails

If write access was expected, review:

• effective permissions

• designated directory

• test account role

Do not attempt to bypass the restriction.

Administrative Share Access Is Denied

For a standard user, this is generally a positive result.

SMB Protocol Version Is Unclear

Record:

Protocol Version:
Inconclusive

rather than making assumptions.

SMB Signing Status Is Unclear

Classify:

Signing:
Requires configuration validation

and recommend an authorized host-side review.

Evidence Requirements

Capture:

Evidence 01

Scope confirmation.

Evidence 02

Windows Service Baseline.

Evidence 03

SMB reachability.

Evidence 04

SMB service identification.

Evidence 05

SMB Protocol Profile.

Evidence 06

Test Account Register.

Evidence 07

Authenticated share listing.

Evidence 08

Share Inventory.

Evidence 09

Share Permission Matrix.

Evidence 10

Authorized read-access validation.

Evidence 11

Authorized write-access validation where configured.

Evidence 12

Least-Privilege Matrix.

Evidence 13

Anonymous/Guest Register.

Evidence 14

Administrative-share assessment.

Evidence 15

SMB Signing Register.

Evidence 16

Information Exposure Register.

Evidence 17

Effective Access Register.

Evidence 18

Windows Service Matrix.

Evidence 19

SMB Exposure Matrix.

Evidence 20

SMB Security Control Matrix.

Evidence 21

Logging Register.

Evidence 22

Validated Findings Register.

Evidence 23

Windows Attack-Surface Profile.

Evidence 24

Mission Challenge worksheet.

Mission Deliverables

Complete:

• scope revalidated

• Windows services inventoried

• SMB reachability confirmed

• SMB protocol versions assessed

• legacy SMB exposure documented

• authentication requirement assessed

• supplied test account used safely

• share inventory created

• standard-user access assessed

• read permissions validated

• write permissions tested only where explicitly authorized

• guest access assessed where configured

• anonymous access assessed where configured

• administrative shares reviewed

• standard-user restrictions verified

• SMB signing assessed

• least privilege evaluated

• effective permissions documented

• Windows network exposure assessed

• firewall/segmentation controls documented

• SMB logging reviewed where available

• positive controls documented

• validated findings written

• remediation recommendations prepared

• retest criteria defined

• final Windows Attack-Surface Profile completed

• final report completed

Lab Report Template

# Lab 08 — SMB & Windows Network Service Assessment

## Executive Summary

## Mission Objective

## Authorization and Scope

## Windows Target Profile

## Windows Network Service Inventory

## SMB Assessment Methodology

## SMB Reachability

## SMB Protocol Assessment

### SMBv1
### SMBv2
### SMBv3

## Authentication Assessment

## Test Identity Register

## Share Enumeration

## Share Permission Assessment

## Guest and Anonymous Access

## Administrative Shares

## Least Privilege Assessment

## SMB Signing

## Information Exposure

## Effective Permissions

## Windows RPC and Related Services

## Network Exposure and Segmentation

## Logging and Auditability

## Positive Security Controls

## Validated Findings

### SMB-01
### SMB-02
### SMB-03

## Potential Weaknesses

## Inconclusive Items

## Recommendations

## Retest Criteria

## Limitations

## Conclusion

Knowledge Check

Question 1 — What is SMB primarily used for?

SMB supports Windows network resource sharing such as files, printers, and administrative resources.

Question 2 — Is TCP port 445 being open automatically a vulnerability?

No.

It indicates SMB or related functionality is exposed and requires security assessment.

Question 3 — What is the difference between share visibility and share access?

A user may be able to see that a share exists without having permission to read or modify its contents.

Question 4 — Why is write access more security-sensitive than read access?

Because write access may allow data modification or introduction of unauthorized content.

Question 5 — Should you attempt password attacks against SMB during this lab?

No.

Use only supplied training identities.

Question 6 — Is C$ existing automatically a vulnerability?

No.

Administrative shares are normal Windows functionality. The key issue is whether access is properly restricted.

Question 7 — Why is SMBv1 a security concern?

It is a legacy SMB protocol lacking many security improvements available in modern SMB implementations.

Question 8 — What does SMB signing provide?

Integrity protection for SMB communication.

Question 9 — Should an ordinary user normally access administrative shares?

Typically no, unless there is a specifically authorized administrative role.

Question 10 — What is the central question of SMB assessment?

Who can reach SMB, who can authenticate, what resources can they access, and are those permissions consistent with business need and least privilege?

Skills Achieved

After completing this lab, you should understand:

• SMB fundamentals

• Windows network-service exposure

• SMB protocol versions

• SMBv1 security context

• SMB authentication

• authenticated share enumeration

• guest and anonymous access

• administrative shares

• share permissions

• read vs write access

• effective access

• NTFS/share-permission interaction

• least privilege

• SMB signing

• Windows network exposure

• management and segmentation controls

• SMB logging

• evidence-based Windows findings

• remediation and retesting

Professional Takeaway

A weak SMB assessment looks like:

445 Open
   ↓
SMB Found
   ↓
Call It Vulnerable

A professional SMB assessment looks like:

Windows Host
     ↓
SMB Reachability
     ↓
Protocol Version
     ↓
Authentication
     ↓
Share Enumeration
     ↓
Permission Validation
     ↓
Administrative Restrictions
     ↓
SMB Signing
     ↓
Network Segmentation
     ↓
Logging
     ↓
Evidence-Based Finding

Always distinguish:

445 Open
   ≠
SMB Vulnerable

Share Visible
   ≠
Share Accessible

Read Access
   ≠
Write Access

Administrative Share Exists
   ≠
Administrative Access Available

SMB Signing Supported
   ≠
SMB Signing Required

SMBv1 Enabled
   ≠
Host Compromised

Authentication Successful
   ≠
Excessive Permission

By the end of this lab, you should be able to answer:

“Are Windows file-sharing and related network services exposed only where required, protected by appropriate authentication and protocol controls, and configured with permissions consistent with least privilege?”

What’s Next?

➡️ Lab 09 — Linux Network Service Assessment

In the next lab, you will apply the same disciplined approach to Linux network services.

You will assess:

• SSH

• HTTP/HTTPS

• FTP where present

• NFS

• RPC

• database listeners

• Linux service bindings

• authentication requirements

• plaintext services

• service accounts

• file exports

• remote management exposure

• local-vs-remote service visibility

• expected vs unexpected services

• least-privilege exposure

The methodology becomes:

Linux Host → Service Exposure → Authentication → Configuration → Resource Access → Network Context → Evidence → Finding

The central question will be:

“Are Linux network services exposed only where needed, protected by appropriate authentication and transport controls, and configured consistently with least privilege?”