Lab 07 Authentication & Remote Access Assessment

Mission Overview

Welcome to Lab 07 — Authentication & Remote Access Assessment.

In Lab 06, you learned how to distinguish scanner alerts from validated findings.

Now you will focus on one of the most important parts of enterprise network security:

Remote access and authentication.

Administrative services such as SSH, RDP, VPN-style gateways, web management interfaces, and remote administration platforms provide legitimate access to systems—but they also create valuable attack surfaces.

Your objective in this lab is not to crack passwords or bypass authentication.

Instead, you will assess whether remote-access services are:

• intentionally exposed

• reachable from the correct network

• protected by authentication

• using supplied or approved test identities

• protected against unrestricted anonymous access

• configured with appropriate account policies

• protected by encrypted transport

• restricted to appropriate administrative segments

• aligned with least privilege

• monitored and governed appropriately

Mission Goal: Evaluate the security posture of authorized remote-access and administrative services without password cracking, credential attacks, or authentication bypass techniques.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Skill	Authentication Security Assessment
Secondary Skill	Remote Access Security
Environment	GoHackersCloud Network Pentesting Lab
Input	Validated service inventory from Labs 03–06
Credentials	Supplied/authorized test accounts only
Primary Outcome	Authentication & Remote Access Security Register
Safety Level	Authorized Training Systems Only

Learning Objectives

By completing this lab, you will be able to:

• identify remote-access services

• determine whether administrative services are appropriately exposed

• evaluate authentication requirements

• use supplied test accounts safely

• assess anonymous or guest access where intentionally configured

• identify management-plane exposure

• review account lockout controls conceptually and safely

• assess transport encryption

• understand MFA requirements

• evaluate least-privilege access

• assess network restrictions around administrative services

• document successful and failed authentication observations responsibly

• distinguish authentication exposure from authentication vulnerability

• create professional remote-access findings

• define remediation and retest criteria

Assessment Methodology

Use:

Service → Reachability → Authentication → Authorization → Transport → Network Restriction → Evidence → Finding

Conceptually:

Remote Access Service
        │
        ▼
Reachable?
        │
        ▼
Authentication Required?
        │
        ▼
Approved Test Identity
        │
        ▼
Access Granted?
        │
        ▼
Privileges Appropriate?
        │
        ▼
Transport Protected?
        │
        ▼
Network Access Restricted?
        │
        ▼
Evidence
        │
        ▼
Security Assessment

The core principle is:

Authentication testing should verify controls—not attack credentials.

Part 1 — Revalidate Scope

Confirm your authorized targets and remote services.

Example:

Linux Target
192.168.56.20
SSH: 22/tcp

Windows Target
192.168.56.30
RDP: 3389/tcp

Optional Web Management Target
192.168.56.40
HTTPS: 443/tcp

Record:

Authorized Network:

Authorized Hosts:

Remote Services in Scope:

Test Accounts Supplied:
Yes / No

Password Guessing Authorized:
No

Brute Force Authorized:
No

Credential Stuffing Authorized:
No

Assessment Date:

Investigator:

Part 2 — Create the Workspace

Create:

Network-Pentesting-Labs/
└── Lab-07/
    ├── Scope/
    ├── Notes/
    ├── Authentication/
    │   ├── SSH/
    │   ├── RDP/
    │   ├── Web-Admin/
    │   ├── Remote-Management/
    │   └── Anonymous-Access/
    ├── Network-Restrictions/
    ├── Transport-Security/
    ├── Evidence/
    ├── Screenshots/
    ├── Findings/
    └── Report/

Create:

Lab-07-Authentication-Remote-Access-Journal.md

Suggested structure:

# Lab 07 — Authentication & Remote Access Assessment

## Mission Objective

## Authorization

## Remote Access Inventory

## Test Accounts

## SSH Assessment

## RDP Assessment

## Web Administration Assessment

## Other Remote Management

## Anonymous / Guest Access

## Account Policy Observations

## Transport Security

## MFA Assessment

## Network Restrictions

## Privilege Assessment

## Findings

## Limitations

## Recommendations

## Conclusion

Part 3 — Build the Remote Access Inventory

Bring forward relevant services from Lab 05.

