Що знаходить пентест: 6 слабких місць, приклади з практики та ризики для бізнесу у 2026 році

Пентест показує не лише технічні вразливості. Іноді найбільший ризик прихований у звичайній бізнес-операції або в тому, як працівники реагують на підроблений лист.

Наші спеціалісти знайшли й провели два показові випадки: критичну вразливість бізнес-логіки в криптообміннику, де зловмисник міг вивести всі доступні на біржі кошти за курсом на власний розсуд, і фішинг-симуляцію в одному з трьох найбільших банків України (тисячі працівників), де 64% усіх працівників перейшли за посиланням, а 36% ввели логін і пароль.

Ці випадки не є статистичною вибіркою. Вони показують, чому важливо перевіряти не тільки відомі технічні вразливості, а й бізнес-логіку, права доступу та поведінку користувачів.

Нижче розглядаємо шість категорій ризиків: як вони працюють, до яких наслідків можуть призвести та з чого почати перевірку. Для міжнародного контексту окремо наводимо дані Verizon DBIR 2026, OWASP, NCSC, CERT-UA та інших першоджерел. Ці дані не є статистикою клієнтів Veiltrack.

Коротко: що показують перевірки безпеки

• Бізнес-логіка: наші спеціалісти знайшли в криптообміннику критичну вразливість: користувач міг сам змінити курс обміну у власній операції. Зловмисник міг би вивести всі доступні на біржі кошти за курсом на власний розсуд, тож збиток обмежувався б лише сумою коштів на біржі.
• Фішинг: у навчальній симуляції в одному з трьох найбільших банків України (тисячі працівників) 64% усіх працівників перейшли за посиланням, а 36% ввели логін і пароль. Деякі робили це повторно, використовуючи різні комбінації облікових даних.
• Шість категорій для перевірки: права доступу в API, бізнес-логіка, захист облікових записів від фішингу, налаштування поштового домену, зовнішні сервіси та права доступу в хмарі.
• Міжнародний контекст: Verizon DBIR 2026 повідомляє, що експлуатація вразливостей стала провідним початковим вектором зламів у дослідженій вибірці: 31%. Людський фактор був присутній у 62% зламів. ^{[1] [2]}
• Практичний результат: для кожної категорії наведено перший крок перевірки.

Головний висновок автора: наявність технічного контролю ще не означає, що бізнес-операція або обліковий запис захищені від зловживання. Під час перевірки важливо встановити не лише те, чи є вразливість, а й те, яку конкретну дію може виконати користувач або зловмисник і до яких наслідків вона призведе.

Два випадки, які провели й знайшли наші спеціалісти, ілюструють цю різницю: у криптообміннику користувач міг змінити курс власної операції та вивести кошти; у навчальній фішинг-симуляції 36% усіх працівників банку ввели облікові дані, причому частина робила це повторно.

Це не статистика українського ринку, а два окремі випадки. Міжнародні показники Verizon DBIR 2026 наведено для контексту, їх не слід приписувати Veiltrack.

Автор і методологія матеріалу

Матеріал підготував Владислав Краєвський, засновник Veiltrack. Він працює у кібербезпеці з 2019 року, має понад шість років досвіду пентесту та керував командою пентестерів.

Цей матеріал поєднує три окремі джерела знань:

1. Знеособлені випадки з практики наших спеціалістів. Дві історії нижче описують те, що знайшли й провели наші спеціалісти. Ми не називаємо організації, точну кількість працівників чи суми операцій.
2. Якісні професійні спостереження. Шість категорій є експертним оглядом ризиків, а не рейтингом за частотою, кількістю знахідок або критичністю.
3. Зовнішні джерела. Стандарти OWASP, рекомендації NCSC і Microsoft, дані Verizon DBIR 2026, повідомлення CERT-UA та технічні специфікації. Їхня статистика не переноситься на українські компанії без окремих даних.

У матеріалі не наводимо кількість перевірок Veiltrack, частки клієнтів із певними вразливостями чи оцінки фінансових збитків, оскільки таких підтверджених показників для цієї публікації немає.

Історія 1. Криптообмінник: користувач міг сам змінити курс операції

Наші спеціалісти знайшли в криптообміннику критичну вразливість бізнес-логіки: користувач міг змінити курс обміну у власній операції, обміняти кошти на вигідних для себе умовах і вивести їх.

Проблема полягала не у вгадуванні пароля чи використанні застарілої версії програмного забезпечення. Система дозволяла виконати фінансову операцію з параметром, який мав контролюватися бізнес-правилами.

