Фишинг, который заставляет сотрудника самому запустить команду: как работает такая атака и чем ее остановить на рабочем месте
изображение: grok
Сотрудник открывает документ, видит сообщение об ошибке и следует инструкции по ее устранению. Через несколько секунд на рабочем компьютере запускается вредоносный код — хотя человек не устанавливал программу и не разрешал макросы. Так работает ClickFix: техника социальной инженерии, которая превращает привычное желание «починить и продолжить работу» в способ проникновения в корпоративную сеть. Остановить ее одним обучением или запретом PowerShell не получится. Защищать нужно сам переход от инструкции на веб-странице к выполнению команды в операционной системе. Подробности рассказывают эксперты «СофтМолл».
Вместо опасного вложения — опасная инструкция
В классическом фишинге злоумышленник часто предлагает открыть зараженный файл или ввести пароль на поддельном сайте. В ClickFix он добивается другого: убеждает человека самостоятельно выполнить команду на своем устройстве.
Предлог выглядит техническим и зачастую безобидным: не отображается документ, браузеру требуется обновление, видеоконференция не запускается, необходимо подтвердить, что посетитель — человек. Страница предлагает короткую последовательность действий, якобы устраняющую проблему.
ClickFix — не название вируса и не отдельная уязвимость. Это способ доставки и запуска вредоносного кода через действия пользователя. По данным Microsoft, такие сценарии распространяются через фишинговые письма, вредоносную рекламу и скомпрометированные сайты. Поэтому сводить защиту к проверке почты нельзя: сотрудник может столкнуться с атакой во время обычного веб-серфинга.
Для российских организаций это уже не теоретическая угроза. В июне 2025 года BI.ZONE сообщила как минимум о двух кампаниях, затронувших около 30 российских компаний в мае — начале июня. Злоумышленники представлялись силовыми ведомствами и присылали PDF-документы, которые подводили получателя к поддельной CAPTCHA. Дальнейшие действия приводили к запуску загрузчика Octowave Loader и трояна удаленного доступа.
Эта цифра описывает наблюдения конкретного исследователя, а не весь российский рынок. Но она показывает главное: сценарий легко адаптируется под местный язык, деловую переписку и привычные для сотрудников источники авторитетных требований.
Как устроена атака
Типовая цепочка ClickFix состоит из нескольких этапов.
Сначала человека вовлекают в правдоподобную рабочую ситуацию. Ему нужно прочитать документ, получить доступ к материалам или подключиться к встрече. Атакующему важно, чтобы сотрудник уже был заинтересован в результате.
Затем возникает искусственное препятствие. Сайт показывает ошибку или проверку «Я не робот». Внешне это может напоминать интерфейс известного сервиса, браузера или системы защиты от ботов. Само сообщение об ошибке при этом является частью страницы, а не достоверным уведомлением операционной системы.
После этого предлагается «исправление». При нажатии на кнопку страница может записать подготовленную команду в буфер обмена — в зависимости от браузера и доступных ему разрешений. Пользователь при этом не обязательно видит, что именно было скопировано. Далее ему предлагают открыть системное окно «Выполнить» или терминал, вставить содержимое буфера и подтвердить запуск.
Наконец, операционная система выполняет команду. Она может вызвать PowerShell, командную оболочку или другую штатную утилиту, которая загрузит и запустит следующий компонент атаки. Конечная цель различается: кража данных, удаленный доступ, закрепление в системе или подготовка дальнейшего проникновения.
Здесь проходит принципиальная граница: само копирование текста в буфер обмена обычно не означает выполнение кода. В типовом ClickFix решающий шаг делает человек, перенося содержимое веб-страницы в инструмент управления операционной системой.
Это не технический побег из песочницы браузера. Злоумышленник добивается того, чтобы пользователь сам выполнил действие за ее пределами.
Хотя многие известные сценарии рассчитаны на Windows, техника не ограничивается одной платформой. Microsoft описывает и варианты для macOS: меняются команды и полезная нагрузка, но сохраняется предложение запустить «исправление» в терминале.
Почему человек соглашается
Сила ClickFix — не столько в сложности кода, сколько в правильно выстроенной последовательности действий.
Во-первых, атака перехватывает текущую задачу. Человеку не предлагают отвлечься ради сомнительного выигрыша: ему мешают закончить работу, а затем показывают якобы короткий путь к ее продолжению.
Во-вторых, используется доверие к знакомым интерфейсам. Проверки CAPTCHA, уведомления об обновлениях и сообщения об ошибках встречаются ежедневно. Логотип известного сервиса снижает настороженность, хотя сам по себе ничего не доказывает.
В-третьих, потенциально опасное действие разбивается на простые операции. Пользователь воспринимает их как «нажать кнопку — вставить код проверки — подтвердить», а не как запуск программы с возможностью доступа к его данным.
Наконец, атака может маскироваться под действия самой службы безопасности. Например, атакующая команда отправляет сообщение об «обновленной памятке» и использует его для закрепления в сети. Этот пример не описывает ClickFix напрямую, но хорошо показывает общий механизм: даже предупреждение об угрозе может стать частью следующей социальной манипуляции.
Поэтому совет «доверяйте только сообщениям от ИТ» недостаточен. Нужен независимо проверяемый процесс обращения в поддержку — через известный сотруднику портал или номер, а не через контакты из подозрительного сообщения.
Почему привычные меры могут не сработать
ClickFix не делает средства защиты бесполезными. Он использует пробелы между ними.
В письме может не быть исполняемого вложения. PDF или ссылка служат только приглашением на следующий этап. Проверка файла не всегда раскрывает всю цепочку, особенно если продолжение требует действий человека.
Пользователь запускает штатную программу. PowerShell, cmd.exe или mshta.exe сами по себе не являются вредоносным ПО. Однако легитимность исполняемого файла не означает легитимности переданной ему команды. Такой подход называют living off the land — использованием уже имеющихся в системе инструментов.
Родительским процессом может оказаться не браузер. При запуске через окно «Выполнить» в цепочке часто фигурирует explorer.exe. Если детектирование построено только на схеме «браузер запускает командную оболочку», часть событий останется вне внимания.
Права администратора нужны не всегда. Даже в контексте обычного пользователя вредоносная программа может получить доступ к части рабочих файлов, пользовательским данным и доступным учетным материалам. Отсутствие запроса UAC не подтверждает безопасность действия.
Многофакторная аутентификация не предотвращает локальный запуск кода. Она остается важнейшим барьером против захвата учетных записей, но не заменяет защиту устройства. Более того, компрометация действующей сессии в некоторых сценариях позволяет использовать доступ без нового ввода пароля.
Из этого следует практический вывод: защита должна работать и тогда, когда сотрудник уже поверил инструкции.
Чем остановить ClickFix на рабочем месте
1. Обучать распознаванию опасного действия, а не только подозрительного письма
Сотруднику не нужно изучать синтаксис PowerShell. Ему нужно запомнить границу: для прохождения CAPTCHA, просмотра документа или подтверждения доступа не требуется вставлять команды в системное окно или терминал. Если сайт предлагает это сделать — остановитесь и обратитесь в поддержку через известный канал.
Это правило полезнее, чем длинный список признаков плохого фишинга. Грамотный текст, HTTPS и узнаваемый дизайн не исключают атаку.
Обучение должно включать и легитимные исключения. Если поддержка действительно использует диагностические команды, сотрудник должен понимать, как проверить заявку и личность специалиста. Иначе компания сама приучает людей к поведению, которое затем эксплуатирует атакующий.
Учебные проверки стоит проводить без вредоносной нагрузки и сбора реальных секретов. Оценивать нужно не только долю переходов, но и то, сколько сотрудников дошли до опасного действия, сколько сообщили об инструкции и как быстро поступило первое сообщение.
2. Ограничить выполнение кода, а не только доступ к одному окну
Отключение окна «Выполнить» для сотрудников, которым оно не нужно, может сократить число успешных атак. Но это вспомогательная мера: остаются другие способы открыть терминал или запустить команду. На ограниченность такого запрета указывает и «Лаборатория Касперского».
Более устойчивый подход — управление разрешенными приложениями и сценариями. Для Windows это могут быть App Control for Business, AppLocker или сопоставимые механизмы в средствах защиты. Политики должны учитывать роль рабочего места: потребности бухгалтера, разработчика и администратора различаются.
Особое внимание требуется интерпретаторам и штатным утилитам, способным выполнять код. Правило «разрешено все, что подписано известным поставщиком» само по себе не закрывает злоупотребление системными инструментами.
При этом Execution Policy в PowerShell нельзя считать полноценной границей безопасности. Microsoft прямо указывает это в документации: политика помогает контролировать запуск файлов сценариев, но не исключает выполнение введенных пользователем команд. Настройки RemoteSigned или AllSigned не равнозначны блокировке ClickFix.
Ограничения следует проверять на пилотных устройствах, включая влияние на поддержку и автоматизацию. Даже режим аудита у некоторых механизмов контроля сценариев имеет особенности, которые нужно учитывать до массового развертывания.
3. Сократить возможный ущерб
Работа без постоянных локальных административных прав, разделение обычных и привилегированных учетных записей, ограничение доступа к сетевым ресурсам и сегментация не гарантируют предотвращения ClickFix. Их задача — не позволить ошибке на одном рабочем месте автоматически превратиться в доступ ко всей инфраструктуре.
Дополнительный рубеж — контроль исходящих соединений. DNS-фильтрация, защищенный веб-шлюз и ограничения прямого доступа в интернет могут помешать загрузке следующего компонента или связи с управляющим сервером.
Однако полагаться только на репутацию домена нельзя: атакующие используют и легитимные скомпрометированные ресурсы. Поэтому сетевые ограничения должны дополнять, а не заменять контроль выполнения и защиту конечной точки.
Что должен видеть SOC
Для центра мониторинга ClickFix — прежде всего задача восстановления последовательности событий. Отдельный запуск PowerShell может быть штатным. Гораздо важнее сочетание признаков: пользователь открыл подозрительную страницу, затем запустил системную утилиту с нетипичными аргументами, после чего появились внешнее соединение, новый файл или механизм автозапуска.
Практически полезны следующие источники:
Телеметрия создания процессов: пользователь, родительский процесс, полная командная строка и дочерние процессы.
Журналы PowerShell, включая Script Block Logging там, где он применим и настроен.
События DNS, прокси и сетевых соединений, позволяющие связать запуск команды с загрузкой следующего компонента.
Изменения файлов, задач планировщика и автозапуска, указывающие на развитие атаки.
Артефакты RunMRU — история команд окна «Выполнить» в пользовательской ветке реестра Windows.
Microsoft и Unit 42 отдельно рассматривают RunMRU как полезный источник для расследования ClickFix. Но это не универсальный журнал выполнения: запуск из другого интерфейса может не оставить там записи. Отсутствие артефакта не доказывает, что атаки не было.
Правило вида «explorer.exe запустил PowerShell» тоже не должно автоматически означать инцидент. Его нужно обогащать контекстом: характером команды, ролью сотрудника, адресом назначения, последующими действиями. Иначе SOC получит поток ложных срабатываний.
Обычно этот принцип относится к злоупотреблению легитимными инструментами: необходимы одновременно ограничение возможности выполнения и выявление аномальной активности средствами мониторинга. Для ClickFix это особенно важно — разрешенная программа может выполнять совершенно неразрешенную задачу.
Если сотрудник уже нажал Enter
На этом этапе нельзя ограничиваться советом закрыть вкладку. Если команда выполнилась, браузер может уже не иметь отношения к продолжающейся атаке.
Сотруднику следует:
- Прекратить выполнять дальнейшие инструкции.
- Немедленно сообщить в ИБ или поддержку через известный канал, указав время и выполненные действия.
- Не запускать команду повторно «для проверки», не удалять файлы и не пытаться самостоятельно чистить систему.
- Действовать по корпоративному регламенту изоляции устройства; без указания специалистов не перезагружать его.
Команде реагирования нужно оперативно изолировать рабочую станцию, сохранив по возможности канал управления EDR, собрать доступные артефакты и определить, что успело выполниться. Затем — проверить другие устройства на признаки той же кампании.
Отдельная задача — оценка компрометации учетных данных. Если обнаружен инфостилер или иной доступ к секретам, одного удаления вредоносного файла недостаточно: могут потребоваться отзыв сессий и токенов, смена паролей с доверенного устройства и проверка доступных пользователю систем.
Не каждое выполнение команды заканчивается заражением: загрузку мог заблокировать веб-шлюз, а запуск — средство защиты. Но установить это должна проверка, а не отсутствие видимых симптомов.
Главный вывод
ClickFix меняет объект доверия: сотрудника убеждают довериться не файлу или форме входа, а инструкции. Поэтому стратегия «научим не открывать подозрительные вложения» больше не покрывает весь сценарий.
Устойчивая защита строится вокруг трех условий: человек распознает опасный переход от веб-страницы к системной команде; рабочее место ограничивает последствия даже при ошибке; SOC способен быстро связать действия пользователя с техническими событиями.
Критерий зрелости здесь — не обещание, что никто никогда не ошибется, а способность компании остановить атаку после этой ошибки.
