Lab 16 Privilege Assessment

Mission Overview

Welcome to Lab 16 — Privilege Assessment.

You have already assessed Linux and Windows host security. Now you will focus specifically on one of the most important security questions in any enterprise environment:

Who has elevated privileges, what can those privileges affect, and are they actually necessary?

Privileges determine what a user, service, process, or application can do.

A standard user might be permitted to read their own files, while an administrator can modify system configuration, install software, manage accounts, access protected resources, or control services.

The objective of this lab is not privilege escalation.

Instead, you will examine existing privilege relationships and determine whether they create unnecessary security exposure.

Mission Goal: Identify and assess privileged users, groups, services, scheduled tasks, filesystem permissions, and administrative capabilities across authorized Linux and Windows training systems, then produce a prioritized Privilege Risk Register.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	90–120 minutes
Primary Skill	Privilege Assessment
Secondary Skill	Least-Privilege Analysis
Platforms	Linux + Windows
Environment	Isolated GoHackersCloud Lab
Testing Type	Read-Only Security Assessment
Primary Outcome	Privilege Risk Register
Evidence	Commands, permissions, screenshots, matrices
Safety Level	Authorized Lab Only

Learning Objectives

By completing this lab, you will be able to:

• distinguish identity from privilege

• understand standard and elevated accounts

• identify privileged Linux groups

• assess sudo permissions

• identify Windows local administrators

• understand User Account Control

• assess service identities

• review scheduled-task privileges

• examine filesystem permissions

• identify excessive privilege

• understand least privilege

• recognize privilege concentration

• assess privileged application components

• distinguish privilege exposure from privilege escalation

• identify security boundaries

• document positive controls

• prioritize privilege-related risk

• recommend practical privilege reduction

Privilege Assessment Methodology

Use:

Identity → Granted Privilege → Resource → Security Boundary → Risk → Evidence

Conceptually:

Identity
   │
   ▼
User / Service / Process
   │
   ▼
Granted Privilege
   │
   ▼
Protected Resource
   │
   ▼
Security Boundary
   │
   ▼
Business / Security Impact

Your objective is not:

Find Privilege
     ↓
Exploit It

Instead:

Find Privilege
     ↓
Understand Purpose
     ↓
Identify Accessible Resources
     ↓
Evaluate Necessity
     ↓
Assess Risk
     ↓
Recommend Improvement

Lab Architecture

Example:

                 GHC Ethical Hacking Lab
                         │
              Assessment Workstation
                         │
             ┌───────────┴───────────┐
             ▼                       ▼
       Linux Training VM       Windows Training VM
       192.168.56.20           192.168.56.40
             │                       │
        Users / Groups          Users / Groups
             │                       │
           sudo                 Administrators
             │                       │
         Services                Services
             │                       │
       Cron / Files             Tasks / NTFS
             │                       │
             └───────────┬───────────┘
                         ▼
                  Privilege Analysis

Use only lab-provided accounts and systems.

Part 1 — Confirm Scope

Document:

Linux Target:

Windows Target:

Authorized Linux Account:

Authorized Windows Account:

Administrative Read Access:
Yes / No

Permitted Commands:

Permitted Directories:

Permitted Services:

Excluded Accounts:

Excluded Data:

Assessment Start:

This lab requires only the access explicitly provided by the training environment.

Part 2 — Rules of Engagement

Permitted

• inspecting your current identity

• listing authorized local users

• listing groups

• reviewing group memberships

• inspecting assigned sudo permissions

• reviewing Windows administrator membership

• inspecting service identities

• examining approved file permissions

• reviewing scheduled tasks

• examining security policies

• documenting privilege relationships

• recording excessive privileges

• identifying least-privilege opportunities

Not Permitted

• privilege escalation

• exploiting SUID binaries

• abusing sudo permissions

• UAC bypass

• exploiting Windows services

• manipulating scheduled tasks

• replacing service binaries

• extracting credentials

• dumping password hashes

• accessing LSASS

• modifying privileged files

• creating administrator accounts

• persistence

• disabling security controls

Identify the weakness without weaponizing it.

Part 3 — Create the Workspace

Create:

