Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm doing an educational pen test exercise and I'm trying to sniff traffic from a compromised Windows machine. I've been using the post-exploitation sniffer and packetrecorder Meterpreter modules, but so far, they've only contained packets either destined for the host I'm using or broadcast traffic. I'm trying to figure out if I'm missing some data or if there isn't any other traffic on the subnet.

Do either of these modules run in promiscuous mode?

share|improve this question
    
Are you plugged into a switch or a hub? –  NULLZ Aug 28 '13 at 1:21
    
My machine (running metasploit) is connected via a virtual switch, but I'm guessing the compromised host is on a hub connected to other hosts because traceroute shows them 1 hop away. –  austin Aug 28 '13 at 2:15
    
I believe you will need to do ARP poisoning to receive all traffic. –  AdnanG Aug 28 '13 at 16:12

1 Answer 1

up vote 3 down vote accepted

To answer whether the sniffer module runs in promiscuous mode by default I am doing a test in my lab right now and will update it here when its done.

UPDATE

The answer finally comes out to be YES. The sniffer module does its capturing in promiscuous mode. To test I set up a win-xp-sp2 (10.10.10.101) vm on proxmoxVE (kvm virtual env). I added it to a bridge and added kali-linux (having ip 10.10.10.15) and a few more machines (machine-a 10.10.10.100 and machine-b 10.10.10.110) to the bridge. After running the exploit for netapi, I started the sniffer module on the target. Problem is linux bridges act as switches by default so again I ran into the same problem. I could only see the machines own traffic and broadcasts. Now to make a linux bridge act like a hub and not a switch, the aging for the bridges mac address table needs to be set to 0 (so it doesn't have a mac-address-table at all and traffic like broadcasts seding it to all members. For reference the command is brctl setageing <bridgename> 0. Once this was done, I pinged from machine-b to machine-a and here is what I got:

2013-08-28 21:22:03.000000 ARP, Request who-has 10.10.10.100 tell 10.10.10.110, length 46
2013-08-28 21:22:03.000000 ARP, Reply 10.10.10.100 is-at 2e:76:03:d3:b9:72, length 46
2013-08-28 21:22:03.000000 IP 10.10.10.110 > 10.10.10.100: ICMP echo request, id 11328, seq 1, length 64
2013-08-28 21:22:03.000000 IP 10.10.10.100 > 10.10.10.110: ICMP echo reply, id 11328, seq 1, length 64
2013-08-28 21:22:04.000000 IP 10.10.10.110 > 10.10.10.100: ICMP echo request, id 11328, seq 2, length 64
2013-08-28 21:22:04.000000 IP 10.10.10.100 > 10.10.10.110: ICMP echo reply, id 11328, seq 2, length 64
2013-08-28 21:22:08.000000 ARP, Request who-has 10.10.10.110 tell 10.10.10.100, length 46
2013-08-28 21:22:08.000000 ARP, Reply 10.10.10.110 is-at 22:06:8c:52:9f:c5, length 46

As you can see none of the above is supposed to be seen by the xp2 vm apart from the ARP who-has packets. Hence I can safely say that all packets which somehow reach the interface being sniffed are indeed recorded by the sniffer module and it is definitely running in promiscuous mode.

General but important Information

Switches send packets destined to IPs which you have an ARP entry on remote hosts for only. The remote host will send the packet with a destination MAC address based on their ARP table and a switch will only send it out the port where that MAC address is located. So even in promiscuous mode you will only see packets either explicitly destined to your IP or broadcasts which are sent out all ports connected to the switch in the same collision domain (VLAN and subnet).

Hubs on the other hand mirror data received from anywhere to all ports irrespective of the destination MAC address since they are not smart enough to know which port the destination MAC address is available on. This leads to traffic between other machines also getting sent to you and this is probably the case you were hoping for, but from what you described the virtual switch acts like a semi-intelligent switch with a MAC table and the behavior is as described in the first paragraph.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.