Четыре часа на одну PNG-шку — почему стеганография в CTF съедает время

Реальная ситуация: команда на соревновании убила четыре часа на файл размером 6 КБ. Запустили steghide — но он не поддерживает PNG. Попробовали binwalk — получили ложную сигнатуру TIFF. А про zsteg просто не вспомнили. Флаг сидел в LSB красного канала и вытащился бы за секунды.

Проблема не в скилле. Проблема — в отсутствии системного чеклиста. Вот сжатая версия того, что реально экономит время.

🔍 Шаг 1. Не верь расширению

В CTF расширение файла врёт постоянно. challenge.txt может оказаться PNG, а image.jpg — ZIP-архивом. Первое действие всегда — file challenge.txt. Команда определяет тип по магическим байтам, а не по имени. Если ответ говорит «PNG image data» — расширение ложное, и это уже подсказка.

Дальше — exiftool. Поля Comment, Artist, Description — классические места, где прячут флаги или хинты. Base64-строка в поле Comment — стабильный паттерн на среднем уровне.

И параллельно: strings challenge.png | grep -iE "flag|ctf|key|{|}". Тривиально, но на лёгких тасках это решает задачу примерно в трети случаев.

📦 Шаг 2. Ищем вложенные файлы

binwalk challenge.png покажет всё, что спрятано внутри: ZIP-архивы, вторые картинки, данные после маркера конца файла. Нашёл что-то — извлекай через binwalk -e.

Но важный нюанс: binwalk часто даёт ложные срабатывания. Случайное совпадение байт с сигнатурой ZIP — обычное дело. Всегда проверяйте извлечённые файлы через file и пробуйте открыть.

Если binwalk молчит — пробуйте foremost. Он ищет пары header/footer и иногда цепляет то, что binwalk пропускает.

🖼 Шаг 3. Формат определяет инструмент

Вот где большинство ошибается. Каждый формат — свой набор утилит:

• PNG/BMP → zsteg (LSB-анализ, работает моментально) и Stegsolve (визуальный просмотр битовых плоскостей)
• JPEG → steghide (прячет данные в DCT-коэффициентах, нужен пароль — попробуйте пустой) и stegseek (брутфорс пароля по словарю rockyou.txt за секунды)
• GIF → проверяйте отдельные фреймы и палитру

Запустить steghide на PNG — пустая трата времени. Он физически не умеет работать с этим форматом. Именно на этом и погорела та команда из начала поста.

🎧 Отдельная история — аудио-стеганография. Спектрограмма в Sonic Visualiser или Audacity часто показывает текст или QR-код, нарисованный частотами.

Это сжатый алгоритм. Полный чеклист с decision tree, таблицей ограничений инструментов и разбором альфа-канала — в развёрнутой статье.

https://hackerlab.pro/blog/steganografiya-v-ctf-cheklist-i-instrumenty-dlya-poiska-skrytyh-dannyh-v-kartinkah-i-audio

Сорок минут на один хэш — или почему новички в CTF теряют время впустую

Представьте: первый CTF, категория Crypto. В условии — строка из 32 hex-символов и вопрос «Какой пароль?». Вы идёте в онлайн-сервисы, гуглите бессистемно, тратите полчаса. А кто-то рядом вбивает одну команду в терминал — и хэш ломается за доли секунды. Разница не в таланте, а в понимании трёх шагов: определить тип, выбрать инструмент, запустить правильную атаку.

🔍 Шаг 1 — определить тип хэша

Самая частая ошибка — запускать инструмент вслепую. Hashcat вообще не стартанёт без явного указания типа через -m. John the Ripper умеет угадывать, но медленнее и порой мимо.

Быстрая шпаргалка по внешнему виду:

• 32 hex-символа → скорее всего MD5 (Hashcat -m 0)
• 40 символов → SHA-1 (-m 100)
• 64 символа → SHA-256 (-m 1400)
• Префикс $6$ → SHA-512crypt из Linux
• Префикс $2a$ → bcrypt
• 32 hex в верхнем регистре → NTLM

Если сомневаетесь — утилита hashid (ставится через pip3 install hashid) выдаст список вероятных форматов. Для hex-строк без префикса первый вариант в списке обычно верный.

⚡️ Шаг 2 — выбрать инструмент

John the Ripper и Hashcat — не конкуренты, а напарники. Ключевое различие: John работает на CPU, Hashcat заточен под GPU. Для типичного CTF-таска с MD5 и словарём rockyou.txt (14+ миллионов паролей) оба справятся мгновенно. Но если дело дойдёт до bcrypt или масочного перебора — GPU в Hashcat даст колоссальное ускорение.

На практике: начинайте с John (проще синтаксис, автодетект формата), переходите на Hashcat, когда нужна скорость или тонкая настройка масок.

🎯 Шаг 3 — запустить атаку

Минимальная команда для John: john --wordlist=/usr/share/wordlists/rockyou.txt --format=raw-md5 hash.txt

Для Hashcat: hashcat -m 0 -a 0 hash.txt rockyou.txt

Пароль из словаря — и результат появляется за секунду. Но что делать, если пароль — мутация словарного слова, вроде Password123!? Тут спасают правила мутации: John умеет на лету добавлять цифры, менять регистр, дублировать символы. Флаг --rules=best64 — хороший старт.

💡 Лайфхак для соревнований: если пароль не нашёлся по rockyou.txt за пару секунд — перечитайте условие задачи. В CTF авторы почти всегда закладывают подсказку на нужный подход.

Полный разбор с примерами масочных атак, настройкой правил и типичными CTF-ловушками — читайте в статье на форуме.

https://hackerlab.pro/blog/vzlom-heshey-v-ctf-john-the-ripper-i-hashcat-ot-nulya-do-pervogo-flaga

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 можно применить не только к новой подписке, но и к продлению текущей. Срок прибавится к концу активного периода.