Detection

Honeypot

A honeypot is a decoy system with no productive purpose, so its use almost always indicates an attacker.

A honeypot is a decoy system that looks realistic but has no productive purpose. Any access to it is suspicious and therefore provides a very clear signal.

How it works

A honeypot can be a server, a service, or an entire environment. It is configured to look interesting to attackers, for example as a file server named 'Finance'. Legitimate users have no reason to access it. Every connection attempt therefore triggers an Alert. Internet-facing honeypots are generally for research. Internal honeypots are used to detect attackers within your own network.

As a practical example, a honeypot on the server network looks like an old database server. On a Tuesday evening, an account from the finance department tries to log in. The SOC investigates the laptop and finds a tool scanning the network for servers. The attacker is discovered before they access any real data.

What to look out for

  • The honeypot must look convincing and fit into your environment.
  • It must not create a real backdoor into your network. Isolate it carefully.
  • Inform IT operations to prevent false alarms from network scans and asset inventories.
  • Send Alerts directly to the SOC with high priority.

Benefits

Honeypots generate very little noise. A hit is almost always relevant. They also detect attackers who use legitimate tools and otherwise remain unnoticed. The effort for operation and maintenance is comparatively low.

Limitations

A honeypot only detects attackers who interact with it. An attacker with a specific target may bypass it. Honeypots are therefore a supplement to other detection methods. They are not a replacement.

Typical mistakes

Often, a honeypot is set up and then neglected. It becomes outdated, fails, or looks obviously artificial after some time. A second mistake is when Alerts land in a separate tool and not in the SOC.

How we implement it

If you use honeypots, we integrate their Alerts into our SOC as a log source.

How ANOMAL implements this