Ethical-Hacking-Labs/
└── Lab-16/
    ├── Notes/
    ├── Evidence/
    │   ├── Linux/
    │   ├── Windows/
    │   ├── Services/
    │   ├── Tasks/
    │   ├── Filesystem/
    │   └── Positive-Controls/
    ├── Screenshots/
    ├── Findings/
    └── Report/

Create:

Lab-16-Privilege-Journal.md

Suggested structure:

# Lab 16 — Privilege Assessment

## Mission Objective

## Scope

## Linux Identities

## Linux Groups

## Sudo Rights

## Linux Services

## Linux Scheduled Tasks

## Linux Filesystem Privileges

## Windows Identities

## Windows Administrators

## UAC

## Windows Services

## Windows Scheduled Tasks

## NTFS Permissions

## Privilege Matrix

## Excessive Privilege

## Positive Controls

## Findings

## Recommendations

## Evidence

## Lessons Learned

Part 4 — Understand Identity vs Privilege

Identity answers:

Who is this?

Privilege answers:

What can this identity do?

Example:

lab-user
   │
   ▼
Member of developers
   │
   ▼
Write access to application directory

Another:

administrator
     │
     ▼
Local Administrators
     │
     ▼
System-Level Administration

Authentication alone does not explain security exposure.

You need to understand the permissions associated with the identity.

Part 5 — Understand Least Privilege

The principle of least privilege means:

Users, services, and applications should receive only the permissions necessary to perform their required functions.

Conceptually:

Required Privilege
       =
Granted Privilege

The security problem appears when:

Granted Privilege
       >
Required Privilege

The larger that difference becomes, the larger the potential impact of compromise or misuse.

Part 6 — Begin the Linux Assessment

Connect using only your authorized training account.

Record:

whoami

Then:

id

Record:

Username:

UID:

Primary Group:

Additional Groups:

Part 7 — Review Linux Group Membership

Run:

groups

You may see memberships such as:

lab-user sudo developers

Do not immediately classify membership as insecure.

Ask:

Why does this account require membership in this group?

Part 8 — Identify Local Linux Accounts

Review:

cat /etc/passwd

This file does not contain normal plaintext passwords.

Build:

Account	UID	Shell	Likely Purpose
root	0	shell	Administrator
lab-user		shell	Training user
service-user		restricted	Service

Focus on accounts relevant to the mission.

Part 9 — Identify UID 0 Accounts

Run:

awk -F: '$3 == 0 {print $1}' /etc/passwd

Normally, you expect:

root

If additional UID 0 accounts exist, document them.

Do not modify or disable them.

Part 10 — Review Privileged Linux Groups

Common privileged or security-sensitive groups can include:

sudo
wheel
docker

depending on the system.

Check relevant groups:

getent group sudo

or:

getent group wheel

Do not assume every Linux distribution uses the same group model.

Part 11 — Build the Linux Privileged User Register

Example:

Identity	Privileged Group	Business Need	Risk
root	root	System administration	Expected
lab-admin	sudo	Lab administration	Expected
lab-user	sudo	Unknown	Review

The key column is:

Business Need

Privilege without a justified purpose deserves investigation.

Part 12 — Review sudo Rights

For your authorized account:

sudo -l

This may show which commands the account is permitted to execute with elevated privileges.

Record:

Account:

Sudo Access:
Yes / No

Scope:

Password Required:

Security Relevance:

Do not execute listed commands merely to determine whether they can be abused.

Part 13 — Understand Why sudo Scope Matters

Compare:

User
 ↓
One Approved Administrative Command

with:

User
 ↓
Broad Administrative Access

These are very different privilege profiles.

Assess:

• which command is allowed

• whether arguments are restricted

• whether the permission is operationally necessary

• whether broad administrative access is justified

The lab stops at analysis.

Part 14 — Review Root Login Exposure

If SSH exists, inspect the approved configuration:

grep -E '^[[:space:]]*PermitRootLogin' /etc/ssh/sshd_config

where permitted.

Record:

Direct Root SSH:

Configuration:

Security Relevance:

Do not attempt root login.

Part 15 — Assess Linux Service Identities

List running services:

systemctl --type=service --state=running

Select several important services and determine their purpose.

Ask:

Which identity runs this service?

Services should generally avoid unnecessary root privileges where practical.

Part 16 — Examine Running Processes

Use:

ps aux

Focus on:

USER
PID
COMMAND

Create:

