Tour of the network traffic "zoo": top 10 anomalies inside your perimeter

These are technical debt and shadow IT: outdated protocols, forgotten service accounts, external DNS, non-standard ports, torrents, and other background network activity. Of course, it's good that these aren't hackers. However, this steady white noise helps threat actors conceal their actions and is sometimes dangerous on its own.

Below the cut — ten common anomalies we constantly find in network traffic. For each one, I will explain what it looks like, why it occurs, what risks it poses, and how to deal with it.

Anomaly No. 1. Logins and passwords transmitted in plaintext

One of the most unpleasant scenarios during a pilot is when NDR shows logins and passwords being transmitted over the network in plaintext.

As a rule, this is not the result of an attack, but a legacy of old integrations or "temporary" solutions. For example, LDAP simple bind without TLS, FTP, outdated HTTP in test segments, custom authorization built on top of regular TCP, or API calls without certificates. Administrators often don't have time to set up encryption, and management is in a hurry: "Let's launch it here and now, we'll polish the security later". But as we know, there is nothing more permanent than temporary.

The most common example is working via the LDAP protocol. And although customers know it can be used more securely, for example via LDAPS or StartTLS, in practice this usually comes down to certificates, regulations, and fear of breaking authorization.

Imagine this scenario: a domain controller certificate expires on Saturday, and on Monday employees come to work and authorization doesn't work. "Maybe we don't need such a complex protection system?" the customer wonders.

This is how that very "conscious" (in reality, not fully considered) risk appears. The customer's logic usually goes like this: "I have LDAP in my internal infrastructure. From the outside I'm protected by NGFW and IPS, from the inside — by NAC and 802.1x. There are no outsiders on the network, so plaintext credentials in traffic are not a problem".

This myth about an impenetrable perimeter could hold up quite well, but there are some nuances. The network has IoT devices with five-year-old firmware, printers with MAC Authentication Bypass (where verification is done only via MAC address, which is easy to spoof), contractors with laptops in meeting rooms, guest segments, and remote employees. If an attacker gains a foothold on at least one node in such a segment, they can enable listening mode on their device or use Man-in-the-Middle techniques.

The Danger

Open passwords become ready-made material for lateral movement. An attacker does not need to breach the domain using complex techniques if some passwords are already flying over the network in plaintext.

How NDR Detects the Anomaly

The system strips IP and TCP headers, parses L7 protocols, and, leveraging its knowledge of RFCs, extracts logins and passwords from traffic. A policy is configured to collect sessions with exposed credentials and organize them by host and protocol pairs. Within two weeks, the customer gains a clear understanding that almost all passwords in their infrastructure are laid out on a silver platter. This creates a pressing urge to prioritize security.

What to Do

The first step is to build a risk map: identify which host pairs transmit credentials in plaintext, what services are behind these transmissions, and which accounts are in use. Next, migrate LDAP to LDAPS or StartTLS, disable simple bind without TLS, decommission FTP, and move test HTTP services and APIs behind TLS.

It is critical not just to disable a single protocol, but to eliminate the entire class of scenarios where a password ends up as part of plaintext network payload. Service accounts should be reviewed separately, and connection sources must be restricted.

Anomaly No. 2. Forgotten Accounts and Configuration Errors

Another common finding is configuration errors and "lost" service accounts. In a large infrastructure, the number of accounts is enormous. Employees resign, and access sometimes needs to be temporarily suspended for certain individuals. Administrators can still handle user accounts relatively easily, but the vast majority of problems arise with service accounts.

Classic scenario: a new cybersecurity solution (for example, a firewall or the same NDR) is brought to the customer for a pilot run. To let the system see the infrastructure, a service account is created for integration with the domain. The pilot ends, the equipment is taken away, the project is closed, but somewhere on a virtual machine or test server, an agent, connector, or script remains that still keeps trying to reach the domain controller.

The password for the service account was changed a long time ago, or the account itself was disabled, but the forgotten agent or connector doesn't know that. It gets a rejection, waits, and tries again. This can go on for weeks.

What is the danger

The network pattern of a forgotten service looks very similar to password spraying (brute-force password attacks). As a result, the SOC receives dozens or hundreds of similar events, and a real attacker simply blends into this background.

In addition, forgotten accounts often have excessive privileges, an unclear owner, and a non-obvious lifecycle. If such an account suddenly becomes a successful entry point, investigating the incident will be difficult: no one remembers who created it and why.

How NDR detects the anomaly

If the protocol is encrypted, NDR does not always see the contents of the authentication process. But it doesn't need to: it is enough to track the frequency, direction, size of sessions, repeatability, and a stable "source — domain controller" pair. The system flags new host pairs, a sharp increase in request frequency, changes in the timing of attempts, and the appearance of previously unknown sources.

