Кибербезопасность | Пентестинг & AppSec

Нас тут уже 7500, пора познакомиться нормально. Многие подписались на канал, чтобы читать полезную инфу и кейсы, мы это постоянно публикуем, но многие не знают чем я вообще занимаюсь. Коротко: я делаю из обычных людей AppSec-ов и Пентестеров. С нуля ! Без теории из Википедии. Мы просто берем реальный API и ломаем его. Потом защищаем. Почему я? У меня нет цели продать вам курс за 2000€, мое обучение гораздо-гораздо бюджетнее. У меня цель - сделать 100 учеников, которых хантерят, а не которые ищут работу. У меня уже есть ребята, которые с нуля вошли в кибер. Есть девы, есть QA, которые x1.5 сделали к зарплате. Я не блогер. Я практик. Хотя чувствую, что и блогером уже становлюсь потихоньку. Сейчас добираю ребят на обучение - цены для своих - цена от €19 до 225€ в месяц. После Нового Года подниму. Все детали, программа, отзывы - в закрепе. Хочешь зайти - пиши мне в личку @faroeman Не хочешь - просто оставайся, буду дальше давать пользу про ИБ.

🪟 Что такое Windows Authentication Architecture? Представьте компанию на 1000 компьютеров. Каждый день сотрудники: — входят в Windows под своими учётными записями — подключаются к общим папкам — работают с корпоративными серверами — используют доменные ресурсы Но как Windows понимает, кто именно пытается получить доступ? И почему одному пользователю доступ разрешён, а другому — нет? 📌 За это отвечают механизмы Windows Authentication Architecture. Это архитектура аутентификации Windows, которая проверяет личность пользователей и служб, создаёт сеансы входа и участвует в формировании контекста безопасности. ⚡️ Основные компоненты: — Winlogon — управляет процессом входа в Windows — LogonUI — отображает экран авторизации — LSASS — обеспечивает работу механизмов аутентификации — SAM — хранит локальные учётные записи и хеши паролей — Active Directory — централизованно управляет доменными учётными записями — Kerberos / NTLM — протоколы аутентификации 🔐 Как происходит вход в домен? Пользователь вводит логин и пароль. Windows передаёт данные механизму аутентификации. При использовании Kerberos клиент взаимодействует с контроллером домена. После успешной проверки Windows создаёт сеанс входа. Пользователь получает токен доступа (Access Token). 💡 Access Token содержит информацию о пользователе, его группах и привилегиях. Именно этот токен Windows использует при проверке прав доступа к локальным ресурсам. Почему это интересно пентестеру? Потому что ошибки конфигурации и недостаточная защита механизмов аутентификации могут привести к: — компрометации учётных данных — злоупотреблению NTLM-аутентификацией — краже или повторному использованию Kerberos-билетов — повышению привилегий — несанкционированному доступу к доменным ресурсам 🧠 Например: Если злоумышленник получил доступ к материалам аутентификации пользователя, в определённых условиях он может использовать их для доступа к другим ресурсам без знания исходного пароля. С этим связаны техники: — Pass-the-Hash — Pass-the-Ticket — Kerberoasting — NTLM Relay 📌 Поэтому понимание Windows Authentication Architecture — одна из основ пентеста Active Directory. Без знания того, как Windows проверяет пользователей, сложно понять, почему работают многие атаки на доменную инфраструктуру. #infra #ad #windows #authentication #kerberos #ntlm #pentest

Записал видео про дыры в PHP которые анонсировал на этой неделе (подробности) https://youtu.be/OCZZmx30v8c?si=hVXhyWycinYfta2h&t=346

Записал видео про дыры в PHP, которые произошли на этой неделе (подробности) https://youtu.be/OCZZmx30v8c?si=lx5pg_ADAmzg7vnB

Записал видео про дыры в PHP, которые произошли на этой неделе (подробности) https://youtu.be/OCZZmx30v8c?si=i01iYhuNAhVnR4qO

