Взлом хэшей в CTF: John the Ripper и Hashcat

Семь хэшей SHA-512crypt из дампа /etc/shadow, таск на 300 очков, 45 минут до конца CTF. Три команды из топ-10 не сдали задание — не из-за сложности паролей, а из-за неверного hash mode в Hashcat. Правильный -m 1800 плюс rockyou.txt давали флаг за 12 секунд. Одна цифра в параметре — и разница между первым местом и пустым скорбордом.

Взлом хэшей через John the Ripper и Hashcat — навык, который определяет результат не только на соревнованиях: техника Password Cracking (T1110.002, Credential Access) по MITRE ATT&CK применяется после дампа учётных данных (T1003) на каждом реальном пентесте. Ниже — конкретный workflow с командами, разбор типичных ошибок и выбор инструмента под задачу.

Идентификация хэша — первый шаг перед подбором

Перед запуском любого инструмента подбора нужно точно определить тип хэша. Hashcat требует явного указания hash mode через флаг -m, а John the Ripper определяет формат автоматически — но далеко не всегда верно. Ошибка здесь обнуляет всю работу: инструмент будет считать хэши по неверному алгоритму и не найдёт совпадение, даже если пароль лежит первой строкой в словаре. Подробнее — в нашем материале про создание ctf заданий.

hashid и hash-identifier (предустановлен в Kali Linux) принимают строку хэша и выдают список возможных алгоритмов. Более толковый инструмент — haiti — дополнительно показывает hash mode для Hashcat и формат для JtR. Для быстрой ручной идентификации достаточно знать базовые маркеры по длине и префиксу:

• 32 символа hex — MD5 (Hashcat -m 0, JtR Raw-MD5)
• 40 символов hex — SHA-1 (-m 100, Raw-SHA1)
• 64 символа hex — SHA-256 (-m 1400, Raw-SHA256)
• 128 символов hex — SHA-512 (-m 1700, Raw-SHA512)
• Префикс $6$ — SHA-512crypt (-m 1800, sha512crypt)
• Префикс $2a$ или $2b$ — bcrypt (-m 3200, bcrypt)
• 32 символа hex в Windows-контексте — NTLM (-m 1000, NT)

В CTF-тасках категории crypto и forensics хэш часто обёрнут в нестандартный формат: Base64-кодированная строка, hex-дамп с пробелами, кастомный разделитель. Первое действие — привести хэш к стандартному виду, иначе ни Hashcat, ни JtR его не распознают.

Hashcat выводит примеры всех поддерживаемых форматов по команде hashcat --example-hashes, а JtR — список форматов через john --list=formats. Обе команды стоит вызывать при любых сомнениях: в jumbo-версии JtR на момент релиза 1.9.0-jumbo-1 — 407 форматов, а в Hashcat число поддерживаемых hash mode превышает 350. Есть где запутаться.

John the Ripper для начинающих: форматы хэшей и режимы атак

John the Ripper работает в трёх основных режимах: Single Crack, Wordlist и Incremental. Согласно исследованию HashKitty (arxiv, 2025), каждый из них заточен под свой сценарий.

Single Crack использует информацию из самого файла паролей — GECOS-поле в /etc/passwd, имя пользователя, имя хоста — для генерации кандидатов. Пользователь admin? JtR попробует admin, Admin1, admin123 и десятки вариаций. Удивительно, как часто это срабатывает.

Wordlist mode — классическая dictionary attack по указанному файлу с возможностью применения правил мутации. Incremental mode — полный перебор, где JtR генерирует комбинации по встроенным частотным моделям символов, начиная со статистически вероятных.

Для CTF полезнее всего wordlist mode. Базовый запуск: john --wordlist=rockyou.txt hash.txt. JtR автоматически определит формат хэша. Если автоопределение ошибается (а на CTF это регулярно случается с нестандартными форматами), формат указывается явно: john --wordlist=rockyou.txt --format=Raw-SHA256 hash.txt. Проверить, какие форматы JtR считает подходящими для конкретного хэша, можно через john hash.txt без дополнительных флагов — он выведет список вариантов.

Правила мутации подключаются флагом --rules. По умолчанию JtR использует секцию [List.Rules:Wordlist] из john.conf. Для более широкого перебора есть --rules=All, но на CTF это обычно избыточно — хватает стандартного набора или --rules=best64. Подключение правил к словарю из 14 миллионов слов превращает их в сотни миллионов кандидатов без загрузки дополнительных файлов.

