🎣 Как пентестеры находят пароли раньше, чем запускают первый эксплойт

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

🔍 Первые 30 минут внутреннего пентеста обычно уходят на пассивную разведку. Запускаешь tcpdump, пишешь трафик в pcap-файл, открываешь в Wireshark — и уже знаешь структуру сети лучше, чем из любого скана. Видно всё: какие VLAN есть, где принтеры с веб-интерфейсом на голом HTTP, кто ходит на внутренний портал без шифрования, какие broadcast-протоколы выдают имена хостов.

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

⚡️ Почему ARP так легко атаковать? Протокол не имеет встроенной аутентификации. Любой хост может отправить gratuitous ARP-ответ и заявить: «MAC-адрес шлюза — это я». Жертва обновит ARP-кеш и начнёт слать пакеты атакующему. Коммутатор по CAM-таблице доставит их куда надо. Весь трафик теперь проходит через нас — читаем, записываем, при необходимости модифицируем, пересылаем дальше. Жертва ничего не замечает.

🛠 Три инструмента покрывают большинство сценариев:

• tcpdump — захват на удалённых машинах без GUI, первый выбор при SSH-доступе к серверу
• Wireshark — визуальный разбор дампов, мощные фильтры, анализ сессий
• Ettercap — ARP spoofing в лабораторных условиях, перехват и модификация трафика на лету

Важный момент, который часто упускают: перед ARP-атакой обязательно включи IP forwarding командой echo 1 > /proc/sys/net/ipv4/ip_forward. Без этого трафик жертвы просто утонет на твоём интерфейсе — соединение оборвётся, жертва всё поймёт.

Отдельно стоит сказать про лабораторную среду. ARP spoofing в продакшн-сети без письменного разрешения — уголовная статья. «Я просто учился» суд не убедит. Поднимите три VM в VirtualBox с Internal Network: атакующий, жертва, шлюз. Изолированный L2-сегмент отлично имитирует плоскую корпоративную сеть, и никто не пострадает.

💡 Контринтуитивный вывод: шифрование не спасает само по себе. MITM-позиция открывает возможность для SSL stripping, подмены сертификатов и атак на протоколы согласования. HTTPS без HSTS и certificate pinning — не такая уж надёжная защита, как кажется.

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

https://codeby.net/threads/sniffing-trafika-i-mitm-ataki-wireshark-tcpdump-i-ettercap-v-real-nykh-stsenariyakh.92857/

🐧 Linux EDR не видит тебя — если знать, куда смотреть

На Windows обход защиты давно каталогизирован: ntdll-хуки, ETW-провайдеры, kernel callbacks. На Linux всё иначе. Каждый EDR-агент использует свой источник телеметрии, и у каждого — свои слепые зоны.

По данным CrowdStrike 2025 Global Threat Report, 82% детектов приходятся на malware-free активность — credential theft, living-off-the-land, identity-based атаки. Именно это Linux EDR отслеживает хуже всего. А готовые bypass-инструменты для Linux уже продаются на подпольных форумах от $300.

🔍 Что именно перехватывает агент

Телеметрия на Linux собирается тремя способами:

• auditd — старый и совместимый, но работает как очередь. Если на хосте уже крутится compliance-система, EDR конкурирует за тот же поток событий. Часть syscall'ов просто не попадает в телеметрию.

• eBPF-сенсоры — современный подход. Агент цепляет kprobes и tracepoints к kernel-функциям. Но для работы BTF и CO-RE нужен kernel, собранный с CONFIG_DEBUG_INFO_BTF=y. На RHEL 7 и CentOS 7 этого нет — и там eBPF-сенсор попросту не запустится.

• Kernel-модули — максимальная видимость, но жёсткая привязка к версии ядра и дистрибутиву.

Первый шаг на любом engagement'е — понять, какой из трёх механизмов используется. От этого зависит всё остальное.

⚙️ Прямые syscall'ы: обходим glibc-хуки

Большинство программ вызывают syscall'ы через обёртки glibc. Часть EDR-агентов ставит uprobes именно на эти обёртки или использует LD_PRELOAD. Если вызвать syscall напрямую через asm volatile("syscall"), минуя __libc_execve, — такой агент ничего не увидит.

На Linux номера syscall'ов стабильны между версиями ядра одной архитектуры. Таблица лежит в arch/x86/entry/syscalls/syscall_64.tbl и практически не меняется. Никакой SysWhispers не нужен.

Что это не обходит: kprobes на kernel-стороне, auditd с правилом -a always,exit -F arch=b64 -S execve, seccomp-BPF фильтры. Они работают на уровне входа в ядро, до любого dispatch'а.

🕳 io_uring: слепая зона другого масштаба

io_uring — асинхронный интерфейс ввода-вывода, появившийся в ядре 5.1. Операции выполняются в ядре через разделяемые кольцевые буферы, без традиционных syscall'ов на каждую операцию. Большинство eBPF-сенсоров и auditd просто не видят эти операции — они не проходят через стандартные точки перехвата.

