Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Botnet Privacy Security

A New Botnet Is Covertly Targeting Millions of Servers (wired.com) 27

An anonymous reader quotes a report from Wired: FritzFrog has been used to try and infiltrate government agencies, banks, telecom companies, and universities across the US and Europe. Researchers have found what they believe is a previously undiscovered botnet that uses unusually advanced measures to covertly target millions of servers around the world. The botnet uses proprietary software written from scratch to infect servers and corral them into a peer-to-peer network, researchers from security firm Guardicore Labs reported on Wednesday. Peer-to-peer (P2P) botnets distribute their administration among many infected nodes rather than relying on a control server to send commands and receive pilfered data. With no centralized server, the botnets are generally harder to spot and more difficult to shut down.

The botnet, which Guardicore Labs researchers have named FritzFrog, has a host of other advanced features, including: In-memory payloads that never touch the disks of infected servers; At least 20 versions of the software binary since January; A sole focus on infecting secure shell, or SSH, servers that network administrators use to manage machines; The ability to backdoor infected servers; and A list of login credential combinations used to suss out weak login passwords that's more "extensive" than those in previously seen botnets. Taken together, the attributes indicate an above-average operator who has invested considerable resources to build a botnet that's effective, difficult to detect, and resilient to takedowns. The new code base -- combined with rapidly evolving versions and payloads that run only in memory -- make it hard for antivirus and other end-point protection to detect the malware.

The botnet has so far succeeded in infecting 500 servers belonging to "well-known universities in the US and Europe, and a railway company."Once installed, the malicious payload can execute 30 commands, including those that run scripts and download databases, logs, or files. To evade firewalls and endpoint protection, attackers pipe commands over SSH to a netcat client on the infected machine. Netcat then connects to a "malware server." (Mention of this server suggests that the FritzFrog peer-to-peer structure may not be absolute. Or it's possible that the "malware server" is hosted on one of the infected machines, and not on a dedicated server. Guardicore Labs researchers weren't immediately available to clarify.)

This discussion has been archived. No new comments can be posted.

A New Botnet Is Covertly Targeting Millions of Servers

Comments Filter:
  • So who is at risk are basically morons that cannot use good passwords and are too incompetent to use certificate-based authentication for their servers or jump-hosts. Will be interesting to see how many they can compromise.

    • Any reasonably competent admin should be running Fail2Ban or something similar to prevent dictionary attacks.

      • by ls671 ( 1122017 )

        Indeed, but you get so many dictionary attacks even if you only allows key auth that it becomes bugging. So, I moved all my ssh daemons open to the Internet to non standard ports and I haven seen one since. You may also only allow access for some set of IPs with ipsets. All these strategies add up to diminish the risk of getting infected. Of course, only use strong passwords if you allow password login and update your ssh daemons and libs as well.

      • A couple of my machines are getting hammered by ssh attacks and they are on non-standard ports. I have plaintext passwords turned off but they still keep trying. Fail2Ban doesn't help unless you jail them after one failed attempt. You never see the same IP address more than twice a day. It's VERY distributed.
        • by ls671 ( 1122017 )

          You never see the same IP address more than twice a day. It's VERY distributed.

          Yep, I have first seen this behaviour appearing last year and wondered, my god, what is the size of this botnet? You can get scanned every second but from a different IP every time!

          I searched to find which botnet that could be but i didn't find any information back then. Maybe this is what they are talking about in TFS. Hopefully, it didn't take that long to discover but maybe it is the case. I couldn't find anybody else reporting it last year when I searched. I can tell for sure that it has been around for

        • setup fail2ban with fakessh on default port to ban 1 try ond default port
          • by ls671 ( 1122017 )

            Might work if only yourself need to access the server. Otherwise, too many customers forget about specifying a different port and would get banned without a chance to try again with the right port. In turn, we would get too many support tickets opened. Geoip blocking is more efficient especially if all your customers are in well defined area. Then again, it's kind of useless to bar an IP that only tries to login once a day like that botnet does (not sure it's the botnet mentioned in TFS but a botnet is acti

          • by ls671 ( 1122017 )

            Additionally, look at at the iptables TARPIT target that greatly slows down tcp port scanning.
            https://serverfault.com/questi... [serverfault.com]

        • by gweihir ( 88907 )

          Well, the "low intensity zombies" have been around forever and they have been successful. As long as too many people have bad security, this will continue.

    • by Miser ( 36591 )

      This. Short of fail2ban or perhaps sshdfilter, if I have ssh exposed to the world with certificates only, (no password auth) I'm guessing I'm immune to this, correct?

      • by gweihir ( 88907 )

        This. Short of fail2ban or perhaps sshdfilter, if I have ssh exposed to the world with certificates only, (no password auth) I'm guessing I'm immune to this, correct?

        Good passwords or certificate auth and you are immune. No need for anything else, unless you mind the log-entries or the (probably small) amount of CPU this consumes. Securing SSH is _easy_ and at least OpenSSH has an absolutely excellent security track record.

  • From what I've read, it requires the system to be running sshd, allowing root login using a password. Most distributions default to requiring a key, or disabling root ssh.
  • All of the neat Raspberry-Pi retro game boxes are looking pretty ripe right about now.

  • The botnet uses proprietary software written from scratch

    I hope they don't sue the malware researchers for violating their copyright!

    Though if you wanted to make it sound maximally pretentious, you should have said

    The botnet is a bespoke proprietary solution

  • If you have port 22 open to the world, you are doing it wrong. Russia and North Korea and plenty of other bad actors exist. Close that port to the world and the attack surface is eliminated. Restricting port 22 is the first step to setting up a new server for use. No need for fail2ban at that point for SSH either. "Oh, but how do I access my server then?" It's called a firewall. Only a few trusted people need SSH access to any given system. If your IP address is dynamic, then your firewall rules nee
    • AWS, DigitalOcean, Google Cloud, and other vendors should be actively scanning their IP space for SSH ports that are open to the world and notifying the account owners that they have 15 days to lock down the SSH port for long-running instances or get booted off their platforms. That would fix a lot of issues.

      A lot of the SSH guessing attempts I'm seeing are coming from DigitalOcean IP addresses. Not so much Google or AWS.

      • Yep. Just recently I've had a lot of scans from DigitalOcean addresses.

        Now, my firewall sends the whole subnet from any DigitalOcean scanner straight into the bit bucket.

  • quote> In-memory payloads that never touch the disks of infected servers;

    Doesn't anyone reboot any more? Aversion to rebooting is getting silly when downtime is now counted in 9 seconds or less.

Keep up the good work! But please don't ask me to help.

Working...