RDP and SMB: two Windows services worth defending

Overview

Security objective. The asset you are protecting is a Windows host's file shares (data on SMB) and its interactive login (remote control via RDP). The threats are unauthorized data access and remote takeover — the two most common ways ransomware and lateral movement start on Windows networks. By the end you will be able to detect an exposed or misconfigured service and prevent the abuse by hardening the service and turning on the right logs.

Windows machines talk to each other constantly, and two protocols carry most of that traffic:

• SMB (Server Message Block), TCP port 445 — file and printer sharing, plus general host-to-host communication. It exposes shares (folders offered over the network) and performs authentication with NTLM or Kerberos.
• RDP (Remote Desktop Protocol), TCP port 3389 — a full graphical, interactive session on a remote machine, as if you were sitting at its keyboard.

This lesson builds directly on your prerequisites. From "Windows users, groups, and SIDs" you already know that every share permission and every RDP login is checked against a user's account and group membership — so a weak account is a weak service. From "TCP vs UDP, ports, and the ones to know" you know that 445 and 3389 are TCP ports a scanner can spot in seconds; seeing them open is your first signal that these services exist and need review.

We treat both protocols as things you defend. You will learn what an attacker looks for only so you can find it first, shut it down, and prove it stayed shut.

Why it matters

In authorized, professional work these two ports shape almost every internal Windows assessment and every Windows hardening project:

• SMB shares leak data and credentials. On real internal networks, readable shares routinely contain password spreadsheets, scripts with hard-coded credentials, backups, and config files. A defender who enumerates shares the way an attacker would can find and lock down that exposure before it is abused.
• SMB authentication underpins relay and pass-the-hash. NTLM relay and pass-the-hash attacks abuse how SMB authenticates. Requiring SMB signing and disabling NTLM where possible directly defeats them — but only if you can verify the setting is on.
• RDP is a leading external entry point. Ransomware crews routinely buy or brute-force exposed RDP. "Is 3389 reachable from the internet?" is one of the highest-value questions in any external review.
• Patch and configuration gaps are findable. SMBv1 (EternalBlue, MS17-010) and unpatched RDP (BlueKeep, CVE-2019-0708) are old but still appear on forgotten hosts. Spotting them is a concrete, reportable win.

Blue-team and IT roles use exactly the same knowledge in reverse: to build secure defaults, monitor for abuse, and answer auditors. Knowing both sides makes you effective at either.

Core concepts

Each concept below is taught the same way: what it is, how it works, when it matters, and the pitfall that trips people up.

1. SMB and shares (TCP 445)

Definition. SMB is the Windows protocol for sharing files, printers, and named pipes, and for host-to-host communication. A share is a folder (or device) a host offers over the network, e.g. \\SERVER\Finance.

How it works. A client connects to port 445, authenticates (NTLM or Kerberos), and is granted access based on two layers: share permissions and underlying NTFS file permissions. Effective access is the more restrictive of the two.

When it matters. Every internal Windows environment uses SMB. The security question is always: which shares exist, who can read them, and what sensitive data is inside?

Pitfall. Admins often set share permissions to "Everyone: Full Control" and rely on NTFS to restrict access — then misconfigure NTFS. The result is a wide-open share. Always check both layers.

2. SMBv1 and EternalBlue

Definition. SMBv1 is the original, obsolete dialect of SMB. EternalBlue (MS17-010) is a remote-code-execution flaw in SMBv1.

How it works. SMBv1 has no modern integrity protection and a memory-handling bug that allowed remote code execution — the mechanism behind the 2017 WannaCry and NotPetya outbreaks.

When (and when not). SMBv1 should be disabled everywhere. There is essentially no modern reason to keep it; the only exception is a decommissioned legacy device you cannot replace, which should be isolated on its own network segment.

Pitfall. SMBv1 is sometimes silently re-enabled by old software installers or left on in a golden image. Finding it enabled is a real, reportable finding.

3. SMB authentication, signing, NTLM relay, and pass-the-hash

