3 ms·

There are plenty of explanations that don't involve malware. If you open 68.235.39.11, you end up on Linux Mint's Repositories website. Similarly, others conn

by dchest 3y ago

There are plenty of explanations that don't involve malware. If you open 68.235.39.11, you end up on Linux Mint's Repositories website. Similarly, others connections may be caused by: - autoupdater - internet detection when connecting to wi-fi - some kind of analytics backed into the distro - some other software

WTHISGO 3y ago
No, normal entries state PID and binary path like so: 1128 root /usr/sbin/NetworkManager But these I'm concerned about look like below, no PID, no binary, just ip pairs. Here you can see various ips making connection to my machine in this very moment: ? root 184.104.179.141:443-172.20.13.34:35542 ? root 104.18.21.226:80-172.20.13.34:39954 ? root 142.250.186.66:443-172.20.13.34:46432 ? root 142.250.186.104:443-172.20.13.34:44694 ? root 172.217.16.195:443-172.20.13.34:53760 ? root 104.17.24.14:443-172.20.13.34:57900 ? root 172.20.13.34:54150-151.101.193.91:443 ? root 172.20.13.34:54140-151.101.193.91:443 ? root 172.217.16.130:443-172.20.13.34:49666 ? root 151.101.193.91:443-172.20.13.34:54136 ? root 142.250.186.138:443-172.20.13.34:53846 ? root 104.16.57.101:443-172.20.13.34:47984 ? root 172.20.13.34:51666-104.26.4.15:443 ? root 104.26.4.15:443-172.20.13.34:51650 ? root 34.120.115.102:443-172.20.13.34:40004 ? root 34.120.208.123:443-172.20.13.34:46076 ? root 104.16.219.84:443-172.20.13.34:44896 ? root 142.250.184.196:443-172.20.13.34:37102 Also, normal services I can control with opensnitch, but these don't trigger prompt and go in the background. If you have a linux machine and a moment, install nethogs and see for yourself.
- LinuxBender 3y ago
  There are many directions one could go with this but as a starting point: Are these hidden in lsof -n, ss -emoainp and in /proc/net/tcp ? Are you able to see the associated inodes in ss or lsof? If you boot up on a live / diskless / ram-only / rescue ISO do you see the same things? I would also suggest downloading the ISO and creating the thumb drive on a different machine if that is an option and don't insert thumb drive into suspect machine until it is powered off. Some distributions have a package command that can validate signatures and checksums of all the binaries. Mount the suspect disk read-only and chroot to it to run this command and save output to ram. Dont validate packages from the live running suspect image as GPG keys can be inserted by an attacker. [1] may be a starting point Before you nuke whatever is doing this, can you capture the output of this to a thumb drive assuming tcpdump is not patched? I'm 30% into my first coffee so please forgive me if I miss something obvious. Don't have any applications open when capturing this. Close the browser. # cooked (all) interfaces, no resolution, epoch, verbose, full packet, 4000 packets, write to shared mem tcpdump -i any -NNnnttvv -s0 -c4000 -w /dev/shm/cap.cap cp /dev/shm/cap.cap /wherever/you/mounted/thumbdrive/ It may be worth validating the path of tcpdump and saving all your current live variables and saving that to a thumb drive. Use objdump -p on any suspect binaries. env > /dev/shm/env.txt # esp look for any LD_ anything which -a tcpdump objdump -p $(which tcpdump) > /dev/shm/tcpdump_objdump.txt Most important probably would be to sanitize anything sensitive prior to sharing with anyone on the internet via a paste site or github or whatever is easiest. Feel free to push files into sftp share@ohblog.net in /pub/ (no pw) [1] - https://help.ubuntu.com/community/SecureApt https://help.ubuntu.com/community/SecureApt [should apply to mint, I think]
  - LinuxBender 3y ago
    Adding to this, the IP's mentioned are mostly Youtube, OpenStreetMap and maybe Netflix. 1e100 can be in front of user contributed content for repositories but it would help to see what inodes are opening that connection. Malware is often boot-strapped on public repositories these days. 102.115.120.34.bc.googleusercontent.com. 123.208.120.34.bc.googleusercontent.com. 141.128-27.179.104.184.in-addr.arpa. fra15s46-in-f2.1e100.net. fra24s05-in-f2.1e100.net. fra24s06-in-f8.1e100.net. fra24s07-in-f10.1e100.net. fra24s11-in-f4.1e100.net. spike-08.openstreetmap.org. zrh04s06-in-f130.1e100.net. The only two not entirely clear are the googleusercontent unless that is just Youtube. Only 1 IP is in a blocklist. voipbl.netset:34.120.208.123
