ASERT Threat Intelligence Report 2015-07 Amplifying Black Energy

ASERT Threat Intelligence Brief 2015-07

© Copyright 2015 Arbor Networks, Inc. All rights reserved.

ASERT Threat Intelligence Report 2015-07

Amplifying Black Energy The Black Energy malware family has a long and storied history. Its original version, now referred to as Black Energy 1, was originally documented by Jose Nazario of Arbor Networks all the way back in 2007 [1]. At this time, Black Energy was exclusively a DDoS platform, and relatively unsophisticated. A few years later, in approximately 2010, an almost entirely new version of Black Energy (dubbed Black Energy 2) emerged and was documented by Joe Stewart of Secureworks [2]. It represented a significant advance in terms of sophistication; one notable change was BE2's new plugin architecture in which the responsibility of the core Black Energy framework was reduced to maintaining persistence on an infected host, communication with C&Cs, and installing modular plugins which performed all the actual dirty work. Various modules quickly appeared that allowed Black Energy 2 to fulfill its original DDoS role, but also to perform other nefarious activities, such as general-purpose info-stealing, web-based banking attacks, spamming, etc.

It appears that the Black Energy 2 code base has enjoyed a bit of a resurgence of late, and some researchers believe a full-blown Black Energy 3 has evolved. These new developments in the ongoing Black Energy saga have been well-documented by other researchers, such as Robert Lipovsky of ESET [3], Kurt Baumgartner and Maria Garnaeva [4], and Dmitry Tarakanov [11], of SecureList, and F-Secure [12]. In this report, we will limit the scope to documenting our findings regarding a particular Black Energy 2 plugin that we have observed in the wild, and for which we have not yet been able to find much, if any, previously published research. This new plugin, named ntp.dll, allows Black Energy 2 botnets to launch true distributed NTP reflection/amplification attacks.

Background: NTP Reflection/Amplification

DDoS via NTP reflection/amplification is a well-‐known technique that has been documented extensively; the basic concept is illustrated in Figure 1. Please see ASERT Threat Intelligence Report 2014-‐05 for an extensive treatment on the subject [5]. In essence, the attacker abuses the NTP protocol by sending a stream of GET_MONLIST requests to a vulnerable NTP server. This particular oddity of the NTP protocol causes the NTP server to respond with a list of the last 600 IP addresses which connected to said NTP server. Since these NTP requests and responses occur over UDP, it is possible for the attacker to replace his real (source) IP address with the IP address of his

Arbor Security Report: Amplifying Black Energy

2 Proprietary and Confidential Information of Arbor Networks, Inc.

target. The abused NTP server will then send the big response to the target instead of the attacker (hence the term “reflection”). In extreme cases, the size of the response can be 200 times larger than the size of the GET_MONLIST request (hence the term “amplification”).

Figure 1: The essence of an NTP reflection/amplification attack

There exist a variety of standalone tools and scripts (e.g., [6]), that allow either well-‐connected (and often compromised) Linux servers, or traditional clients (e.g., laptops) to launch NTP amplification attacks, both for Windows and Linux/Unix-‐like operating systems. However these are typically standalone tools (though sometimes installed on multiple servers) as opposed to traditional bot clients under the remote control of a C&C. There also exist some Linux-‐based bot families, such as XNote [7], that implement such NTP attacks while being remotely controlled via C&Cs. But as far as we know, this ntp.dll plugin to Black Energy 2 could be one of the first “traditional” (C&C-‐controlled, not standalone) Windows bots to correctly implement an NTP reflection/amplification attack. As an example of a Windows bot that tries and fails (miserably) to implement an NTP attack, we present Trojan.Megalodon, documented recently by Damballa [8]. We recently analyzed this poorly-‐written C# bot; among other things, it makes a very half-‐hearted attempt at implementing an “ntp” attack method. Figure 2 shows a decompilation of the complete attack implementation in all its glory. It is basically sending UDP datagrams containing the following 8-‐byte payload: 0x17 0x00 0x03 0x2A 0x00 0x00 0x00 0x00. This is indeed a correct NTP GET_MONLIST request. However, the bot seems to have missed the concept of “reflection”; it sends this GET_MONLIST request directly to the target, rather than a reflecting NTP server. So the attack essentially devolves into a generic, low-‐grade UDP flood. It also fails to spoof the source IP address, so in the unlikely event that the intended target host actually is an NTP server, and the target port is specified as 123 (ntp), the GET_MONLIST response will actually be sent back to the bot itself! In light of this property, and since it seems to be a requirement these days that all malware families be adorned with a nice piece of logo artwork, we'd like to propose Figure 3 as a logo for any future Megalodon panels.


