Tag Archives: HoneyPoint

HoneyPoint Event Stats

Posted on by
Reply

I have gotten a few inquiries about the average number of events per day that HoneyPoint Security Server deployments catch on average networks. While this question is pretty hard to answer in a general sense, since most networks differ by size, deployment security, policies and processes, we can talk about averages across multiple client networks and our own HoneyPoint sensor networks.

On average, Internet visible HoneyPoint deployments usually experience around 4 events per HoneyPoint deployed per day. This can vary depending on services emulated, but in general, adding smtp and web (the two largest receivers by far) against those deployed on rarely scanned ports yields this average over time. Those are amazing statistics when you consider that each of those is a genuine probe/scan event or attack! Many clients use Internet facing sensors as a means of populating black hole lists, web application address filters and other prevention focused mechanisms. Less often, clients use this information as means to perform risk assessment and response, meaning that they actively track this data and the sources and take a manual action. Usually clients use Internet exposed HoneyPoints as a source of threat intelligence, trend tracking for frequency and source variations and automated blocking configurations.

Internally, most clients experience 3-4 events per month on average. These events are usually treated very seriously, since any HoneyPoint traffic internally is suspicious at best and malicious at worst. Most security teams leveraging HoneyPoint use these events as triggers for true security incidents. They launch full investigations and either mitigate or minimize the discovered issues. They are able to do this and focus on these critical events due to the low number of them they experience, the lack of false positive events they see and the placement of the HoneyPoints close to the actual assets they are tasked with protecting. Many clients have moved away from using NIDS as any type of action item at all, and refer to their NIDS deployments only as forensic and correlation data for incidents triggered from HoneyPoints and log analysis/log management solutions.

While HoneyPoint Security Server is not a panacea for information security, it is a very strong addition to a security program. Clients are continually discovering new uses, new capabilities and new ways to leverage the system to further reduce their resource requirements. HPSS has proven to be a low noise, high signal, effective, traditional approach to providing threat management, security intelligence and detective capabilities for organizations of any size.

If you are interested in hearing more about the averages and what you can expect from a HoneyPoint deployment, just let us know. Give us a call or drop us a line and we will be happy to share the metrics we have with you!

Port Mining with HoneyPoints

Posted on by
Reply

Myself and a client have been playing around with a new technique that we are calling port mining. In this approach, we use HoneyPoint Security Server and HoneyPoints deployed in key locations to mess with worms, scans and tools.

The process is very very basic. We basically configure a simple HoneyPoint so that instead of sending the various text files it usually sends down the connection it sends a large binary file like an MP3, ISO or other binary data. Then we deploy the HoneyPoint and have it listen on a port for incoming traffic.

When the HoneyPoint gets a completed TCP connection, it immediately shoves the binary content down the pipe. It then waits for a response and sends either the same file again or another file. Very basic, right? Yes, indeed. However, we have seen three effects from this process:

1. In many cases, the file transfer of the first huge file completes and the connection dies with a timeout. In our lab testing, this was due to the unexpected input size and content of the data sent from the HoneyPoint, which has caused multiple forms of tools and malware to simply crash.

2. In other cases, we have seen the file transfer complete and the tool or malware respond only to get the file again down the pipe. We have watched this process act like a LaBrea scenario where the tool, scan or malware is significantly slowed by the data (of course, we are also using a lot of our own bandwidth) and in some cases we were able to cause the MS08-067 scans we were seeing to wait up to 50 mins for each 8 MB MP3 we sent and do this hundreds of times! Effectively, we slowed down that system from further scans while it kept playing with our HoneyPoint.

3. In very few cases, we see the connection terminate upon partial sending of the binary data. In about half of these cases, the connection terminates properly (so likely we had no effect) but in the other half, we see odd disconnections (unknown, but possible crash of the malware). In the lab, we have seen this happen with a few tools due to unexpected inputs causing exceptions in the code.

Now, it should be said, that we are just “playing” with this approach. We are not sure how or if this will be beneficial to anyone, but it was a fun idea to mess with scanners and such in such an easy way. Give it a try and let us know what you think!

