Up The Cybersec Ante With Honeypots

Oct 23, 2020 · 1688 words · 8 minute read security honeypot honeypots

Up the Cybersec Ante with Honeypots

In the interest of brevity, ubiquitous IT acronyms (such as VM, IP, SSH etc.) are used in this article. You can find a comprehensive list of Common IT acronyms and their meanings here

The Name of the Game

Imagine you are playing a game of poker, and you are dealt a really poor hand. You don’t know what cards your adversaries have in their hands, but they certainly look confident and they might as well have a good reason to.

Well, that’s the reality of most cybersecurity engineers. We spend most of our time defending against zero-day threats, hackers, script kiddies, and cyber attacks that can come from virtually (pun intended) anywhere.

We put in place firewalls, anti-malware, network and host IDS, DLP systems, VPNs, austere security policies (such as two-factor authentication, strong passwords with frequent expiration etc.), which at times are detrimental to another very important factor in the information technology ecossystem: user experience.

This tradeoff between protecting our data and our business while providing users with an intuitive, enjoyable experience is that poor hand I mentioned earlier. If you think about it, an attacker needs to own you only once. You have to defend all the time. They have, by and large, the upper hand.

In such a situation, how can you up the ante and increase the odds of success? How can you create a buffer space between yourself and your adversaries without impacting customer experience? While the definition and measurements of ‘success’ vary from business to business, there’s an old and simple trick (known and mastered by every respected poker player) that you can use: the bluff. And that’s where honeypots come into play.

A Trick Up the Sleeve

Since the early 1990’s, honeypots have been getting traction both in the academic and business spaces, and they perform well as a cost-effective early detection system and first line of defense.

According to the Collins Dictionary, a honeypot is:

(esp internet) An attractive thing used to lure people into performing a particular action or visiting a particular location

Lance Spitzner, the founder of the Honeynet Project, defines a honeypot as a:

Security resource whose value lies in being probed, attacked or compromised

The idea is to present a crafted decoy system that has no real production value, whose goal consists of deceiving, deflecting and delaying adversaries from attempting to get access to our real systems. It’s like bluffing, pretending to have something that you don’t in order to throw your adversaries off the course and keep yourself afloat in the game.

One of the main advantages of honeypots is that they expand on your security catalogue without impacting user experience, since they are transparent to legitimate users. That is, unless a ‘legitimate’ user decides to go rogue on you and starts poking around the network for crispy secrets.

Whether you want to deploy them to be publicly exploitable on the internet (DMZ deployment), or inside your network (honeypots are great assets to find out if an internal agent is crawling all over your network), honeypots come in all shapes and sizes and apply to multiple use-cases.

Here at Pan-Net, we’re crafting internal honeypot networks based on free, open-source software (FOSS) with ease of deployment. Instead of relying on one particular software, we are customizing a patchwork of different types of honeypots. We adopt an Infrastructure as Code (IaC) model to install, configure and fine-tune honeypots in an automated and idempotent way.

Here’s an eagle’s nest view of our honeynet architecture model:

A Practical Example

Take, for instance, the example below. Suppose that we have 2 honeypot VMs emulating interesting services. We’re assuming an internal agent is probing the Pan-Net network for potential openings:

To find out exploitable services, a simple nmap scan would do:

$ nmap -sS -Pn 192.168.0.0/24

This potential attacker has just discovered exploitable services. The decoy servers present themselves as Elasticsearch nodes, moreover accessible via SSH.

... omitted ...

Nmap scan report for 192.168.0.30
Host is up (0.086s latency).
Not shown: 995 filtered ports
PORT     STATE  SERVICE
22/tcp   open   ssh
9200/tcp open   wap-wsp

Nmap scan report for 192.168.0.32
Host is up (0.076s latency).
Not shown: 995 filtered ports
PORT     STATE SERVICE
22/tcp   open  ssh
9200/tcp open  wap-wsp

... omitted ...

Nmap done: ... omitted ...

Let’s start with checking the cluster health status:

$ curl http://192.168.0.30:9200/_cluster/health?&pretty
{
  "error": {
    "root_cause": [
      {
        "type": "index_not_found_exception",
        "reason": "no such index",
        "resource.type": "index_or_alias",
        "resource.id": "test",
        "index": "test"
      }
    ],
    "type": "index_not_found_exception",
    "reason": "no such index",
    "resource.type": "index_or_alias",
    "resource.id": "test",
    "index": "test"
  },
  "status": 404
}

