Wack-a-mole OR bandwidth theft

[GreyGeek]

While experimenting with Wayland, which has nothing to do with what I found, I noticed wifi activity when my browser wasn't open. Curious, I ran ss and noticed:

tcp ESTAB 0 0 192.168.1.100:57590 96.17.53.210:https
tcp ESTAB 0 0 192.168.1.100:57588 96.17.53.210:https

Using whois I found that 96.17.53.210 was akamai, a CDN (Content Delivery Network). It turns out that they use p2p to exploit users bandwidth, even if the user didn't give them permission. I found akamai was generating up to a dozen streams to store its content on my SSD and to deliver it to others whose browsing led to an akamai connection.
I tracked the app down, but it is ephemeral:

The problem is that plasmashellKOTClr.6.slave-socket doesn't exist where its path says it should exist. When I end the process, there are always two (one to receive and store content and the other to send to the final destination?) and if I terminate them another pair pops up almost immediately, so a hidden process is triggering the regens.

The last thing to consider is that this process is, in effect, an intrusion into my desktop, at least at the user level. It wouldn't take a keyboard logger long to catch my password and the game would be over. I'm continuing to explore the situation but wanted to pass on what I knew so far.

[GreyGeek]

I didn't identify any sockets that could be associated with the akamai p2p socket.
The following is all the sockets systemd is aware of:

[GreyGeek]

Doing some research I installed Konqueror and found that Konqueror allowed me to see the socket in its listing. That install also gave Dolphin the ability to see sockets as well. The process tree in ksysmon lists the kioslave5 processes under systemd, but as shown in the post above there is no listener or socket which loads kioslave5 or reloads it when it is terminated. And, I am unable to find any scripts or settings which relate to akamai and a kioslave5.
I fired up EtherApe and discovered the domain name of the akamai server. I found it appeared to be linked to kdeconnect. Lines between my laptop and my Android and akamaiedge.net lit up simultaneously. I put the full akamai domain name in my /etc/hosts file and am now watching to see what happens.

[GreyGeek]

I used wireshark to see what was being saved to my storage and what was being transmitted to akamai. The payload averaged about 600 bytes per packet but they were encrypted so I couldn't see what the data was.

After putting the following in the /etc/hosts file

# [akamaiedge.net]
0.0.0.0 e7876.dscg.akamaiedge.net
0.0.0.0 e12930.dscj.akamaiedge.net
0.0.0.0 a23-44-164-37.deploy.static.akamaitechnologies.com

I noticed that the p2p connection switched to an amazon server. I'm assuming that akamai and the other corporations can create domain names faster than I can wack them. That makes wack-a-mole essentially impossible.

Not finding any other source for the constant triggering of kioslave5 processes related to the p2p CDN connection from akamai, I was left with only one remaining source: the Brave browser itself. I closed Brave and monitored the kioslave5 processes. They disappeared on their own after a few minutes. I fired up FireFox and browsed a bit and then checked for the 443 port connections via kioslave5 processes. None were present. I closed FF and started up Brave again. The kioslave5 processes appeared immediately. I conclude the the source of the p2p connection to akamai is the Brave browser.

I have switched to FireFox.

[GreyGeek]

I need to put at least six characters in this post to make it go!

[GreyGeek]

I thought I had the culprit nailed down. So, I switched to FireFox. I was wrong. Using FF the p2p started up again, this time with a fresh domain from akamai, which is not in my /etc/hosts files. Back to square one.

Anybody see ?.akamaitechnoligies.net (or com) in their processes? when they run EtherApe or Wireshark?