Hacking? Spyware?

[FawrIze]

Hi All,

I just picked up something disturbing on my link. If I close all my internet apps, there's still some traffic going as picked up by Ethereal, and in particular something that looks like RPC calls. I've checked for Spyware etc. but nothing. Also look at the traceroute at the bottom of this post. There seems to be a routing loop somewhere in the WBS network - I don't understand why its using 196.30.31.100 as a default gateway. My IP at the time was 196.46.67.59 "attacking" other IPs on the WBS subnet. I also saw SYNs from hosts all over the show when I closed down Skype, MSN messenger, TCPIQ's bandwidth tester and NetMeter - so I don't know which of these (if any) could be the culprit. The offending process is svchost, but with no username. Any ideas?

No. Time Source Destination Protocol Info
1 0.000000 196.46.66.15 196.46.67.59 TCP 3090 > epmap [SYN] Seq=0 Ack=0 Win=17136 Len=0 MSS=1360
2 0.009224 196.46.67.59 196.46.66.15 TCP epmap > 3090 [SYN, ACK] Seq=0 Ack=1 Win=17136 Len=0 MSS=1360
3 0.460082 196.46.66.15 196.46.67.59 TCP 3090 > epmap [ACK] Seq=1 Ack=1 Win=17136 Len=0
4 0.460998 196.46.66.15 196.46.67.59 TCP 3090 > epmap [FIN, ACK] Seq=1 Ack=1 Win=17136 Len=0
5 0.461864 196.46.66.15 196.46.67.59 TCP 3150 > epmap [SYN] Seq=0 Ack=0 Win=17136 Len=0 MSS=1360
6 0.469779 196.46.67.59 196.46.66.15 TCP epmap > 3090 [ACK] Seq=1 Ack=2 Win=17136 Len=0
7 0.471949 196.46.67.59 196.46.66.15 TCP epmap > 3150 [SYN, ACK] Seq=0 Ack=1 Win=17136 Len=0 MSS=1360
8 0.473848 196.46.67.59 196.46.66.15 TCP epmap > 3090 [FIN, ACK] Seq=1 Ack=2 Win=17136 Len=0
9 0.737858 196.46.66.15 196.46.67.59 TCP 3150 > epmap [ACK] Seq=1 Ack=1 Win=17136 Len=0
10 0.738792 196.46.66.15 196.46.67.59 DCERPC Bind: call_id: 1 UUID: MGMT
11 0.739786 196.46.66.15 196.46.67.59 TCP 3090 > epmap [ACK] Seq=2 Ack=2 Win=17136 Len=0
12 0.741583 196.46.67.59 196.46.66.15 DCERPC Bind_ack: call_id: 1 accept max_xmit: 5840 max_recv: 5840
13 1.260800 196.46.66.15 196.46.67.59 MGMT rpc__mgmt_inq_if_ids request
14 1.273814 196.46.67.59 196.46.66.15 MGMT rpc__mgmt_inq_if_ids response
15 1.490792 196.46.66.15 196.46.67.59 TCP 3150 > epmap [FIN, ACK] Seq=97 Ack=365 Win=16772 Len=0
16 1.491462 196.46.67.59 196.46.66.15 TCP epmap > 3150 [ACK] Seq=365 Ack=98 Win=17040 Len=0
17 1.492301 196.46.66.15 196.46.67.59 TCP 3222 > epmap [SYN] Seq=0 Ack=0 Win=17136 Len=0 MSS=1360
18 1.492689 196.46.67.59 196.46.66.15 TCP epmap > 3150 [FIN, ACK] Seq=365 Ack=98 Win=17040 Len=0
19 1.501199 196.46.67.59 196.46.66.15 TCP epmap > 3222 [SYN, ACK] Seq=0 Ack=1 Win=17136 Len=0 MSS=1360
20 1.643664 196.46.66.15 196.46.67.59 TCP 3150 > epmap [ACK] Seq=98 Ack=366 Win=16772 Len=0
21 1.644654 196.46.66.15 196.46.67.59 TCP 3222 > epmap [ACK] Seq=1 Ack=1 Win=17136 Len=0
22 1.645662 196.46.66.15 196.46.67.59 DCERPC Bind: call_id: 127 UUID: ISystemActivator
23 1.652092 196.46.67.59 196.46.66.15 DCERPC Bind_ack: call_id: 127 accept max_xmit: 5840 max_recv: 5840
24 1.961709 196.46.66.15 196.46.67.59 ISystemActivator RemoteCreateInstance request
25 1.973714 196.46.66.15 196.46.67.59 TCP 3222 > epmap [PSH, ACK] Seq=1433 Ack=61 Win=17076 Len=104
26 1.981903 196.46.67.59 196.46.66.15 TCP epmap > 3222 [ACK] Seq=61 Ack=1537 Win=17136 Len=0
27 1.985676 196.46.67.59 196.46.66.15 ISystemActivator RemoteCreateInstance response
28 2.143601 196.46.66.15 196.46.67.59 TCP 3222 > epmap [FIN, ACK] Seq=1537 Ack=101 Win=17036 Len=0
29 2.152154 196.46.67.59 196.46.66.15 TCP epmap > 3222 [ACK] Seq=101 Ack=1538 Win=17136 Len=0
30 2.153575 196.46.67.59 196.46.66.15 TCP epmap > 3222 [FIN, ACK] Seq=101 Ack=1538 Win=17136 Len=0
31 2.399590 196.46.66.15 196.46.67.59 TCP 3222 > epmap [ACK] Seq=1538 Ack=102 Win=17036 Len=0



