🔍 OSINT: почему не только Google?

Большинство при поиске информации используют только Google
и теряют кучу данных😏

📌 Важно понимать

Google — не единственный источник

Иногда:

Yandex и Bing дают больше, чем Google

🔥 Yandex

👉 особенно силён в:

— поиске по СНГ
— индексировании “старых” страниц
— поиске изображений

Часто находит то, чего нет в Google

⚡️ Bing

underrated инструмент

— иногда показывает другие результаты
— лучше индексирует некоторые сайты
— полезен для альтернативного поиска

💀 Почему так происходит

Каждый поисковик:

— индексирует разные сайты
— по-разному ранжирует
— имеет свои фильтры

поэтому результаты отличаются

🧠 Как использовать в OSINT

не ограничивайся одним поисковиком

Пробуй:

— Google
— Yandex
— Bing

и сравнивай результаты

🔥 Пример

— не нашёл через Google?

Попробуй:

— тот же запрос в Yandex
— или Bing

шанс найти выше✍️

OSINT — это про поиск

чем больше источников — тем больше данных

#osint #recon

🐙 GitHub Dorks — как находят пароли и ключи

Многие ищут только через поисковики, которые рассмотрели выше☝️
Но забывают про один из самых жирных источников 👇

✅ GitHub

Разработчики часто:

— пушат код
— забывают удалить ключи
— оставляют токены
— сливают конфиги

и всё это лежит в открытом доступе

🔥 Что можно найти

— API-ключи
— токены
— пароли
— конфиги (.env)
— доступы к сервисам

⚡️ Примеры dorks

👉 поиск API ключей:

