40 минут на ручной перебор паролей — или 3 минуты на скрипт?

На одном онлайн-CTF участник вбивал пароли в форму вручную. 200 попыток, 40 минут, ноль результата. Его тиммейт написал 10 строк на Python с requests, натравил на словарь — и забрал флаг за три минуты. Разница не в глубине знаний языка, а в конкретных приёмах: отправить POST, вытащить токен из HTML, прогнать перебор в цикле.

🔧 Четыре библиотеки закрывают около 90% задач автоматизации в CTF:

• requests — HTTP-запросы, брутфорс форм, работа с куками через сессии
• BeautifulSoup4 — парсинг HTML, извлечение токенов, флагов, скрытых полей
• pwntools — бинарная эксплуатация, TCP-сервисы, упаковка адресов
• hashlib — встроен в Python, хеширование для крипто-задач

Вся установка — одна команда после создания виртуального окружения: pip install requests beautifulsoup4 pwntools.

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

1. Сессия через requests.Session() — без неё сервер воспринимает каждый запрос как нового пользователя, и куки теряются.

2. Имена полей формы — не угадывайте, а откройте F12 в браузере и скопируйте точные значения атрибутов name из тегов <input>. Бывает username, бывает login или user — одна буква сломает весь скрипт.

3. Условие успеха — в CTF работает проверка от обратного. Если в ответе нет слова «Invalid» или «Wrong» — скорее всего, вы внутри. Альтернатива: ловить код 302 (редирект после POST).

Словарь на 10 000 строк прогоняется за 10–30 секунд в зависимости от задержки сервера.

🛑 Когда скрипт сломается? Если сервер режет по rate limit — добавьте time.sleep(0.3) между запросами. Если форма требует CSRF-токен — сначала GET-запросом забираете страницу, парсите скрытое поле через BeautifulSoup, подставляете в POST. Без этого шага цепочка брутфорса развалится.

И тут начинается самое интересное: большинство web-задач CTF — это не один запрос, а цепочка. GET → парсинг → POST → проверка. Три метода BeautifulSoup покрывают 95% случаев: find() для конкретного элемента, find_all() для списка и get() для атрибутов тега.

📖 В полной статье — готовые скрипты с разбором каждой строки, работа с pwntools для бинарных задач и примеры парсинга CSRF-токенов. Забирайте в закладки.

https://hackerlab.pro/blog/python-dlya-ctf-avtomatiziruem-rutinu-ot-brutforsa-do-parsinga-otvetov

Пять команд в терминале вместо двадцати минут в Wireshark: как решать network-таски на CTF

Пока кто-то кликает по меню Statistics → Protocol Hierarchy в графическом интерфейсе, три флага уже улетают в скорборд. На KnightCTF 2024 пять задач из категории networking решались чистым tshark — без единого запуска GUI.

🔍 Первое действие с любым pcap-файлом — не открывать Wireshark, а набрать:

strings capture.pcap | grep -i "flag{"

Подставляешь формат флага из условия (KCTF{...}, flag{...}, ctfa{...}) и в части задач получаешь ответ за одну секунду. Флаг нередко лежит в открытом виде прямо в трафике — организаторы закладывают это намеренно.

Если не сработало — второй шаг: смотрим распределение протоколов.

tshark -r capture.pcap -q -z io,phs

На выходе — дерево с процентами. Видишь 95% HTTP и крошечную долю FTP или странные DNS-запросы? Вот туда и копай. Аномалия в протокольном распределении — почти всегда указатель на флаг.

⚡ Три главных места, где прячут флаги в HTTP-трафике:

• GET-параметры URL — что-то вроде /page.php?secret=flag{abc}
• POST-тело — формы логина, загрузка файлов
• Нестандартные заголовки ответа — X-Flag, X-Secret-Data

