Stalking the Bad Guys

Tracking down bad guys

Suppose you found some malicious code on your system. Maybe it’s a login that didn’t below at the sysadmin level, or maybe a stored procedure that might disable a trigger, make a change, and re-enable the trigger. What do you do?

Suppose you stumbled upon a strange stored procedure in one of your databases. It wasn’t something you had coded, and it appeared to be altering permissions, maybe adding a login, or even querying sensitive data. What do you do?

The easy answer is to delete the procedure and go on about your day. Some of you might save a copy of the code, along with its permissions and make a note to check the system a week or two later and see if it needed to be there.  However I’m not sure that is the best action to take.

If you are unaware of the origins of code, it can be detrimental to your system if you remove object. A legitimate stored procedure might cause application errors, which can result in some type of discipline. At the very least, managers might be upset with you for taking action without understanding the consequences.

I think a different approach might be better. Set up auditing or tracing, focusing on the code and documenting any actions. I would talk to security people and potentially initiate lower level tracing of the network to determine who is making use of this code. If it’s truly malicious code, it’s not necessarily your job to stop someone. Setting up the honeypot, documenting actions, and then allowing someone else to determine the final action might be the best way to deal with the situation.

Steve Jones

The Voice of the DBA Podcasts

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged . Bookmark the permalink.