How can identify an unknown source of suspicious network traffic on my Mac OS X computer?

Question

Sometimes (maybe about once a day) I appear to have a quite high amount of incoming network traffic of around 2.5Mb/s during 15 minutes for no apparent reason. No P2P, nothing launched except browser and email and I even tried to stop them without changes.

My computer is a personal Mac OS X 10.10.4 (Yosemite) updated from Mac OS X 10.9.6 (Mavericks) and I’m the only owner. I have a script that rsync’s data on my local network every hour but it’s obviously not that. I also have a Synology app installed but it's closed and doesn't appear in ps aux or top.

I investigated with iftop, so I can see where it’s comming from:

When I turn port display to numeric, FMTP is 8500, it corresponds to flight message protocol.

Then I tried to ping the IPs:

Buzut:~ Buzut$ ping 89.86.97.2
PING 89.86.97.2 (89.86.97.2): 56 data bytes
36 bytes from vl212.c6k04-t2.net.bbox.fr (62.34.0.182): Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 abc7   0 0000  38  01 5abc 192.168.1.37  89.86.97.2 

Request timeout for icmp_seq 0
36 bytes from vl212.c6k04-t2.net.bbox.fr (62.34.0.182): Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 ae78   0 0000  38  01 580b 192.168.1.37  89.86.97.2 


--- 89.86.97.2 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss

Buzut:~ Buzut$ ping 239.0.5.49
PING 239.0.5.49 (239.0.5.49): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
--- 239.0.5.49 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss

What’s weird is that I’m 192.160.1.37 on my network but here it’s downloading data from 89.86.97.2 to 239.0.5.49 like if it just went through my computer without it to be the destination.

bbox.fr has something to do with my ISP because it’s Bouygues Telecom. But appart from that, it still look suspect to me. How can I know more? What is being downloaded? For what purpose?

At the same time, I don’t see this with netstat. The version of netstat in Mac OS X doesn’t work the same way as on other systems as far as options go. So here it goes:

Buzut$ netstat -a
Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)    
tcp4       0      0  192.168.1.37.50924     stackoverflow.co.https ESTABLISHED
tcp4       0      0  192.168.1.37.50922     190.93.245.58.http     ESTABLISHED
tcp4       0      0  192.168.1.37.50918     ec2-23-21-110-17.http  ESTABLISHED
tcp4       0      0  192.168.1.37.50917     ec2-23-21-110-17.http  ESTABLISHED
tcp4       0      0  192.168.1.37.50912     104.16.12.8.http       ESTABLISHED
tcp4       0      0  192.168.1.37.50799     a23-200-86-198.d.http  ESTABLISHED
tcp4       0      0  192.168.1.37.50797     mrs04s09-in-f206.http  ESTABLISHED
tcp4       0      0  192.168.1.37.50585     ip-228.net-89-3-.6690  ESTABLISHED
tcp4       0      0  localhost.cap          *.*                    LISTEN     
tcp4       0      0  localhost.1024         *.*                    LISTEN     
tcp4       0      0  localhost.blackjack    *.*                    LISTEN     
tcp4       0      0  192.168.1.37.49468     stackoverflow.co.https ESTABLISHED
tcp46      0      0  *.53673                *.*                    LISTEN     
tcp4       0      0  *.53673                *.*                    LISTEN     
tcp4       0      0  192.168.1.37.49445     17.110.227.99.5223     ESTABLISHED
tcp4       0      0  localhost.27017        localhost.64807        ESTABLISHED
tcp4       0      0  localhost.64807        localhost.27017        ESTABLISHED
tcp4       0      0  *.27017                *.*                    LISTEN     
tcp4       0      0  192.168.1.37.64286     192.230.65.4.ip..https ESTABLISHED
tcp4     143      0  192.168.1.37.58235     ns0.ovh.net.imap       CLOSE_WAIT 
tcp4     143      0  192.168.1.37.58232     ns0.ovh.net.imap       CLOSE_WAIT 
tcp4     143      0  192.168.1.37.58230     ns0.ovh.net.imap       CLOSE_WAIT 
tcp4       0      0  192.168.1.37.56996     17.172.239.102.5223    ESTABLISHED
tcp4       0      0  localhost.intu-ec-clie *.*                    LISTEN     
tcp6       0      0  localhost.intu-ec-     *.*                    LISTEN     
tcp4     143      0  192.168.1.37.62687     ns0.ovh.net.imap       CLOSE_WAIT 
tcp4       0      0  localhost.ipp          *.*                    LISTEN     
tcp6       0      0  localhost.ipp          *.*                    LISTEN     
udp4       0      0  *.53878                *.*                               
udp4       0      0  *.62654                *.*                               
udp4       0      0  *.*                    *.*                               
udp46      0      0  *.53673                *.*                               
udp4       0      0  *.53673                *.*                               
udp4       0      0  *.54480                *.*                               
udp4       0      0  192.168.1.37.ntp       *.*                               
udp6       0      0  buzut.ntp              *.*                               
udp6       0      0  *.62268                *.*                               
udp4       0      0  *.62268                *.*                               
udp6       0      0  *.53100                *.*                               
udp4       0      0  *.53100                *.*                               
udp6       0      0  *.63111                *.*                               
udp4       0      0  *.63111                *.*                               
udp6       0      0  *.53310                *.*                               
udp4       0      0  *.53310                *.*                               
udp6       0      0  *.65513                *.*                               
udp4       0      0  *.65513                *.*                               
udp6       0      0  *.62913                *.*                               
udp4       0      0  *.62913                *.*                               
udp46      0      0  *.*                    *.*                               
udp4       0      0  *.*                    *.*                               
udp4       0      0  *.*                    *.*                               
udp4       0      0  *.*                    *.*                               
udp4       0      0  *.*                    *.*                               
udp4       0      0  *.54514                *.*                               
udp4       0      0  *.*                    *.*                               
udp4       0      0  *.*                    *.*                               
udp4       0      0  *.*                    *.*                               
udp6       0      0  localhost.ntp          *.*                               
udp4       0      0  localhost.ntp          *.*                               
udp6       0      0  localhost.ntp          *.*                               
udp6       0      0  *.ntp                  *.*                               
udp4       0      0  *.ntp                  *.*                               
udp4       0      0  *.*                    *.*                               
udp4       0      0  *.*                    *.*                               
udp4       0      0  *.*                    *.*                               
udp4       0      0  *.*                    *.*                               
udp4       0      0  *.*                    *.*                               
udp4       0      0  *.*                    *.*                               
udp4       0      0  *.*                    *.*                               
udp46      0      0  *.*                    *.*                               
udp4       0      0  *.*                    *.*                               
udp4       0      0  *.*                    *.*                               
udp4       0      0  *.*                    *.*                               
udp6       0      0  *.mdns                 *.*                               
udp4       0      0  *.mdns                 *.*                               
udp4       0      0  *.*                    *.*                               
udp4       0      0  *.netbios-ns           *.*                               
udp4       0      0  *.netbios-dgm          *.*

