Can a Trojan horse hide its activity from TCPView?

I've done a little research before asking, but I still can't find the answer for this.

I know that a Trojan horse can hide from the Windows Task Manager through various methods. Also, less frequently, it can hide its activity from the netstat command (mostly replacing the program with their own version). I guess is less frequently because (I expect) any non-compromised antivirus protect and alert for changes in system files (not sure if I'm being naive). Even though, If the Trojan uses a Windows process (not it's own name) to connect to the Internet, many times you can identify what isn't an expected connection to some random IP address.

Many websites recommend using TCPView to check for unusual connections, and I wonder if a Trojan can hide its activity from TCPView. I'm not sure if TCPView is just a graphic interface using the netstat program. In that case, if there's any method to hide from netstat, it will be hidden from TCPView of course.

I don't think that a Trojan horse would be specifically coded to hide from TCPView (or it is TCPView so popular that this happens?), but maybe there's a method to hide its activity from any program trying to check the current Internet connections (even Wireshark) and to hide what programs or Windows processes (even svchost or system) are establishing those connections as well.

If you know specific methods used to hide from TCPView could you mention them?

I want to know this, because I'm not sure that using TCPView or Wireshark to check for unusual connections is a bulletproof test to confirm that activity.

  • A simple way to hide from tcp viewers is to use UDP (or even raw packets, if you are an admin). But that wouldn't hide you from Wireshark. If the Trojan is a kernel mode rootkit (or even worse, compromised the BIOS or the firmware of certain hardware pieces), all bets are off. – CodesInChaos Oct 19 '15 at 6:55
  • @BlueBerry-Vignesh4303 thanks but it doesn't help that much as it doesn't provide any information about the likelyhood (or not likelyhood) for a RAT of hide its activity from TCPview or wireshark. Its the same as other pages that I've read that take for granted that there will be no false-negatives using such utilities. same as other pages take for granted the same about netstat. and regarding netstat,that's not always the case, and some rootkits actually target and change netstat. But I still don't know that about TCPview or wireshark – JohnSt Oct 19 '15 at 6:56
  • @CodesInChaos,Ok. and In the case of a trojan that is not a kernel mode rootkit: It would be fair to assume that there isn't a known method to hide the internet connections that this trojan makes from wireshark?. I mean there's no chances to have "false-negatives"? – JohnSt Oct 19 '15 at 7:06
  • If Wireshark is running on the same user or the trojan has admin privileges, the trojan could act as usermode rootkit. – CodesInChaos Oct 19 '15 at 7:07

I don't think that a trojan horse will be specifically codded to hide from TCPview (or it is TCPview so popular that this happens?) but maybe there's a method to hide it's activity form any program trying to check the current internet connections (even wireshark) and what programs or windows processes (even svhost or system) are establishing those connections.

If you know specific methods used to hide from TCPview could you mention them?

A kernel-level rootkit can hide itself from any user-level program on the system, which includes TCPview. That's because all user-level programs make requests of the kernel in order to get information, such as access to network connection tables, interfaces, and packets. The attacker "hooks" the kernel interfaces so as to intercept these requests, and so user-level programs may say "show me all the packets" and receive everything except the rootkit packets.

There's a good paper here called Countering Persistent Kernel Rootkits Through Systematic Hook Discovery which describes the method by which rootkits do this pretty concisely. To quote:

...a rootkit by nature is programmed to hide itself especially from various
security programs including those widely-used system utility programs such
as ps, ls, and netstat. As such for an infected OS kernel, the provided
kernel service (e.g., handling a particular system call) to any request
from these security software is likely manipulated. The manipulation
typically comes from the installation of kernel hooks at strategic
locations somewhere within the corresponding kernel-side execution path
of these security software.

The reason I want to know this is I'm not sure that using TCPview or Wireshark to check for unusual connections is a bulletproof test to confirm that activity

If you think a system may be compromised, you can't trust a thing it tells you. So external methods of checking, such as wireshark on a different machine (capturing via hub, span port, what-have-you) are necessary to get an objective view of network traffic.

The combination of external and information can also be very, very useful. If you see lots of packets from remote:3456 to suspect:8080, but your suspect machine says it's not listening to 8080, that's a good sign you've got a kernel rootkit hiding its use of the network.