Tracing route to 196.46.66.15 over a maximum of 30 hops



1 138 ms 169 ms 69 ms 196.30.31.100

2 99 ms 190 ms 109 ms 196.30.31.193

3 70 ms 109 ms 109 ms 196.30.31.100

4 *

[kuberkoos]

196.30.31.100 looks fine as a default gw. all iburst users are _not_ on a subnet. thank dog... :D

over PPP the remote end _must_ be you default GW and, as PPP is point-to-point, the endpoints need not be related, i.e. on a conventional subnet like you'd find on an ethernet.

chz,
kk

[kuberkoos]

as to the traffic...

i'm not familiar with MS networking. was you machine _ever_ connected to the 'NET unprotected? it so, you can't trust it anymore. have look at http://isc.sans.org/presentations/xpsurvivalguide.pdf for instructions to connect a MSWin machine directly onto the net with _reasonable_ confidence.

it boils down to disabling MS File&Print Sharing, disabling Client for MSNetworking and NetBIOS over TCP/IP as well as enabling Windows IP Filtering. The packet trace looks like it involves MSNetworking (DCE?)

chz,
kk

[AcidRaZor]

as to the traffic...

was you machine _ever_ connected to the 'NET unprotected? it so, you can't trust it anymore.

Funny, when I went for an AIDS test, that was what the lady asked me as well....

[stoke]

Looks to me like windows is trying to examine the network on the internet side.

Remove MS Client and all other crap from that (Dial-Up/Internet) connection, leave only TCPIP and possibly Quality of Service (QOS).

[AcidRaZor]

format c: /q /s

[FawrIze]

All good suggestions which I'll implement - thanks.

There's some other funny business going on - If I kill some of the svchost processes, I get SYNs from hosts I've never seen before, and for which there are no connections shown in netstat. Anyway I don't want to make my problem yours, but I'm concerned what an "outbreak" like this does to a wireless link in particular, so one way to ensure a good quality service is to eliminate the junk on the waves - which I think should be a joint WBS/client responsibility.

[stoke]

Sounds bizzare - you kill a process, and you get SYN's from other ip addrs.
That can only mean that these other addrs have known about you and are responding to a - hey, i'm terminating something broadcast from windows.
It makes sense for MS to use a broadcast to send information like that (In a sick kind of way.)
Methinks that it's the MS's (Domain/Active Directory) stuff that's broadcasting like that, and the responses that you are getting is from other PC's in a close (4 hops) range that are also configured incorrectly. You could probably do a net view on the machines that responded.
The usual solution for this kind of rubbish is to run a firewall.

[Obelix]

this is now the third place i've seent his in the same day. The guys in europe mentioned massive netbios connection attempts, i've seem it hammer our company's firewall, and ive seen it on my own machine.

I think a new windows worm/virus has just hit paydirt time.

check your updates

[bb_matt]

Hmm, interesting, I've been getting DNS errors on web addresses all morning - wonder if it's related ?

[AcidRaZor]

nope, im hacking him so that I can get all the lame people off my bandwidth...

[fergus]

FawrIze are you running mysql on windows by any chance? there's reportedly a new worm that exploits it.

http://it.slashdot.org/article.pl?sid=05/01/27/1546222&tid=220&tid=172&tid=95

[FawrIze]

Rather lame than ignorant... noone can argue with that.

Anyway, I'm not running netbios on that adapter at all, so whatever it was (is?) was generating its own packets. It looks like it is trawling the net for specific types of AD well known services by querying DNS - and perhaps hitting those? What freaks me out is that some of the SYN's came from hosts in the bk domain - certainly more than 4 hops away! Smells like a P2P broadcast jobbie. I'm not running mySQL - all patched up (BITS updated posted yesterday), so I'll see how it goes.

[FawrIze]

This could be the one:

http://archives.neohapsis.com/archives/vulnwatch/2005-q1/0036.html

[AcidRaZor]

question is, how'd it get ON your system

#1 firewall isn't just a wall on fire...
#2 antivirus isn't just during winter time....
#3 anything with a microsoft logo on it, patch it...set your "check for automatic updates" to every 2 seconds... JUST IN CASE