Cyberattacks are nothing new, but recently there have been significant changes in who is capable of conducting...
them. What was once an illicit profession restricted to a highly skilled, knowledgeable and well-connected few has morphed into something that nearly anyone can undertake, thanks in large part to automated exploit kits.
These toolkits have automated the fastest-changing part of today's malware: the inclusion of exploits for newly discovered client-side software vulnerabilities.
Automated exploit kits like Zeus and Blackhole, for example, have lowered the barrier to performing cyberattacks to the point where there is almost no barrier. Criminals with minimal technical skills are now able to use an exploit kit to launch sophisticated attacks against their victims, a feat that would have been impossible just five years ago.
In this tip, we will discuss how attack toolkits have evolved and how enterprises can protect themselves both now and in the future.
The evolution of exploit kits
The first exploit toolkits were used by script kiddies in the 1990s. Published exploits from Bugtraq, Rootshell and elsewhere were utilized in scripts to attack systems when the script kiddies didn't know enough to develop the exploit themselves. Compared to those early attack toolkits, the emergence of exploit toolkits like Zeus and Blackhole over the last five years has greatly advanced cybercrime and allowed more criminals to perpetrate attacks, and both offer impressive functionality. Exploit toolkits have evolved to allow an attacker to purchase and download the toolkit, create malicious executables with specific exploits supported by the toolkit with antivirus evasion functionality, set up the command and control (C&C) infrastructure and then start sending the malware out via compromised websites or spam. The attacker then just monitors the C&C infrastructure to collect the compromised credentials or use the botnet.
The strong demand for automated attack tools that can be used with minimal technical skills has spurred the rapid evolution of these exploit kits. They have been successful, in part, because they are modular, meaning they can be developed to add on new functionality; for example, the miniFlame malware served as a module that further enhanced the original malcode of the Flame and Gauss malware. These toolkits have automated the fastest-changing part of today's malware: the inclusion of exploits for newly discovered client-side software vulnerabilities. More automated functionality can quickly be added to malware via toolkits, which could help, for example, to transfer money out of a bank account to specific, rapidly changing locations as directed by the attacker, or to automate the finding and sending of sensitive data to the attackers.
As for the future of these toolkits, in short, they aren't going away. They will continue to evolve so that they can easily incorporate functionality from the likes of Stuxnet and other advanced attacks. Enterprises should expect advanced attacks to be fully automated to the point where an attacker only needs to implement or develop one piece of custom functionality for a targeted attack on a specific enterprise's technology. These attacks may also be cross-platform and include modules for mobile devices or other platforms. In case it wasn't already abundantly clear, because toolkits make advanced, targeted attacks easier to conduct, it's increasingly likely that your organization will encounter one, if it hasn't already.
Exploit kit mitigations for now and later
Note from the author
Remember that exploit toolkits are not all bad. Depending on how you see vulnerability scanners like SATAN, Saint and many others evolving into automated penetration testing tools like Metasploit, Core Impact and Canvas, these tools could seem like exploit toolkits. How a tool is used can help determine if it is viewed as a positive or a negative. There are very few legitimate reasons for using an exploit toolkit to attack users, outside of a formal social engineering test or research.
To defend against these increasingly sophisticated and automated exploit kits, enterprises should first deploy effective, standard antimalware controls to protect themselves from malware; otherwise, it won't matter if new controls are implemented just for the new malware. The defenses that enterprises should have in place to defend against future exploit kits will change over time, but enterprises must have a security program in place that continually evaluates whether the security controls in place are effective and provide protection against current attacks. Many exploit kits use phishing or a compromised website as an initial vector. Enterprises could deploy antiphishing tools to minimize this risk and network-based tools that block malware to prevent malicious code from infecting client systems from compromised websites.
As many of these toolkits are used to target financial institutions, there are also specific mitigations that can be put in place by those organizations. Strong checks and balances on the financial systems to identify and prevent suspicious transactions will help detect the financial aspect of attacks as early as possible to minimize stolen funds. To identify whether there is a malicious attacker, access to financial systems could be limited to only known, secure systems; they could also be evaluated every time they connect to the financial system. Enterprises may want to investigate anomaly-based detection systems to possibly help detect exploited machines or malware with certain characteristics earlier.
Be sure to watch the news headlines as well. Unfortunately, word of an attack caused by an automated toolkit often doesn't break until attacks are already underway, but staying on top of the latest attack toolkit trends can be helpful in knowing the short-term attack patterns to watch for especially closely.
Malware, toolkits and automated mass cyberattacks continue to evolve at a much faster pace than the people defending and using the systems can respond. The malware community was slow to adopt standard security software practices in software development, but is now realizing the benefits of using strong software development practices in the form of these toolkits, to the detriment of enterprise security. Toolkits will only continue to grow more sophisticated as the incentive to commit such attacks grows, so enterprises must be aware of the risk they present and adjust risk tolerances and defenses accordingly.
About the author:
Nick Lewis (CISSP) is an information security architect at Saint Louis University. Nick received his master of science in information assurance from Norwich University in 2005, and in telecommunications from Michigan State University in 2002. Prior to joining Saint Louis University in 2011, Nick worked at the University of Michigan and at Children's Hospital Boston, the primary pediatric teaching hospital of Harvard Medical School, as well as for Internet2 and Michigan State University.