| improve this answer | |
  • 1
    You are right: rootkits can even alter some kernel functions. – user45139 Oct 19 '15 at 12:23
  • 1
    @Begueradj I would say it isn't possible to develop a rootkit without altering kernel functions! – Josef says Reinstate Monica Oct 19 '15 at 14:24
  • @Josef: BIOS, SMM - there are a few more options. With smart TCP offloading engines, a rootkit could even hide in the network card. Heck, if reports are to believed, even the switches themselves can be compromised. – MSalters Oct 19 '15 at 20:53
  • 2
    The earliest "rootkits" were designed simply to "hide from root", and did so by replacing user-space tools - a version of ls that would ignore certain files, a version of ps that would ignore certain processes. So it is possible to have a rootkit without kernel manipulation... but it's increasingly rare because meddling with the kernel is so much more capable. – gowenfawr Oct 19 '15 at 20:57

I'm sure others will be able to specify exactly how this could be done, but I'd like to point out that you should always assume that it can and has been done. Sure it might not be likely for most trojan infections, but due diligence demands that you act as though you can't trust anything a compromised machine is telling you.

In practice this means that you'd pop a network hub somewhere upstream of the machine, and monitor the traffic using that to see what your suspect machine up to, and why generally, nuking it from orbit is the only way to be sure.

I guess it depends on the situation. If you have a suspect machine on the network of an embassy say, you'd probably want to put your super paranoid hat on and use a hub/switch mirror port to monitor traffic whilst minimising the chances of tipping off your adverseries. For a small business or personal computers; sure have a look with tcpview and wireshark on the machine initially to see if anything jumps out at you. Even then though if you've still got doubts, personally I'd want to see the traffic from the wire so to speak to see what's going on.


As KonradGajewski points out in the comments below, you could use any number of different methods to intercept the traffic from the machine depending on the specifics of your network layout. This might be as simple as putting a hub or a laptop in-between the machine and the rest of the network, or by using a switch mirror port, monitoring wireless traffic, and so on.

| improve this answer | |
  • 1
    Instead of a hub one might consider using a Linux machine with two Ethernet cards and bridging (two lines of commands). – Konrad Gajewski Oct 19 '15 at 9:25
  • 1
    @KonradGajewski absolutely, whatever allows you to look at the traffic. I mentioned hubs as the simplest way I could think of. I've updated the answer :) – GreatSeaSpider Oct 19 '15 at 9:37
  • 1
    I commented because it is probably easier nowadays to summon up a laptop and an additional NIC than a working hub. :) On a decent switch (Cisco) it is possible to duplicate the whole traffic on one port to another - this is yet another option. – Konrad Gajewski Oct 20 '15 at 12:31

It's absolutely possible that someone is developing malware which is capable of hiding packets from sniffers. As most sniffers on Windows systems depend on WinPCAP as a capture driver, it would for example be possible to manipulate the drivers to hide specific packets that are traveling the wire.

This is why I use my laptop as a bridge to capture packets when it comes to potentially compromised systems. You can easily do this using the bridge-utils package on most linux systems.

| improve this answer | |

Anything can be manipulated in Windows with skilled reverse engineering. An generic RAT hiding TCP from Wireshark is extremely unlikely, but it's possible. Don't just rely on your antivirus software (AV) as they are very unreliable and don't have very good heuristic techniques in my opinion.

You could write yourself some malicious program and upload it to https://www.virustotal.com/, and I bet you most AVs wouldn't detect what you've written. File system changes are not logged by all AVs, and it would be a time-consuming initial task as it would have to hash known system files.

If you want bulletproof checks for networking you'll want to log the traffic on the router, but make sure your router isn't compromised before you do the network logging.

| improve this answer | |

Basic Trojans can sometimes be found by monitoring the network traffic or just looking at open ports.

Advanced Trojans may hide their traffic inside other traffic, may use steganography techniques or just send their data very rarerly or only at or during specific events - so they could be much harder to detect by a network monitor. It depends how much targeted Trojans you would expect, i.e. if you are private user or at a security-relevant company or at an embassy, etc.

As in the other answers written, monitoring on a possibly infected host may give incorrect results. The Trojan also could deactivate itself for the time the user uses a network monitoring tool on the same host to prevent detection of itself.

| improve this answer | |

Your Answer

