A Normal Day at the Office

(Never ending story...)

We arrived a bit early at the office the other day. It was a beautiful sunny day, you know, typical weather when you have to work 😀 Soon after arriving, we stumbled upon what became an interesting case. It was an executable file that apparently was related to the DNS cache poisoning attack that happened a few days prior, and we had to see what was it all about. One file, right?

Below we will try to present the whole picture, starting with how the DNS cache server gets poisoned up to what kind of malicious programs will try to make their way into your computer.

Let’s start from the beginning.

An attacker will do a poison attack on a DNS cache server in order to redirect a user to a malicious website. Now, the DNS server does the translation from hostnames to IP addresses. A DNS cache server is a server that will try to add into an internal database all the results of the queries that are made in a certain amount of time, so that when a new request arise for the same domain, it will not have to query the DNS server that is authoritative for that domain. In this way the replies are sent much faster. But when there is something new, it will request an answer from an external source about a certain domain.

A malicious user may forge some packets to appear as legitimate responses to those queries. The trick is to guess the identifier (ID) for that query. This is a 16-bit number assigned by the program that generates any kind of query. This identifier is copied to the corresponding reply and can be used by the requester to match up replies to outstanding queries.

If the malicious user can "guess" it then it may interfere with the normal operation of the DNS cache server.

The attacker will send requests for random hostnames for a certain domain and it will also send answers that appear to be coming from the authoritative DNS server of that domain. In order to guess the transaction ID, it will send thousands of packets with different id’s in the hope that one will be recognised as valid. In this way, by spoofing the packets, it is possible to alter the original records about the targeted domain.

So by feeding the cache-server a bunch of fake hostnames for a target domain, the attacker will be able to sneak in a fake entry that will replace the original records for that domain.

As an example (see above) if a user will try to access the foobar.com (by querying the poisoned cache-server), then in the end he/she will be redirected to a web server that is controlled by the attacker.

The real tale begins here. After a request to the poisoned DNS server, our user will get redirected to a webpage that will have an iframe into it. This iframe leads to various websites with exploits, malware programs, etc. All sorts of nasty things that try to make their way into the system.

So, once the user is redirected to the injected iframe

(#1) wori???/a25.htm

the page loads another iframe and a malicious javascript

(#2) wori???/new.htm
(#3) js.users.???la/1836606.js

While the (#3) javascript is basically there for statistics purposes, the (#2) new.html file is the cookie jar no one should get their hands into. Besides setting a cookie, it also contains reference to no less than seven other malicious script files. While the first three scripts are loaded by simple iframe references, the next four would be loaded by targeting Real Player exploits.

(#4) wori???/14.htm
(#5) wori???/as.htm
(#6) wori???/fx.htm
(#7) wori???/real11.htm
(#7b) wori???/real10.htm
(#8) wori???/lz.htm
(#9) wori???/Bfyy.htm

The first one in the batch (#4) is an obfuscated script that uses an Adodb vulnerability to download and execute the following:

(#10) user1.16???/ms06014.css

which is in fact a malicious executable.

Next one in iframe batch (#5) is exploiting Snapshot Viewer Control vulnerability to download and execute:

(#11) user1.16???/as.css

Last script in the iframe batch (#6) gets to check the user’s browser and if the browser is Internet Explorer it loads:

(#12) wori???/mlink.html


(#13) wori???/xlink.html

Here’s where things really start to get complicated.

Files (#12) and (#13) use basically the same concept to load maliciously crafted Shockwave files, that target specific versions of the Adobe Flash Player using an open source javascript (SWFObject) that can  detect the flash versions in all major web browsers.

File (#12) will attempt to download one of the following:

(#14) wori???/m15.swf
(#15) wori???/m16.swf
(#16) wori???/m28.swf
(#17) wori???/m45.swf
(#18) wori???/m47.swf
(#19) wori???/m64.swf

File (#13) attempts to download

(#20) wori???/x15.swf
(#21) wori???/x16.swf
(#22) wori???/x28.swf
(#23) wori???/x45.swf
(#24) wori???/x47.swf
(#25) wori???/x64.swf

Each of these malicious Shockwave files (#14) to (#25) contain

and attempt to download one of these two files, using urlmon.dll:

(#26) wori???/a25.css
(#27) wori???/i64.css

Not lost yet? Wait... there’s loads to come for your enjoyment 😀

We’re now going a bit back in our tale, for files (#7) to (#9)

File (#7) exploits Real Player, file (#8) exploits Ourgame GLWorld ActiveX Control and file (#9) uses a Baofeng Storm ActiveX Controls exploit. All three try to download and execute the same

(#28) dz.???/bak.css

which is now offline.

File (#7b) continues the “cat-and-mouse” game and loads a malicious javascript

(#29) wori???/real10.js

which at the end points, you guessed, to the same (#28).

Simple, isn’t it? Let’s dig further.

Files (#10), (#11), (#26), (#27) are very similar. Once executed, they copy themselves to <system folder>\sunsekv\svchost.exe, set a registry key as

HKLM\Software\Microsoft\Active Setup\Installed Components\{97abb985-1f23-6478-6478-2034421e6623}
"StubPath" = "<system folder>\sunsekv\svchost.exe /t"

and they connect to (using several input parameters)


from where a list of files to download (#30) is obtained. This (#30) list contains:


Which is a big collection of password stealers belonging to the OnLineGames/Tilcun family.

At the end of the day we conclude this was a very good day for research (it rained anyway).

--Andrei Saygo && Marian Radu && Patrik Vicol

Comments (2)

  1. Anonymous says:

    183 Microsoft Team blogs searched, 87 blogs have new articles in the past 7 days. 205 new articles found

Skip to main content