До чого це могло призвести. Зловмисник міг би вивести всі доступні на біржі кошти за курсом на власний розсуд, тож збиток обмежувався б лише сумою коштів, які біржа тримає.

Чому це важливо для бізнесу. Якщо система неправильно перевіряє ціну, курс, комісію чи ліміт, ризик виникає без необхідності отримувати адміністративні права. Користувач може залишатися в межах власного облікового запису, але виконувати операцію, яку бізнес не передбачав.

OWASP WSTG виділяє тестування бізнес-логіки в окремий напрям і пояснює обмеження автоматизованого пошуку таких проблем. ^[4]

Що перевірити насамперед. Для операцій, пов'язаних із грошима, перевірте, які параметри надходять від клієнта, які значення визначає сервер і чи можна змінити передбачений порядок дій. Особливу увагу приділіть курсу обміну, сумі, комісії, лімітам та повторному виконанню операцій.

Висновок для власника бізнесу: система може правильно прийняти й виконати запит, але результат операції все одно може суперечити бізнес-правилам. Тому фінансову функцію недостатньо перевірити лише на стандартні технічні вразливості: потрібно також з'ясувати, хто контролює критичні параметри операції та чи здатна система відхилити неприпустиму зміну.

Ключове запитання для перевірки: чи може звичайний користувач отримати фінансову перевагу, змінюючи параметри або порядок операцій, які система дозволяє йому виконувати?

Докладніше в статті тестування безпеки фінтеху і платежів.

Історія 2. Фішинг-симуляція: 64% перейшли за посиланням, 36% ввели облікові дані

Наші спеціалісти провели навчальну фішинг-симуляцію в одному з трьох найбільших банків України (назву не розкриваємо). У банку працюють тисячі працівників. Результати:

• 64% усіх працівників перейшли за посиланням із тестового листа.
• 36% усіх працівників ввели логін і пароль на навчальній сторінці.

Частина працівників вводила облікові дані повторно, іноді використовуючи різні комбінації логінів і паролів. Це відбувалося тому, що після відправлення форми сторінка перезавантажувалася.

Що означають ці цифри. Обидва відсотки розраховані від усіх працівників банку, а не лише від тих, хто відкрив повідомлення чи перейшов за посиланням.

Це результати однієї навчальної симуляції в одному великому банку. Вони не означають, що 64% працівників українських банків переходять за фішинговими посиланнями або що 36% працівників українських компаній розкривають паролі. Так само 36% працівників, які ввели дані, не дорівнюють 36% скомпрометованих облікових записів.

Чому це важливо. Перехід за посиланням і введення облікових даних є різними подіями. Для оцінки ризику недостатньо рахувати лише кліки: потрібно окремо оцінювати готовність користувачів вводити дані на сторінці, яку вони сприймають як справжню.

Повторне введення після перезавантаження форми також показує, що невдалий або незрозумілий сценарій авторизації не обов'язково змушує людину зупинитися.

Що робити. Навчання працівників потрібно поєднувати з технічним захистом облікових записів. Британський NCSC рекомендує надавати перевагу FIDO2 перед методами MFA, що використовують коди. ^[5]

Окремо необхідно передбачити простий спосіб повідомлення про підозрілі листи та перевіряти не лише переходи за посиланнями, а й подальші дії у навчальному сценарії.

Висновок: результат фішинг-симуляції не можна оцінювати лише за кліками. У цьому випадку 64% усіх працівників перейшли за посиланням, 36% усіх працівників ввели логін і пароль, а частина повторювала введення після перезавантаження форми.

Ці спостереження описують три різні аспекти поведінки: перехід за посиланням, введення облікових даних і повторні спроби введення.

Для замовника це означає, що звіт про симуляцію має пояснювати не тільки кількість переходів, а й подальші дії учасників. Інакше важлива частина результату перевірки залишиться поза увагою.

Як влаштовано таку перевірку, описано в статті фішинг-симуляція для працівників.

6 слабких місць, які варто перевірити в бізнесі

Нижче шість категорій ризиків, на які варто звертати увагу під час перевірок вебзастосунків, API, зовнішньої інфраструктури, пошти та хмарних облікових записів.

Це не рейтинг найпоширеніших вразливостей України. Ми не ранжуємо їх за кількістю проєктів, поширеністю чи оцінкою CVSS.

Для кожної категорії пояснюємо суть проблеми, можливий вплив на бізнес і перший практичний крок. Публічні першоджерела наведено як технічне обґрунтування або міжнародний контекст, а не як доказ частоти знахідок у клієнтів Veiltrack.

