История одного взлома или учитесь на чужих ошибках

в 8:00, , рубрики: антивирусная защита, безопасность, Блог компании VDSina.ru — хостинг серверов, взлом, информационная безопасность, инфраструктура

История одного взлома или учитесь на чужих ошибках - 1

Тут должна быть затёртая цитата из Ницше про силу, но мы не стали её писать.

Однажды это может случится с каждым системным администратором – он придёт утром на работу, станет проверять работу инфраструктуры и обнаружит, что на файловом сервере вместо данных пользователей лежит архив и текстовый файл с требованием выкупа. Что делать, как жить дальше и как предотвратить повтор разбираемся в этой статье.

Рассматривается случай, который случился с инфраструктурой компании, которая построена на ПК с Windows. Итак, наш герой утром обнаружил, что на файловом сервере вместо пользовательских файлов архив data.zip и readme.txt. Архив был запаролен, а в текстовике стандартное требование перевести на биткоин-кошелёк увесистую сумму, прислать на указанную почту подтверждение о переводе и в ответ получить пароль. Как завещали нам предки — в переговоры с террористами вступать не стали, но время шло, а данные нужно было восстанавливать.

Когда ситуация случилась, то встал пул задач:

  • Восстановить данные
  • Установить маршрут взлома
  • Предотвратить повторение

С восстановлением данных всё просто – ночная копия наше всё. На всякий случай прошлись утилитой восстановления удалённых файлов, но впустую, на диске явно поработал Eraser. Так что поставили раскатывать резервную копию и переходим к пункту об установлении маршрута взлома.

Начинаем с осмотра «улик». Даты создания у файлов примерно одинаковые и в качестве создателя – локальный администратор, больше ничего интересного. Переходим к операционной системе. Помимо администратора в пользователях висит непонятный пользователь Kelly с административными правами. Уже интереснее! Смотрим дальше. Изменены сетевые настройки – в качестве DNS указаны адреса гугла. Это всё хорошо, но файловый сервер не имеет прямого выхода в интернет, так что непонятно как злоумышленник попал на него. Да, на сервер можно попасть через RDP, но этот RDP не смотрит наружу. Ищем дальше.

В компании имеется терминальный сервер для сотрудников, работающих в удалённом режиме. Осматриваем его. В логах безопасности много отказов входа с явным перебором учётных записей, но больше ничего подозрительного. Лишних пользователей в системе нет, настройки не изменены, всё чисто.

Раз уж речь зашла о сотрудниках на удалёнке, то поднимаем списки таких работников и смотрим, как настроены их рабочие места. Часть работает на уже осмотренном терминальном сервере, а часть на своих ПК. И вот тут была найдена точка входа. На ПК одного из дизайнеров был локальный пользователь Kelly с административными правами и в его папке загрузок лежал дистрибутив WinRar’а с помощью которого были заархивированы данные и тут же лежал Eraser для затирания. Окей, точку нашли, но как попали на машину и как попали на файловый сервер?

Детальный осмотр машины дизайнера выявил, что в настройках удалённого доступа не была включена проверка подлинности на уровне сети и кроме того, на операционную систему давно не устанавливали обновления. Так что предположительно вектор атаки был следующий: насканить порт за которым висит RDP-доступ и исследовать его на предмет уязвимости на уровне проверки пользователя. Дальше, используя уязвимость в системе выполнить код, заводящий пользователя Kelly и войти на ПК. После этого на ПК закидывается архиватор, Eraser — и дело за исследованием инфраструктуры и выполнением вредоносных действий. Тут стоит отметить, что конкретном случае компания дёшево отделалась – сотрудники попали только на время восстановления файлов из резервной копии и всё. Ну и администратор, конечно попал под раздачу за халатность. Но злоумышленники могли бы пойти и дальше — базы данных или документы с данными могли бы быть не зашифрованы, а вынесены за пределы досягаемости. Ну и наконец, сами резервные копии — хорошо, что не добрались до них.

Теперь самое главное — как не стать героем такой статьи. Тут на самом деле всё просто: главное — бдительность. Проверьте себя по чек-листу:

  • На всех операционных системах установлены все актуальные обновления
  • Контролируйте все точки входа в инфраструктуру
  • Не используйте простые пароли
  • В случае аутентификации по паролям разверните политику использования только безопасных паролей
  • По возможности разверните вход по сертификатам
  • По возможности переименовывайте административные учётные записи
  • Используйте принцип минимальных привилегий
  • Внутренний брандмауэр
  • Корпоративный антивирус
  • Оффлайн копия данных
  • Контролируйте повышенное внимание к вашему периметру и реагируйте

Что имеется в виду под этими рекомендациями.

Обновления в операционных системах не только добавляют функционал, но и закрывают уязвимости, которые могут использовать злоумышленники. Важно понимать, что следует обновлять не только операционную систему, но всё программное обеспечение, которое используется на рабочем месте.

Под контролем точек выхода наружу, понимается то, что всегда нужно знать кто, по какой причине и как попадает в сеть компании изнутри. Не должно быть ситуаций, что из машины бухгалтера торчит RDP на стандартном порту.