Create:

ID	Host	Port	Service	Purpose	Management Service
RA-01	Linux	22	SSH	Remote administration	Yes
RA-02	Windows	3389	RDP	Remote administration	Yes
RA-03	Web Target	443	Admin Portal	Web management	Yes

Other possible services include:

• WinRM

• VPN gateways

• VNC

• web consoles

• database administration endpoints

• network-device management interfaces

Part 4 — Classify Service Exposure

For each service classify:

Expected

Administrative access is intentionally available from the assessment segment.

Unexpected

The service should not be reachable from this segment.

Restricted

Reachability is limited by firewall, ACL, VPN, jump host, or management network.

Unknown

Architecture information is insufficient.

Build:

Host	Service	Reachable	Expected	Classification
Linux	SSH	Yes	Yes	Expected
Windows	RDP	Yes	No	Unexpected

Part 5 — Verify Reachability

Use the port evidence from Lab 03 rather than starting from assumptions.

Where required, perform a simple authorized connection check.

Example:

nc -vz 192.168.56.20 22

For RDP:

nc -vz 192.168.56.30 3389

Record:

Target:

Port:

Reachability:

Expected Reachability:

Evidence:

This confirms exposure only.

It does not test credentials.

Part 6 — Understand Authentication vs Authorization

These are different.

Authentication

Answers:

Who are you?

Examples:

• password

• SSH key

• certificate

• MFA

• smart card

Authorization

Answers:

What are you allowed to do?

For example:

User authenticated successfully
        ↓
Read-only role

is different from:

User authenticated successfully
        ↓
Administrator privileges

Both must be assessed.

Part 7 — Establish Authorized Test Accounts

Create a Test Identity Register.

Identity	Target	Role	Credential Source	Authorized
lab-user	Linux	Standard User	Supplied	Yes
lab-admin	Windows	Admin/Test	Supplied	Yes
web-reviewer	Portal	Restricted User	Supplied	Yes

Never use:

• production credentials

• reused personal passwords

• leaked credentials

• guessed credentials

Part 8 — Protect Credentials During the Lab

Do not put passwords directly into:

• screenshots

• filenames

• reports

• command history where avoidable

• shared notes

Document:

Credential Used:
Authorized supplied test credential

Password Recorded in Report:
No

Part 9 — Assess SSH Authentication

First confirm SSH:

nmap -sV -p 22 192.168.56.20

Record:

SSH Reachable:
Yes / No

Authentication Required:
Yes / No

Product:

Version:

Expected Exposure:
Yes / No

Part 10 — Connect with a Supplied Account

Where the lab provides a valid SSH account:

ssh lab-user@192.168.56.20

Use only the supplied credential.

Record:

Authentication Result:
Successful / Failed

Account:
Authorized Test User

Interactive Access:
Yes / No

Privilege Level:
Standard / Administrative / Unknown

Do not attempt other passwords if authentication fails.

Part 11 — Assess SSH Authentication Methods

Determine which authentication mechanisms are supported.

Examples may include:

Password

Public key

Certificate

Keyboard-interactive

Record:

Method	Available	Expected
Password
Public Key
MFA

Avoid attempts to bypass or downgrade authentication.

Part 12 — Assess Root or Direct Administrative Login

If configuration information is provided by the lab, determine whether direct administrative login is permitted.

The security question is:

Should privileged identities be able to authenticate directly over the network?

Preferred design often uses:

Standard Identity
      ↓
Authentication
      ↓
Controlled Privilege Elevation

rather than routine direct root login.

Do not attempt guessing privileged credentials.

Part 13 — Assess SSH Network Exposure

Ask:

Who can reach SSH?

User Network?

Management Network?

Pentest Network?

Internet?

Only Approved Jump Host?

Build:

Source Segment	SSH Reachable	Expected
Pentest	Yes	Yes
User
Management
External

This will connect directly to Lab 12 segmentation testing.

Part 14 — Assess SSH Transport Security

SSH is encrypted, but configuration still matters.

Document:

Encrypted Transport:
Yes

Protocol:
SSH

Legacy Configuration Observed:
Yes / No / Not Assessed

Security Status:
Review / Acceptable / Requires Further Analysis

