Another family of DDoS bots: Avzhan

By: jedwards -

Earlier this month, security researchers at Damballa published their findings regarding a new commercial DDoS service called IMDDOS.  In addition to observing a number of samples of IMDDOS bots in our malware analysis sandboxes, we have also seen a significant number of samples recently from a new DDoS family which appears to be closely related to IMDDOS; we have been referring to this new malware family as “Avzhan” based on the host names of some of the initial malware distribution servers.  The IMDDOS and Avzhan families appear to have significant similarities in terms of their installation mechanisms, their DDoS attack engines, and certain aspects of their bot-to-CnC communications.  Both families tend to be controlled from Chinese IP space.

Malcode Properties

The Avzhan malware is distributed in the form of a small executable that is most commonly 45,056 bytes in size; we have also seen slightly larger samples (e.g. 45,568 or 46,080 bytes) as well.  Some of the sample MD5 hashes include:

98efaa9cd6bbd2a54ce6d5b91397469a
40bd7fb91ca2335e4c129286d4dc4368
05dfe8215c1b33f031bb168f8a90d08e
e481cd344794b27b80b0be7739b701c7

Once the bot is launched, either via a previously installed trojan downloading and running it, or by a user being tricked into double-clicking it, the malware follows a typical installation procedure.  It copies itself into the Windows system directory as a randomly-generated filename consisting of six lower-case letters.  Examples that we have observed include:

pcljco.exe
koagos.exe
vmtxme.exe
wwqiwy.exe

It would appear that this random file name is generated on the fly at installation time because identical samples have installed themselves under different names; the existence of the string “%c%c%c%c%c%c.exe” within the bot’s executable lends further evidence to this conjecture.

The malware will then complete the installation process by making changes to the Registry and invoking Service Control Manager commands in order to configure itself as a Windows service that is to be automatically started upon each reboot of the infected host.  The name of this service is typically a derivative of “QQ Music”, or a randomly-generated string.  Representative examples include:

QQ Music updates
Ausadhfk
Ojdsjhk
gtey

The fake service name used by a particular Avzhan sample can be found as a hard-coded string within the malware executable.

In terms of installation process, the Avzhan and IMDDOS families have quite a bit in common.  Like Avzhan, IMDDOS copies itself to the system directory as a filename containing six randomly-generated lower-case letters (e.g., “xkjtks.exe”), and uses a very similar mechanism to install itself as an automatic service.  One difference is that IMDOSS names its fake service as some derivative of “SafePrec” (also hard-coded within the IMDDOS executable.)  IMDDOS executables also tend to be larger than Avzhan executables (e.g., 73,728 bytes versus 45,056 bytes.)

Bot-to-CnC Communications

Once it has installed itself on the infected host, the Avzhan bot will connect to it’s command & control (CnC) server using a raw TCP connection.  The Avzhan botnet controller(s) prefer to host their CnC servers on non-standard high ports, usually in the range of 1988 through 1994, or 8080 through 8083 (although we have observed a CnC listening on port 6600 as well.)  Once a TCP connection has been established, the Avzhan bot will upload a 1028-byte binary message to its CnC.  The format of this message is very structured and contains specific fields at specific offsets; it is very reminiscent of a C struct.  Most of the information within this message structure is transmitted in plaintext.  The format is as follows:

  • Offset 0: Four bytes encoding a DWORD with value of either 1 or 2 (depending on the sample);
  • Offset 4: A null-terminated Unicode string specifying the language used by the infected machine, such as “English (United States)”
  • Offset 68: A null-terminated ASCII string specifying the name of the infected machine as returned by the Windows GetComputerName() API call;
  • Offset 196: A null-terminated ASCII string specifying the version of the Windows operating system such as “Windows XP” or “Windows Vista”;
  • Offset 260: A null-terminated ASCII string specifying the amount of physical memory installed on the infected host, such as “512 MB”;
  • Offset 292: A null-terminated ASCII string specifying the CPU speed of the infected host, such as “3367 MHz”;
  • Offset 324: a null-terminated ASCII string that appears to specify the version or “batch” associated with the Avzhan malware sample, such as “v1-10.7.4″;

Some of the “version strings” we have observed include the following:

v1-10.3.3
v1-10.3.30
v1-10.5.5
v1-10.7.4

It is possible that the Avzhan controllers use the convention of naming their version strings based on the date of release in YEAR.MONTH.DAY format; so far, the dates upon which we have observed the various Avzhan samples is not inconsistent with such a theory.  Regardless of the naming convention used, the version string associated with a particular Avzhan sample is hard-coded (in plaintext) within the malware executable and can be easily determined as follows:

$ strings malware.exe | grep "v1-"
v1-10.7.4

Within the first 360 bytes of the message structure, null bytes (0x00) are used for empty or uninitialized locations.  From offset 360 onwards, the bot-to-CnC message contains binary data that we have not yet reverse engineered; it is not clear whether these bytes represent actual information communicated from bot to CnC or whether they are simply the portion of the 1028-byte message buffer that the bot code neglected to initialize with zeroes.

Again, we find similarities with IMDDOS; in fact, we have observed some IMDDOS samples that employ the same 1028-byte structured binary message format for their bot-to-CnC communications, with the exception that the first byte is a value of 0x98 for IMDDOS instead of Avzhan’s 0x01 or 0x02.  However, we have also seen IMDDOS samples that use a shorter, 497-byte binary structure for bot-to-CnC communications.  In addition, the IMDDOS family has an entire second tier of HTTP communications with the “Target-List Hosting Domain” (TLHD) servers (e.g., hxxp://imddos.my03.com:9090/puff.html), as described thoroughly in Damballa’s analysis, that does not exist at all within the Avzhan family.

CnC-to-Bot Communications

If an Avzhan botnet is engaging in a DDoS attack at the time a bot reports to its CnC, the CnC will respond with a command message that is also exactly 1028 bytes in length.  This response message contains the instructions of the DDoS attack that the bot is being ordered to commit.  The response message is also a binary structure and is formatted as follows:

  • Offset 0: Four bytes encoding a DWORD with a value that specifies the method of attack; we have observed attack codes of 3 (HTTP GET request flood) and 2 (unknown) to date;
  • Offset 4: Null-terminated ASCII string specifying the host name or IP address of the victim to be attacked;
  • Offset 132: Null-terminated ASCII string specifying the relative URI that is to be attacked in the case of an HTTP GET flood, such as “/index.aspx”; this field is missing in the case of attack code 2;
  • Offset 260 (or 132 in the case of attack code 2): Two bytes encoding a DWORD that specifies the victim port number that is to be attacked (e.g., 0x50 for a web server);

There are a few additional data fields included in the CnC-to-bot response that we have not yet reverse engineered; based on anecdotal evidence we are speculating that one of them is an integer that corresponds to the number of simultaneous flooding threads that the bot should spawn.

When it crafts its response message, it appears that the CnC software “reuses” the 1028-byte memory buffer in which it receives the initial bot-to-CnC message.  In other words, the CnC-to-bot response message is a verbatim copy of the bot-to-CnC message except for locations within the buffer that were explicitly overwritten by the CnC server software (e.g., the attack code, the victim host name and port, etc.)

In this regard, Avzhan differs substantially from IMDDOS, which receives its target(s) from the aforementioned TLHD server infrastructure instead of directly from the CnC.

Attack Traffic

As mentioned above, we have observed Avzhan bots receive at least two different DDoS attack command codes: code 3 (HTTP GET floods) and code 2 (unknown.)  When engaging in an HTTP GET flood, the Avzhan bot will send large numbers of GET requests to the victim web server.  Some of this traffic is malformed and does not even constitute valid HTTP requests, whereas the other request traffic, although malicious in nature, at least complies with the HTTP protocol.

Within the scope of a particular attack, each of the well-formed HTTP requests are identical in terms of the requested URL as well as the HTTP header information.  Here is an example:

GET /index.aspx HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel,
application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
User-Agent:Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1)
Host: www.victim.com.cn
Connection: Keep-Alive

The Avzhan bot attempts to masquerade as legitimate traffic by including a benign User-Agent header.  However, note that, with the exception of the User-Agent field, all of the HTTP header fields follow the near-universal standard format of “key: value” (i.e., a single space following the delimiting colon.)  Yet the User-Agent field contains no whitespace following the colon delimiter. Although this is technically not a violation of the HTTP protocol, it is highly unusual and quite distinctive; not only do almost all legitimate browsers include a single space following the colon, but so do the vast majority of malware families in our experience.

Furthermore, a static analysis of the sample’s executable indicates that there appear to be a variety of  possible User-Agent values that the bot might employ:

User-Agent:Mozilla/4.0 (compatible; MSIE %d.0; Windows NT %d.1; SV1)
User-Agent:Mozilla/4.0 (compatible; MSIE %d.0; Windows NT %d.1; SV1)
User-Agent:Mozilla/5.0 (X11; U; Linux i686; en-US; re:1.4.0) Gecko/20080808 Firefox/%d.0
User-Agent:Mozilla/4.0 (compatible; MSIE %d.00; Windows NT %d.0; MyIE 3.01)
User-Agent:Mozilla/4.0 (compatible; MSIE %d.00; Windows NT %d.0; MyIE 3.01)
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

Note that all of these hard-coded strings contain the same tell-tale “no whitespace after the delimiting colon” property.  A regular expression or simple string match against the GET request should therefore be fairly effective in detecting and mitigating this HTTP flood traffic, most likely.

Avzhan bots also generate completely malformed HTTP traffic as part of their flood attacks.  These requests consist of the following string repeated endlessly:

GET ^&&%$%$^%$#^&**(*((&*^%$##$%^&*(*&^%$%^&*.htmGET ^&&%$%$^%$#^&**(*((&*^%$##$%^&*(*&^%$%^&*.htm

Note that this traffic is not a valid HTTP request because, among other reasons, it does not include an HTTP version in the initial request line.  Static analysis reveals the existence of this string hard-coded into the Avzhan executables.  Again, it should be straightforward to detect this traffic based on a simple string match.  It should also be noted that a Google search will reveal that the above GET request is a popular string that is found in various publicly available DDoS code bases.

We have also observed Avzhan specimens flood the target host with large numbers of TCP SYN requests upon receipt of command code 2 from the CnC.  During these observed attacks, the victims were completely non-responsive, so it is unclear whether the attacks were classic SYN floods or some other kind of attack that we could not observe because the victim was unable to complete any three-way TCP handshakes.  Since the source IP address of the SYN requests from Avzhan were not spoofed, it seems likely that command code 2 corresponds to some kind of attack other than a traditional SYN flood.

The characteristics of the attack traffic represent one of the most interesting similarities between Avzhan and IMDDOS and suggests that they might share a common DDoS traffic engine.  This is based on the observation that static analysis of IMDDOS samples reveals identical instances of both the “GET ^&&%$%…” string as well as the six “User-Agent:Mozilla…” strings.  We have not studied IMDDOS in great detail and cannot confirm that these strings are used in the actual attack traffic that it generates, but it seems like a reasonable conjecture.

Control Servers

To date, we have identified at least 20 different Avzhan CnC servers that have actually issued DDoS attack commands, all of which are hosted on the following five Chinese netblocks:

CN    4134    CHINANET    CHINANET JIANGSU PROVINCE NETWORK
CN    4134    CHINANET    CHINANET GUANGXI PROVINCE NETWORK
CN    4134    CHINANET    NINBO LANZHONG NETWORK LTD
CN    4134    CHINANET    SHENZHENSHILUOHUQUHEPINGLUYIFENGGUANGCHANGCZUO32H
CN    4134    CHINANET    THE YANDA ZHENGYANG ELECTRON LTD. OF QINHUANGDAO

Every one of the Avzhan CnC servers that we have observed uses a host name within the 3322.org domain, a large Chinese provider of dynamic DNS services.

As is typical with this sort of malware, the host name of the CnC is hard-coded (in obfuscated form) within the bot executable itself.  After performing a memory dump of a running Avzhan bot process and scanning it for strings, the CnC host name can be determined by a simple grep on “3322.org”.

Here again we find another similarity with IMDDOS, which also makes heavy use of the 3322.org domain for its CnC servers.

Victims

We wrote a simple botnet tracker that connects to known Avzhan CnC servers and sends 1028-byte messages that mimic the binary protocol used by real Avzhan specimens.  This allows us to log DDoS attack instructions issued by the various CnC servers.  Since the Avzhan tracker started running (approximately one month ago), we have observed 49 different IP addresses come under attack.  The victims have been distributed fairly widely across the following 32 netblocks:

CN    17638    CHINATELECOM-TJ-AS    CHINANET TIANJIN PROVINCE NETWORK
CN    17816    CHINA169    CHINA UNICOM GUANGDONG PROVINCE NETWORK
CN    17896    CHINATELECOM-JL-AS    CHINANET JILIN PROVINCE NETWORK
CN    4134     CHINANET    CHINANET ANHUI PROVINCE NETWORK
CN    4134     CHINANET    CHINANET GUANGDONG PROVINCE NETWORK
CN    4134     CHINANET    CHINANET HEBEI PROVINCE NETWORK
CN    4134     CHINANET    CHINANET JIANGSU PROVINCE NETWORK
CN    4134     CHINANET    CHINANET JIANGXI PROVINCE NETWORK
CN    4134     CHINANET    CHINANET-ZJ TAIZHOU NODE NETWORK
CN    4134     CHINANET    DALIANG JIEXIN CO.LTD
CN    4134     CHINANET    DONGGUANSHIWEIYIWANGLUOKEJIYOUX
CN    4134     CHINANET    NINBO LANZHONG NETWORK LTD
CN    4837     CHINA169    CHINA UNICOM GUANGDONG PROVINCE NETWORK
CN    4837     CHINA169    CHINA UNICOM LIAONING PROVINCE NETWORK
CN    4837     CHINA169    CHINA UNICOM SHANDONG PROVINCE NETWORK
CN    4837     CHINA169    IDC NODE ACCESS USER NETWORK
HK    45753    NETSEC    SIMCENTRIC SOLUTIONS INTERNET SERVICE PROVIDER
KR    3786     LGDACOM    KOREA INTERNET DATA CENTER INC
KR    4766     KIXS-AS    KOREA TELECOM
KR    9318     HANARO    HANARO TELECOM
TW    9919     NCIC    PROHOSTCO. LTD
TW    9924     TFN    TFN-NET
US    15105    NETWORKTELEPHONE    LIMESTONE NETWORKS INC
US    19029    NEWEDGENETS    EARTHLINK INC
US    19853    USONL-2    CNLINK NETWORKS INC
US    21844    THEPLANET-AS    THEPLANET.COM INTERNET SERVICES INC
US    26496    PAH-INC    GODADDY.COM INC
US    29761    OC3-NETWORKS-AS-NUMB    OC3 NETWORKS & WEB SOLUTIONS LLC
US    30058    ACTIVO-SYSTEMS    FDCSERVERS.NET
US    35908    VPLSNET    VPLS INC. D/B/A KRYPT TECHNOLOGIES
US    36351    SOFTLAYER    HOSTING SERVICES INC
US    46844    ST-BGP    SHARKTECH INTERNET SERVICES

All total, 27 of the victims were located in China, 13 in the United States, 6 in South Korea, 2 in Taiwan, and 1 in Hong Kong.

The longest duration Avzhan attack we have observed to date lasted approximately 66 hours, with another attack lasting 20 hours and several lasting more than six hours each.  Furthermore, although the nature of the Avzhan communications protocol appears to limit a particular CnC to attacking a single victim at a time, we have observed multiple Avzhan CnCs simultaneously engaging in attacks against different victims.   We have also observed instances in which multiple Avzhan CnC servers were simultaneously attacking the same victim.

Detection

The VirusTotal A/V detection rates for the Avzhan specimens we have observed range from 0% (e.g., fae34bca61e3f0d6922c22026a2e769f) to 93% (e.g., 05dfe8215c1b33f031bb168f8a90d08e).  Typical detections for the Avzhan bots include the following:

TrendMicro               Mal_SCAR-1
Sophos                   Mal/Behav-116
Symantec                 Backdoor.Trojan
F-Secure                 Trojan.Generic.3808091
McAfee                   BackDoor-CKB.gen.bw
Microsoft                Trojan:Win32/ServStart.A

Summary

The similarities between Avzhan and IMDDOS in terms of installation procedures, bot-to-CnC communications protocols, location of CnC servers, and (possibly) actual attack traffic suggest the possibility that the two malware families share a great deal of code in common.  One theory that comes to mind is that the developers of the IMDDOS family might have obtained the Avzhan source code and added the modifications necessary to evolve it into a more easily commercializable DDoS service, such as the new TLHD tier of control.  At any rate, the commonalities between Avzhan and IMDDOS represent yet another data point that indicates how much sharing, re-using, and/or “borrowing” of code takes place in the underground malware industry.

Comments