После успешного подбора результат сохраняется в ~/.john/john.pot. Чтобы увидеть найденные пароли: john --show hash.txt. И тут ловушка: повторный запуск JtR на том же хэше молча пропустит его, если результат уже в pot-файле. Без --show можно решить, что пароль не найден, хотя он давно взломан. На CTF я видел, как команда 20 минут гоняла словари по уже решённому хэшу.

Утилиты *2john — секретное оружие на CTF

Главное преимущество John the Ripper перед Hashcat на CTF — набор утилит *2john. Как указано в документации Openwall (создатель JtR — Александр Песляк, Solar Designer), эти скрипты извлекают «псевдохэши» из зашифрованных файлов и приводят их к формату, пригодному для подбора.

Наиболее востребованные на соревнованиях:

• zip2john — защищённые паролем ZIP-архивы
• rar2john — RAR-архивы
• pdf2john — зашифрованные PDF-документы
• ssh2john — приватные SSH-ключи с passphrase
• keepass2john — базы KeePass (.kdbx)
• office2john — документы Microsoft Office с паролем
• gpg2john — GPG-ключи

Workflow стандартный: сначала извлечение хэша утилитой, затем подбор.

# Извлечение хэша из ZIP-архива
zip2john protected.zip > zip_hash.txt
# Подбор по словарю
john --wordlist=/usr/share/wordlists/rockyou.txt zip_hash.txt
# Просмотр результата
john --show zip_hash.txt

Hashcat напрямую с файлами не работает — ему нужен уже извлечённый хэш в правильном формате. Поэтому на CTF стандартная связка: извлечь хэш через *2john, после чего ломать либо JtR, либо Hashcat. В реальном пентесте тот же подход применяется после получения зашифрованных файлов с целевой системы — по сути, это часть цепочки Credentials In Files (T1552.001, Credential Access).

Hashcat: примеры команд и режимы атак

Hashcat поддерживает шесть режимов атаки, каждый задаётся флагом -a:

• -a 0 — Dictionary (атака по словарю)
• -a 1 — Combinator (комбинация двух словарей)
• -a 3 — Brute-force / Mask (перебор по маске)
• -a 6 — Hybrid Wordlist + Mask (словарь + маска справа)
• -a 7 — Hybrid Mask + Wordlist (маска слева + словарь)
• -a 9 — Association (ассоциативная атака)

Для подбора хэшей в CTF чаще всего используются -a 0 (словарь), -a 0 с правилами через -r и -a 3 (маска). Базовая dictionary attack: hashcat -m 0 -a 0 hash.txt rockyou.txt. Тут -m 0 — тип MD5. Hashcat требует явного указания типа хэша, в отличие от JtR с его автоопределением (согласно HashKitty, arxiv, 2025).

Комбинаторная атака (-a 1) берёт слова из двух словарей и склеивает их попарно: hashcat -m 0 -a 1 hash.txt dict1.txt dict2.txt. На CTF полезна, когда в подсказке намекают на составной пароль из двух слов.

Гибридная атака (-a 6) дополняет слова из словаря символами по маске: hashcat -m 0 -a 6 hash.txt rockyou.txt ?d?d?d — добавит три цифры справа к каждому слову из rockyou. По бенчмарку с dev.to, именно гибридный режим помог вскрыть пароль вида password$K0a, где чистая dictionary attack не дала результата: базовое слово password было в словаре, но суффикс $K0a потребовал mask-расширения.

Маски для брутфорса Hashcat

Маска задаёт набор символов для каждой позиции пароля. Встроенные charset-плейсхолдеры:

• ?l — строчные латинские (a-z)
• ?u — заглавные (A-Z)
• ?d — цифры (0-9)
• ?s — спецсимволы
• ?a — все печатаемые (?l?u?d?s)
• ?b — полный байтовый диапазон (0x00-0xff)

Кастомные charset задаются через -1, -2, -3, -4. Пароль начинается с заглавной буквы, затем строчные и цифры? Маска — ?u?l?l?l?d?d.