Do not assume:

SSH
=
Automatically Secure

Part 15 — Build the SSH Security Profile

SERVICE PROFILE

Host:

IP:

Port:
22

Service:
SSH

Reachable:
Yes / No

Expected Exposure:

Authentication Required:

Authentication Methods:

Authorized Test Login:
Success / Failure / Not Performed

Direct Privileged Access:
Allowed / Restricted / Unknown

Encryption:
Yes

Network Restriction:

MFA:
Present / Absent / Unknown

Assessment:

Evidence:

Part 16 — Assess RDP Reachability

For the authorized Windows target, verify:

3389/tcp

Record:

RDP Reachable:
Yes / No

Expected:
Yes / No

Assessment Segment:

Management Segment:

Do not begin password testing.

Part 17 — Use Supplied RDP Credentials Only

If the lab provides a Windows account, use only that identity.

You may establish a normal authorized remote desktop session through the client available in your environment.

Record:

Authorized Account:

Authentication Successful:
Yes / No

Remote Session Established:
Yes / No

Role:

Desktop Access:
Yes / No

Part 18 — Evaluate RDP Authentication Requirements

Assess:

Authentication Required:
Yes / No

Network Level Authentication:
Enabled / Disabled / Unknown

MFA:
Yes / No / Unknown

Account Restrictions:
Observed / Not Observed

Do not try multiple identities or passwords to infer authentication behavior.

Part 19 — Understand Network Level Authentication

NLA requires authentication earlier in the RDP connection process.

It can reduce exposure to unauthenticated remote-session functionality.

Record:

NLA:
Enabled / Disabled / Unknown

If uncertain, classify as:

Requires configuration verification.

Part 20 — Assess RDP Exposure Context

The key question is often not:

“Is RDP running?”

but:

“Who can reach RDP?”

Example:

User Workstation Network
        │
        ▼
     3389/RDP
        │
        ▼
Critical Server

If that is not intended, the exposure may represent a segmentation weakness.

Part 21 — Build the RDP Security Profile

Host:

IP:

Port:
3389

Reachability:

Expected Exposure:

Authentication Required:

NLA:

MFA:

Authorized Login:

Account Role:

Network Restrictions:

Security Assessment:

Evidence:

Part 22 — Assess Web Administrative Interfaces

For an authorized administrative portal:

curl -I https://192.168.56.40

Identify:

Authentication Page:

HTTP Status:

TLS:

Redirects:

Admin Functionality:

Expected Exposure:

Do not attempt to bypass the login page.

Part 23 — Use Supplied Web Credentials

Where a test account is provided, authenticate normally through the application.

Record:

Account:

Role:

Authentication Successful:

Privileges Presented:

Administrative Functions Visible:

Expected Role:

Do not attempt privilege escalation during this lab.

Part 24 — Assess Web Role Separation

Suppose the lab provides:

User Account

Administrator Account

You may compare intended access using each supplied identity.

The goal is to determine:

Does each authorized identity receive the expected level of access?

Build:

Function	Standard User	Admin	Expected
View profile	Yes	Yes	Yes
Change system settings	No	Yes	Yes
Manage users	No	Yes	Yes

This is authorization testing—not authentication bypass.

Part 25 — Assess Web Session Protection at a High Level

Observe:

HTTPS Used:
Yes / No

Session Cookie Present:
Yes / No

Authentication Required:
Yes / No

Logout Available:
Yes / No

Detailed web-session testing belongs in Web Pentesting Labs.

Here, the focus is remote administrative access.

Part 26 — Assess Other Remote Management Services

If your lab contains:

• WinRM

• VNC

• hypervisor console

• device management UI

• database administration

• remote shell platform

apply the same methodology:

Reachability
   ↓
Authentication
   ↓
Authorization
   ↓
Transport
   ↓
Network Restriction

Part 27 — Identify Unauthenticated Management Access

If an intentionally vulnerable training system provides administrative functionality without authentication, document it carefully.

Example:

Administrative Interface:
Reachable

Authentication Prompt:
Absent

Administrative Functions:
Visible

Configuration Change:
Not Performed

Do not modify the system merely to prove access.

Part 28 — Assess Anonymous Access

