What is this about? Compromised system / intrusion?

Hello everyone,

on a freshly installed openSUSE 42.2 system I get this strange output from “netstat -tulp”:


Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name   
tcp        0      0 localhost:ipp           *:*                     LISTEN      1373/cupsd          
tcp        0      0 localhost:smtp          *:*                     LISTEN      1509/master         
tcp        0      0 *:xmsg                  *:*                     LISTEN      1731/kdeconnectd    
udp        0      0 *:bootpc                *:*                                 928/wickedd-dhcp4   
udp        0      0 *:xmsg                  *:*                                 1731/kdeconnectd    
udp        0      0 *:mdns                  *:*                                 822/avahi-daemon: r 
udp        0      0 *:38806                 *:*                                 822/avahi-daemon: r 

Now I really wonder what this “xmsg” might be about. According to http://www.speedguide.net/port.php?port=1716 it is assigned to “America’s Army Massively multiplayer online role-playing game (MMORPG) (unofficial)” (needless to say that I didn’t install this game, I never even heard about it), which doesn’t sound very legitimate to me. It uses port 1716 (TCP and UDP), but “nc -l 1716” gives “Address already in use” as its output.

It belongs to the process with PID 1731 (kdeconnectd), so I first used “pstree -ap” to find out more about this process, which gave me the following result:

  │   ├─file.so,3552
  │   ├─kdeconnectd,1731 -session 10117108a5ed000148857986700000017710000_1488585928_992025
  │   │   ├─{QDBusConnection},1740
  │   │   ├─{QXcbEventReader},1737
  │   │   └─{Qt bearer threa},1741

Then I checked the environment for this process:

 1731 ?        Sl     0:00 /usr/lib64/libexec/kdeconnectd -session 10117108a5ed000148857986700000017710000_1488585928_992025 XDG_VTNR=7 LESSKEY=/etc/lesskey.bin MANPATH=/usr/local/man:/usr/share/man NNTPSERVER=news XDG_SESSION_ID=2 HOSTNAME=linux-7x3r XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB TERM=xterm SHELL=/bin/bash HOST=linux-7x3r HISTSIZE=1000 PROFILEREAD=true GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/suseuser/.gtkrc-2.0:/home/suseuser/.config/gtkrc-2.0 GS_LIB=/home/suseuser/.fonts MORE=-sl XSESSION_IS_UP=yes GTK_MODULES=canberra-gtk-module KDE_FULL_SESSION=true XDG_SESSION_CLASS=user USER=suseuser JRE_HOME=/usr/lib64/jvm/jre XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1 XNLSPATH=/usr/share/X11/nls QT_AUTO_SCREEN_SCALE_FACTOR=0 XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 HOSTTYPE=x86_64 QEMU_AUDIO_DRV=pa FROM_HEADER= CONFIG_SITE=/usr/share/site/x86_64-unknown-linux-gnu PAGER=less CSHEDIT=emacs XDG_CONFIG_DIRS=/etc/xdg MINICOM=-c on DESKTOP_SESSION=/usr/share/xsessions/plasma5 PATH=/home/suseuser/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games MAIL=/var/spool/mail/suseuser CPU=x86_64 QT_IM_MODULE=xim JAVA_BINDIR=/usr/lib64/jvm/jre/bin PWD=/home/suseuser XDG_SESSION_TYPE=x11 INPUTRC=/home/suseuser/.inputrc XMODIFIERS=@im=local JAVA_HOME=/usr/lib64/jvm/jre KDE_SESSION_UID=1000 LANG=de_DE.UTF-8 PYTHONSTARTUP=/etc/pythonstart SSH_ASKPASS=/usr/lib/ssh/ksshaskpass AUDIODRIVER=pulseaudio GPG_TTY=kein Terminal SHLVL=1 XDG_SEAT=seat0 HOME=/home/suseuser QT_SYSTEM_DIR=/usr/share/desktop-data KDE_SESSION_VERSION=5 OSTYPE=linux LESS_ADVANCED_PREPROCESSOR=no SDL_AUDIODRIVER=pulse ALSA_CONFIG_PATH=/etc/alsa-pulse.conf XCURSOR_THEME=breeze_cursors WINDOWMANAGER=/usr/bin/startkde LOGNAME=suseuser XDG_SESSION_DESKTOP=KDE MACHTYPE=x86_64-suse-linux LESS=-M -I -R G_FILENAME_ENCODING=@locale,UTF-8,ISO-8859-15,CP1252 XDG_DATA_DIRS=/usr/share DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-9Zh5lcABNi,guid=7f5f06ecaf5a81a482c4933e58c9efa4 LESSOPEN=lessopen.sh %s DISPLAY=:0 XDG_RUNTIME_DIR=/run/user/1000 GTK_IM_MODULE=cedilla XAUTHLOCALHOSTNAME=linux-7x3r XDG_CURRENT_DESKTOP=KDE LESSCLOSE=lessclose.sh %s %s QT_IM_SWITCHER=imsw-multi G_BROKEN_FILENAMES=1 XAUTHORITY=/tmp/xauth-1000-_0 COLORTERM=1 JAVA_ROOT=/usr/lib64/jvm/jre _=/usr/lib64/libexec/kf5/start_kdeinit_wrapper KDE_MULTIHEAD=false GTK_RC_FILES=/etc/gtk/gtkrc:/home/suseuser/.gtkrc:/home/suseuser/.config/gtkrc SESSION_MANAGER=local/linux-7x3r:@/tmp/.ICE-unix/1714,unix/linux-7x3r:/tmp/.ICE-unix/1714

