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

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

В ходе мониторинга угроз ИБ в мае 2020 года эксперты Positive Technologies обнаружили несколько новых образцов вредоносного ПО (ВПО). На первый взгляд их следовало отнести к группе Higaisa, однако подробный анализ показал, что связывать эти вредоносы следует с группой Winnti (также известной как APT41, по данным FireEye). 

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

2020 год. Повсюду карантин. И эта статья тоже про карантин, но он другого рода.

Я расскажу об экспериментах с карантином для динамической памяти ядра Linux. Это механизм безопасности, противодействующий использованию памяти после освобождения (use-after-free или UAF) в ядре Linux. Я также подведу итоги обсуждения моей патч-серии в списке рассылки ядра (Linux Kernel Mailing List, LKML).

Опыт участия команды в киберполигоне The Standoff на стороне защиты.

Привет, меня зовут Антон Калинин, я руководитель группы аналитиков центра мониторинга информационной безопасности и реагирования на компьютерные инциденты CyberART, ГК Innostage. Этой осенью мы принимали участие в киберучениях The Standoff в качестве Blue Team. Для нашего SOC это стало одним из самых интересных событий года, по горячим следам мы уже проделали много чего внутри нашего центра, теперь же хочется делиться опытом с более широкой аудиторией. Кому более комфортно не читать, а смотреть (или слушать), в конце статьи кину ссылку на вебинар на ютубе, который мы провели неделю назад.

Привет! Меня зовут Тимур Гильмуллин, я работаю в отделе технологий и процессов разработки Positive Technologies. Неформально наш отдел называют DevOps-отделом, мы занимаемся автоматизацией различных процессов и помогаем разработчикам и тестировщикам в нашей компании.

Я и мой коллега Дима Рагулин хотим рассказать, как инженеры нашего отдела внедряли сканер кода PT Application Inspector (PT AI) в сборочные процессы продуктовых команд внутри компании. Отмечу, что статья про архитектуру и интеграцию PT AI в CI, а не про работу с этим инструментом и не про поиск уязвимостей. Подробнее о функциональных возможностях PT AI вы можете узнать из вебинара.

Статья состоит из двух частей. В первой части расскажем, какое место PT AI занимает в наших технологических цепочках, дадим рекомендации по возможной архитектуре его внедрения в CI-конвейер. Это будет полезно DevOps-архитекторам и специалистам по внедрению решений в области безопасной разработки (DevSecOps). Вторая часть посвящена практическому внедрению PT AI в наш корпоративный CI-конвейер: в ней мы поделимся наработками своих шаблонов и скриптов, а также покажем, как можно подключить сканирование через PT AI в пару строчек кода. Это может быть интересно инженерам, перед которыми встали вопросы внедрения PT AI внутри уже сложившихся инфраструктуры и процессов разработки.

С 12 по 17 ноября 2020 года на киберполигоне The Standoff прошла крупнейшая битва между командами атакующих и защитников. Действия разворачивались в течение 123 часов в городе FF — цифровом двойнике мегаполиса с характерной инфраструктурой: морским портом, аэропортом, нефтяным месторождением, деловым центром, парком развлечений и другими объектами.



Двадцать девять команд атаковали инфраструктуру, добиваясь реализации бизнес-рисков, опасных для различных компаний, работающих в городе, а другие шесть команд мониторили и изучали активность нападающих, тренировали навыки противодействия и расследования инцидентов. В общем, все как в жизни. Хотя кроме нападающих и обороняющихся была еще третья сторона, которая пристально наблюдала за их действиями, — глобальный SOC (подробнее о нем читайте в другой нашей статье). Прозванный Большим Братом, SOC объединил несколько команд PT Expert Security Center, которые в режиме нон-стоп анализировали события при помощи специальных средств защиты. Одной из таких команд был отдел обнаружения вредоносного ПО, который с помощью песочницы PT Sandbox вылавливал и исследовал троянские программы «редтимеров». Напомним, PT Sandbox может:

• сканировать файл правилами PT ESC,
• сканировать файл движками внешних антивирусных вендоров,
• обнаруживать вредоносную активность после запуска в изолированной среде поведенческими правилами,
• анализировать сетевой трафик правилами PT Network Attack Discovery,
• анализировать дампы процессов правилами PT ESC.

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

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

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

…или как хакеры ломали наш опенсорс платежный процессинг в кибергороде.

Привет! Мы тут недавно с процессингом RBK.money приняли активное участие в киберполигоне The Standoff — это когда делают виртуальную модель целого мегаполиса со всей его инфраструктурой, энергостанциями, магазинами и прочими важными элементами. А потом пускают в этот цифровой двойник города команды blue team (6 команд в этом году) и red team (29 команд в этом году соответственно), первая защищает всю эту инфраструктуру, вторая же активно пытается что-то сломать.


из к/ф “Бегущий по лезвию 2049”

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

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

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

Экспертный центр безопасности Positive Technologies (PT Expert Security Center, PT ESC) расследовал кибератаку вируса-шифровальщика на инфраструктуру одного СМИ, вернул доступ к данным, выявил двухлетнюю деятельность известной АРТ-группировки (предположительно с азиатскими корнями) и пресек ее.

Полная версия расследования представлена по ссылке, а в этой статье мы поделимся его главными фактами.

