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
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
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
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