Some services may intentionally permit:

Anonymous FTP

Guest SMB

Unauthenticated web content

Where this is part of the lab, determine:

Authentication Required:

Resources Visible:

Read Access:

Write Access:
Not Tested unless explicitly authorized

Sensitive Content:
Not Accessed

Part 29 — Avoid Unnecessary Data Access

If an unauthenticated share is visible, you generally do not need to download every file.

A safer evidence model is:

Share Exists
      +
Unauthenticated Enumeration
      +
Permitted Access Level
      =
Sufficient Evidence

where possible.

Part 30 — Evaluate Default Access Carefully

If the training system intentionally provides a documented default account, you may validate it only if that account is explicitly supplied as part of the exercise.

Do not independently search for or guess default credentials against arbitrary services.

Record:

Credential Source:
Lab Documentation

Account:
Supplied

Result:

Configuration Status:
Default / Changed / Unknown

Part 31 — Understand Account Lockout

Account lockout policies can limit repeated authentication failures.

Important controls include:

Failure Threshold

Observation Window

Lockout Duration

Administrative Reset

Monitoring

However, testing lockout carelessly can deny access to legitimate users.

Part 32 — Assess Lockout Without Brute Force

Preferred methods:

• review lab configuration

• inspect authorized policy settings

• use documentation supplied for the environment

• perform only specifically designed failure tests

Do not generate large numbers of failed attempts.

If one or two failed test logins are part of the scenario, document them and stop.

Part 33 — Create the Account Policy Register

Control	SSH	Windows/RDP	Web Admin
Authentication Required
Lockout Policy
MFA
Password Policy
Session Timeout
Privileged Access Restricted

Some values may be:

Unknown

That is acceptable.

Part 34 — Understand MFA

Multi-factor authentication combines factors such as:

Something you know

Something you have

Something you are

For remote administrative access, MFA can significantly strengthen protection.

Record:

MFA Required:
Yes / No / Unknown

Applicable Services:

Evidence:

Do not attempt to bypass MFA.

Part 35 — Evaluate Least Privilege

For each authorized test identity ask:

Does this account receive only the privileges required for its role?

Example:

lab-user
    ↓
SSH login
    ↓
Standard shell

Expected.

Versus:

lab-user
    ↓
SSH login
    ↓
Unnecessary administrator privileges

Potential weakness.

Part 36 — Build the Privilege Register

Identity	Service	Expected Role	Observed Role	Status
lab-user	SSH	Standard	Standard	Pass
web-reviewer	Web	Read-only	Admin	Potential Issue

Only use authorized test accounts.

Part 37 — Assess Shared Accounts

Where documentation reveals shared administrative accounts, record:

Shared Account:
Yes / No

Individual Accountability:
Available / Limited

Security Concern:

The issue is often accountability rather than the mere existence of a username.

Part 38 — Assess Administrative Account Separation

An organization may separate:

Normal User Account

Privileged Administrator Account

This reduces routine use of highly privileged identities.

Record:

Privileged Identity Separation:
Yes / No / Unknown

Part 39 — Assess Transport Encryption

Build:

Service	Authentication	Encryption	Assessment
SSH	Yes	Yes
RDP	Yes	Yes
HTTPS Admin	Yes	TLS
HTTP Admin	Yes	No	Review

If credentials are transmitted through a plaintext administrative service, that deserves attention.

Part 40 — Plaintext Authentication Example

Suppose an administrative application uses:

HTTP

rather than:

HTTPS

Do not submit real credentials.

In the lab, use only supplied test credentials if the exercise specifically requires validation.

The security concern is:

Authentication traffic may lack adequate transport protection.

Part 41 — Build the Transport Security Register

Host	Service	Transport	Encryption	Sensitive Auth	Status
Linux	SSH	TCP	Yes	Yes
Web	HTTP	TCP	No	Yes	Review

Part 42 — Evaluate Management Plane Segmentation

Administrative services should often be reachable only from:

Management Network

Jump Host

VPN

Approved Administrator Systems

not:

Every User Workstation

Build:

Service	User Network	Management Network	Expected
SSH	Reachable	Reachable	Mgmt only
RDP	Reachable	Reachable	Mgmt only

