A good way to keep an eye on attackers and get insight on their techniques and tactics is to use a honeypot. A honeypot is a purposefully vulnerable system with fake data that you actually want attackers to breach. This gives you a bit of a safe sandbox where you can monitor the attacker's activity. Today I want to discuss how to set up a Microsoft SQL honeypot for the purpose of luring automated bots.
Since this system will be set up especially with the expectation of being hacked, you do not want it on the same network as any internal system. Use an isolated virtual machine in the cloud or keep the system segmented off on its own network.
If you want to have a nice and healthy bot visit your MSSQL honeypot, you have to show some hospitality. You should begin by keeping default ports on your MSSQL Server to allow for smooth discovery. Make sure that those ports are open through any firewall to connect your server to a public Internet. That should do the trick and you should start seeing buzzing and knocking bots in no time.
In the next step you have an option - you get to choose which login you would allow your favorite bot to take over. Here is a list of accounts that are currently the most popular probed: sa, NT AUTHORITY\ANONYMOUS LOGON, hbv7, vice, kisadmin, bwsa, ps, uep, 401hk, sysdba, su, sql, web, mssqla, dbhelp
By choosing an insecure password for the account you selected (e.g. Password123 or abc123), you assure that bots will find their way into your honeypot.
Now that your new bot is on the inside, we need to make sure that all the bots play well with each other. After bots get onto the system they try to prevent other bots from doing the same thing. To achieve that, they often change the password they guessed to something more complex.
To mitigate that behavior, you can use a little script that will change the password back to something easily guessable value every few minutes.
import pyodbc
import time
def main():
try:
while True:
conn = pyodbc.connect(.......)
cursor = conn.cursor()
cursor.execute("ALTER LOGIN [sa] WITH PASSWORD=N'<...>' ")
conn.commit()
conn.close()
time.sleep(200)
except:
print("See you later.")
main()
Another common step taken by bots is to shut down MSSQL audit trace by executing sp_trace_setstatus.
To address that, we can start an audit trace and then patch MSSQL in memory using windbg:
- Start windbg64
- Attach the debugger to sqlservr.exe
- Find the module 'sqllang' and change the name of the function 'p_trace_setstatus' to something else in memory view
Now you may wonder, what do bots do when they think no one is watching? They register dll files, make wmi calls, change registry keys, create OLE objects, setup rogue jobs, upload binary code, create logins and delete logins of other known bots ... All the good stuff.
And you should see it for yourself.
A list of bot logins deleted by other bots often looks like this even after a short time of monitoring: ps, su, Rolename, shitou, masqer, se, Mssqla, vice, count, suz, syn, gaibian, sasa, xxa, Myar, win7, sz, wwo, kisadminnew1, ss, mms, chicago, users, so, gd, windows, wq, gaibian!@, bingo
Watch these cute little carnivores snap their jaws at each other and flex permissions "muscles" expanding control over the server by any means available. It’s very entertaining to watch techniques that many consider uncommon or permissions being taken advantage of that are often thought to be useless/harmless. Also, you should be concerned with the possibility of more sophisticated targeted attacks of similar nature.
This is what lurks right outside of your firewalls, just waiting for the next zero-day or a mistake in your security implementation. Have fun with your playdate with bots and keep your system secure by using database security scanners like Trustwave’s.
