Home > forensics, network security > Network forensics afternoon

Network forensics afternoon

Well, strange things happened today . While working on a project , I noticed a strange high incoming network traffic on the system monitor of my ubuntu machine. High, as in ~8MBps with small bursts that lasted some minutes and produced ( according to system monitor again ) a total download traffic of 1.9 GB .
As you can imagine I was pretty surprised , I was sure I was not running anything that could cause such amounts of traffic . The applications running at that time were skype,  firefox , thunderbird and Aptana studio none of which could result to that kind of traffic (I had only one tab open in ff at the time , pointing to KTH website , and Aptana’s automatic update process needs user confirmation in order to download updates) . My first reaction was to run netstat , which produced uninteresting results , typical ESTABLISHED connections by thunderbird to the imap servers it was supposed to, a connection to ip initiated by an application recognised as “python” ( which was actually the ubuntu one client ) , one regarding skype and one regarding ff as expected more or less. I didn’t keep the output somewhere but I’m pretty sure I didn’t miss anything there. As I was gradually getting from surprised to worried since the traffic seemed to continue at approx the same rate, I fired up wireshark and started capturing my wired interface. Couple of minutes after that the traffic stopped and I haven’t noticed anything peculiar since.

So I started to check the capture , trying to find the stream that produced the traffic I observed. From a first look there seemed to be many long UDP flows from different IP addresses (various high ports) to a specific IP address (not my interface’s though) on port 51508 . The destination address is in the same subnet as mine and I have  confirmed that is up and port 51508 (among other high ports is open). This smelled like bittorrent traffic from distance . To confirm , here is what a random packet of that stream looked like :

0000  0c 60 76 61 69 98 00 12  bf d9 bf 65 08 00 45 00   .`vai... ...e..E.
0010  00 83 5f cc 00 00 0e 11  8f 96 18 71 f4 7d d5 67   .._..... ...q.}.g
0020  da b1 fb 21 c9 34 00 6f  fd 34 64 31 3a 61 64 32   ...!.4.o .4d1:ad2
0030  3a 69 64 32 30 3a 49 b8  74 ec 25 bf d6 64 bc 10   :id20:I. t.%..d..
0040  b8 94 e1 60 fd 59 b8 b0  45 15 36 3a 74 61 72 67   ...`.Y.. E.6:targ
0050  65 74 32 30 3a 49 b9 33  f4 ee 98 e2 29 bd 70 f2   et20:I.3 ....).p.
0060  a3 95 7b de d5 05 8d 38  01 65 31 3a 71 39 3a 66   ..{....8 .e1:q9:f
0070  69 6e 64 5f 6e 6f 64 65  31 3a 74 34 3a 84 8c 00   ind_node 1:t4:...
0080  00 31 3a 76 34 3a 55 54  57 b2 31 3a 79 31 3a 71   .1:v4:UT W.1:y1:q
0090  65                                                 e

which is actually a find_node DHT QUERY as described here . While this sort of explains the nature of the traffic , it doesn’t explain

a) Why was I apparently receiving this traffic when I was not supposed to in the first place .

b) If I was receiving the traffic, what was it and where was it stored in my machine.( remember we are talking about ~2GB of data.)

To start with b) I didn’t remember the last time I checked how much space i was using on my disk, but the current usage percentage didn’t seem alerting by itself. So , this is where find(1) came in handy

~$ find . -type f -mmin -120 -printf '%p %s \n'

didn’t reveal anything interesting although. There were a bunch of files modified in the past 2 hours , but none of them seemed suspicious or modified with no reason.

as to a)  I can only make wild guesses. One detail that might be interesting is that yesterday all the switches in the building were replaced so to support the 100/1o we are ow offered (hence the 8,4 MBps in the beginning) .It doesn’t look like an ARP attack , according to the capture. But what kind of misconfiguration would have these kind of results ? I can see a lot of packets addressed to other hosts. CAM table overflow at the switch ?But why I was seeing the traffic in the system monitor ? Shouldn’t those packets be dropped by my NIC ? It wasn’t in promiscuous mode before I ran wireshark .

