🛠 Инструменты пентестера | Burp Suite

Продолжаем рубрику «Инструменты».
После разведки сети и сервисов (nmap)
логично перейти к анализу прикладного уровня.

Здесь на сцену выходит Burp Suite.

━━━━━━━━━━━━━━━━━━
🧠 ЧТО ТАКОЕ BURP SUITE
━━━━━━━━━━━━━━━━━━
Burp Suite — это инструмент для анализа и тестирования
веб-приложений и API.

Если nmap показывает *что* открыто,
то Burp позволяет понять:
👉 *как именно приложение общается с клиентом*.

━━━━━━━━━━━━━━━━━━
🎯 ЗАЧЕМ BURP НУЖЕН ПЕНТЕСТЕРУ
━━━━━━━━━━━━━━━━━━
Burp Suite позволяет:

• перехватывать и анализировать HTTP / HTTPS-трафик
• понимать логику запросов и ответов
• тестировать авторизацию и роли
• искать логические ошибки и trust-issues
• вручную проверять гипотезы

Это основной инструмент веб-пентеста.

━━━━━━━━━━━━━━━━━━
⚠️ ВАЖНЫЙ МОМЕНТ
━━━━━━━━━━━━━━━━━━
Частая ошибка — думать, что:
❌ Burp = автоматический взлом
❌ достаточно включить Scanner
❌ главное — знать кнопки

На самом деле Burp —
это лупа для анализа, а не магия.

━━━━━━━━━━━━━━━━━━
🧠 КАК ПЕНТЕСТЕР ИСПОЛЬЗУЕТ BURP
━━━━━━━━━━━━━━━━━━
Правильный подход:

1️⃣ Перехватить и изучить запрос
2️⃣ Понять, какие параметры реально важны
3️⃣ Задать вопрос: «А что если изменить это?»
4️⃣ Проверить гипотезу вручную
5️⃣ Только потом — автоматизация

━━━━━━━━━━━━━━━━━━
📘 ДОКУМЕНТАЦИЯ
━━━━━━━━━━━━━━━━━━
Официальный сайт:
https://portswigger.net/burp

━━━━━━━━━━━━━━━━━━
📌 ВЫВОД
━━━━━━━━━━━━━━━━━━
Burp Suite — это фундаментальный инструмент
для понимания веб-логики.

Он не ищет уязвимости «за вас»,
он помогает найти их самому.

#tools #nmap #pentest #base

OSI - модель, в пентесте без знаний данной модели делать нечего!

Очень важно при тестировании приложений знать на каком уровне происходят определенные процессы.

1️⃣ Физический уровень (Physical)

Передаёт биты по проводам, оптоволокну или через Wi-Fi.
Это сигналы, напряжение, частоты — чистая физика.

2️⃣ Канальный уровень (Data Link)

Упаковывает данные в кадры и передаёт их внутри одной сети.
Работает с MAC-адресами.

3️⃣ Сетевой уровень (Network)

Определяет маршрут передачи данных между сетями.
Работает с IP-адресами.
Главный протокол — IP.

4️⃣ Транспортный уровень (Transport)

Доставляет данные от приложения к приложению.
Контролирует скорость и целостность.
Примеры: TCP (надёжно), UDP (быстро).

5️⃣ Сеансовый уровень (Session)

Устанавливает, поддерживает и завершает соединение между устройствами.

6️⃣ Уровень представления (Presentation)

Отвечает за формат данных: шифрование, сжатие, кодировку.

7️⃣ Прикладной уровень (Application)

Самый «близкий к пользователю».
Протоколы: HTTP, FTP, SMTP, DNS.

В Испании задержали 20-летнего хакера, который годами жил в люксовых отелях, платя за ночи по одному евроценту

Вместо тысяч евро он вносил символическую сумму, пользуясь уязвимостью в системе онлайн-бронирования. Об этом сообщает информационное агентство Belga со ссылкой на заявление Национальной полиции...

⠀

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

⠀

В этой же гостинице испанец останавливался не раз. Общий ущерб отелю превысил 20 тысяч евро. При этом он активно пользовался мини-баром, заказывая напитки и закуски, которые входили в тариф, но по факту тоже не оплачивались...

⠀

Расследование началось после жалобы от турагентства 2 февраля. Внешне всё выглядело обычно: система показывала полную стоимость и стандартную процедуру оплаты. Обман вскрылся через несколько дней, когда платформа перевела компании реально уплаченную сумму – по центу за каждое бронирование.

