Ready to start a project with us? Let us know what's on your mind.

1501 Broadway STE 12060
New York, NY 10036-5601

    Select Service(s)*

    x Close


    • Blog articles related to hacking are only for informational and educational purposes. Any time the word “hacking” is used on this site, it shall be regarded as Ethical Hacking. You may try out these hacks on your own computer at your own risk. Performing hack attempts (without permission) on computers that you do not own is a serious crime under federal law.
    • Refer to the laws in your province/country before accessing, using, or in any other way utilizing these materials. These materials are foreducational and research purposes only.
    • Any actions and or activities relating to the material contained within this website is solely your responsibility. The misuse of the information in this website can result in criminal charges brought against the persons in question. The author and Winmill Software will not be held responsible in the event any criminal charges be brought against any individuals misusing the information in this website to break the law.

    Penetration testers say that, given enough time and resources, any system can be hacked. In this demonstration, we will attack a Microsoft 2016 server with no patchable vulnerabilities without using any exploits. Our entry point will be an Outlook Web Access (OWA) application. We will compromise an email account. We’ll use the compromised account to send out a phishing email to the global address list to capture a password hash with Responder. We’ll crack the password hash with John the Ripper, and use the password to get unprivileged access to the server. 

    We will then enumerate running processes and analyze their permissions using PowerShell and native Windows tools from the System Internals suite to elevate privileges and retrieve a secret file from the administrator’s account. We will do this by hijacking the system’s Just Enough Administration (JEA) account used by Microsoft to prevent abuse of privileges and privilege escalation.

    We begin by running an all-TCP Ports Nmap scan to identify open ports and running services. We discover three http services running on ports 80, 443, and 8080. We also notice that the Windows Remote Management is running on port 5985 (Figure 1). Let’s investigate!

    Figure 1: Nmap scan shows ports 80, 443, 8080, and 5985 open.

    First, we look at port 80 and receive a 403 Access denied response from the server (Figure 2).

    Figure 2: 403 Response on port 80.

    Next, we look at port 443 and discover an IIS server running on the port (Figure 3).

    Figure 3: IIS running on port 443.

    Finally, we examine port 8080 and discover a Wallstant open-source social networking application (Figure 4).

    Figure 4: Wallstant social networking web application.

    IIS is running on port 443. We fuzz the web server for files and folders with FFUF and discover the OWA mail client app (Figure 5).

    Figure 5: OWA page on port 443.

    We visit /owa with our browser and confirm that it is an Outlook email client (Figure 6).

    Figure 6: Outlook Web Application (Exchange Client).

    Without knowing the domain name it’s impossible to bruteforce the authentication. But we can use the Spraying Toolkit to identify the domain and run various password spraying configurations. We clone the repository, and issue commands below to install it.

    git clone

    cd SprayingToolkit

    apt install -y libxml2-dev libxslt1-dev

    pip3 install -r requirements.txt

    Once installed, we issue the command below, and discover our domain to be HTB. Let’s browse to port 8080 and continue our enumeration. We return to the application running on port 8080, register, and login (Figure 7).

    Figure 7: Social account registration as Hax Elite.

    Checking the POSTS tab reveals two posts from cube and svensson (Figure 8).

    Figure 8: Posts tab content.

    Reviewing the search.php source code, we see that if a request is made to this page without a query parameter, the application will return all registered user names (Figure 9).

    Figure 9: Entering search without any parameters returns the full list of users.

    This is successful, and it also reveals an xampp installation. We can write a simple Python script to collect the list of users’ first and last names (Figure 10).

    Figure 10: Python script to retrieve list of usernames.

    While attempting to identify valid OWA accounts, it’s a good idea to try several common username formats to identify the internal naming convention. We can use a tool such as Username Anarchy to create common username permutations based on the full names. After saving the full names to a text file, we run the script (Figure 11).

    Figure 11: Username permutations generated by username-anarchy.

    We recall that one of the posts in the application refers to Summer and year 2020, so it’s worth spraying the OWA login with the password Summer2020, as it is a very common password format. This is successful, but we don’t find any emails in the mailbox (Figure 12). As we gained access to OWA, it’s possible to perform phishing attacks by sending an email to all users in the Global Address List (GAL). 

    Figure 12: Successful OWA login.

    The GAL is a built-in address list that’s automatically created by Exchange that includes every mail-enabled object in the Active Directory Forest. There are multiple ways to dump the Global Address List. Using the GUI, we can click on the phonebook icon on the top-right corner, and a new window opens that shows the list (Figure 13).

    Figure 13: Global Address List

    We create a simple phishing email (Figure 14).

    Figure 14: Generic phishing email.

    Before sending the email to the GAL we configure Responder to listen for OWA authentications (Figure 15).

    Figure 15: Responder tool configured to answer authentication requests.

    We load the GAL and send the email (Figure 16).

    Figure 16: Email sent to the GAL.

    After a minute or two, we receive our first hash (Figure 17). 

    Figure 17: Password hash of the k.svensson user.

    The hash is cracked, and the password is found to be kittycat1. From the Nmap scan, we found that the Windows Remote Management service is running on the default port 5985. We use PowerShell Linux and issue the commands below (Figure 18) to obtain a PS Remoting session on the box.

    Figure 18: We get an unprivileged shell on the target.

    We now have a foothold on the server, although we are found to be constrained by a Just Enough Administration (JEA) policy (Figure 19).

    Figure 19: Limited list of commands we can run.

    Just Enough Administration is a feature in Windows 10/Server 2016 that allows administrators to create granular least-privilege policies, by granting specific administrative privileges to users, defined by built-in and script-defined PowerShell cmdlets. (A “cmd” is the key shortcut that opens a Windows command line window; a “cmdlet” is a small, lightweight command used in the Windows PowerShell environment.) 

    This feature is similar to Linux capabilities, which provide a way for a program to be granted specific abilities that would otherwise require root access. By default, JEA starts a session in NoLanguage mode which restricts the execution of cmdlets, functions, and other PowerShell language elements. However, when configuring JEA, it is also possible to change the language mode. Let’s check the language mode of our session (Figure 20).

    Figure 20: We are in constrained language mode.

    It’s in ConstrainedLanguage mode. The official documentation states that this mode allows all PowerShell scripting elements. We can break out of the JEA restriction by creating a function &. This is successful and we see the output of the whoami command. We can also use a script block to bypass this restriction (Figure 21). 

    Figure 21: Breaking out of the constrained language execution restriction.

    Figure 22: We use the technique to download nc.exe to our target machine and connect back to our Kali attacking box.

    Figure 23: We get our PowerShell reverse shell connection.

    Figure 24: We list running processes and stickynotes grabs our attention.

    StickyNotes is an application used for taking notes and displaying them on the desktop. The version and installation directory of the software can be obtained from the process ID (Figure 25).

    Figure 25: StickyNotes file information. Version is 0.3.0.

    We upload the Strings64.exe tool from System Internals and run it against the application’s log file revealing the jea_test_account credentials (Figure 26).

    Figure 26: Credentials for the jea_test_account revealed.

    We upload upload procdump64.exe to the box and dump the StickyNotes process memory (Figure 27).

    Figure 27: StickyNotes process memory dump.

    The configuration includes RunAsVirtualAccount, which indicates that the defined role htb\jea_test_account will have administrative capabilities. We see that the session runs in NoLanguage mode, which means that we can’t use the earlier bypass methods. A close inspection of the output reveals that the custom function Check-File has been defined, which will allow the jea_test_account user to read the plain text contents of files from either the D: drive or from the C:\ProgramData folder and subfolders. Assuming the JEA configuration file name is also the JEA policy ConfigurationName, let’s try to log in to WinRM. First, we convert the password to a secure string (Figure 28), then we create the credential object (Figure 29), and finally we establish the session as jea_test_account (Figure 30).

    Figure 28: Converting the Password to secure string using PowerShell in Kali Linux.

    Figure 29: Creating the $cred object.

    Figure 30: Creating the session.

    Now that we have a session with elevated privileges, we can use the Check-File function to retrieve files by abusing a Local File Inclusion vulnerability that we discovered while we were testing. In this case, it appears that the Windows Server 2016 server will deliver any file requested by the Check-File function if the path begins with c:\ProgramData\..\PATH TO FILE. We test this by requesting a file that we know is always present in Microsoft products, license.rtf (Figure 31).

    Figure 31: We retrieve license.rtf.

    Our final test will be to retrieve the administrator’s secret (root.txt) from his desktop. We successfully retrieve the hash! (Figure 32).

    Figure 32: Administrator hash successfully retrieved.

    This demonstration proves that given enough time and imagination to explore and enumerate with commonly available tools, we can breach environments hardened with the latest security features. Don’t become the next victim of a cyberattack. Schedule your penetration test today!