Я вообще думал что cudahashcat и oclhashcat - это уже давно не рабочие инструменты, и что hashcat заменил их оба!!!

подскажите, а если в базе данных более 10к пользователей?! можно каким то образом не дампить всех пользователей а именно админа? и как понять кто из них админ. что-то я не догоняю

Конечно можно, самый простой способ это указать id в запросе, по-умолчанию id админа равен 1 (прошаренный админ сменит id, но это случается нечасто). Как-то так примерно:
SELECT * FROM login WHERE id=1

Подскажи как указать это sqlmap? Я понял что за параметр, но как это протолкнуть в проге? И еше, админу могут держать свою инфу в недоступной для данного пользователя MySql?

Очень просто:
sqlmap -u http://vulnsite.php?id=1 -D db_name --where="id=1" --dump

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

Может ли лежать пароль от админки сайта в information_schema? или в базе данных?

Не может, а с вероятностью 99% именно в базе данных он и лежит. И с вероятностью более 90% он будет захеширован, то есть пароль находится не в открытом виде. Пример из дампа БД:

Всем привет, античат !

Предыдущая часть: SQLMAP: гайд по SQL-инъекциям и обходу WAF (2025)

Подробный гайд, который часто просят новички. Разберём классический сценарий — эксплуатация SQL-инъекции с помощью связки SQLMap + Hashcat. Пройдём весь путь от получения структуры базы данных до взлома пароля.

Важно: всё, что вы увидите ниже — полностью вымышленный сценарий. URL, база данных и хеши созданы специально для этого руководства. Цель — научиться работать с инструментами, а не ломать реальные сайты. Помните об этике и законодательстве. Погнали!

Представим, что мы уже нашли уязвимый параметр на неком сайте. Наш старт — вот этот URL:
.
Шаг 1: Разведка. Узнаём столбцы в таблице
Первым делом нужно понять, какая структура у таблицы, где, как мы предполагаем, лежат данные пользователей. Наша цель — найти поля с логином и паролем в таблице
внутри базы
.

Команда:

Bash:

• Код:

  -u

  — наш целевой URL. Берём его в кавычки, это хорошая привычка.
  
• Код:

  -D

  — указываем имя базы данных, которое мы могли узнать на предыдущих этапах разведки.
  
• Код:

  -T

  — конкретная таблица, которая нас интересует.
  
• Код:

  --columns

  — команда, которая говорит SQLMap: «Эй, покажи-ка мне все столбцы из этой таблицы».

Что вернёт SQLMap:

Код:


Отлично, столбцы
и
на месте. Это наши цели.
Шаг 2: Получаем имена пользователей
Теперь, когда мы знаем, где искать, давайте вытащим логины. Это полезно, чтобы убедиться, что в таблице вообще есть данные.

Bash:


Тут всё знакомо, кроме двух флагов:

• Код:

  -C user_login

  — говорим, что нам нужен только столбец с логинами.
  
• Код:

  --dump

  — команда для извлечения (дампа) данных.

Примерный вывод:

Код:


Супер, у нас есть пользователь
. Теперь самое интересное.
Шаг 3: Извлекаем хеш пароля
Действуем по аналогии, но теперь наша цель — столбец
.

Bash:


Результат:

Код:


SQLMap, скорее всего, сам подскажет, что это похоже на хеш и предложит его взломать. Но мы сделаем это вручную, чтобы понять процесс.
Шаг 4: Определяем тип хеша
Что это за строка
? С опытом вы будете узнавать некоторые хеши «в лицо», но для надёжности воспользуемся утилитой из Kali Linux —
.
Вводим наш хеш:

Код:


Как и предполагалось, это старый добрый MD5. Очень небезопасный по нынешним меркам, но всё ещё встречающийся в старых системах.
Шаг 5: Крашим хеш с помощью Hashcat
Финальный рывок. Создаём файл
и записываем в него наш хеш. Затем запускаем тяжёлую артиллерию — Hashcat.

Bash:


Разберём эту магию:

• Код:

  -m 0

  — это код режима для MD5. Для каждого типа хеша у Hashcat есть свой код.
  
• Код:

  -a 0

  — режим атаки. Ноль — это классический перебор по словарю (Straight).
  
• Код:

  hash.txt

  — наш файл с хешем.
  
• Код:

  /usr/share/wordlists/rockyou.txt

  — путь к знаменитому словарю. Если у вас его нет, обязательно установите.

Итог работы Hashcat:

Код:


Победа! Пароль —

Код:

abc123

.

Конечно, наш вымышленный пример был довольно простым. В реальных задачах всё бывает куда интереснее: фильтры, кастомное хеширование и многоуровневая защита. Чтобы увидеть, как похожие техники применяются на практике, очень советую почитать разборы (райтапы) с CTF. Там можно подсмотреть много полезных фишек.

Вот, например, пара свежих разборов веб-заданий от наших форумчан:

• Квантовый прорыв WriteUp: разбор задач CTF-вызова
  
• Форум предсказателей: Writeup и разбор задачи

Мораль и защита: что нужно знать
А теперь самое главное. Мы всё это делали не ради взлома, а чтобы понять, как защищаться.

1. Не доверяйте данным. Всегда проверяйте команды и имена, которые вы используете. Опечатка в имени таблицы или столбца — и вы впустую потратите время.
   
2. Хеширование — это не шифрование. Наш пример с MD5 идеально показывает, почему он плох. Его можно быстро взломать перебором по словарю. В 2025 году использовать MD5 для паролей — преступление. Смотрите в сторону bcrypt, scrypt или Argon2, которые являются адаптивными и требуют больших вычислительных ресурсов для взлома.
   
3. Этика и закон. Ещё раз: все эти действия легальны только в рамках официального тестирования на проникновение (пентеста) или на собственных учебных стендах. На форуме
   
   Код:

   codeby.net

   мы за белый хакинг.
   
4. Главная защита от SQL-инъекций.
   • Параметризованные запросы (Prepared Statements): Это основной и самый надёжный способ. Он разделяет код SQL-запроса и данные, не давая пользователю вмешаться в логику запроса.
     
   • ORM (Object-Relational Mapping): Фреймворки вроде Django, Ruby on Rails или Laravel используют ORM, которые в большинстве случаев автоматически создают безопасные запросы.
     
   • WAF (Web Application Firewall): Хороший дополнительный уровень защиты, который может отфильтровать вредоносные запросы ещё на подлёте.
     
   • Принцип наименьших привилегий: Учётная запись, от имени которой веб-приложение подключается к БД, не должна иметь прав на всю базу данных. Только на те таблицы и операции, которые ей реально нужны.
5. Профессиональный рост. Понимание таких атак — это только первый шаг. Чтобы развиваться в пентесте и превратить это в профессию, нужен системный подход. Кстати, на античат есть отличная статья о том, как спланировать свой путь в эту сферу, особенно если вы переходите из другого IT-направления.

Итак, наш путь в пяти шагах:

1. Разведали структуру таблицы через
   
   Код:

   --columns

   .
   
2. Вытащили логин и хеш пароля с помощью
   
   Код:

   --dump

   .
   
3. Определили тип хеша — MD5.
   
4. Подобрали пароль (
   
   Код:

   abc123

   ) через Hashcat.
   
5. Сделали выводы о том, как строить надёжную защиту.

Надеюсь, этот разбор был полезен. Если есть вопросы или хотите обсудить другие сценарии — пишите в комментариях!