🍁 Когда за окном холоднее, в Академии становится жарче — потому что осенью начинается новая волна курсов: от Пентеста и DevSecOps до Основ в ИБ и Цифровой Криминалистики.

Что мы предлагаем:

🎃 WAPT — веб-пентест с практикой, где вы не просто читаете про XSS — вы его находите.

Теперь ещё больше практики: +6 новых видео, +16 лабораторных и +15 экзаменационных заданий. Добавлена виртуалка для Mac M-чипов и улучшена стабильность лаборатории.

🎃 DevSecOps — системная безопасность CI/CD, облаков и контейнеров.

Старт первого потока — 10 ноября 2025 со скидкой 10%: 125 990 ₽ 113 391 ₽

🎃 Основы ИБ — идеальный старт, если вы только заходите в профессию, и хотите избежать хаоса.

Курс даст фундамент, с которого начинают карьеру в ИБ. Linux, сети, атаки, защита — всё, без чего не попасть в профессию. А первый поток — уже со скидкой!

И многое другое!

Все курсы включают:
🟧экспертную проверку заданий;
🟧доступ к виртуальным лабораториям;
🟧поддержку от преподавателей с опытом OSCP, CEH, CISSP;
🟧разборы атак и защитных мер, а на WAPT — живые вебинары с куратором!

Смотрите карту курсов ЗДЕСЬ
— и стройте свой путь: от основ до экспертизы.

И помните:
«Лучшее время начать было год назад. Второе лучшее — сейчас!»

Увидимся в лабораториях! 😎
🥇 @CodebyManagerBot

Исследователи из SpecterOps продемонстрировали инструменты для извлечения памяти процесса LSASS через протокол WMI. В данной статье приведены отличные от Win32_Process классы, позволяющие достичь той же функциональности.

1️⃣MSFT_MTProcess (CreateProcess)
Наиболее близкий к Win32_Process класс WMI. Win32_Process — это канонический пример горизонтального перемещения в WMI, и именно его в основном используют для этих целей.

В MSFT_MTProcess есть метод CreateProcess, который принимает аргумент командной строки, как и Win32_Process. Однако у этого класса есть существенный недостаток: он существует только в Windows Server 2016 и более поздних версиях. Это означает, что он недоступен на рабочих станциях, но вызовет выполнение данного двоичного файла, такого как Win32_Process.

2️⃣MSFT_MTProcess (CreateDump)
Вторым интересным методом для MSFT_MTProcess является CreateDump. Если необходимо удаленно/локально создать дамп процесса без добавления каких-либо новых инструментов, то можно использовать метод CreateDump.

Этот класс использует ту же технику, что и дамп через диспетчер задач (нажатие на процесс правой кнопкой мыши и создание дампа). Это загружает dbghelpd.dll и вызывает MiniDumpWriteDump в экземпляре процесса, который ему предоставляют. Однако цепочка выполнения процесса немного отличается. Вместо того, чтобы диспетчер задач загружал библиотеку DLL, тут уже есть процесс WmiPrvSE, который завершает загрузку и выполняет вызов функции.

⛏Инструменты
⏺️WMI_Proc_Dump.py — инструмент, использующий класс MSFT_MTProcess для удалённого дампа процесса при работе с Windows Server 2016 или более поздней версией. Он вызывает MSFT_MTProcess для дампа процесса, который автоматически записывается в C:\Windows\Temp\<Process_Name>.dmp.
Однако, если пользователь захочет переименовать это во что-то менее подозрительное, это можно сделать через CIM_DataFile.

python wmi-proc-dump.py user:pass@hostname -pid 580
python wmi-proc-dump.py user:pass@hostname -proc lsass.exe
python wmi-proc-dump.py user:pass@hostname -proc lsass.exe -rename chrome-debug.dmp

⏺️mtprocess.py - второй скрипт, реализующий метод CreateProcess класса MSFT_MTProcess. Кроме того, этот скрипт позволяет автоматически установить класс MSFT_MTProcess на рабочей станции.

python mtprocess.py -exec user:pass@hostname calc.exe
python mtprocess.py -exec -cimv2 user:pass@hostname calc.exe

DefectDojo — Платформа управления уязвимостями и DevSecOps

DefectDojo (django-DefectDojo) — это open-source решение для управления безопасностью приложений. Платформа объединяет сканеры, трекинг уязвимостей, автоматизацию, отчёты и аналитику на одной панели. Помогает командам DevSecOps, исследователям и инженерам безопасности управлять рисками, устранять дублирования и ускорять ответ на угрозы.