Сразу постараюсь ответить🤔 А вы уже по реакциям дайте мне понять, согласны ли вы со мной или нет Ответ: в наших условиях XSS уже не получится. ✅ Раньше мы использовали кавычку ", чтобы выйти из атрибута value и добавить свой JavaScript-код. Теперь сервер заменяет " на ". И тут есть интересный момент! 🤔 Браузер действительно понимает, что " означает кавычку. Но он воспринимает её как обычный символ внутри значения value, а не как конец атрибута. А если использовать одинарную кавычку '? Тоже не поможет, потому что наш атрибут заключён в двойные кавычки:

<input type="text" value="USER_INPUT">

Одинарная кавычка здесь ничего не закрывает. 💡 Главный вывод: Не каждую XSS-уязвимость можно эксплуатировать после исправления фильтра. В нашем случае правильное экранирование кавычек, < и > защищает именно этот HTML-контекст. Но есть нюанс: если тот же пользовательский ввод попадёт в JavaScript, URL или другой HTML-контекст, правила защиты будут отличаться.

Сижу читаю комментарии под вчерашней задачкой и в голове возник еще один вопрос:

А если бы разработчики экранировали ещё и двойные кавычки " — сработал бы наш payload?
Или пришлось бы искать другой контекст внедрения?

🔥 Разбор пятничного XSS Challenge — нашли уязвимость? Вчера мы разбирали интересный случай, когда разработчики попытались защититься от XSS, но забыли про одну маленькую деталь. 😈 Проблема в том, что пользовательский ввод находится внутри HTML-атрибута value. Если двойные кавычки не экранируются, мы можем выйти за пределы атрибута и добавить собственные. 🎯 Один из возможных payload:

" autofocus onfocus="alert(1)" x="

После подстановки HTML будет выглядеть так:

<input type="text" value="" autofocus onfocus="alert(1)" x="">

🧠 Разбираем по шагам: 1️⃣ Первая " закрывает исходный атрибут value. 2️⃣ autofocus просит браузер автоматически установить фокус на поле ввода. 3️⃣ onfocus="alert(1)" добавляет JavaScript-обработчик события получения фокуса. 4️⃣ x=" позволяет корректно завершить оставшуюся часть исходного HTML-атрибута. ⚡️ Что произойдёт? Если браузер установит фокус на поле ввода, сработает onfocus и выполнится alert(1). При этом важно понимать: autofocus не гарантирует автоматического выполнения во всех браузерах и условиях. Например, фокус уже может находиться на другом элементе. Но главное здесь другое: мы смогли внедрить JavaScript-обработчик, даже не используя символы < и >. 🛡 Как правильно защититься? Недостаточно просто заменять < и >. Нужно экранировать пользовательский ввод с учётом контекста, в котором он используется. Для значения HTML-атрибута необходимо корректно обрабатывать кавычки и другие специальные символы. А ещё лучше — использовать безопасные механизмы шаблонизатора или DOM API, например присваивать значение через свойство .value, а не собирать HTML из строк. 💡 Главный вывод XSS — это не всегда внедрение тега <script>. Иногда достаточно одной неэкранированной кавычки, чтобы изменить структуру HTML и получить возможность выполнения JavaScript. Поэтому при поиске XSS важно понимать не только что фильтруется, но и куда именно попадает пользовательский ввод.

🌙 Пятничный XSS Challenge — сможешь обойти фильтр? 😈 Сегодня небольшая задачка для тех, кто изучает Web Pentest. Представим, что во время тестирования учебного веб-приложения ты обнаружил интересное поведение. Есть страница: https://lab.example/search?q=hello Параметр q отражается в HTML-ответе сервера. Посмотрим на исходный код:

<input type="text" value="hello">