Process	Identity	Privilege	Expected
sshd	root/service context	Elevated	Review context
web app	web user	Restricted	Positive
lab service	root	Elevated	Review

A process running as root is not automatically a vulnerability.

Some operating-system services legitimately require elevated privileges.

Part 17 — Assess Service Privilege

For each important service ask:

Does it require this identity?

Could it use a dedicated service account?

Does it need filesystem write access?

Does it require administrative privileges?

What would compromise of this service expose?

This converts service enumeration into privilege analysis.

Part 18 — Review SUID Files

On the authorized Linux target:

find / -perm -4000 -type f 2>/dev/null

SUID files can execute with the file owner’s effective privileges under defined conditions.

Your task is only to inventory them.

Do not attempt to use SUID binaries for privilege escalation.

Part 19 — Build the SUID Inventory

Create:

Binary	Owner	Expected	Review
<binary>	root	Yes	Baseline
<lab binary>	root	Unknown	Investigate

Compare with the expected operating-system baseline where available.

Part 20 — Review SGID Files

Where appropriate:

find / -perm -2000 -type f 2>/dev/null

Again:

Inventory ≠ exploitation.

Determine whether entries are expected for the installed system.

Part 21 — Assess Linux Filesystem Privileges

Review approved training directories.

Example:

ls -ld /opt/labapp

and:

ls -l /opt/labapp

Record:

Owner:

Group:

Permissions:

Sensitive Content:

Writable By:

Expected:

Part 22 — Understand the Privilege Relationship

Consider:

Privileged Service
       │
       ▼
Application File
       │
       ▼
Writable by Standard User

That is a meaningful security relationship.

Your lab objective is to document:

A lower-privileged identity can modify a resource used by a higher-privileged component.

Do not modify the file to prove impact.

Part 23 — Review World-Writable Directories

Inventory:

find / -type d -perm -0002 2>/dev/null

Many legitimate writable locations may appear.

For example:

/tmp

may legitimately be world writable and protected by additional permission semantics such as the sticky bit.

Context matters.

Part 24 — Review Linux Scheduled Tasks

Inspect:

ls -la /etc/cron.d

and:

ls -la /etc/cron.daily

For your own account:

crontab -l

where available.

Do not edit scheduled tasks.

Part 25 — Analyze Scheduled-Task Privilege

For each relevant task determine:

Which identity runs it?

Which command/script does it execute?

Who owns that script?

Who can modify it?

What resources does it access?

Conceptually:

Privileged Scheduled Task
          │
          ▼
       Script
          │
          ▼
Writable by Lower-Privilege User

This can represent a dangerous privilege boundary.

Document only.

Part 26 — Build the Linux Privilege Matrix

Example:

Identity	Sudo	Services	Scheduled Tasks	Sensitive Write	Risk
root	Full	Many	Yes	Yes	Expected
lab-admin	Limited	No	No	Limited	Review
lab-user	No	No	No	App files	Review
web-user	No	Web	No	Web data	Expected

Part 27 — Record Positive Linux Controls

Examples:

Standard users are not members of sudo.

Web service runs under a dedicated account.

Sensitive configuration files are writable only by administrators.

Privileged scheduled scripts are protected from standard-user modification.

Professional assessments document these controls too.

Part 28 — Begin the Windows Assessment

Log in using the authorized Windows training account.

Open PowerShell.

Run:

whoami

Then:

whoami /user

and:

whoami /groups

Record:

Username:

SID:

Groups:

Integrity / Privilege Context:

Part 29 — Understand Windows Administrative Privilege

A Windows user may belong to:

Administrators

while User Account Control still affects how administrative actions are performed interactively.

Therefore:

Administrator Membership
        ≠
Every Process Always Fully Elevated

This distinction is important.

Part 30 — List Local Windows Users

Use:

Get-LocalUser

Review:

• account name

• enabled status

• description

• last logon where available

Do not access credential material.

Part 31 — List Local Groups

Use:

Get-LocalGroup

Identify security-sensitive groups.

The most obvious is:

Administrators

but other groups can also grant meaningful capabilities depending on system role.

Part 32 — Review Local Administrators

Use:

Get-LocalGroupMember -Group "Administrators"

Fallback:

net localgroup administrators

Create:

Account	Type	Administrative Need	Status
Administrator	Local	System administration	Expected
lab-admin	Local	Training admin	Expected
lab-user	Local	Unknown	Review