⚡️ Основные возможности DefectDojo
➡️ Импорт результатов от множества сканеров (SAST, DAST, SCA и др.).
➡️ Объединение и устранение дублирующихся уязвимостей (deduplication) и автоматическое подавление ложных срабатываний.
➡️ Модель «Продукт / Взаимодействие / Engagement» — позволяет отслеживать проект, период сканирования, сравнивать состояния, создавать отчёты по проектам и версиям.
➡️ Интеграции: с более чем 180 инструментами и платформами, включая Jira, репозитории кода, инструменты сканирования, LDAP, OAuth2/SAML и др.
➡️ Отчёты, метрики и визуализация — дашборды, метрики тенденций, отчёты для различных заинтересованных сторон.

⬇️ Установка и запуск
Клонируйте репозиторий:

git clone https://github.com/DefectDojo/django-DefectDojo.git
cd django-DefectDojo

Запуск через Docker Compose (предпочтительный вариант):

docker compose build
docker compose up -d

Администраторские учётные данные автоматически создаются через инициализатор.

⚙️ Преимущества DefectDojo
⏺️ Снижает ручную работу, помогая автоматизировать импорт, triage, отчёты.
⏺️ Централизует управление уязвимостями, предотвращает дубли и «шум» от одинаковых ошибок в разных сканах.
⏺️ Подходит как для малых команд, так и для крупных организаций, за счёт масштабируемости и множества интеграций.
⏺️ Прозрачность и видимость: дашборды, отчёты, метрики помогают донести состояние безопасности до руководства.

⚠️ Linux в опасности!

🐧 Агентство по кибербезопасности и защите инфраструктуры США (CISA) 29.09.2025 добавило в свой каталог (KEV) критическую уязвимость в Unix-системах, влияющую на утилиту командной строки Sudo, сославшись на свидетельства её активной эксплуатации.

❗️ Уязвимость имеет идентификатор CVE-2025-32463 с оценкой CVSS: 9.3, которая затрагивает версии Sudo до 1.9.17p1. Обнаружил её исследователь из Stratascale в июле 2025 года.

💻 По заявлению CISA, уязвимость в sudo позволяет злоумышленнику, получивший локальный доступ, использовать опцию sudo -R (—chroot) для запуска произвольных команд от имени пользователя root, даже если они не указаны в файле sudoers.

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

❓ А как вы планируете защищаться в данном случае?

Checkov: Статический анализатор безопасности IaC

Checkov — фреймворк с открытым исходным кодом от компании Bridgecrew, предназначенный для сканирования облачной инфраструктуры, описанной в виде кода, на предмет наличия ошибок конфигурации. Он анализирует ваши шаблоны Terraform, CloudFormation, Kubernetes манифесты, конфигурации Helm и другие файлы IaC, проверяя их на соответствие сотням предопределенных политик. Эти политики основаны на практиках от облачных провайдеров (AWS, Azure, GCP) и стандартов безопасности (CIS Benchmarks).

🔜 Что умеет?
- Находит уязвимости до того, как инфраструктура будет развернута, следуя принципу «Shift Left» в безопасности.
- Поддерживает все основные облачные платформы.
- Работает с Terraform, CloudFormation, Kubernetes, ARM Templates, Dockerfile и многими другими.
- Позволяет создавать собственные пользовательские политики на простом языке Python.

🟣Установка
Самый быстрый способ — использовать менеджер пакетов pipх.

pipx install checkov

🟣Проверка

checkov -h

🟣Базовое использование
У вас есть директория с файлами Terraform (.tf). Просканируем ее:

checkov -d /path/to/your/terraform/code

Checkov рекурсивно просканирует все файлы в указанной директории, определит их тип и запустит соответствующие проверки.

🟣Сканирование конкретного файла
Проверим конкретный файл, например, манифест Kubernetes:

checkov -f deployment.yaml

🟣Интеграция в CI/CD
Сила Checkov раскрывается при его интеграции в конвейер непрерывной интеграции и доставки (CI/CD). Например, в GitHub Actions это можно сделать так:

name: "Security Scan"
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  checkov:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: .
          framework: terraform  #можно указать конкретный фреймворк

Это гарантирует, что каждый

Pull Request

будет автоматически проверен на соответствие стандартам безопасности.

🎃Друзья, напоминаем, на каких курсах начинается обучение в октябре, выбирайте направление и присоединяйтесь!🟧

Старт 2 октября:
🟧 Курс «Тестирование Веб-приложений на проникновение (WAPT)» — отработаем полный цикл тестирования: от разведки до пост-эксплуатации.

Старт 9 октября:
🟧 Курс «Основы программирования на Python» — овладеем самым попуярным ЯП за 2 месяца.

Старт 13 октября:
🟧Курс «Цифровая криминалистика и реагирование на инциденты ОС Linux (DFIR)» — ищем и анализируем следы кибервзломов (анализ артефактов, работа с opensource инструментами).

Старт 20 октября:
🟧 Курс «Специалист центра мониторинга инцидентов информационной безопасности (SOC)» — освоите полный цикл работы: от обнаружения киберугроз до расследования инцидентов.
🟧Курс «OSINT: технология боевой разведки» — освоим профессиональный поиск информации и анализ данные из открытых источников.
🟧 Курс «Анализ защищенности приложений Андроид» — изучим этапы создания мобильного приложения, приемы реверса и возможные уязвимости.

🟧Запишитесь у нашего менеджера @CodebyManagerBot

Или узнайте подробности и программы курсов — на нашем 🟧сайт

🍺 Пиво в Японии - В С Ё!

🇯🇵 Хакеры остановили производство на крупнейшем пивоваренном заводе в Японии.

🏭 Крупнейший производитель пива в Японии Asahi Group заявил, что приостановил заказы и доставку продукции в стране после того, как кибератака привела к остановке его производственных операций.

❌ По данным информационного агентства, компания, выпускающая пиво Asahi Super Dry Beer и виски Nikka, а также ряд безалкогольных напитков, заявила, что не может предсказать, когда возобновится производство.

❗️ Об атаке впервые стало известно 29.09, когда компания Asahi опубликовала заявление, в котором говорилось, что операции по заказу и доставке в ее японских компаниях, а также услуги колл-центра были приостановлены «из-за сбоя системы»

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

🟧Сдвиг безопасности влево (Shift Security Left)
Практика предполагает интеграцию инструментов безопасности на начальных этапах разработки. Статический анализ безопасности приложений (SAST) выявляет уязвимости (например, SQL-инъекции) непосредственно в исходном коде, а анализ компонентов ПО (SCA) проверяет сторонние библиотеки на известные уязвимости до сборки артефакта.

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

🟧Автоматизация процессов безопасности (Automate Security Processes)
Для соответствия скорости CI/CD-пайплайнов необходима полная автоматизация проверок. Интеграция сканирования инфраструктуры как код (IaC) на этапе планирования развертывания предотвращает создание небезопасно сконфигурированных ресурсов. Автоматическое обнаружение секретов в каждом коммите минимизирует риски утечки учетных данных.

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

🟧Приоритизация на основе рисков (Risk-Based Prioritization)
В условиях ограниченных ресурсов важно фокусироваться на наиболее значимых угрозах. Использование метрик EPSS позволяет оценить вероятность эксплуатации уязвимости, а анализ достижимости определяет возможность активации уязвимого кода в рабочей среде.
Например, уязвимость в недоступном извне административном интерфейсе будет иметь более низкий приоритет по сравнению с уязвимостью на публичной странице аутентификации.

Это позволяет командам оптимально распределять усилия по устранению недостатков.

🟧Автоматическая защита секретов (Automated Secrets Management)
Проактивное управление секретами включает сканирование репозиториев на наличие учетных данных и их автоматический отзыв.

Например, интеграция с системами типа

HashiCorp Vault

позволяет не только выявить случайно закоммиченный токен

API

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

🟧Контроль безопасности инфраструктуры как код (IaC Security)
Безопасность инфраструктуры должна проверяться на стадии разработки конфигураций. Сканирование шаблонов Terraform или Kubernetes выявляет мисконфигурации, такие как: излишне разрешительные политики безопасности или нешифруемые хранилища данных.

Исправление ошибок на этапе кода предотвращает создание уязвимых сред и обеспечивает соответствие стандартам комплаенс.

🟧Формирование культуры безопасности (Cultivating a Security-First Culture)
Успех DevSecOps зависит от вовлеченности всей команды. Регулярные тренировки по безопасному программированию, внедрение практик code review с фокусом на безопасность и предоставление разработчикам оперативной обратной связи через инструменты способствуют повышению коллективной ответственности.

Когда разработчик сразу видит результаты проверки

SAST

, это ускоряет внедрение лучших практик безопасности.

🟧Повышение видимости с помощью дашбордов и отчетности (Enhanced Visibility and Reporting)
Централизованные дашборды обеспечивают единую точку мониторинга метрик безопасности для всех стейкхолдеров. Например, они могут отображать динамику обнаружения уязвимостей, их критичность и скорость устранения.

Интеграция с системами управления задачами (

Jira

) автоматизирует создание тикетов на исправление, обеспечивая прозрачность процесса управления рисками.

🟧Непрерывный мониторинг пайплайнов (Continuous Pipeline Monitoring)
Практика направлена на обнаружение аномалий в процессах CI/CD. Мониторинг на основе поведенческого анализа выявляет подозрительную активность, например, запуск сборок из неавторизованных источников.

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