`id="gh1"
"api_key" "password"

👉 поиск .env файлов:

id="gh2"
filename:.env

👉 поиск AWS ключей:

id="gh3"
"AWS_SECRET_ACCESS_KEY"

поиск токенов:

id="gh4"
"authorization: Bearer"

👉 ищем пароли в конфиге

id="gh5"
filename:.env DB_PASSWORD

💀 Почему это работает

человеческий фактор

— забыли удалить
— закоммитили случайно
— не проверили

⚠️ И НАПОМИНАЕМ!
— используем только в рамках закона
— не злоупотребляем найденными данными

GitHub — это не только код

это огромная база утечек

#osint #recon

Объявляю набор на месячный интенсив по SECURITY TESTING.

— Пройдемся по методологи OWASP / OWASP API
— В течении 10-12 часов мы разберем с вами XSS инъекции на реальных примерах
— Поймем, что такое BOLA/IDOR и как можно атаковать / защищать API.
— Будем искать уязвимости в бизнес-логике
—Будем работать с Postman / OWASP Zap.

Кому подойдет?
— QA инженерам в первую очередь
— Разработчкикам
— Всем начинающим, кто хочет пощупать, что такое безопасность

Требования
— Компьютер/лаптоп хотя бы от 4-6 гб RAM
— Интернет соединение
— Желание

Есть домашние задания с моей проверкой

По окончанию каждому, кто прошел интенсив, даю сертификат

Этой мой первый поток именно по секьюрити, поэтому цену поставил подешевле, со второго потока
цена будет в 2 раза выше.

В группе до 10 человек

За подробностями пишите мне в ТГ @faroeman

SQL Injection в 2026 году: Одна ошибка - и ваша база данных в Darknet :)

Казалось бы, мы в 2026 году. У нас есть квантовые вычисления, продвинутый ИИ и беспилотные такси.

Но старый добрый SQL Injection всё еще в топе OWASP и всё еще позволяет хакерам сливать гигабайты данных за считанные минуты.

Почему это всё еще работает?
--- Наследие (Legacy): Код, написанный 10 лет назад, до сих пор крутится в бэкенде крупных корпораций.

--- Сложные API: Современные микросервисы общаются через сотни эндпоинтов, где валидация данных иногда проседает.

--- ИИ на службе у хакеров: Если раньше атакующему нужно было подбирать кавычки вручную, то сегодня LLM-агенты автоматически сканируют код и находят слепые (blind) инъекции там, где их не видел статический анализатор.

Как выглядит слив всей базы сегодня?
Достаточно одного незащищенного поля в поиске или заголовке HTTP-запроса. С помощью техники UNION SELECTили автоматизированных инструментов (вроде прокачанного sqlmap) злоумышленник:
--- Обходит аутентификацию.
--- Получает список всех таблиц.
--- Выгружает персональные данные пользователей (PII).

В худшем случае - получает доступ к файловой системе сервера.

Итог: Репутационные потери, огромные штрафы по GDPR и полная остановка бизнеса.

Как не стать героем новостей о взломе?
--- Забудьте про конкатенацию строк. Только Parameterized Queries (Prepared Statements). Это база.

--- ORM - не панацея. Даже популярные библиотеки могут иметь уязвимости в методах вроде .raw(). Проверяйте, что вы туда передаете.

--- Принцип наименьших привилегий. У пользователя базы данных, под которым работает веб-приложение, не должно быть прав DROP TABLE или доступа к системным таблицам.

--- WAF с поддержкой ИИ. В 2026-м обычные регулярные выражения не спасают. Нужны системы, анализирующие поведение и аномалии в запросах.

Главный урок: Безопасность - это не разовое действие, а процесс. Если вы не проверяли свои старые сервисы последние полгода, скорее всего, они уже под прицелом.

А как часто вы проводите аудит безопасности своих SQL-запросов? Рассказывайте!

#cybersecurity #SQLi #infosec #webdevelopment #programming #2026tech #data-protection

Сегодня работаю с SOAP и XML. Если вы думаете, что в 2026 SOAP никому не нужен и его никто не использует, вы глубоко ошибаетесь.

Не представляете, сколько написано легаси софта(особенно fintech) на SOAP.

В чем его преимущество? Безопасность.

В чем его проблема? Не гибкость, более сложная архитектура.

Проблема в том, что все помешаны на REST API, и мало кто знает детали SOAP и его внутрянку.

Хотя можно спокойно (конечно нет) делать XXE инъекции и получать все данные с хоста.

Уязвимости в SOAP - это на самом деле ад для компании. Можно слить все данные одним кривым XML.

Например, как на скрине (тестовая машина)

Хотел бы немного практики и ваших советов🤔

Вчера проводил пентест локальной сети и через nmap нашёл интересный сервер, к которому нужно получить доступ🙈

Вот что показал скан:

80/tcp   open  http          Microsoft IIS httpd 10.0
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
3389/tcp open  ms-wbt-server
5985/tcp open  http          WinRM

Более углубленно начав тестировать по отдельности каждую службу и получил, что:

1️⃣ SMBv1 включён

NT LM 0.12 (SMBv1)

👉 legacy-конфигурация

2️⃣ SMB signing disabled

message_signing: disabled

👉 уже интереснее с точки зрения конфигурации

3️⃣ WinRM открыт

5985/tcp

👉 PowerShell Remoting / удалённое администрирование

4️⃣ RDP открыт

3389/tcp

👉 удалённый рабочий стол

💀 Но проблема вот в чём
OS:

Windows Server 2022 Standard 20348

И нормальных рабочих векторов пока не нашёл 😐 Очень хотел бы зайти со стороны SMB и долго ковырял CVE-2022-26810

Но ничего интересного не вышло.

💬 Может кто-то сталкивался с Windows Server 2022? С какой стороны можно зайти в моем случае?
или же у кого-то получилось запустить CVE-2022-26810 и он полноценно отработал?

#practice #real

А вы знали, что ваша интеграция со сторонним API - это большая дыра в безопасности?

Многие разработчики совершают одну и ту же ошибку: они тщательно проверяют данные от пользователей, но полностью доверяют данным, которые приходят от других сервисов (Stripe, GitHub, системы аналитики).

Это и есть OWASP API10:2023 - Unsafe Consumption of APIs.

В чем реальная опасность?
Если сторонний сервис будет взломан или скомпрометирован, он пришлет вам вредоносные данные. Без проверки ваш сервер обработает их как легитимные, что приведет к SQL-инъекциям, выполнению стороннего кода (RCE) или отказу в обслуживании (DoS).

Чек-лист для защиты:
Валидация по схеме:
- Всегда проверяйте, соответствуют ли пришедшие данные ожидаемому формату, типу и длине.
- Не принимайте лишние поля.
- Тайм-ауты и лимиты: Установите жесткие ограничения на время ожидания ответа и размер передаваемых данных, чтобы сторонний сервис не положил ваш бэкенд.
- HTTPS и сертификаты: Используйте только зашифрованные соединения и проверяйте валидность SSL-сертификатов.
- Санитизация: Очищайте входящие строки от спецсимволов перед тем, как передавать их в базу данных или отображать в интерфейсе.

Главное правило: любой ответ от внешнего API - это такой же небезопасный ввод, как и текст из поисковой строки браузера.

Как вы обрабатываете ответы от внешних сервисов в своих проектах? Используете готовые библиотеки для валидации схем или проверяете вручную?

В общем, удачи в тестировании!

Запись на группу по security testing еще открыта (телеграм @faroeman)
#API #Security #Backend #OWASP #Development

Всем привет!

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

Поэтому в понедельник, заряженный энергией и новыми идеями, я снова вернулся к локальной сети 😄

И начал с самого очевидного

— Поднял Responder. аккуратно

И буквально в течение нескольких минут словил 4 хеша от разных пользователей 😐

А дальше уже сообщение от Evil-WinRM :
— хеш отработал.✅

На рабочем столе одного из пользователей лежали RDP-подключения к серверу, где и находилось всё самое интересное, что в итоге и пойдёт в отчёт заказчику 😅

ВЫВОД:

Не всегда нужно ломиться в самую “сложную” машину.

Очень часто:
— есть обходные пути
— слабым местом оказывается инфраструктура
— или человеческий фактор

🔥 Спасибо всем за советы и активность. Постараюсь делать такие обзоры чаще и в ближайшее время сделаю обзор на чудо-инструмент ИИ , который мне помогал при тестировании данной задачи.
По скрину немного можно увидеть его интерфейс

#practice #real

Для наглядности собрал весь сценарий в одну схему☝️

🤖 После опроса и обсуждений в чате понял одну интересную вещь…

Многие до сих пор воспринимают ИИ просто как:
👉 “спросить что-то у ChatGPT”.
А некоторые даже и с gpt слабо знакомы.

Но сейчас AI в ИБ — это уже намного больше ⚡️

Долгое время я сам пытался обходиться без ИИ именно в пентесте.

Понятно, что:
— писать код
— автоматизировать рутину
— генерировать скрипты

без ИИ сейчас уже тяжело 😄

Вайбкодинг вообще стал отдельным явлением.

Но вот именно использовать AI в самом пентесте я начал относительно недавно.

И, честно говоря, некоторые результаты меня удивили и продолжают удивлять🤔

📌 Потому что одно дело:

👉 спросить у ChatGPT:
“что такое XSS?”

А другое:
— поднять модель локально
— подключить её к инструментам
— и использовать для анализа веб-ресурса или поиска уязвимостей в локальной сети.

И этим тоже надо уметь пользоваться. Да и это не все так просто как кажется со стороны. На данный момент у нас в команде более 20 человек трудится над созданием своей модельки АI - агента. Для этого очень точно нужно все расписать в документации и обучить этим моментам саму модель.

🧠 И дальше начинается самое интересное

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

Особенно если правильно его использовать, а не просто задавать “общие вопросы”.

Уже сейчас умение работать с AI станет таким же важным навыком, как:
— Linux
— Burp Suite
— Nmap

Да и я уже подумываю выделить в нашей базе знаний отдельную ветку под AI 🤔. Подкиньте реакций если поддерживаете мою идею)

Где можно будет:
— обсуждать модели
— локальные LLM
— AI-агентов
— автоматизацию
— использование AI в пентесте и OSINT

💬 А вы что используете на данный момент и почему?

ChatGPT?
Claude?
Локальные модели?
Или вообще пока не внедряли AI в работу?

#mindset #base

🤖 Периодически сижу на форумах и задаю различные вопросы

И почти всегда даже на самый, казалось бы, глупый вопрос прилетают действительно умные мысли.

И вот один из последних вопросов был:

👉 “Как вообще тестировать IP-камеры и IoT-устройства внутри локальной сети?”

На что мне ответили максимально просто:

👉 ai iot pentest “Вбей это в Google и всё поймёшь” 😄

И вот следующие пару дней я просто сидел и изучал различные статьи, проекты и инструменты по теме AI + IoT Pentest.

И особенно меня впечатлила одна статья на Habr
После её изучения захотелось:
— протестировать сам инструмент
— поковыряться глубже
— а позже даже связаться с автором статьи и обсудить его опыт использования этого инструмента
И, честно говоря, меня это очень впечатлило 🔥

🧠 Мы уже начали обсуждать тему ИИ в пентесте, и я говорил, что сам начал активно экспериментировать с AI относительно недавно.
Но именно HEXSTRIKE-AI стал для меня одним из тех инструментов, после которых начинаешь немного иначе смотреть на автоматизацию в ИБ.

⚡️ Что интересно
HEXSTRIKE-AI совсем недавно добавили в Kali Linux.
И по сути это уже не просто “чатик с ИИ”.
👉 HexStrike AI — это полноценная AI-платформа для offensive security, которая объединяет:
— классические pentest-инструменты
— автоматизацию
— AI-агентов
— анализ уязвимостей
— recon
— CTF workflow

📌 Особенно интересен сам подход
Система построена вокруг multi-agent архитектуры.
То есть AI не просто отвечает на вопросы, а:
— анализирует
— принимает решения
— строит цепочки действий
— помогает двигаться дальше по сценарию атаки
💀 На Habr очень интересно расписано, как связка:
👉 OpenCode + HexStrike AI
решает задачи CTF даже на бесплатной модели.
И это уже выглядит не как “игрушка”, а как полноценный инструмент для практики и автоматизации.

🧠 Из своего опыта пока могу сказать так:
В разведке и анализе поверхности атаки использовать такие инструменты очень полезно.
Но:
👉 чтобы нормально управлять AI и понимать, что он делает — базовые знания всё равно необходимы.
Потому что без понимания:
— сетей
— Linux
— веба
— инфраструктуры
AI легко может увести вообще не туда 😄 И например, подобрать пароль к камерам запустить нужный эксплойт у меня не получилось

🔥 Но сам факт того, что подобные AI-инструменты уже появляются прямо внутри Kali Linux — очень показательный.
Мне кажется:
👉 это только начало очень больших изменений в пентесте.

#AI #pentest #kali

Многие думают, что информационная безопасность — это просто:
“хакеры и защитники”

Но на практике направлений и команд в ИБ намного больше

Хотелось бы разобрать основные, чтобы навести порядок в голове😁

🔴 Red Team — атакующие

Это offensive security.

👉 задача:
имитировать действия реального злоумышленника.

📌 Чем занимаются:

— пентест
— social engineering
— фишинг
— обход защит
— эксплуатация уязвимостей
— lateral movement

💡 По сути:
“показать, как компанию могут взломать”

🔵 Blue Team — защитники

Это defensive security.

👉 задача:
обнаружить и остановить атаку.

📌 Чем занимаются:

— мониторинг
— анализ логов
— SIEM
— EDR/XDR
— реагирование на инциденты
— threat hunting

💡 По сути:
“не дать компании упасть после атаки”

🟣 Purple Team

Связующее звено между Red и Blue.

👉 задача:
не “соревноваться”, а улучшать защиту вместе.

📌 Чем занимаются:

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

💡 Purple Team часто сильно бустит зрелость ИБ внутри компании.

🟠 SOC (Security Operations Center)

Отдельное направление, но чаще относится к Blue Team.

👉 это центр мониторинга безопасности.

📌 SOC-аналитики:

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

Именно SOC обычно первым видит атаку.

🕵️ Threat Intelligence

Разведка угроз.

👉 задача:
изучать злоумышленников, группы и новые техники атак.

📌 Чем занимаются:

— анализируют malware
— отслеживают APT-группы
— изучают IOC
— собирают threat intel

⚡️ DFIR

Digital Forensics & Incident Response

👉 цифровая криминалистика и расследования.

📌 Чем занимаются:

— расследуют инциденты
— анализируют заражения
— восстанавливают цепочку атаки
— изучают дампы памяти и диски

💡 Это уже ближе к “кибердетективам”.

🌐 AppSec (Application Security)

Безопасность разработки.

👉 задача:
делать приложения безопасными ещё на этапе разработки.

📌 Чем занимаются:

— secure code review
— threat modeling
— SAST/DAST
— DevSecOps
— CI/CD security

☁️ Cloud Security

Безопасность облаков.

Сейчас очень быстро растёт 👀

📌 Чем занимаются:

— AWS / Azure / GCP security
— IAM
— Kubernetes
— контейнеры
— cloud misconfiguration

🤖 AI Security (новое направление)

Сейчас начинает очень активно расти.

📌 Чем занимаются:

— безопасностью AI-моделей
— AI agents
— prompt injection
— AI-assisted pentest
— защитой LLM


И мне кажется, что ближайшие годы это направление очень сильно вырастет.


Что важно понимать новичку

👉 ИБ — огромная сфера.

Кому-то ближе:
— атака
— защита
— аналитика
— расследования
— разработка
— AI


#mindset #base

Нужно ли использовать ИИ в кибербезе?
Давайте по-честному, кибератаки поменялись, это не 2019 год.
Злоумышленники больше не действуют вручную - они используют автоматизацию (как и защитники), дипфейки и тот же генерированный ИИ для создания фишинга нового поколения и мгновенного поиска уязвимостей.

В этих реалиях классический подход ‘человеку против машины’ 100% проигрывает по всем фронтам.

Именно поэтому интеграция ИИ в кибербез - это не тренд, а просто MUST HAVE!

Давайте помыслим почему без ИИ в кибербезе в 2026+ году не обойтись.

--- Zero Day атаки. Человеку нужны часы, а иногда и дни, чтобы обнаружить сложную аномалию и изолировать угрозу.
--- ИИ делают это за милисекуды - минуты предотвращая ущерб еще до тогО, как SOC команда вообще поймет в чем дело
--- Анализ гигантских массивов данных. Количество логов и алертов в современной компании исчисляется миллионами. ИИ берет на себя рутину, отсеивает мусор (то есть ложные срабатывания) и подсвечивают именно те критические инциденты, которые требуют внимания экспертов.
--- Есть такое понятие как предективная защита. Вместо того, чтобы просто реагировать на атаки, ИИ анализирует поведение пользователей и систем выявляя скрытые угрозы и компрометацию учетных записей еще ДО ТОГО, как они нанесут вред.
--- Решение проблемы дифицита кадров. Квалифицированных киберщиков критически не хватает по всему миру. ИИ не заменяет людей, но он работает как мощный инструмент, снимая с крутых аналитиков рутину и позволяет сфокусироваться на более сложной задаче или более стратегических проблемах.

Ну и если подытожив, то использовать ИИ просто обязательно в наше время,
Имейте в виду(касается также тестировщиков, кто занимается защитой), если вы не используете ИИ, то вы шаг позади злоумышленников.

Идет набор на конец мая - начало июня по обучение тестированию безопасности.
ТГ @faroeman