InfoSec Insights: Getting Indexed Via Twitter – Good & Bad

Earlier this week, I did a quick experiment in the MSI Threat Lab. I wanted to see what happened when someone mentioned a URL on Twitter. I took a HoneyPoint Agent and stood it up exposed it to the Internet on port 80.

I then mapped the HoneyPoint to a URL using a dynamic IP service and tweeted the URL via a test account.

Interestingly, for the good, within about 30 seconds, the HoneyPoint had been touched by 9 different source IP addresses. The search engines, it seems, quickly picked the URL out of the stream, did some basic traffic and I assume queued the site for crawling and indexing in the near future. A few actually indexed the sites immediately. The HoneyPoint cataloged touches from 4 different Amazon hosts, Yahoo, Twitter itself, Google, PSINet/Cogent and NTT America. It took less than an hour for the site to be searchable in many of the engines. It seems that this might be an easier approach to getting a site indexed then the old visit each engine and register approach, or even using a basic register tool. Simply tweet the URL and get the ball rolling for the major engines. 🙂

On the bummer side, it only took about 10 minutes for the HoneyPoint to be probed by attacker scanning tools. We can’t tie cause to the tweeting, but it did target that specific URL and did not touch other HoneyPoints deployed in the range which certainly seems correlative. Clearly, search engines aren’t the only types of automated applications watching the Twitter stream. My guess is that scanning engines watch it too, to some extent, and queue up hosts in a similar manner. Just like all things, there are good and bad nuances to the tweet to get indexed approach.

Further research is needed in what happens when a URL is tweeted, but I thought this was an interesting enough topic to share. Perhaps you’ll find it useful, or perhaps it will explain where some of that index traffic (and scanner probes) come from. As always, your mileage and paranoia may vary. Thanks for reading!

HoneyPoint Wasp is Almost Ready to Leave the Nest

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

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!

Using Honeypots to Track Attackers: Eric Romang’s FileAve.com Report

One of MSI’s Twitter friends, Eric Romang, recently wrote a deep dive about PHP RFI attacks that used the fileave.com service. The write-up was based on a large set of honeypot data that dates back several years!

The data is interesting and compelling and goes a long way to show value derived from the use of honeypots to track attackers and reveal information and trends about their behaviors. Check out this article here.

We were quite impressed with the data visualizations and are excited to see the level of effort put forth. Thanks for the dedication and hard work! We hope that, you, our readers, enjoy pointers to great data like this.

Have you seen or done other honeypot research or visualizations on your networks and threats? If you care to share tips, results or the like, drop us a line below in the comments or via Twitter (@lbhuston, @mrmaguire). We would love to hear more about them!

As always, thanks for reading!

HoneyPoint Decoy Host Pays Off

Just talked to a client who had dropped a HoneyPoint decoy host in their VPN termination segment a couple of weeks ago. Yesterday, it paid off.

They caught a machine that had passed the anti-virus and patching requirements of the NAC for the VPN. The machine was AV scanned clean. But, immediately upon connection the machine began to port probe hosts around it. This triggered the decoy machine’s HoneyPoints, causing the security team to investigate. The machine was brought in and examined. Closer inspection found it infected with a bot tool that escaped AV detection, but was capable of scanning for bad passwords and a couple of common vulns on surrounding machines. The machine is currently being imaged and rebuilt.

This is an excellent example of how HoneyPoint can help catch bots and malware, even when other controls fail. Defense is depth pays off and the leverage that HoneyPoint provides is often quite powerful, as in this case.

Have you thought about using decoy hosts? If so, how?

VMWare Virtual HoneyPoint Host Appliance

MSI is proud to announce a VMWare appliance based on Damn Small Linux (DSL) for HoneyPoint hosting.

The VM appliance is available free from the HoneyPoint FTP site provided in your license documents. The appliance currently has all available HoneyPoints installed and configured to autostart with the installation.

Root and “dsl” account passwords are “hpss”. Obviously, please change the passwords when you configure the system!

All HoneyPoints have basic configurations provided, and will need to be edited for the location of your console. Currently, they point to 127.0.0.1.

The appliance is capable of being used in any of the VMWare products from Player to ESX and includes use in the OS X Fusion environment.

You can use the VM to emulate entire workstation(s) on the network using Player and such, or use ESX to sprinkle them around your virtual environments en masse. The image is smaller than 60Meg and needs less than 128 Meg of RAM at full utilization. In testing, we easily ran 10 of them on older machines still waiting in the lab for death or recycle….  😉

Let us know if you have any questions, or comments. We really dig this idea and folks seem to really want it.