# Маска: заглавная + 4 строчных + 2 цифры (SHA-256)
hashcat -m 1400 -a 3 hash.txt ?u?l?l?l?l?d?d
# Кастомный charset: только гласные + цифры
hashcat -m 0 -a 3 -1 aeiou0123456789 hash.txt ?1?1?1?1?1
# Инкрементальная длина от 4 до 8 символов
hashcat -m 0 -a 3 --increment --increment-min=4 --increment-max=8 hash.txt ?a?a?a?a?a?a?a?a

Бенчмарк на i7-9700K (по материалам dev.to): mask attack на SHA-256 с маской ?u?a?a?a?a (первый символ заглавный) — 11 секунд в JtR и 16 секунд в Hashcat на CPU. Полный brute-force ?a?a?a?a?a по тому же хэшу занял 42 секунды у обоих инструментов. Маска сократила время подбора в 2,6–3,8 раза.

На CTF маска критически важна, когда из условия задачи можно вывести паттерн пароля. «Пароль администратора, 6 символов, начинается с заглавной» — это ?u?a?a?a?a?a, а не полный ?a?a?a?a?a?a, который потребует в 3,5 раза больше времени. Разница между 30 секундами и двумя минутами — на CTF это целая вечность.

Rule-based атака — умный перебор

Правила мутации модифицируют слова из словаря по заданным шаблонам: добавить цифры в конец, заменить a на @, переключить регистр, перевернуть строку и сотни других операций. В Hashcat правила подключаются через -r: hashcat -m 1000 -a 0 hash.txt rockyou.txt -r /usr/share/hashcat/rules/best64.rule.

Популярные наборы правил:

• best64.rule — 64 наиболее эффективных правила, оптимальное соотношение скорости и охвата
• rockyou-30000.rule — 30 000 правил, агрессивный перебор
• d3ad0ne.rule — правила от сообщества хэшкрякеров, хорошо работают на реальных утечках
• toggles1.rule — переключение регистра в разных позициях

В JtR правила описываются в john.conf в секциях [List.Rules:...]. Синтаксис отличается от Hashcat: JtR использует собственный формат, Hashcat — формат, совместимый с oclHashcat-plus. Пересказывать спеку в сотый раз не вижу смысла — но разницу между ними стоит держать в голове, если пишете свои правила.

Собственные правила Hashcat пишутся за секунды. Основные операторы: $1 — добавить 1 в конец, ^! — добавить ! в начало, sa@ — заменить все a на @, c — capitalize (первый символ заглавный). Правило c$1$! превращает password в Password1!. Если контекст CTF-задачи подсказывает конкретный паттерн модификации — написать одно правило быстрее, чем ждать полный перебор.

Подключение best64.rule к rockyou.txt увеличивает число кандидатов с ~14 миллионов до ~900 миллионов. На быстрых хэшах вроде MD5 или NTLM это всё равно отрабатывает за секунды.

John the Ripper или Hashcat — что выбрать на CTF

Оба инструмента решают одну задачу, но подходят к ней по-разному. Согласно HashKitty (arxiv, 2025), Hashcat превосходит JtR по гибкости и производительности на GPU, автоматически распределяет задачи между несколькими видеокартами (JtR требует ручной настройки), поддерживает больше алгоритмов на GPU.

Для CTF выбор определяется задачей:

JtR берите, когда нужно извлечь хэш из файла (ZIP, PDF, SSH-ключ, KeePass) через *2john. Когда формат хэша неизвестен и нужно автоопределение. Когда работа идёт только на CPU (VPS без GPU, ноутбук на соревновании). В Kali он предустановлен — нулевой порог входа.

Hashcat — когда тип хэша известен и доступна GPU. Для mask attack с кастомными charset. Для rule-based атак с гибким синтаксисом правил. Для гибридных и комбинаторных атак, которые в JtR настраиваются сложнее.

На практике оптимальная стратегия — использовать оба. Извлечь хэш через *2john, попробовать JtR в режиме single crack (за секунду), затем переключиться на Hashcat для dictionary + rules на GPU. Это не взаимоисключающие инструменты, а звенья одной цепочки.

Wordlist для брутфорса: rockyou и кастомные словари

Словарь определяет потолок dictionary attack. Если пароля нет в словаре и ни одно правило его не породит — атака провалится на любом железе. Тут хоть десять GPU поставь.

rockyou.txt — стандарт де-факто для CTF: ~14 миллионов паролей из реальной утечки сервиса RockYou в 2009 году. В Kali Linux валяется по пути /usr/share/wordlists/rockyou.txt.gz (требует распаковки через gunzip). На CTF начального и среднего уровня абсолютное большинство паролей находятся именно в rockyou.