Исследователи из ARMO показали, что через io_uring можно открывать файлы, читать данные и устанавливать соединения, не генерируя ни одного события в auditd. Falco и Tracee на момент публикации исследования не детектировали этот вектор.

Полная разбивка по всем трём векторам — с механикой eBPF-атак и практическими примерами для пентеста — в статье на форуме.

https://codeby.net/threads/obkhod-edr-linux-syscall-evasion-io_uring-i-ebpf-ataki-dlya-pentesterov.92859/

🚨 47 алертов, тимлид ушёл, а ты один

Именно так выглядит первая смена в SOC для большинства. 23:00, три монитора с дашбордами Splunk, очередь из алертов и полное ощущение, что ты не туда попал. Через три месяца после такого старта можно триажить 80+ алертов за смену и писать корреляционные правила. Вопрос только в том, какой маршрут выбрать.

📊 Начнём с масштаба задачи. По данным Ponemon Institute, средний SOC получает около 10 000 алертов в сутки. Большинство из них — ложные срабатывания: легитимный сканер, похожий на разведку, или пользователь, трижды промахнувшийся по паролю. Работа L1-аналитика — не знать всё на свете, а выстроить дисциплинированный процесс: открыл алерт, проверил контекст, принял решение. Всё.

Карьера в SOC строится по трём уровням, и понимание этой иерархии определяет твой учебный план.

L1 — триаж и первая линия. Разгребаешь поток из SIEM, отделяешь реальные угрозы от шума, эскалируешь наверх. Срок на позиции — от полугода до двух лет. Именно здесь появляется «чутьё на аномалию» — оно не читается из книг, а приходит после пятисотого алерта, когда глаз сам цепляется за нетипичный паттерн.

L2 — расследование инцидентов. Строишь таймлайн атаки, ищешь IoC по всей инфраструктуре, маппишь артефакты на MITRE ATT&CK. Начинается форензика — дампы памяти, артефакты файловой системы, корреляция логов.

L3 — threat hunting. Проактивный поиск угроз, которые ещё не вызвали ни одного алерта. Формулируешь гипотезу и проверяешь её по телеметрии.

🔧 Три области, без которых не выжить на первом дежурстве:

• Сети. TCP/IP, DNS, HTTP/HTTPS. Если видишь трафик на порт 4444 — насторожись: это классический дефолт Metasploit, и да, атакующие до сих пор забывают его менять.
• Windows-логи. Шесть Event ID, которые покрывают 80% типичных инцидентов: 4624 (вход), 4625 (неудача), 4672 (привилегии), 4688 (процесс), 4720 (новый аккаунт), 7045 (сервис). Первые две недели держи их на стикере у монитора — все так делают.
• Linux. /var/log/auth.log, journalctl, команды ss -tlnp и ps aux — ежедневный минимум для проверки соединений и процессов.

💡 Самый контринтуитивный совет для новичка: не пытайся выучить всё до первого дежурства. Паралич от объёма материала — реальная проблема. Лучше потрать 2–3 часа на Wireshark: захвати трафик между двумя виртуалками, разбери TCP-хендшейк и DNS-запрос. Это даст больше, чем неделя чтения RFC.

Полный маршрут на первые 90 дней — инструменты, SIEM, план по неделям и то, что делать при P1-инциденте в одиночку — в статье на форуме 👇

https://codeby.net/threads/analitik-soc-s-chego-nachat-instrumenty-navyki-i-plan-vyzhivaniya-v-pervyye-90-dnei.92864/

Коммерческий C2 за $10 000 в год детектируется за 12 секунд. Кастомный имплант, написанный за три недели, живёт в сети месяцами

🔍 Разница не в бюджете и не в функциях. Разница в том, понимаете ли вы, как устроен loader, почему EDR видит ваш beacon, и на каком уровне абстракции вы принимаете решения о стелсе.

Threat intelligence команды CrowdStrike и SentinelOne годами картографируют артефакты коммерческих C2. Каждый Malleable C2 profile, каждый паттерн beacon'а, каждый формат конфига — рано или поздно превращается в detection rule. Инженеры SECFORCE сформулировали это точнее всех: «Стандартный подход — модификация коммерческих C2 — не будет устойчивым в долгосрочной перспективе». Именно поэтому они написали собственный C2 на стеке Nim + C (имплант), Go (сервер), Node.js + React (интерфейс).

⚙️ Вот где ломается логика «дорогой инструмент = надёжный инструмент». Nighthawk от MDSec стоит $10 000 за пользователя в год (минимум три лицензии). Cobalt Strike — около $3 500/год. Оба детектируются на уровне loader'а — потому что EDR-вендоры давно знают их артефакты наизусть.

Это не значит, что коммерческие C2 бесполезны. Всё зависит от типа операции:

• Стандартный пентест — Sliver или Mythic с правильным OpSec покрывают 90% задач без дополнительной разработки
• Red Team против зрелого SOC с CrowdStrike/SentinelOne — коммерческий C2 детектируется на уровне loader'а, нужен кастомный имплант
• Adversary simulation на 3–6 месяцев — кастомный C2 единственный способ пережить активный threat hunting

