Sounds like a compromise or someone at the very least "tinkering about" with either the Web/Apps tier or database. The latter manisfests itself if you've exposed a database instance directly to the Internet - I sincerely hope that you've not done that. If yes (drop a comment and I'll follow up off line) ..... appears that someone has initiated mulitple connect requests to brute force logon accounts. If you've a Password Policy that implements lockout then they've more than likely knocked it out. SQL Accounts? Hmm, if was me I'd try "sa" to begin with. Isn't it the web instance that can't find the database?
Checkout the principles from Chip Andrews site http://sqlsecurity.com. Also, is the IIS Config and underlying Windows O/S locked down?
Next Steps .....
How does your ASP App/Web Tier hook into SQL back-end? Via stored procedures or SQL on the fly? There is still opportunity for mis-use in either case.
For instance, in SQL2005 onwards, the more interesting Stored Procedures such as xp_cmdshell are disabled. If you have not removed the dll from the system you can still enable them i.e.
exec sp_configure 'show advanced options', 1
exec sp_configure reconfigure
exec sp_configure 'show advanced options', 1
exec sp_configure 'xp_cmdshell', 1
exec sp_configure reconfigure
And if you have SQL on the fly, then look through Input Validation Techniques recommended on this site.
Are there any areas of upload provided by the site?
If you've implemented Windows Integrated Auth, if someone has gotten to your SQL server by an interface presented indirectly via Web/App, they can then set themselves up as a Domain Admin and own your entire Windows estate.
Cheers.
BTW On the IP front .....
FYI http://www.ripe.net/ in Europe and ARIN in the US (also samspade.org) may help determine those rogue source IP addresses. You may not be able to do an awful lot with the info if those IP's are registered with 1 of the big Service Providers like BT in the UK but you never know