Отдельная история — заголовок Authorization: Basic. Встретил строку вроде dXNlcjpwYXNz? Это Base64. Декодируешь одной командой: echo "dXNlcjpwYXNz" | base64 -d → user:pass. В CTF-задачах Base64 встречается повсюду: HTTP-заголовки, поддомены DNS, тело FTP-передач.

🕵️ DNS exfiltration — ещё один классический паттерн. Атакующий кодирует данные в поддоменах DNS-запросов: ZmxhZ3s.evil.com. Выглядит как обычный резолв, а на деле — канал утечки. Кстати, flag{ в Base64 выглядит как ZmxhZ3s — запомни этот паттерн, он экономит время на каждом втором соревновании.

Что касается FTP — протокол передаёт логины и пароли открытым текстом. Если в pcap есть FTP-сессия, креды достаются элементарно. Фильтруешь по ftp.request.command == "PASS" — и вот они.

📌 Минимальный набор для старта:

• tshark — фильтрация, follow stream, экспорт объектов
• strings + grep — быстрый поиск по бинарнику
• base64 — декодирование на лету
• binwalk -e — извлечение вложенных файлов (картинки, архивы, документы)

Всё это есть в любом Linux из коробки. Kali — вообще без доустановки. RAM от 4 ГБ, сеть не нужна, pcap-файлы на CTF редко превышают 50 МБ.

Когда GUI всё-таки нужен? Файлы от 500 МБ с десятками тысяч потоков, визуальный анализ ретрансмиссий и временных диаграмм. Но на типичном CTF — терминал быстрее.

В полной статье — пошаговый разбор реальных задач с KnightCTF и CTF Academy: follow stream через CLI, извлечение файлов из трафика и декодирование DNS-эксфильтрации. Забирай в закладки 👇

https://hackerlab.pro/blog/setevoy-analiz-ctf-razbiraem-http-ftp-i-dns-v-trafike-i-dostaem-flag-bez-wireshark-ekspert

🔍 Неделя 4 — Финал: Секретный кабинет

Последняя неделя серии «Сетевая разведка за 30 дней» — и сразу 500 очков.

Маршрут к цели известен. Нужен пароль. Всё, что изучали три недели — сейчас в одной цепочке:

nmap → gobuster → Burp Repeater → hydra

Разведка, directory enumeration, разбор auth-формы, брутфорс. Именно так выглядит реальный engagement.

⏱️ Старт: 23 июня, 10:00 МСК
🏁 Дедлайн: 28 июня, 23:59 МСК

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

После 29 июня — финальный wrap-up серии, лучшие writeup'ы и что будет дальше.

👉 Неделя 4 — Финал: Секретный кабинет

printf(buf) — одна строка кода, которая ломает всё

На недавнем CTF один pwn-таск решили всего 12 команд из 200. Бинарник принимал строку через fgets, отправлял её прямиком в printf — и всё. Ни переполнения буфера, ни use-after-free, ни heap-примитивов. Команды, привыкшие к классическому BOF, зависли: переполнять нечего. А ведь это и есть format string — одна из самых элегантных атак в binary exploitation.

🔍 Суть проблемы укладывается в одно сравнение:

• printf("%s", buf) — безопасно. Ввод трактуется как текст.
• printf(buf) — уязвимо. Ввод трактуется как инструкция форматирования.

Когда printf встречает спецификатор вроде %p или %x, она лезет на стек за следующим аргументом. Проблема в том, что макрос va_arg понятия не имеет, сколько аргументов реально передано. Он просто сдвигает указатель дальше по стеку — без проверки границ. Три спецификатора %x в строке — три значения со стека, даже если дополнительных аргументов ноль.

⚙️ Что это даёт атакующему? Целый арсенал примитивов:

• %p / %x — чтение стека. Утечка адресов, обход ASLR, поиск канареек.
• %s — чтение по произвольному указателю. Если на стеке лежит адрес, printf прочитает строку по этому адресу.
• %n — запись в память. Записывает количество уже выведенных символов по адресу на стеке. Это arbitrary write — самый опасный примитив.

Первый шаг в любом CTF-таске с format string — найти смещение (offset) до своего буфера на стеке. Отправляешь уникальный маркер типа AAAA и серию %p, ищешь в выводе 0x41414141. Нашёл на седьмой позиции? Значит offset = 7, и теперь можно обращаться к нему напрямую через %7$p.

На x86-64 есть нюанс: первые шесть аргументов идут через регистры (rdi, rsi, rdx, rcx, r8, r9), а на стек попадают только остальные. Поэтому смещение при переходе с 32-bit на 64-bit нужно определять заново.

Дальше — дело техники. В pwntools есть класс FmtStr, который автоматизирует и поиск смещения, и генерацию payload для записи. Ты задаёшь адрес и значение — он сам рассчитывает нужное количество символов и расставляет %hhn для побайтовой записи. Без этого инструмента ручной расчёт превращается в ад с арифметикой.

🎯 Format string — тема, которая кажется простой на поверхности, но в реальных тасках требует понимания раскладки стека, calling conventions и защитных механизмов.

Полный разбор с компиляцией уязвимого бинарника, пошаговой отладкой в GDB и готовым эксплойтом — в статье на форуме.

https://hackerlab.pro/blog/format-string-uyazvimost-v-ctf-razbiraem-printf-ataku-i-chitaem-pamyat-protsessa-shag-za-s

Три символа, которые ломают авторизацию: как JWT-атаки решают CTF-задачи

На одном из CTF я потратил 40 минут на веб-задачу — перебирал эндпоинты, пробовал SQLi, ковырял параметры. А решение уместилось в три символа: none в поле alg JWT-заголовка и пустая подпись. Флаг пришёл мгновенно.

JWT — это строка из трёх частей через точку: header.payload.signature. Header говорит серверу, каким алгоритмом проверять подпись. Payload хранит данные о пользователе в открытом виде — никакого шифрования, просто base64url. Signature гарантирует, что никто не подменил содержимое. В теории.

На практике разработчики допускают ошибки в валидации, и вот три атаки, которые чаще всего встречаются в CTF:

🔓 1. alg:none — самая простая и самая недооценённая. Меняем алгоритм в header на "alg":"none", правим payload (например, "role":"admin"), убираем подпись, оставив финальную точку. Если сервер не проверяет алгоритм строго, он примет токен без подписи вообще. В jwt_tool это одна команда: python3 jwt_tool.py TOKEN -X a.

🔑 2. Брутфорс слабого секрета. Алгоритм HS256 использует один симметричный ключ для подписи и проверки. Если разработчик поставил пароль вроде secret, password123 или qwerty — его можно подобрать за секунды. hashcat с режимом 16500 и словарём rockyou.txt перебирает миллионы вариантов в секунду на GPU. Нашёл ключ — подписываешь любой payload и заходишь как admin.

⚡ 3. Algorithm confusion — уровень посложнее. Сервер ожидает RS256 (асимметричная пара ключей), но атакующий переключает заголовок на HS256 и подписывает токен публичным ключом сервера как HMAC-секретом. Публичный ключ часто доступен — через /jwks.json или в исходниках. Сервер берёт тот же ключ для проверки и... подпись совпадает.

Где искать токен в задаче? Четыре места:

• Cookie — самый частый вариант (названия: jwt, token, session)
• Заголовок Authorization: Bearer ...
• Тело JSON-ответа после логина
• localStorage в DevTools для SPA-приложений

Практический алгоритм на CTF: нашёл токен → декодировал header и payload → посмотрел alg → попробовал none → не сработало — запустил брутфорс секрета → проверил algorithm confusion. Три шага, которые закрывают 80% JWT-задач на соревнованиях.

По классификации OWASP, эти уязвимости попадают сразу под три категории Top 10: Broken Access Control, Cryptographic Failures и Security Misconfiguration. Не только CTF — реальные CVE тоже.

Полный разбор с командами и примерами — в статье на HackerLab.

https://hackerlab.pro/blog/jwt-ataki-ctf-ot-struktury-tokena-do-zahvata-flaga-cherez-alg-none-i-slabyy-sekret

Пустая страница Apache — и четыре минуты до флага

Представьте: вы подключаетесь к тренировочной машине на HackTheBox. Nmap показал единственный открытый порт 80, браузер — пустую страницу. Тупик. Одна команда gobuster dir со словарём common.txt — и через 35 секунд найден /robots.txt. Внутри — путь к админке. В исходном коде — забытые тестовые креды. Четыре минуты от запуска до флага. Без dirbusting эту машину можно было ковырять часами.

Перебор директорий — это первое, что делает пентестер после сетевого скана. Вы знаете, что порт открыт, но структура приложения — тёмный лес. Gobuster берёт словарь с типовыми именами путей, подставляет каждое в URL и анализирует HTTP-ответ. Просто, грубо, эффективно.

🔍 Что реально находят при dirbusting:

• .env, config.php.bak, db_backup.sql — файлы с учётными данными, которые разработчик забыл убрать
• Директории .git/ и .svn/ — раскрывают исходный код проекта
• Панели phpMyAdmin без пароля, Tomcat Manager с дефолтными tomcat:tomcat
• Забытые веб-шеллы вроде cmd.php — прямой путь к RCE

По данным Verizon DBIR 2025, около 26% подтверждённых утечек приходится на атаки на веб-приложения. Немалая часть начинается именно с обнаружения эндпоинтов, которые никто не планировал показывать миру.

⚙️ Gobuster написан на Go, потребляет минимум памяти и работает быстро. В Kali Linux он предустановлен — просто набираете gobuster в терминале. Словари SecLists ставятся одной командой: sudo apt install seclists. После установки они лежат в /usr/share/seclists/.

Лайфхак из практики: если ставите через go install, сразу пропишите export PATH=$PATH:$HOME/go/bin в .bashrc. Иначе после перелогина команда «пропадёт», и вы потратите минут пять на выяснение причин.

Режим dir — основной. В CTF-контексте 90% работы — именно он. Минимальная команда требует всего два параметра: URL цели и путь к словарю. Остальные режимы (dns, vhost, fuzz, s3) решают другие задачи и в веб-задачах встречаются реже.

📌 Для тренировки поднимите OWASP Juice Shop в Docker — уязвимое приложение с десятками скрытых эндпоинтов. Идеальный полигон, чтобы прощупать Gobuster без риска что-то сломать.

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

https://hackerlab.pro/blog/gobuster-perebor-direktoriy-i-poisk-skrytyh-faylov-v-veb-zadachah-ctf

☝️Промокод MIDSUMMER2026 можно применить не только к новой подписке, но и к продлению текущей. Срок прибавится к концу активного периода.

🤖 ИИ в пентесте и VA: заменит или поможет?

Всем привет, Кодебаевцы!

Середина 2026-го, а из каждого угла всё то же: «вот-вот ИИ заменит нас всех». Верится с трудом — по крайней мере в обозримом будущем. А вот как толковый помощник в рутине (и не только) — почему бы и нет?

Открываем обсуждение и собираем реальный опыт комьюнити:

🔹 Как вы применяете ИИ в пентест-проектах — разведка, фаззинг, разбор выводов, генерация отчётов?
🔹 Где ИИ реально ускоряет управление уязвимостями (VA), а где только мешает?
🔹 Кейсы из других ИБ-сфер — SOC, threat intel, реверс, OSINT?

Без хайпа и маркетинга — только практика: что действительно экономит время, а что оказалось переоценённым.

💬 Делитесь опытом в теме — самое ценное всегда в комментариях практиков.
👉 Обсудить →