Category Archives: HoneyPoint

InfoWorld Reviews Honey Pots and HoneyPoint

Posted on by
Reply

MicroSolved, Inc. was recently featured in InfoWorld’s article, “Intrusion detection honeypots simplify network security,” by Roger A. Grimes.

It’s a great review of MSI’s HoneyPoint technology, along with two other honey pot software solutions. The article is very thorough, testing everything from features and logging capability to ease-of-use and value. As Roger stated, intrusion detection is a complicated business, which is why we continue to strive to increase the visibility of the security team within an ever-increasingly insecure world. His use cases are very specific and the article presents a powerful argument for honey pots and their role in modern information security. We commend the author for his work and very much appreciate HoneyPoint’s inclusion in the solution set.

Some of HoneyPoint’s features, namely defensive fuzzing (HornetPoint behavior) and port mining appear to have been misunderstood by the reviewer. He mistakenly compares it to “tarpitting”, which is a technique used to slow down scans by tampering with the TCP packets in the 3 way handshake to delay connections. HornetPoints do not perform any actions at the packet layer, but instead, apply fuzzing routines within the specific emulated protocol (HTTP, SMTP, etc.) to attempt to cause the scanner or worm to fault on the attacking system, a form of self-defense. Port mining simply shoves a large binary file at attacker tools, again with the intent of crashing them, not simply slowing them down. These differences did not seem to be communicated well in the review when we read it.

We completely agree with the author that HoneyPoint has a large feature set and that our reporting and event tracking make it a powerful enterprise tool. We also appreciate his coverage of the plugin capability that allows users to extend and automate their alerting and response capabilities with HoneyPoint. We designed the product to be easy to use and most customers learn to install, configure and manage the product in a simple 2-4 hour virtual session included in every purchase. Our customer’s experience and rating for ease of use varies from what is presented in the review. Customers continually praise HoneyPoint as being one of the easiest enterprise products they have deployed and used.

Lastly, the author’s review makes the point that honey pot tools cannot bind to ports already in use, making them essentially blind to attack traffic on those services already installed on the hosts on which the tool is running. This is a valid truth and represents one of the core reasons why we felt it was important to design HoneyPoint to run across platforms. If a honey pot product can only run in Windows, it cannot bind to ports like 135-139 and 445, which are the common ports used for Windows CIFS. It also cannot bind to ports, and thus provide detection on Windows RPC ports that are in use. As such, a low interaction honey pot deployed only on a stock Windows workstation cannot perform detection of threats like Conficker and other traditional Windows-centric attacks. This leaves an organization using a Windows-constrained detection tool unable to emulate these services and detect these attacks. HoneyPoint, on the other hand, can just as easily be deployed on Linux as on Windows. Using a simple liveCD install (such as Puppy, DSL or the Ubuntu, etc.) you can deploy HoneyPoint on these ports, emulating Windows and thus gaining detection and visibility not available with a Windows-constrained product. We feel, as do many of our clients, that this is a powerful difference between our product and others and that it gives our clients the ability to stud their environment with detection decoys, even at the Windows protocol level, where others are blind.

We designed HoneyPoint not as an academic tool for laboratory use or for those folks wishing to capture packets of the attack tools and write papers about them, but as a real-life, deploy and forget, enterprise threat management system for businesses interested in breaking the attacker life cycle. We are quite proud that the tool is functional, flexible and simplistic. That was the goal from the beginning. We are as proud of the things that our product DOESN’T do to maintain that core focus as we are of the things it DOES do and how it accomplishes them.

Overall, we are in full agreement with InfoWorld: the impact of honey pots in the corporate environment is best understood by serving as an early-warning system. When honey pots are utilized in this way, they are economical and efficient, yet meet the need to identify threats in the network environment. We extend kudos to Roger for his review and for the hard and complex work he did reviewing and comparing the three products.

MSI welcomes this type of review, because our quest to make you safer is what drives us. Clients tell us that we’re good listeners and we love to hear feedback from the community. We will not stop improving our efforts to protect our clients because frankly, the attackers will not stop searching for vulnerabilities. As always, thanks for reading and stay safe out there!

OpenSSL Vulnerability

