created instruction files for my home OSCP labs

This commit is contained in:
2026-06-29 21:27:45 -04:00
commit 2004f53e08
26 changed files with 2509 additions and 0 deletions

185
README.md Normal file
View File

@@ -0,0 +1,185 @@
# OSCP Enterprise Homelab
> A fully documented, enterprise-inspired cybersecurity lab built on Proxmox for practicing penetration testing, Active Directory exploitation, privilege escalation, pivoting, web application attacks, and professional reporting.
---
## Overview
This repository documents the design, deployment, and operation of a reusable cybersecurity lab that closely resembles a small enterprise network.
The primary goal is to create a repeatable environment where attacks can be practiced safely and reset to a known-good state using Proxmox snapshots.
Unlike many "vulnerable VM" collections, this lab emphasizes realistic infrastructure and attack paths. Machines exist for a reason, users belong to departments, and services are deployed similarly to what an internal penetration tester would encounter.
---
## Objectives
* Learn enterprise networking
* Build an Active Directory environment
* Practice OSCP-style methodology
* Learn Windows and Linux privilege escalation
* Practice web application testing
* Practice buffer overflow exploitation
* Learn lateral movement and pivoting
* Build professional documentation habits
* Maintain a reusable cyber range
---
## Lab Architecture
```text
Internet
|
Home Router
|
Proxmox
|
vmbr0 (WAN)
|
pfSense
+-----------+-----------+
| |
vmbr1 (Attack) vmbr2 (Corporate)
| |
Kali Linux Active Directory
Windows Clients
SQL Server
File Server
Linux Targets
Buffer Overflow VM
vmbr3 (DMZ)
|
Public Web Targets
```
---
## Repository Layout
```text
homelab/
├── README.md
├── diagrams/
├── docs/
├── playbooks/
└── assets/
```
### Documentation
| File | Purpose |
| -------------------------- | --------------------------------------- |
| 01-proxmox.md | Proxmox installation and virtualization |
| 02-pfsense.md | Firewall and routing |
| 03-networking.md | Network design and IP addressing |
| 04-active-directory.md | Domain deployment |
| 05-kali.md | Attacker workstation |
| 06-vulnerable-machines.md | Windows/Linux targets |
| 07-pivoting.md | Internal routing and tunneling |
| 08-buffer-overflow.md | Dedicated BOF machine |
| 09-web-attacks.md | Web application testing |
| 10-privilege-escalation.md | Windows/Linux PrivEsc |
| 11-attack-methodology.md | Full penetration testing workflow |
| 12-resetting-the-lab.md | Snapshots and restoration |
| troubleshooting.md | Common issues |
---
## IP Addressing
| Network | Purpose |
| -------------- | ---------------------- |
| 192.168.1.0/24 | Home LAN |
| 10.10.10.0/24 | Attacker Network |
| 10.10.20.0/24 | Internal Corporate LAN |
| 10.10.30.0/24 | DMZ |
---
## Virtual Machines
| Machine | Purpose |
| ---------- | -------------------------- |
| pfSense | Firewall and routing |
| Kali Linux | Attacker workstation |
| DC01 | Active Directory |
| WIN10-01 | Domain workstation |
| WIN10-02 | Domain workstation |
| FILE01 | SMB enumeration |
| SQL01 | MSSQL attacks |
| WEB01 | Web exploitation |
| LINUX01 | Linux privilege escalation |
| BOF-WIN7 | Buffer overflow practice |
| PIVOT01 | Pivoting and tunneling |
---
## Learning Workflow
Each exercise should follow the same methodology:
1. Reconnaissance
2. Enumeration
3. Vulnerability Identification
4. Initial Access
5. Privilege Escalation
6. Credential Harvesting
7. Pivoting
8. Lateral Movement
9. Domain Compromise
10. Documentation
11. Restore Snapshot
---
## Snapshot Philosophy
Every virtual machine should maintain at least one baseline snapshot.
Recommended naming convention:
```
BASE_INSTALL
DOMAIN_JOINED
VULNERABLE
READY_FOR_ATTACK
```
Rollback should always return the machine to a known state within seconds.
---
## Documentation Standards
Every completed attack should include:
* Objective
* Enumeration
* Exploitation
* Privilege Escalation
* Screenshots
* Commands Used
* Lessons Learned
* Detection Opportunities
* Mitigations
---
## Long-Term Goals
Future improvements include:
* SIEM integration
* Wazuh
* Sysmon
* BloodHound
* Elastic Stack
* Terraform
* Ansible
* Automated lab deployment
* Continuous lab documentation through Wiki.js

0
diagrams/ad.mmd Normal file
View File

0
diagrams/attack-flow.mmd Normal file
View File

