How to identify suspicious network activity and protect your machine

Learn practical steps to analyse active connections, recognise malware behaviour, and distinguish legitimate background activity from potential threats on Windows, Linux, and macOS systems.

Many people notice the same pattern: the network light flickers even when nothing is open, the antivirus stays quiet, and an unfamiliar process appears in the task manager. The useful first step is not panic, but attribution: identify which process is making which connection, then decide whether that behaviour matches what the machine is supposed to be doing. On Linux and macOS, ss or lsof can show live sockets; on Windows, netstat -bano from an elevated command prompt, or the Network tab in Resource Monitor, gives a similar view. Documentation on netstat also notes that the tool exposes active connections, listening ports and process identifiers, which makes it a practical starting point for this kind of check.

The key detail is the link between a socket and the programme behind it. A list of ports alone is not enough; the process name and PID are what let you decide whether the traffic belongs to a browser, a messenger, a cloud-sync client or something less familiar. In the Linux example, ss -tunp state established surfaces the protocol, local address, remote address and the owning process in one line. lsof -i -n -P | grep ESTABLISHED provides a comparable view if you prefer lsof. That is why the first practical question is simple: do you recognise the process name, and does its network use make sense?

If the remote address looks odd, the next step is to identify where it belongs. Reverse DNS and WHOIS lookups can show the organisation or network name behind an IP address, but that alone rarely proves anything. Large cloud providers host ordinary consumer services, corporate agents and, at times, systems that users would rather not see. The address may therefore look suspicious while still being entirely routine. In practice, the domain name requested before the connection is often more informative than the IP address itself.

That is why DNS evidence matters. A connection is usually preceded by a name lookup, and tools such as tshark can show queried domains on an unencrypted DNS stream. When DNS is encrypted, the same visibility may have to come from the resolver’s logs or the router’s statistics, if it keeps them. Domain names are easier for humans to interpret than numerical addresses, and they often reveal the real purpose of the traffic at once: update checks, telemetry, synchronisation or in-app analytics.

Not every unexpected connection is a threat. Background network activity while a machine sits idle is normal, because modern software checks for updates, keeps sessions alive and synchronises data in the background. Multiple simultaneous connections to the same cloud service are also common, as are connections made by applications that are not obviously network tools. A text editor may check for updates, an image viewer may fetch previews and an office suite may reach out for fonts or account data. These observations are consistent with the broader advice in network-diagnostic guides, which treat active connections and listening ports as normal diagnostic output rather than proof of compromise.

The more useful warning signs are structural. A process that does not appear in the installed-programme list, but has a name that imitates a system component with a small spelling change, deserves attention. So does a binary launched from an unusual path, which can be checked directly through /proc/.../exe on Linux. Persistent traffic to a non-standard port, or a connection that appears at fixed intervals around the clock, may indicate an updater, an enterprise agent or a command-and-control beacon. Sudden bursts of activity overnight, when nothing legitimate should be running, are also worth investigating. The point is not to assume malice, but to narrow the field until the behaviour is explained.

What this method does not do is equally important. It captures a moment in time, so a programme that connects only once an hour may never appear in a short scan. It does not decrypt traffic, and it does not replace malware analysis. A sufficiently careful threat can hide inside a browser extension, where all the outbound traffic still looks like ordinary browser activity. If the process remains unexplained, the next sensible steps are to inspect its file path, check its hash against public reputation services and remove it through the operating system’s normal uninstallation path rather than by killing the process alone. That keeps the investigation focused on evidence rather than instinct.