Port 2707 Hacked by bigfoot trojan or legitimate used by emcsymapiport?

I did a nmap scan on my server and I saw that (to me unknown) port 2707 was filtered and which was said to be used by emcsymapiport (which seems to be a Dell product?). Furthermore this port is also used by the bigfoot trojan.

But I did not install emcsymapiport myself consciously and my server has nothing to do with Dell at all. I installed however vboxwebservice and remotebox in order to be able to easily setup virtual machines so maybe emcsymapiport was part of one of those installations.

The thing is that, as far as I know, emc symapi port does not run on Freebsd and also is not shown in freshports.

So now I am wondering whether I was hacked by the bigfoot trojan, disguised as emcsymapiport? Which however is also strange because I have set up my server in a testlab environment on my LAN only and which is not connected to the internet.

Except ofcourse when I install something on my server, so could either bigfoot or emcsymapiport have been piggybacked with some software installation?

Anybody any idea?
 
sockstat
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
maarten sshd 1121 3 tcp4 192.168.100.200:22 192.168.100.30:35550
maarten sshd 1121 4 stream -> ??
root sshd 1119 3 tcp4 192.168.100.200:22 192.168.100.30:35550
root sshd 1119 5 stream -> ??
root cron 1025 5 dgram -> /var/run/logpriv
smmsp sendmail 1021 3 dgram -> /var/run/log
root sendmail 1018 3 tcp4 127.0.0.1:25 *:*
root sendmail 1018 4 dgram -> /var/run/logpriv
root sshd 1015 3 tcp6 *:22 *:*
root sshd 1015 4 tcp4 *:22 *:*
vbox VBoxSVC 1003 6 stream -> /tmp/.vbox-vbox-ipc/ipcd
vbox VBoxXPCOMI 988 4 stream /tmp/.vbox-vbox-ipc/ipcd
vbox VBoxXPCOMI 988 5 stream /tmp/.vbox-vbox-ipc/ipcd
vbox VBoxXPCOMI 988 6 stream /tmp/.vbox-vbox-ipc/ipcd
vbox vboxwebsrv 975 6 stream -> /tmp/.vbox-vbox-ipc/ipcd
vbox vboxwebsrv 975 9 tcp4 192.168.100.200:?????? *:*
root syslogd 800 4 dgram /var/run/log
root syslogd 800 5 dgram /var/run/logpriv
root syslogd 800 6 udp6 *:514 *:*
root syslogd 800 7 udp4 *:514 *:*
root devd 696 4 stream /var/run/devd.pipe
root devd 696 5 seqpac /var/run/devd.seqpacket.pipe
root devd 696 7 dgram -> /var/run/logpriv
 
