JavaScript insertion and log deletion attack tools

Published: 2009-04-02
Last Updated: 2009-04-02 00:39:28 UTC
by Bojan Zdrnja (Version: 1)
0 comment(s)

In my last two diaries ( and I described two very common attacks on web servers that I have seen in the wild recently. During the forensic analysis, I acquired two attack tools that were used in almost all cases, so here is a short description of them.

The main goal of attackers was to inject malicious JavaScript tags pointing to their own servers, which then served malware to all visitors of the compromised web page. When successful, the attackers used ARP poisoning in order to virtually attack all other servers in the local network.

However, in cases where they couldn’t do this (for one reason or the other), they used a very simple file injection named JS.exe, which you can see disassembled below:


As the application is written in C#, it can be easily disassembled. The tool accepts just two parameters: which files to modify and what to insert. The attackers usually insert the JavaScript tag and the files to modify parameter is by default “all” which will search all local hard disks for files ending with the .js extension and append the malicious JavaScript at the bottom. So, if you happen to experience this attack be sure to check your JavaScript files.

The other attack tool I recovered is a log cleaner for Windows. It’s another simple tool which allows attackers to easily delete all IIS, FTP and EventLog logs. The help window is shown below:


While the both files are very simple, finding them solved another puzzle that troubled many web administrators lately as attacks such as those I describe are becoming increasingly common.

I’d like to use this opportunity to warn people about the “unpatched” Windows vulnerability described in again, since I’ve seen it used in the wild again. While Microsoft listed some workarounds, for most users using IIS 6 they will not be acceptable as they require one to disable the Distributed Transaction Coordinator service. The workaround for IIS 7 is better, but some (many?) shops can’t easily migrate to it so they are kind of left in the open.
If you have more experience or comments about these workarounds please do contact us.



0 comment(s)


Diary Archives