При этом разработчики добавили простенький фильтр: 🔹 Символы < и > заменяются на HTML-сущности < и >. 🔹 Двойные кавычки " остаются без изменений. 🔹 Значение параметра q вставляется непосредственно в атрибут value. 🎯 Твоя задача: 1️⃣ Можно ли здесь добиться выполнения JavaScript? 2️⃣ Какой payload ты бы попробовал в первую очередь? 3️⃣ Потребуется ли действие пользователя или код выполнится автоматически? 4️⃣ Как правильно исправить эту уязвимость? Условия: — Это учебная лаборатория. — CSP отсутствует. — Дополнительной фильтрации нет. — Можно управлять только параметром q. Пишите свои варианты payload в комментариях. Посмотрим, кто первым найдёт рабочее решение. Завтра опубликую разбор с объяснением, почему экранирование < и > не всегда спасает от XSS. #практика

🚨 Нашёл XSS, вызвал alert(1). Ты уже взломал сайт? Спойлер: нет. Многие начинающие пентестеры думают, что если удалось выполнить alert(1), то уязвимость автоматически критическая. Но всё немного интереснее. Представим: Ты тестируешь учебное веб-приложение и обнаруживаешь Reflected XSS. Переданный параметр попадает в JavaScript-контекст, и тебе удаётся выполнить собственный код. Так совсем недавно мне написал человек из нашей команды, скинув XSS, в надежде что я помогу ему получить полный доступ к сайту через эту XSS. Приступили к изучению XSS, все красиво - уязвимость была найдена прямо на странице /login. Это прям High level и для отчета это было бы очень хорошо, но с получением доступа к сайту, не все так просто. Причём это была Reflected XSS: переданный через URL параметр попадал в JavaScript-контекст страницы без корректной обработки, что позволяло выполнить произвольный JavaScript. Проверили — alert(1) успешно срабатывает. 🎯 Что на самом деле даёт такая XSS? Выполнение JavaScript в контексте уязвимого сайта открывает определённые возможности: — Взаимодействие с DOM и содержимым страницы. —Доступ к данным, которые доступны JavaScript в браузере. — Изменение интерфейса страницы, в том числе форм авторизации. — Выполнение запросов от имени пользователя в пределах его браузерного контекста и действующих ограничений. — Потенциальное воздействие на пользовательскую сессию, если для этого существуют необходимые условия. Но есть один важный момент. XSS ≠ доступ к аккаунту. Если уязвимость находится на /login, это ещё не означает, что мы можем получить доступ к административной панели или авторизоваться без пароля. Например, если вредоносный код выполняется в браузере неавторизованного пользователя, у него может просто не быть доступа к функциям, требующим авторизации. А если приложение использует HttpOnly для сессионных cookie, прочитать их напрямую через document.cookie не получится. При этом HttpOnly не устраняет саму XSS и не исключает другие сценарии воздействия. Поэтому после обнаружения XSS важно ответить на несколько вопросов: 1️⃣ Кто должен открыть уязвимую ссылку, чтобы код выполнился? 2️⃣ Выполняется ли JavaScript в авторизованной сессии? 3️⃣ Какие данные и действия доступны в этом контексте? 4️⃣ Какие ограничения накладывают CSP и другие защитные механизмы? 5️⃣ Можно ли продемонстрировать реальное воздействие в рамках разрешённого тестирования? И только после этого оценивать реальный риск. Какой вывод можно из этого сделать и как этим пользоваться?

Найти XSS — это только первый этап. Гораздо важнее разобраться, что именно позволяет сделать уязвимость, при каких условиях и к каким последствиям это может привести.

Именно этим отличается простое подтверждение XSS от полноценного анализа её безопасности.

