Researchers knock out the grum botnet

Over on the New York Times blogs page, writer Nicole Perlroth writes about how security company SpyEye, in conjunction with Spamhaus, worked together to take down the Command-and-Control centers (C&C’s) associated with the grum botnet, purportedly the world’s 3rd largest botnet.  From the Times:

On Wednesday, computer security experts took down Grum, the world’s third-largest botnet, a cluster of infected computers used by cybercriminals to send spam to millions of people. Grum, computer security experts say, was responsible for roughly 18 percent of global spam, or 18 billion spam messages a day.

Computer security experts blocked the botnet’s command and control servers in the Netherlands and Panama on Tuesday. But later that day, Grum’s architects had already set up seven new command and control centers in Russia and Ukraine. FireEye, a computer security company based in Milpitas, Calif., said it worked with its counterparts in Russia and with SpamHaus, a British organization that tracks and blocks spam, to take down those command and control centers Wednesday morning.

So what’s to say Grum’s creators will not just run their botnet from a new command and control center tomorrow?

“It’s not about creating a new server. They’d have to start an entirely new campaign and infect hundreds of thousands of new machines to get something like Grum started again,” said Atif Mushtaq, a computer security specialist at FireEye.”They’d have to build from scratch. Because of how the malware was written for Grum, when the master server is dead, the infected machines can no longer send spam or communicate with a new server.”

This follows on the heels of Microsoft disrupting the Zeus botnet this past March and the Kelihos botnet last November.  Microsoft took flak from some researchers who complained about the company’s unilateral actions because other researchers were tracking Zeus and its disruption messed up their research. I wonder if SpyEye and Spamhaus will take similar criticism?

It is true botnet takedowns in the past don’t always last long because botnet operators just rebuild their networks.  Nobody in the security industry thinks that these last forever.  However, as Atif Mushtag says above, they have to start over and that takes time.  They have to rebuild their infrastructure and while they are doing that, they are losing money.  And sometimes, like in the case of the Rustock botnet, they don’t come back.

I took a look at our own IP statistics about who is the largest botnet.  Specifically, I looked over the past 45 days.  Below are the top 5 sending botnets by number of unique IPs:

  1. cutwail
  2. festi
  3. grum
  4. darkmailer
  5. asprox

Grum is #3, just like in the report.  According to my statistics, Cutwail is 3.5 times larger by number of unique IPs.

The other way to measure the impact of the top botnets is how many email messages they send.  Below are the top 5 sending botnets over the past 45 days by number of email messages after our IP blocks and after the messages have been bifurcated (sent to all recipients on the To: line):

  1. Cutwail
  2. Sendsafe
  3. Lethic
  4. Festi
  5. Grum

In this list, Cutwail is about 4.7 times larger than grum.  This is consistent with previous behavior I have observed, cutwail sends more mail per IP than grum does.

Finally, below is a chart of spam messages from grum hitting our network over the past 30 days:


You can see that its behavior is erratic (most botnets show patterns like this) but we also see dips a week ago as well as late June.  What’s up with that?

The answer is I don’t know.   I thought maybe I had some reporting errors (sometimes my scripts mess up).  I checked a few other botnets (cutwail, asprox, darkmailer, festi and sendsafe) and all of them have dips (except darkmailer), but not all on the same days.  This means that the scripts are working fine because the behavior is not consistent across all data sets, they are spaced out evenly.  This suggests that even botnets take vacations as the rental time expires.

Will grum recover? We shall see.

Comments (0)

Skip to main content