Quick Use Case for HoneyPoint Wasp

Several organizations have begun to deploy HoneyPoint Wasp as a support tool for malware “cleanup” and as a component of monitoring specific workstations and servers for suspicious activity. In many cases, where the help desk prefers “cleanup” to turn and burn/re-image approaches, this may help reduce risk and overall threat exposures by reducing the impact of compromised machines flowing back into normal use.

Here is a quick diagram that explains how the process is being used. (Click here for the PDF.)

If you would like to discuss this approach in more detail, feel free to give us a call to arrange a one on one session with an engineer. There are many ways that organizations are leveraging HoneyPoint technology as a platform for nuance detection. Most of them increase the effectiveness of the information security program and even reduce the resources needed to manage infosec across the enterprise!

Interview with Brent Huston: Meet “Paul,” An Attacker — Up Close and Personal

Many organizations we talk to still vastly underestimate the capability of the threat. They still think of the attackers and the hackers as folks who are trying to use canned exploits or use the latest version of metasploits to pop a bunch of boxes — that’s just frankly not true. “Paul” is proficient in eight different coding languages. [He’s skilled and learning.] That needs to become the mindset of the defender. – Brent Huston, CEO and Security Evangelist, MicroSolved, Inc.

What would you do if you met an attacker online? Give him a piece of your mind? Or dig a little deeper to find out what motivates him and how he operates? In this special interview, Brent Huston discusses a recent incident where he had such an opportunity.  In this fascinating conversation, Brent described how he met Paul and his attitude toward meeting another “up and coming” hacker. Take a listen! Discussion questions include:

  • How Brent tracked Paul down
  • What was Paul’s attitude toward Brent and his questions
  • A little about Paul and his skills
  • What does Paul use his compromised systems for?
  • What lessons can organizations draw from this encounter?

Interview Participants:
Brent Huston, CEO, Founder, and Security Evangelist
Mary Rose Maguire, Marketing Communication Specialist and moderator

Click the embedded player to listen. Or click this link to access downloads. Stay safe!

MSI Strategy & Tactics Ep. 17: Thoughts On The SCADA Breach In Springfield, Illinois

What happened with the water facility SCADA breach in Springfield Illinois? ICS-SCADA security has been on our radar for a few months, now. The recent attack on a water plant in Illinois has highlighted existing vulnerabilities that open the door to malware. In this special edition of MSI Strategy & Tactics, Chris Lay, Account Executive, interviews MSI CEO, Brent Huston on the breach. Take a listen! Discussion questions include:

  • Breaking down the nuts and bolts of the attack
  • The similarities and differences of the attack vs. the Stuxnet worm
  • What ICS-SCADA organizations can learn from this attack

Panelists:
Brent Huston, CEO, Founder, and Security Evangelist
Chris Lay, Account Executive
Mary Rose Maguire, Marketing Communication Specialist and moderator

Click the embedded player to listen. Or click this link to access downloads. Stay safe!

McAfee: 65 Million Malware Samples — And That’s Just the Tip of the Iceberg

I was fascinated by this article that came across my newsfeed earlier this week. In it, McAfee says that they have hit 65 million malware samples in the 2nd quarter of 2011. I have heard similar stories in my frequent conversations with other AV vendors this year. It seems, that the malware cat, truly is out of the bag. I don’t know about you, but it seems like someone forgot to warn the crimeware world about opening Pandora’s box.

One of the things that I think is still interesting about the number of signatures that AV vendors are creating are that they are still hitting only a small portion of the overall mountain of malware. For example, many of the AV vendors do not cover very many of the current PHP and ASP malware that is making the rounds. If you follow me on twitter (@LBHuston), then you have likely seen some of the examples I have been posting for the last year or so about this missing coverage. In addition, in many of the public talks I have been giving, many folks have had wide discussions about whether or not AV vendors should be including such coverage. Many people continue to be amazed at just how difficult the role of the AV vendor has become. With so much malware available, and so many kits on the market, the problem just continues to get worse and worse. Additionally, many vendors are still dealing with even the most simple evasion techniques. With all of that in mind, the role and work of AV vendors is truly becoming a nightmare.