AI в пентесте: кроме Claude и Codex — а что ещё? Ищу тех, кто уже собрал рабочий пайплайн Последние месяцы я плотно пытаюсь встроить ИИ в свой пентест-процесс. Не потому что все это делают, а чтобы реально разгрузить рутину: разведка, разбор выдачи сканеров, черновики отчётов и так далее. И чем дальше, тем чаще ловлю себя на одном и том же вопросе. Из «мозгов» у меня по сути два рабочих варианта — Claude и Codex. Оба неплохо справляются с рассуждением, планированием шагов и интерпретацией результатов. И Codex лично для меня работает поприятнее, так как Claude постоянно видит в моих действиях нарушения 😎. На этих двух инструментах мой список и заканчивается. И тут возникает вопрос, на который хочется услышать мнение тех, кто уже глубже в теме. Ведь ещё совсем недавно, месяца 3–4 назад, я даже выкладывал в паблик разбор ИИ-инструментов, которые потом даже встроили в Kali, — и вот уже как будто бы это неактуально.

Если модель грамотно настроена — с нормальным системным промптом, доступом к инструментам и внятным контекстом по скоупу — есть ли вообще смысл городить связки с отдельными «агентными» обёртками вроде HexStrike AI? Или при правильной настройке самой модели + MCP эти прослойки становятся лишним звеном?

Поясню, о чём речь. Сейчас экосистема вокруг «ИИ + оффенсив» выглядит примерно так: HexStrike AI — MCP-сервер, который прокидывает модели доступ к 150+ security-тулзам (nmap, sqlmap и прочее) и как будто бы всё «мышление» делегирует подключённой LLM. PentAGI — попытка сделать полностью автономного агента со своей архитектурой, а не просто обёртку над тулзами. Pentest Swarm AI — здесь уже не «несколько агентов подряд», а настоящий swarm: децентрализованные агенты с общей «доской» для обмена состоянием. CyberStrikeAI — аналог HexStrike, но на Go: единый бинарник, web-консоль, встроенный лёгкий C2, role-based агенты. PentestGPT — тот самый ранний проект, который в своё время показал, что LLM в принципе способна вести пентест. Инструментов различных очень много. Но у меня складывается ощущение, что половина из них решает проблему, которую хорошо настроенная модель с прямым доступом к инструментам закрывает и так — своими базовыми возможностями. Что я хотел бы узнать — и, возможно, в комментариях каждый найдёт для себя что-то полезное. — Не изобретаю ли я велосипед, пытаясь обойтись минимумом инструментов там, где люди уже собрали нормальные пайплайны? — Какие ещё инструменты вы используете помимо базовых Codex CLI и Claude CLI? Буду признателен за любой практический опыт, грабли и советы. Возможно, что-то изложил не совсем корректно, но я постарался максимально подробно рассказать про свою боль и спросить про ваш опыт с использованием ИИ.

CVE vs CWE. Вечно путают, а разница в 10 секунд. CWE - это вид уязвимости. Шаблон. Например CWE-89 это SQL-инъекция. Всего таких шаблонов около 900. Это как диагноз. CVE - это уже найденная дыра в реальном софте. Конкретный кейс. Например CVE-2023-44487 - уязвимость в протоколе HTTP/2. У нее есть номер, дата, описание и патч. Это как история болезни. Итого: CWE = какой тип проблемы CVE = где именно она случилась Поэтому сначала закрываешь конкретную CVE, а потом по ее CWE идешь и проверяешь весь остальной код на такие же ошибки. Все

В дополнение к прошлому посту Спасибо за комменты, все видим, все читаем😉 🎯 Что важно пентестеру Сканирование порта — это как стучать в дверь и смотреть, что будет. С TCP всё понятно: — открыли дверь → порт открыт — сказали «тут никого» → порт закрыт — вообще тишина → дверь, скорее всего, закрыта охраной (firewall) С UDP сложнее. UDP-сервис отвечает, только если вы спросили его «на его языке». На просто стук он промолчит. И nmap не понимает: за дверью кто-то есть, но молчит, или дверь просто заблокирована. Поэтому пишет:

161/udp  open|filtered

То есть «может, открыт, а может, фильтруется — не знаю». 📌 Как уточнить Добавьте -sV — nmap заговорит с сервисом на его протоколе, и тот, скорее всего, ответит. 🧱 Firewall тоже бывает разный Один молча игнорирует ваш стук — видим filtered. Другой отвечает «уходи» — и порт выглядит просто закрытым, хотя сервис там может быть. ⏱️ Почему UDP сканируется долго Система отвечает на такие «стуки» неохотно и редко, nmap приходится ждать. Поэтому сканируйте только популярные порты, а не все подряд.

