I am pleased to announce that the BrowserGather project now supports the extraction of Chrome cookie data. In the first part of the BrowserGather project, I used binary regular expressions in PowerShell to extract Chrome credentials in a novel, fileless manner. In this blog post, I will discuss how I was able to apply this technique to extract Chrome cookie data, and the issues that arose during development. Check out my GitHub for the updated code.
I am pleased to introduce the first module for my latest project, BrowserGather. BrowserGather is an entirely fileless web browser information gathering tool for red teamers, written in PowerShell to compliment tools such as Empire and PowerSploit. The Get-ChromeCreds module allows for the extraction of Chrome credentials without the need to write to disk, making it much stealthier than previous techniques.
I got a request today from Matt Maley over at Gotham Security (@mjmaley) for a list of SQL queries that could be used to execute the SeeCLRly technique over a SQLi vector. I’ve also seen some interest in this topic on Reddit, so I decided to make this post. Below you will find a series of queries that, when injected, will allow you to perform command execution on a SQL Server without the use of the xp_cmdshell stored procedure. Note that the user which executes the injected queries still needs to have the sysadmin privilege. I haven’t been able to test these queries over a SQLi vector myself so please let me know your results!
In my previous post, I demonstrated how it was possible to execute custom C# code via the creation of a custom CLR stored procedure on a target SQL Server, entirely in memory. In this post I will provide and discuss a working command execution PowerShell script for this technique and possible ways to mitigate it.
Recently I was given the task of performing command execution on a compromised MSSQL server with the following restrictions:
- No use of the xp_cmdshell stored procedure.
- No writing anything to disk.
These restrictions matched those of a recent pentest that a member of my team, Lee Christensen (@tifkin_), was involved in. Through my research I found that there were basically two means to achieve this objective. The first is through the use of SQL Agent jobs, as documented here. The other option was to create a custom stored procedure using the Common Language Runtime (CLR), which would allow for the execution of code from any of the supported programming languages, such as C#. While both methods require the attacker to have the sysadmin role, each option also has their own unique restrictions. The SQL Agent method requires that the SQL Agent service be active (which it is not by default), and that the SQL Agent service account has the necessary privileges required for the command to execute successfully. The CLR stored procedure method requires the ability to create custom stored procedures, the ability to enable the use of CLR on the SQL Server, and requires that the SQL Server service account has the necessary permissions for the command/code to be executed. I also initially believed that that the stored procedure had to be available externally as a DLL file, and then loaded into the SQL Server for execution, thus failing the second restriction. This turned out not to be the case.