Hopefully, this report will give some folks insight into the challenges that the AV teams are facing. AV is a good baseline solution. However, it is critical that administrators and network security teams understand the limitations of this solution. Simple heuristics will not do in a malware world where code entropy, encoding and new evasion techniques are running wild. AV vendors and the rest of us must begin to embrace the idea of anomaly detection. We must find new ways to identify code, and its behavior mechanisms that are potentially damaging. In our case, we have tried to take such steps forward in our HoneyPoint line of products and our WASP product in particular. While not a panacea, it is a new way of looking at the problem and it brings new visibility and new capability to security teams.

I enjoyed this article and I really hope it creates a new level of discussion around the complexities of malware and the controls that are required by most organizations to manage malware threats. If you still believe that simple AV or no malware controls at all are any kind of a solution, quite frankly, you’re simply doing it wrong. As always, thanks for reading and stay safe out there.

Massachusetts Getting Tough On Data Breach Law

From Slashdot:

“A Massachusetts restaurant chain was the first company fined under the state’s toughest-in-the-nation data breach law, according to a statement by the Massachusetts Attorney General. The Briar Group, which owns a number of bars and restaurants in Boston, is charged with failing to protect patrons’ personal information following an April, 2009 malware infestation. It was ordered to pay $110,000 in penalties and, essentially, get its *&@! together. Among the revelations from the settlement: Briar took six months to detect and remove the data stealing malware, continuing to take credit and debit cards from patrons even after learning of the data breach, said Massachusetts Attorney General Martha Coakley.”

Full Story

This is exactly why we developed our latest addition to our HoneyPoint family of products: HoneyPoint Wasp. It is a great way to monitor Windows-based desktops with minimal fuss, decreasing help desk calls while allowing the IT department to quickly take action when malware is detected. Learn more about HoneyPoint Wasp.

Learning USB Lessons the Hard Way


I worked an incident recently that was a pretty interesting one.
The company involved has an application running on a set of Windows kiosks on a hardened, private network that though geographically diverse, is architected in such a way that no Internet access is possible at any machine or point. The kiosk machines are completely tied to a centralized web-based application at a central datacenter and that’s all the kiosk machines can talk to. Pretty common for such installs and generally, a pretty secure architecture.

The client had just chosen to install HoneyPoint and Wasp into this closed network the previous week to give them a new layer of detection and visibility into the kiosk systems since they are so far apart and physical access to them is quite difficult in some locations. The Wasp installs went fine and the product had reached the point where it was learning the baselines and humming along well. That’s when the trouble began. On Saturday, at around 5am Eastern time, Wasp identified a new application running on about 6 of the kiosk machines. The piece of code was flagged by Wasp and reported to the console. The path, name and MD5 hash did not match any of the applications the client had installed and only these 6 machines were running it, with all of them being within about 20 miles of each other. This piqued our curiosity as they brought us in, especially given that no Internet access is possible on these machines and users are locked into the specific web application the environment was designed for.

Our team quickly isolated the 6 hosts and began log reviews, which sure enough showed outbound attempts on port 80 to a host in China known to host malware and bots. The 6 machines were inspected and revealed a job in the scheduler, set to kick off on Saturdays at 5am. The scheduler launched this particular malware component which appeared to be designed to grab the cookies from the browser and some credentials from the system and users and throw them out to the host in China. In this case, the closed network stopped the egress, so little harm was done. Anti-virus installed on the kiosk machines showed clean, completely missing the code installed. A later scan of the components on virustotal.com also showed no detections, though the sample has now been shared with the appropriate vendors so they can work on detections.

In the end, the 6 machines were blown away and re-installed from scratch, which is the response we highly suggest against today’s malware. The big question was how did it get there? It turned out that a bit of digging uncovered a single technician that had visited all 6 sites the previous week. This technician had just had a baby and he was doing as all proud fathers do and showing off pictures of his child. He was doing so by carrying a USB key with him holding the pictures. Since he was a maintenance tech, he had access to drop out of the kiosk and perform system management, including browsing USB devices, which he did to show his pictures to his friends. This completely human, innocent act of love, though much understandable, had dire results. It exposed the business, the users, the customers and his career to potential danger. Fortunately, thanks to a secure architecture, excellent detection with Wasp, good incident planning and a very understanding boss, no harm was done. The young man got his lesson taught to him and the errors of his ways explained to him in “deep detail”. Close call, but excellent lessons and payoff on hard work done BEFORE the security issue ever happened.

