Honeypots - The Bastion of Proactive Security since 1991... Vol 9 rel 14

Honeypots

Honeypots, currently known Cyber Deception Systems, are computers set up to appear

operational to collect information on threat behavior and vectors. One of the most common reactions from people who hear the term cyber deception is “Oh, so it's like a honeypot!” Honeypots are definitely a component of cyber deception, but deception is not just about creating a machine that will look believable (i.e., an emulation) to an attacker, and then having that machine learn everything possible about said attacker. 

As you will see in the next section, cyber deception is comprised of multiple elements – honeypots being just one of them. One of the reasons honeypots aren’t in widespread use today is that honeypots are simply not effective enough for mass usage; they were and are still considered to be very complex to deploy and maintain, and/or easy for attackers to detect. 

So, what is the difference between deception and honeypots? Other than the fact that deception is made up of much more than just honeypots, there is also the fact that technology has evolved; orchestration and virtualization have now been commoditized, allowing for many things that were previously impossible. 

For example, even five years ago, if you wanted to set up a network of honeypots, you needed to manually distribute the honeypots among different servers, or find another way to make them look believable. If you wanted to create a honeypot on demand, you had to build the scripts. If you wanted to build a set of honeytokens and then automatically deploy them across the organization's network, there was simply no way to do so. 

With current virtualization and orchestration technologies, it is now possible to: Additionally,

the new generation of cyber deception now allows for the integration of deception elements into an organization's existing security tools, where they can harness the power of these tools. As a result, the tools themselves become more valuable because of the additional information received from deception elements.

The Value of Honeypots

Real or simulated systems and processes appear as if they are natural systems.  However, these systems are embedded with some glaring vulnerabilities. Nevertheless, along with these vulnerabilities come to some sophisticated sensors inserted within and around honeypots to collect data on threat behaviors. Honeypots can be anything from a single server to a cluster of servers. Honeypots are used for detecting uncontrolled threat sources.  Mileage may vary on the value of any given Honeypot, subject to configuration, and set up. The following depicts the primary benefits of the proverbial ‘Honeypot.’

1.   Prevent Automated Attacks

Automated attacks, such as worms or auto-rooters. These attacks played are based on tools that randomly scan entire networks looking for vulnerable systems. If vulnerable systems ar, these automated tools will then attack and take over the system (with worms self-replicating, copying themselves to the victim). Honeypots can help defend against such attacks by slowing their scanning down, potentially even stopping them. Sticky honeypots, as they are referred, they monitor IP addresses beyond the scope of the DHCP server.  When an intruder accesses these systems, the systems' response is to slow the attacker's process. This can be accomplished by a wide variety of techniques using TCP, such as a Window sizing of zero, putting the attacker into a holding pattern. Placing attackers in a holding pattern is an excellent way to slow down or prevent worm proliferation, or other malware types. One of the first production Honeypot's was a sticky honeypot, is LaBrea Tarpit. Sticky honeypots are often low-interaction solutions (you can almost call them 'no-interaction solutions' as they slow the attacker down to a crawl :).r

2.   Detection

Detection is critical in prevention, identifying failures, or breakdown. By detecting an attacker, they can quickly react to them, stopping or mitigating their damage. Traditionally, the detection was out of reach. IDS sensors and systems logs, although of singular importance in postmortem activities, have proven wanting in the proactive arena. There are several reasons for this:  They generate far too much data, a veritable tsunami of false positives, inability to detect zero-day attacks, and lack the ability to address encrypted or IPv6 environments. Conversely, Honeypots excel at detection, addressing many of these problems of traditional detection.

3.   Response

Once a failure is detected, how do they respond? This question can often be one of the most significant, for there are several factors in play here—crucial information like attacker identity, attack vector, attack damage. Just detecting a failure is treating a symptom, knowing the attacker's activity can discover the root cause.

Two problems are compounding the incidence response.

First, the "too big to fail" scenario, i.e., a system, although compromised, is too critical to operations, e.g., email server, financial server, etc.  Hence, security professionals are forced to do forensic analysis live, or must wait till off-hours to do anything.  This limitation cripples the IT team's ability to fault isolate, let alone address root causes properly.