⠀

В полиции уточнили, что подобного мошенничества в Испании ещё не фиксировали. Задержанному грозит уголовное дело преследование за компьютерное мошенничество. Отельеры теперь наверняка усилят контроль за платежами .

🔎 Web Pentest: Что делать, если открыт только 80 порт?

Сохрани себе. Это базовый алгоритм.

1️⃣ Первичный осмотр

— Открыть сайт в браузере
— Посмотреть исходный код страницы
— Проверить заголовки ответа сервера
— Проверить favicon (иногда палит CMS)
— Проверить robots.txt

2️⃣ Определение технологий

— Запустить whatweb
— Определить веб-сервер (Apache / Nginx)
— Определить язык (PHP / ASP / Node)
— Проверить версии

Пример команды:

whatweb http://TARGET

3️⃣ Directory / File Brute Force

/admin
/login
/backup
/uploads
/dev
/test
/api

Инструменты:
— gobuster
— feroxbuster

4️⃣ Анализ параметров

?id=
?page=
?file=
?search=

Проверяем:

SQL Injection
XSS
IDOR
LFI

Выложил подобный чек лист, так как часто при тестировании приложений нахожу, что открыт 80 порт, а это значит вся атака строится вокруг веба. Также не забываем проверять логику приложения, а именно:

— Можно ли менять ID вручную?
— Есть ли скрытые функции?
— Есть ли upload?
— Есть ли reset password?

✍️ Добавляйте в комментарии, на что еще нужно обратить внимание при обнаружении открытого 80 порта. Возможно у кого-то есть свои чек листы, будет интересно глянуть!

#practice #ctf

Подготовил небольшую задачку по прошлому посту🤔

Есть цель:

IP: 10.10.10.47

Результат сканирования:

PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http

Открываем сайт и видим:

“Welcome to our company website”

И больше ничего😳 Ни форм, ни ссылок...robots.txt пустой, технологий не видно.

👉 Вопрос:

Что ты делаешь дальше?

PS...тут нет “единственно правильного” ответа — интересен ход мыслей. Завтра выложу разбор

РАЗБОР ПРАКТИЧЕСКОЙ ЗАДАЧИ

Спасибо всем за обратную связь. Большинство мыслит в правильном направлении по поводу использования перебора директорий. Ниже расписал СВОЙ план действий:

1️⃣ Если страница выглядит пустой —
это НЕ значит, что нет скрытых директорий.

gobuster dir -u http://10.10.10.47 -w /usr/share/seclists/Discovery/Web-Content/common.txt

Очень часто на таких “пустых” сайтах находятся:
/admin
/dev
/test
/backup
/uploads

2️⃣ Проверяем поддомены

gobuster vhost ...
amass enum ...

Иногда основной сайт пустой,
а dev.site.local — живой.

3️⃣ Проверяем HTTP-методы

curl -X OPTIONS http://10.10.10.47 -I

Иногда открыт PUT 👀

Если сайт “пустой” —
значит копать нужно глубже.

Большинство машин ломаются не через “главную страницу”,
а через скрытый функционал.

Парни, хочу собрать всё своё мясо по Linux для пентеста в один короткий курс. Только практика, без воды. Цена будет в районе 39€.
Первым 10 участникам цена 29 евро + с вас отзыв
Кому актуально - ставьте 🔥, чтобы я знал, что тема вам интересна

Закинул в один свой паблик вот такой скрин и меня начали дизить за то, что я какую-то фейковую инфу публикую. Что типа нет таких зарплат в США, что это фейки все, что на одно место 500 человек, что ИИ забирает работу у киберщиков.

1) я не утверждал, что везде такие зарплаты, просто попалось - заскринил - отдал, понятно можно и за 80к устроиться на начальном этапе

2) фейки .... нет я слышал, что в сфере ИТ много фейковых вакансий, но меня стали уверять, что там 80% вакансий фейк. Что за бред? Откуда эта статистика ?

3) на одно место 500 человек. Я могу еще поверить про QA, что там 500, хотя не всегда и не везде, но чтобы на кибер, але народ) кибер - самая незаполненная сфера в ИТ

4) ии забирает работу у спецов по киберу, ля ни одного случая не слышал, чтобы забрали. Даже SOC у аналистов не забирает, хотя это по факту может первые претенденты на это.

Чем больше ИИ развивается, тем больше атак становится.

