Idle or NOT?!

Posted on 2006-11-10
Last Modified: 2012-05-05
Bottom line I've been analyzing a hack that appears to be related to WMF/CHM exploits.  While doing so I happened to catch a number of active TCP connections attached to PID 0 (System Idle Process).

I thought "System Idle Process" was, essentially, a placeholder for reflecting 'unused' CPU cycles.  Can someone explain why it would reflect active TCP connections via 'process explorer'?

I don't want to waste time analysing the hack so, if the TCP connections related to PID 0 are 'normal', it would help to know that.

XP PRO SP2 (current).  NIS 2006 (current).  Trojan-hunter (current).  At the time was running TCPVIEW and PROCESS EXPLORER and this was shortly after boot.

Question by:jrs_50
LVL 86

Expert Comment

ID: 17917458
Technically, the 'System Idle Process' is a process, Windows' process table has an EPROCESS entry for it which is referenced vial the 'PsIdleProcess' kernel variable. It has to be one, since the scheduler needs to be a ble to switch to it, even though the only thing that this process executes is the 'HLT' instruction. See also ("Microsoft Windows Internals, Fourth Edition"), chapter "Process Internals"

Author Comment

ID: 17917567
Thanks.  BUT I already knew it was a 'process'.  What I am TRYING to understand is why it would reflect active TCP connections.  You are correct, in a sense, that AS a process it CAN do things.  On the other hand, it doesn't seem reasonable to me that it would do much other than act as an IDLE placeholder.
LVL 86

Expert Comment

ID: 17917698
Since it is a process, there is the chance to inject any kind of code into its address space (yet that is not trivial in this case). Another possibility would be that a rootkit manipulates the information you see and the connections in fact belong to a different process.
Enterprise Mobility and BYOD For Dummies

Like “For Dummies” books, you can read this in whatever order you choose and learn about mobility and BYOD; and how to put a competitive mobile infrastructure in place. Developed for SMBs and large enterprises alike, you will find helpful use cases, planning, and implementation.


Author Comment

ID: 17917840
As I mentioned; I AM dealing with an active hacking scenario.  Not detected by any of the major/minor virus/spyware/trojan/rootkit scanners (including spyware doctor which SAYS it can detect CHM related malware - and I'm fairly convinced at this point that a CHM exploit is, at least, part of the problem).

Are you agreeing with me that, in effect and without regard to the how/why, the active TCP connections reflected as being attached to PID 0 are, in fact, NOT 'normal'?

I'm wondering if it could, somehow, be related to Norton/Symantec liveupdate but so far as I can determine LU was completed at the point I noted the problem and I did not note the problem while LU was running which was about a minute prior.
LVL 86

Assisted Solution

jkr earned 200 total points
ID: 17917904
>>As I mentioned; I AM dealing with an active hacking scenario.

That was clear ;o)

>>Are you agreeing with me that, in effect and without regard to the how/why, the active TCP connections
>>reflected as being attached to PID 0 are, in fact, NOT 'normal'?

I'd even say that this is quite unusual and quite amazing. I'd however check for rootkit activity to be sure that PID 0 was responsible for that behaviour.

Author Comment

ID: 17918144

Interestingly; returning to my desktop after closing out of IE I ran process explorer again to check properties on PID 0.  A few seconds later PID 0 reflected TCP connections (EE amongst them).  I'm wondering, now, whether or not this might, somehow, be tied to the final closing of the ports.  Although, I can't quite picture any 'normal logic' to that scenario.  I would think that would be handled by svchost or something OTHER than PID 0.  Or; as suspected SOMETHING (rootkit or otherwise) is 'distorting' the information/process.

I'm going to leave this question open for a bit to see if anyone else checks in with thoughts on it.  But, it is helpful to know I'm not the only one who finds the situation 'unusual and amazing'.  Thanks for the input.  I may not check back this evening.  I've got to disconnect from the net to pursue some other analysis.  I will, however, check back soon.  
LVL 15

Accepted Solution

venom96737 earned 300 total points
ID: 17921209

In some rare circumstance, Windows XP doesn't clean up all its sockets correctly after an application has closed. This has the effect of Port Explorer or process explorer showing a socket with an asterix and no filename because the application is closed yet Windows XP is reporting that the closed application owns the socket(s). Usually after your internet connection has been disconnected the 'blank' socket(s) will be cleaned up by Windows XP. it's a Windows XP issue. To check this, whenever you see a blank socket go to your command prompt and type "netstat -ano" (without quotes). You should see the sockets which have the same PID as the blank sockets in Port Explorer. If you look in Windows Task Manager (Ctrl+Alt+Delete | Task Manager) you will see no process that has the PID that netstat and Port Explorer process explorer report.

