Взлом Sony Entertainment, ограбление центробанка Бангладеш и дерзкие атаки на систему SWIFT по всему миру, уничтожение данных южнокорейских медиа- и финансовых компаний. Казалось бы, между этим акциями нет ничего общего. И каждый раз это были одни и те же ребята из группы Lazarus.
Впечатляют и масштаб кампаний, и разнообразие, и объем затрат – только наши исследователи смогли увязать с Lazarus более 150 вредоносных инструментов! Фактически для каждой атаки хакеры писали новые инструменты – от эксплойтов до стирателей. Код был новый, но не полностью, что в конечном итоге их и выдало. Подробный отчет об известной деятельности Lazarus содержит 58 страниц, здесь же я приведу наиболее любопытные моменты.
Изменчивость и наследственность
На самом деле связать все вышеописанные атаки с Lazarus очень и очень сложно. В первую очередь потому, что девиз парней – постоянное изменение применяемых инструментов. В большинстве случаев компиляция происходит не более чем за два дня до атаки. Это делает полностью бесполезными инструменты сигнатурного анализа и сильно ограничивает эффективность Yara. Именно поэтому на первый взгляд все эти атаки проводятся разными людьми, однако полное погружение в код говорит нам об обратном.
Взяв на вооружение изменчивость, хакеры не смогли избежать наследственности. Писать каждый раз код с нуля не только сложно, но и крайне накладно. Поэтому определенная преемственность между разными на первый взгляд инструментами прослеживается совершенно четко. К примеру, сравнение семплов из Бангладеш и Юго-Восточной Азии показывает, что функция записи в лог была перенесена в новый код с небольшими модификациями – новый код пишет в лог еще и ID текущего процесса.
При сравнении малвари, найденной после двух других инцидентов, исследователи из компании Novetta заметили использование одного и того же магического числа 0xA0B0C0D0 файла конфигурации в двух разных инструментах, что точно нельзя списать на совпадение (см. lpFileData на скриншоте).
После публикации отчета Novetta хакеры это исправили, но не вполне – число другое, но алгоритм проверки тот же самый.
И, кстати, если вы думаете, что тут описаны последовательные эволюции кампаний Lazarus, вы ошибаетесь. По заключению наших аналитиков, атаки на ЦБ Бангладеш и упомянутого банка из Юго-Восточной Азии проводились одновременно и практически синхронно, это говорит о том, что это части одной большой операции по извлечению сотен миллионов долларов.
SWIFT под прицелом
Мы полагаем, что добычей денег для финансирования операций Lazarus занимается отдельное подразделение внутри группы. Наши аналитики окрестили его Bluenoroff (по названию одного из инструментов, используемых в атаках на банках). Блюнороффы сфокусированы на банках, казино, разработчиках финансового софта и криптовалютных сервисах. Мотивация прозрачна, методы хитроумны, география чрезвычайно обширна – от Мексики до Малайзии.
Bluenoroff не интересует кража и уничтожение данных. Их цель – исключительно живые деньги.
Схемы атак Bluenoroff на банки просты, но эффективны. Группа очень хорошо изучила софт SWIFT (международной сети межбанковских переводов), и вероятно, периодически его реверсит. Начинается все как обычно, со взлома сети банка.
Исследователи описали несколько примечательных векторов:
— Компрометация свежеустановленного веб-сервера банка. Вообще банк поступил осмотрительно, наняв пентестеров для проверки защиты сайта. Ну а Lazarus взломали его прямо во время проведения тестов. Тут есть две возможности: либо хакеры успели воспользоваться уязвимостью, закрытой после пентеста, либо забэкдорили шелл, который сами пентестеры и воткнули на сервер. В любом случае это красиво.
— Польский банк был заражен через сайт польского финансового регулятора. Хакеры внедрили на сайт эксплойт для IE, который запускал на атакованной машине загрузчик малвари.
— Эксплойт для Adobe Flash, размещенный на сайте производителя стройматериалов. Любопытно, что хакеры успешно эксплуатировали давно закрытую уязвимость. Как оказалось, на зараженной машины стоял Flash версии 20.0.0.235, выпущенный еще в декабре 2015 года. Все это время он регулярно пытался обновиться, но ничего не получалось – апдейтер не мог найти в сети банка прокси-сервер, чтобы подключиться к серверу обновлений.
Затем атака скрытно распространяется по сети, при этом кейлоггером собираются учетные данные сотрудников (вдруг попадется администратор).
Объем файла: 73216 байт
Тип: PE32+ (DLL) (GUI) x86-64, MS Windows
Дата линковки: 2016.04.06 07:38:57 (GMT)
Версия линковщика: 10.0
Оригинальное название: grep.dll
Где пойман: инцидент #1 (атака на банк в Юго-Восточной Азии)
Характер: нордический, выдержанный.
Кейлоггер пространства пользователя, после запуска создает новый тред, который, по всей видимости, должен быть загружен каким-то PE-загрузчиком (например DLL-инжектором). Поток задает класс Shell TrayCls%RANDOM%", где %RANDOM% – целое случайное, генерируемое системным генератором из зерна в виде системного времени. Затем поток создает окно “Shell Tray%RANDOM%. Новое окно регистрирует перехватчик клавиатуры и начинает записывать нажатия на клавиши и текст из буфера обмена.
Протокол кейлоггер ведет в файле, расположенном в каталоге профиля пользователя, название задается как NTUSER{%USERNAME%}.TxS.blf. Данные шифруются по RC4 с 64-байтным ключом (захардкоденным). Ключ не вполне случайный, похоже, внутри ошметки ASCII-текста, то ли из базы данных, то из запросов к БД:
"SUM.0USD0,0>'DBT LIMITCUSD0,..CDT.SUM.1USD265,0.7CDT.LIMIT.USD0,"
Возможно, это сделано, чтобы затруднить распознавание ключа при анализе кода, или для ложных срабатываний сигнатурного анализа, если кто-то додумается включить в сигнатуру часть этого ключа.
Бинарный файл протокола кейлоггера состоит из записей, организованных в блоки по событиям:
1. Старт сессии. Внутри имя пользователя, тип сессии (конольный, RDP, и т.д.), идентификатор сессии.
2. Действия в этой сессии. Имена активных окон и последовательности нажатых клавиш.
3. Окончание сессии. Имя пользователя и идентификатор сессии.
Каждая запись содержит временную отметку в DWORD.
Кейлоггер также запускает сторожевой поток, который отслеживает создание файла ODBCREP.HLP в директории текущего DLL. Если файл обнаружен, кейлоггер удаляет клавиатурный перехватчик и выгружается из памяти.
Тип: PE32+ (DLL) (GUI) x86-64, MS Windows
Дата линковки: 2016.12.08 00:53:43 (GMT)
Версия линковщика: 10.0
Имя экспорта: wide_loader.dll
Где пойман: инцидент #2 (атака на европейский банк)
Модуль упакован Enigma Protector и реализован в качестве сервисного бинарника с процедурой ServiceMain. На старте он импортирует все необходимые функции системного API и ищет файл %SYSTEMROOT%Help%name%.chm, где %name% – название текущего DLL модуля. Затем модуль расшифровывает код из .chm по алгоритму Spritz с захардкоденным 64-байтным ключом
Далее он ищет целевой процесс и пытается внедрить расшифрованный код в его адресное пространство. Умеет выполнять инжекцию с двумя процессами на выбор – lsass.exe или в свой собственный сервисный процесс. Куда именно – определяется при компиляции модуля. Найденный семпл внедрял код в свой процесс.
В Европе и на Ближнем Востоке были обнаружены еще несколько семплов инжектора, с названиями srservice.dll, msv2_0.dll, SRService.dll и разного объема. Они отличаются тем, что не упакованы Энигмой, и используют 32-байтныые ключи. Выполняют они те же самые задачи – внедряют код в lsass.exe или в свой процесс. И в этих случаях в .chm содержался активный бэкдор.
Наконец, когда в сети обнаружен и инфицирован сервер SWIFT, хакеры перехватывают сессию администратора и манипулируют базой данных. В результате миллионы долларов (в случае бангладешского ЦБ – $81 млн) уходят не по адресу.
После нашумевшей атаки на Бангладеш SWIFT обновил свой софт, добавив дополнительные проверки целостности кода и базы данных. Надо сказать, что блюнороффов это совершенно не смутило – уже в следующей атаке их малварь ловко отключила эти проверки. Что характерно, возвращать софт в исходное состояние она тоже умеет.
Запутывание следов
Любопытный момент – хакеры контролируют взломанные системы посредством набора бэкдоров, через TCP-туннель. Однако не напрямую: зараженные машины образуют ретрансляционную цепь, и весь бэкдор-трафик идет через один туннель, с одной из машин. Это затрудняет обнаружение и локализацию заражения. Даже если админ выявит машину, поддерживающую соединение с C&C-сервером, определить другие скомпрометированные узлы будет не так непросто.
Дата обнаружения: 2016.08.12 01:11.31
Путь обнаружения: C:Windowswinhlp.exe
Объем файла: 20480 байт
Время последнего запуска: 2016.08.12 21:59
Запускается из: svchost.exe (стандартный подписанный бинарник Windows)
Тип: PE32 (DLL) (GUI) 80386, MS Windows
Дата компиляции: 2014.09.17 16:59:33 (GMT)
Версия линковщика: 6.0
Где пойман: инцидент #1 (атака на банк в Юго-Восточной Азии)
Эта штука работает как TCP-ретранслятор, который шифрует коммуникации с командным сервером. Можно конфигурировать удаленно. Запускается как минимум с двумя параметрами: IP и порт хоста A. Есть два опциональных параметра: IP и порт хоста B (для исходящего соединения). Эти параметры могут быть переданы и с сервера управления.
Процедура соединения с командным сервером начинается с генерирования ключа хэндшейка с помощью простого алгоритма:
i = 0;
do
{
key[i] = 0xDB * i ^ 0xF7;
++i;
} while ( i < 16 );
Ключ получается такой, если интересно: 2c 2d 2e 2f 28 29 2a 2b 24 25 26 27 20 21 22.
После этого создается тело сообщения – строка длиной от 64 до 192 байт. Пятое DWORD заменяется на специальный код 0x00000065 (“e”). Сообщение шифруется ключом хендшейка и посылается командному серверу.
Структура пакета такая (голубые строки – данные, шифрованные по RC4 ключом хендшейка):
Сервер отвечает похожим пакетом, в котором первое DWORD – размер, в остальной части пакета осмысленное значение только одно, по смещению 0x14. Если хендшейк неуспешный, там должно быть 0x00000066 (“f”). Если хендшейк успешен, туннель создает поток TCP-соединения с командным сервером, зашифрованный по RC4 хардкоденным 4-байтным ключом.
Проанализированный семпл использует для связи бинарный протокол, обмениваясь с сервером шифрованными 40-байтными блоками. В каждом блоке DWORD по смещению 0x4 задает команду.
В случае команды 0x10003 в блоке также задаются IP и порт по смещениям 0x10 и 0x14 соответственно. В прочих случаях оставшееся пространство блока заполняется случайными значениями. Подключение к хосту B инициализируется по команде 0x10002. При этом открывается TCP-сессия с хостом A, выполняется хендшейк, и далее данные передаются от A к B и обратно без изменений.
Разные варианты этого инструмента были обнаружены в Коста-Рике и Эфиопии, и еще вариант был загружен в мультисканнер из Бангладеш.
Lazarus применяют несколько новых интересных техник. Мы полагаем, что злоумышленники осведомлены о том, какие проблемы при расследовании кибератаки вызывает разделение ответственности между SWIFT и банком. И они стали разделять свою малварь таким образом, чтобы одна часть хранилась в системах, подключенных к SWIFT, а другая на собственных системах банка. Так они пытаются затруднить обнаружение следов атаки как со стороны банка, так и со стороны SWIFT – и как раз тут третья сторона, например «Лаборатория Касперского», имеет преимущество. Мы можем увидеть картину в целом.
Технически это реализовано разделением файлов, которые должны быть собраны обратно для получения функционирующего вредоносного процесса. Мы это наблюдали уже дважды и твердо уверены, что это не совпадение.
При расследовании ИБ-инцидента обычно анализируют систему как целое, исследуя дамп памяти и образ диска. Мало кому придет в голову, что система может быть наполовину зараженной, и что второй ингредиент атаки живет где-то в другом месте. Аналитик запросто может из-за деревьев не увидеть леса, замкнувшись на анализе замкнутой системы. Собственно потому мы и считаем, что эта техника применена для того, чтобы затруднить расследование.
Даже если удалось добыть все компоненты всех этапов атаки, воспроизвести атаку будет непросто. Дело в хитроумной схеме запуска цепочки – каждый компонент требует пароля для расшифровки кода, который предыдущий компонент должен передать в параметрах запуска. И без первого пароля, который известен только самому первому компоненту – установщику, исследователи не смогут понаблюдать за поведением малвари, и дизассемблировать код будет почти невозможно.
Кстати, всю деятельность Lazarus ведут в нерабочие часы часового пояса жертвы, и тщательно подчищают за собой логи.
Lazarus совсем не палится
Расследования многих акций группы указывали на Северную Корею, однако признаки были сплошь косвенные. В основном выводы основывались на возможном мотиве. К примеру, атака на Sony Entertainment была проведена незадолго до премьеры «Интервью», комедии, в финале которой убивают лидера КНДР Ким Чен Ына. В результате премьеру пришлось отложить (но не отменить). Аналогично и атаки на южнокорейские сайты – никто так и не смог придумать, кому бы это могло понадобиться, кроме «северного соседа». Но в случае банковских ограблений такая логика неприменима – деньги нужны всем.
Lazarus старательно подчищают следы и оставляют ложные флаги, чтобы препятствовать точной атрибуции. Нередко пытаются перевести стрелки на знаменитых рашн хакерс. В частности, в коде эксплойта, взятого для атаки на польские банки в январе 2017 года, нашли русские слова. Причем какие! Xoroshspat, vyzov_chainika, podgotovkaskotiny. Не знаю, кто как, а я только так и называю метки, когда пишу код. В бэкдоре также обнаружились слова вида kliyent2podklyuchit, ustanavlivat, poluchit, nachalo. Все это звучит очень странно, как будто иностранец выбирал слова из разговорника.
Подвела наших героев и еще одна небольшая небрежность. Исследователям удалось захватить европейский сервер управления и контроля, который использовала группа. Анализ показал, что хакеры установили Apache Tomcat, сконфигурировали его, загрузили JSP-скрипт для удаленного управления малварью и принялись тестировать. А после тестирования решили чуток подзаработать, – и правда, зачем процессорным ресурсам простаивать, – и нахлобучили на сервер майнер криптовалюты Monero. Майнер оказался кривоват, и подвесил сервер напрочь. Тот стал недоступен, и хакеры не смогли зачистить все следы, в частности, лог Апача.
А в логе нашлось интересное. Оператор подключал к серверу тестовые установки бэкдора, осмотрительно используя прокси и VPN. Поэтому в логе фигурируют IP-адреса из Франции и Южной Кореи, но есть и кратковременное подключение из очень необычного диапазона 175.45.176.0 – 175.45.179.255, который принадлежит северокорейскому провайдеру Star JV. Возможно, оператор по оплошности зашел со своего IP, хотя доказательством это, конечно, назвать нельзя: раз в интернете есть компьютеры из КНДР, их точно также можно взломать и использовать для заметания следов.
В заключение скажем, что процесс извлечения мякотки из банков у Bluenoroff не слишком оперативен: в большинстве случаев они долго пасутся внутри сети, потихоньку изучая ее, собирая учетные данные администраторов и тестируя разные методы на серверах SWIFT. Например, атака на азиатский банк, откуда мы получили часть семплов, длилась более девяти месяцев. А это можно назвать прекрасным доказательством постулата “даже если вас взломали, ущерб еще можно предотвратить”. У пострадавших было достаточно времени для этого, вот только не хватило внутренней экспертизы понять, что их грабят – медленно, но верно.
Автор: «Лаборатория Касперского»
