Please help me interpret a suspicious netstat SYN_SENT TCP port 1058 ?

The whois search indicates that this IP is for Qwest communications so I doubt that it is malicious traffic. Maybe your ISP, other internet service, or an application you have on your computer has something to do with Qwest. Your SYN_SENT means that a session is being established with their website at that IP and is part of the tcp/ip handshake to establish a connection. Such can be done to check for updates, etc or possibly spyware so you should also scan for Spyware with something like AdAware SE. Antivirus programs do not check for spyware. Another thing you could do is to install, even if just temporarily, a software firewall like Zone Alarm that would alert you when an application is trying to access the internet and show you which application. --- Steve

--- AdAware SE --- Link to Zone Alarm

mreg_.281059.29

etstat.mspx

The web server at the above IP is using host header security. I would attempt a packet capture to learn host header values to access the site. It is quite odd, though.

No worries, it's just an ephemeral port.

I am quite sure that the two are synonymous.

192.168.0.101:1058 sent a syn to 63.236.111.222:80 and awaits a syn/ack response.

ws2_32 is likely winsock2. WinHTTP is this groovy little windows component. I've written web spiders using it. I would look for a script to be utilizing this component at boot time, according to your observation.

What process had PID 912?

Yours, VB.

~~~~~~~~~~~

Didn't get enough sleep? :-)

It's just a matter of balancing the equation with enough coffee.

Actually it's a race condition. To get awake, you need some coffee, but you're too tired to get using the coffee machine.

But this is no problem since Emacs fully implements RFC 2324 (Hyper Text Coffee Pot Control Protocol). And AFAIK recently someone has build a coffee machine that supports it, too. Now that's serious concurrence for my NetBSD toaster.

Yes, indeed ;-)

Yours, VB.

*slurp*

VB.oO( HTH )

You know, I always wondered why the first webcam (to achieve much publicity anyway) was watchcing a coffee pot.

Then I got a job in a larger office full of developers and I found out.

:-)

-Russ.

[snip]

I believe that is one of the still unanswered questions in science, how to acurately specify requirements for QoS using distributed coffee solutions in large networks.

I've done some research in the area, but the results are unconclusive:

The cost of high-performance equipment tend to be significant, and with the current technology there will still be a threat of congestion at peak hours.

A plain coffee pot will have to be sized after the expected throughput, its size variations greatly affecting performance in terms of temperature and other QoS factors. There is also a problem when people empty the pot and fails to initiate the process to refill it. This is more of a social problem, and should be studied independently.

The coffee machines that deliver just one and one cup eliminates most of the QoS problems, but are more prone to congestion. Further research is needed in this area.

Anyone got links to related work or statistics?

Your system initiated a connection. See any decent textbook on TCP such as 'TCP/IP Network Administration' 3rd Edition (O'Reilly & Assoc, ISBN

0-596-00297-1, April 2004, 746 pgs, US$45) by Craig Hunt, or W. Richard Stevens classic books 'TCP/IP Illustrated Volume 1' (Addison-Wesley, ISBN 0-201-93346-9). Briefly, your computer sends a TCP packet with the SYN flag set and a randomly generated sequence number. The peer should respond with a packet with the SYN and ACK flags set, agreeing to your random number, and proposing one of it's own. Your system would then respond with a third packet with the ACK flag, agreeing to the peers random number. This is the "three-way-handshake" that starts a TCP connection. The random numbers are used to keep track of bits sent. Now, the peer may not wish to talk to you, and instead of responding with a SYN ACK packet, may respond with a ACK RST packet, which basically says "go away kid, you're bothering me" and that is the end of that.

Sorry, I don't do windoze.

Process 912 on your system (192.168.0.101) sent a packet from port 1058 which is an ephemeral port allocated to users sent a SYN packet to

63.236.111.222 hoping to connect to the web server running on port 80 of that system. Apparently, it did not respond (which could be a firewall issue as that host seems to be alive).

You may not have a browser running, but something wants to talk to a web server. As mentioned, I don't do windoze.

Yes, the idiots running the datacenter did not configure a DNS PTR record.