1. Доступ до чужих даних через API (IDOR / BOLA)

Що це. Сервер може правильно встановлювати особу користувача, але недостатньо перевіряти його право на конкретний об'єкт: рахунок, документ, профіль або операцію.

Чому це важливо. Помилка авторизації на рівні об'єкта може дозволити перегляд або зміну чужих даних. Масштаб наслідків залежить від того, до яких саме об'єктів відкрито доступ і які дії дозволяє API.

В OWASP API Security Top 10 2023 Broken Object Level Authorization (BOLA) наведено як API1:2023. ^[3]

Перший крок. Створіть два тестові облікові записи з різними правами на дані. Перевірте, чи може перший користувач читати або змінювати об'єкти другого через API. Контроль доступу має виконувати сервер для кожної операції, а не лише інтерфейс застосунку. Детальніше в статті перевірка безпеки сайту і API.

2. Помилки в бізнес-логіці

Що це. Застосунок може правильно обробляти кожен окремий запит, але допускати дії, які суперечать бізнес-правилам: зміну фінансових параметрів, повторну операцію або пропуск обов'язкового етапу.

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

OWASP WSTG пояснює, що перевірка бізнес-логіки потребує розуміння процесів застосунку й часто не може бути повністю замінена автоматизованим скануванням. ^[4]

Перший крок. Визначте операції, що впливають на гроші, залишки, бонуси, комісії чи права користувачів. Для кожної перевірте джерело критичних параметрів, допустимий порядок дій та можливість повторного виконання.

Висновок: ризик залежить не лише від технічної вразливості, а й від того, яку бізнес-дію система дозволяє виконати.

3. Фішинг і MFA, яку можна обійти

Що це. Працівник вводить пароль на підробленій сторінці. Якщо другого фактора немає або це код з SMS чи застосунку, зловмисник може перехопити і його.

Чому це важливо. Людський фактор присутній у 62% зламів за DBIR 2026. ^[2] Британський NCSC пише, що коди з застосунків і апаратних генераторів вразливі до фішингу з перехопленням коду, а push-підтвердження дають лише часткову стійкість через атаку «втоми від запитів». Стійкість до фішингу дає FIDO2: ключі безпеки і passkeys. ^[5]

Фішинг використовують і проти українських організацій. Повідомлення CERT-UA від 21 травня 2026 року описує розсилки листів зі скомпрометованих облікових записів державних організацій. ^[6] Це опис конкретної кампанії, а не статистика фішингу серед українських компаній.

Що варто перевірити окремо. Наявність MFA в основному корпоративному сервісі не гарантує, що всі інші способи входу захищені однаково. Перевірте VPN, поштові протоколи, адміністративні інтерфейси та інші зовнішні точки автентифікації.

Для облікових записів із критичними правами окремо оцініть, чи використовується MFA, стійка до фішингу, зокрема FIDO2-ключі або passkeys. ^[5]

Перший крок. Увімкніть MFA всюди, де є вхід ззовні, і почніть з FIDO2-ключів або passkeys для адміністраторів і фінансового відділу. Паралельно проведіть фішинг-симуляцію і рахуйте окремо переходи за посиланням та введення облікових даних. Про налаштування пошти і реакцію на фішинг читайте в статті захист пошти від фішингу.

4. Налаштування захисту поштового домену (SPF, DKIM, DMARC)

Що це. SPF визначає дозволені джерела відправлення пошти, DKIM дає змогу перевірити криптографічний підпис повідомлення, а DMARC пов'язує результати перевірок із доменом у полі From та задає політику обробки повідомлень, що не пройшли автентифікацію.

Чому це важливо. Неправильна конфігурація може полегшити підробку домену відправника. NCSC рекомендує застосовувати ці механізми для протидії поштовому спуфінгу. ^[7]

RFC 9989 описує DMARC і замінює RFC 7489. ^[8] Google вимагає SPF і DKIM, а також DMARC від відправників, які надсилають понад 5000 повідомлень на день на особисті адреси Gmail. Для інших відправників базова вимога: SPF або DKIM. ^[9]

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

Зверніть увагу на домени без DMARC, коректність автентифікації легітимних відправників і політику p=none. Вона призначена для моніторингу й сама по собі не вимагає від одержувача відхиляти повідомлення, які не пройшли DMARC. ^[8]

Перед переходом до quarantine або reject перевірте легітимні джерела пошти, щоб не порушити доставлення робочих повідомлень.