So ? Comments, suggestions , answers to the questions ?

  1. ikoz
    December 1, 2010 at 8:36 pm

    do you have a pcap? What was the mac address of the incoming packets?

  2. ilektrojohn
    December 1, 2010 at 10:30 pm

    Yes I do have a pcap but it is 100 MB :S . I started looking at the MAC addresses of the packets more thoroughly since your comment and what I figured out is :

    Most of the packets in the capture have the same source address in ethernet header, which makes sense since it’s the MAC address of the interface of the router that the switch is connected to.
    Interestingly enough all ( apart from 10-20 ) the packets that are associated with the UDP flow I was describing in the main post , seemingly come through 2 interfaces which have a lot in common . Different IP addresses but both in the same subnet, MAC address of the same manufacturer, and having the same filtered ports . The other thing about those 2 MAC addresses is that through the whole capture they are sending simultaneous(~2 msec apart each time) ARP requests for the same IP addresses .
    The destination ethernet address of the packets in the UDP flows much the dest IP address . Any ideas ?

  3. ikoz
    December 1, 2010 at 11:20 pm

    “The destination ethernet address of the packets in the UDP flows much the dest IP address .” something is not right here 😛
    Can you post the exact hex mac addresses, mostly the destination ones?
    What I was thinking is that there must be an issue with the switch, so the destination mac addresses might be multicast mac addresses or something.

  4. ilektrojohn
    December 1, 2010 at 11:31 pm

    Yes ,the thing that is not right is how freaking sleepy I am 🙂 Obviously s/much/match/ .
    What I meant is that for the traffic I am talking about , the dest MAC address is what it would normally be , the MAC address of the interface who’s IP address is the dest IP.
    It’s the first 6 bytes of the packet I posted above : 0c:60:76:61:69:98. Which is the MAC address of the IP the packets are destined to, although not the IP of my interface.

    Some people on twitter have suggested that all this thing can simply be my skype instance , acting as a super peer, I’m checking that also .

  5. ikoz
    December 2, 2010 at 3:21 am

    ok no luck with the mac addresses – btw i should really tcpdump the packet instead of asking :p

    Skype, thats an interesting idea. Do all your received packets look like that? Because this is clearly a dht packet. Skype uses dht for node management and control issues, not for its traffic afaik. Also, if we suppose those packets are skype traffic destined to the IP you see, if the computer at that IP had a hostbased firewall, and you were a super-node for him, those packets should be destined to you, and then you would forward them to him..

    How are IPs managed where you live? Does your router give you dynamic IPs? Maybe there is an IP conflict, or some other weird ip / switching problem.

  6. dtsomp
    December 2, 2010 at 10:57 am

    Some random ideas…

    1) If not all of your traffic is P2P, then Thunderbird may be responsible for a good part of the 1.9GB. On my computer, Thunderbird decides to reindex all (~8000) Gmail/IMAP messages every now and then. Nasty business.
    2) Skype can use super-peers to bypass NAT but you should see similar upstream traffic.
    3) This is so far out but shit happens: is there any chance you are hooked on a hub? 😀 I mean, you get traffic that’s not meant for you.

  7. zmousm
    December 22, 2010 at 8:09 am

    You mentioned seeing (presumably broadcast) ARP for the same IP address by two MAC addresses. I suppose no other (unicast) traffic has been sent from these addresses (e.g. an ICMP echo reply)?
    If so, this pattern resembles a particular clustering mechanism (Microsoft unicast NLB comes to mind), where cluster members share a virtual MAC address (usually a LAA) and do not send any unicast frames using the particular MAC as source, so as to prevent this address from being learned by the switch, in order to achieve flooding of frames having this destination address to all ports of the broadcast domain, so all cluster members can receive them, effectively turning the switch into a hub.
    This is of course a very ugly hack and certainly not meant to be used in a “public” broadcast domain.

  8. August 23, 2013 at 12:20 am

    Refrigerant dehumidifiers are those typically marketed in the hire brochure like a ‘builders dehumidifier’ or ‘building dryer’.
    This on it’s own can help save a bunch of money because you’ll be able to
    get a well reviewed dehumidifier sometimes for under $100.
    And you need to understand how to pick the one which will give
    you the top deal.

  9. October 16, 2014 at 10:13 am

    Hi colleagues, fastidious article and good urging commented
    at this place, I am genuinely enjoying by these.

  10. January 19, 2017 at 7:58 pm

    If you are going for best contents like me, simply visit this site every day
    because it gives quality contents, thanks

  11. January 26, 2017 at 12:08 am

    An impressive share! I have just forwarded
    this onto a co-worker who has been conducting a little homework on this.

    And he actually ordered me dinner because I stumbled upon it for him…
    lol. So let me reword this…. Thanks for the meal!!
    But yeah, thanks for spending time to discuss this issue here on your internet site.

  12. May 3, 2017 at 9:28 am

    Todas estas fórmulas tienen algo en común: te fuerzan a concentrarte y activar tu
    mente para recitar unas oraciones repetir unas palabras memorizadas.  http://haley9clemons90.blox.pl/2017/03/Contactar-Con-Uber-Por-Un-Objetoenspperdido.html

  13. July 1, 2017 at 9:58 pm

    Hello to every , as I am genuinely keen of reading this
    web site’s post to be updated oon a regular basis.
    It includes good data.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: