In 2002, many of the IT security incidents we responded to involved vulnerable Windows IIS web servers. During the past few years, many firms with a large internet presence have initiated patch management or vulnerability management plans to withstand the barrage of attacks that are geared to exploit the "low hanging fruit" on victim networks. Therefore, most of the attacks that attempt to exploit vulnerable services on internet-facing systems have been rendered less effective. This might be the cause of the trend shift in 2003 and 2004. The attacks we have seen in that time have many different exploit mechanisms. We have witnessed the negative impact and nuisance of automated, self-propagating computer intrusions that promote widespread compromise and seriously complicate remediation efforts.
These automated intrusion worms often spread on victim networks via the user's valid Windows credentials. The attacks can spread very rapidly, opening client-side backdoors on your networks. If your organization has enterprise-wide administrator accounts, this type of attack can propagate at alarming rates, opening backdoors across your entire enterprise in a matter of minutes. To make matters even more complex, the creators of such worm-like computer intrusion tools choose the payload, thereby limiting the effectiveness of most anti-virus software.
The worm often works by brute-forcing the administrator credentials on a system that is not guarded by a firewall. Therefore the worm has access to, and can connect to, port 139 or port 445. This suggests that the potential avenue for the initial intrusion is via wireless access points, or via laptop systems that employees carry home with them to unprotected networks.
It has been our experience that the unarmed and unprepared laptop, when removed from the protections of the workplace, is usually the culprit for unleashing these automated intrusion worms into victim networks.
If the worm breaks the "administrator" account on a system, then it uses "psexec.exe" to upload and execute an extractor program. The following command is similar to those we have seen executed by worms: psexec.exe -u administrator -p "" -c tools.exe -d
This line of code would log into the victim system using the "administrator" account, without a password, and then upload and execute a file called "tools.exe". The extractor program, called "tools.exe" in the command line above, would contain dozens, if not hundreds, of scripts, libraries, and executable files tailored to the desires of the author of the extractor kit. In one instance, we responded to an extractor tool that immediately populated the "c:WINNTsystem32driversdisdn" directory with over 60 files, including backdoors, keystroke capture software, and software that kills processes such as anti-virus applications.
In many cases, the client-side backdoor initiated was an IRC client, usually installed as a service using the "srvany.exe" tool from the Windows Resource Kit. Once the IRC client was installed as a service, it was configured to connect to a rogue IRC server on a commonly used port such as port 21. Once a victim system was re-booted, it immediately performed a connection to the rogue IRC server on port 21. At this point, the IRC backdoor was very effective; using commonly used ports to evade firewall rule-sets, overcoming the safeguards provided by network address translation by having a client-side backdoor run on the victim system, and restarting every time the victim system was rebooted.
Since these automated intrusion worms propagate outside the control of the attacker, it is often very difficult to determine the true source of an attack. As an attacker, you can unleash one in the wild and, five days later, have administrator-level access to several thousand systems. One of the more frustrating aspects of these types of attacks is the fact that they are so widespread. It only takes one infected system to re-propagate and spread the infection across your network.
We have responded to dozens of similar cases to the one just described. In each one of them, our primary goals were to investigate and perform the following tasks:
- Identify all modes of entry by the attackers;
- Determine the number of compromised hosts;
- Determine the appropriate network-based, host-based, and procedural countermeasures required to secure the network and sustain a heightened posture of security;
- Perform a damage assessment of the information that was compromised.
The lessons learned by the organizations attacked were exceptional, and numerous, but three of the common lessons were: a well-prepared incident response capability is crucial; a standard build or common operating environment fosters earlier detection and a more effective response; and remediation requires real commitment from top-level management.
The organizations that were victims to these attacks usually developed a well-honed incident response capability. They developed pre-made toolkits to perform host-based data collection, and also ironed out the best methods to perform network security monitoring. When determining the full extent of any compromise, it is critical that responders use tools that quickly allow them to determine the host-based and network-based indicators of the attack.
Many organizations realize the value of developing standard builds and performing baselines of these systems. This would allow a more rapid detection of anomalies on their network.
Kevin Mandia is president and founder of Red Cliff Consulting
