Pull to refresh
73.9

По следу Cobalt: тактика логической атаки на банкоматы в расследовании Group-IB

Reading time 13 min
Views 42K
image

В июле 2016 года работа First Bank, одного из крупнейших банков Тайваня, была парализована. Банк столкнулся с масштабной атакой: люди в масках одновременно опустошили три десятка банкоматов на $2 млн. Полиция терялась в догадках: на корпусах банкоматов не было ни следов взлома, ни накладных устройств — скиммеров. Злоумышленники даже не использовали банковские карты.

Как все происходило, зафиксировали видеокамеры: люди в масках подходили к банкоматам, звонили по мобильному — банкомат выдавал деньги, преступники складывали их в рюкзаки и убегали. После такого масштабного налета восемь крупнейших банков страны приостановили выдачу наличных в 900 банкоматах.

То, с чем столкнулся First Bank, называется логической атакой. Ее суть в том, что киберпреступники получают доступ к локальной сети банка и из нее устанавливают полный контроль над банкоматами. Удаленно они получают команду на выдачу денег. Сообщники взломщиков — “мулы” — забирают деньги и передают их организаторам атаки. Таким образом Cobalt — самая активная и опасная преступная группа — меньше чем за год атаковала банки в двух десятках стран мира.

image

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


Бесконтактные атаки на банкоматы — лишь одна из разновидностей целенаправленных атак на банки. Кроме систем управления банкоматами, киберпреступники стараются получить доступ к системам межбанковских переводов (SWIFT), платежным шлюзам и карточному процессингу.

Давайте поподробнее рассмотрим тактику логических атак на банкоматы и способы противодействия. Эта статья построена на основе отчета Group-IB о деятельности группы Cobalt, выпущенного осенью 2016 года. Часть этой информации впервые публикуется в открытом доступе.

Проникновение

Cobalt проникает в банковскую сеть через рассылку фишинговых писем с эксплойтом или исполняемый файл в архиве с паролем. Для банков СНГ преступники отправляли вложения «Договор_хранения2016.zip» и «список документов.doc». Для иностранных — «The rules for European banks.doc» и «Bitcoin ATM’s.doc».

На получение полного доступа к контроллеру домена уходит от 10 минут до 1 недели.


Фишинговые письма чаще всего рассылались от имени Европейского центрального банка, производителя банкоматов Wincor Nixdorf или региональных банков. Распознать подмену было непросто: в адресе отправителя были указаны их официальные домены. Для отправки поддельных писем в июне использовалась система анонимной рассылки писем «йаПосылалка v.2.0.» (другое название сервиса: «alexusMailer v2.0»), а позже злоумышленники стали использоваться возможности Cobalt Strike. Вообще Cobalt Strike — это богатый фреймворк для проведения тестов на проникновение, позволяющей доставить на атакуемый компьютер полезную нагрузку и управлять ею.

Вот так выглядело письмо от имени Европейского центрального банка:

image

Письма отправляли с двух серверов с IP адресами 88.212.208.115 и 5.101.124.34. Оба — находятся в России. Мы получили часть писем, отправленных с этих серверов, изучили вредоносные вложения, нашли связанные с ними экземпляры вредоносных программ и проверили, откуда в момент атаки загружались подозрительные файлы на Virus Total, онлайн-сканер, осуществляющий проверку на вирусы и вредоносные программы.

Вот пример результатов его загрузки на Virus Total:

image

Так нам удалось установить более полный список целей атак, в который вошли банки из России, Великобритании, Нидерландов, Испании, Румынии, Польши, Эстонии, Болгарии, Белоруссии, Молдавии, Грузии, Армении, Киргизии и Малайзии. В случае с First Bank, хакеры проникли в сеть филиала банка в Великобритании и через него получили доступ к сети центрального офиса.

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

Закрепление в системе

После того как вредоносное вложение было запущено, начинался процесс закрепления в системе:

1. Во вложении находились вредоносные RTF-документы, эксплуатирующие уязвимость CVE-2015-1641. При этом использовался стандартный шеллкод, генерируемый такими инструментами для тестирования на проникновение, как Metasploit и Cobalt Strike.

2. В оперативную память загружалась полезная нагрузка, которая называется Beacon, входящая в состав Cobalt Strike.

Взаимодействие с серверной частью Cobalt Strike происходит посредством создания скрытых каналов с использованием протоколов DNS, HTTP, HTTPS для предотвращения обнаружения сетевого взаимодействия с помощью стандартных систем IDS/IPS.

Список команд для Beacon:

image

3. Если метод с эксплойтом не срабатывал, атакующие повторно присылали письмо с запароленным архивом, в котором находился тот же самый Beacon.

