Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

3/29/2012
05:23 PM
Connect Directly
Twitter
RSS
E-Mail
50%
50%

It's (Already) Baaack: Kelihos Botnet Rebounds With New Variant

Botnet hunters debate whether Kelihos/Hlux operators can reclaim rescued bots

Less than one day after botnet hunters announced they had crippled the Kelihos.B/Hlux.B botnet, a new version of the tenacious botnet is now back up and running today.

Researchers at Seculert were the first to point out the Kelihos/Hlux botnet was in action: Aviv Raff, co-founder and CTO at Seculert, late yesterday confirmed that his firm had seen the botnet spreading via a Facebook worm despite the announcement yesterday by Kaspersky, CrowdStrike, Dell SecureWorks, and The Honeynet Project that they had knocked the botnet offline. Raff says there's still communication under way via its command-and-control (C&C) servers.

"We still see infected Kelihos.B machines, even new ones, sending spam and communicating with the C&C server," Seculert's Raff says.

But researchers from Kaspersky Lab, CrowdStrike, Fortinet, and Unveillance contend that this is a new variant of Kelihos/Hlux, not the same botnet that was taken down over the past few days. That one, KelihosB/HluxB -- which was built for spamming, information-stealing, DDoSing, as well as for pilfering Bitcoins and electronic wallets -- was sunk when the team poisoned it with their own code in order to redirect some 110,000 bots to their sinkhole server and away from the operator's control. It was about three times as large as the first Hlux/Kelihos botnet, which was crippled last fall by a team led by Microsoft and that included Kaspersky.

Marco Preuss, head of global research and analysis in Germany for Kaspersky Lab, says the new botnet activity is coming from Hlux.C/Kelihos.C, and that the one that his firm and others took down remains offline. "We confirm that a new Hlux/Kelihos sample exists, but it has a different configuration, which means it's coming from a new Hlux botnet (Hlux C). The previous generation (Hlux B) is under control by the sinkhole server. It is not uncommon for new versions of botnets to appear that are operated by the same group," Preuss says.

CrowdStrike's Tillmann Werner says the Kelihos.B-infected machines in the sinkhole set up by CrowdStrike and the other research teams can no longer be used by the botnet operators, and has confirmed that the C&C infrastructure doesn't use the Kelihos.B protocol anymore. The researchers say they diverted some 110,000 infected machines to their sinkhole server.

The new Kelihos.C variant, which Werner says was released "shortly" after the sinkhole operation began, is "completely separate" and is spreading via social networks. It contains a tweaked message format for spreading commands to its peers, he says.

CrowdStrike isn't aware of any way for the new botnet to steal back its bots from the sinkhole, he says.

Bit Seculert maintains that this new botnet activity is still Kelihos.B: "Some might call this 'a new variant' or Kelihos.C. However, as the new infected machines are operated by the same group of criminals, which can also regain access to the sinkholed bots through the Facebook worm malware, we believe that it is better to still refer this botnet as Kelihos.B," according to a blog post by the company that says more than 70,000 Facebook users were infected with the worm.

Debates aside, Kelihos/Hlux's comeback was not unexpected by the botnet hunters. But it was certainly faster than most had predicted. Why the quick turnaround?

Kyle Yang, manager of AV engine development at Fortinet, says the botnet operators obviously were ready for a takedown this time around. According to Yang's findings, the botnet operators had in their possession two "job" servers from the first Kelihos/Hlux variant taken down by Microsoft. Job servers are controlled by C&C servers.

"Pretty much those guys were ready for a takedown. They were just waiting for it," Yang says. "The reason why [they did it] so quickly was they still had two [job] servers alive" from the first botnet, he says. Those were not servers crippled by this week's botnet takedown, however, he says.

Yang says he hasn't been able to figure out just how the malware authors regained control of those two servers from the first round. The attackers also since have put up three additional job servers in support of the C version of the botnet, he says.

Unveillance, meanwhile, was able to confirm that the new variant uses a different protocol. "We can also confirm that the live sample we've been observing is what they are calling .C ... The two older binaries use well-formed HTTP and .C does not," says Karim Hijazi, CEO at Unveillance.

"In reference to Seculert's claim that because the same botmasters may be operating this new version that it should be called .B instead of .C, we disagree. Due to the change in the communication protocol, it seems perfectly in keeping with standard AV naming convention to give this a new version name," he says. "AV naming convention does not take into account distinct botnets within a given malware type. For example, the Mariposa C2 samples are still named Palevo/Rimecud, not Mariposa."

Most everyone does agree, however, that the only way to really kill a botnet is to apprehend its operators.

Next Page: Legal implications of taking over a P2P botnet? Kelly Jackson Higgins is the Executive Editor of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Bprince
50%
50%
Bprince,
User Rank: Ninja
3/30/2012 | 11:14:48 PM
re: It's (Already) Baaack: Kelihos Botnet Rebounds With New Variant
It's a non-stop game of whack-a-mole. I think it should be expected at this point that botnet operators are going to look for ways to build a more resilient network in light of the success these take downs are having.
Brian Prince, InformationWeek/Dark Reading Comment Moderator
Manchester United Suffers Cyberattack
Dark Reading Staff 11/23/2020
As 'Anywhere Work' Evolves, Security Will Be Key Challenge
Robert Lemos, Contributing Writer,  11/23/2020
Cloud Security Startup Lightspin Emerges From Stealth
Kelly Sheridan, Staff Editor, Dark Reading,  11/24/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-20934
PUBLISHED: 2020-11-28
An issue was discovered in the Linux kernel before 5.2.6. On NUMA systems, the Linux fair scheduler has a use-after-free in show_numa_stats() because NUMA fault statistics are inappropriately freed, aka CID-16d51a590a8c.
CVE-2020-29368
PUBLISHED: 2020-11-28
An issue was discovered in __split_huge_pmd in mm/huge_memory.c in the Linux kernel before 5.7.5. The copy-on-write implementation can grant unintended write access because of a race condition in a THP mapcount check, aka CID-c444eb564fb1.
CVE-2020-29369
PUBLISHED: 2020-11-28
An issue was discovered in mm/mmap.c in the Linux kernel before 5.7.11. There is a race condition between certain expand functions (expand_downwards and expand_upwards) and page-table free operations from an munmap call, aka CID-246c320a8cfe.
CVE-2020-29370
PUBLISHED: 2020-11-28
An issue was discovered in kmem_cache_alloc_bulk in mm/slub.c in the Linux kernel before 5.5.11. The slowpath lacks the required TID increment, aka CID-fd4d9c7d0c71.
CVE-2020-29371
PUBLISHED: 2020-11-28
An issue was discovered in romfs_dev_read in fs/romfs/storage.c in the Linux kernel before 5.8.4. Uninitialized memory leaks to userspace, aka CID-bcf85fcedfdd.