🛠 Что реально даёт написание своего инструмента? Контроль над каждым байтом. Вы сами решаете, как выглядит shellcode в памяти, какой транспортный протокол использует имплант, как обходится AMSI и ETW. Модифицируете чужой фреймворк — работаете в рамках чужих ограничений. Пишете свой — платите временем и экспертизой, но получаете инструмент, который EDR-вендор ещё не видел.

🎯 Разработка offensive-инструментов — это инженерная дисциплина с реальными trade-off'ами. Здесь нет универсального ответа: BOF-модуль для Cobalt Strike иногда закрывает задачу быстрее, чем три недели разработки. Но понимать весь стек — от архитектуры C2 до уровня kernel callbacks — это то, что отделяет оператора от инженера.

В полной статье — карта всей дисциплины: архитектура C2, написание shellcode, обход AMSI/ETW, bypass конкретных EDR (CrowdStrike, SentinelOne, Defender), разработка BOF и агентов Mythic. Читайте, если хотите понять дисциплину целиком.

https://codeby.net/threads/razrabotka-red-team-instrumentov-ot-arkhitektury-c2-freimvorkov-do-kastomnykh-implantov-i-obkhoda-edr.92877/

«80% практики» — это когда флаг сам себя не захватит

Каждая школа кибербезопасности пишет про «практикоориентированность». Но когда доходит до дела, выясняется: у одних «практика» — это тест с вариантами ответов после видеолекции, у других — самостоятельная эксплуатация уязвимости на стенде с поднятым Active Directory. Разница примерно как между чтением книги про плавание и заплывом через реку.

🔥 Рынок давит: только за первый квартал 2025 года в России открылось 41 800 вакансий в сфере кибербезопасности — почти половина от всего 2024 года. Медианная зарплата пентестера на старте — 80 000–110 000 рублей. Спрос есть. Но вот вопрос: после какого курса вы реально способны провести пентест от разведки до отчёта?

💡 Есть метрика, которую почти никто не считает при выборе курса — стоимость академического часа. Курс за 156 000 рублей может оказаться дешевле курса за 85 000, если в первом втрое больше часов реальной практики. Сравнивать по общему ценнику — всё равно что выбирать отель по стоимости номера, не зная, что входит в завтрак.

Ещё один момент, который режет глаз в большинстве обзоров: никто не спрашивает, готовит ли курс к международным сертификациям. А зря. Для работодателя OSCP или eJPT — конкретный сигнал уровня. Диплом школы без привязки к признанной сертификации работает только внутри экосистемы этой школы.

🎯 Что реально отделяет сильный курс от маркетингового:

• Стенд с доменной инфраструктурой, а не одна уязвимая машина с очевидным эксплойтом
• Живое ревью отчётов от куратора — на реальном пентесте 60% работы это именно отчёт
• Покрытие актуальных векторов: Broken Access Control встречается в 94% случаев среди веб-уязвимостей по OWASP, и курс обязан это отрабатывать
• Терминология MITRE ATT&CK в программе — если её нет, курс оторван от индустриальных стандартов

🤔 Честно: большинство обзоров курсов ИБ пишут люди, которые ни разу не открывали msfconsole на рабочем проекте. Они сравнивают лендинги, а не содержание. А потом студент приходит на первый реальный пентест — и понимает, что половина изученного была мёртвым грузом.

В полной статье — разбор Codeby Academy, OTUS, Skillfactory и Нетологии по шести конкретным критериям: доля стендовой практики, глубина лабораторий, подготовка к сертификациям, формат обратной связи, актуальность программы и стоимость часа. Без маркетинга — только то, что важно при выборе.

https://codeby.net/threads/kursy-po-kiberbezopasnosti-2025-chestnoye-sravneniye-codeby-otus-skillfactory-i-netologiya.92880/

🔴 Red Team против Blue Team: не хайп, а разный образ мышления

Есть стереотип: Red Team — это крутые хакеры, Blue Team — скучные ребята за мониторами. На деле всё ровно наоборот.

80% времени Red-тимера — это написание отчётов, а не взломы. Методология, документация, воспроизводимость атаки. Голливудский образ «хакера в капюшоне» разбивается о реальность уже на первом пентесте.

А Blue Team? Когда в три часа ночи в Splunk прилетает lateral movement в реальном времени — и ты понимаешь, что атакующий уже внутри — адреналин не слабее, чем от первого полученного шелла. Это не мониторинг алертов. Это охота.

💡 Ключевое различие между командами — не инструменты, а асимметрия задачи. Red-тимеру достаточно одной успешной атаки, чтобы доказать точку. Blue-тимер должен останавливать сотни атак одновременно — и не пропустить ту единственную, которая реально опасна.

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

🟣 А что такое Purple Team? В большинстве российских компаний это вообще не существует как штатная единица. Но именно Purple-подход — когда атакующие и защитники садятся за один стол и вместе разбирают дыры в детектировании — отделяет зрелую программу безопасности от «бумажной» ИБ.

Как это выглядит на практике: Red-тимер проводит технику из матрицы MITRE ATT&CK, Blue-тимер смотрит — сработало ли детектирование. Не сработало — пишем правило. Сработало — проверяем, нет ли ложных срабатываний. Результат фиксируется и сразу идёт в улучшение защиты. Никакого «отчёта в стол».

Как выбрать своё направление? Задайте себе один вопрос: вам интереснее сломать систему или понять, почему она не сломалась? Первое — Red. Второе — Blue. Оба варианта — Purple.

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

🗺 В полной статье — детальная карта всех специализаций: от SOC Tier 1 до Threat Hunter, от junior-пентестера до оператора Red Team. Плюс реальные зарплатные вилки, сравнение сертификаций (OSCP, CEH, eJPT), и пошаговый план — с чего начать, если вы только присматриваетесь к ИБ.

Читайте полную версию — там разобраны все развилки пути.

https://codeby.net/threads/kar-yera-v-kiberbezopasnosti-red-team-blue-team-i-purple-team-polnaya-karta-spetsializatsii-i-poshagovyi-plan-rosta.92896/

Семь из десяти корпоративных сетей ломаются за 48 часов. Вот что за этим стоит

Звучит как кино, но это статистика из реальных пентестов. Семь из десяти корпоративных сетей оказывались скомпрометированы ещё до истечения двух суток — и каждая атака начиналась с одного и того же места: терминала Linux.

🖥 Не потому что это «хакерская ОС из кино». А потому что именно здесь цепочка от nmap -sS до secretsdump.py выстраивается без единого графического клика. Полный контроль, полная автоматизация, нулевая зависимость от GUI.

Но здесь начинается главная ловушка для новичков: большинство русскоязычных материалов застряли в бесконечных сравнениях Kali против Parrot. Опытный пентестер оперирует не дистрибутивом, а конкретными инструментами на каждом этапе kill chain. Дистрибутив — это просто ящик для инструментов. Цвет ящика не важен.

🔍 Если всё-таки выбирать, вот честная картина:

• Kali Linux — промышленный стандарт. Около 600 инструментов в базовом метапакете, образы для VM, Docker, WSL и ARM, меню структурировано по категориям MITRE ATT&CK. 99% обучающих материалов написаны под Kali — главный аргумент для старта.

• Parrot Security — Debian stable в основе, Tor и Anonsurf из коробки, меньше жрёт ресурсов. Единственный пентест-дистрибутив с полноценной Home-редакцией для повседневной работы.

• BlackArch — репозиторий из 2900+ утилит поверх Arch Linux. Потребление RAM в простое — около 330 МБ. Порог входа высокий, документация минимальная, зато найдёте любой инструмент.

⚡️ Теперь про то, что реально решает исход теста: разведка. По классификации MITRE ATT&CK это этапы T1595 и T1046. Пропустите разведку — будете стучаться в запертую дверь, когда окно рядом открыто настежь.

Пассивная разведка начинается до отправки первого пакета к цели. amass enum -passive -d target.com выгружает поддомены из Certificate Transparency логов. theHarvester собирает email-адреса, поддомены и имена сотрудников из публичных источников. И всё это — без единого пакета в сторону цели.

🎯 Дальше — активное сканирование, повышение привилегий через LinPEAS, техники закрепления через cron и systemd, обход EDR через syscall evasion и eBPF-атаки. Каждый этап kill chain — отдельная дисциплина со своими инструментами и ловушками.

Всё это разобрано в полном руководстве: от первого nmap-скана до закрепления в инфраструктуре. Карта kill chain с конкретными командами, инструментами и ссылками на детальные разборы каждого этапа — в статье по ссылке.

https://codeby.net/threads/linux-dlya-pentestera-polnoye-rukovodstvo-po-instrumentam-tekhnikam-i-avtomatizatsii.92899/

⚔️ WAF в режиме мониторинга — это просто дорогой логгер

Разворачиваешь пентест внешнего периметра — и снова видишь знакомую тройку: PT Application Firewall перед вебом, UserGate или Континент на границе сети. Маркетинговые даташиты обещают «полную защиту от OWASP Top 10». Реальность — другая.

🔍 Первое, что нужно понять: WAF и NGFW — принципиально разные инструменты, и обходятся они по-разному. WAF — прокси уровня приложений (L7), который разбирает HTTP-запрос на атомы: заголовки, URI, параметры, тело. NGFW работает на уровнях L3–L7, но «широко», а не «глубоко». Для атакующего это прямая развилка: WAF обманывают через семантику HTTP — мутируют payload, играют с кодировками, эксплуатируют парсерные дифференциалы. NGFW обходят туннелированием через разрешённые протоколы или фрагментацией пакетов. Смешивать подходы — терять время и плодить лишние следы в логах.