This can reveal an important architectural finding.

Part 43 — Build the Remote Access Matrix

Source	Destination	Service	Reachable	Expected	Result
Pentest	Linux	SSH	Yes	Yes	Pass
User Segment	Windows	RDP	Yes	No	Review

Use only network paths available inside your lab architecture.

Part 44 — Assess Exposure to Broad Network Ranges

An administrative service reachable from:

0.0.0.0/0

or an unnecessarily broad network is significantly different from one restricted to:

10.20.30.0/28

management systems.

Document the architectural intent.

Part 45 — Assess Source Restrictions

Possible controls include:

Host Firewall

Network ACL

Security Group

VPN

Jump Host

Conditional Access

Management VLAN

Record:

Control	SSH	RDP	Admin Web
Host Firewall
Network Restriction
VPN Required
Jump Host Required

Part 46 — Identify Authentication Error Leakage

A login system may reveal different messages such as:

Unknown user

versus:

Incorrect password

This can provide account-existence clues.

For this lab, observe behavior only for supplied test identities.

Do not enumerate usernames.

Record:

Authentication Error Messaging:

Generic / Detailed / Unknown

Part 47 — Assess Session Timeout

Where visible through an authorized administrative session, record whether idle sessions expire according to lab policy.

Do not wait excessive periods just to force timeout behavior unless the lab explicitly requires it.

Configuration review may be sufficient.

Part 48 — Assess Concurrent Sessions

Where supplied documentation describes concurrent-session limits, record them.

Do not intentionally exhaust session limits.

Part 49 — Assess Login Logging

Where the lab provides system logs, verify that normal authorized authentication creates an audit trail.

Examples:

Successful login

Failed login

Source address

Timestamp

Identity

This bridges pentesting with defensive security.

Part 50 — Build the Authentication Logging Register

Event	Logged	Identity	Source IP	Timestamp
Successful SSH login
Failed authorized test login
RDP login

Do not create unnecessary failed-login events.

Part 51 — Understand Why Logging Matters

Authentication controls are stronger when they support:

Prevention
     +
Detection
     +
Investigation

A successful login that leaves no useful audit trail may reduce accountability.

Part 52 — Identify the Major Authentication Risk Categories

Use:

Unauthenticated Access

Weak Network Restrictions

Excessive Privilege

Lack of MFA

Plaintext Authentication

Unnecessary Management Exposure

Insufficient Logging

Shared Administrative Accounts

Weak Session Controls

Not every environment will contain each category.

Part 53 — Classify Findings

Use:

Observation

Authentication behavior worth noting.

Potential Weakness

Security concern requires additional architectural/configuration validation.

Validated Finding

Condition is confirmed with sufficient evidence.

Not Applicable

Control does not apply to this service.

Inconclusive

Evidence is insufficient.

Part 54 — Example Finding — Broad SSH Exposure

Finding ID:
AUTH-01

Title:
Administrative SSH Service Accessible from User Network

Asset:
192.168.56.20

Service:
22/tcp SSH

Classification:
Validated Finding

Description:
The SSH management service is reachable from the user assessment
segment.

Architecture documentation indicates that server administration
should originate only from the management network.

Evidence:
TCP connection validation and SSH service response from the
authorized user-segment test host.

Impact:
A compromised endpoint within the user network could directly
interact with the server's administrative authentication surface.

Recommendation:
Restrict SSH access to approved management networks, jump hosts,
or authorized administrative endpoints.

Retest:
Confirm SSH is inaccessible from the user segment while remaining
available from the approved management path.

Part 55 — Example Finding — Administrative Portal Without TLS

Where actually configured in the lab:

Finding ID:
AUTH-02

Title:
Administrative Authentication Available Over Unencrypted HTTP

Description:
The administrative web interface is reachable over HTTP and
presents authentication functionality without encrypted transport.

Impact:
Credentials and authenticated session information may be exposed
to interception on an untrusted network path.

Recommendation:
Require HTTPS for administrative access and redirect or disable
unencrypted HTTP access.

Retest:
Verify administrative authentication is available only over
approved TLS-protected endpoints.

Part 56 — Example Observation — MFA Not Present