Answer 1

So here is my forensics on what you are presenting:

The Basics

239.0.5.49 is a multicast address in the administratively-scoped (local) multicast range of addresses from 239.0.0.0 to 239.255.255.255.

Since 89.86.97.2 resolves to Bouygues Telecom, my best guess is that is your outward/WAN interface address or perhaps a router on the Bouygues Telecom network.

And as far as your differences between iftop results and netstat goes, this answer on Server Fault sums it up concisely: iftop uses pcap (packet capture) to show/capture all packets on a network while netstat strictly shows the sockets open machines on the network.

So my educated guess is while you might not be aware of a process actively running, something on your network—and possibly even your ISP connection device; modem or router—is broadcasting outwardly to the 89.86.97.2 network. And multicast means basically that: Just throw packets onto the network.

More Details/Theories

Yes, port 8502 translates to “FTN Message Transfer Protocol” on some port deciphering sites but the receiving port of 49152 is within the dynamic/private port range. My gut tells me that port 8502 might be used for something else in this case because—for example—software like CommCell/CommVault uses port 8502 as well.

As for what would constitute 2.5MB of traffic every now and then? No clue. But following up on the CommCell idea and reading the documentation on the software reveals:

The software provides a powerful set of storage management tools that help you move and manage your critical data. These tools enable you to store and retrieve data associated with computer systems in your enterprise.

So knowing all of that, you say you are using Mac OS X I am but unclear what machine you have or where it initially came from. Was it ever a machine that was a part of an Enterprise (aka: workplace) environment where data on machine usage would need to be sent to an administrator on a regular basis? Because what you are saying about this burst of 2.5MB of data every now and then seems to mesh nicely with some background/daemon system monitoring process that is trying to “reach out” to a network central server to send data.

Meaning, I believe that some CommCell related process—perhaps the iDataAgent installed on a client system as explained here—is attempting to broadcast your machine’s system EKG data to the larger world; what it thinks is a central CommCell Console server. But it’s failing since you are not in an Enterprise environment or this machine is misconfigured. So that 2.5MB of data is just being dumped into the ether and the “destination” of your 89.86.97.2 (Bouygues Telecom) external IP address is the best it can do.

Addendum

All of that said, in a comment on this answer you state, “…but the 2.5MB of data is ingoing, not outgoing…” Well, yes it technically is incoming; the traffic is coming from the address 89.86.97.2 (a Bouygues Telecom address) and apparently going to 239.0.5.49 (a multicast address on your system). So it would seem that something on the Bouygues Telecom network is broadcasting that 2.5MB of data to all multicast connections; including yours. That is what multicast is about.

Which is to say, I don’t believe any of this is coming from a process on your Mac OS X computer but rather iftop is just picking up all packets it gets and tells you what it sees.

Should you be concerned that a seemingly random 2.5MB burst of data is headed to your Bouygues Telecom network connection? I am a bit unsure about that but if it concerns you I would recommend contacting Bouygues Telecom tech support and asking, “Is there a reason why 2.5MB of multicast traffic is being sent to my computer’s network by your network every 15 minutes or so?” Granted, the chances of you getting a straight/real answer to that question are slim at best, but honestly it wouldn’t be a bad first step to take if you are truly curious about this.