🏗 PT Application Firewall разворачивается как обратный прокси: терминирует TLS, полностью разбирает запрос, нормализует его и только потом отправляет на бэкенд. Это означает, что часть техник обхода, построенных на разнице между тем, как WAF и бэкенд по-разному читают одни и те же байты, здесь работает иначе. Сигнатурный движок стабильно ловит классические SQLi и XSS в стандартных параметрах. Но атаки в глубоко вложенных JSON/XML-структурах или с нестандартным Content-Type — уже сложнее.

Реально сильная сторона PT AF — виртуальный патчинг: при интеграции с PT Application Inspector продукт закрывает конкретные уязвимости без изменения кода приложения. Ни один NGFW этого не умеет.

Слепое пятно — атаки на бизнес-логику: IDOR, mass assignment, race conditions. Сигнатурами они не ловятся в принципе. Поведенческий ML-модуль теоретически может заметить аномалию, но только после обучения на нормальном трафике. На практике его нередко отключают — команда ИБ устаёт разгребать false positives.

🔒 UserGate NGFW — не WAF. Его задача — контроль трафика между сегментами и защита периметра. DPI-модуль идентифицирует приложения по сигнатурам и применяет политики. Для инспекции зашифрованного трафика используется TLS-инспекция (SSL bump) с подменой сертификата. Стандартный подход, но с важным следствием: его обычно настраивают выборочно, и в зонах без инспекции туннелирование через разрешённые протоколы работает предсказуемо.

💡 И самый важный практический вывод, который подтверждает опыт аудитов в финансовом и госсекторе: значительная часть российских WAF работает в режиме мониторинга, а не блокировки. Причина банальна — тюнинг политик под конкретное приложение требует ресурсов, которых у команды ИБ просто нет. Полный разбор архитектуры всех трёх продуктов, конкретные техники обхода и выводы по Континент — в статье на форуме.

https://codeby.net/threads/rossiiskiye-waf-i-ngfw-sravneniye-pt-af-usergate-i-kontinent-glazami-pentestera.92901/

🛠 Kali из коробки — это заготовка, а не рабочий инструмент

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

Первые полчаса после установки уходят не на «взлом», а на превращение дистрибутива в нормальное рабочее место. Дефолтный shell без алиасов, пустая домашняя директория, никакой структуры проектов. Если ты работаешь в VM и не настроил гостевые дополнения до обновления системы — после apt full-upgrade получишь сюрприз: новое ядро сломает интеграцию с VirtualBox, и ты окажешься в консоли с разрешением 800x600 без буфера обмена.

🔄 Правильная последовательность спасает от этого:

1. Сначала ставишь гостевые дополнения (virtualbox-guest-utils или open-vm-tools-desktop для VMware)
2. Проверяешь, что экран, буфер обмена и drag-and-drop работают
3. Делаешь snapshot в гипервизоре
4. И только потом запускаешь sudo apt full-upgrade

Откат к snapshot — секунды вместо переустановки. Это не паранойя, это гигиена.

⚖️ Отдельный вопрос — Kali или Parrot? Большинство гайдов говорят «ставь Kali» и не объясняют почему. Разница есть, и она практическая. Parrot в режиме ожидания потребляет на 300–400 МБ RAM меньше — ощутимо, если у тебя 4 ГБ и параллельно крутятся Burp Suite с браузером. Плюс встроенный AnonSurf для анонимизации трафика без дополнительных настроек.

Но если ты учишься по TryHackMe, Hack The Box или любому платному курсу — почти все гайды написаны под Kali. Адаптировать команды под Parrot придётся вручную, и на старте это лишнее трение. Оба дистрибутива — Debian с набором пакетов, и всё, что работает на одном, работает на другом. Выбор — вопрос комфорта, а не возможностей.

🔐 Ещё один момент, который игнорируют новички: не работай постоянно из-под root. Случайный rm -rf в привилегированной сессии — и результаты сканирования исчезли. Создай отдельного пользователя командой sudo useradd -m -s /bin/zsh pentester, добавь в группу sudo и работай из-под него. Это базовая гигиена, которая однажды спасёт важные данные.

Про инструменты: не ставь kali-linux-large сразу — это ~15 ГБ дополнительного места. Начни с точечных метапакетов под задачу: kali-tools-web для веба, kali-tools-passwords для брутфорса, kali-tools-information-gathering для разведки. Полный список — apt-cache search kali-tools.

📖 Полный чеклист настройки, кастомизация shell и организация структуры проектов — в статье на форуме.

https://codeby.net/threads/nastroika-kali-linux-dlya-pentesta-kastomizatsiya-instrumenty-i-optimizatsiya-okruzheniya.92927/

В апреле команда HackerLab ездила на международный Cyber Range в Астану. Формат боевой: Active Directory, Red Team, Bug Bounty по OWASP Top 10, цепочки раскрутки уязвимостей на живой инфраструктуре.

После первого дня стояли в топ-10.

На второй день в 16:00 тиммейт нашёл критичный Risk во внутрянке, сдал отчёт — прилетело +4000 баллов. Команда вышла на первое место. Все вокруг уставились в рейтинг.

17:00 — стоп. Первое место.

17:30 — финальная проверка отчётов. Первое место.

