Dealing with the compromise

If you're only worried about this individual SQL Server, you all are thinking too narrowly.

What typically happens is an attacker gets control of one system and then uses it to attack other systems. Typically an attacker with any sort of skill will install a trojan or some other sort of backdoor that they've run through the various AV engines. That means you have to assume the server itself is compromised.

Because of the way password hashes are stored and because these hashes can be used in a Pass the Hash attack, and also because of the fact that any service account being used on the system (such as SQL Server's own) can be dumped using an LSA secrets attack, you must assume that any logins used to log into the server via the console or via RDP or which run as a service are compromised.

Given all of this, it's important to:

1) Pull the box off-line

2) Perform any forensics you wish to do

3) Wipe the server and start over

4) Reset any accounts that may have been compromised

I know you have to take care of the access of your users and ensure minimal data loss, but you need to these 4 steps as soon as you possibly can. Even if they've fixed the firewall, a lot of trojans "phone home" to a CNC server, and most folks don't practice whitelisting outbound traffic through the firewall.

Auditing Logins

It is typical to audit failed logins. It is not typical to audit successful logins. That throws up so much noise to render the auditing useless and is only typically done on high security systems.

Auditing logins will not provide them the IP address they are looking for. Their IDS/IPS was their best mechanism for getting this info. If they have IDS/IPS.

Disabling xp_cmdshell is not a false sense of security

There are several good reasons to do this.

1) They prevent against a mistake by someone with privileges who just doesn't think. For instance, if you shouldn't be running a command shell query from a production server but it's okay from dev, having it turned off in prod will remind them they are on the prod box. We've all been guilty of running a query against the wrong server if we've been a DBA for any length of time.

2) It stops script kiddies and those who don't know much about SQL Server. To get xp_cmdshell back on involves knowing sp_configure and RECONFIGURE. If an attacker only knows the rudiments of how to attack a SQL Server, then this stops their attempt. Yes, they can then go search on the Internet for the answer, but it gives you something they don't want to give up: time.

3) It can cause a trip against a functioning IDS/IPS. A lot of IDS/IPS will flag the string xp_cmdshell. In order to turn on xp_cmdshell when it has been turned off requires an attacker to execute sp_configure 'xp_cmdshell', 1. Guess what? That triggers the hit. So does the initial xp_cmdshell use, which will fail. It may only give you a few seconds notice, but if the attacker has to search for the answer, your IDS/IPS just tripped, your security folks should get alerted, and you know you're under attack. If it's the case like in #2, that may give you just enough time to break up the attack.

It doesn't do a lot. However, to say it provides a false sense of security is incorrect. It's just another way to lay a tripwire to try and detect an attacker. Of course, for #2 and #3, if your organization doesn't have an IDS/IPS set up properly, it's all a moot point.