And then I checked which file handles are being used by it:
I didn’t notice much suspicious there, except maybe these entries:

kdeconnec 1731 suseuser  mem       REG               0,20   217032    15900 /run/nscd/passwd
kdeconnec 1731 suseuser    3u     unix 0xffff8802fc6e9c00      0t0    21090 type=STREAM
kdeconnec 1731 suseuser    4u  a_inode               0,11        0     8172 [eventfd]
kdeconnec 1731 suseuser    5u  a_inode               0,11        0     8172 [eventfd]
kdeconnec 1731 suseuser    6u     unix 0xffff8803114c5c00      0t0    21091 type=STREAM
kdeconnec 1731 suseuser    7u  a_inode               0,11        0     8172 [eventfd]
kdeconnec 1731 suseuser    8u     unix 0xffff8802fd297800      0t0    21094 type=STREAM
kdeconnec 1731 suseuser    9u  a_inode               0,11        0     8172 [eventfd]
kdeconnec 1731 suseuser   10u     unix 0xffff8800d7dda800      0t0    19092 type=STREAM
kdeconnec 1731 suseuser   11u     IPv4              22129      0t0      UDP *:xmsg
kdeconnec 1731 suseuser   12u     IPv4              22131      0t0      TCP *:xmsg (LISTEN)

The files in /run/nscd are all binary format, but some stuff is readable, so I’ve created a .tar archive from the directory and uploaded it on my GoogleDrive, where anyone can download it from:

When I searched for “/run/nscd” and “xmsg”, Google returned only three results, one of these being this site, which I don’t really know what it’s about, but it gives me a very ‘obscure’ impression:

What do other people think about this? Did anyone ever get this netstat output on a freshly installed system? What is the relationship between kdeconnectd (a normal program) and this strange protocol?

And does anyone have an idea how I could proceed to find out more about this?

Thanks in advance and kind regards

It’s not xmsg the protocol, it’s just the port (1716) and it’s being mapped to that name from /etc/services by netstat. You should use -n in netstat so it’ll report the port number and not the mapped name.

It just happens to be that kdeconnect uses that port for communication - and a few others as well if needed, ranging from 1714 to 1764 (defined in the source code as min port and max port).

So what you’re seeing is quite normal and nothing to worry about.

Exactly; add the ‘n’ (numeric) option to your netstat/ss commands in order
to just get the actual port without silly mappings to possibly-obsolete names.

Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

Thanks to both of you for these precise and helpful replies!

I could imagine that I’m not the only one who would feel confuse when seeing this odd “xmsg” entry in his netstat output…

I tried using tcpdump when no application using internet access was active (I also uninstalled NTP support for this reason), since I was curious which results would appear then (I used it together with the “-vvv” switch). Here are some excerpts from this output:

01:02:53.018777 IP6 (hlim 1, next-header Options (0) payload length: 32) fe80::62e3:27ff:febd:c4d2 > ipv6-allnodes: HBH (rtalert: 0x0000) (pad1)(pad1) [icmp6 sum ok] ICMP6, multicast listener querymax resp delay: 10000 addr: ::
01:02:53.021232 IP (tos 0x0, ttl 64, id 7062, offset 0, flags [DF], proto UDP (17), length 68)
    linux-7x3r.lan.41661 > OpenWrt.lan.domain: [udp sum ok] 52929+ PTR? (40)