Definition. SMB signing cryptographically signs each message so it cannot be tampered with or replayed. NTLM relay forwards a victim's authentication to another server. Pass-the-hash reuses a stolen NTLM password hash to authenticate without knowing the password.

How it works. Without signing, an attacker positioned between client and server can relay the client's NTLM authentication to a third host and act as that user. Signing breaks relay because the relayed messages fail the signature check.

When it matters. In any Active Directory network. Enforcing SMB signing and reducing NTLM usage are core hardening steps.

Pitfall. Signing is often enabled but not required. "Enabled" means "use it if the other side asks"; "required" means "refuse unsigned sessions." Only required stops relay.

4. RDP (TCP 3389) and Network Level Authentication (NLA)

Definition. RDP gives an interactive graphical session on a remote host. NLA forces the user to authenticate before a full session (and its resources) is created.

How it works. With NLA on, the server checks credentials up front over a secure channel, so an unauthenticated attacker cannot reach the login screen or consume a session slot.

When (and when not). RDP belongs on internal/administrative networks reached through a VPN or an RD Gateway, with NLA and MFA. It should never be directly exposed to the internet.

Pitfall. Turning on RDP via a quick registry tweak often leaves NLA off and the Windows Firewall rule wide open, exposing 3389 to everything.

5. RDP brute force, password spraying, and BlueKeep

Definition. Brute force tries many passwords against one account; password spraying tries one common password against many accounts (to dodge lockouts). BlueKeep (CVE-2019-0708) is a pre-auth RCE flaw in unpatched RDP.

How it works. Exposed RDP invites automated password guessing 24/7. Unpatched systems add the risk of a network-level exploit with no credentials at all.

When it matters. The moment 3389 is reachable from an untrusted network.

Pitfall. Account lockout defends against brute force but can aid spraying (it locks accounts, causing denial of service) — layered controls (MFA, gateway, monitoring) matter more than lockout alone.

6. Lateral movement and enumeration (the big picture)

Definition. Enumeration is inventorying shares, users, and services. Lateral movement is using valid access on one host to reach another.

How it works. With one set of valid credentials, SMB (admin shares, remote execution) and RDP become the highways an attacker uses to spread. Defenders shrink this by least privilege, network segmentation, and monitoring.

Knowledge check

1. What asset is protected when you require SMB signing, and which specific attack does requiring (not just enabling) it defeat?
2. Where is the trust boundary that makes internet-exposed RDP so dangerous, and what control moves that boundary back to safety?
3. What insecure assumption causes a "Everyone: Full Control" share to leak data even when the admin thinks NTFS protects it?
4. Which Windows log source would show a burst of failed RDP logins from one IP, and why might that same pattern be a false positive?
5. Why must every enumeration or brute-force test in this lesson run only in an isolated lab you are authorized to use?

Threat model

         UNTRUSTED                 | TRUST BOUNDARY |        WINDOWS HOST (asset)
  ------------------------------   |                |   ----------------------------------
  Internet / other VLAN / guest    |                |
  * scanner probing 445, 3389 -----+--> [Firewall]--+--> TCP 445  SMB service
  * RDP brute-force bot        -----+--> [RD Gtwy ] -+       |-- shares (Finance, IT, backups)
  * NTLM relay (on-path)       -----+--> [VPN     ] -+       |-- NTLM / Kerberos auth
                                    |                |   --> TCP 3389 RDP service
  Entry points:                     |                |       |-- interactive login (NLA)
    - open port 445 / 3389          |                |
    - SMBv1 enabled                 |   Controls at  |   Detection:
    - unsigned SMB sessions         |   the boundary:|    - Security log 4624/4625/4776
    - RDP without NLA / MFA         |    firewall,   |    - Security log 5140/5145 (share)
    - unpatched (EternalBlue,       |    RD Gateway, |    - firewall connection logs
      BlueKeep)                     |    VPN, MFA     |    - RDP Operational logs