Part 33 — Review Account Status

For selected authorized accounts:

Get-LocalUser | Select-Object Name,Enabled,PasswordRequired,PasswordExpires,LastLogon

Availability of properties can vary.

Assess:

• unused enabled accounts

• unnecessary administrator accounts

• guest-style accounts

• stale training accounts

Do not change them.

Part 34 — Review Built-In Accounts

Check:

Get-LocalUser -Name "Administrator"

and, where present:

Get-LocalUser -Name "Guest"

Record:

Built-in Administrator Enabled:

Guest Enabled:

Security Context:

Account naming alone is not a strong security control.

Part 35 — Assess UAC Configuration

Read the relevant policy values:

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' |
Select-Object EnableLUA,ConsentPromptBehaviorAdmin,PromptOnSecureDesktop

Record:

UAC Enabled:

Admin Prompt Behavior:

Secure Desktop:

Assessment:

Do not disable or modify UAC.

Part 36 — Understand UAC

Conceptually:

Administrator Account
        │
        ▼
Standard Interactive Context
        │
        ▼
Administrative Action
        │
        ▼
UAC Decision
        │
        ▼
Elevated Context

UAC provides an important administrative boundary but is not a replacement for proper account separation or least privilege.

Part 37 — Review Windows Privileges

Run:

whoami /priv

This shows privileges associated with the current security token.

Do not attempt to abuse individual privileges.

Instead record:

Privilege:

State:

Why Present:

Expected:

Part 38 — Understand Windows Privileges vs Permissions

A privilege can grant a system-level capability.

A permission controls access to a particular object.

Conceptually:

Privilege
   ↓
System Capability

versus:

Permission
   ↓
Access to File / Registry / Object

Both matter during security assessment.

Part 39 — Review Windows Services

Use:

Get-Service

For additional service context:

Get-CimInstance Win32_Service |
Select-Object Name,StartName,State,StartMode,PathName

Focus on designated training services.

Part 40 — Identify Service Accounts

Review:

LocalSystem

LocalService

NetworkService

Dedicated Service Accounts

Ask:

Does this service need the privilege level under which it operates?

Part 41 — Build the Windows Service Privilege Register

Service	Identity	State	Privilege	Expected
<service>	LocalSystem	Running	High	Review
<service>	NetworkService	Running	Restricted	Expected
Lab App	lab-service	Running	Dedicated	Positive

Do not change service identities.

Part 42 — Review Service Executable Permissions

Select only a designated lab service.

Identify its executable path from the service information.

Then inspect the approved path:

Get-Acl "C:\LabApp\service.exe" | Format-List

or:

icacls C:\LabApp\service.exe

Ask:

Who owns the file?

Who can modify it?

Does a standard user have Write/Modify/FullControl?

Does a privileged service depend on it?

Part 43 — Understand the Risk Relationship

Suppose:

Service
   │
Runs as LocalSystem
   │
   ▼
C:\LabApp\Service.exe
   │
   ▼
Standard User Has Modify

That is a significant privilege-boundary concern.

You do not need to replace or modify the executable.

The permission relationship itself is evidence.

Part 44 — Review Service Configuration Carefully

A service may have:

PathName
StartName
StartMode

Document unexpected configuration.

Concepts such as poorly protected service paths may have security relevance, but this lab does not include exploitation.

Part 45 — Review Scheduled Tasks

Use:

Get-ScheduledTask |
Select-Object TaskName,TaskPath,State

Focus on the designated lab tasks.

Do not modify or manually trigger high-impact tasks.

Part 46 — Inspect a Specific Training Task

For an approved task:

Get-ScheduledTask -TaskName "LabTask"

Review:

Principal

Actions

Triggers

You can inspect these properties in PowerShell without changing the task.

Part 47 — Assess Task Privilege

Ask:

Which account runs the task?

Does it run with elevated privileges?

Which executable/script does it call?

Who owns that file?

Who can modify it?

Conceptually:

High-Privilege Task
       │
       ▼
Training Script
       │
       ▼
Standard User Write Access

Document the relationship.

Do not exploit it.

Part 48 — Review NTFS Permissions

For an approved training directory:

Get-Acl "C:\LabApp" | Format-List

or:

icacls C:\LabApp

Look for rights such as:

