V. Yakobchuk - Fotolia
While modern malware far surpasses it in functionality and sophistication, Conficker has entrenched itself far into the many corners of the Internet, demonstrating the massive efforts needed to fully clean the Internet of widespread malware. It also foreshadows the problems Internet of Things (IoT) devices and devices with long lifetimes can bring -- problems enterprises should be prepared to address sooner rather than later.
Learning lessons from not only the initial Conficker botnet attack, but also the current state of Conficker cleanup is critical to being prepared for such an event in the future.
Current state of Conficker cleanup
Once the Conficker botnet left the headlines, many people promptly moved on to the next attention-grabbing malware. Behind the scenes, though, significant efforts were being made to respond to Conficker and eradiate it from the Internet. The command-and-control infrastructure was taken over and the botnet sinkholes created to monitor the infected systems were analyzed (sinkholes are systems set up to specifically monitor for connections from infected computers). While this is typically unglamorous work, it is critical to maintain trust in the operation of the Internet.
This year, researchers at Delft University of Technology analyzed the data from Conficker sinkholes to evaluate if the nationwide anti-botnet efforts were indeed effective.
Despite the national response effort, the sinkholing seven years ago has still left nearly 1 million machines infected. So what's the cause? Researchers found that nations with lower uses of technology or more unlicensed software have high infection rates, and the clean-up of infected computers has proven to be slower than the replacement of machines running Windows XP.
The researchers also reported that "some ISPs may have judged the neutralized botnet [as] an insufficient threat to merit remediation," therefore many ISPs may not have devoted the necessary resources to coordinate with the national anti-botnet response effort. This would likely result in an ISP not notifying customers they are infected or not taking other critical remediation actions.
Additionally, some of the machines still infected today appear to be outside the reach of the efforts of anti-botnet organizations, antimalware vendors, Microsoft and ISPs; these machines unfortunately may stay infected indefinitely. Research has also proven that Conficker-infected systems are at higher risk from other botnets; there is a 6% to 15% overlap in Conficker and GameOver Zeus.
Lessons learned from the Conficker botnet
Many of the challenges of remediating Conficker-infected systems have occurred on non-enterprise systems, but the same lessons will apply to enterprises as more consumer-based devices connect to enterprise networks.
One of the main takeaways from the Conficker botnet incident is that enterprises must gather contact information for endpoints in order to notify users that their device is infected. However, this task can be challenging because of DHCP churn and IPv6 visibility problems. DHCP is handled differently in IPv6, but as more devices connect to networks and IPv4 space depletes, visibility into IPv6 for future botnet remediation will be critical. Though having contact information for endpoints and tools would not necessarily have changed how systems were remediated, it could help enterprises notify their end users of an issue and explain how to fix it, potentially making remediation that much quicker.
Another important lesson learned is that providing easy access to remediation tools and automated patching requiring no intervention by the end user are the most effective methods of fixing infected endpoints. Similarly, reinfection was a problem for some systems that could not download security updates or had their network access restricted so they couldn't download remediation tools from approved sources. Given the large number of infected systems, it is unlikely that all of the endpoint owners had the technical skills needed to remediate their systems. Therefore, having resources from a coordinated response center could help users who want to remediate their system themselves. Coordinated response centers could also provide end users with the automated tools to remediate their systems, or, in the case of Conficker, just steer users to Microsoft's Malicious Software Removal Tool, which could detect and remove the worm.
Some ISPs stopped responding to the Conficker botnet because of its perceived low risk and the resources needed for response. However, it is important to note that some infected systems may not be able to be blamed on end users; for example, forgotten embedded systems are most effectively addressed by ISPs; without ISP coordination, remediating these embedded devices could be impossible. This is yet another lesson to learn from the Conficker botnet; ensuring ISP coordination can help prevent future botnet responses from taking seven years -- or longer. Though the Delft University researchers found that anti-botnet initiatives were not effective in the case of Conficker, this could be due to the slowness of starting the response effort and the fact that the response started after the Conficker botnet was dismantled. Using coordinated response on higher-risk or active botnets today might justify the resources needed to protect systems from further exposure.
Using lessons learned from Conficker botnet in the future
The lessons learned from Conficker are important for general incident response, but absolutely critical when planning for incident response in the Internet of Things.
Many IoT devices are expected to be in continuous operations for much longer than a standard desktop or laptop, meaning malware that is seven or eight years old will not be unexpected on such devices.
While the Delft University researchers' work didn't directly support wide-scale coordinated long-term remediation efforts, it did report that the country with the longest coordinated response had the lowest infection rates, thus supporting the long-term view.
Enterprises can also use a long-term view and apply it broadly to IoT devices to help ensure device trust and security.
About the author: Nick Lewis, CISSP, is a program manager for the Trust and Identity in Education and Research initiative at Internet2, and previously was an information security officer at Saint Louis University. Lewis received Master of Science degrees in information assurance from Norwich University in 2005 and in telecommunications from Michigan State University in 2002.
Here are five steps to ensure botnet removal