© Copyright 2015 Arbor Networks, Inc. All rights reserved. 3

Figure 2: How not to implement an NTP Amplification attack (courtesy Trojan.Megalodon)

// attack_params are 3-tuple: (target_host, target_port, attack_duration) namespace ntp { internal class Program { private static void Main(string[] attack_params) { try { Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp); IPAddress address = IPAddress.Parse(attack_params[0]); IPEndPoint remote_end = new IPEndPoint(address, int.Parse(attack_params[1])); int num = Environment.TickCount / 1000; int num2 = int.Parse(attack_params[2]); while (Environment.TickCount / 1000 - num < num2) { socket.SendTo(new byte[] { 23,0,3,42,0,0,0,0}, remote_end); } } catch (Exception) {} } } }

Figure 3: <joke>Proposed panel logo for Trojan.Megalodon</joke>

All joking aside, we will now report the details of some of our recent findings on the ntp.dll DDoS plugin observed in Black Energy 2 botnets, which is a far more serious threat due to the quality of its implementation.

Representative Black Energy 2 Sample

The Black Energy 2 sample we observed downloading the ntp.dll plugin is as follows:

MD5: c5b71c52459c03e5e7c6f5f0cc2fc6fb SHA1: 8d20701bd846dc78e984074e408ac38ca33fe9ab SHA256: 76047a2d2973897a77cb91b5c66733f6e4925c061dedc044c51f7ab99623637d



Size: 190,976 bytes A/V Detections: BackDoor.BlackEnergy.45 (Dr. Web); Backdoor:Win32/Phdet.S (Microsoft)

This sample is configured to use the following three C&C server URLs:

http://wewwwwera.mcdir.ru/nasty/getcfg.php http://wewww44wera.mcdir.ru/nasty/getcfg.php http://weww884wwera.mcdir.ru/nasty/getcfg.php

From the first of these three C&Cs, we observed it download, in addition to other nastiness, the ntp.dll plugin that is the primary topic of this article. After decryption, this plugin has the following properties:

MD5: 113e937337a19f2dd0cacf6ce01b0a6e SHA1: 6eaf00a8a4e82606fc9e6656fc2ba5257126313f SHA256: 5277bacb794dd7ded99a86dacab6c8efc3642559690981924db22e45b238a7b1 Size: 285,697 bytes

Installation of Third Party DLLs

As discussed above, the key to successfully implementing an NTP reflection/amplification attack (or for that matter, any general form of UDP-‐based amplification attack, such as SSDP, etc.) is the ability to spoof the source IP address of packets. In general, this is not possible using any of the standard WinSock2 APIs such as socket(), sendto(), etc. It is true that WinSock2 does support a RAW_SOCKET mode that allows one to “manually” craft low-‐level packets. However, modern versions of Windows impose severe constraints on the use of such raw sockets; in particular, per the MSDN documentation [9]:

On Windows 7, Windows Vista, Windows XP with Service Pack 2 (SP2), and Windows XP with Service Pack 3 (SP3), the ability to send traffic over raw sockets has been restricted in several ways: UDP datagrams with an invalid source address cannot be sent over raw sockets. The IP source address for any outgoing UDP datagram must exist on a network interface or the datagram is dropped. This change was made to limit the ability of malicious code to create distributed denial-‐of-‐service attacks and limits the ability to send spoofed packets (TCP/IP packets with a forged source IP address).