В любом случае, после запуска вредоносного вложения Beacon загружался только в оперативную память. Это означает, что после перезагрузки операционной системы атакующие теряли контроль над этим компьютером.

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

В реальных атаках мы наблюдали замену файлов с именами iusb3mon. exe (Intel® USB 3.0 eXtensible Host Controller) и jusched.exe (Sun Java Update Scheduler). В результате такой замены службы, которые должны были автоматически запускать легальные программы, запускали вредоносные приложения.

4. В тот же каталог, где находились замененные легальные исполняемые файлы, копировалась и библиотека с именем crss. dll. Каждый раз при старте операционной системы замененные приложения загружали эту библиотеку в память. Ее основной задачей была загрузка из интернета модуля Beacon в оперативную память.

Таким образом обеспечивалась жизнеспособность основной программы. После каждой перезагрузки операционной системы основной модуль удалялся. Все описанные выше шаги выполнялись автоматически после запуска вредоносного вложения. На тот случай, если зараженный компьютер выключат или переустановят операционную систему, нужно было наладить постоянный доступ к локальной сети. Для этого необходимо было повысить привилегии.

Получение привилегий

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

Начиная с Windows Server 2008 в групповых политиках была добавлена дополнительная функциональность — Group Policy Preferences (GPP). GPP позволяют администраторам применять множество политик: автоматическое назначение сетевого диска в момент входа пользователя в свой компьютер, обновление имени встроенной учетной записи администратора, создание новых пользователей, внесение изменений в реестр и т.п.

Такие действия, как добавление локального пользователя, подключение сетевого диска или принтера могут потребовать указания пароля. Когда такие политики будут загружаться для применения на отдельном компьютере, они будут делать это вместе с указанным паролем. Пароль, зашифрованный с помощью алгоритма AES-256 и дополнительно кодированный по Base64, хранится в конфигурационном файле GPP Groups.xml.

Этот XML-файл создается не всегда, а когда, например, создается или меняется встроенная учетная запись администратора. Файл хранится на контроллере домена в подкаталоге директории SYSVOL и, как и сам каталог, доступен любому пользователю в домене.

Атакующие используют Groups.xml для извлечения пароля администратора домена следующим образом:

1. После получения доступа в локальную сеть они находят контроллеры домена, которые указаны в настройках компьютера.
2. На контроллерах домена они проверяют наличие директории SYSVOL и файла Groups.xml, который доступен по следующему пути: «\\[server_name]\sysvol\[domain_name]\Policies\[group_policy_ name]\Machine\Preferences\Groups\Groups.xml»
3. Из файла Groups.xml они извлекают логин и пароль администратора домена из полей cpassword и userName.

Фрагмент файла Groups.xml:

image

4. Для получения пароля в открытом виде атакующие декодируют пароль по Base64, получая строку вида 2412D5A8073B0B9EEF429FB6AF94B737C95E66B685409A1FD9C36509DF7D6166
— это пароль, зашифрованный с помощью AES-256.
5. Полученный зашифрованный пароль расшифровывается с помощью ключа 4e9906e8fcb66cc9faf49310620ffee8f496e806cc057990209b09a433b66c1b, опубликованного на официальном сайте Microsoft MSDN.

image

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

При такой конфигурации контроллера домена атакующие получали к нему доступ за 10 минут.


Еще один способ извлечения логинов и паролей из оперативной памяти зараженного компьютера был связан с использованием бесплатного инструмента Mimikatz. Исходный код этой утилиты опубликован на Githud, доступен всем и встроен в некоторые инструменты для тестов на проникновение, включая Cobalt Strike.

Закрепление на зараженном компьютере/сервере

Итак, у атакующих есть как минимум один хост с Beacon. Им необходимо иметь доступ к множеству компьютеров, в том числе к тем, которые не имеют выхода в интернет. Для этого в локальной сети банка они выстраивали свою мини-сеть из зараженных компьютеров, которыми можно было управлять через единую консоль Cobalt Strike, установленную на удаленном сервере и предоставляющей возможность коллективной работы.

