Welcome Guest. | Log In| Register | Membership Benefits
  • Email this page E-mail this page
  • |  Print Print this page
  • |   Bookmark and Share

Rival Botnets Share a Common Bond, Researchers Find

But world's biggest botnets Rustock and Srizbi remain autonomous

Aug 20, 2008 | 09:42 AM

By Kelly Jackson Higgins
DarkReading

Two of the world’s largest and most prolific spamming botnets have been spotted sharing a common bot malware-delivery method. But whether that means that the operators of the rival Rustock and Srizbi botnets are actually in cahoots is unclear, security researchers say.

Rustock, which recently edged Srizbi for the top slot as the biggest spammer mostly due to a wave of fake Olympics and CNN news spam, and Srizbi, known for fake video and DVD spam, have been using the same Trojan, Trojan.Exchanger, to download their bot malware updates, researchers say. “This is the first time” we had seen this connection between the two botnets, says Fengmin Gong, chief security content officer for anti-botnet software firm FireEye. “That’s why when we saw it, it was surprising.” (See CNN, Olympics Spam Put Botnet in First Place and Malicious Spam Traffic Triples in One Week.)

“They definitely have a relationship,” he says. “There’s not the rivalry we used to think about.”

But Gong says the speculation by a FireEye researcher in a recent blog post on the vendor’s site that the two botnets are run by one operator -- namely the Russian Business Network -- is not conclusive at this point, however. “We would need more information to conclude that,” he says. “In this instance, at a minimum we can say these two botnets are actually using the same carrier for their updates.”

Other researchers say they have witnessed a recent overlap between Rustock and Srizbi, too. Some say it’s spammers diversifying their spam campaigns with different botnets, and others, that it could be some sort of coordination among the bot herders or their spammer customers. Either way, they all agree that the two botnets remain separate networks of zombies with distinct command and control infrastructures.

“They are not one in the same, although they have some overlap. If you take down one, the other will continue to persist,” says Paul Royal, principal researcher with Damballa.

Royal says the two botnets may be using a common “exchanger” service, a service that puts their malware onto victims’ computers. “That service may spam the emails to put the software on people’s computers,” he says. He says he’s seen similar connections among other botnets, namely Srizbi, Storm, Zlob, and Zbot: “We found in data-mining sample last fall a Trojan dropper... that had downloaded seven different binaries. Among them was Storm and Srizbi.”

Joe Stewart, director of security research for SecureWorks, says the Srizbi-Rustock connection is most likely due to a spammer using both zombie networks -- not that the operators of the two botnets are actually collaborating. “What is confusing people is that you’re seeing Rustock bots sending out emails that essentially infect people with Srizbi, so they think it must be Srizbi that’s sending it, but it’s not,” he says. “Srizbi is not just one big model. It’s rented out to lots of different spammers."

A major spammer may be trying to diversify by using the two botnets, he says. “It could be because they want to separate their malware-seeding operation from their spamming operation,” Stewart says. “Maybe their bots are getting blacklisted faster when they’re sending out URLs with fake video files because they’re easy to spot, so their spam doesn’t get through. So they send malware from this botnet, and spam from this one, to keep out of the blacklists longer.”

And given that botnets are constantly evolving -- shrinking, growing, and segmenting -- it’s tough to get an accurate or up-to-date read on their relationships, anyway. “They are very much a moving target,” says Glen Myers, an engineer with Marshal.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.

  • Damballa Inc.
  • FireEye Inc.
  • SecureWorks Inc.
  • Marshal Inc.


  • Subscribe to RSS










    Bugs
    ENTERPRISE VULNERABILITIES
    Vulnerability:cxf
    Published:2010-08-19
    Severity:High
    Description:Apache CXF 2.0.x before 2.0.13, 2.1.x before 2.1.10, and 2.2.x before 2.2.9, as used in Apache ServiceMix, Apache Camel, Apache Chemistry, Apache jUDDI, Apache Geronimo, and other products, does not properly reject DTDs in SOAP messages, which allows remote attackers to read arbitrary files, send HTTP requests to intranet servers, or cause a denial of service (CPU and memory consumption) via a crafted DTD, as demonstrated by an entity declaration in a request to samples/wsdl_first_pure_xml, a similar issue to CVE-2010-1632.
    Vulnerability:libvirt
    Published:2010-08-19
    Severity:Medium
    Description:Red Hat libvirt, possibly 0.6.1 through 0.8.2, looks up disk backing stores without referring to the user-defined main disk format, which might allow guest OS users to read arbitrary files on the host OS, and possibly have unspecified other impact, via unknown vectors.
    Vulnerability:libvirt
    Published:2010-08-19
    Severity:Medium
    Description:Red Hat libvirt, possibly 0.7.2 through 0.8.2, recurses into disk-image backing stores without extracting the defined disk backing-store format, which might allow guest OS users to read arbitrary files on the host OS, and possibly have unspecified other impact, via unknown vectors.
    Vulnerability:libvirt
    Published:2010-08-19
    Severity:Medium
    Description:Red Hat libvirt, possibly 0.6.0 through 0.8.2, creates new images without setting the user-defined backing-store format, which allows guest OS users to read arbitrary files on the host OS via unspecified vectors.
    Vulnerability:libvirt
    Published:2010-08-19
    Severity:Low
    Description:Red Hat libvirt 0.2.0 through 0.8.2 creates iptables rules with improper mappings of privileged source ports, which allows guest OS users to bypass intended access restrictions by leveraging IP address and source-port values, as demonstrated by copying and deleting an NFS directory tree.


    Briefing Centers
    POWERFUL INFORMATION
    AT YOUR FINGERTIPS
    (SPONSORED LINKS)