PS – Extra points (and fun) can be had for finding the worst MP3 of the most horrible songs that have the largest effective use as a port mine defensive component. So, bust out your one hit wonders MP3 collection and see how your milage varies. 🙂

MS08-067 – The Worm That Wasn’t – Wait… Might Be?

Posted on by
Reply

So, the worm based on MS08-067 was rumored last week and now SANS confirms that the worm is spreading from at least one host. SANS is blaming 61.218.147.66. We also have seen scans from 208.23.24.52, 66.100.224.113, 97.89.26.99, 219.158.0.96, 88.178.18.41, 91.142.209.26, 189.20.48.210, 212.122.95.217, 131.118.74.244, 84.3.125.99, 81.57.69.99 and a ton more. Those started to increase dramatically starting this morning around 9:25 am Eastern and have continued throughout the day.

HoneyPoints on consumer bandwidth networks and commercial ISP’s alike are picking up a spike in 445 scans and traffic.

Obviously, given the metasploit framework’s improvement of the exploit in the last week or so and the myriad of proof of concept tools that have been filtering around the underground, the threat of a worm is a reality. Worm code was first announced several days ago, but seemed to fail to propagate likely due to the lack of port 445 being available on most Internet connections. However, it appears that some victims have been found and have been slowly accumulating.

While we are not yet seeing the massive scans and probes associated with the worms of the past, we are beginning to see traffic levels that indicate increasing worm behaviors.

Obviously, if you have not yet ensured that port 445 is blocked at your Internet connection, you should immediately do so. HoneyPoint users can also setup TCP listeners or basic TCP HornetPoints to discover and attempt to “defensive fuzz” the worm code. Mixed results of causing termination have been shown so far, but our lab is working on a HornetPoint configuration to cause exceptions in the worm code in a stable manner.

HoneyPoint TCP listeners can be deployed on Linux boxes and other platforms where port 445 is undialated and used to identify hosts performing 445 scans and probes. This is an excellent approach to finding laptops and portable devices that might be infected on the internal network.

HoneyPoint Personal Edition Key Change in Upcoming Versions

Posted on by
Reply

Please be aware that new versions of HPPE in the works will be using a new key mechanism. The current key mechanism appears to have fallen prey to piracy and a key has been identified in several “WAREZ” distribution sites. It appears that the current key that was leaked was made public after the software was awarded as a prize at a local public IT event. We have received several reports of web sites hosting the current version of the software with the leaked key and of several torrents floating about the Internet.

Thanks to those who reported the issue and who alerted us to the presence of the leaked key. We urge any illicit users to register their software and purchase a valid copy from our site here. Your continued support of the product will allow us to continue to improve the product.

While software piracy is regrettable, we of all people, know that essentially any type of software license can be defeated. We have and will continue to make our software licenses as convenient for our customers as possible. In our opinion, ease of use is key!

Please note that HPSS keys are unaffected as the product is licensed using an entirely different mechanism that is host specific. HPPE licenses depend solely on a custom generated numeric key sequence.

Why Replacing Internal NIDS with HoneyPoint is Critical to Your Organization

Posted on by
Reply

We are in a new age of information security. The primary threats to our critical data assets are well within the firewalls and layered architectures of the degenerative “perimeter”. Attackers can and will leap your firewalls, tunnel through your DMZs and trick your users into being the gateway to attack. The idea of the walled castle as a form of defense is destroyed and no longer serves anyone well.

With 55% of all attacks that cause financial damages to organizations originating internally, it makes sense that organizations change their focus to internal prevention, detection and response. But using a “false positive generator” like Snort!, Proventia or other NIDS approach is just madness. These mechanisms are so fraught with bad data when focused on the typical internal network that applying any attention to them at all is a huge waste of resources. Of course, the vendors will respond with their magic phrases – “tuning” and “managed service” both of which are just marketing speak for “spend more time and resources that you already don’t have on making our tool actually useful”. Don’t believe me, just ask them about applying their tool to a complex internal environment. Our polls, interviews and questions to users of these technology showed immense amounts of time, money and human resources being applied to keeping signatures up to date, tweaking filters and rules to eliminate false positives and spending HUGE amounts of security team time to chase ghosts and sort out useful events from the noise.