What to do

Conduct an inventory of service accounts and authentication sources. For each account, assign an owner, purpose, lifespan, allowed connection sources, and a rotation process. On the NDR side, it is important not just to alert on the fact of failed authentication, but to track behavioral anomalies. For example, new sources, activity spikes. This way, the forgotten service will remain on the technical debt list, and new activity will be easier to investigate.

Anomaly #3. External DNS

Shadow IT usually emerges after infrastructure legacy is addressed. One of the most common examples is hosts that do not use corporate DNS servers and instead connect directly to external resolvers: 8.8.8.8, 1.1.1.1 and similar ones.

The reasons are trivial. Sometimes a port on the firewall was opened to test something and was never closed. Or IP cameras with default external DNS were deployed from a poorly managed IoT segment. The corporate firewall is supposed to catch such requests, but misconfigurations may cause it to let them through.

What is the danger

First, regular DNS requests are not encrypted. Internal service names, contractor domains, cloud system names, and environments like test, stage and prod may be sent out. From these details, part of the company's architecture can be reconstructed.

Second, DNS is a convenient channel for bypassing information security policies. Tunnels can be built over DNS, data can be transmitted in small chunks, and exfiltration can be disguised as regular requests. A sharp increase in DNS traffic, long subdomains, a large number of NXDOMAIN responses, and requests to newly registered domains are all reasons to launch an investigation.

How NDR sees this

NDR easily detects hosts sending DNS requests outside the corporate network. If it is regular DNS on port 53, the domain names themselves are visible. If DoH (DNS over HTTPS) or DoT (DNS over TLS) is used, the request contents cannot be read directly, but the very fact of bypassing the corporate resolver remains an anomaly.

What to do

Corporate information security policy should be simple: clients may only access internal resolvers, and only these resolvers are allowed to send DNS traffic outside. Exceptions must be documented, approved, and restricted by source.

In NDR, it is useful to monitor direct access to public DNS, growth in DNS traffic volume, suspiciously long names, abnormal request frequency, and the appearance of DoH/DoT in places where they should not be present.

Anomaly No. 4. Non-standard ports

Non-standard ports are a common occurrence in any infrastructure. We regularly see custom-built services that are accessible not on port 80, but for example on port 188, or SSH running on port 2022. The customer's logic is clear: if a service is moved from a standard port, it will not be found by a basic internet scanner.

From the outside, it seems that 65,535 ports is an astronomical figure, a vast space where it's easy to get lost. But this is a myth, and such protection is illusory: an attacker who has already gained a foothold in the corporate network is not limited by primitive vulnerability scanners. If they found a loophole, they don't care which port the service is running on — the main thing is that it is accessible.

What is the danger, and how NDR helps

“Hidden” services often fall outside the scope of monitoring. They are forgotten during inventory, stop being updated, and their access permissions are never checked. In this case, NDR helps distinguish legitimate noise from attacker actions: if traffic follows a known pattern of an in-house application, that is one scenario, but if a port suddenly starts being used for unusual connections, that is an alarming signal.

A situation where a completely different protocol than what the firewall expects is running on a standard allowed port is no better. If a service uses a non-standard encrypted protocol and the firewall cannot recognize it, the firewall sees “port allowed” and lets the traffic through, while the actual application logic remains uncontrolled.

What to do

DPI (Deep Packet Inspection) helps. For SSH, TLS and other encrypted connections, in addition to DPI, you can use metadata analysis, client profiles, frequency, volume, direction, and deviations from the baseline. The main thing is to ensure transparency: any non-standard port must have an owner, purpose, and description in the CMDB (Configuration Management Database) or a similar inventory system.

Anomaly #5. Crypto activity: from exchanges to miners

The most unusual finding for customers is crypto activity in the corporate network. It would seem that it is serious business, everything is legitimate, so where did mining come from? But here it is important not to mix up different things.

A crypto exchange app on a smartphone connected to guest Wi-Fi is most likely a false positive or a violation of guest network usage policy, but not an attack. Meanwhile, a printer from the office segment that communicates with mining infrastructure is a direct alarm signal.

What is the danger

At the very mildest, this is a policy violation. In more serious cases, it is a sign of compromise. For example, mining on a workstation may be a consequence of installing pirated software. A miner on a server is the result of exploiting a vulnerability. A miner on a printer, camera, or other device where a full-fledged Endpoint Detection and Response (EDR) cannot be installed is a signal that the device has been compromised.

How this appears to NDR

Problems with such devices can often only be identified via anomalous network activity. NDR cross-references network connections with threat intelligence feeds, DNS names, IP addresses, and SNI (if it is visible).

What to do