О необходимости использования безопасных паролей написаны сотни и тысячи статей, постов и заметок. Но люди делятся на тех, чьи пароли подобрали и на тех, кто их сменил на более безопасные. Давайте это проговорим ещё раз – длина от восьми символов, обязательное использование букв верхнего и нижнего регистра, цифр и спецсимволов. В идеале – использовать генератор, коих полно, как в сети, так и встроенных в ближайший парольный менеджер.

И уж речь зашла о безопасных паролях, то политика должна носить не рекомендательный, а принудительный характер. Групповые политики Active Directory позволяют реализовать сценарии по принудительной смене пароля у пользователей через заданные промежутки времени. Кроме того, задаётся политика минимальной длины пароля и количество использованных паролей, чтобы пользователь не использовал два пароля безопасных с точки зрения политики, просто меняя их по мере устаревания.

Сложные пароли это, конечно хорошо, но ещё лучше – доступ по сертификату. Да, это сложнее в развёртывании, местами неудобно, но это безопасно. Подумайте над этим, возможно стоимость внедрения PKI инфраструктуры, будет меньше чем стоимость восстановления данных, потерянных в ходе хакерской атаки.

Переименование административных записей помогает от атаки по словарю на учетные записи вроде Administrator, Admin, Администратор и админ, которые присутствуют в системах по умолчанию и достаточно редко блокируются. Переименование административных учётных записей в случайный набор букв и цифр позволит закрыться от такой атаки. Разумеется, это шаг повлечёт за собой внедрение если не глобального парольного менеджера, то хотя бы реестра паролей.

Принцип минимальных привилегий учит нас не давать лишних прав для выполнения поставленных задач. Службе, которая, например, чистит пользовательские профили от временных файлов, по факту не нужны административные права на файловый сервер, ей достаточно прав на удаление файлов в хранилище профилей. Причём именно на удаление. На изменение файлов права тоже не нужны. Это избавит вас от проблемы, которая возникнет в случае компрометации учётных данных, как сервисных аккаунтов, так и вообще уменьшит фронт атаки на вашу инфраструктуру.

В принцип минимальных привилегий также укладывается и наличие активированного файерволла на пользовательских машинах и серверах. Оставляем только необходимое, а остальное выключаем или запрещаем. По возможности не реагируем на входящие подключения. Ничего лишнего – вот ваш девиз.

Используйте антивирус. Да, пользователи и системные администраторы всегда жалуются, что антивирус мешает работе, уменьшает быстродействие и это лишние траты денег компании и вычислительной мощности компьютеров. Но отсутствие антивируса рано или поздно сыграет свою роль и однажды пользователь запустит файл из письма и дешифрация файлов обойдётся намного дороже корпоративной лицензии на противовирусный комплекс.

Выше было упомянуто, что хорошо, что не добрались до самих резервных копий. У вас всегда должна быть копия, которая вынесена за пределы инфраструктуры и доступ к таким копиям должен быть максимально ограниченным. Держать такие копии в совсем уж актуальном состоянии накладно, но файлам даже квартальной давности пользователи обрадуются больше, чем полной потере данных.

И, наконец, читайте логи доступа — в них содержится масса интересного. Внедрение полновесной системы предотвращения вторжений дорогостоящее удовольствие, но многое можно сделать своими руками. Анализируйте адреса с которых идёт скан портов или перебор учётных данных. Регулярно проверяйте машины пользователей и сервера на предмет наличия зловредов.

Разумеется, даже полное следование данным рекомендациям не даст вам стопроцентной гарантии от взломов, но хотя бы позволят снизить процент риска. И не забывайте об обучении сотрудников, потому как даже самая защищённая система оказывается беззащитной при полном непонимании о последствиях тех или действий. Если сотрудник ввёл свои учётные записи на фишинговой форме, то какой бы ни была защищённой система, то сотрудник уже скомпрометирован. Если доступ осуществляется с инфицированной машины, то вы сами запускаете зловредов в свою сеть. Всегда соблюдайте осторожность, пренебрежение безопасностью может нанести ощутимый ущерб не только сотруднику, но и компании в целом.

Теперь немного о том, почему это не было сделано в данном случае. Тут тоже всё просто, как карандаш ТМ — рабочее место дизайнера было развёрнуто с использованием пиратской сборки. Пожалуйста, не делайте таких фатальных ошибок. Во-первых, это незаконно, а во-вторых вы теряете больше ресурсов, когда разгребаете последствия такого халатного отношения к своей IT-инфраструктуре. Берегите себя и свои данные. А если есть что добавить по чек-листу или по ситуации в целом, то милости просим в комментарии.


На правах рекламы

Наша компания предлагает безопасные серверы с бесплатной защитой от DDoS-атак. Возможность использовать лицензионный Windows Server на тарифах с 2 ГБ ОЗУ или выше, создание резервных копий сервера автоматически либо в один клик.

Используем исключительно быстрые серверные накопители от Intel и не экономим на железе — только брендовое оборудование и одни из лучших дата-центров в России и ЕС. Поспешите проверить.

История одного взлома или учитесь на чужих ошибках - 2

Автор: Mikhail

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js