Necurs += DDoS
World’s largest spam botnet (5 million bots) adds proxy module with DDoS features, but will it really be used that way?
Necurs is a malware that is mainly known for sending large spam campaigns, most notably the Locky ransomware. However, Recurs is not only a spambot, it is a modular piece of malware that is composed of a main bot module, a userland rootkit and it can dynamically load additional modules.
At first look, it seemed to be a simple SOCKS/HTTP proxy module, but as we looked at the commands the bot would accept from the C2 [port 5222] we realised that there was an additional command, that would cause the bot to start making HTTP or UDP requests to an arbitrary target in an endless loop, in a way that could only be explained as a DDOS attack.
Please notice that we have not seen Recurs being used for DDOS attacks, we simply saw that it has that capability in one of the modules that it has been loading
The rest of their post contains the results of a technical analysis of this module, detailing its C2 protocol, the SOCKS/HTTP proxy features, and the DDOS attack features.
The sheer size of the Necurs botnet, even in its worst days, dwarfs all of today’s IoT botnets. The largest IoT botnet ever observed was Mirai Botnet #14 that managed to rack up around 400,000 bots towards the end of 2016.
“The proxy/DDoS module is quite old,” said MalwareTech, a security researcher that has tracked Necurs’ evolution for years. “I imagine it was put in as a potential revenue stream but then they found there was more money in spam.”
Outside a higher revenue stream the Necurs gang stands to earn from spam, we must also take into consideration other reasons why it’s highly unlikely that we’re going to see DDoS attacks from Necurs.
Recurs’ authors have invested time and money into developing a professional, well-oiled cyber-crime machine. There is no reason to risk their steady revenue stream just for the sake of running a DDoS-for-hire service from which they have only to lose.
Mathematically, it makes no sense to destroy three revenue streams (Dridex, Locky, and rentable spamming service) just for the sake of creating and supporting a DDoS booter service.
Les serveurs mail de Microsoft n’acceptent pas d’emails envoyés par de nouveaux serveurs.
Il ne suffit plus de configurer correctement son serveur mail, il faut en plus l’inscrire chez MS.
Senden Sie E-Mails über eine neue IP-Adresse?
IP-Adressen, die bisher noch nicht für das Senden von E-Mails verwendet wurden, verfügen in unserem System noch über keinerlei Eintragungen zur Zuverlässigkeit. Daher können bei E-Mails, die von neuen IP-Adressen gesendet werden, mit höherer Wahrscheinlichkeit Zustellbarkeitsprobleme auftreten. Nachdem sich die IP-Adresse durch das Nichtversenden von Spam als zuverlässig erwiesen hat, wird in Outlook.com in der Regel eine bessere Zustellbarkeit für E-Mails erreicht.
Neue IP-Adressen, die für Domänen hinzugefügt werden, die über vorhandene SPF-Einträge authentifiziert wurden, übernehmen in der Regel einen Teil der Sendezuverlässigkeit der Domäne. Wenn die Domäne über eine gute Sendezuverlässigkeit verfügt, ist für neue IP-Adressen möglicherweise eine schnellere Anlaufzeit festzustellen. Eine neue IP-Adresse wird spätestens nach einigen Wochen vollständig akzeptiert. Ausschlaggebend sind hierbei jeweils das Volumen und die Listengenauigkeit – vorausgesetzt, es liegen möglichst wenig Junk-E-Mail-Beschwerden vor.
Hinweis: Denken Sie daran, Ihr JMRP-Konto (Junk E-Mail Reporting Program, Junk-E-Mail-Meldeprogramm) mit den neuen IP-Adressen zu aktualisieren. Wenn Sie ein JMRP-Konto aktualisieren oder einrichten möchten, klicken Sie auf hier
Dienste für Absender und Internetdienstanbieter
Comme tout est payant chez MS ils conseillent de souscrire un abonnemenet chez un service de maintien de réputation. Pourtant on peut effectivement s’en passer sauf si on est en train de monter un service de mailings commerciaux.
Ein Akkreditierungs-/Reputationsdienst eines Drittanbieters mit dem Zweck, Absendern den Status eines sicheren Absenders zu verleihen
Weitere Informationen finden Sie unter ▻http://g.live.com/9wc9en-us/senderscore
Wenn Hotmail Deine Mailserver abweist
Comment j’ai appris cette « nouvelle » ? Notre fournisseur de serveurs héberge des serveurs piratés et MS a mis sur ses blocklists de réseaux IP entiers.
In unsere “Nachbarschaft” bei Hetzner gab es wohl einige SPAM Schleudern so das Hotmail ganze Netzsegmente auf eine “schwarze Liste” gestellt hat. Unsere Server selbst ist sauber.
Nach etwas Suchen bin ich auf diese Seite gestoßen. Hier kann man beantragen das eine IP Adresse wieder freigeschaltet wird.
Il faut demander gentiment qu’ils vérifient un peu, et hop, quelques heures plus tard ca roule. MS réagit nettement plus vite et mieux que Google.
Après (enfin, de préférance préalablement) il faut toujours installer les protocoles de vérification qui améliorent la fiabilité de la communication avec les grands fournisseurs de services email.
Ubuntu+ISPConfig+DKIM | Howtoforge - Linux Howtos and Tutorials
How Senders Deploy DMARC in 5-Easy Steps
Cette liste décrit les étapes essentielles pour transformer un serveur mail traditionnel en machine acceptée par la majorité de ses interlocutrices. Il ne faut jamais oublier que ce sont des conventions qui évoluent et ne sont pas parfaites du tout.
DMARC has been designed based on real-world experience by some of the world’s largest email senders and receivers deploying SPF and DKIM. The specification takes into account the fact that it is nearly impossible for an organization to flip a switch to production. There are a number of built-in methods for “throttling” the DMARC processing so that all parties can ease into full deployment over time.
1. Deploy DKIM & SPF. You have to cover the basics, first.
2. Ensure that your mailers are correctly aligning the appropriate identifiers.
3. Publish a DMARC record with the “none” flag set for the policies, which requests data reports.
4. Analyze the data and modify your mail streams as appropriate.
5. Modify your DMARC policy flags from “none” to “quarantine” to “reject” as you gain experience.
A DMARC record was detected while looking for an SPF record. DMARC records must be located at “_dmarc.rezo.net”, and not directly at “rezo.net”.
The SPF record authorizes 8 individual netblocks using 3 DNS-querying mechanisms/modifiers. The maximum number of DNS-querying mechanisms/modifiers is 10.
This record utilizes a small number of DNS-querying mechanisms/modifiers. No fixing is required. If this record is meant to be included by other records, consider reducing the number of DNS-querying mechanisms/modifiers (if possible) to keep total resource consumption low.
Duplicate netblock authorization:
The following netblocks have been authorized more than once. Duplicates usually indicate inefficient records or redundant “include:” mechanisms, and should be removed:
netblock # of occurrences
Record flattening (experimental!):
The dmarcian SPF Record Flattener (experimental!) rewrites this record by removing duplicate netblocks, collapsing any overlapping netblocks, and using 0 DNS-querying mechanisms/modifiers. Each SPF record is kept to less than 512 bytes to fit into a single UDP packet (assuming no other TXT records are sharing the DNS label).
NOTE: this approach does not take into account administrative or domain boundaries, and is meant to show that “minified” SPF records are possible. The presence of unusual qualifiers, macros, and creative semantics will likely yield less than optimal results.
rezo.net v=spf1 ip4:126.96.36.199/23 ip4:188.8.131.52/22 ip4:184.108.40.206/24 ip6:2001:67c:288::/48 ip6:2a00:99a0::/128 ~all
NewWorldHackers & Anonymous are behind the massive DDoS attack against Dyn DNS service, using the Mirai bonnet and other booters
When I asked which Anon groups were involved they replied me that many crews targeted the Dyn DNS service.
“Anonymous, Pretty much all of Anonymous” sais NewWorldHackers.
They confirmed me that they are testing the capability of their botnet, highlighting that the DDoS attack against the Dyn DNS Service was carried with the Mirai botnet alongside with other booters.
Statement by Dyn
We can confirm, with the help of analysis from Flashpoint and Akamai, that one source of the traffic for the attacks were devices infected by the Mirai bonnet. We observed 10s of millions of discrete IP addresses associated with the Mirai botnet that were part of the attack.
Krebs’s view on this
“The issue with these particular devices is that a user cannot feasibly change this password,” Flashpoint’s Zach Wikholm told KrebsOnSecurity. “The password is hardcoded into the firmware, and the tools necessary to disable it are not present.
Rumours about extorsion
Cunningham [director of cyber operations for A10 Networks] says he’s seen chatter on underground forums indicating that the attackers tried to extort Bitcoin from Dyn by threatening the attacks, and when the provider didn’t pay up, launched them. He says Dyn seems to be doing a pretty good job of mitigating the effects relatively quickly.
Lengthy and interesting article by #Level3 on Mirai, containing information on the C2s (command & control servers) and the structure of the botnet
By analyzing the communication patterns of the Mirai C2 IP addresses, we were able to identify and enumerate Mirai’s infrastructure. This analysis was later confirmed accurate when the Mirai source code was released.
Chinese firm admits its hacked DVRs, cameras were behind [Dyn DNS] massive DDOS attack
Hangzhou Xiongmai Technology, a vendor behind DVRs and internet-connected cameras, said on Sunday that security vulnerabilities involving weak default passwords in its products were partly to blame.
DDos On Dyn Used Malicious TCP, UDP Traffic
Scott Hilton, executive vice president of product for Dyn, in a blog post said the attackers employed masked TCP and UDP traffic via Port 53 in the attack as well as recursive DNS retry traffic, “further exacerbating its impact,” he said.
He noted that the DNS traffic sent in the DDoS attacks also generated legitimate DDoS retry traffic, making the attack more complicated to parse, and the attack generated ten- to 20 times the normal DNS traffic levels thanks to malicious and legit retries.
“During a DDoS which uses the DNS protocol it can be difficult to distinguish legitimate traffic from attack traffic,” he said in the post. “When DNS traffic congestion occurs, legitimate retries can further contribute to traffic volume. We saw both attack and legitimate traffic coming from millions of IPs across all geographies.”
More on Mirai, and more than Mirai
Akamai says Mirai was not alone:
While Akamai confirmed that the Mirai botnet was part the attack, the company also said that Mirai was only “a major participant in the attack” and that at least one other botnet might have been involved, though they couldn’t confirm that the attacks were coordinated.
Akamai refers to Mirai as Kaiten and has it documented here:
More on the released source code of Mirai which confirms the use of GRE flooding, one of the techniques used on top of DNS Water Torture:
A copy of the source code files provided to SecurityWeek includes a “read” where the author of Mirai explains his reasons for leaking the code and provides detailed instructions on how to set up a botnet.
Mirai, believed to have made rounds since May 2016, infects IoT devices protected by weak or default credentials. Once it hijacks a device, the threat abuses it to launch various types of DDoS attacks, including less common UDP floods via Generic Routing Encapsulation (GRE) traffic.
This was proven through reverse-engineering by
It is still GRE is still an uncommon attack vector, but it was already used during the 2016 Rio games
What cameras, IoT and DVR devices are taking part of Mirai ?
But one researcher, Flashpoint’s Zachary Wikholm, today claimed to have found a single Chinese firm, Hangzhou XiongMai Technologies (XM), that shipped flawed code allowing the perpetrators to potentially amass nearly half a million bots for their malicious network.
Interesting article by F5 which goes in a bit more detail about the two types of GRE flood attacks (Ethernet and IP based)
They also make a reference to the origin of the Mirai name:
It seems that the bot creator named his creation after a Japanese series “Mirai Nikki (The Future Diary)” and uses the nickname of “Anna-senpai” referring to the “Shimoneta” series.
Here are the 61 passwords that powered the Mirai IoT botnet
Some more information on its spread, operations, and code, by Incapsulate.
One of the most interesting things revealed by the code was a hardcoded list of IPs Mirai bots are programmed to avoid when performing their IP scans.
This list is interesting, as it offers a glimpse into the psyche of the code’s authors. On the one hand, it exposes concerns of drawing attention to their activities. A concern we find ironic, considering that this malware was eventually used in one of the most high-profile attacks to date.
HTTP GET floods were already pernicious. For years, attackers have been able to disable web sites by sending a flood of HTTP requests for large objects or slow database queries. Typically, these requests flow right through a standard firewall because hey, they look just like normal HTTP requests to most devices with hardware packet processing. The Mirai attack code takes it a step further by fingerprinting cloud-based DDoS scrubbers and then working around some of their HTTP DDoS mitigation techniques (such as redirection).
Mirai botnet leverages #STOMP Protocol to power DDoS attacks.
STOMP is a simple application layer, text-based protocol [an alternative to other open messaging protocols, such as AMQP (Advanced Message Queuing Protocol] that allows clients communicate with other message brokers. It implements a communication method among for applications developed using different programming languages.
Below the steps of the DDoS STOMP attack:
• A botnet device uses STOMP to open an authenticated TCP handshake with a targeted application.
• Once authenticated, junk data disguised as a STOMP TCP request is sent to the target.
• The flood of fake STOMP requests leads to network saturation.
• If the target is programmed to parse STOMP requests, the attack may also exhaust server resources. Even if the system drops the junk packets, resources are still used to determine if the message is corrupted.
How Mirai Uses STOMP Protocol to Launch DDoS Attacks
Mirai botnet with 400.000 devices now for rent
A DDoS-for-hire service, run by two hackers going by the pseudonyms Popopret and BestBuy, is now reportedly advertising a Mirai botnet up for rent. The Mirai botnet allegedly comprises of over 400,000 infected bots and may have been sired from the original Mirai source code.
renting the botnet does not come cheap. Customers desiring to rent the botnet must do so for a minimum of two weeks. However, clients can determine the amount of bots, the attack duration and the DDoS cool down (a term which refers to the length of time between consecutive attacks).
Popapret and BestBuy’s Mirai botnet is a more evolved version of the original botnet. The two hackers have added new features, such as brute-force attacks via SSH and support for exploiting zero-day vulnerabilities. According to two security researchers, going by handle 2sec4u and MalwareTech on Twitter, some of the newly created Mirai botnets can now carry out DDoS attacks by spoofing IP addresses and may also be capable of bypassing DDoS mitigation systems.
Understanding the Mirai Botnet
In this paper, we provide a seven-month retrospective analysis
of Mirai’s growth to a peak of 600k infections and a history of its DDoS victims. By combining a variety of measurement perspectives, we analyse how the botnet emerged, what classes of devices were affected, and how Mirai variants evolved and competed for vulnerable hosts. Our measurements serve as a lens into the fragile ecosystem of IoT devices. We argue that Mirai may represent a sea change in the evolutionary development of bonnets—the simplicity through which devices were infected and its precipitous growth, demonstrate that novice malicious techniques can compromise enough low-end
devices to threaten even some of the best-defended targets.
To address this risk, we recommend technical and nontechnical
interventions, as well as propose future research directions.
New ransomware variant integrates DDoS attack capabilities
We recently found a ransomware variant that not only holds the victim’s machine and data hostage [by file encryption and screen locking] until a ransom is paid, but also exploits the compromised machine as part of a potential DDOS attack. This means that while the victim is unable to access their endpoint, that same endpoint is being used to deny service to another victim.
The observed network traffic looks to be flooding the subnet with UDP packets over port 6892. By spoofing the source address, the host could direct all response traffic from the subnet to a targeted host, causing the host to be unresponsive.
The ransomware is based on a modified version of the Cerber strain, which executes malicious MS Office VBScript.
On a beaucoup parlé des attaques #DoS par réflexion + amplification en les présentant souvent comme spécifiques à #UDP. Mais un article récent (mais passé curieusement inaperçu) montre qu’on peut en faire également avec #TCP.
TCP Handshake Amplification
DDoS amplification attacks currently typically use UDP-based protocols with spoofed source IPs. The reason being that there is no 3-way handshake in UDP.
However, it turns out there are TCP-based protocols are also vulnerable to amplification attacks. Better even, the handshake itself can be abused for amplification.
Authors of the 2014 research mentioned in Stéphane’s article (and below) have identified 4.8 million devices vulnerable to an average TCP-based amplification factor of 112x. Of those, they identified thousands of hosts that can be abused for an amplification of almost 80.000x.
They identified that there are hosts responding to a SYN with an excessive amount of RST packets, and others that transmit actual payload data via PSH packets – even before the three-way handshake has been completed.
From the point of view of an attacker, the number of amplifiers is important to scale up the overall attack bandwidth.
Compared to UDP-based amplification attacks, the fact that there are much more amplifiers makes this form still the most attractive.
An attacker has to scan many more IPv4 hosts in order to find a large enough number of TCP-based amplifiers.
Why would TCP-based amplifiers be interesting?
• They could be interesting to attackers who have little bandwidth available and who want to amplify as much as possible.
• Also, TCP traffic is considerably harder to filter at the network edges than UDP-based protocols. It is not easy to make a difference between legitimate and malicious TCP traffic without appliances that keep trace of and inspect the states of TCP connections.
• Another reason why TCP-based is more complicated is that TCP-based amplification traffic does not carry payload that can be inspected for validity.
Hell of a Handshake: Abusing TCP for Reflective Amplification DDoS Attacks
(Marc Kuhrer, Thomas Hupperich, Christian Rossow, Thorsten Holz)
SYN/ACK: The majority of amplifiers cause amplification by repeatedly retransmitting SYN/ACK packets upon our SYN segments. This attack type amplifies traffic up to 80x on average, and for SIP even up to 1,596x.
PSH: The number of amplifiers that transmit payload data via PSH (without a completed handshake) is low for most protocols. Nevertheless, the amplification factor is higher compared to the SYN/ACK amplifiers.
RST: The by far highest amplification is observed for hosts that transmit a tremendous number of RST segments. As such, an attacker could abuse the 4,242 vulnerable Telnet hosts to achieve an average amplification rate of 79,625x. Compared to SYN/ACK, the RST amplifiers of most protocols also have a much higher traf- fic volume—even though the number of hosts is significantly lower. That is, the 8,863 SYN/ACK amplifiers of NetBIOS transmitted about 25 MB of traffic, while the RST amplifiers caused traffic of more than 12 GB. Similarly, even though we observed most of the FTP ampli- fiers sending SYN/ACK packets (causing a total of 3.2 GB of traffic), the RST amplifiers transferred 15.1 GB of traf- fic in the same amount of time, a multitude of factor 5x.
A New DDoS Reflection Attack: Portmapper (TCP/UDP 111)
Portmapper is a mechanism to which Remote Procedure Call (RPC) services register in order to allow for calls to be made to the Internet.
When a client is looking to find the appropriate service, the Portmapper is queried to assist. The response size varies wildly depending on which RPC services are operating on the host.
It already has been used in a number of attacks, with the largest impact to organizations taking place August 10 through 12. These attacks targeted only a subset of verticals, primarily focused on gaming, hosting and Internet infrastructure
On the high end of the spectrum, we have seen responses as large as 1930 bytes for an amplification of 28.4x.
We recommend disabling Portmapper along with NFS, NIS and all other RPC services across the open Internet as a primary option. In situations where the services must remain live, firewalling which IP addresses can reach said services and, subsequently, switching to TCP-only are mitigations to avoid becoming an unknowing participant in DDoS attacks in the future.
Torrent clients and BitTorrent Sync can be leveraged for DrDoS attacks
In this paper, we demonstrate that the BitTorrent protocol family is vulnerable to distributed reflective denial-of-service (DRDoS) attacks. Specifically, we show that an attacker can exploit BitTorrent protocols (Micro Transport Protocol (uTP), Distributed Hash Table (DHT), Message Stream Encryption (MSE))and BitTorrent Sync (BTSync) to reflect and amplify traffic from peers.
We validate the efficiency, robustness and evadability of the exposed BitTorrent vulnerabilities in a P2P lab testbed. We further substantiate the lab results by crawling more than 2.1 million IP addresses over Mainline DHT (MLDHT) and analyzing more than 10,000 BitTorrent handshakes. Our experiments reveal that an attacker is able to exploit BitTorrent peers to amplify the traffic up to a factor of 50 times and in case of BTSync up to 120 times.
Additionally, we observe that the most popular BitTorrent clients are the most vulnerable ones. (uTorrent, Mainline Vuze)
We showed that anattack is quite difficult to circumvent, as the found vulnerabilities can only be defended with a DPI firewall. In case of a MSE handshake, it is even harder to detect the attack, since the packet contains a high entropy payload with a public key and random data.
BitTorrent Inc has been notified about the vulnerabilities and patched some in a recent beta release. For now, however, uTorrent is still vulnerable to a DHT attack. Vuze was contacted as well but has yet to release an update according to the researcher.
Arstechnica also wrote about it:
En Français :
New DRDoS (Distributed Reflection Denial-of-Service) based on NTP, similar to the previous DNS open resolver based DDoS in 2013
The mechanism is to spoof UDP port 123 packets with a REQ_MON_GETLIST request, which will return the last 600 clients with NTP requests and hence the significant BAF - Bandwidth Amplification Factor. NTP is reflection-vulnerable as it does not validate the source IP of the sender.
Affected are all versions of ntpd prior to 4.2.7p26;
this last version has disabled support for MON_GETLIST
How to test if you are vunerable ?
ntpq -c rv
ntpdc -c sysinfo
ntpdc -n -c monlist
If the last command returns nothing then you’re OK.
If it returns a whole list of hostnames and IP addresses, then you know what time it is…
Download version 4.2.7p26 or later: ▻http://www.ntp.org/downloads.html
Disable queries: if update is not possible in your environment then a workaround is to disable status queries by adding to /etc/ntp.conf:
For IPv4 : restrict default kod nomodify notrap nopeer noquery
For IPv6: restrict -6 default kod nomodify notrap nopeer noquery
(restart ntpd after the change)
Allow status queries but disable “ntpdc –c monlist” via “disable monitor”
Either approach is a good idea because
(a) you protect your network from unwanted reconnaissance, as monlist is included in network tools such as NMAP or metasploit
(b) you avoid participating in DRDoS attacks and probably also suffering from it.
Official Security Reports :
NIST reference of the vulnerability
CERT vulnerability notice
Other reports on this NTP DRDoS :
very good : "Understanding and mitigating NTP-based DDoS attacks" - ▻http://blog.cloudflare.com/understanding-and-mitigating-ntp-based-ddos-attacks
"New DoS attacks taking down game sites deliver crippling 100Gbps floods" ▻http://arstechnica.com/security/2014/01/new-dos-attacks-taking-down-game-sites-deliver-crippling-100-gbps-flood
"Les attaques DDoS sur l’industrie du jeu mettent en lumière les faiblesses de sécurité du NTP" ▻http://www.pcworld.fr/jeux-video/actualites,attaques-ddos-steam-origin-league-leagends-planetside-guild-wars-
"Hardening Cisco Routers - Chapter 10: NTP" - ▻http://oreilly.com/catalog/hardcisco/chapter/ch10.html
Lest anyone think that #D-Link is the only vendor who puts #backdoors in their products, here’s one that can be exploited with a single #UDP packet, courtesy of #Tenda :
▻http://www.devttys0.com/2013/10/from-china-with-love #router #CPE
Downloads of LOIC DoS Attack Tool Spike as Anonymous Inspires Online Protests | SecurityWeek.Com
As Anonymous initiated what it said will be the “largest attack ever on government and music industry sites” in response to actions taken by the Justice Department against operators of file sharing site Megaupload.com, downloads of a popular DoS attack tool have spiked.
Anonymous DDoS AttacksWhile the Denial of Service tool known as the “Low Orbit Ion Cannon” (LOIC) was developed by the “good guys” to stress test websites, it has been a favorite tool of Anonymous to take its targets offline by sending a flood of TCP/UDP packets in an attempt to overwhelm a system and make it inaccessible.