Our initial metrics, as we discussed previously showed that we could cut those resource requirements by 60-90% using a different approach. By leveraging the power of HoneyPoints, their deploy and forget architecture and their lack of false positives your organization can reap the reward of better security with less time, money and work. By combining HoneyPoint Security Server and an appropriate log monitoring tool (like OSSEC), organizations have been able to greatly simplify their deployments, reduce their costs and increase their abilities to focus on the security events that matter. Many have relegated their NIDS deployments at the perimeters to being another source of forensic data to be used along with syslog server data, file system analysis and other data sources compiled to provide evidence when a true incident occurs. NIDS at the perimeters have their value here and being a part of solution as a forensic tool makes them effective when needed, but prevents the “attention overload” that they require when used as a data source on a daily basis.

Detection of attackers in your environment IS CRITICAL. But the way you go about it has to make sense from both a security and manageability standpoint. NIDS has proven to be an ineffective solution in terms of allowing organizations with average resources to succeed. There is a way forward. That way is to change the way we think about information security. HoneyPoint Security Server and MicroSolved can help your organization do just that!

Check out http://www.microsolved.com/honeypoint/ for more information, or give us a call and we will be happy to explain how it works!

Please note: Snort! and Proventia are trademarks of their respective companies. They are great tools when applied to appropriate problems, but in the case of internal network security – we just have a better way! 🙂

HPSS And OSSEC

Posted on by
Reply

I’d like to go over some of the tools that we mention on the blog. The first one I’d like to take a look at is OSSEC. You may have heard of us talking about it before, we mentioned it a few days ago. That was in relation to HoneyPoints and using OSSEC as another layer of your “defense in depth” strategy. I’ll explain what it does, and how it can help you.

First of all, what is OSSEC? OSSEC is an acronym for “Open Source Host-based Intrusion Detection System”. From the name you can see it’s a Host-based Intrusion Detection System (HIDS). As a HIDS it has the capability to do log analysis, integrity checking, Windows registry monitoring (and event log), rootkit detection, real-time alerting and active response against malicious hosts. It can be run locally, or as a centralized system with agents running on hosts.

So how does OSSEC relate to HoneyPoint? Well they both watch different things, and complement each other. While HoneyPoints are psuedo services and capture traffic from them, OSSEC watches real services for probes and compromises. It does this largely by a system of log analysis. I won’t go into it deeply, but the log analysis rules are very configurable, chainable, and fairly easy to write for anyone that knows regex and has a familiarity of basic scripting language.

With OSSEC’s active monitoring, it’s possible for the host to dynamically write firewall rules to block that host. Similar to HoneyPoints Plugin interface, with which you could also use to write a plugin to do that. You could even use OSSEC to watch your HoneyPoint Console syslogs and integrate HoneyPoint Console triggers with its own active response rules, to centralize blocking of hosts between HPSS and OSSEC.

As you can see, OSSEC can work quite nicely with HoneyPoint Security Server as part of a “defense in depth” strategy. There’s no single tool to “rule them all”, so to speak, so it’s important to watch from multiple perspectives! If you want to check out OSSEC, you can visit www.ossec.net.

Save Time and Money with HoneyPoint Security Server

Posted on by
Reply

Well, the initial round of metrics are in. Organizations that have changed the way they think about information security can seriously benefit from changing the way they use NIDS (if they use them at all) and embracing the evolution in information security that HoneyPoint represents. Here are some pretty amazing metrics that have come back from our clients:

Strategy:

Customers who have continued to use NIDS have been able to cease daily monitoring of the alerts and relegate the NIDS to basically being a forensics tool when odd events occur.

Customers who combined our technology with a high signal, low noise log monitoring tool (such as OSSEC) have seen the largest return on investment and simplification.