Read
Write
Modify
FullControl

and identities such as:

SYSTEM
Administrators
Users
Authenticated Users

Part 49 — Understand NTFS Inheritance

Permissions may be inherited from parent directories.

Conceptually:

C:\
 │
 ▼
LabApp
 │
 ▼
Config

A child resource may inherit access from its parent.

Do not report inherited permissions as insecure without analyzing what access they actually grant.

Part 50 — Review Sensitive Configuration Permissions

If the lab contains:

C:\LabApp\Config\

inspect the directory and designated configuration files.

Ask:

Can a standard user modify configuration consumed by a privileged process?

This is a strong privilege-assessment question.

Part 51 — Review Windows Shares

Where permitted:

Get-SmbShare

For a designated lab share:

Get-SmbShareAccess -Name "LabShare"

Remember:

Share permissions and NTFS permissions both matter.

Part 52 — Build a Share Privilege Matrix

Share	Principal	Share Access	NTFS Access	Expected
LabShare	Users	Read	Read	Yes
AdminShare	Administrators	Full	Full	Yes
SensitiveShare	Everyone	Full	Modify	Review

Administrative shares may be expected Windows behavior.

Context matters.

Part 53 — Assess Remote Administration Privilege

Review known services such as:

RDP
WinRM
SMB

Correlate with Lab 09 and Lab 04.

Ask:

Who can connect?

Which group grants access?

Is the service exposed beyond required networks?

Does access lead to administrative capability?

Do not enable or connect to services that are outside the mission.

Part 54 — Build the Windows Privilege Matrix

Example:

Identity	Admin	Service Rights	Task Rights	Sensitive Write	Risk
Administrator	Yes	High	High	High	Expected
lab-admin	Yes	Limited	Limited	High	Review
lab-user	No	None	None	App directory	Review
lab-service	No	Service only	None	App data	Positive

Part 55 — Compare Linux and Windows Privilege Models

Conceptually:

Linux	Windows
root	SYSTEM / Administrator
sudo	Administrative elevation
groups	Local/security groups
filesystem rwx	NTFS ACLs
cron	Scheduled Tasks
systemd services	Windows Services
SUID/SGID	Windows privileges/service contexts

They are not identical technologies.

But the assessment question is similar:

Who can cause a privileged component to perform or consume something?

Part 56 — Build the Cross-Platform Privilege Map

Example:

                     Privilege
                         │
            ┌────────────┴────────────┐
            ▼                         ▼
          Linux                     Windows
            │                         │
      ┌─────┼─────┐            ┌─────┼─────┐
      ▼     ▼     ▼            ▼     ▼     ▼
    sudo  Service Cron       Admin Service Task
      │     │     │            │     │     │
      └─────┼─────┘            └─────┼─────┘
            ▼                         ▼
         Resources                 Resources
            │                         │
            └────────────┬────────────┘
                         ▼
                   Security Impact

Part 57 — Identify Privilege Boundaries

Examples:

Standard User → Administrator

Web User → root

Application User → SYSTEM

Service Account → Sensitive Database

Normal User → Protected Configuration

The boundary is important because crossing it changes security impact.

Part 58 — Identify Privilege Relationships

Create:

Source Identity	Resource	Higher-Privilege Consumer	Relationship
lab-user	app.conf	root service	Write
Users	LabTask.ps1	SYSTEM task	Modify
web-user	upload dir	web service	Expected

This is one of the most valuable deliverables in the lab.

Part 59 — Understand Privilege Concentration

Suppose one account has:

Local Administrator
+
Database Administrator
+
Backup Access
+
Remote Administration

This creates significant privilege concentration.

Ask:

Does one identity require all of these capabilities?

Concentrated privilege increases potential impact if the account is compromised.

Part 60 — Review Separation of Duties

Consider whether sensitive functions are appropriately separated.

Example:

Developer
    ↓
Application Code

versus:

Administrator
    ↓
Production Deployment

In enterprise environments, sensitive functions may require separation to reduce fraud, mistakes, or compromise impact.

Part 61 — Identify Excessive Privilege

Examples can include:

• unnecessary local administrator membership

• broad sudo access

• service running with more privilege than required

• standard user modifying privileged application files

• privileged task executing a broadly writable script

• excessive share permissions

• unused privileged account

• excessive service-account access

