Mystery Machine Invades Network?

Now THIS is making my morning interesting!

I came into the office today to find a note from my boss showing that a machine with the IP of 192.168.1.200, named "MUJPOLEDNIK" has joined our LAN rather mysteriously. We have no idea what or where this machine is, much less where it came from or how it joined the LAN!

So after having read a few handy AO tutorials, I finally got brave enough to bust out Nmap for some detective work for the first time. So I ran nmap -sS -O -v 192.168.1.200 and got this:

Quote:

---

Daylight Time
Host MUJPOLEDNIK (192.168.1.200) appears to be up ... good.
Initiating SYN Stealth Scan against MUJPOLEDNIK (192.168.1.200) at 10:20
Adding open port 135/tcp
Adding open port 139/tcp
Adding open port 6346/tcp
The SYN Stealth Scan took 1 second to scan 1659 ports.
For OSScan assuming that port 135 is open and port 1 is closed and neither are f
irewalled
Interesting ports on MUJPOLEDNIK (192.168.1.200):
(The 1656 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
6346/tcp open gnutella
Device type: general purpose
Running: Microsoft Windows 2003/.NET
OS details: Microsoft Windows .NET Enterprise Server (build 3604-3790)
TCP Sequence Prediction: Class=truly random
Difficulty=9999999 (Good luck!)
IPID Sequence Generation: Incremental

Nmap run completed -- 1 IP address (1 host up) scanned in 2.674 seconds

---

Something is definately VERY fishy. What do you guys think?

I'm curious if this has something to do with the 'too many ip's' issue the other day. I mentioned zombie accounts and spoofers then...

If you have managed switches it should be easy to trace the culprit.

If you have a DHCP server running.. it's probably some external contractor that plugged his/her own laptop into your network..

We do indeed have a DHCP server, and I'm about to look into that managed switch as we speak.

Interesting, it's a Windows 2003 server of some sort according to nmap. Our is a Windows 2000 network...

How large is your network? I would suggest a physical inspection of all jacks on the network depending on the size and the equipment room to make sure everything is the way it should be. Looks for rogue hubs attached to network jacks. If you switch is managed try to narrow it down that way. Try to traceroute to it also if your network has any size to it.

No need to traceroute if you have managed switches. If done correctly you will find the switch and the port this user is using. After that you just need to follow the cable.

Ok, whatever this IP belongs to, it doesn't appear to be attached to the switch, as it shows no connection between the two.

Evidently it's talking to 224.0.0.251, so I ran nmap on that, and it came back as down, so now I'm running nmap -sS -O -v -P0 224.0.0.251, and as I write this it's still scanning (does show it as being up at least now), so we'll see what happens...

So I wonder if somehow it's a wireless connection? Our wireless AP is protected by 128 bit encryption, but I presume it's within the realm of possibility.

224.0.0.251 is a multicast address.

nbtstat -a 192.168.1.200 and note the mac address.
Use the mac address to trace it on your switches.

If nbtstat doesn't work look at your dhcp leases to get the mac.

How active is your WAP? Simple solution:

Ping host - get response.
Unplug WAP from network.
Ping host

If you get a responce still its not on the WAP, if you don't its on the WAP.

Here's what nbtstat resulted in:

Node IpAddress: [192.168.1.34] Scope Id: []

NetBIOS Remote Machine Name Table

Name Type Status
---------------------------------------------
MUJPOLEDNIK <00> UNIQUE Registered
WORKGROUP <00> GROUP Registered
MUJPOLEDNIK <20> UNIQUE Registered
WORKGROUP <1E> GROUP Registered
WORKGROUP <1D> UNIQUE Registered
..__MSBROWSE__.<01> GROUP Registered

MAC Address = 00-12-F0-04-19-11

Time to start tracing then...

Looking further into 224.0.0.251 I came across this.
That machine probably has AppleTalk installed.

Found this too.

Found it!

But the answer is WIERD.

I discovered that the MAC address I found was indeed connecting wirelessly. That meant it had to be one of our machines since I have MAC filtering enabled. Sure enough, that MAC belongs to one of our company laptops, however that laptop is NOT a Windows 2003 server (it's XP Pro) and is NOT named "MUJPOLEDNIK".

So I'm going to find out who has that laptop right now and take a look at it...

Your WIFI is on the same subnet as your wired hosts? You should have them on different subnets separated by a firewall... just in case something like this were to happen. then its easier to track down and lock out hosts on that subnet... 128bit encryption using WEP? The firewall between the subnets should limit the wireless hosts access to your wired lan.

like sirdice said... nbtstat -a 192.168.1.200 and get the mac. then you can match it up.

Since netbios is running, you can possibly get other useful info... such as user account logged in, which workgroup/domain it belongs to, etc. you can use nessus or languard or nbtstat or nbtscan, etc. there are a lot of tools out there that will give you that info.

From your nbtstat you can determine the following

Workstation Service
Belongs to the "Workgroup" domian/workgroup
Has file/print share service turned on
Participates in browser service elections
It is the master browser for that domain/workgroup

BTW: If you are using WEP... its not very difficult to break. And MAC filtering? Does no good... a simple MAC spoofing program can get around that. You need to be using WPA along with some type of authentication server (VPN or Radius)

And it just gets stranger...

That laptop that the MAC belongs to is turned off, sitting safely in a cabinet right now.

Could this mean someone's cracked our WEP and spoofed the MAC as phis mentioned then?

Looks like it, expect a letter from the Riaa. Lol
Your scan does show port 6346/tcp gnuttela as open.

Quote:

---

Your scan does show port 6346/tcp gnuttela as open.

---

So I don't know much about that. What's the purpose of that particular port?

Quote:

---

Your scan does show port 6346/tcp gnuttela as open.

---

file sharing on the gnutella p2p network
http://www.gnutella.com/

Quote:

---

Could this mean someone's cracked our WEP and spoofed the MAC as phis mentioned then?

---

Sure. Wep is easy to crack. It can be done in minutes. Valid MACs can be found in seconds... they are not encrypted...

Remove that MAC from your filters and see if they try to reconnect using a different MAC.

http://isc.sans.org/port_details.php?port=6346

AngelicK,

You have a physical or logical map of your network, no?
Let's say you do, that means all managed switches and servers will show on the map as static IPs, the rest of the network, maybe excluding printers, are DHCP.

With that information in hand, simply "tracert" the IP. (I'd suggest a GUI program that does the same thing but tracert is free).

Then go to the next "static" IP reported in the tracert output and "tracert" again.
If it gets too confusing, tracert from another couple locations on your network as a type of "triangulation".

If all tracert's go thru the WAP, then exclude that MAC and see who complains.
OR:
In the mean time, you can use another laptop booted up with Knoppix STD CD (free download) to use Kismet to physically track the offender.

Using Network Stumbler (runs under windows for free) to walk the general area looking for offending device will only give you active APs (with their MAC ID), sometimes you get the peer-to-peer connections, othertimes not.

I'd also contact whomever had been using the laptop.
It could be a former employee/technician who grabbed the data prior to leaving.

So, mystery solved! Turns out it's a laptop that belongs to one of our employees. He changed the name of his machine to that weird name above, thus throwing me off all morning long. All it took was kicking that MAC off the AP for me to get the "I lost my connection!" phone call. :D

Quote:

---

Originally posted here by AngelicKnight
So, mystery solved! Turns out it's a laptop that belongs to one of our employees. He changed the name of his machine to that weird name above, thus throwing me off all morning long. All it took was kicking that MAC off the AP for me to get the "I lost my connection!" phone call. :D

---

So the question that remains is why does he have "gnutella p2p networking" loaded on his laptop? Do you allow P2P apps. on your company systems?

Cheers:

Busted...

Quote:

---

Originally posted here by AngelicKnight
That laptop that the MAC belongs to is turned off, sitting safely in a cabinet right now.

---

Thats the part that confuses me. Was that laptop indeed off at the time your were querying it?

Doesn't need P2P. P2P should go away methinks. :D

Quote:

---

Thats the part that confuses me. Was that laptop indeed off at the time your were querying it?

---

Sorry 'bout that, look back a few posts up where I was talking about the new firmware jumbling up the correlation of MAC addresses and system names...that's the culprit for that. I'm now going back in and fixing it all.

Hmmm, I user who changes his PC name, and has open p2p ports. He/She would now be on my official "****" list.

He kinda has a habit on staying on everyone's list actually...

Can anyone add machines to your network???

Change the name??

Usually that is restricted...even in w2k??

MLF

I think he did more than change the name, if he was able to connect to your network and bypass your domain log in.

So... now that you've had this problem... its time to look into ways to prevent this from happening again.

REMOVE local admin rights from the users. Doesn't look like you have a domain... or they unjoined/formatted/reloaded their box. If you are on a domain... start using group policies. Restrict people from installing software, etc.

Firewalls: You must be allowing outbound traffic for that p2p app... you need to lock down your gateway's outgoing ports. Arrainge your hosts in groups of IP addresses and filter outgoing based on those groups. group1 only needs outbound 53, 80 and 443. group 2 needs 20,21,22,25,53,80 and 443. Etc.

You should have your wifi and wired clients on different subnets with a firewall between. This doesn't have to be expensive... an old PII or PIII with IPCOP loaded would fit nicely. And it'd provide you a lot more security (iptables, transparent proxy with filtering (dansguardian), etc.) and services than your standard AP. Only allow access from the wifi boxes to what they NEED. You can do this on an IP basis if you want to. If they only need access to the gateway and server x... restrict them from everything else.

WIFI: You don't HAVE to use VPN or a Radius server for authenticaion... but it is recommened for a corp network. Ditch WEP and implement WPA (with our without Radius).

I'm sure I'm leaving out a lot... but I'm in a hurry. Time to take my last final!

I configured his laptop to access the network. In fact, he purchased that laptop for use at home and here, letting us totally get rid of the desktop that was in that office. However, that certainly wasn't the name I gave the system, so that's what he changed.

jinxy

That was my point.

Obviously the guy has rights that maybe he shouldnt have??

You cant just change a machine name without adding it into the domain...somehow

MLF
edit>

sorry..looks like we were all posting at the same time.

I would definately heed advise given by phishphreek80

Quote:

---

he purchased that laptop for use at home and here

---

I'm assuming he bought it with his own money. This may be a messy situation as telling users what they can and can't do with computers that they bought is never fun, "Oh by the way you can't have admin rights on your laptop anymore".

In theory it's straight forward, "If you want to work here do as we say" but we all know how that's going to go over. Although you said he's on everyone's **** list so maybe it will make him quit.

Good luck

Quote:

---

I'm assuming he bought it with his own money. This may be a messy situation as telling users what they can and can't do with computers that they bought is never fun, "Oh by the way you can't have admin rights on your laptop anymore".

---

That's exactly the issue. However, laptops that use wireless are not allowed to join the domain. They pick up the wireless connection for Internet usage, but have no access to local network resources.

I've been thinking about breaking out network into subnets for a while now, and I just used this experience as a prime example to make the case for it to my boss. We also have a web server that I think should be sitting on a DMZ instead of right here on the main network with everything else.

this guy has a laptop running p2p. even if he doesn't p2p at work (which im hoping for your sake) he does at home them comes in and just connects!! does he know enough to keep your job?

when you find some kids from SE asia using your network for a playground or your email server winds up on a black-hole list and your network goes down with a virus your the one that's going to take the heat. he should be coming to you for approval evertime he wants to connect or just put the desktop back.

Quote:

---

I've been thinking about breaking out network into subnets for a while now, and I just used this experience as a prime example to make the case for it to my boss. We also have a web server that I think should be sitting on a DMZ instead of right here on the main network with everything else.

---

:eek:

Tell your boss from me:-

Everything that cannot be implicitly trusted must not be allowed on the trusted network... period. This includes services that are available to the public such as HTTP, SMTP, FTP etc. and laptops that are unable to restrict the user from altering the security settings set via policy by the IT department, (or the local geek in your case...). Entities such as that should be DMZed or placed outside the firewall and any access to the trusted network from them should be on a different service or, at a minimum, a different type of the service that requires an attacker to have two simultaneously unpatched exploits for different systems. Uncontrolled laptops should attach to the WAP and have to VPN into the trusted network under restricted conditions. The only exception I can think of for this is Outlook Web Access over SSL.... I still can't find a sensible solution for this that doesn't allow several critical ports to be opened from the DMZ to the trusted as opposed to the single port allowed directly through... What can I say? I'm an idiot.... :D