2

Looking at a wireshark capture, I'm seeing something really strange. Ethernet II packets with random data are being sent on the network. The larger packets in the capture seem to contain bits and pieces of http, but the src/dst don't make any sense at all.

Both src and dst mac addresses are random.... neither exist on my network. The funny thing is, the src/dst randomly change with each packet.

About 1-3 packets/sec. Unable to find either src or dst mac in the switch tables.

Any ideas as to what this traffic is?

See .pcap file from cloudshark below.

http://cloudshark.org/captures/eca6e20e1835

Any help would be appreciated. My mind is boggled. I would love to know how to track down the culprit of these packets!

A

eaglefly21
  • 23
  • 1
  • 5
  • Which packets are you concerned about? [Also this may help with finding the source/destination.](http://hwaddress.com/?q=AMS) It's a list of MAC addresses licensed to different manufacturers. – Mike Naylor Feb 03 '14 at 16:33
  • All of these packets are randomly generated. None of these packets originate from legitimate MAC addresses on my network. – eaglefly21 Feb 03 '14 at 16:37
  • It looks like a lot of the MAC addresses are licensed to Samsung. Do you have a wireless network? – Mike Naylor Feb 03 '14 at 16:37
  • I have already filtered everything else that doesn't relate out. These packets continue to stream in at about 2-3 packets/ sec. If you want a longer capture, I can run one for a while. – eaglefly21 Feb 03 '14 at 16:37
  • Try turning off your wireless access points to see if the traffic stops. – Mike Naylor Feb 03 '14 at 16:38
  • MY AP's are mac and wpa2 locked down. Only approved devices allowed, etc. Also the samsung devices on my network are already accounted for. – eaglefly21 Feb 03 '14 at 16:39
  • This is just a subset of the random MACs being generated. notice that the dst mac seems to be just incrementing the first pair. – eaglefly21 Feb 03 '14 at 16:40
  • Just noticed that and that the item that states its from a CISCO has a non-Cisco licensed MAC. This looks like something is spoofing MACs on your network. This could be malware or a virus trying to send data out to a receiver. Do you have a security device that can scan the network for virus/malware activity? – Mike Naylor Feb 03 '14 at 16:42
  • Here's another cloudshark capture I just finished filtering: http://cloudshark.org/captures/067a60a323c7 – eaglefly21 Feb 03 '14 at 16:45
  • Do you have any recommendations for a scanner like you are referring? I was thinking possible malware as well, but none of my current equipment looks at this level of info. – eaglefly21 Feb 03 '14 at 16:46
  • I don't have any direct recommendations but if you have a firewall or edge security device that has policies on traffic you could see if the outbound traffic is getting dropped there. Also if you have managed anti-virus see if you can make sure the clients are up to date and schedule a mandatory scan of the machines. You could also use something like Spiceworks to scan the network and get application lists to see who has what installed, if you have admin access. Seeing a bunch of toolbar applications or coupon printers is normally a tell-tale sign of a machine to check first... – Mike Naylor Feb 03 '14 at 16:51
  • Thanks for the ideas. I do have an IPS/firewall at the perimiter. Managed A/V is TrendMicro. I use spiceworks and will look to see what it finds. We do not allow toolbars, etc. so that's usually something we come down hard on. This is a new one to me though.... I usually track MACs across the network to find infected machines. With random MACs, I may just be out of luck finding the culprit.... for now. – eaglefly21 Feb 03 '14 at 16:54
  • Another option is to either monitor bandwidth on the machines to find one using more than others or using bandwidth after hours. Then there's the always faithful, turn 'em off one at a time and see when the traffic stops trick. With spoofing like this it's hard to track down the culprit. – Mike Naylor Feb 03 '14 at 16:57
  • Thanks for your ideas. I've traced the source to one of two VLANs within the company... neither of which makes any sense to me, but I'll keep digging. – eaglefly21 Feb 03 '14 at 17:31

1 Answers1

1

Packet 5 has, starting at an offset of hex 0036:

b4 99 ba 3d 49 00 00 17 54 01 63 b2 08 00 45

which looks like the beginning of an Ethernet packet to b4:99:ba:3d:49:00 from 00:17:54:01:63:b2, with a type field of 0x0800 meaning IPv4, and then the first byte of an IPv4 packet with no options.

If we treat that as an IPv4 header:

45 00 01 52 d7 d7 40 00 40 06 13 2f c0 a8 00 09 45 1f 48 cf

that's:

  • 45 - IPv4, 20-byte header
  • 00 - type of service (00 probably means "ordinary boring packet")
  • 01 52 - total length (338 bytes)
  • d7 d7 - identification
  • 40 00 - flags+fragment offset; flags = Don't Fragment, fragment offset = 0
  • 40 - Time To Live
  • 06 - protocol (TCP)
  • 13 2f - checksum
  • c0 a8 00 09 - source address (192.168.0.9)
  • 45 1f 48 cf - destination address (69.31.72.207)

I don't know whether that indicates where the packet came from or not, and I don't know what encapsulation is being used here (i.e., what all the stuff before the IPv4 header is). There might be a header that's not an Ethernet header but does have an Ethernet type field at the end.

  • Thanks for the analysis. The 192.168.0.9 is my Barracuda web filter, which has been featured in several of these packets. Most of the world-readable data in the larger packets in this trace seems to be pieces of URL headers relating to keepalives. Not sure why the src/dst mac addresses are so screwy though. Its almost as though there is something either on the Barracuda filter or elsewhere on the network that is sending barracuda web traffic info to random dst addresses. I'll have to dig into my Barracuda a little bit more and see if it might be causing this. Thanks for the lesson! – eaglefly21 Feb 03 '14 at 21:20
  • One question.... What is creating the packet? Its probably not either of the two machines listed in the info above. Still, VERY weird! – eaglefly21 Feb 04 '14 at 19:18
  • Closest thing I have to an actual answer. Thanks for helping with the offset. – eaglefly21 Feb 05 '14 at 13:13