But every finding requires context.

Part 62 — Distinguish Exposure from Exploitability

Suppose:

Standard User
     ↓
Write Access
     ↓
Privileged Service Configuration

You can report:

A potentially dangerous privilege relationship exists.

You do not need to demonstrate code execution.

This distinction is important:

Security Exposure
       ≠
Need to Exploit

Part 63 — Build the Privilege Risk Model

Use:

Privilege Level + Resource Sensitivity + Modification Capability + Exposure + Business Importance

Example:

Standard User
      +
Write Access
      +
SYSTEM Service Binary
      +
Critical Server
      =
High Priority

Part 64 — Finding Example: Excessive Administrative Membership

Finding:
Standard training user has unnecessary local administrator access.

Observation:
The account was identified as a member of the local
Administrators group despite its documented standard-user role.

Security Relevance:
Compromise or misuse of the account could provide significantly
greater system access than required for its intended function.

Recommendation:
Remove unnecessary administrative membership and provide
separate controlled administrative access where required.

Part 65 — Finding Example: Excessive sudo

Finding:
Linux user has broader sudo permissions than required.

Observation:
The authorized account's sudo configuration permits
administrative operations beyond its documented operational role.

Security Relevance:
Excessive sudo rights increase the impact of account compromise
or misuse.

Recommendation:
Restrict sudo permissions to explicitly required administrative
functions and periodically review assignments.

Part 66 — Finding Example: Privileged Service Uses Writable File

Finding:
Privileged service depends on a resource writable by a
lower-privileged user.

Observation:
The designated service operates under an elevated identity while
its application file or configuration can be modified by a
standard training user.

Security Relevance:
The permission relationship weakens the boundary between the
standard user and the privileged service.

Recommendation:
Restrict modification rights to trusted administrative or
service identities and validate ownership of privileged service
resources.

Part 67 — Positive Control Example

Positive Control:
Application service uses a dedicated low-privilege identity.

Evidence:
The training application process runs under a dedicated service
account that is not a member of administrative groups.

Security Value:
Compromise of the application is less likely to provide
unnecessary operating-system privileges.

Part 68 — Build the Privilege Risk Register

ID	Platform	Identity	Privilege/Resource	Observation	Risk
PRIV-01	Linux	lab-user	sudo	Excessive access	High
PRIV-02	Linux	web-user	web service	Restricted identity	Positive
PRIV-03	Windows	lab-user	Administrators	Unnecessary membership	High
PRIV-04	Windows	Users	LabApp	Modify permission	Medium/High
PRIV-05	Windows	lab-service	Service	Dedicated identity	Positive

Part 69 — Assign Confidence

Use:

Confirmed

Direct configuration or permission evidence exists.

Probable

Evidence strongly indicates the relationship but additional context is required.

Possible

Potential privilege issue requiring validation.

Expected

Privilege matches documented system requirements.

Positive Control

Configuration demonstrates effective least privilege.

Part 70 — Remediation Principles

Remove Unnecessary Administrative Access

Avoid routine administrator/root access.

Use Dedicated Administrative Accounts

Separate standard work from privileged administration.

Restrict sudo

Grant only necessary administrative commands.

Use Dedicated Service Accounts

Avoid running applications as root or SYSTEM when unnecessary.

Protect Service Resources

Privileged executables and configuration files should not be modifiable by lower-privileged identities.

Protect Scheduled Tasks

Scripts and executables invoked by privileged tasks require strong permissions.

Review Groups Regularly

Remove stale or unnecessary memberships.

Apply Least Privilege to Shares

Avoid unnecessarily broad access.

Review Privileged Accounts

Identify dormant, unused, or duplicate privileged identities.

Monitor Privileged Activity

Administrative operations should produce useful security telemetry.

Part 71 — Create the Privilege Baseline

Document:

Linux Privileged Users:

Linux Sudo Users:

Linux Privileged Services:

Linux SUID/SGID Baseline:

Linux Privileged Tasks:

Windows Administrators:

Windows Privileged Services:

Windows Elevated Tasks:

Sensitive Files:

Sensitive Directories:

Privileged Shares:

Remote Administration Groups:

This baseline can later support detection and incident response.

Part 72 — Evidence Requirements

Capture:

Evidence 01

Linux current identity.

Evidence 02

Linux group membership.

