SSH attack to my server

Today I realised that my home server ( ubuntu 16.04 x86 ) was compromised via ssh, and the attacker got root access.

He put followings on my root crontab:

root@d:~# crontab -l
5 8 * * 0 /root/.configrc/a/upd>/dev/null 2>&1
@reboot /root/.configrc/a/upd>/dev/null 2>&1
5 8 * * 0 /root/.configrc/b/sync>/dev/null 2>&1
@reboot /root/.configrc/b/sync>/dev/null 2>&1
0 0 */3 * * /tmp/.X25-unix/.rsync/c/aptitude>/dev/null 2>&1
root@d:~#


root@d:~# tree -C .configrc/
.configrc/
├── a
│   ├── a
│   ├── bash.pid
│   ├── dir.dir
│   ├── init0
│   ├── kswapd0
│   ├── run
│   ├── stop
│   └── upd
├── b
│   ├── a
│   ├── dir.dir
│   ├── run
│   ├── stop
│   └── sync
├── cron.d
└── dir2.dir

2 directories, 15 files
root@d:~#

Didn’t analyse yet, but looks like crontab runs above files, and add his ssh key to authorized_keys, and runs kswapd.

Please beware !!!

10 thoughts on “SSH attack to my server”

  1. Got hacked me too, luckily with non-sudoer user. Have you analysed what the hacker seemed to do with this kind of attack?
    Thanks!

    Like

      1. Exactly the same one.

        Anyway, in my case not only kswapd0 process was executed, a lot of rsync process were running too. Then, I currently think the purpose probably was “stealing” information across system files.

        It’s a mystery for me why kswapd0 process is fired in this hacking context. Actually this abnormal process put me in the right way for hacking detection 😀

        Liked by 1 person

      2. Hello again.

        according to ClamAV the hacker should be a bitcoin miner:

        /home/xxxxx/.configrc/a/kswapd0: Multios.Coinminer.Miner-6781728-2 FOUND

        It makes sense IMO. Mystery solved.

        Like

  2. Actually it is a nice idea for the hacker to hide their processes with a valid process (binary) name. In this example, he was using “kswapd” , which is a real/valid kernel process. I am still wondering how did he gained access to my server… It seems I need to learn much more about linux security 😦

    Like

    1. In my case, I swear the reason was very simple: a weak password. My conclusion: disabling password authentication for cloud servers is a good practice 😀

      Like

Leave a comment