The Black Energy ntp.dll plugin gets around this restriction by foregoing the use of WinSock2 raw sockets, and instead uses the WinPcap library [10] to craft and send raw packets. The APIs provided by this library allow Black Energy to precisely craft every byte of an outbound packet; in fact, as we will see below, the entire Ethernet frame itself is carefully fabricated, including MAC addresses. However, WinPcap is not installed on most Windows machines. So the ntp.dll plugin must see to it that the two core DLLs that implement the WinPcap API are installed, prior to engaging in any attack activity. These two DLLs are:

• wpcap.dll, which implements the high-level WinPcap API;



• Packet.dll, which provides the Win32-specific implementation for capturing and sending packets, and is similar to PF_PACKET sockets on Linux, BPF driver on BSD systems, etc.

The ntp.dll plugin will first call OpenSCManagerA(), OpenServiceA(), and StartServiceA() in an attempt to start the WinPcap service named “NPF” on the infected host. If this attempt succeeds, then it means that the WinPcap libraries are already properly installed on the host. If the NPF service could not be started, then it will try to directly invoke LoadLibraryA() on “wpcap.dll”; if this also fails, then the NTP plugin assumes WinPcap is not installed, and therefore performs the installation process itself (see Figure 4.)

Figure 4: Checking to see if WinPcap is already installed

For the majority of infected systems that require installation of WinPcap, the NTP plugin will first check the version of the Windows operating system to determine which version of Packet.dll to install. It does this via a call to GetVersionEx(); for infectees with a dwMajorVersion of 5 (i.e., Win2K, WinXP, Win2K3), it will use one version of Packet.dll; for infectees with a dwMajorVersion of 6 (i.e., Vista, Win7, and Win8), it will use a different version of Packet.dll. Regardless of Windows version, it will use a single version of wpcap.dll.

The binary contents of the three embedded DLLs (two versions of Packet.dll and one of wpcap.dll) are encrypted with the same modified-RC4 algorithm (documented initially by Joe Stewart [2]) used elsewhere by Black Energy 2, and are then compressed with LZ77. For each of the three embedded DLLs, Black Energy stores the necessary metadata in a small struct of the following form:



struct EMBEDDED_DLL_INFO { DWORD dwUncompressedSize; DWORD dwCompressedSize; DWORD dwLengthRC4Key; DWORD dwUnused; unsigned char pRC4Key_and_EncryptedAndCompressedBytes[]; };

This EMBEDDED_DLL_INFO struct specifies the sizes of the working buffers that need to be heap-allocated to store both the compressed and uncompressed DLL byte streams. The last field of this struct is the beginning of an array of raw bytes. The first dwLengthRC4Key bytes represent the key material used for the RC4 encryption of the DLL content; the remaining dwCompressedSize bytes represent the actual compressed and encrypted DLL content. The RC4 key length was 16 in our representative ntp.dll plugin sample.

The process by which Black Energy installs these DLLs is straightforward: it simply uses the hard-coded RC4 key to decrypt the compressed DLL bytes, and then performs LZ77 decompression to obtain the DLL file image. The decompressed DLL is then written to a new path located within the system temporary directory; i.e., whatever path is returned by a call to GetTempPathA().

Upon successful installation of these two DLLs, Black Energy will use LoadLibraryA() and GetProcAddressA() to obtain pointers to the following WinPcap API functions:

• pcap_open_live() • pcap_close() • pcap_findalldevs() • pcap_freealldevs() • pcap_geterr() • pcap_sendpacket()

The addresses of these dynamically loaded WinPcap API functions are stored in global variables for use by the NTP amplification attack routine.

In our representative version of ntp.dll, the three embedded DLLs had the following characteristics shown in Table 1:

Table 1: WinPcap DLLs embedded within the Black Energy NTP plugin

Name dwMajorVersion Installed Size MD5

Packet.dll 5 102,136 2ce150705bbeb30e6c8059cc530043aa

Packet.dll 6 98,040 86316be34481c1ed5b792169312673fd



wpcap.dll 5 and 6 282,360 4633b298d57014627831ccac89a2c50b

All three embedded DLLs claim to be version 4.0.1.2980 of the official WinPcap DLLs and are properly signed by Riverbed Technology, Inc.

Specification of Attack Parameters

Like all Black Energy 2 plugins, the operation of the ntp.dll plugin is parameterized; the values of those parameters are obtained from the C&C by the core Black Energy framework. A representative sample of an ntp.dll parameter set, in its original XML-style formatting as sent by the C&C, is as follows:

<ntp><ntp_freq>50</ntp_freq> <ntp_threads>5</ntp_threads> <servers> <server>158.46.94.140</server> <server>171.25.232.244</server> <server>172.25.39.242</server> <server>172.29.0.8</server> <server>176.100.101.20</server> <server>176.100.101.52</server> <server>176.100.42.131</server> <server>176.107.13.60</server> <server>176.118.252.27</server> <server>176.118.64.3</server> <server>176.124.144.54</server> <server>176.192.100.186</server> <server>176.192.100.187</server> <server>176.192.114.110</server> <server>176.192.114.45</server> <server>176.192.226.202</server> <server>176.192.38.138</server> <server>176.196.102.166</server> <server>176.196.105.55</server> <server>176.196.11.51</server> <server>176.196.131.5</server> <server>176.196.134.201</server> <server>176.196.156.169</server> <server>176.196.158.241</server> <server>176.196.161.50</server> <server>176.196.164.182</server> <server>176.196.179.78</server> <server>176.196.210.153</server> <server>176.196.226.9</server> <server>176.196.231.18</server> <server>176.196.235.89</server> <server>176.196.241.205</server> <server>176.196.242.138</server> </servers></ntp>

As can be seen, the NTP plugin may be configured to use dynamically-specified values for the number of concurrent attack threads (ntp_threads) and the delay, in milliseconds, between the sending of each spoofed UDP packet (ntp_freq). Of particular interest is the dynamically-specified list of NTP servers to use



for reflecting and amplifying the attack against a particular target. This particular plugin configuration specifies 33 NTP servers. Table 2 lists the country code, ASN, and organization associated with these NTP reflectors:

Table 2: Hosting information for NTP reflectors abused by Black Energy

NTP Server Country ASN Organization 158.46.94.140 RU 39927 e-light-telecom 171.25.232.244 RU 57700 deepco ltd 172.25.39.242 US 7018 at&t internet services 172.29.0.8 US 7018 at&t internet services 176.100.101.20 RU 49718 nizhnevolzhskie telecommunication networks real ltd. 176.100.101.52 RU 49718 nizhnevolzhskie telecommunication networks real ltd. 176.100.42.131 RU 57439 unet telecommunication ltd 176.107.13.60 RO 42998 cjsc pushkino-telecom 176.118.252.27 RU 52041 taimer. ru ltd. 176.118.64.3 RU 48128 obyedinyonniye lokalniye seti ltd 176.124.144.54 RU 59665 ultra-telecom llc 176.192.100.186 RU 12714 net by net holding llc 176.192.100.187 RU 12714 net by net holding llc 176.192.114.110 RU 12714 net by net holding llc 176.192.114.45 RU 12714 net by net holding llc 176.192.226.202 RU 12714 net by net holding llc 176.192.38.138 RU 12714 net by net holding llc 176.196.102.166 RU 39927 e-light-telecom 176.196.105.55 RU 39927 e-light-telecom 176.196.11.51 RU 39927 e-light-telecom 176.196.131.5 RU 39927 e-light-telecom 176.196.134.201 RU 39927 e-light-telecom 176.196.156.169 RU 39927 e-light-telecom 176.196.158.241 RU 39927 e-light-telecom 176.196.161.50 RU 39927 e-light-telecom 176.196.164.182 RU 39927 e-light-telecom 176.196.179.78 RU 39927 e-light-telecom 176.196.210.153 RU 39927 e-light-telecom 176.196.226.9 RU 39927 e-light-telecom 176.196.231.18 RU 39927 e-light-telecom 176.196.235.89 RU 39927 e-light-telecom 176.196.241.205 RU 39927 e-light-telecom 176.196.242.138 RU 39927 e-light-telecom