Metrics:

Basically, when compared with a FREE NIDS (like Snort) using a registered rule set (with a 30 day delay), clients still achieved total cost of ownership savings of 50% by eliminating signature updates, IDS/IPS tuning and management human costs. The elimination of false positives and drastic reduction of events to process (from 5-18K per day) to less than 20 actual events per month, on average also aided these savings. The time savings they reported on average was about 90% per full time employee engaged in security monitoring!

Customers had nothing but praise for HoneyPoint’s strategy, performance and commitment to “deploy and forget” security.

That’s right! Let me recap that again: TCO reduction of 50% and time reduction of 90%! — Better security with less time and money…

The numbers increase significantly from there when compared with commercial (pay for play) software and managed services from a variety of companies. A couple of clients who were using commercial software managed services to try and manage their internal security were able to save between $30K and $82K in their first year with HoneyPoint and then up to $95,000 per year in subsequent years!

The last key point we have taken away from the quick summary of the interviews we have done so far is the amount of respect that the approach, strategy and implementation has earned from regulatory auditors. They have examined the product very thoroughly and done very deep reviews of the both the strategy and the capabilities. The outcome of these regulatory reviews, to date, have been excellent. Regulators have seemed to appreciate the forward thinking and the payoff that customers are receiving. Feedback has been excellent and continues to make us very proud of the work that we and our clients have done to bring HoneyPoint to market.

We will be putting together a more formal way to demonstrate these numbers in the near future. Our use cases and the attack results that we have been able to capture continue to come in and some simply amaze us! Stay tuned for more details as we finish analyzing the interviews and the use cases.

If your organization is interested in trying HoneyPoint and is willing to be a use case or public reference, we would like to talk to you. Deep discounts are available to firms who are willing to engage in this manner with us and we are certainly looking for more verticals outside of our existing markets. Give us a call if you would like to discuss it!

BTW – customers using HoneyPoint Security Server and HornetPoints exposed to the Internet have achieved some significant reduction is scans, probes and attacks by leveraging both “defense fuzzing” and our “one strike and you’re out black hole” approach. Let us know if you would like to hear more about how these strategies and tactics can reduce your Internet risk.

HoneyPoint:Network Trust Agent Helps IT Team Identify Serious Network Hole

Posted on by
Reply

We got a great story this week from a user of HoneyPoint:Network Trust Agent (NTA). This user touched base with us to let us know how his NTA deployment on his laptop helped his security team identify a critical network hole.

His story started as usual, he had downloaded NTA after one of our conferences and installed it on his laptop. He felt very strongly that it gave him unique insights into how safe he was as he traveled around and used a variety of public wi-fi and other networks. Users often tell us stories of catching various worms and scans with the product as they work from coffee shops, airports and hotels. Sure enough, the logs he sent us also showed the capture of several PHP scans and some other “wormy” activity against his laptop. He included that he has become a strong believer in “when the light turns red, it is time to go”.

But, his logs also showed us something else. He confided that his laptop had “gone red” while he was using his corporate protected network. Since this was unusual, he notified his network administration team. They, in turn, inspected his laptop and pulled his NTA log. Aghast, they found that the log contained evidence that an Internet host had attempted a telnet connection to his box. That should not be possible, since the firewall should be blocking all inbound telnet attempts. After a short discussion, the admin team analyzed the firewall rules and found a misconfiguration problem. Over the previous weekend, one of the administrators had needed to allow a remote vendor to telnet into a network device for some maintenance, however, the admin is question had applied the wrong netmask to the ACL on the firewall. This had inadvertently exposed the entire internal network to telnet probes from the global public Internet!

Obviously, the admin team took immediate action to properly configure the firewall and teach the administrator in question the proper method for ACL creation. They also began to look for other signs of intrusion and to examine the logs of routers, switches and other systems that could have been exposed to compromise from the error. After they had done a careful review and knew that they were OK, they took the time to have the gentleman let us know about their experience and thank us for the helping hand. “That may be the best 10 bucks we ever spent!”, one of the team members exclaimed.