Evidence 03

UID 0 accounts.

Evidence 04

Relevant privileged groups.

Evidence 05

Authorized sudo -l output.

Evidence 06

Relevant Linux service identities.

Evidence 07

SUID/SGID inventory.

Evidence 08

Approved Linux filesystem permissions.

Evidence 09

Linux scheduled-task configuration.

Evidence 10

Windows current identity.

Evidence 11

Windows group membership.

Evidence 12

Local Administrators membership.

Evidence 13

UAC configuration.

Evidence 14

Windows token privileges.

Evidence 15

Relevant service identities.

Evidence 16

Approved service-file ACL.

Evidence 17

Scheduled-task privilege.

Evidence 18

NTFS permissions.

Evidence 19

Share permissions where applicable.

Evidence 20

Linux Privilege Matrix.

Evidence 21

Windows Privilege Matrix.

Evidence 22

Cross-Platform Privilege Map.

Evidence 23

Privilege Risk Register.

Evidence 24

Positive controls.

Part 73 — Mission Challenge

Assess both training hosts and complete:

LINUX

Current User:

Groups:

UID 0 Accounts:

Sudo Access:

Privileged Groups:

Root-Running Services:

Dedicated Service Accounts:

SUID Files Reviewed:

SGID Files Reviewed:

Privileged Scheduled Tasks:

Sensitive Writable Resources:

Positive Controls:

Highest-Risk Privilege Relationship:


WINDOWS

Current User:

Groups:

Local Administrators:

Built-in Administrator:

Guest:

UAC Enabled:

Current Token Privileges:

SYSTEM Services Reviewed:

Dedicated Service Accounts:

Scheduled Tasks Reviewed:

Sensitive NTFS Permissions:

Share Permissions:

Remote Administration Privilege:

Positive Controls:

Highest-Risk Privilege Relationship:


OVERALL

Most Privileged Identity:

Most Sensitive Resource:

Most Significant Excessive Privilege:

Strongest Least-Privilege Control:

Highest-Priority Remediation:

Final Assessment:

Part 74 — What Not to Do

This lab does not require:

Privilege escalation

SUID exploitation

sudo abuse

Shell spawning

UAC bypass

Service exploitation

Service binary replacement

Scheduled-task modification

DLL hijacking

Credential dumping

SAM extraction

LSASS access

Password hash extraction

Token theft

Impersonation

Registry manipulation

Administrator creation

Persistence

Security-control disabling

Your job ends when sufficient evidence exists to demonstrate the privilege relationship.

Assessment before exploitation. Evidence before assumption.

Part 75 — Troubleshooting

sudo -l Requires a Password

Use only the password assigned to your authorized lab account.

Do not attempt to obtain another user’s credentials.

Permission Denied When Inspecting a Resource

Document:

Access Denied

This may itself demonstrate an effective security boundary.

Do not bypass the restriction.

Get-LocalUser Is Unavailable

Use:

net user

For administrators:

net localgroup administrators

Service Details Require Elevation

Record the information available to your assigned account.

Do not escalate merely to complete the checklist.

Get-Acl Shows Many Entries

Focus on principals with meaningful modification capabilities:

Users
Authenticated Users
Everyone
Administrators
SYSTEM
Designated Service Accounts

Many SUID Files Appear

This is normal on many Linux systems.

Compare them with the expected baseline rather than reporting every SUID file.

Mission Deliverables

Complete:

• scope confirmed

• Linux identity assessed

• Linux groups assessed

• UID 0 accounts reviewed

• sudo rights reviewed

• privileged Linux services reviewed

• service identities documented

• SUID/SGID inventory reviewed

• Linux filesystem privilege reviewed

• Linux scheduled tasks reviewed

• Windows identity assessed

• local groups reviewed

• local administrators reviewed

• UAC reviewed

• Windows token privileges reviewed

• Windows services reviewed

• service executable permissions reviewed

• scheduled tasks reviewed

• NTFS permissions reviewed

• share privileges reviewed where applicable

• remote-administration privilege reviewed

• Linux Privilege Matrix created

• Windows Privilege Matrix created

• cross-platform privilege map created

• excessive privileges identified

• positive controls documented

• Privilege Risk Register completed

• remediation priorities created

• evidence collected

• final report completed

Lab Report Template