All but 3 of the 33 NTP reflectors chosen for use by Black Energy 2 are hosted in Russia, with two in the U.S. and one in Romania.



Crafting of Spoofed Ethernet Frames

As discussed above, the Black Energy NTP plugin goes to the trouble of installing WinPcap in order to give itself the ability to fabricate exactly the packets it uses to instigate its NTP reflection attacks. This section discusses in detail the steps the plugin performs in order to craft these packets. As an illustrative aid, we will use a contrived example in which the Black Energy C&C orders a hypothetical NTP attack against the host checkboot.mcdir.ru 1.

Upon receipt of an attack command from its C&C, the core Black Energy module (running as a thread within a svchost.exe process into which it was injected) will invoke the ntp.dll plugin's CommandHandler() exported API function; this is the standard mechanism used across all of Black Energy 2's plugin-centric architecture. The attack command itself would typically exist as an element within an encrypted XML-style transmission from the C&C, and would look something like this (with ellipses designating additional XML before and after the command section):

.... <cmds> <cmd>ddos_ntp_start checkboot.mcdir.ru</cmd> </cmds> ....

The Black Energy 2 core process will invoke the ntp.dll plugin's CommandHandler() API and pass both the command (ddos_ntp_start) and the target (checkboot.mcdir.ru in this contrived example.) CommandHandler() will execute this command by spawning multiple attack threads. In theory, the number of these attack threads is determined by the dynamically-specified ntp_threads parameter discussed above; however it seems that at least some versions of Black Energy 2 have a bug such that the ntp_threads parameter is ignored and a hard-coded value of 5 threads is always used.

Each thread will operate identically, and will operate in a continuous loop for the duration of the attack. At the initiation of a new attack, it will randomly choose one of the NTP servers to be the designated reflector/amplifier. To continue our contrived example, let us assume that our attack thread chooses 176.196.134.201 as the NTP reflector.

Next, the thread will perform a DNS lookup on the target hostname to obtain its current IP address. It performs this victim DNS lookup by using the DnsQueryA() API provided by the Windows DNSAPI library. At the time of writing, our hypothetical target host, checkboot.mcdir.ru, was resolving to 85.93.31.116.

So at this point, the task at hand is clear: to fabricate a packet that sends an NTP monlist request to NTP server 176.196.134.201, but spoofs the source IP address of the packet so as to trick the NTP server into

1 This server happens to host, among other forms of badness, a known Black Energy C&C.



believing that the request came from 85.93.31.116 (the intended victim of the attack.) Black Energy's NTP plugin fulfills this task with gusto, and goes the whole nine yards by generating a complete low-level Ethernet frame. It carefully fabricates each byte in this frame into a stack-allocated buffer, and then uses the pcap_open_live() and pcap_sendpacket() WinPcap APIs to deliver a sequence of these frames.

In our contrived example, the actual Ethernet frame that Black Energy will attempt to fabricate will look very similar to Figure 5:

Figure 5: Example monlist request to 176.196.134.201 spoofed as coming from 85.93.31.116

This 50-byte Ethernet frame consists of four layers: a 14-byte Ethernet II header, a 20-byte IPv4 header, an 8-byte UDP header, and an 8-byte NTP monlist request payload. Conceptually flattening these multi-encapsulated layers into a static data structure yields the fields shown in Table 3:

