Setting up promiscuous mode

Hi folks-
I am just starting my quest to figure out this network security stuff and am afraid one of my users is sniffing passwords on our network. I would like to try and recreate doing this, but for the life of me I cannot figure out how to set my network card to promiscuous mode. It's a broadcom netxtreme 57xx card. Is there a document somewhere I can reference how to do that. I did spend some time searching for an answer today and learned quite a bit about what promiscuous mode was, but not starting it. Can anyone help?
Thanks for any help.
-Rich

THIS might be what your looking for.

Fantastic, that gives me some answers. I appreciate the quick response and thanks.

Depending on the OS you are running, you will also need libpcap or Winpcap. For Linux you should check out:

http://www.tcpdump.org/

For Windows:

http://www.winpcap.org/

You'll need these installed so that Ethereal or whatever tool you use can access the network card in promiscuous mode.

However, you are likely in a switched network. If your "naughty" user is sniffing passwords, the user has more access to your network than he/she should have. In the switched network, your promiscuous mode network card can still only see that traffic that passes by that card. Normally that is management traffic, broadcast traffic and traffic directed specifically to that NICs IP.

Hmm, that certainly makes things a little more interesting. We do have a switched network, so what I am gathering from your post is that running a sniffer won't really even read passwords on its own subnet, which is how I thought it would work. That's probably a good thing, but it thickens the plot a little...

What evidence do you have that the user is sniffing passwords?

It's an easy conclusion to come to but the user would need to be quite sophisticated to do it on a non-switched network, (not a genius - but smarter than your average user). On a switched network they would have to be very sophisticated.

Frankly, I would look for some other avenue such as his access to a password list that he should be denied from. Certainly you could look at his machine when he isn't there to see if a sniffer is loaded but I think you'll find he's ding this stuff in a more mundane fashion.

The only proof I had was the user logging in as administrator where he was not supposed to know the password at all. This thread is good though, I am learning to not look into the most difficult scenario first, maybe just look to the more obvious first. I am learning as I go for sure, so thanks all for the help.

Sniffing the administrators, (or any user's), password for a domain login is difficult to say the least since the password is never passed across the network - a hash of it is. This would require your user being able to sniff the hash off a switched network, recognize the hash within the packet capture and then decrypt the hash to reveal the original password - a task which could take months or years. None of these acts are trivial..... He got this password in another fashion... Start looking under keyboards.... ;)

Well i am not sure about all this switched netwrok stuffs, but here at my work one of my co-workers has this helpful little cd that he made. It has a bunch of **** on it like DBAN, Lysol, FDisk, and other helpful apps. But it also has this thing where if you use it as a boot disk then you can reset and change any of the passwords AND rights for any of the accounts on that pc. It also allows him to create his own admin accounts on that computer. Maybe the person your talking about is doing something similar.

JewishIntent made a good point. There is also the possibility that the person installed a keylogger on one of your systems and has been grabbing the information that way. That is a lot of work and there may be a high noise to content ratio, depending on the system monitored.

The direct route is the simplest and the most probable. The person in question has physical access. With physical access, you can get almost anything you want from the machine if you can boot to floppy/CD/DVD. Allowing systems to boot from CD/DVD/floppy makes it trivial to change local admin passwords, add local admin-level accounts, almost anything else. There should also be a Supervisor password on the BIOS to protect the boot sequence.

The sad thing about all of this is, I noticed the activity after I had reimaged a lab so anything that my "arch-enemy" was doing was wiped out. Of course, without the image I might not have noticed in the first place...double edged sword. It has taught me that I need to be WAY more vigilant though. One other question I have though, if the domain admin account had a profile on a machine, can the password somehow be decrypted out if that profile? I thought I read something about that in the past few days while I have been trying to figure out, just how much I don't know...which apparently is quite a bit.

It may be possible, with a cracking tool, to ferret out the domain admin passwords. My own policies cleared those from systems on logout, in my previous life. But, I also didn't use those for logins. Use a non-priviledged account for login, then runas for the heavy stuff.

Tutorial: Setting Up Promiscuous Mode

Code:

---

1. Saturday Night, Shower and shave.
2. Polish the black Justins.
3. Dust off the Stetson.
4. Dress with nice western shirt, jeans, Justins and Stetson. Skoal in back pocket.
5. Drive to honkey tonk.
6. Enter honkey tonk.
7. Order three shots whiskey at bar and slam 'em down.
8. Order beer for chaser.
9. Turn around and scan the floor.
10. Promiscuous Mode ON!

---

Just hadda do that.
;)

If you set the domain policy such that the clients don't cache passwords then there will be no passwords or their hashes from the domain stored on the client. The authentication will have to take place over the network.

To test for this setting log in as a domain user that has rights on the local machine. Log out, disconnect the network cable and try logging in as the same domain user. If it comes back telling you the domain can't be found then the setting is set correctly. If it logs you in to the local machine then it is not.