Я не понимаю, почему людям вот лишь бы засрать?
Один негатив в массы несут...

Я сам весной выхожу на рынок и я точно найду работу. И никакие ИИ, фейки и тд мне не помешают.

🏢 Основы инфраструктурного пентеста

Инфраструктурный пентест — это проверка
внутренней и внешней IT-инфраструктуры компании
на предмет уязвимостей, ошибок конфигурации и избыточного доверия.

Если веб-пентест — это «вход через приложение»,
то инфраструктурный пентест — это вход через сеть.

━━━━━━━━━━━━━━━━━━
🎯 ЧТО ПРОВЕРЯЕТСЯ
━━━━━━━━━━━━━━━━━━
В рамках инфраструктурного пентеста анализируются:

• внутренняя сеть
• серверы и рабочие станции
• сетевые сервисы и протоколы
• Active Directory (если используется)
• доверие между хостами и сегментами
• права пользователей и сервисных аккаунтов

Цель — понять:
👉 как атакующий может получить доступ
👉 как развить его
👉 до каких ресурсов можно добраться

━━━━━━━━━━━━━━━━━━
🧠 КАК МЫСЛИТ ПЕНТЕСТЕР
━━━━━━━━━━━━━━━━━━
Инфраструктурный пентест — это не про «одну уязвимость».

Это про цепочки:
• открытый сервис
• слабая конфигурация
• доверие внутри сети
• избыточные права
• развитие доступа

Часто каждая ошибка по отдельности — не критична.
Но вместе они приводят к полному компромиссу домена.

━━━━━━━━━━━━━━━━━━
🗺 ОСНОВНЫЕ ЭТАПЫ
━━━━━━━━━━━━━━━━━━
Классический подход выглядит так:

1️⃣ Разведка
• определение активных хостов
• открытые порты и сервисы

2️⃣ Анализ сервисов
• версии
• конфигурации
• типовые ошибки

3️⃣ Получение начального доступа
• слабые пароли
• misconfiguration
• legacy-сервисы

4️⃣ Развитие доступа
• lateral movement
• privilege escalation

5️⃣ Анализ AD (если есть)
• пользователи
• группы
• доверия
• политики

━━━━━━━━━━━━━━━━━━
🏗 ACTIVE DIRECTORY
━━━━━━━━━━━━━━━━━━
Active Directory — сердце корпоративной инфраструктуры.

Именно здесь чаще всего находятся:
• избыточные права
• устаревшие учётные записи
• слабые политики
• неправильные доверия

Поэтому AD почти всегда —
главная цель инфраструктурного пентеста.

━━━━━━━━━━━━━━━━━━
⚠️ ТИПОВЫЕ ОШИБКИ
━━━━━━━━━━━━━━━━━━
• отсутствие сегментации сети
• одинаковые пароли на сервисах
• устаревшие протоколы (SMBv1, NTLM)
• слишком широкие права пользователей
• отсутствие мониторинга

━━━━━━━━━━━━━━━━━━
🎯 ВЫВОД
━━━━━━━━━━━━━━━━━━
Инфраструктурный пентест —
это про понимание архитектуры и доверия,
а не про быстрые эксплойты.

Кто понимает инфраструктуру —
тот контролирует всю систему.

#infra #ad

Немного базовой теории про инфаструктуру мы рассмотрели, теперь ПРАКТИКА

Мы внутри корпоративной сети:

Сканируем хост и видим:

445/tcp   open  smb
3389/tcp  open  rdp
5985/tcp  open  winrm

Это обычная рабочая станция пользователя.
Доменная среда.

👉 Вопрос:

Куда полезем первым и почему?

PS...напоминаю, что в таких ответах нету “единственно правильного” ответа — интересен ход мыслей. Завтра выложу разбор

Спасибо за активность
В целом мне понравился ваш ход мыслей, но хотел бы немножко поправить (добавить).
Ваша цепочка выглядит так:
— null session
— guest session
— RID brute
— MS17-010 / SMBGhost
— PetitPotam
— проверка SMB signing
— Responder → NetNTLMv1
— relay на LDAP → RBCD / Shadow Credentials
—BlueKeep на RDP

Вроде ничего не пропустил🙈

Но правильно ли начинать с RCE-уязвимостей?

В реальном корпоративном сегменте:

MS08-067 — почти не встретишь
MS17-010 — редкость
BlueKeep — ещё реже
SMBGhost — тоже не массовая история

