БлогРазбор инцидента: как бывший сотрудник Cisco вывел из строя Webex Teams
Сентябрь 2018 года. Пять месяцев назад из Cisco уволился инженер. Его пропуск давно сдан, рабочая почта отключена, но доступ к публичному облаку по-прежнему действует. Он открывает ноутбук и по сохранившимся учётным данным подключается к облачной инфраструктуре компании в AWS. Из личного проекта в Google Cloud он запускает скрипт, который удаляет 456 виртуальных машин, обеспечивающих работу сервиса Webex Teams (сейчас — Webex). Утром тысячи пользователей по всему миру обнаруживают, что их корпоративный ресурс недоступен. Как один неотозванный доступ обернулся для Cisco миллионными убытками — разберём ниже.
18.09.2026'%20fill='%235A5A5A'/%3e%3c/svg%3e){kind=small}
5 мин.'%3e%3crect%20width='426'%20height='240'%20fill='%23C2DAFF'/%3e%3cpath%20fill-rule='evenodd'%20clip-rule='evenodd'%20d='M399.883%20247H153.98C107.189%20247%2069.1741%20208.816%2069.1741%20161.78C69.1741%20114.782%20107.189%2076.5979%20153.98%2076.5979C155.735%2076.5979%20157.453%2076.6356%20159.171%2076.7481C171.83%2020.8225%20221.683%20-21%20281.17%20-21C330.089%20-21%20372.511%207.28165%20393.049%2048.4288C395.327%2048.2787%20397.605%2048.2035%20399.883%2048.2035C454.479%2048.2035%20498.842%2092.7639%20498.842%20147.602C498.842%20202.477%20454.479%20247%20399.883%20247Z'%20fill='%23E3ECFD'/%3e%3crect%20x='95'%20y='163'%20width='74.9533'%20height='74.9533'%20rx='12.8541'%20transform='rotate(45%2095%20163)'%20fill='%2399C2FF'/%3e%3crect%20x='217'%20y='57'%20width='140'%20height='140'%20rx='69.5'%20fill='white'/%3e%3ccircle%20cx='287'%20cy='112'%20r='17'%20fill='%233A85F4'/%3e%3cpath%20d='M281.655%20114.57C281.856%20113.653%20282.669%20113%20283.608%20113H290.392C291.331%20113%20292.144%20113.653%20292.345%20114.57L302.465%20160.57C302.74%20161.818%20301.79%20163%20300.512%20163H273.488C272.21%20163%20271.26%20161.818%20271.535%20160.57L281.655%20114.57Z'%20fill='%233A85F4'/%3e%3cpath%20d='M94.5%2072C72.6848%2072%2055%2089.6848%2055%20111.5C55%20133.315%2072.6848%20151%2094.5%20151C116.315%20151%20134%20133.315%20134%20111.5C134%2089.6848%20116.315%2072%2094.5%2072ZM94.5%2089C106.926%2089%20117%2099.0736%20117%20111.5C117%20123.926%20106.926%20134%2094.5%20134C82.0736%20134%2072%20123.926%2072%20111.5C72%2099.0736%2082.0736%2089%2094.5%2089Z'%20fill='%23FF833E'/%3e%3cpath%20d='M249%20107C249%20104.791%20247.209%20103%20245%20103H127.5C122.806%20103%20119%20106.806%20119%20111.5C119%20116.194%20122.806%20120%20127.5%20120H245C247.209%20120%20249%20118.209%20249%20116V107Z'%20fill='%23FF833E'/%3e%3cpath%20d='M224%20150C226.209%20150%20228%20148.209%20228%20146L228%20105L213%20105L213%20146C213%20148.209%20214.791%20150%20217%20150L224%20150Z'%20fill='%23FF833E'/%3e%3cpath%20d='M200%20150C202.209%20150%20204%20148.209%20204%20146L204%20105L189%20105L189%20146C189%20148.209%20190.791%20150%20193%20150L200%20150Z'%20fill='%23FF833E'/%3e%3cpath%20d='M221%20133C223.209%20133%20225%20131.209%20225%20129L225%20104L192%20104L192%20129C192%20131.209%20193.791%20133%20196%20133L221%20133Z'%20fill='%23FF833E'/%3e%3crect%20x='93'%20y='131'%20width='4'%20height='52'%20rx='2'%20fill='%2399C2FF'/%3e%3ccircle%20cx='95'%20cy='203'%20r='8'%20fill='%233A85F4'/%3e%3cpath%20d='M95.0041%20214.826C101.983%20214.826%20107.991%20218.563%20110.69%20223.933C111.782%20226.107%20109.891%20228.312%20107.457%20228.312H82.5518C80.1183%20228.312%2078.227%20226.107%2079.3196%20223.933C82.0179%20218.563%2088.0258%20214.826%2095.0041%20214.826Z'%20fill='%233A85F4'/%3e%3c/g%3e%3cdefs%3e%3cclipPath%20id='clip0_3747_14126'%3e%3crect%20width='426'%20height='240'%20fill='white'/%3e%3c/clipPath%3e%3c/defs%3e%3c/svg%3e)
Коротко о главном
Инцидент: бывший инженер Cisco через 5 месяцев после увольнения удалил 456 виртуальных машин, обеспечивавших работу Webex Teams.
Путь атаки: неотозванная учётная запись в AWS → ключи доступа без ротации → широкие привилегии → удаление инфраструктуры. Ни фишинга, ни эксплойтов, ни вредоносного ПО.
Ошибки: локальная (не федеративная) учётная запись, которая не была отозвана при увольнении + отсутствие блокировки неактивных аккаунтов + ключи без ротации + избыточные права + доступ к облаку с любых IP. Именно совокупность этих ошибок сделала инцидент возможным.
Последствия: до 2 недель на восстановление, 16 000+ недоступных аккаунтов, 2,4 млн долларов убытков и репутационный ущерб. Для инженера — 2 года тюрьмы.
Почему это важно: по данным Cloud Advisor, 24% пользовательских учётных записей в публичных облаках не используются более 90 дней. За ними нет ни задачи, ни рабочей необходимости — только действующие права. Это чистый риск без единой выгоды.
Масштаб последствий
Восстановление сервиса заняло до двух недель. Свыше 16 000 пользовательских аккаунтов оказались недоступны. По данным Министерства юстиции США, Cisco потратила около 1,4 млн долларов на восстановление и свыше 1 млн — на компенсации клиентам. Данные пользователей при этом не пострадали, однако многодневный простой сервиса, которым пользуются тысячи компаний, — серьёзный репутационный ущерб для Cisco. Для бывшего инженера история закончилась приговором: два года тюрьмы и штраф 15 000 долларов.
По данным Cloud Security Alliance, недостатки в управлении идентификацией и доступом (IAM) заняли первое место среди угроз облачной безопасности в 2026 году.
Что обычно стоит за такими инцидентами
Ключевой факт, подтверждённый следствием: доступ к облаку не был отозван после увольнения и оставался рабочим почти пять месяцев.
24% пользовательских учётных записей в публичном облаке не использовались более 90 дней.
по данным исследования Cloud Advisor
«Состояние облачной безопасности в России 2026»
Однако неотозванный доступ — лишь первое звено в цепочке упущений. Инцидент можно было предотвратить как минимум на пяти уровнях, но ни один из них не был защищён.
| Несоблюдение лучших практик | Как можно было предотвратить |
|---|---|
| Учётная запись была создана как локальная, а не через федерацию удостоверений. Поэтому при увольнении она не была отозвана вместе с остальными доступами. | Используйте федерацию удостоверений: при увольнении сотрудника доступ к публичному облаку будет отзываться автоматически вместе с остальными доступами. Если федерация не применяется, включите отзыв облачных доступов в чек-лист увольнения. |
| Неактивная учётная запись не блокировалась автоматически, хотя ею не пользовались почти полгода. | Блокировать неактивные учётные записи: типовая практика — отключение после 30–90 дней без использования. |
| Учётные данные и ключи доступа не ротировались и оставались валидными месяцами. | Ввести обязательную ротацию ключей доступа. Даже если учётная запись не была отозвана, уволенный сотрудник не сможет ею воспользоваться. |
| У сотрудника были широкие права, позволявшие удалить сотни ресурсов. | Применять принцип наименьших привилегий: выдавать только необходимые разрешения и только на необходимые ресурсы. |
| Отсутствовали правила доступа сотрудников к корпоративным ресурсам. | Ограничьте доступ к панели управления облачного провайдера: разрешайте подключения только с доверенных IP-адресов, например, из офиса или по корпоративному VPN. |
Если хотя бы одна из мер была реализована, инцидент был бы невозможен. Именно комбинация упущений привела к миллионным убыткам: неотозванная учётная запись опасна вдвойне, если у неё широкие права и неротируемые ключи доступа.
Проблема в том, что вручную отслеживать такие ошибки в масштабе крупной облачной инфраструктуры практически невозможно — здесь нужны автоматизированные инструменты.
Как Cloud Advisor помогает устранять подобные угрозы
Cloud Advisor — решение класса CNAPP (Cloud-Native Application Protection Platform) для защиты облачных сред — помогает устранять риски безопасности в публичных облаках до того, как они приведут к инциденту.
Применительно к кейсу Cisco Webex Cloud Advisor выявил бы:
учётные записи, неактивные более 90 дней;
локальные учётные записи вне федерации удостоверений;
ключи доступа, которые не ротировались более 90 дней;
избыточные привилегии.
Контролем IAM возможности платформы не ограничиваются. Cloud Advisor помогает обеспечивать комплексную защиту облачной инфраструктуры: ищет уязвимости и вирусы, контролирует конфигурацию облака, обеспечивает безопасность Kubernetes, проводит другие проверки безопасности. Обладая полной картиной всего происходящего в облаке, платформа находит токсичные комбинации выявленных рисков и строит критические пути атаки. Это помогает ИБ-специалистам не «тонуть» в алертах, а фокусировать свои усилия на устранении реальных угроз безопасности.
Главный вывод
Причина инцидента с Cisco не таргетированная APT-атака, а обычный неотозванный доступ. Типичные причины таких атак: ключи без ротации и избыточные права.
Если это произошло с технологическим гигантом уровня Cisco, стоит задать вопрос: а как обстоят дела в вашей инфраструктуре? Сколько у вас ключей доступа старше 90 дней, которые имеют высокие привилегии? Сколько локальных (не федеративных) учётных записей? Сколько пользователей заходят в облако без MFA?
Ответим на эти вопросы по вашей инфраструктуре на бесплатном пилотном тестировании Cloud Advisor. Покажем, какие риски безопасности есть в вашем облаке и как их устранить.
