Только за первый квартал 2026 года APWG зафиксировала 971 181 фишинговую атаку — это на 13,8% больше, чем кварталом ранее. А уже в январе 2026 года Google нарушил работу того, что компания назвала одной из крупнейших в мире сетей residential-прокси, после того как выяснилось: за одну неделю через неё маршрутизировали трафик более 550 групп угроз. Как оказалось, прокси-инфраструктура стоит по обе стороны фишинговой борьбы.
Именно это противоречие большинство статей о «прокси и фишинге» игнорируют. Одни уверяют, что прокси — это щит (купи наш продукт и будешь в безопасности). Другие пугают тем, что прокси — это оружие атакующих. На самом деле всё сложнее и интереснее.
Злоумышленники используют прокси-инфраструктуру, чтобы скрыть источник трафика, переключаться между доверенными IP-адресами и красть уже аутентифицированные сессии — даже после MFA. Защитники применяют прокси, чтобы безопасно изучать подозрительные ссылки, смотреть, как фишинговые страницы отображаются в разных странах, и отсекать вредоносный трафик ещё до того, как он попадёт на их сайты. В этом руководстве разбираем обе стороны, а затем переходим к практическому рабочему процессу, который реально можно внедрить. Без общих слов и без чудо-решений.
- Сложность: средняя
- Время: около 25 минут на чтение и планирование; реализация зависит от этапа
- Что понадобится: базовое понимание веб-инфраструктуры вашей компании, доступ к DNS-настройкам домена, браузер Chrome (для шагов с Thunderbit) и, при желании, аккаунт у провайдера прокси
Что такое фишинг и почему бизнесу стоит об этом заботиться?
Фишинг — это атака на обмане. Злоумышленники используют электронные письма, SMS, поддельные страницы входа, QR-коды или фейковые сайты, чтобы заставить людей передать учётные данные, подтвердить вход, установить вредоносное ПО или перевести деньги.
Сегодня это уже не просто история про «плохое письмо». Современный фишинг включает страницы на облачном хостинге, поддельные формы входа Microsoft 365, QR-коды и кражу session-токенов.
Для бизнеса ставки вполне конкретные. В отчёте IBM 2025 Cost of a Data Breach среднюю глобальную стоимость утечки оценивают в 4,4 млн долларов США. В Internet Crime Report 2025 ФБР сообщается, что IC3 получил около 453 000 жалоб на кибермошенничество, а сумма заявленных убытков превысила 17,7 млрд долларов США; при этом на business email compromise (BEC) пришлось более 3 млрд долларов.
Кража учётных данных, мошеннические переводы, компрометация цепочек поставок, штрафы регуляторов — фишинг затрагивает всё это.
Далее: как прокси вписываются и в атаки, и в защиту, и как на самом деле выглядит многослойная оборона.
Двойная природа прокси: ваш щит и их оружие
Прокси — это посредник между вашим устройством и интернетом. Вместо вашего реального IP-адреса сайт видит адрес прокси. Это похоже на службу пересылки писем: получатель видит адрес пересылки, а не ваш домашний адрес.
Именно это свойство и создаёт проблему двойного назначения. Команды безопасности используют прокси, чтобы изучать угрозы, не раскрывая корпоративный IP или рабочую станцию аналитика. Атакующие применяют ту же самую технологию, чтобы вредоносный трафик выглядел как запросы обычных пользователей, жителей других стран или доверенных домашних сетей. Анализ Barracuda за апрель 2026 года объясняет это прямо: residential-IP выглядят подлинными, потому что привязаны к реальным домашним или небольшим бизнес-подключениям, а значит, антифрод-системы реже их помечают.
Большинство конкурирующих материалов описывают лишь одну сторону. Из-за этого у читателя складывается неполная картина — и защита получается такой же неполной.
Как злоумышленники используют прокси против вас
Для защитников бизнеса особенно важны три направления атак: анонимность и ротация IP, злоупотребление residential-прокси и обход доверенных платформ.
AiTM-фишинг: как это работает
AiTM — это атака, которая ломает предположение «MFA нас защищает» (спойлер: классическая MFA от неё не спасает).
В AiTM-атаке злоумышленник ставит reverse proxy между жертвой и легитимной страницей входа — например, Microsoft 365. Пользователь видит почти настоящий экран логина. Он вводит учётные данные, проходит MFA, и настоящий провайдер идентификации выдаёт session cookie. Но поскольку весь трафик проходит через прокси атакующего, тот перехватывает эту cookie. Затем он может воспроизвести её и зайти в аккаунт без пароля и без повторного запроса MFA.
Анализ Microsoft по Tycoon2FA, одному из самых распространённых AiTM-фишинг-китов, показывает, что операторы могут имитировать страницы входа Microsoft 365, Outlook, SharePoint, OneDrive и Google. Кит генерирует PDF и QR-коды, управляет цепочками редиректов и отслеживает использование MFA и перехват session cookie. В его инфраструктуре используются короткоживущие субдомены и размещение на Cloudflare, чтобы затруднить блокировку.
Это не теория. AiTM-киты активно применяются в масштабных атаках, и именно поэтому фраза «у нас есть MFA» не является полноценным ответом на фишинг.
Злоупотребление residential-прокси и ротация IP
Сети residential-прокси направляют трафик атакующего через реальные домашние IP-адреса, из-за чего фишинговые запросы выглядят легитимнее и проходят мимо IP-базированных антифрод-систем. Многие провайдеры недостаточно строго проверяют, как именно используются их IP, и это создаёт серую зону.
Самый показательный пример: в январе 2026 года Google Threat Intelligence Group нарушила работу residential-прокси-сети IPIDEA, сократив доступный пул устройств на миллионы. GTIG зафиксировала более 550 отдельных групп угроз, использовавших exit-узлы IPIDEA в течение одного семидневного периода. Расследование выявило пересечения с ботнетами, злоупотреблением доступом к SaaS, password spray-атаками и глобальными шпионскими операциями. Во многих SDK для прокси отсутствовало явное согласие пользователей.
В рекомендации ФБР 2026 года по residential-прокси среди преступных сценариев названы фишинг, вход с украденными учётными данными, brute force, захват аккаунтов, спам и маскировка C2-инфраструктуры.
Размещение на доверенных платформах и обход детектирования фишинг-китов
Ещё один способ обхода — размещение фишинговых страниц на доверенных платформах, таких как SharePoint, Google Docs или Azure Blob Storage, чтобы пользоваться их репутацией домена. Анализ Microsoft по угрозам в Azure Blob Storage показывает, что атакующие используют это для размещения поддельных страниц входа Microsoft, делая их менее заметными для жертв, которые судят о легитимности только по сертификату.
Фишинговые киты тоже умеют прятаться. Разбор Cofense о фишинг-китах описывает фильтрацию по геолокации, user-agent и языку, CAPTCHA, обнаружение developer tools и редиректы на настоящие страницы. Если посетитель не соответствует целевому профилю — не та страна, не тот браузер или он похож на security scanner — страница покажет безобидный экран или 404.
Сканирование с одного корпоративного IP или из облачного дата-центра такие страницы не найдёт. Кит буквально создан, чтобы прятаться от вас.
Как защитники используют прокси, чтобы дать отпор
С оборонной стороны прокси решают четыре практические задачи:
-
Анонимное сканирование URL и доменов. Подозрительные ссылки прогоняются через контролируемый прокси, чтобы целевой сайт видел IP прокси, а не ноутбук сотрудника или корпоративную сеть. Это снижает прямой риск и делает расследование воспроизводимым.
-
Сбор threat intelligence. Ротационные прокси позволяют собирать данные о фишинговой инфраструктуре, списках доменов, публичных фидах угроз или недавно зарегистрированных доменах без блокировки после нескольких запросов. (Разумеется, только в рамках закона и условий использования сервисов.)
-
Геораспределённое выявление фишинга. Прокси в разных регионах позволяют проверить, ведёт ли себя подозрительный URL по-разному из США, ЕС, APAC или другого целевого рынка. Так выявляются киты, использующие геофенсинг или фильтрацию по user-agent — те же методы обхода, о которых говорилось выше.
-
Reverse proxy / WAF для собственных ресурсов. Reverse proxy стоит перед вашими доменами. Он не мешает сотрудникам нажимать на внешние фишинговые ссылки, но защищает собственные веб-ресурсы от бот-трафика, credential stuffing, вредоносных payload'ов и агрессивных паттернов запросов.
Почему одной MFA недостаточно против фишинга через прокси
Я наблюдал, как этот спор разгорается на десятках IT-форумов: «У нас есть MFA, значит мы защищены». У системных администраторов, которым приходилось разбирать инцидент AiTM, взгляд обычно совсем другой.
Механизм прост. Жертва проходит MFA на странице, которая выглядит как настоящий логин. Реальный провайдер идентификации выдаёт session token. Атакующий перехватывает этот токен через свой reverse proxy.
Аутентификация формально прошла успешно — но сессия уже у злоумышленника. Простого сброса пароля может быть недостаточно, если активные сессии и изменения MFA, внесённые атакующим, остаются в силе. Microsoft прямо указывает, что пострадавшим организациям нужно отзывать session cookie и откатывать изменения MFA, сделанные атакующим, а не ограничиваться стандартным remediation.
SMS-коды, OTP-приложения, push-подтверждения — всё это можно перехватить через фишинг, если пользователь завершает шаги внутри потока, контролируемого атакующим. MFA выполнила свою задачу. Проблема в том, что злоумышленник наблюдал за всем процессом.
Что на самом деле останавливает AiTM-фишинг
FIDO2 / passkeys. FIDO Alliance объясняет, что passkeys по своей архитектуре устойчивы к фишингу: нет пароля, который можно украсть, и нет данных входа, которые можно использовать повторно. Криптографическая пара ключей привязана к origin легитимного домена, поэтому прокси атакующего просто не может воспроизвести challenge. CISA подтверждает, что FIDO и PKI — единственные широко доступные небрендированные методы MFA, предотвращающие фишинг учётных данных.
Аутентификация на основе сертификатов. Решение корпоративного уровня, сложнее в развёртывании, но так же устойчиво к фишингу, поскольку опирается на сертификаты устройства, а не на коды, введённые пользователем.
Политики Conditional Access. В среде Microsoft Conditional Access может требовать соответствующие устройства, доверенные локации, проверки на основе риска или аутентификацию с фишинг-устойчивым уровнем защиты — это снижает ценность украденного session token, даже если атакующий его получил.
Всё это дополняет прокси, а не заменяет их. Цель — многослойная защита.
Практичные варианты для малого бизнеса с ограниченным бюджетом
Очевидное возражение: «Intune, MDM, аппаратные ключи — это бюджет уровня enterprise». Справедливо. Вот более доступный путь:
- Passkeys в браузере. Большинство современных браузеров поддерживают passkeys нативно. Покупать отдельное оборудование не нужно. Начните с аккаунтов администраторов, финансового отдела и HR.
- Бесплатное внедрение DMARC. Записи SPF, DKIM и DMARC можно опубликовать бесплатно. У Google Workspace и Microsoft 365 есть готовые инструкции по настройке.
- Защитная регистрация доменов. Зарегистрируйте распространённые опечатки и домены-двойники вашего бренда. У большинства регистраторов это стоит 10–15 долларов в год за домен. На каждом таком домене включите DMARC reject.
- Точечное обучение. Сделайте акцент на сценариях AiTM: поддельные страницы входа Microsoft 365, фейковые общие документы, QR-коды, атаки через device code и схемы «срочная оплата / срочный запрос от поставщика».
Думайте об этом как о подходе «начни здесь, улучшай потом». Даже частичное внедрение заметно снижает риск.
Какой тип прокси лучше всего подходит для защиты от фишинга?
Разные типы прокси решают разные задачи, и ошибка в выборе ведёт либо к лишним расходам, либо к слепым зонам.
| Тип прокси | Лучший сценарий против фишинга | Плюсы | Минусы | Уровень затрат |
|---|---|---|---|---|
| Дата-центр | Массовое сканирование URL, мониторинг доменов | Быстрый, дешёвый, высокая пропускная способность | Продвинутые фишинг-киты легко его распознают | Низкий |
| Residential | Геотаргетированное выявление фишинга, тестирование глазами пользователя | Выглядит как реальный пользовательский трафик, обходит геоблокировки | Медленнее, дороже, серьёзные этические вопросы к источнику | Высокий |
| Ротационный | Сбор threat intelligence, длительный мониторинг | Позволяет обходить IP-баны во время долгих сессий сбора | Сложнее настроить, переменная задержка | Средний |
| Reverse Proxy / WAF | Защита собственных веб-ресурсов | Фильтрует входящие угрозы, детектирует ботов, защищает от DDoS | Не помогает с выявлением исходящего фишинга | Средний |
Примечание об этичности источника. Кейс Google/IPIDEA и рекомендация ФБР ясно показывают: residential-прокси могут строиться на скомпрометированных устройствах, обманных SDK, скрытых условиях VPN или вредоносном ПО. Перед покупкой residential-трафика требуйте от провайдера прозрачного согласия пользователей, механизма отказа, возможности аудита и процедур обработки злоупотреблений. К провайдерам, которых ранее упоминали в исследованиях по безопасности (PacketStream, уже не существующий 911 Proxy), стоит относиться с максимальной осторожностью.
Для большинства малых и средних компаний разумнее начать с дата-центровых прокси для массового сканирования и reverse proxy/WAF для собственных доменов. Residential-прокси добавляйте только тогда, когда действительно нужно тестирование по географии и вы можете тщательно проверить провайдера.
Пошагово: как избежать фишинга с помощью прокси (практический рабочий процесс)
Большинство статей останавливаются на теории. Ниже к каждому шагу приложена рекомендация по инструменту и достаточно деталей, чтобы передать это IT-команде или сделать самостоятельно.
Шаг 1: отслеживайте недавно зарегистрированные домены, похожие на ваш бренд
Перед запуском кампаний злоумышленники регистрируют домены, похожие на ваши: thunderb1t.com, thunderbit-login.com, thunderbit-support.net.
Поймать их на раннем этапе — одно из самых ценных защитных действий.
Как это сделать:
- Составьте список для мониторинга из названия бренда, продуктов, имён руководителей и слов, связанных со входом в систему (например, «login», «portal», «invoice», «payment»).
- Ежедневно проверяйте логи Certificate Transparency (CT) через crt.sh, где можно искать сертификаты по домену или названию организации. Поскольку публично доверенные сертификаты обязаны попадать в CT, новые сертификаты для доменов-двойников будут видны там.
- Отмечайте домены с небольшим расстоянием редактирования от вашего бренда, подозрительными TLD (.xyz, .top, .click) или словами login/payment.
- Открывайте отмеченные страницы через прокси или sandbox — никогда не из браузера сотрудника.
Как здесь вписывается Thunderbit: batch extract API Thunderbit может обрабатывать до 100 подозрительных URL за одну задачу, используя renderMode: "full" для рендеринга фишинговых клонов с тяжёлым JavaScript. Вы задаёте JSON Schema для нужных данных — заголовок страницы, наличие формы входа, домен action формы, SSL issuer, цепочку редиректов, финальный URL. Вариант для CLI удобно встраивается в мониторинг через cron:
thunderbit batch extract --file suspicious-urls.txt --schema phishing-signals.json --render-mode full
Для нетехнических пользователей расширение Thunderbit для Chrome тоже подходит: с его помощью можно быстро извлечь и просмотреть подозрительные страницы буквально в пару кликов — удобно, когда нужно просто оценить несколько URL на глаз, а не запускать весь пайплайн по расписанию.
Ожидаемый результат: ежедневный или еженедельный отчёт о новых доменах-двойниках со структурированными метаданными, готовый для triage.
Попробовать Thunderbit для проверки подозрительных URL
Шаг 2: прогоняйте подозрительные ссылки через дата-центровые прокси
Прежде чем кто-то из вашей организации откроет подозрительную ссылку, проанализируйте её через контролируемый путь. Видимым будет IP прокси, а не устройство сотрудника и не корпоративная сеть.
Как это сделать:
- Для быстрой проверки используйте urlscan.io (web-sandbox с выбором страны сканирования) или VirusTotal (проверка URL десятками антивирусных движков и blocklist'ов).
- Для внутренних скриптов или анализа большого объёма запросов направляйте трафик через дата-центровый прокси:
curl -x http://proxy.example.com:8080 -I "https://suspicious.example"
- Для живых фишинговых страниц используйте одноразовую VM или browser sandbox. Не вводите учётные данные. Фиксируйте цепочку редиректов, заголовок страницы, конечный адрес, формы, скрипты и скриншоты.
- Никогда не отправляйте настоящие корпоративные логины и пароли. И осторожно относитесь к публичным сканам — некоторые сервисы показывают отправленные URL, если не включён приватный режим.
Ожидаемый результат: безопасная оценка назначения ссылки, поведения страницы и признаков угрозы — без риска для корпоративной среды.
Шаг 3: используйте геораспределённые прокси, чтобы выявлять таргетированные фишинговые кампании
Некоторые фишинговые киты показывают вредоносный контент только посетителям из конкретной страны или с определённым языковым профилем. Cofense отмечает, что геолокационная фильтрация — очень распространённый приём: посетители из «не той» локации видят безобидную страницу или 404, а целевая аудитория получает форму сбора учётных данных.
Как это сделать:
- Тестируйте подозрительные ссылки из тех регионов, где реально работают ваши сотрудники, клиенты и финансовая команда. Если компания базируется в США, но есть офис в Великобритании, проверяйте оба региона.
- Сравнивайте финальные URL, скриншоты, заголовки страниц, формы и HTTP-коды ответа по регионам.
- При анализе QR-кодов или мобильных приманок меняйте user-agent и языковые настройки — некоторые киты фильтруют и по ним.
- Передавайте на эскалацию URL, где в одной локации показан безобидный контент, а в другой — форма входа. Это сильный сигнал фишинга.
Ожидаемый результат: выявление геотаргетированных кампаний, которые были бы невидимы при проверке только из одной локации.
Шаг 4: внедрите reverse proxy или WAF для собственных доменов
Пора перейти от исходящего выявления к входящей защите. Reverse proxy и WAF стоят перед вашими веб-ресурсами и проверяют входящий трафик до того, как он попадёт на серверы.
Как это сделать:
- Направьте DNS домена на провайдера reverse proxy. Cloudflare — самый доступный вариант для малого и среднего бизнеса: DNS, CDN, WAF и правила в одном интерфейсе. Для приложений, размещённых в AWS, хорошо подойдёт AWS WAF, если вы уже используете CloudFront, ALB или API Gateway.
- Включите managed WAF rules. Они блокируют известные вредоносные IP, фильтруют бот-трафик и выявляют паттерны credential stuffing.
- Настройте rate limit для страниц входа, сброса пароля и контактных форм.
- Добавьте bot/challenge-правила для наиболее рискованных endpoint'ов.
- Еженедельно проверяйте события WAF — не оставляйте всё без присмотра.
Ожидаемый результат: входящий вредоносный трафик отсекается ещё до попадания на ваши серверы. Попытки credential stuffing на страницах входа блокируются или требуют дополнительной проверки.
Шаг 5: автоматизируйте и настройте постоянный мониторинг
Фишинг — это не разовая проверка. Новые домены, киты и инфраструктура появляются ежедневно, поэтому мониторинг должен работать по расписанию:
- Ежедневно: проверка CT на lookalike-домены и очередь подозрительных доменов.
- Ежедневно или ежечасно (для высокорискованных брендов): sandbox-проверка новых обнаруженных доменов.
- Еженедельно: анализ сводных DMARC-отчётов и паттернов подмены.
- Еженедельно: проверка событий WAF на credential stuffing и всплески ботов.
- Ежемесячно: оценка прогресса внедрения phishing-resistant MFA.
- Ежеквартально: тестирование процессов финансов и HR на реалистичных сценариях AiTM и BEC.
Как здесь вписывается Thunderbit: плановый сбор данных и рабочие процессы API/CLI Thunderbit помогают организовать повторяющийся мониторинг для нетехнических команд. Лучший сценарий использования — не «Thunderbit сам защищает от фишинга», а «Thunderbit помогает операционным командам собирать структурированные сигналы с подозрительных страниц и источников мониторинга доменов без написания собственного скрапера с нуля». Результаты можно отправлять в Google Sheets или Airtable для видимости в команде, или в Slack через простую интеграцию.
Ожидаемый результат: непрерывный цикл мониторинга, который выявляет новые угрозы за часы, а не за недели.
Что прокси не поймают: защита почты через DMARC, SPF и DKIM
Провайдеры прокси не всегда говорят об этом прямо: прокси — лишь один слой защиты, а фишинг через email, который вообще не проходит через proxy-слой, требует отдельной защиты.
Многие фишинговые атаки приходят с поддельных адресов отправителя. Прокси их не перехватит.
Настройка SPF с жёстким отказом
SPF (Sender Policy Framework) — это DNS-запись со списком IP-адресов, которым разрешено отправлять письма от имени вашего домена. Настраивайте -all (hard fail), а не ~all (soft fail), чтобы сразу отклонять неавторизованных отправителей.
Частая ошибка: забывают включить все легитимные сервисы отправки — CRM, маркетинговую платформу, провайдера транзакционных писем, helpdesk. Перед публикацией записи проверьте все источники отправки.
Развёртывание подписи DKIM
DKIM (DomainKeys Identified Mail) добавляет к исходящим письмам криптографическую подпись. Получатель проверяет, что сообщение не было изменено при передаче. У Google Workspace и Microsoft 365 есть встроенные инструкции по настройке DKIM. Обычно это занимает около 15 минут.
Принудительное применение DMARC в режиме reject
DMARC (Domain-based Message Authentication, Reporting & Conformance) сообщает принимающим серверам, что делать, если проверка SPF или DKIM не прошла. Критически важный шаг, который пропускают многие организации: перейти с p=none (только мониторинг) на p=reject (блокировать письма, не прошедшие проверку) после подтверждения легитимных потоков почты.
Многие компании оставляют DMARC на p=none бессрочно — видимость есть, защиты нет. Это как поставить камеру наблюдения, но никогда не запирать дверь.
Защитная регистрация доменов-двойников
Заранее зарегистрируйте распространённые опечатки и домены, похожие на ваш бренд. На этих защитных доменах включите DMARC reject, чтобы их нельзя было использовать для подделки отправителя. По цене 10–15 долларов в год за домен это одна из самых дешёвых и эффективных мер, о которой малый бизнес часто вообще не задумывается.
Собираем всё вместе: многослойная защита от фишинга
Ни один инструмент не останавливает фишинг сам по себе. Работает именно комбинация мер. Практический чек-лист:
Исходящий контур (расследование угроз):
- сканирование подозрительных ссылок через прокси;
- мониторинг доменов через CT-логи и batch extraction;
- геораспределённое тестирование кампаний, нацеленных на конкретные регионы.
Входящий контур (защита собственных ресурсов):
- reverse proxy / WAF для ваших веб-доменов;
- DMARC/SPF/DKIM для аутентификации почты;
- защитная регистрация доменов-двойников.
Аутентификация (защита аккаунтов):
- FIDO2 / passkeys как phishing-resistant MFA;
- политики Conditional Access (соответствующие устройства, проверки на основе риска);
- процедуры мониторинга и отзыва session token.
Люди — последняя линия защиты:
- обучение, сфокусированное именно на AiTM-приманках, QR-кодах и сценариях BEC;
- понятная культура сообщений об инцидентах — сделать репорт подозрительного письма простым и без наказаний;
- регулярная проверка процессов финансов и HR на реалистичных фишинговых сценариях.
Такой подход соответствует принципу defense-in-depth из NIST Cybersecurity Framework: несколько независимых уровней, чтобы сбой одного не означал полную компрометацию.
Для команд, которым нужно расследовать подозрительные URL, собирать threat data или масштабно мониторить домены, AI web scraper от Thunderbit может ускорить рабочий процесс — расширение Chrome для нетехнических пользователей, API/CLI для технических команд. Это не security-продукт сам по себе, но он заслуживает место в наборе инструментов аналитика. Подробнее можно узнать о веб-скрапинге без кода или изучить подходы к AI web scraping в нашем блоге.
Используйте AI web scraping для мониторинга угроз Get Started Free
Часто задаваемые вопросы
Как злоумышленники используют прокси для фишинговых атак?
Злоумышленники используют residential и rotating-прокси, чтобы скрыть свой реальный IP, переключаться между доверенными адресами, обходить IP-базированный антифрод и разворачивать AiTM reverse proxy для перехвата уже аутентифицированных сессий — даже после того, как жертва прошла MFA. Операция против IPIDEA в январе 2026 года показала, что одну residential-прокси-сеть использовали более 550 групп угроз.
Как reverse proxy помогает предотвращать фишинг и компрометацию сайта?
Reverse proxy стоит перед вашими веб-серверами и проверяет входящий трафик ещё до того, как он попадёт в инфраструктуру. Он блокирует известные вредоносные IP, фильтрует бот-трафик, ограничивает частоту попыток входа и выявляет credential stuffing или действия, связанные с фишингом. Но сотрудников от кликов по внешним фишинговым ссылкам он не защитит.
Можно ли полностью предотвратить фишинг с помощью прокси?
Нет. Прокси — это важный слой, но для фишинга через email нужны DMARC/SPF/DKIM, а для перехвата сессий через AiTM-атаки — phishing-resistant MFA вроде FIDO2/passkeys. Нужна многослойная защита, объединяющая прокси, аутентификацию почты, устойчивые к фишингу учётные данные и обучение сотрудников.
Что такое AiTM-фишинг и почему MFA его не останавливает?
AiTM (Adversary-in-the-Middle) фишинг использует reverse proxy между жертвой и настоящей страницей входа, чтобы перехватить session token после завершения MFA. Классическая MFA его не останавливает, потому что атакующий крадёт не пароль, а уже аутентифицированную сессию. FIDO2/passkeys устойчивы к этой атаке, поскольку криптографический challenge привязан к легитимному домену и не может быть воспроизведён через прокси атакующего.
Какой тип прокси лучше всего подходит для выявления фишинга?
Дата-центровые прокси лучше всего подходят для массового сканирования URL — они быстрые и дешёвые. Residential-прокси лучше для геотаргетированного тестирования — они реалистичны, но дороже; провайдера нужно тщательно проверять на этичность источника IP. Reverse proxy/WAF лучше всего защищают собственные сайты. Самый сильный подход — комбинация инструментов в зависимости от того, что именно вы хотите выявить или защитить.
Попробуйте Thunderbit для мониторинга угроз и AI-скрапинга Get Started Free
Узнать больше
