Hathor

Doing Sekhmet before this is super helpful, but still it is super hard. There are multiple different users we get shells as, and this writeup will divide them as follows instead of the usual.

Windcorp\web Shell

Nmap scan:

$ nmap -p- --min-rate 5000 10.129.71.218 
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-11 11:28 EDT
Nmap scan report for 10.129.71.218
Host is up (0.0070s latency).
Not shown: 65516 filtered tcp ports (no-response)
PORT      STATE SERVICE
53/tcp    open  domain
80/tcp    open  http
88/tcp    open  kerberos-sec
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
389/tcp   open  ldap
445/tcp   open  microsoft-ds
464/tcp   open  kpasswd5
593/tcp   open  http-rpc-epmap
636/tcp   open  ldapssl
3268/tcp  open  globalcatLDAP
3269/tcp  open  globalcatLDAPssl
5985/tcp  open  wsman
9389/tcp  open  adws
49664/tcp open  unknown
49668/tcp open  unknown
49674/tcp open  unknown
49696/tcp open  unknown
49701/tcp open  unknown

We can do a detailed scan for this because I don't want to miss anything from this machine.

The first thing we notice is the domain name, which is hathor.windcorp.htb. This has all the ports open, so it might be the DC itself. We can add the domain name to our /etc/hosts file.

Web Enum -> Default Creds

Port 80 shows a corporate page that is still under construction:

At the bottom of the page, there's a link that brings us to a login page on the website:

Viewing the page source reveals this is a mojoPortal instance:

A quick Google search for mojoPortal exploits and default credentials led to this:

Surprisingly, this worked!

Admin Panel -> Move RCE

The administrator panel lets us edit the pages and what is shown:

This is an IIS server, so uploading an .aspx reverse shell might work. Head to File Manager > Upload Files:

When trying to upload, it doesn't work.

If we change it to cmd.txt, it works.

Then it shows up here:

Interestingly, there's a Move function as well, and we can try moving this to be cmd.aspx.

We can try to rename it as cmd.aspx, and it seems to work:

Turns out this is actually a CVE:

LogoUpload Malicious File in mojoPortal v2.7 (CVE-2022-40341) | CVEweed-1.gitbook.io

Anyways, we can access our webshell using this CVE:

However, getting ANY shell fails to work. Similar to Sekhmet (which I actually solved before this), there's some kind of firewall in use here that is blocking us.

Firewall + AppLocker Enum

Since this was the first machine before Sekhmet which also had AppLocker, we can run some powershell enumeration to find out what exactly can be done:

This would generate a massive string of stuff that we can and cannot execute.

Here is what is allowed for files and binaries:

I don't think it's possible to replace these DLLs, and even if for some reason I have write access, I cannot restart these processes. Also, unsigned binaries like nc.exe won't run properly.

In this case, we can try some better webshells that don't rely on external binaries to run.

Logopentest/shell/insomnia_shell.aspx at master · jivoi/pentestGitHub

Insomnia shell is a fully implemented web shell that can give us a reverse shell without the use of external binaries. We can upload this one and try again.

Using this, we can get a reverse shell as web.

GinaWild Shell

Bad Passwords -> User Creds

Earlier, I saw some kind of Powershell script called Get-bADpasswords in use, so let's find that.

Within one if the directories, there's a bunch of different CSVs present:

Reading the latest one reveals a hash:

This is crackable:

!!!!ilovegood17 is the password here.

NTLM Ban -> Beatrice Ticket

I tried to use crackmapexec, but it doesn't work:

STATUS_NOT_SUPPORTED is an error that looks like it's going to be a reoccuring theme throughout this machine. A bit of research reveals that this is due to NTLM not being able to be used as an authentication method on this machine.

https://care.qumulo.com/hc/en-us/articles/360001006108-Resolve-failing-SMB-Client-Connections-with-NTLM-Authentication-#adjust-ntlm-authentication-level-0-4care.qumulo.com

This means that only Kerberos tickets would work in trying to authenticate in this machine. For this case, we have to use kinit to get a ticket, similar to another machine Absolute. We need to include this within our /etc/krb5.conf file:

Then we can run kinit and give it the credentials we got earlier:

Great! Now we can finally view the shares:

We can connect using smbclient.py.

SMB Enumeration -> DLL Hijack

Within the share share, we can find some stuff:

So that's where the 7-zip64.dll file is located. One of the things I noticed is that we can write to it. We can perform the DLL HIjacking attack for this. Because of AppLocker, I think that msfvenom generated DLLs won't work, so let's create our own.

I grabbed this script from Hacktricks, and we can build it within VS Code in our Windows machine. Afterwards, we can grab this DLL and place it within the share.

Afterwards, we can wait for a bit then check the C:\Windows\Tasks folder. Eventually, I would see that it did create a file:

I can't read it, meaning this is probably another user. There seems to be a really aggressive script that is cleaning this up every minute, because it wasn't long before this file disappeared. While waiting, I checked the AppLocker policy for the .exe files:

It seems that this file can be run regardless of what it is. Now that we have RCE as another user, let's try to enumerate who this user is and what they can do. Since the Bginfo64.exe file can be run, let's see if we can overwrite it with our own file like nc.exe.

First we enumerate using this new DLL:

After a while, it would create those files. Here's the interesting output:

It appears that the user is ginawild, and is part of the ITDep group. Also, this user has Write Owner privileges over the Bginfo64.exe file. This means we can take over as the owner of the file, replace it with nc.exe , change the permissions to let everyone execute it, and then execute it to gain a reverse shell as ginawild.

Before doing so, we need to get the file over. SMB wasn't going to work as something is closing our connection. powershell itself runs with very little allowance. So, let's re-use the file upload vulnerability we found earlier, and upload our nc64.exe shell to the website.

My final DLL looks something like this:

After waiting for a little bit, we will get a shell back!

We can now grab the user flag.

Bpassrunner Shell

Recycle Bin -> PFX Crack

Within the main C:\ directory, there are some files within the Recycle Bin.

We can only access one of the directories, and it just has a bunch of .pfx files.

To transfer the files, we can copy them over to the C:\share directory and download them from SMB. All 3 files are data:

Since all 3 are pfx, let's try to use pfx2john to crack them. We would be able to find one of the passwords:

Now we can use openssl to read more information about this:

So this is from the Administrator. Since we have a .pfx from the administrator, we can actually use this. In the AppLocker conditions, we can see the subject match some conditions:

This means that we can run 'any program' if we import this into the Certificate Store of the machine. The question is, what script do we run?

Script Hijack -> Shell

I was still curious about the Get-bADpasswords.ps1 script, what was the point of it? I checked the ACLs of it, and found that I could overwrite it:

We have Modify Access to this file. So in this case, we can replace it with our own AND then sign it using the certificate. I downloaded it, and made a small edit at the top to use our Bginfo64.exe file (which is still nc.exe) to gain another reverse shell.

Afterwards, we can re-upload this to SMB and use copy to overwrite the existing script. Now, we need to sign the script.

LogoHow to Sign a PowerShell Script (a Step-By-Step Guide)Code Signing Store

Using the above resource, we can run these commands to sign it:

This script should let us know that we have imported it:

It should also let us know that we have signed it successfully:

Then, there's a run.vbs script that looks like it executes the file:

We can simply use cscript ./run.vbs to run this, and we would get another reverse shell:

Root Shell

Get-ADReplAccount -> Hashes

So this user is in charge of running the script that checks whether there are weak passwords. Witin the script, I found this part here:

It appears this user can use Get-ADReplAccount to retrieve NTLM hashes for users. I found some cheatsheetys for this command online as well:

LogoDSInternals/Documentation/PowerShell/Get-ADReplAccount.md at master · MichaelGrafnetter/DSInternalsGitHub

Using this, we can retrieve the hash of the administrator.

Kerberos Ticket -> Shell

Using this NTLM hash, we have to request for a Kerberos ticket because NTLM hashes have been disabled.

Then, we can use this ticket to get a shell using this ticket:

Rooted! Although hard, this machine had steps that were simple if the enumeration was done properly. Great machine!

PreviousFulcrumNextMultimaster

Last updated