Satanbot Employs VBScript to Create Botnet

Malware is on the rise. At the beginning of 2008, our malware collection had 10 million samples. Today we have already surpassed 70 million. Most of the malicious samples are Trojans (backdoors, downloaders, fake alerts), but there are also a lot of viruses, worms, and bots that in a short time can infect many computers without user interaction. Usually the malicious code comes in a form of an executable or DLL, but sometimes malware authors opt to use alternate languages such as VBScript (Visual Basic Scripting Edition), a lightweight Active Scripting language that is installed by default in most Microsoft Windows versions since Windows 98. One example of this kind of malware is Satanbot: a fully functional VBScript botnet that uses the Remote Desktop Connection to connect to infected systems.

VBScript files are usually in clear text because they are interpreted at runtime, rather than being compiled previously by the author. However, for cases in which the user wants to avoid allowing others to view or modify the source code, Microsoft provides a command-line tool, Script Encoder, which will encode the final script by generating a .vbe file. This file looks like a normal executable, but it can be decoded to its original form. Once that file is decoded, we can look at the bot’s source code, which is divided by sections. Each section specifies a different function of Satanbot, most of which we’ve already seen in AutoRun worms like Xirtem. Here is a description of these functions:

  1.  Enable CMD and REGEDIT: To perform all the changes in the system (modify the registry and execute BAT files), the edition of the registry (regedit) or the use of the command line (cmd) will be enabled by changing the values “DisableRegistryTools” and “DisableCMD” to 0. In addition, one AutoRun feature is configured by creating the value “Update” in the “Run” key with the path of the script, along with hiding files and file extensions in the system.
  2. Disable UAC: The value “EnableLUA” is checked to verify whether it is necessary to disable the User Account Control in Windows Vista, Windows Server 2008 and Windows 7. If it is enabled, the script will create on the fly another script and a BAT file to disable UAC. Another modification in the registry is done to perform operations that require elevation of privileges without consent or credentials. At the end, all the temporary files used to do the modifications in the system will be deleted.
  3. Take ownership of folders: The command TAKEOWN (in Windows Vista and 7) runs to take ownership and enable the modification of folders including Application Data, Cookies, and Local Settings
  4. Self-Install and spread: Another BAT file in the %TEMP% path is created. It first changes the icon of .vbe files to the one used by Windows pictures so the user will think that it is a picture and not the malware. Also the original .vbe, along with a shortcut file, will be copied in several locations, including network shares and peer-to-peer shared folders from popular clients like eMule, LimeWire, and Ares. Another spreading vector this malware uses is infecting removable drives by creating autorun.inf files along with a copy of the original .vbe and a shortcut (.lnk) file.
  5. Worm test: This may seem a confusing term, but it is another spreading method. The original .vbe will be copied to other folders such as Startup and %Userprofile%\ Microsoft with the name “System File [Not Delete]” to trick the user to not delete the file.
  6. [email protected]: Contains a loop that will trigger the execution of the code every 60 minutes
  7. Backdoor: Using another temporary BAT file, the malware will enable Remote Desktop Access by making the following changes to the system:
  • Allow unsolicited remote assistance and full control
  • Allow the use of blank passwords
  • Enable multiple concurrent remote desktop connections (with a maximum of five)
  • Automatically start the Terminal Service
  • Open port 3389 in the Windows firewall
  • Add an administrator user to the system
  • Start the Remote Desktop Services UserMode port redirector service
  • Create a file in the bot’s path with an “OK” inside
  • The foregoing commands execute on reboot while the message “Windows repare quelques fichiers, patientez …” (Windows is repairing some files, wait …) appears to the user at the command prompt.


Another interesting part of the code is the section Compt.Bot, from which the malware sends an HTTP POST request with a specific user agent to the URL of the botnet command server. With that request, the server can get the public IP address of the infected machine, which probably has Remote Desktop Access enabled with the required specifications so the bad guys can connect. By opening that URL in the browser, we can see the IP address of the machine that is connected to the control panel and the number of compromised machines, which can grow very quickly. Take a look at this 24-hour comparison:

Other functionalities of the botnet:

  • Delete browser and user histories of some common software: Internet Explorer, Firefox, Chrome, Thunderbird, and Skype
  • Terminate processes of security software by downloading and executing a batch file that can be easily updated with more processes
  • Download an .exe file from another URL (currently offline). We need to examine this file more thoroughly, but one of its purposes seems to be updating the malware by executing a different embedded .vbe.


Even if VBScript is not the best language to hide malicious activities (using encryption, obfuscation, packers, antidebuggers, or anti-virtual machine features), it is pretty effective when we take into account the rate of infection in just one day. In addition, those scripts can build a botnet of infected machines that can be controlled by using a Remote Desktop connection, which allows the attacker to perform any action in the system. The malicious files related to this threat are detected by McAfee products as VBS/Satanbot.

Duqu: Updated Targeting Information

I wrote Symantec's original blog post describing the discovery of Duqu. In that blog I use the term "industrial control system manufacturers" and (after discussions with a variety of parties) we want to change that term to "industrial industry manufacturers" to more accurately define where Duqu has been found. We already made this change to our paper.

Finding the correct term can sometimes be a challenge. When we first wrote about Stuxnet, we originally used the term SCADA (supervisory control and data acquisition) and quickly discovered the proper term was "industrial control systems". In the computer security industry, we actually have specific definitions of viruses, worms, and trojans, while the general public often refer to any malware as just a virus. (In an unrelated coincidence we mismarked Duqu as a worm rather than a trojan, which is being corrected; no self-replication routine has been discovered so far.)

However, this change in language to "industrial industry manufacturers" does not change the threat to organizations we believe are at risk. We still have a number of variants of Duqu we have discovered where we do not know the target.

Considering the history of Stuxnet, the potential of the same attackers, and currently known targets, we urge industrial control system manufacturers and any other organizations who provide solutions to industrial facilities to audit their network for Duqu. The command and control IP is a reliable network indicator of Duqu infection for all the variants discovered so far.

In addition, industrial industry targets have not been the sole targets. We have also identified one or more targets outside the industrial industry who provide assets that would aid a future attack.

We will continue to provide updates as we uncover more information.

Comcast No Longer Choking File Sharers’ Connections, Study Says

Comcast appears to be in compliance with a Federal Communications Commission decision demanding the ISP stop throttling BitTorrent traffic, according to a new study.

A study this week by the Measurement Lab, first reported by TorrentFreak, verifies for the first time that Comcast has virtually stopped its throttling practices in the wake of the FCC’s order, which concluded that Philadelphia-based Comcast breached so-called net neutrality rules. A federal appeals court, however, said the FCC overstepped its authority, and the issue is tied up in the courts after the FCC introduced a new net neutrality plan.

Comcast has said it would comply with the FCC order, despite its legal uncertainty, and said it had the right to throttle to manage heavy traffic loads. Comcast says it has moved to a system that throttles heavy users during times of congestion, without picking on any particular application, a kind of network management policy generally accepted by network-neutrality advocates.

The study by the Google-funded lab also shows how disingenuous Comcast was when the FCC ordered it in 2008 to end its throttling practices. Throttling is the slowing or blocking of BitTorrent data, which consumes a large amount of bandwidth and is often associated with pirated movies, music and software.

“We did not block access to websites or online applications, including peer-to-peer services,” Comcast spokeswoman Sena Fitzmaurice said back in 2008. Six weeks after the order, however, Comcast came clean and disclosed its throttling practices.

According to the study, Comcast throttled 49 percent of all BitTorrent traffic in early 2008. Last year, according to the study’s most recent data, the number dropped to 3 percent.

Photo: Torkildr/Flickr

Urchins, LizaMoons, Tigers, and Bears

