Can a trojan bypass netstat?

[Und3ertak3r]

There are tools like rootkitrevealer (don'task me for the URL..I am too lazy)..
or useing the good old tools like HJT and Stinger on a BART PE os disk.. in other words a "remote" scan of the HDD.. that is where it isn't your os that is checking the registry and files..
For information on the BART PE disk setup have a look at IronGeeks tutorial on the subject

[alamuru420123]

Here is the output from FPORT:

Pid Process Port Proto Path
1912 inetinfo -> 25 TCP C:\WINDOWS\system32\inetsrv\inetinfo.exe
1912 inetinfo -> 80 TCP C:\WINDOWS\system32\inetsrv\inetinfo.exe
1340 -> 135 TCP
4 System -> 139 TCP
1912 inetinfo -> 443 TCP C:\WINDOWS\system32\inetsrv\inetinfo.exe
4 System -> 445 TCP
1912 inetinfo -> 1029 TCP C:\WINDOWS\system32\inetsrv\inetinfo.exe
2592 mqsvc -> 1032 TCP C:\WINDOWS\system32\mqsvc.exe
2344 -> 1039 TCP
2592 mqsvc -> 1801 TCP C:\WINDOWS\system32\mqsvc.exe
2592 mqsvc -> 2103 TCP C:\WINDOWS\system32\mqsvc.exe
2592 mqsvc -> 2105 TCP C:\WINDOWS\system32\mqsvc.exe
2592 mqsvc -> 2107 TCP C:\WINDOWS\system32\mqsvc.exe
996 ccApp -> 2405 TCP C:\Program Files\Common Files\Symantec Shared\ccApp.exe
1284 FIREFOX -> 2974 TCP C:\PROGRA~1\MOZILL~1\FIREFOX.EXE
1284 FIREFOX -> 2975 TCP C:\PROGRA~1\MOZILL~1\FIREFOX.EXE
1284 FIREFOX -> 3031 TCP C:\PROGRA~1\MOZILL~1\FIREFOX.EXE
1284 FIREFOX -> 3032 TCP C:\PROGRA~1\MOZILL~1\FIREFOX.EXE
1284 FIREFOX -> 3033 TCP C:\PROGRA~1\MOZILL~1\FIREFOX.EXE
1284 FIREFOX -> 3034 TCP C:\PROGRA~1\MOZILL~1\FIREFOX.EXE
3024 mysqld-nt -> 3306 TCP C:\MySQL\bin\mysqld-nt.exe
1728 ypager -> 5101 TCP C:\Program Files\Yahoo!\Messenger\ypager.exe
1284 FIREFOX -> 123 UDP C:\PROGRA~1\MOZILL~1\FIREFOX.EXE
2592 mqsvc -> 123 UDP C:\WINDOWS\system32\mqsvc.exe
3024 mysqld-nt -> 137 UDP C:\MySQL\bin\mysqld-nt.exe
1728 ypager -> 138 UDP C:\Program Files\Yahoo!\Messenger\ypager.exe
1912 inetinfo -> 161 UDP C:\WINDOWS\system32\inetsrv\inetinfo.exe
1912 inetinfo -> 445 UDP C:\WINDOWS\system32\inetsrv\inetinfo.exe
1340 -> 500 UDP
1912 inetinfo -> 1025 UDP C:\WINDOWS\system32\inetsrv\inetinfo.exe
1284 FIREFOX -> 1027 UDP C:\PROGRA~1\MOZILL~1\FIREFOX.EXE
1284 FIREFOX -> 1028 UDP C:\PROGRA~1\MOZILL~1\FIREFOX.EXE
4 System -> 1031 UDP
1284 FIREFOX -> 1900 UDP C:\PROGRA~1\MOZILL~1\FIREFOX.EXE
4 System -> 1900 UDP
1912 inetinfo -> 2015 UDP C:\WINDOWS\system32\inetsrv\inetinfo.exe
2344 -> 2019 UDP
2592 mqsvc -> 2020 UDP C:\WINDOWS\system32\mqsvc.exe
2592 mqsvc -> 3456 UDP C:\WINDOWS\system32\mqsvc.exe
2592 mqsvc -> 3527 UDP C:\WINDOWS\system32\mqsvc.exe
2592 mqsvc -> 4500 UDP C:\WINDOWS\system32\mqsvc.exe

Why are there so many instances of mqsvc running on so many ports? Can this be the trojan? I googled and found that mqsvc is the message queuing service. netstat -abn shows the destination ip address of mqsvc as 0.0.0.0:0. What does this mean? rootkit revealer hasn't detected anything.
I don't know what;s wrong but, trendmicro's housecall is giving me an error. It keeps saying "page not found" the minute I click on the "start scan now" link.

[SDK]

You have ISS 5.0 running, MySQL, Message Queue Server Process running?

What type of OS are you running? What service that OS is providing to your LAN?

[alamuru420123]

I'm using winxp pro sp2. I'm not providing any service to the LAN. I've got an assignment to make a webserver and that's why i've got iss and mysql running.

[Dr Toker]

This is quite a shock to me. I thought Netstat was infallible. With all the different syntax i have always been able to find what I need or suspected.

I thought Netstat simply checked all TCP/UDP Ports and displayed the connection. How does it do this? Does it use ICMP? And beyond that, how can a program hide its connection?

[tarpi]

I always liked and used the sysinternals free tools. Like pstools, tcpview, procexp, regmon, filemon. other than that I use Spybot S+D, and AdAware SE.

tarpi

[sec_ware]

Hi

alamuru420123, your fport output looks ok to me, if you have use for
the Microsoft Message Queue Server and if you use the yahoo messenger.

Originally posted here by Dr Toker
I thought Netstat simply checked all TCP/UDP Ports and displayed the connection. How does it do this? Does it use ICMP? And beyond that, how can a program hide its connection?

I will quickly give the keywords for three ways to display connections, and then throw some
keywords that it is possible to hide it from being shown (which is hiding ), in principle.

netstat

I just shortly mention a few ways how netstat could reveal the
TCP/UDP connections:


- ntdll.dll: Use ntdeviceiocontrolfile() to check
for the "\device\tcp"/"\device\udp" resource (kernel land!)
and ntquerysysteminformation() for the process id etc.

- iphlpapi.dll: Either use AllocateAndGetTcpExTableFromStack()/
AllocateAndGetUdpExTableFromStack or GetTcpTable() (user land!)


rootkits

Now, it is possible to hide processes and their interaction from
the system, but one has to create rootkits to do so.

Either on kernel level (ring 0)[1], for example with overwriting entries in
the Service Descriptor Table to redirect addresses to own functions -
however, this might be very difficult, since the devices varies from
OS to OS, or

on user level (ring 3)[2] - which is quite complicated (one has to hook all
target API), but might allow for larger compatibility.


Currently I am looking into a "new" method using EPROCESS structure[3]
(eEye has written a White Paper about it), but I had no time to test it.


Cheers.

[1] http://www.phrack.org/phrack/62/p62-...Windows_NT.txt
[2] http://www.phrack.org/show.php?p=62&a=12
[3] http://www.google.com/search?q=+EPRO...3Aantpower.org

[Tiger Shark]

To expand on Sec-Ware's excellent post and to broaden the the thrust of what he is saying.....

There are two types of rootkit, the User and the Kernel Level. They sound similar but they are very different. One is 'relatively' easy to detect and beat, the other is near impossible unless you work in a very high security environment with very strict procedures that are actually adhered to. On the other hand the first is relatively easy to implement by the attacker while the other is very difficult and has it's inherent risks to the attacker.

The User Level Rootkit: This is the more commonly found rootkit because it's easier to install and less likely to cause problems on the target machine. It consists of replacing certain executables with subverted executables that will mask the attackers activity. Easy examples are Netstat.exe and cmd.exe.

Netstat would be subverted to show all connections except those from IP Address xxx.xxx.xxx.xxx. All the other connections will show just fine.

Cmd would be subverted so that a "dir"will show all folders except those that begin with "+" for example. Thus an attacker will add a folder to the root called "+owned". That folder and all subfolders will never show when a dir is done, (obviously, in this case explorer.exe would have to be similarly subverted). These will be further subverted, usually, to not show the additional disk space taken up by the folders so that you don't notice the sudden loss of a gig or so.

This is very easily detected once you realize that "something" is wrong and is why I carry "trusted" versions of the appropriate files with me wherever I go, either on CD or on a USB fob with all the files set as read only. It's very simple to run a netstat from the local machine and a netstat from the trusted media and compare them..... If they differ you are looking at a user level rootkit.... The solution... Reinstall....

The Kernel Level Rootkit: What could possibly be the difference between this and a User Level Rootkit? Simple really... Netstat, cmd, explorer and all those other apps get their information from the kernel. That's why, when you take a "trusted" app and run it, the results are not different and is exactly why a kernel level rootkit is so much more difficult to detect. The attacker doesn't have to change the apps themselves - they can all remain "trusted" and even my stash of "trusted" apps will do me no good. In fact _any_ app you bring in to look at the system will be lied to by the kernel whereas in a user level rootkit if I used Fport rather than netstat I would see the difference because the attacker didn't find the fport and subvert it, (or couldn't).

