The following analysis of the "FreeVideo Player" trojan was shared with us by Brian Eckman of the University of Minnesota. We are pleased to share it with ISC readers with Brian's permission. His write-up is presented below.

---

For more than a month now, we have been seeing a steadily increasing amount of DNS traffic heading to a block of IP addresses assigned to a (supposedly) Ukrainian company called InHoster. This DNS traffic is coming directly from client computers - ones that should be configured to use our local DNS servers for recursion.

I traced back the actions of some computers that are exhibiting this behavior, and have found at least one example of what is causing it. What I found is a number of pornographic Web sites are hosting (purported) links to videos that, when clicked on, bring up a Web page that claims that you need to install a codec to view their videos. Clicking on the link to install the codec is simply a link to an EXE file hosted on a different Web server.

(I have not seen evidence of this being installed via browser exploits, nor evidence of it being installed via any other method without the knowledge and consent of the user.)

While the strategy of tricking people into installing a Trojan by claiming they need a codec to view the video isn't brand new, I haven't seen any information regarding this particular line of malware.

The Web server hosting the installer is http://www-dvdaccess-net/. (URL intentionally broken, replace - with .) As of Friday, November 3rd, and when checked again on November 16th and 17th, they were hosting 301 unique versions of the installer. The home page of that site offers http://www-dvdaccess-net/download/dvdaccess1000.exe to anyone who wants it. On top of that, dvdaccess[1001-1300].exe also exist, and some or all are pointed at by various pornographic sites as described above. When downloaded, all 300 of these files have a unique MD5sum value.

The dvdaccess[1000-3000].exe files use "NullSoft Install System" as the installer, and come with a somewhat professional-looking EULA. As most EULAs do, this one has a "catch" too. In fact, it's about the most blunt I've seen. It basically says they reserve the right to install third-party software. Period. No indication as to what types of software they might install, how or when it will be installed, what rights (if any) you have to remove that software while keeping the "FreeVideo Player" installed, or if removing the "FreeVideo Player" removes that software, etc.