☎️ Хакеры обманом заставляют загружать вредоносную версию Microsoft Team

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

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

🎩 Компания Blackpoint выявила новую волну атак, при которой пользователи, ищущие «скачать Microsoft Teams», видят вредоносную рекламу, перенаправляющую их на поддельные веб-сайты. Пользователи переходили на "teams-install[.]top", в котором располагался вредоносный файл "MSTeamsSetup.exe"

✍️ Чтобы выглядеть как настоящие, эти поддельные установщики часто подписываются ненадёжными цифровыми сертификатами от таких эмитентов, как «4th State Oy» и «NRM NETWORK RISK MANAGEMENT INC.». Этот приём помогает обойти базовые проверки безопасности, которые выявляют неподписанное ПО.

📌 ВПО помещала в папку %APPDATA%\\Roaming зараженный DDL с именем CaptureService.dll и тем самым обеспечивала закрепление в инфраструктуре жертвы.

🔐 Данный комплекс вредоносной активности назвали бэкдор Oyster, который обеспечивал удаленный доступ и взаимодействие с C2-сервером. В ходе анализа были выявлены такие индикаторы компрометации, как nickbush24[.]com и techwisenetwork[.]com.

⚠️ Будьте внимательны и проверяйте, какие ресурсы посещаете.

Скучали по неформальным встречам? Тогда вам на Security DrinkUp 15 октября от Авито! ☄️

Некоторые из тем, которые будут там обсуждать в неформальной обстановке:

➡️ WAF или POH? Стоит ли WAF своих денег;
➡️ Нужны ли «апруверы» в заказе доступов;
➡️ DLP: фикция или реальное средство защиты данных организации;
➡️ AI в безопасности и безопасность в AI.

Будет ли что-то кроме дискуссий?

Конечно! Можно будет сыграть в кастомную настолку «Киберлабиринт» и максимально продуктивно понетворкать.

Так что если давно искали, как познакомиться поближе с комьюнити — велком по ссылке на регистрацию!

Исследователь из команды Google Project Zero детально описал новый метод удаленной утечки адресов памяти в операционных системах macOS и iOS. Этот подход позволяет обойти ключевую технологию безопасности — рандомизацию макета адресного пространства (ASLR), — не используя традиционные уязвимости повреждения памяти или атаки по боковым каналам, основанные на времени.

🟧 История открытия
Исследование было инициировано в 2024 году в рамках внутренней дискуссии в Project Zero о поиске новых способов удаленного обхода ASLR на устройствах Apple. Хотя в ходе работы не была выявлена конкретная уязвимая система или приложение в реальном мире, исследователь создал работающий прототип (proof-of-concept) на основе искусственного тестового случая с использованием фреймворка сериализации NSKeyedArchiver в macOS.

Полученные выводы были ответственно раскрыты компании Apple, которая изучила проблему и устранила ее в своих обновлениях безопасности, выпущенных 31 марта 2025 года.

🟧 Механизм атаки
В основе техники лежит предсказуемое поведение процессов сериализации и внутренняя работа объектов NSDictionary (которые, по сути, являются хэш-таблицами) в среде Apple.

Цель атаки

— утечка адреса памяти системного синглтона (уникального объекта)

NSNull

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

ASLR

для общей области памяти (кэша), в которой он находится.

🟧 Процесс атаки имеет несколько этапов:
🟧Злоумышленник создает сериализованный объект NSDictionary. Этот словарь содержит комбинацию ключей NSNumber (хэш-значения которых можно контролировать) и один ключ NSNull.
🟧Ключи NSNumber подбираются таким образом, чтобы они заняли конкретные «сегменты» (bucket) внутри хэш-таблицы, создавая заранее известную схему заполненных и пустых слотов.
🟧Приложение-жертва десериализирует присланный объект, создавая его копию в своей памяти. Когда это приложение повторно сериализирует объект (например, чтобы отправить его обратно), оно перебирает сегменты хэш-таблицы в предсказуемом порядке.
🟧Позиция, которую ключ NSNull занимает в возвращенных сериализованных данных, указывает на тот сегмент хэш-таблицы, в который он был помещен. Это раскрывает частичную информацию о его адресе в памяти, а именно результат вычисления адрес modulo размер_таблицы.
🟧Для реконструкции полного 64-битного адреса памяти в этой технике применяется китайская теорема об остатках. Злоумышленник отправляет жертве множество словарей разного размера (каждый — с разным простым числом сегментов). Это позволяет собрать несколько различных «остатков» от адреса.

Комбинируя эти результаты, можно вычислить точное местоположение синглтона

NSNull

в памяти, что эффективно обходит защиту

ASLR

для этой области.

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

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

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