[compton ~]$ whois 63.236.111.222 [whois.arin.net] Qwest Communications Corporation QWEST-INET-9 (NET-63-236-0-0-1) 63.236.0.0 - 63.239.255.255 Qwest Cybercenters QWEST-CYBERCENTER (NET-63-236-0-0-2) 63.236.0.0 - 63.236.127.255 Savvis Communications Corporation QWEST-IAD-SAVVIS (NET-63-236-111-192-1) 63.236.111.192 - 63.236.111.223

# ARIN WHOIS database, last updated 2006-02-23 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. [compton ~]$

QWorst is one of the 'Baby Bells' - a regional telephone company with delusions of grandeur. The 'Cybercenters' is a data center (think of a large building with a major sized data cable, and rooms or cages leased out to providers). Savvis is a "well known" provider who seems to have no concern who they rent space, addresses, and bandwidth to. So, QWorst owns the address, this block seems to be located in a data center they own in the Washington DC metro area, and Savvis has leased a small block of addresses there. Savvis _probably_ has sub-leased bandwidth to one of their customers.

Meaningless. Your system wants to communicate, and grabs a semi-random number over 1024 (ports below 1025 "should" be reserved for server applications) and uses that to source the connection. On a general basis, port numbers are only registered/reserved on the _destination_ end of a conversation. By this - you want to connect to "some" service. There are

65536 ports on the server, and which should you connect to in order to get the service you are looking for. The answer is the registered/reserved or 'well known' port for that service.

SYN_SENT is a state - a condition. It's not a command.

None the less, _something_ on your system decided it wanted to connect to a web server.

No, I got rid of windoze before microsoft belatedly invented networking some

13 years after everyone else.

Old guy

################################################ arin.net showed Quest as the owner of that block. Search your HD and the registry for quest. Run msconfig and look at the startup. You might find something there.

I wasn't sure how to tell what is running at startup so I googled for and found a tiny program called "StartupList.exe" from Soeperman Enterprises, Ltd. which listed all the programs running at startup. None of these programs has "quest" in them though. Do you see anything strange here? Can I kill some of these initialization files? Thanks, .....Pam

StartupList report, 02/23/2006, 9:02:23 PM StartupList version: 1.52 Started from : C:\\Program Files\\os\\start/p\\startuplist\\StartupList.EXE Detected: Windows XP SP2 (WinNT 5.01.2600) Detected: Internet Explorer v7.00 (7.00.5296.0000)

• Using default options ================================================== Running processes: C:\WINDOWS\System32\smss.exe C:\WINDOWS\system32\winlogon.exe C:\WINDOWS\system32\services.exe C:\WINDOWS\system32\lsass.exe C:\WINDOWS\system32\ibmpmsvc.exe C:\WINDOWS\System32\svchost.exe C:\WINDOWS\system32\spoolsv.exe C:\WINDOWS\System32\svchost.exe C:\WINDOWS\Explorer.EXE C:\WINDOWS\system32\cmd.exe

-------------------------------------------------- Checking Windows NT UserInit:

[HKLM\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon] UserInit = C:\\WINDOWS\\system32\\userinit.exe,

-------------------------------------------------- Autorun entries from Registry: HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run avast! = c:\\Program Files\\vaccine\\malware\\avast4\\ashDisp.exe

-------------------------------------------------- Autorun entries from Registry: HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run

-------------------------------------------------- Shell & screensaver key from C:\\WINDOWS\\SYSTEM.INI:

Shell=*INI section not found* SCRNSAVE.EXE=*INI section not found* drivers=*INI section not found*

Shell & screensaver key from Registry:

Shell=Explorer.exe SCRNSAVE.EXE=*Registry value not found* drivers=*Registry value not found*

Policies Shell key:

HKCU\\..\\Policies: Shell=*Registry key not found* HKLM\\..\\Policies: Shell=*Registry value not found*

-------------------------------------------------- Enumerating Download Program Files:

-------------------------------------------------- Enumerating Windows NT logon/logoff scripts:

*No scripts set to run*

Windows NT checkdisk command: BootExecute = autocheck autochk *

Windows NT 'Wininit.ini': PendingFileRenameOperations: C:\\TEMP\\HGL1A2B.EXE

-------------------------------------------------- Enumerating ShellServiceObjectDelayLoad items:

PostBootReminder: C:\\WINDOWS\\system32\\SHELL32.dll CDBurn: C:\\WINDOWS\\system32\\SHELL32.dll WebCheck: C:\\WINDOWS\\system32\\webcheck.dll SysTray: C:\\WINDOWS\\System32\\stobject.dll

-------------------------------------------------- End of report, 4,170 bytes

--------------------------------------------------

Thanks old guy! You explained a lot!

One source of confusion you eliminated was the port used to make the outgoing SYN request. The evilware seems to change ports, as you predicted - eg it recently used port 1032. Thanks to your explanation, we can eliminate the port itself as a clue to the solution of the dilemma. I'll move on to debugging the process which seems to be svchost Generic Host Process for Win32 Services, whatever that is.

Thanks, .....Pam

I searched the Windows XP file system for "Quest" and for "Quest Communications" but came up blank. Even when I searched inside the files, I mostly came up with hundreds of "requests" and "questions" but not Quest Communications.

The registry search came up with similar results even after googling for and downloading an enhanced registry search tool called "NirSoft regscanner" from

Most of the information I found I couldn't tell if it was significant or not but none had the words "Quest Communications" unfortunately.

It was a good try though! Thanks, .....Pam

I'm not sure if you're poking fun at me or at the world at large or if this is a technical discussion that I'm not understanding.

I did find a strange file which seems to be related to a virus but maybe not from my googling.

Windows NT 'Wininit.ini': PendingFileRenameOperations: C:\\TEMP\\GLB1A2B.EXE

I'm in the process of figuring out just what GLB1A2B.EXE is really.

Thanks, .....Pam

I rebooted and ran netstat again a few times and at first did not know how to see what process was 912 until I found and installed something called NirSoft CurrProcess

which told me it was the "svchost.exe" process and that this process was owned by the "NT AUTHORITY\\SYSTEM".

I tried finding more information about that process by downloading something called Sysinternals Process Explorer by Mark Russinovich

but I could not comprehend the information in the bottom bar of the window (Thread, Semaphore, Port, Mutant, KeyedEvent, Key, WindowStation, etc).

It seems that one of my many svchost "Generic Host Process for Win32 Services" processes is the culprit which is initiating "SYN_SENT" signals on random ports to Quest Communications (63.236.111.222) at port 80. But why?

Even though I ran and reran a virus scan, malware scan, Ad-Aware scan, Spybot Search and Destroy scan, etc., do you think this unsolicited request to

63.236.111.222 at port 80 might be related to the strange C:\\TEMP\\GLB1A2B.EXE file I saw but which went away after a reboot?

Not at you.

Is there a world outside the server room? Well, must be, where else should the pizza man come from?

Most likely just a temporary file from an installer.

I did an experiment of turning off my ISP's connection and the problem only seems to occur at bootup. In this case (which maybe I didn't get right on time) I saw UDP 0.0.0.0:1032 *:* 920 C:\\WINDOWS\\system32\\mswsock.dll C:\\WINDOWS\\system32\\WS2_32.dll c:\\windows\\system32\\DNSAPI.dll C:\\WINDOWS\\system32\\mswsock.dll C:\\WINDOWS\\system32\\WS2_32.dll [svchost.exe]

Where as it always seems to be, the process 920 resolved to "svchost.exe" which I'm pretty unsure of what it does especially after googling for it as there are a handful of svchosts.exe processes always running.

Where would I find boot up scripts that might be calling this? All I know to look for is where the NirSoft startuplist program indicated there was something in [HKLM\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon] UserInit = C:\\WINDOWS\\system32\\userinit.exe

and in Windows NT 'Wininit.ini': PendingFileRenameOperations: C:\\TMP\\GLB1A2B.EXE

The contents of the Windows XP C:\\Windows\\wininit.ine file seem to be:

[Rename] NUL= NUL= NUL= .. (about twenty of these NUL lines are all the same)

At this point I don't know what to do to find out WHY my WinXP pc is initiating these SYN_SENT requests from my 192.168.0.101 to the "Quest Communications" 63.236.111.222 server on port 80 in the early minutes after a reboot if the internet connection is alive on the wireless two-pc home network. Do you?