Перший крок. Перевірте SPF, DKIM і DMARC для всіх своїх доменів. Налаштуйте звітування DMARC, переконайтеся, що легітимні джерела пошти проходять автентифікацію, і після перевірки переходьте від моніторингу до політик quarantine або reject.

Важливе обмеження. SPF, DKIM і DMARC не захищають від усіх видів фішингу, зокрема від листів, надісланих зі справді скомпрометованої скриньки.

5. Забуті зовнішні сервіси і старі версії ПЗ

Що це. Тестовий сервер, стара адмінка, VPN-шлюз чи сервіс, про який забули після звільнення адміністратора. Він доступний з інтернету і давно не оновлювався.

Чому це важливо. Забутий сервіс може залишатися доступним з інтернету без регулярних оновлень і контролю відповідального власника.

За Verizon DBIR 2026, експлуатація вразливостей стала найпоширенішим початковим вектором зламів у дослідженій вибірці: 31%. У наборі даних про вразливості, що входили до CISA KEV, лише 26% знахідок були повністю усунуті в усіх виявлених екземплярах, а медіанний час повного усунення становив 43 дні. Це показники вибірки дослідження, а не статистика українських компаній. ^{[1] [2]}

OWASP API9:2023 окремо описує ризики неналежної інвентаризації API. ^[3]

Що варто перевірити окремо. Порівняйте внутрішній реєстр ІТ-активів із фактично доступними з інтернету доменами, IP-адресами та сервісами. Особливу увагу приділіть тестовим середовищам, старим адміністративним панелям і сервісам, для яких важко встановити відповідального.

Критерій результату: для кожного доступного з інтернету активу має бути зрозуміло, навіщо він потрібен, хто за нього відповідає, як контролюється його доступність і чи потребує він оновлення.

Перший крок. Складіть перелік усього, що видно з інтернету: домени, піддомени, IP-адреси, сервіси. Вимкніть зайве, а для решти звірте версії з каталогом CISA KEV ^[11] і оновіть першими ті, що є в ньому. Регулярне сканування вразливостей допомагає не повертатися до цього раз на рік.

6. Зайві права в хмарі та Microsoft 365

Що це. Забагато людей мають права глобального адміністратора, сервісні акаунти мають повний доступ «про всяк випадок», а права колишніх працівників і підрядників не відкликають.

Чому це важливо. Надмірні адміністративні права збільшують можливі наслідки компрометації облікового запису.

У Verizon DBIR 2026 зазначено, що в дослідженій вибірці хмарних середовищ сторонніх організацій час усунення половини знахідок, пов'язаних зі слабкими паролями та некоректними правами доступу, сягав майже восьми місяців. Ці дані не є оцінкою стану Microsoft 365 в Україні. ^[2]

Microsoft рекомендує принцип мінімальних привілеїв, тимчасове надання прав через Privileged Identity Management, регулярний перегляд доступів і менш ніж п'ятьох глобальних адміністраторів. ^[10]

Що варто перевірити окремо. З'ясуйте, які облікові записи мають адміністративні права в Microsoft 365 та інших хмарних середовищах. Перевірте активність облікових записів колишніх працівників і підрядників, обсяг прав сервісних акаунтів, а також терміни дії та порядок відкликання ключів доступу.

Критерій результату: кожне привілейоване право повинно мати обґрунтоване призначення. Якщо право більше не потрібне для виконання завдання, його слід відкликати або обмежити. ^[10]

Перший крок. Вивантажте список усіх акаунтів з адміністраторськими ролями, залиште мінімум, решті видайте вужчі ролі. Покрокову перевірку описано в статтях перевірка безпеки Microsoft 365 і пентест хмари AWS, Azure, GCP.

Що ці приклади означають для замовника пентесту

Головне завдання перевірки: показати не лише назву вразливості, а й те, яку дію вона дозволяє виконати та до чого це може призвести для бізнесу.

Три висновки з практики наших спеціалістів

1. Фінансовий ризик може виникати в межах звичайного облікового запису. В одному з випадків користувач криптообмінника міг змінити курс власної операції, виконати обмін на вигідних умовах і вивести кошти; зловмисник міг би вивести всі доступні на біржі кошти. Цей приклад показує, чому тестування бізнес-логіки має охоплювати не лише технічні помилки, а й правила виконання фінансових операцій.
2. Клік і введення пароля: різні показники. В одній навчальній фішинг-симуляції в одному з трьох найбільших банків України 64% усіх працівників перейшли за посиланням, а 36% усіх працівників ввели логін і пароль. Це два показники з однаковою базою розрахунку, але різним змістом.
3. Повторне введення даних також має значення. Під час тієї самої симуляції частина працівників вводила різні комбінації облікових даних після перезавантаження форми. Отже, аналіз поведінки не варто завершувати підрахунком першої взаємодії зі сторінкою.

