Суд в США признал 34-летнего жителя Вирджинии Сохаиба Ахтера виновным по делу об уничтожении десятков государственных баз данных после увольнения из компании-подрядчика. По версии обвинения, за несколько часов он и его брат-близнец стерли около 96 баз, где хранились чувствительные материалы федеральных ведомств.

История важна не только для госсектора. Она показывает, как быстро бывший сотрудник с техническими правами может превратить конфликт при увольнении в крупный инцидент с потерей данных, расследованиями и уголовным сроком.

Что произошло после онлайн-увольнения

Ахтер работал федеральным подрядчиком в компании, которая сотрудничала более чем с 45 ведомствами США и размещала государственные данные на серверах в городе Ашберн. Вместе с ним там работал его брат Муниб Ахтер.

18 февраля 2025 года компания уволила обоих во время удалённой онлайн-встречи. Причиной стало прошлое уголовное дело Сохаиба: работодатель обнаружил, что раньше он уже получил срок за незаконный доступ к системам Госдепартамента США.

По данным Минюста США, сразу после увольнения братья вошли в компьютерные системы без разрешения. Обвинение утверждает, что они переводили базы в режим запрета записи, удаляли их и пытались скрыть следы.

Суд уже признал Сохаиба Ахтера виновным. Приговор ему должны вынести 9 сентября 2026 года; максимальное наказание — 21 год лишения свободы.

Почему прошлый приговор не остановил новый инцидент

Это не первое дело братьев Ахтеров. В 2016 году они признали вину в незаконном доступе к системам Госдепартамента США и краже персональных данных десятков коллег, а также федерального сотрудника правоохранительных органов, который расследовал их действия. Оба получили несколько лет тюрьмы.

После освобождения братьев снова наняли как подрядчиков. Подобные решения часто принимают не сами ведомства, а цепочка внешних компаний, субподрядчиков и кадровых служб. Чем длиннее цепочка, тем выше риск, что проверка биографии, прав доступа и реальных обязанностей разойдётся по разным людям и системам.

Для бизнеса вывод прямой: опасен не только внешний хакер. Опасен сотрудник или подрядчик, у которого остались права администратора, доступ к облачным панелям, ключи к базам данных и понимание, где лежат самые важные файлы.

Какие данные могли пострадать

Согласно судебным материалам, братья стерли около 96 государственных баз данных за несколько часов в феврале 2025 года. Среди них, по данным обвинения, были чувствительные материалы расследований нескольких федеральных ведомств и записи по американскому закону о свободе информации — Freedom of Information Act, FOIA.

Удаление базы данных — не то же самое, что потеря одного файла на рабочем столе. В базе могут лежать заявки граждан, служебная переписка, материалы проверок, внутренние журналы, сведения о сотрудниках и технические метаданные. Даже если резервная копия есть, восстановление занимает время, а часть операций ведомства может встать.

Отдельный эпизод касается попытки скрыть следы. По версии обвинения, после удаления базы Министерства внутренней безопасности США один из участников спросил у ИИ-помощника, как очистить системные журналы. Сам по себе вопрос к искусственному интеллекту не доказывает преступление, но для следствия такие действия выглядят как попытка замести следы.

Похожая логика работает и при утечках из корпоративных систем: если злоумышленник забирает ключи, токены или журналы, расследование резко усложняется. Мы уже разбирали, как технические ошибки ведут к раскрытию секретов, в материале про утечку ключей API и переписок из Ollama.

Где компаниям чаще всего не хватает контроля

Инсайдерская атака почти всегда начинается раньше, чем заметит служба безопасности. Человек получает доступ «на время проекта», потом проект заканчивается, команда меняется, а права остаются. Администраторская учётная запись живёт годами, пароль попадает в скрипты, токен — в хранилище кода, а отключение сотрудника после увольнения превращается в ручную гонку.

Удалённое увольнение добавляет риск. Если сотрудник в момент разговора ещё подключён к рабочим системам, у него остаются минуты или часы для вредных действий. Для человека с доступом к базам этого достаточно.

Слабое место — журналы событий. Компании часто собирают их формально, но не связывают входы, команды администратора, массовое удаление и смену прав в единую картину. Когда тревога выглядит «низкоприоритетной», её легко пропустить. О том, почему такие сигналы нельзя списывать со счетов, SAFENET21 писал в статье о слабых тревогах в SOC, где SOC означает Security Operations Center — центр мониторинга безопасности.

Почему ИИ в этой истории важен, но не главный

В деле фигурирует запрос к ИИ-помощнику о том, как очистить журналы. Это не превращает искусственный интеллект в соучастника и не делает его причиной атаки. Главная проблема была в доступах, контроле действий и скорости реакции после увольнения.

ИИ лишь снизил порог для поиска технических подсказок. Раньше сотрудник искал команды в документации, форумах или старых заметках. Теперь он может спросить чат-бота обычным языком. Поэтому компаниям стоит отслеживать не только внешние атаки, но и опасные сценарии внутри рабочих процессов: массовое удаление, попытки стереть журналы, скачивание архивов, изменение прав перед уходом сотрудника.

Для удалённых администраторов важна и защита канала связи, особенно в поездках и публичных сетях. В таких ситуациях помогает сервис безопасного интернет-соединения, который снижает риск перехвата рабочих данных при подключении из кафе, гостиниц и коворкингов.

Что сделать прямо сейчас

  • Проверьте, кто имеет административный доступ к базам данных, облачным панелям, резервным копиям и системам журналирования.
  • Уберите общие учётные записи. У каждого администратора должен быть личный логин, многофакторная проверка и понятная зона ответственности.
  • Настройте сценарий увольнения: блокировка учётных записей, отзыв токенов, закрытие удалённых сессий и изъятие рабочих устройств должны идти до финального разговора или одновременно с ним.
  • Включите неизменяемые журналы событий. Администратор не должен иметь право стереть логи о собственных действиях без отдельного следа.
  • Проверьте резервные копии не на бумаге, а тестовым восстановлением. Важно знать, сколько времени займёт возврат базы и какие данные потеряются.
  • Настройте тревоги на массовое удаление таблиц, запрет записи, смену прав и очистку журналов. Это признаки инцидента, а не обычной админской работы.
  • Разделяйте бытовые сбои и угрозы: если не работает мобильный интернет на телефоне, это чаще проблема связи, но внезапные входы в рабочие аккаунты и запросы кодов подтверждения требуют проверки безопасности.
  • Подготовьте короткий план для руководителей: кому звонить, какие доступы отключать, где лежат резервные копии и кто принимает решение об остановке системы.
Поделиться: