YoyoDDos: A new family of DDos bots
by Jeff EdwardsA new family of DDos bots started showing up in our sandboxes in May. The first sample was analyzed on May 7, and since then our sandboxes have processed over 70 specimens from this family. Upon further analysis, it turns out that we had actually started receiving specimens as early as March, 2010. We have been using the moniker “YoyoDdos” to refer to this family (derived from the hostname of one of the initially observed C&C servers.)
Malcode Properties
The malcode does not use a packer. It is most frequently encountered in the form of a 37,888-byte executable with various MD5 hash values. Some of the MD5 hash values that we have observed to date include:
1f7dd0f7ba97823f1e74324b2171774b e4a6e9911fe07f6df12c485001df8b2c a5c29b7b0c77521d961e47c4fdad90b8 1cbe4f8242f906a0b41fb4ed261df20f 5233ce366910191b52d977b3b37d30ef c9bfbd9e4297c992bf0b5b54aaf6dda7 40096faa7b065de36d48e581779030a5 ae6c6f2a7c6d23153b0fa8d7a5e2573f e71ba1af792c3449383a11f24e21de3b 2bac9d7c6e60884388870e829acc0d89 620c1569eaae9b755d40b68285a22a01 d669736eefffdceeaa24bd557c6b3bb2 150fff5f199760b77477d9ed4a86a367 79bcbe08b297dddfe1b8c1d125ce7fde
It is quite common for differences between individual samples to be quite small. For example, three different YoyoDDos executables were identical except for the byte values at approximately 30 offset locations:
Offset Sample-A Sample-B
[0x00000fe4] O E
[0x00000fe5] m b
[0x00000fe6] j z
[0x00000fe7] h t
[0x00000fe8] e r
[0x00000fee] R d
[0x00000fef] R d
[0x00000ff0] R d
[0x00000ff1] R d
[0x00000ff2] R d
[0x00000ff3] R d
[0x000070b4] S G
[0x000070b5] ? ?
[0x000070b6] ? ?
[0x000070b7] : 9
[0x000070b8]
[0x000070d6] ? ?
[0x000070d7] ?
[0x000070d8] : ;
[0x000070d9] ? ?
[0x000070da] U K
[0x000070fc] ? ?
[0x000070fd] ? ?
[0x000070fe] ; =
[0x000070ff] ? ?
[0x00007133] ? ?
[0x00007134] 1 5
[0x00007135] ? ?
[0x00007136] _ b
[0x00007137] { }
Fortunately, it is not uncommon for several different variants of the bot to have the same PEHash value.
The life cycle of the bot is as follows:
1. It writes a copy of it’s own executable file into the C:\Windows\System32\ directory with a randomly-generated file name; this file name begins with a capital A, followed by eight to ten random lower-case letters. We have never observed two YoyoDDos samples using the same name for this file. Examples we have observed include:
Antidzkue.exe Asunumkzx.exe Asynheuuf.exe Antirwzwh.exe Auuziixbguo.exe Antimedmd.exe Antihzwkb.exe Anhldjxep.exe Antixgojx.exe Antiftypz.exe Antiwzkmd.exe Arntiuzhnp.exe Anztingomn.exe Anztifudxz.exe Avntivcgkt.exe Antiaijbsd.exe
It also sets the “hidden” and “system” attributes of this file. This is an exact copy of the original malware sample, and is 37,888 bytes in size.
2. It opens the newly written copy of itself, and appends 53,716,000 bytes of data after the initial 37,888 bytes of data. The exact nature of this data has not been analyzed. The result is that the file’s size grows to 53,753,888 bytes. The initial 37,888 bytes remain unchanged. It is not clear whether or not any of the 53 MB of appended data contains reachable instructions.
3. It then copies the large (53 MB) version of itself from the System32 directory to the Start Menu\Startup directory of the current user, using a name that starts with the string “360” followed by a random capitalized letter and four random lower-case letters. We have never observed two YoyoDDos samples using the same name for this file. We have also observed this string being hard-coded within the bot executables. Representative examples that we have observed include:
360Icaxv.exe 360Ytqol.exe 360Davsq.exe 360Omkhf.exe 360Kifdx.exe 360Ebztr.exe 360Hfcxu.exe 360Khfdx.exe 360Vsnlf.exe 360Eywqo.exe 360Tomge.exe 360Icaus.exe
It then modifies a single byte located at offset 1262, changing it from a value of 0×26 to 0×00.
4. It launches the appended copy of itself that it placed in the System32 directory, as well as the appended (and one-byte modified) version of itself it placed in the user’s Startup directory.
5. It launches a cmd.exe shell to delete the original copy of itself and then terminates.
6. At this point, the modified copy of itself (placed in the Startup directory) has started executing. It creates a mutex with a pseudo-random name that appears to be derived from the host computer name and possibly other seed information. It is not uncommon for different samples to use the same mutex name. Examples we have observed include:
MRSG643GMVXGOLRTGMZDELTPOJTTUMJZHA2A==== NNWGIZDPOM4TOLRTGMZDELTPOJTTUMJQGIYA==== OJXXK2TJFZ2XKZDEN5ZS4Y3PNU5DGNRR OJXXK2TJFZ2XKZDEN5ZS4Y3PNU5DGNRS OV2XU2JOOZUXA5LVFZXGK5B2GM3DC=== PFXXK6LPOVSGILRTGMZDELTPOJTTUMRQGEYA====
7. The second process (living in the Startup directory) then initiates communications with the C&C master server and goes operational (see details below.)
8. Meanwhile, the third process (launched from the copy placed in System32 directory) creates a MS-DOS batch file that is always named C:\9.bat. This batch file contains the commands for creating a new Windows service associated with the hidden executable that it created in the C:\Windows\System32 directory. The service is configured to start automatically. Once this new service is created, it is started immediately, and the c:\9.bat file deletes itself.
The service is given a name that is more-or-less gibberish, although it sometimes begins with the word “Media”. The display name of the service is generally some derivative of “MS Media Center”. Sometimes the service names are enclosed in paranetheses. Examples of the service names include:
MediaCubmkz CeaxyaMencle EnclCtwyme MediaCwhlbh (Meuuziexnzh) (MediaCelkuh) MediaCshehw MehlaCkxjkk MediaChdqps (MediaCemdze) MerdiaCuzqnv (MezdiaCawlcd) MedziaCsueny (MuediaCvismx) (MediaaCyrqkf)
Examples of service display names include:
(MS Media Conblur Center) MS Mdeaia Congnvm Center Intele Porconoswd Center MS Media Conwwsk Center (MS Media Conndph Ceuuzi) (MS Media Conbwhh Center) MS Media Conwmez Center MS Media Chlezhf Center MS Media Conckyl Center (MS Media Conlree Center) MS Mredia Conwfrk Center (MS Mzedia Conydua Center) MS Mezdia Conxvep Center (MuS Media Connome Center) (MS Meadia Conbofm Center)
The service is given a description that is some derivative of “support for media palyer. This service can’t be stoped.” (note the spelling errors.) Examples include:
Prohbdrd support for media palyer. This service can't be stoped. Support for media palyer. This service can't be stoped. EnclCtwyme Media palyer. This service can't be stoped. MediaCwhlbh Proulull support for media palyer. This service can't be stoped. Meuuziexnzh Proktjbr suuuzit for media palyer. This service can't be stoped. MediaCelkuh Probkwrw support for media palyer. This service can't be stoped. MediaCshehw Prorzkll support for media palyer. This service can't be stoped. MehlaCkxjkk Projbbmh support for mhlia palyer. This service can't be stoped. Prohfqqu support for media palyer. This service can't be stoped. MediaCemdze Prozdzlb support for media palyer. This service can't be stoped. Proropnpb support for media palyer. This service can't be stoped. Prohzlnzr support for media palyer. This service can't be stoped. Promzoseq support for media palyer. This service can't be stoped. Puroimywg support for media palyer. This service can't be stoped.
A typical example of the contents of the C:\9.bat file is as follows:
@ECHO OFF SC CREATE CeaxyaMencle binPath= "C:\WINDOWS\system32\Asunumkzx.exe" START= auto DISPLAYNAME= "MS Mdeaia Congnvm Center Intele" type= own type= interact SC description CeaxyaMencle "Support for media palyer. This service can't be stoped." SC START CeaxyaMencle del %0
9. The third process then terminates.
10. Finally, a fourth process is initiated as a consequence of the start of the newly installed service. This process (associated with the copy living in System32 directory) detects the existing mutex and aborts.
At this point, the malware is installed as both a service (to be automatically started at boot time) as well as a normal file residing in the user’s Startup directory (also to be invoked automatically upon log in.)
Communication Protocol
After installation, the bot connects to the C&C server and establishes a TCP connection. The C&C server appears to be hard-coded in the bot executable as a host name (not a bare IP address) and port, although the particular location and encoding method used has not been analyzed.
The bot always initiates communications with its master by sending either a 232-byte (or less frequently, a 228-byte) message in binary format. Qualitatively, the message submitted by the bot client is very similar from specimen to specimen. In some cases, we have observed a single bot specimen attempting to communicate to two C&C servers (presumably for redundancy purposes.)
Here is a representative example of a typical 232-byte communication sent from the bot to the C&C:
6d 90 8a 99 92 ce 64 cd d6 5e 99 8f 90 ce 6a 71 cd d6 73 66 69 d6 c3 d0 c6 c8 77 6e 7c b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 c4 c9 c9 71 74 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 67 8d 90 d6 5e 66 d6 63 66 c4 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 68 c4 c6 c5 c6 c6 be 69 69 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 b6 ad ba b6 b6 ff ff ff ff
Although we have not fully reverse engineered the communication protocol used by this family, we have been able to determine that it uses a weak obfuscation scheme that appears to be a hard-coded substitution table. When de-obfuscated by applying this hard-coded substitution table, we find that the message contains the following strings:
Intel(R) Xeon(TM) CPU 3?0.GHz 2--MB Win XP SP2 V201008UU
Note: there are some flaws in our de-obfuscation procedure because the hard-coded substitution table has only been partially reverse-engineered to date. Nevertheless, it is clear that the bot reports details about the victim host, including the make, model, and speed of the processor, and the operating system and service pack level. The last string (V201008UU in the above example) turns out to be a kind of identification (or version) string that is embedded in each bot variant’s binary. The bot apparently includes this string with each message it sends to the C&C. The identifier fails to show up in a static analysis on the original sample, but is easily revealed within the strings of a memory dump of a live YoyoDDos process. Examples of these identification strings that we have observed include:
V201008UU V20100809 Vip090I03 LuoJ0810
The actual substitution table that we have been able to reverse engineer to date appears to be a modification of a more simple substitution scheme we have seen previously. The table appears to be constructed by starting with a mapping of the form: C = 0xB6 – P, where P is the plaintext ASCII value of a character, and C is its “encrypted” representation. Thus, the null byte 0×00 is encoded as 0xB6, the ASCII value “A” is encoded as 0xB6 – 0×41 = 0×75, etc. However, once this basic layout is created, some block ranges of the table are relocated; for example, the block of (reversed) lower-case characters “z” through “a” is relocated to occupy byte codes 0×84 through 0x9d. Then a few smaller blocks of codes are again relocated within the larger relocated blocks.
DDOS Operation
If the C&C server is alive and responsive, it always sends a 124-byte message. The first four bytes appear to be a command code indicating the action that the bot client is requested to perform, followed by additional details. We have observed the following different commands:
0×00100000 – Initiate HTTP flood attack. The URL to attack is provided in plaintext NULL-terminated ASCII starting at byte offset 4. Example:
00000000 00 10 00 00 68 74 74 70 3a 2f 2f 77 77 77 2e XX ....http ://www.v 00000010 XX XX XX XX XX XX XX XX XX 2e 63 6f 6d 2f 69 6e ictimsit e.com/in 00000020 64 65 78 2e 61 73 70 00 00 00 00 00 00 00 00 00 dex.asp. ........ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00000060 00 00 00 00 00 00 00 00 50 00 00 00 0a 00 00 00 ........ P....... 00000070 1e 00 00 00 64 00 00 00 c8 00 00 00 ....d... ....
In this example, the (anonymized) victim URL is http://www.victimsite.com/index.asp (the real victim in this particular attack was the website of a Chinese automotive parts merchant.) The meaning of the remaining non-zero data bytes in the instructions is currently unknown.
In our observations, the bot generates HTTP traffic against the victim URL at a rate of approximately 20-25 GET requests per second.
0×80040000 – Initiate a generic UDP+TCP/SYN DDOS attack. The host name or IP address to attack follows at byte offset 4. Example:
00000000 80 04 00 00 31 32 31 2e 31 32 2e 31 30 34 2e XX ....121. 12.104.X 00000010 XX 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 X....... ........ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00000060 00 00 00 00 00 00 00 00 c5 54 00 00 02 00 00 00 ........ .T...... 00000070 1e 00 00 00 00 00 00 00 00 00 00 00 ........ ....
In this example, the target is the IP address 121.12.104.XX (last octet has been anonymized.)
Upon receiving such a command, the bot immediately attempts to set up two TCP connections to the victim IP address on a port that appears to be random (e.g., 21701). As soon as these initial two SYN packets are sent off to the victim, the bot begins flooding the victim with UDP packets to the same port number.
During one observed attack, the bot sent UDP packets from two different source ports (1048 and 1049) to the same destination port (presumably randomly chosen). The packets sent from port 1048 contained 78 bytes of junk data (all bytes had the value 0×32, or “2”); the packets from port 1049 contained 111 bytes of junk (all bytes had the value 0×53, or “S”.) These two 78- and 111-byte UDP data packets were repeated at a rate of approximately 260 packets/second until the victim responded with a SYN/ACK to one of the initial TCP connection requests, at which point the bot transitioned from UDP flooding to TCP SYN flooding. It is not clear whether the size of the UDP packets and/or their content were randomly chosen.
Once the victim responds to one of the initial SYN packets with a SYN/ACK, the bot will cease the UDP flood and initiate a SYN flood. Specifically, it will issue additional SYN packets from sequentially increasing source ports to initiate approximately 3-4 TCP connections per second. The bot executes a typical SYN flood attack: when the victim responds to each initial SYN packet with a SYN/ACK, the bot ignores the respond and refuses to send an ACK to complete the 3-way TCP handshake. Instead, it just keeps sending more SYN packets (from incrementally increasing source ports) to request more and more TCP connections.
In one observed attack, the bot managed to coerce the victim into partially opening more than 40 TCP connections over the course of about 12 seconds.
0×00000004 – Download and launch an executable. The URL to the executable that is to be downloaded is provided at byte offset 4.
0xc1000000 – Unknown command. We observed this command, followed by a hostname at byte offset 4. The bot then performed a DNS resolution of the specified hostname. However, our logging of this sample terminated before we observed any further actions, so we do not know what, if any, kind of attack is associated with this command code.
HTTP Header Signature
As mentioned above, if commanded to launch an HTTP flood attack, the bot will generate a large number of HTTP GET requests to the victim URL. The header fields in these GET requests are as follows:
Accept: */*
Accept-Language: zh-cn
Accept-Encoding: g{ip, deflate
Host: www.victimsite.com:80
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Mozilla/4.1 (compatible; MSIE 6.0; Windows 5.1)
Referer: http://www.victimsite.com
Connection: Keep-Alivf
Note that the HTTP GET header fields generated by the bot contain several distinctive typos: the “Connection: Keep-Alivf” header is misspelled, and the “Accept-Encoding: g{ip, deflate” header has a typo. Both of these header values are present as hard-coded strings within the bot executable, which suggests that they are consistently present in the HTTP GET requests generated by this family.
Additional characteristics of the bot’s GET header include the User-Agent and Accept-Language fields, which are also hard-coded into the bot and are therefore expected to remain constant:
- Accept-Language: zh-cn
- User-Agent: Mozilla/4.1 (compatible; MSIE 6.0; Windows 5.1)
Furthermore, the bot has been observed to use the host name of the victim website for the “Referer” header field. Alternatively, an analysis of hard-coded strings within the bot executable suggests that it may also provide the header “Referer: http://www.google.com” in some cases instead.
Taken together, these distinctive GET header properties would most likely allow a very precise signature to be developed with a low probability of false positives. This signature would be able to identify inbound HTTP flooding traffic at a victim site.
Identification
The following interesting ASCII strings were found hard-coded within the bot executable; note that some of these strings suggest the possibility that the bot could have some limited rootkit functionality:
\svchoSt.exe JiangMin c:\2.eXe c:\winddk\demo\repairssdt\bin\i386\RepairSSDT.pdb Possibly KiServiceLimit==%08X relo type %d found at .%X strange NtQuerySystemInformation()! &KiServiceTable==%08X Dumping 'old' ServiceTable: Can't find KeServiceDescriptorTabme Can't find KiServiceTable... KeServiceDescriptorTablf Start beep service ok \drivers\PCIDump.sys \\.\Dark2118
C&C Servers
To date, we have observed YoyoDDos samples connect to at least 34 C&C server hostnames. All but three of these C&Cs are located in China; with two in the U.S. and one in South Korea. The networks on which these C&Cs are located are as follows:
ASN ASN Name Country Network 27645 ASN-DCS-03 US MANAGED SOLUTIONS GROUP INC 36351 SOFTLAYER US SOFTLAYER TECHNOLOGIES INC 3786 LGDACOM KR KOREA INTERNET DATA CENTER INC 4134 CHINANET CN CHINANET ANHUI PROVINCE NETWORK 4134 CHINANET CN CHINANET GUANGDONG PROVINCE NETWORK 4134 CHINANET CN CHINANET HUNAN PROVINCE NETWORK 4134 CHINANET CN CHINANET JIANGSU PROVINCE NETWORK 4134 CHINANET CN CHINANET-ZJ JINHUA NODE NETWORK 4134 CHINANET CN DONGGUANSHIWEIYIWANGLUOKEJIYOUX 4134 CHINANET CN JINHUA TELECOM CO. LTD IDC CENTER 4134 CHINANET CN NINBO LANZHONG NETWORK LTD 4134 CHINANET CN NINGBO LIGONG UNIVERSITY(2) 4134 CHINANET CN SHENZHENSHILUOHUQUHEPINGLUYIFENGGUANGCHANGCZUO32H 4134 CHINANET CN VA OFFICE BRANCH OF CHINA TELECOM CORP 4837 CHINA169 CN CHINA UNICOM LIAONING PROVINCE NETWORK 4837 CHINA169 CN ZHENGZHOU GIANT COMPUTER NETWORK TECHNOLOGY CO. LTD
DDos Victims
To date, we have observed over 180 victims of YoyoDDos attacks, the majority of which are located in China; the breakdown by country of the victim IP addresses is as follows:
Country Victim Count China 126 United States 32 South Korea 9 Germany 5 Hong Kong 4 Egypt 2 Netherlands 2 Taiwan 1 Romania 1 Bolivia 1
Anti-Virus Coverage
Approximately 50% of the YoyoDdos samples we have observed do not exist at all in the Virus Total database. The remaining samples have AV detection results roughly similar to the following:
Antivirus Version Last Update Result a-squared 5.0.0.31 2010.07.09 Trojan.Win32.SystemHijack!IK AhnLab-V3 2010.07.09.01 2010.07.09 Win-Trojan/Agent.53753888 AntiVir 8.2.4.10 2010.07.09 TR/Dropper.Gen2 Antiy-AVL 2.0.3.7 2010.07.09 - Authentium 5.2.0.5 2010.07.09 W32/QQhelper.C.gen!Eldorado Avast 4.8.1351.0 2010.07.09 Win32:Agent-AERY Avast5 5.0.332.0 2010.07.09 Win32:Agent-AERY AVG 9.0.0.836 2010.07.09 Dropper.Agent.RCT BitDefender 7.2 2010.07.09 - CAT-QuickHeal 11.00 2010.07.09 TrojanDropper.Agent.ayqh ClamAV 0.96.0.3-git 2010.07.09 - Comodo 5372 2010.07.09 TrojWare.Win32.TrojanDropper.Agent.~CSQ DrWeb 5.0.2.03300 2010.07.09 BackDoor.Darkshell.96 eSafe 7.0.17.0 2010.07.08 - eTrust-Vet 36.1.7694 2010.07.09 - F-Prot 4.6.1.107 2010.07.08 W32/QQhelper.C.gen!Eldorado F-Secure 9.0.15370.0 2010.07.09 - Fortinet 4.1.143.0 2010.07.09 - GData 21 2010.07.09 Win32:Agent-AERY Ikarus T3.1.1.84.0 2010.07.09 Trojan.Win32.SystemHijack Jiangmin 13.0.900 2010.07.09 TrojanDropper.Agent.abzo Kaspersky 7.0.0.125 2010.07.09 Trojan-Dropper.Win32.Agent.ayqh McAfee 5.400.0.1158 2010.07.09 BackDoor-DKA McAfee-GW-Edition 2010.1 2010.07.05 Heuristic.BehavesLike.Win32.Downloader.H Microsoft 1.5902 2010.07.09 Trojan:Win32/SystemHijack.gen!C NOD32 5264 2010.07.09 a variant of Win32/Farfli.AY Norman 6.05.11 2010.07.09 W32/Obfuscated.FA nProtect 2010-07-09.01 2010.07.09 Trojan-Dropper/W32.Agent.37888.BO Panda 10.0.2.7 2010.07.08 Trj/Downloader.MDW PCTools 7.0.3.5 2010.07.09 - Prevx 3.0 2010.07.09 - Rising 22.55.04.04 2010.07.09 Trojan.DL.Win32.SBXQ.a Sophos 4.54.0 2010.07.09 Mal/Agent-AG Sunbelt 6562 2010.07.09 BehavesLike.Win32.Malware (v) Symantec 20101.1.0.89 2010.07.09 - TheHacker 6.5.2.1.311 2010.07.08 Trojan/Dropper.Agent.ayqh TrendMicro 9.120.0.1004 2010.07.09 - TrendMicro-HouseCall 9.120.0.1004 2010.07.09 - VBA32 3.12.12.6 2010.07.09 Backdoor.Win32.Httpbot.ahj ViRobot 2010.6.29.3912 2010.07.09 Dropper.Agent.31744.I VirusBuster 5.0.27.0 2010.07.08 -
Automated Identification
After manually identifying over 40 samples of YoyoDDos, we developed a simple automated identification system which classifies malware samples as YoyoDDos based on the characteristics of the bot-to-controller communications protocol.
We have not yet reverse engineered the (apparently) obfuscated message sent from bot to C&C. We have also observed multiple varieties of YoyoDDos that exhibit a very similar communication pattern but for which the actual bytes differ significantly. In addition, we are still not sure which of the bytes that appear to be constant are actually variable and just derived from non-changing aspects of our sandbox environment (e.g., machine name.) This made a hard-coded signature-based method for detecting YoyoDDos communication difficult.
Shown below are two representative examples of bot-to-C&C messages sent by two different sub-YoyoDDos varieties:
Observed March 26, 2010 (using a substitution table based on C = 0xB8 – P):
71 8E 84 95 8C D0 6A D1 D8 60 95 8F 8E D0 64 6D "q.....j..`....dm"
D1 D8 7B 68 65 D8 CB CE C4 C8 77 70 82 B8 B8 B8 "..{he.....wp...."
B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 "................"
B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 "................"
B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 "................"
B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 "................"
B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 "................"
B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 "................"
CA C5 C5 6D 7A B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 "...mz..........."
B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 "................"
67 91 8E D8 60 68 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 "g...`h.........."
B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 "................"
F1 F9 3F ED D8 D8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 "..?............."
B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 B8 "................"
E1 B7 B8 B8 "...."
Observed August 3, 2010 (using a substitution table based on C = 0xB6 – P):
6D 90 8A 99 92 CE 64 CD D6 5E 99 8F 90 CE 6A 71 "m.....d..^....jq" CD D6 73 66 69 D6 C3 D0 CA C6 77 6E 7C B6 B6 B6 "..sfi.....wn|..." B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 "................" B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 "................" B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 "................" B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 "................" B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 "................" B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 "................" C4 C9 C9 71 74 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 "...qt..........." B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 "................" 67 8D 90 D6 5E 66 D6 63 66 C4 B6 B6 B6 B6 B6 B6 "g...^f.cf......." B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 "................" 68 8D 86 C6 BD C6 78 C6 CA B6 B6 B6 B6 B6 B6 B6 "h.....x........." B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 B6 "................" AD BA B6 B6 FF FF FF FF "........"
Both are approximately the same length (228 and 232 bytes, respectively). Both have a single byte value that occurs very frequently (0xB8 and 0xB6, respectively), which we believe to encode a null byte value (i.e., padding.) And both have substantive (non-padding) bytes in approximately the same offset locations, which represent the specifications of the victim machine as well as the aforementioned identification string for the botnet.
Based on these commonalities, we were able to develop a simple algorithm for detecting YoyoDDos traffic as follows:
1. If the length of the message is not between 228 and 232 bytes, classify it as non-YoyoDDos; otherwise continue.
2. Find the most commonly occurring byte (called the “padding byte”); if the percentage of the entire message that consists of “padding bytes” is not between 70% and 80%, then classify it as non-YoyoDDos; otherwise continue.
3. Enumerate the offset locations of all the “substantive bytes” in the message and compare them to a canonical set of 59 substantive byte offsets observed in manually classified YoyoDDos traffic. If the number of mis-matched offsets is greater than 12, classify the sample as non-YoyoDDos; otherwise classify it as YoyoDDos.
So far, these simple heuristics are quite reliable at automatically identifying YoyoDDos traffic without any false positives of which we are aware.
Automated Tracking
Once we had a mechanism for automatically identifying and tagging YoyoDDos samples that were analyzed by our malware lab, we built a rudimentary YoyoDDos botnet tracker. It periodically takes the complete set of positively identified YoyoDDos samples from our malware lab and replays their 232-byte (or 228-byte in some cases) bot-to-C&C messages to their corresponding C&C hosts and ports. Since YoyoDDos hard-codes its C&C server(s) as hostnames rather than IP addresses, the tracker checks to see if the DNS record associated with the C&C hostname has changed to a different IP since the sample was actually dynamically analyzed; if so, then both the new and original IP addresses are tried.
For each C&C candidate IP, the tracker initiates a socket connection and, if successful, sends the original (replayed) communication message verbatim. It then listens for a response; if no response is received within 15 seconds, it gives up and moves on the next C&C candidate. On the other hand, if it receives a response, it attempts to parse it based on the command code set observed to date and mentioned above (e.g., 0×00100000 for HTTP flood, etc.)
Our initial statistics with this tracker show that approximately 2/3 of the identified YoyoDDos C&C servers are still live (in the sense that they are still accepting connections.) Of these, the majority tend to be dormant and not actively issuing commands, but our tracker regularly observes multiple HTTP flood (and occasionally other) attacks being issued from different botnets and/or C&C servers.
We have also experimented with replaying a message from a bot to its C&C that we had manually modified to replace the bot’s true identification string (e.g., V201008UU) with a different string. The motivation was to determine whether the C&C server infrastructure for a particular botnet uses this identification string as a kind of “password” or authentication token. Using the tracking mechanism described above, we located a C&C that was actively engaged in an attack; i.e., issuing flood commands on a victim host in response to the verbatim replay of a message (with correct ID string.) We then immediately replayed the modified version of that message to the C&C (with the bogus ID string.) We observed no change in the C&C behavior in response to the bogus message: the C&C issued the identical response (including the same attack command) as it issued to the unaltered bot transmission. Based on this experiment, it does not appear that the YoyoDDos infrastructure attempts to authenticate the individual bot clients that report in to the botnets.
Popularity: 3% [?]
[...] YoyoDDos: A new family of DDos bots | Security to the Core | Arbor Networks Security. [...]