Honeypots: Good servers in bad alleys

Have you ever thought of spying on a malicious hacker? Wanted to see what tactics they use, learn more about attacks which are active “in the wild”, and peek behind their curtain? This is where honeypots can be very useful. ?

Honeypots are network-connected computers designed to appear to be vulnerable to attack, which can be very appealing to the threat actors who spend time performing and reviewing internet scans, always looking for new vulnerable systems to try and infiltrate, and seeking to leverage any access they have gained to both maintain persistence and move laterally across the network. The value of honeypots lie in the data which is generated when they are probed, attacked, or compromised.

Honeypots are used to deploy a “monkey-in-the-middle” to an attacker’s efforts while still allowing them to continue, which provides insight into how they operate, and, upon deeper analysis, delivers more information about their interests. Honeypots and other ‘honey technologies’ (like canary tokens) can be leveraged to start a nascent internal threat intelligence program, to augment an existing set of threat detection capabilities, or simply to perform independent security research and scratch that curiosity itch!

Cheaper than you think

Leveraging honeypots and other low cost ‘honey technologies’ can give a growing security program a detection-based edge where there wasn’t one before, at a low cost. Security program budgets most often run quite lean, and any unnecessary expenses are scrutinised. Honeypots are a serious way to gain an advantage without major new investments in infrastructure and tooling, and should be considered for their potential benefit to any security program.

However, management of honeypots can become labour-intensive, so any effort made to reduce the overall time expenditure involved with deploying and managing these systems should be a matter of focus at a scale larger than a handful.

Flavours of honey

Honeypots come in a few flavours:

“Low Interaction”: These systems emulate vulnerable applications, and are not likely to fool a sophisticated human attacker. Low interaction honeypots are great for collecting data from botnets and other worm-like, self-propagating malware.

“High Interaction”: These systems emulate both the operating system and vulnerable applications. As the attacker’s actions and movements are less restricted due to greater functionality, these honeypots generally requires a higher level of technical
experience on the operator’s part for proper deployment and maintenance.

“Pure”: These systems, pure honeypots, are in actuality production operating systems running fully functional versions of outdated or otherwise vulnerable system services and/or applications. The closer to “pure” a honeypot is (the more services an attacker can interact with that are not simply emulated), the less likely the attacker is to detect the honeypot. Preventing detection of sandboxed systems is a key component of many current malware families.

Another way to approach this is to think of a honeypot as exploitable or non-exploitable. We can also classify honeypots as “research” or “production”-focused. Do they primarily exist to collect data, or to protect assets?

Placement matters

Where you deploy your honeypot impacts the type of visibility and data you will be able to gather. It is effective to deploy them on the same network segments as the assets you would like to mimic and protect.

Those looking to gain insight into incoming attacker activity should place their honeypots on the edge of public-facing networks. These systems will be subjected to the barrage of threat actors who are constantly on the hunt, testing defences and looking for machines to compromise. Public-facing honeypots can provide a wealth of insight into active reconnaissance campaigns against your network: the types of attacks, origination, and more, all in (almost) real time.

Placed within a network, honeypots can produce high fidelity detection alerts. As these systems should have no actual production value, any attempted accesses whatsoever should be considered malicious and trigger incident response activity, including detection rule tuning and security control effectiveness review for the real production systems you’re trying to protect.

As a quick note, please be sure to verify that an attacker cannot leverage a compromised honeypot in unexpected ways, nor make contact with your actual production infrastructure. It can be helpful to develop a visual threat model, showing your honeypot’s planned and unplanned weaknesses and any possible connection points with your own infrastructure — then secure those so no other communication can be initiated with other internal hosts.

Server Resources

As an independent researcher, you are not likely to have the same resources that an enterprise does at your disposal, but low interaction honeypots are not highly resource-intensive, and cloud computing is not costly if used effectively. There are many free and open-source honeypot softwares you can find using Google, and various types of common services can be emulated, such as SSH, RDP, VNC, and SIP.

For my own research, I opted to use T-Pot, a honeypot platform which is developed and maintained by the security team at Deutsche Telekom (thanks y’all!) Set-up was a breeze as the instructions provided are quite good, and within 15 minutes of deployment, I began to visually see new data start streaming into the web application dashboard. Attacks on my public-facing honeypots occurred non-stop on full-tilt. Every open port was scanned and enumerated many times by many different systems from varied public IP spaces.

Statistics

I left this honeypot online for 48 hours and collected quite a lot of information about bad actors, the current state of unfiltered public internet, and what it was like to be a good server in a dark alley. During this time, I averaged 24,992 offensive probes per hour, and attacks against the system came from all over the planet.

Here are a few statistics:

The biggest attack source offenders were:

● ?Vietnam (25%)
● ?Russia(13%)
● ?India (13%)

The most in use attack operating system

?Unknown (51.9%)
?Windows 7 or 8 (44.7%)
?Linux 2.x (1.3%)

Service most under attack

?SMB (79.1%)
?HTTPS (11.9%)
?HTTP (3.8%)

Attacker source IP address

?5.188.86.172 (72,128 events)
?5.188.62.11 (10,518 events)
?5.182.39.62 (7,033 events)

Although 48 hours worth of data isn’t nearly enough to extrapolate work or sleep cycles, there is basic evidence in my dataset showing peaks and valleys of traffic suggesting these attackers are more than just automated bots — many systems behind the scanning appeared to be actively maintained and controlled by human operators.

Longer-term collection efforts would provide a wider view from which to create a basis for actionable intelligence.

Okay, how do we use the data?

Developing a honeypot playbook will help to align your organisation to perform the correct actions when certain types of alerts are received from your honeypots. These playbooks provide specific response actions to take when data is received from different types of honeypots in your environment.

For instance, alerts of probing activity from non-exploitable, low-interaction honeypots can serve as rollup statistics from which an analysis is developed twice a week to identify any trends and opportunities for refining the security program.

In contrast to that type of passive defensive response, alerts of exploitation activity from exploitable “pure” honeypots which are placed in the same network segment as the critical assets they are mimicking may be leveraged as evidence of an active threat actor on the protected network which must be handled immediately.

I have also heard of folks getting greater budget increases due to being able to show actual evidence of attack against specific targeted assets within the organisation.

Conclusions

Leaving a good server in both dark and well-lit alleys can yield dividends with regard to investment in your Threat Intelligence program. Developing this capability requires forethought and corresponding process documentation, but for organisations at the right maturity level, analysis of raw data from your own honeypots can be a boon to both your threat analysts and strategic decision-makers.