Monthly Archives: September 2009

Drive-by campaign using dynamic DNS domains

Since Monday a new drive-by campaign is making the round which is using dynamic DNS domains of DynDNS and No-IP to spread malware.

The drive-by campaign consists of three different stages illustrated below:


*** First stage***
The first stage is always the same on all drive-by campaigns: The cybercriminals injects malicious code into legitimate websites (mostly using stolen FTP credentials, see “An Iframer for Dummies”). In this case the malicious code is a iframe which is pointing to a malicious domain for the second stage. The Iframe can look like this:

<iframe src="" width=248 height=0 style="visibility: hidden"></iframe>
<iframe src="" width=625 height=0 style="visibility: hidden"></iframe>

As you can see above, for this purpose the cybercriminals are using dynamic DNS domains names in the Iframes.

*** Second stage***
The second stage is the URL to which an iframe from the first stage is pointing to. The URL comes along with one of the following parameter, which will be given to in.cgi:

For example:


If a user visits a infected website with such a malicious iframe, the in.cgi script tries to set three cookies for the domain ( – CHINANET-SH) and sends a HTTP 302 (redirect) back to the victims browser.

Here’s an example of such a request:

Connecting to||:8080… connected.
HTTP request sent, awaiting response… 302 Found
Cookie coming from attempted to set domain to
Cookie coming from attempted to set domain to
Cookie coming from attempted to set domain to
Location: [following]

…with the following HTML content:

<meta http-equiv="REFRESH" content="1; URL=’’">
document moved <a href="">here</a>

…and the following cookies (one per line): FALSE / FALSE [number] SL_default_0000 _1_ FALSE / FALSE [number] TSUSER open4 FALSE / FALSE [number] SL_open4_0000

Until now I’ve seen the following dynamic DNS domains which are acting as “redirector” in the second stage:

Redirecting URLs (second stage)

Each of these redirection domains seems to select a target URL as redirection for the third stage. For this purpose every redirection URL has a pool of ten target URLs to choose from (some kind of a domain set), and this pool is changed every hour.

*** Third stage ***
As mentioned before, the dynamic DNS domains used by the third stage will change frequently (using different domain sets and HTTP 302). One would expect the target domains to contain malicious code that exploits vulnearable web browsers and browser plugins used by the visitors. BUT actually they are neither serving contents nor exploits – just blank pages:

Target URLs (third stage)

A full list of the malicious domains used by this drive by campaign in the third stage can be found here: (currently I already caputred more than 1’500 uniq domains which are assoiciated with this drive-by campaign). The list will be updated permanently using a script.

The strange thing is that the malicious domains currently doesn’t serve any kind of exploits/malware. So the question is why the cybercriminals are injecting malicious Iframes in thousands of legitimate websites while the drive-by infection doesn’t work? While several explanations like geoIP dependencies exist, the following one sounds most reasonable: They want to inject the malicious iframes in as many sites as possible. As soon as they have infected enough websites, they will put exploits on to the dynamic DNS domains which are currently just hosting a blank page. The benefit of it could be that AV-vendors are not able to get any exploits or malware before the cybercriminals “activate” the attack. Though the security industry might track the threat, they would be unable to react onto it while the attack has not been launched (don’t forget the domain flux which the domains are using).

Dynamic DNS domains are more and more used for this kind of attacks. Maybe it’s time for us to reconsider firewall policies of corporate networks concerning access to them?

UPDATE 2009-09-14
It seems that this drive-by campaign spreads a variant of the Bredolab trojan.

An Iframer for Dummies

Today I came accross an Iframer called Ziframer. But first of all: What is an Iframer?

An Iframer is a script which is used to test stolen FTP accounts and inject malicious code into web pages. If an FTP account is valid, the Iframer automaticly puts an Drive-by infection on the specified html, php or asp files.

In this case the Iframer is a PHP-script which is used to spread a variant of ZeuS (aka Zbot/WSNPoem). The Iframer is called “Ziframer” and is sold for 30$. The PHP script can bee launched via command line or accessed using a web browser:

Ziframer v1.3

The script is very simple and just needs a list of FTP accounts which the script should check. As you can see on the screenshot above, the input file (ftp.txt) currently contains more then 18’000 stolen FTP credentials:

Stolen FTP credentials title=

In the file “iframe.txt” the attacker can define the (JavaScript- or HTML-) code he would like to inject:

Malicious Iframe

The cyberciminal has also the possibility to set a timeout, a file where the script will report invalid FTP credentials (bad.txt) and a file which will collect valid FTP credentials (good.txt). The screenshot below shows you the script while working through the list of stolen FTP credentials (ftp.txt):


Last but not least the attacker has to define where he wants to put the malicious code. He has the following options:

start page – Inject the code at the top of the page
end – Inject the code at the bottom of the page
change – Replace a text or a string in the page with the malicious code
check – Check if the malicious code is already on the page

Now the cybercriminal has just to press the “START” button to run the script. The Iframer script will now get through the FTP accounts and inject the malicious code which is defined in the file “iframe.txt” (see this one).

To make the use of the script more user friendly, the script has a readme file which describes the usage of the script in russian and english.

Content of readme.html (english):

This script is designed to test the FTP accounts on the validity, insert the code into files on the FTP.

[*] Console and Web interface
[*] Stabilno runs under Windows and Nix BSD
[*] Check for validity ftp
[*] Paste the Code (at the beginning or end of file. Or a full overwrite the file to your text – defeys)
[*] Strange Komentirovanie iframe’ov
[*] Convenience logs [*] All akki (valid \ invalid) remain in the database.
[*] The names of files, to insert the code can be set regExp’om, such as index \ .(.*)[_ b] or [_b ](.*). php | html | asp | htm.
[*] It takes on all the folders on the site.
[*] Function update replaces your old code to the new (for example, changed the addresses fryma)

[!] Recommend to use the console interface

Open a console (Start-> Run-> cmd)
Write to the path to php.exe for example c: \ php \ php.exe
then write the path to the script (zifr.php)
For example the so-c: \ php \ php.exe D: \ soft \ ziframer \ zifr.php
the script will run and display a certificate.

Open the console / ssh
Write to php then write the path to the script (zifr.php)
For example the so-php / home / user / soft / ziframer / zifr.php
the script will run and display a certificate.

-file -f Path to the file to your FTP
-code -c path to a file with code introduced
-inject -i Where vstavlt code three options
start – top of the page
end – in the bottom of the page
change – replace the text in the page code
-time -t Timeout for connecting to the FTP
-del -d With this option chyuzhye ifremy komentiruyutsya
-update -u Update your code with this option, the script ishet inserted your code and replaces it with a new
-good -g file where badat skladyvatsya working FTP
-bad -b file where badat skladyvatsya not working FTP
-hide -h If you enable this option, your code will not markerovatsya but you will not be able to use the function update
-restore -r Continue from the last FTP if you had not had time to do the whole list you can start from where you stopped


The Ziframe script is very simple an cheap. Even a n00b is able to use it.

It also demonstrates how efficiently and easily cybercriminals can distribute their malicious code to tremendous numbers of stolen FTP accounts. Automated mechanisms like this one shows how infection vectors are more and more shifted from E-mails with malicious attachments to Drive-by. The modular approach allows the cybercriminal to feed the script with different lists of compromised accounts that can be acquired on the underground market.