0
diagrams/network.mmd Normal file
View File

0
diagrams/proxmox.mmd Normal file
View File

535
docs/01-proxmox.md Normal file
View File

@@ -0,0 +1,535 @@
# Chapter 1 - Proxmox Infrastructure
> This chapter covers the installation and configuration of the Proxmox virtualization environment that serves as the foundation for the entire cyber range.
---
# Objectives
After completing this chapter you should have:
* A working Proxmox VE server
* Virtual networking configured
* Storage configured
* VM templates prepared
* Snapshot strategy planned
* A scalable architecture capable of supporting an enterprise penetration testing lab
---
# Hardware
My lab consists of a single Proxmox server.
Minimum recommendations:
| Component | Recommendation |
| --------- | -------------------------------------: |
| CPU | 8+ Threads with virtualization support |
| RAM | 32 GB minimum |
| Storage | 500 GB SSD |
| Network | One Gigabit Ethernet adapter |
One physical network adapter is sufficient because all internal networks will exist as virtual bridges.
---
# Virtualization Extensions
Verify virtualization is enabled in BIOS.
AMD
```bash
egrep "(svm)" /proc/cpuinfo
```
Intel
```bash
egrep "(vmx)" /proc/cpuinfo
```
---
# Install Proxmox
1. Download the latest ISO.
2. Create a bootable USB drive.
3. Install Proxmox.
4. Configure:
* Hostname
* Management IP
* DNS
* Gateway
5. Log into the web interface.
Example:
```
https://192.168.1.100:8006
```
---
# Storage Layout
Recommended layout:
```
Local
ISO Images
Local-LVM
Virtual Machine Disks
Templates
VM Templates
Backups
vzdump Backups
```
As the lab grows, consider moving VM disks to dedicated SSD storage.
---
# Virtual Networking
The cyber range is isolated using Linux bridges.
```
Internet
|
Home Router
|
eno1
|
vmbr0
```
vmbr0 is connected to the physical NIC.
Additional bridges are completely virtual.
```
vmbr1
Attack Network
vmbr2
Corporate LAN
vmbr3
DMZ
```
No physical interfaces are attached to these bridges.
This creates isolated virtual switches inside Proxmox.
---
# Creating Linux Bridges
Navigate to:
```
Node
└── System
└── Network
```
Create:
## vmbr1
Type
```
Linux Bridge
```
Bridge Ports
```
(blank)
```
IPv4
```
None
```
IPv6
```
None
```
Repeat for:
```
vmbr2
vmbr3
```
Apply configuration.
---
# Bridge Purposes
## vmbr0
Management network.
Contains:
* Proxmox
* pfSense WAN
---
## vmbr1
Attack network.
Contains:
* Kali Linux
Subnet
```
10.10.10.0/24
```
---
## vmbr2
Corporate network.
Contains:
* Domain Controller
* Windows Clients
* File Server
* SQL Server
* Linux Target
Subnet
```
10.10.20.0/24
```
---
## vmbr3
DMZ
Contains:
* Vulnerable Web Server
Subnet
```
10.10.30.0/24
```
---
# VM Naming Convention
Maintain consistent naming.
Examples:
```
DC01
```
```
WIN10-01
```
```
WIN10-02
```
```
WEB01
```
```
FILE01
```
```
SQL01
```
```
BOF-WIN7
```
```
PIVOT01
```
```
KALI
```
---
# VM Hardware Standards
## Kali
CPU
```
2
```
Memory
```
4096 MB
```
Disk
```
80 GB
```
Bridge
```
vmbr1
```
---
## Windows Workstations
CPU
```
2
```
Memory
```
4096 MB
```
Disk
```
80 GB
```
---
## Windows Server
CPU
```
2-4
```
Memory
```
4096-8192 MB
```
Disk
```
100 GB
```
---
# VirtIO Drivers
For Windows virtual machines:
* Attach the VirtIO ISO.
* Install storage drivers during Windows setup.
* Install the VirtIO guest tools after installation.
Benefits:
* Better disk performance
* Better network performance
* Improved stability
---
# VM Templates
Create reusable templates.
Recommended templates:
```
Ubuntu Server
```
```
Windows Server 2022
```
```
Windows 10
```
```
Kali Linux
```
Convert each into a Proxmox template after completing:
* Updates
* Guest Agent
* VirtIO drivers
* Basic configuration
Future machines can be cloned in seconds.
---
# Snapshots
Snapshots are one of the biggest advantages of using Proxmox.
Recommended snapshot workflow:
```
Fresh Install
```
```
Patched
```
```
Configured
```
```
Vulnerable
```
```
Ready for Attack
```
If a machine becomes unstable after exploitation:
```
Rollback
```
and continue practicing.
---
# Backups
Snapshots are not backups.
Use Proxmox Backup jobs to protect:
* Domain Controller
* pfSense
* Wiki.js
* Gitea
Recommended schedule:
```
Nightly
```
Keep multiple restore points.
---
# Best Practices
✔ Use VirtIO devices whenever possible.
✔ Allocate only the RAM required.
✔ Enable the QEMU Guest Agent.
✔ Use static IP addresses for infrastructure.
✔ Name every VM consistently.
✔ Snapshot every vulnerable machine.
✔ Keep ISO images organized.
✔ Document every configuration change in Wiki.js.
---
# Validation Checklist
Before moving to the next chapter:
* [ ] Proxmox installed
* [ ] vmbr0 configured
* [ ] vmbr1 created
* [ ] vmbr2 created
* [ ] vmbr3 created
* [ ] ISO library populated
* [ ] VM templates created
* [ ] Snapshot strategy documented
* [ ] Backup strategy configured
---
# Next Chapter
The next chapter covers pfSense.
Topics include:
* Creating multiple virtual NICs
* Assigning interfaces
* WAN configuration
* LAN configuration
* DMZ configuration
* Firewall rules
* DHCP
* NAT
* DNS
* Static mappings
* Routing between virtual networks
* Internet access for the cyber range
* Isolating the lab from the home network

