В мире кибербезопасности есть такие примеры атак, что не знаешь — плакать или смеяться. В 2023 году один из крупнейших производителей бытовой химии в мире — Clorox, оценённый в $16 миллиардов, — стал жертвой взлома. Взлома, совершённого по принципу «дай пароль, пожалуйста». И теперь компания судится со своим IT-подрядчиком на $380 миллионов.
Да, это не шутка.
Хакер, предположительно из группировки Scattered Spider, просто позвонил в техническую поддержку подрядчика Clorox — компании Cognizant, — представился сотрудником и… попросил сбросить пароль. Техподдержка не удосужилась проверить ни личность, ни ID, ни даже имя менеджера. Просто предоставила доступ.
Цитата из стенограммы телефонного разговора (она стала частью судебных материалов):
— I don’t have a password, so I can’t connect.
— Oh, OK. OK. So let me provide the password to you OK?
После этого злоумышленники получили удалённый доступ, прошли внутрь корпоративной инфраструктуры и начали распространяться по системам Clorox. В результате — массовые сбои в производстве, сбитые цепочки поставок и почти два месяца хаоса. На восстановление систем ушли недели, ущерб — $380 миллионов, включая прямые убытки и потерянную прибыль.
Clorox работал с Cognizant с 2013 года — та оказывала им поддержку IT-инфраструктуры, в том числе верификацию пользователей. В иске Clorox указывает, что ещё в феврале 2023 года Cognizant заверила: протоколы безопасности обновлены, все сбросы паролей проходят только при проверке через MyID или менеджера. Но на деле выяснилось: никакой проверки не было, и хакер получил доступ без препятствий.
Также в иске говорится, что Cognizant медлила с реагированием, допустила новые ошибки при восстановлении доступа и нарушила SLA.
Cognizant в ответ утверждает: они не отвечали за кибербезопасность Clorox, а только за техническую поддержку. И действовали в рамках контракта.
Если вы работаете в ИБ, вы знаете: самые громкие взломы происходят не из-за дыр в коде, а из-за дыр в голове — точнее, в процессе. Этот кейс — textbook social engineering. Никаких вирусов, никакой магии, только телефонный звонок и слабый регламент в первой линии поддержки.
Мы учим сотрудников не кликать по подозрительным ссылкам. Но кто учит help desk спрашивать ID? Кто проверяет, как действительно сбрасываются пароли? Часто это «серые зоны» — не прописанные, не контролируемые, не автоматизированные. А значит — уязвимые.
Что делать компаниям
Первым делом стоит разобраться: кто и как у вас сбрасывает пароли. Это может показаться мелочью — но именно с неё всё начинается. Если у доступа нет жёсткой верификации, если help desk может выдать его «на честное слово», значит, у вас не ИБ, а иллюзия ИБ.
Любая выдача прав доступа должна сопровождаться проверкой личности — желательно не вручную, а через автоматизированные системы. И важно не просто прописать это в политике, а убедиться, что на практике всё работает именно так.
Наконец, обучение должно касаться не только рядовых сотрудников, но и тех, кто стоит у руля технической поддержки. Потому что социальная инженерия не различает уровней доступа — она работает в любой уязвимой точке.
Настоящая кибербезопасность начинается не с фаерволов, а с простого, но обязательного вопроса:
«А кто ты такой?»