Category Archives: HoneyPoint

Hackers Hate HoneyPoint

Posted on by
Reply

HackersHateHPlogoed200.jpg

We have been getting so much great feedback and positive response to our HoneyPoint products that Mary Rose, our marketing person, crafted this logo and is putting together a small campaign based on the idea.

We are continuing to work on new capabilities and uses for HoneyPoint. We have several new tricks up our sleeve and several new ways to use our very own “security swiss army knife”. The capabilities, insights and knowledge that the product brings us is quickly and easily being integrated into our core service offerings. Our assessments and penetration testing brings this “bleeding edge” attack knowledge, threat analysis and risk insight to our work. We are routinely integrating the attack patterns and risk data from our deployed HoneyPoints back into the knowledge mix. We are adding new tools, techniques and risk rating adjustments based on the clear vision we are obtaining from HoneyPoint.

This is just one of the many ways that HoneyPoint and the experience, methodology and dedication of MSI separate us from our competitors. Clients continue to love our rapport, reporting formats, flexibility and deep knowledge – but now, thanks to HoneyPoint, they also enjoy our ability to work with them to create rational defenses to bleeding edge threats.

You can bet that you will see more about HoneyPoint in the future. After all, hackers hate HoneyPoint, and in this case, being hated is fine with us!

Webcollage Agent Proxy Scans – Likely a Bot

Posted on by
2

Here is a quick example of a scan that we have been seeing a lot of lately, especially in our HoneyPoints deployed around consumer ISP networks. The example is about month old, but proxy scans are a very common occurrence.

HoneyPoint shows the following aler (some data modified for privacy)t:

XXX received an alert from 92.240.68.152 at 2008-11-08 09:57:07 on port 80
Alert Data: GET http://www.morgangirl.com/pics/land/land1.jpg HTTP/1.0
User-Agent: webcollage/1.135a
Host: www.morgangirl.com

Now, the XXX replaces the HoneyPoint location, so it remains obscured from the public.

This is a web server emulating HoneyPoint and it is listening on port 80.

The Alert Data: field shows the request received, which appears to be a proxy attempt to get a graphic.

The source of the request was 92.240.68.152 which the whois plugin shows to be (trimmed):

% Information related to ‘92.240.68.149 – 92.240.68.159’

inetnum: 92.240.68.149 – 92.240.68.159

netname: ADDIO-LTD-20080414

descr: ADDIO Ltd.

descr: Server farm Daype.com

country: LV

admin-c: AS11278-RIPE

tech-c: AS11278-RIPE

status: ASSIGNED PA

org: ORG-IOMA1-RIPE

mnt-by: lumii-mnt

source: RIPE # Filtered

organisation: ORG-IoMa1-RIPE

org-name: Institute of Mathematics and Computer Science of University of Latvia

org-type: LIR

Interesting in that the agent is likely faked as webcollage, a screen saver type application for displaying random graphics from the web. Another possibility on this event is that a previous scanner took the bait of the 200 return code from the HoneyPoint and added it as an open proxy. If that is true, then we may be on a proxy list and get to see many requests from people attempting to use open proxies. Getting a HoneyPoint added into these lists has given us great insight to web attacks, scams and phishing attacks in the past.

Now you have a variety of actions, you could block the source IP address to kill further scans and probes from that host. You could report the suspicious activities to the ISP in question. If a review of the web site that was the target showed illicit activity, you could also analyze and proceed to take actions to alert its owners as well. Many times these quick investigations have identified compromised hosts on both ends or compromised web hosts that are spreading malware. Plugins are available or can be created to automate many, if not all of these activities.

In this case, since this is simply a quick proxy attempt, and a cursory review of the target web site does not show any overt malicious activity, we will pass on this one and just use it as an example.

HoneyPoint can be used in a variety ways. Internet exposed HoneyPoints can give you deep insights into the types of targeting and exploit activity your networks are experiencing without the need to troll through immense log files or dig through noisy NIDS event patterns. HoneyPoint is great at collecting black list hosts, scanners and bot patterns. The longer clients use HoneyPoint, the more they discover that they can do with it. It becomes like a security swiss army knife to many clients.

Check out more information about HoneyPoint here. Follow me on twitter here to learn more about HoneyPoint, the threats we capture and other security and non-security info.

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!