Summary

Welcome! This post is going to dive into Proving Grounds' Hutch machine and explain a little bit of the workflow and potentially some new concepts. We'll talk about LDAP, WebDAV, and LAPS.

This box can certainly be more difficult but my advice would be just to KEEP ENUMERATING! If you do your research that's about all it will take. A little exploitation to get a webshell but we're gonna be heavy on enumeration tactics and workflows for this one.

Enumeration

NMAP

As per usual, run through your initial Nmap scans to see what's out there.

sudo nmap -p- --min-rate 10000 192.168.XXX.122
sudo nmap -p XX,XXX,XXX,XXXX -A 192.168.XXX.122 -v

Excellent information here. I'd like to point out and zero in on the 80/http and 389/ldap services. Firstly, anytime you see port 80, go navigate there to a browser to see what's up. We should just see a default IIS page but it's always great to check what can be there. Running through some quick scans for directories and files is also good, just don't waste too much time on it.

LDAP services are sometimes hit or miss for scanning. However, there is a key component here that is perhaps obvious but we really ought to put a pin in it.

Our aggressive scan has revealed two critical points:

80/http : WebDAV looks to be enabled
389/ldap : We found the target's domain: hutch.offsec

So let's talk real briefly about why it is a good find and where we can go from here.

• WebDAV: WebDAV (Web-based Distributed Authoring and Versioning) is an extension of HTTP that allows clients to perform remote web content authoring operations. Its presence could provide opportunities for exploiting vulnerabilities or uploading malicious files.

• LDAP Enumeration: LDAP is used for accessing and maintaining directory services. Discovering an LDAP service can be valuable for obtaining user and system information within the directory.

With WebDAV we have a potential exploit opportunity and with LDAP we have found the associated domain and can conduct further reconnaissance.

So which one to pursue first? Well, we don't have any credentials and there are no indications of a vulnerability to exploit in IIS so let's pivot to additional LDAP enumeration.

LDAP Enumeration

We've done a partial enumeration of LDAP with our nmap scan but now we want to round it out and fully enumerate this LDAP service to see if we can find anything of value. HackTricks has a fantastic resource and I would encourage you to explore ldapsearch to find the information we need.

Hopefully you've landed on a nice search, so let's talk about it.

• -v : verbose

• -x : Specifies simple authentication. In other words, it uses a clear-text password for authentication.

• -b “DC=hutch,DC=offsec”: Sets the base DN (Distinguished Name) for the search.

• -H “ldap://192.168.247.122”: Specifies our target LDAP server’s address (note the ldap:// instead of http://)

• "(objectclass=*)": This is the LDAP filter used to specify the search criteria. In LDAP, objects are classified into classes, and the "objectclass" attribute is a mandatory attribute for all objects. By specifying "(objectclass=*)", the search retrieves all entries in the LDAP directory regardless of their object class, effectively querying for all objects. (so yes, lots of results)

A word on LDAP and these things called search filters:

These filters allow you to narrow down the search results based on specific conditions:

1. Syntax:

   • LDAP search filters are expressed as strings enclosed in parentheses.

   • They consist of one or more expressions combined using logical operators (AND, OR, NOT).

2. Common Components:

   • Attribute: The attribute you want to search (e.g., cn for common name, mail for email address).

   • Operator: Determines how the attribute value is compared (e.g., = for equality, >= for greater than or equal).

   • Value: The specific value you’re looking for (e.g., a username, an email address).

3. Examples:

   • (cn=John Smith): Searches for entries with the common name “John Smith.”

   • (objectClass=person): Retrieves entries where the object class is “person.”

   • (&(cn=John)(mail=john@example.com)): Combines conditions using AND (both common name and email match).

   • (|(cn=John)(cn=Jane)): Combines conditions using OR (either John or Jane).

4. Wildcards:

   • Asterisk (*) is used as a wildcard to match any characters.

   • (cn=J*) would match entries with common names starting with “J.”

5. Advanced Filters:

   • You can use more complex filters:

     • (objectClass=inetOrgPerson)(|(sn=Smith)(sn=Johnson)): Retrieves inetOrgPerson entries with last names “Smith” or “Johnson.”

     • (memberOf=CN=Admins,OU=Groups,DC=mydomain,DC=com): Finds entries that are members of the “Admins” group.

As we should always be reading ALL of our output, we should find credentials that are left in the description of a user. One could also pipe this to a text file ( ... > output.txt ) and grep for useful things like "password" ( ... | grep -i "password")

And now we have a set of credentials, fmcsorley:CrabSharkJellyfish192

This will be a good time to remember we have an IIS server running WebDAV.

Exploitation

WebDAV Web Shell

To take from HackTrick's resourceful wiki once again: "When dealing with a HTTP Server with WebDav enabled, it's possible to manipulate files if you have the right credentials, usually verified through HTTP Basic Authentication. Gaining control over such a server often involves the upload and execution of a webshell."

Multiple ways to accomplish that and I encourage you to go through research, connect, and drop a web shell (think what is IIS running)

Cadaver acts as a client for WebDAV operations, enabling you to interact with WebDAV-enabled servers from the command line. It's actually a legitimate admin tool used for interacting with WebDAV so no real exploit here, just using valid credentials.