Wasp brought excellent visibility to this company and let them quickly identify activity outside the norm. It did so with very little effort in deployment and management, but with HUGE payoff when things went wrong. Hopefully this story helps folks understand where Wasp can prove useful for them. After all, not all networks are closed to the Internet. Is yours? If you had infected hosts like this and AV didn’t catch it, would you know? If not, give us a call or drop us a line and let’s talk about how it might fit for your team. As always, thanks for reading!

Incident Response: Practice Makes Perfect

 

Is it possible to keep information secure? Read on to find out.

IF there is only one person that knows the information, IF that person never writes that information down or records it electronically, and IF that person is lucky enough not to blurt out the information while they are sleeping, drugged or injured, then the answer is yes…probably. Under any other conditions, then the answer is an emphatic NO! It is an unfortunate truth that no system ever developed to protect the security of information is perfect; they all can be breached one way or another. That is why it is so important to have a good incident response program in place at your organization.

And most of you out there, I’m sure, have an incident response plan in place. All information security standards organizations such as ISO and NIST include incident response in their guidance, and many of you are required to have incident response programs in place in order to comply with regulation. But how many of you practice responding to incidents to make sure your planning actually works? At MicroSolved, we’ve been involved in reviewing, developing and testing information security incident response programs for many years. And we have found that no matter how good response plans looks on paper, they’re just not effective if you don’t practice them. Practicing doesn’t have to be a big chore, either. We’ve helped many organizations conduct table top incident response exercises and they usually only last a few hours. They’ve never failed to produce valuable returns.

Unfortunately, there are no good incident response exercise frameworks available out there – we’ve looked. But it is not hard to create your own. Simply pick a type of incident you want to practice – a malware attack for example. You imagine what such an attack would look like to your help desk personnel, system administrators, security personnel, etc. and construct a scenario from that. You just need a basic outline since the details of the response will construct themselves as you proceed with the exercise.

What we have found from conducting and observing these exercises is that problems with the written plan are always exposed. Sure, maybe the plan says that this group of people should be contacted, but is there a procedure for ensuring that list is always kept current in place? Have you made pre-arrangements with a forensic specialist in case you need one? Are the help desk personnel and desk top administrators trained in how to recognize the signs of an attack in process? These are the types of issues performing simple table top incident response exercises will reveal.

Perhaps you will be lucky and never experience a bad information security incident. But if you do, you will be very glad indeed if you have a well practiced information security incident response program in place!

Opinion: Warez More Dangerous Than P0rn


A couple of vendors have been talking about how prevalent malware is in online porn these days, but during our testing of HoneyPoint Wasp, we found pirated software (or “warez”) to be among the most concerning. Pornography is still a dangerous segment for infection, but it seems that grabbing so called “cracks” and “keygens”, along with pirated programs from the web and peer to peer networks is even more dangerous.

In our testing, it took us around 1/8 of the time to find infected warez that it took to find infected pornographic sites. In fact, our estimates are that less than 10% of the pornography files we tested (excluding “codecs”, obvious Trojan Horses) were infected, while nearly 90% of the cracking and keygen tools were, in fact, malware. In many cases, the warez would appear to work, but contained a background dropper that would install one or more pieces of adware, spyware or other malicious software. Even worse, in a clear majority of our testing cases, several of these malicious programs were missed by the consumer-grade anti-virus applications we had installed on the test bed. We used the white listing capability of HoneyPoint Wasp as the control and indeed identified a large number of malicious programs that traditional AV missed.

The key point of this topic though, is that pirated software remains a significant threat to businesses without proper license controls. Particularly, small and mid-size businesses where piracy often runs rampant, present a very wide target for attackers. Good policies against pirated software, user awareness and the use of license enforcement/asset inventory tools are useful controls in ramping up protection against this attack vector.