ps aux
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
root 11 1200.0 0.0 0 192 - RL 12:13 1335:34.68 [idle]
root 0 0.0 0.0 0 13856 - DLs 12:13 0:01.68 [kernel]
root 1 0.0 0.0 5408 616 - ILs 12:13 0:00.04 /sbin/init --
root 2 0.0 0.0 0 16 - DL 12:13 0:00.00 [crypto]
root 3 0.0 0.0 0 16 - DL 12:13 0:00.00 [crypto returns]
root 4 0.0 0.0 0 64 - DL 12:13 0:00.00 [cam]
root 5 0.0 0.0 0 256 - DL 12:13 0:00.78 [zfskern]
root 6 0.0 0.0 0 16 - DL 12:13 0:00.00 [soaiod1]
root 7 0.0 0.0 0 16 - DL 12:13 0:00.00 [soaiod2]
root 8 0.0 0.0 0 16 - DL 12:13 0:00.00 [soaiod3]
root 9 0.0 0.0 0 16 - DL 12:13 0:00.00 [soaiod4]
root 10 0.0 0.0 0 16 - DL 12:13 0:00.00 [audit]
root 12 0.0 0.0 0 1184 - WL 12:13 0:11.53 [intr]
root 13 0.0 0.0 0 48 - DL 12:13 0:00.01 [geom]
root 14 0.0 0.0 0 80 - DL 12:13 0:00.27 [usb]
root 15 0.0 0.0 0 16 - DL 12:13 0:00.00 [Timer]
root 16 0.0 0.0 0 16 - DL 12:13 0:00.00 [Timer]
root 17 0.0 0.0 0 16 - DL 12:13 0:00.00 [sctp_iterator]
root 18 0.0 0.0 0 16 - DL 12:13 0:01.05 [rand_harvestq]
root 19 0.0 0.0 0 16 - DL 12:13 0:00.00 [enc_daemon0]
root 20 0.0 0.0 0 48 - DL 12:13 0:00.08 [pagedaemon]
root 21 0.0 0.0 0 16 - DL 12:13 0:00.00 [vmdaemon]
root 22 0.0 0.0 0 16 - DL 12:13 0:00.00 [pagezero]
root 23 0.0 0.0 0 16 - DL 12:13 0:00.02 [bufspacedaemon]
root 24 0.0 0.0 0 16 - DL 12:13 0:00.02 [bufdaemon]
root 25 0.0 0.0 0 16 - DL 12:13 0:00.02 [vnlru]
root 26 0.0 0.0 0 16 - DL 12:13 0:00.05 [syncer]
root 137 0.0 0.0 8320 1296 - Is 12:13 0:00.00 adjkerntz -i
root 632 0.0 0.0 10624 1768 - Is 12:13 0:00.00 dhclient: igb0 [priv] (dhclient)
_dhcp 678 0.0 0.0 10624 1888 - Is 12:13 0:00.00 dhclient: igb0 (dhclient)
root 683 0.0 0.0 12716 1528 - Ss 12:13 0:00.00 /usr/sbin/moused -p /dev/ums0 -t auto -I /var/run/moused.ums0.pid
root 696 0.0 0.0 9560 4780 - Ss 12:13 0:00.00 /sbin/devd
root 745 0.0 0.0 0 192 - DL 12:13 0:00.00 [ng_queue]
root 800 0.0 0.0 10500 1900 - Is 12:13 0:00.02 /usr/sbin/syslogd -s
root 952 0.0 0.0 10464 1564 - Ss 12:13 0:00.65 /usr/sbin/powerd
root 974 0.0 0.0 10468 1560 - Ss 12:13 0:00.00 daemon: /usr/local/lib/virtualbox/vboxwebsrv[975] (daemon)
vbox 975 0.0 0.0 134756 12732 - S 12:13 0:00.36 /usr/local/lib/virtualbox/vboxwebsrv -H 192.168.100.200 -t0 -F /home/vbox
vbox 988 0.0 0.0 84008 7920 - S 12:13 0:00.13 /usr/local/lib/virtualbox/VBoxXPCOMIPCD
vbox 1003 0.0 0.0 123644 11264 - S 12:13 0:00.79 /usr/local/lib/virtualbox/VBoxSVC --auto-shutdown
root 1015 0.0 0.0 57812 4736 - Is 12:13 0:00.00 /usr/sbin/sshd
root 1018 0.0 0.0 20636 4588 - Ss 12:13 0:00.06 sendmail: accepting connections (sendmail)
smmsp 1021 0.0 0.0 20636 4316 - Is 12:13 0:00.00 sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue (sendmail)
root 1025 0.0 0.0 12592 1952 - Is 12:13 0:00.02 /usr/sbin/cron -s
root 1119 0.0 0.0 85228 5668 - Is 12:28 0:00.03 sshd: maarten [priv] (sshd)
maarten 1121 0.0 0.0 85228 5768 - S 12:28 0:00.17 sshd: maarten@pts/0 (sshd)
root 1085 0.0 0.0 10484 1680 v0 Is+ 12:13 0:00.00 /usr/libexec/getty Pc ttyv0
root 1086 0.0 0.0 10484 1680 v1 Is+ 12:13 0:00.00 /usr/libexec/getty Pc ttyv1
root 1087 0.0 0.0 10484 1680 v2 Is+ 12:13 0:00.00 /usr/libexec/getty Pc ttyv2
root 1088 0.0 0.0 10484 1680 v3 Is+ 12:13 0:00.00 /usr/libexec/getty Pc ttyv3
root 1089 0.0 0.0 10484 1680 v4 Is+ 12:13 0:00.00 /usr/libexec/getty Pc ttyv4
root 1090 0.0 0.0 10484 1680 v5 Is+ 12:13 0:00.00 /usr/libexec/getty Pc ttyv5
root 1091 0.0 0.0 10484 1680 v6 Is+ 12:13 0:00.00 /usr/libexec/getty Pc ttyv6
root 1092 0.0 0.0 10484 1680 v7 Is+ 12:13 0:00.00 /usr/libexec/getty Pc ttyv7
maarten 1122 0.0 0.0 13180 2360 0 Is 12:28 0:00.01 -sh (sh)
root 1123 0.0 0.0 46444 2888 0 I 12:28 0:00.02 sudo su
root 1124 0.0 0.0 43740 2336 0 I 12:28 0:00.01 su
root 1125 0.0 0.0 19660 3476 0 S 12:28 0:00.04 _su (csh)
root 1405 0.0 0.0 21208 2048 0 R+ 14:04 0:00.00 ps aux
 
then your nmap scan is showing your out of band port on the same host. Like EMC VSI for VMware vSphere that is listening on tcp/2707.
so nothing to worry about as this is a virtual machine.
 
is there any out of band remote server management enabled in the bios?


