В этой статье мы детально разбираем большой кейс с атакой на целую ферму машин под управлением Linux. Нас ждет взлом веб-сервера, заражение майнером, эскалация root из виртуального контейнера и создание ячейки ботнета, которая рассылала спам. Уже не терпится узнать подробности? Тогда поехали!

Это заключительная часть цикла по форензике для новичков, в котором мы рассказываем о том, что такое цифровая форензика, разбираем наиболее популярные инструменты анализа, изучаем несколько кейсов на устройствах с Android и расследуем хищение денежных средств из системы ДБО на ноутбуке с Windows 10.

  1. «Теория, книги, курсы, полезные материалы»
  2. «Находим источники данных, ищем и анализируем артефакты»
  3. «Android под колпаком. Как раскрывают кейсы взлома»
  4. «Тайна казначейского ноутбука. Используем форензику, чтобы раскрыть ограбление»
  5. «Форензика в Linux. Дампим память, диски и сетевые коннекты для дальнейшего поиска улик»

 

Предыстория инцидента

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

Меня попросили помочь разобраться в аномальном поведении администрируемых заказчиком систем и выявить причины. Если же обнаружатся факты взлома — пресечь каналы несанкционированного доступа и обезопасить хостера от повторных атак.

Сами серверы находились в дата-центре, поэтому вопрос о физическом несанкционированном доступе однозначно снимался.

Вот основные жалобы, с которыми обратился заказчик:

  • ОС и отдельные демоны работали нестабильно, система часто спонтанно перезагружалась, в syslog шло много критичных ошибок, не зависящих от действий системного администратора;
  • часто сменялись пики и падения на графиках загрузки ввода-вывода и сетевого трафика;
  • IP-адреса из выделенного пула часто попадали в черные списки;
  • при работе легитимных администраторов с системой соединение SSL часто обрывалось по разным сценариям;
  • периодически сбрасывались настройки пакетного фильтра iptables на значения по умолчанию.

В работе системы наблюдался и ряд других, более мелких аномалий. При этом проверки на предмет наличия вирусов и руткитов такими известными утилитами, как rkhunter, chkrootkit и ClamAV, результата не дали.

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

Все это давало основание предполагать, что причиной происходящего было сознательное вмешательство третьих лиц в работу машин.

Однако попытки самостоятельных поисков, такие как анализ журналов, безопасное конфигурирование iptables, перенос прикладных сервисов в chroot, использование длинных и сложных паролей, парсинг сетевого трафика с помощью Wireshark и подобных утилит, никаких следов хакерского взлома не выявили.

 

Поиск артефактов

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

 

Извлекаем данные из оперативной памяти

Для анализа образа RAM мы выбрали хорошо зарекомендовавший себя пакет утилит Volatility Framework. По умолчанию он уже должен быть у тебя установлен, но если вдруг произошло невероятное и его нет, то накатить свежую версию — секундное дело:

$ sudo apt-get install volatility volatility-profiles volatility-tools 

Как вариант, ты всегда можешь скачать и установить пакет из исходников.

Рабочее окно Volatility Framework после запуска
Рабочее окно Volatility Framework после запуска

После этого нам необходимо сгенерировать volatility profile, который зависит от версии ядра ОС. Чтобы не терять время зря, можно воспользоваться приложенным к статье готовым скриптом (см. врезку со скриптами ниже), который соберет профиль в автоматическом режиме.

После того как профиль сгенерирован и выбран, запуск утилиты в общем виде выглядит так:

$ ./vol.py –profile=<имя профиля> -f <файл-образ RAM> <команда> 

К примеру, запуск Volatility с вызовом команды pslist для получения списка процессов будет таким:

$ ./vol.py –profile=KaliLinux-19_02-25_16_0-30x64 -f ~/cases/pfe1/ram_image.lime linux_pslist 

Аналогичный результат можно получить и другой командой:

$ ./vol.py –profile=KaliLinux-19_02-25_16_0-30x64 -f ~/cases/pfe1/ram_image.lime linux_psaux 

Теперь попробуем выстроить карту процессов с флагами разрешений и списком сегментов:

$ ./vol.py –profile=KaliLinux-19_02-25_16_0-30x64 -f ~/cases/pfe1/ram_image.lime linux_proc_maps 

Эта команда зачастую используется при поиске следов малвари, которая может внедряться в благонадежные процессы системы или пользователя.

Извлечение и просмотр истории команд bash:

$ ./vol.py –profile=KaliLinux-19_02-25_16_0-30x64 -f ~/cases/pfe1/ram_image.lime linux_bash 

Наконец, проверка файловых операций с целью поиска следов возможной модификации руткитом выглядит так:

$ ./vol.py –profile=KaliLinux-19_02-25_16_0-30x64 -f ~/cases/pfe1/ram_image.lime linux_check_fop 

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

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.


Check Also

Raspberry Pi 4. Что дают четыре ядра и четыре гига в четвертой ревизии «малинки»

Как и у людей, у компьютеров есть своя судьба — и складывается она зачастую по-разному. Од…

8 комментариев

  1. Аватар

    unmoved

    12.04.2019 at 16:48

    Хорошая статья, я очень много утилит ни когда не знал.
    Многие вещи можно было обнаружить и без таких сложных манипуляции, например на cloud маршрутизаторах с возможностью инспекта трафика…

    • Аватар

      unmoved

      12.04.2019 at 16:57

      или софт-свичах

    • Иван Пискунов

      Иван Пискунов

      13.04.2019 at 12:58

      И это лишь часть утилит, которые использовались мной конкретно в этом кейсе, описать же весь набор тулз, которые есть в наличии под разные случаи — не хватило бы ни какой статьи. Что касается детекта на «cloud маршрутизаторах», доступа к сетевому оборудованию дата-центра у меня не было, специфические железки типа UTM\NGFW-шлюзов, которые могли бы помочь в инспекции трафика у клиента не использовались, а имеющиеся по умолчанию маршрутизаторы опций детекта, к примеру, того же DNS-туннелинга не имели.

  2. Аватар

    0xFF3

    15.04.2019 at 14:46

    Опечатка в слове: «который соберет профиль в автоматическ*им режиме.»

  3. Аватар

    eugeneshcherban

    01.06.2019 at 13:01

    там еще смотрю vsftpd 2.3.4 стоит. Если залогиниться с любым именем с окончанием 🙂 типа: test:) и любым паролем, то vsftpd открывает порт 6200, на который можно nc подключиться.

    • Иван Пискунов

      Иван Пискунов

      06.06.2019 at 11:01

      да, есть такая фича в vsftpd, оч приятно, что наши читатели такие подкованные)) и обращают внимание на «ускользающие» от большинства мелочи!)))

  4. Аватар

    AseN

    05.06.2019 at 23:29

    Осталось непонятной цель применения volatility framework

    • Иван Пискунов

      Иван Пискунов

      06.06.2019 at 11:06

      Volatility Framework классический инструмент для анализа дампов оперативной памяти ОС. Не упомянуть его при расследовании столь грандиозного кейса было просто невозможно, это must have в тулкит наборе любого мало-мальски продвинутого эксперта. Просто объем работы, который был сделан для расерча этого кейса при любом желании ну никак не мог поместить в объем одной статьи, и поэтому множество манипуляций, о которых было хоть немного рассказано в предыдущих частях цикла, остались за кадром..

Оставить мнение