How has your organization fared against pirated software? What controls do you have in place to reduce both the legal liability and the malware threat that warez represents?

Touchdown Task #2: Detection: How Much Malware Do You Have? #security

Our last Touchdown task was “Identify and Remove All Network, System and Application Access that does not Require Secure Authentication Credentials or Mechanisms”. This time, it is “Detection”.

When we say “detection” we are talking about detecting attackers and malware on your network.

The best and least expensive method for detecting attackers on your network is system monitoring. This is also the most labor intensive method of detection. If you are a home user or just have a small network to manage, then this is not much of a problem. However, if your network has even a dozen servers and is complex at all, monitoring can become a daunting task. There are tools and techniques available to help in this task, though. There are log aggregators and parsers, for example. These tools take logging information from all of the entities on your system and combine them and/or perform primary analysis of system logs. But they do cost money, so on a large network some expense does creep in.

And then there are signature-based intruder detection, intruder prevention and anti-virus systems. Signature-based means that these systems work by recognizing the code patterns or “signatures” of malware types that have been seen before and are included in their databases. But there are problems with these systems. First, they have to be constantly updated with new malware patterns that emerge literally every day. Secondly, a truly new or “zero day” bit of Malware code goes unrecognized by these systems. Finally, with intruder detection and prevention systems, there are always lots of “false positives”. These systems typically produce so many “hits” that people get tired of monitoring them. And if you don’t go through their results and winnow out the grain from the chaff, they are pretty much useless.

Finally there are anomaly detection systems. Some of these are SEIM or security event and incident management systems. These systems can work very well, but they must be tuned to your network and can be difficult to implement. Another type of anomaly detection system uses “honey pots”. A honey pot is a fake system that sits on your network and appears to be real. An attacker “foot printing” your system or running an exploit cannot tell them from the real thing. Honey pots can emulate file servers, web servers, desk tops or any other system on your network. These are particularly effective because there are virtually no false positives associated with these systems. If someone is messing with a honey pot, you know you have an attacker! Which is exactly what our HoneyPoint Security Server does: identify real threats!

Undertaking this Touchdown Task is relatively easy and will prove to be truly valuable in protecting your network from attack. Give us a call if you’d like us to partner with you for intrusion detection!

3 Changes in Crimeware You Can Count On

Crimeware is becoming a significant threat to most organizations. The capability and dependence on crimeware as an attack model is growing. With that in mind, here are 3 things that the folks at MSI think you will see in the next year or two with crimeware:

1. Cross platform crimeware will grow. Attackers will continue to embrace the model of malware that runs everywhere. They will focus on developing tools capable of attacking systems regardless of operating system and will likely include mobile device platform capability as well. They have embraced modern development capabilities and will extend their performance even further in the coming years.

2. Specialized crimeware will continue to evolve. Organized criminals will continue to develop malware capable of focusing in on specific business processes, keying on specific types of data and attacking specific hardware that they know are used in areas they wish to compromise. Whether their targets are general data, ATM hardware, check scanners or the smart grid, the days of crimeware being confined to desktop user PCs are over. The new breed knows how ACH works, can alter firmware and is capable of deeper comprise of specific processes.

3. Crimeware will get better at displacing the attack timeline. Many folks consider malware to be symetric with time. That is, they see it as being operational continually across the event horizon of a security incident. However, this is not always true and attackers are likely to grow their capability in this area in the coming years. Modern malware will be very capable of making its initial compromise, then sitting and waiting to avoid detection or waiting for the right vulnerability/exploit to be discovered, etc. The attacks from the next generations will have a much longer tail and will come in a series of waves and lulls, making detection more difficult and extending the time window of control for the attackers.

MSI believes that organizations need to be aware of these threats and ideas. They must get better at detecting initial stage compromises and begin to focus on closing the window of opportunity attackers now have, once they get a foothold (in most cases days-months). Prevention is becoming increasingly difficult, and while it should not be abandoned, more resources should be shifted into developing the capability to detect incidents and respond to them.