In other words xp has a problem cleaning up its sockets and it will show that a blank or PID 0 is using it when in all actuality it is not.

Author Comment

ID: 17921868
I didn't think of the 'n' and had this available from an 'ao' from this AM.  I modified a bit for security purposes but the following is essentially complete.  Am I understanding you correctly that this is, if not normal, at least reasonable.  I don't have the corresponding image from process explorer but, basically, process explorer would reflect the '0' connections on the System Idle Process properties view with the same LA/FA info.

Active Connections

  Proto  Local Address          Foreign Address        State           PID
  TCP    cot:epmap     cot:0         LISTENING       876
  TCP    cot:microsoft-ds  cottage-lt-1:0         LISTENING       4
  TCP    cot:1025      cot:0         LISTENING       1608
  TCP    cot:1025      localhost:1039         TIME_WAIT       0
  TCP    cot:1025      localhost:1041         TIME_WAIT       0
  TCP    cot:1025      localhost:1043         TIME_WAIT       0
  TCP    cot:1025      localhost:1049         TIME_WAIT       0
  TCP    cot:1025      localhost:1053         TIME_WAIT       0
  TCP    cot:1025      localhost:1055         TIME_WAIT       0
  TCP    cot:1025      localhost:1057         TIME_WAIT       0
  TCP    cot:1025      localhost:1059         TIME_WAIT       0
  TCP    cot:1025      localhost:1067         TIME_WAIT       0
  TCP    cot:1025      localhost:1071         TIME_WAIT       0
  TCP    cot:1025      localhost:1079         TIME_WAIT       0
  TCP    cot:1025      localhost:1081         TIME_WAIT       0
  TCP    cot:1025      localhost:1083         TIME_WAIT       0
  TCP    cot:1027      cot:0         LISTENING       2012
  TCP    cot:1028      cot:0         LISTENING       2440
  TCP    cot:netbios-ssn  cot:0         LISTENING       4
  TCP    cot:1038  TIME_WAIT       0
  UDP    cot:microsoft-ds  *:*                                    4
  UDP    cot:isakmp    *:*                                    632
  UDP    cot:1029      *:*                                    1036
  UDP    cot:4500      *:*                                    632
  UDP    cot:ntp       *:*                                    960
  UDP    cot:ntp       *:*                                    960
  UDP    cot:netbios-ns  *:*                                    4
  UDP    cot:netbios-dgm  *:*                                    4

Incidentally, until yesterday (after taking some steps to alter the hack/malware/spyware/whatever activity) netstat was not reporting connections, NIS was only reporting some (still true), and I was using process explorer because it, at least seemed reasonable if I picked the right process.  Finding the connections on System Idle was actually accidental.  With everything else I've been dealing with you might understand that, not expecting to see connections on System Idle I NEED some clarification.  It still seems 'odd' to me that the sockets are fairly consistently 'not cleaned up correctly' but I can understand PE attaching the info to the 'relevant' PID even though it isn't 'relevant'.  

As long as the infor has been posted anyway does anyone see anything else 'odd' besides the PID 0?

Thanks for the feedback.

Author Comment

ID: 17981173
Sorry for the delay.  Was reinstalling.  Got re-hacked. :=(

Thanks for the feedback.

Expert Comment

ID: 20686832
This is a normal report for the TIME_WAIT state: "The TIME_WAIT state is a state that all the TCP connections enter into when the connection has been closed.". It's stopped being displayed against its original process, which might well have exited, and shows against PID 0.

Featured Post

Live: Real-Time Solutions, Start Here

Receive instant 1:1 support from technology experts, using our real-time conversation and whiteboard interface. Your first 5 minutes are always free.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
2 windows xp desktops computer 8 149
windows seems to be corrupt 10 76
Exe program is not a valid Win 32 application 15 108
Best practices power settings GPO Win 10 4 95
Are you unable to synchronize your OST (Offline Storage Table) file with Microsoft Exchange Server? Is your OST file exceeding 2 GB size limit? In Microsoft Outlook 2002 and earlier versions, there is a 2 GB size limit for the OST file. If the file …
Can you find a fax from a vendor you saved a decade ago in seconds? Have you ever cursed your PC under your breath during an audit because you couldn’t find the requested statement or driver history?  If you answered no to the first question or yes …
Microsoft Active Directory, the widely used IT infrastructure, is known for its high risk of credential theft. The best way to test your Active Directory’s vulnerabilities to pass-the-ticket, pass-the-hash, privilege escalation, and malware attacks …
Two types of users will appreciate AOMEI Backupper Pro: 1 - Those with PCIe drives (and haven't found cloning software that works on them). 2 - Those who want a fast clone of their boot drive (no re-boots needed) and it can clone your drive wh…

785 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question