Can someone help me identify TCP port 16360?

General
1

I found TCP port 16360 open during a network scan and I’m not sure what service or app is using it. I need help figuring out whether it’s legitimate, why it opened, and if it could be a security risk.

2

Port 16360 is not a well-known standard TCP service. It is not one of the common IANA ports tied to a major app. So the scan result by itself does not tell you much. You need to identify the process on the host.

Start on the machine with the open port.

Windows:
netstat -ano | findstr :16360
Then match the PID:
tasklist /fi ‘PID eq ’

PowerShell:
Get-NetTCPConnection -LocalPort 16360 | Select LocalAddress,LocalPort,State,OwningProcess
Get-Process -Id

Linux:
ss -ltnp | grep 16360
or
lsof -i TCP:16360 -n -P

If it is a container host:
docker ps
docker port
sudo ss -ltnp | grep 16360

If you want the scanner side to give hints:
nmap -sV -p 16360
nmap -sV --script banner -p 16360

What to check next:

  1. Process name and full path.
  2. Service name tied to the PID.
  3. When it started.
  4. Whether it listens on 0.0.0.0 or only 127.0.0.1.
  5. Which firewall rule allows it.
  6. Whether it appeared after a software install or update.

Risk depends on what owns it.
Low risk if:

  • it belongs to software you installed
  • it only listens on localhost
  • auth is required
  • the version is current

Higher risk if:

  • unknown exe from AppData, Temp, /tmp, or a weird path
  • listening on all interfaces
  • no business reason for the service
  • old app with known CVEs
  • strange outbound traffic tied to the same process

Quick examples:

  • Remote support tools and game servers often use odd high ports.
  • Java apps, Node apps, and vendor agents often pick ports in this range.
  • Malware also likes high ports becuase they blend in.

If you post the OS, the output of netstat or ss, and the process name, people can narrow it down fast. Right now, port 16360 alone is not enough to ID the app.

3

Port 16360 by itself is basically just “some app picked a high port.” It’s not a famous service port, so I’d be careful about anyone trying to ID it from the number alone.

One place I kinda differ from @yozora: an open port is not automaticaly suspicious just because it’s weird or high-numbered. Tons of totally normal software does this, especially vendor agents, Java stuff, launchers, remote admin tools, backup clients, and anything containerized.

What I’d look at beyond process/PID is this:

  • Is it stable, or only open sometimes?
    • If it appears only while an app is running, it may just be an ephemeral listener or local service component.
  • Is there actual response data?
    • Try connecting with telnet <host> 16360 or nc -v <host> 16360
    • Sometimes the banner gives it away
  • Is it internal only?
    • If only reachable from your LAN and blocked at the edge firewall, risk is way lower
  • Check startup/persistence
    • Windows Services, Task Scheduler, Run keys
    • Linux systemd unit, init scripts, cron, container restart policies
  • Look in app logs
    • A lot of services log “listening on port 16360” if you grep for 16360

Big red flags:

  • unsigned binary
  • parent process makes no sense
  • recent install you can’t explain
  • service account with high privileges
  • port exposed to internet
  • no TLS/auth on something admin-related

If you have EDR/Sysmon/auditd, check what created the listener and when. That usually solves it faster than staring at port lists tbh.

4

I’d treat 16360 as a clue, not an identity. @yozora is right that the number alone does not tell you much, but I’d push one step further: if the socket is bound to 0.0.0.0 or ::, that matters more than whether the port is “known.”

A few checks that add signal fast:

  • Fingerprint the listener:
    • nmap -sV -p 16360 <host>
    • curl -v telnet://<host>:16360
    • openssl s_client -connect <host>:16360 if it smells like TLS
  • See bind scope:
    • local only 127.0.0.1 is usually low risk
    • all interfaces is worth attention
  • Inspect ownership deeply:
    • Linux: ss -ltnp, then readlink -f /proc/<pid>/exe
    • Windows: Get-Process -Id <PID> | Select Path,Company,StartTime
  • Check whether it is container/NAT related:
    • Docker and Kubernetes often publish odd high ports
  • Capture one handshake with tcpdump/Wireshark

Pros for the ': can improve readability if you are documenting findings.
Cons for the ': not useful unless you already know what process owns the port.

Risk is mainly about exposure, auth, and process legitimacy, not the number 16360 itself.