The attacker's goal is to cross the trust boundary at an entry point. Your job as defender is to (1) close or gate the entry points, (2) harden the service so a crossing fails, and (3) log the attempt so you see it.

Syntax notes

The key structures here are the service ports and the PowerShell / event sources you use to inspect and harden them. Run everything in a lab (see the code section for the authorization checklist).

SMB   -> TCP 445    file sharing + auth   (avoid legacy 137-139 NetBIOS too)
RDP   -> TCP 3389   interactive graphical session

Annotated PowerShell primitives you will use (read-only checks first):

# Is SMBv1 enabled on THIS host? (want: State = Disabled)
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

# Server-side SMB settings; want EnableSMB1Protocol=$false, RequireSecuritySignature=$true
Get-SmbServerConfiguration | Select EnableSMB1Protocol, RequireSecuritySignature

# List the shares this host offers (know your own attack surface)
Get-SmbShare

# Is RDP listening, and is NLA required? (UserAuthentication=1 means NLA on)
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name UserAuthentication

These are inspection commands: they change nothing. The hardening (state-changing) commands appear in the code section, each paired with a verification step.

Lesson

Two protocols carry most Windows network activity — and most Windows attacks.

SMB (port 445)

Server Message Block (SMB) is the protocol for Windows file and printer sharing, plus general communication between machines. Over SMB you can find shares (folders made available on the network), authenticate, and — with the right permissions — run remote commands.

Key points:

• Enumeration. You can list shares and readable files. These are a frequent source of credentials and sensitive data on internal engagements.
• Authentication. SMB uses NTLM and Kerberos (covered in the Active Directory track). Attacks like NTLM relay and pass-the-hash abuse this authentication.
• History. EternalBlue (MS17-010) was a remote code execution flaw in SMBv1. SMBv1 should be disabled everywhere — flag it if you find it still enabled.

RDP (port 3389)

Remote Desktop Protocol (RDP) gives a graphical, interactive session on a remote machine.

Key points:

• Exposure. RDP open to the internet is a top ransomware entry vector. It should sit behind a VPN or gateway and require MFA.
• Attacks. Common threats include credential brute force and password spraying, plus BlueKeep (CVE-2019-0708) on unpatched systems.

Why both matter

On an internal test, SMB enumeration finds data and footholds. Once you have credentials, RDP and SMB become the main channels for lateral movement — moving from one compromised host to another. Recognising ports 445 and 3389 in a scan immediately shapes your plan.

Code examples

All commands below run only in a local, isolated lab — a Windows VM you own, snapshotted, with no bridge to production or the internet. Confirm the authorization checklist first.

AUTHORIZATION CHECKLIST (complete before running anything)
[ ] The host is a VM/lab you own or are explicitly, in-writing authorized to test.
[ ] It is isolated: host-only or internal network, no production/internet bridge.
[ ] You took a VM snapshot named e.g. "pre-lab-clean" so you can revert.
[ ] You are testing YOUR OWN accounts on YOUR OWN host — no third-party systems.
[ ] You have a rollback/cleanup plan (below) if a change breaks access.

(1) Insecure baseline — what a weak lab host looks like

WARNING: intentionally vulnerable — use only in a local, isolated, authorized lab. Do not deploy.

# INSECURE LAB SETUP (never on a real machine). This recreates the classic mistakes
# so you can then detect and fix them.

# a) Legacy SMBv1 left enabled (EternalBlue-vulnerable dialect)
Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart

# b) SMB signing NOT required (relay/tamper possible)
Set-SmbServerConfiguration -RequireSecuritySignature $false -Force

# c) An over-shared folder: share permission Everyone:Full, relying on NTFS alone
New-Item -Path C:\LabShare -ItemType Directory -Force | Out-Null
New-SmbShare -Name LabShare -Path C:\LabShare -FullAccess 'Everyone'

# d) RDP enabled but with NLA turned OFF (pre-auth session reachable)
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' `
  -Name fDenyTSConnections -Value 0
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name UserAuthentication -Value 0

