Find the source of a recurrent mass SQL edit on a server
SQL Injection is hard to track from SQL Server side. Instead of looking at sql server, you should look at your web server IIS logs.
Use Log Parser to parse your IIS Logs to track down the source of sql injection. e.g.
logparser.exe -i:iisw3c -o:Datagrid -rtp:100 “select date, time, c-ip, cs-uri-stem, cs-uri-query, time-taken, sc-status from C:\wwwlogs\W3SVCXXX\u_ex1207*.log where cs-uri-query like ‘%declare%’”
Read up on
- SQL Injection – a Serious Security Issue by Erland Sommarskog
- SQL Injection: How it Works and How to Thwart it
- Protecting Yourself from SQL Injection in SQL Server - Part 1 and Part 2 from Aaron Bertrand.
The server has already been scanned with several tools and all the main password (administrator, sa of SQL Server) has been changed.
If the SQL Server service account user is an administrator on the local machine, then you need to build a new machine from the ground up to replace it using long (14 character plus) cryptographically random passwords, and then shred the hard drives from the old machine; there's no telling what malware was installed on it.
If the SQL Server service account user is a domain admin, call a professional security specialist.
If neither of those is true, and you don't want to rebuild it from scratch (you should rebuild from scratch), take the SQL Server offline, drop every user, drop every login, change the SA password, and then carefully rebuild every login and user with long (14 character plus) cryptographically random passwords.
Then wipe out every agent job and rebuild them from scratch. While you're doing that, rebuild (preferably) or go over ever word in every piece of code every agent job calls... and every piece of data if you've got dynamic or concatenated SQL, and have issues with second order SQL injection.