Hmm. This is odd. Let’s investigate a step further and check out what indices this Elasticsearch node might be storing:

$ curl http://192.168.0.30:9200/_cat/indices
health status index      pri rep docs.count docs.deleted store.size pri.store.size
yellow open   ews          5   1         15            2     16.8kb         16.8kb
yellow open   dummy        5   1          0            0       795b           79

Hmm, something doesn’t seem right. At this point, depending on the level of familiarity of the attacker with Elasticsearch, he might have already figured out that something fishy is happening and abort his attack, or he might attempt to connect to the node directly. Whatever the case may be, we already have some information about the attacker. Our Grafana dashboard is reporting activity on port 9200:

Our SIEM systems are also aware of the attack. Graylog provides further context about the situation (IPs, node names and FQDNs are omitted):

A Slack notification is sent to relevant groups, warning cybersecurity staff about the ongoing attempt (stream names and FQDNs omitted):

Unbeknownst to the malicious agent, we’re onto him.

Let’s assume, for completeness sake, that this attacker is persistent, and attempts to brute-force his way into the ‘elasticsearch’ server:

$ ssh root@192.168.0.30
The authenticity of host '192.168.0.30 (192.168.0.30)' can't be established.
RSA key fingerprint is SHA256:...omitted...
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.0.30' (RSA) to the list of known hosts.
Password:
Password:
Password:
root@192.168.0.30's password: 

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@elastic0:~

Upon a few arbitrary number of attempts, access is granted. This person is now presented with an interactive shell session. This shell is an emulation and limits what the attacker can do.

Let’s try to fingerprint the operating system.

root@elastic0:~ history -n
1  b'history -n'
root@elastic0:~ export HISTSIZE=0  
root@elastic0:~ uname
Linux
root@elastic0:~ cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Intel(R) Core(TM)2 Duo CPU     E8200  @ 2.66GHz
stepping	: 6
cpu MHz		: 2133.304
cache size	: 6144 KB

... omitted ...

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Intel(R) Core(TM)2 Duo CPU     E8200  @ 2.66GHz
stepping	: 6
cpu MHz		: 2133.305
cache size	: 6144 KB

... omitted ...

root@elastic-0:~ free -m
              total        used        free      shared  buff/cache   available
Mem:           4038        1805         213           1        2020        2335
Swap:             0           0           0

Once again, it doesn’t take too much time for this person to figure out the deception (e.g., by noticing unrealistic CPU or memory activity that would otherwise be expected of an Elastic node), and that’s okay because at this point your bluff already paid off. The dashboards and SIEM systems are already aware of the honeypot activity (down to every single command entered in the bogus shell session):

You have their source IP address (that by itself doesn’t really mean all that much, considering that this IP address might have been spoofed) and enough evidence to discard a ‘false positive’ and ascertain that somebody attempted to obtain unauthorized access to your network resources.

It’s a good enough starting point for a deeper forensic analysis into the network and the source and motivation behind this attack. At the very least, it indicates that there are indeed malicious agents inside your organization and closer attention must be paid.

The more honeypots you deploy, the less likelihood that a real system be breached. Remember, what counts here is not that the person find out that you are operating a honeypot, but that they now have to watch their back when they see another ‘low-hanging’ fruit, and the psychological burden that entails.

The Showdown

The aforementioned example uses low and medium-interaction honeypots, which work well for most cases. Although they have a reduced scope of activity, they present a much smaller attack footprint that can prevent the malicious agent from turning the tables on you. In other words, they are harder to circumvent because they are not real systems, but rather simpler emulations.

High-interaction honeypots are also a viable option. For example, a variation of the medium-interaction SSH honeypot in which instead of an emulated shell session, the attacker would get SSH-proxied access to a real system. The connection is observed and monitored through the SSH-Proxy at all times. There are risks to this, however, and both the SSH-proxy VM and the honeypot VM need to be protected (in paranoid detail) so that the attacker doesn’t successfully download malware or use the VMs as a HQ for further attacks.

Unless your goal is to thoroughly study a compromise or an attacker’s motivation to a meticulous depth, the use of high-interaction honeypots in the enterprise is discouraged.

Whatever the case may be, when it’s time for showdown, you want to make sure that you have used all the cards and tricks available in the book. After all, this game is never over and there’s a lot at stake.

Stay tuned for more.

Up the Cybersec Ante with Honeypots

The Name of the Game

A Trick Up the Sleeve

A Practical Example

The Showdown

Further Reading