Skip to main content

IRC Botnets: Sysyphus Part II - containment

Many organizations are struggling with containment of and invasions this week, as a result of the vulnerability and myriad variant worms exploiting it (Zotob, Spybot, Esbot, Rxbot, bobax, et. al.) Most of these organizations have patch management, firewalls, IDS and AntiVirus systems in place as part of a layered defense. They may suffer dozens or hundreds of compromised systems regardless of these efforts at prevention. The current crop of worms are nearly all bots -- remote controlled software agents that call out of your network to a remote server, looking for instructions from an attacker. Containing the outbreaks can dramatically reduce the cost of the later cleanup. If you have a large network, with a large population of vulnerable machines, and you don't have a containment strategy in place, consider the following tactics.

Network Partitioning

Consider partitioning your internal network on the ports used by the worm to spread. This worm seems to favor port 445, but some variants also employ port 139. Block these inbound at VPN and dial-up access points. Consider creating zones within your enterprise that are partitioned on these ports, at least until you get all your systems patched. If an outbreak occurs, the damage can be contained within a zone.

Egress Filtering

Don't wait for the AntiVirus vendors to capture and analyze all the variants to determine what ports to block. Start by blocking all of the standard IRC ports if you don't have a critical business need for IRC (most organizations don't). The standard IRC ports are used surprisingly often for botnet control, because they can sometimes be set up on existing IRC servers with relative ease. Although there is a small chance that someone in your organization might be using IRC for legitimate purposes, consider directing them to use a more modern Instant Message protocol, like AIM, Yahoo IM, MSN IM, Jabber/XMPP, etc. Standard IRC ports should be blocked indefinitely. There are other ports associated with IRC, registered with the IANA , but they don't seem to be in use for botnet control at this time. We might need to expand this list at a later time. Note also that several of these ports are identified as commonly used by IRC servers, but not registered with the IANA, they currently show as "unassigned"). 6660/tcp 6661/tcp 6662/tcp 6663/tcp 6664/tcp 6665/tcp 6666/tcp 6667/tcp 6668/tcp 6669/tcp 7000/tcp Also, in your perimeter routers, block and log the IRC ports used by the known variants, as documented by the various AntiVirus Vendors. During an outbreak, don't wait for a variant to hit your network. Block and log the IRC ports as soon as the variant is documented. Have someone one your team assigned to review the emergent documentation from three or four major AntiVirus vendor web sites, and update your perimeter egress filtering rules at least twice a day during an outbreak.

Disable NULL sessions

If you have a software distribution system in place, and if you haven't done it already, consider disabling NULL sessions on the Windows systems which haven't been patched yet. This can be accomplished with a tiny package and distributed much more quickly than large system patches. It appears that this will prevent an infection of an unpatched Windows 2000 system, allowing you more time to patch. Microsoft declined to confirm or deny that the UPnP vulnerability could be exploited with NULL sessions disabled, but apparently the current crop of worms and bots all rely on NULL session to perform the exploit.

Smart Bombs

Practice adroit and vigilant application of cleanup tools as part of your containment strategy, but not recovery (apologies to George F. Kennan). Cleanup tools can be deployed to contaminated systems to kill and delete the probing worm process which is spreading through buffer overflow exploits. If you can test and deploy it quickly enough, such tools can be part of a layered defense -- even if they are the "last line" of that defense. Focus testing on system compatibility -- will it accidentally wreck something on the system, making recovery harder? Probably not, but it's a good idea to check it out in your test lab. Don't squander precious time during the early phases of an outbreak by trying to validate that a cleanup tool kills every variant on your network. Deploy it only to systems that are contaminated and probing other systems. This is an attempt to slow the spread of the worm -- remember, you're engaged in containment, not recovery. If you have good reason to believe it will kill some of the variants on your network, send it out to contaminated systems after basic compatibility testing has been performed against your system image baseline. As follow-up, you can focus your limited forensics resources on the systems that continue to spew worm traffic, despite the cleanup tool, and return with an improved version to taunt the silly worm a second time.

Intrusion Suppression

Our FireBreak AntiWorm can help you identify those infected systems within moments of the start of an outbreak, and with an extremely low false positive rate (no false positives at all on a typical network). FireBreak AntiWorm can also significantly impede the progress of , allowing you more time to respond. The system is appliance based and dramatically simpler than traditional IDS systems. Our solution can be deployed very quickly, so if you're having trouble putting the lid on the worm this week, don't wait -- call us today.

Comments

Popular posts from this blog

Verified by Visa (Veriphied Phishing?)

If you have used a Visa card to make a purchase online lately you may have encountered a relatively new program, Verified by Visa . I've encountered it twice. The system is an interesting attempt by Visa to reduce online fraud and identity theft. It's a noble effort, but the user experience is unsettling, and the security implications are not exactly crystal clear. Here's what happened to me, both times the Verified by Visa system was activated. I was redirected away from the domain at which I was shopping, to a URL which was: not the domain where I was shopping, not the domain of the bank that issued my card not visa.com I've been telling people for years that if anything like that happens to you, close your web browser immediately and do not under any circumstances enter any personal information into the form, because this is a sure sign of a man in the middle or phishing scam. (Never mind that all the best phishing scams now-a-days look like the actual dom

Splunk acquires Phantom Cyber

I hope it doesn't come across as too cynical, the observation that most acquisitions in the tech domain fail to produce anything useful and often as not wind up killing a promising upstart technology, even if only by accident. I have hope for this one, though. Splunk strikes me as a likely exception. This acquisition of fresh ideas and talent might breathe new life into a solid, if somewhat staid, security company. Splunk’s data analytics gets a security boost with $350 million acquisition of Phantom Cyber

Jailbreaking iOS is a Dead Man Walking

Rumor has it that Apple will include a new security feature (possibly known to the developers in Apple as "Rootless") in the upcoming releases iOS 9 and OS X 10.11. Although details are sparse, it looks like Apple may have implemented what other UNIX systems call "namespaces" (See this nice discussion of namespaces on Linux ). Most of the public speculation about the rumor concerns a possible end to jailbreaking , a sport which has fallen on hard times with successful jailbreaks coming fewer and farther between. Since the defects which enable jailbreaking are inherently open to malware, Apple's ongoing efforts to find and fix these bugs with the LLVM/Clang compiler's ever-more-diligent static analyzer make it harder for the jailbreak community to find a toehold. However, a namespaces-like security architecture might fix one of the biggest issues that leads people to desire a jailbroken iPhone. When iOS was created, the system extension features were