Не мог, не запостить эту картинку😄

🔌 TCP и UDP: в чём разница и зачем это пентестеру 📌 TCP и UDP — протоколы транспортного уровня. Работают поверх IP и доставляют данные до приложения через порт. 🤝 TCP — сначала договоримся Перед передачей устанавливает соединение:

SYN → SYN/ACK → ACK
   ↓
Соединение установлено

Гарантирует доставку и порядок данных. 📨 UDP — отправил и забыл Без соединения и подтверждений. Быстрее, но без гарантий.

TCP:  HTTP, SSH, SMB
UDP:  DNS, DHCP, SNMP, TFTP

🎯 Что важно пентестеру TCP-порт отвечает понятно, а UDP часто молчит. Поэтому nmap пишет:

161/udp  open|filtered  snmp

Многие сканируют только TCP и пропускают SNMP, TFTP, DNS — а там бывают интересные находки. 🛠 Команды

sudo nmap -sS 192.168.1.10
sudo nmap -sU --top-ports 20 192.168.1.10

🧠 Главная мысль Сканируете только TCP — видите не всю картину. #network #base #recon

Новое видео про поиск работы в кибербезе С вас лайк/коммент/подписка- заранее спасибо каждому! https://youtu.be/tMGfiP2UEW8?si=6d8XoDkY1iGF7fBe

Только мы придумали, что-то интересно и сразу бан!🫤 Telegram заблокировал наш чат предзаписи. Мы подали апелляцию и ждём ответа. Из-за чего тоже непонятно, возможно кто-то пожаловался🤔 Пока вопрос не решён, запуск клуба ставим на паузу. Если у кого-то были похожие ситуации напишите, пожалуйста, в лс. А канал работает как обычно: теория, задачи и разборы выходят по плану 💪 Спасибо всем, кто записался и поддержал 🔥 Это показало, что клуб вам нужен, и мы к идее ещё вернёмся.

Ну что ребят - задачка. Дано: интернет-магазин. При регистрации вам на почту приходит ссылка для подтверждения: site . com/verify?token=abc123 Вопрос: где тут можно украсть чужой аккаунт? Ответ покажется тупым, но ... Разбор тестовой лабы: Я заметил 2 вещи: Токен в ссылке живет 24 часа После того как ты подтвердил почту, токен НЕ СГОРАЕТ. Он все еще валидный. А дальше классика: Я регаю аккаунт на свою почту vitali@test.com Подтверждаю его, все ок Иду в настройки профиля и меняю почту на admin@victim.com (почту жертвы) Сайт снова шлет письмо с подтверждением на НОВУЮ почту. С ТЕМ ЖЕ САМЫМ токеном abc123 Я не подтверждаю. Я просто жду. Что делает жертва? Она хочет зарегаться на admin@victim.com, но сайт ей пишет "такая почта уже занята". Она идет делать "Забыли пароль?" -> ей на почту приходит письмо -> она меняет пароль и заходит. И вот в этот момент мой старый токен abc123 все еще работает. Я перехожу по site. com/verify?token=abc123 и сайт пишет: "Почта admin@victim.com успешно подтверждена. Вы владелец аккаунта". Я только что угнал ее аккаунт после того, как она сменила пароль. Это называется ЗАХВАТ АККАУНТА!!!. Очень !!!редкий!!! и очень простой баг. Как надо было фиксить: 1 правило: Любой токен на почту должен сгорать сразу после использования. Один раз кликнули - все, в мусорку. Проверьте свои проекты.  . Нашли бы сами? По менторству security testing (для QA) / AppSec - пишите в телеграм @faroeman (укажите откуда вы) #bugbounty #infosec #appsec #для_начинающих