Second, even if a system can be taken offline, there is so much data pollution, it can be exceedingly difficult to determine what the bad guy did. By data pollution, we mean the activity (user's logging in, mail accounts read, files written to databases, etc.). With mountains of data, it can be daunting to determine what is regular day-to-day versus attacker activity. Honeypots can assist in both scenarios.

Honeypots are excellent incident response tools, not only do they only focus on recording anomalous behavior, i.e., no day-to-day traffic, but can be easily taken offline for a full forensic analysis.  This anomalous behavior focus makes hacked honeypots easier to analyze than hacked production systems, as any data retrieved is likely the perpetrator born.  These factors alone are of singular importance to promoting rapid and effective incident response.

Honeypots: A History

• In 1991 two publications, "The Cuckoos Egg" and "An Evening with Berferd," introduced the first successful deployments of the Honeypot as a viable defense for pervasive attacks.
• "The Cuckoos Egg" by Clifford Stoll was about his experience catching a computer hacker,  searching for secrets in his corporation.
• "An Evening with Berferd" by Bill Chewick, is about a Cracker that is Lured, Monitored, and Studied.
• In both papers, the origins of the Honeypot can be found. In 1997, the Deceptive Toolkit was published. The kit gave remedies to attack back.
• In 1998, Cybercop Sting, the first commercial Honeypot, was offered.
• In 2002, the Honeypot was pervasively shared globally.
• In 2005, The Philippine Honeypot Project promoted computer safety in the Philippines.

How Do Honeypots Work?

Honey pots are on a real server, a simple operating system, complete with simulated data.

Honey pots work by performing duties such as log, alert, and capture an attacker's activities. Most honeypot solutions, such as Honeyd or Specter, have their logging and alerting capabilities. Snort deployment with any honeypot is an ideal scenario. Snort is an OpenSource IDS system that will not only detect and alert any attacks against a honeypot, but it can capture the packets and packet payloads involved in the attack.  This information can prove critical in analyzing the attackers' activities.

How does it Gather information?

Data capture happens on several levels;

1.   Firewall Logs-Simple, yet effective

2.  A Packet Sniffer (or similar IDS sensor) - The IDS is to monitor network traffic passively. To remain anonymous, one might set the system up to have no IP address or, in some instances, the sniffer could lack an IP stack. This anonymity will capture all cleartext communication and can read keystrokes.

3.  Local and Remote Logs typically configured,  just as would on any other system, risk being disabled, deleted, or modified by an experienced hacker. Regardless, a bounty of information is readily available from a wide variety of other capture processes. Remotely Forwarded Logs: capture and forwards data to a remote log to be relayed instantly to another system even further out of the range of the attacker.

 

Types of Honeypots

Production Honeypot

Honeypots can be performing in an advanced detection role. They prove whether Honeypot's

security function is inadequate in case of an attack, which becomes hard to lock. However, measures to avoid a real attack should be in place.

With a Honeypot, it is easier to determine and close security holes. In addition, Honeypot allows justifying the investment of other security technologies by documenting evidence of specific attack vectors. UT organizations find the monthly reports to be crucial for justifying budgets for personnel and resources.

For disgruntled employees, the risk is even higher, for they may have internal access that is completely authorized, but with a Honeypot, one can prove that their activities have malicious intent. Finally, Honeypots detect other security systems that do not catch attacks.

Research Honeypot

A research Honeypot is a different scenario. A research Honeypot collects information about the Blackhat community's tactics and techniques (In the Security discipline, a Blackhat is a hacker that pursues illegal interests. Conventional technology usually finds the attacker's tools, but there is no information about how. A Honeypot affords real-time knowledge on how and why a specific attack occurred.

Honeyed Research: Honeypots Against Spam

Honeyd is a Honeypot dedicated to irradicating spam. Since June 2003, Honeyd has been the

the dominant player in the spam trap discipline. It focuses on spammers by detecting open mail relays, techniques, etc.  The figure shows the architecture of the system.

Instrumented with open relays and open proxies, the Honeypot network, will intercept all spam email and analyze the vector that produced it. It simulates mail servers, proxies, and web servers.  Collaborative spam filters receive captured email sent, allowing other users to avoid reading known spam. Curiously, this setup has also been successful in identifying hosts infected with worms.

Creating a plan

Honeypot deployment planning should not only consider geographic information, but business demographic disbursement, and proximity to actual servers.  Ad-hoc Honeypots should never exist on a network. Like any other security platform, they must be part of a larger plan. Honeypots, like most security technology, should have executive sponsorship – not only does this protect the security team, but it facilitates a detailed security deployment plan. Being able to explain the honeypot deployment's security goals are important because there will undoubtedly be much pushback from leadership who can see honeypots as nothing but a "science experiment" or, worse, a liability within the organization.

The honeypot deployment planning should align with the organization's missions and should be optimized to collect data that will lead to the greatest amount of security intelligence in the production environment. Some of the questions that need to address:

• What are the most valuable assets in the organization?
• What systems contain those assets?
• How would an adversary gain access to those systems?

Questions like these will help narrow the focus of the honeypot deployment. These questions will also help determine what types of honeypots to deploy.

Building a Honeypot

A set of virtual machines (VMs) dare created and set up on a private network with the host OS. A stateful firewall, such as IPTables, is used to facilitate data control and can be used to log connections. Typically, this firewall would typically be configured in bridging mode, rendering it transparent to the attacker.

Structure of A VM Based Honeypot

The final step is data capture, for which tools such as Sebek and Term Log are instrumental. The data this captured, analyzed with tools such as Honey Inspector, PrivMsg, or Sleuth Kit. This approach is straightforward; however, a few significant issues exist.

1. The choice of a private host-only network. Though this may seem counter-intuitive at first, there is a relatively sound reasoning for doing so.
2. While bridging VMs on to the physical network would transparently forwards packets to the VM eliminating the need for a router,  it does require additional data control device to monitor the packets exchanged between the VMs. Note: The operation of data control should not be by the host OS, for the VMs are in bridged mode since all data from the VMs bypass any firewalls or IDSs at the application layer on the host shown in figure.

Honeypot Types

Based on the implementation of Honeypots, are categorized into the following:

Low-Involved Honeypots

A typical Low-Involved Honeypot limits the open ports so to facilitate rapid fault isolation of the attacker's approach. The attacker activities are extremely limited on a Low-Involved Honeypot. Hence, Low-Involved Honeypots are relatively less risky. Low-Involved DO NOT give users insight into the attacker; hence, they ideal for production honeypots.

High-Involved Honeypots

A typical High-Involved Honeypot will have, for example, a few ports open a few vulnerable services are running. Hence, the attacker can break into the Honeypot. The attacker can do everything he wants to on the High-Involved Honeypot. Hence, High-Involved honeypots are considered relatively risky. High-Involved honeypots are to gather much insight into the attacker's tools, techniques, and methods. Hence, they used as research honeypots.

The First Production Sticky Honeypot

Although In 1998, Cybercop Sting, was the first commercial Honeypot, Tom's Honeypot, developed by Tom Liston, developer of one of the earliest production sticky honeypots, the LaBrea Tar Pit. Tom's Honeypot is a low interaction Python honeypot designed to mimic a few specific services commonly targeted by attackers. These services include:

·        Remote Desktop Protocol (RDP) (TCP/3389)

·        Microsoft SQL Server (MSSQL) (TCP/1433, UDP/1434)

·        Virtual Network Computer (VNC) (TCP/5900)

·        RAdmin (Remote Administration) (TCP/4899)

·        Session Initiation Protocol (SIP) (UDP/5060)

Tom's Honeypot listens on specified ports for communication-related to these services. When an attacker attempts to access one of these services, an alert generates in the tomshoneypot.log file.

Since Tom’s Honeypot is just a Python script that requires the Python Twisted module, and then use Python to run it. The following command will install the prerequisite in Security Onion:

sudo apt-get install python-twisted

The script is available here: http://labs.inguardians.com/tomshoneypot. Once installed, just run the following command:

python tomshoneypot.py

By default, Tom’s Honeypot runs with all its available services turned on. If it is desired to run a subset of these services, one must manually edit the script and comment on the appropriate sections. These sections are:

 

reactor.listenTCP(1433, fMSSQL, interface = interface)

reactor.listenTCP(3389, fTS, interface = interface)

reactor.listenTCP(5900, fVNC, interface = interface)

reactor.listenTCP(22292, fDump, interface = interface)

reactor.listenTCP(4899, fRAdmind, interface = interface)

reactor.listenUDP(1434, uFakeMSSQL(), interface = interface)

reactor.listenUDP(5060, uFakeSIP(), interface = interface)

 

If a service is not desired, comment out the line with a preceding # sign that calls the service. This # will cause the Python interpreter to skip this line service.

For example, let us look at one of these services, RDP. The RDP protocol is for remote desktop administration of Windows hosts. A common scenario where an attacker has gained a foothold onto the network will typically do some scanning to determine other targets that are susceptible. 

The RDP port is 3389, and when an attacker sees this, they will try to connect to it with an RDP client. With the user's credentials obtained through some other means, the RDP service could allow them to take control of the server and begin pillaging data. Even if the user's credentials are not at hand, they could initiate a brute force attack trying to guess a user's password or to enumerate the version of Windows running on the machine.

In Tom's Honeypot, a fake RDP serves runs, and when an attacker attempts to connect, the system will complete a three-way TCP handshake with the Honeypot and will then initiate an RDP connection request; however, the Honeypot will not generate a response back. A typical attacker will usually assume this is because some host restriction is in place, or that the service is simply malfunctioning. However, this is occurring because there is no legitimate RDP service. Instead of providing an RDP server to log into, Tom's Honeypot logs the access to the fake system. An example of such a log is in the figure.

An Example Tom’s Honeypot RDP Access Attempt Log

In the logs shown will notice five individual entries. Four of these entries include a “Login” field.

While Tom’s Honeypot will not generate an interactive screen that an attacker can attempt to log into, it takes advantage of the fact that an RDP client will attempt to transmit a cookie during its initial negotiation request.

This RDP cookie does not have anything to do with authentication, but it contains a username for terminal services identification.  The first log in the figure does not show any result for this field because no RDP cookie was present during that connection attempt, but the following four log entries have values.

The second and third entries show two different IP addresses attempting to connect to the Honeypot with RDP cookie usernames values of "a" and "j." The last two log entries show two IP address attempts 192.0.2.234, using the RDP cookie username "NCRACK_USER."

The Ncrack tool is an authentication-cracking tool that can attack RDP servers. This information would indicate that 192.0.2.234 is attempting to obtain unauthorized access to the honeypot system.

There are other fake services provided by Tom's Honeypot that work similarly. Figure below shows an example of logs generated from the MSSQL and SIP honeypot services.

Two logs in the figure. The first log shows data obtained from an attacker attempting to communicate with Tom's Honeypot via an MS SQL client (TCP port 1433). Note that this output shows information about the client used to connect to the fake MS SQL service.

The second log shows someone attempting to communicate with the Honeypot via the SIP protocol (UDP 5060), commonly used by Voice over IP (VoIP) services. In this case, we see that this traffic is associated with the Sipvicious tool, which is used for scanning, enumerating, and auditing SIP services.

Tom’s Honeypot Logs for MSSQL and SIP Protocols

Tom's Honeypot is an actively developed project, and it is likely that by the time this paper is published, even more features exist. To learn more about Tom's Honeypot,  visit the project site at http://labs.inguardians.com/tomshoneypot/.

Take-a-Ways

A honeypot is just a tool. How we use that tool to lure perpetrators to reveal their activities.

There are a variety of honeypot options, each having different value to organizations. We have shown the value of the honeypot and how they reduce the attacks.  Furthermore, we have shown the different categories of honeypots, production and research.

• Production honeypots help reduce risk in an organization. While they do little for prevention, they can greatly contribute to detection or reaction.
• Research honeypots are different in that they are not used to protect a specific organization. Instead, they are used as a research tool to study and identify the threats in the Internet community.

Regardless of what type of honeypot, the more the honeypot can do, and the more we can learn from it. Honeypots will not solve an organization's security problems but maybe a tool to help to cultivate proactive security best practices.  In short, they provide beneficial information regarding the security of a network.  With the different types of honeypots such as BOF, Honeyd, Specter, etc. we can solve the current challenges and make it possible to use Honeypots for the benefit of the broader Internet community.

Honeypots, now coined as a component of a larger domain, Deception technology, finds itself quickly gaining popularity due to the increasing need for an effective solution for stopping and deterring attackers, gathering quality attack analytics and information, and generating high-fidelity alerts. While deception does involve honeypot technology, it is a complex field that meets multiple needs, many of which can only be addressed by deception. The effects of cyber deception are far-reaching and include benefits such as rapid attack detection, attack origin pinpointing, supply chain protection, the identification of advanced attackers, and more. Not only is cyber deception incredibly useful and powerful, but it can usually be introduced gradually to the organization without requiring many resources, which makes it a technology that is relatively easy to adopt. There is little doubt that cyber deception is a tool of the future and will soon become an integral part of cybersecurity systems the world over.

  

Share and enjoy…

 _________________________________________

We would like to thank our sponsors, for without them - our fine content wouldn't be deliverable!

Rick's Cafe' American

____________________________________________

Source(s):

• http://www.123seminarsonly.com/Seminar-Reports/012/53599210-Honey-Pots.pdf
• https://www.sciencedirect.com/topics/computer-science/honeypots
• http://www.rbaumann.net
• http://www.christianplattner.net
• http://www.honeynet.org
• http://www.topsite.com/best/honeypot
• http://www.en.wikipedia.org/Honeypot 

So “Once more unto the breach, dear friends, once more;”

____________________________________________________________

About Rick Ricker

An IT professional with over 23 years' experience in Information Security, wireless broadband, network and infrastructure design, development, and support.

Currently a Computer Science Instructor at CSULB, Shout-out to Cohort 2 - CIT class!