Connecting and looking at the directory, we can see the index.aspx file which will tell us that the server is running ASP (Active Server Page) and we can drop a similar ASPX web shell to gain command line interface. Because we're at the root directory we should be able to just navigate to the page and input the web shell (see below)

Navigating to our new web shell we can now run commands (http://192.168.247.122/cmdasp.aspx)

Anytime I see a user have the SeImpersonatePrivilege I like to note it and think "Privilege Escalation" (maybe potato or printspoofer). However, this box is actually going to be a little more simplistic than that, even though it would work. I'm going to go down a different avenue that I think is a really good learning point.

Upgrade to Reverse Shell

While we do have a web shell it can be advantageous to get an enhanced reverse shell for continued operations. Web shells do have limitations as they lack a proper terminal environment. We can get full control with a reverse shell.

For construction we can user MSFVenom and catch it with netcat. (Don't forget, LHOST is your host!)

As we have now landed on a host with low privileges it is time to start the cycle again and ... ENUMERATE. Look for things, like directories, that are not like all other Windows systems.

Escalation

Like I mentioned earlier, the SeImpersonatePrivilege should be a nice win for privilege escalation. I encourage you to explore that avenue. However, I would like to dive into another vector, that starts with understanding a Microsoft security implementation, LAPS

Microsoft LAPS

Microsoft LAPS, or Local Administrator Password Solution, is a free solution provided by Microsoft to manage the local administrator account passwords across an organization's Windows-based computer infrastructure. It is particularly useful in environments where maintaining secure and unique local administrator passwords on every workstation is essential for security.

Key features and functions of Microsoft LAPS include:

1. Randomization of Local Administrator Passwords: LAPS automatically generates random, complex passwords for the local Administrator account on each computer. These passwords are securely stored in Active Directory (AD) and regularly rotated according to configurable policies.

2. Secure Storage in Active Directory: LAPS stores the generated passwords as attributes of computer objects in Active Directory. Access to view these passwords is restricted to specified groups or individuals, ensuring security and preventing unauthorized access.

3. Password Expiration and Rotation: LAPS enables administrators to set policies for password expiration and rotation intervals. This helps mitigate the risk of stale or compromised passwords by regularly updating them.

4. Integration with Group Policy: LAPS integrates seamlessly with Group Policy, allowing administrators to configure and manage LAPS settings centrally. Group Policy settings define password policies, such as password complexity requirements and password expiration periods.

5. Auditing and Reporting: LAPS provides auditing capabilities to track password changes and access to password information. It also includes reporting features to monitor password compliance and identify potential security issues.

Overall, Microsoft LAPS offers a simple yet effective solution for managing local administrator account passwords in Windows environments, enhancing security by ensuring that these passwords are regularly rotated and stored securely in Active Directory.

~ BREAK BREAK ~

Read point 2 again!

That should ring a bell for our earlier LDAP enumeration with ldapsearch ... except NOW we have credentials. So with that, move into the thought process of "which attribute should I be looking for?" Go through a few google searches and add it to your search filter.

Windows LAPS schema extensions reference

ldapsearch -v -x -D fmcsorley@hutch.offsec -w CrabSharkJellyfish192 -b "DC=hutch,DC=offsec" -H ldap://192.168.247.122 "(ms-MCS-AdmPwd=*)" ms-MCS-AdmPwd

• -D fmcsorley@hutch.offsec: Sets the bind DN (Distinguished Name) for authentication.

• -w CrabSharkJellyfish192: Provides the password for the specified user.

• “(ms-MCS-AdmPwd=*)”: Defines the search filter. It looks for entries where the ms-MCS-AdmPwd attribute exists (wildcard matches any value).

And just like that we have the local administrator password. There are a great many ways to gain access now, take your pick. It should be noted that as this has to do with LAPS (see point 1) the password is going to be different in each environment.

PsExec, SmbExec, CrackMapExec, a few impacket tools to log in as administrator.

One technique that is useful to talk about is the use of scheduled tasks to execute a payload, as see in the write up for this box.

First create a new payload with MSFVenom, upload with Cadaver, then use PowerShell's functionality to create and execute the task:

> $pw = ConvertTo-SecureString "EnterAdmPwdHere" -AsPlainText -Force
> $creds = New-Object System.Management.Automation.PSCredential ("Administrator", $pw)
> Invoke-Command -Computer hutchdc -ScriptBlock { schtasks /create /sc onstart /tn ChooseATaskName /tr C:inetpubwwwrootadminshell.exe /ru SYSTEM } -Credential $creds
> Invoke-Command -Computer hutchdc -ScriptBlock { schtasks /run /tn ChosenTaskName} -Credential $creds

Recap

With that, we uncovered vulnerabilities to gain access to the target system. Initially, we obtained a user's password from LDAP and exploited the IIS web server, utilizing WebDAV to upload a shell for code execution. We then elevated our privileges by leveraging Microsoft LAPS, allowing us to discover the random password for the Administrator user through LDAP.

Learning Points:

- Understanding LDAP Vulnerabilities: LDAP can be a source of sensitive information, such as user credentials, which can be exploited to gain initial access.

- Exploiting Web Servers: The IIS web server, when misconfigured or with enabled features like WebDAV, can provide avenues for uploading malicious code and gaining execution privileges.

- Leveraging Microsoft LAPS: Utilizing Microsoft LAPS enables access to privileged information like randomly generated local administrator passwords, enhancing the scope of exploitation and privilege escalation.