LabNet Internal Assessment - UbuntuServ

Executive Summary

An authorized internal assessment of UbuntuServ (10.x.x.3) on the isolated LabNet segment, to determine whether the host could be compromised from an attacker already positioned on the internal network.

UbuntuServ exposed four services (SSH, HTTP, and SMB on 139/445). The service software was fully patched, so the exploitable risk lived in configuration (anonymous SMB enumeration) and credentials (a weak SSH password). Both were demonstrated, remediated, and verified. Findings: 1 High, 1 Medium.

F-01 (High): a weak SSH password was brute-forced to a full shell in about a minute. F-02 (Medium): anonymous SMB null sessions disclosed share names and host/OS information.

Both findings are remediated and verified. Extend the same controls - key-based SSH, brute-force protection, and no anonymous SMB - across all hosts, and segment the network so a single foothold cannot reach every system.

Scope

UbuntuServ - 10.x.x.3 (Ubuntu 24.04.4 LTS), across all listening services. Attacker position: Kali 10.x.x.4 on the same segment.

Any system outside LabNet 10.x.x.0/24, and all external or internet-facing systems.

Testing was confined to the isolated LabNet 10.x.x.0/24. The credential finding used a deliberately weak throwaway account (testuser), created for the test and removed on completion.

Objectives

Determine whether UbuntuServ can be compromised from an attacker already on the internal network, following a repeatable methodology: scope & recon, scan & enumerate, exploit / validate, remediate, verify, then clean up and report.

A weakness counts as demonstrated only when it is safely proven to have impact and captured as evidence, and counts as closed only when the exact attack is re-run and confirmed to fail.

Activities

Step 1 - Identify the target: confirmed reachability of 10.x.x.3 and mapped live hosts with nmap -sn 10.x.x.0/24 (target 10.x.x.3, attacker 10.x.x.4).

Step 2 - Scan services: nmap -sV 10.x.x.3 found 22/tcp OpenSSH 9.6p1, 80/tcp nginx 1.24.0, and 139/445 Samba 4.

Step 3 - Check known exploits: searchsploit returned no results for OpenSSH 9.6 or nginx 1.24 - the software was patched, so the work pivoted to configuration and credentials.

Step 4 - Enumerate SMB: smbclient -L -N and enum4linux showed the server accepted null sessions and exposed share names (public, share, IPC$).

Step 5 - Attempt anonymous read: smbclient //10.x.x.3/public -N logged in anonymously but the tree connect was denied - only enumeration was exposed, not the data.

Step 6 - Brute-force SSH: hydra against the weak testuser account recovered the password in about a minute, yielding a full shell.

Step 7 - Remediate: hardened Samba (map to guest = never, restrict anonymous = 2, SMB2 minimum) and SSH (fail2ban, key-based auth, PasswordAuthentication no).

Step 8 - Verify: SMB enumeration was denied, fail2ban banned the attacker IP, and the SSH brute force found nothing.

Step 9 - Clean up: removed the throwaway testuser account and restored the environment.

Spencer - lead tester, operating the Kali attacker box (10.x.x.4). Target host: UbuntuServ (10.x.x.3).

Outcomes

Two findings identified, demonstrated, remediated and verified within the engagement. The deliberately weak test account was removed and the environment restored.

None outstanding for UbuntuServ. The broader recommendations - network segmentation and fleet-wide credential and SMB hardening - remain for the wider environment.

Recommendations

Segment the network into VLANs with firewall / ACL rules between them, so a single foothold cannot reach every host. Layer with phishing training, MFA on all remote access, not exposing services to the internet, patching, least privilege, and monitoring / EDR. (MITRE ATT&CK: Initial Access -> Discovery -> Lateral Movement.)

Disable anonymous access on all services; enforce key-based SSH with PasswordAuthentication no; deploy fail2ban.

Timeline

2026-08-17 - single-session engagement: identify the target, scan services, check known exploits, enumerate SMB, attempt anonymous read, brute-force SSH, remediate, verify, and clean up.

Conclusion

Patched software resisted known exploits; the exploitable risk lived in configuration and credentials, both remediated and verified within the engagement, with the test account removed afterward. Recommendations: disable anonymous access on all services, enforce strong-password / key-based authentication, apply defense in depth (fail2ban + keys), keep systems patched, and segment the network so a single foothold cannot reach every host.

Appendix

Initial-access context: this engagement began with the attacker already on LabNet. Gaining that position - phishing, an exposed internet-facing service, stolen, weak or reused credentials, a malicious download or supply-chain compromise, or Wi-Fi / physical access - is a separate, harder phase; everything in this report is what happens after a foothold exists. The primary defense is network segmentation. Companion to the VM Lab Playbook.

Findings

ID	Finding	Severity	Affected asset
FND-2026-0001	SSH Weak Password (Brute-Forceable)	High	UbuntuServ 10.x.x.3 - SSH / OpenSSH 9.6p1 (TCP 22)
FND-2026-0002	Anonymous SMB Enumeration	Medium	UbuntuServ 10.x.x.3 - SMB / Samba 4 (TCP 139, 445)

FND-2026-0001 — SSH Weak Password (Brute-Forceable)

Severity: High · Asset: UbuntuServ 10.x.x.3 - SSH / OpenSSH 9.6p1 (TCP 22)

A user account (testuser) used a weak dictionary password, allowing a credential brute-force attack over SSH and full interactive shell access as that user.

Impact.

A foothold suitable for privilege escalation and lateral movement, with a full interactive shell as the user.

Remediation.

Installed fail2ban to ban brute-force sources; moved to key-based authentication (ssh-copy-id) and set PasswordAuthentication no in sshd_config; restarted ssh.

FND-2026-0002 — Anonymous SMB Enumeration

Severity: Medium · Asset: UbuntuServ 10.x.x.3 - SMB / Samba 4 (TCP 139, 445)

Null sessions let an unauthenticated attacker enumerate share names and host/OS information. The share contents themselves still required authentication.