(Interestingly, I mention that the EULA appears somewhat professional-looking. Reading it, there are a few clues that this software is at least shady, if not overtly malicious. First off, the Licensor is never defined. It claims to be a legally binding agreement, but it never claims who you are bound to. They claim that you must abide by the intellectual property laws, but never say where the origin of the software is, or what nation's law it claims to be under. Based on this, along with other observations, while I am not a lawyer, I am doubtful as to whether or not the EULA is enforceable in the US.)

Several AntiVirus (AV) companies detect at least some of these as variants of Zlob. For example, dvdaccess1000.exe was called "Zlob.UGF" by Norman Sandbox. Symantec claims to now (as of late last night) provide detection for one of the files generically as "Trojan.Emcodec".

From what I have seen, any AV company that detects this Trojan bundles detection of it in with other, related but still quite different Trojans (which is now common). Therefore, their writeups so far are mostly useless for describing how this line of Trojans works, what its capabilities are, etc. (Hopefully due to the number of variants, and the seemingly widespread infection rate, some companies will consider giving it a more appropriate name, such as Trojan.FreeVideo.)

Anyhow, the effect of this installation that caught my eye is the fact that it adds values to the "NameServer" key in several places in the registry. This overrides DNS Server values entered manually and those assigned by DHCP, taking over all DNS resolution functions for the clients. The different versions appear to use somewhat different IP addresses in that 85.255.112.0/20 netblock. From what I have seen, two IP addresses are chosen and those same two are used for the various registry entries that are created.

The DNS servers return a valid IP address as the answer for lookups that should be NXDOMAIN. If a non-existent record is accessed via a Web browser (for example, due to a typo), the wildcard entry will return a search page with links typically chosen by some porn-centric company.

Recently, I decided to install dvdaccess1094.exe on an old computer and a Virtual Machine, to perform further analysis. Here is what I found. Note that my findings are specific to the dvdaccess1094.exe file, and are possibly *slightly* different in the other 300 variants.

===================
DNS Server Settings
===================
The installation modified numerous registry settings pertaining to the DNS servers, including overwriting settings that are issued via DHCP. The settings given to my PC initially were 85.255.116.27 and 85.255.112.114. These settings were visible in the Network Connections applet within the Control Panel, as well as via `ipconfig /all`.

Modifying the settings via the Network Connections applet worked, and did survive a reboot. It does appear that it is not protecting these values.

From what I have observed, the InHoster netblocks being used for DNS are 85.255.112.0/24, 85.255.113.0/24, and 85.255.114.0/23. There are many dozen of servers in those netblocks that are involved. Cursory investigation leads me to guess that the Trojan may always pick one IP from a list inside of 85.255.112.0/24, and the other DNS server IP may always be from one of the other two subnets.

==================
Rootkit Technology
==================
The installation set a value in a typically-unused registry key that allows it to run an executable at startup. It set a value for HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon "System"="kdfle.exe"

(A subsequent install used a slightly different value "kdyda.exe", but did use the same DNS server settings. Another subsequent install used a different value AND different DNS server settings.)

That file is not visible via Windows Explorer, but it is obviously there, stored in %WINDIR%\System32. This is simple to check - if you try to create a file in %WINDIR%\System32 using whatever name is listed as the value for "System" within that Winlogon key, you are told that you cannot do this because a file with that name already exists here. If you try to open it via the command line using Notepad, you are told that Notepad cannot open it because an existing process has it open.

================================
Built-In FreeVideo "Uninstaller"
================================
Installation of the FreeVideo software visibly creates C:\Program Files\FreeVideo\uninstall.exe, as well as a shortcut to it in Start Menu>>Programs, and the necessary registry entries to remove it via Add/Remove Programs. Using this uninstall program does not change the DNS server settings back to their original settings, it does not remove the value for the System sub-key within HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, nor does it remove the executable that that key runs at startup.

===================
Symantec AV results
===================
SAVCE 10.1.4.4000 with definitions file "11/14/2006 rev. 34" did not detect dvdaccess1094.exe nor kdyda.exe, even with Heuristics turned up to the Maximum setting.

========================
Windows Defender Results
========================
Windows Defender with the most recent definitions as of November 14th did not detect anything during the installation, nor during a manual scan after installation.

========================
Rootkit Revealer Results
========================
The most recent version of Rootkit Revealer (v. 1.71) did not flag the hidden file "kdyda.exe" or anything else related to this software.

==================
Removal Challenges
==================
The registry subkey "System" within HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon cannot simply be deleted or modified. If you modify or delete it while the Trojan is running, it simply replaces the entry immediately. This also is the case when booting into Safe Mode. It may be possible to restrict access to write to the Winlogon key to only one user account, then use that account to change it, but the one time I tried it, I forgot to set permissions back for everyone else, and the machine got stuck in the Blue Screen of Death & reboot cycle, probably because SYSTEM no longer had the rights that it needed to the Winlogon key.

Obviously the technically savvy can find lots of interesting ways to remove it. Some are more dangerous than others. The most obvious ways involve booting an alternate Operating System and mount the hard disk containing the infection with read/write capabilities, and remove/rename the file.

Note that the file that was dropped in System32 contained a "modified" date that had been altered, so finding it by simply walking the System32 directory might be a challenge (although I suspect the file name will always be five letters, starting with "kd", and use the .exe extension - at least until they release the next version of it). In one test, I booted to "ntpasswd", used the registry editor functionality, and removed the registry value that started up the file. Upon booting to Windows, the file was visible to Windows Explorer (since it wasn't running), and could easily be deleted or renamed.

=================
Wicked Technology
=================
Further analysis shows that this appears to inject itself into running processes. One noticeable side effect is that it redirects certain Internet traffic within Internet Explorer. For example, I used the Search Bar in IE7 (I have Google Search as the default search provider on this Virtual Machine) to search for "BitDefender". IE brought up the Google search results. Network traffic analysis shows that I am indeed served up results from Google.

In tests where I clicked the link within the Google search results for the BitDefender Online Virus Scan, I was taken to any one of a number of Web pages. Some of them are various "search results" pages, some are trying to get me to buy AntiVirus software, etc. Network traffic analysis shows that Google takes me to BitDefender, BitDefender returns a page, but my client immediately also contacts a Web site in the InHoster IP space, which forwards me to a page, which forwards me to another page, one or two more forwards occur (all are "302 Found" messages that redirect the client to a different URL), before landing at the final destination page. It is that destination page that is rendered in my existing IE tab - not the BitDefender page!

Note that this activity occurred even though I had already changed the client's DNS servers back to our official DNS servers! My DNS query appeared in our DNS query logs, and my client did initially start to go to the BitDefender site before it went to another site (that neither I, Google nor BitDefender told it to go to), and IE showed me that page instead.

===============================
Additional Threat Possibilities
===============================
I have not observed any false DNS query responses, except for the wildcarding done for non-existent names (queries that should result in NXDOMAIN responses are instead given answers pointing to various places). Also, the instances of Web page redirection that I have observed have appeared to be revenue generating through pay-per-click services so far. However, I cannot stress enough that the capabilities of this Trojan would allow it to be incredibly effective (i.e., devastating) if used for phishing. If they decided to return false DNS answers for banks, credit monitoring companies, auction sites, etc., there is almost no protection for the end user. Even if they return valid DNS responses, they can present any page they want to the Web browser.

(Since they can install any code they want, inserting a new trusted root certificate into the Web browser (like MarketScore did) could even let them generate whatever SSL certificates they want. Heck, in that case, they wouldn't even need to return false DNS results to steal credentials to Web-based services. But I digress.)

Also, since this Trojan can apparently return whatever Web content it wants (to Internet Explorer, anyhow), there is no telling what havoc they might wreak if they decide to redirect certain program downloads. ("You want the new Acrobat Reader? Sure, I've got that right over here....")

============================
Virtually Unlimited Variants
============================
In order to better determine if the Web site was simply serving up random variants of this FreeVideo Trojan, regardless of the filename requested, I asked some colleagues for assistance. Warren Raquel (UIUC.edu), Louis Brooks (FSU.edu) and I each downloaded all 301 files from the dvdaccess-dot-net Web site, all within an hour of each other. We each ran md5sum against our local cache of the 301 files, and compared results. We wound up with 903 unique md5sums!

Afterwards, Scott Dier (UMN.edu) went one step further and downloaded all 301 files from three different IP addresses. All 903 resulting files had unique MD5sum values, and all did not match any of those that the rest of us found.

All of us verified that we could re-download any or all of the filenames from the same IP address and receive a file with the exact same md5sum that we received previously. This showed that we were not receiving random files - a single IP Address will always get the same md5sum value when requesting the same filename. (I checked a packet capture to make sure that the Web server was indeed sending the file again, and was not trying to rely on a HTTP 304 code.)

Scott went on to show that the dvdaccess[1000-1300].exe files decompressed into two different malware binaries - step1.exe and step2.exe. He discovered that all of 903 files (all 301 files, each downloaded from three different IP addresses) that he downloaded had unique MD5sum values for step1.exe, but there were only 301 unique values for the md5sum of step2.exe.

This leads me to believe that once someone requests one of the dvdaccess[1000-1300].exe files from the Web server, a process starts that:

1. Generates a step1.exe file that will be tied to that dvdaccess[1000-1300].exe file and the IP address of the downloading host.
2. Takes the pre-compiled step2.exe file that corresponds with the requested dvdaccess[1000-1300].exe file.
3. Packages them together and hands them to the Web server to present to the requester.

=======
Summary
=======
I believe that this software clearly fits the definition of a Trojan Horse. From what I have been able to gather thus far, the apparent motive is profiting from pay-per-click advertising. I do not know and cannot speculate at this time if this is the only motive, the primary motive, or simply a front for more insidious tactics.

The engineering of this Trojan and the social engineering behind its spread appear to me to be far more advanced than typical Web browser exploits and IRC bots. It is clear that we are dealing with a well organized crime ring that has significant resources at hand, including lots of IP space, bandwidth, as well as talented in-house programmers, sysadmins and marketing analysts. Considering their capability to distribute 301 unique variants of the same malware on a Web server, they clearly have the ability to distribute 301 different ones once enough companies start detecting their current versions. (Not to mention that they have plenty of other "business" taking place on this IP space.)

Finally, all of this analysis was performed by observing changes made to the computer by this Trojan, as well as authorized network packet captures taken from a computer in the path of the network traffic. No reverse engineering of any of the components was performed, as that would violate the terms of the (likely not enforceable) EULA.

---

The above overview of the FreeVideo Player trojan, which we referenced in the November 19, 2006, diary, was written and shared with us by Brian Eckman. Thanks, Brian!