then your nmap scan is showing your out of band port on the same host. Like EMC VSI for VMware vSphere that is listening on tcp/2707.
Also there's vmdaemon

The thing is that I don't know this emc software at all, but I indeed also saw it also has something to do with virtual machines, so it would not be strange that it is there. But what I don't understand is why port 2707 is not active, though I am using remotebox right now
 
then your nmap scan is showing your out of band port on the same host. Like EMC VSI for VMware vSphere that is listening on tcp/2707.
so nothing to worry about as this is a virtual machine.

So if I understand you right, it is just a name nmap gives to this service as it expects a service like emcsymapiport on this port and it also has the same kind of functionality?
 
You can have any service running on this port.
nmap report that this port as filtered (blocked) by firewall that prevents its probes from reaching the port. There's well know ports registered by IANA which links the port number with usually expected service on that port.

https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
That is exactly why I was afraid bigfoot was using this port :(
But I also believe that you are right and that it is part of either vboxwebserv and/or remotebox and that port 2707 is not active at the moment, probably has to do with the fact that I don't use its specific function at the moment.

So thank you very much.

I will close the thread as solved now
 
You need to worry only for the "OPEN" ports. So as this port is filtered it may not be hosted on your server it's has been blocked by a firewall on the route to your server.
 
You need to worry only for the "OPEN" ports. So as this port is filtered it may not be hosted on your server it's has been blocked by a firewall on the route to your server.

Forgive me if I am wrong, but with that I don't agree. If for one or another reason bigfoot (or any other malware) was able to install itself on my system during the installation of some (legitimate and/or manipulated) software it can communicate with its "owner" from the inside out. Even when a firewall blocks all other traffic coming from the outside.
Ofcourse unless the firewall also blocks outgoing traffic.
 
If you don't see the port in your netstat / sockstats then this port has been blocked before your machine by a firewall. That's why the nmap scan is showing it as filtered because it can't determinate if there's any service on this port or not.
 
software it can communicate with its "owner" from the inside out..

This type of software will use random dynamic upper port above port 49151 and you will never had an idea of it's existents unless you are monitoring every outgoing traffic from your machine and it will be visible in the netstat.
 
If you don't see the port in your netstat / sockstats then this port has been blocked before your machine by a firewall. That's why the nmap scan is showing it as filtered because it can't determinate if there's any service on this port or not.

I was preparing my machine because I wanted to install a firewall and did a scan on all 65000 ports to check for possible open ports and the scan was done from another machine (without firewall on) in my LAN. So the traffic was not filtered by any firewall.

I believe it was filtered because of this reason: You issue a SYN, if the server does not reply, or replies with ICMP error : it means that the port is filtered. And to my opinion there was no reply because there was no active service on port 2707 at that specific moment.
 
Is the hardware that you are using have some sort of remote management like vPro, HP ILO, Dell DARC? What is your hardware?
 
No nothing at all. precisely because I dont want any "factory" remote management software on my servers. It is a simple asrock Z370 Extreme4 motherboard with an i7-8700K cpu.
 
Before, I had security/portsentry installed, and it showed false positives from running security/rkhunter with security/nmap support. rkhunter alone didn't do that, only when it was compiled with nmap did that happen. portsentry found listening on that port, which was likely by rkhunter with nmap. At first, I wasn't sure if that was the problem, but later on, I became confident that it was the issue. It's not exactly the same as your issue, but there may be similarities.

Firewall that port anyway. On mine, I went as far as compiling the base system without ssh, which isn't a solution for you, since you're using a remote computer.
 
Before, I had security/portsentry installed, and it showed false positives from running security/rkhunter with security/nmap support. rkhunter alone didn't do that, only when it was compiled with nmap did that happen. portsentry found listening on that port, which was likely by rkhunter with nmap. At first, I wasn't sure if that was the problem, but later on, I became confident that it was the issue. It's not exactly the same as your issue, but there may be similarities.

Firewall that port anyway. On mine, I went as far as compiling the base system without ssh, which isn't a solution for you, since you're using a remote computer.

I will firewall all incoming and outgoing traffic, except for the ports I know I need. So I will also block port 2707. If a legitimate application needs that port, I will know soon enough.
The thing is that, if there is something wrong with that port, it is better to reinstall the complete system right now. Not when everything is installed. And to be honest, I am still in doubt if I will do that.

What I had hoped for is that somebody here would have said: Oh don't worry it is because of this or that.
 
I would suggest against just using sockstat because that can become confusing quite fast because it basically mixes everything together which makes it easy to overlook items. Instead: sockstat -4l (assuming you're not using IPv6) is usually much easier. And to be honest I also don't necessarily agree with an out of bound port.

Have you already tried checks using, for example, security/rkhunter just to be sure here?

Also important: what FreeBSD version are you using?
 
Back
Top