TL;DR

We access some SMB shares anonymously and retrieve an HR email template containing a temporary user password. We have more accesses with that user and can read a bunch of XML configuration files in the IT share. They leak the encrypted password of the user C.Smith as well as a subfolder of the share Secure$. We mount that subfolder and retrieve the source code of a custom application RU Scanner that reads the config file with the encrypted password. The password is encrypted with AES256-CBC and uses PBKDF2 to derive the key from a passphrase. We decrypt the user password and retrieve the user flag from the Users/C.Smith shared folder. There is a custom service running as well. It allows us to explore the file system and read files if we have the password to enable the debug mode. We find an empty file in C.Smith folder that contains the debug password in its extended attributes (or streams). We activate the debug mode in the service and read one of the config files that leaks the encrypted password of the Administrator. We found as well a binary used by the service in C.Smith folder. We decompile it (.NET) and see that the same encryption scheme is used again. We decrypt the Administrator password and get a shell with psexec to retrieve the root flag.

Reconnaissance & Enumeration

Open Ports

An NMAP scan shows the following (partial) output:

We discover the SMB port open as well as an unknown service on port 4386, probably a custom service.

SMB discovery

Anonymous access is enabled and we can list the available shares with crackmapexec:

We have read access to 2 shares: Data and Users. The Users share contains some user folders but they are not accessible anonymously:

The Data share contains some IT folders and only the Shared subfolder is accessible:

The full content of the Shared folder is:

We retrieve the 2 text files. The first one does not contain anything useful:

The HR file contains:

It leaks a temporary user credentials. With this account, we can read a new share Secure$:

On top of that, we have as well access to Users/TempUser that contains a unique file New Text Document.txt but it is empty. Back to the Secure$ share. It contains 3 folders: Finance, HR and IT but we can’t read their content. However, Data/IT is now accessible and contains multiples files. Let’s mount it:

We discover a bunch of XML config files in Data/IT/Configs. A config file contains credentials information. It is related to an app called RU Scanner:

We saw a folder C.Smith previously in the Users share. If we base64-decode the password we don’t get much, so probably this is an encrypted or hashed password. We can recover the bytes:

It is 256 bit so our first guess is either it is a SHA256 hash or an AES256 encrypted password.

In NotepadPlusPlus/config.xml, we find the file history of the user C.Smith:

It leaks a file and a subfolder of the Secure$ share.

Port 4386

This is a custom reporting service that we can access with telnet. It does not work with nc, not even with the -T flag to use telnet negotiation…not sure why.

We guess the Help command:

We can explore the available commands. LIST seems to list the files and folders in the current folder:

We should be able to use RUNQUERY to run queries with a query ID as argument. However, running RUNQUERY 1, 2 or 3 does not work.

We can use the SETDIR command as we use cd to move in the file system:

Running HELP LIST shows another command SHOWQUERY which supposedly can read the content of a file, however, we need to be in DEBUG mode and it requires a password.

Gaining Access

We do not have access to any folder of the Secure$ share with our TempUser access rights. However, we can mount and read the subfolder we found earlier Secure$\IT\Carl:

In there, we access a VB Projects/WIP/RU folder that contains the source code of RU Scanner. We might find out how C.Smith password in the config file was encrypted or hashed.

The Main function in Module1.vb is quite empty. It loads the config file, reads the username and decrypts the password:

The DecryptString function is found in Utils.vb:

It calls the Decrypt function with the encryption scheme parameters. The function signature explains those value:

The code shows that the encryption used is AES256 in CBC mode:

And that the AES key is derived from the passphrase using PBKDF2:

As per Microsoft documentation, Rfc2898DeriveBytes uses HMACSHA1.

We have all the necessary parameters to decrypt the password. We can use CyberChef as follows. First, we get the AES256 key:

Then we use this key to decrypt the password:

The credentials are then c.smith:xRxRxPANCAK3SxRxRx. We can mount his user folder:

We get the user flag in there:

Privilege Escalation

Along with the user flag, we find a folder HQK Reporting that contains an executable file called HqkLdap.exe in a subfolder called AD Integration Module. We get as well a strange empty file called Debug Mode Password.txt:

The @ sign next to the permissions indicates that the file has extended attributes. We can use ls -l@ to list the file attributes, and xattr -l to list the attributes and values:

Now that we have the debug password, we can resume the exploration of the HQK Reporting Service. Once the debug mode activated we have access to more commands:

SERVICES and SESSION just show information about the running process and session. The only useful information is the current folder. We start in C:\Program Files\HQK\ALL QUERIES. We can change directories with SETDIR and find HqkLdap.exe (that we retrieved previously) and Ldap.conf in C:\Program Files\HQK\LDAP. We can read the config file with SHOWQUERY:

This looks again like an encrypted password, this time for the Administrator account. We can probably decrypt it by analyzing HqkLdap.exe.

The executable is a .NET PE32 file:

We can decompile the code with tools like dotPeek. And it is clear that the encryption scheme is exactly the same as the one in RU Scanner:

Back to CyberChef for the decryption. We first get the AES256 key:

Then decode the encrypted password and decrypt it:

With the Administrator password. we can use psexec to get a shell and the root flag:

Conclusion

This was an easy box but more in the CTF style in my opinion. The only difficulty was to find out the hidden debug password.

Here are some takeaways:

• always enforce SMB authentication, disable SMBv1, enable SMB signing and encryption if possible,
• enforce a strong password policy,
• review access rights periodically and grant them according to need-to-know and least privilege principles.

Resources

[1] PBKDF2
https://en.wikipedia.org/wiki/PBKDF2
https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.rfc2898derivebytes?view=netframework-4.8

[2] CyberChef
https://gchq.github.io/CyberChef/

[3] Alternate Data Streams
https://blog.malwarebytes.com/101/2015/07/introduction-to-alternate-data-streams/

[4] dotPeek .NET decompiler
https://www.jetbrains.com/decompiler/