Why each line is dangerous: (a) exposes a wormable RCE dialect; (b) allows NTLM relay and message tampering; (c) advertises a share to Everyone; (d) lets an unauthenticated attacker reach a session and try BlueKeep-class attacks or brute force.

(2) Secure fix — harden the host

# SECURE HARDENING. Run as Administrator in the lab.

# a) Disable SMBv1 entirely
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

# b) REQUIRE SMB signing (enabled is not enough; require refuses unsigned sessions)
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force

# c) Fix the over-shared folder: least privilege on the share, then on NTFS
Grant-SmbShareAccess -Name LabShare -AccountName 'BUILTIN\Users' `
  -AccessRight Read -Force
Revoke-SmbShareAccess -Name LabShare -AccountName 'Everyone' -Force

# d) Require Network Level Authentication for RDP
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name UserAuthentication -Value 1

# e) Restrict who can reach 3389 at the firewall to the admin subnet only
#    (placeholder RFC1918 lab range — replace with YOUR lab management subnet)
Set-NetFirewallRule -DisplayGroup 'Remote Desktop' `
  -RemoteAddress 10.10.10.0/24 -Profile Domain,Private

# f) Turn on the detection you will need (share + logon auditing)
auditpol /set /subcategory:'File Share' /success:enable /failure:enable
auditpol /set /subcategory:'Logon' /success:enable /failure:enable

(3) Verify — prove the fix rejects bad and accepts good

# VERIFICATION. Each check should print the SECURE value.

# SMBv1 must be Disabled and server-side flag false
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol |
  Select FeatureName, State                       # expect State: Disabled
Get-SmbServerConfiguration |
  Select EnableSMB1Protocol, RequireSecuritySignature  # expect False, True

# The share must NOT list Everyone, and only grant Read to Users
Get-SmbShareAccess -Name LabShare                 # expect BUILTIN\Users Read; no Everyone

# NLA must be required for RDP
(Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name UserAuthentication).UserAuthentication    # expect 1

# Firewall rule scoped to the admin subnet only
Get-NetFirewallRule -DisplayGroup 'Remote Desktop' |
  Get-NetFirewallAddressFilter | Select RemoteAddress  # expect 10.10.10.0/24

Positive (accept-good) test: from a host inside 10.10.10.0/24, an authorized user can still open the RDP session and read LabShare — hardening must not break legitimate use.

Negative (reject-bad) test: from an out-of-scope address the RDP connection is refused, and connecting to the share as an anonymous/Everyone identity is denied. A legacy SMBv1-only client can no longer negotiate a session.

Expected result: every verify command prints the secure value (Disabled / False,True / no Everyone / 1 / the admin subnet). If any prints the insecure value, the change did not take — re-apply and re-verify before trusting the host.

Lab cleanup / reset

# Revert the intentionally-vulnerable share and RDP change
Remove-SmbShare -Name LabShare -Force -ErrorAction SilentlyContinue
Remove-Item C:\LabShare -Recurse -Force -ErrorAction SilentlyContinue

Then revert the VM to the pre-lab-clean snapshot to guarantee a known-good state. Never leave a lab host with SMBv1 or non-required signing.

Line by line

Walking through the three phases of the code:

The key mental shift: a value like signing has three states — off, enabled, required. The verify step reads the live value so you never confuse "I typed the fix" with "the fix is in effect." UserAuthentication flips 0 -> 1; RequireSecuritySignature flips False -> True; the share's access list loses the Everyone row. Each verify line is chosen to read exactly the field the matching fix line changed.

Common mistakes

Debugging tips

When a hardening step or a test doesn't behave, work through these:

