История Одного Расследования Или Как Dlp-Система Обнаружила Целевую Атаку

Аналитики Solar JSOC и Solar Dozor в своих статьях часто говорят, что даже все многообразие существующих на рынке средств безопасности не защитит компанию от атаки, если она будет рассматривать данные каждой системы отдельно.

Чаще всего атаку, если она не совсем примитивна, можно обнаружить только путем объединения данных из разных источников.

Сегодня мы хотим поговорить еще об одном примере, подтверждающем эту истину.

Ниже приводится история одной атаки, которая осталась почти незамеченной.



История одного расследования или как DLP-система обнаружила целевую атаку

Все началось вполне стандартно: мы запустили проект внедрения с другим заказчиком.

Менее чем через неделю, когда мы даже не успели должным образом настроить систему под требования компании, Солар Дозор выявил нарушения самой элементарной политики информационной безопасности: ряд конфиденциальных документов регулярно отправлялся на внешний адрес типа XXXX @icloud.com. В документах содержалась вполне серьезная информация – финансовые показатели компании, технические данные о продукции и т. д., но тело письма всегда было пустым.

Подозрительный адрес встречался исключительно один, никогда не соседствуя с другими получателями в поле «Кому».

С этого адреса не пришло ни одного ответного письма.

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

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

Можете ли вы безопасно отправлять документы с важной информацией на внешний почтовый ящик, зная, что компания использует DLP? Быстро выяснилось, что нарушитель был не один — на этот адрес письма направили несколько сотрудников компании.

Мы составили список всех нарушителей; оно насчитывало около 20 человек.

При этом одним удалось отправить только одно письмо, другим – два или три.

Первым шагом в расследовании таких инцидентов является создание графа связей.



История одного расследования или как DLP-система обнаружила целевую атаку

График подключения в Solar Dozor Наша практика показывает, что в таких случаях у виновников утечки всегда есть что-то общее.

Это правило настолько надежно, что само отсутствие общения между инсайдерами можно считать аномалией.

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

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

Мы решили поискать другие аномалии.

Вторым шагом стала попытка найти подозрительные действия в поведении нарушителей.

Для инцидента мы установили специальную политику: сотрудники, отправлявшие документы на этот адрес, автоматически попадали в специальную группу контроля.

Каково же было наше удивление, когда туда массово стали прибывать, казалось бы, вполне «законопослушные» и лояльные сотрудники! Заказчик не выдержал и решил посмотреть эти письма лично, и тут возникла следующая странность.

Оказалось, что писем нет ни на сервере, ни на рабочих станциях отправителей.

Все следы были удалены, но поскольку Solar Dozor хранит всю историю сообщений, письма остались в DLP-архиве.

Стало ясно, что мы, возможно, имеем дело с чем-то более сложным, чем инсайдерская информация для сотрудников.

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

Наша гипотеза заключалась в том, что электронные письма были отправлены (и удалены) не сотрудниками компании, а вредоносным ПО, которое могло быть внедрено в компанию в рамках целенаправленной атаки.

С согласия заказчика мы передали дело на анализ в Solar JSOC. Аналитики подключились к мониторингу рабочих станций, с которых отправлялись письма.

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

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

Как оказалось, мы имели дело с вирусом 0day, который действовал на машинах пользователей не как процесс, а как сервис.

Заметив эту аномалию, мы изолировали тело связанного с ним вредоносного объекта и запустили его в изолированной среде, чтобы наблюдать за происходящим.

Process Monitor, WireShark и другие утилиты обеспечили дополнительный сбор журналов, чтобы мы могли записывать все аномалии в сети и процессах.

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

и по расписанию отправлял их ночью на ту самую внешнюю почту, о чем предупредила DLP-систему.

Вирус утекал не более 50 МБ за раз — очевидно, злоумышленникам было важно не только закрепиться в инфраструктуре, но и как можно дольше не раскрывать свое присутствие.

С этой же целью работало и то, что сразу после установки вредоносное ПО деактивировало антивирус незаметно для пользователя.

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

Дальше нам оставалось только проанализировать, какие записи вирус делает в ветке реестра, какие библиотеки модифицирует, где прописывает автозапуск.

На основании выявленных показателей мы запустили массовое сканирование всей инфраструктуры пользователя.

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

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

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

.

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

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

Собственно, поэтому мы всегда уделяем этому большое внимание.

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

Поэтому будьте осторожны, не игнорируйте странности, соберите всю возможную информацию и – да пребудет с вами сила :).

Теги: #информационная безопасность #apt #расследование инцидентов #Solar Security #forensics #solar jsoc #dlp #dlp #солнечный дозор #целевая атака

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.