Потом команда из Узбекистана сообщила организаторам, что их отчёт на 5000 баллов пролежал необработанным с первого дня. Орги подтвердили и приняли — уже после стопа. Первое место стало вторым.

Решение осталось за организаторами. Второе место на международном турнире — это второе место на международном турнире.

Приз — 500 000 тенге.

Полный отчёт с техническими деталями: что искали, как делили работу внутри команды, что стоит взять в практику — на codeby.net: https://codeby.net/threads/aitu-ctf-cyber-range-2026.92931/

Почему скорборд падает на 40-й минуте — и как это не допустить

🔥 300+ участников, динамический скоринг в CTFd, и база данных — SQLite по дефолту. Именно так выглядит рецепт катастрофы на реальном Jeopardy. Скорборд лёг через сорок минут после старта: динамический скоринг пересчитывал стоимость тасков при каждом сабмите, а SQLite просто не справился с нагрузкой. Итог — перезапуск, миграция на PostgreSQL, потеря двух раундов и час разборок в чате. Одна конфигурационная ошибка, которую тест за 10 минут поймал бы ещё до старта.

Организация CTF — это инженерная задача, а не «закинул таски на платформу и открыл регистрацию». Каждая деталь имеет значение.

⚙️ Три формата — три разных уровня боли

Jeopardy — самый доступный старт. Команды решают независимые таски из категорий web, crypto, pwn, reverse, forensics и других, сдают флаги вида flag{s0m3_t3xt} и получают очки. Масштабируется от 10 до 1000+ команд без изменения инфраструктуры. Главная трудность здесь — не сервера, а сами задания. Каждый таск нужно проверить на unintended-решения: один реальный кейс — таск по crypto за 500 очков решался командой strings на бинарнике, потому что автор забыл убрать дебаг-вывод. Второй автор нашёл бы это за минуту.

Attack-Defense — совсем другая история. Каждая команда получает идентичный уязвимый сервер (vulnbox) и одновременно атакует противников и защищает себя. Игра идёт по тикам — раундам длиной 1-5 минут. Отошёл на обед — потерял 20 тиков. Классическая ловушка: команда блокирует все входящие соединения через iptables -P INPUT DROP и радуется, что её «не сломают». Через тик gameserver фиксирует DOWN — и SLA-очки улетают в ноль. Нельзя просто выключить сервис и стать неуязвимым: в этом и есть главный баланс формата.

🛡 Скоринг: где ошибаются чаще всего

Статический скоринг прост: 100 очков за easy, 500 за hard. Но если организатор ошибся в оценке сложности и «хард» решили 80% команд — баланс турнирной таблицы рушится. Динамический скоринг решает эту проблему: чем больше команд решило таск, тем меньше он стоит. Но именно здесь живёт та самая история с SQLite — при большом потоке сабмитов база данных просто не выдерживает. Мигрируй на PostgreSQL до старта, а не во время.

💡 Хочешь разобрать полную механику скоринга, античит и выбор инфраструктуры — читай статью целиком.

https://codeby.net/threads/organizatsiya-ctf-sorevnovanii-formaty-skoring-i-antichit-na-praktike.92940/

🔥 Как я заблокировал релиз на два дня и чему это научило о DevSecOps

Однажды я добавил SAST-сканер в продовый пайплайн без настройки порогов. Через час в Slack прилетело сорок уведомлений: мёрж заблокирован, двести находок, из которых сто восемьдесят — false positives. Релиз сдвинулся на два дня, а слово «безопасность» стало ругательным в командном чате на три недели.

Это классический антипаттерн DevSecOps: взять инструмент, включить на максимум, сломать процесс. Но проблема глубже, чем просто «неправильно настроили».

⚠️ CI/CD-пайплайн — это вектор атаки

Большинство статей о shift left security останавливаются на тезисе «лови баги раньше». Но за ним прячется неочевидная вещь: незащищённый пайплайн — полноценный инструмент для атаки на всю организацию.

В матрице MITRE ATT&CK задокументированы конкретные техники против CI/CD:
• Poisoned Pipeline Execution — внедрение кода через конфиг пайплайна
• T1195.001 — компрометация зависимостей и инструментов сборки
• T1552.001 — секреты, забытые прямо в конфигах

SolarWinds в 2020-м — не абстрактный кейс. Вредоносный код внедрили в процесс сборки, и он разлетелся через легитимное обновление на тысячи организаций. Это происходит, когда безопасность в пайплайне — просто галочка, а не процесс.

🛠 Минимальный стек, который реально работает

Не нужно прикручивать десять сканеров за один спринт. Четыре инструмента закрывают четыре разных вектора:

1. Gitleaks — ловит захардкоженные секреты до того, как они осядут в git-истории навсегда
2. Semgrep — SAST с читаемыми правилами, стартуй с p/owasp-top-ten, не с полным аудитом
3. Trivy — CVE в зависимостях и контейнерах, работает с package-lock.json, requirements.txt, Dockerfile
4. OWASP ZAP — DAST на staging, ловит то, что видно только в рантайме

