Applications of MHN and Honeypots in the Enterprise

<p>Often times we are asked about various uses of <a href="https://github.com/threatstream/mhn">Modern Honey Network</a> (MHN) and deploying honeypots. In this post we will discuss several different use cases for how MHN and honeypot sensors can be used in the enterprise.</p><h2>Threat Intelligence Collection</h2><p>MHN was originally designed for Threat Intelligence collection in mind and it has expanded to several other applications. In this use case, the goal is to gather intelligence about IP addresses that are scanning, exploiting, and brute forcing lots of systems on the Internet as well as gather URLs, payloads/shellcode, and malware/tools dropped during exploitation attempts. For threat intelligence collection the individual events are less important than the overall aggregate activity levels and the <a href="https://en.wikipedia.org/wiki/Indicator_of_compromise">Indicators of Comnpromise</a> (IOCs) collected. When several sensors are deployed you will see similar malicious activity originating from the same IPs spanning many if not all your sensors.</p><p>Typically you will want to deploy several different types of sensors based on your collection goals. Here are some sensors combos (on one server) that we recommend:</p><ol><li>Dionaea + kippo + snort + p0f</li><li>Amun + kippo + snort + p0f</li><li>Elastichoney + shockpot + snort + p0f</li><li>Conpot + snort + p0f</li><li>Elastichoney + Glastopf + snort + p0f</li></ol><p>We recommend <a href="https://www.snort.org/">snort</a> and <a href="http://lcamtuf.coredump.cx/p0f3/">p0f</a> in each deployment because they can provide very useful contextual data for threat intelligence such as the attacking host's operating system, its uptime, its network connection type, and possibly some characteristics of the attack payload such as vulnerability exploited or malware family.</p><p>MHN has two API endpoints that are especially useful for retrieving collected threat intelligence. They are: /api/top_attackers/ and /api/intel_feed/. They both provide indicators and contextual information about the host attacking hosts during a specified time period.  For more information about MHN's APIs see the <a href="https://github.com/threatstream/mhn/wiki/MHN-REST-APIs">MHN REST API wiki page</a>.</p><h2>Honeypots as Sinkhole Servers</h2><p>Many organizations we work with are using <a href="https://dnsrpz.info/">Response Policy Zones</a> (RPZ) to block or sinkhole malicious or suspicious DNS traffic. Often times they want to send the possibly infected host to a sinkhole server in order to identify the host, capture the network traffic and fire off an event in their <a href="https://en.wikipedia.org/wiki/Security_information_and_event_management">SIEM</a>. Modern Honey Network and honeypot sensors can aid in this scenario.</p><p>Honeypots such as <a href="https://github.com/rep/dionaea">Dionaea</a>, co-deployed with p0f and snort can be a very effective sensor for catching these sorts of network activity and MHN will ensure that the data collected from these sensors will be stored and integrated with a SIEM such as ArcSight, Splunk, or even <a href="https://www.elastic.co/products">ELK</a>. Typically, you will only need one of these sensors deployed to a static IP address. This IP will be used in the RPZ responses to reroute the requesting host to the honeypot sensor instead of the real malicious IP in the wild.</p><h2>Catch Hosts Violating Web Proxy Policy</h2><p>Several organizations we work with have been exploring options for how to catch hosts or processes that are attempting to connect directly to external websites without going through their corporate web proxy. They want to detect these hosts and often they want to examine the traffic associated with the requests to determine if the device is misconfigured or if malware is attempting to connect directly out.</p><p>Very similar to the sinkhole server use case, Dionaea, p0f, and snort deployed through MHN are very useful here. They enable security operators to catch these hosts and gather useful contextual information such as the full HTTP request, the operating systems and uptime of the host, and any malicious traffic patterns the host might be exhibiting. This use case is most powerful when MHN is integrated into the enterprise's SIEM or log management platform.</p><h2>Low Noise IDS</h2><p>In this use case, MHN can be used to deploy several sensors strategically located throughout the enterprise (behind your firewall). These sensors should be configured to blend in with their surrounding hosts as much as possible. If your deploy them in the same network as your Linux servers you may want to deploy <a href="https://github.com/desaster/kippo">Kippo</a> and Dionaea (but tuned). If deployed among Windows hosts, you may want to deploy Dionaea or <a href="https://github.com/zeroq/amun">Amun</a>, but configured to only run services the other hosts are running. If deployed properly, any traffic to these systems should be considered suspect and should be investigated as an IDS alert would be. All of the sensor events will be collected by MHN and are made available for either querying via the REST APIs or they can be shipped to a SIEM or log management platform for incorporation into the Enterprise security stack.</p><h2>Event Enrichment or Reputation</h2><p>When deployed properly, honeypots' data can be used for event enrichment for other non-honeypot related network events. What this means is collecting and aggregating honeypot events into summaries that can be queried quickly and leveraged by other systems to make decisions about a host. For example, MHN provides an API endpoint called /api/attacker_stats/{IP}/ which returns a summary of the activity as seen by all your deployed honeypots. This summary can be interpreted to derive the host's reputation. It includes: first seen timestamp, last seen timestamp, event count, ports interacted with, number of sensors touched, and types of sensors touched. This summary can be used by a high security web application to determine whether this IP's requests might need extra scrutiny or whether they should be blocked outright.</p><h2>Forensics</h2><p>Honeypot data can be very useful for forensics investigations. For this use case, you may not be able to leverage sensors in your production alerting infrastructure as previously mentioned in the "Low Noise IDS" section. Even if you can't do this, you should consult your honeypot logs to determine if a potentially compromised system interacted with your honeypots, possibly during an internal foot-printing or lateral movement attempt. Many honeypots are designed to catch malicious payloads such as shell code, droppers, and other tools. Because of this, they can be great ways to find this data that may not have been logged or that may have been deleted on real systems that were exploited.</p><h2>Research</h2><p>Lastly, MHN can be very useful to setup data collection to feed research efforts especially when the sensors are deployed on Internet facing systems far and wide. When lots of sensors are deployed you may find some very interesting traffic that may or may not be malicious. For instance, we have found several instances of HTTP requests to websites whose domain used to resolve to the Cloud hosted IP our honeypot sits on.</p><p>We have also see what appear to be masscan based scans for very specific URL paths which is likely for determining either scale of infections, identification of a C2 server/control panel, or identification of a vulnerability.</p><p>For more information about the Modern Honey Network see its Github repo <a href="https://github.com/threatstream/mhn">here</a>, or see its mailing list <a href="https://groups.google.com/forum/#!forum/modern-honey-network">here</a>.</p>