[unisog] Significant Rogue DNS Activity To 184.108.40.206/22 (thanks to the "FreeVideo Player" Trojan)
eckman at umn.edu
Fri Nov 17 21:32:22 GMT 2006
Warning: long, somewhat detailed analysis 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
(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 220.127.116.11/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 18.104.22.168 and
22.214.171.124. 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
126.96.36.199/24, 188.8.131.52/24, and 184.108.40.206/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 220.127.116.11/24, and the other DNS server IP may
always be from one of the other two subnets.
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
(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.
The registry subkey "System" within
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
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.
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
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
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.
Brian Eckman, Security Analyst
University of Minnesota
Office of Information Technology
Security & Assurance
More information about the unisog