В 2012 году мы начали делать новый большой продукт, призванный сменить MaxPatrol 8. Внутри компании он получил прозвище MaxPatrol X. К тому времени у нас сложилось понимание, что сделать качественно новый продукт можно только полностью поменяв подход к решению задачи. Подход был связан с идеями полномасштабного сбора и анализа информации обо всем происходящем в IT-инфраструктуре (анализ конфигурации узлов, конфигурации сети, анализ происходящего в сети — то есть анализ трафика — и на узле — то есть анализ логов). Из необходимости собирать и анализировать логи, собственно, и родился SIEM. К пятилетию MaxPatrol SIEM, который вышел на рынок в 2015 году, мы решили рассказать историю разработки.

В ходе одного из проектов в 2013 году стали вырисовываться принципы необходимой нам архитектуры обработки данных. Сбор, нормализация, корреляция, хранение. В качестве базиса для нормализации избрали подход MITRE CEE (subject — action — object — state), который в то время казался очень правильным и интересным. Но будущее показало, что реальные события не всегда идеально ложатся в прокрустово ложе академического подхода CEE.

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

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

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

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

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

На проектах по анализу защищенности корпоративных информационных систем в 2019 году нашим пентестерам удалось преодолеть сетевой периметр 93% компаний. При этом в сеть 50% компаний можно было проникнуть всего за один шаг. Чтобы не дать реальным атакующим достичь цели, важно вовремя выявлять их активность. Один из критически важных этапов атаки — перемещение внутри периметра (lateral movement), когда злоумышленники расширяют свое присутствие в сети.

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

В марте 2020, в рамках исследования угроз информационной безопасности, специалисты PT Expert Security Center обнаружили неизвестный ранее бэкдор и назвали его xDll, по оригинальному названию в коде. Из-за ошибки конфигурации контрольного сервера некоторые из директорий стали доступны извне. 

На сервере были обнаружены новые образцы вредоносного ПО, включая бэкдор Shadowpad, бэкдор xDll, неизвестный ранее Python-бэкдор, утилиты для развития атаки и т.д. Именно Shadowpad позволил связать новый бэкдор и обнаруженные инструменты с кибергруппировкой Winnti и проанализировать возможную связь этой группы с другими масштабными кибератаками.

Полная версия исследования доступна по ссылке, а в этой статье мы перечислим главные факты и выводы.

Объем трафика в интернете растет (особенно в последние месяцы, когда мы все оказались на удаленке и многие перевели свои активности в онлайн). Увеличивается и число автоматических средств взаимодействия с контентом на веб-сайтах и, как следствие, все большую актуальность получает фильтрация нежелательной автоматизированной активности. Сегодня до 50% интернет-активности генерится автоматически с помощью так называемых веб-ботов (или просто ботов). И в данном случае речь о любой активной в сети программе, вне зависимости от целей ее использования. Обычно такие программы выполняют повторяющиеся, простые в автоматизации действия. Например, поисковые движки Google или Yandex используют краулеры для периодического сбора контента и индексации страниц в интернете.

Итак, есть два типа веб-ботов — легитимные и зловредные. К легитимным можно отнести поисковые движки, RSS-ридеры. Примеры зловредных веб-ботов ― сканеры уязвимостей, скрейперы, спамеры, боты для DDoS-атак, трояны для мошенничества с платежными картами. После определения типа веб-бота к нему могут быть применены различные политики. Если бот легитимный, можно уменьшить приоритет его запросов к серверу или снизить уровень доступа к определенным ресурсам. Если бот определен как зловредный, можно его заблокировать или отправить в песочницу для дальнейшего анализа. Обнаруживать, анализировать и классифицировать веб-боты важно, так как они могут нанести вред: например, вызвать утечку важных для бизнеса данных. А также это снизит нагрузку на сервер и сократит так называемый шум в трафике, ведь до 66% трафика веб-ботов — это именно зловредный трафик.

Эта статья — завершение цикла материалов (первая часть, вторая часть), посвященного синтаксису Sigma-правил. Ранее мы рассмотрели пример простого Sigma-правила и подробно описали самые важные части правила — секцию описания источников событий и секцию описания логики детектирования. Теперь у нас есть почти все знания, которые могут понадобиться при написании и разборе Sigma-правил любой сложности. Нам осталось лишь рассмотреть атрибуты, содержащие метаинформацию, и разобраться, что такое коллекции правил и как с ними работать. Именно этим вопросам посвящена заключительная часть цикла.

Сфера информационной безопасности богата на разные специальности, а сами специалисты сегодня остро востребованы на рынке труда. Если попытаться не задумываясь прикинуть пять направлений деятельности, которые относятся к ИБ, то мне на ум приходят такие: администратор ИБ, аналитик SOC (security operation center), пентестер или специалист по анализу защищенности, инженер по ИБ, оператор систем защиты. Но, как и в любой другой сфере, в ИБ возникают направления деятельности, которые находятся на стыке специальностей. Одно из таких направлений образовалось в свое время в Positive Technologies — аналитика информационной безопасности.

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

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

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

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

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

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

В следующей публикации мы подробно остановимся на описании метаинформации (атрибуты, которые имеют информативный или инфраструктурный характер, такие, например, как описание или идентификатор) и коллекций правил. Следите за нашими публикациями!