Table 3: Specific fields to be filled in to fabricate authentic-‐looking Ethernet frame

Offset Size Example Value Field 0x00 6 00:10:DB:EC:D5:06 Destination MAC address 0x06 6 40:A8:F0:1E:EF:30 Source MAC address 0x0c 2 0x0800 (IP) Ethertype 0x0e 1 0x45 (IPv4, 20 bytes) IP version and IP header length 0x0f 1 0x00 Differentiated Services Field 0x10 2 0x0024 (36 bytes) Total IP Length (IP header + IP payload data) 0x12 2 0xec61 (60513) IP Identification field 0x14 1 0x00 IP Flags 0x15 1 0x00 Fragment Offset 0x16 1 0xff (255) Time-to-live (TTL) 0x17 1 0x11 (17, UDP) Protocol 0x18 2 [computed dynamically] IP Header Checksum 0x1a 4 85.93.31.116 Source IP address 0x1e 4 176.196.134.201 Destination IP address 0x22 2 4950 (ephemeral) Source UDP port 0x24 2 123 (ntp) Destination UDP port



0x26 2 0x0010 (16 bytes) Total UDP length (UDP header + UDP payload) 0x28 2 [computed dynamically] UDP checksum 0x2a 1 0x17 NTP request, NTP version 2 0x2b 1 0x00 NTP authentication 0x2c 1 0x03 (XNTP) NTP implementation 0x2d 1 0x2a (MON_GETLIST) NTP Request Code

Many of these fields are static in the sense that, for the purposes of generating NTP reflection attacks, they will hold fixed values, as follows:

• Ethertype will always be 0x0800, corresponding to the Internet Protocol; • IP version and header length will always be the very common 0x45 representing IPv4 with the

standard 20-byte header; • The IP header's Differentiated Services Field will always be 0x00; • The Total IP Length field will always be 36 bytes (20 for IP header, 8 for UDP header, and 8 for NTP

payload); • The IP Flags and IP Fragment Offset will always be 0x00 since no fragmentation is needed; • The Time-to-live (TTL) for the packet will be set to its maximum value of 0xff; • The Protocol field will always be set to 0x11 for UDP; • The Destination UDP Port will always be 123 for NTP; • The Total UDP Length will always be 16 bytes (8 for UDP header and 8 for NTP payload); • The entire 8-byte NTP request payload will be static as well, and will simply request a MON_GETLIST

operation;

To fill in these fields, Black Energy simply writes the correct static byte values at the correct offsets.

Some of the other fields are also easy to fill in dynamically:

• The Source IP Address will be set to the intended target's IP address (85.93.31.116, corresponding to checkboot.mcdir.ru, in our contrived example);

• The Destination IP Address will be set to the randomly chosen NTP reflector server address (176.196.134.201 in our example);

• Source UDP Port will be a randomly generated 16-bit value; it is mildly interesting that Black Energy allows the entire 16-bit space of ports to be chosen, rather than restricting it to ephemeral ports above 1024;

• The IP Identification field will also be a randomly generated 16-bit value;

That leaves the physical MAC addresses and the IP and UDP checksum WORDs as the only remaining difficulties for the malcode.

To correctly fill in the MAC addresses, and thus ensure that the outgoing Ethernet frames successfully make their way from the infected client out to the Internet, eventually being routed to the NTP reflector, Black



Energy performs a decent amount of work. It uses several Win32 functions provided by the Iphlpapi.dll (IP Helper API) library.

It first calls GetBestInterface(), passing in the IP address of the chosen NTP reflector (e.g., 176.196.134.201) . This retrieves the numerical index of the infected host's network interface which provides the best route to the destination NTP server. It then alls GetAdaptersInfo() to obtain a pointer to a linked list of IP_ADAPTER_INFO structures for each interface on the infected host. It walks this linked list comparing the Index field of each structure with the best adapter index as previously retrieved from GetBestInterface(). Once it finds a match, it copies the AdapterName field.

