Приветствую,

Вам когда-нибудь хотелось узнать, как же именно работает программа, которой вы так активно пользуетесь, игра, в которую часто играете, прошивка какого-нибудь устройства, которое что-то делает по расписанию? Если да, то для этого вам потребуется дизассемблер. А лучше — декомпилятор. И если с x86-x64, Java, Python ситуация известная: этих ваших дизассемблеров и декомпиляторов полным-полно, то с другими языками всё обстоит немного сложнее: поисковые машины уверенно утверждают — «It's impossible».

Что ж, мы решили оспорить данное утверждение и произвести декомпиляцию NodeJS, а именно выхлоп, который выдаёт npm-пакет bytenode. Об этом подробнее мы и расскажем по ходу статьи. Заметим, что это уже вторая статья в серии о нашем плагине для Ghidra (первый материал был также опубликован в нашем блоге на Хабре). Поехали.

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

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

Для решения этой проблемы хакеры используют техники упаковки, шифрования и мутации кода. Такие техники часто реализуют отдельные инструменты — «крипторы» (crypters) или просто «пакеры». В этой статье на примере банковского трояна RTM мы рассмотрим, какие «пакеры» могут использовать злоумышленники и как эти «пакеры» осложняют обнаружение ВПО.

Полная версия данного исследования доступна по ссылке.

«Да я роботов по приколу изобретаю!» Рик Санчес

Многим известно, что в 2019 году АНБ решило предоставить открытый доступ к своей утилите для дизассемблирования (реверс-инжиниринга) под названием Ghidra. Эта утилита стала популярной в среде исследователей благодаря высокой «всеядности». Данный материал открывает цикл статей, посвященных плагину ghidra_nodejs для Ghidra, разработанному нашей командой (https://github.com/PositiveTechnologies/ghidra_nodejs). Задача плагина — десериализовать содержимое jsc-файлов, дизассемблировать байткод функций и декомпилировать их. В первой статье мы обсудим сущности и байткод движка V8, а также тезисно опишем сам плагин, про который подробно расскажем в последующих статьях.

Рано или поздно все сталкиваются с программами на языке JavaScript, их так и называют скриптами. JavaScript — это полноценный язык со своим стандартом ECMA Script, скрипты которого выполняются не только в браузере, но и на сервере.

Скрипты исполняются с помощью специальной программы, которую называют движком (engine) JavaScript. За годы движкостроения их понапридумывали предостаточно: V8, SpiderMonkey, Chakra, Rhino, KJS, Nashorn и т. д.

По данным Positive Technologies, 42% кибератак на компании совершаются с целью получения прямой финансовой выгоды. Выявить атаку можно на разных ее этапах — от проникновения в сеть и до того момента, когда хакеры приступят к выводу денег. Разбираем, как распознать злоумышленников на каждом из этапов и свести риски к минимуму.

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

На прошедшем The Standoff эксперты PT Expert Security Center, в данном случае представляющие команду глобального SOC киберполигона, мониторили действия команд атакующих и защитников цифровой копии мегаполиса FF, противостояние проходило в режиме реального времени и длилось 123 часа. Ранее мы писали о том, как глобальный SOC следил за всем происходящим в инфраструктуре виртуального города, как отдел обнаружения вредоносного ПО вылавливал и исследовал троянские программы «редтимеров» с помощью песочницы PT Sandbox и как мы следили за всеми веб-ресурсами киберполигона с помощью PT Application Firewall. Теперь поговорим о защищенности технологических сетей объектов виртуального города и результатах мониторинга, проведенного с помощью системы глубокого анализа технологического трафика PT Industrial Security Incident Manager (PT ISIM).

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

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

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

На прошедшем 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. На основании этого документа стали проводиться аудиты для выявления несоответствий. Вот только аудиты эти помогали убедиться, что системы обеспечения информационной безопасности в компании соответствуют установленным на бумаге (в политиках, регламентах) требованиям, а не защищают от реальных киберугроз. Причем сама проверка проводилась преимущественно в форме опроса сотрудников.

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

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