HTML-вложения как инструмент фишинга 🤑

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

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

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

В начале JavaScript-кода (скриншот 1) определяются константы P и W, являющиеся ключом шифрования и зашифрованным текстом, а также функция дешифрования k. Полученные дешифрованные инструкции помещаются в константу Y и имеют вид, представленный на скриншоте 2.

Как можно понять по этим инструкциям, они создают элемент iframe, содержимое которого получено из фишингового URL-адреса (его значение закодировано в base64); также установлены CSS-стили, позволяющие полученному контенту занять всю доступную область экрана. Кроме того, в этих инструкциях видим вызов метода document.write для размещения полученного контента на вкладке браузера.

Пока что это просто набор текста. Отдельно остановимся на способе запуска инструкций из константы Y. Для этого из вложения вызывается следующая часть скрипта (скриншот 3).

При определении константы H создается ссылка на глобальный объект o, которым в JavaScript-коде является window. Вызов o[X] (в X просто закодировано слово Function) эквивалентен вызову у глобального объекта свойства Function, при передаче параметров в которое они будут исполнены как новые функции. Как мы видим далее по коду, в объект передаются декодированные инструкции из константы Y.

Чтобы дополнительно усложнить детектирование исполнения вредоносного кода скрипта, злоумышленники создают пустую функцию y, переопределяют для нее метод toString, дополняя его вызовом вышеупомянутого глобального объекта window. Далее выполняется строчка U = ${y}: y преобразуется в строку, вызывая переопеределенный toString, внутри которого уже запускается загрузка контента.

Подозрительные маркеры при анализе подобных образцов — переопределение стандартных методов (вроде toString); маппинг слов из числового массива через вызов функции fromCharCode (в константе X), а также определение длинных числовых и текстовых констант с дальнейшим определением функций по их декодированию.

2️⃣ Еще один заинтересовавший нас образец содержит интересные методы «антидебага», но о них чуть попозже. Он представляет собой форму ввода учетных данных для открытия заблюренного pdf-документа.

HTML-образец содержит два скрипта. Первый после простой валидации наличия email-адреса в поле ввода содержит POST-метод, отправляющий учетные данные на сторонний сервер (скриншот 4).

Как можем видеть, в качестве query-параметра у URL-ссылки есть количество попыток. Естественно, никакой аутентификации по введенным в форму данным не производится, они просто утекают по указанному адресу. При этом параметр attempt инкрементируется, и при третьей попытке ввести в форму какие-то данные производится перенаправление на легитимный веб-ресурс. Спасибо авторам за комментарии к коду, позволившие понять, что вообще происходит.

Второй скрипт, о котором мы упомянули ранее, имеет следующий вид, представленный на скриншоте 5.

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

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

#phishing #detect #tip
@ptescalator