It also locates the IP addresses (in dotted string notation) of both the infected host's interface and the interface's gateway; it does this by inspecting the first list elements of the IpAddressList and GatewayList fields of IP_ADAPTER_INFO, respectively. It uses inet_addr() to convert these human-readable dotted notation IP address strings into proper 32-bit integer representations of the IP addresses. As a last step, it will store the 6-byte physical MAC address of the infectee's interface. Figure 6 illustrates these operations.

At this point, it has obtained the source MAC address (of the infectee's interface), but still needs the destination MAC address (of this interface's gateway.) From the aforementioned inspection of GatewayList, it at least knows the IP address of the gateway. Conveniently for Black Energy, there is a protocol for obtaining the MAC address of an interface if one knows its IP address: ARP. So it will use the SendARP() API, also provided by Iphlpapi.dll, to emit an ARP request and thereby determine the MAC address of the infectee's gateway.

It has now assembled all the information it needs to fabricate an authentic-looking Ethernet frame. It writes each value into the proper location within the 50-byte frame buffer. For the IP header checksum, it implements the correct algorithm that sums the one's complements of each 16-bit WORD. Likewise, it goes to the trouble of assembling a UDP “pseudoheader' and using it to compute the correct 16-bit UDP checksum using a similar algorithm. The final product is a valid (though spoofed) 50-byte Ethernet frame that will be correctly transmitted to the infectee's gateway, and from there to the NTP reflector, presenting a GET_MONLIST request with output to be sent to the ultimate target IP address.

This Ethernet frame is sent along its way via a call to WinPcap's pcap_sendpacket() API. The attack thread runs in a loop, continuously fabricating and sending these Ethernet frames, with a short delay after sending each frame; the duration of this delay is controlled by the ntp_freq parameter; 50 milliseconds is a typical value.



Figure 6: Determining the IP addresses of the infectee's best NIC (for routing to NTP reflector) and its gateway

Each iteration through the loop, a new 50-byte Ethernet frame buffer is generated; the only fields that change are the Source UDP Port and the IP Identification fields, which are filled in with new randomly generated 16-bit values on each iteration. The IP Header and UDP Checksums are also re-calculated to take into account the new values in these two fields.

Every 15 minutes during the course of the attack, the thread will randomly choose a new NTP reflector server, and also perform a new DNS lookup of the target host - presumably to thwart possible victim evasive manouvers that involve changing DNS records. Since this 15-minute refresh entails possible new values for both the spoofed source IP (victim) and destination IP (reflector) addresses, the aforementioned routine of querying the infectee's interfaces and sending an ARP request to obtain physical MAC addresses is repeated.



Mitigation

From the point of view of the victim, mitigation of NTP amplification attacks comes down to filtering out the flood of GET_MONLIST response traffic reflected off the abused NTP servers. Please refer to [5] for a comprehensive strategy on this topic. It should also be mentioned that by monitoring the Black Energy botnets in order to extract the exact list of NTP reflectors used by the ntp.dll plugin (e.g., the 33 servers listed in Table 2 above), this task could become significantly simplified.

Summary

