Tcposmod.exe First Trojan Tracking Journey

Back Home

Last Updated: Monday May 09, 2005

Michael Ligh (

Thanks to SANS for linking here from their Diary on June 30, 2005

Table of Contents

  1. Introduction
  2. The 1st Experiment (May 2003)
  3. The 2nd Experiment (June 2003)
  4. Discussion
  5. Summary, Conclusions, and Further Work
  6. The 3rd Experiment (July 2004)
  7. References And Additional Information
  8. Appendix A. Duplicate This Research
  9. Appendix B. Linksys Logs From 1st Experiment
  10. Appendix C. A Final Word
  11. The 4th Experiment (May 2005)


The content here claims a software author’s program, as it is readily available on the net for download, is bundled with a trojan of some sort. The author was given ample time and proof to either validate or dispute this claim. Since neither occurred and several people are awaiting information on this program, I am releasing it now, without the author’s input. As needed, revisions may occur in time if a response from the author is received.

This paper was built by combining two smaller pieces of work with tcposmod.exe. The first part presented here is the relevant chapter from a multi-topic paper completed at the beginning of May 2003. The second was completed in mid-June and serves to fill the gaps left by the initial research. Thus far tcposmod has either been unexplored or terribly undocumented (If you don't believe me, try searching for it). Most major conclusions are near the end; while the earlier sections discuss the methods used to draw them.

The 1st Experiment (May 2003)

This section has an interesting beginning and middle, however the ending is disappointing. So, I’ll just get the ending out of the way: I don’t know when this software made its way onto my laptop, nor do I know where it came from or how it got there. Spyware has a reputation of accompanying the install of programs or simply downloaded files. The possibilities are far too many to even attempt re-acquisition in search of its source. Rather, I will concentrate on the more manageable factor: what it does.

The program is named tcposmod.exe and was found in the C:\WINNT\system32 directory of a Windows 2000 machine. I will explain how it came to my attention later on. It was removed from the system immediately and backed up to floppy disk for research purposes such as this. There was also a value of “DSS” added to the registry along with a pointer to the executable (C:\WINNT\system32\tcposmod.exe) at this location:


I noted that this path also provides residence to Norton Antivirus and DU Meter strings on my personal system; which causes both programs to run at boot-up. In this manner, the tcposmod.exe process is started automatically by Windows each time the computer is booted; and remains active for as long as the computer is on. It also means that once placed on the drive, it cannot become active until the first reboot. Since many Windows applications require a reboot following installation, spyware that comes along with it is quickly activated.

So, to begin the monitoring process, I copied the program from the floppy disk back to its original directory and added the registry string at the correct location. Just to verify it would not become active before the reboot, I checked Task Manager for any running process named tcposmod.exe and the DOS ‘netstat’ command for any invalid open connections: there were none. It was time to reboot.

DU Meter (Download / Upload Meter) is a program that provides graphical output when the system is downloading or uploading data. It also calculates statistics on the amounts of data transferred within specified time periods. This is how the existence of tcposmod.exe was first brought to my attention - red peaks dominating the graph when I was neither downloading nor uploading intentionally.

I allowed tcposmod.exe to run for almost 8 minutes (it began at startup, as predicted). During this time frame, 2.95 MB of data were downloaded and 359.8 KB were uploaded. The uploading, based on such a small amount, was most likely my computer’s outgoing ACK’s to the data being downloaded; letting the sender know it had been received.

Task Manager revealed the process using 7,054 KB of RAM when idle. Once an Internet connection was provided, this value peaked at 21,372 KB. During the flood of communications, tcposmod.exe was draining as much as 79% of the CPU resources.

My Linksys firewall/router logged the stats from each outgoing packet. Connections initiated by tcposmod.exe seem to be limited to port 80; except one to 137 (netbios) and one to 443 (SSL). Among the remote locations were,,,, and even The log is composed of 144 connections (see Appendix B), which is about 18 per minute.

tcposmod.exe resides on a hard drive w ith the hidden, read-only, and archive attributes set. It is (falsely) copyrighted as “Copyright (C) Microsoft Corp. 1981-2002” and reports having an original name of dss6.exe.

The 2nd Experiment (June 2003)

This report comes as a sequel to the daunting and previously unanswered questions regarding the tcposmod executable found on my laptop. In particular, the source and infection mechanism of the code is no longer a mystery. The program’s behavior can also be understood to a certain degree.

The first experiment revealed tcposmod’s most noticeable behavior was to initiate outbound connections at a rapid pace. At that point we were unable to discover little else besides how many connection attempts were made, where they were aimed, and the bandwidth this consumed. This limitation prevented anything more than speculation regarding the nature of the packets transmitted and data within them. The purpose of this second round of testing was to go beyond this limitation and spy on the so-called spyware, Trojan, or whatever it is.

The experiment will be conducted again on the same Windows 2000 laptop. This time instead of a Linksys router as the source of outgoing connection logs, there stands in its place a Linux machine through which all traffic bound for either direction must first pass. Running Snort in Network Intrusion Detection System mode, all traffic set on the wire by my laptop will be sucked up into Snort’s realm of packet capture.

The laptop can be identified on the network with its IP address of Because the Linux system is now the firewall and default gateway for all other systems on the network as well, I will collect the traffic with the following snort configuration file and command line options (if not I would have to shuffle through 4 computer’s traffic rather than 1):

output log_tcpdump: tcposmod.log
pass udp $DNS_SERVERS 53 <> $HOME_NET any
log ip $LAPTOP any <> $EXTERNAL_NET any

[root@fw]# snort -i eth1 -c ~/snort.conf -l ~/log -b

What this does is tell Snort to output all traffic to and from the laptop and store it in a separate log file. It essentially ignores any traffic generated by other machines on the network. I also opted to let the laptop's DNS queries pass through the filter, as they would not be part of the suspicious traffic. This contributes simplicity and organization to the post-experiment log auditing task, which otherwise would be rather hefty.

This time, tcposmod was activated for a duration of 6 minutes. The resulting traffic log is 8 MB as a text file. Active Ports 1.4 was used to ensure this traffic was indeed generated by the process named tcposmod.exe. Now, to keep the suspense rolling I will discuss where this thing came from in the first place. The answer is: mungabunga.exe (HTTP Brute Forcer 1.0.3). How is that an answer? The mungabunga brute forcer is a web-based password cracker. It can be downloaded from several internet sites, mainly, which is the home of the software’s author. Upon installation, tcposmod is covertly carried along.

Though I say "covertly," the file's name is actually flashed during the installation process of mungabunga.exe. Most users would not notice this, however my laptop is six years old, thus anciently slow; and I was staring. Deleting the mungabunga executable and other files in its directory does not remove tcposmod.

Interestingly enough, the following paragraph can be found on Hackology’s website:

We have been informed of some web sites distributing altered copies of this program, please only download our software from our site. It appears as though some web sites bundled the program with a home grown Trojan. The Trojan is not harmful in any way just annoying (according to our tests). In addition, Trend Micro (apparently) has issued a patch for the Trojan.

If you have downloaded our software from another site, we are in no way liable. Please do not download from unapproved sites, or sites that you cannot trust. We suggest you only download our software from our site, or other sites that are approved by The Hackology Network.

Regards, MB [1]

At the time of this reading, it was unclear if the Trojan referred to in this message was tcposmod.exe. The following email to MB himself revealed that it was not, as he was not aware of such a program.

Received: Wednesday, 11 June 2003 11:29 PM
Subject: RE:Tcposmod.exe


We are not aware of such a Trojan... in order for us to test your claim, please tell us what monitoring software or firewall software you are using or have used to detect this trojan... once done... we will try to replicate your findings on our end exactly as you did, so that we may find the culprit. Our traditional methods did not work.

Once again, do let us know!

-----Original Message-----
> Sent: Wednesday, 11 June 2003 6:19 PM
> To:
> From:
> Subject: Tcposmod.exe

> MB,

> I'm writing to inquire about the executable named tcposmod that
> accompanies mungabunga.exe (1.0.3) and adds a registry key to run
> at startup. During a test it initiated 144 TCP connections to port
> 80 of web servers around the net in about 8 minutes. It doesn't seem
> to do more than fill up the temporary internet files folder with
> random web page material.

> I read your trojan warning and agree if this is what you refer to
> that its not harmful, just annoying. But, mungabunga was downloaded
> from and no other site. Actually the link on hackology
> to download it leads to at, so I don't know
> if that is affiliated with you.

> Well, I just wanted to know if you were aware of it and if you are:
> what purpose does this program serve?

> Thanks,

> MH


I have sent my proof and am awaiting a response, which I may or may not get. Meanwhile, we still have a nearly 8 MB text file of Snort’s output to talk about. This comprehensive log suggests several key findings:

Summary, Conclusions, and Further Work

We know tcposmod.exe is installed under our noses along with mungabunga.exe downloaded from It seems to be a standalone program capable of binding to ports, sending and receiving data, and interacting with other files and directories on the machine. We know where tcposmod.exe resides on the hard drive and the value of its corresponding registry entry. Removal of these two will effectively bring the overt suspicious behavior to a halt. I say ‘overt’ rather than ‘all’ because what this research presents cannot be considered exhaustive without source code of the program to validate.

In other words, the longest period of time tcposmod was allowed to run was 8 minutes. It is possible that behavior might change drastically on the 9th minute. It is possible other actions are being carried out against the local system and the noisy network activity is just a disguise. It also may behave differently when run in conjunction with mungabunga.exe.

Speculation of this will remain until MB or someone with reverse engineering skill can produce some source code. Or, simply track down the person who wrote and inserted tcposmod into MB’s program, since it was not him (as he says); and ask what else (if anything) it does. A possible motive could be to launch a distributed denial of service against the hosts or domains visited by tcposmod. If present on several machines on the same LAN, the program could easily consume a majority of the network’s own resources as well.

The 3rd Experiment (July 2004)

Alright so I hope I'm not the only person who thinks this is funny. Over a year ago we found tcposmod and notified the author of the program it was bundled with. The author claimed his servers were hacked and code inserted into his program. The irony here is that a year later, the author's program, which happens to be a hacking script for brute force password guessing, is still "infected" with the tcposmod trojan. I HAVE to believe that MB (see the emails below) and his crew are better coders than that. Anyone who overlooks an entire executable packed within a program they update frequently and rave about has serious security issues.

I thought about wasting some more time on tcposmod because it seems people are still getting infected with it, quite often; and there is still a major shortage of information about it on the web. The test setup is a little more advanced than a year go, which gives us some extra tools and more analytical capabilities as well. I built a Windows 2000 VMware machine and downloaded a copy of munga bunga brute forcer (mbhttpbf.exe) from I installed cygwin to get some basic Unix tools onboard (mainly find) and proceeded to install the brute forcer. I quickly checked if tcposmod.exe was in C:\WINNT\System32 and at the registry location for auto start at boot; and then rebooted the machine. The process ran for a few minutes as once again, I captured all the network traffic at the gateway.

The first HTTP GET request that originated from the machine was for a file named /data/fxn.txt, which was encoded or encrpyted in some format I'm not able to read, though I can guess with a high degree of confidence that this is the file in which the domains/IP addresses exist. Once the file was dowloaded, tcposmod began initiating connections to various sites, once again, probably derived from the content of fxn.txt. There were:

mhale@fire:~> grep "\*\*\*\*\*\*S\*" tcposmod.cap | wc -l

mhale@fire:~> grep TCP tcposmod.cap | grep TTL | awk '{print $3}' | egrep -v | cut -d: -f1 | sort -rn | uniq | wc -l

mhale@fire:~> grep GET tcposmod.cap | wc -l

In other words, in the appoximately 7 minutes tcposmod was active, it made 329 connections to 65 unique destination servers and issued 644 GET requests for arbitrary files. On subsequent review, most of the files were images, javascripts, and html. There were no executables, cabs, dlls, chms, or htas downloaded, which is good. Whats NOT good is that tcposmod comes with its own additional set of files to install on the machine. These were either not part of the original mbhttpbf.exe or I was not keen enough to notice. Either case is equally likely. Putting cygwin to use, after terminating the tcposmod process I searched for the file system for anything modified or created within the past 24 hours. Here are the critical ones:

$ find . -type f -ctime -1



It appears tcposmod is not the only trojan bundled with munga bunga's software; it is accompanied by several dll, ocx, and a misspelled notpad.exe. No puns intended I guess, notpad.exe is really not notepad.exe. Anyway, it looks like the brute forcer to hack passwords on other machines is really just a venue for munga bunga and crew to hack your own machine. I was lucky enough to get a second option on the purpose of tcposmod from someone with BASIC reverse engineering skills. This is what he had to say:

From what i can tell, by doing some BASIC reverse engineering, it uses "msinet.ocx" to access web sites & socketX.ocx ( which is a winsock type control (client/server applications). I found the socketX.ocx control in my system32 folder & I dont know where it came from...

Well, now we know for sure where socketX.ocx came from; and the facts about msinet.ocx are interesting, but not surprising. What I like about the other information he gave us is the theory on tcposmod's main function:

I think mb has created this 'tool' to access click-thru sites, that he has signed up for, to gain him hits. according to him he says that not many people download mungabunga http cracker but I think there is quite a lot! So lets say that 1000 people are infected with tcposmod and they all access his click-thru sites unknownly via tcposmod, and say there is about 20 click-thru sites in the list (i didnt count them). So that 20 * 1000 = 20000. And if all of the click-thru sites where offering 1p per hit he would get 200.00 per day!!

Of all the possible intentions, that seems like the most likely. No others seem to fit like that one does.

References and Additional Information

[1] Hackology: Trojan Warning

Trend Micro search for “munga”

The AntiOnline Discussion

The TrojanForge Discussion

The Discussion at Stormfront White Nationalist Community forum (whatever that is) if you can read German (I can’t).

The Advisory
I am unable to validate much of the information here, however.

Appendix A: Duplicate this research (the 1st experiment)

The following steps, if carried out in order, should produce the same effects as I have described in this paper.

Software & Hardware Index

1st Experiment Operating System: Windows 2000 Pro

Monitoring Software

2nd Experiment Operating System: Windows 2000 Pro

Monitoring Software

Scanning Software

Appendix B

Linksys Logs from the 1st Experiment:
Date Time Src Src_Port Dest Dest_Port
05/01/2002 20:42:52 1032 80
05/01/2002 20:43:06 1037 80
05/01/2002 20:43:20 1039 80
05/01/2002 20:44:13 137 137
05/01/2002 20:44:34 1042 80
05/01/2002 20:44:37 1044 80
05/01/2002 20:44:37 1046 80
05/01/2002 20:44:39 1047 80
05/01/2002 20:44:43 1049 80
05/01/2002 20:45:00 1074 80
05/01/2002 20:45:02 1076 80
05/01/2002 20:45:02 1078 80
05/01/2002 20:45:02 1081 80
05/01/2002 20:45:02 1082 80
05/01/2002 20:45:03 1084 80
05/01/2002 20:45:08 1086 80
05/01/2002 20:45:09 1091 80
05/01/2002 20:45:09 1092 80
05/01/2002 20:45:11 1096 80
05/01/2002 20:45:11 1097 80
05/01/2002 20:45:11 1099 80
05/01/2002 20:45:14 1103 80
05/01/2002 20:45:15 1104 80
05/01/2002 20:45:15 1105 80
05/01/2002 20:45:15 1111 80
05/01/2002 20:45:18 1113 80
05/01/2002 20:45:23 1116 80
05/01/2002 20:45:23 1118 80
05/01/2002 20:45:23 1120 80
05/01/2002 20:45:23 1122 80
05/01/2002 20:45:24 1124 80
05/01/2002 20:45:24 1127 80
05/01/2002 20:45:24 1129 80
05/01/2002 20:45:24 1130 80
05/01/2002 20:45:24 1132 80
05/01/2002 20:45:25 1133 80
05/01/2002 20:45:25 1135 80
05/01/2002 20:45:25 1137 80
05/01/2002 20:45:25 1138 80
05/01/2002 20:45:25 1140 80
05/01/2002 20:45:26 1141 80
05/01/2002 20:45:28 1142 80
05/01/2002 20:45:28 1143 80
05/01/2002 20:45:28 1144 80
05/01/2002 20:45:30 1149 80
05/01/2002 20:45:32 1150 80
05/01/2002 20:45:32 1152 80
05/01/2002 20:45:32 1153 80
05/01/2002 20:45:33 1159 80
05/01/2002 20:45:36 1161 80
05/01/2002 20:45:41 1163 80
05/01/2002 20:45:42 1165 80
05/01/2002 20:45:42 1167 80
05/01/2002 20:45:43 1169 80
05/01/2002 20:45:53 1171 80
05/01/2002 20:45:55 1172 80
05/01/2002 20:45:55 1176 80
05/01/2002 20:46:00 1177 80
05/01/2002 20:46:05 1179 80
05/01/2002 20:46:12 1188 80
05/01/2002 20:46:12 1190 80
05/01/2002 20:46:12 1192 80
05/01/2002 20:46:12 1194 80
05/01/2002 20:46:13 1196 80
05/01/2002 20:46:15 1199 443
05/01/2002 20:46:35 1200 80
05/01/2002 20:46:36 1201 80
05/01/2002 20:46:41 1203 80
05/01/2002 20:46:42 1204 80
05/01/2002 20:46:50 1207 80
05/01/2002 20:46:50 1209 80
05/01/2002 20:46:57 1212 80
05/01/2002 20:47:01 1213 80
05/01/2002 20:47:01 1218 80
05/01/2002 20:47:02 1219 80
05/01/2002 20:47:02 1221 80
05/01/2002 20:47:03 3155 110
05/01/2002 20:47:05 1222 80
05/01/2002 20:47:06 1224 80
05/01/2002 20:47:06 1225 80
05/01/2002 20:47:07 1231 80
05/01/2002 20:47:09 1234 80
05/01/2002 20:47:17 1250 80
05/01/2002 20:47:17 1252 80
05/01/2002 20:47:17 1253 80
05/01/2002 20:47:17 1255 80
05/01/2002 20:47:18 1256 80
05/01/2002 20:47:26 1264 80
05/01/2002 20:47:35 1265 80
05/01/2002 20:47:35 1266 80
05/01/2002 20:47:35 1267 80
05/01/2002 20:47:42 1268 80
05/01/2002 20:47:43 1272 80
05/01/2002 20:47:44 1274 80
05/01/2002 20:47:51 1276 80
05/01/2002 20:47:52 1277 80
05/01/2002 20:47:53 1278 80
05/01/2002 20:47:57 1279 80
05/01/2002 20:47:57 1280 80
05/01/2002 20:48:05 1288 80
05/01/2002 20:48:05 1290 80
05/01/2002 20:48:24 1299 80
05/01/2002 20:48:25 1301 80
05/01/2002 20:48:25 1302 80
05/01/2002 20:48:25 1307 80
05/01/2002 20:48:28 1308 80
05/01/2002 20:48:29 1311 80
05/01/2002 20:48:29 1312 80
05/01/2002 20:48:29 1313 80
05/01/2002 20:48:29 1316 80
05/01/2002 20:48:32 1318 80
05/01/2002 20:48:33 1319 80
05/01/2002 20:48:33 1320 80
05/01/2002 20:48:33 1321 80
05/01/2002 20:48:34 1323 80
05/01/2002 20:48:34 1325 80
05/01/2002 20:48:35 1327 80
05/01/2002 20:48:36 1330 80
05/01/2002 20:48:36 1331 80
05/01/2002 20:48:36 1332 80
05/01/2002 20:48:36 1333 80
05/01/2002 20:48:40 1334 80
05/01/2002 20:48:41 1335 80
05/01/2002 20:48:41 1337 80
05/01/2002 20:48:41 1339 80
05/01/2002 20:48:42 1341 80
05/01/2002 20:48:42 1342 80
05/01/2002 20:48:42 1344 80
05/01/2002 20:48:46 1346 80
05/01/2002 20:48:48 1348 80
05/01/2002 20:48:55 1351 80
05/01/2002 20:48:56 1355 80
05/01/2002 20:48:58 1357 80
05/01/2002 20:49:00 1358 80
05/01/2002 20:49:03 1367 80
05/01/2002 20:49:04 1368 80
05/01/2002 20:49:11 1372 80
05/01/2002 20:49:13 1377 80
05/01/2002 20:49:15 1379 80
05/01/2002 20:49:18 1381 80
05/01/2002 20:49:20 1384 80
05/01/2002 20:49:22 1385 80
05/01/2002 20:49:38 1392 80

Appendix C: Final Word

-----Original Message-----
From: MB []
Sent: Saturday, December 06, 2003 10:34 AM
To: 'michael hale'
Subject: RE: Tcposmod.exe

I will be looking into this properly soon, just haven't had no time to even be in front of a computer recently.

How have you been anyway?

-----Original Message-----
From: michael hale []
Sent: Friday, 14 November 2003 6:16 AM
Subject: RE: Tcposmod.exe

Greetings, MB, it looks like we have another problem. It's been nearly 5 months since your last message stating the removal of tcposmod.exe from mbhttpbf, alas, it has either *not* been removed or has found its way back. This is not an attempt to complain on my own part, honestly I could care less - I didn't even think to check again without a boost from some recent information.

Conversations of tcposmod are showing up in forums, news boards, and the like. People want to know where this executable comes from and why. Your very experienced security contact is not keeping things very secure and the truth is going to come out sometime. I figure it is my job to warn you since I am one of the very few who actually knows the truth.

I am still in favor of keeping this a secret, yet a trojan is a trojan - harmful or not - and if you wish to retain the trust of the public you would want to realize this. I am only willing to maintain this stance of confidentiality if you are willing to respect the users who download your software, and, ultimately what gets installed on their systems as a result.


-----Original Message-----
From: MB []
Sent: Wednesday, June 18, 2003 4:27 PM
To: 'Michael Hale'
Subject: RE: Tcposmod.exe


Thank you for the report, after looking into it in greater detail, and escalating the issue to our security contact (who is very experienced), we have found that it does reside in the mungabunga file, and have removed it.

As we speak, a clean version of mbhttpbf is being uploaded, and we'll be trying to investigate the source of this infection. I believe someone may have gained access to our servers to distribute this Trojan.

It doesn't seem dangerous or worrisome though (the trojan that is), and we believe that you've found little documentation on it because it is not very popular at all... we suspect only a few machines would have been infected with it.

Probably just some school kids practice at programming, writing silly little annoying & somewhat pointless applications, who knows?

Once again, thank you for the report.

I do suggest that you hold the publication of the document; otherwise it would bring us unnecessary negative attention, rumours etc... And people may believe that we were the source... and if we tell them otherwise, then we'll have to publicly make known that our servers were hacked (which is really not good). I'm sure you understand.

If you would like to talk about this further, we are more then happy to.

We will also correspond with you with any further findings.

Once again, the scope of this kiddie-code doesn't really seem significant or threatening enough to publish the report and give us a bad name. When you weigh the trojans significance to the potentially bad reputation it would give us. It's a loose-loose situation.

Speak to you soon.

-----Original Message-----
From: Michael Hale []
Sent: Thursday, 19 June 2003 5:25 AM
Subject: RE: Tcposmod.ex


Yes, you would most definitely have empty software logs without the hardware to produce them.

Enclosed is a document explaining my methods, key findings, and conclusions regarding tcposmod.exe in further detail. It should be more than enough to at least verify tcposmod's existance within mungabunga.exe (by checking the registry and system folders after
installation) even if you can't verify what network traffic it produces. For this purpose I would suggest a packet sniffer such as Snort or tcpdump.

It was prepared for myself and several others wishing to solve the mystery created by finding this software on their systems. I have not released it yet because - I would like to end it on a good note such as "Tcoposmod.exe has been sucessfully removed" so as to not correlate any trust issues with your software in the future. Better yet, maybe there is a solid explanation and/or someone responsible for inserting the executable without your knowledge.

Please continue to help resolve this.


-----Original Message-----
From: MB []
Sent: Wednesday, June 18, 2003 2:18 PM
To: 'Michael Hale'
Subject: RE: Tcposmod.exe


I installed The LinkSys LogViewer, however, it did not log anything.

I am assuming that one needs The LinkSys BEFSR41 hardware for the LinkSys LogViewer to work?

Let me know, thanks.

-----Original Message-----
From: Michael Hale []
Sent: Wednesday, 18 June 2003 11:30 AM
Subject: RE: Tcposmod.exe

MB & Friends,

Any news on this yet? It's been almost a week. As of last night, mungabunga.exe from still contains tcposmod.exe so I am just checking up.


-----Original Message-----
From: MB []
Sent: Wednesday, June 11, 2003 11:29 PM
To: 'Michael Hale'
Subject: RE: Tcposmod.exe


We are not aware of such a Trojan... in order for us to test your claim, please tell us what monitoring software or firewall software you are using or have used to detect this trojan... once done... we will try to replicate your findings on our end exactly as you did, so that we may find the culprit. Our traditional methods did not work.

Once again, do let us know!

-----Original Message-----
From: Michael Hale []
Sent: Thursday, 12 June 2003 8:19 AM
Subject: Tcposmod.exe


I'm writing to inquire about the executable named tcposmod that accompanies mungabunga.exe (1.0.3) and adds a registry key to run at startup. During a test it initiated 144 TCP connections to port 80 of web servers around the net in about 5 minutes. It doesn't seem to do more than fill up the temporary internet files folder with random web page material.

I read your trojan warning and agree if this is what you refer to that its not harmful, just annoying. But, mungabunga was downloaded from and no other site. Actually the link on hackology to download it leads to at, so I don't know if that is affiliated with you.

Well, I just wanted to know if you were aware of it and if you are: what purpose does this program serve?



The 4th Experiment (May 2005)

Approaching the 2 year anniversary of the first tcposmod experiment and the first trojan I ever encountered, I'd like to follow up with some final (I said that last time) details. First, on subsequent download attempts, tcposmod.exe has had differing MD5 values. To clarify things, this round of experimentation will deal with the original copy:

# md5sum tcposmod.exe
2a8647ef467286fc858d9408c17603ea  tcposmod.exe

The first thing I did was load it up in PEInfo, a portable executable analyzer written by Tom Liston. I really had no idea that it was actually in PE format, but the fact that it loaded into PEInfo proved that it was. According to the Sections view, there are several sections named "BitArts," which is a packer available for quite a bit (no puns) of money from their website ( This was the first indication that it was packed with intention of staying packed - as you see later BitArts uses a patent pending algorithm to prevent reverse engineering (as opposed to UPX which is natively reversable).

The next indication was the Imports section which showed KERNEL32.DLL as being the only library called during execution of the program. For a nearly 400K program (with might I add had VERY minimal strings output), this is highly unlikely. If the majority of 400K is not Import calls, system calls to functions within those libraries, or text strings - what is it? One interesting artifact of the strings output is the alleged username of the author who packed tcposmod with BitArts: "C:\DOCUME~1\Erhan\LOCALS~1\Temp\SocketX.OCX"

Image Not Available

Next, I loaded tcposmod into Stud_PE which is another portable executable analyzer - but with a few extra features that PEInfo lacks. I used this tool to browse for packer signatures (traces left behind by the packing utility) and it verified that tcposmod.exe had been packed with the BitArts application called Cruch.

Image Not Available

From the vendor's web site:

Crunch enables developers of Windows software to compress a program by up to 70% and still run without any performance difference. Crunch adds a layer of anti-debug routines into your program, preventing novice crackers from viewing or tampering with your software.

I have to say, though this is probably only the 5th executable I've ever loaded into IDA Pro, BitArts' Cruch does a nice job. First, the disassembler complains that the Import table is not able to be loaded. Furthermore, the entire program file is completely uncomprehendable - it makes standard assembly routines look like a poem. Just for kicks I then loaded it into the OllyDbg debugger and it complained that the tcposmod.exe has an entry point outside of the code, as specified in it's PE header. This may indicate a self-extracting or self-modifying routine is present. OllyDbg warns that it's interpretation may be highly unreliable or simply wrong!

Maybe in another two years I'll continue the static analysis, but its pretty obvious I'm getting nowhere with it today. This is hardly a problem, it just means I'll have to do things a different way. In a VMWare environment, tcposmod will be executed in the presense of several monitoring tools including SysInternals' FileMon, RegMon, and TDIMon. RegShot will be used to make comparisons of the Windows Registry and file system before and after the program runs. Fundelete will be used to determine if anything is created, run, then deleted before the 2nd snapshot of the file system (such as a bat script or something). Network traffic will be re-directed via default gateway setting to a Red Hat Linux machine where Snort will be listening. This time DNS will not be excluded in case the program attempts some hostname lookups, too.

For consistency across tests, which may require several, I'll let it run for approximately 60 seconds.

I'll start with the RegShot output. There was a lot of activity with Keys and Values in the Registry, of course. Most are related to the configuration of MSINET.OCX and SOCKETX.OCX (described in prior experiments). What I'm more interested in now are the files it created:


We knew about the two OCX files and the placement of tcposmod.exe is normal (note as I mentioned before the MD5 values of tcposmod varied between earlier experiments, which is probably why notpad.exe isn't created here - there is more than one variation of tcposmod out there). I'm very curious about readme-net.doc; malware doesn't usually include help documentation. Since I'll talk about this later, I'll skip it now and move onto another logfile.

In the 60 second lifespan, tcposmod utilized TCP ports 3007 through 3019 (one at a time of course) to interact with the network. Once again, since I'll discuss the purpose of this activity later, I'll skip it now (just identifying the high level details from each log).

The RegMon output is only mildy informative in this case, because we already know which Keys and Values were added to the registry. It does prove that tcposmod.exe was the responsible process though, something RegShot can't show. FileMon turned out to be the award winner as you're about to see. Here, I can see ALL of tcposmod's interaction with the filesystem, not only what remains after it's process is terminated.

Aside from what we already know, this output shows that during tcposmod's execution, winlogin.exe called CREATE with parameters of "C:\WINDOWS\system32\" and "C:\WINDOWS\system32\dllcache\" at 7:40:33 and 7:40:38, respectively. Further investigation shows that just before that, at 7:40:28, tcposmod called DELETE for "C:\WINDOWS\System32\netstat.exe" and completed with success. That made me grep the FileMon log for any line which included "netstat" and it gave a nice summary of what happened. Here is an abridged version:

7:40:28 tcposmod.exe:1528       READ    C:\WINDOWS\System32\netstat.exe END OF FILE     Offset: 30720 Length: 65024
7:40:28 tcposmod.exe:1528     DELETE  C:\WINDOWS\System32\netstat.exe SUCCESS
7:40:33 winlogon.exe:640        OPEN    C:\WINDOWS\system32\netstat.exe NOT FOUND
7:40:33 winlogon.exe:640        OPEN    C:\WINDOWS\system32\dllcache\netstat.exe
7:40:33 winlogon.exe:640        CREATE  C:\WINDOWS\system32\     SUCCESS Options: OverwriteIf Sequential  Access: All
7:40:33 winlogon.exe:640        WRITE   C:\WINDOWS\system32\     SUCCESS Offset: 0 Length: 30720
7:40:33 winlogon.exe:640        OPEN    C:\WINDOWS\system32\netstat.exe SUCCESS Options: Open  Access: All
7:40:33 winlogon.exe:640        SET INFORMATION         C:\WINDOWS\system32\     SUCCESS FileRenameInformation
7:40:33 winlogon.exe:640        QUERY INFORMATION       C:\WINDOWS\system32\netstat.exe SUCCESS Length: 30720

Tcposmod opens the original netstat.exe, reads it to the end of file and deletes it from the file system (although the action is still fairly obvious using Fundelete, which shows netstat.exe in the trash). Then it attempts the open method again and gets a failure, which lets it know that the previous set of instructions were successful. It opens a copy of netstat.exe from the DLL cache and creates and another netstat.exe, then writes 30720 bytes of code to them. Lastly, it queries the file size and makes sure all 30720 bytes are there.

During the same time, a file named readme-net.doc was created, opened, and filled with 30720 bytes. Surely enough, it's just a backup of the new netstat:

C:\>md5sum C:\WINDOWS\System32\netstat.exe C:\WINDOWS\System32\readme-net.doc
\4e1c6742ad4f55656e75d814ea6d7383 *C:\\WINDOWS\\system32\\netstat.exe
\4e1c6742ad4f55656e75d814ea6d7383 *C:\\WINDOWS\\system32\\readme-net.doc

These executables will be examined later, but first I'll check out the final log file from our 60 second test - the network capture. From the time that it was invoked, tcposmod tried to resolve,,,, and I added these domains to the HOSTS file and pointed them at the Linux machine were I can netcat on port 80, expecting some web traffic. Web traffic is what I got, but interestingly enough tcposmod crashed instantaneously EVERY time. So, without name resolution it runs until manually terminated. With name resolution it crashes before sending netcat any data.

I took the chance to look up tcposmod.exe on Google and see if it was any more popular than it was in May of 2003. It turns out some AV vendors are detecting it now. Some of the better analysis are by Zone Labs and TrendMicro. Here is the output from VIrusTotal:

Scan results
File: tcposmod.txt
Date: 04/26/2005 04:29:41 (CET)
AntiVir       found [BDS/DSSDoor]
AVG     718/20050425    found [BackDoor.Dssdoor.A]
BitDefender     7.0/20050426    found [Backdoor.Tobuf.A]
ClamAV  devel-20050307/20050425 found nothing
DrWeb   4.32b/20050425  found [BackDoor.Tobuf]
eTrust-Iris      found [Win32/Posmod!Trojan]
eTrust-Vet       found [Win32.Posmod.B]
Fortinet        2.51/20050426   found nothing
F-Prot  3.16b/20050426  found [security risk or a "backdoor" program]
Ikarus  2.32/20050425   found nothing
Kaspersky       found [Backdoor.Win32.DSSdoor.a]
McAfee  4476/20050425   found [BackDoor-APQ.gen]
NOD32v2 1.1078/20050425 found [Win32/DSSdoor.A]
Norman  5.70.10/20050420        found nothing
Panda   8.02.00/20050425        found [Trj/Posmod]
Sybari  7.5.1314/20050426       found [Troj/Bdoor-APQ]
Symantec        8.0/20050425    found [Backdoor.Trojan]

As an anniversary present, I went back to Hackology Network where the original file was obtained, and downloaded the mbhttpbf.exe program, just to see how things had progressed in two years. It turns out the old tcposmod.exe is still packaged with the software but under the name of wintcpmod.exe. It still reports being manufactured by Microsoft, but labels itself as dss7, a new major build from dss6 - the original. The new version is much sloppier than the original - in the 60 seconds that it ran, there were over 18,000 API calls recorded by FileMon, as opposed to about 4,000 in the original. It also created 900+ new files on the system, as opposed to a mere 8 in the original.

Either we are getting better or they are getting worse. I suppose MB will still claim that his server was hacked and a script kiddie inserted this.