Ни один из них не заменяет остальные. Именно поэтому — стек, а не один сканер.

💡 Главный урок после трёх провалов

Начинай с allow_failure: true. Везде. Сканеры показывают находки, но не блокируют мёрж. Разработчики видят результаты, привыкают к инструменту, доверие не рушится. Убираешь эту настройку в первый день — получаешь бунт. Блокирующие правила вводи постепенно, начиная только с severity: ERROR и только после того, как команда перестала воспринимать сканер как врага.

Ещё один контринтуитивный момент: секрет, попавший в git-историю, остаётся там даже после удаления файла. git log помнит всё. Поэтому Gitleaks запускают с флагом GIT_DEPTH: 0 — иначе shallow clone просто пропустит старые коммиты со всеми их сюрпризами.

Полный roadmap с конфигами для GitLab CI и GitHub Actions, примерами правил Semgrep и разбором реальных кейсов — в статье на форуме.

https://codeby.net/threads/devsecops-vnedreniye-s-nulya-kak-vstroit-bezopasnost-v-ci-cd-i-ne-slomat-razrabotku.92943/

APT28 готовит эксплойт за две недели до патча: как устроена кампания PRISMEX

12 января 2026 года группировка APT28 регистрирует WebDAV-домены. 26 января Microsoft выпускает внеочередной патч для CVE-2026-21509. 28 января — фишинговая рассылка уже в разгаре. Между подготовкой инфраструктуры и массовой атакой — 16 дней. Между патчем и атакой — 48 часов.

🎯 Масштаб впечатляет: 29 писем, девять стран, 72 часа. Но главное — письма шли не с поддельных доменов, а с реально скомпрометированных государственных почтовых ящиков Румынии, Боливии и Украины. Цели — министерства обороны, логистические хабы, дипломатические миссии. В Польше били по железнодорожной логистике, в Словакии и Чехии — по цепочкам поставок боеприпасов.

Что делает эту кампанию особенной технически?

⚙️ Цепочка заражения полностью автоматическая. Жертва открывает RTF-документ, и дальше всё происходит без единого дополнительного клика. Через OLE-механизм инстанциируется COM-объект Shell.Explorer.2, который инициирует соединение к WebDAV-серверу атакующего и подтягивает LNK-файл. Никаких макросов. Protected View обходится. Стандартные OLE-предупреждения — тоже.

Загруженный LNK эксплуатирует вторую уязвимость — CVE-2026-21513 в MSHTML Framework (CVSS 8.8). Через вложенные iframe и манипуляцию trust boundaries вызывается ShellExecuteExW за пределами браузерного sandbox. Итог: открыл документ → полная компрометация.

🔬 Дальше — ещё интереснее. Малварный набор PRISMEX использует три приёма, которые серьёзно усложняют детектирование:

• Стеганография в PNG — payload прячется внутри обычных картинок. Антивирус видит легитимное изображение, а внутри — код.
• Fileless-исполнение — вредоносный код живёт только в памяти, на диск ничего не пишется.
• Облачный C2 через Filen.io — управляющий трафик маскируется под обычное обращение к легитимному облачному сервису.

Отдельная деталь для аналитиков: серверная фильтрация. Если вы пытаетесь скачать образец из нецелевой страны или с неподходящим User-Agent, сервер отдаёт чистый ответ. Классический sandbox-evasion на уровне инфраструктуры.

Почему это важно для SOC прямо сейчас? Потому что между раскрытием CVE-2026-21513 и выходом патча прошло 11 дней подтверждённой zero-day-эксплуатации в дикой среде. А CERT-UA зафиксировал атаки на более чем 60 почтовых аккаунтов центральных органов Украины через ту же связку.

В полной статье — конкретные YARA-правила, Sigma-запросы, IoC и detection-логика, которую можно внедрить в SIEM уже сегодня. Разобраны оба варианта цепочки (MiniDoor и Covenant Grunt), COM hijacking, техники по MITRE ATT&CK и рекомендации по hardening.

Читайте полный разбор на форуме.

https://codeby.net/threads/apt28-kampaniya-prismex-analiz-tsepochki-zarazheniya-oblachnyi-c2-i-detection-dlya-soc.92951/

$13,7 млн испарились за ночь: что взлом Grinex говорит о реальной безопасности криптобирж

15 апреля 2026 года криптобиржа Grinex встала колом. Около 1 млрд рублей вывели в неизвестном направлении. Площадка публично обвинила «западные спецслужбы» — и не предоставила ни единого индикатора компрометации. Ни хеша, ни IP, ни CVE. Ничего.

Для любого Threat Intelligence-аналитика это красный флаг: громкая атрибуция без технических деталей означает, что реальный вектор компрометации либо не исследовали, либо результаты слишком неудобны.

🔍 Контекст делает картину ещё интереснее. Grinex — фактический наследник санкционированной Garantex. После того как OFAC заморозил активы Garantex в марте 2025-го, средства клиентов перетекли на Grinex через рублёвый стейблкоин A7A5, который обработал десятки миллиардов долларов за год. Санкционное давление нарастало волнами — OFAC, Великобритания, ЕС, блокировка на Uniswap. И на этом фоне — кибератака. Совпадение? Возможно. Но паттерн показательный.