Весь процесс можно описать следующим образом:

  • На хостах с доступом в интернет запускалась версия Beacon, которая устанавливала соединение с удаленным сервером управления по скрытому каналу. Для предотвращения обнаружения такого сетевого взаимодействия с помощью стандартных систем IDS/IPS использовались протоколы DNS, HTTP, HTTPS. Таких хостов было немного, и они обеспечивали возможность взаимодействия с другими хостами в локальной сети. Назовем их master-node.

  • Наибольший интерес в банке представляют изолированные хосты, не имеющие доступа в интернет. Но даже если доступ разрешен, создание соединения с удаленным сервером на критичных системах вызывает подозрения у бдительной службы безопасности. Чтобы управлять такими хостами и не вызывать подозрения у систем обнаружения аномалий, атакующие использовали специальную версию Beacon, которой можно управлять только из локальной сети по протоколу SMB с использованием pipe. Назовем их slave-node.

  • Cobalt Strike позволяет связывать master-node и slave-node через специальный канал по протоколу SMB. Таким образом, slave-node становятся доступны в удаленной центральной консоли управления Cobalt Strike. Т.е. изолированные хосты получают доступ в интернет через master-nod, которые становятся шлюзом для slave-node.

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

image

Чтобы выдворить атакующих из сети, необходимо как минимум выявить все хосты, выполняющие роль master-node, и вывести их из сети единовременно, иначе у преступников появляется шанс восстановить работу в течении нескольких минут.

Обеспечение резервного канала доступа

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

Несмотря на то, что Cobalt Strike имеет встроенный модуль удаленного доступа по VNC, атакующие перестраховывались и загружали модифицированный установщик TeamViewer — легальный инструмент удаленного доступа. Восстановить установщик полностью не удалось, поэтому мы предполагаем, что основным отличием от официального приложения является сокрытия оповещения о том, что к компьютеру осуществлено удаленное подключение, как это было в атаках других преступных групп в России. Подготовка завершена — впереди оставался последний этап — вывод денег.

Получение доступа к банкоматам

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

Получив доступ к компьютеру или серверу, с которого разрешен доступ к банкоматам, атакующие использовали стандартные инструменты удаленного доступа, используемые в банке. Как правило, это протокол удаленного управления Microsoft Remote Desktop Protocol.

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

Программа, используемая для выдачи денег из банкоматов, является уникальной и используется только одной этой группой.


Программное обеспечение для атаки на банкоматы


После получения удаленного доступа к банкоматам на него загружаются три файла:

  • скрипт del.bat, который запускал программу SDelete с нужными параметрами.


Содержимое скрипта del.bat

sdelete.exe -accepteula -p 32 d2.exe
sdelete.exe -accepteula -p 32 xtl.exe
sdelete.exe -accepteula -p 32 *.txt
sdelete.exe -accepteula -p 32 d2s.exe
del sdelete.exe
del del.bat

  • легитимная программа SDelete (опубликована на сайте Microsoft). Ее предназначение — удаление файлов специальным образом, чтобы их было невозможно восстановить в ходе криминалистического исследования.

  • вредоносная программа, использующая стандартные функции по интерфейсу XFS через XFS Manager (eXtensions for Financial Services). Именно эта программа по команде из внутренней сети банка начинает выдачу денег.

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

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

Аргументы командной строки должны располагаться в следующим порядке:


ServiceLogicalName — имя сервиса, используемое в качестве аргумента для функции WFSOpen (например «Cash Dispenser Module»).

Cassettes Count — общее число кассет, присутствующих на устройстве. Значение должно быть в интервале от 1 до 15.

Cassette Number — номер кассеты, из которой следует выдать наличность. Значение должно быть в интервале от 1 до 15.

Banknotes Count — число банкнот, которое необходимо выдать из кассеты. Значение должно быть в интервале от 1 до 60.

Dispenses Count — какое количество раз необходимо повторить выдачу наличности. Значение должно быть в интервале от 1 до 60.

image

Все эти значения указываются в консоли оператором, который подключен к банкомату удаленно.

Если все аргументы были переданны корректно, выводится сообщение, отображающее параметры, в соответствии с которыми будут производиться дальнейшие действия.

image

Далее заполняется массив, каждый элемент которого соответствует номеру кассеты в устройстве. Количество элементов массива должно совпадать с общим количеством кассет. Значение, которое хранит каждый элемент массива, означает количество банкнот, которые необходимо выдать из соответствующей кассеты. Нумерация элементов массива начинается с 1.

В процессе функционирования программа получает данные о системном времени, и, в случае если оно не соответствует указанному в коде программы, завершает свою работу.

image

Далее программа производит ряд стандартных действий, которые необходимо проделать до операции выдачи наличности, и, если все они завершились успешно, банкомат выдает купюры мулу. Эта операция будет повторена столько раз, сколько указано в аргументе «Dispenses Count».

При успешном завершения каждой такой операции в файл с именем «disp. txt», расположенный в в том же каталоге, что и вредоносная программа, записывается текстовая строка «Cassettes Count: Banknotes Count», где «Cas-settes Count» и «Banknotes Count» значения соответствующих аргументов.

