Не входьте в банк чи платіжний сервіс через несподіване посилання. Відкрийте відомий bookmark або введіть адресу вручну, перевірте account alerts, sessions і MFA; якщо credentials уже введено, негайно змініть їх і повідомте установу.
Фінансист отримує лист про «призупинений payout» і переходить на схожий login page. Якщо пароль уже введено, просте закриття вкладки не завершує інцидент: зловмисник може мати активну сесію, а його метою бути саме зміна payout endpoint.
Інформацію та офіційні джерела перевірено 2026-08-02. Якщо у матеріалі є майбутня дата набрання чинності, вона не означає, що правило вже діє.
Межі цього матеріалу
| Параметр | Сценарій |
|---|---|
| Хто платить | компанія або приватний клієнт, який отримав платіжну інструкцію |
| Кому | постачальник, керівник, marketplace або інша сторона, чию особу треба перевірити |
| Мета | запобігання credential phishing через платіжне посилання |
| Валюта / інструмент | invoice, банківський переказ, payment link або payout settings |
| Що змінює висновок | lookalike URL, shortened link, MFA method, session theft, device compromise і entered credentials |
Що потрібно знати до платежу
MFA додає бар’єр після компрометації пароля
CISA пояснює, що multifactor authentication потребує більше одного способу підтвердження особи й ускладнює доступ зловмисника навіть зі stolen password. Найстійкіший доступний метод слід увімкнути для фінансових і admin-акаунтів. (CISA — Require multifactor authentication)
Ключова контрольна умова
Фішинговий сайт може копіювати дизайн справжнього сервісу й використовувати HTTPS; замок не підтверджує легітимність домену. (CISA — Require multifactor authentication)
Яку доказову нитку зберегти
MFA підвищує захист, але користувач не повинен підтверджувати несподіваний prompt або передавати one-time code. (FTC — Scammers hide harmful links in QR codes)
Що змінює практичний висновок
Після введення credentials потрібні containment actions: офіційний reset, session revocation, review events і контакт із провайдером. (NCSC — Business payment fraud)
Покрокова підготовка
- Перевірте URL без входу з листа. Наведіть курсор або скопіюйте адресу в безпечний analyzer, перевірте hostname, але сам сервіс відкрийте через bookmark. Порівняйте alerts і payout status у справжньому кабінеті.
- Стримайте можливу компрометацію. З чистого пристрою змініть пароль, revoke sessions і recovery tokens, перевірте MFA methods, admin users та beneficiary changes. Повідомте провайдера через офіційний support і збережіть phishing URL, headers та timestamps.
- Перевірте без переходу. Подивіться повний URL, домен і контекст; відкрийте сервіс через bookmark та знайдіть той самий request у кабінеті.
- Стримайте компрометацію. З безпечного пристрою змініть пароль, відкличте sessions, перевірте MFA, payment settings і повідомте security або банк.
Які дані та документи зібрати
- оригінальне повідомлення з headers, URL або вкладенням у безпечному incident archive
- incident log із часом виявлення, сумою ризику, акаунтами, діями й контактами банку або платформи
- безпечний знімок URL, sender і часу фішингового запиту
- account security log та перелік containment actions
Документи мають пояснювати одну й ту саму операцію: хто платить, кому, за що, скільки, у якій валюті та до якої дати. Якщо назва отримувача, рахунок або призначення не узгоджуються між файлами, спочатку отримайте письмове пояснення й актуальну версію документа.
Практичний сценарій
Фінансист отримує лист про «призупинений payout» і вводить пароль на схожому домені. Він одразу закриває сторінку, з іншого пристрою відкликає sessions, змінює пароль і перевіряє реквізити.
Це приклад логіки перевірки, а не обіцянка результату для іншого клієнта. Навіть схожі платежі можуть відрізнятися через країну, банк, суму, валюту, тип отримувача та дату.
Типові помилки
- щодо предмета «перевірка URL перед входом або підтвердженням платежу» перевіряти підозрілий запит відповіддю на той самий лист або номером із нього; наслідок — втрата зв’язку з метою: запобігання credential phishing через платіжне посилання
- під час контролю предмета «перевірка URL перед входом або підтвердженням платежу» чекати завершення внутрішнього розслідування, якщо кошти вже відправлено й банк треба повідомити негайно; окремої оцінки потребують: lookalike URL, shortened link, MFA method, session theft, device compromise і entered credentials
- довіряти HTTPS як доказу справжнього банку
- схвалювати MFA prompt, який користувач не ініціював
Де проходить межа поради
Остаточні вимоги залежать від юрисдикції, банку, платіжного провайдера, статусу сторін і призначення операції.
Матеріал має інформаційний характер і не є юридичною, податковою, фінансовою, інвестиційною, імміграційною або санкційною консультацією. Для дії перевірте актуальний первинний документ і, коли потрібно, зверніться до профільного спеціаліста.
Як перейти від статті до конкретної заявки
TradePay приймає таку заявку на індивідуальну перевірку; менеджер підтвердить доступність, курс, підсумкову суму, реквізити та орієнтовний строк до оплати. Після цього чекліста можна передати підготовлений контекст менеджеру TradePay — країни, суму, валюту, призначення, реквізити й дедлайн.
За змінами платіжних маршрутів і практичними розборами можна стежити в Telegram-каналі TradePay Desk.
Важливо
Матеріал має інформаційний характер. Доступність маршруту, строк, курс і підсумкова вартість залежать від країни, валюти, реквізитів та перевірки конкретної заявки менеджером.
Джерела та перевірка
- CISA — Require multifactor authentication
- FTC — Scammers hide harmful links in QR codes
- NCSC — Business payment fraud
- FBI IC3 — Business Email Compromise
Дата редакційної перевірки: 2026-08-02.
TradePay Desk
Перевірте маршрут до відправлення коштів
Менеджер уточнить реквізити, валюту та доступний спосіб розрахунку для вашої заявки.
Зворотний зв’язок
Наскільки корисним був матеріал?
Оцінка допомагає редакції обирати теми та оновлювати пояснення.
Оберіть оцінку від 1 до 5.