• A verify command still prints the insecure value. Re-run the fix in an elevated (Administrator) PowerShell. Group Policy can also overwrite local settings on the next refresh — if GPO manages the host, change the policy, not just the local key.
• Legit users lost access after hardening (accept-good test fails). You over-restricted. Re-check Get-SmbShareAccess (did the right group keep Read?) and the firewall RemoteAddress (is the admin subnet actually included?). Widen by the minimum needed, then re-verify.
• Get-SmbServerConfiguration shows signing required but clients still connect unsigned. Client-side signing settings differ from server-side; confirm you changed the server config on the server, and that clients aren't forcing SMBv1.
• RDP refuses connections you expect to succeed. Confirm the source IP is inside the firewall scope, the account has "Allow log on through Remote Desktop" rights, and NLA is supported by the client.
• Expected audit events never appear. auditpol /get /category:* to confirm auditing is actually on; share-access events (5140/5145) need the File Share subcategory enabled, and they can be high-volume.

Questions to ask when it fails: Am I elevated? Is a GPO overriding my local change? Did I verify the live value or just the command's exit? Is this the server or the client setting? Is the source address in scope? Is the relevant audit subcategory enabled?

Memory safety

Security & safety — detection and logging. Hardening is only half the job; you must see attempts. On Windows, the primary sources are the Security event log and firewall connection logs.

What to log (and watch):

Every security-relevant log line should carry: timestamp, source IP/host, account attempted, target resource (share path or host), result (success/fail), the security decision (allowed/denied), and a correlation id to tie related events together.

Never log: passwords, NTLM hashes, Kerberos tickets, session cookies, private keys, full credential blobs, or unnecessary PII. Logging a failed password value just creates a new secret to steal. Record that auth failed and for which account, never the secret itself.

Which events signal abuse: a spike of 4625 from one IP (brute force), 4625 spread across many accounts (spraying), NLA-blocked RDP attempts, share access to sensitive paths by unexpected accounts, or SMBv1 negotiation attempts (should be zero after hardening).

How false positives arise: a mistyped password, a service account with a stale credential, a backup job hammering a share, a vulnerability scanner you authorized, or a user reconnecting after a VPN drop all look like attacks. Tune thresholds, all‑list known scanners/backup hosts, and correlate with change tickets before escalating. Detection without tuning drowns you in noise; tuning without detection leaves you blind.

Real-world uses

Authorized real-world use case. A company hires you to review a Windows file server. With written authorization and a defined scope, you (1) scan and see 445 and 3389 open, (2) enumerate shares and find a Backups share readable by Everyone containing a config file with a database password, (3) confirm SMBv1 is still enabled and signing is only enabled, not required, and (4) find RDP reachable from the general staff VLAN without MFA. Your report doesn't stop at "vulnerable": for each item you give the remediation (remove Everyone, require signing, disable SMBv1, gate RDP behind the gateway + MFA) and a retest step proving it's fixed.

Professional best-practice habits:

• Validation: never trust a setting because you typed it — read the live value back.
• Least privilege: shares grant the narrowest group the minimum right; RDP is limited to specific admin accounts and source subnets.
• Secure defaults: SMBv1 off and signing required in the golden image, RDP off unless explicitly needed with NLA + gateway.
• Logging: enable logon and file-share auditing before you need it, ship logs to a central SIEM, and alert on the signals above.
• Error handling: hardening that breaks legitimate access is a failure too; always run the accept-good test.

Beginner vs advanced:

• Beginner: identify 445/3389 in a scan, list your own host's shares, disable SMBv1, require signing, turn on NLA, and verify each.
• Advanced: enforce these via Group Policy across a domain, disable/limit NTLM, deploy RD Gateway with MFA, segment RDP into a jump-host model, and build SIEM detections for spraying and share-enumeration patterns with tuned thresholds.

Practice tasks

All tasks are lab-only, on a Windows VM you own or are explicitly authorized to test, isolated from production and the internet, with a snapshot taken first. Each ends by remediating and verifying — never by leaving a host weakened.

Beginner 1 — Inventory your own shares.

• Objective: know your attack surface.
• Requirements: run Get-SmbShare and Get-SmbShareAccess on your lab host; list each share, its path, and who can access it.
• Output: a table of share → account → right.
• Hints: look for Everyone or overly broad groups.
• Concepts: SMB shares, least privilege.
• Defensive conclusion: flag any over-share and note the intended, minimal access.