Do you have a good story about how one of the HoneyPoint products has helped you? Have you caught malicious inbound traffic on your laptop at a coffee shop? If so, let us know.

If you are interested in learning more about HoneyPoint:Network Trust Agent, Personal Edition or our critically acclaimed Security Server product for enterprises, please feel free to email us at info<_at_>microsolved.com or give us a call. We would love to talk with you about how honeypot technologies and our products in particular can help you create effective, efficient and affordable security controls throughout your environment!

Morfeus Scanner soapCaller.bs Scans

Posted on by
14

Our HoneyPoint deployments have been picking up a recently added (August 08) scan signature from Morfeus, the bot-based web scanner, that has been around for a long time. The new scans were first detected on our consumer grade DSL/Cable segments in late August and have now also been seen on our Corporate environment sensors as well.

The scans check for “soapCaller.bs” and then “/user/soapCaller.bs”. Returning a 200 result code did not bring any additional traffic or attacks from the original source within 96 hours of the initial scans. In fact, returning the 200 did not seem to cause any change in behavior of the scans or any additional attacks from any source. Likely, this means that vulnerable hosts are being cataloged for later mass exploitation.

Morfeus scans are quite prevalent and can include searches for a number of common PHP and other web application vulnerabilities. Google searches on “morfeus” return about 259,000 results, including quite a few mentions of ongoing scans from the bot-net.

Here is a blog post that discusses using .htaccess rules to block scans with the morfeus user agent.

Morfeus has shown itself to be quite adaptive and seems to be updated pretty frequently by the bot-masters with new application attack signatures. The scanning is very widespread and can be observed on a regular basis across platforms and ISP types.

The soapCaller.bs page is a file often associated with Drupal content management system. There have been a number of vulnerabilities identified in this package in the past, including during our recent content manager testing project. Users of Drupal should be vigilant in patching the systems and in performing application assessments.

Forget Solutions for a While, Let’s Think Differently About Security

Posted on by
Reply

As many of you may know, this has been my mantra for the last couple of years. It was the perspective that gave birth to HoneyPoint and many of our service offerings that we have launched in the last couple of years.

I was very pleased when SANS ran this article a few days ago and when they made their initial call for ideas.

Many of the ideas that they uncovered were excellent! I especially think that there might be a future in organized education of young people around cyber-ethics, security behaviors and deeper understandings of privacy in the physical and online world. I am an obvious believer in new technical frameworks and thought processes that dynamically change the nature of the game from responsive to proactive. Further, I am a stronger and stronger believer in Honey-based technologies and in adapting attacker techniques and strategies for use against attackers. The last two years have incredibly strengthened my belief that a true key to future security is to manipulate the ability for threat agents to tell the real assets from the pseudo-assets and the true exposures from the ones that only lead to capture. I am a true evangelist of the idea that active manipulation of threat agents is a both a productive mechanism for defense and an effective control for differentiating between real, dangerous risks and non-persistent “noise” risks. While these solutions do not apply to every situation, their leverage and power do apply to a number of them and provide both excellent feedback and education as well as an intense level of engagement.

The ideas of adopting principles of genetic engineering are excellent and should be a basis for research in the future. I think the cyber world could learn a lot about data analysis, correlation and visualization by looking at the physical and medical worlds as a baseline for exploration. The data sets of the cyber world are large, but nearly as large, complex or dynamic as some human and physiological systems that scientists are tackling.

I think that if we step back from the day to day security problems we face and spend some time considering and researching “game changing” ideas, we might just find some amazing ways to change the very essence of what we do. I know attackers will always have a say in how the game is played. I know how history shines and enumerates the role of the defender. But, I also know that true evolutionary leaps are possible. True change is powerful, violent and often obvious once it has been discovered, branded and explained to us. Maybe what we need now is more discovery, more exploration and more application of free flowing thought.

As always, let me know what you think about it. You can send email responses to me or comment through the blog. The more brains thinking about the problem – the better!