Posted on by
Reply

A new security issue in OpenSSL should be on the radar of your security team. While Stunnel and Apache are NOT affected, many many other packages appear to be. The issue allows denial of service and possibly remote code execution.

Patches for OpenSSL and many packages that use it are starting to roll in. Check with your favorite vendor on the issue for more information. The CVE is: CVE-2010-3864

HoneyPoint users who leverage black hole defenses should ensure that they have exposed port 443/tcp honeypoints and have dilated other common ports for their applications that might be vulnerable. Internal HoneyPoint users should already have these ports deployed, but if not, now is a good time to ensure that you have HoneyPoint coverage for any internal applications that might be using OpenSSL. Detecting scans and probes across the environment for this issue is highly suggested given the high number of impacted applications and platforms.

If you have any questions about this issue or the proper HoneyPoint deployment to detect probes and scans for it, please give us a call or drop us a line. We will be happy to discuss it and assist you.

Tip: Pre-loading Wasp Configuration Databases

Posted on by
Reply

Thanks to a couple of users who have provided this excellent tip for reducing the initial number of alerts that come in when you first deploy HoneyPoint Wasp as it learns it’s environment.

The tip is to load an initial copy of Wasp on a trusted, fresh desktop workstation image and then execute all of the applications your organization generally supports. Then, let the Wasp run for about 48 hours and populate its database with the accepted applications and the like from the default image.

Once complete, use copies of this database in your installation across the enterprise. You will then get delta alerts instead of the base alerts for things you already know and trust. This eliminates the initial set of alerts from each Wasp workstation you deploy and greatly reduces the management load of the initial roll out.

Thanks to the two folks who really worked out this method, tested it and wrote up notes for us to share the idea with you. Much appreciated!

To learn more about using Wasp to extend your malware protection, gain security visibility easily to the workstation layer and create anomaly detection techniques for your security program, give us a call or drop us a line. We look forward to sharing tips like these and success stories with you as they come in from users.

Keep Your Eyes on This Adobe 0-Day

Posted on by
Reply

A new Adobe exploit is circulating via Flash movies in the last day or so. Looks like the vulnerability is present across many Adobe products and can be exploited on Android, Linux, Windows and OS X.

Here is a link to the Dark Reading article about the issue.

You can also find the Adobe official alert here.

As this matures and evolves and gets patched, it is a good time to double check your patching process for workstation and server 3rd party software. That should now be a regular patching process like your ongoing operating system patches at this point. If not, then it is time to make it so.

Users of HoneyPoint Wasp should be able to easily any systems compromised via this attack vector using the white listing detection mechanism. Keep a closer than usual eye out for suspicious new processes running on workstations until the organization has applied the patch across the workstation environment.

HoneyPoint Wasp is Almost Ready to Leave the Nest

Posted on by
Reply

As many of you may know, the MSI team has been hard at work the last several months finishing the beta of our new compromised workstation detection product, HoneyPoint Wasp. It is a fully integrated component of HoneyPoint Security Server, capable of executing distributed detection and threat monitoring on Windows workstations across enterprises. The initial feedback by the beta group have been absolutely amazing. We are finding bots, malware and compromised hosts in a variety of locations, once thought to be “clean” and “safe”.

Wasp accomplishes this mission by being deployed as a service on workstations and by monitoring for the most common signs of compromise. It can watch for changes in the users, admins, port postures and such. It does white list detection of the running processes and it is even capable of detecting DNS tampering and changes to selected files on the operating system.

Even better, it does this work without the need for workstation event logs, signature updates or tuning. It “learns” about the workstation on which it is deployed and adapts its detection techniques to focus on important changes over the long run.

We designed Wasp to be easy to install, easy to manage and to be transparent to the end – user. As such, it is deployed as a 0-interface piece of software. There are no pop-ups, no GUI and no interaction at all with the user. All alerts are routed to the HoneyPoint console and the security team, eliminating any chance of increased help desk calls, user push back and confusion.

In the next couple of weeks, we will be making some announcements about the general availability of the Wasp product. I hope you will join me in my excitement when we announce this launch. In the meantime, think about what you are doing today to protect against initial stage compromises and congratulate the MSI development team and our beta testers on a job well done. I think you are going to be amazed at how easy, capable and advanced Wasp is, when it is released. I know I continue to be amazed at what it is detecting and how much stuff has evaded current detection techniques.

