Введение
Предотвратить проникновение злоумышленника, сделать периметр организации неприступной крепостью – именно такие задачи чаще всего ставятся перед подразделениями ИБ. По многим объективным причинам это не работает на 100%. Периодически всплывают громкие скандалы со взломом крупных компаний, например, кибератака на SolarWinds в результате которой пострадали многие ИТ компании, среди которых были даже производители средств защиты информации. Пандемия неожиданно принесла еще один сюрприз в виде размытия периметра. Организации, вынужденно отпустив своих сотрудников во время локдаунов на удаленку, зачастую, решили сохранить данный режим работы или же сделать смешанный режим. Конечно, контролировать периметр, когда множество девайсов появляется и исчезает уже внутри инфраструктуры становится значительно сложнее.
Если компаниям уже нельзя значительно повысить сложность проникновения злоумышленника в инфраструктуру организации, то можно повысить скорость выявление злоумышленника внутри этой инфраструктуры.
Согласно исследованиям в 100% случаев, если атакующий проник в инфраструктуру организации, то атака заканчиваются достижением цели атакующих.
Почему так происходит?
Потому что атаку не смогли вовремя обнаружить.
Что делать в такой ситуации?
Для начала нарастить инструментарий для выявления того, чего не должно быть в инфраструктуре.
Одним из классов систем, которые значительно ускоряют выявление злоумышленника, являются Deception системы. Для тех, кто еще не успел познакомиться с этим классом решений, напомню, Deception системы — это комбинация серверов-ловушек, способов обмана злоумышленника и подталкивания его на взаимодействие с серверами-ловушек, которые детектируют любое взаимодействие с ними. Именно способ «подталкивания» злоумышленника к взаимодействию и является отличительной (и, наверное, самой важной) чертой разных Deception систем от honeypot. Обман обычно сводится к двум способам:
создание ложных сетевых узлов с различными сервисами;
размещение на узлах данных, которые ведут злоумышленника на взаимодействие с trap-сервером (сервер ловушка). Именно те системы, которые комбинируют два этих подхода и являются наиболее действенными.
Сейчас мы с Вами рассмотрим на примере Xello Deception, как будет выглядеть развитие атаки в инфраструктуре с действующей Deception системе. Я постараюсь показать вам, насколько усложняется жизнь злоумышленника и насколько быстрее становиться его выявление.
Дано:
Домен, внутри которого несколько АРМ и серверов.
Злоумышленник, имеющий сетевой доступ к домену и АРМ, но без каких-то известных учетных записей в инфраструктуре.
Развернутый Xello Deception:
· на конечных устройствах учетные записи настоящие, пароли ложные (легко подобрать). В рамках нашего примера ограничимся только настоящими учетными записями (Dexem-приманки в терминологии вендора). Кроме действующих УЗ можно еще создавать ложные записи (которые есть только локально и не существуют в AD) и отключенные учетные записи.
· В AD пара учетная запись-пароль настоящая, пароль устойчив к перебору
· Созданы DNS-алиасы ведущие на сенсоры Xello (trap-серверы)
o Созданы сервера сенсоры xello (trap-серверы)
Типичный случай
Представим ситуацию, что злоумышленники смогли подключить к внутренней сети через одноплатный компьютер с удаленным доступом (подкуп-шантаж или просто обиженный сотрудник решил оставить свой след в истории – не важно для нашего случая). Если вам ближе истории про социальную инженерию, прокрутите статью до шага 3 и представьте, что хакер сразу получил доступ к АРМ.
Итог: злоумышленник имеет сетевой доступ к узлам внутри инфраструктуры.
Шаг 1. Сбор информации
Одно из первых действий, которые делает злоумышленник это разведка. Это может быть как безобидный пинг, так и полноценное сканирование.
Часто в ходе разведки удается найти учетные данные в исходных кодах внутренних веб-приложений, внутренних инструкций, регламентах, логах отладки и т.д. все это может содержать данные полезные для злоумышленника. Именно поэтому одно из первых возможных действий типичного злоумышленника сканирование открытых сетевых директорий.
Договоримся, что листинг команд мы обрежем для экономии «бумаги» и будем подводить итоги сами. Злоумышленник общедоступных сетевых директорий не нашел, подписывание SMB включено и NTLM-релей не пройдет. Есть список стандартных портов unix и windows машин.
Пока злоумышленник думает, что лучше проверит следующим, посмотрим, что уже видно со стороны Xello. А там, красота!
Шаг 2. Получение первичного доступа
Вернемся к нашему кейсу.
Злоумышленник не опускает руки, если нет сетевых шар с УЗ, то можно: найти уязвимые хосты, подобрать пароли, провести LLMNR/NBTNS спуфинг и т.д. Поскольку именно нарушение парольной политики приводит злоумышленников к достижению поставленных целей в 86%[1] случаев, то первое что он делает – PasswordSpray SMB.
Нашему злоумышленнику повезло. Проводя атаку "PasswordSpray" по протоколу SMB, он обнаружил что на одной рабочей станции забыли сменить стандартный пароль локального администратора. Это позволило ему получить точку опоры в сети и только один шаг отделяет его от доступа к инфе в DC - ему необходимо добыть из скомпрометированного АРМ доменную учетную запись.
Пока злоумышленник продолжает подбирает пароли (никто обычно не тормозит при обнаружении первой пары УЗ-пароль), посмотрим, как дела идут у Xello.
На каждую попытку подбора УЗ генерировался Алерт, о котором бравый Deception может рапортовать в сторону SIEM системы по syslog или почтой в АИБ (Администратор ИБ).
Загибаем пальцы: два.
Шаг 3. Сбор дополнительной информации
А что Хакер?
Хакер занят, ему некогда отвлекаться. Один из простых и относительно незаметных способов добыть сохраненные на АРМ хеши и пароли пользователей - сдампить процесс lsass.exe и забрать сделанный дамп себе для изучения. У злоумышленника как раз уже есть все необходимые права. Дампим LSASS одной командой при помощи crackmapexec:
Выкачиваем дамп и удаляем его при помощи smbclient:
При помощи pypykatz извлекаем все интересное и видим в открытом виде пароли доменных пользователей:
Злоумышленник уже потирает руки, наливает себе чай и готов праздновать победу т.к. учетные данные нескольких пользователей на руках.
Время собирать инфу о домене и намечать бизнес-критикал системы, искать админов и т.д.
Что-то идет не так. Неправильные учетные данные? Возможно, тут лежали закешированные данные, а пользователь обновил доменные данные и давно тут не логинился? Возможно.
Но мы то с вами знаем в чем дело. Это учетные записи приманки. Они созданы Deception-системой автоматизировано, на основании ваших реальных данных из домена (у Xello технология создания максимально похожих УЗ называется Dexem), и служат для того, чтобы заставить хакера тратить свое время и явно сигнализировать о его действиях. Учетные записи, которые видит злоумышленник на узлах реальные, только пароль, который есть в LSASS легко перебирается, а настоящий пароль который установлен для данной УЗ не перебирается. Любая попытка обращения нашего хакера с данными УЗ вызовет появление события ИБ. Обычно, многие организации отключают в SIEM корреляцию на некорректную аутентификацию или тюнят ее так, чтобы не отвлекаться на каждую опечатку обычных пользователей, что так или иначе снижает возможности SIEM. Тут же Xello знает, какие учетки являются ложными и на каждое логируемое действие с ложными УЗ вызывает событие безопасности. Кроме того, данные УЗ-приманки не отличаются от настоящих поскольку по своей природе это и есть самые обычные доменные УЗ.
Основной функционал Xello заключен именно в этом, наводнить настоящую инфраструктуру таким количеством ложных данных, чтобы злоумышленник натыкался на них, поднимал алерты и тратил свое время. При этом эти учетные данные не мешают работать обычным пользователям.
Загибаем пальцы: три
А в Deception уже сработки, что была попытка доступа с этими УЗ:
Как было видно из скриншотов выше, злоумышленник восстановил не 1 учетную запись, а несколько. Одна из дальнейших попыток приводит его к успеху (а каждый провал генерирует алерт в Xello). Среди множества восстановленных учетных записей приманок злоумышленник нашел настоящую УЗ "dmitry.pchelkin" после восстановления хеша выясняется, что пароль - Q1w2e3r4. Наконец-то была получена информация о домене!
Получив список пользователей, наш злоумышленник хочет собрать больше УЗ. Для этого он пробует атаку PasswordSpray по протоколу Kerberos. Злоумышленник помнит, что в собранной информации была инфа по парольной политике и блокировкам УЗ и увеличивает интервал, чтобы не вызывать блокировки.
Пока злоумышленник "незаметно" проверяет разные пароли, для каждой такой сессии Deception генерирует инцидент, в котором мы видим что кто-то пытается войти в наши Dexem-приманки, можно бить тревогу.
Загибаем пальцы: четыре.
И вот только сейчас злоумышленник смог начать проверять сетевые файловые хранилища.
И опять Xello говорит нам о том, что есть что-то не то.
Загибаем пальцы: пять.
Шаг 4. Финал
Если наш злоумышленник пришел в инфраструктуру за данными, то у него уже есть возможность достучаться к сетевым файловым хранилищам (с полученной УЗ) и это финал (как атаки, так и возможно самой компании из-за колоссальных убытков последующих за утечкой информации). Как показывает наша практика проведения тестирования на проникновение, очень часто на файловых шарах можно найти настоящие бриллианты.
Однако, стоит заметить, что есть и другие варианты развития атак, которые в свою очередь зависят от целей злоумышленника. Это может быть, как и последующее исследование окружения и перемещение между станциями и серверами, дальнейшие попытки повышения привилегий в домене, шифрование данных с целью выкупа и т.д.
А что ИБ? Служба ИБ знает, что уже есть у Злоумышленника, где он имеет привилегии и они могут уже вести расследование инцидента и принимать соответствующие меры к Злоумышленнику.
Заключение
В ходе этого примера мы выявляли зловредную деятельность в сети практически с первого пакета, рассмотрели базовый функционал Deception системы и увидели, как сильно он помогает в выявлении злоумышленника. Конечно, действия злоумышленника, описанные выше, это один из множества возможных вариантов как может вести себя хакер проникший внутрь, но есть и места, по которым пойдут 99,9% злоумышленников – доступ к доменным УЗ (см. шаг 3). Созданные и разложенные на АРМ приманки, которые не отличаются от обычных УЗ это тот уникальный функционал, который вынудит злоумышленника заявить о себе. Восстановление хешей учетных записей-приманок и их использование выдает злоумышленника в 100% случаев. Обычно, процесс бокового перемещения злоумышленника занимает несколько шагов и на каждом шаге, хакер будет видеть не одну или две УЗ на АРМ или сервере, а 10 или даже 30 УЗ, кроме того, приманки размещаются не только в LSASS (а еще и в Microsoft Vault, истории сессий в браузере, подключения putty/winscp, скрипты подключений, обычные как-бы «забытые» текстовые файлы с «логин-пароль-IP» и т.д.), что действительно усложняет и замедляет действия хакера по практически всем возможным векторам атак.
Шансов, что на каждом из шагов своего перемещения хакер угадает среди десятков УЗ настоящие на протяжении всего бокового перемещения около 0.
Функционал Deception систем не ограничен только лишь приманками в виде учетных данных windows, есть еще множество типов хостовых приманок для разных протоколов взаимодействия, DNS-алиасы, которые очень полезны для выявления действия инсайдеров и запутывания атакующего, сенсоры (trap-сервера), которые помогают оперативно выявлять ВПО внутри инфраструктуры и т. д. но это не укладывается в эту статью и может быть рассмотрена в рамках отдельной статьи.
Низкое количество ложных срабатываний, создание дополнительных препятствий для злоумышленников, возможности интеграции по API с другими СЗИ и автоматизация(!) реагирования СЗИ на определенные действия делает из Deception систем очень эффективное средство по выявлению злоумышленников.
