Please find this article in german here
Intro
About 12 months ago, we developed the concept of DDoS RedTeaming in order to better prepare our customers, who have already reached a high security maturity level, for attacks. The goal is always to find the real weak spots.
We quickly realised that we started at exactly the right time, as the corresponding ThreatActors also use OSINT methods in target selection to identify the really exciting and worthwhile attack points.
In recent months, the the KillNet group has shown that it has evolved from a standard level of mostly harmless attacks on websites to a real threat in a very short time. Killnet has, through training and learning, enabled itself to cause real damage in just 2 months by successfully attacking tax authorities, business portals, VPN/access gateways, logistics companies, payment providers, OAuth providers etc and forcing days of business interruptions.
Purpose of DDoS RedTeamings
Our performance reviews are about the basic functioning of the DDoS defence. The attacks take place under laboratory conditions, as we work with fixed targets, playbooks and procedures.
In RedTeaming, we are basically free in the choice of targets and weapons. There is a scope and a few insiders with whom we discuss our potential targets. The rest of the team (SOC, NOC, Support, Operations etc) don't know.
We have customers who have a hybrid solution in place to protect against volume attacks, with a local appliance and manual BGP announcements/changes. There, it's about testing the filters, alerting and workflows. Other customers test the settings of WAF/botnet defence against Layer7 attacks.
Basically, it's about testing whether the DDoS protection would actually withstand a real attack if the attacker had a little more skill and clout than a booter service.
The procedure
RedTeaming is about finding actual weak spots, before real attackers do.
To do this, we use various OSINT techniques and tools to obtain an overview of the infrastructure and identify potential points of of the infrastructure and identify potential points of attack. These can be very individual and allows us a good insight into the security maturity level.
RedTeamings can last for a week or a month, and we also have continuous engagements. It usually include a reconnaissance/recon phase in which we assess the infrastructure in use.
From this perspective, there is also a benefit for the client, as they see their infrastructure through hacker's glasses. In addition to the operated services and applications, we also look at the upstream connectivity, peerings, traceroutes, etc., to find out which protection provider we are dealing with.
After the Recon phase, we develop a plan of attack and carry out various small tests.
We often have success with direct attacks on individual services, mixing several attack types for maximum impact. In this way, we have developed several effective attack methods methods of attack that have not been seen by ITW before, but the details of which we share with DDoS protection providers.
For example, in the first set of screenshots, you can see how we used a targeted multiple attack on an application with only 6 Mbit traffic, and brought the application to a standstill. and brought the application to a halt.
The second row of screen shots shows an attack with unusual protocols (GRE/MPLS) against the router infrastructure of a data centre, which was not the anti-DDoS solution was not set. We were able to disrupt the 10 GB uplink so much with 5 GB/s of attack traffic, that most of the normal traffic was lost without the DDoS protection reacted to it.
We can use our own sensor
Emox/GNA" to
measure the traffic on the target and thus the quality of the DDoS protection solution. Above all, it is a question of
response time, ratio of clean traffic to attack traffic, detection of protection gaps
and potentially critical protocols.
Learnings and results
With RedTeaming, we deviate from the standard attack paths of a botnet and botnets and specifically look for vulnerabilities in infrastructure and and applications that have not been considered so far.
The customers learn whether there may still be weak points that have not yet been considered, and under what assumptions. not considered so far, and under which assumptions they can be exploited.
RedTeaming can greatly increase the level of protection against targeted attacks. attacks can be increased enormously.
We have also found that the maturity level of a dedicated BlueTeam can go from a slightly disastrous state (DRS Level 3 and below) (DRS Level 3 and below) to a very robust level of protection, if the threat and responsibility are taken seriously.
Examples
The following are further examples from a RedTeaming and a genuine attacks, in which gezielet attacks on neuralgic points were were difficult to defend and led to major problems
1.
One client had a very well set up defence and good team. We were able to 30 seconds downtime at the most, after which our attempts were were always blocked. The only point we found to be vulnerable after analysing the infrastructure was the vulnerable was the DNS infrastructure, which serves as the authoritative server for several thousand other customer domains; there were only 2 DNS servers, and they were on the same network segment. One night at 3am we then attacked the DNS servers with a layer 7 attack and brought them to their knees. Since the total Ingress traffic never exceeded 1 GB/s - mark and the requests were legitimate, the volume protection could not volume protection could not "see" this attack, and it was successful. By the way, protection against such an attack is very simple: "Fallback DNS with Anycast: a simple way to strengthen DNS infrastructure against DDoS attacks".
2.
ECommerce companies with turnovers in the 2-digit millions in a highly competitive market segment. Acquiring new customers during campaign periods is extremely important, high advertising budgets are regularly allocated for this purpose.
A targeted attack on customer registration can cause heavy losses for this company without losses to this company without this attack being noticed immediately. It is not necessary to disrupt the application on a large scale; It is enough to slow down the process so much that hardly any new new customers register. This has the advantage that the monitoring monitoring may not notice this directly and therefore the attack remains unnoticed.
We saw exactly such an attack during an incident response job for a client. for a customer. The attack led to a loss of 30,000 euros/day over 10 days before it was even noticed.
Fragen? Kontakt: info@zero.bs