Что произошло
Google описал кампанию, где злоумышленники в основном использовали социальную инженерию и злоупотребление учётными записями, а затем двигались к инфраструктуре виртуализации.
Почему это важно
Инцидент показывает, что сильная техническая защита не компенсирует слабый процесс подтверждения личности. Доступ к учётной записи часто становится первым шагом к более глубокому компромиссу.
Что стоит проверить
- MFA и восстановление доступа
- Процедуры проверки личности службой поддержки
- Сессии и привилегированный доступ
- Устойчивую к фишингу аутентификацию, где это возможно
- Логи изменений аккаунтов и ролей
Что это означает на практике
В подобных сценариях граница между «технической» и «организационной» безопасностью почти исчезает. Если процесс поддержки позволяет обойти нормальную аутентификацию, злоумышленнику не обязательно ломать сложную систему: достаточно убедить человека или воспользоваться слабым восстановлением доступа. Поэтому проверка должна охватывать не только форму входа, но и весь жизненный цикл учётной записи.
Полезно заранее определить, какие действия действительно требуют усиленного подтверждения личности: сброс MFA, смена контактных данных, выдача привилегий, создание новых токенов и восстановление доступа. Логи этих операций должны позволять быстро понять, кто, когда и почему изменил состояние аккаунта.
Что даёт аудит
На аудите полезно проверять не отдельный индикатор, а весь путь: внешний сервис, идентификацию, права, данные, соседние системы и способность команды заметить попытку злоупотребления.