Атаки в браузере все чаще проходят мимо EDR не потому, что endpoint-защита «сломалась», а потому что ей часто нечего ловить: нет нового процесса, подозрительного exe-файла или классического вредоноса. По данным BleepingComputer, NordLayer описывает три сценария, где решающие действия происходят внутри браузерной сессии: кража токенов, вредоносные расширения и манипуляции пользователем до запуска кода на хосте.
Проблема особенно заметна в компаниях, где большая часть работы переехала в SaaS. Сотрудник входит в облачный сервис, подтверждает OAuth-запрос, открывает HR-файлы, выгружает документы или загружает данные в веб-приложение. Для EDR это может выглядеть как нормальная работа браузера: пользователь авторизован, процесс легитимный, исполняемый файл тот же самый. NordLayer ссылается на свой Browser Security Report 2026: браузерный доступ есть во всех 504 рассмотренных приложениях, а 79% инструментов доступны только через браузер.
Первый сценарий — adversary-in-the-middle-фишинг. В 2026 году группа Storm-2755, которую отслеживает Microsoft, атаковала сотрудников в Канаде через поисковое отравление и вредоносную рекламу. Люди искали «Office 365», попадали на поддельную страницу входа Microsoft 365, а инфраструктура злоумышленников проксировала авторизацию в реальном времени. Так атакующие получали не только логин и пароль, но и session cookies, OAuth-токены и результат прохождения MFA.
Дальше украденная сессия переиспользовалась уже с инфраструктуры атакующих. Microsoft наблюдала, как один и тот же session ID переходил от браузера жертвы к user agent Axios. После этого злоумышленники заходили в сервисы Microsoft, искали payroll- и HR-данные, создавали правила в почте, чтобы скрывать письма о смене банковских реквизитов, а в отдельных случаях добирались до Workday. Для endpoint-телеметрии вход мог выглядеть легитимно: браузер открыт, пользователь сам прошел MFA, вредоносный процесс на машине не появился.
Защита здесь начинается не с еще одного алерта в EDR, а с устойчивой к фишингу аутентификации. FIDO2 WebAuthn привязывает ответ к легитимному origin, поэтому прокси между пользователем и настоящим провайдером идентификации ломает сценарий атаки. Плюс нужны браузерные политики: блокировка фишинговых доменов, запрет неразрешенных веб-приложений, условия доступа по выделенному IP или другим сетевым признакам, если это поддерживает identity provider.
Второй сценарий — вредоносные расширения. Они живут в профиле браузера, выполняются внутри обычного browser process и используют стандартные API: читают содержимое страниц, отслеживают URL, взаимодействуют с формами, отправляют данные по HTTPS. На уровне хоста это может выглядеть как обычный браузер, который ходит в сеть. Без контекста по расширениям команда безопасности видит трафик, но не понимает, какой именно аддон его инициировал, какие разрешения у него есть и одобрен ли он компанией.
Пример свежий и неприятный: в марте 2026 года Microsoft сообщала о вредоносных Chromium-расширениях, замаскированных под AI-ассистентов. Их установили около 900 000 раз, активность подтвердилась более чем в 20 000 корпоративных tenants. Расширения собирали посещенные URL и содержимое разговоров в ChatGPT и DeepSeek, а затем периодически отправляли данные на инфраструктуру атакующих. Для бизнеса вывод простой: extension allowlist, запрет самовольной установки и регулярный аудит разрешений уже не гигиена для параноиков, а базовая часть контроля SaaS-среды.
Третий сценарий — атаки, которые почти целиком проходят до endpoint-исполнения. Скомпрометированный сайт, вредоносная реклама или внедренный скрипт могут изменить содержимое страницы, перенаправить пользователя, прочитать доступные данные или подменить содержимое буфера обмена. Пользователь также может сам загрузить чувствительный файл в неразрешенный SaaS или AI-сервис. Ущерб уже есть, а артефактов, под которые проектировался EDR, все еще может не быть.
Хороший пример — ClickFix и его вариант TerminalFix, который Microsoft наблюдала в августе 2026 года. Скомпрометированные сайты показывали фальшивую Cloudflare CAPTCHA. После клика страница копировала в буфер обмена вредоносную PowerShell-команду и просила пользователя открыть Windows Terminal или PowerShell и вставить ее. До этого момента атака держалась на браузерном контенте, clipboard manipulation и социальной инженерии. Только после запуска команды появлялась привычная для EDR картина: PowerShell, загрузка ZIP-архива, DLL side-loading, закрепление через реестр и scheduled tasks, разведка Active Directory, обратный туннель.
Атаки в браузере не отменяют EDR: он по-прежнему нужен, когда начинается выполнение кода, persistence, разведка и сетевое поведение на хосте. Но рассчитывать, что endpoint-телеметрия увидит все в SaaS-среде, уже опасно. Браузер стал рабочим столом для корпоративных данных, админок и identity-процессов, а значит, контроль расширений, веб-доступа, загрузок, буфера обмена и фишинговых маршрутов постепенно переезжает из категории «приятно иметь» в категорию «почему у нас этого еще нет».