As DDoS attacks grow more frequent, more powerful, and more sophisticated, many organizations turn to DDoS mitigation providers to protect themselves against attack.
Before evaluating DDoS protection solutions, it is important to assess the needs, objectives, and constraints of the organization, network and applications. These factors will define the criteria for selecting the optimal solution.
Distributed Denial of Service (DDoS) attacks have entered the 1 Tbps DDoS attack era. However, Radware research shows that DDoS attacks are not just getting bigger; they’re also getting more sophisticated. Hackers are constantly coming up with new and innovative ways of bypassing traditional DDoS defenses and compromise organizations’ service availability.
Your Service Level Agreement (SLA) is a crucial component of DDoS defenses. It is your contractual guarantee outlining what your DDoS mitigation provider will deliver and their obligation to remedy in case they do not meet those guarantees.
With the growing online availability of attack tools and services, the pool of possible attacks is larger than ever. Let’s face it, getting ready for the next cyber-attack is the new normal! This ‘readiness’ is a new organizational tax on nearly every employed individual throughout the world.
This is the last part of the blog series exploring the various alternatives for protection against DDoS attacks, and how to choose the optimal solution for you. The first part of this series covered premise-based hardware solutions, the second part discussed on-demand cloud solutions, and the third part covered always-on cloud solutions. This final piece will explore hybrid DDoS solutions, which combine both hardware and cloud-based components.
This blog series dives into the different DDoS protection models, in order to help customers choose the optimal protection for their particular use-case. The first parts of this series covered premise-based appliances and on-demand cloud services. This installment will cover always-on cloud DDoS protection deployments, its advantages and drawbacks, and what use-cases are best for it. The final part of this series will focus on hybrid deployments, which combine premise-based and cloud-based protections.
This blog series explores the various options for DDoS protection and help organizations choose the optimal solution for themselves. The first part of this series covered the premise-based DDoS mitigation appliance. This installment will provide an overview of on-demand cloud-based solutions. Subsequent chapters will also cover always-on and hybrid solutions.
Let’s take a journey through a real-life booter and stresser service to better understand the tools, the trade and pricing behind DDoS-as-a-Service.
A question that I’ve encountered many times in the field of late is what are the impacts of DDoS attacks on cloud compute environments? The primary benefit of cloud is that it elastically scales to meet variable demand, scale up instantly, scale down when demand subsides – in seconds… So layman’s logic might say that cloud-based services are immune from the downtime effects of DDoS attackers, however the possibility of gigantic unexpected bills is a given?
On February 8th, 2018, Radware’s Deception Network detected a significant increase in malicious activity over port 8080. Further investigation uncovered a new variant of the Satori botnet capable of aggressive scanning and exploitation of CVE-2017-18046 – Dasan Unauthenticated Remote Code Execution. Referred to as “Satori.Dasan,” it’s been rapidly expanding with a high success rate. The C2/Exploit server for this botnet is 185.62.188.88 (AS49349 – BlazingFast LLC, Ukraine)
It is not clear what is the purpose of this new botnet, as we were unable to find specific attack vectors in the binary.
Our analysis suggests that Satori is looking to take over 40,000 IoT devices to join its growing family of cryptocurrency miners, as we saw here, and here. This would make the Satori.dasan malware a stage #1 infection, responsible for rapidly scanning the internet looking for vulnerable devices.
Over the past two days Radware has detected over 2000 malicious Unique IPs daily, almost 10 times higher than the daily average in the weeks prior.
The majority of the traffic came from Vietnam originating almost entirely from an ISP named ‘Viettel.’
A significant percentage of those malicious bots were also listening themselves on port 8080.
By sampling roughly 1000 IPs and querying their server headers, Radware revealed that 95% identified themselves as running “Dasan Network Solution.”
A quick Shodan search revealed about 40,000 devices listening on port 8080, with over half located in Vietnam, and not surprisingly an ISP named ‘Viettell Corporation.’
The infected bots will perform aggressive scanning of random IP addresses, exclusively targeting port 8080. Once it finds a suitable target, it notifies a C2 server which immediately attempts to infect it.
See the following sequence captured at one of Radware’s sensors (10.0.0.70):
The infected bot sends a half-open stealth-scan SYN request to port 8080. Instead of Ack, a TCP Reset is sent. Typical to Mirai code, the initial TCP SYN packet contains a sequence number identical to the 32bit value of the target victim.
After 4 seconds, the bot establishes a 3-way TCP handshake to port 8080
The following 113 bytes payload is sent:
Note that this is not the actual exploitation attempt, but rather a screening process to find vulnerable hosts.
Radware’s Deception Network sensor is answering the probe with the following response:
The bot closes the connection.
Now comes the interesting part.
Notice the timestamp – it is just 106 milliseconds after the last packet and we suddenly get an exploitation attempt from a completely different IP address. This IP belongs to a central exploitation server running on 185.62.188.88
The exploit server sends the following payload over HTTPS port 8080:
The threat actors who operate this C2 Crime Server are responsible for numerous attacks that were recently covered by different security vendors, including Fortinet, 360netlab, SANS.
With some scanning, fuzzing and Open-Source Intelligence (OSINT0) we found some interesting details.
As with previous incidents, the domain rippr.me is used to point to the C2 server.
The following entries have an associated TXT record:
As we saw in the exploit payload, the server is listening on port 7777. Connecting to it brings the following download code:
So let’s get the file and check the contents:
It looks like a downloader that will be running on an infected device. The script downloads several versions of the binary and tries to execute it. If it fails (due to wrong CPU architecture), it will just go over to the next one.
Let’s grab the binaries (and guess some additional ones, like the x86_64). They look quite fresh according to server timestamps:
At the moment, VirusTotal already knows about the C2 address and shows that less than five antivirus products detect the files as malicious. Not very promising right now, but this should improve.
We will use this opportunity to submit some of the binaries that are missing in VT.
The Satori.Dasan variant is a rapidly growing botnet which utilizes a worm-like scanning mechanism, where every infected host looks for more hosts to infect. In addition, it also has a central C2 server that handles the exploitation itself once the scanners detect a new victim.