Black Energy's NTP plugin exhibits an impressive level of attention to detail relative to many other DDoS-centric malware families. Correctly fabricating “by hand” the 50-bytes of an Ethernet frame to yield a valid (though malicious) GET_MONLIST request is not rocket science, but it does require a degree of effort that is fairly uncommon amongst run-of-the-mill flooder bots. The quality of Black Energy's NTP attack code stands in stark contrast to the shoddy, and in some cases pathetic (we're looking at you, Trojan.Megalodon) attempts at NTP implementations seen in other Windows bots.

UDP-based reflection/amplification attacks in general, such as the NTP attack implemented by Black Energy, are already responsible for generating some of the largest volumetric DDoS floods observed on the modern Internet. By combining these powerful DDoS methods with the use of traditional Windows botnets as the original emitting source of spoofed request floods, it is possible that Black Energy could manage to increase the intensity of these dangerous attacks even further.

In addition, after gaining first-hand insight into the degree of craftsmanship present in the Black Energy ntp.dll attack code, it seems clear that development of additional forms of amplification attacks, such as SSDP (port 1900), would be well within the capabilities of the malcode author(s). It may just be a matter of time before we see additional plugins, most likely derivatives of the existing ntp.dll, that implement these other UDP-based amplification attacks.

As such, we will be keeping a close eye on Black Energy 2 for further developments in both its original DDoS arena, as well as other nefarious activities (banking, credential stealing, targetted attacks, etc.) into which it has ventured.



References

[1] Nazario, Jose. (2007). BlackEnergy DDoS Bot Analysis. http://atlas-public.ec2.arbor.net/docs/BlackEnergy+DDoS+Bot+Analysis.pdf

[2] Stewart, Joe. (2010). BlackEnergy Version 2 Analysis, https://web.archive.org/web/20150910050156/http://www.secureworks.com/cyber-threat-intelligence/threats/blackenergy2/

[3] Lipovsky, Robert. (2014). Back in BlackEnergy: 2014 Targeted Attacks in Ukraine and Poland. http://www.welivesecurity.com/2014/09/22/back-in-blackenergy-2014/

[4] Baumgartner, Kurt and Garnaeva, Maria. (2014, November). BE2 custom plugins, router abuse, and target profiles. https://securelist.com/blog/research/67353/be2-custom-plugins-router-abuse-and-target-profiles/

[5] Arbor Networks. (2014). ASERT Threat Intelligence Report 2014-5: Comprehensive Insight and Mitigation Strategies for NTP Reflection/Amplification Attacks. Available to Arbor Netwoks customers upon request.

[6] Vypor. (2014, April). NTP v4. http://pastebin.com/0nK7bJqM

[7] Help Net Security. (2015, September). New multi-purpose backdoor targets Linux servers. http://www.net-security.org/malware_news.php?id=2959

[8] Damballa. (2015, November). MegalodonHTTP Botnet Discovered. https://www.damballa.com/megalodonhttp-botnet-discovered-the-shark-paradox/

[9] Microsoft. (2015). MSDN Documentation. https://msdn.microsoft.com/en-us/library/windows/desktop/ms740548%28v=vs.85%29.aspx

[10] WinPcap.org. (2007). WinPcap Documentation. https://www.winpcap.org/docs/docs_40_2/html/main.html

[11] Dmitry Takrakanov. (2010, July). Black DDoS. https://securelist.com/analysis/publications/36309/black-ddos/

[12] F-Secure. (2014). BlackEnergy and Quedagh: The convergence of crimeware and APT attacks. https://www.f-secure.com/documents/996508/1030745/blackenergy_whitepaper.pdf

About ASERT

The Arbor Security Engineering & Response Team (ASERT) at Arbor Networks delivers world-‐class network security research and analysis for the benefit of today's enterprise and network operators. ASERT engineers and researchers are part of an elite group of institutions that are referred to as “super remediators,” and represent the best in information security. This is a reflection of having both visibility and remediation capabilities at a majority of service provider networks globally.

ASERT shares operationally viable intelligence with hundreds of international Computer Emergency Response Teams (CERTs) and with thousands of network operators via intelligence briefs and security content feeds.



ASERT also operates the world1s largest distributed honeynet, actively monitoring Internet threats around the clock and around the globe via ATLAS®, Arbor's global network of sensors: http://atlas.arbor.net. This mission and the associated resources that Arbor Networks brings to bear to the problem of global Internet security is an impetus for innovation and research.

To view the latest research, news, and trends from Arbor, ASERT and the information security community at large, visit our Threat Portal at http://www.arbornetworks.com/threats/.

ASERT Threat Intelligence Report 2015-07 Amplifying Black Energy

Documents

Transcript of ASERT Threat Intelligence Report 2015-07 Amplifying Black Energy