Возможно я смотрю со своей стороны, но на мой взгляд в 2026 году чаще ломают не CVE, а:

— неправильные права
— доверие
— reuse паролей
— misconfiguration

Также PetitPotam + relay — красиво, но…
Чтобы все сработало, нужно как минимум:
— не должно быть SMB signing
— должен быть уязвимый DC
—нужно правильное окружение

Это прям “цепочка при удачном стечении обстоятельств”.

Да и вообще когда мы начинаем сразу с:

MS17-010
BlueKeep
SMBGhost

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

Но в 2026 году большинство компаний:
— патчат критические RCE
— закрывают массовые эксплойты
— включают NLA
— включают SMB signing

А вот избыточные права и доверие внутри AD — живут годами.

Как по мне , то начинаем с SMB и ищем:
— структуру домена
— имена пользователей
— скрипты и конфиги
—отключена ли подпись SMB
— кто локальный админ на хосте
— доступ к шарам (особенно SYSVOL и NETLOGON)

И только потом:
— проверяем RCE
— тестируем экзотику
— пробуем relay

Мой пост удалили из профессиональной соц сети LinkedIn, якобы он нарушает сообщества, потому что я там ломаю API. Продублирую тут… думаю будет полезно …

——- вот сам пост ——-

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

Представьте: вы заходите на сайт, вводите свой логин и пароль. Всё стандартно.

Обычно мы смотрим на экран - там кнопка Войти и ваш профиль. Но если заглянуть под капот (в то, что сайт на самом деле присылает вашему браузеру), можно офигеть.

Я недавно проверял один тестовый дырявый сервис. Захожу в свой профиль, а в скрытом ответе от сайта вижу не только свои данные, но и… права администратора. Буквально строчка: isAdmin: false.

И знаете, в чем прикол? Я просто перехватываю этот ответ, меняю false на true - и сайт пускает меня в панель управления всеми пользователями. Я могу менять цены, удалять заказы и видеть чужие кошельки и тд

Теперь подробнее...
Что я сделал:
Зашел в наш дырявый сервис, залогинился под своим тестовым аккаунтом.
1) Нажал в браузере заветную кнопку F12 (Инструменты разработчика) и перешел во вкладку Network (Сеть). Это то место, где видно всё, что сайт отдает серверу.
2) Просто обновил страницу своего профиля.
Что я увидел под капотом: В списке запросов проскочил один с названием /api/v1/user/me. Я кликнул на него и посмотрел ответ сервера (Response).
На экране монитора было написано просто: "Hello, Vitali".

А в коде ответа прилетела целая гора данных, которые программист поленился скрыть: { "id": 554, "name": "Vitali", "role": "user", "balance": 100, "isAdmin": false }

Теперь магия..: Я использовал простую бесплатную утилиту (прокси-перехватчик), поймал этот запрос на лету и прямо в коде поменял: "isAdmin": false -> на -> "isAdmin": true

Результат: Сайт поверил моему браузеру. Страница обновилась, и у меня в меню появилась кнопка Панель администратора. Я зашел туда и увидел список всех заказов, адреса покупателей и их карты.

Почему для вас как QA это супер круто знать?
Обычный QA этого не видит. Обычный тестер кликает по кнопкам и видит, что всё работает. А то, что в коде страницы летит лишняя инфа - никто не смотрит.

Это стоит дорого: За один такой найденный переключатель компания готова платить премии, потому что это прямой доступ к их бабкам и данным. Потерять репутацию и получать штрафы от регуляторов никому не охото, поверьте....

Ну ок, пусть премию не дадут может, но поверьте, вас точно заметят и запомнят, гарантирую.

PS: это пример в специально тестовом дырявом сервисе, но на практике такое спокойно может встретиться...

Я до сентября решил вытаскивать всю эту изнанку сюда и в Link. Пока все учат теорию тестирования(что безусловно тоже важно), я буду показывать, как видеть систему насквозь и стоить на рынке тупо дороже.

Что думаете? Это реальные баги, которые могут быть в системе …

Начинаем неделю правильно (с практики😂)

В доменной сети ты получил обычную учётку пользователя.

При выполнении команды:

whoami

видишь:

corp.local\ivan

👉 Вопрос:

Что из этого ты можешь сделать без повышения привилегий?

A) Получить список всех пользователей домена
B) Прочитать SYSVOL
C) Сделать Kerberoasting
D) Подключиться к любой машине по RDP

Напиши буквы в комментариях 👇
Разбор завтра.

