ЗДРАВСТВУЙТЕ, Я ВАША ТЕТЯ (CEO)
Что случилось: мошенники украли более $25 млн у транснациональной компании при помощи «дипфейк-созвона».
Как это произошло: в январе 2024 года мошенник фишинговое письмо сотруднику финансового отдела гонконгского филиала транснациональной компании. В письме злоумышленник представился финансовым директором британского филиала и попытался убедить коллегу срочно совершить перевод на большую сумму.
Конечно, сотрудник в это не поверил и попросил возможного коллегу подтвердить личность по видеосвязи. Мошенник согласился. По словам жертвы, в «дипфейк-созвоне» участвовало несколько человек – и все они выглядели и говорили как коллеги из британского офиса. Это убедило сотрудника и он перевел $25,6 млн 15-ю транзакциями.
Обман раскрылся только через несколько дней, когда сотрудник начал беспокоиться по поводу перевода и обратился в головной офис компании. Полиция Гонконга заявила, что это первый случай, когда мошенники использовали групповой дипфейк для обмана.
Алексей Дрозд: За 2024 год дипфейки совершили сразу два эволюционных скачка. Во-первых, «дипфейки подмены» (когда объекту «пересаживается» голос и лицо «донора») окончательно стали массовыми. Для замены изображения/звука в реальном времени больше не нужно сверхмощное железо и специальные навыки: появились простые инструменты, которые работают по принципу «нажми на кнопку – получишь результат», причем в неплохом качестве. Это удешевляет стоимость атаки для мошенников. Конечно, чтобы устроить жертве такое «шоу Трумана», как в описанном кейсе, злоумышленники вряд ли сделали дипфейки на коленке – но проблема в том, что для «охоты» на цели попроще таких усилий не понадобится. Поэтому растет и будет расти число инцидентов по схеме fakeboss и в ее адаптациях.
Во-вторых, мощно шагнули вперед «генерационные дипфейки». Показательный : пользователь Reddit смог сгенерировать верификационное фото (девушку с водительскими правами) при помощи нейросети. На моей памяти это первый случай, когда нейросеть синтезировала настолько достоверную подделку. Здесь проблема в том, что процесс можно автоматизировать. Поручить скрипту или чат-боту написание промптов по удачному шаблону и «штамповать» гиперреалистичные изображения людей и документов (!). Тогда, чтобы обмануть удаленную верификацию в условном каршеринге (да и многих других сервисах, включая финансовые), мошенникам не придется искать и покупать слитые паспорта, права и т.д. А сервисам в перспективе придется пересматривать механизмы верификации: сверять фото документов с базами, подключать биометрию, пока не научились массово подделывать и ее, привлекать живых людей для подтверждения личности клиентов, и так далее. Будет интересно за этим наблюдать.
БОТОФИКАЦИЯЧто случилось: в феврале 2024 года, перед увольнением из Gizmodo, Том Маккей оставил «чеховское ружье», чтобы разыграть бывших коллег. О результатах и подробностях розыгрыша Том рассказал в своем аккаунте в одной «щебечущей» соцсети.
задумки стал корпоративный аккаунт в Slack и встроенный в платформу чат-бот Slackbot. Прямо перед увольнением Том поменял имя своего профиля на Slackbot, а аватар на картинку, напоминающую более злобную версию настоящего лого чат-бота. При этом Том обошел запрет платформы на одинаковые имена пользователей, заменив «o» в имени профиля аналогичным символом в Юникоде. Так ему удалось избежать удаления своей учетной записи. Скорее всего, администраторы подумали, что ее уже удалил кто-то из коллег, а то и сам Том.
Далее Том начал общение с коллегами якобы от лица чат-бот. Отправлял им запросы на получение пароля от аккаунта, отсылал уведомления, что его (Тома) заперли в компьютере или просто шутил. Но никто из бывших коллег ничего необычного не заметил. Когда Тому надоело, он раскрыл сам себя.
Алексей Дрозд: Забавно, как даже крупные и известные сервисы не лишены «детских болячек». Например, здесь Slack попал в ловушку, известную с незапамятных времен – например, на подмене символов в названии аккаунта или домена буквально строится киберсквоттинг и создание фишинговых сайтов. А ведь на уровне сервиса это «лечится» простой проверкой входных данных: запретить при регистрации имени использовать омоглифы, символы в Юникоде и пр., что в теории позволит обойти запрет платформы на одинаковые никнеймы. Но часто бывает так, что самыми простыми вещами часто пренебрегают – и в продукте появляется брешь. И всегда найдется «Том», который проверит систему на прочность – и не факт, что остановится на шутке.
НАТАША, ВСТАВАЙ, ТЕБЯ DDoSЯТЧто случилось: кошка предупредила программиста о ночной DDoS-атаке.
Как это произошло: в апреле некий Дэнни Го в личном блоге об интересном случае из практики – и история завирусилась. По словам Дэнни, «пару лет назад» он работал в неназванном стартапе и периодически дежурил ночами – они с коллегами по очереди мониторили алерты о проблемах и в случае чего должны были оперативно их исправить.
В одно из своих дежурств Дэнни уснул. Но по счастливой случайности программиста разбудила его кошка, которая пришла к нему ласкаться посреди ночи. Спросонья Дэнни схватился за телефон – просто проверить время. И тут увидел на экране алерты от сервиса мониторинга AWS CloudWatch.
Это оказалась DDoS-атака. Дэнни заметил, что атака идет с разных иностранных IP-адресов и просто временно заблокировал весь иностранный трафик. Таким образом простая случайность помогла быстро принять меры противодействия.
Алексей Дрозд: Рассказ о кошке, будто бы почувствовавшей и «предупредившей» о проблеме, наполнен веселой мистикой – потому что приукрашен, как многие цепляющие истории. На деле все произошедшее – забавное совпадение с хорошим концом. Впрочем, это и обнадеживает. Если предыдущий кейс показывает, что никто не застрахован от банальной ошибки, то этот – как случайность может исправить ситуацию. Не предлагаю ждать вмешательства высших сил и «кошек-провидиц», которые спасут от беды, но где-то тут можно чуть расслабиться. Даже если ты «профессиональный параноик» и работаешь в ИБ, твоя задача – снизить риски до приемлемого, контролируемого уровня, а не «победить мировое зло».
СНЕЖНАЯ УТЕЧКАЧто случилось: Компания Snowflake, предоставляющая облачные хранилища и аналитические сервисы, стала жертвой кибератаки. Пострадали клиенты: Adobe, AT&T, HP, Mastercard и др.
Как это произошло: в мае на все новостные ленты прогремел взлом крупного облачного провайдера Snowflake. Тогда неизвестный доступ к облачным аккаунтам более 165 клиентов компании и выгрузил терабайты данных. Среди пострадавших клиентов оказалось много брендов-гигантов с мировыми именами. По разным , эта утечка может быть одной из крупнейших в истории. Для наглядности, только у одного клиента – британского банка Santander – в результате взлома Snowflake оказались скомпрометированы данные 30+ млн держателей карт и счетов.
После инцидента Snowflake начала расследование и привлекла в помощь специалистов из и . И тут начался хаос! Версии того, как развивались события, множатся и путаются.
Одни эксперты говорят, что хакеры сначала получили доступ к демонстрационной среде Snowflake, используя инфостилеры на ПК подрядчиков самого провайдера. Далее, имея доступ к этой среде, злоумышленники могли выполнять действия по обнаружению и извлечению информации из других демо-аккаунтов, в т.ч. клиентских. Доступ к клиентским аккаунтам был получен также через инфостилеры, а поскольку функционал демо-аккаунтов не предусматривал механизмы многофакторной аутентификации – хакер смог легко скачать корпоративные данные, зная логин и пароль.
По другой версии, злоумышленник смог войти в демо-аккаунт Snowflake, используя учетные данные бывшего сотрудника компании. Далее хакер воспользовался учетными данными от Snowflake-аккаунтов клиентов, полученными при помощи инфостилеров. МФА в них не была подключена, и хакер смог без проблем украсть их данные.
Наконец, сам хакер , что сначала взломал одного из подрядчиков нескольких компаний, которые также являлись клиентами Snowflake, затем – эти несколько компаний, а уже затем через их аккаунты – всю Snowflake. Но и в этом случае ключевой проблемой стало то, что в клиентских и демо-аккаунтах не применялась МФА. Это позволило хакеру беспрепятственно «гулять» внутри скомпрометированной инфраструктуры.
На данный момент предположительный виновник задержан, а Snowflake обновила свою по безопасности аккаунтов – теперь МФА будет применяться по умолчанию для всех обычных пользователей, а сервис будет требовать более сложные пароли.
Алексей Дрозд: Ситуация из разряда «ничего не понятно, но очень интересно». Вопросов больше, чем ответов. Например, почему у большинства клиентских Snowflake-учеток не была подключена МФА? Это ведь крупнейшие компании мира, а совершают ошибки новичков. Или – почему Snowflake только после инцидента сделала использование МФА обязательным? Получается, в чужом глазу соринку видишь…
И ТАК СОЙДЕТЧто случилось: китайские военные сдали в макулатуру секретные документы, которые впоследствии обнаружил случайный человек.
Как это произошло: китайский пенсионер по фамилии Чжан увлекался коллекционированием книг. В июне 2024 он приобрел в пункте приема макулатуры несколько случайных книг для своей коллекции. А дома обнаружил на них грифы «Конфиденциально» и «Секретно»: в книгах содержались секретные военные документы.
Пенсионер об этом в местное отделение министерства госбезопасности. Началось расследование. Оказалось, что за утилизацию документов отвечали двое военнослужащих – Го и Ли. Вместо соблюдения регламента они поленились и продали более 30 кг секретных документов в пункт приема макулатуры – всего-то примерно за $3. Нарушителей наказали, но как – доподлинно неизвестно.
Алексей Дрозд: Уж сколько раз твердили миру… – в том смысле, что подобных кейсов известно множество. Вот история, как флешку с данными всех преступников Англии и Уэльса. Вот – про с анализом планов террористов. А вот Минобороны Великобритании: за последние два года были потеряны или украдены 361 ноутбук, 98 мобильный телефон, 70 жестких дисков для компьютеров и 50 флеш-накопителей с секретными данными. И это только одно ведомство в одной стране – а проблема встречается повсюду. Секреты теряют, забывают, неправильно утилизируют (загуглите, например, «документы/данные на свалке», ссылок с историями будет не перекликать), и от такого раздолбайства не застрахован никто.
Удивительно, что проблема часто встречается в учреждениях с самой строгой политикой секретности. Это в очередной раз напоминает, что сама по себе строгость регламента от инцидентов не спасает. Если он не соблюдается, безопасности не будет. Поэтому кроме внедрения правил нужно продумывать способы контроля за их соблюдением.
ФРЕНДЛИ ФАЙЕРЧто случилось: дефектное обновление CrowdStrike вызвало миллионы «синих экранов» по всему миру.
Как это произошло: CrowdStrike – американская ИБ компания. Она занимается безопасностью конечных точек, а ее флагманский продукт – платформа Falcon. 19 июля 2024 года CrowdStrike распространила обновление для этой платформы среди своих клиентов. Но из-за неверного файла конфигурации, который отвечает за проверку именованных каналов, на всех компьютерах под управлением Windows появился синий «экран смерти».
По заявлениям CrowdStrike они быстро обнаружили неладное и приостановили распространение обновления, но пакеты, которые уже «летели» клиентам, было не вернуть. В итоге около 8,5 млн компьютеров вышли из строя. Многим компаниям пришлось остановить или ограничить свою работу. Например, по всему миру было отменено 5078 авиарейсов, а это 4,6% от всех запланированных.
После инцидента CrowdStrike выпустила патч, но его нельзя было установить централизованно, требовалось физическое присутствие у ПК. Также вендор предложил своим партнерам и интеграторам купоны UberEats в благодарность за помощь. Однако из-за того, что купон использовался слишком часто, он был отключен Uber и вызвал новую волну насмешек по отношению к компании.
Алексей Дрозд: еще с стало очевидно, что проблемы у подрядчика грозят проблемами компании-заказчику. А тут никаких хакеров или инсайдеров не потребовалось, разработчики CrowdStrike справились сами и «положили» больше 8 млн ПК. Дополнительную пикантность создает то, что это подрядчик в сфере ИБ: безопасность клиентов зависит от него во всех смыслах, и в этом они вдвойне полагаются на вендора. Получился крайне болезненный «огонь по своим».
Говоря об этом, стоит вспомнить важное правило: нельзя класть все яйца в одну корзину – то есть зависеть от одного вендора или подрядчика. Поэтому, надо сказать, у большинства крупных компаний обычно стоит сразу несколько систем даже внутри одного класса, например, несколько разных DLP. Диверсификация «спасает жизни». Второй момент – грамотный патч-менеджмент. Не стоит «раскатывать» обновления критичного ПО сразу на всей инфраструктуре, даже если очень доверяете вендору. Разработайте план и действуйте поэтапно. И обязательно дожидайтесь стабильного, проверенного билда.
КУРЕНИЕ УБИВАЕТ (ВАШЕ ПОДКЛЮЧЕНИЕ)Что случилось: сотрудник спешил на перекур, поэтому случайно «оставил» половину Африки без интернета.
Как это произошло: в августе британская The Register выпустила колонку «от читателя», которого издание представило как Пэйтона. В ней бывший инженер крупного южноафриканского интернет-провайдера рассказал о своем легендарном факапе, случившемся «несколько десятилетий назад».
В число его обязанностей на рабочем месте входило ведение списков контроля доступа (ACL). Как-то Пэйтон получил от руководства задачу, в рамках которой в ACL нужно было внести кое-какие изменения. По словам экс-инженера, задача была легкая, но тут коллеги позвали его на перекур. Он заторопился побыстрее закончить дело и «на бегу» случайно удалил часть информации из ACL. Из-за этого жители большинства стран южнее Сахары остались без интернета. К тому же ситуацией воспользовались неизвестные и заявили, что провайдера взломали.
Алексей Дрозд: Проблема «бутылочного горлышка», когда стабильность и безопасность процессов держится на одном сомнительном элементе, очень распространена и проявляется по-разному. Например, сразу вспоминается кейс банка, который остановил работу из-за севших батареек – все системы дата-центра банка работали с привязкой ко времени на радиочасах, как только они сели, все «легло». Здесь история чуть другая, но смысл тот же. Если в системе нет «защиты от дурака» (автопроверки действий оператора, дополнительного подтверждения критичных действий вроде массового удаления данных или отключения функций), то вся система – колосс на глиняных ногах, ситуации типа «я что-то нажала и все исчезло» неизбежны. Надеюсь, этот интернет-провайдер за годы после инцидента пересмотрел внутренние процессы, чтобы стабильность его услуг не зависела от внимательности одного-единственного сотрудника. Ну и раз уж появился случай напомнить: курение – зло.
ИЗ ЛЮБВИ К ИСКУССТВУЧто случилось: стажер компании ByteDance саботировал разработку нейросетей.
Как это произошло: летом 2024 года человек по имени Кейю Тянь устроился на стажировку в крупную китайскую компанию по обучению нейросетей. Но вместо работы он методично и целенаправленно превращал жизнь коллег в ад.
Тянь добавлял ошибки в код, изменял чекпоинты (файлы-сохранения обучения ИИ), параметры обучения моделей. А порой и вовсе останавливал процесс обучения, загружая Pickle-файлы с вредоносным кодом. В итоге команда из 30 программистов два месяца работала впустую. В конце концов, когда все сроки были сорваны, а деньги заказчиков (как и нервы всей команды) безнадежно потрачены, саботажника по логам.
История китайского «борца со скайнетом» стала известна СМИ в октябре: ByteDance инцидент, но подчеркнула, что он «преувеличен». Однако уже в декабре компания против бывшего стажера иск на 8 млн юаней ($1,1 млн). Довольно впечатляющая сумма для компенсации «преувеличенного» ущерба, верно?
Алексей Дрозд: История Тяня – уникальный случай. Он без видимой причины, кажется, просто «из любви к искусству» сорвал в большой компании большой проект. Однако примечательно, что как бы он ни маскировался, внедрялся в доверие и делал вид, что работает в поте лица – действовал все же довольно «в лоб». Это снова история, как пренебрежение простейшими правилами: контроля «новичков», недопуска непроверенных кадров к критичным процессам – привело к масштабным проблемам. Надеюсь, после суда миру расскажут, был ли стажер новым Джоном Коннором или имел более приземленные мотивы. А мы тем временем помним про принцип Оккама: самое простое решение часто самое верное, контроль прав пользователей и надзор за новичками правда работают.
ЧЕСТЬ ПО ЧЕСТИЧто случилось: сотрудники японского Shikoku Bank обязались сделать сэппуку, если обнаружится, что они замешаны в финансовых махинациях.
Как это произошло: в ноябре 2024 года на сайте Shikoku Bank вышла в разделе «взаимоотношения с инвесторами». В ней компания сообщает, что ее сотрудники в прямом смысле кровью подписали «договор о сэппуку».
В нем сказано, что если «работник банка украдет денежные средства или заставит это сделать других, то поплатится за это своим имуществом, а затем покончит с жизнью с помощью обряда сэппуку». Примечательна не только часть с сэппуку, но и про имущество. Так сотрудники обязуются возместить ущерб клиенту, продав свою недвижимость, машины и т.д.
Алексей Дрозд: Случай почти анекдотический – и любопытно, и крайне не хочется увидеть, как в компании случится внутренний инцидент и договор придется выполнить. Хотя логика присутствует: когда ставки при нарушении так высоки, решатся на него единицы. Это огромная мотивация соблюдать правила. В России, например, с прошлого года действует персональная – уголовная! – ответственность для руководителей ИБ за инциденты по . Тут невольно хочется пошутить: лишь бы японский пример не вдохновил на ужесточение. Но по правде, «метод кнута» работает – а у нас к тому же есть и относительный «пряник» в , где хорошая оснащенность средствами ИБ смягчает ответственность за утечки ПДн.
Напоследок хочется пожелать, чтобы инциденты ИБ оставались для вас только забавным чтивом в таких подборках. А нам – надеяться, чтобы такие подборки стало сложнее собирать: за полным отсутствием новостей, как кого-то взломали и что-то утекло. Поздравляем вас с наступающими праздниками! Пусть 2025-й будет кибербезопасным
