Howdy, Stranger!

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

Subscribe to our newsletter

Advertise on LowEndTalk.com

Latest LowEndBox Offers

    A New Botnet Hits Servers With 150 Gbps DDoS Attacks
    New on LowEndTalk? Please read our 'Community Rules' by clicking on it in the right menu!

    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

    • dediservedediserve Member, Provider

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

      Thanked by 1Maounique
    • Yeah I thought the same lol

    • ClouviderClouvider Member, Provider

      Sounds like fun for the providers now :-).

      Clouvider Leading UK Cloud Hosting solution provider || UK Dedicated Servers Sale || Tasty KVM Slices || Latest LET Offer

      Web hosting in Cloud | SSD & SAS True Cloud VPS on OnApp | Private Cloud | Dedicated Servers | Colocation | Managed Services

    • pbgbenpbgben Member, Provider

      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, 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.

      Clouvider Leading UK Cloud Hosting solution provider || UK Dedicated Servers Sale || Tasty KVM Slices || Latest LET Offer

      Web hosting in Cloud | SSD & SAS True Cloud VPS on OnApp | Private Cloud | Dedicated Servers | Colocation | Managed Services

    • @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.

      RIPE LIR: Contact me for ASN registrations/IPv6. No IPv4 space left.

    • ClouviderClouvider Member, 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.

      Clouvider Leading UK Cloud Hosting solution provider || UK Dedicated Servers Sale || Tasty KVM Slices || Latest LET Offer

      Web hosting in Cloud | SSD & SAS True Cloud VPS on OnApp | Private Cloud | Dedicated Servers | Colocation | Managed Services

    • 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.

      Extremist conservative user, I wish to preserve human and civil rights, free speech, freedom of the press and worship, rule of law, democracy, peace and prosperity, social mobility, etc. Now you can draw your guns.

    • 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

      yyyyyy

    • @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

      yyyyyy

    • netomxnetomx Member, Moderator

      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

      yyyyyy

    • 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

      www.urdn.com.ua - KVM/Qemu hosting in Sweden.

    • 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

      wget https://s.flamz.pw/dl/bench.sh && bash bench.sh

      curl https://s.flamz.pw/analytics/bench/stats.php

    • @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!

      SecureLayer7 Provide
      penetration testing & vulnerability assessments | Server Hardening | Malware Removal | Mobile application security testing | Source Code Audit

    • 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.

      wget https://s.flamz.pw/dl/bench.sh && bash bench.sh

      curl https://s.flamz.pw/analytics/bench/stats.php

    • SplitIceSplitIce Member, Provider

      @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.

      X4B - DDoS Protection: Affordable DDoS protection including Layer 7 mitigation with PoPs in the US, EU and Asia.
      Latest Offer: $14 in Asia DDoS mitigation
    • OVH game protection works great, and is quite cheap.

      wget https://s.flamz.pw/dl/bench.sh && bash bench.sh

      curl https://s.flamz.pw/analytics/bench/stats.php

    • WilliamWilliam Member, Provider

      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.

      tsdns.io - free, redundant, DDoS-protected TSDNS

    • Though CF sucks big time in L7 protection.

      wget https://s.flamz.pw/dl/bench.sh && bash bench.sh

      curl https://s.flamz.pw/analytics/bench/stats.php

    • 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 Provider

      @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

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

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

      Francisco

      BuyVM - Dedicated KVM Slices / Anycast Support! / Stallion Control Panel / Windows 2008, 2012, & 2016! / Unmetered Bandwidth!
      BuyShared - Shared & Reseller Hosting / cPanel + Softaculous + CloudLinux / Pure SSD! / Free Dedicated IP Address
    • 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.