Было обнаружено две версии такой программы. Одна имела имя d2.exe, а вторая d2sleep. exe. Разница между ними заключалась лишь в том, что вторая выдавала наличность с небольшой паузой — 1 секунда.

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

Кроме того, операторы выводили из строя внутренние серверы банка, с которого осуществлялись атаки на банкоматы, с помощью вредоносной программы MBRkill- er, которая удаляла записи MBR (master boot record). Все это сильно усложняет криминалистическое исследование атаки.

Атака на банкоматы

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

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

Часто мулы въезжают в страну по туристическим визам специально для осуществления атаки и покидают ее как только операция окончена. Через несколько дней после атак на банкоматы First Bank в Таипее были задержаны граждане Латвии и Румынии. Оставшиеся 13 подозреваемых, включая граждан России, успели покинуть остров.

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

После каждого успешного выполнения операции по выдаче наличных программа записывает специальный лог (файл с именем «disp.txt») с информацией о количестве банкнот, выданных из каждой кассеты. Оператор передает этот лог-файл организатору, который использует полученные сведения для контроля цепи обналичивания.

Как устроена группа Cobalt

image

Связь с Buhtrap

Расследуя логические атаки Cobalt на российские и европейские банки, мы заметили, что механизмы доставки фишинговых писем и получения доступа к контроллеру домена идентичны методам, которые раньше использовала группа Buhtrap. С августа 2015 по январь 2016 она похитила со счетов российских банков более 1,8 млрд рублей.

После того, как в мае 2016 года были задержаны люди, занимавшиеся обналичкой украденных денег для группы Buhtrap, хищения со счетов банков с помощью одноименного трояна прекратились, однако бот-сеть продолжила существовать.

Можно предположить, что как минимум часть участников группы Buhtrap вошла в Cobalt или, что не менее вероятно, костяк Buhtrap просто переключился на атаки на банкоматы.


Как отразить логические атаки

Логические атаки набирают все большую популярность. Количество инцидентов будет только расти. Для совершения атаки не требуется дорогостоящая разработка сложного программного обеспечения — большинство инструментов находится в открытом доступе.

  • Чтобы предотвратить заражение через фишинговое письмо с вложенным эксплойтом, рекомендуется не открывать подозрительные письма и своевременно обновлять программное обеспечение Microsoft. Cobalt пока не использовала уязвимости нулевого дня. Их эксплойты —старые. Поэтому даже обычное обновление программного обеспечения не позволяло атакующим попасть в корпоративную сеть. К сожалению, в некоторых атакованных банках это требование не соблюдалось.

  • В тех случаях, когда атакующие сталкивались с обновленным программным обеспечением, они отправляли вложения с исполняемым файлов в архиве с паролем. Такие атаки можно отбить, отправляя подобного рода письма в карантин на динамический анализ в изолированной среде (“песочнице”).

  • Развертывание атаки после получения доступа в сеть банка может занять дни, а иногда месяцы. Используйте это время для выявления действий атакующих. Проверьте настройки контроллера домена и наличие файла Groups.xml в каталоге SYSVOL с зашифрованным паролем на стандартном ключе AES-256, как это было описано в разделе о получении привилегий.

  • Установите на банкоматы программное обеспечение для контроля целостности.

Эти рекомендации помогут предотвратить хищения, но свести риски к минимуму позволяет только работа на опережение с помощью данных Threat intelligence (Киберразведки) и использование специализированные решения для обнаружения целевых атак.

Подписчики нашего сервиса Threat Intelligence узнали о тактике и механике атак Cobalt еще летом 2016. Наши консультации помогли нескольким банкам вовремя остановить атаку, полностью очистить сеть и закрыть атакующим доступ к банкоматам.

В Group-IB знают о киберпреступности всё, но рассказывают самое интересное.

Остросюжетный Telegram-канал (https://t.me/Group_IB) об информационной безопасности, хакерах и кибератаках, хактивистах и интернет-пиратах. Расследования нашумевших киберпреступлений по шагам, практические кейсы с применением технологий Group-IB и, конечно, рекомендации, как не стать жертвой в интернете.

Фотолента Group-IB в Instagram www.instagram.com/group_ib
Короткие новости в Twitter twitter.com/GroupIB

Group-IB — один из ведущих разработчиков решений для детектирования и предотвращения кибератак, выявления мошенничества и защиты интеллектуальной собственности в сети со штаб-квартирой в Сингапуре.
Tags:
Hubs:
+24
Comments 17
Comments Comments 17

Articles

Information

Website
www.facct.ru
Registered
Founded
Employees
501–1,000 employees
Location
Россия