2 Ноября, 2018

Проверь себя: сможете ли вы защитить компанию от кибератаки?

SolarSecurity
Недавно в Самаре прошли международные открытые соревнования по информационной безопасности VolgaCTF . Владимир Дрюков, директор центра мониторинга и реагирования на кибератаки Solar JSOC, рассказал участникам соревнований о трех реальных атаках и спросил, как можно было их выявить. Проверьте, сможете ли вы ответить правильно.

Ниже расшифровка выступления Владимира, но для желающих посмотреть uncensored and uncut version (включая ответы слушателей) — вот видео:




Итак, слово Владимиру:



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

Надеюсь, это поможет вам в будущем, когда вы станете профессиональными пентестерами и будете работать в Positive Technologies, Digital Security или у нас. Вы будете знать, как центр мониторинга видит такие атаки, как он на них реагирует, и – кто знает – может быть, это поможет вам обойти защиту, добиться своей цели и показать заказчику, что он не так неуязвим, как ему казалось. Ну что, поехали?

Задача №1. Эта служба и опасна, и трудна, и на первый взгляд как будто не видна...


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

«Ребята, у меня творится какая-то странная ерунда. Есть четыре машины, которые начинают спонтанно перезагружаться, вываливаться в синий экран – в общем, происходит какая-то чушь. Давайте поразбираемся».

Когда ребята из группы форензики приехали на площадку, оказалось, что security логи на всех машинах почищены – активностей так много, что журнал security быстро ротируется (перезаписывается). В Master File Table тоже не удалось найти ничего интересного – фрагментация сильная, данные быстро перезатираются. Тем не менее, удалось найти кое-что в журнале system: примерно раз в сутки на этих четырех машинах появляется служба it_helpdesk, делает что-то неизвестное (security логов нет, как мы помним) и исчезает.

У нашего главы форензики появилось примерно такое выражение лица:



Стали разбираться дальше, и оказалось, что служба it_helpdesk – на самом деле переименованный PSExec.
Служебные программы, такие как Telnet, и программы удаленного управления, такие как PC Anywhere компании Symantec, позволяют выполнять программы в удаленных системах, однако их не так просто установить, поскольку требуется устанавливать еще и клиентское программное обеспечение в тех удаленных системах, к которым необходимо получить доступ.

Программа PsExec — это облегченный вариант Telnet. Она позволяет выполнять процессы в удаленных системах, используя для этого все возможности интерактивного интерфейса консольных приложений, и при этом нет необходимости вручную устанавливать клиентское программное обеспечение. Основное достоинство PsExec — это возможность вызывать в интерактивном режиме интерфейс командной строки в удаленных системах и удаленно запускать такие инструменты как IpConfig. Это единственный способ вывести на экран локального компьютера данные об удаленной системе.

technet.microsoft.com

Проверив журналы system на других машинах, мы увидели, что задействованы не 4 рабочих станции, а 20, плюс еще 19 серверов, в том числе один критичный сервер. Пообщались с айтишниками и выяснили, что они к этому отношения не имеют, такой подсистемы у них нет. Стали копать дело дальше, и тогда обнаружилась довольно любопытная и редко встречающаяся вещь – DNS-tunneling, которое использовал модуль ВПО, отвечающий за связь с центром управления ботнетом.
DNS-tunneling — техника, позволяющая передавать произвольный трафик (фактически, поднять туннель) поверх DNS-протокола. Может применяться, например, для того чтобы получить полноценный доступ к Интернет из точки, где разрешено преобразование DNS-имён.

DNS-туннелирование нельзя запретить простыми правилами брандмауэра, разрешив при этом остальной DNS-трафик. Это связано с тем, что трафик DNS-туннеля и легитимные DNS-запросы неразличимы. Обнаруживать DNS-туннелирование можно по интенсивности запросов (если трафик по туннелю велик), а также более сложными методами, используя системы обнаружения вторжений.

xgu.ru

Вредоносный код попал в организацию через почту, распространялся по инфраструктуре и взаимодействовал с C&C-сервером через DNS-туннель. Поэтому запреты на взаимодействие с интернетом, которые стояли в серверном сегменте, не работали.

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

К чему это привело? За то время, пока вредонос жил в инфраструктуре, было скомпрометировано много учеток и, помимо этого, большой объем других потенциально чувствительных данных. В ходе расследования мы локализовали область действия злоумышленников и «выгнали» их из сети. Заказчик же получил еще четыре месяца муки – потребовалось перезалить половину машин и перевыпустить все пароли – от баз данных, учеток и так далее. Людям с ИТ-опытом не надо объяснять, какая это непростая история. Но, тем не менее, все закончилось хорошо.

Итак, вопрос: как можно было выявить эту атаку и поймать за руку киберпреступника?

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

Во-вторых, не стоит пренебрегать и информацией с самых базовых средств защиты. PSExec неплохо детектируется антивирусами, но маркируется не как вредоносное ПО, а как Remote Admin Tool или Hacking Tool. Если внимательно смотреть в логи антивируса, можно вовремя увидеть срабатывание и принять соответствующие меры.


Задача №2. Страшные сказки


Большой банк, женщина работает в финансовой службе и имеет доступ к АРМ КБР.
АРМ КБР – автоматизированное рабочее место клиента Банка России. Представляет собой программное решение для защищенного информационного обмена с Банком России, в том числе отправки платежных поручений, банковских рейсов и т.д.

Эта сотрудница финансовой службы принесла на работу флешку с файлом под названием Skazki_dlya_bolshih_i_malenkih.pdf.exe. У нее была маленькая дочка, и женщина хотела распечатать на работе детскую книжку, которую скачала из интернета. Расширение файла .pdf.exe не показалось ей подозрительным, да и потом, когда она запустила файл, открылась обычная pdf.



Женщина распечатала книгу и ушла домой. Но расширение .exe, конечно, было не случайным. За ним скрывался Remo Admin Tool, который сел на рабочую станцию и окопался там в системных процессах больше чем на год.

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

Вопрос: как можно было выявить «незаметный» вредонос, не детектируемый антивирусом?

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

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


Задача №3. «Кровавый warez»


Системному администратору надо было сравнить 2 .xml-файла. Он пошел простым путем – набрал в поисковике «скачать xml merger без регистрации и sms». Официальный сайт разработчика этой утилиты был на 3 месте в выдаче, а на первых двух – файлообменники. Там администратор и скачал программу.

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



Самое плохое было в том, что ИТ-администратор – это король замка, у него есть доступ везде. С его машины вирус может добраться до любого хоста или сервера. Вредонос пополз по сети через доменные sharepoint, пытаясь добраться до машины главного финансиста. В этот момент ее поймали за хвост, и история была погашена.

Вопрос: как выявить такую атаку на машину привилегированного пользователя?

Ответ на третью задачу
Опять-таки, можно слушать трафик, пытаясь поймать вредонос «с поличным» – в момент запроса к C&C-серверу. Однако если в компании нет NGFW, IDS, системы анализа сетевого трафика или SIEM, которая выловит из трафика хоть что-то ценное, слушать его можно до бесконечности.

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