449
docs/02-pfsense.md Normal file
View File

@@ -0,0 +1,449 @@
# Chapter 2 - pfSense Configuration
> This chapter covers the deployment and configuration of pfSense as the virtual firewall and router for the cyber range.
---
# Objectives
After completing this chapter you should have:
* A functioning pfSense firewall
* Four virtual interfaces
* Internet access for every lab network
* Network isolation between lab segments
* DHCP configured (optional)
* Static addressing plan
* Firewall rules documented
* A secure foundation for the remainder of the lab
---
# Why pfSense?
Rather than allowing Proxmox to route traffic directly, pfSense simulates what you would find in a real enterprise:
* Stateful firewall
* Router
* DHCP server
* DNS resolver
* NAT gateway
* VPN support
* Traffic monitoring
Every packet in the lab will flow through pfSense.
---
# Network Topology
```text
Internet
|
Home Router
|
vmbr0
|
pfSense
+----------------+----------------+
| | |
vmbr1 vmbr2 vmbr3
Attack LAN Corporate LAN DMZ
10.10.10.0 10.10.20.0 10.10.30.0
```
Only **vmbr0** is connected to a physical network adapter.
Everything else is virtual.
---
# Creating the pfSense VM
Recommended hardware:
| Resource | Value |
| -------- | ----------: |
| CPU | 2 vCPU |
| Memory | 24 GB |
| Disk | 20 GB |
| BIOS | OVMF (UEFI) |
| Machine | q35 |
---
# Network Adapters
Before installation, add four network adapters.
| Adapter | Bridge |
| ------- | ------ |
| NIC 1 | vmbr0 |
| NIC 2 | vmbr1 |
| NIC 3 | vmbr2 |
| NIC 4 | vmbr3 |
Use the **VirtIO** model for all adapters.
---
# Interface Assignment
During installation, assign the interfaces:
| Interface | Purpose |
| --------- | ------- |
| WAN | vmbr0 |
| LAN | vmbr1 |
| OPT1 | vmbr2 |
| OPT2 | vmbr3 |
After installation, rename the interfaces if desired:
* WAN
* ATTACK
* INTERNAL
* DMZ
Using descriptive names makes firewall rules much easier to understand.
---
# IP Addressing
## WAN
Obtain an address from your home router using DHCP.
Example:
```text
192.168.1.150/24
Gateway: 192.168.1.1
```
---
## Attack Network
Interface:
ATTACK
Address:
```text
10.10.10.1/24
```
---
## Corporate Network
Interface:
INTERNAL
Address:
```text
10.10.20.1/24
```
---
## DMZ
Interface:
DMZ
Address:
```text
10.10.30.1/24
```
---
# DHCP
You can either use DHCP or assign static IPs.
For learning purposes, static addresses are recommended for infrastructure servers.
If DHCP is enabled:
Attack LAN
```
10.10.10.100
to
10.10.10.199
```
Corporate
```
10.10.20.100
to
10.10.20.199
```
DMZ
```
10.10.30.100
to
10.10.30.199
```
---
# DNS
Initially use the pfSense DNS Resolver.
Later, after deploying Active Directory:
Corporate clients should use
```
10.10.20.10
```
(the Domain Controller)
This allows Active Directory to manage DNS.
---
# NAT
Navigate to
```
Firewall
→ NAT
→ Outbound
```
Leave NAT in **Automatic** mode initially.
This allows every internal network to access the Internet.
Later, if desired, experiment with Hybrid or Manual NAT.
---
# Firewall Rules
By default, only the LAN interface has an allow rule.
You must create rules for the other interfaces.
## ATTACK
Allow:
```
Source:
ATTACK net
Destination:
Any
```
---
## INTERNAL
Allow:
```
Source:
INTERNAL net
Destination:
Any
```
---
## DMZ
Initially allow:
```
DMZ net
Any
```
Later, harden the rules by restricting access.
---
# Future Hardening
Once the lab is working, tighten the rules.
Example:
* DMZ cannot initiate connections to INTERNAL.
* INTERNAL cannot access ATTACK except for specific services.
* ATTACK can scan all networks.
This creates realistic segmentation.
---
# Static Mappings
Infrastructure servers should always use static addresses.
Recommended:
| Machine | Address |
| ------- | ----------- |
| pfSense | 10.10.10.1 |
| DC01 | 10.10.20.10 |
| FILE01 | 10.10.20.70 |
| SQL01 | 10.10.20.80 |
| WEB01 | 10.10.30.10 |
| Kali | 10.10.10.10 |
---
# Testing Connectivity
From Kali:
```bash
ping 10.10.10.1
```
```bash
ping 10.10.20.10
```
```bash
ping 10.10.30.10
```
Internet connectivity:
```bash
ping 1.1.1.1
```
DNS:
```bash
nslookup google.com
```
---
# Useful pfSense Features
As the lab grows, explore:
* OpenVPN
* WireGuard
* HAProxy
* ACME (Let's Encrypt)
* Traffic Graphs
* Packet Capture
* Diagnostics
* States Table
* ARP Table
These tools are valuable for both administration and troubleshooting.
---
# Backup Strategy
After completing the configuration:
Navigate to:
```
Diagnostics
→ Backup & Restore
```
Export the configuration file.
Store it in your Gitea repository or a secure backup location.
This allows rapid recovery of the firewall configuration.
---
# Troubleshooting
### No Internet Access
* Verify WAN received an IP address.
* Check the default gateway.
* Ensure Automatic Outbound NAT is enabled.
### Cannot Reach Another Subnet
* Verify the VM is connected to the correct Proxmox bridge.
* Confirm the gateway points to pfSense.
* Check firewall rules on the source interface.
### DNS Fails
* Test with:
```bash
ping 1.1.1.1
```
If this works but domain names fail, review DNS settings.
### VM Cannot Reach pfSense
Verify:
* Bridge assignment in Proxmox
* Static IP configuration
* Default gateway
* Firewall rules
---
# Validation Checklist
Before continuing:
* [ ] pfSense installed
* [ ] Four interfaces configured
* [ ] WAN has Internet access
* [ ] ATTACK network operational
* [ ] INTERNAL network operational
* [ ] DMZ operational
* [ ] NAT working
* [ ] DNS working
* [ ] Firewall rules created
* [ ] Configuration backup exported
---
# Next Chapter
The next chapter focuses on networking concepts used throughout the lab, including:
* IP addressing strategy
* Static vs DHCP
* Routing
* VLANs vs Linux bridges
* Dual-homed hosts
* Pivoting concepts
* Traffic flow between networks
* Preparing the environment for Active Directory

502
docs/03-networking.md Normal file
View File

@@ -0,0 +1,502 @@
# Chapter 3 - Networking
> Understanding how traffic flows through the cyber range is one of the most important skills for penetration testing. Before attacking systems, you should understand exactly how hosts communicate, how routers forward packets, and how segmentation affects an attack.
---
# Objectives
After completing this chapter you should understand:
* IPv4 addressing
* Subnets
* Default gateways
* DNS
* Routing
* NAT
* Virtual bridges
* Firewall segmentation
* Dual-homed systems
* Attack paths within the lab
---
# Enterprise Network Overview
Our lab is designed to simulate a small business.
```text
Internet
|
Home Router
|
192.168.1.0/24
|
Proxmox Host
|
vmbr0
|
pfSense
+------------------+------------------+
| | |
vmbr1 vmbr2 vmbr3
Attack LAN Corporate LAN DMZ
10.10.10.0/24 10.10.20.0/24 10.10.30.0/24
```
Only **pfSense** connects these networks together.
No VM can communicate between networks unless pfSense routes the traffic.
---
# IP Addressing Plan
## Home Network
Purpose
Management only.
Subnet
```text
192.168.1.0/24
```
Example
```text
Router 192.168.1.1
Proxmox 192.168.1.100
pfSense WAN 192.168.1.150
```
---
## Attack Network
Subnet
```text
10.10.10.0/24
```
Gateway
```text
10.10.10.1
```
Hosts
```text
Kali
Pivot Host
```
---
## Corporate Network
Subnet
```text
10.10.20.0/24
```
Gateway
```text
10.10.20.1
```
Hosts
```text
DC01
WIN10-01
WIN10-02
FILE01
SQL01
LINUX01
BOF-WIN7
```
---
## DMZ
Subnet
```text
10.10.30.0/24
```
Gateway
```text
10.10.30.1
```
Hosts
```text
WEB01
```
---
# Static Addressing
Infrastructure should always use static IP addresses.
Example:
| Machine | Address |
| ------- | ----------- |
| pfSense | 10.10.10.1 |
| Kali | 10.10.10.10 |
| DC01 | 10.10.20.10 |
| FILE01 | 10.10.20.70 |
| SQL01 | 10.10.20.80 |
| WEB01 | 10.10.30.10 |
This prevents services from changing addresses unexpectedly.
---
# Default Gateway
A default gateway is where traffic is sent when the destination is outside the local subnet.
Example:
Kali
```text
IP Address : 10.10.10.10
Mask : 255.255.255.0
Gateway : 10.10.10.1
```
Suppose Kali connects to:
```text
10.10.20.10
```
Since that address is outside the local subnet, Kali forwards the packet to **10.10.10.1 (pfSense)**.
pfSense then forwards the traffic to the Corporate LAN.
---
# Packet Flow
Example:
Kali scans the Domain Controller.
```text
Kali
10.10.10.10
|
|
V
pfSense
10.10.10.1
10.10.20.1
|
|
V
DC01
10.10.20.10
```
Understanding this flow is critical when troubleshooting firewall rules or pivoting.
---
# DNS
Initially:
Clients use pfSense.
Later:
Corporate machines should use the Domain Controller as their DNS server.
```text
10.10.20.10
```
This enables:
* Active Directory
* Kerberos
* LDAP
* Group Policy
* Service discovery
---
# Linux Bridges
A Linux bridge acts like a virtual Ethernet switch.
```text
vmbr2
+--------+--------+
| | |
WIN10 FILE01 SQL01
```
No routing occurs inside a bridge.
Routing only occurs through pfSense.
---
# Why We Don't Need More Physical NICs
Many beginners think each network requires another Ethernet port.
Not in virtualization.
Each Linux bridge is an isolated virtual switch.
Because every VM exists on the same Proxmox host:
* vmbr1
* vmbr2
* vmbr3
are completely independent even though only vmbr0 uses a physical cable.
This is one of the biggest advantages of virtualization.
---
# Dual-Homed Hosts
A dual-homed host has two network interfaces.
Example:
```text
NIC 1
10.10.10.20
NIC 2
10.10.20.50
```
This machine exists on two networks simultaneously.
It becomes useful for learning:
* Ligolo-ng
* Chisel
* SSH tunneling
* SOCKS proxies
* Meterpreter routing
---
# Network Segmentation
Our lab intentionally separates systems.
Attack Network
* Kali
Corporate
* Users
* Servers
* Active Directory
DMZ
* Public web server
This mirrors a real enterprise where servers and user devices are not placed on the same network.
---
# Example Attack Path
A typical penetration test might follow this route:
```text
Internet
|
V
WEB01
|
Privilege Escalation
|
Credentials
|
Pivot Host
|
Corporate LAN
|
Windows Workstation
|
Domain Controller
|
Domain Admin
```
This sequence demonstrates how attackers rarely compromise a domain controller directly.
---
# Common Networking Commands
Linux
Show interfaces
```bash
ip addr
```
Show routes
```bash
ip route
```
Ping
```bash
ping 10.10.20.10
```
DNS lookup
```bash
nslookup lab.local
```
Traceroute
```bash
traceroute 10.10.20.10
```
---
Windows
Display configuration
```powershell
ipconfig /all
```
Show routing table
```powershell
route print
```
Test connectivity
```powershell
ping 10.10.20.10
```
DNS
```powershell
nslookup dc01.lab.local
```
---
# Troubleshooting
### Cannot Reach Another Network
Check:
* Correct IP address
* Correct subnet mask
* Correct gateway
* Firewall rules
* Bridge assignment
---
### Internet Doesn't Work
Verify:
* WAN IP
* Gateway
* NAT
* DNS
---
### Hosts Cannot Resolve Names
Verify:
* DNS server
* Active Directory DNS
* pfSense DNS Resolver
---
### VM Cannot Communicate
Check:
* Proxmox bridge
* NIC status
* IP address
* Gateway
* pfSense rules
---
# Validation Checklist
Before moving to the next chapter:
* [ ] Understand the purpose of each subnet
* [ ] Verify every VM has the correct gateway
* [ ] Confirm Internet access from Kali
* [ ] Confirm Kali can reach the Corporate LAN
* [ ] Confirm Kali can reach the DMZ
* [ ] Verify DNS resolution
* [ ] Understand packet flow through pfSense
* [ ] Understand why Linux bridges replace physical switches in this lab
---
# Next Chapter
The next chapter covers the deployment of **Active Directory**.
You'll build a realistic Windows domain including:
* Domain Controller
* DNS
* Organizational Units (OUs)
* Users
* Groups
* Group Policy
* Domain-joined workstations
* Service accounts
* Common enterprise misconfigurations for security testing
By the end of the next chapter, you'll have the foundation of a Windows enterprise ready for enumeration, Kerberos attacks, SMB testing, privilege escalation, and lateral movement.

419
docs/04-active-directory.md Normal file
View File

@@ -0,0 +1,419 @@
# Chapter 4 - Active Directory
> In this chapter, you'll build the Active Directory environment that powers the corporate network. This includes deploying a Domain Controller, configuring DNS, creating users and groups, joining workstations to the domain, and intentionally introducing realistic misconfigurations for security testing.
---
# Objectives
By the end of this chapter, you will have:
* Windows Server 2022 installed
* Active Directory Domain Services (AD DS) configured
* DNS configured
* A new domain created
* Organizational Units (OUs)
* Domain users and groups
* Service accounts
* Domain-joined Windows clients
* Group Policy configured
* A realistic enterprise directory for penetration testing
---
# Active Directory Overview
Active Directory (AD) is Microsoft's centralized identity and authentication platform.
It provides:
* Authentication
* Authorization
* DNS
* Kerberos
* LDAP
* Group Policy
* Computer management
* User management
Almost every medium or large Windows environment relies on Active Directory.
---
# Lab Topology
```text
Corporate LAN
10.10.20.0/24
+----------------------------------+
| |
DC01 WIN10-01
| |
| WIN10-02
|
FILE01
|
SQL01
|
LINUX01
```
---
# Domain Controller VM
Recommended specifications:
| Setting | Value |
| ------- | -----------: |
| CPU | 24 vCPU |
| RAM | 40968192 MB |
| Disk | 100 GB |
| Bridge | vmbr2 |
Static configuration:
```text
Hostname : DC01
IP : 10.10.20.10
Mask : 255.255.255.0
Gateway : 10.10.20.1
DNS : 10.10.20.10
```
Notice that after installing AD, the server points DNS to itself.
---
# Installing Active Directory
Open:
```
Server Manager
```
Select:
```
Add Roles and Features
```
Install:
* Active Directory Domain Services
* DNS Server
After installation:
Select:
```
Promote this server to a Domain Controller
```
---
# Create a New Forest
Domain name:
```text
lab.local
```
Although `.local` is acceptable for a lab, a production environment would typically use a registered internal namespace such as `corp.example.com`.
Set a Directory Services Restore Mode (DSRM) password and document it securely.
---
# Organizational Units
Avoid placing users directly in the default **Users** container.
Create the following OUs:
```text
LAB.LOCAL
├── Servers
├── Workstations
├── Users
├── Service Accounts
├── IT
├── HR
├── Finance
└── Security
```
Keeping objects organized makes administration easier and allows targeted Group Policies.
---
# User Accounts
Create realistic users:
| Username | Department |
| ------------- | ---------- |
| john.smith | IT |
| sarah.jones | HR |
| michael.brown | Finance |
| emily.davis | Security |
| helpdesk | IT |
Create passwords that are memorable but not identical.
Example:
```text
Winter2026!
```
Avoid using the same password everywhere unless intentionally creating a vulnerable scenario.
---
# Administrative Accounts
Create dedicated administrative accounts.
Examples:
```text
administrator
itadmin
domainadmin
```
Avoid logging into workstations with highly privileged accounts during normal operation.
---
# Service Accounts
Many enterprise attacks target service accounts.
Create:
```text
svc_backup
svc_sql
svc_web
```
Later chapters will intentionally configure weak permissions or Service Principal Names (SPNs) to practice attacks such as Kerberoasting.
---
# Security Groups
Create groups such as:
```
IT
HR
Finance
Developers
Helpdesk
Server Admins
SQL Admins
```
Assign users based on job function rather than individual permissions.
---
# Domain Computers
Join the following systems to the domain:
```
WIN10-01
WIN10-02
FILE01
SQL01
```
Linux systems will remain standalone for now.
---
# Joining a Workstation
Configure:
```text
IP Address : 10.10.20.20
Gateway : 10.10.20.1
DNS : 10.10.20.10
```
Open:
```
System Properties
```
Change the computer from a workgroup to the `LAB.LOCAL` domain.
Restart the machine when prompted.
Verify the computer appears under the **Computers** container, then move it into the **Workstations** OU.
---
# DNS Verification
From a workstation:
```powershell
nslookup dc01.lab.local
```
You should receive:
```text
10.10.20.10
```
Test name resolution before moving on.
---
# Group Policy
Create a baseline GPO for the Workstations OU.
Example settings:
* Disable guest account
* Configure Windows Update
* Set desktop wallpaper
* Enable Remote Desktop (optional)
* Configure password policy
* Enable auditing
Later, you can create intentionally weak GPOs to practice abuse.
---
# File Shares
On FILE01 create:
```
Finance
HR
IT
Public
Software
```
Use different NTFS and share permissions to simulate real departments.
Some shares can intentionally have excessive permissions for later exercises.
---
# SQL Server
Deploy SQL Server Express on SQL01.
Create:
* Sample databases
* SQL logins
* Windows authentication
This provides targets for SQL enumeration and privilege escalation.
---
# Common AD Attacks to Practice
After the environment is complete, you'll be able to explore:
* SMB Enumeration
* LDAP Enumeration
* Kerberos Enumeration
* Password Spraying
* AS-REP Roasting
* Kerberoasting
* BloodHound Collection
* Lateral Movement
* Pass-the-Hash
* Pass-the-Ticket
* Group Policy Abuse
* Unconstrained Delegation
* Resource-Based Constrained Delegation (RBCD)
---
# Recommended Snapshots
Take snapshots after each milestone:
```
SERVER_INSTALLED
AD_INSTALLED
USERS_CREATED
WORKSTATIONS_JOINED
READY_FOR_ATTACK
```
This lets you reset the environment after exercises.
---
# Validation Checklist
Before continuing:
* [ ] Windows Server installed
* [ ] AD DS installed
* [ ] DNS installed
* [ ] `LAB.LOCAL` domain created
* [ ] Organizational Units created
* [ ] User accounts created
* [ ] Service accounts created
* [ ] Security groups created
* [ ] Workstations joined to the domain
* [ ] DNS resolution verified
* [ ] Baseline Group Policy applied
* [ ] Snapshot created
---
# Next Chapter
The next chapter covers the Kali Linux attack workstation.
Topics include:
* Installing offensive security tools
* Building a consistent pentesting toolkit
* Configuring SSH keys
* Setting up wordlists
* Installing Impacket, BloodHound, Ligolo-ng, and other utilities
* Creating reusable aliases and scripts
* Organizing notes and reports for engagements

419
docs/05-kali.md Normal file
View File

@@ -0,0 +1,419 @@
# Chapter 5 - Kali Linux Attack Workstation
> Kali Linux serves as the primary attack platform for the cyber range. This chapter covers installing, configuring, and organizing Kali into a professional penetration testing workstation.
---
# Objectives
After completing this chapter you will have:
* Kali Linux installed
* Static networking configured
* SSH configured
* A professional directory structure
* Essential offensive security tools installed
* Wordlists organized
* Python virtual environments configured
* Go tools installed
* Notes synchronized
* Snapshots created
---
# Virtual Machine Specifications
| Setting | Value |
| ------- | -------: |
| CPU | 2-4 vCPU |
| RAM | 4-8 GB |
| Disk | 80 GB |
| Bridge | vmbr1 |
| BIOS | UEFI |
| Machine | q35 |
---
# Network Configuration
Static IP:
```text
Hostname : kali
IP Address : 10.10.10.10
Subnet Mask : 255.255.255.0
Gateway : 10.10.10.1
DNS : 10.10.20.10
```
The gateway points to pfSense while DNS points to the Domain Controller after Active Directory has been deployed.
Verify:
```bash
ip addr
```
```bash
ip route
```
```bash
ping 10.10.10.1
```
```bash
ping 10.10.20.10
```
```bash
ping google.com
```
---
# Update Kali
```bash
sudo apt update
sudo apt full-upgrade -y
sudo apt autoremove -y
```
Reboot afterwards.
---
# Create Your Workspace
Create a dedicated directory for all assessments.
```bash
mkdir -p ~/Labs
```
```text
~/Labs
├── Active
├── Archive
├── Loot
├── Notes
├── Reports
├── Scans
├── Scripts
├── Tools
├── Wordlists
└── Screenshots
```
Each assessment gets its own folder.
Example:
```text
~/Labs/Active/DC01
```
---
# Install Essential Packages
```bash
sudo apt install \
git \
curl \
wget \
vim \
tmux \
jq \
ripgrep \
netcat-openbsd \
python3-pip \
python3-venv \
golang-go \
feroxbuster \
gobuster \
ffuf \
seclists \
impacket-scripts \
bloodhound \
crackmapexec \
evil-winrm \
enum4linux-ng \
hashcat \
john \
rlwrap
```
Some package names may vary slightly depending on the Kali release.
---
# Install Go Tools
Create a Go workspace.
```bash
mkdir -p ~/go
```
Add to your shell configuration:
```bash
export GOPATH=$HOME/go
export PATH=$PATH:$GOPATH/bin
```
Useful tools include:
* Ligolo-ng
* Chisel
* Kerbrute
* Naabu
* Httpx
* Katana
* Notify
Install them with:
```bash
go install <package>@latest
```
---
# Python Virtual Environments
Avoid installing Python packages globally.
Example:
```bash
python3 -m venv ~/venvs/tools
```
Activate:
```bash
source ~/venvs/tools/bin/activate
```
---
# Git Repositories
Clone frequently used projects.
```text
~/Labs/Tools
├── PEASS-ng
├── SecLists
├── LinEnum
├── Linux Exploit Suggester
├── PowerSploit
├── Nishang
├── Ligolo-ng
├── Chisel
└── Sherlock
```
Keep these updated regularly.
---
# Wordlists
Organize custom wordlists.
```text
Wordlists
├── DNS
├── Passwords
├── Usernames
├── Directories
├── API
└── Custom
```
Store any generated usernames or discovered passwords separately from the default SecLists.
---
# SSH Configuration
Generate a keypair.
```bash
ssh-keygen -t ed25519
```
Test:
```bash
ssh localhost
```
If you plan to administer your servers from Kali, copy your public key to them.
---
# Tmux
Create a repeatable workspace.
Example layout:
```text
+----------------------+
| nmap |
+----------+-----------+
| shell | notes |
+----------+-----------+
```
Suggested windows:
1. Enumeration
2. Web
3. Shells
4. Notes
5. Packet captures
---
# Browser
Install:
* Firefox
* Burp Suite Community
* FoxyProxy extension
Configure Burp as the browser proxy.
---
# Screenshots
Create a dedicated folder.
```text
~/Labs/Screenshots
```
Use descriptive filenames.
Example:
```text
01-nmap.png
02-smb.png
03-shell.png
```
---
# Notes
Document everything.
Suggested structure:
```text
Notes
├── Enumeration.md
├── Credentials.md
├── Findings.md
├── PrivEsc.md
└── Timeline.md
```
These notes will later be copied into Wiki.js.
---
# Aliases
Useful aliases:
```bash
alias ll="ls -lah"
alias ports="ss -tulpn"
alias myip="ip addr"
alias cls="clear"
```
Customize this over time as your workflow evolves.
---
# Snapshots
Create snapshots after:
```text
FRESH_INSTALL
FULLY_UPDATED
TOOLS_INSTALLED
READY_FOR_ATTACK
```
This allows you to roll back after experimenting with new tools.
---
# Validation Checklist
Before continuing:
* [ ] Static IP configured
* [ ] Internet access verified
* [ ] DNS working
* [ ] Kali fully updated
* [ ] Workspace directories created
* [ ] Offensive tools installed
* [ ] Wordlists organized
* [ ] SSH keys generated
* [ ] tmux configured
* [ ] Browser configured for Burp Suite
* [ ] Snapshot created
---
# Recommended Daily Workflow
For each new target:
1. Create a new folder in `~/Labs/Active`.
2. Start a tmux session.
3. Begin note-taking immediately.
4. Save all scan results.
5. Capture screenshots as you go.
6. Record credentials and hashes in your notes.
7. Write a short summary before moving to the next target.
8. Transfer your final notes into Wiki.js.
Following the same workflow every time helps build discipline and makes it much easier to write professional reports later.
---
# Next Chapter
The next chapter covers building the vulnerable machines that populate the enterprise network.
You'll deploy:
* Windows 10 workstations
* Windows file server
* SQL Server
* Ubuntu Linux target
* Web server
* Intentionally vulnerable configurations
* Snapshot strategy for repeatable practice

View File

0
docs/07-pivoting.md Normal file
View File

View File

0
docs/09-web-attacks.md Normal file
View File

View File

View File

View File

0
docs/troubleshooting.md Normal file
View File

0
playbooks/enumeration.md Normal file
View File

View File

0
playbooks/ldap.md Normal file
View File

0
playbooks/pivoting.md Normal file
View File

0
playbooks/reporting.md Normal file
View File

0
playbooks/smb.md Normal file
View File

0
playbooks/sql.md Normal file
View File

0
playbooks/web.md Normal file
View File