Для серьёзных соревнований стоит использовать расширенные списки из проекта SecLists (публичный репозиторий на GitHub): тематические словари по именам, городам, фразам из фильмов, IT-терминам. Утечка LinkedIn 2012 года (публично раскрыта в 2016) обнажила 164 миллиона пар email/пароль (по данным Have I Been Pwned) — хэши из подобных утечек активно используются сообществом для пополнения словарей и исследования паттернов.

Отдельная история — rainbow tables, предвычисленные таблицы соответствия «хэш → пароль». Они эффективны против unsalted raw-хэшей (MD5, SHA-1 без соли), но бесполезны против солёных форматов вроде SHA-512crypt или bcrypt. На CTF встречаются оба типа, так что выбор между rainbow tables и словарём с правилами зависит от конкретного задания. Для солёных хэшей словарь с правилами — единственный рабочий вариант.

На CTF контекст задания — главный источник для кастомного словаря. Задание содержит текст, картинку с именами или веб-сайт? cewl соберёт словарь из указанной страницы: cewl https://target-site.com -d 2 -m 5 -w custom.txt. Оптимизация словаря: sort -u для удаления дубликатов, awk 'length <= 20' для отсечения нереалистично длинных строк. Авторы тасков рассчитывают на разумное время решения — пароли длиннее 20 символов на CTF встречаются крайне редко.

Ускорение взлома паролей: GPU против CPU

Hashcat проектировался для GPU-вычислений и поддерживает CUDA (Nvidia) и OpenCL (AMD, Intel, Nvidia). По данным HashKitty (arxiv, 2025), Hashcat автоматически распределяет задачи между несколькими GPU — масштабирование тривиальное. JtR в версии 1.9.0-jumbo-1 поддерживает OpenCL для 88 форматов, при этом разработчики отказались от CUDA в пользу OpenCL как более портативного фреймворка.

Разница в скорости радикально зависит от типа хэша. Для «быстрых» алгоритмов (MD5, NTLM, SHA-1) одна современная GPU выдаёт миллиарды хэшей в секунду, тогда как CPU — десятки миллионов. Для «медленных» хэшей (bcrypt, scrypt, Argon2) разрыв значительно меньше: эти алгоритмы специально спроектированы так, чтобы GPU-ускорение давало минимальный выигрыш. Собственно, в этом их смысл.

Бенчмарк на i7-9700K (по материалам dev.to): brute-force MD5 на шестисимвольном пароле — JtR за 10 минут 53 секунды, Hashcat за 9 минут 57 секунд. Оба работали исключительно на CPU. На GPU тот же Hashcat выполнит эту задачу за секунды.

На CTF GPU-ускорение актуально в двух случаях: быстрый хэш с длинным паролем (mask attack на 8+ символов MD5) или большое количество хэшей (дамп на десятки записей). Для одиночного bcrypt-хэша с паролем из rockyou GPU даст минимальный прирост.

Проверить скорость на конкретном железе: hashcat -b -m 0 (бенчмарк MD5) или hashcat -b -m 1000 (NTLM). JtR: john --test --format=Raw-MD5. Эти цифры покажут реальный потолок и помогут оценить — стоит ли ждать или лучше пересмотреть стратегию атаки.

Подбор хэшей в CTF — пошаговый workflow

Решение CTF-таска с хэшем укладывается в конкретную последовательность. Каждый шаг занимает от секунд до минут — если понимать что делать.

Шаг 1: определить тип хэша. Длина, префикс, контекст задания. hashid или haiti при сомнениях. Нестандартный формат — привести к каноническому виду (убрать пробелы, декодировать Base64).

Шаг 2: проверить, нужна ли *2john. Если задание выдало файл (ZIP, PDF, SSH-ключ, KeePass), а не голый хэш — сначала извлечь хэш через соответствующую утилиту. В реальных атаках это аналог техники /etc/passwd and /etc/shadow (T1003.008) или Credentials from Password Stores (T1555).

Шаг 3: прогнать через rockyou.txt. На быстрых хэшах это секунды. Если пароль в rockyou — задание решено. На CTF начального уровня это срабатывает чаще, чем кажется.

Шаг 4: подключить правила. Повторить с best64.rule, затем с rockyou-30000.rule. Пространство поиска вырастает на два порядка.