Observation:
The authorized test account authenticated to the remote management
service using a single authentication factor.

Context:
No additional factor was presented during the approved lab login.

Assessment:
Whether MFA is required depends on organizational remote-access
policy.

Status:
Policy Review Required.

This avoids calling every lack of MFA automatically critical.

Part 57 — Example Finding — Excessive Privilege

Finding ID:
AUTH-03

Title:
Standard Remote Access Account Receives Administrative Privileges

Identity:
lab-user

Expected Role:
Standard User

Observed Role:
Administrative

Impact:
Compromise of the standard account could provide greater system
control than required for the user's intended function.

Recommendation:
Apply least privilege and assign elevated permissions only to
dedicated administrative identities.

Part 58 — Example Positive Control

Not everything should become a finding.

Example:

Control:
SSH management access

Observation:
The service requires authentication, uses encrypted transport, and
is reachable only from the authorized management segment.

Assessment:
Control operating as expected.

Professional reports should recognize effective controls too.

Part 59 — Build the Authentication Findings Register

ID	Host	Service	Condition	Severity	Confidence
AUTH-01	Linux	SSH	Broad management exposure	Medium	High
AUTH-02	Web	HTTP	Unencrypted admin login	High	High
AUTH-03	Linux	SSH	Excessive privileges	Medium	High

Only populate findings supported by your actual lab evidence.

Part 60 — Build the Authentication Control Matrix

Control	SSH	RDP	Web Admin
Authentication Required
Supplied Test Login Works
MFA
Encrypted Transport
Network Restricted
Least Privilege
Individual Identity
Logging
Session Controls

Part 61 — Build the Remote Access Risk Matrix

Service	Exposure	Auth Strength	Privilege	Transport	Priority
SSH	Broad	Password	Standard	Encrypted	Medium
RDP	Restricted	Password	Admin	Encrypted	Medium
Admin Web	Broad	Password	Admin	Plaintext	High

Part 62 — Separate Control Failure from Exploitability

For example:

RDP available from user network

is a security-control weakness.

You do not need to:

Compromise an account

to prove that network exposure exists.

This principle keeps testing proportional.

Part 63 — Assess Defense in Depth

Good remote-access security often combines:

Restricted Network Path
        +
Strong Authentication
        +
MFA
        +
Least Privilege
        +
Encrypted Transport
        +
Logging

No single control should be the only defense.

Part 64 — Create the Evidence Chain

For each authentication finding:

Service Identified
      ↓
Reachability Confirmed
      ↓
Authentication Behavior
      ↓
Authorized Identity
      ↓
Privilege Observed
      ↓
Network/Transport Context
      ↓
Evidence
      ↓
Finding

Part 65 — Create the Remote Access Service Profile

Use for every major management service:

REMOTE ACCESS PROFILE

Asset:

IP:

Service:

Port:

Purpose:

Reachable From:

Expected Reachability:

Authentication Required:

Authentication Method:

MFA:

Authorized Test Account:

Authentication Result:

Observed Role:

Expected Role:

Transport Encryption:

Network Restriction:

Host Firewall:

Logging:

Session Controls:

Security-Relevant Observation:

Classification:

Evidence:

Recommendation:

Part 66 — Mission Challenge

Complete:

LAB INFORMATION

Lab:
Authentication & Remote Access Assessment

Authorized Network:

Assessment Date:

Investigator:


REMOTE SERVICES

Total Remote Access Services:

Administrative Services:

Authentication Services:

Unexpected Management Services:


SSH ASSESSMENT

Host:

Port:

Reachable:

Expected Reachability:

Authentication Required:

Approved Account Used:

Authentication Successful:

Authentication Method:

Direct Privileged Login:

MFA:

Transport Encryption:

Network Restriction:

Observed Privilege:

Expected Privilege:

Logging:

Assessment:


RDP ASSESSMENT

Host:

Port:

Reachable:

Expected Reachability:

Authentication Required:

Approved Account Used:

Authentication Successful:

NLA:

MFA:

Observed Role:

Transport Protection:

Network Restriction:

Assessment:


WEB ADMIN ASSESSMENT

URL/IP:

HTTPS:
Yes / No

Authentication Required:

Approved Account:

Role:

Expected Role:

Administrative Functionality:

MFA:

Network Restriction:

Session Protection:

Assessment:


ANONYMOUS / GUEST ACCESS

Service:

Anonymous Access:
Yes / No

Authorized Validation Performed:
Yes / No

Resources Visible:

Write Access:
Not Tested / Authorized Result

Assessment:


ACCESS CONTROL

Least Privilege:
Pass / Review / Unknown

Privileged Account Separation:

Shared Accounts:

Network Segmentation:

Management Plane Restricted:


TRANSPORT SECURITY

SSH:
Encrypted / Not Applicable

RDP:
Encrypted / Unknown

Web Administration:
HTTP / HTTPS

Plaintext Authentication Identified:
Yes / No


MONITORING

Successful Login Logged:

Failed Login Logged:

Source IP Logged:

Identity Logged:

Timestamp Logged:


FINAL FINDINGS

Validated Authentication Findings:

Potential Weaknesses:

Positive Controls:

Inconclusive Controls:

Highest-Priority Issue:

Ready for Windows Network Service Assessment:
Yes / No

Part 67 — What Not to Do

Do not:

Brute-force passwords

Guess usernames

Perform password spraying

Perform credential stuffing

Use leaked credentials

Reuse credentials outside the lab

Attempt MFA bypass

Attempt authentication bypass

Lock out accounts intentionally

Create large numbers of failed logins

Use production credentials

Capture real passwords

Modify administrative configurations unnecessarily

Access unrelated user data

Escalate privileges beyond the approved task

Install persistence

Create hidden accounts

Disable authentication controls

Disable logging

Expose lab services to the Internet

The professional principle is:

Test the security control—not the limits of someone else’s credentials.

Troubleshooting

SSH Connection Works but Login Fails

Verify:

• supplied username

• supplied lab credential

• account status

• correct target

Do not begin guessing alternatives.

RDP Port Is Open but Session Cannot Be Established

Possible causes include:

• NLA requirements

• supplied account restrictions

• local policy

• remote-desktop permission

• session limitations

Record the limitation.

Web Portal Rejects Valid Test Credentials

Verify:

• correct portal

• correct supplied identity

• account role

• test account validity

Do not bypass authentication.

Administrative Service Is Not Reachable

This may indicate a successful network restriction.

Compare against the intended architecture.

Account Becomes Locked

Stop authentication testing.

Document:

Testing Stopped:
Yes

Reason:
Account lockout observed.

Do not attempt to circumvent lockout.

Evidence Requirements

Capture:

Evidence 01

Scope and authorization.

Evidence 02

Remote Access Inventory.

Evidence 03

Test Identity Register.

Evidence 04

SSH reachability.

Evidence 05

SSH authentication behavior.

Evidence 06

SSH Security Profile.

Evidence 07

RDP reachability.

Evidence 08

RDP authentication behavior.

Evidence 09

RDP Security Profile.

Evidence 10

Web administrative-interface assessment.

Evidence 11

Web role comparison where authorized.

Evidence 12

Anonymous/guest assessment where configured.

Evidence 13

Account Policy Register.

Evidence 14

MFA assessment.

Evidence 15

Privilege Register.

Evidence 16

Transport Security Register.

Evidence 17

Remote Access Matrix.

Evidence 18

Authentication Logging Register.

Evidence 19

Authentication Control Matrix.

Evidence 20

Authentication Findings Register.

Evidence 21

Remote Access Risk Matrix.

Evidence 22

Mission Challenge worksheet.

Mission Deliverables

Complete:

• scope revalidated

• remote services identified

• management services classified

• authorized test identities documented

• credential-handling rules followed

• SSH reachability assessed

• SSH authentication assessed

• SSH network restriction reviewed

• RDP exposure assessed

• RDP authentication controls reviewed

• NLA documented where applicable

• web administrative access reviewed

• role separation assessed where authorized

• anonymous access assessed only where intentionally configured

• account lockout reviewed safely

• MFA status documented

• least privilege assessed

• privileged identity separation reviewed

• management-plane exposure evaluated

• transport protection documented

• login logging reviewed where available

• positive controls recorded

• validated findings written

• remediation prepared

