Alright, let’s dive into this box, which officially sits at an intermediate level on Offsec’s Playground called "Access". But here’s the catch: the community collectively agrees it’s a “Very Hard” ride. It is really time consuming but here's we are, challenge accepted? You can check out the box yourself here.
First things first – Nmap to the rescue. Let's start with a scan.
sudo nmap -Pn -n $IP -sC -sV -p- --open
I pretty much always kick things off with Nmap because it’s a quick way to gather a ton of useful intel. Here’s the plan:
• Use sudo for that sweet, faster half-open SYN scan.
• Add -Pn to skip the ping check and assume the host is alive (no “Host seems down” headaches here).
• Throw in -n to dodge DNS resolution and save time.
• Include -sC for default scripts and -sV for version detection – gotta know what we’re working with.
• Use -p- to cover all 65,535 ports because you never know where the goodies might hide.
• And the MVP here: --open ensures scripts and version detection only run on ports that are actually open – no wasted effort.
Now, let’s use the IP and let Nmap do its thing.
┌──(kali㉿kali)-[~/offsec-labs]
└─$ sudo nmap -Pn -n 192.168.207.187 -sC -sV -p- --open
[sudo] password for kali:
Starting Nmap 7.94 ( https://nmap.org ) at 2023-10-05 12:14 EDT
Nmap scan report for 192.168.207.187
Host is up (0.082s latency).
Not shown: 65514 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
80/tcp open http Apache httpd 2.4.48 ((Win64) OpenSSL/1.1.1k PHP/8.0.7)
|_http-server-header: Apache/2.4.48 (Win64) OpenSSL/1.1.1k PHP/8.0.7
|_http-title: Access The Event
| http-methods:
|_ Potentially risky methods: TRACE
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2023-10-05 16:17:08Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: access.offsec0., Site: Default-First-Site-Name)
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: access.offsec0., Site: Default-First-Site-Name)
3269/tcp open tcpwrapped
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
9389/tcp open mc-nmf .NET Message Framing
49666/tcp open msrpc Microsoft Windows RPC
49667/tcp open msrpc Microsoft Windows RPC
49669/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49670/tcp open msrpc Microsoft Windows RPC
49673/tcp open msrpc Microsoft Windows RPC
49695/tcp open msrpc Microsoft Windows RPC
49734/tcp open msrpc Microsoft Windows RPC
Service Info: Host: SERVER; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
| smb2-security-mode:
| 3:1:1:
|_ Message signing enabled and required
| smb2-time:
| date: 2023-10-05T16:18:02
|_ start_date: N/A
Seeing ports like 53 (DNS), 88 (Kerberos), and 389 (LDAP) is a dead giveaway – we’re likely dealing with a Domain Controller here. That’s already a big clue. Plus, we spot the domain access.offsec in the mix (ignore that zero at the end, it’s not important).
To make things more interesting, there’s an Apache web server chilling on port 80. Classic.
Now, the presence of standard SMB ports 139 and 445 combined with 5985 raises some eyebrows—this hints at potential Remote Management access (always worth exploring).
Ports 636 (Secure LDAP) and 2369, however, are marked as tcpwrapped, which isn’t exactly helpful on its own. To get more out of those, we can try:
• A netcat banner grab for any additional clues.
• Or re-running Nmap on those ports with the -T0 flag. This ultra-slow, stealthy scan might tease out something more useful.
Time to dig in.
Another noteworthy discovery is port 9389, linked to a .NET message framework that I don’t recognize, along with a series of Microsoft RPC ports.
Given the presence of a web server, it’s wise to launch a Gobuster scan in a new tab immediately. Since these scans can be time-consuming, starting one early allows us to revisit the results later. As a general rule, it’s beneficial to have an enumeration scan running in the background before attempting initial access—unless stealth is a priority, in which case every packet sent must be handled with caution.
sudo gobuster dir -w '/home/kali/Desktop/wordlists/dirbuster/directory-list-2.3-medium.txt' -u http://$IP:80 -t 42 -b 400,403,404
I opted to use 42 threads with -t 42 for better efficiency and filtered out irrelevant response codes such as 400, 403, and 404 by including -b 400,403,404.
The next step is to update the /etc/hosts file to include the domain name.
sudo subl /etc/hosts
Use your preferred text editor. At this stage, we could attempt a DNS zone transfer, an LDAP search (since we now have the domain name), or SMB enumeration using tools like enum4linux and smbclient. However, our next focus will be on the Apache web server.
