Почему скорость блокировки вредоносной инфраструктуры критична?
Трояны почти никогда не работают в одиночку. За ними стоит командный сервер (C&C), домены для приёма команд и облачные хранилища для краденых данных. Время жизни этой инфраструктуры — ключевой фактор успеха атаки. Чем дольше она активна, тем больше устройств заражается и тем больше данных попадает в руки злоумышленников. Поэтому время реагирования на инциденты — это не просто метрика эффективности техподержки, а механизм прямого противодействия кибератакам.
Если компания-провайдер блокирует аккаунт, связанный с вредоносным ПО, в течение первых минут, операторы трояна теряют управление ботнетом. Если же пауза затягивается, вредоносное ПО продолжает «жить», обновляться и расширять своё присутствие.
Backblaze: 11 минут — и троян остался без хранилища
В нашей практике мы столкнулись с тем, что троян семейства StealC использовал облачное объектное хранилище Backblaze B2 для выгрузки похищенных паролей и логинов. Как только мы отправили жалобу на официальный портал безопасности Backblaze, система автоматического мониторинга подозрительной активности сработала буквально мгновенно. Уже через пару минут на почту пришёл автоматический ответ, что обращение принято к рассмотрению, а ещё через несколько минут мы увидели, что доступ к бакету запрещён.
Через 11 минут после отправки жалобы бакет был полностью заблокирован, а аккаунт, с которого он был создан, помечен как связанный с вредоносной активностью. Backblaze также передала данные в координационный центр CERT, чтобы другие компании могли скорректировать свои защитные списки.
Быстрое реагирование на инциденты — это не одолжение провайдера, а его прямая обязанность. Пока виртуальная инфраструктура работает, злоумышленник легально пользуется чужими мощностями для атаки на третьих лиц.
reg.ru: неделя бездействия, которая стоила данных
А вот регистратор доменных имён reg.ru, через который были зарегистрированы домены для командных серверов того же трояна, повёл себя иначе. Наши обращения на почту support и через форму на сайте оставались без ответа в течение пяти дней. Только после подключения к разбирательству вышестоящей регистратуры и направления официального уведомления от CERT домены были приостановлены — но на это ушла целая неделя.
Один из наших сотрудников написал в поддержку письмо, на которое через три дня пришёл стандартный ответ с просьбой «подождать, пока служба безопасности проверит информацию». Никаких промежуточных обновлений не было. И только после того, как мы продублировали обращение на русском и английском языках, а также отправили ссылки на отчёт антивирусной компании, домены перевели в статус clientHold. За эту неделю троян успел распространиться на несколько тысяч новых машин, а часть украденных данных, вероятно, уже была продана на теневых форумах.
Почему регистратор так медлил? Чаще всего доменные регистраторы не имеют автоматизированных процедур для реагирования на жалобы о вредоносном использовании: они либо игнорируют запросы, пока не будет решения суда, либо просто не хотят рисковать, блокируя домены, которые могут оказаться «чистыми».
Сравнительная таблица: Backblaze vs reg.ru
| Критерий | Backblaze | reg.ru |
|---|---|---|
| Время реакции | 11 минут | более 7 дней |
| Автоматический мониторинг | Есть, применяется для выявления подозрительных бакетов | Нет, проверка вручную |
| Каналы приёма жалоб | Выделенный портал безопасности | Общая техподдержка, тикеты без приоритезации |
| Координация с CERT | Активная | Отсутствует, реагируют только на «официальные» письма |
Таблица наглядно показывает, что автоматизированные системы безопасности и наличие выделенного канала для жалоб радикально ускоряют процедуру. Даже в таком простом случае, как подозрительный бакет, современный хостинг-провайдер может отреагировать быстрее, чем крупный доменный регистратор.
Почему регистраторы доменов часто бездействуют?
Домены используются для сотен легальных целей, и блокировка по первому требованию может привести к конфликтам. Но когда речь идёт о явно вредоносном ПО, которое уже ассоциировано с трояном в отчётах антивирусных вендоров, ожидание «формальных процедур» выглядит как минимум странно. Сказывается и то, что работа доменного регистратора не предполагает глубокого анализа контента, который привязан к домену, тогда как облачный провайдер обычно имеет техническую возможность быстро отключить доступ к данным.
Что поможет ускорить реакцию на инциденты?
Очевидно, что идеальная ситуация — когда и облачные сервисы, и регистраторы внедряют автоматизированный мониторинг подозрительной активности. Пример Backblaze показывает, что достаточно иметь систему, которая при поступлении жалобы способна сопоставить данные об аккаунте с репутационными списками, и блокировка становится делом нескольких минут.
Для доменных регистраторов можно порекомендовать:
- ввести отдельный email или форму для сообщений об инцидентах безопасности с обязательным SLA;
- настроить автоматическую сверку доменов, упоминаемых в отчётах антивирусных компаний;
- наладить взаимодействие с национальными CERT, чтобы ускорить проверку и принятие мер.
Личное наблюдение автора
За годы работы в инфобезе я заметил: компании, которые однажды пережили крупный инцидент из-за своей медлительности, обычно кардинально пересматривают процессы. Backblaze, вероятно, на собственном опыте убедилась, что каждая минута простоя вредоносного бакета — это прямая репутационная угроза. С другой стороны, некоторые регистраторы, похоже, живут в парадигме «домен — это просто запись в базе», не задумываясь о том, как активно он используется злоумышленниками. Хочется верить, что после подобных случаев они пересмотрят свои регламенты.
Резюме
Сравнение 11 минут у Backblaze и недели у reg.ru наглядно демонстрирует, как разные подходы к реагированию на вредоносную активность влияют на масштаб ущерба. Быстрые автоматизированные процедуры, открытые каналы для жалоб и координация с CERT — это то, что отличает ответственного провайдера от компании, которая тянет время, пока троян собирает данные. Пользователям и исследователям стоит учитывать эти различия при выборе сервисов для своих проектов и при планировании взаимодействий с техподдержкой.
