Blog Post

SQL Injection Attack using script from, hackers are back

There seems to be a really new SQL injection attack running around like wildfire on the Internet that leaves a trail pointing at If your applications are not hardened to sql injection attacks, you may have noticed a very funny new behavior of some of your web pages. Specifically, there is some script from running when you look at the source code that you didn't put there. This is serious business on a big scale. We put in a little tracker to catch in the act and had over 10,000 unique IP addresses hitting us in under 24 hours. So, don't think that a simple IP block approach will work here.

Behavior After Attack

Your site will still function, but the pages will load really really slowly. Additionally, the end user's browser is executing someone else's javascript, and it's not the friendly kind. In other words, after being attacked by this SQL Injection from, your site will still function. However, now it's essentially doing someone else's dirty work, spreading evil of some kind, in the form of a browser payload.

How does the SQL Injection work?

There are a few steps to this little virus hack from The first thing it needs to do is figure out that your site is not hardened to a sql injection attack. So, it will probably run a few tests on user input forms around your site and see what it gets back. Specifically, I would imagine that they are appending simple exploratory statements to various user-input forms. In many cases, with sloppy development, this input is not validated or checked for malicious intent (I know - how crazy to trust the world ;-) So they will run an EXECUTE or SELECT at the end of a user field. If it works, they know that your site is vulnerable to a SQL Injection attack.

From there, they need to do some exploratory analysis. In the case of, they specifically want to find out your table and field names. Once they are in, this is really easy. They can query some system tables and dump those values out. Now they have the blue print to your database. In the case of the sql injection attack, the hacker then runs a series of update statements. If you dig around after an attack, you can usually find a few examples. If you log any of your user input, that's a great place to start. You will find something REALLY REALLY long with VARCHAR statements, DECLARE and EXECUTE. What they are doing in the case of this attack virus is putting a script statement at the end of every field in every table. The script statement is javascript pointing to the domain. Their hope is that some of these fields end up in user-facing web pages (which they usually do). Thus, when an unsuspecting end-user comes to your trustworthy web site, they actually load the script call from your database. That's not where the malicious code sits. But that is a remote call back to the mother ship of evil where the real damages start. The end-users browser pulls this attack / virus script from and then the payload is delivered locally on the end-users browser.


Make sure you don't allow any statements like EXECUTE, DECLARE, VARCHAR, or SELECT through your user-input fields. Just pull them off. If you want to be slightly more proactive, keep a list of source IPs that try and cut them off to keep them from coming back, but that's not entirely necessary. What's important is that the SQL statements that are injected don't get executed. You can also remove execute permissions on the database side, but you may need that available for other reasons.

As far as I can tell, as a web master and server administrator, your systems are not really harmed, per se. However, your data is seriously messed up with this javascript virus attack thingy appended to every field in every table. To clean this up is a real mess. I'm hoping you are making good backups.

I don't know who the dudes are at, but they really are no fun at all.