The problem for the attacker is that he is messing with the kernel. It's actually easier for him to do once he owns a *nix box because he can recompile the kernel with his changes in it. Windows is more problematic which is why there are less Kernel Level Rootkits for Windows.. You can't just recompile the kernel... There's a whole lot of hoops you have to go through, (and hope they all work right without screwing up the machine).

If the attacker manages to install a _stable_ rootkit on any type of machine it really, really isn't yours.... and it's bloody difficult to detect after the fact. Your only real chance is to have a regular MD5 checksum made of every system file and log any changes made to the system that you make and which files the changes affect. Only a comparison of the changes in MD5 checksums and your changes to files after the fact will give you a clue that the files have changed. By the way, do _not_ keep the checksums on the box you are trying to protect.... They should be read only on a separate media - it would be trivial for an attacker with the skill to place a Kernel Level Rootkit to alter your precious MD5 checksums to match his spiffy new ones....

The solution to a Kernel Level Rootkit... Panic, quit, run to the pub, drink beer, sleep, get over hangover, go back to work and beg for your job, reinstall every computer on the network from scratch.... Quit....

Hope that's all clearer then my morning coffee... Mud...

[alamuru420123]

Wow, that's a lot of food for thought. But to be able to do something like changing netstat.exe and cmd.exe, an attacker would need to get physical access to my computer and have to replace the files while in safe mode right. I never leave the computer alone for so long that someone comes in and just starts fooling around (Hey, it's my comp right?). After I made my last post, I reset all the applications permissions in sygate to ask me whenver they need to connect to the internet. Since then, I haven't been having any problems. Although every now and then, I get a pop-up saying 'ndsuio.sys has been contacted from an external address 10.x.x.x. Allow?' I've disabled this. But it doesn't seem to really affect anything. People can still connect to my shared folders (those who I've given read permission to) and I can connect to other computers. What is this file used for?

[Tiger Shark]

Netstat, cmd etc. are not protected system files. You can do anything you like to them..... So can an attacker.... locally or remotely....

I can't find anything sensible about ndsuio.sys.... I would consider finding it, renaming it ndsuio.sys.old and restarting and see whether your box works normally.