🔍 Неделя 2: Virtual Server — Service Enumeration через SSH и FTP

Серия «Сетевая разведка за 30 дней» продолжается.

Открытые порты — это только начало. На этой неделе учимся читать сервисы: выжимать версии, баннеры, конфиги и файлы до первой попытки эксплуатации.

Цель: VDS, где SSH и FTP настроены «потом исправлю»

Инструменты: — nmap -sV + скрипты ftp-anon, ssh-auth-methods — anonymous FTP: конфиги, бэкапы, исходники — ssh-audit — слабые алгоритмы и разрешённые методы — nc для сырого banner-grab + searchsploit по версии

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

До дедлайна — обсуждаем подходы, не флаги. После — writeup'ы открыты.

👇 Задание и обсуждение: 🔗 https://codeby.net/threads/nedelya-2-virtual-nyi-server-service-enumeration-cherez-ssh-i-ftp.93753/

🪪 У чата HackerLab теперь есть лицо!

Кликни на ник или аватарку собеседника прямо в чате — и откроется его карточка: уровень и ранг, место в рейтинге, сколько задач и CTF решено, активность на форуме. Тут же можно написать в личку, подписаться или заглянуть в полный профиль — в один клик.

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

🔗 hackerlab.pro

Первый бинарник в Ghidra: почему новички тонут и как выплыть

Два часа на одну CTF-задачу по реверсу — и ноль результата. Функция main потерялась среди тысячи символов, декомпилятор выдал стену из undefined8 и DAT_00104020, а ассемблерный листинг выглядел как случайный набор мнемоник. Знакомо? Через полгода практики такая же задача решается за десять минут. И дело не в зубрёжке ассемблера, а в конкретном навыке: открыть бинарник, найти нужную функцию, прочитать псевдокод.

Ghidra — фреймворк для реверс-инжиниринга от NSA, open source с 2019 года. Ключевое преимущество перед конкурентами для новичка — бесплатный встроенный декомпилятор. IDA Pro Free его не даёт, а платная версия стоит тысячи долларов. radare2 мощен, но его CLI — отдельная кривая обучения, которая на старте только мешает.

⚙️ Что нужно для старта:

• JDK 21 (без Java Ghidra не запустится — даже не пытайтесь)
• Минимум 4 ГБ RAM, лучше 8 — автоанализ активно ест память
• Любая ОС: Windows, Linux, macOS
• Сеть не нужна — Ghidra работает полностью offline

Установка на Linux укладывается в три команды: sudo apt install openjdk-21-jdk, распаковать ZIP с GitHub, запустить ./ghidraRun. На Windows — аналогично, только через ghidraRun.bat. Никакого инсталлятора.

🎯 Первые шаги в интерфейсе — вот где большинство сдаётся. Десятки панелей, деревьев, кнопок. Но для CTF реально нужны только четыре окна:

• Symbol Tree — здесь ищете функцию main через ветку Functions
• Listing — ассемблерный код с адресами и перекрёстными ссылками
• Decompile — псевдокод на C, ради которого всё и затевалось
• Defined Strings — текстовые строки из бинарника, часто содержат подсказки или сам флаг

Алгоритм работы простой. Создаёте проект (File → New Project → Non-Shared). Импортируете бинарник — Ghidra сама определит формат: ELF, PE, Mach-O. Открываете CodeBrowser, соглашаетесь на автоанализ. За секунды инструмент определяет границы функций, строит ссылки, вытаскивает строки. Дальше — находите main в Symbol Tree, кликаете, читаете декомпилированный код справа.

💡 Главный совет: не пытайтесь понять каждую строку ассемблера. Декомпилятор выдаёт псевдокод с уродливыми именами переменных — это нормально. Переименовывайте их по мере понимания логики (правый клик → Rename Variable). Ищите паттерны: сравнение строк, XOR-шифрование, побайтовые проверки. В большинстве CTF-задач начального уровня флаг либо лежит в строках, либо восстанавливается из простых преобразований.

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

https://hackerlab.pro/blog/ghidra-revers-inzhiniring-razbiraem-pervyy-binarnik-v-ctf-zadache-po-reversu

Четыре часа на одну 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