In the meantime, while we await the full release, check out this PDF for some more information about where we are going with Wasp and our HoneyPoint product line. I think you are going to like the diagrams and the explanations. If you would like to book a special sneak preview of Wasp and the rest of HoneyPoint, give your account executive a call. We will be happy to sit down and discuss it with you. As always, thanks for reading!

Excellent Source for Metrics on PHP RFI

Posted on by
1

My friend Eric has put up some excellent statistics and metrics on PHP RFI attacks against his honeynet. This is some excellent data. If you have read other stuff we have pointed to from Eric, then you know what to expect. But, if you are interested in a real world look at trends and metrics around PHP exposures, give this a few moments of your time.

You can find the interface and metrics set here.

Check it out, I think you’ll be impressed. Thanks, as always, to Eric and other folks in the honeypot community for all of their hard work, time and attention.

If you have some honeypot metrics to share, drop a comment below! As always, thanks for reading!

An Explanation of Our HoneyPoint Internet Threat Monitoring Environment #HITME #security

Posted on by
Reply

One of the least understood parts of MicroSolved is how the HoneyPoint Internet Threat Monitoring Environment (#HITME) data is used to better protect our customers. The engineers have asked me to drop this line into the newsletter and give you a “bees knees” perspective of how it works! First, if you don’t know about the #HITME, it is a set of deployed HoneyPoints that gather real world, real time attacker data from around the Internet. The sensors gather attack sources, frequency, targeting information, vulnerability patterns, exploits, malware and other crucial event data for the technical team at MSI to analyze. You can even follow the real time updates of attacker IPs and target ports on Twitter by following @honeypoint or the #HITME hash tag. MSI licenses that data under Creative Commons, non-commercial for FREE as a public service to the security community.

That said, how does the #HITME help MSI better protect their customers? Well, first, it allows folks to use the #HITME feed of known attacker IPs in a blacklist to block known scanners at their borders. This prevents the scanning tools and malware probes from ever reaching you to start with. Next, the data from the #HITME is analyzed daily and the newest, bleeding edge attack signatures get added to the MSI assessment platform. That means that customers with ongoing assessments and vulnerability management services from MSI get continually tested against the most current forms of attack being used on the Internet. The #HITME data also gets updated into the MSI pen-testing and risk assessment methodologies, focusing our testing on real world attack patterns much more than vendors who rely on typical scanning tools and back-dated threats from their last “yearly bootcamp”.

The #HITME data even flows back to the software vendors through a variety of means. MSI shares new attacks and possible vulnerabilities with the vendors, plus, open source projects targeted by attackers. Often MSI teaches those developers about the vulnerability, the possibilities for mitigation, and how to perform secure coding techniques like proper input validation. The data from the #HITME is used to provide the attack metrics and pattern information that MSI presents in its public speaking, “State of the Threat,” the blog, and other educational efforts. Lastly, but certainly not least, MSI provides an ongoing alerting function for organizations whose machines are compromised. MSI contacts critical infrastructure organizations whose machines turn up in the #HITME data and works with them to mitigate the compromise and manage the threat. These data-centric services are provided, pro-bono, in 99% of all of the cases!

If your organization would be interested in donating an Internet facing system to the #HITME project to further these goals, please contact your account executive. Our hope is that the next time you hear about the #HITME, you’ll get a smile on your face knowing that the members of my hive are working hard day and night to protect MSI customers and the world at large. You can count on us, we’ve got your back! 

Review of Puppy Linux 5.0

Posted on by
Reply

Lucid Puppy Linux 5.0 was released back in May of 2010, but as one of my favorite distros, I have been playing with it heavily since then. I have been so impressed with the new version that I wanted to take a moment and write a quick review of this release.

You can find the official release page here, along with download information.

First, let me say that I have really come to love Puppy Linux over the last several years. I use it as a LiveCD/USB platform for secure on the go browsing, a Linux OS for old hardware that I donate to a variety of folks and causes, and as a platform for using HoneyPoint as a scattersensor. I like the ease of use, wide range of hardware support, and small footprint. All of these make this a very workable Linux distro.

This version especially seems to be stable, fast, and capable. I have taken to running it from a bootable USB drive and the performance has been very nice. Being able to drop these onto untrusted systems and use them as a browser, VPN client, and productivity tool has been handy. Using HoneyPoint Personal Edition, the nmap plugins and some other Puppy installs of security tools gives me a great platform for working incidents, gaining visibility and catching rogue scans, probes and malware that are in circulation when I pull in to help a client. Over and over again, the distro has proven itself to be a very powerful tool for me.

I suggest you take a look at the distro, LiveCD or USB and see how it can help you. I think you’ll find it fun, easy to use, and quite addicting. The pictures of the puppies don’t hurt either. 🙂

Check it out!

Fighting Second Stage Compromises

Posted on by
Reply

Right now, most organizations are fighting a losing battle against initial stage compromises. Malware, bots and client side attacks are eating many security programs alive. The security team is having a nearly impossible time keeping up with the onslaught and end-user systems are falling left and right in many organizations. Worse, security teams that are focused on traditional perimeter security postures and the idea of “keeping the bad guys outside the walls” are likely unaware that these threats are already active inside their networks.

There are a number of ways that second stage compromises occur. Usually, a compromised mobile device or system comes into the environment via remote access, VPN or by being hand carried in by an employee or consultant. These systems, along with systems that have been exploited by client-side vulnerabilities in the day to day network represent the initial stage compromise. The machines are already under attacker control and the data on these machines should already be considered as compromised.

However, attackers are not content with these machines and their data load. In most cases, they want to use the initial stage victims to compromise additional workstations and servers in whatever environment or environments they can ride those systems into. This threat is the “second stage compromise”. The attackers use the initial stage victims as “pivot points” or bots to attack other systems and networks that are visible from their initial victim.

Commonly, the attacker will install bot-net software capable of scanning other systems and exploiting a few key vulnerabilities and bad passwords. These flaws are all too common and are likely to get the attacker quite a bit of success. The attacker then commands the bot victim to scan on new connections or at designated times, thus spreading the attacker’s presence and leading to deeper and deeper compromise of systems and data.

This pattern can be combated in a number of ways. Obviously, organizations can fight the initial stage compromise. Headway has been made in many organizations, but the majority are still falling quite short when it comes to protecting against a growing diverse set of attack vectors that the bot herders and cyber-criminals use. Every day, the attackers get more and more sophisticated in their campaigns, targeting and approach. That said, what can we do if we can’t prevent such attacks? Perhaps, if we can’t prevent them easily, we can strengthen our defenses in other ways. Here are a couple if ideas:

One approach is to begin to embrace enclave computing. This is network and system trust segregation at the core. It is an approach whereby organizations build their trust models carefully, allowing for initial stage compromises and being focused on minimizing the damage that an attacker can do with a compromised workstation. While you can’t prevent compromise, the goal is to create enough defensive posture to give your team time to detect, isolate and respond to the attack. You can read more about this approach in our 80/20 rule of Information Security.

A second idea is to use HoneyPoint decoy hosts on network segments where exposures and initial stage compromise risks are high. These decoy hosts should be dropped where they can be easily scanned and probed by infected hosts. VPN segments, user segments, DMZs and other high exposure areas are likely candidates for the decoy placement. The idea is that the systems are designed to receive the scans. They offer up services that are fake and implemented just for this purpose. The decoy systems have no other use and purpose than to detect scans and probes, making any interaction with them suspicious or malicious. Decoy services, called HoneyPoints, can also be implemented on the servers and other systems present in these network segments. Each deployed HoneyPoint Agent ups the odds of catching bots and other tools deployed by the attacker in the initial stage compromise.

Both of these strategies can be combined and leveraged for even more defense in depth against initial stage compromises. If you would like to learn more about how these tools and techniques can help, drop us a line or give us a call. We would be happy to discuss them with you.

In the meantime, take a look at how your team is prepared to fight initial stage compromises. What you find may be interesting, especially if your team’s security focus has been on the firewall and other perimeter controls.