First, classify the source of suspicious traffic and analyze the risks. Next, check segmentation, outbound traffic rules, the consistency of DHCP, MAC, and IP data with each other, whether device spoofing has occurred, and access history. If cryptomining activity originates from a corporate asset, this is an incident or policy violation that must be investigated together with the device owner.

Anomaly No. 6. P2P activity and unwanted software

BitTorrent in corporate networks is also a fairly common phenomenon, and as a rule, a bad sign. Not because the P2P protocol itself is inherently malicious, but because it may be associated with pirated software, unaccounted downloads, and infected software distributions.

What is the danger

The typical scenario is as follows: an employee downloads a "needed utility", "cracked editor" or "portable version" via torrent. A loader is hidden inside, which later downloads the payload, obfuscates it, injects it into the memory of a legitimate process, or launches a chain of commands to bypass host-based protection. Antiviruses do not provide a 100% guarantee, especially if the code arrives in parts and is executed in memory. Malicious activity is first detected via network indicators.

Similar issues may arise when using Tor or remote access programs (for example, TeamViewer, AnyDesk, and similar tools), which can also be used to establish command-and-control channels and can become a vector for malware intrusion.

How this appears to NDR

NDR detects applications (BitTorrent, TeamViewer, AnyDesk, and others) using DPI and signatures, and also flags anomalies based on a large number of identical connection types and a high volume of external peers.

What to do

BitTorrent and other similar P2P protocols should be banned or strictly restricted in corporate network segments. However, it is important not to turn this into a witch hunt for users who "downloaded something". It is worth focusing on identifying hosts that, after P2P activity, have new external periodic connections, access to low-reputation domains, or atypical TLS sessions.

Anomaly No. 7. Suspicious Binaries

In almost any infrastructure, we see transfers of EXE files, DLLs, PDFs, Word or Excel documents with macros. In large networks, such transfers occur constantly: administrators distribute installers, update systems push out agents, and developers share builds.

It is critical to monitor the transfer of executable files within the network perimeter, as they may potentially carry executable code.

Why this is dangerous, and how NDR helps

Alerts should be triggered by the transfer of executable files to user segments or segments where software installation is not typically permitted. For example, transfers to printers, terminals, IoT devices, and industrial control zones (ICS, SCADA systems).

NDR is not an antivirus, so it should not determine whether a transferred file is malicious or legitimate. However, the system records the fact of the executable file transfer itself and helps reconstruct the file's movement path: where the file originated, which nodes it passed through, and where it ended up.

NDR can track transfers over HTTP, FTP, SMB, email (SMTP), or other protocols if the content is available for analysis. In the case of encryption, visibility is limited, but metadata remains: who sent what to whom, how often, in what volume, and in which direction.

What to do

Build a file transfer map between segments. Normal host pairs, update systems, file servers, and software repositories should be documented. Anything that does not fit this map needs to be checked. Segments without host-based protection require special attention.

Anomaly No. 8. Abnormal spikes in ICMP traffic

NDR always raises an alert if it detects such activity in the network

During peak load periods, the corporate DNS server would start «lagging» and respond with a 5–10 second delay. The client (terminal server) would stop waiting, close the connection, and resend the request. By the time the DNS server finally «woke up» and sent the delayed response, the client was no longer waiting for it.

The basic network standard (RFC 792) was triggered: a device that receives a packet for a closed port is required to send an error message back to the sender — ICMP Destination Unreachable. Inside this ICMP message, the client is required to pack a fragment of the original packet (that same delayed DNS response) so the server can understand which response is being referred to. This «matryoshka» (packet inside a packet) is technically a tunnel, so the NDR flagged its appearance.

What's the danger

While this situation is not an attack, it creates a lot of background noise. Analysts waste time sifting through this noise, and real suspicious ICMP activity can get lost in it.

What to do

Do not disable false positive alerts, but instead investigate the root causes of their occurrence. These alerts may not be related to information security, but they point to performance issues with DNS or other services that also need to be fixed.

Anomaly No. 9. Beaconing in network traffic

Now let's move on to something that is much closer to real attacks.

After gaining initial access, an attacker needs a command and control channel. The implant periodically contacts the C2 server to receive commands and send back results. To avoid drawing attention, it uses beacons (beaconing): short check-ins at set time intervals, sometimes with artificial «jitter» to make the traffic look less robotic.

The problem is that this type of behavior is easily disguised as regular network activity. In any infrastructure, we see periodic interactions using HTTP, DNS, and DNS over HTTPS (DoH) protocols. For example, suspicious periodic activity can come from a customer's automated system that accesses a contractor's resources via HTTPS to retrieve data.

What is the danger

While experience shows that this kind of anomaly is most often legitimate activity, turning off monitoring is unsafe. After all, if this is actually an attack, the consequences will be severe.

