An user called the helpdesk because the antivirus was yelling about a supposed malicious PDF file.
The only problem was: this alert was happening while surfing on a professional website, a supposed 'trustworthy' one...
At first, I have to say I did not believe the AV detection was reliable, since I personaly worked on AV issues in PDF detection...
But... a quick check of the source code of the webpage proved that a strange link had been added. This link was pointing to a russian website, and more especially to a JS file (ECMA script). This obviously drew my attention.
First of all, about the domain itself: www.bannerdriven.ru. The suspect script is: www.bannerdriven.ru/ads.js.
If you search for it using Google, you just find out that hundreds of websites have been compromised (their source code has been indexed by Google, and it shows to you the malicious link). Here is a screenshot of what I got on the 26th of september:
It appears that most (if not all of them) of those websites run IIS 5, 5.1, and 6.
It also seems that the attack is an automaticated one, targeting:
- the "TITLE" part of the webpage
- any link pointing to an ASP page hosted on a targeted website.
Thus, it is only needed to access a compromised website to see the attack being tried on the user's computer!
Then, about the internet domain. I find the DomainCrawler results quite interesting:
See NS servers, WhoIs, and even IP-addresses.
If you look at the malicious server itself, there is a surprise about the DNS. Here is a screenshot of requests through OpenDNS: differents IP, different machines... This is an evidence of the use of the fast flux system.
Running the suspect link on a hardened computer, Firebug helped me discovering the obfuscated JS file was just redirecting the user to:
Then, the victim is being redirected to:
A bit of reverse engineering made me understand the malicous website uses:
- cookie and PHP session ID, to make sure the attack is tried only once on a same computer
- autodefense system: wget download blocked! (UserAgent detection, I guess)
- visitor's IP addresses recording, to make sure the attack is tried only once on a same computer
After that, two attacks are launched on the victim's computer:
- a malicious SWF: http://bannert.ru/ad/spl/files/8628468724.swf
- the PDF, apparenlty downloaded from http://bannert.ru/ad/spl/files/info.php
At the end of it, a fake error page is being displayed to the user, not to warn him about something suspicious.
If the attack succeeds, then the malicious software AntivirusPro2010 is downloaded and directly installed on the computer. Compromised computers even went to crash (BSOD, on WinXP SP2).
Clearly, this is again about financial fraud...
What about the Internet domain bannert.ru? well yeah, the DomainCrawler results are again quite interesting:
Here is a VirusTotal comparative analysis of the malicious PDF: https://www.virustotal.com/fr/analisis/1fc413651af1fe6901581888f53b5bf53669067d270b3e2a291929fc4c4aab52-1254273671
Here is what I could say at the time of the discover (09/27):
- McAfee: detection OK (Exploit.gen PDF, updated 16th of September)
- Sophos: no detection (I sent them a sample on the 09/29)
- ESET: no detection (still true on the 30th of September)
- PC-Tools Antispyware: no detection (still true on the 30th of September)
- MalwareByte: no detection (still true on the 30th of September)
At the time of writing (09/29), we still don't know for sure the exact attack being used to compromise the IIS servers. I believe it is one of the last IIS vulns (IIS FTP?), other people think it is about ASP / SQL injection...
I'll post further details as I find out.
Here is a VT analysis of the SWF file:
Still very few AV detection huh... 5 AV out of 41...
More about the IIS attack method:
Well yeah, I think I've lost my bet.
Apparently, it is a real SQL injection, like a classical one... supposedly coming from an ancient BotNet (The ASProx one). A simple Google search, http://www.google.fr/search?q=sql+injection+bannerdriven.ru&hl=fr&sa=2 led me last night to: http://garwarner.blogspot.com/
I'd like to congratulate the author for his great job.
Further on, we even have IIS logs as an evidence of what happened:
Some of the first bursts have certainly been launched of the 25th of September...
For those who wanna see the whole SQL injection command line, I think there it is:
Then, if that helps, some guys published automated tools (scripts) to clean up compromised MS SQL databases:
Use with care, in case of you don't know what you're doing exactly...
One last point should be emphasized, IMHO.
Compromised websites were indexed by Google, okay. But, if you search Google for the different malicious URL, you may discover that the compromised websites were indexed with a malicious JS file link, which is no longer the one you could see in their source code! (well, we assume here those websites are still compromised when you look at their source code...).
That means... that the BotNet has got a kindda update feature, which is able to change/update the URL being injected within vulnerable pages!
It also could mean that the attack is being tried repeatedly on IIS servers that were already compromised, but with a different malicious URL, and until the SQL injection weakness has been corrected.
Thus, the guys who try to clean up the SQL databases and webpages have to keep in mind that if they don't correct the security weakness which had permitted the SQL injection, their IIS will be compromised again sooner or later...
New domain being inserted within the webpages source code: doublebanner.ru.
There is a new file: counter.js.
Are the bad guys trying to count their victims?
To conclude with, once again folks:
1- use NIPS (Network Intrusion Prevention System)
2- use WAF (Web Application Firewall) to protect your applications! Classical firewalls are not suitable to do that...
3- don't forget to sanitize the user data inputs... (a bit complex to do if the application is already deployed... I know)
4- update all your applications on the stations and servers, not only MS products!
5- if you website has been compromised, don't forget to tell your external customers (provide an AV procedure link...) and keep an eye on the services that could give a "bad security reputation" to your website
6- whether your website has been compromised or not, make sure your traceability is operational and protected!