Шаг 5: проанализировать контекст задания. Подсказки в описании, имена персонажей, тематика — всё в кастомный словарь. cewl для веб-страниц, связанных с заданием.

Шаг 6: маска, если известен паттерн. Из задания ясна структура пароля (длина, набор символов, первый символ) — маска в Hashcat отработает быстрее расширенного словаря.

Шаг 7: брутфорс — крайняя мера. Полный перебор оправдан только для коротких паролей (до 6 символов) на быстрых хэшах. Для 8+ символов с ?a — это часы даже на GPU.

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

Чек-лист: хэш не ломается — что проверить

Если ни словарь, ни правила, ни маска не дали результата — прежде чем наращивать мощность, пройдитесь по списку типичных технических ошибок.

Неверный hash mode / format. Самая частая причина. MD5 и NTLM — оба 32 символа hex, но hash mode разный (-m 0 vs -m 1000). SHA-512 и SHA-512crypt — разные алгоритмы (-m 1700 vs -m 1800). Hashcat не предупредит о несоответствии — просто не найдёт пароль. Молча.

Хэш повреждён или обрезан. Потеряли символ при копировании, обрезали newline, вставили лишний пробел. Проверить длину: MD5 = ровно 32, SHA-256 = 64, SHA-512 = 128. Несовпадение — хэш битый.

Проблема кодировки. Пароль содержит кириллицу, умлауты или другие символы за пределами ASCII. Hashcat по умолчанию работает с UTF-8, но некоторые системы хэшируют пароль в Latin-1 или CP1251. Флаг --encoding-to в Hashcat и --encoding в JtR задают нужную кодировку.

Соль не учтена. Для crypt-форматов (SHA-512crypt, bcrypt) соль встроена в сам хэш — отдельного указания не требуется. Проблема hash:salt vs salt:hash актуальна для raw-хэшей (например, -m 10 для md5($pass.$salt) или -m 20 для md5($salt.$pass)), где формат нужно указывать явно. Проверить через hashcat --example-hashes -m <mode>.

Конфликт pot-файла. JtR молча пропустит уже взломанный хэш, если результат в ~/.john/john.pot. Hashcat — аналогично с hashcat.potfile. Для чистого запуска: --potfile-disable в Hashcat или перенос pot-файла в JtR.

Хэш — не то, чем кажется. На CTF бывают ложные следы: строка выглядит как MD5, а на деле это Base64-фрагмент или часть другого формата. Потренировавшись на кошках, начинаешь такое чуять.

# Быстрая проверка: Base64 или hex?
echo "строка_из_задания" | base64 -d 2>/dev/null && echo "Base64"
# Проверка длины хэша
echo -n "d41d8cd98f00b204e9800998ecf8427e" | wc -c
# Сброс pot-файла JtR для повторного запуска
mv ~/.john/john.pot ~/.john/john.pot.bak

Большинство «неломаемых» хэшей — следствие ошибки на стороне решающего, а не криптографической стойкости пароля. Этот чек-лист экономит десятки минут на каждом соревновании.

На каждом CTF вижу одну и ту же картину: команда, которая потратила 5 минут на анализ задания и собрала кастомный словарь, обходит команду с арендованным GPU-кластером. Hashcat и JtR — инструменты с огромными возможностями, но мощность без стратегии не работает. Пароль на соревновании почти никогда не ломается грубой силой — он ломается пониманием контекста. Автор таска заложил подсказку в описание, в имя файла, в EXIF-данные изображения. Кто это заметил и собрал целевой словарь — решил задачу за минуту. Кто запустил ?a?a?a?a?a?a?a?a — ждёт до сирены.

Это не вопрос инструмента. Это вопрос мышления. И JtR, и Hashcat покрывают любой сценарий подбора хэшей — от dictionary attack до гибридных режимов. Собственные правила, кастомные charset, утилиты *2john для нестандартных форматов — каждая из этих возможностей сокращает пространство поиска на порядки, если применяется осознанно. Но осознанность приходит с практикой, а не с чтением writeups. Если хочется не просто разбор чужих решений, а системная прогрессия от подбора хэшей до полной цепочки пентеста — на WAPT это покрыто лабами с ментором на каждом этапе.

🚀 Хочешь закрепить на практике? Реши задачи по теме на HackerLab — категория «cryptography».