Джерело прикладів: практика наших спеціалістів, описана Владиславом Краєвським, засновником Veiltrack. Це не статистичне дослідження і не репрезентативна вибірка українських компаній.

Саме тому результати перевірки варто оцінювати з урахуванням технічної серйозності, доступності вразливої функції, можливого сценарію зловживання та бізнес-наслідків. Оцінка CVSS корисна, але не замінює аналізу конкретного сценарію.

Якщо хочете перевірити ці шість пунктів у своїй компанії руками фахівця, почніть зі сторінки пентест.

Чекліст: шість перших кроків

• Двома тестовими акаунтами перевірили, що один не бачить і не змінює даних іншого в API.
• Ціну, курс, комісію і ліміти визначає і перевіряє сервер, а не клієнт.
• MFA увімкнена на всіх зовнішніх входах, у адміністраторів FIDO2-ключі або passkeys.
• Для всіх доменів є SPF, DKIM і DMARC, політика DMARC рухається до quarantine або reject.
• Є перелік усього, що видно з інтернету, версії звірено з каталогом CISA KEV.
• Глобальних адміністраторів менше п'яти, зайві права і старі акаунти прибрано.

Завантажити чекліст підготовки (PDF)PDF · A4

Як ми проводимо такі перевірки, описано на сторінці як Veiltrack проводить пентест; там же можна завантажити демо-звіт на вигаданому застосунку.

Автор: Владислав Краєвський, засновник Veiltrack. У кібербезпеці з 2019 року, понад шість років досвіду пентесту, досвід керівництва командою пентестерів.

FAQ

Звідки взято історії і чому в них немає назв?

Це знеособлені випадки з практики наших спеціалістів, без назв, дат і деталей, за якими можна впізнати компанію.

Чи можна вважати 64% і 36% статистикою фішингу в Україні?

Ні. Це результати однієї навчальної симуляції в одному великому банку, обидва відсотки рахуються від усіх його працівників. Це одна симуляція, а не статистика по Україні. Репрезентативна статистика потребує багатьох організацій і єдиної методики, тому для міжнародного контексту ми окремо наводимо публічні дослідження: Verizon DBIR 2026, OWASP, NCSC, CERT-UA.

Яке слабке місце закривати першим?

Те, що веде до грошей або до великих обсягів даних: бізнес-логіку платежів, доступ до чужих об'єктів в API і адміністраторські акаунти без стійкої до фішингу MFA. Далі пошта і забуті сервіси.

Чи достатньо навчити працівників не переходити за посиланнями?

Ні. У фішинг-симуляції з цієї статті за посиланням перейшли 64% усіх працівників, а 36% ввели логін і пароль. Навчання потрібне, але його варто поєднувати з технічним захистом: NCSC рекомендує надавати перевагу FIDO2 перед MFA з кодами. ^[5]

Чи можна використовувати цей матеріал у публікаціях?

Так, з посиланням на цю сторінку і атрибуцією «Джерело: практика наших спеціалістів, описана Владиславом Краєвським, засновником Veiltrack». Не варто подавати ці випадки як «дослідження Veiltrack» чи «статистику українських банків». Цифри зі сторонніх досліджень краще цитувати за першоджерелами з переліку нижче.

Посилання

1. Verizon: 2026 Data Breach Investigations Report news release (19 May 2026) verizon.com
2. Verizon: 2026 Data Breach Investigations Report (full report) verizon.com
3. OWASP Top 10 API Security Risks 2023 api-security.owasp.org
4. OWASP Web Security Testing Guide: Introduction to Business Logic github.com
5. NCSC: Multi-factor authentication for your corporate online services. Recommended types of MFA ncsc.gov.uk
6. CERT-UA: Оновлений інструментарій UAC-0057: OYSTERFRESH, OYSTERSHUCK та OYSTERBLUES (21.05.2026) cert.gov.ua
7. NCSC: Email security and anti-spoofing ncsc.gov.uk
8. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) rfc-editor.org
9. Google Workspace Admin Help: Email sender guidelines support.google.com
10. Microsoft Learn: Best practices for Microsoft Entra roles learn.microsoft.com
11. CISA: Known Exploited Vulnerabilities catalog data github.com