Athena Botnet Shows Windows XP Still Widely Used

Lately, we have seen a lot of active samples of the Athena HTTP botnet. The builder tool for Athena has already been leaked to Internet forums; we got a hold of a few active samples that have caused some pretty serious infections. The statistics found for the following web panel shows that an HTTP botnet like Athena can be very effective in damaging computers. The web panel looks to be poorly configured:



("click the images to make them larger")

The preceding image shows a lot of infections made by this botnet. Most of them are still online, receiving commands from the control server. From the statuses for this infection, we see some very scary things:

• 99.6% (465 systems) of infected machines are still using Windows XP

• 96.6% (451 admins) of infected machines have an admin user

• 73.4% (343 desktop) of infected machines are desktops (in general desktop machines remain online for a longer time)

The scariest thing is that so many people are still using Windows XP on their laptops and desktops. Microsoft will end official support for XP early next year, but this botnet infection shows people still have a love for XP.

With help from these infections, the control server has some active DDoS commands launched against certain IPs. Here is the active command page:



The network traffic generated by this botnet appears to be custom formatted and encoded to evade detection. This step makes it a little difficult for researchers to immediately decode. The binary has some old antianalysis, anti-VMware checks. If those are bypassed, it will immediately sends HTTP POST requests containing encoded data to its control server. Now let’s look at the network traffic generated by this botnet:



The encoded data looks very similar to Base64 encoded data, but we can’t easily read the information because the parameters are dependent on each other in some way (modified Base64). To decode the generated traffic we first need to understand parameters a, b, and c that are passed in the POST request. This requires a little reverse engineering. Let’s split the string into its parameters:

“a=%63%58%4A%76%62%47%6C%71%5A%32%52%6C%59%57%4A%35%64%6E%64%30%62%6D%4E%36%64%57%31%6F%63%48%68%72%5A%6E%4D%36%63%47%31%71%61%32%68%6C%5A%6D%4E%36%64%33%68%31%63%6E%4E%70%5A%47%46%32%63%57%35%35%59%6D%78%6E%64%47%38%3D”

“&b=tHR5aGU6x25tZXykY3l1wWQ6OTM0ZDZyNDBnZeNeNDElMWUuMnE3MeJg ODA2ZDYlNvI2OTZntHBuwXY6YWRiwW58YXJewDb4ODZ8Z2VqZDbgZXNmcG9st GNranVvOeF8x3M6V19YUHl2ZXI6ceEqMC44tG5kcDj0LeB8xnV3OeF8″

“&c=%68%68%65%66%62%63%7A%7A%7A%77%78%75%75%72%72%73%70%70%6D%6D%6D%6A%6B%6B”

Parameter a

Here is how parameter a is generated:



First the binary generates two random strings composed of the 26 letters from a to z and joins these strings using a colon (. Then it converts this joined string into Base64 encoding format and later converts the Base64 string into % hex format. So if we convert parameter a (via reverse steps) back into text, we get:

a=qrolijgdeabyvwtnczumhpxkfs:pmjkhefczwxursidavqnyblgto

This parameter is used to generate parameter b.

Parameter b

The parameter b is data, converted to Base64, that is sent to a control server. Here is the assembly code:



After this, the original Base64 string is modified using two random strings generated earlier. Below is the assembly snippet of the code:



In short, it replaces characters from random string1 with random string2 generated in parameter a.

So in our example, parameter b is:

“&b=tHR5aGU6x25tZXykY3l1wWQ6OTM0ZDZyNDBnZeNeNDElMWUuMnE3MeJgODA2ZDYlNvI2OTZntHBuwXY6YWRiwW58YXJewDb4ODZ8Z2VqZDbgZXNmcG9stGNranVvOeF8x3M6V19YUHl2ZXI6ceEqMC44tG5kcDj0LeB8xnV3OeF8″

Random String 1 = qrolijgdeabyvwtnczumhpxkfs

Random String 2 =pmjkhefczwxursidavqnyblgto

So if we replace String2 characters with String1 and then decode Base64, parameter b becomes:

“&b= |type:on_exec|uid:934d6a40ff3c4111e22a722d806d6172696f|priv:admin| arch:x86|gend:desktop|cores:1|os:W_XP|ver:v1.0.8|net:4.0|new:1|”

The bot collects information such as user account, system information, OS version, etc. and sends this to the control server.

Parameter c

Parameter c is just a hex representation of another 24-byte random string used as a data marker. So if we convert to text, this is how c looks:

“&c=hhefbczzzwxuurrsppmmmjkk”

The Base64 string of this parameter value is used in the response.

Control Server Response

The response from the control server is also custom encoded:

“aGhlZmJjenp6d3h1dXJyc3BwbW1tamtrZgcocWRHVdkgxUZvUFRmc2ZBPT0K”

The first part of the response contains the Base64 string of parameter c, which is just a random data marker string. Here is how the botnet checks for the Base64 value in its response:



Recall that in parameter c if we take the Base64 value of the random value we will have a match in the preceding response. The remaining part contains malicious commands. The remaining string is also custom Base64 and is also encoded like parameter b, using two randomly generated strings. So to decode we first need to find and replace characters using two random strings and then decode the Base64 string. Here is the code snippet:



In the preceding image, we see the function has decoded the Base64 string, which is another Base64 string. The loop also suggests the bot supports multiple commands. If we decode further, we will get commands in plain text. The decoded string in the preceding case is “|interval=90|,” which tells the bot to ping the control server every 90 seconds. The botnet supports a lot of commands and can launch DDoS attacks against websites. We may even conclude that if the response length is greater than 60-70 bytes, then the control server might send other commands because the bot can support multiple commands. To demonstrate shell commands, here is how calc.exe can be executed on a victim’s machine:



The botnet supports the following commands:



And DDoS attacks:



The Athena HTTP web panel has a full help page that gives details of this botnet:



Athena appears to be a multitalented HTTP botnet–with many commands and DDoS attack methods. The availability of the leaked builder and easy setup instructions may lead to a rise in infections from this botnet. The custom-encoded network communications makes it a little difficult to understand commands flowing between the victim and the control server, but there are a few patterns (if you pay close attention) that help us detect these malicious communications. Last, this botnet infection shows people are still fond of Windows XP and haven’t yet moved to more secure operating systems such as Windows 7 or Windows 8.


Original article: By Umesh Wanve on Oct 24, 2013