📎 Как быстро проверить, какие домены реально живые

httprobe — быстрый фильтр HTTP(S)-эндпоинтов без лишнего шума.

Что делает:

— Проверяет HTTP и HTTPS
— Работает параллельно
— Отдаёт только отвечающие URL

🟢 Установка

go install github.com/tomnomnom/httprobe@latest

🟢 Использование

cat domains.txt | httprobe > alive.txt

Идеальный первый шаг перед nuclei, ffuf, EyeWitness.

🔗 Ссылка на GitHub

🐸 Библиотека хакера

#tool_of_the_week

🔥 BGP-hijack: тихая атака на вашу сборку

Сценарий:

1️⃣ Злоумышленник анонсирует «более короткий» BGP-маршрут к npm-зеркалу или внутреннему registry

2️⃣ Часть трафика идёт через его автономную систему

3️⃣ MITM, подмена зеркала, вмешательство в доставку пакетов

4️⃣ CI получает модифицированную зависимость

Платформа не взломана. Но supply chain уже заражён. GitHub — сложная цель: Anycast, несколько аплинков, RPKI. Реалистичнее атака на менее защищённые зеркала или внутренние registry. Прецеденты есть: Rostelecom 2020, Pakistan Telecom → YouTube 2008, AS7007.

⚠️ Почему это критично:

— CI автоматически тянет зависимости
— Большинство проектов не проверяют подписи пакетов
— Lock-файлы не спасают без верификации integrity hash — а большинство CI гоняет `npm ci` молча
— Разработчики замечают проблему слишком поздно

Один hijack — и вредоносный код распространяется через ваши же сборки.

❓ Что реально мониторить:

— RPKI / Origin Validation — валиден ли анонс префикса
— AS-path в traceroute — неожиданные автономные системы в маршруте
— Резкие скачки latency и TTL
— Аномалии в логах CI при загрузке зависимостей

🛡 Практический вывод:

Современный периметр — это CI/CD. Минимальный уровень зрелости: внутреннее зеркало registry, кэш зависимостей, изоляция runner'ов, проверка checksum / подписи пакетов, мониторинг сетевых маршрутов.

Если защищён ноутбук, но не защищена сборка — атакующему даже не нужно писать эксплойт.

🔥 — видел BGP-аномалии в своей инфре
❤️ — уже защитил CI/CD
🌚 — у нас это вообще не мониторится

📍 Навигация: [Вакансии]

🐸 Библиотека хакера

#breach_breakdown

🔥 Топ-вакансий недели для хакеров

Менеджер проектов ИБ — от 70 000 до 100 000 ₽, офис (Ярославль)

Главный инженер отдела сетевой безопасности — офис (Москва)

Инженер по информационной безопасности — офис (Анапа)

➡️ Больше офферов в канале: @hackdevjob

🐸 Библиотека хакера

Ну филя 🕷

🐸 Библиотека хакера

#hack_humor

📌 Обновления инструментов за февраль

🟢 Burp Suite

Релизы 2026.1.x и 2026.2.x выходили весь февраль: исправления багов сканера, оптимизации запросов, улучшения расширяемости и поддержки расширений.

🟢 OWASP ZAP — релиз 2.17.0

✔ уменьшение шума в отчетах через alert de-duplication;

✔ Insights — новая вкладка аналитики;

✔ улучшение обработки памяти и диск-space ошибок;

✔ оптимизацию headless/CI-сканирования;

✔ структурированные отчеты с ISO 8601-датой.

🟢 Metasploit — свежие модули и фиксы

✔ новый набор exploit-модулей, включая RCE-эксплоиты для Xerte Online Toolkits;

✔ модуль для SolarWinds Web Help Desk с получением SYSTEM-сессии;

✔ улучшена поддержка MITRE ATT&CK-метаданных и LDAP-кэширования.

📍 Навигация: [Вакансии]

🐸 Библиотека хакера

#patch_notes

🔥 Вопрос с собеседования на Middle+ / Senior

Почему SSRF в AWS при использовании IMDSv1 может привести к компрометации инфраструктуры?

👇 Правильный ответ (нажми, чтобы прочитать):

Если через SSRF доступен 169.254.169.254 и на инстансе включён IMDSv1:

1️⃣ Можно получить временные credentials IAM-роли (instance profile)
2️⃣ Эти ключи дают права, назначенные роли
3️⃣ При избыточных IAM-политиках возможна privilege escalation
4️⃣ В худшем случае — полный контроль над AWS-аккаунтом

Важно понимать: «полный захват» происходит не из-за самого SSRF, а из-за небезопасных IAM-настроек.

IMDSv2 требует предварительный session token и проверяет hop-limit, что значительно усложняет эксплуатацию SSRF и закрывает большинство примитивных атак.

🏮 Что отличит сильного кандидата:

— упоминание STS и временного характера ключей
— проверка через aws sts get-caller-identity
— перечисление IAM и попытка AssumeRole / PassRole
— понимание влияния SCP и ограничений на уровне организации

👍 — знал/а
🔥 — стало понятнее

📍 Навигация: [Вакансии]

🐸 Библиотека хакера

#ctf_challenge

📌 Шпаргалка по настройке VPS за 13 шагов

Покупаешь новый сервер — и каждый раз заново вспоминаешь нужные команды.

🔵 Собрали всё в одну шпаргалку: от первого SSH-подключения до настройки firewall, SSH-ключей, Fail2Ban и автообновлений.

🔗 Оригинал статьи на Хабре

📍 Навигация: [Вакансии]

🐸 Библиотека хакера

#cheat_sheet

🔥 5 bypass-сценариев, которые дают реальный account takeover

🔘 Login CSRF → тихий захват аккаунта

Если state не проверяется или хранится криво — можно:

1. Авторизоваться через OAuth у себя

2. Подсунуть жертве ссылку на callback

3. Жертва «логинится» в ваш аккаунт

Дальше — phishing, data exfiltration, business-logic abuse.

🔘 Substitution attack через ID Token

Классика SPA:

Backend не проверяет:

• aud
• iss
• nonce
• подпись через JWK

Берём валидный id_token от другого клиента → отправляем в API → логинимся. Если нет строгой валидации claims — это ATO.

🔘 OAuth + Open Redirect = перехват кода

Сценарий:

1. redirect_uri проходит слабую проверку

2. Внутри него есть open redirect

3. Authorization code уходит на атакующий домен

4. Обмен кода → access_token

Это уже не просто баг — это полный доступ к аккаунту.

🔘 SSRF через OAuth metadata

Некоторые реализации динамически подтягивают:

/.well-known/openid-configuration

Если можно подменить issuer → сервер сам сделает SSRF.

Дальше:

• Внутренние сервисы

• Cloud metadata

• Credential leak

OAuth превращается в pivot.

🔘 Email collision → маппинг на чужой аккаунт

Приложение доверяет: email = уникальный идентификатор

Но:

• email_verified не проверяется

• Разные провайдеры могут вернуть одинаковый email

• Нет жесткой привязки к provider ID

Результат — silent account takeover.

📍 Навигация: [Вакансии]

🐸 Библиотека хакера

#breach_breakdown