Standoff 10 прошел насыщенно: юбилейная кибербитва ознаменовалась масштабными учениями атакующих (red team) и защитников (blue team), актуальными докладами и дискуссиями по вопросам кибербезопасности. Мероприятие стало знаковым и для нашей команды, отвечающей в компании за мониторинг и реагирование, — SOC PT Expert Security Center. Во-первых, на битве компания объявила о старте первой в России багбаунти-программы на реализацию недопустимого события — хищения денежных средств со счетов Positive Technologies. Ее особенность в том, что багхантеры атакуют нашу действующую инфраструктуру. До сих пор провести многоэтапную атаку вплоть до неприемлемого для нас сценария не удалось ни одному белому хакеру, поэтому компания увеличила размер вознаграждения втрое — до 30 млн рублей.
Во-вторых, мы с коллегами из SOC приняли участие в митапе Standoff Talks, в рамках которого я рассказала о распространенных ошибках атакующих, которые помогают нам быстро и эффективно их обнаруживать. Все это могло предвещать определенное изменение атакующего воздействия на нашу инфраструктуру — как количественное, так и качественное.
И действительно, с первого дня запуска багбаунти-программы мы фиксировали всплеск интереса к нашим ресурсам, применение нестандартных техник и методов. Совпадение или нет, но стали встречаться и предложенные нами на Standoff Talks подходы к байпасу SOC 😊.
На волне впечатлений от разнообразной активности атакующих я решила, что самое время написать статью по мотивам моего доклада. Какие опрометчивые действия чаще всего совершают редтимеры на киберучениях? На какие маркеры всегда обращает внимание SOC? И как стать чуть менее заметными для синих команд? Обо всем этом читайте под катом!
Коротко про киберучения: что, зачем и почему
О том, как трудно искать в темной комнате черную кошку, аналитики SOC знают не понаслышке. Особенно если там ее нет: среди многообразия анализируемых в процессе мониторинга алертов (подозрений на инцидент) реальные, требующие реагирования инциденты ИБ встречаются редко. Отсюда закономерно вытекает вопрос: как на практике оценить эффективность SOC, средств защиты и используемых детектов в случае кибератаки до того, как она обернется критическими последствиями? Ответ — провести киберучения на своей инфраструктуре!
Наша команда накопила богатый и разноплановый опыт, участвуя в различных мероприятиях по оценке защищенности компании: варьировались форматы (от классического red teaming до популярного сейчас purple teaming), менялись противники (от наших замечательных внутренних пентестеров до сторонних белых хакеров), продолжительность (от нескольких дней до нескольких месяцев). Не углубляясь в традиционно холиварные провокационные вопросы отличий и особенностей возможных методов оценки ИБ, отмечу, что каждый из них отвечает разным целям и задачам, но абсолютно все несут возможности для развития экспертизы SOC.
🟥 Red team (атакующие, «красные») — команда исследователей безопасности, которые осуществляют комплексную имитацию реальных атак с целью оценки кибербезопасности IT-систем.
🟦 Blue team (защитники, «синие») — сотрудники подразделений ИБ, которые отвечают за мониторинг безопасности сетевой инфраструктуры, выявляют любые возможные уязвимости и реагируют на атаки.
🟪 Purple team («фиолетовые») — взаимодействие red team и blue team. Такой формат тестирования позволяет выявить слабые места и улучшить организацию работы обеих команд.
Безусловно, самым большим вызовом и проверкой на прочность для нас стали «полноконтактные» киберучения с внешними атакующими (о них мы много и подробно рассказывали). Особенность таких учений в том, что приглашенные команды исследователей пытаются верифицировать обозначенные нашей компанией недопустимые события, максимально точно имитируя реальных злоумышленников и стараясь остаться не замеченными SOC. Наша же главная задача — не допустить реализации этих недопустимых событий 🙂. Задача на самом деле незаурядная, когда против тебя работают профессиональные красные команды с сильнейшей экспертизой. На чем же базируется успешное отражение атак со стороны SOC?
Защитники должны мыслить как атакующие... и наоборот
В основе эффективного противодействия всегда лежит понимание образа мыслей и поведения противника. Зная, какие техники и подходы обычно используют атакующие, можно определить и систематизировать признаки для выявления их действий. Идеальных преступлений не бывает, и любой нападающий обязательно где-нибудь ошибется и оставит следы, по которым грамотный защитник сможет его обнаружить.
Этот же подход работает и в обратную сторону: чем лучше атакующие понимают, как строятся детектирующие правила и на что обращает внимание SOC при расследовании инцидентов, тем успешнее они могут уклоняться от обнаружения и достигать поставленных целей на проектах red teaming.
Обобщив свой опыт, мы выделили самые распространенные ошибки атакующих и следы, которые чаще всего их выдают. Далее мы разберем каждую ошибку на живых примерах и рассмотрим ее с обеих сторон: для коллег из blue team подсветим некоторые идеи по обнаружению и расследованию, а для red team — возможные варианты обхода детектов и уклонения от обнаружения. В этом материале рассмотрим маркеры, которые позволяют обнаружить и пресечь действия «красных» на ранних этапах атаки. Поехали!
Сканеры
Любые киберучения неизменно начинаются с проведения атакующими внешней разведки. Она, в свою очередь, включает в себя два этапа: пассивный сбор информации (не предполагающий взаимодействие с целевой инфраструктурой) и активное исследование, подразумевающее сканирование внешнего периметра компании, анализ опубликованных на нем сервисов, поиск веб-приложений, идентификацию уязвимостей в автоматизированном и ручном режимах.
По своей природе активная разведка — довольно «шумный» процесс, который, как правило, быстро попадает на радары защитников. В частности, многие сканирующие утилиты, используемые при исследовании веба, оставляют характерные следы в HTTP-трафике, по которым можно моментально идентифицировать их активность. К таким следам относятся паттерны инструмента в заголовках запросов, например у сканеров часто бывают прописаны дефолтные значения User-Agent, в явном виде содержащие их названия. Кроме того, некоторые утилиты можно определить по специфичным индикаторам в виде их стандартных полезных нагрузок, захардкоженных URI или параметров. Все эти признаки часто применяются для создания различных детектов (например, IDS-, IPS-, NTA-сигнатур или правил для WAF), которые дают возможность выявлять сканирования автоматизированными средствами. Примеры подобных сигнатур из открытого набора ETOpen:
Соответственно, такие сигнатурные признаки позволяют задетектировать активность атакующих не только в случае агрессивных массовых сканирований, но и в случае аккуратного «прощупывания» отдельных веб-ресурсов, которое могло бы остаться не замеченным SOC:
При этом стоит отметить, что внешние сканирования обычно носят массовый характер, и с ходу отличить целенаправленное воздействие от рядовых ботов или скрипт-кидди бывает весьма непросто. Поэтому на этапе активной разведки «красные» преимущественно попадают в поле зрения SOC не из-за сканирований как таковых, а из-за обнаружения сопутствующих индикаторов, по которым их можно атрибутировать и найти связи с другими активностями. Подобным индикатором может быть, например, использование IP-адресов из пула определенного провайдера или региона, фиксированные значения куки или общие поля в других заголовках. Такие следы позволяют blue team отслеживать (и при необходимости превентивно блокировать) атакующих по этим паттернам, а также соотносить сканирования с последующими атаками (например, с брутфорсом внешних сервисов или фишингом).
По нашему опыту, «красных» нередко удается выявить по банальному переиспользованию IP-адресов, задействованных в активной разведке. Самым запоминающимся был случай на киберучениях, в ходе которых команда редтимеров получила доступ к нашей внутренней инфраструктуре. В тот раз нам удалось оперативно обнаружить атакующих по попыткам подключения к корпоративному VPN с IP-адреса, замеченного двумя днями ранее в сканировании архивных сайтов конференции PHDays 😊.
🔴 Tips & Tricks для «красных»:
меняйте дефолтные для применяемых инструментов значения User-Agent, но аккуратно, так как слишком нестандартные значения тоже могут привлечь внимание SOC (кроме того, старайтесь избегать других идентификационных признаков инструментов в запросах);
не используйте для дальнейшей активности IP-адреса (и подсети, и провайдера), задействованные во внешнем сканировании;
оставляйте как можно меньше следов, по которым ваши действия можно скоррелировать и отследить, — чистите куки, чередуйте разных провайдеров и т. д.
🔵 Tips & Tricks для «синих»:
детектируйте признаки работы утилит для сканирования портов и уязвимостей, а также отслеживайте другую активность на периметре, свидетельствующую о проведении внешней разведки (многочисленные попытки эксплуатации уязвимостей, переборы файлов и директорий, фаззинг и пр.);
обращайте внимание на признаки, характерные для целенаправленной активности, например на точечные попытки эксплуатации определенной уязвимости, а не массовое автоматизированное сканирование всего подряд;
выявив IP-адреса, которые атакующие использовали при разведке, не блокируйте их сразу: адреса они все равно оперативно поменяют, а вы лишитесь IoC, по которым могли бы вести наблюдение и фиксировать дальнейшую активность редтимеров 😊.
Анонимайзеры
Своевременное выявление следов компрометации часто превращается в нетривиальную задачу для blue team — особенно при грамотном подходе атакующих. Впрочем, иногда решение этой задачи удается свести… к нехитрому анализу подозрительных IP-адресов, взаимодействующих с внутренней инфраструктурой. Наиболее очевидный пример — вышеописанный кейс, когда «красные» использовали для коннекта к нашей сети адрес, ранее уже «засвеченный» при сканировании внешних ресурсов. Собирая сетевые индикаторы атакующих и ставя их на автоматический мониторинг, мы можем в разы ускорить обнаружение новой активности и упростить расследование. Конечно, справедливо будет заметить, что подобный трюк работает не всегда: осторожные атакующие могут регулярно «переключать» адреса. Но есть и другие, более устойчивые признаки «плохих» IP-адресов, с большой вероятностью указывающие на нелегитимное подключение.
Как правило, при любом взаимодействии с атакуемой инфраструктурой редтимеры используют различные средства анонимизации: прокси, VPN, Tor и пр. Полезно ли отслеживать подключения к внутренним ресурсам или входы в корпоративные сервисы с анонимных адресов? Однозначно да, так как это позволяет SOC моментально идентифицировать нелегитимное соединение: едва ли нормальный сотрудник пойдет в сеть своей компании через Tor или виртуалку в облаке.
Во многих случаях диапазоны IP-адресов известных VPN и прокси-сервисов легко доступны, как и адреса выходных нод Tor или облачных провайдеров. Следовательно, такая активность может успешно детектироваться автоматически за счет интеграции соответствующих фидов в средства мониторинга или применения полноценных TI-платформ. Существуют и еще более доступные способы отслеживания по косвенным, но вполне очевидным признакам. Простейший способ обнаружения аномальных подключений — обогащение геолокацией внешних IP-адресов с помощью GeoIP.
Используя VPN, Tor или другие средства анонимизации, атакующие нередко оставляют явный маркер в виде иностранной локации IP-адреса. Однако, учитывая увеличившееся во многих компаниях число сотрудников, работающих из-за рубежа, хорошей практикой является дополнительное профилирование подключений пользователей к корпоративным ресурсам. Если для каждой учетной записи на основе истории подключений будет сформирована модель поведения в виде связки «легитимные IP-адрес — локация», то коннекты из нестандартных локаций и с новых адресов будут детектироваться автоматически.
🔴 Tips & Tricks для «красных»:
не работайте через Tor, облачных провайдеров и известные прокси-серверы без крайней необходимости 😊;
используйте выделенные прокси и VPN с сервером в стране, подключение из которой не будет аномалией для целевой компании.
🔵 Tips & Tricks для «синих»:
обогащайте геолокацией логируемые внешние адреса;
настройте профилирование подключений из внешней сети к корпоративной инфраструктуре (VPN, RDG, корпоративные веб-сервисы);
обращайте внимание на случаи подключений из анонимизирующих сетей: с большой долей вероятности это нелегитимная активность (в общем случае входы с зарубежных IP-адресов, не соответствующих местоположению и не являющихся типичной активностью для учетной записи, также будут признаком компрометации).
Нестандартное поведение в инфраструктуре
В каждой организации существует целый комплекс процессов и правил, привязанных к различным областям ее внутренней деятельности. Они могут быть закреплены в официальных политиках и регламентах или вытекать из особенностей межкомандного взаимодействия и корпоративной культуры. Устройство внутренних процессов хорошо известно сотрудникам компании, но требует времени для изучения людьми извне. По этой причине внешние атакующие регулярно допускают ошибки, связанные с нетипичным (не соответствующим принятым процессам) поведением в инфраструктуре организации. Например, это часто встречается при проведении фишинговых рассылок.
Во время недавних киберучений команда красных пыталась проникнуть в нашу инфраструктуру при помощи фишинговой рассылки от имени Ярослава Бабина, CPO платформы Standoff 365. Сообщение касалось отсрочки от мобилизации. Атака не увенчалась успехом, поскольку почти все сотрудники, получившие письма, верно идентифицировали их как фишинг и сообщили о происходящем в корпоративный SOC. Главным образом атакующих подвело явное несоответствие контекста и отправителя. Отправителем подобной официальной рассылки мог бы быть сотрудник, рабочие процессы которого потенциально предполагают оформление отсрочек от мобилизации, но это точно не мог быть руководитель платформы Standoff 365!
Если команде атакующих хотелось сделать фишинг от лица Ярослава 😊, то им стоило бы придумать более правдоподобный сценарий — скажем, письмо, в котором он обращается с просьбой внутри компании или предупреждает о чем-нибудь как ответственный пользователь. Вероятно, это бы лучше соответствовало стандартным внутренним коммуникациям и вызвало бы меньше подозрений.
В целом любые серьезные отклонения от стандартной рабочей активности пользователя — триггер для SOC. Например, подозрение возникнет, если под учетной записью HR-специалиста будет зафиксирован вход в корпоративный GitLab, бухгалтер начнет удаленно подключаться через PsExec со своего узла или сотрудник АХО попытается получить доступ к внутренним сетевым ресурсам казначейства. К наиболее явным маркерам относятся входы под одной учетной записью с разных адресов или, наоборот, подключения с одного узла к нескольким учеткам. Примерьте на себя: как обычный пользователь, постоянно работающий из офиса, вы вряд ли можете логиниться с трех разных узлов за день или, находясь на удаленке, пытаться подключиться с того же IP-адреса, что и четверо ваших коллег. А вот не очень осторожные редтимеры, скомпрометировавшие ваши учетные данные, — вполне!
Нередко атакующие попадают в поле зрения синих команд из-за нестандартных (отличных от принятых в компании) наименований учетных записей или узлов. В нашей практике встречалось много разнообразных сценариев, в подавляющем большинстве связанных с тем, что редтимеры забывали изменить имена своих рабочих устройств. Дело в том, что локальный хостнейм может оставить множество следов, например в DHCP-трафике при запросе IP-адреса или в событиях аутентификации через NTLM. В частности, на наших прошлых киберучениях пентестеры не раз выдавали себя именами узлов вроде blackarch и parrot, а также хостнеймами, вероятно, сохранившимися от предыдущих работ с другими заказчиками.
🔴 Tips & Tricks для «красных»:
осмотритесь и действуйте в соответствии со сложившимися процессами🙂 (качественную мимикрию всегда трудно выявить);
придерживайтесь принятого в организации формата нейминга учетных записей пользователей, хостов и т. д.;
всегда подключайтесь к одной учетной записи с одного и того же адреса и не переиспользуйте его для других учеток;
старайтесь следовать профилю пользователя и не совершать явно нетипичных в рамках его рабочего процесса действий. Если без этого не обойтись, лучше действовать как можно медленнее и не создавать много подозрительной активности зараз: одно-два аномальных события blue team может и пропустить, а вот десяток за час точно привлечет их внимание.
🔵 Tips & Tricks для «синих»:
обращайте внимание на нетипичное в рамках стандартных рабочих процессов поведение пользователей: необычные перемещения внутри периметра, аномальные входы в приложения, входы с одного узла под разными пользовательскими учетными записями, входы с разных узлов под одной пользовательской учеткой и т. д.;
настройте профилирование подключений к критически важным активам и административным учетным записям;
используйте системы UEBA (либо их функциональность в других средствах мониторинга, например в SIEM- и NTA-системах) для автоматического детектирования аномалий в поведении пользователей.
Брутфорс и спреинг паролей
Традиционно популярный у red team начальный вектор атаки — это подбор учетных данных к сервисам на периметре целевой компании. Механика таких атак может варьироваться. Как показывает практика, «красные» чаще прибегают не к классическому подбору пароля, а к технике спреинга. Например, собрав из открытых источников имена корпоративных пользователей и проанализировав принятый в компании формат нейминга учетных записей, атакующие могут составить список потенциально валидных учеток и использовать его для последующего перебора во внешнем сервисе с доменной аутентификацией. В ряде случаев такому спреингу может предшествовать перечисление, чтобы заведомо отсеять несуществующих пользователей из получившегося списка. В перспективе спреинг паролей позволяет получить больше учетных записей и избежать блокировки подбираемых аккаунтов, поэтому зачастую он служит более эффективной альтернативой. Однако стандартные реализации обеих техник брутфорса обычно весьма «шумные» и моментально обнаруживаются blue team. Подходы к их детектированию схожи и в общем случае строятся на отслеживании множественных неуспешных попыток входа с одного IP-адреса за небольшой промежуток времени, для спреинга — под разными учетными записями.
И брутфорс пароля, и спреинг можно выявлять как на основе хостовой телеметрии, так и в сетевом трафике. Конечно, сложнее всего валидировать случаи, когда нам, специалистам SOC, доступны только сессии в шифрованном виде. Но даже тогда атаку можно определить по аномальным всплескам в трафике: обилие коротких частых сессий с одного адреса с одинаковым размером ответа сервера свидетельствует о том, что на ресурс, вероятно, идет атака перебором.
Конечно, атакующие непрерывно совершенствуют свои подходы и методы, изобретая новые либо модифицируя старые, хорошо известные и изученные blue team. Исключением не стали и переборные атаки, привычные реализации которых все чаще сменяются более эффективными в разрезе обхода обнаружения техниками — техниками медленного и распределенного перебора. Их сочетание дает атакующим возможность наиболее успешно обходить детекты и оставаться незаметными для SOC. Ротация IP-адресов и продолжительные задержки между попытками входа позволяют избежать превышения пороговых значений, заложенных в детектирующую логику, и замаскировать спреинг под не связанную между собой активность обычных пользователей. Для отслеживания таких атак необходим проактивный поиск признаков, идентифицирующих единый источник подозрительных попыток аутентификации. Скажем, общие для всех запросов значения определенных заголовков, например одинаковый User-Agent (скриншот ниже) или даже настоящий IP-адрес источника в X-Forwarded-For (однако не забываем, что иногда такие заголовки, используемые неанонимными прокси для отправки реального IP клиента, могут быть добавлены или модифицированы самими атакующими). По нашему опыту, «красные» регулярно забывают (или, возможно, ленятся 😊) ротировать подобные идентифицирующие свойства, ограничиваясь только сменой адресов и тем самым упрощая задачу blue team. Другими отличительными признаками могут служить общие характеристики задействованных в атаке IP. К примеру, используемые атакующими адреса часто относятся к одному и тому же региону или пулу адресов одного и того же хостинг-провайдера.
Нам встречались случаи, когда атакующих выдавали… используемые ими анонимайзеры, а вернее, недочеты в их настройках. На прошлых киберучениях мы столкнулись с неплохо подготовленной распределенной спреинг-атакой на один из наших ресурсов: задействованные IP-адреса ротировались на каждый новый запрос и использовались всего несколько раз за час, при этом частота обращений к ресурсу оставалась сравнительно невысокой, а промежуток времени между попытками входа в одну и ту же учетную запись cоставлял более 15 минут. В совокупности это позволяло «красным» успешно уклоняться от детектирования и не поднимать лишних алертов. Неизвестно, как скоро их активность была бы обнаружена, если бы не одна любопытная деталь: иногда несколько попыток входа подряд совершались с одного и того же фиксированного адреса, после чего брутфорс на какое-то время прекращался. Подобная ситуация повторялась не единожды: «проскакивал» тот самый IP, и после небольшой паузы атака возобновлялась в прежнем режиме. Примечательно, что данный адрес не был анонимным и принадлежал интернет-провайдеру, в то время как все остальные относились к пулу известного VPN.
Собственно, это и стало отправной точкой расследования: выявив с этого IP-адреса попытки подключения под разными учетками (как действующими, так и несуществующими), мы начали детально анализировать активность и в результате обнаружили характерные индикаторы — общие значения заголовка. По ним удалось отследить всю спреинг-атаку и установить единый источник нелегитимных сессий. Безусловно, подлинную причину происходившего знают только сами редтимеры, но можно уверенно предположить, что проблема была в некорректно настроенном VPN-шлюзе. Именно это повлекло утечку трафика при разрывах соединения и, как следствие, привело к раскрытию реального IP-адреса атакующих, а также поспособствовало тому, что защитники их быстро обнаружили.
🔴 Tips & Tricks для «красных»:
перебирайте учетные записи медленно и распределенно;
не ограничивайтесь ротацией IP-адресов при проведении распределенной атаки, меняйте и другие признаки (User-Agent, локацию и пр.), по которым можно сопоставить и отследить активность;
заранее проверяйте, правильно ли настроено применяемое средство анонимизации: необходимо убедиться, что при любых внеплановых потерях соединения (например, при отключении VPN) нелегитимный трафик не пойдет напрямую и ваш настоящий адрес не станет известен blue team.
🔵 Tips & Tricks для «синих»:
отслеживайте факты успешного подбора учетных данных: очень важно не только уметь детектировать попытки брутфорса, но и автоматически фиксировать случаи компрометации учетных записей, подобранных в результате атаки;
мониторьте попытки медленного и распределенного перебора: обычно такие атаки успешно обходят детектирующую логику и могут долго оставаться незаметными для защитников. Поэтому целесообразно отслеживать общие нестандартные паттерны (значения заголовков, локацию, провайдеры или autonomous system) в подозрительных попытках аутентификации и использовать их в качестве индикаторов для ретроспективного поиска, а также для создания автоматических алертов, чтобы отслеживать атаки и выявлять случаи успешного подбора учетных данных.
Оригинальные либо отсутствующие метаданные
Множество техник атакующих невозможно задетектировать лишь с помощью штатных средств аудита: необходимы более глубокие данные и дополнительные решения для мониторинга. В частности, одним из инструментов, помогающих блютимерам расширить покрытие и повысить содержательность узловой телеметрии, является утилита Sysmon из пакета Sysinternals. Для примера возьмем события создания процесса. По сравнению с нативным Windows Event ID 4688, Sysmon Event ID 1 предоставляет такую ценную для мониторинга информацию, как, например, хеш исполняемого файла, командную строку родительского процесса, GUID и, last but not least 😊, метаинформацию исполняемого файла процесса (описание, заданное разработчиком исходное имя, цифровую подпись и т. д.).
К сожалению, при расследовании инцидентов или разработке детектов защитники часто упускают из виду содержимое метаданных. К счастью, атакующие упускают его из виду не реже 🙂. Например, переименовывая для маскировки используемый в атаке инструмент под легитимный процесс, они забывают убрать оригинальные метаданные или записать фейковые значения, как у исполняемого файла, под который маскируются.
На скриншоте — яркий пример того, как забытая редтимерами метаинформация позволила нам распознать в ничем, казалось бы, не примечательном запуске wireshark.exe сбор данных через SharpHound и быстро обнаружить компрометацию актива.
Предвосхищая возможные вопросы, отмечу, что наши продукты PT Network Attack Discovery и MaxPatrol SIEM умеют детектировать активность коллектора BloodHound (как, кстати, и многих других часто применяемых в атаках утилит) не только за счет сигнатурных паттернов, но и исключительно по специфичному поведению инструмента. Но благодаря тому, что в этом случае исполняемый файл SharpHound был доставлен атакующими непосредственно на скомпрометированный узел, у нас была возможность отследить запуск процесса и весь сопутствующий контекст. Так что оплошность красной команды с метаданными облегчила нам задачу, позволив обойтись и без дополнительной верификации других срабатываний.
Аналогичный пример: неплохая попытка редтимеров пройти под радарами SOC, переименовав используемый инструментInternalMonologue в системный исполняемый файл tasklist.exe, увы, тоже не увенчалась успехом из-за все тех же оригинальных метаданных.
🔴 Tips & Tricks для «красных»:
очищайте исходные метаданные применяемого в атаках инструментария, но не оставляйте их пустыми — это тоже вызовет подозрение у SOC;
добавляйте такую же метаинформацию, как у ПО, под которое маскируетесь;
не забывайте про цифровые подписи ваших файлов: если у blue team настроены нужные параметры аудита, информация о их наличии и валидности также будет отражена в событиях Sysmon.
🔵 Tips & Tricks для «синих»:
при ручном поиске угроз и ретроанализе обязательно обращайте внимание на значения метаданных запущенных процессов, их несоответствие или отсутствие;
применяйте поля метаинформации в событиях Sysmon для автоматических детектов использования переименованных утилит;
детектируйте запуски процессов с отсутствующими или фейковыми метаданными.
Нестандартное расположение
Чтобы не бросаться в глаза blue team и спрятать свою активность, атакующие часто маскируют вредоносное ПО либо под системные файлы, либо под известные легитимные программы, например распространенные IT-утилиты или браузеры. На деле же это палка о двух концах: если скрывать применяемые инструменты под именами таких процессов, велика вероятность привлечь внимание SOC их нестандартным расположением:
Как правило, защитники пристально отслеживают добавление новых файлов в автозапуск, так как это излюбленная техника атакующих для закрепления в системе. Кроме того, они всегда обращают внимание на активность процессов, запущенных из общедоступных (то есть не требующих прав администратора для записи и выполнения исполняемых файлов) директорий. Поэтому svchost, conhost и другие «системные» процессы, вдруг запускающиеся из TEMP-папки или автозагрузки вместо своих стандартных путей, — аномалия и однозначный аларм для SOC. Одним словом, подобная мимикрия под процессы системы — не самый оптимальный вариант для red team. Другое дело — маскировка под что-то менее приметное:
Тут команда атакующих придумала хорошо хотя и потеряла букву, но не докрутила: все-таки Zabbix, работающие из временных директорий, слишком явно свидетельствуют о нелегитимном происхождении исполняемых файлов на узлах.
🔴 Tips & Tricks для «красных»:
скрывая свои инструменты под названиями других утилит и исполняемых файлов, не забывайте про маскировку их расположения.
🔵 Tips & Tricks для «синих»:
отслеживайте события запуска процессов из подозрительных каталогов, в которых легитимное ПО обычно не располагается;
детектируйте запуски стандартных утилит и системных процессов из нетипичных директорий.
Артефакты в командной строке
Отслеживание специфичных командных строк по-прежнему остается одним из самых популярных способов детектирования используемых в атаках инструментов. И не случайно: зачастую даже «замаскированную» утилиту можно легко идентифицировать по характерным ключам.
Думаю, выступающий под именем pd.exe ProcDump в представлении не нуждается: ключи известной утилиты для снятия дампов памяти процессов из набора Sysinternals, как и суть происходящего на скриншоте, хорошо известны многим (как минимум тем, кто интересовался способами сдампить LSASS).
Стоит сказать, что данный кейс может служить наглядным примером не самой идеальной с точки зрения обхода обнаружения техники: неудачная маскировка, «шумная» и узнаваемая командная строка и прямое обращение к памяти LSASS. Если на целевом хосте есть Sysmon, то доступ к памяти LSASS с большой вероятностью покрыт автоматическими детектами и мгновенно выявляется SOC за счет генерации события Sysmon EID 10 (ProcessAccess).
Параметры широко используемой в атаках LolBin-утилиты Certutil также многие «знают в лицо», поэтому наверняка распознали ее под маской notepad.exe. Хотя в целом данное событие должно было бы навести на размышления даже не знакомых с синтаксисом Certutil специалистов: запуск блокнота из командной строки с ключами, да еще и с URL в качестве аргумента однозначно выглядит оригинально подозрительно. Кстати, об URL: второй распространенный класс «флажков для SOC» в командлайне — это IP- и URL-параметры:
IP-адреса, URL и подобные параметры, в явном виде передающиеся в командной строке, — настоящий подарок для «синих». Во-первых, защитники получают индикаторы компрометации (IoC) для отслеживания атакующих и выявления других фактов компрометации в инфраструктуре. Во-вторых, по ним защитники могут идентифицировать назначение даже хорошо замаскированного или не известного им хакерского инструмента.
🔴 Tips & Tricks для «красных»:
по возможности избегайте использования узнаваемых ключей известных инструментов, IP и URL-параметров либо модифицируйте их исходный код (например, переименовывая ключи во что-то менее приметное или заранее «зашивая» их в исполняемый файл);
в крайнем случае применяйте обфускацию, но аккуратно, чтобы не быть обнаруженными из-за попытки обфускации, так как такие паттерны в командной строке тоже могут детектироваться.
🔵 Tips & Tricks для «синих»:
проводите тщательный анализ встреченных в командной строке IoC: IP или URL, подозрительных имен файлов, специфичных параметров распространенных утилит;
детектируйте использование популярных утилит (хакерский и околохакерский инструментарий, LolBins и др.) на основе характерных ключей и паттернов в командной строке. Чтобы забайпасить такую логику обнаружения, «красным» необходимо (если это возможно) или изменить их исходный код, или прибегнуть к более сложным техникам подмены параметров запуска, или вообще заменить их чем-то другим. Однако стоит помнить про возможности обхода таких правил и не пренебрегать поведенческими детектами.
Напоследок
Традиционные взгляды на кибербезопасность, как правило, постулируют фундаментальное преимущество атакующих перед защитниками. Attackers only need to be right once, defenders must be right all the time — хорошо известно каждому профильному специалисту. С одной стороны, поспорить с этим трудно: атакующим достаточно найти всего один вектор, одну брешь в системе защиты, чтобы успешно проникнуть в инфраструктуру. Но с другой, ведь верно и обратное: хакерам достаточно допустить одну ошибку, оставить один след, чтобы защитники смогли их обнаружить и не допустить дальнейшего развития атаки. Очевидно, что просто взлом не является самоцелью. И как перед редтимерами на киберучениях, так и перед реальными злоумышленниками всегда стоят конкретные задачи — скажем, вывод денег со счетов компании или кража конфиденциальных сведений. Да, предотвратить все сценарии взлома невозможно, но можно остановить атаку до того, как наступят критические для организации последствия и будет причинен серьезный ущерб. А при наличии эффективных средств защиты информации и детектирующих правил, при правильно выстроенных процессах мониторинга и реагирования большинство атак могут (и должны!) быть выявлены и сведены на нет на начальных этапах.
Надеюсь, эта статья помогла коллегам-защитникам расширить кругозор в области выявления атак и почерпнуть новые идеи для детектирования, специалистам red team — посмотреть на себя глазами SOC 🙂 и усовершенствовать техники уклонения от обнаружения. А всем читателям дала возможность окунуться в происходящее на киберучениях и по-новому взглянуть на особенности работы blue team.
В будущих статьях мы продолжим делиться историями с наших проектов red teaming и рассказывать о других ошибках нападающих, поэтому не прощаемся!
Екатерина Никулина
Специалист отдела мониторинга информационной безопасности, Positive Technologies
