
Mysterious outbound UDP traffic on port 8888… Help!
What is this traffic on port 8888? Or a device is infected and trying to communicate over port 8888 to IP addresses all over the world?!?! I’ve seen forum posts with similar titles a handful of times now and the final result is often someone discovering the Private Internet Access (PIA) client on a device or computer. I get a chuckle every time I see it because I was once in their shoes so I figured I would make a post explaining what is going on. I also hope it saves someone from a future freakout moment!
TL;DR version -> R. E. L. A. X. It’s absolutely worth investigating, but you probably haven’t been breached. Instead, your network likely has some shadow IT in an attempt to get around IT-related restrictions.
Changelog
5July2018 – Originally posted
What is Private Internet Access (PIA)? PIA is a low cost, anonymous VPN provider and quite honestly, it’s awesome. For under $70 dollars/year, you get access to a myriad of locations around the world. For example, you can easily make your traffic appear as though it is coming from California, Israel, Canada, or wherever else they have nodes. I do occasionally use PIA if I *really* need to hop on an untrusted network and I want to protect my traffic while I’m on the road. However, more often than not, I use it for customer security testing from external, “outside” IP addresses. For example, if I just added a restrictive firewall rule that *should* only allow traffic from specific IP addresses. I say should because sometimes firewall vendor configurations are quirky and what you thought was a beautifully configured rule just opened a service to everyone on the planet.
Unfortunately, it appears are some other folks are using the anonymous nature of PIA for evil too. We know this because of how many times PIA IP addresses end up on threat feeds and that’s what most of this post will discuss.
Evil? How Do You Know?
The table below shows an IP on my LAN attempting to communicate with a number of bad guys/IPs on the internet. As you may or may not recognize, my block notifications are coming courtesy of the pfSense-based pfBlockerNG package that I’ve written about many times before. pfBlockerNG shows me that the IP addresses are related to AlienVault threat feeds, Bad IP 7-day threat feeds, etc. Honestly, many of the IPs getting blocked are likely on hundreds of other feeds. Why? Those IPs ended up on threat/reputation feeds because at some point, someone from that IP address tried scanning a honeypot or running a vulnerability against a “protected” system and they got caught. No, they weren’t hauled off to jail in that sense of getting caught. Instead, they scanned a system and said system identified the traffic as malicious. It then shared that new information with others and voila, it became part of a basic threat feed.
So a bunch of traffic is getting blocked because I’m trying to communicate with an IP address that was known evil at some point. That’s great because they should! But what about the original question of determining if this was PIA traffic and nothing more? What are the other telltale signs of PIA traffic?
Sign #1: UDP Port 8888
First, all of the traffic is destined for UDP port 8888 as shown in the simple connection information below.
19:54:48.044077 IP <myip>.24333 > 104.156.228.165.8888: UDP, length 1 19:54:48.044125 IP <myip>.4481 > 107.182.231.27.8888: UDP, length 1 19:54:48.044180 IP <myip>.59804 > 172.98.79.199.8888: UDP, length 1 19:54:48.044229 IP <myip>.62132 > 162.251.236.6.8888: UDP, length 1 19:54:48.044282 IP <myip>.13800 > 205.251.148.122.8888: UDP, length 1 19:54:48.044336 IP <myip>.58759 > 89.238.154.241.8888: UDP, length 1 19:54:48.044389 IP <myip>.52178 > 31.24.226.230.8888: UDP, length 1 19:54:48.044433 IP <myip>.43292 > 89.238.139.7.8888: UDP, length 1
Sign #2: Length Matters
If you look again at the simple traffic flow data above and you’re used to perusing network traffic, you might have noticed all of the packets have a length of 1. That’s odd to say the least. In this case, the packets act as a test to see if the external host is accessible. If you were to dive into further analysis of the packet, the hex data is 61, which translates to a lowercase letter ‘a’ and I’ve highlighted both below.
Sign #3: Countries Contacted
Going back to the block list created by pfBlockerNG, you’ll see the column GeoIP. The 2-letter country code found there is related to the destination IP address. Is it normal for machines to rifle through IP addresses from all over the globe? Probably not!
Country Code | Country |
IL | Israel |
IT | Italy |
IE | Ireland |
SE | Sweden |
DE | Germany |
Right-click the PIA client icon next to your clock (red when not connected, green when it is) and you’ll see a large list of locations PIA can connect to. You can browse through the select-able locations and easily find ones that have issues by correlating them with the block list. I’ve highlighted a handful of the locations I found which generated alerts such as Germany and Sweden.
Detecting PIA Without pfBlockerNG
When this first happened to me, I saw the alert from pfBlockerNG. What if you don’t have pfBlockerNG at your disposal? Are you doing egress filtering? All commercial firewalls [that are not re-branded consumer-grade junk] allow you to perform egress filtering rather easily. The issue is usually figuring out your traffic and which ports are necessary. Fortunately or unfortunately, for this reason most default firewall configurations start off with an “allow all” instead because a) it’s easier and b) many people have a bear of a time configuring anything otherwise. If you don’t have egress filtering configured and/or you ended up here because someone was doing shadow IT on your network, then you could block 8888 outbound and the PIA “issue” goes away. But wait! Keep in mind there are a thousand (or more) other VPN solutions available and not all of them use port 8888. So while you’re blocking 8888 outbound, you really need to go ahead and block everything else outbound except for what you need. You would be amazed at the number of problems — outbound spam, some malware, some ransomware — egress filtering can proactively prevent or at least detect. Not to mention, your network will thank you!

