Оглавление
Введение
Хотя большинство организаций применяет многоуровневую стратегию защиты, злоумышленники все равно время от времени находят бреши и незаметно обходят несколько уровней безопасности. Чтобы свести к минимуму ущерб от подобного сценария, нужна оценка компрометации (compromise assessment), основная задача которой — снижение рисков путем выявления активных исторических кибератак, не замеченных стандартными средствами защиты. В оценку компрометации входят следующие задачи:
сканирование всех конечных устройств специализированными инструментами;
анализ журналов хостов и сетевого оборудования;
анализ угроз, включающий поиск в даркнете;
первоначальное реагирование на инциденты для сдерживания обнаруженных угроз.
В этой статье мы рассмотрим реальные случаи из нашей практики, когда организации были скомпрометированы, несмотря на множество мер безопасности. Во всех рассматриваемых случаях оценка компрометации стала последней линией защиты, которая успешно выявила инциденты.
Проблемы с управлением установкой исправлений
Процесс устранения уязвимостей обычно занимает время и включает несколько этапов: от выпуска исправления до выявления уязвимых активов и их правильного обновления, что требует предварительной инвентаризации активов и своевременного уведомления ответственных сотрудников об уязвимости. Существует множество факторов, которые могут замедлить этот процесс, включая бюрократию в требованиях по обеспечению непрерывности бизнеса и невозможность перезагрузки сервера без окна простоя.
Вот почему неэффективные процессы управления исправлениями у клиентов часто становятся одной из главных причин инцидентов, которые мы наблюдаем в проектах по оценке компрометации. Более того, эксплуатация доступных извне приложений стала основной причиной 42,37% инцидентов, расследованных Международной группой экстренного реагирования «Лаборатории Касперского» (GERT) в 2023 году.
В ходе расследования одного случая мы выяснили, что соответствующее исправление для веб-сервера было установлено лишь через месяц после проникновения злоумышленника в сеть. Это промедление позволило атакующему незаметно совершить ряд вредоносных действий, пока организация оставалась незащищенной.
Сразу после компрометации сервера злоумышленник развернул стейджер командного сервера SILENTTRINITY.
В первый день он попытался сделать дамп учетных данных с помощью упакованной версии Mimikatz, а на четвертый день — сохранить дамп памяти процесса LSASS на диск.
В течение этого месяца злоумышленник проводил внутреннюю разведку SMB-ресурсов, пока не получил учетные данные администратора домена.
Нарушения политики безопасности сотрудниками
Большинство организаций сосредотачиваются на внешних угрозах, однако нарушения политики безопасности сотрудниками также представляют серьезный риск: 51% инцидентов в малом и среднем бизнесе и 43% инцидентов на предприятиях связаны с небезопасными действиями сотрудников. Под сотрудниками мы подразумеваем любого человека, имеющего стандартный уровень доступа к системам организации.
В одном из проектов по оценке компрометации мы выявили инцидент, который стал возможен из-за действий внешнего консультанта по кибербезопасности. На промежуточном отчетном совещании мы представили совету директоров клиента список скомпрометированных учетных записей, полученный в результате поиска в даркнете, а также статистику по этим учетным записям. Из всех скомпрометированных аккаунтов 71% принадлежали сотрудникам заказчика, при этом 63% из них были связаны со службами, доступными извне.
Статистика по скомпрометированным учетным записям организации. Источник: Kaspersky Digital Footprint Intelligence
В список попала учетная запись представителя высшего руководства. Поскольку ситуация была критической (все подозревали, что ноутбук руководителя был скомпрометирован), мы провели быстрое расследование прямо во время встречи. Выяснилось, что учетные данные попали к злоумышленникам с компьютера стороннего консультанта: руководитель создал учетную запись во внешней системе, использовав свою корпоративную электронную почту, и поделился данными с консультантом. Поскольку было очевидно, что на ноутбуке консультанта могут быть и другие конфиденциальные данные, мы разработали следующий план реагирования.
Извлечь пакет необработанных данных с ноутбука консультанта.
Проанализировать пакет данных, чтобы составить полный список утекших учетных данных.
Проверить ноутбук консультанта на наличие вредоносного ПО.
Провести поиск по ключевым словам для выявления потенциально утекших документов.
Изучить журналы электронной почты, VPN и других служб, которые могли быть затронуты, на предмет аномального поведения скомпрометированных учетных записей.
Проверить, была ли включена многофакторная аутентификация для скомпрометированных учетных записей на момент инцидента.
Обновить план реагирования на инцидент на основе полученных результатов. Необходимо как минимум сбросить пароли и переустановить образ ноутбука.
Этот инцидент можно было бы предотвратить, обеспечив соблюдение политик как сотрудниками, так и третьими сторонами, имеющими доступ к сети. Но на практике это бывает непросто и требует времени, усилий и глубоких технических знаний.
Проблемы MSP/MSSP
Обычно MSSP больше внимания уделяют непрерывному мониторингу и оповещениям, чем выявлению пробелов в системах обнаружения и улучшению видимости инфраструктуры клиента — периодическому анализу политики аудита событий клиента, включению отключенного источника событий и перенастройке плохо работающих источников. Например, на веб-сервере часто оказывается не включен HTTP-заголовок X-Forwarded-For. В результате SOC не видит исходный IP-адрес соединения и не может определить источник атаки, что усложняет расследование инцидента.
В нашей практике оценки компрометации мы часто выявляем инциденты, которые были пропущены внешними SOC. В ходе одного проекта мы проверили журналы сторонних антивирусов и обнаружили несколько случаев детектирования веб-шелла на одном сервере в течение нескольких дней.
День (считая с первой попытки применения эксплойта)
Путь к файлу
Вердикт
Сообщение
День 1-й
C:Windows[скрыто
в целях
конфиденциальности].aspx
Backdoor.ASP.WEBS
HELL.SM
Вредоносное ПО успешно
удалено
День 2-й
C:Windows[скрыто
в целях
конфиденциальности].aspx
Backdoor.ASP.WEBS
HELL.SM
Вредоносное ПО успешно
удалено
День 3-й
C:Windows[скрыто
в целях
конфиденциальности].aspx
Backdoor.ASP.WEBS
HELL.SM
Вредоносное ПО успешно
удалено
День 4-й
C:Windows[скрыто
в целях
конфиденциальности].aspx
Backdoor.ASP.WEBS
HELL.SM
Вредоносное ПО успешно
удалено
День 7-й
C:Program FilesCommon
Filesmicrosoft sharedWeb
Server
Extensions16TEMPLATELA
YOUTS[скрыто в целях
конфиденциальности].aspx
Backdoor.ASP.WEBS
HELL.SM
Вредоносное ПО успешно
удалено
День 9-й
C:Windows[скрыто
в целях
конфиденциальности].aspx
Backdoor.ASP.WEBS
HELL.SM
Вредоносное ПО успешно
удалено
SOC-аналитики MSSP не подняли тревогу, потому что антивирус каждый раз удалял вредоносное ПО. Это классическая ошибка неопытных специалистов: если мотивированный злоумышленник заполучил доступ к серверу через уязвимость, он будет пробовать различные техники и методы, чтобы обойти защитное решение. Поэтому важно, чтобы аналитик сохранял бдительность и предотвращал такие попытки, обеспечивая дополнительный уровень защиты.
В описанном случае не хватило именно реакции аналитика: эксперты «Лаборатории Касперского» провели глубокую криминалистическую экспертизу и выяснили, что злоумышленник в течение нескольких недель пробовал разные веб-шеллы и, наконец, нашел один, который на тот момент не обнаруживало установленное у клиента защитное решение, что позволило ему проникнуть в сеть. Дальнейшее расследование показало, что весь домен был скомпрометирован в течение нескольких месяцев.
Мониторинг и проверка качества услуг вашего MSP или MSSP часто являются сложными задачами. Контрактные соглашения обычно не позволяют клиентам получать доступ к внутренним системам поставщика для детальной проверки. Кроме того, клиентам может недоставать технических знаний или времени для контроля за каждым шагом, предпринимаемым их субподрядчиками.
MSP и субподрядчики, которые не обладают достаточной осведомленностью в области кибербезопасности, могут непреднамеренно подвергнуть сеть риску, неправильно настроив механизмы защиты или следуя сомнительным практикам.
Неполное реагирование на инцидент
Устранение последствий действий злоумышленника после компрометации требует тщательного плана по удалению всех артефактов в сети или системах. Этот план должен включать:
удаление вредоносного ПО, скриптов, инструментов и бэкдоров, установленных злоумышленником;
смену паролей скомпрометированных учетных записей и удаление любых неавторизованных служебных учетных записей, созданных злоумышленниками;
откат настроек системы, которые увеличивают поверхность атаки или создают новые уязвимости.
Даже после удаления вредоносного ПО в системе остаются аналитические артефакты, поэтому во время оценки компрометации часто обнаруживаются следы прошлых атак. Хотя умышленно внедренные злоумышленниками ошибки конфигурации встречаются реже, иногда мы сталкиваемся с тем, что такие «хвосты» остаются незамеченными внутренними командами реагирования на инциденты.
В ходе анализа конфигурации Active Directory аналитики «Лаборатории Касперского» обнаружили групповую политику с несколькими следующими подозрительными характеристиками.
Изменение свойства AllowReversiblePasswordEncryption для каждой учетной записи AD, которое позволяет контроллерам домена хранить пароли в расшифровываемом виде без использования одностороннего хеширования. В этом случае злоумышленник сможет получить учетные данные в открытом виде с помощью атак типа DCSync.
Отключение аудита операций, связанных с билетами Kerberos. В этом случае все авторизации злоумышленника на всех конечных устройствах, управляемых через Active Directory, будут скрыты.
Ложное чувство безопасности
Даже очень продвинутые решения кибербезопасности эффективны только при правильной установке, интеграции и настройке. Без этого организация не сможет полностью раскрыть их потенциал и выстроить надежную защиту.
В нашей практике оценки компрометации некоторые инциденты удавалось обнаружить благодаря развертыванию специализированных сканеров вместе с существующим антивирусом или решением для защиты рабочих мест, что обеспечило дополнительный уровень обнаружения.
Отсутствие правила обнаружения: антивирус клиента не смог выявить веб-шелл pivotnacci, потому что у его поставщика не было соответствующего правила обнаружения.
Устаревшие сигнатуры вредоносного ПО: антивирус клиента не смог обнаружить вредоносное ПО, так как брандмауэр заблокировал сетевой порт центрального сервера обновлений, из-за чего актуальные обновления не загружались.
Теневые IT: антивирус не был установлен на некоторых серверах, так как они не входили в Active Directory, что делало их уязвимыми.
Заключение
Описанные в этой статье случаи показывают, что ни одна мера безопасности, даже самая продвинутая, не является панацеей. Риски бывают самые разные и зачастую, несмотря на свою очевидность, остаются незамеченными: от нарушений внутренних политик и проблем с управлением установкой исправлений до неправильной конфигурации систем сторонних поставщиков услуг. Эти примеры показывают, что ложное чувство безопасности может принести больше вреда, чем полное отсутствие защиты, поскольку оно делает организации уязвимыми к угрозам, которые могли бы быть выявлены в ходе тщательного регулярного оценивания.
Благодаря интеграции оценки компрометации (compromise assessment) в свою структуру безопасности организации смогут выявлять скрытые угрозы и эффективно устранять уязвимости, что в конечном счете усилит их общую защиту. В мире, где киберугрозы постоянно развиваются, упреждающее выявление и предотвращение потенциальных угроз не просто желательно, но и жизненно необходимо. Этот подход дает возможность не только реагировать на инциденты, но и постоянно контролировать эффективность защиты, что снижает риск незамеченной компрометации и помогает лучше защищать активы.
Securelist