How NDR sees this

With unencrypted HTTP, it is easy to look at headers and determine that this is a legitimate system. It is more difficult with DNS. The most complex case is HTTPS and DoH. When the payload is encrypted, you cannot simply read the command. However, NDR accumulates statistics on connection periodicity, session duration, data volume, direction, TLS profile, and domains. We can see parameters that match exploitation tools such as Cobalt Strike, Brute Ratel, and others.

However, it is difficult to determine using only behavioral analysis whether this is an attacker's tool or a legitimate system with similar behavior.

After filtering out Microsoft Update, Chrome, Mozilla, monitoring agents, backups, and other known sources, in a network of a couple thousand hosts, it is often possible to isolate one or two machines that regularly “beacon” outwards at a suspicious frequency. Hosts that previously had no external periodic activity but then started regularly accessing a new domain or IP are especially suspicious.

What to do

First, separate known automation from unknown. Legitimate systems require precise exceptions: specific service, direction, and owner.

Here, NDR does not replace endpoint investigation, but provides a list of machines from which the investigation should be started. Then you can check the short list of hosts using endpoint tools: review process logs, autorun entries, network connections, PowerShell history, scheduled tasks, browser extensions, and proxy logs.

Anomaly #10. DGA domains

NDR also detects such things as DGA domains.

Domain Generation Algorithm (DGA) — a technique widely used by botnets and post-exploitation frameworks. The implant dynamically generates domain names using an algorithm known only to itself and the server. Today it looks for a connection at qwezxcasd.net, tomorrow at bnmpoiu.org. The attacker only needs to register one of these domains, and the implant will "guess" it.

On the surface, DGA domains look like gibberish. It seems simple: just set up an NDR rule to flag unusual domain names and you're all set. But the catch is that not all gibberish is hacker-generated DGA traffic.

Why do we see these domains all the time? Because corporate infrastructure can also have domains that are not generated by humans. For example, Citrix load balancers legally generate technical node names like lb-type-load-0-1.segment-1344.example.com. Similar patterns are produced by cloud platform segments and Kubernetes technical services.

This is legitimate internal naming. A simple regex rule to "block everything unusual" will disrupt the operation of legitimate nodes.

How NDR sees this

In Garda NDR, a specialized ML model trained on more than 10 million domain names using gradient boosting is used to detect DGA. It helps accurately separate legitimate "good" traffic from potential malware with no clear signatures, by relying on the structure of legitimate corporate suffixes.

The system uses a mathematical entropy estimation model to determine how closely the sequence of letters in a domain name resembles natural language. For example, microsoft.com has low entropy, while the generated qwezxcasd.net has high entropy. This allows us to accurately distinguish malicious domain generation from legitimate technical names (load balancers, Kubernetes, CI/CD artifacts) and reduce the number of false positives.

High entropy on its own is not a definitive red flag. But when combined with other factors, it becomes strong grounds for investigation.

What to do

Use DGA detection not as a binary rule, but as one of the factors in the scoring model. Separately account for corporate suffixes, well-known cloud platforms, CDNs, balancers, Kubernetes naming conventions, and contractor domains in the exclusions.

Instead of a conclusion

In the first days after NDR deployment, it usually highlights not APTs or complex post-exploitation activity, but technical debt, shadow IT, and long-forgotten workarounds. In this sense, NDR is useful not only as a protection tool, but also as an observation tool: it helps you see how the network actually behaves.

LDAP without TLS, forgotten service accounts, external DNS, non-standard ports, torrents, executable files in unexpected segments — all of this can accumulate for years and not look like an urgent problem. But it is precisely this background that prevents real incidents from being detected.

How to reduce the number of false positives and find real threats faster? One of the working approaches is to add context and automatic prioritization.

For example, automatic host risk scoring is used in "Garda NDR". The system calculates a danger index for each device based on a large number of detections (DPI, IDS, behavioral analysis, deception). Instead of analyzing thousands of disparate events, the analyst gets a list of hosts that are most likely compromised. This does not eliminate manual analysis, but allows you to focus on the most critical ones.

Another useful mechanism is clustering hosts based on behavior. Hosts with similar network behavior are automatically grouped. If a device starts acting atypically for its cluster (for example, using an unusual protocol or changing the direction of communications), the system registers an anomaly. This approach helps detect hidden attacks, including lateral movement using legitimate protocols (RDP, SSH).

Of course, no technology provides a 100% guarantee, but their combination significantly reduces the share of false positives and speeds up investigation.

I think everyone who has dealt with false triggers of behavioral models has their own favorite anomaly. Tell us in the comments: which network anomaly has eaten up the most of your nerve cells?