Dallas Haselhorst has worked as an IT and information security consultant for over 20 years. During that time, he has owned his own businesses and worked with companies in numerous industries. Dallas holds several industry certifications and when not working or tinkering in tech, he may be found attempting to mold his daughters into card carrying nerds and organizing BSidesKC.
10 thoughts on “Mysterious outbound UDP traffic on port 8888… Help!”
I have forwarded your post to PIA and asked for comments. This is what they replied:
Quote
Thank you for reaching out to us for support.
This is actually not mysterious traffic. This traffic is being generated by Ruby, and is simply sending a ping to all of PIAs different servers. If you would like to verify this, you can use a terminal window and use the command “tracert xxx.xxx.xxx.xxx” where the “x”‘s are the IP Addresses that you are seeing before the port 8888. You will find that when the tracert completes, the end hostname will be one of several shell companies used by PIA such as logic web, choopa, m247 and there may be a couple of others. This traffic is only used to find the server with the lowest ping times so that when you disconnect from our service, and select “connect automatically”, the server with the lowest ping time will be the one that you are connected to.
Please let us know if we can further assist you.
Unquote
Hey Jerome! PIA support is spot on. There’s nothing mysterious or malicious about the traffic. The title and first few sentences are simply the type of reactions I see (or hear) from people when they first find this “type” of traffic on their network. The post really is explaining what this traffic looks like and why it appears evil at first glance in the hopes “it saves someone from a future freakout moment!” As I mentioned, I personally went through this entire step-by-step analysis some time ago and since then I’ve heard others discussing it so I thought it would make an interesting post. Thanks again for stopping by!
Thank you for writing this up. I should have checked first before wiping my macbook on the fear that it is infected.
Since, installing PIA I started seeing these alerts again on my pfblockerng. That’s when I thought of searching inter webs.
Oh well, at least now I have clean macbook air.
Dang! I wish you would have seen this too! Like you said though, fresh OS installs are never a bad thing!
Very helpful. I spent numerous hours trying to track down this problem. I used 2 different sniffers, and other apps to find the problem was Rubyw.exe coinciding with my ports being blocked. I thought it was my Kali Linux and Ruby on Rails which I removed. Later today thinking I fully resolved my issue, I saw your post. Curious, I restarted my PIA connection and it did restart the port 8888 connections, however, it is no longer every 1 minute and 4 seconds now that I removed Ruby off my Windows computer. Now it connects to many IPs just once. No idea why Rubyw.exe, once stopped, no longer causes about 12 outgoing UDP sessions on port 8888 but PIA still works. I was curious “why” use Ruby instead of local ping. It appears Ruby has an ability to do a non-ICMP ping, doing a TCP Echo ping.
Sergio, thanks for the feedback! You’re likely right on the ‘why.’ The standard Windows traceroute (tracert.exe) uses ICMP while most *nix-based systems use UDP so it may have been done for consistency. The only side effect of removing/stopping Ruby is that your latency times to each VPN connection in the UI will never change, which is pretty minor IMO.
Thank you so much for publishing this – I just spent an hour-long adventure with wireshark and tcpdump and lsof thinking that I was accidentally part of a botnet or something. PIA was the culprit after all, not malware at all.
Mind you, it seems a little bit weird that these are sent out every minute, even when the VPN is disconnected. I guess like they said, the purpose is to calculate the lowest ping, but on the other hand, why advertise that you’re a PIA user to everyone by sending a bunch of datagrams every minute while the thing is disconnected? Just to save yourself a couple seconds of startup time when you connect, even when it takes several seconds anyway? I’m not a fan. I guess the moral of the story is that I should just completely exit PIA when I’m not using it.
Again, thank you for publishing this! This is a huge relief.
Happy to hear this helped! I see their reasoning for it, but at the same time I agree with you. I exit PIA whenever I don’t need it. I guess if we don’t like it, we just use a standard OpenVPN client which is what I do on Linux systems anyway. Thanks again for the feedback!
I found this very helpful. I’ve been wondering why my ASUS router’s Trend Micro protection was sending me outbound alerts for my MacBook. Blocking port 8888 for the pia-daemon seemed to do the trick. Thanks!
No problem at all! Thanks for the feedback!