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

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

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



    Начиналось все вполне стандартно: мы запустили проект внедрения у очередного заказчика. Менее чем через неделю, когда мы еще даже не успели толком настроить систему под требования компании, Solar Dozor выявил нарушения самой базовой политики ИБ: ряд конфиденциальных документов регулярно уходил на внешний адрес вида XXXX@icloud.com. Документы содержали достаточно серьезную информацию – финансовые показатели компании, технические данные о продукции и т.п., но тело письма всегда было пустым. Подозрительный адрес встречался исключительно в одиночку, никогда не соседствуя с другими адресатами в поле «Кому». Не было ни одного письма, которое приходило бы с этого адреса в ответ. Напрашивалось предположение, что сотрудники скидывают на личную почту наиболее интересные документы. Честно говоря, хотя на проектах приходится сталкиваться с самыми разными, порой довольно нелепыми в своей наивности попытками вынести конфиденциальную информацию, такая «лобовая атака» вызвала некоторую оторопь. Спокойно отправлять документы с критически важной информацией на внешний ящик, зная, что в компании используется DLP?

    Быстро стало ясно, что нарушитель не один – целый ряд сотрудников компании отправлял письма на этот адрес. Мы составили список всех нарушителей, он насчитывал около 20 человек. При этом кто-то успел отправить только одно письмо, кто-то – по два-три. Первым шагом при расследовании таких инцидентов является составление графа связей.


    Граф связей в Solar Dozor

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

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

    Заказчик не выдержал и решил лично посмотреть на эти письма, и тут возникла следующая странность. Оказалось, что писем нет ни на сервере, ни на рабочих станциях отправителей. Все следы были удалены, но, поскольку Solar Dozor хранит всю историю сообщений, в архиве DLP письма остались. Стало понятно, что мы, возможно, имеем дело с чем-то более сложным, чем инсайдерские действия сотрудников. DLP свою задачу выполнила – выявила утечку, сделала анализ окружения, коммуникаций и действий сотрудников, пришло время использовать другие средства.

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

    Аналитики подключили к мониторингу рабочие станции, с которых уходили письма. Обычно по логам операционной системы можно собрать всю необходимую информацию, но в этом случае никакой информации в списке запускаемых процессов не было – security log был очищен на всех станциях сразу после отправки последнего транша писем, а новых отправок не было. Единственной зацепкой, с помощью которой мы вышли на след злоумышленника, стало то, что журнал system log не был очищен и зафиксировал запуск необычной службы. Как оказалось, мы имели дело с 0day-вирусом, который действовал на машинах пользователей не как процесс, а как служба.

    Увидев эту службу-аномалию, мы вычленили тело связанного с ней вредоносного объекта и запустили его в изолированной среде, чтобы понаблюдать за происходящим. Process Monitor, WireShark и другие утилиты осуществляли дополнительный сбор логов, чтобы мы могли зарегистрировать все сетевые и процессные аномалии.

    В результате о вредоносе стало известно следующее: он состоял из нескольких модулей – один был типовым кейлоггером и делал скриншоты экрана, второй предоставлял возможность удаленного доступа, а третий копировал те документы, с которыми работает пользователь, и по расписанию ночью отправлял их на ту самую внешнюю почту, которая и насторожила DLP-систему. Вирус «сливал» вовне не более 50 МБ за раз – очевидно, злоумышленникам было важно не только закрепиться в инфраструктуре, но и как можно дольше не выдавать своего присутствия. На эту же цель работало то, что сразу после установки вредонос незаметно для пользователя деактивировал антивирус. Мы перехватили трафик, идущий с зараженного хоста, и, разобрав его, установили IP сервера, с которым общался вирус.

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

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

    Этот случай показывает, что иногда, если быть внимательным к аномалиям в действиях пользователей и систем, даже логи DLP могут указать на целенаправленную атаку. Собственно, поэтому мы всегда уделяем этому большое внимание. Часто аномалии не свидетельствуют ни о чем нелегитимном, но иногда их анализ способен открыть безопаснику полную картину, которую не дадут разрозненные средства защиты. Поэтому будьте внимательны, не проходите мимо странностей, собирайте всю возможную информацию и — да пребудет с вами сила:).
    Ростелеком-Солар
    Безопасность по имени Солнце

    Комментарии 19

      –2
      Спасибо, весьма интересно и познавательно!
        +3

        А как насчет поделиться техническими данными, хотя бы где этот вирус держит автозапуск? Лучше, конечно, всеми, которые определяют сам вирус, но не определяют атакованного клиента.

          –2
          Автозапуск — в службах)
          +1
          А как именно происходит контроль исходящей почты и вложений?
          Если бы вредонос перед отправкой данных зашифровал или закодировал их, и результат ни в какой части не совпадал с конфиденциальными документами(добавив в какой-то сгенерированный документ, к примеру), то никто-бы и не среагировал?
            0
            0-day вирус через services — и при этом отправляет без палева в открытую на левый адрес??
            Вы серьёзно????))))
              0
              Сам термин непонятен, что значит 0-day вирус?! В остальном терпимо и интересно)
                +1
                Подразумевается вирус, который пока не известен антивирусным решениям.
                Спасибо)
              +1
              но тело письма всегда было пустым. Подозрительный адрес встречался исключительно в одиночку
              Не было ни одного письма, которое приходило бы с этого адреса в ответ.
              такая «лобовая атака» вызвала некоторую оторопь.
              Мы составили список всех нарушителей, он насчитывал около 20 человек.

              То есть, пара десятков человек якобы внаглую отправляют со своих компьютеров на левую почту пустые письма с важными документами, а у вас "напрашивалось предположение, что это сотрудники скидывают"? Странно, что вы сразу на вирус не подумали.

                +1
                Так бывает чаще, чем может показаться. Причем иногда это даже не злонамеренная утечка — просто человек хочет поработать из дома и скидывает себе необходимые документы. И как раз в таких случаях тело письма отсутствует.
                Сложно сказать, почему сначала подумали на внутренний сговор, а не на вирус. Возможно, профдеформация — на DLP-проектах люди «заточены» на выявление утечек и различного толка мошенничеств. К тому же, в рамках большой организации 20 человек — это не так много, как может показаться.
                0
                Меня тут удивил адрес XXXX@icloud.com. Чтобы пользоваться таким адресом надо иметь устройство Эппл. По функционалу аккаунт ничем не отличается от любой другой почтовой системы. Так, спрашивается, почему именно Icloud? Странно, что авторы трояна используют такой неудобный адрес. Еще непонятно: «ряд конфиденциальных документов регулярно уходил на внешний адрес вида XXXX@icloud.com» — это каким образом было? Почтовый сервер организации их туда отправлял? по SMTP? Может быть документы предавались по SMTP через посторонний сервер? В этих случаях организации следовало бы вначале настроить правильно свое хозяйство, а уж потом внедрять DLP.
                  +1
                  сервер организации их туда отправлял? по SMTP

                  А что тут странного? Вирус от имени пользователя создавал письмо, авторизовывался на SMTP-сервере и отсылал документы (возможно, автоматизацией аутлука), как любой другой пользователь "вот документы. которые Вы просили", "Акты и счета фактуры для ООО "Вектор"" и пр. Если известно что организация так шлёт постоянно, то логичнее так же отсылать, а не слать .gz.pgp какой, который может почтовик забанить. Про DLP они могли и не знать, а без него затеряться в потоке .doc/.xls проще.
                  Адрес да, странный, в домене .mail.zw кажется более логичным (по крайней мере там точно не узнают id связанного устройства и не сдадут IP отделу K, как mail.ru какой).

                  –1
                  пользователи имеют возможность напрямую подключаться к любым внешним адресам в интернете для доставки почты? Прекрасно…

                    0
                    Тогда надо и весь интернет пропускать через белый список. Иначе легко например через веб отправлять письма.
                      0
                      http/http можно в прокси завернуть и логи анализировать или отключать доступ по расписанию
                        0
                        Если развернута целая DLP-система — следует предположить, что какой-то firewall тоже существует. Закрыть на уровне firewall все, не относящееся напрямую к бизнес-процессам в конторе (а уж SMTP в первую очередь). Как минимум тупых зловредов, которые сразу начинают рассылать спам, это нейтрализует.
                        Думаю, скоро появятся зловреды, которые сначала будут анализировать исходящий траффик, а уж потом решать, каким образом передавать информацию. Человек лазит по социальным сетям? Фотографии котиков, стеганография, https — попробуйте обнаружить канал утечки.
                    • НЛО прилетело и опубликовало эту надпись здесь
                        +1
                        Теперь, когда дело по dlp системе прогремело по компании, самые хитрые начнут сливать информацию по более изощрённым схемам изучив пару статей в интернете «обход dlp для чайников».
                          0
                          Меня интересует вопрос, зачем вообще вирусы используют протокол email? Может быть нее палевно использовать http?
                            +1
                            Ну, авторам вируса это показалось удобным. Странное решение, как по мне. Внедрить 0-day зловреда и рассчитывать, что SMTP в компании не закрыт и не мониторится — это fuckup.

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

                          Самое читаемое