01:02:53.031972 IP (tos 0x0, ttl 64, id 41601, offset 0, flags [DF], proto UDP (17), length 103)
    OpenWrt.lan.domain > linux-7x3r.lan.41661: [udp sum ok] 52929 q: PTR? 1/0/0 [4h59m8s] PTR all-systems.mcast.net. (75)
01:02:53.032529 IP (tos 0x0, ttl 64, id 7063, offset 0, flags [DF], proto UDP (17), length 66)
    linux-7x3r.lan.47348 > OpenWrt.lan.domain: [udp sum ok] 10218+ PTR? (38)
01:02:53.043277 IP (tos 0x0, ttl 64, id 41602, offset 0, flags [DF], proto UDP (17), length 134)
    OpenWrt.lan.domain > linux-7x3r.lan.47348: [udp sum ok] 10218 NXDomain q: PTR? 0/1/0 ns: in-addr.arpa. [4m17s] SOA b.in-addr-servers.arpa. nstld.iana.org. 2016111065 1800 900 604800 3600 (106)
01:02:53.144369 IP (tos 0x0, ttl 255, id 19025, offset 0, flags [DF], proto UDP (17), length 118)
    linux-7x3r.lan.mdns > [udp sum ok] 0 PTR (QM)? 2.d.4.c.d.b.e.f.f.f.7.2.3.e. (90)
01:02:54.145549 IP (tos 0x0, ttl 255, id 19191, offset 0, flags [DF], proto UDP (17), length 118)
    linux-7x3r.lan.mdns > [udp sum ok] 0 PTR (QM)? 2.d.4.c.d.b.e.f.f.f.7.2.3.e. (90)
01:02:56.147839 IP (tos 0x0, ttl 255, id 19383, offset 0, flags [DF], proto UDP (17), length 118)
    linux-7x3r.lan.mdns > [udp sum ok] 0 PTR (QM)? 2.d.4.c.d.b.e.f.f.f.7.2.3.e. (90) is a multicast address (though I thoght that it would be only used by Apple devices, and there is no Apple device in my network), so this is legitimate I gues. I don’t mean to suspect this being an intrusion, but I’m just curious: What is this sequence “0 PTR (QM)? 2.d.4.c.d.b.e.f.f.f.7.2.3.e. (90)” about?

However, I was wondering about this output:

01:02:58.060038 IP (tos 0x0, ttl 64, id 41978, offset 0, flags [DF], proto UDP (17), length 127)
    OpenWrt.lan.domain > linux-7x3r.lan.41087: [udp sum ok] 53565 NXDomain q: PTR? 0/1/0 ns: 224.in-addr.arpa. [1m7s] SOA sns.dns.icann.org. noc.dns.icann.org. 2016110923 7200 3600 604800 3600 (99)
01:03:03.048636 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has linux-7x3r.lan tell OpenWrt.lan, length 46
01:03:03.048642 ARP, Ethernet (len 6), IPv4 (len 4), Reply linux-7x3r.lan is-at 4c:cc:6a:00:1c:5d (oui Unknown), length 28
01:03:13.048453 IP (tos 0x0, ttl 64, id 11465, offset 0, flags [DF], proto UDP (17), length 70)
    linux-7x3r.lan.32940 > OpenWrt.lan.domain: [udp sum ok] 5552+ PTR? (42)
01:03:13.049051 IP (tos 0x0, ttl 64, id 42148, offset 0, flags [DF], proto UDP (17), length 95)
    OpenWrt.lan.domain > linux-7x3r.lan.32940: [udp sum ok] 5552* q: PTR? 1/0/0 [0s] PTR OpenWrt.lan. (67)

Why is “NxDomain” being sent within this data transfer? I know that there is a relationship between NXDOMAIN and DNS Hijacking, that’s why this made me feel a bit suspicious.

And what is this sequence “2016110923 7200 3600 604800 3600 (99)” about?

Kind regards and thanks in advance

It’s Multicast DNS used by services such as Avahi ( https://en.wikipedia.org/wiki/Multicast_DNS ).

You’re overthinking things, there are no “hidden services” on a 42.2 install, all the traffic you’re seeing is related to normal services that are required in a variety of different setups - for example to provide access to mDNS services (possibly devices such as printers, other computers, random peripherals such as Kodi boxes, TVs, etc.)

Note: Uninstalling NTP is a bad idea since some computers tend to have horrible real time clocks that drift a lot.

Just relax and have fun.