• retest criteria defined

• final report completed

Lab Report Template

# Lab 07 — Authentication & Remote Access Assessment

## Executive Summary

## Mission Objective

## Authorization and Scope

## Remote Access Inventory

## Test Identity Register

## Assessment Methodology

## SSH Assessment

### Reachability
### Authentication
### Authorization
### Transport Security
### Network Restrictions

## RDP Assessment

### Reachability
### Authentication
### NLA
### MFA
### Network Restrictions

## Web Administrative Access

### Authentication
### Role Separation
### TLS
### Session Controls

## Other Remote Management Services

## Anonymous / Guest Access

## Account Policy Assessment

## MFA Assessment

## Least Privilege Assessment

## Privileged Identity Separation

## Transport Security

## Management Network Segmentation

## Authentication Logging

## Positive Security Controls

## Validated Findings

## Potential Weaknesses

## Limitations

## Recommendations

## Retest Criteria

## Conclusion

Knowledge Check

Question 1 — What is the difference between authentication and authorization?

Authentication establishes identity. Authorization determines what that identity is permitted to do.

Question 2 — Should you brute-force passwords during this lab?

No.

Use only supplied or explicitly authorized test identities.

Question 3 — Is an exposed SSH service automatically a vulnerability?

No.

Its network location, authentication controls, configuration, and intended exposure must be evaluated.

Question 4 — Why are administrative network restrictions important?

They reduce the number of systems capable of reaching sensitive authentication surfaces.

Question 5 — What is least privilege?

Giving an identity only the permissions necessary for its intended role.

Question 6 — Is a successful login itself evidence of weak authentication?

No.

A valid supplied credential is expected to authenticate successfully.

Question 7 — Why should lockout testing be performed carefully?

Because excessive failed attempts can deny legitimate users access.

Question 8 — Why is encrypted transport important for authentication?

It protects credentials and session information while transmitted across the network.

Question 9 — Does lack of MFA automatically mean a critical vulnerability?

No.

The requirement depends on policy, service sensitivity, exposure, and risk context.

Question 10 — What is the central principle of this lab?

Verify that remote access is appropriately authenticated, authorized, encrypted, restricted, and auditable—without attacking credentials.

Skills Achieved

After completing this lab, you should understand:

• remote-access inventory

• authentication assessment

• authorization assessment

• SSH security review

• RDP security review

• web-admin authentication review

• supplied test-account usage

• anonymous-access assessment

• account-lockout awareness

• MFA assessment

• least privilege

• privileged account separation

• transport protection

• management-plane security

• administrative network segmentation

• authentication logging

• evidence-based authentication findings

• positive-control documentation

• remediation and retest planning

Professional Takeaway

Authentication testing should not look like:

Login Page
    ↓
Guess Passwords
    ↓
Try More Accounts

The professional workflow is:

Remote Service
      ↓
Confirm Reachability
      ↓
Understand Purpose
      ↓
Verify Authentication
      ↓
Use Approved Test Identity
      ↓
Verify Authorization
      ↓
Review MFA
      ↓
Review Transport Security
      ↓
Review Network Restriction
      ↓
Review Logging
      ↓
Evidence-Based Finding

Always distinguish:

Service Reachable
      ≠
Authentication Weak

Valid Credential Works
      ≠
Vulnerability

Password Authentication
      ≠
Automatically Insecure

No MFA
      ≠
Automatically Critical

Administrator Service
      ≠
Automatically Overexposed

Authentication Failure
      ≠
Permission to Guess More Passwords

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

“Are the authorized remote-access services protected by appropriate authentication, privilege boundaries, encrypted transport, management-network restrictions, and audit controls?”

What’s Next?

➡️ Lab 08 — SMB & Windows Network Service Assessment

In the next lab, you will focus specifically on the Windows network attack surface identified earlier.

You will examine:

• SMB exposure

• Windows host information

• SMB protocol configuration

• SMB signing

• share visibility

• share permissions

• supplied test-user access

• intentionally configured guest access

• administrative shares

• legacy protocol awareness

• Windows remote-service exposure

• expected vs observed access

• professional Windows-service findings

The methodology becomes:

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

The central question will be:

“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?”