Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


A New Botnet Hits Servers With 150 Gbps DDoS Attacks
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

A New Botnet Hits Servers With 150 Gbps DDoS Attacks

Just yesterday, Akamai’s Security Intelligence Response Team announced that it’s discovered a new botnet that uses a 150 Gbps onslaught to bring servers and websites to their knees.

The Linux-based botnet spreads aboard a Trojan that’s called XOR DDoS. It wriggles its way into Linux systems by attacking embedded devices — things like routers — and then gains SSH (secure shell) access. Once it’s achieved that, it can happily download a small piece of botnet hardware, turning the system into yet another node in the botnet that can happily do the same thing.

While the security team has known about the botnet for over a year, it has only recently been observed taking hold in the wild. It’s said to strike up to 20 times a day, largely being used to attack Asian gaming and education sites at the moment, and has been observed to throw attack of up to 150 Gbps at servers. That is huge – easily enough to bring down most commercial servers.

It remains to be seen how widespread an impact XOR DDoS will have. But individuals — and companies — that run Linux systems may want to double down on security.

Source: http://www.gizmodo.co.uk/2015/09/a-new-botnet-hits-servers-with-150-gbps-ddos-attacks/

Comments

  • I presume it downloads some 'software' not hardware :)

    Thanked by 1Maounique
  • Yeah I thought the same lol

  • ClouviderClouvider Member, Patron Provider

    Sounds like fun for the providers now :-).

  • pbgbenpbgben Member, Host Rep

    I don't see why peers don't come together to setup a system that is able to detect where the traffic is coming from and block it at the source.. Or near enough to it.

  • ClouviderClouvider Member, Patron Provider

    @pbgben said:
    I don't see why peers don't come together to setup a system that is able to detect where the traffic is coming from and block it at the source.. Or near enough to it.

    I suppose the source is changing / expanding as these are, for example, home routers.
    You would also indefinitely penalize users who have no idea what happened, and whose routers have been supplied by their carriers.

    The vector of the attack is probably dynamic too, so it will be quite hard to eradicate this botnet.

  • tomletomle Member, LIR

    @Clouvider said:
    I suppose the source is changing / expanding as these are, for example, home routers. > You would also indefinitely penalize users who have no idea what happened, and whose routers have been supplied by their carriers.

    Maybe this could lead to a good thing where users are complaining to their providers that "Internet is not working". Then providers would finally have to take some responsibility for the crap that they send out to their users.

  • ClouviderClouvider Member, Patron Provider

    tomle said: Then providers would finally have to take some responsibility for the crap that they send out to their users.

    Ok, they would. Say they would replace the device, what if the users would still be unable to access some services? Who would be responsible then ? Routing, or blocking on a global/network is not a good idea.

  • MaouniqueMaounique Host Rep, Veteran

    Clouvider said: what if the users would still be unable to access some services

    They will change to a provider which is not blocked because monitors attacks from inside their network.

  • Aren't SSDP attacks larger? Should we be more afraid of SSDP attacks than this?

  • @GIANT_CRAB said:
    Aren't SSDP attacks larger? Should we be more afraid of SSDP attacks than this?

    This is UDP directly , botnet.
    All SSDP attacks , NTP (most bigger) , DNS (most bigger) are blocked on newest firewalls.
    A few firewalls can block a UDP botnet

  • @Zeast said: This is UDP directly

    No. XOR.DDoS uses large SYN packets. The botnet has both been active and common since this time last year, so article is really late.

  • @Flapadar said:
    No. XOR.DDoS uses large SYN packets. The botnet has both been active and common since this time last year, so article is really late.

    The important thing is that is not SSDP, NTP, DNS

  • netomxnetomx Moderator, Veteran

    Zeast said: (most bigger) , DNS (most bigger)

    My grammar book commited suicide u.u

  • ZeastZeast Member
    edited September 2015

    @netomx said:
    My grammar book commited suicide u.u

    :'(

    Thanked by 2netomx linuxthefish
  • singsingsingsing Member
    edited October 2015

    https://isc.sans.edu/forums/diary/XOR+DDOS+Mitigation+and+Analysis/19827/

    It was not proven, but believed that ssh brute force was the incoming vector of attack.

    So, care to share the root password of the victim system you set up to test this, so we can evaluate the likelihood?

    Once the attackers were onto the server, a root kit trojan was used. A very intelligent one. ... The malware creates random string startup scripts and places them in /etc/init.d. You need only to execute ls /etc/init.d to discover some evidence. Along with the use of the top utility, you can determine how many are running.

    Yep, that sounds like a very intelligent root kit trojan.

    From a page linked from that one, however:

    https://www.fireeye.com/blog/threat-research/2015/02/anatomy_of_a_brutef.html

    The rootkit used by XOR.DDoS loads itself as a LKM. Its primary purpose is to hide indicators of compromise at the kernel level. It has functions for hiding processes, files, ports, and controlling netfilter (Linux kernel firewall).

    A compromised system should be isolated from the network, to the extent possible, and cleaned of all IoC’s (see appendix). If a version of XOR.DDoS containing a rootkit has compromised the system, removal may not be feasible.

    So it appears that are rootkit versions and non-rootkit versions.

  • @dediserve said:
    I presume it downloads some 'software' not hardware :)

    Crap... Does that mean that we can download RAM now? :)
    (http://downloadmoreram.com)

  • Some script-kiddies have tried this against some hosts on our network, I haven't seen anything near the gigabit/s yet.

    Thanked by 1linuxthefish
  • FlamesRunnerFlamesRunner Member
    edited October 2015

    Here's the solution: Disable external connections/port forwarding, drop malformed SYN packets, problem solved. If it's a Linux computer, you should have disabled passwords ages ago. SSH = Private key only.

    Booters are easily fended off against anyways :-)

    Thanked by 1netomx
  • @singsing said:
    https://isc.sans.edu/forums/diary/XOR+DDOS+Mitigation+and+Analysis/19827/

    So it appears that are rootkit versions and non-rootkit versions.

    Exactly!

  • This must be why LET keeps going down!

    Thanked by 1netomx
  • 150 GBPS DDOS today: lame

    500GBPS-1TBPS: Crap, OVH is going to kill my reverse proxy.

  • SplitIceSplitIce Member, Host Rep

    @FlamesRunner said:
    Here's the solution: Disable external connections/port forwarding, drop malformed SYN packets, problem solved. If it's a Linux computer, you should have disabled passwords ages ago. SSH = Private key only.

    Booters are easily fended off against anyways :-)

    The cost to receive and filter 150Gbps is rarely easily absorbed.

  • OVH game protection works great, and is quite cheap.

  • 150Gbps what? UDP? I can do 150G UDP with like 3 Ecatel boxes...

    Now 150G TCP would be impressive.

  • CloudFlare will happily block it for you and then brag about it.

  • Though CF sucks big time in L7 protection.

  • William said: 150Gbps what? UDP? I can do 150G UDP with like 3 Ecatel boxes... Now 150G TCP would be impressive.

    Well, since the botnet "owners" have kernel-level access to a large number of these rootkited systems (I haven't seen any report on how many there are, but I'm guess well into the thousands), I'm sure they can craft fancier attacks than anyone can do from three dedicated servers.

    What's being mentioned is "large SYN packets" which is probably considerably more harmful per bit than amplified UDP (because the latter is really easy to detect and drop without too much processing).

  • FranciscoFrancisco Top Host, Host Rep, Veteran

    @William said:
    150Gbps what? UDP? I can do 150G UDP with like 3 Ecatel boxes...

    Now 150G TCP would be impressive.

    Here's a sample


    20:08:52.567777 IP XXX.XXX.XXX.XXX.64404 > YYY.YYY.YYY.YYY.3389: Flags [SE], seq 4220839530:4220840426, win 65535, length 896
    20:08:52.567778 IP XXX.XXX.XXX.XXX.6224 > YYY.YYY.YYY.YYY.3389: Flags [SE], seq 407929862:407930758, win 65535, length 896
    20:08:52.567789 IP XXX.XXX.XXX.XXX.64770 > YYY.YYY.YYY.YYY.3389: Flags [SE], seq 4244779536:4244780432, win 65535, length 896
    20:08:52.567808 IP XXX.XXX.XXX.XXX.57603 > YYY.YYY.YYY.YYY.3389: Flags [SE], seq 3775099948:3775100844, win 65535, length 896
    20:08:52.567815 IP XXX.XXX.XXX.XXX.6458 > YYY.YYY.YYY.YYY.3389: Flags [SE], seq 423267343:423268239, win 65535, length 896
    20:08:52.567817 IP XXX.XXX.XXX.XXX.32764 > YYY.YYY.YYY.YYY.19150: Flags [S], seq 2147276084:2147276980, win 65535, length 896
    20:08:52.567823 IP XXX.XXX.XXX.XXX.7154 > YYY.YYY.YYY.YYY.3389: Flags [SE], seq 468903687:468904583, win 65535, length 896
    20:08:52.567827 IP XXX.XXX.XXX.XXX.3203 > YYY.YYY.YYY.YYY.3389: Flags [SE], seq 209975331:209976227, win 65535, length 896
    20:08:52.567833 IP XXX.XXX.XXX.XXX.16555 > YYY.YYY.YYY.YYY.3389: Flags [SE], seq 1084957503:1084958399, win 65535, length 896
    20:08:52.567835 IP XXX.XXX.XXX.XXX.38827 > YYY.YYY.YYY.YYY.3389: Flags [SE], seq 2544567917:2544568813, win 65535, length 896
    20:08:52.567850 IP XXX.XXX.XXX.XXX.6790 > YYY.YYY.YYY.YYY.3389: Flags [SE], seq 445020681:445021577, win 65535, length 896
    20:08:52.567854 IP XXX.XXX.XXX.XXX.46326 > YYY.YYY.YYY.YYY.3389: Flags [SE], seq 3036026368:3036027264, win 65535, length 896
    20:08:52.567857 IP XXX.XXX.XXX.XXX.56182 > YYY.YYY.YYY.YYY.3389: Flags [SE], seq 3681990692:3681991588, win 65535, length 896
    20:08:52.567860 IP XXX.XXX.XXX.XXX.58875 > YYY.YYYY.YYY.YYY.19150: Flags [S], seq 3858496847:3858497743, win 65535, length 896
    20:08:52.567882 IP XXX.XXX.XXX.XXX.34099 > YYY.YYY.YYY.YYY.3389: Flags [SE], seq 2234721794:2234722690, win 65535, length 896
    20:08:52.567898 IP XXX.XXX.XXX.XXX.55286 > YYY.YYY.YYY.YYY.3389: Flags [SE], seq 3623283988:3623284884, win 65535, length 896
    20:08:52.567901 IP XXX.XXX.XXX.XXX.28933 > YYY.YYY.YYY.YYY.3389: Flags [SE], seq 1896216412:1896217308, win 65535, length 896
    20:08:52.567903 IP XXX.XXX.XXX.XXX.47964 > YYY.YYY.YYY.YYY.3389: Flags [SE], seq 3143396217:3143397113, win 65535, length 896
    20:08:52.567917 IP XXX.XXX.XXX.XXX.61353 > YYY.YYY.YYY.YYY.3389: Flags [SE], seq 4020844636:4020845532, win 65535, length 896
    20:08:52.567928 IP XXX.XXX.XXX.XXX.21050 > YYY.YYY.YYY.YYY.3389: Flags [SE], seq 1379552056:1379552952, win 65535, length 896
    20:08:52.567930 IP XXX.XXX.XXX.XXX.32515 > YYY.YYY.YYY.YYY.3389: Flags [SE], seq 2130909478:2130910374, win 65535, length 896

    They push as hard as they can and it's not uncommon to see a single VPS push 300 - 700mbit/sec.

    Francisco

  • Well, a legitimate SYN packet is 40 bytes long. It seems relatively easy to detect and block 896 bytes long SYN packets. Though one would still need to have massive capacity to be able to filter that 150Gbps of unwanted crap.

  • singsingsingsing Member
    edited October 2015

    rds100 said: Well, a legitimate SYN packet is 40 bytes long.

    That was my first reaction, but when I searched this I found that sending data along with SYN packet is actually allowed by the TCP specs. At least CISCO thinks so:

    http://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=1314&signatureSubId=0&softwareVersion=6.0&releaseVersion=S272

    Not a bad idea to drop as it's not used much in practice. But, once it gets common to drop "large SYN packets" I'm sure they will move on to something else.

Sign In or Register to comment.