ГК Softline: когда удаленный доступ становится инструментом атаки

Исследователи обнаружили три инцидента, в которых злоумышленники использовали вредоносные клиенты ScreenConnect, программы для удаленного доступа к компьютерам. Для компаний, где этот инструмент применяется легитимно, возникает вопрос: как отличить штатную работу сотрудника или подрядчика от атаки? Само название запущенной программы этого не объясняет. Оценка риска требует проверки источника установки клиента и действий, которые происходят после подключения.

В этих инцидентах клиенты запускали четырехэтапную цепочку VBScript. В зависимости от условий на зараженном компьютере она могла установить бэкдор ScreenConnect, инструменты повышения привилегий или криптомайнер. Особую опасность представляла возможность передачи скриптов на новые системы через подключения ScreenConnect. Это означает, что при обнаружении атаки нельзя ограничиваться проверкой одной машины: необходимо учитывать ее соединения с другими узлами.

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

Мы в Softline считаем, что защита от такого сценария начинается с контроля установки ПО, а обнаружение требует анализа поведения программы. Нужно знать, откуда появился клиент, кто использует подключение и какие процессы, изменения файлов и сетевые соединения с ним связаны. Разрешение на использование инструмента не должно исключать его действия из мониторинга.

Риск зависит от порядка установки ПО

Возможность установить вредоносный клиент ScreenConnect зависит от того, как компания контролирует установку ПО. Если на рабочую станцию можно установить программу из внешнего или непроверенного источника, одного списка разрешенных приложений недостаточно: название клиента не подтверждает его происхождение.

Чтобы снизить риск, ScreenConnect следует устанавливать из внутреннего репозитория, проверенного ИБ, а установку ПО из внешних и непроверенных источников ограничивать. Эти меры должны действовать одновременно: проверка установочного пакета теряет смысл, если на компьютер можно установить другой клиент в обход принятого порядка.

Поэтому при оценке риска необходимо выяснить, откуда ScreenConnect попал на рабочую станцию. Знакомое название не подтверждает, что клиент установлен из согласованного источника. Особенно важно проверить это при обнаружении нетипичных действий после подключения.

Управленческая задача здесь связана с ответственностью за установку. ИБ должна определять требования к проверке источников и ограничениям, а эксплуатация должна обеспечивать соблюдение принятого порядка. Тогда проверка происхождения клиента становится частью работы с ПО, а не отдельным поиском сведений уже во время инцидента.

Однако даже при легитимном использовании ScreenConnect одного контроля установки недостаточно для оценки происходящего на машине. Необходимо наблюдать за действиями после подключения и сопоставлять их с рабочей задачей.

Что должно насторожить администратора

Главный источник информации для обнаружения такой атаки связан с цепочкой процессов. Если после ScreenConnect запускаются wscript.exe, PowerShell или другие интерпретаторы, а затем выполняются VBScript из временных каталогов, это нетипичная активность, которая требует проверки.

Значение имеет вся последовательность. Нужно установить, что именно запустил клиент удаленного доступа, какой скрипт начал выполняться и какие действия последовали. Отдельная запись о работающем ScreenConnect не показывает этой связи и потому мало говорит о наличии угрозы.

Дополнительными сигналами служат новые файлы в %TEMP% или %APPDATA%, изменения автозапуска, попытки отключить защитные средства и неожиданные сетевые соединения. Их следует сопоставлять с запуском процессов и временем подключения.

Например, появление нового файла во временном каталоге не объясняет, зачем он создан. Но если после подключения ScreenConnect запускается интерпретатор, выполняется VBScript и меняется автозапуск, администратору нужно проверить эти события как одну последовательность. Неожиданное соединение или попытка отключить защиту дополняют картину.

Для нас в Softline важно, чтобы мониторинг позволял восстановить эту последовательность. Если события рассматриваются по отдельности, связь между удаленным подключением и последующими изменениями может остаться незамеченной. Компания будет видеть работу разрешенной программы, но не сможет оценить действия, которые через нее выполняются.

Технические события нужно сопоставлять с работой сотрудника

Чтобы отличить подозрительную активность от штатной, необходимо понимать, как ScreenConnect используется в компании. Кто подключается к компьютеру, откуда приходит соединение и в какое время сотрудник или подрядчик выполняет работу.

Если после такого подключения с той же машины появляются соединения с другими узлами и начинается запуск скриптов, это должно фиксироваться средствами мониторинга. Дальше требуется установить, связано ли происходящее с выполняемой задачей.

Для такой проверки нужны сведения от эксплуатации. Служба ИБ анализирует процессы, файлы и трафик, а специалисты, отвечающие за обслуживание, подтверждают, какие действия были запланированы. Без этого техническая последовательность остается без объяснения: события видны, но их связь с работой сотрудника не установлена.

Время подключения тоже нужно учитывать вместе с остальными признаками. Оно помогает сравнить активность с обычным порядком использования ScreenConnect, но не заменяет проверку действий. Подключение в привычное рабочее время само по себе не объясняет запуск скриптов или появление соединений с другими машинами.

Поэтому порядок разбора должен предусматривать взаимодействие ИБ и эксплуатации. Необходимо заранее определить, кто проверяет подозрительную активность и кто предоставляет сведения о работах. Это позволяет перейти от обнаруженного сигнала к оценке риска.

Почему антивирусных событий недостаточно

Ориентироваться только на антивирусные события в таком сценарии недостаточно. Нужна корреляция: кто запустил ScreenConnect, откуда пришло подключение, какие процессы появились после него, что изменилось на диске и куда пошел трафик.

Каждый источник отвечает на свою часть вопросов. Цепочка процессов показывает запуск интерпретаторов и скриптов. Изменения файлов и автозапуска помогают установить последующие действия. Сетевые соединения позволяют проверить, с какими узлами взаимодействовала машина. Сведения о пользователе и подключении связывают эти события с сеансом удаленного доступа.

Вместе они дают основу для расследования. Можно проверить, какие действия относились к обслуживанию, а какие не имеют подтвержденной рабочей причины. Если же анализ ограничен одним типом событий, часть последовательности остается неизвестной.

Одной технологии поэтому недостаточно. Средства мониторинга должны предоставлять связанные сведения, а сотрудники должны уметь сопоставлять их с порядком эксплуатации. Обнаруженный запуск скрипта требует разбора, а для разбора нужны и технические данные, и информация о том, кто работал с машиной.

Расследование не должно ограничиваться одним компьютером

Возможность распространения скриптов через ScreenConnect требует внимания к связанным подключениям. Если на одной машине обнаружена подозрительная цепочка, необходимо проверить, какие соединения происходили и появилась ли похожая активность на других системах.

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

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

Для бизнеса важно сохранить контроль над удаленным доступом, который используется в работе. Это требует двух постоянных процессов: соблюдения порядка установки ПО и наблюдения за действиями после подключения. Руководителю ИБ необходимо закрепить ответственность за оба процесса и обеспечить взаимодействие с эксплуатацией при разборе отклонений. Тогда легитимность инструмента не станет основанием игнорировать подозрительное поведение, а обнаружение атаки приведет к проверке ее последствий и связанных систем.