Author |
Topic  |
|
iesa
Starting Member
USA
2 Posts |
Posted - 03/10/2015 : 12:00:43
|
I recently found that I could no longer download the BAK file from the SQL instance on our website, hosted remotely, to the local network. Sonicwall would always kill the download, indicating "ScrInject.UR (Trojan) blocked".
After finding no suspicious data in the 200 or so tables, I created a copy of the database and started deleting tables, creating a BAK (overwrite), and then testing download. Eventually I deleted ALL tables, including sysdiagrams - and Sonicwall still won't allow download.
Is it possible for Trojan code to reside in a BAK file, even when it has no tables at all?
Craig Johnson |
|
gbritton
Flowing Fount of Yak Knowledge
2780 Posts |
Posted - 03/10/2015 : 12:18:09
|
hard to see how. or at least, it would have to be pretty sophisticated. but just to be sure, how big is your BAK file on that database with no tables? Easy enough to compare it to others to see if there's room for something else in there. |
 |
|
tkizer
Almighty SQL Goddess
USA
38200 Posts |
|
iesa
Starting Member
USA
2 Posts |
Posted - 03/10/2015 : 15:17:31
|
With tables, it's a 100 MB bak file. No tables, it's 8.3 MB. Sonicwall allows the download to progress to 20% or 30%, then kills it.
My bak file download had been functional for a few years now, then it just stopped working. Changing the extension doesn't help.
If it's unlikely that the table-less file actually contains a malicious code, I would have to suspect a false positive by SonicWall, wouldn't I?
Craig Johnson |
 |
|
gbritton
Flowing Fount of Yak Knowledge
2780 Posts |
Posted - 03/10/2015 : 15:38:15
|
Sounds like a false +ve to me |
 |
|
Lincolnburrows
Yak Posting Veteran
52 Posts |
Posted - 05/27/2015 : 05:37:06
|
To repair bak file no other option is better then external software |
 |
|
|
Topic  |
|