Аналитики 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 могут указать на целенаправленную атаку. Собственно, поэтому мы всегда уделяем этому большое внимание. Часто аномалии не свидетельствуют ни о чем нелегитимном, но иногда их анализ способен открыть безопаснику полную картину, которую не дадут разрозненные средства защиты. Поэтому будьте внимательны, не проходите мимо странностей, собирайте всю возможную информацию и — да пребудет с вами сила:).
Сегодня мы хотим рассказать об очередном примере, подтверждающем эту истину. Под катом – история одной атаки, которая едва не прошла незамеченной.
Начиналось все вполне стандартно: мы запустили проект внедрения у очередного заказчика. Менее чем через неделю, когда мы еще даже не успели толком настроить систему под требования компании, 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 могут указать на целенаправленную атаку. Собственно, поэтому мы всегда уделяем этому большое внимание. Часто аномалии не свидетельствуют ни о чем нелегитимном, но иногда их анализ способен открыть безопаснику полную картину, которую не дадут разрозненные средства защиты. Поэтому будьте внимательны, не проходите мимо странностей, собирайте всю возможную информацию и — да пребудет с вами сила:).