5 логических дыр в API, которые не видят автотесты

В LinkedIn я привел пример с подменой ID. Здесь разберем глубже. Автоматика проверяет функцию (работает/не работает), человек проверяет логику (злоупотребление процессом).

Вот 5 сценариев, которые я рекомендую проверять в первую очередь:

1. IDOR / BOLA (Подмена ID)
Самое простое и самое частое. Вы авторизованы как user_id=100, но меняете параметр в запросе на user_id=101. Если сервер отдает чужие данные - это дыра.

Где искать: Смена пароля, просмотр профиля, скачивание счетов.

2. Mass Assignment (Лишние права)
При регистрации или обновлении профиля вы отправляете JSON. Попробуйте дописать туда поле, которого нет в форме.

Пример: К вашему имени и почте добавьте "role": "admin" или "balance": 99999. Иногда сервер слепо записывает эти данные в базу.

3. Отсутствие проверки на владение ресурсом
Вы можете удалить свой комментарий по ID=500. А можете ли вы отправить запрос на удаление комментария ID=501, который написал другой человек?

Суть: Сервер проверяет, что вы залогинены, но забывает проверить, что удаляемый объект принадлежит именно вам.

4. Игры со статусами (Business Logic Flaw)
Вы отменяете заказ и получаете возврат денег. Что будет, если отправить запрос на отмену заказа, который уже доставлен? Или применить промокод на скидку, а потом удалить товар из корзины, сохранив скидку на остальное?

5. Информация в скрытых полях
Часто API отдает в браузер гораздо больше данных, чем видит пользователь на экране.

Пример: Вы запрашиваете краткую инфу о коллеге, а в скрытом JSON-ответе прилетает его номер телефона, домашний адрес и хэш пароля. Это называется Excessive Data Exposure.

Пользуйтесь!

Публикуем разбор к вчерашней практике

Правильные ответы: A, B, C

✅ A — список пользователей

Любой доменный пользователь может читать AD-объекты.
Это база для дальнейшей атаки.

✅ B — SYSVOL

Папка SYSVOL доступна на чтение всем доменным пользователям.
А там могут быть:

— скрипты
— конфиги
— старые GPP с паролями

✅ C — Kerberoasting

Любой доменный пользователь может запрашивать TGS для сервисных аккаунтов с SPN.

А дальше — оффлайн-брут хеша.

❌ D — RDP ко всем

Нет. Нужны права.
По умолчанию обычный пользователь не может RDP-шиться куда угодно.

Кто также думал отмечаемся реакцией 👍, кто не согласен с моими ответами, пишите в комменты обсудим.

Кейс на $40 000 за одну ночь. Как ложится бизнес-логика
Сегодня в LinkedIn я закинул тему про Race Condition
Теперь к деталям.
Многие думают, что взлом - это подбор пароля. В реальности это использование тупости архитектуры.

Суть кейса о котором я как-то читал на реддите: Один крупный ритейл запустил акцию с промокодами. Промокод одноразовый, привязан к ID пользователя. Разработчик поставил проверку:
1. Юзер вводит код.
2. Система лезет в БД: Использовал ли юзер этот код?
3. Если нет - применяет скидку и ставит в БД отметку Использовано.

Где жесть: Между пунктом 2 (проверка) и пунктом 3 (запись в базу) проходит доля секунды. Если отправить не один запрос, а 50–100 одновременно (используя обычный Turbo Intruder в Burp Suite), система не успевает обновить статус Использовано.

В итоге: база на 100 запросов отвечает Да, код еще не использован. Юзер получает 100 скидок на один чек.

Результат: Товар стоимостью $400 уходил за $4. За ночь, пока админы спали, нагенерили заказов на сорок тысяч долларов убытка. Автотесты этот сценарий не ловили, потому что они не проверяют многопоточность на один и тот же ресурс.

Почему это происходит? Потому что Senior-разработчик за 500к+ не подумал о блокировках в базе данных. Он думал о том, как красиво отрендерить фронтенд.

К чему я это: Пока вы учите, как центрировать div или писать тесты на зеленую кнопочку, мимо вас пролетают реальные деньги и реальные задачи.

В AppSec платят за то, что вы находите такие косяки ДО того, как их найдет школьник с прямыми руками. Это не программирование. Это понимание того, как на самом деле бегают данные между серверами. Ну и конечно понимание архитектуры

Кто сталкивался с Race Condition в проде? Пишите в комментах