In early April, I wrote about the famed “LizaMoon” SQL-injection attacks. I said it then, and I’ll say it again now: SQL-injection (SQLi) attacks are a constant. Some of these attacks are more visible than others.  Some adversaries find intelligent ways to hide their tracks so as not to splatter evidence of their misdeeds all over various search engine results and caches.

There have been a number of reports and studies on the SQLi threat and the extent to which various regions/platforms/verticals/etc. are exposed. The basic takeaway runs along these lines:

  • On any given day, it is normal to expect to see around 1,600 SQLi attacks against the most attractive servers (Microsoft IIS/ASP.NET and Apache, for example)
  • The most prevalent and attractive (to the attackers) servers or platforms could easily expect to log 40 to 80 SQLi attempts per hour


Those are the current stats. Does this mean we should not be worried about the Urchin.js attacks? Goodness, no. But, my answer would be the same for the other 1,599 attacks going on every day.

As I highlighted in my previous LizaMoon blog:

Before any of us blow our IT budgets on database security goodies, we must all take the basic first steps. Simple and core techniques, such as constraining user input, validating user input, limiting types of input, encrypting sensitive data, and designing accounts with the principle of least privilege will go a long, long way.

The same basic principle holds true for this event.

On a side note, a few other handy stats may help put this into perspective.

  • According to Netcraft and a few others, there are around 505,000,000 sites on the web
  • Apache is the most popular web server platform, running around 327,000,000 sites
  • Microsoft (IIS/ASP.NET) is the second-most popular server platform, running around 79,000,000 sites


The SQLi attacks associated with the urchin.js script inclusion are specific to ASP.NET servers. Current stats indicate that the number of injected/affected hosts is just over 1,000,000.

This particular attack really began to take root at the beginning of this month.

Once the news broke, it was quite easy (via simple Google queries) to see evidence of the injections on affected sites.

Example Search Engine Results

Searchin' for Urchin

Technical Meat and Potatoes?

The injected script (urchin.js) forces the browser session to direct traffic to a number of malicious domains. At this point we have observed a variety of secondary malware. They range from the most basic generic Trojan families, to DNS changers, and now to rogue video codecs (bogus Adobe Flash Player, for example), which are backdoor Trojans.

The latest variants (example: MD5: fb4c93935346d2d8605598535528506e) are no different. This sample in particular is a rogue Flash Player install.

This Trojan contacts an number of remote hosts that are known to be “sketchy” and have been associated for years with other malware campaigns. (Remote hosts are registered under GigeNET.)

The LizaMoon Relationship

The original attack domains are:



Both of these share the same domain registration details as the original LizaMoon attacks.

Domain name: 

Registrant Contact:


James Northone
jamesnorthone @ hotmailbox .com

+1.5168222749 fax: +1.5168222749

128 Lynn Court

Plainview NY 11803


Again, both the original attack domains are registered under BIZCN.COM, which has a less than stellar reputation of associations (direct or otherwise) with malicious domains. This reputation can be traced back for several years.

Make Me Feel Safe–Again

I hope this information has put the threats in perspective. Don’t get me wrong; this attack is certainly visible, and deserves the attention of those who are exposed. I would like to stress (as we have done before) that this attack is one of many that occur constantly. Establishing a strong security posture and embracing the most basic and essential steps in web and database security will go a long way. You’ll find yourself much less exposed to Urchin.js as well as to the thousands of other SQLi attacks that are targeting your environments.

As of this writing, here’s your McAfee-specific coverage information:

McAfee AV/MWG Associated malware threats are covered under Generic.dx (varies),, and Generic Backdoor!dsm. This coverage also applies to the McAfee Web Gateway.
GTI-Enabled Coverage Coverage for associated domains/IPs is provided in deployments running the GTI component (example: McAfee Firewall Enterprise, McAfee Network Security Platform, McAfee Web Gateway, and more).


We will continue to update our content/coverage/countermeasures, as the situation requires.