Beginner 2 — Confirm SMBv1 and signing state.

• Objective: detect two classic misconfigurations.
• Requirements: report State of SMBv1 and the values of EnableSMB1Protocol and RequireSecuritySignature.
• Output: the three live values plus a one-line verdict (secure / not).
• Constraints: read-only; change nothing yet.
• Hints: Get-WindowsOptionalFeature, Get-SmbServerConfiguration.
• Concepts: SMBv1/EternalBlue, SMB signing.
• Defensive conclusion: if insecure, write the exact fix command you would run.

Intermediate 1 — Harden and verify RDP.

• Objective: require NLA and scope RDP access.
• Requirements: set UserAuthentication = 1, restrict the Remote Desktop firewall rule to your lab admin subnet, then verify both live values.
• Input/Output: before/after values of NLA and the firewall RemoteAddress.
• Constraints: keep at least one authorized path working (accept-good test).
• Hints: Get-NetFirewallRule | Get-NetFirewallAddressFilter.
• Concepts: NLA, firewall scoping, trust boundary.
• Defensive conclusion: prove an out-of-scope source is now refused.

Intermediate 2 — Turn on detection and read it.

• Objective: make abuse visible.
• Requirements: enable Logon and File Share auditing; perform a few deliberate failed logons with your own account on your own lab host; find the resulting 4625 events.
• Output: the event IDs, source, account, and result fields you captured.
• Constraints: your own account, your own host, small number of attempts; this is detection practice, not a brute-force tool.
• Hints: auditpol, then filter the Security log for 4625.
• Concepts: logging fields, brute-force signals, false positives.
• Defensive conclusion: write a rule idea (threshold + source grouping) and note one false-positive cause.

Challenge — Full remediate-and-retest report on the insecure baseline.

• Objective: take the intentionally-vulnerable baseline from the code section to a verified-secure state and document it.
• Requirements: start from the insecure setup, apply every fix, run every verify, and write a short finding for each issue using the template: title, severity (justified by exploitability/access/impact — not everything is critical), affected component, preconditions, safe reproduction, evidence (the verify output), impact, remediation, and retest result.
• Constraints: lab-only; no third-party targets; end by reverting to the clean snapshot.
• Hints: map each baseline line to its fix and its verify line; severity for internet-exposed unpatched RDP differs from an internal read-only over-share.
• Concepts: remediation, mitigation verification, severity reasoning, reporting.
• Defensive conclusion: the deliverable is a report proving each issue is fixed and retested, plus confirmation the host was reset.

Summary

Main concepts. SMB (TCP 445) shares files and authenticates; RDP (TCP 3389) gives interactive remote sessions. Both are prime targets, so both are things you defend: know your shares, disable SMBv1, require (not merely enable) SMB signing, put RDP behind NLA + a gateway/VPN + MFA, and never expose 3389 to the internet.

Key syntax/commands. Inspect with Get-SmbShare, Get-SmbServerConfiguration, Get-WindowsOptionalFeature ... SMB1Protocol, and the RDP-Tcp UserAuthentication key. Harden with Set-SmbServerConfiguration, Grant/Revoke-SmbShareAccess, Set-NetFirewallRule, and auditpol. Always read the live value back to verify.

Common mistakes. Confusing "enabled" with "required" signing; enabling RDP without NLA or firewall scope; Everyone: Full Control shares; internet-exposed RDP; assuming a patch removed SMBv1; and trusting a clean scan as proof of security.

What to remember. Every hardening step needs three things: the fix, a verification that it took effect (reject-bad and accept-good), and detection/logging (4625/4624/4776/5140-5145 and firewall logs) so abuse is visible. Log the decision and context, never the secret. Test only on systems you own or are authorized to test, in an isolated, snapshotted lab, and reset it when done. Nothing is ever "completely secure" — you reduce risk and prove you did.

Practice with these exercises

• Classify an ARP frame