Як виглядає пентест зсередини — від брифінгу до фінального звіту
Тест на проникнення (penetratin test, пентест) — це не ситуація, коли «хакери кілька тижнів щось роблять, а потім надсилають PDF зі списком проблем». Це структурований процес із чіткими етапами, погодженими правилами та зрозумілим результатом.
Для клієнта все виглядає досить спокійно: кілька стартових зустрічей, період, коли команда майже не виходить на зв'язок, а потім — фінальний звіт. Але саме за цей час виконується велика кількість технічної роботи, від якої залежить, чи отримаєте ви реальну картину стану безпеки, чи просто перелік знайдених проблем.
У цій статті розберемо, як виглядає процес пентесту з боку замовника, чого очікувати на кожному етапі та як отримати від тестування максимальну користь.
Перед початком пентесту: що відбувається на брифінгу
Перша зустріч із командою пентестерів насамперед це узгодження об'єму робіт, тобто визначення того, що саме буде тестуватися, у яких межах і за якими правилами.
Саме на цьому етапі формується майбутній пентест. Від визначеного об'єму робіт залежатимуть їх тривалість, вартість і, головне, практична цінність отриманих результатів. Тому перед стартом варто заздалегідь підготувати відповіді на кілька ключових запитань.
1. Що тестуємо?
Пентест може охоплювати різні компоненти інфраструктури:
- зовнішню інфраструктуру (сервери, VPN, поштові шлюзи, вебресурси та інші системи, доступні з інтернету);
- внутрішню мережу;
- вебзастосунок або API;
- мобільний застосунок;
- Wi-Fi-мережу;
- або їхню комбінацію.
Чим чіткіше визначений scope, тим якіснішим буде результат.
Бажання "перевірити все" звучить логічно, але на практиці майже завжди означає поверхневий аналіз великої кількості систем замість детальної перевірки найбільш критичних.
2. Якого рівня доступ надаємо
Від цього залежить формат проведення пентесту.
Black box
Фахівці починають тестування без жодної інформації про систему. Це максимально наближений до реальної зовнішньої атаки сценарій, коли зловмисник має лише те, що доступне будь-кому з інтернету.
Такий підхід найкраще показує, як вашу інфраструктуру бачить потенційний нападник. Водночас він потребує більше часу й не завжди дозволяє знайти проблеми, приховані у внутрішній логіці систем.
Grey box
Пентестери отримують частину інформації: наприклад, обліковий запис звичайного користувача, схему мережі або технічну документацію.
Такий формат імітує ситуацію, коли обліковий запис уже скомпрометовано або атака здійснюється внутрішнім користувачем із обмеженими правами. Саме Grey Box сьогодні є найпоширенішим варіантом для корпоративних пентестів.
White box
У цьому випадку команда отримує максимум інформації: архітектуру системи, вихідний код, документацію, адміністративні облікові записи та інші матеріали.
Такий підхід дозволяє знайти найбільшу кількість потенційних вразливостей за найкоротший час. Водночас він майже не показує, наскільки система захищена від зовнішнього нападника.
Вибір формату завжди залежить від мети тестування. Якщо потрібно оцінити, що бачить зовнішній зловмисник, доречніше обрати Black Box або Grey Box. Якщо ж головне завдання, максимально детально перевірити безпеку самої системи, ефективнішим буде White Box або Grey Box із розширеним рівнем доступу.
Що заборонено?
Ще до початку робіт сторони погоджують Rules of Engagement (RoE) — документ, який визначає правила проведення тестування.
Зазвичай у ньому зазначаються обмеження, наприклад:
- не виконувати активне тестування у години найбільшого навантаження;
- не проводити потенційно деструктивні атаки на production-системи без окремого погодження;
- не тестувати сервіси третіх сторін (хмарні платформи, SaaS-рішення тощо) без відповідного дозволу.
Rules of Engagement потрібен не для формальності. Він захищає і клієнта, і команду пентестерів, чітко визначаючи межі тестування та відповідальність кожної зі сторін.
Для замовника це гарантія того, що перевірка не створить зайвих ризиків для роботи бізнесу. Для виконавця — офіційно погоджені правила, яких він має дотримуватися під час виконання робіт.
Що підписуємо?
До початку будь-якого пентесту зазвичай оформлюють кілька документів.
NDA (Non-Disclosure Agreement) — угода про нерозголошення, яка гарантує конфіденційність усіх матеріалів, отриманих під час тестування.
Scope та Rules of Engagement — документ, який визначає об'єкти тестування, його межі та погоджені правила проведення.
У деяких випадках також оформлюється Letter of Authorization — офіційний дозвіл на проведення тестування. Він може знадобитися, якщо під час робіт виникнуть запитання з боку інтернет-провайдера, хостинг-компанії або інших третіх сторін.
Фаза 1. Розвідка
Після брифінгу зазвичай настає період, коли клієнт майже не отримує повідомлень від команди. Часто складається враження, що роботи ще не почалися. Насправді саме в цей час закладається основа всього пентесту.
Розвідка (Reconnaissance) — це перший етап тестування, під час якого пентестери збирають максимум інформації про ціль без активного впливу на її системи.
Залежно від формату пентесту цей етап може включати:
Пасивну розвідку. Аналіз відкритих джерел: DNS-записів, WHOIS, SSL-сертифікатів, профілів співробітників у LinkedIn, репозиторіїв GitHub, даних із Shodan, а також перевірку можливих витоків облікових даних.
Активне сканування. Виявлення відкритих портів, доступних сервісів, версій програмного забезпечення та особливостей конфігурації.
Дослідження вебзастосунків. Аналіз структури застосунку, технологічного стеку, механізмів автентифікації та всіх доступних точок введення даних.
Уже на цьому етапі досвідчені пентестери починають будувати гіпотези щодо потенційних сценаріїв атаки.
Наприклад:
«На сервері використовується Microsoft Exchange 2019 без актуальних оновлень — варто перевірити наявність відомих вразливостей ProxyLogon або ProxyShell.»
або
«Кілька адміністраторів Azure знайдено через LinkedIn — є сенс перевірити, чи не фігурують їхні облікові дані у відкритих витоках.»
Участь клієнта на цьому етапі мінімальна. Головне це залишатися на зв'язку, якщо команді знадобиться уточнення щодо окремих систем або сервісів.
Фаза 2. Сканування та аналіз вразливостей
Після завершення розвідки починається активна фаза роботи. Команда виконує автоматизоване сканування, перевіряє конфігурації, аналізує знайдені потенційні проблеми та вручну досліджує все, що викликає підозру.
Тут важливо розуміти різницю між скануванням вразливостей (Vulnerability Assessment) і пентестом.
Автоматизований сканер шукає відомі вразливості за сигнатурами та базами CVE.
Пентестер іде значно далі. Він перевіряє, чи можна реально використати знайдену проблему саме у вашому середовищі та який ризик вона створює для бізнесу.
Наприклад, сканер може повідомити про використання застарілої версії SSL і присвоїти їй середній рівень ризику.
Під час пентесту спеціаліст оцінює зовсім інше:
- чи передаються через цей канал конфіденційні дані;
- чи можна використати слабкість для подальшої атаки;
- чи стане вона частиною більшого ланцюга компрометації.
Саме тому одна й та сама технічна вразливість може мати зовсім різний рівень ризику для різних компаній.
На цьому етапі команда може звернутися до клієнта із запитаннями. Наприклад, уточнити, чи працює певна система в production, чи це тестове середовище.
Ще один важливий момент — критичні знахідки.
Якщо під час тестування виявлено вразливість, яка становить безпосередню загрозу для бізнесу, якісний провайдер повідомляє про це одразу, не чекаючи фінального звіту.
Наприклад, це може бути:
- можливість отримати адміністративний доступ без автентифікації;
- відкритий доступ до резервних копій;
- витік секретів або ключів доступу;
- критична RCE-вразливість у сервісі, доступному з Інтернету.
Такий підхід дозволяє усунути проблему ще до завершення пентесту та мінімізувати ризики.
Фаза 3. Експлуатація
Саме цей етап більшість людей уявляє, коли чує слово «пентест».
Насправді експлуатація лише одна з фаз роботи, хоча саме вона найкраще демонструє реальний рівень захищеності системи.
Мета тут не просто знайти вразливість, а підтвердити, що її можна використати.
Інакше кажучи, різниця між повідомленням:
«Виявлено SQL Injection» і «Через SQL Injection вдалося отримати доступ до бази даних із 50 000 записів клієнтів»
— це різниця між технічною знахідкою та доведеним бізнес-ризиком.
Під час цієї фази команда:
- підтверджує можливість реальної експлуатації знайдених вразливостей;
- оцінює, який рівень доступу можна отримати;
- перевіряє можливість подальшого розвитку атаки (lateral movement);
- аналізує, до яких систем або даних може дістатися потенційний зловмисник;
- документує кожен крок, щоб усі результати можна було підтвердити у фінальному звіті.
Саме тут формується відповідь на головне питання будь-якого CTO:
«Що реально може зробити зловмисник, якщо використає цю вразливість?»
Під час тестування ви можете побачити незвичну активність у журналах подій або отримати сповіщення від SIEM, EDR чи інших засобів захисту.
Це абсолютно нормально.
Навпаки, якщо ваші засоби моніторингу виявили дії пентестерів, це свідчить про те, що механізми детектування працюють.
Такі результати також варто врахувати під час оцінки ефективності захисту.
Фаза 4. Звіт
Після завершення всіх технічних робіт команда переходить до підготовки фінального звіту.
Саме звіт є головним результатом пентесту. Його якість визначає, чи стане проведене тестування практичним інструментом для підвищення безпеки, чи залишиться просто набором технічних фактів.
Хороший звіт завжди орієнтований на різні аудиторії.
Керівництву потрібне розуміння бізнес-ризиків та пріоритетів, тоді як технічній команді — детальні рекомендації щодо усунення вразливостей.
Саме тому більшість професійних звітів складається з двох взаємодоповнювальних частин.
Executive Summary
У цьому розділі майже немає технічної термінології.
Його головне завдання відповісти на три питання.
Наскільки добре захищена компанія?
Загальна оцінка стану безпеки з урахуванням проведеного тестування, галузевих практик і, якщо вони є, результатів попередніх пентестів.
Які ризики найнебезпечніші?
Короткий перелік найкритичніших знахідок із поясненням їхнього потенційного впливу на бізнес.
Не "Виявлено CVE-2026-XXXX", а: "Зловмисник може отримати доступ до персональних даних клієнтів без проходження автентифікації."
Саме така інформація допомагає керівництву оцінити ризики та приймати рішення.
Що потрібно зробити насамперед?
Замість десятків окремих рекомендацій керівництво отримує зрозумілий план дій із визначеними пріоритетами.
Технічний розділ
Саме цей розділ стане робочим документом для спеціалістів, які усуватимуть знайдені проблеми.
Для кожної знахідки зазвичай зазначаються:
- опис вразливості;
- точне місце її виявлення (URL, IP-адреса, система або компонент);
- сценарій відтворення (Proof of Concept);
- CVSS-оцінка та її обґрунтування;
- рекомендації щодо усунення;
- посилання на відповідні стандарти (CVE, CWE, OWASP тощо), якщо вони застосовні.
Головна ознака якісного технічного звіту — конкретика.
Після його прочитання IT-команда має чітко розуміти, що саме потрібно виправити, чому це важливо і як перевірити, що проблему справді усунуто.
Як читати CVSS: що означають цифри
CVSS (Common Vulnerability Scoring System) — це міжнародна система оцінювання критичності вразливостей за шкалою від 0 до 10. Більшість сучасних звітів використовує версію CVSS 3.1 або CVSS 4.0.
Однак важливо пам'ятати, що CVSS — це лише базова оцінка, яка не враховує особливості саме вашої інфраструктури.
Наприклад, вразливість із CVSS 7.5 у системі, що обробляє платіжні дані та доступна з інтернету, може створювати значно більший ризик, ніж аналогічна проблема у внутрішньому тестовому середовищі без конфіденційної інформації.
Саме тому професійний звіт не обмежується лише числовою оцінкою. Хороший провайдер завжди пояснює, який реальний вплив конкретна знахідка може мати саме для вашого бізнесу.
На що ще звернути увагу, окрім CVSS
Оцінка CVSS не єдине, що допомагає зрозуміти критичність вразливості.
Attack Vector (AV)
Показує, звідки може бути виконана атака.
Якщо експлуатація можлива безпосередньо через Інтернет (Network), ризик зазвичай значно вищий, ніж коли потрібен фізичний доступ або перебування всередині корпоративної мережі.
Privileges Required (PR)
Вказує, чи потрібні зловмиснику певні права доступу.
Найнебезпечнішими вважаються вразливості, для використання яких не потрібна автентифікація.
User Interaction (UI)
Показує, чи має користувач виконати якусь дію.
Наприклад, відкрити вкладення, перейти за посиланням або підтвердити виконання операції.
Якщо взаємодія користувача не потрібна, ризик зазвичай вищий.
Proof of Concept (PoC)
Якісний звіт містить докази того, що знайдену вразливість вдалося реально використати.
Це можуть бути:
- скриншоти;
- журнали подій;
- фрагменти HTTP-запитів;
- відеозаписи;
- інші технічні підтвердження.
Такі матеріали потрібні не для того, щоб "вразити" клієнта. Вони допомагають підтвердити, що ризик не є теоретичним, а також пояснити керівництву, чому усунення конкретної проблеми має бути пріоритетом.
Дебрифінг
Після передачі фінального звіту провайдер майже завжди проводить окрему зустріч із замовником.
Це не повторне читання PDF і не формальна презентація.
Головна мета дебрифінгу — допомогти правильно інтерпретувати результати тестування.
Під час зустрічі ви можете:
- поставити запитання щодо конкретних знахідок;
- отримати пояснення складних технічних моментів;
- обговорити пріоритети усунення ризиків;
- уточнити рекомендації та порядок їх реалізації.
Якщо після надсилання звіту провайдер більше не виходить на зв'язок, ви фактично залишаєтеся сам на сам із документом, який може містити десятки технічних деталей без необхідного контексту.
Що робити після пентесту
Основна цінність пентесту з'являється тоді, коли результати тестування перетворюються на конкретні зміни в інфраструктурі та процесах компанії.
Крок 1. Визначте пріоритети
Не всі знайдені вразливості однаково небезпечні. Найзручніше одразу розділити їх на три категорії.
Термінові
Critical і найбільш небезпечні High-вразливості.
Наприклад, можливість отримати адміністративний доступ або виконати довільний код без автентифікації.
Такі проблеми бажано усувати протягом перших 24–72 годин.
Планові
Вразливості з високим або середнім ризиком, які дійсно можуть бути використані, але потребують додаткових умов.
Їх зазвичай включають до найближчого циклу оновлень або плану робіт служби безпеки.
Backlog
Менш критичні знахідки, які також потребують усунення, але не становлять нагальної загрози.
Їх можна виконувати в рамках планового розвитку інфраструктури.
Крок 2. Переконайтеся, що проблему справді усунуто
Після внесення змін важливо перевірити, що вразливість більше не експлуатується.
Це можна зробити силами власної команди або замовити Retest — повторну перевірку саме тих проблем, які були виправлені.
Retest давно став стандартною практикою після професійних пентестів.
Адже між словами "виправили" і "ризик справді усунуто" іноді проходить кілька додаткових перевірок.
Крок 3. Усуньте причину, а не лише наслідок
Пентест нерідко показує не окремі технічні помилки, а системні проблеми.
Наприклад:
- відсутність процесу встановлення оновлень;
- надмірні привілеї користувачів;
- слабку сегментацію мережі;
- недостатній контроль конфігурацій.
Якщо усунути лише окремі вразливості, проблема може повторитися вже через кілька місяців.
Саме тому хороший звіт пояснює не лише що потрібно виправити, а й чому ця проблема виникла і які процеси варто змінити, щоб вона більше не повторювалася.
Крок 4. Захистіть сам звіт
Фінальний звіт містить детальний опис ваших слабких місць.
Фактично це інструкція, яка пояснює, де саме знаходяться вразливості інфраструктури.
Тому:
- обмежте коло осіб, які мають до нього доступ;
- не надсилайте його незашифрованою електронною поштою;
- не зберігайте у відкритих корпоративних папках;
- використовуйте захищені сховища документів.
Найпоширеніші питання після першого пентесту
«47 вразливостей — це багато чи мало?»
Сама по собі кількість знахідок майже нічого не говорить.
Значно важливіше:
- скільки серед них Critical або High;
- чи вдалося довести можливість їх експлуатації;
- яких систем вони стосуються.
Одна критична вразливість із підтвердженим доступом до бази даних може становити набагато більший ризик, ніж десятки інформаційних зауважень.
«Наші адміністратори кажуть, що це не критично. Кому вірити?»
IT-команда оцінює систему з точки зору її роботи та конфігурації.
Пентестери дивляться на неї очима потенційного зловмисника.
Обидві точки зору важливі.
Саме тому остаточна оцінка повинна базуватися не на думках, а на доказах експлуатації (PoC), наведених у звіті.
«Коли потрібно проводити наступний пентест?»
Для більшості компаній оптимально проводити повноцінний пентест щонайменше раз на рік.
Окремо тестування рекомендується після:
- запуску нових сервісів;
- суттєвих змін інфраструктури;
- міграції в хмару;
- запуску нових вебзастосунків або API;
- значних змін у мережевій архітектурі.
Якщо компанія працює відповідно до вимог PCI DSS, ISO 27001, DORA або інших регуляторних стандартів, частота перевірок може бути вищою.
«Ми виправили всі знахідки. Чи означає це, що тепер ми захищені?»
Пентест показує стан безпеки лише в межах визначеного об'єму роботи і на конкретний момент часу.
Нові вразливості з'являються постійно, через вихід нових CVE, оновлення програмного забезпечення, зміни конфігурацій або запуск нових сервісів.
Тому пентест варто розглядати не як одноразову перевірку, а як регулярний елемент процесу управління кібербезпекою.
Замовити пентест і отримати фінальний документ лише перший крок.
Реальна користь з'являється тоді, коли результати тестування стають основою для виправлення вразливостей, вдосконалення процесів безпеки та розвитку інфраструктури.
Для CTO або IT-директора головне завдання пентесту — не просто «успішно пройти перевірку», а отримати об'єктивне розуміння поточного рівня захищеності компанії та чіткий план подальших дій.
Якщо після завершення проєкту ви розумієте:
- які ризики існують;
- які з них потрібно усунути насамперед;
- які зміни допоможуть уникнути подібних проблем у майбутньому,
— отже пентест виконав свою головну задачу.
Саме в цьому і полягає його справжня цінність.
ESKA Red Team проводить пентести вебзастосунків, API, мобільних застосунків, зовнішньої та внутрішньої інфраструктури, хмарних середовищ і Wi-Fi-мереж. Ми не обмежуємося автоматичним скануванням: перевіряємо можливість реальної експлуатації вразливостей, оцінюємо їхній вплив на бізнес і надаємо конкретні рекомендації щодо усунення.
За результатами ви отримуєте детальний технічний звіт, Executive Summary для керівництва, пріоритизований перелік ризиків і рекомендації для IT та Security-команди.