⚙️ Что мы знаем о вероятных техниках? Если разложить атаку по MITRE ATT&CK, типовая kill chain для криптобирж в 2026 году выглядит так:

• T1078 Valid Accounts — компрометация ключей подписи транзакций через фишинг оператора или инсайдера. По статистике TRM Labs, это главный вектор финансовых киберинцидентов прямо сейчас
• T1190 Exploit Public-Facing Application — API биржи, особенно если кодовую базу унаследовали от предшественника без полного аудита
• T1657 Financial Theft — прямая кража с hot wallet, не ransomware, не шифрование, а вывод средств on-chain

Обратите внимание: Grinex не опубликовала postmortem. А T1070 (очистка логов) — стандартная практика атакующих, которая объясняет, почему IOC так и не появились.

📊 И это лишь один инцидент на фоне масштабной картины. За 2025 год в открытый доступ попали более 767 млн записей персональных данных российских пользователей. Q1 2026 продолжил тренд — десятки миллионов строк на андеграундных форумах и в Telegram. Оборотные штрафы за утечки перестали быть теорией, а supply chain атаки начали бить по самим инструментам защиты.

Что с этим делать SOC-аналитику? Как минимум — мониторить аномальные вызовы к signing-сервисам, отслеживать нетипичные объёмы транзакций с hot wallet и проверять целостность CI/CD-пайплайнов.

В полной статье — детальный маппинг TTPs по MITRE ATT&CK, хронология от Garantex до Grinex и готовый detection-чеклист для SOC. Разбираем всё.

https://codeby.net/threads/utechka-dannykh-kriptobirzhi-v-rossii-2026-vzlom-grinex-na-13-7-mln-razbor-ttps-i-detection-cheklist-dlya-soc.92947/

🔓 Патч закрыл RCE, но оставил кражу хешей: как CVE-2026-32202 обманывает Windows Shell

Представьте: вы добросовестно накатили февральский Patch Tuesday, закрыли активно эксплуатируемую zero-day с CVSS 8.8, проверили — код через вредоносный .lnk больше не выполняется. Всё хорошо? Нет. Ваша машина по-прежнему отправляет Net-NTLMv2-хеш на сервер атакующего. Просто потому, что пользователь открыл папку с ярлыком.

Именно это обнаружили исследователи Akamai, тестируя фикс для CVE-2026-21510. Патч убрал обход SmartScreen и заблокировал RCE, но не тронул механизм аутентификации. Так появился CVE-2026-32202 — zero-click уязвимость Windows Shell, которую CISA 29 апреля добавила в каталог Known Exploited Vulnerabilities с дедлайном до 12 мая.

⚙️ Как это работает

Когда Windows Explorer открывает папку, он автоматически парсит все .lnk-файлы внутри — чтобы отрисовать иконки и метаданные. Если ярлык указывает на UNC-путь вроде \\attacker.com\share\payload.cpl, Shell пытается его резолвить. А резолвинг UNC-пути — это SMB-соединение с удалённым сервером и отправка NTLM-хендшейка.

Ключевой момент: всё это происходит до проверок SmartScreen и Mark of the Web. Исследователи называют это «gap between path resolution and trust verification» — окно между разбором пути и проверкой доверия. Функция ShellExecuteExW резолвит путь и инициирует соединение раньше, чем любые защитные механизмы успевают вмешаться.

Итого — цепочка атаки:

• Атакующий создаёт .lnk с UNC-путём на свой сервер
• Доставляет через фишинг, шару или USB
• Жертва просто открывает папку — даже не кликает по файлу
• Windows Shell автоматически отправляет NTLM-хеш
• Атакующий ловит хеш через Responder и делает relay или offline-брутфорс

🎯 Почему CVSS 4.3 — это обманка

Microsoft оценила уязвимость как MEDIUM (CVSS 4.3). Формально — «частичная утечка конфиденциальных данных, целостность не нарушена». Но в реальной доменной среде перехваченный Net-NTLMv2-хеш — это входной билет. NTLM Relay даёт доступ к соседним сервисам без подбора пароля. Offline-брутфорс через hashcat при слабых паролях занимает минуты. А главное — APT28 уже использовала предшественника этой уязвимости в кампаниях против Украины и стран ЕС.

Получается парадокс: неполный патч превратил критическую RCE (CVSS 8.8) в «среднюю» spoofing-уязвимость (CVSS 4.3). Стало безопаснее, но не безопасно.

Если вы администрируете Windows-инфраструктуру с NTLM — проверьте, что апрельский патч установлен. А полный разбор механики, хронологию от первой CVE до попадания в каталог KEV и рекомендации по защите читайте в полной статье.

https://codeby.net/threads/cve-2026-32202-uyazvimost-windows-shell-zero-click-krazha-ntlm-kheshei-cherez-lnk-faily.92952/