Комплекс под названием TIKTOUK объединяет три независимых инструмента. Они вместе ищут уязвимые сайты на WordPress, читают открытые конфигурационные файлы и извлекают из них учётные данные. Опубликованный разбор описывает полный цикл: от первичного перебора страниц до отправки собранных сведений на центральный узел. Схема рассчитана на массовый охват, цель выбирает автоматика, а не человек. Пострадать могут владельцы сайтов, хостинг-провайдеры и компании, чьи сотрудники пользуются корпоративной почтой через плагины WordPress.
Описание
Первый компонент перебирает адреса и определяет, работает ли на них WordPress. Затем он обращается к программным интерфейсам сайта необычными запросами. В адрес подставляется заведомо некорректная строка, рядом уходят операции удаления и создания записей. Такой набор проверяет, как система обрабатывает нестандартные обращения. Когда сервер отвечает отказом, инструмент повторяет попытку в другом формате и нередко получает согласие. Смена формата важна для защиты: одну и ту же проверку видно в журналах дважды. Сначала она выглядит как обычный запрос, потом как загрузка данных.
По данным SpiderLabs, слабым местом оказалось соседство открытой конфигурации и зашифрованных настроек плагинов. Второй компонент забирает резервную копию файла конфигурации, извлекает из неё доступы к базе данных и служебные ключи сайта. Те самые ключи потом используются для расшифровки паролей почтовых сервисов, сохранённых в настройках плагинов. Речь не о взломе шифрования. Ключ лежал рядом с зашифрованными данными, поэтому шифрование перестаёт защищать пароли.
Тот же инструмент проверяет, не выложены ли наружу файлы окружения, служебные каталоги системы контроля версий, резервные дампы баз и журналы отладки. В ответах он ищет записи о подключении к базе, параметры почтовых серверов, пары облачных ключей и шаблоны программных интерфейсов. Отдельный режим работы нацелен исключительно на облачные учётные данные. Найденное не остаётся на машине злоумышленника: каждый результат уходит на центральный узел. Тот распределяет задания между исполнителями и собирает отчёты.
Из настроек трёх популярных плагинов для отправки писем - WP Mail SMTP, Easy WP SMTP и FluentSMTP - исследователи восстановили открытые пароли. Для каждого формата применялся свой способ преобразования, но результат совпадал с исходными значениями. Ключевой вывод: для восстановления хватило материала из конфигурации сайта. Дополнительно инструмент превращал облачный секретный ключ в пароль почтового шлюза. Это открывает доступ к рассылке писем от имени компании.
Третий элемент - отдельная программа для Linux, написанная на Go. Она собирает подключённые к страницам скрипты и просматривает их содержимое. В находках оказались токены платёжного сервиса SendGrid, ключи доступа к платформам искусственного интеллекта Anthropic и Bedrock, а также облачные пары ключей. Клиентский код по-прежнему часто содержит секреты, которые разработчики считают скрытыми от посторонних.
Разбор опирается на два предупреждения WordPress об уязвимостях. Первое касается недостаточной очистки параметра выборки записей: непроверенные данные приводят к внедрению SQL-кода. Второе описывает путаницу маршрутов пакетной обработки. Вместе эти уязвимости позволяют выполнить произвольный код на сервере. Под угрозой ветки 6.9.x до версии 6.9.5 и 7.0.x до 7.0.2. Авторы отмечают, что успешную эксплуатацию они не воспроизводили, тестовый стенд возвращал подготовленные ответы.
Отдельная часть отчёта касается реального инцидента. Аналитик Бен Ли из LevelBlue описал телеметрию. Атакованный узел загружал полезную нагрузку с внешнего сервера и продолжал с ним связь, получая задания и передавая результаты. Другой аналитик, Леон Коттрелл, изучил попавшую в открытый доступ панель TIKTOUK. В ней находились около 50 тысяч действующих серверных учётных данных с почти 37 тысяч доменов, включая сотни подтверждённых облачных ключей. Наблюдение продолжается: найдены дополнительные панели и связанный ботнет на Go с возможностью удалённо выполнять команды.
Границы исследования обозначены прямо. Запуски шли на синтетических данных и задачах, которые подавал сам аналитик. Они подтверждают поведение программ, но не факт взлома конкретного сайта, не подлинность похищенных паролей и не автоматическую передачу данных между компонентами. Инцидент подтверждается только сверкой журналов пострадавшей системы с сетевыми обращениями и отправленными отчётами.
Защитникам стоит обращать внимание на сочетание признаков. Нестандартные обращения к программным интерфейсам сайта, следом - запросы к резервным копиям конфигурации, файлам окружения и дампам баз с одного узла. Сами по себе отдельные пути или имена параметров вредоносную активность не доказывают. Картину даёт связка сетевых запросов с последующей отправкой отчётов на внешний адрес. Полезно заранее определять, какие служебные файлы вообще доступны снаружи, и закрывать их.
Для владельцев сайтов практические выводы просты. Обновляйте WordPress и плагины до актуальных версий, не оставляйте в открытом доступе резервные копии конфигурации, дампы баз и журналы отладки. Удаляйте лишние файлы окружения. Хранить ключ шифрования рядом с зашифрованными паролями бессмысленно: при утечке конфигурации они раскрываются. Проверяйте клиентский код на секреты и не встраивайте долгоживущие ключи в страницы. Ротация облачных и почтовых учётных данных, двухфакторная аутентификация и ограничение прав почтовых шлюзов снижают ущерб от подобных сборщиков.
Индикаторы компрометации
