Tag Archives: malware

3 Changes in Crimeware You Can Count On

Posted on by
1

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.

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

Posted on by
Reply

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!

A Quick Word on LiveCD’s and Bootable USB for Consumers

Posted on by
Reply

I gave a quick interview today for a magazine article to be printed in late July. The topic was pretty interesting; it revolved around consumer fears about online banking.

The key point of the discussion was that financial organizations are doing a ton of work on securing your data and their systems from attack. The major problem facing online banking today is really the consumer system. So many home PCs are compromised or infected today that they represent a significant issue for the banking process.

The good news is that home systems can pretty easily be removed from the equation with a simple bootable LiveCD or USB key. It is quite easy (and affordable) to create Linux distros with very limited applications and security measures that enforce using it just for banking and other high risk transactions. Solutions in this space are available in open source, community/payment supported and of course, full blown commercial software tools complete with a variety of VPN, access control and authentication tools.

You might even consider creating your own open source distro, labeled and logo branded to distribute for free to your customers. A few of my credit unions are taking this approach. For the cost of CD duplication, they get the high trust customer contact and peace of mind of having a dedicated, trusted platform for their home banking. That, indeed, may be well worth the investment.

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.

HoneyPoint Decoy Host Pays Off

Posted on by
Reply

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?

Choosing Your OS is NOT a Security Control

Posted on by
Reply

Just a quick note on the recent Google announcement about dumping Windows for desktops in favor of Linux and Mac OS X. As you can see from the linked article, there is a lot of hype about this move in the press.

Unfortunately, dumping Windows as a risk reducer is just plain silly. It’s not which OS your users use, but how safely they use it. If a user is going to make the same “bad computing hygiene” choices, they are going to get p0wned, regardless of their OS. Malware, Trojans and a variety of attacks exist for most every, if not every, platform. Many similar brower-based attacks exist across Windows, Linux and OS X. These are the attack patterns of today, not the Slammer and Code Red worm attack patterns of days gone by.

I fail to see how changing OS will have any serious impact on organizational risk. Perhaps it will decrease, a very small amount, the costs associated with old-school spyware and worms, but this, in my opinion is likely to be a decreasing return. Over time, attackers are getting better at cross platform exploitation and users are likely to quickly feel a false sense of security from their OS choice and make even more bad decisions. Combine these, and then multiply the costs of additional support calls to the help desk as users get comfortable and have configuration issues in the enterprise, and it seems to me to be a losing gambit.

Time will tell, but I think this was a pretty silly move and one that should be studied carefully before being mirrored by other firms.

Piracy as a Crimeware Defense

Posted on by
3

So, just a quick thought on this one. What if we, as security folks, made a serious endeavor to reduce the earning capability of those who create crimeware, spyware and other malware? What if we did to them exactly what the gaming companies and MPAA have been saying is killing their business? What if every time we saw a piece of “licensed” crimeware tool, we cracked it and published keygens and other cracks for it?

Sure, in the mid-term there would be more attackers able to use the malware. But, what if, in the longer term, less malware were actually created? What if the bar went up to the point where publishing these tools was no longer profitable? Would the numbers and evolution of malware be slowed?

I am asking, not because I have an answer in mind, but because I am curious. At what point does striking at the root of the profitability of criminals reduce their efforts and capabilities? Anyone with ideas or experience in this line of thought, please leave a comment below. Thanks for reading and I look forward to your responses.

AV Versus Old and New Bot Code

Posted on by
Reply

Today, in my research work on the data from the HoneyPoint Internet Threat Monitoring Environment (HITME), I uncovered an old (2008) piece of PERL code embedded inside a PHP bot-net infector client that I discovered from the HITME logs. This perl code was included in the PHP bot as a base64 string, which is quite common. The PHP code unencodes the perl script and drops it on your hard disk when the PHP bot herder wants to have a reverse shell to execute commands on your system.

In this case, the placement of the PHP bot was via PHP Remote File Injection, so the malware would be placed on your victimized web server. For enterprises, that means that if your web server got hacked in this way, then you would expect your anti-virus to be the last line of defense for protecting you against this malware.

Here’s where it gets weird. AV detection was absolutely horrible for both of these pieces of code. For the perl backdoor, the detection rate at VirusTotal was just 55% and that code has been known for years. For the PHP bot, in its entirety, the total was even worse with detection rates of just 46%.

Even worse to me than the percentages are the vendors that caught vs missed these simple scripts. Check the list for your AV vendor, because I was shocked to see that some of the big name, enterprise class products missed these forms of malware entirely. Some of the small freeware vendors we might expect to miss some of the malware targeted at servers, but I would think we should expect more from the enterprise AV vendors, especially if you read the hype of their marketing.

Now, a lot of folks are going to say, of course AV misses stuff. There’s polymorphic code out there, Brent, and a lot of the bad guys have really spent a ton of resources to obfuscate and modify their code on the fly. I agree with this. But, in this case, we are not talking about custom designed binary code with trapdoors, memory injection, polymorphism or anything of the like. These are simple script files, in plain text. Neither of them is obfuscated. You can see the PERL back door code for your self. I just published it on my Posterous blog for supporting materials. I think after you check that out, you can see that the “complex malware code” argument, just doesn’t hold water in this scenario.

The bottom line is this, your AV software and other mechanisms that are heuristics based are likely not doing the job of protecting you that you might imagine. Just something to keep in mind when you do your next risk assessment, threat model or the like.

Thanks for reading!

Interesting Bot News

Posted on by
Reply

In the last couple of days, there have been a couple of interesting pieces of bot-net news.

This one, discusses how a bot-net software war is brewing over control of your PC. Some bots are now including kill code for other bots. In this case, the new kid on the block is killing zeus code to make sure it has sole control over your fraud.
Then there was this one about ms10-015 where the bot authors have fixed their rootkit code to make the BSOD go away. They did this not as a favor to MS or anything, but to restore use of the PCs and their chain of fraud. They also wanted to cover up their own code to keep users from cleaning it.
Interesting stuff around the bot threat landscape….

Expect More Worms

Posted on by
Reply

The team at PandaLabs has discovered an application that converts any given executable into a worm. Apparently originating in Spain the tool allows a user to wrap any executable in worm code using a simple GUI interface. There are options for enabling Mutex, UPX compression, and disabling various operating system components. We will continue to see these types of tools lower the technical threshold of attackers and increase the number of malicious agents increase in the wild.

Security practitioners need to continue to assist their clients in developing defense in depth strategies that will reduce risk and exposure to these threats. Key elements to address would be identifying key at risk assests, moving towards enclave computing and adding more rigorous security testing of Internet facing applications (slowing their deployment if necessary). The need for security awareness training that is both engaging and current will continue to increase.

For more details on the tool itself you can visit:  http://pandalabs.pandasecurity.com/archive/T2W-_2D002D003E00_-Trojan-to-Worm.aspx