- elesiuta 3y ago
  Could you try picosnitch? (disclaimer, I'm the author of it) It should be able to get the executable (and the hash of it) or at least give you a little more information. Of those I only see 151.101.193.91 which was used for nominatim.gnome.org and dl.flathub.org, with the executables /usr/libexec/gsd-datetime, /usr/bin/io.elementary.appcenter, and /usr/bin/flatpak. With nethogs running for a few minutes I saw: ? root 192.168.2.10:42650-13.225.195.73:80 which I was able to see in picosnitch as /usr/sbin/NetworkManager connecting to 204.pop-os.org. If there really was a boot or rootkit, you probably wouldn't see any trace of it at all in picosnitch, opensnitch, or nethogs, since it could be hiding at a lower level than whatever anything running on your system can detect, and would therefore need an external firewall.

by dchest 3y ago

WTHISGO 3y ago

No, normal entries state PID and binary path like so: 1128 root /usr/sbin/NetworkManager But these I'm concerned about look like below, no PID, no binary, just ip pairs. Here you can see various ips making connection to my machine in this very moment: ? root 184.104.179.141:443-172.20.13.34:35542 ? root 104.18.21.226:80-172.20.13.34:39954 ? root 142.250.186.66:443-172.20.13.34:46432 ? root 142.250.186.104:443-172.20.13.34:44694 ? root 172.217.16.195:443-172.20.13.34:53760 ? root 104.17.24.14:443-172.20.13.34:57900 ? root 172.20.13.34:54150-151.101.193.91:443 ? root 172.20.13.34:54140-151.101.193.91:443 ? root 172.217.16.130:443-172.20.13.34:49666 ? root 151.101.193.91:443-172.20.13.34:54136 ? root 142.250.186.138:443-172.20.13.34:53846 ? root 104.16.57.101:443-172.20.13.34:47984 ? root 172.20.13.34:51666-104.26.4.15:443 ? root 104.26.4.15:443-172.20.13.34:51650 ? root 34.120.115.102:443-172.20.13.34:40004 ? root 34.120.208.123:443-172.20.13.34:46076 ? root 104.16.219.84:443-172.20.13.34:44896 ? root 142.250.184.196:443-172.20.13.34:37102 Also, normal services I can control with opensnitch, but these don't trigger prompt and go in the background. If you have a linux machine and a moment, install nethogs and see for yourself.

LinuxBender 3y ago
There are many directions one could go with this but as a starting point: Are these hidden in lsof -n, ss -emoainp and in /proc/net/tcp ? Are you able to see the associated inodes in ss or lsof? If you boot up on a live / diskless / ram-only / rescue ISO do you see the same things? I would also suggest downloading the ISO and creating the thumb drive on a different machine if that is an option and don't insert thumb drive into suspect machine until it is powered off. Some distributions have a package command that can validate signatures and checksums of all the binaries. Mount the suspect disk read-only and chroot to it to run this command and save output to ram. Dont validate packages from the live running suspect image as GPG keys can be inserted by an attacker. [1] may be a starting point Before you nuke whatever is doing this, can you capture the output of this to a thumb drive assuming tcpdump is not patched? I'm 30% into my first coffee so please forgive me if I miss something obvious. Don't have any applications open when capturing this. Close the browser. # cooked (all) interfaces, no resolution, epoch, verbose, full packet, 4000 packets, write to shared mem tcpdump -i any -NNnnttvv -s0 -c4000 -w /dev/shm/cap.cap cp /dev/shm/cap.cap /wherever/you/mounted/thumbdrive/ It may be worth validating the path of tcpdump and saving all your current live variables and saving that to a thumb drive. Use objdump -p on any suspect binaries. env > /dev/shm/env.txt # esp look for any LD_ anything which -a tcpdump objdump -p $(which tcpdump) > /dev/shm/tcpdump_objdump.txt Most important probably would be to sanitize anything sensitive prior to sharing with anyone on the internet via a paste site or github or whatever is easiest. Feel free to push files into sftp share@ohblog.net in /pub/ (no pw) [1] - https://help.ubuntu.com/community/SecureApt https://help.ubuntu.com/community/SecureApt [should apply to mint, I think]
- LinuxBender 3y ago
  Adding to this, the IP's mentioned are mostly Youtube, OpenStreetMap and maybe Netflix. 1e100 can be in front of user contributed content for repositories but it would help to see what inodes are opening that connection. Malware is often boot-strapped on public repositories these days. 102.115.120.34.bc.googleusercontent.com. 123.208.120.34.bc.googleusercontent.com. 141.128-27.179.104.184.in-addr.arpa. fra15s46-in-f2.1e100.net. fra24s05-in-f2.1e100.net. fra24s06-in-f8.1e100.net. fra24s07-in-f10.1e100.net. fra24s11-in-f4.1e100.net. spike-08.openstreetmap.org. zrh04s06-in-f130.1e100.net. The only two not entirely clear are the googleusercontent unless that is just Youtube. Only 1 IP is in a blocklist. voipbl.netset:34.120.208.123
elesiuta 3y ago
Could you try picosnitch? (disclaimer, I'm the author of it) It should be able to get the executable (and the hash of it) or at least give you a little more information. Of those I only see 151.101.193.91 which was used for nominatim.gnome.org and dl.flathub.org, with the executables /usr/libexec/gsd-datetime, /usr/bin/io.elementary.appcenter, and /usr/bin/flatpak. With nethogs running for a few minutes I saw: ? root 192.168.2.10:42650-13.225.195.73:80 which I was able to see in picosnitch as /usr/sbin/NetworkManager connecting to 204.pop-os.org. If there really was a boot or rootkit, you probably wouldn't see any trace of it at all in picosnitch, opensnitch, or nethogs, since it could be hiding at a lower level than whatever anything running on your system can detect, and would therefore need an external firewall.