# Lab 16 — Privilege Assessment

## Executive Summary

## Mission Objective

## Scope

## Assessment Methodology

## Linux Privilege Assessment

### Users and Groups
### Sudo Rights
### Service Identities
### SUID and SGID
### Scheduled Tasks
### Filesystem Permissions

## Windows Privilege Assessment

### Users and Groups
### Local Administrators
### UAC
### Token Privileges
### Service Identities
### Scheduled Tasks
### NTFS Permissions
### Shares
### Remote Administration

## Privilege Matrices

## Privilege Relationships

## Security Boundaries

## Excessive Privilege

## Least-Privilege Assessment

## Positive Security Controls

## Privilege Risk Register

## Findings

## Risk Prioritization

## Recommendations

## Evidence

## Limitations

## Lessons Learned

## Conclusion

Knowledge Check

Question 1 — What is least privilege?

Granting an identity only the permissions required to perform its legitimate function.

Question 2 — Does membership in a privileged group automatically mean a vulnerability exists?

No.

The privilege must be evaluated against the account’s intended role and business need.

Question 3 — Why review sudo -l?

It shows which elevated operations the authorized Linux account is permitted to perform, allowing the assessor to evaluate whether those permissions are excessive.

Question 4 — Should you exploit an unusual SUID binary during this lab?

No.

Document its presence, ownership, purpose, and security relevance.

Question 5 — Why examine service identities?

Because a compromised service may inherit the permissions of the identity under which it operates.

Question 6 — Why are writable files used by privileged services important?

Because they can weaken the security boundary between lower-privileged users and higher-privileged components.

Question 7 — What does Windows UAC provide?

A mechanism that helps control and mediate administrative elevation for interactive Windows activity.

Question 8 — Are SYSTEM services automatically vulnerabilities?

No.

Many Windows services legitimately require high privilege. The question is whether that privilege is necessary and whether associated resources are properly protected.

Question 9 — Why inspect scheduled tasks?

Because scheduled tasks can execute applications or scripts under identities with privileges different from the user who can modify the underlying resources.

Question 10 — Do you need to achieve administrator/root access to prove excessive privilege?

No.

A defensible configuration and permission relationship can be sufficient evidence.

Skills Achieved

After completing this lab, you should understand:

• identity vs privilege

• least privilege

• Linux users and groups

• UID 0 accounts

• sudo assessment

• Linux service identities

• SUID/SGID awareness

• Linux filesystem permissions

• cron privilege assessment

• Windows local users

• Windows Administrators

• UAC

• Windows token privileges

• Windows service identities

• NTFS permissions

• Windows scheduled tasks

• SMB share permissions

• remote-administration privilege

• privileged resource relationships

• security boundaries

• privilege concentration

• separation of duties

• excessive-privilege identification

• positive-control documentation

• privilege risk prioritization

• professional privilege reporting

Professional Takeaway

Privilege assessment is not:

“Can I become root or SYSTEM?”

The professional question is:

“Which identities already possess elevated capabilities, what resources can they influence, are those privileges necessary, and what would happen if the identity were compromised?”

A strong assessor thinks in relationships:

Identity
   ↓
Privilege
   ↓
Resource
   ↓
Higher-Privilege Component
   ↓
Potential Impact

The central principle is:

The existence of privilege is not automatically a vulnerability. Unnecessary, excessive, poorly protected, or unjustified privilege creates risk.

And unlike an exploitation exercise, you do not need to cross the security boundary to prove that it is weak.

What’s Next?

➡️ Lab 17 — Network Segmentation Assessment

You have assessed individual hosts, services, applications, traffic, DNS, and privilege boundaries.

The next question is:

Should these systems be able to communicate with each other in the first place?

In Lab 17, you will assess:

• network zones

• trust boundaries

• source and destination relationships

• permitted network paths

• restricted network paths

• firewall policy behavior

• management-plane exposure

• user-to-server connectivity

• server-to-server communication

• segmentation between security zones

• expected vs observed connectivity

• least-access networking

• segmentation evidence

• remediation priorities

The methodology becomes:

Source → Zone → Destination → Service → Expected Policy → Observed Result → Risk

By the end of Lab 17, you should be able to answer:

“Which systems can communicate across trust boundaries, which paths are legitimately required, and where does unnecessary connectivity weaken network segmentation?”