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

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

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

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

Бесконтактные атаки на банкоматы — лишь одна из разновидностей целенаправленных атак на банки. Кроме систем управления банкоматами, киберпреступники стараются получить доступ к системам межбанковских переводов (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 — это богатыи? фреи?мворк для проведения тестов на проникновение, позволяющеи? доставить на атакуемыи? компьютер полезную нагрузку и управлять ею.

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



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

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



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

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

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

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

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

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

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

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



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:



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



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.

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



Чтобы выдворить атакующих из сети, необходимо как минимум выявить все хосты, выполняющие роль 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.



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

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



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

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



Далее программа производит ряд стандартных деи?ствии?, которые необходимо проделать до операции выдачи наличности, и, если все они завершились успешно, банкомат выдает купюры мулу. Эта операция будет повторена столько раз, сколько указано в аргументе «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



Связь с 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. Наши консультации помогли нескольким банкам вовремя остановить атаку, полностью очистить сеть и закрыть атакующим доступ к банкоматам.